> On 2020-Jul-11, at 15:12, Mark Millard <marklmi at yahoo.com> wrote:
> 
> 
>> 
>> On 2020-Jul-11, at 14:45, Robert Crowston <crows...@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)
@@ -739,5 +739,5 @@
     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)

_______________________________________________
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Reply via email to