Page MenuHomeFreeBSD

[BHND] Change default implementation of bhnd_bus_get_chipid from NULL to GENERIC
AbandonedPublic

Authored by mizhka on Jun 17 2016, 12:56 PM.
Tags
None
Referenced Files
Unknown Object (File)
Feb 18 2024, 4:11 AM
Unknown Object (File)
Aug 6 2023, 10:05 AM
Unknown Object (File)
Jun 21 2023, 6:35 AM
Unknown Object (File)
Apr 9 2023, 6:15 AM
Unknown Object (File)
Mar 23 2023, 6:40 AM
Unknown Object (File)
Jan 18 2023, 10:46 AM
Unknown Object (File)
Jan 10 2023, 10:06 AM
Unknown Object (File)
Nov 28 2022, 2:00 PM
Subscribers

Details

Reviewers
landonf
adrian
Summary

This patch changes default implementation of GET_CHIPID from NULL to GENERIC. The purpose of it is to allow sub-sub-drivers to get chip ID.

Reason: There are ethernet switches integrated into MIPS SoC. These switches doesn't provide idents (i.e. has id eq to 0). From device tree perspective they are located under BHND bus > ethernet driver > intermediate bus (SPI or MDIO).

Proposed solution: allow hierarchical call of GET_CHIPID to retrieve SoC ID, so switches can be identified by SoC.

Diff Detail

Repository
rS FreeBSD src repository - subversion
Lint
Lint Skipped
Unit
Tests Skipped

Event Timeline

mizhka retitled this revision from to [BHND] Change default implementation of bhnd_bus_get_chipid from NULL to GENERIC.
mizhka updated this object.
mizhka edited the test plan for this revision. (Show Details)
mizhka added reviewers: landonf, adrian.
mizhka set the repository for this revision to rS FreeBSD src repository - subversion.

I believe the the switch type can be determined via the NVRAM boardflags:

  • BFL_ENETADM (ADMtek switch)
  • BFL_ENETSPI (SPI roboswitch)
  • BFL_ENETVLAN (VLAN support for either)

I'd like the bhnd-attached drivers to identify the child device configuration locally, and then provide that in a generic form to their children, so that we can limit the CHIPID switch statements and NVRAM variable dependencies to a few central places that use the declarative device tables, and avoid hard dependencies on bhnd(4) API in (potentially non-bhnd-specific) devices attached to the device tree well below the bhnd(4) cores.

I believe the the switch type can be determined via the NVRAM boardflags:

  • BFL_ENETADM (ADMtek switch)
  • BFL_ENETSPI (SPI roboswitch)
  • BFL_ENETVLAN (VLAN support for either)

I'd like the bhnd-attached drivers to identify the child device configuration locally, and then provide that in a generic form to their children, so that we can limit the CHIPID switch statements and NVRAM variable dependencies to a few central places that use the declarative device tables, and avoid hard dependencies on bhnd(4) API in (potentially non-bhnd-specific) devices attached to the device tree well below the bhnd(4) cores.

Yes, it allow to identify bus of etherswitch, but not model.

We need to know Chip ID because different chips has different register layout. For instance, BCM5325 and BCM5358 are very-very close, but has crucial difference in one bit -"VLAN Valid" flag: for BCM5325 it's bit(6), for BCM5358 it's bit(7). (BCM5325 can be external/integrated, BCM5358 is integrated). As result, BCM5325 code fails on BCM5358 and vice versa.

To be honest, there are many families of BroadCom ethernet switches, B53xx is subclass, mostly used in home routers.
As possible solution, we can put ChipId in independent place (i.e. not-BHND-specific), for instance, kernel environment variable.

In D6880#144503, @mizhka_gmail.com wrote:

I believe the the switch type can be determined via the NVRAM boardflags:

  • BFL_ENETADM (ADMtek switch)
  • BFL_ENETSPI (SPI roboswitch)
  • BFL_ENETVLAN (VLAN support for either)

I'd like the bhnd-attached drivers to identify the child device configuration locally, and then provide that in a generic form to their children, so that we can limit the CHIPID switch statements and NVRAM variable dependencies to a few central places that use the declarative device tables, and avoid hard dependencies on bhnd(4) API in (potentially non-bhnd-specific) devices attached to the device tree well below the bhnd(4) cores.

Yes, it allow to identify bus of etherswitch, but not model.

From what I remember of the ISC-licensed Broadcom code, there may some quirks to reading the etherswitch device ID, but it /should/ be readable.

We need to know Chip ID because different chips has different register layout. For instance, BCM5325 and BCM5358 are very-very close, but has crucial difference in one bit -"VLAN Valid" flag: for BCM5325 it's bit(6), for BCM5358 it's bit(7). (BCM5325 can be external/integrated, BCM5358 is integrated). As result, BCM5325 code fails on BCM5358 and vice versa.

To be honest, there are many families of BroadCom ethernet switches, B53xx is subclass, mostly used in home routers.
As possible solution, we can put ChipId in independent place (i.e. not-BHND-specific), for instance, kernel environment variable.

Rather than a global variable (i.e. kenv), my recommendation would to be pass down what you need from the ethernet driver itself; that way the interface between ethernet and switch driver can be independent of the bhnd bus, and we're not creating dependencies on global state populated by bhnd.

In D6880#144503, @mizhka_gmail.com wrote:

I believe the the switch type can be determined via the NVRAM boardflags:

  • BFL_ENETADM (ADMtek switch)
  • BFL_ENETSPI (SPI roboswitch)
  • BFL_ENETVLAN (VLAN support for either)

I'd like the bhnd-attached drivers to identify the child device configuration locally, and then provide that in a generic form to their children, so that we can limit the CHIPID switch statements and NVRAM variable dependencies to a few central places that use the declarative device tables, and avoid hard dependencies on bhnd(4) API in (potentially non-bhnd-specific) devices attached to the device tree well below the bhnd(4) cores.

Yes, it allow to identify bus of etherswitch, but not model.

From what I remember of the ISC-licensed Broadcom code, there may some quirks to reading the etherswitch device ID, but it /should/ be readable.

We need to know Chip ID because different chips has different register layout. For instance, BCM5325 and BCM5358 are very-very close, but has crucial difference in one bit -"VLAN Valid" flag: for BCM5325 it's bit(6), for BCM5358 it's bit(7). (BCM5325 can be external/integrated, BCM5358 is integrated). As result, BCM5325 code fails on BCM5358 and vice versa.

To be honest, there are many families of BroadCom ethernet switches, B53xx is subclass, mostly used in home routers.
As possible solution, we can put ChipId in independent place (i.e. not-BHND-specific), for instance, kernel environment variable.

Rather than a global variable (i.e. kenv), my recommendation would to be pass down what you need from the ethernet driver itself; that way the interface between ethernet and switch driver can be independent of the bhnd bus, and we're not creating dependencies on global state populated by bhnd.

Mm... in this case switch driver will depend on bgmac core what is part of BHND and depends on BHND. It will result in double-dependency: bgmac & bhnd.

Abandon this revision. need to find more flexible way