mirror of
https://github.com/edk2-porting/linux-next.git
synced 2024-12-27 22:53:55 +08:00
0ab5fe5374
The various FSI devices (sbefifo, occ, scom, more to come) currently use misc devices. This is problematic as the minor device space for misc is limited and there can be a lot of them. Also it limits our ability to move them to a dedicated /dev/fsi directory or to be smart about device naming and numbering. It also means we have IDAs on every single of these drivers This creates a common fsi "device_type" for the optional /dev/fsi grouping and a dev_t allocator for all FSI devices. "Legacy" devices get to use a backward compatible numbering scheme (as long as chip id <16 and there's only one copy of a given unit type per chip). A single major number and a single IDA are shared for all FSI devices. This doesn't convert the FSI device drivers to use the new scheme yet, they will be converted individually. Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
68 lines
2.0 KiB
Plaintext
68 lines
2.0 KiB
Plaintext
#
|
|
# FSI subsystem
|
|
#
|
|
|
|
menuconfig FSI
|
|
tristate "FSI support"
|
|
depends on OF
|
|
select CRC4
|
|
---help---
|
|
FSI - the FRU Support Interface - is a simple bus for low-level
|
|
access to POWER-based hardware.
|
|
|
|
if FSI
|
|
|
|
config FSI_NEW_DEV_NODE
|
|
bool "Create '/dev/fsi' directory for char devices"
|
|
default n
|
|
---help---
|
|
This option causes char devices created for FSI devices to be
|
|
located under a common /dev/fsi/ directory. Set to N unless your
|
|
userspace has been updated to handle the new location.
|
|
|
|
Additionally, it also causes the char device names to be offset
|
|
by one so that chip 0 will have /dev/scom1 and chip1 /dev/scom2
|
|
to match old userspace expectations.
|
|
|
|
New userspace will use udev rules to generate predictable access
|
|
symlinks in /dev/fsi/by-path when this option is enabled.
|
|
|
|
config FSI_MASTER_GPIO
|
|
tristate "GPIO-based FSI master"
|
|
depends on GPIOLIB
|
|
select CRC4
|
|
---help---
|
|
This option enables a FSI master driver using GPIO lines.
|
|
|
|
config FSI_MASTER_HUB
|
|
tristate "FSI hub master"
|
|
---help---
|
|
This option enables a FSI hub master driver. Hub is a type of FSI
|
|
master that is connected to the upstream master via a slave. Hubs
|
|
allow chaining of FSI links to an arbitrary depth. This allows for
|
|
a high target device fanout.
|
|
|
|
config FSI_MASTER_AST_CF
|
|
tristate "FSI master based on Aspeed ColdFire coprocessor"
|
|
depends on GPIOLIB
|
|
depends on GPIO_ASPEED
|
|
---help---
|
|
This option enables a FSI master using the AST2400 and AST2500 GPIO
|
|
lines driven by the internal ColdFire coprocessor. This requires
|
|
the corresponding machine specific ColdFire firmware to be available.
|
|
|
|
config FSI_SCOM
|
|
tristate "SCOM FSI client device driver"
|
|
---help---
|
|
This option enables an FSI based SCOM device driver.
|
|
|
|
config FSI_SBEFIFO
|
|
tristate "SBEFIFO FSI client device driver"
|
|
depends on OF_ADDRESS
|
|
---help---
|
|
This option enables an FSI based SBEFIFO device driver. The SBEFIFO is
|
|
a pipe-like FSI device for communicating with the self boot engine
|
|
(SBE) on POWER processors.
|
|
|
|
endif
|