I'd think it's safe to remove the #ifdef FDTs from both of these bits and uniformly across FDT and non-FDT platforms create spigen cdevs with the new naming convention, rather than mixing it up.

It seems like it would be safe- we shouldn't have hinted children on a single spibus with the same cs, right?

ian suggested (in IRC channel) to make an alias device using the original naming scheme, as well as this naming scheme, and to use make_dev_s() and make_dev_alias_p() when doing it.

also 'cs' needs to be 'cs & (~SPIBUS_CS_HIGH)' [forgot to put that in]

initial test code works (using make_dev_s and make_dev_alias_p).

I noticed that the alias (symlink) device names are created as owned by root:wheel with 0755 permissions. I didn't really expect this, but I expect that as it's permissions on the symlink itself, and not on the device file name that it points to, that it doesn't matter?

So the net result looks like this:
lrwxr-xr-x 1 root wheel 9 May 10 01:45 /dev/spigen0 -> spigen0.0
crw-rw---- 1 root operator 0x2c May 10 01:45 /dev/spigen0.0
crw-rw---- 1 root operator 0x2e May 10 01:45 /dev/spigen0.1
crw-rw---- 1 root operator 0x30 May 10 01:45 /dev/spigen0.2
lrwxr-xr-x 1 root wheel 9 May 10 01:45 /dev/spigen1 -> spigen0.1
lrwxr-xr-x 1 root wheel 9 May 10 01:45 /dev/spigen2 -> spigen0.2

On a related note, this might cause confusion for those who think that 'spigen0' relates to spigen0.0 through spigen0.2 . So should I use a different name instead?

The sysctl vars are using spigen.0 spigen.1 and spigen.2 . So the name that would need to change is the one prefixing the "0.0" through "0.2" versions.

So for now I'll propose 'spig0.0' through 'spig0.2' to disambiguate them. These will be the devices that user mode is expected to make use of.

If it's preferred to make THESE the symlink aliases, we can do that, too.

Not necessarily better. Since spibus is the creator/owner of child device info, just using devi directly is fine.

I know it was me who said having the spigen= in the location (kinda like usb ugen does) would be nice, but this is indeed kinda hacky. Let's leave it out for now and just use bus=%d cs=%d in all cases, since that really does provide all the info you need to find the right spigen device anyway.

There is general agreement that the 'spigenN' naming scheme is inadequate, but it's present in stable-11 which lessens our freedom to just change it.

My current thinking is that we should use the spigen<BUS>.<CS> scheme always, and we should define a new kernel option, SPIGEN_LEGACY_CDEVNAME that causes us to create spigen# aliases sequentially numbered from 0-n like the old scheme used to. Then in stable-11 we find the few existing kernel configs that reference spigen and add that option, to avoid breaking users relying on it, when we MFC these changes. In 12-current we have more freedom to make changes, so we don't add that option to kernel configs, but users can enable it if needed.

This needs to be done by setting mda_si_drv1 = dev; before calling make_dev_s(). Much of the reason for make_dev_s() and the mda stuct is to avoid the race of making a cdev appear in /dev before the cdev struct is completely filled out and ready to use in the driver.

I will take the '!strcmp(devclass "spigen")' compare out and just use what's in the 'else' clause. simpler too.

will place #ifdef SPIGEN_LEGACY_CDEVNAME around the next section that creates the alias, and also in the unload part (and variable declaration in the struct)

also move these 3 lines to before setting up the cdev, on the same theory... don't make /dev/spigenX.Y visiable in devfs until everything is set up and ready to start servicing requests in the driver.