On 01/02/2014 11:03 PM, Cody P Schafer wrote: > 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? > If it is possible to detect the specific board I would go with that. At least when the led configuration is different we have to do different things for the different boards. In the current way it does not take a lot of memory to add a new board to the detect code just some bytes < 50 in init ram. I would remove the generic entry now and leave the others in, if someone has a different board we can add it. Hauke
