Re: OverDrive 1000 head -r360311 -> r363021 upgrade: USB & Ethernet disappeared, "usb_needs_explore_all: no devclass" (Now: artifact.ci bisect)

On 12.07.2020 8:37, Mark Millard via freebsd-arm wrote:
> 
> 
>> On 2020-Jul-11, at 15:12, Mark Millard <marklmi at yahoo.com> wrote:
>>
>>
>>>
>>> On 2020-Jul-11, at 14:45, Robert Crowston <crowston_at_protonmail.com> wrote:
>>>
>>> So what is the mistake I made here?
>>>
>>> Should I have given a globally unique name as the first argument to DRIVER_MODULE()? I didn't see that in the man page, and other examples of pcib drivers apparently get away with it.
>>>
>>> I did notice the weird message about "driver already loaded from kernel". I wondered if that meant I was dragging in code to the core kernel, that would otherwise live in an external module?
>>>
>>> Let me know how I can help fix it!
>>>
>>>   -- RHC.
>>
>> It is not an area of expertise for me. I've spent hours just
>> getting to the point of sending the notes that I have sent.
>>
> 
> Having found no evidence of any likely disaster from trying
> the experiment, I've tried:
> 
> # svnlite diff /usr/src/sys/arm/broadcom/bcm2835/bcm2838_pci.c
> Index: /usr/src/sys/arm/broadcom/bcm2835/bcm2838_pci.c
> ===================================================================
> --- /usr/src/sys/arm/broadcom/bcm2835/bcm2838_pci.c	(revision 363021)
> +++ /usr/src/sys/arm/broadcom/bcm2835/bcm2838_pci.c	(working copy)
> _at__at_ -739,5 +739,5 _at__at_
>      sizeof(struct bcm_pcib_softc), generic_pcie_fdt_driver);
>  
>  static devclass_t bcm_pcib_devclass;
> -DRIVER_MODULE(pcib, simplebus, bcm_pcib_driver, bcm_pcib_devclass, 0, 0);
> +DRIVER_MODULE(bcm_pcib, simplebus, bcm_pcib_driver, bcm_pcib_devclass, 0, 0);
>  
> 
> This was enough of a change for Ethernet and USB to become available
> again on the OverDrive 1000.
> 
> Apparently one must search all existing DRIVER_MODULE use and then
> pick naming to have the new DRIVER_MODULE(NAME,BUSNAME,... end up
> with the NAME,BUSNAME as a unique combination of names (or
> combinations for when there is BUSNAME0, BUSNAME1, . . .).
> 
> I also updated the USB3 SSD I use for booting either RPi4
> or Rock64. Be warned that the RPi4 boots are via
> UEFI v1.16 use instead of by sysutils/u-boot-rpi4 use.
> I do not have things set up for sysutils/u-boot-rpi4 as
> stands.
> 
> The SSD booted both contexts fine and the USB worked like
> normal. On the Rock64, the built-in EtherNet also worked
> fine. For the RPi4, a USB3 EtherNet adapter is used and
> it worked fine.
> 
> If someone checks sysutils/u-boot-rpi4 operation and finds
> that it works, then I expect that such a patch as above is
> all that is required.
> 
> Note: If future bcmDDDDD's need similar code, care will
> need to be taken naming ???? in DRIVER_MODULE(????,...
> for them so that uniqueness is maintained. My use of
> "bcm_" to match the context is not the only prefix that
> would lead to unique naming currently.
> 
> ===
> Mark Millard
> marklmi at yahoo.com
> ( dsl-only.net went
> away in early 2018-Mar)
> 

Fixed in r363121. Thanks for the report.

Michal Meloun