Change Details

Rather than assigning spigen device names in order of creation, use a device name that corresponds to the owning spibus and cs register. Example: spigen0.1 would be a child of spibus0, and use cs = 1 This recommended patch uses the existing 'spigenN' naming convention when FDT is not enabled. Otherwise, it grabs the spibus unit number, and 'cs' value from the ivars, and then creates an appropriate name from those two values (in lieu of using 'unit') when attaching the device.

Rather than assigning spigen device names in order of creation, use a device name that corresponds to the owning spibus and cs register. Example: spigen0.1 would be a child of spibus0, and use cs = 1 This recommended patch uses the existing 'spigenN' naming convention when FDT is not enabled. Otherwise, it grabs the spibus unit number, and 'cs' value from the ivars, and then creates an appropriate name from those two values (in lieu of using 'unit') when attaching the device. The intent is for systems like Raspberry Pi to have a consistent way of using an SPI interface with a specific cs value from a user application. Otherwise, there is no consistent way of knowing which cs pin will be assigned to a particular spigen device. The alternative is to specify everything in "the right order" in an overlay file, which is less than ideal. Additionally, this duplicates (to some extent) the way Linux handles a similar situation with their 'spidev' device, so it would be somewhat familiar to those who also use Linux.

Rather than assigning spigen device names in order of creation, use a device name that corresponds to the owning spibus and cs register. Example: spigen0.1 would be a child of spibus0, and use cs = 1 This recommended patch uses the existing 'spigenN' naming convention when FDT is not enabled. Otherwise, it grabs the spibus unit number, and 'cs' value from the ivars, and then creates an appropriate name from those two values (in lieu of using 'unit') when attaching the device. The intent is for systems like Raspberry Pi to have a consistent way of using an SPI interface with a specific cs value from a user application. Otherwise, there is no consistent way of knowing which cs pin will be assigned to a particular spigen device. The alternative is to specify everything in "the right order" in an overlay file, which is less than ideal. Additionally, this duplicates (to some extent) the way Linux handles a similar situation with their 'spidev' device, so it would be somewhat familiar to those who also use Linux.