On Thu, Jan 2, 2014 at 1:35 PM, Rafał Miłecki <zajec5@xxxxxxxxx> wrote: > 2014/1/2 Hauke Mehrtens <hauke@xxxxxxxxxx>: >> From: Cody P Schafer <devel@xxxxxxxxxx> >> >> Add a few Belkin F7Dxxxx entries, with F7D4401 sourced from online >> documentation and the "F7D7302" being observed. F7D3301, F7D3302, and >> F7D4302 are reasonable guesses which are unlikely to cause >> mis-detection. >> >> It also appears that at least the F7D3302, F7D3301, F7D7301, and F7D7302 >> have a shared boardtype and boardrev, so use that as a fallback to a >> "generic" F7Dxxxx board. > > Cody, Hauke: I'm starring at this patch for 10 minutes now and it's > still unclear for me. > > You say 3301, 3302, 7301 and 7302 have the same board_* entries > stating they can be treated with a generic ID entry. I included the generic BCM47XX_BOARD_BELKIN_F7DXXXX entry to catch those boards that we don't yet have specific entries for. It allows us to get the leds and buttons working mostly correctly. The specific names are included so that one can determine a more exact board. The stock CFE requires different images for different boards even though they are very similar. Hardware variations are simply gigabit vs 100MB switches, usb port population, led population, and 5Ghz radio population (none of which truly require the greater detail in board type). > At the same time > you define BELKIN_F7D3301 and BELKIN_F7D3302... so they are not > identical after all? [rehash of above] They have the same boardtype & boardrev, but (unfortunately) have different image requirements from the stock CFE. > Finally what about 4302? I can see it's untested, > but for some reason you assign it to the separated enum entry. Is this > not going to share config with the generic ones? Sorry, I've had this patch go though a couple revisions (adding more boards), and not all of them made it into the patch description. (4302 is just another variation on the generic f7dxxxx board). > Sorry, but it looks really messy to me. We can thank Belkin for that (see CFE issues mentioned above that cause us to want these more specific BCM47XX_BOARD_* macros). As an alternate to exposing the specific board names via this interface, we (openwrt) could use the nvram userspace tool to look for the specific type (the kernel really only needs the generic one, unless we want to give a more accurate picture of which LEDs are populated). Hauke - thoughts?
