Re: [GIT PULL] Driver core update for 4.7-rc1
On Sat, May 21, 2016 at 10:16 AM, William Breathitt Graywrote: > > Would you like me to submit a patchset after your commit to introduce > the ISA_BUS/ISA_BUS_API Kconfig options, as well as adjust the relevant > drivers' Kconfig options to depend on the ISA_BUS_API? Yes please. Linus
Re: [GIT PULL] Driver core update for 4.7-rc1
On Sat, May 21, 2016 at 10:16 AM, William Breathitt Gray wrote: > > Would you like me to submit a patchset after your commit to introduce > the ISA_BUS/ISA_BUS_API Kconfig options, as well as adjust the relevant > drivers' Kconfig options to depend on the ISA_BUS_API? Yes please. Linus
Re: [GIT PULL] Driver core update for 4.7-rc1
On Sat, May 21, 2016 at 09:59:09AM -0700, Linus Torvalds wrote: >Author: Linus Torvalds>Date: Sat May 21 09:13:41 2016 -0700 > >x86 isa: add back X86_32 dependency on CONFIG_ISA > >Commit b3c1be1b789c ("base: isa: Remove X86_32 dependency") made ISA >support available on x86-64 too. That's not right - while there are >some LPC-style devices that might be useful still and be based on >ISA-like IP blocks, that is *not* an excuse to try to enable any random >legacy drivers. > >Such drivers should be individually enabled and made to perhaps depend >on ISA_DMA_API instead (which we have continued to support on x86-64). >Or we could add another "ISA_XYZ_API" that we support that doesn't >enable random old drivers that aren't even 64-bit clean nor do we have >any test coverage for. > >Turning off ISA will now also turn off some drivers that have been >marked as depending on it as part of this series, and that used to work >on modern platforms. > >See for example commits ad7afc38eab3..cc736607c86d, which may also need >to be reverted. > >Cc: William Breathitt Gray >Cc: Linus Walleij >Cc: Guenter Roeck >Cc: Greg Kroah-Hartman >Signed-off-by: Linus Torvalds > >diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig >index 48ac29034e1e..0a7b885964ba 100644 >--- a/arch/x86/Kconfig >+++ b/arch/x86/Kconfig >@@ -2447,6 +2447,8 @@ config ISA_DMA_API > Enables ISA-style DMA support for devices requiring such controllers. > If unsure, say Y. > >+if X86_32 >+ > config ISA > bool "ISA support" > ---help--- >@@ -2456,8 +2458,6 @@ config ISA > (MCA) or VESA. ISA is an older system, now being displaced by PCI; > newer boards don't support it. If you have ISA, say Y, otherwise N. > >-if X86_32 >- > config EISA > bool "EISA support" > depends on ISA Acked-by: William Breathitt Gray That makes sense to me. The drivers which switched to use the ISA bus driver would simply need their respective Kconfig option adjusted to depend on a "ISA_BUS_API" option, rather than ISA, to allow them to compile on X86_64. Would you like me to submit a patchset after your commit to introduce the ISA_BUS/ISA_BUS_API Kconfig options, as well as adjust the relevant drivers' Kconfig options to depend on the ISA_BUS_API? William Breathitt Gray
Re: [GIT PULL] Driver core update for 4.7-rc1
On Sat, May 21, 2016 at 09:59:09AM -0700, Linus Torvalds wrote: >Author: Linus Torvalds >Date: Sat May 21 09:13:41 2016 -0700 > >x86 isa: add back X86_32 dependency on CONFIG_ISA > >Commit b3c1be1b789c ("base: isa: Remove X86_32 dependency") made ISA >support available on x86-64 too. That's not right - while there are >some LPC-style devices that might be useful still and be based on >ISA-like IP blocks, that is *not* an excuse to try to enable any random >legacy drivers. > >Such drivers should be individually enabled and made to perhaps depend >on ISA_DMA_API instead (which we have continued to support on x86-64). >Or we could add another "ISA_XYZ_API" that we support that doesn't >enable random old drivers that aren't even 64-bit clean nor do we have >any test coverage for. > >Turning off ISA will now also turn off some drivers that have been >marked as depending on it as part of this series, and that used to work >on modern platforms. > >See for example commits ad7afc38eab3..cc736607c86d, which may also need >to be reverted. > >Cc: William Breathitt Gray >Cc: Linus Walleij >Cc: Guenter Roeck >Cc: Greg Kroah-Hartman >Signed-off-by: Linus Torvalds > >diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig >index 48ac29034e1e..0a7b885964ba 100644 >--- a/arch/x86/Kconfig >+++ b/arch/x86/Kconfig >@@ -2447,6 +2447,8 @@ config ISA_DMA_API > Enables ISA-style DMA support for devices requiring such controllers. > If unsure, say Y. > >+if X86_32 >+ > config ISA > bool "ISA support" > ---help--- >@@ -2456,8 +2458,6 @@ config ISA > (MCA) or VESA. ISA is an older system, now being displaced by PCI; > newer boards don't support it. If you have ISA, say Y, otherwise N. > >-if X86_32 >- > config EISA > bool "EISA support" > depends on ISA Acked-by: William Breathitt Gray That makes sense to me. The drivers which switched to use the ISA bus driver would simply need their respective Kconfig option adjusted to depend on a "ISA_BUS_API" option, rather than ISA, to allow them to compile on X86_64. Would you like me to submit a patchset after your commit to introduce the ISA_BUS/ISA_BUS_API Kconfig options, as well as adjust the relevant drivers' Kconfig options to depend on the ISA_BUS_API? William Breathitt Gray
Re: [GIT PULL] Driver core update for 4.7-rc1
On Sat, May 21, 2016 at 9:31 AM, Linus Torvaldswrote: > > We're not suddenly enabling ISA on x86-64 after having successfully > gotten rid of that insane crap long long ago. > > If you have *specific* dribvers that are actually relevant for some > reason, make those ones available based on other options. For example, > we've had the ISA_DMA_API config option to say "we support a subset of > ISA, even when we don't actually want to ever see actual plug-in ISA > cards". I am planning on committing something like the attached. Note that anything that added "depends on ISA" because of the other patches will now be disabled on x86-64, even if that driver wasn't disabled before. Added Linus Walleij and Guenther Roech to the cc because of the drivers that I'm aware that did this. To repeat: I'm not at all interested in enabling random old drivers on x86-64. Any driver enablement needs to be done on a one-by-one basis, after having actually gotten TESTING, and after having had people make sure that we don't get tons of new warnings like we did with the "let's just enable ISA randomly" approach. I'm ok with enabling some "ISA_BUS_API" support (like we have ISA_DMA_API) that allows people to enable drivers one-by-one as they are converted to a convenience function. The patch series seems to have had that kind of approach initially. I'd suggest doing that ISA_BUS_API config option as a *general* thing (not arch-specific), and make it start out like config ISA_BUS_API def_bool ISA which means that everybody gets it, and if ISA was enabled, it will be enabled automatically. Then, architectures that do *not* enable ISA itself (like x86-64), could choose to have a config option like config ISA_BUS bool "support ISA-style drivers on modern systems" if (x86 && EXPERT) default y select ISA_BUS_API or something, which means that ISA_BUS_API would then get enabled (but not ISA itself). That's similar to what we do today with ISA_DMA_API, except we made the mistake of making all the different architectures define the ISA_DMA_API option. It's the wholesale "enable random crap" that I will not accept. Not even if there is then "hide the crap again when it causes warnings". Even a driver that doesn't warn isn't necessarily useful, and I don't want people to suddenly start seeing a lot of options for random ISA drivers that simply aren't relevant, and never will be. Not even if they compile cleanly. Linus Author: Linus Torvalds Date: Sat May 21 09:13:41 2016 -0700 x86 isa: add back X86_32 dependency on CONFIG_ISA Commit b3c1be1b789c ("base: isa: Remove X86_32 dependency") made ISA support available on x86-64 too. That's not right - while there are some LPC-style devices that might be useful still and be based on ISA-like IP blocks, that is *not* an excuse to try to enable any random legacy drivers. Such drivers should be individually enabled and made to perhaps depend on ISA_DMA_API instead (which we have continued to support on x86-64). Or we could add another "ISA_XYZ_API" that we support that doesn't enable random old drivers that aren't even 64-bit clean nor do we have any test coverage for. Turning off ISA will now also turn off some drivers that have been marked as depending on it as part of this series, and that used to work on modern platforms. See for example commits ad7afc38eab3..cc736607c86d, which may also need to be reverted. Cc: William Breathitt Gray Cc: Linus Walleij Cc: Guenter Roeck Cc: Greg Kroah-Hartman Signed-off-by: Linus Torvalds diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig index 48ac29034e1e..0a7b885964ba 100644 --- a/arch/x86/Kconfig +++ b/arch/x86/Kconfig @@ -2447,6 +2447,8 @@ config ISA_DMA_API Enables ISA-style DMA support for devices requiring such controllers. If unsure, say Y. +if X86_32 + config ISA bool "ISA support" ---help--- @@ -2456,8 +2458,6 @@ config ISA (MCA) or VESA. ISA is an older system, now being displaced by PCI; newer boards don't support it. If you have ISA, say Y, otherwise N. -if X86_32 - config EISA bool "EISA support" depends on ISA
Re: [GIT PULL] Driver core update for 4.7-rc1
On Sat, May 21, 2016 at 9:31 AM, Linus Torvalds wrote: > > We're not suddenly enabling ISA on x86-64 after having successfully > gotten rid of that insane crap long long ago. > > If you have *specific* dribvers that are actually relevant for some > reason, make those ones available based on other options. For example, > we've had the ISA_DMA_API config option to say "we support a subset of > ISA, even when we don't actually want to ever see actual plug-in ISA > cards". I am planning on committing something like the attached. Note that anything that added "depends on ISA" because of the other patches will now be disabled on x86-64, even if that driver wasn't disabled before. Added Linus Walleij and Guenther Roech to the cc because of the drivers that I'm aware that did this. To repeat: I'm not at all interested in enabling random old drivers on x86-64. Any driver enablement needs to be done on a one-by-one basis, after having actually gotten TESTING, and after having had people make sure that we don't get tons of new warnings like we did with the "let's just enable ISA randomly" approach. I'm ok with enabling some "ISA_BUS_API" support (like we have ISA_DMA_API) that allows people to enable drivers one-by-one as they are converted to a convenience function. The patch series seems to have had that kind of approach initially. I'd suggest doing that ISA_BUS_API config option as a *general* thing (not arch-specific), and make it start out like config ISA_BUS_API def_bool ISA which means that everybody gets it, and if ISA was enabled, it will be enabled automatically. Then, architectures that do *not* enable ISA itself (like x86-64), could choose to have a config option like config ISA_BUS bool "support ISA-style drivers on modern systems" if (x86 && EXPERT) default y select ISA_BUS_API or something, which means that ISA_BUS_API would then get enabled (but not ISA itself). That's similar to what we do today with ISA_DMA_API, except we made the mistake of making all the different architectures define the ISA_DMA_API option. It's the wholesale "enable random crap" that I will not accept. Not even if there is then "hide the crap again when it causes warnings". Even a driver that doesn't warn isn't necessarily useful, and I don't want people to suddenly start seeing a lot of options for random ISA drivers that simply aren't relevant, and never will be. Not even if they compile cleanly. Linus Author: Linus Torvalds Date: Sat May 21 09:13:41 2016 -0700 x86 isa: add back X86_32 dependency on CONFIG_ISA Commit b3c1be1b789c ("base: isa: Remove X86_32 dependency") made ISA support available on x86-64 too. That's not right - while there are some LPC-style devices that might be useful still and be based on ISA-like IP blocks, that is *not* an excuse to try to enable any random legacy drivers. Such drivers should be individually enabled and made to perhaps depend on ISA_DMA_API instead (which we have continued to support on x86-64). Or we could add another "ISA_XYZ_API" that we support that doesn't enable random old drivers that aren't even 64-bit clean nor do we have any test coverage for. Turning off ISA will now also turn off some drivers that have been marked as depending on it as part of this series, and that used to work on modern platforms. See for example commits ad7afc38eab3..cc736607c86d, which may also need to be reverted. Cc: William Breathitt Gray Cc: Linus Walleij Cc: Guenter Roeck Cc: Greg Kroah-Hartman Signed-off-by: Linus Torvalds diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig index 48ac29034e1e..0a7b885964ba 100644 --- a/arch/x86/Kconfig +++ b/arch/x86/Kconfig @@ -2447,6 +2447,8 @@ config ISA_DMA_API Enables ISA-style DMA support for devices requiring such controllers. If unsure, say Y. +if X86_32 + config ISA bool "ISA support" ---help--- @@ -2456,8 +2458,6 @@ config ISA (MCA) or VESA. ISA is an older system, now being displaced by PCI; newer boards don't support it. If you have ISA, say Y, otherwise N. -if X86_32 - config EISA bool "EISA support" depends on ISA
Re: [GIT PULL] Driver core update for 4.7-rc1
On Sat, May 21, 2016 at 9:20 AM, William Breathitt Graywrote: > > I'll submit patches to resolve these warnings and errors. No. I will disable that ISA config option. We're not randomly making old drivers available on modern platforms. Really. We're not suddenly enabling ISA on x86-64 after having successfully gotten rid of that insane crap long long ago. If you have *specific* dribvers that are actually relevant for some reason, make those ones available based on other options. For example, we've had the ISA_DMA_API config option to say "we support a subset of ISA, even when we don't actually want to ever see actual plug-in ISA cards". Your patch already resulted in having to add several cases of - depends on ISA + depends on X86 && ISA because you tried to randomly widen what "ISA" meant. No. No no no. No more "let's randomly change what ISA is". Do this enabling one driver at a time, or not at all. I'm not at all interested in seeing some kind of generic "we will support random shit on modern platfoms" crap. 99% of all drivers that depend on ISA have no maintainership, and will never get any maintainership. Linus
Re: [GIT PULL] Driver core update for 4.7-rc1
On Sat, May 21, 2016 at 9:20 AM, William Breathitt Gray wrote: > > I'll submit patches to resolve these warnings and errors. No. I will disable that ISA config option. We're not randomly making old drivers available on modern platforms. Really. We're not suddenly enabling ISA on x86-64 after having successfully gotten rid of that insane crap long long ago. If you have *specific* dribvers that are actually relevant for some reason, make those ones available based on other options. For example, we've had the ISA_DMA_API config option to say "we support a subset of ISA, even when we don't actually want to ever see actual plug-in ISA cards". Your patch already resulted in having to add several cases of - depends on ISA + depends on X86 && ISA because you tried to randomly widen what "ISA" meant. No. No no no. No more "let's randomly change what ISA is". Do this enabling one driver at a time, or not at all. I'm not at all interested in seeing some kind of generic "we will support random shit on modern platfoms" crap. 99% of all drivers that depend on ISA have no maintainership, and will never get any maintainership. Linus
Re: [GIT PULL] Driver core update for 4.7-rc1
On Fri, May 20, 2016 at 10:04:38PM -0700, Greg KH wrote: >On Fri, May 20, 2016 at 09:51:18PM -0700, Linus Torvalds wrote: >> On Fri, May 20, 2016 at 8:23 PM, Greg KHwrote: >> > >> > William Breathitt Gray (13): >> > base: isa: Remove X86_32 dependency >> > isa: Decouple X86_32 dependency from the ISA Kconfig option >> >> So I'm going to revert these unless I get >> >> (a) a good reason for them >> >> (b) patches to get rid of the incessant warnings these cause. > >What warnings? I haven't seen any reports of warnings, what .config >causes them? > >> Most of the ISA drivers are not 64-bit safe. They give compiler >> warnings, and they will definitely simply not work. So just blindly >> enabling that shit is not the answer. >> >> We've never needed this before, why do we need it now? > >I'll let William answer that, it seems he has some crazy isa hardware >for x86_64 platforms... > >thanks, > >greg k-h I'll submit patches to resolve these warnings and errors. The primary reason for decoupling the x86_32 dependency from the X86 ISA Kconfig option is to allow the ISA bus driver to be used to interface with PC/104 devices. Although you are correct that the ISA bus for general consumers is essentially legacy from the pre-64-bit era, the PC/104 bus (a derivative of the ISA bus) is ubiquitous in the embedded systems industry; new PC/104 devices are developed and produced every day. Despite the form factor difference, PC/104 devices appear to software as ISA devices: you can interact with them like you would any other ISA device, using I/O port-mapped reads and writes. This makes the existing ISA bus driver an apt solution to interface with PC/104 devices (to software, there is no difference between PC/104 and ISA). The issue arises with the X86_32 dependency on the X86 ISA Kconfig option: this dependency is not necessary because there is no hard 32-bit dependency on the ISA bus itself; in fact, the ISA bus driver (drivers/base/isa.c) is portable across all X86 platforms. Worse, the X86_32 dependency puts an artifical limitation on PC/104 devices. Many embedded systems vendors produce PC/104 compatible motherboards running 64-bit X86 processors; this isn't the exception, it's the norm. To use the ISA bus driver with the X86_32 dependency means preventing support for PC/104 devices on virtually any modern PC/104 compatible embedded system motherboard. There are real PC/104 devices out there, from real companies and people, intended to run on real motherboards with 64-bit X86 processors. I'm in the process of developing drivers for a few new PC/104 devices. For reference, there are currently four PC/104 drivers already merged: the Apex Embedded Systems STX104 DAC driver, the ACCES 104-DIO-48E series GPIO driver, the ACCES 104-IDI-48 series GPIO driver, and the ACCES 104-IDIO-16 series GPIO driver. Although not necessarily PC/104 devices, the WinSystems EBC-C384 watchdog timer driver and WinSystems WS16C48 GPIO driver communicate via an ISA bus interface and are also expected to run on motherboards with 64-bit X86 processors. One alternative to decoupling the X86_32 dependency from the ISA Kconfig option would be to copy the drivers/base/isa.c code to a new drivers/base/pc104.c file, which will serve as the PC/104 bus driver; new PC/104 drivers intended to run on any X86 platform can use this new bus driver. However, it doesn't seem right to maintain an identical set of code simply to sidestep a Kconfig dependency issue. Removing the X86_32 dependency from the X86 ISA Kconfig option results in warnings and errors for two reasons: 1. The relevant code is meant to be 32-bit X86 specific. - In this case, an explicit X86_32 should be added to the Kconfig option for the relevant code. 2. The relevant code is meant to work on both 32-bit and 64-bit X86 platforms, but a 32-bit specific piece of code was overlooked. - In this case, the code should be fixed to be portable across X86 platforms as intended. Regardless, in both scenarios, adding an explicit X86_32 dependency to the relevant Kconfig options resolves the warnings and errors by limiting the compilation to X86_32 as they have been before; thus the status quo is maintained. However, a major benefit is gained: the ISA bus driver may now be used to support these new PC/104 devices expected to run with 64-bit X86 processors. Regarding the excerpt of warnings already posted: the Kconfig for the IDE chipsets has an X86 dependency which should explicitly be X86_32, while the 3C515 and NI65 drivers' Kconfig dependencies should also be adjusted since neither use the X86 ISA bus driver. As I said before, it is my intention to submit patches to resolve the warnings and errors which have appeared; they are currently there simply because I mistakenly overlooked them when I performed my initial testing. I've logged the warnings and errors after compiling from an
Re: [GIT PULL] Driver core update for 4.7-rc1
On Fri, May 20, 2016 at 10:04:38PM -0700, Greg KH wrote: >On Fri, May 20, 2016 at 09:51:18PM -0700, Linus Torvalds wrote: >> On Fri, May 20, 2016 at 8:23 PM, Greg KH wrote: >> > >> > William Breathitt Gray (13): >> > base: isa: Remove X86_32 dependency >> > isa: Decouple X86_32 dependency from the ISA Kconfig option >> >> So I'm going to revert these unless I get >> >> (a) a good reason for them >> >> (b) patches to get rid of the incessant warnings these cause. > >What warnings? I haven't seen any reports of warnings, what .config >causes them? > >> Most of the ISA drivers are not 64-bit safe. They give compiler >> warnings, and they will definitely simply not work. So just blindly >> enabling that shit is not the answer. >> >> We've never needed this before, why do we need it now? > >I'll let William answer that, it seems he has some crazy isa hardware >for x86_64 platforms... > >thanks, > >greg k-h I'll submit patches to resolve these warnings and errors. The primary reason for decoupling the x86_32 dependency from the X86 ISA Kconfig option is to allow the ISA bus driver to be used to interface with PC/104 devices. Although you are correct that the ISA bus for general consumers is essentially legacy from the pre-64-bit era, the PC/104 bus (a derivative of the ISA bus) is ubiquitous in the embedded systems industry; new PC/104 devices are developed and produced every day. Despite the form factor difference, PC/104 devices appear to software as ISA devices: you can interact with them like you would any other ISA device, using I/O port-mapped reads and writes. This makes the existing ISA bus driver an apt solution to interface with PC/104 devices (to software, there is no difference between PC/104 and ISA). The issue arises with the X86_32 dependency on the X86 ISA Kconfig option: this dependency is not necessary because there is no hard 32-bit dependency on the ISA bus itself; in fact, the ISA bus driver (drivers/base/isa.c) is portable across all X86 platforms. Worse, the X86_32 dependency puts an artifical limitation on PC/104 devices. Many embedded systems vendors produce PC/104 compatible motherboards running 64-bit X86 processors; this isn't the exception, it's the norm. To use the ISA bus driver with the X86_32 dependency means preventing support for PC/104 devices on virtually any modern PC/104 compatible embedded system motherboard. There are real PC/104 devices out there, from real companies and people, intended to run on real motherboards with 64-bit X86 processors. I'm in the process of developing drivers for a few new PC/104 devices. For reference, there are currently four PC/104 drivers already merged: the Apex Embedded Systems STX104 DAC driver, the ACCES 104-DIO-48E series GPIO driver, the ACCES 104-IDI-48 series GPIO driver, and the ACCES 104-IDIO-16 series GPIO driver. Although not necessarily PC/104 devices, the WinSystems EBC-C384 watchdog timer driver and WinSystems WS16C48 GPIO driver communicate via an ISA bus interface and are also expected to run on motherboards with 64-bit X86 processors. One alternative to decoupling the X86_32 dependency from the ISA Kconfig option would be to copy the drivers/base/isa.c code to a new drivers/base/pc104.c file, which will serve as the PC/104 bus driver; new PC/104 drivers intended to run on any X86 platform can use this new bus driver. However, it doesn't seem right to maintain an identical set of code simply to sidestep a Kconfig dependency issue. Removing the X86_32 dependency from the X86 ISA Kconfig option results in warnings and errors for two reasons: 1. The relevant code is meant to be 32-bit X86 specific. - In this case, an explicit X86_32 should be added to the Kconfig option for the relevant code. 2. The relevant code is meant to work on both 32-bit and 64-bit X86 platforms, but a 32-bit specific piece of code was overlooked. - In this case, the code should be fixed to be portable across X86 platforms as intended. Regardless, in both scenarios, adding an explicit X86_32 dependency to the relevant Kconfig options resolves the warnings and errors by limiting the compilation to X86_32 as they have been before; thus the status quo is maintained. However, a major benefit is gained: the ISA bus driver may now be used to support these new PC/104 devices expected to run with 64-bit X86 processors. Regarding the excerpt of warnings already posted: the Kconfig for the IDE chipsets has an X86 dependency which should explicitly be X86_32, while the 3C515 and NI65 drivers' Kconfig dependencies should also be adjusted since neither use the X86 ISA bus driver. As I said before, it is my intention to submit patches to resolve the warnings and errors which have appeared; they are currently there simply because I mistakenly overlooked them when I performed my initial testing. I've logged the warnings and errors after compiling from an allmodconfig, with and without the
Re: [GIT PULL] Driver core update for 4.7-rc1
On Fri, May 20, 2016 at 10:39 PM, Greg KHwrote: > > This is odd, I just tried this, and I don't get any error for > drivers/rtc/rtc-ds1685.c, nor any drivers/rtc/ file. Ok, the rtc one was different - it's due to the objtool checks. Not related to the ISA issue. The others (the "warning: cast to pointer from integer" ones) are all due to ISA, afaik. I actually tried to find a picture of a Racal NI6510 card just to show you guys what kinds of drivers we're talking about that got enabled. I found a google books snipet from PC mag 1993 instead. That piece of old-timey engineering sold for $239 USD, and it lost in a benchmark to an ne2000 card. We're talking 10MB ethernet only, because this was before people used fast ethernet, and the competition was still often 10base2/BNC. We're talking stone-age technology. We really don't want to enable it. Linus
Re: [GIT PULL] Driver core update for 4.7-rc1
On Fri, May 20, 2016 at 10:39 PM, Greg KH wrote: > > This is odd, I just tried this, and I don't get any error for > drivers/rtc/rtc-ds1685.c, nor any drivers/rtc/ file. Ok, the rtc one was different - it's due to the objtool checks. Not related to the ISA issue. The others (the "warning: cast to pointer from integer" ones) are all due to ISA, afaik. I actually tried to find a picture of a Racal NI6510 card just to show you guys what kinds of drivers we're talking about that got enabled. I found a google books snipet from PC mag 1993 instead. That piece of old-timey engineering sold for $239 USD, and it lost in a benchmark to an ne2000 card. We're talking 10MB ethernet only, because this was before people used fast ethernet, and the competition was still often 10base2/BNC. We're talking stone-age technology. We really don't want to enable it. Linus
Re: [GIT PULL] Driver core update for 4.7-rc1
On Fri, May 20, 2016 at 10:20:19PM -0700, Linus Torvalds wrote: > On Fri, May 20, 2016 at 10:04 PM, Greg KHwrote: > > > > What warnings? I haven't seen any reports of warnings, what .config > > causes them? > > There's tons of them if you just do an allmodconfig build. > > This suddenly enables a lot of random 16-bit ISA driver crap on > x86-64, and not surprisingly it doesn't build cleanly, nor can most of > those drivers work. > > I'll just put a smattering of the warnings at the bottom, it scrolls > off the screen. > > These really are drivers that should not have been enabled. They are > legacy crap, it's not worth anybodys time to try to "fix" them, they > just shouldn't be on. > > Linus > > --- > > drivers/ide/ht6560b.c: In function ‘ht6560b_init_dev’: > drivers/ide/ht6560b.c:317:27: warning: cast to pointer from integer of > different size [-Wint-to-pointer-cast] > ide_set_drivedata(drive, (void *)t); >^ > drivers/ide/qd65xx.c: In function ‘qd6500_init_dev’: > drivers/ide/qd65xx.c:295:27: warning: cast to pointer from integer of > different size [-Wint-to-pointer-cast] > ide_set_drivedata(drive, (void *)QD6500_DEF_DATA); >^ > drivers/ide/qd65xx.c: In function ‘qd6580_init_dev’: > drivers/ide/qd65xx.c:311:27: warning: cast to pointer from integer of > different size [-Wint-to-pointer-cast] > ide_set_drivedata(drive, (void *)((drive->dn & 1) ? t2 : t1)); >^ > drivers/net/ethernet/3com/3c515.c: In function ‘corkscrew_start_xmit’: > drivers/net/ethernet/3com/3c515.c:1066:8: warning: cast from pointer > to integer of different size [-Wpointer-to-int-cast] >outl((int) (skb->data), ioaddr + Wn7_MasterAddr); > ^ > drivers/net/ethernet/amd/ni65.c: In function ‘ni65_stop_start’: > drivers/net/ethernet/amd/ni65.c:756:16: warning: cast from pointer to > integer of different size [-Wpointer-to-int-cast] > buffer[i] = (u32) isa_bus_to_virt(tmdp->u.buffer); > ^ > drivers/rtc/rtc-ds1685.o: warning: objtool: ds1685_rtc_poweroff() > falls through to next function ds1685_rtc_work_queue() > drivers/net/wan/sdla.c: In function ‘sdla_transmit’: > drivers/net/wan/sdla.c:714:13: warning: cast to pointer from integer > of different size [-Wint-to-pointer-cast] > pbuf = (void *)(((int) dev->mem_start) + (addr & SDLA_ADDR_MASK)); > ^ This is odd, I just tried this, and I don't get any error for drivers/rtc/rtc-ds1685.c, nor any drivers/rtc/ file. But I get the warning for drivers/ide/qd65xx.c, so that's not good. Yeah, just revert it for now, let's not polute the build, sorry about this. thanks, greg k-h
Re: [GIT PULL] Driver core update for 4.7-rc1
On Fri, May 20, 2016 at 10:20:19PM -0700, Linus Torvalds wrote: > On Fri, May 20, 2016 at 10:04 PM, Greg KH wrote: > > > > What warnings? I haven't seen any reports of warnings, what .config > > causes them? > > There's tons of them if you just do an allmodconfig build. > > This suddenly enables a lot of random 16-bit ISA driver crap on > x86-64, and not surprisingly it doesn't build cleanly, nor can most of > those drivers work. > > I'll just put a smattering of the warnings at the bottom, it scrolls > off the screen. > > These really are drivers that should not have been enabled. They are > legacy crap, it's not worth anybodys time to try to "fix" them, they > just shouldn't be on. > > Linus > > --- > > drivers/ide/ht6560b.c: In function ‘ht6560b_init_dev’: > drivers/ide/ht6560b.c:317:27: warning: cast to pointer from integer of > different size [-Wint-to-pointer-cast] > ide_set_drivedata(drive, (void *)t); >^ > drivers/ide/qd65xx.c: In function ‘qd6500_init_dev’: > drivers/ide/qd65xx.c:295:27: warning: cast to pointer from integer of > different size [-Wint-to-pointer-cast] > ide_set_drivedata(drive, (void *)QD6500_DEF_DATA); >^ > drivers/ide/qd65xx.c: In function ‘qd6580_init_dev’: > drivers/ide/qd65xx.c:311:27: warning: cast to pointer from integer of > different size [-Wint-to-pointer-cast] > ide_set_drivedata(drive, (void *)((drive->dn & 1) ? t2 : t1)); >^ > drivers/net/ethernet/3com/3c515.c: In function ‘corkscrew_start_xmit’: > drivers/net/ethernet/3com/3c515.c:1066:8: warning: cast from pointer > to integer of different size [-Wpointer-to-int-cast] >outl((int) (skb->data), ioaddr + Wn7_MasterAddr); > ^ > drivers/net/ethernet/amd/ni65.c: In function ‘ni65_stop_start’: > drivers/net/ethernet/amd/ni65.c:756:16: warning: cast from pointer to > integer of different size [-Wpointer-to-int-cast] > buffer[i] = (u32) isa_bus_to_virt(tmdp->u.buffer); > ^ > drivers/rtc/rtc-ds1685.o: warning: objtool: ds1685_rtc_poweroff() > falls through to next function ds1685_rtc_work_queue() > drivers/net/wan/sdla.c: In function ‘sdla_transmit’: > drivers/net/wan/sdla.c:714:13: warning: cast to pointer from integer > of different size [-Wint-to-pointer-cast] > pbuf = (void *)(((int) dev->mem_start) + (addr & SDLA_ADDR_MASK)); > ^ This is odd, I just tried this, and I don't get any error for drivers/rtc/rtc-ds1685.c, nor any drivers/rtc/ file. But I get the warning for drivers/ide/qd65xx.c, so that's not good. Yeah, just revert it for now, let's not polute the build, sorry about this. thanks, greg k-h
Re: [GIT PULL] Driver core update for 4.7-rc1
On Fri, May 20, 2016 at 10:04 PM, Greg KHwrote: > > What warnings? I haven't seen any reports of warnings, what .config > causes them? There's tons of them if you just do an allmodconfig build. This suddenly enables a lot of random 16-bit ISA driver crap on x86-64, and not surprisingly it doesn't build cleanly, nor can most of those drivers work. I'll just put a smattering of the warnings at the bottom, it scrolls off the screen. These really are drivers that should not have been enabled. They are legacy crap, it's not worth anybodys time to try to "fix" them, they just shouldn't be on. Linus --- drivers/ide/ht6560b.c: In function ‘ht6560b_init_dev’: drivers/ide/ht6560b.c:317:27: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast] ide_set_drivedata(drive, (void *)t); ^ drivers/ide/qd65xx.c: In function ‘qd6500_init_dev’: drivers/ide/qd65xx.c:295:27: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast] ide_set_drivedata(drive, (void *)QD6500_DEF_DATA); ^ drivers/ide/qd65xx.c: In function ‘qd6580_init_dev’: drivers/ide/qd65xx.c:311:27: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast] ide_set_drivedata(drive, (void *)((drive->dn & 1) ? t2 : t1)); ^ drivers/net/ethernet/3com/3c515.c: In function ‘corkscrew_start_xmit’: drivers/net/ethernet/3com/3c515.c:1066:8: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast] outl((int) (skb->data), ioaddr + Wn7_MasterAddr); ^ drivers/net/ethernet/amd/ni65.c: In function ‘ni65_stop_start’: drivers/net/ethernet/amd/ni65.c:756:16: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast] buffer[i] = (u32) isa_bus_to_virt(tmdp->u.buffer); ^ drivers/rtc/rtc-ds1685.o: warning: objtool: ds1685_rtc_poweroff() falls through to next function ds1685_rtc_work_queue() drivers/net/wan/sdla.c: In function ‘sdla_transmit’: drivers/net/wan/sdla.c:714:13: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast] pbuf = (void *)(((int) dev->mem_start) + (addr & SDLA_ADDR_MASK)); ^
Re: [GIT PULL] Driver core update for 4.7-rc1
On Fri, May 20, 2016 at 10:04 PM, Greg KH wrote: > > What warnings? I haven't seen any reports of warnings, what .config > causes them? There's tons of them if you just do an allmodconfig build. This suddenly enables a lot of random 16-bit ISA driver crap on x86-64, and not surprisingly it doesn't build cleanly, nor can most of those drivers work. I'll just put a smattering of the warnings at the bottom, it scrolls off the screen. These really are drivers that should not have been enabled. They are legacy crap, it's not worth anybodys time to try to "fix" them, they just shouldn't be on. Linus --- drivers/ide/ht6560b.c: In function ‘ht6560b_init_dev’: drivers/ide/ht6560b.c:317:27: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast] ide_set_drivedata(drive, (void *)t); ^ drivers/ide/qd65xx.c: In function ‘qd6500_init_dev’: drivers/ide/qd65xx.c:295:27: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast] ide_set_drivedata(drive, (void *)QD6500_DEF_DATA); ^ drivers/ide/qd65xx.c: In function ‘qd6580_init_dev’: drivers/ide/qd65xx.c:311:27: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast] ide_set_drivedata(drive, (void *)((drive->dn & 1) ? t2 : t1)); ^ drivers/net/ethernet/3com/3c515.c: In function ‘corkscrew_start_xmit’: drivers/net/ethernet/3com/3c515.c:1066:8: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast] outl((int) (skb->data), ioaddr + Wn7_MasterAddr); ^ drivers/net/ethernet/amd/ni65.c: In function ‘ni65_stop_start’: drivers/net/ethernet/amd/ni65.c:756:16: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast] buffer[i] = (u32) isa_bus_to_virt(tmdp->u.buffer); ^ drivers/rtc/rtc-ds1685.o: warning: objtool: ds1685_rtc_poweroff() falls through to next function ds1685_rtc_work_queue() drivers/net/wan/sdla.c: In function ‘sdla_transmit’: drivers/net/wan/sdla.c:714:13: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast] pbuf = (void *)(((int) dev->mem_start) + (addr & SDLA_ADDR_MASK)); ^
Re: [GIT PULL] Driver core update for 4.7-rc1
On Fri, May 20, 2016 at 09:51:18PM -0700, Linus Torvalds wrote: > On Fri, May 20, 2016 at 8:23 PM, Greg KHwrote: > > > > William Breathitt Gray (13): > > base: isa: Remove X86_32 dependency > > isa: Decouple X86_32 dependency from the ISA Kconfig option > > So I'm going to revert these unless I get > > (a) a good reason for them > > (b) patches to get rid of the incessant warnings these cause. What warnings? I haven't seen any reports of warnings, what .config causes them? > Most of the ISA drivers are not 64-bit safe. They give compiler > warnings, and they will definitely simply not work. So just blindly > enabling that shit is not the answer. > > We've never needed this before, why do we need it now? I'll let William answer that, it seems he has some crazy isa hardware for x86_64 platforms... thanks, greg k-h
Re: [GIT PULL] Driver core update for 4.7-rc1
On Fri, May 20, 2016 at 09:51:18PM -0700, Linus Torvalds wrote: > On Fri, May 20, 2016 at 8:23 PM, Greg KH wrote: > > > > William Breathitt Gray (13): > > base: isa: Remove X86_32 dependency > > isa: Decouple X86_32 dependency from the ISA Kconfig option > > So I'm going to revert these unless I get > > (a) a good reason for them > > (b) patches to get rid of the incessant warnings these cause. What warnings? I haven't seen any reports of warnings, what .config causes them? > Most of the ISA drivers are not 64-bit safe. They give compiler > warnings, and they will definitely simply not work. So just blindly > enabling that shit is not the answer. > > We've never needed this before, why do we need it now? I'll let William answer that, it seems he has some crazy isa hardware for x86_64 platforms... thanks, greg k-h
Re: [GIT PULL] Driver core update for 4.7-rc1
On Fri, May 20, 2016 at 8:23 PM, Greg KHwrote: > > William Breathitt Gray (13): > base: isa: Remove X86_32 dependency > isa: Decouple X86_32 dependency from the ISA Kconfig option So I'm going to revert these unless I get (a) a good reason for them (b) patches to get rid of the incessant warnings these cause. Most of the ISA drivers are not 64-bit safe. They give compiler warnings, and they will definitely simply not work. So just blindly enabling that shit is not the answer. We've never needed this before, why do we need it now? Linus
Re: [GIT PULL] Driver core update for 4.7-rc1
On Fri, May 20, 2016 at 8:23 PM, Greg KH wrote: > > William Breathitt Gray (13): > base: isa: Remove X86_32 dependency > isa: Decouple X86_32 dependency from the ISA Kconfig option So I'm going to revert these unless I get (a) a good reason for them (b) patches to get rid of the incessant warnings these cause. Most of the ISA drivers are not 64-bit safe. They give compiler warnings, and they will definitely simply not work. So just blindly enabling that shit is not the answer. We've never needed this before, why do we need it now? Linus