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.

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
Lint
Lint Skipped
Unit
Unit Tests Skipped

Event Timeline

mizhka updated this revision to Diff 17658.Jun 17 2016, 12:56 PM
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.
landonf edited edge metadata.Jun 17 2016, 9:00 PM

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.

landonf added a comment.EditedJun 22 2016, 7:38 PM
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.

mizhka abandoned this revision.Nov 16 2016, 7:12 AM

Abandon this revision. need to find more flexible way