On 06/07/2012 10:05 PM, Arend van Spriel wrote: > On 06/06/2012 01:07 AM, Hauke Mehrtens wrote: >> Instead of checking if there is a PCIe core on the bus, better check if >> hosttype is PCIe. > > I was under the impression that the macro was used for code needed when > the chip has a PCIe core instead of a PCI core. Maybe BCMA only supports > chips with PCIe core and in the respect checking the hosttype is > essentially the same, but I would not necessarily call it better. > The code from the initial submission to staging looked like this: #define PCIE(si) ((BUSTYPE((si)->pub.bustype) == PCI_BUS) && \ ((si)->pub.buscoretype == PCIE_CORE_ID)) I have never seen a device using the AI bus (bcma) and a PCI core and not a PCIe core and I do not think bcma will work with a PCI device or core. The bustype in your old code is the same as the hosttype in bcma, so under the assumption that all device are using PCIe that are coming to this code the code now does the same as in the initial submission to staging. buscore in brcmsmac contained a reference to a PCIe core on the bus, if there was any. On a SoC with a PCIe core in host mode this also contained this PCIe core, but it was not the buscore and the hosttype was not PCIE, nor the bustype when using your SDK would be PCI_BUS, but SI_BUS. So this patch is also more or less a bugfix for brcmsmac when you are not on a PCIe connected device, like a SoC. The old code also caused a null pointer in ai_get_buscoretype() and ai_get_buscorerev() if buscore was not set because there was no PCIe core on the bus. >> Signed-off-by: Hauke Mehrtens <hauke@xxxxxxxxxx> >> --- >> drivers/net/wireless/brcm80211/brcmsmac/aiutils.c | 9 ++++----- >> 1 file changed, 4 insertions(+), 5 deletions(-) >> > > Gr. AvS > -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
