[opensuse-kernel] Help with driver configs - DT/OF
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi folks - I just did the update to 4.0-rc1 and am in something of a cleanup mode. There are a number of drivers that are only loaded when enumerated via device tree/open firmware. On x86_64, there isn't any hardware we support that uses DT/OF, so we can skip building them entirely. On i386, we support the OLPC XO-1, so we need to determine which drivers that hardware requires. It gets cloudy when it comes to ppc/ppc64/ppc64le. The following is a quick review of drivers that we are building that are only enumerated using device tree/open firmware. Drivers that are only being built on ARM already are not included. The gist is that there are 46 drivers that are built with only DT/OF support across all non-ARM architectures. Of those, 17 are being built because the driver doesn't report CONFIG_OF as a dependency. 24 of them are being built on i386 or x86_64, where the devices will never be discovered. Before I go and commit these changes, I'd like to ask for some quick review to see if I've overlooked anything or have some false positives. As it is, I'm sure there is hardware that is only on ARM but is being built for ppc. The process used was to expand every non-ARM kernel RPM from Kernel:HEAD and run depmod on each one. Every driver that loads with OF/DT will have an alias that starts with of:. Every driver that can also load after being enumerated by another mechanism (typically either ACPI or I2C) is filtered out. airport - APPLE_AIRPORT - enabled on ppc, ppc64, ppc64le - macio: ppc64le can be disabled altera_tse - ALTERA_TSE - buggy, should require OF - enabled on armv7hl, i386, ppc, ppc64, ppc64le, s390x, x86_64 - i386, s390x, x86_64 can be disabled - ppc, ppc64, ppc64le should probably be disabled apbps2 - Documentation/devicetree/bindings/input/ps2keyb-mouse-apbps2.txt - SERIO_APBPS2 - enabled on arm64, armv6hl, armv7hl, i386, ppc, ppc64, ppc64le - typical environment is on a LEON SPARC system - i386 can be disabled - arm64, armv6hl, armv7hl, ppc, ppc64, ppc64le should probably be disabled bh1780gli - SENSORS_BH1780 - enabled on arm64, armv6hl, armv7hl, i386, ppc, ppc64, ppc64le, x86_64 - buggy? has an i2c device table but it's not exported bmac - BMAC - enabled on ppc - ok docg3 - MTD_DOCG3 - buggy, should depend on OF - enabled on i386, ppc64, ppc64le, x86_64 - i386, x86_64 can be disabled - ppc64, ppc64le should probably be disabled dw_wdt - DW_WATCHDOG - buggy, should depend on OF - enabled on armv6hl, armv7hl, i386, ppc, ppc64, ppc64le, x86_64 - i386, x86_64, ppc, ppc64, ppc64le can be disabled - Used to be documented as ARM-only until commit 58a251f2c25 updated it to be generic after it became used on Xtensa. ethoc - ETHOC - buggy, should depend on OF - enabled on arm64, armv6hl, armv7hl, i386, ppc, ppc64, ppc64le, x86_64 - i386, x86_64 can be disabled - can probably be disabled everywhere fec_mpc52xx - FEC_MPC52xx - enabled on ppc - ok fec_mpc52xx_phy - FEC_MPC52xx - enabled on ppc - ok fsl_lpuart - SERIAL_FSL_LPUART - buggy, should depend on OF - enabled on armv6hl, armv7hl, i386, ppc, ppc64, ppc64le, x86_64 - can be disabled on i386, x86_64 - unsure if it can be disabled on ppc, ppc64, ppc64le gpio_74xx_mmio - GPIO_74XX_MMIO - enabled on arm64, i386, ppc, ppc64, ppc64le - can be disbled on i386 gpio_beeper - INPUT_GPIO_BEEPER - buggy, should depend on OF - enabled on i386, ppc, ppc64, ppc64le, x86_64 - can be disabled on i386, x86_64 - can probably be disabled everywhere gpio_grgpio - GPIO_GRGPIO - Documentation/devicetree/bindings/gpio/gpio-grgpio.txt - typical environment is on a LEON SPARC system - enabled on arm64, armv6hl, armv7hl, i386, ppc, ppc64, ppc64le - can be disabled on i386, ppc, ppc64, ppc64le - can probably be disabled everywhere gpio_ir_recv - IR_GPIO_CIR - buggy, should depend on OF - enabled on arm64, armv6hl, armv7hl, i386, ppc, ppc64, ppc64le, x86_64 - can be disabled on i386, x86_64 gpio_syscon - GPIO_SYSCON - buggy, should depend on OF - enabled on arm64, armv6hl, armv7hl, i386, ppc, ppc64, ppc64le - can be disabled on i386, x86_64 gpio_wdt - GPIO_WATCHDOG - enabled on armv6hl, armv7hl, i386, ppc, ppc64, ppc64le - can be disabled on i386 i2c_mpc - I2C_MPC - should probably depend on PPC32 - enabled on ppc, ppc64, ppc64le - can be disabled on ppc64, ppc64 i2c_opal - I2C_OPAL - enabled on ppc64, ppc64le - ok ibm_emac - IBM_EMAC - enabled on ppc64,ppc64le - ok ipmi_powernv - IPMI_POWERNV - enabled on ppc64, ppc64le - ok ks8851_mll - KS8851_MLL - buggy, should depend on OF - enabled on arm64, armv7hl, armv6hl, i386, ppc, ppc64, ppc64le, x86_64 - can be disabled on i386, x86_64 - should probably be disabled on ppc, ppc64, ppc64le ll_temac - XILINX_LL_TEMAC - enabled on ppc, ppc64, ppc64le - ok mac53c94 - SCSI_MAC53C94 - enabled on ppc - ok mace - MACE - enabled on ppc - ok mdio_mux_gpio - MDIO_BUS_MUX_GPIO - enabled on arm64, armv6hl, armv7hl, i386, ppc, ppc64, ppc64le - can be disabled on i386 mdio_mux_mmioreg - MDIO_BUS_MUX_GPIO - enabled on arm64, armv6hl, armv7hl, i386, ppc, ppc64, ppc64le - can be disabled on i386 mesh - SCSI_MESH - enabled on ppc - ok ocfb - FB_OPENCORES - buggy, should depend on OF - enabled on i386, ppc, ppc64, ppc64le, x86_64 - can be disabled on i386, x86_64 - can probably be disabled everywhere olpc_apsp - ok olpc_battery - ok pata_mpc52xx - PATA_MPC52xx - enabled on ppc - ok physmap_of - MTD_PHYSMAP_OF - enabled on arm64, armv6hl, armv7h, i386 - not sure if required by olpc flash pps_gpio - PPS_CLIENT_GPIO - buggy, should depend on OF - enabled on i386, ppc, ppc64, ppc64le, x86_64 - can be disabled on i386, x86_64 rtc_snvs - RTC_DRV_SNVS - enabled on arm64, armv6hl, armv7hl, ppc, ppc64, ppc64le - can be disabled on i386 sdhci_of_arasan - MMC_SDHCI_OF_ARASAN - enabled on arm64, armv6hl, armv7hl, i386 - can be disabled on i386 - can possibly be disabled on arm64 snd_aoa_i2sbus - SND_AOA_SOUNDBUS_I2S - enabled on ppc, ppc64, ppc64le - ok st_drv - TI_ST - buggy, should depend on OF - enabled on arm64, armv7hl, armv6hl, i386, ppc, ppc64, ppc64le, x86_64 - can be disabled on i386, x86_64 - can probably be disabled on ppc, ppc64, ppc64le stmmac_platform - STMMAC_PLATFORM - buggy, should depend on OF - enabled on armv7hl, i386, ppc, ppc64, ppc64le, x86_64 - can be disabled on i386, ppc, ppc64, ppc64le, x86_64 ti_am335x_tscadc - MFD_TI_AM335X_TSCADC - buggy, should depend on OF - enabled on arm64, armv6hl, armv7hl, i386, ppc, ppc64, ppc64le, x86_64 - can be disabled on i386, ppc, ppc64, ppc64le, x86_64 timeriomem_rng - HW_RANDOM_TIMERIOMEM - buggy, should depend on OF - enabled on arm64, armv6hl, armv7hl, ppc - can probably be disabled on ppc virtio_mmio - buggy, should depend on OF - enabled on arm64, armv7hl, i386, ppc, ppc64, ppc64le, x86_64 - can be disabled on i386, x86_64 w1_gpio - W1_MASTER_GPIO - buggy, should depend on OF - enabled on arm64, armv6hl, armv7hl, i386, ppc,ppc64, ppc64le, x86_64 - can be disabled on i386, x86_64 xilinx_emaclite - XILINX_EMACLITE - enabled on armv7hl, ppc - ok xilinx_ps2 - SERIO_XILINX_XPS_PS2 - enabled on ppc, ppc64, ppc64le - ok xilinx_uartps - SERIAL_XILINX_PS_UART - enabled on armv6hl, armv6hl, ppc, ppc64, ppc64le, i386 - can be disabled on i386 Thanks for taking a look. - -Jeff - -- Jeff Mahoney SUSE Labs -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) iQIcBAEBAgAGBQJU9hw4AAoJEB57S2MheeWyO+8P/1rjY36ITRP9UxaAQab6f9Zh k0U4i2IJF1Qz8lMoG7sSDh522M7T+ayZmAFawA0JOyPNXlQqOgyX6lscKgj5Ru1T juOewRCDxXL0FIR2j9j2r839TeKSisylcosp6Kv/T/cDufgMYxOjdvesiraZi9l0 Dcc8etCeDJW87a+inw9ro/NZh6swcI6y8XwZ/v5YPk3NVujy9GD6m8TKFFPyUAfb 5+RdufGHqFXYQ6dR/BcBv1DgTzFgE/Yw/yQl7rhTVN4I6wmafD/IvMNfxvadwC/i kDliPDLgDtcyWzAZHm6OcBDdw6s7Sz15j3eNKmlDG5BW2YQWSh8SOmJRX/HE/XFB ZZl9lUyjaTuO+v7zSJTlvkadNVz9mvyxIEdhoeBGhmr2JIipObVgoZKzM1ghMw/f 9nOIx7bZFd169Niz5b5uyQVlPV1Z8uHKsXVlDVWfoItV03FRHeuPGCpdGjwaYEYN umFrNJSK7c1A6SODE0v0HUj8emxFa2qjNwedwjjxOUIDdyObQU5BFhr8e0yQsezC Vh7+hDp4FBt+MMwwN5jURRR3YDQtxOM7I36bil5aFw6UrrXV/pCcw3reUID9vD30 euDyC6E+4eMSd9nVEqbb/vwUh+WGtLyMSgZ5EYbKDq/ABxoP+bQ86lf7USIeH8sb VwRBi/6HrmcldB3/ZW5M =tn7K -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
At Tue, 03 Mar 2015 15:40:24 -0500, Jeff Mahoney wrote:
snd_aoa_i2sbus - SND_AOA_SOUNDBUS_I2S - enabled on ppc, ppc64, ppc64le
It's for the old powermacs, so it unlikely supports LE. But if we want to torture ppc64le builds, we can keep the config... Takashi -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 3/4/15 3:10 AM, Takashi Iwai wrote:
At Tue, 03 Mar 2015 15:40:24 -0500, Jeff Mahoney wrote:
snd_aoa_i2sbus - SND_AOA_SOUNDBUS_I2S - enabled on ppc, ppc64, ppc64le
It's for the old powermacs, so it unlikely supports LE. But if we want to torture ppc64le builds, we can keep the config...
Thanks, Takashi. I've added it to my list. I think there are enough other drivers still enabled that we have pretty good build coverage. - -Jeff - -- Jeff Mahoney SUSE Labs -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) iQIcBAEBAgAGBQJU9v19AAoJEB57S2MheeWyn7AQAKsziAZgCYzgl/VlF74eLWxw NfBr0ATR2Cy2XZLDndosC1MJ0iLl/8hwPpYBWD/NAb71SyZmiqYBh7Lve2ctyq92 7fzgryzjEt3PZRPHiOWEE07puLGd+7YSm60sfTkU6QAYcrB3NZgwgxpxjP1o3pth Fr8e5k5N/UocXPNDP11m+oN2i3/OzaLghiKw8DH9QEq1HSxTTH5F4r+fnLcNfG/c kEcTsWsztaoUPYISBDKBrvoHdD9ZzLmlwT6/v93MJK5/vlzEcsR1uSxaVxIt9cI+ bjNRM3O9FHzVFQHshKq3VQOUR0umrWecjh+KZsBhOuls0aIMLOUmVTwO55F+BDbo rRjhyorJkjGtXhB/nB8BEGkDHT2Uv8wKQ9XvgJDX5gTIqZQ9jnnNoUhI/S5kMxuh 1LLVIjTVzTbDiKhndQkH45jh1qTn8NW6Um8sW1iQ3h0v1NfBUVBXiTTcfxiSS2x+ nTmi/R4oaI7/RMyCf2njMkT4QTa+IQ5c0ESVHASIq0dTcxIoM/fu6ptwtUI7AZLc YcKpQokW/kfIRATes5TPax2OQ/UXWiNVl7E9kolnNA9rrsjw1jLL6sYqRzeNS7ZP WpHNPM8QhovB2xRsLRr/QiSvMhAGS+S24mUuixaQNMk615aV7ADY68E4ClGjdMqt R3CKzFkxHzECuZCIjSVu =BKa5 -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
Hi, Am 03.03.2015 um 21:40 schrieb Jeff Mahoney:
apbps2 - Documentation/devicetree/bindings/input/ps2keyb-mouse-apbps2.txt - SERIO_APBPS2 - enabled on arm64, armv6hl, armv7hl, i386, ppc, ppc64, ppc64le - typical environment is on a LEON SPARC system - i386 can be disabled - arm64, armv6hl, armv7hl, ppc, ppc64, ppc64le should probably be disabled
Don't know of an ARM platform that needs it; on the other hand, AFAIU GRLib like DesignWare is just an IP library that could be used anywhere, including FPGAs (zynq, socfpga, etc.).
bh1780gli - SENSORS_BH1780 - enabled on arm64, armv6hl, armv7hl, i386, ppc, ppc64, ppc64le, x86_64 - buggy? has an i2c device table but it's not exported
For armv6hl (i.e., Raspberry Pi) I went through and enabled all I2C and SPI sensors just recently. I obviously did not check them for presence of the module table macro line - can you or Jean send a patch to add that?
fec_mpc52xx - FEC_MPC52xx - enabled on ppc - ok fec_mpc52xx_phy - FEC_MPC52xx - enabled on ppc - ok
Alex, do we really run on mpc52xx?
fsl_lpuart - SERIAL_FSL_LPUART - buggy, should depend on OF - enabled on armv6hl, armv7hl, i386, ppc, ppc64, ppc64le, x86_64 - can be disabled on i386, x86_64 - unsure if it can be disabled on ppc, ppc64, ppc64le
fsl is for Freescale, so can be disabled for our ppc* builds. cc Alex
gpio_74xx_mmio - GPIO_74XX_MMIO - enabled on arm64, i386, ppc, ppc64, ppc64le - can be disbled on i386
Was unsure about this one and thus didn't enable it for armv7/armv6. arm64 can probably be disabled, too.
ti_am335x_tscadc - MFD_TI_AM335X_TSCADC - buggy, should depend on OF - enabled on arm64, armv6hl, armv7hl, i386, ppc, ppc64, ppc64le, x86_64 - can be disabled on i386, ppc, ppc64, ppc64le, x86_64
I'm pretty sure I disabled that for armv6hl default config the weekend? It should be needed for armv7hl only, i.e. disable for arm64 please. Regards, Andreas -- SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Jane Smithard, Jennifer Guild, Dilip Upmanyu, Graham Norton; HRB 21284 (AG Nürnberg)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 3/4/15 10:30 AM, Andreas Färber wrote:
Hi,
Am 03.03.2015 um 21:40 schrieb Jeff Mahoney:
apbps2 - Documentation/devicetree/bindings/input/ps2keyb-mouse-apbps2.txt - SERIO_APBPS2 - enabled on arm64, armv6hl, armv7hl, i386, ppc, ppc64, ppc64le - typical environment is on a LEON SPARC system - i386 can be disabled - arm64, armv6hl, armv7hl, ppc, ppc64, ppc64le should probably be disabled
Don't know of an ARM platform that needs it; on the other hand, AFAIU GRLib like DesignWare is just an IP library that could be used anywhere, including FPGAs (zynq, socfpga, etc.).
Ok, I'll leave it enabled on ppc* (and didn't touch ARM anyway).
bh1780gli - SENSORS_BH1780 - enabled on arm64, armv6hl, armv7hl, i386, ppc, ppc64, ppc64le, x86_64 - buggy? has an i2c device table but it's not exported
For armv6hl (i.e., Raspberry Pi) I went through and enabled all I2C and SPI sensors just recently. I obviously did not check them for presence of the module table macro line - can you or Jean send a patch to add that?
Jean, since you're much more involved with i2c, could you take a look at this?
fec_mpc52xx - FEC_MPC52xx - enabled on ppc - ok fec_mpc52xx_phy - FEC_MPC52xx - enabled on ppc - ok
Alex, do we really run on mpc52xx?
IIRC, Olaf Hering used to run some of this hardware.
fsl_lpuart - SERIAL_FSL_LPUART - buggy, should depend on OF - enabled on armv6hl, armv7hl, i386, ppc, ppc64, ppc64le, x86_64 - can be disabled on i386, x86_64 - unsure if it can be disabled on ppc, ppc64, ppc64le
fsl is for Freescale, so can be disabled for our ppc* builds. cc Alex
Doesn't Freescale also make ppc hardware? Or is this only found on their ARM versions?
gpio_74xx_mmio - GPIO_74XX_MMIO - enabled on arm64, i386, ppc, ppc64, ppc64le - can be disbled on i386
Was unsure about this one and thus didn't enable it for armv7/armv6. arm64 can probably be disabled, too.
ti_am335x_tscadc - MFD_TI_AM335X_TSCADC - buggy, should depend on OF - enabled on arm64, armv6hl, armv7hl, i386, ppc, ppc64, ppc64le, x86_64 - can be disabled on i386, ppc, ppc64, ppc64le, x86_64
I'm pretty sure I disabled that for armv6hl default config the weekend? It should be needed for armv7hl only, i.e. disable for arm64 please.
The ARM configs haven't been updated for 4.0-rc1 yet, so I'd prefer to leave these one to you and the other ARM folks. - -Jeff - -- Jeff Mahoney SUSE Labs -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) iQIcBAEBAgAGBQJU+z2uAAoJEB57S2MheeWy14YP/iBj77+PpCu3zKIfMI5o2vXj fMhwTsrv/b3jf0hPCZPXyqYIveRpzwSX77KfD82hZwAhlC1SXfT3ohierwr1JNn7 xJVQ8VhHKBQC/5y4SavRbtWnmSE3ZxbfexQzFQecHzoIhQoglbN9jwXJ9slTvbMT zoZpfBcHHAZA12xkF1w+aprbwwirze8AraeVWm8tIoT7VRX/ILoRDNRtYtoLGSRE 7O5T5n2he+VnoKwKzYt1p2dn/tx/mROcf68IBaHhkP7o+Q5kUktK+loPQbgH51SA z3f/K6Bx2WTQev0KZBXvKak7xRJtac0W0xHCWcRiB4aJcxHAoz4Kb3n8cPNkGQTY HUroKkpuDe8YX0C2NnZdaU9NBwfDezEQKq2VgoJuVpGzu5pmAQgqQrFlde5NkWIM ztI0MbnKoPGIJ5K/56FnKQNueFct7nqArl3SY+7zb1GHZR4DHbr5k0pIrzQv7HyM 9inszUGgjl3KulyJlo4xDr4wi3M+fJnP/FvdP1zIXkzexh5ECMFR+v6HsqjMhjem UsjyEfhBlbPyrgMlIFHsmifCEstepj2ZNcZcCLrHKUGcBwqRCNdwYuNtWUWkgacQ Q008vilEMQCEibOfoJ9KPf6AunY1uSEqyZCrESEMnsmp6rOYJootQSqW1YRY/d9K SSjyPquGzNLvxFYC5uSl =cSpK -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
Hi Jeff, Andreas, On Sat, 07 Mar 2015 13:04:30 -0500, Jeff Mahoney wrote:
On 3/4/15 10:30 AM, Andreas Färber wrote:
Am 03.03.2015 um 21:40 schrieb Jeff Mahoney:
bh1780gli - SENSORS_BH1780 - enabled on arm64, armv6hl, armv7hl, i386, ppc, ppc64, ppc64le, x86_64 - buggy? has an i2c device table but it's not exported
For armv6hl (i.e., Raspberry Pi) I went through and enabled all I2C and SPI sensors just recently. I obviously did not check them for presence of the module table macro line - can you or Jean send a patch to add that?
Jean, since you're much more involved with i2c, could you take a look at this?
I've just sent a patch adding the missing MODULE_DEVICE_TABLE to the bh1780gli driver: http://marc.info/?l=linux-kernel&m=142580461109630&w=2 Note that DT/OF-based systems are not affected, and this does not prevent the driver from being used on the other systems either, all that is missing is module auto-loading. But I couldn't find any piece of kernel code instantiating this device anyway, so the only case where it would make a difference is if someone instantiates the device manually from user-space through sysfs. -- Jean Delvare SUSE L3 Support -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 3/8/15 5:01 AM, Jean Delvare wrote:
Hi Jeff, Andreas,
On Sat, 07 Mar 2015 13:04:30 -0500, Jeff Mahoney wrote:
On 3/4/15 10:30 AM, Andreas Färber wrote:
Am 03.03.2015 um 21:40 schrieb Jeff Mahoney:
bh1780gli - SENSORS_BH1780 - enabled on arm64, armv6hl, armv7hl, i386, ppc, ppc64, ppc64le, x86_64 - buggy? has an i2c device table but it's not exported
For armv6hl (i.e., Raspberry Pi) I went through and enabled all I2C and SPI sensors just recently. I obviously did not check them for presence of the module table macro line - can you or Jean send a patch to add that?
Jean, since you're much more involved with i2c, could you take a look at this?
I've just sent a patch adding the missing MODULE_DEVICE_TABLE to the bh1780gli driver: http://marc.info/?l=linux-kernel&m=142580461109630&w=2
Note that DT/OF-based systems are not affected, and this does not prevent the driver from being used on the other systems either, all that is missing is module auto-loading. But I couldn't find any piece of kernel code instantiating this device anyway, so the only case where it would make a difference is if someone instantiates the device manually from user-space through sysfs.
Huh. Ok. Shows how much I know about how the i2c subsystem works. Is it the case that there are probably a bunch of drivers like this that would never be loaded on e.g. x86 systems? - -Jeff - -- Jeff Mahoney SUSE Labs -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) iQIcBAEBAgAGBQJU/NY9AAoJEB57S2MheeWyCEwP/27F9fJFVDB1aLxwZCGim4rV KSrxHf1DQX/zSaySKuyP5XAxDq+QXzr97GscCe9wt5jYdhCStsv+Rhs2PVy2WJzl ff+c05E8NgOG490Jq8qdYooa6MRB31Giv3nKVD117knDNaWJTUeg6283VPekvfau O3KnEpySXpr9buUIUauQsqCca8xmoqXOg1+e/U+4kK6+fydPOUKRr+2jFmeMnDZO xTbyQVpcmXYHiB28Ki2Z0j+zb/mH37y0bSdTmECY/12tmLVTdBFukS2o+RaYxjHD 9UYZbbNbLtL6/vuhF/ofrG3QkvC4TTKaP4+VMxdJ+Inv/0oSAhJ+Z/u8nx0c2+fm w0CPLJh6q1jPWnlWJLeOF6IqDKn0YXXdGIBFJaBBZA61oBroSUHBiPD8QwJbmHSK fvHbAytODyzMykrImdDGpVQIS3HNeTbzD9nsb08UuJmL8ppfqgk81RJ2ynzZXd5s bUS3T/fEl1v8LrPcTUFQTujm3+tgEICKnYpuZHNdETb7R/jS9wP5uPMVoe9Rq5Hi xldSutC04e1SRJhtPdPk5xCb+dx7/TONyhX1XBGTpKqCJRnXUFUfBqeytE6PQNRI M+0drWZ4LQNgmIZgJtIunsH+lR/qct5ieIy0pJUvD8Vf8HUTPL0nvucjyLPEgC+7 IxnLkSoC1X+b7V3OgkdG =EgOJ -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
Hi Jeff, Le Sunday 08 March 2015 à 19:07 -0400, Jeff Mahoney a écrit :
On 3/8/15 5:01 AM, Jean Delvare wrote:
I've just sent a patch adding the missing MODULE_DEVICE_TABLE to the bh1780gli driver: http://marc.info/?l=linux-kernel&m=142580461109630&w=2
Note that DT/OF-based systems are not affected, and this does not prevent the driver from being used on the other systems either, all that is missing is module auto-loading. But I couldn't find any piece of kernel code instantiating this device anyway, so the only case where it would make a difference is if someone instantiates the device manually from user-space through sysfs.
Huh. Ok. Shows how much I know about how the i2c subsystem works. Is it the case that there are probably a bunch of drivers like this that would never be loaded on e.g. x86 systems?
It's very hard to say. Some I2C device drivers (most notably in drivers/hwmon) implement a detect callback which allows the driver to probe for devices and instantiate these by itself. Such drivers can be used on any system even if you don't see any piece of kernel code instantiating the device explicitly. Also note that instantiating i2c devices through sysfs is a totally legitimate way to operate. While use cases include device emulation and driver development, it is also possible to use this mechanism to declare devices on real systems. This could even replace the in-kernel self-probing at some point in time. So I think we have 3 options when it comes to deciding which I2C device drivers should be enabled in our kernels: 1* Enable every new driver everywhere (except specialized kernel flavors), just in case. Very easy, but a waste of build time, update time and disk space. 2* Disable every new driver everywhere by default and wait for users to ask for the drivers they actually need. We'd get cleaner and smaller kernels, but this probably requires more human interactions than we can afford, and user experience would degrade. 3* Try to guess which drivers may be needed on each platform based on the device nature. For example we know that x86 systems typically don't use I2C RTC chips. The problem is that borders are getting blurred between architectures with regards to target systems and intended uses, so I'm afraid that in the end we can't exclude much and we're basically back to option 1. None of these options is really pleasant. I think we are using option 3 at the moment, and it is not worse than the other 2 so I'm fine with that. -- Jean Delvare SUSE L3 Support -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 3/9/15 4:04 AM, Jean Delvare wrote:
Hi Jeff,
Le Sunday 08 March 2015 à 19:07 -0400, Jeff Mahoney a écrit :
On 3/8/15 5:01 AM, Jean Delvare wrote:
I've just sent a patch adding the missing MODULE_DEVICE_TABLE to the bh1780gli driver: http://marc.info/?l=linux-kernel&m=142580461109630&w=2
Note that DT/OF-based systems are not affected, and this does not prevent the driver from being used on the other systems either, all that is missing is module auto-loading. But I couldn't find any piece of kernel code instantiating this device anyway, so the only case where it would make a difference is if someone instantiates the device manually from user-space through sysfs.
Huh. Ok. Shows how much I know about how the i2c subsystem works. Is it the case that there are probably a bunch of drivers like this that would never be loaded on e.g. x86 systems?
It's very hard to say. Some I2C device drivers (most notably in drivers/hwmon) implement a detect callback which allows the driver to probe for devices and instantiate these by itself. Such drivers can be used on any system even if you don't see any piece of kernel code instantiating the device explicitly.
Also note that instantiating i2c devices through sysfs is a totally legitimate way to operate. While use cases include device emulation and driver development, it is also possible to use this mechanism to declare devices on real systems. This could even replace the in-kernel self-probing at some point in time.
So I think we have 3 options when it comes to deciding which I2C device drivers should be enabled in our kernels:
1* Enable every new driver everywhere (except specialized kernel flavors), just in case. Very easy, but a waste of build time, update time and disk space.
2* Disable every new driver everywhere by default and wait for users to ask for the drivers they actually need. We'd get cleaner and smaller kernels, but this probably requires more human interactions than we can afford, and user experience would degrade.
3* Try to guess which drivers may be needed on each platform based on the device nature. For example we know that x86 systems typically don't use I2C RTC chips. The problem is that borders are getting blurred between architectures with regards to target systems and intended uses, so I'm afraid that in the end we can't exclude much and we're basically back to option 1.
None of these options is really pleasant. I think we are using option 3 at the moment, and it is not worse than the other 2 so I'm fine with that.
Ok, I'll leave it alone then. Thanks, - -Jeff - -- Jeff Mahoney SUSE Labs -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) iQIcBAEBAgAGBQJU/aHIAAoJEB57S2MheeWyfzMP/A5lNs/tb1Ze/nsZs6q98+70 hk8cK5SnBMbcGzol8R/u1jzxEmUW596lOFbTwySS1osie5JZD/O9IdMacA2OjFV5 ymbrO850b+43sZWQeOVfWIM2jap2sS6TM9ATIfHbiF6MF8+VOWD1cmhY4gW56FJe rkgUQ6bghqhU356ic21IOWU6OAWuUnFN/OBwcs0fViT7/0X3anslEOO1pmcCED3j gwjyyHrGp8jaXSfdhPgm5NFAZLm+dNRhhUmpyvRmY3ZOjNdzhQZjEZpBdAalA00z 5wrORCQx2IQbu64idZxo0kXk5SVOZw/+687vc6TaCUcMMpg70cnzI2iRgzs5hcrN iYv2fP1aDOtvlD3oFOIzdSrZ/8Paf+Zk7rKP1iCeIo8KQrVbQJz9FhXs03A9Fk6e aIlfOo1ojZtW6ommrUh3yU1ll5mJEJuODxjq4aFqQkAALlc5A4MW4pMeak4eZRrd iunY0RIAgsY+kJ6BXJFA00l2Rf9iEbjTRy41JOKsjiD88GBtGNiIBVn2xi+8TKal uPhm9OxEmRAC8qsOZQ/o/qqDuqX2qp+UR0HqQUY6URFjJ5m6GAAgGcvmaGVbTlZx mZohDLt4w/HqdQSOzloGnKk2IKoGgGfqLLbwvxdeIvgJzY186a5vEjzAI3RlRpPy C0TOJmNvRql79z0t54w8 =MWpA -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
On Sat, Mar 07, Jeff Mahoney wrote:
fec_mpc52xx - FEC_MPC52xx - enabled on ppc - ok fec_mpc52xx_phy - FEC_MPC52xx - enabled on ppc - ok Alex, do we really run on mpc52xx? IIRC, Olaf Hering used to run some of this hardware.
This is used on the Efika board. Not sure if Factory still runs on G3 or similar hardware. If in double disable anything mpc52 related. Olaf -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
On 04.03.15 16:30, Andreas Färber wrote:
Hi,
Am 03.03.2015 um 21:40 schrieb Jeff Mahoney:
apbps2 - Documentation/devicetree/bindings/input/ps2keyb-mouse-apbps2.txt - SERIO_APBPS2 - enabled on arm64, armv6hl, armv7hl, i386, ppc, ppc64, ppc64le - typical environment is on a LEON SPARC system - i386 can be disabled - arm64, armv6hl, armv7hl, ppc, ppc64, ppc64le should probably be disabled
Don't know of an ARM platform that needs it; on the other hand, AFAIU GRLib like DesignWare is just an IP library that could be used anywhere, including FPGAs (zynq, socfpga, etc.).
bh1780gli - SENSORS_BH1780 - enabled on arm64, armv6hl, armv7hl, i386, ppc, ppc64, ppc64le, x86_64 - buggy? has an i2c device table but it's not exported
For armv6hl (i.e., Raspberry Pi) I went through and enabled all I2C and SPI sensors just recently. I obviously did not check them for presence of the module table macro line - can you or Jean send a patch to add that?
fec_mpc52xx - FEC_MPC52xx - enabled on ppc - ok fec_mpc52xx_phy - FEC_MPC52xx - enabled on ppc - ok
Alex, do we really run on mpc52xx?
Phew, that' e300, no? I don't think anyone tried :).
fsl_lpuart - SERIAL_FSL_LPUART - buggy, should depend on OF - enabled on armv6hl, armv7hl, i386, ppc, ppc64, ppc64le, x86_64 - can be disabled on i386, x86_64 - unsure if it can be disabled on ppc, ppc64, ppc64le
fsl is for Freescale, so can be disabled for our ppc* builds. cc Alex
We don't run on any FSL PPC with our kernel. I'm trying to make sure user space stays compatible whenever I can, but we don't have any kernel flavor that supports FSL chips. Alex -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
Hi, On 03/08/2015 09:56 AM, Alexander Graf wrote:
fec_mpc52xx - FEC_MPC52xx - enabled on ppc - ok fec_mpc52xx_phy - FEC_MPC52xx - enabled on ppc - ok Alex, do we really run on mpc52xx? Phew, that' e300, no? I don't think anyone tried :).
Once upon a time (about eight years ago) I was the one requesting support for mpc52xx because of this device: http://genesi.company/products/efika/5200b By that time many people were running openSUSE on this little machine. Admittedly I did not turn in my EFIKA in the past three years... Bye, CzP -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 3/8/15 4:56 AM, Alexander Graf wrote:
On 04.03.15 16:30, Andreas Färber wrote:
Hi,
Am 03.03.2015 um 21:40 schrieb Jeff Mahoney:
apbps2 - Documentation/devicetree/bindings/input/ps2keyb-mouse-apbps2.txt
- - SERIO_APBPS2
- enabled on arm64, armv6hl, armv7hl, i386, ppc, ppc64, ppc64le - typical environment is on a LEON SPARC system - i386 can be disabled - arm64, armv6hl, armv7hl, ppc, ppc64, ppc64le should probably be disabled
Don't know of an ARM platform that needs it; on the other hand, AFAIU GRLib like DesignWare is just an IP library that could be used anywhere, including FPGAs (zynq, socfpga, etc.).
bh1780gli - SENSORS_BH1780 - enabled on arm64, armv6hl, armv7hl, i386, ppc, ppc64, ppc64le, x86_64 - buggy? has an i2c device table but it's not exported
For armv6hl (i.e., Raspberry Pi) I went through and enabled all I2C and SPI sensors just recently. I obviously did not check them for presence of the module table macro line - can you or Jean send a patch to add that?
fec_mpc52xx - FEC_MPC52xx - enabled on ppc - ok fec_mpc52xx_phy - FEC_MPC52xx - enabled on ppc - ok
Alex, do we really run on mpc52xx?
Phew, that' e300, no? I don't think anyone tried :).
fsl_lpuart - SERIAL_FSL_LPUART - buggy, should depend on OF - enabled on armv6hl, armv7hl, i386, ppc, ppc64, ppc64le, x86_64 - can be disabled on i386, x86_64 - unsure if it can be disabled on ppc, ppc64, ppc64le
fsl is for Freescale, so can be disabled for our ppc* builds. cc Alex
We don't run on any FSL PPC with our kernel. I'm trying to make sure user space stays compatible whenever I can, but we don't have any kernel flavor that supports FSL chips.
Ok, so should I disable FEC_MPC52xx entirely and SERIAL_FSL_LPUART on ppc*? - -Jeff - -- Jeff Mahoney SUSE Labs -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) iQIcBAEBAgAGBQJU/NaRAAoJEB57S2MheeWyn3oQAMUPuy8in4yEpeSiJsMo+I5A 6ClTQKbutn2B5D/8CCa8XrFifJO+gPZEFy3Xy3zYIuSPEDw9JNn60Q+DYlM/lr5h 3eqjofV6OlJCe/quxdBt7XTObutOGZNTkmE80fyTlvnztIraBizK2O9F1jmBZeuz zxzWtf1cn65CdpY5PNymur+pStXsibgiOiMnUf0jFOTvjkL/9tYF6JOqNwDm3Gpc 5h4Xbo9nJVyEG3wUr3ml1+UpBM+gKSl4HbwHAEUmuw5BsTLVMJXTjAcxIpq+fymu 62kMkbEGZ+hR4QXV9s/4szY0gD0lKMmTliDJ+EA2HKmZtMuE3CxCsZpaVOtcVJIB 80Tbi1c7nUvrz5aGGlwuJtS+Z5ZIuKDrAX9kxMF6dsD4vDH1tNrjCQT4IdOs/3yU 8jGW1j75bckZHub+ye6pZwlUGQ3ubG9pzBQ6nhwyrdKYl5RzdrWX7sKqqqwTyFTH EVr65fPzKYcHXfSfCx71Plh+g58fST6LOTMF8ZvskaWsumu88X1DG2aAXK0YVrpz TMTrsKJZr1XT4JJFaD3GvOP/7HtPXS3LlCucXCT4zC1A/vtddaQG1UuQc2lf7L17 Co0s4rtB/txkh9uazzzhsgLwdGv4Cf7tG/oqLgmonk25NWEOKswpdMTSTyUaFskU pAYbHOKxTdpHQtX4HcK7 =arpD -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
On 08.03.15 18:09, Jeff Mahoney wrote: > On 3/8/15 4:56 AM, Alexander Graf wrote: > > >> On 04.03.15 16:30, Andreas Färber wrote: >>> Hi, >>> >>> Am 03.03.2015 um 21:40 schrieb Jeff Mahoney: >>>> apbps2 - >>>> Documentation/devicetree/bindings/input/ps2keyb-mouse-apbps2.txt >>>> >>>> > - SERIO_APBPS2 >>>> - enabled on arm64, armv6hl, armv7hl, i386, ppc, ppc64, >>>> ppc64le - typical environment is on a LEON SPARC system - i386 >>>> can be disabled - arm64, armv6hl, armv7hl, ppc, ppc64, ppc64le >>>> should probably be disabled >>> >>> Don't know of an ARM platform that needs it; on the other hand, >>> AFAIU GRLib like DesignWare is just an IP library that could be >>> used anywhere, including FPGAs (zynq, socfpga, etc.). >>> >>>> bh1780gli - SENSORS_BH1780 - enabled on arm64, armv6hl, >>>> armv7hl, i386, ppc, ppc64, ppc64le, x86_64 - buggy? has an i2c >>>> device table but it's not exported >>> >>> For armv6hl (i.e., Raspberry Pi) I went through and enabled all >>> I2C and SPI sensors just recently. I obviously did not check them >>> for presence of the module table macro line - can you or Jean >>> send a patch to add that? >>> >>>> fec_mpc52xx - FEC_MPC52xx - enabled on ppc - ok >>>> fec_mpc52xx_phy - FEC_MPC52xx - enabled on ppc - ok >>> >>> Alex, do we really run on mpc52xx? > >> Phew, that' e300, no? I don't think anyone tried :). > >>> >>>> fsl_lpuart - SERIAL_FSL_LPUART - buggy, should depend on OF - >>>> enabled on armv6hl, armv7hl, i386, ppc, ppc64, ppc64le, x86_64 >>>> - can be disabled on i386, x86_64 - unsure if it can be >>>> disabled on ppc, ppc64, ppc64le >>> >>> fsl is for Freescale, so can be disabled for our ppc* builds. cc >>> Alex > >> We don't run on any FSL PPC with our kernel. I'm trying to make >> sure user space stays compatible whenever I can, but we don't have >> any kernel flavor that supports FSL chips. > > Ok, so should I disable FEC_MPC52xx Let's disable it and wait until someone screams. I doubt anyone does. > entirely and SERIAL_FSL_LPUART According to the patch description it's only available on ARM platforms, so yes, disable it for ppc. > Add Freescale lpuart driver support. The lpuart device > can be found on Vybrid VF610 and Layerscape LS-1 SoCs. Alex -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 3/3/15 3:40 PM, Jeff Mahoney wrote:
Hi folks -
I just did the update to 4.0-rc1 and am in something of a cleanup mode. There are a number of drivers that are only loaded when enumerated via device tree/open firmware. On x86_64, there isn't any hardware we support that uses DT/OF, so we can skip building them entirely. On i386, we support the OLPC XO-1, so we need to determine which drivers that hardware requires. It gets cloudy when it comes to ppc/ppc64/ppc64le.
The following is a quick review of drivers that we are building that are only enumerated using device tree/open firmware. Drivers that are only being built on ARM already are not included.
The gist is that there are 46 drivers that are built with only DT/OF support across all non-ARM architectures. Of those, 17 are being built because the driver doesn't report CONFIG_OF as a dependency. 24 of them are being built on i386 or x86_64, where the devices will never be discovered.
Before I go and commit these changes, I'd like to ask for some quick review to see if I've overlooked anything or have some false positives. As it is, I'm sure there is hardware that is only on ARM but is being built for ppc.
The process used was to expand every non-ARM kernel RPM from Kernel:HEAD and run depmod on each one. Every driver that loads with OF/DT will have an alias that starts with of:. Every driver that can also load after being enumerated by another mechanism (typically either ACPI or I2C) is filtered out.
airport - APPLE_AIRPORT - enabled on ppc, ppc64, ppc64le - macio: ppc64le can be disabled altera_tse - ALTERA_TSE - buggy, should require OF - enabled on armv7hl, i386, ppc, ppc64, ppc64le, s390x, x86_64 - i386, s390x, x86_64 can be disabled - ppc, ppc64, ppc64le should probably be disabled apbps2 - Documentation/devicetree/bindings/input/ps2keyb-mouse-apbps2.txt - SERIO_APBPS2 - enabled on arm64, armv6hl, armv7hl, i386, ppc, ppc64, ppc64le - typical environment is on a LEON SPARC system - i386 can be disabled - arm64, armv6hl, armv7hl, ppc, ppc64, ppc64le should probably be disabled bh1780gli - SENSORS_BH1780 - enabled on arm64, armv6hl, armv7hl, i386, ppc, ppc64, ppc64le, x86_64 - buggy? has an i2c device table but it's not exported bmac - BMAC - enabled on ppc - ok docg3 - MTD_DOCG3 - buggy, should depend on OF - enabled on i386, ppc64, ppc64le, x86_64 - i386, x86_64 can be disabled - ppc64, ppc64le should probably be disabled dw_wdt - DW_WATCHDOG - buggy, should depend on OF - enabled on armv6hl, armv7hl, i386, ppc, ppc64, ppc64le, x86_64 - i386, x86_64, ppc, ppc64, ppc64le can be disabled - Used to be documented as ARM-only until commit 58a251f2c25 updated it to be generic after it became used on Xtensa. ethoc - ETHOC - buggy, should depend on OF - enabled on arm64, armv6hl, armv7hl, i386, ppc, ppc64, ppc64le, x86_64 - i386, x86_64 can be disabled - can probably be disabled everywhere fec_mpc52xx - FEC_MPC52xx - enabled on ppc - ok fec_mpc52xx_phy - FEC_MPC52xx - enabled on ppc - ok fsl_lpuart - SERIAL_FSL_LPUART - buggy, should depend on OF - enabled on armv6hl, armv7hl, i386, ppc, ppc64, ppc64le, x86_64 - can be disabled on i386, x86_64 - unsure if it can be disabled on ppc, ppc64, ppc64le gpio_74xx_mmio - GPIO_74XX_MMIO - enabled on arm64, i386, ppc, ppc64, ppc64le - can be disbled on i386 gpio_beeper - INPUT_GPIO_BEEPER - buggy, should depend on OF - enabled on i386, ppc, ppc64, ppc64le, x86_64 - can be disabled on i386, x86_64 - can probably be disabled everywhere gpio_grgpio - GPIO_GRGPIO - Documentation/devicetree/bindings/gpio/gpio-grgpio.txt - typical environment is on a LEON SPARC system - enabled on arm64, armv6hl, armv7hl, i386, ppc, ppc64, ppc64le - can be disabled on i386, ppc, ppc64, ppc64le - can probably be disabled everywhere gpio_ir_recv - IR_GPIO_CIR - buggy, should depend on OF - enabled on arm64, armv6hl, armv7hl, i386, ppc, ppc64, ppc64le, x86_64 - can be disabled on i386, x86_64 gpio_syscon - GPIO_SYSCON - buggy, should depend on OF - enabled on arm64, armv6hl, armv7hl, i386, ppc, ppc64, ppc64le - can be disabled on i386, x86_64 gpio_wdt - GPIO_WATCHDOG - enabled on armv6hl, armv7hl, i386, ppc, ppc64, ppc64le - can be disabled on i386 i2c_mpc - I2C_MPC - should probably depend on PPC32 - enabled on ppc, ppc64, ppc64le - can be disabled on ppc64, ppc64 i2c_opal - I2C_OPAL - enabled on ppc64, ppc64le - ok ibm_emac - IBM_EMAC - enabled on ppc64,ppc64le - ok ipmi_powernv - IPMI_POWERNV - enabled on ppc64, ppc64le - ok ks8851_mll - KS8851_MLL - buggy, should depend on OF - enabled on arm64, armv7hl, armv6hl, i386, ppc, ppc64, ppc64le, x86_64 - can be disabled on i386, x86_64 - should probably be disabled on ppc, ppc64, ppc64le ll_temac - XILINX_LL_TEMAC - enabled on ppc, ppc64, ppc64le - ok mac53c94 - SCSI_MAC53C94 - enabled on ppc - ok mace - MACE - enabled on ppc - ok mdio_mux_gpio - MDIO_BUS_MUX_GPIO - enabled on arm64, armv6hl, armv7hl, i386, ppc, ppc64, ppc64le - can be disabled on i386 mdio_mux_mmioreg - MDIO_BUS_MUX_GPIO - enabled on arm64, armv6hl, armv7hl, i386, ppc, ppc64, ppc64le - can be disabled on i386 mesh - SCSI_MESH - enabled on ppc - ok ocfb - FB_OPENCORES - buggy, should depend on OF - enabled on i386, ppc, ppc64, ppc64le, x86_64 - can be disabled on i386, x86_64 - can probably be disabled everywhere olpc_apsp - ok olpc_battery - ok pata_mpc52xx - PATA_MPC52xx - enabled on ppc - ok physmap_of - MTD_PHYSMAP_OF - enabled on arm64, armv6hl, armv7h, i386 - not sure if required by olpc flash pps_gpio - PPS_CLIENT_GPIO - buggy, should depend on OF - enabled on i386, ppc, ppc64, ppc64le, x86_64 - can be disabled on i386, x86_64 rtc_snvs - RTC_DRV_SNVS - enabled on arm64, armv6hl, armv7hl, ppc, ppc64, ppc64le - can be disabled on i386 sdhci_of_arasan - MMC_SDHCI_OF_ARASAN - enabled on arm64, armv6hl, armv7hl, i386 - can be disabled on i386 - can possibly be disabled on arm64 snd_aoa_i2sbus - SND_AOA_SOUNDBUS_I2S - enabled on ppc, ppc64, ppc64le - ok st_drv - TI_ST - buggy, should depend on OF - enabled on arm64, armv7hl, armv6hl, i386, ppc, ppc64, ppc64le, x86_64 - can be disabled on i386, x86_64 - can probably be disabled on ppc, ppc64, ppc64le stmmac_platform - STMMAC_PLATFORM - buggy, should depend on OF - enabled on armv7hl, i386, ppc, ppc64, ppc64le, x86_64 - can be disabled on i386, ppc, ppc64, ppc64le, x86_64 ti_am335x_tscadc - MFD_TI_AM335X_TSCADC - buggy, should depend on OF - enabled on arm64, armv6hl, armv7hl, i386, ppc, ppc64, ppc64le, x86_64 - can be disabled on i386, ppc, ppc64, ppc64le, x86_64 timeriomem_rng - HW_RANDOM_TIMERIOMEM - buggy, should depend on OF - enabled on arm64, armv6hl, armv7hl, ppc - can probably be disabled on ppc virtio_mmio - buggy, should depend on OF - enabled on arm64, armv7hl, i386, ppc, ppc64, ppc64le, x86_64 - can be disabled on i386, x86_64 w1_gpio - W1_MASTER_GPIO - buggy, should depend on OF - enabled on arm64, armv6hl, armv7hl, i386, ppc,ppc64, ppc64le, x86_64 - can be disabled on i386, x86_64 xilinx_emaclite - XILINX_EMACLITE - enabled on armv7hl, ppc - ok xilinx_ps2 - SERIO_XILINX_XPS_PS2 - enabled on ppc, ppc64, ppc64le - ok xilinx_uartps - SERIAL_XILINX_PS_UART - enabled on armv6hl, armv6hl, ppc, ppc64, ppc64le, i386 - can be disabled on i386
Thanks for the feedback, everyone. I've pushed the config update. Jan, I updated the xen/ec2/pv configs for this as well so you shouldn't need to resync for that. config: disable FEC_MPC52xx on ppc config: disable SERIAL_XILINX_PS_UART on i386 config: disable W1_MASTER_GPIO on i386, x86_64 config: disable VIRTIO_MMIO on i386, x86_64 config: disable MFD_TI_AM335X_TSCADC on non-ARM platforms config: disable STMMAC_PLATFORM on non-ARM platforms config: disable TI_ST and RADIO_WL128X on i386, x86_64 config: disable MMC_SDHCI_OF_ARASAN on i386 config: disable PPS_CLIENT_GPIO on i386, x86_64 config: disable MDIO_BUS_MUX_GPIO on i386 config: disable KS8851_MLL on i386, x86_64 config: disable I2C_MPC on ppc64, ppc64le config: disable GPIO_WATCHDOG on i386 config: disable GPIO_SYSCON on i386 config: disable IR_GPIO_CIR on i386, x86_64 config: disable GPIO_GRGPIO on i386, ppc, ppc64, ppc64le config: disable INPUT_GPIO_BEEPER on i386, x86_64 config: disable GPIO_74XX_MMIO on i386 config: disable SERIAL_FSL_LPUART on non-ARM platforms. config: disable DW_WATCHDOG on i386, x86_64, ppc, ppc64, ppc64le config: disable MTD_DOCG3 on i386, x86_64, ppc64, ppc64le config: disable SERIO_APBPS2 on i386 config: disable APPLE_AIRPORT on ppc64le config: disable ALTERA_TSE on i386/x86_64 config: disable ETHOC on i386, x86_64 config: disable FB_OPENCORES on i386/x86_64 - -Jeff - -- Jeff Mahoney SUSE Labs -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) iQIcBAEBAgAGBQJU/aaKAAoJEB57S2MheeWyacUQAJHyQbF6RorDD8+fE/nYWPfg vnB79tUFjqQr6mHZwCwU8fgeDG9PraAGntvhZaizP1wM2ikOJsSs+Wf14NL25KaM NI0OhA9othseHpR9Tx+thgZH7mKPOEzGSXgfGHt4F5nMtPhSIJTgTIkzjNQ5Vsrc reY8g1/epYHDN5elbqbzssYppfRXeAuKHM9/WilXpoqE8ONEoKQsU71vBfaGOeX5 HjwkoZTg3381PwXoA/QkhotMg8VRNfSf8LYdK3piM/iQwOD+enBY4rFxQ/wHaN1e ft0/4h6eQeNL9ZAD9k4PZMd1ESrWkX1TOC7WJbXSB5VJiPw/g52tipg5NK86cIC3 gUxQlozU9WiEIAJLr70pZ/0aEY/vjm8Qey6vCcbaYzMzFDFLP9kvwQRQ7lcYVvEg o/6N1zz9/zGBFKtMXIW38qcqN2Hw1/XiuFSsQ8aiYjxA7/dRZbKqp9u11olUSbIK wYCb/Vui9TEAJ+dWKDfDtED0ZM1RmlFNrR/oe2IRq/5OrSskvB3vxc90+pRrmiO+ E9qjUBZUCi4dUmb9BgDDFkENypCdEzIWhdGgd0KXp5HLT6UcZevdoJi7AkBg7gjH CBTFubQqwFaZFAj71dOT/KVWSzAeo/5/K6/s4rCPNB3OmjBSJJh9Iu8IPj76hRHF Nyi3caw23LZNAJy++1hi =OjKI -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
participants (7)
-
Alexander Graf -
Andreas Färber -
Jean Delvare -
Jeff Mahoney -
Olaf Hering -
Peter Czanik -
Takashi Iwai