Page MenuHomeFreeBSD

run(4): Add a new USB device ID.
ClosedPublic

Authored by scottph on Jul 10 2018, 11:06 PM.
Tags
None
Referenced Files
Unknown Object (File)
Feb 20 2024, 2:27 AM
Unknown Object (File)
Nov 11 2023, 10:22 AM
Unknown Object (File)
Nov 6 2023, 3:49 PM
Unknown Object (File)
Oct 5 2023, 2:47 PM
Unknown Object (File)
Aug 26 2023, 8:25 AM
Unknown Object (File)
Jun 14 2023, 12:36 PM
Unknown Object (File)
Apr 2 2023, 12:34 AM
Unknown Object (File)
Apr 2 2023, 12:34 AM

Details

Summary

Add the device id of the Panda Wireless PAU06 which seems to be
the already-supported combination of RT5392 MAC and RF RT5372
radio.

Diff Detail

Lint
Lint Passed
Unit
No Test Coverage
Build Status
Buildable 17957
Build 17712: arc lint + arc unit

Event Timeline

allanjude added a subscriber: allanjude.

Don't forget you still need your Mentor's approval

This revision is now accepted and ready to land.Jul 11 2018, 1:18 AM

(I'm assuming its been tested by at least one person)

jhb added a subscriber: jhb.

You can put 'Approved by: jhb' and I'll take any fallout. Ed is on vacation this week AFAIK.

The summary says PAU06 is the combination of two already-supported chips: RT5372 radio and RT5392 MAC. But nothing in the diff mentions the latter chip.

Maybe that's fine and reasonable; I know ~nothing about the USB stack, the WiFi stack, or the intersection thereof. At the very least, the summary is confusing.

Don't forget to bump .Dd when you commit btw

(I'm assuming its been tested by at least one person)

Tested-by: D Scott Phillips <d.scott.phillips@intel.com>

(I happened to have one of these, it's working great with the id added).

The summary says PAU06 is the combination of two already-supported chips: RT5372 radio and RT5392 MAC. But nothing in the diff mentions the latter chip.

The driver finds the mac version by reading it from the chip. There's actually no necessary connection between the usb device id and the radio chip id, the numbers just happened to coincide here.

Maybe that's fine and reasonable; I know ~nothing about the USB stack, the WiFi stack, or the intersection thereof. At the very least, the summary is confusing.

Maybe adding that sentence above will clear it up?

... the numbers just happened to coincide here.

I'm not sure what you mean by that.

I guess what I'm asking is:

  1. The RT5372 radio is already supported by run(4), modulo having to add the look-up table entries?
  2. The RT5392 MAC is already supported by run(4)?
  3. The fact that the RT5372 in the PAU06 uses the RT5392 is determined at runtime, so nothing needs to be done to support the combination?

If those points are all correct, then please include something like this in the commit message:

  • The PAU06 contains a RT5372 (which just needs look-up table updates) connected to a RT5392 (which is already supported); nothing special is required to support the combination.

Or something along those lines. Thanks!

... the numbers just happened to coincide here.

I'm not sure what you mean by that.

I guess what I'm asking is:

  1. The RT5372 radio is already supported by run(4), modulo having to add the look-up table entries?

So the run_devs[] table that I'm updating here doesn't actually say that this device has a 5372 radio, but only that the usb device id 0x5372 should be matched with this driver. Later on the driver finds both the mac and radio by querying the device. 5372 radio and 5372 device id are separate "namespaces" here. Perhaps the comment is just unhelpful trivia and is better dropped?

This revision was automatically updated to reflect the committed changes.