On Thu, Jul 17, 2025 at 12:27:44PM -0400, Sean Anderson wrote:

On 7/17/25 12:21, Greg Kroah-Hartman wrote:

quoted

On Thu, Jul 17, 2025 at 12:04:15PM -0400, Sean Anderson wrote:

quoted

On 7/17/25 11:59, Greg Kroah-Hartman wrote:

quoted

On Thu, Jul 17, 2025 at 11:49:37AM -0400, Sean Anderson wrote:

quoted

On 7/16/25 01:09, Greg Kroah-Hartman wrote:

quoted

On Tue, Jul 15, 2025 at 08:01:07PM -0400, Sean Anderson wrote:

quoted

Support creating auxiliary devices with the id included as part of the
name. This allows for hexadecimal ids, which may be more appropriate for
auxiliary devices created as children of memory-mapped devices. If an
auxiliary device's id is set to AUXILIARY_DEVID_NONE, the name must
be of the form "name.id".

With this patch, dmesg logs from an auxiliary device might look something
like

[    4.781268] xilinx_axienet 80200000.ethernet: autodetected 64-bit DMA range
[   21.889563] xilinx_emac.mac xilinx_emac.mac.80200000 net4: renamed from eth0
[   32.296965] xilinx_emac.mac xilinx_emac.mac.80200000 net4: PHY [axienet-80200000:05] driver [RTL8211F Gigabit Ethernet] (irq=70)
[   32.313456] xilinx_emac.mac xilinx_emac.mac.80200000 net4: configuring for inband/sgmii link mode
[   65.095419] xilinx_emac.mac xilinx_emac.mac.80200000 net4: Link is Up - 1Gbps/Full - flow control rx/tx

this is especially useful when compared to what might happen if there is
an error before userspace has the chance to assign a name to the netdev:

[    4.947215] xilinx_emac.mac xilinx_emac.mac.1 (unnamed net_device) (uninitialized): incorrect link mode  for in-band status

Signed-off-by: Sean Anderson <sean.anderson@linux.dev>
---

Changes in v2:
- Add example log output to commit message

I rejected v1, why is this being sent again?

You asked for explanation, I provided it. I specifically pointed out why
I wanted to do things this way. But I got no response. So here in v2.

Again, I said, "do not do that, this is not how ids work in the driver
model", and you tried to show lots of reasons why you wanted to do it
this way despite me saying so.

So again, no, sorry, this isn't ok.  Don't attempt to encode information
in a device id like you are trying to do here, that's not what a device
id is for at all.  I need to go dig up my old patch that made all device
ids random numbers just to see what foolish assumptions busses and
userspace tools are making....

But it *is* how ids work in platform devices.

No one should ever use platform devices/bus as an excuse to do anything,
it's "wrong" in so many ways, but needs to be because of special
reasons.  No other bus should work like that, sorry.

quoted

And because my auxiliary
devices are created by a platform device, it is guaranteed that the
platform device id is unique and that it will also be unique for
auxiliary devices. So there is no assumption here about the uniqueness
of any given id.

Then perhaps use the faux device api instead?

There's *another* pseudo bus? OK the reason why is that faux was added
four months ago and there is nothing under Documentation for it. So I
had no idea it existed. I will have a look, but perhaps you should write
up some documentation about why someone might want to use a "faux" bus
over the auxiliary bus or MFD.

"faux" is for when platform devices were being abused because someone
just wanted a device in the device tree, and did not use any of the
platform device resources.

Yes, more documentation is always a good idea, someday...

thanks,

greg k-h