Hi, Hauke. > On 01/09/2012 08:14 PM, George Kashperko wrote: > > Hello, Hauke! > > > > Spotted a typo in drivers/ust/host/ssb-hcd.c > > #define SSB_OHCI_CORECTL_HOSTMODE (1 << 13) > > > > It should be 1 << 29 for SSB as SiliconBackplane control flags are at > high > > 16 bits of SSB_TMSHIGH > > In drivers/usb/host/ssb-hcd.c in OpenWrt brcm47xx it says: > #define SSB_HCD_TMSLOW_HOSTMODE (1 << 29) > > When searching for SSB_OHCI_CORECTL_HOSTMODE I found your patch > changing > it to (1 << 13). Did you get a little confusion or am I wrong? ;-) To keep things the same for both ssb and ssb/ai I've used control flags in unsigned short, just 16bits. Thus flags were 1:1 for axi; for ssb respective abstraction handlers' code behind device_(enable|reset) did << 16 So for mine ssb/ai patches 1 << 13 will be 1 << 13 + 16 For pure ssb it should be 1 << 29
> > > Also, for bcma-based EHCI to work correctly it requires OHCI to be > driven > > as well > > or USB1.1 devices won't work (researched and reported by Joel Crisp > > <joel.a.crisp at googlemail.com>) so it seems reasonable to have > > +kmod-usb-ohci in package/kernel/modules/usb.mk (might with > +kmod-usb2 as > > well). > EHCI just supports USB 2.0, in general for USB 1.1 support an other > interface like OHCI or UHCI is needed [0]. Yeah it would make sense to > add a dependency to kmod-usb2 for the OHCI or UHCI driver depending on > the platform, I will talk with the other developers about it as it does > not affect brcm47xx only, but all USB 2.0 controllers. Just looked through package/kernel/modules/usb.mk again. Think I'm wrong here as you already have +TARGET_brcm47xx:kmod-usb-brcm47xx in DEPENDS for both ohci and ehci. Actually it even wiser to keep it in this way rather than back-reference them from usb-brcm47xx as I thought initially. So please just forget it - its really fine as it is now. Overall there could be done few cleanups for the (ssb|bcma)-hcd.c, If you don't plan to do it yourself I could do a patch and send you for review in few days as soon as get some spare time and finish testings on 47XX SoCs I've got. > While I am writing you, I would like to apply > http://www.znau.edu.ua/temp/asus-rt-n16/2012-01-01T23-55/000-openwrt471 > 6-TARGET_brcm4716-prereq.patch > to OpenWrt trunk, are you fine with that? Sure thing, I'm not a Broadcom guy and don't stamp PROPRIETARY UNPUBLISHED here and there :P Btw I see good room for broadcom-diag gpio code cleanup. We could could modify half-assed generic gpio to be finally compliant with it completely moving out that #ifdefs into chipcommon/extif code and rm -f src/gpio.h > We also wrote a spec [1] of the gmac et driver, so someone (now Rafał) > is able to implement a clean room developed driver for the gmac core. Great ! Hopefully we will have fully functional GPL-compliant 4716 system soon. Have nice day, George _______________________________________________ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
