| Message ID | 20230314121216.413434-16-schnelle@linux.ibm.com (mailing list archive) |
|---|---|
| State | Handled Elsewhere |
| Headers | show |
| Series | Kconfig: Introduce HAS_IOPORT config option | expand |
On Tue, 14 Mar 2023, Niklas Schnelle wrote: > In a future patch HAS_IOPORT=n will result in inb()/outb() and friends > not being declared. We thus need to add HAS_IOPORT as dependency for > those drivers using them. > > Acked-by: Pavel Machek <pavel@ucw.cz> > Co-developed-by: Arnd Bergmann <arnd@kernel.org> > Signed-off-by: Niklas Schnelle <schnelle@linux.ibm.com> > --- > drivers/leds/Kconfig | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) Applied, thanks -- Lee Jones [李琼斯]
On Thu, 2023-03-16 at 16:14 +0000, Lee Jones wrote: > On Tue, 14 Mar 2023, Niklas Schnelle wrote: > > > In a future patch HAS_IOPORT=n will result in inb()/outb() and friends > > not being declared. We thus need to add HAS_IOPORT as dependency for > > those drivers using them. > > > > Acked-by: Pavel Machek <pavel@ucw.cz> > > Co-developed-by: Arnd Bergmann <arnd@kernel.org> > > Signed-off-by: Niklas Schnelle <schnelle@linux.ibm.com> > > --- > > drivers/leds/Kconfig | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > Applied, thanks Sorry should have maybe been more clear, without patch 1 of this series this won't work as the HAS_IOPORT config option is new and will be missing otherwise. There's currently two options of merging this, either all at once or first only patch 1 and then the additional patches per subsystem until finally the last patch can remove inb()/outb() and friends when HAS_IOPORT is unset. Thanks, Niklas
On Thu, Mar 23, 2023, at 13:42, Niklas Schnelle wrote: > On Thu, 2023-03-16 at 16:14 +0000, Lee Jones wrote: >> On Tue, 14 Mar 2023, Niklas Schnelle wrote: >> >> > In a future patch HAS_IOPORT=n will result in inb()/outb() and friends >> > not being declared. We thus need to add HAS_IOPORT as dependency for >> > those drivers using them. >> > >> > Acked-by: Pavel Machek <pavel@ucw.cz> >> > Co-developed-by: Arnd Bergmann <arnd@kernel.org> >> > Signed-off-by: Niklas Schnelle <schnelle@linux.ibm.com> >> > --- >> > drivers/leds/Kconfig | 2 +- >> > 1 file changed, 1 insertion(+), 1 deletion(-) >> >> Applied, thanks > > Sorry should have maybe been more clear, without patch 1 of this series > this won't work as the HAS_IOPORT config option is new and will be > missing otherwise. There's currently two options of merging this, > either all at once or first only patch 1 and then the additional > patches per subsystem until finally the last patch can remove > inb()/outb() and friends when HAS_IOPORT is unset. It's probably too late now to squeeze patch 1 into linux-6.3 as a late preparation patch for the rest of the series in 6.4. It would be good if you could respin that patch separately anyway, so I can add it to the asm-generic tree and make sure we get it ready for the next merge window. Arnd
On Thu, 2023-03-23 at 14:32 +0100, Arnd Bergmann wrote: > On Thu, Mar 23, 2023, at 13:42, Niklas Schnelle wrote: > > On Thu, 2023-03-16 at 16:14 +0000, Lee Jones wrote: > > > On Tue, 14 Mar 2023, Niklas Schnelle wrote: > > > > > > > In a future patch HAS_IOPORT=n will result in inb()/outb() and friends > > > > not being declared. We thus need to add HAS_IOPORT as dependency for > > > > those drivers using them. > > > > > > > > Acked-by: Pavel Machek <pavel@ucw.cz> > > > > Co-developed-by: Arnd Bergmann <arnd@kernel.org> > > > > Signed-off-by: Niklas Schnelle <schnelle@linux.ibm.com> > > > > --- > > > > drivers/leds/Kconfig | 2 +- > > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > > Applied, thanks > > > > Sorry should have maybe been more clear, without patch 1 of this series > > this won't work as the HAS_IOPORT config option is new and will be > > missing otherwise. There's currently two options of merging this, > > either all at once or first only patch 1 and then the additional > > patches per subsystem until finally the last patch can remove > > inb()/outb() and friends when HAS_IOPORT is unset. > > It's probably too late now to squeeze patch 1 into linux-6.3 > as a late preparation patch for the rest of the series in 6.4. > > It would be good if you could respin that patch separately > anyway, so I can add it to the asm-generic tree and make > sure we get it ready for the next merge window. > > Arnd Yes, sorry I was traveling Thursday to Monday and then spent some time catching up and investigating an internal issue. I'm currently going through the patches one by one incorporating comments. I fear the split of the USB patch as well as the suggestions for video might take a bit of time, so if you prefer I could also send just an updated patch 1 separately. How would I do this cleanly? Send as v4 without(?) a cover letter and add a Note after the '---'? Thanks, Niklas
On Thu, Mar 23, 2023, at 15:02, Niklas Schnelle wrote: > On Thu, 2023-03-23 at 14:32 +0100, Arnd Bergmann wrote: >> On Thu, Mar 23, 2023, at 13:42, Niklas Schnelle wrote: >> > On Thu, 2023-03-16 at 16:14 +0000, Lee Jones wrote: >> > > On Tue, 14 Mar 2023, Niklas Schnelle wrote: > Yes, sorry I was traveling Thursday to Monday and then spent some time > catching up and investigating an internal issue. I'm currently going > through the patches one by one incorporating comments. I fear the split > of the USB patch as well as the suggestions for video might take a bit > of time, so if you prefer I could also send just an updated patch 1 > separately. How would I do this cleanly? Send as v4 without(?) a cover > letter and add a Note after the '---'? Yes, that sounds good to me. In case you need multiple versions, I would suggest you continue counting at v4 independently for both the preparation patch and the rest of the series. Arnd
On Thu, 23 Mar 2023, Niklas Schnelle wrote: > On Thu, 2023-03-16 at 16:14 +0000, Lee Jones wrote: > > On Tue, 14 Mar 2023, Niklas Schnelle wrote: > > > > > In a future patch HAS_IOPORT=n will result in inb()/outb() and friends > > > not being declared. We thus need to add HAS_IOPORT as dependency for > > > those drivers using them. > > > > > > Acked-by: Pavel Machek <pavel@ucw.cz> > > > Co-developed-by: Arnd Bergmann <arnd@kernel.org> > > > Signed-off-by: Niklas Schnelle <schnelle@linux.ibm.com> > > > --- > > > drivers/leds/Kconfig | 2 +- > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > Applied, thanks > > Sorry should have maybe been more clear, without patch 1 of this series > this won't work as the HAS_IOPORT config option is new and will be > missing otherwise. There's currently two options of merging this, > either all at once or first only patch 1 and then the additional > patches per subsystem until finally the last patch can remove > inb()/outb() and friends when HAS_IOPORT is unset. You only sent me this patch. If there are in-set dependencies, you need to send everyone the whole set so that we can organise a suitable merge strategy between us. I'll revert the patch for now. -- Lee Jones [李琼斯]
On Thu, 2023-03-23 at 14:53 +0000, Lee Jones wrote: > On Thu, 23 Mar 2023, Niklas Schnelle wrote: > > > On Thu, 2023-03-16 at 16:14 +0000, Lee Jones wrote: > > > On Tue, 14 Mar 2023, Niklas Schnelle wrote: > > > > > > > In a future patch HAS_IOPORT=n will result in inb()/outb() and friends > > > > not being declared. We thus need to add HAS_IOPORT as dependency for > > > > those drivers using them. > > > > > > > > Acked-by: Pavel Machek <pavel@ucw.cz> > > > > Co-developed-by: Arnd Bergmann <arnd@kernel.org> > > > > Signed-off-by: Niklas Schnelle <schnelle@linux.ibm.com> > > > > --- > > > > drivers/leds/Kconfig | 2 +- > > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > > Applied, thanks > > > > Sorry should have maybe been more clear, without patch 1 of this series > > this won't work as the HAS_IOPORT config option is new and will be > > missing otherwise. There's currently two options of merging this, > > either all at once or first only patch 1 and then the additional > > patches per subsystem until finally the last patch can remove > > inb()/outb() and friends when HAS_IOPORT is unset. > > You only sent me this patch. > > If there are in-set dependencies, you need to send everyone the whole > set so that we can organise a suitable merge strategy between us. > > I'll revert the patch for now. > > -- > Lee Jones [李琼斯] I know this isn't ideal and I'm sorry for the confusion, extra work and churn. As far as I know sadly it's not possible to Cc everyone for such treewide series because the recipient list will hit the limits supported by some systems and mails get dropped which sucks even more. Maybe this can be solved in the future though, Konstantin Ryabitsev actually reached out because I mentioned that I tried using b4 prep / b4 send but couldn't exactly because it only supports a global recipient list. Thanks, Niklas
Hi Arnd, On Thu, Mar 23, 2023 at 2:32 PM Arnd Bergmann <arnd@arndb.de> wrote: > On Thu, Mar 23, 2023, at 13:42, Niklas Schnelle wrote: > > On Thu, 2023-03-16 at 16:14 +0000, Lee Jones wrote: > >> On Tue, 14 Mar 2023, Niklas Schnelle wrote: > >> > >> > In a future patch HAS_IOPORT=n will result in inb()/outb() and friends > >> > not being declared. We thus need to add HAS_IOPORT as dependency for > >> > those drivers using them. > >> > > >> > Acked-by: Pavel Machek <pavel@ucw.cz> > >> > Co-developed-by: Arnd Bergmann <arnd@kernel.org> > >> > Signed-off-by: Niklas Schnelle <schnelle@linux.ibm.com> > >> > --- > >> > drivers/leds/Kconfig | 2 +- > >> > 1 file changed, 1 insertion(+), 1 deletion(-) > >> > >> Applied, thanks > > > > Sorry should have maybe been more clear, without patch 1 of this series > > this won't work as the HAS_IOPORT config option is new and will be > > missing otherwise. There's currently two options of merging this, > > either all at once or first only patch 1 and then the additional > > patches per subsystem until finally the last patch can remove > > inb()/outb() and friends when HAS_IOPORT is unset. > > It's probably too late now to squeeze patch 1 into linux-6.3 > as a late preparation patch for the rest of the series in 6.4. > > It would be good if you could respin that patch separately > anyway, so I can add it to the asm-generic tree and make > sure we get it ready for the next merge window. Through an immutable branch, else all dependencies have to wait for v6.5? Gr{oetje,eeting}s, Geert
On Thu, Mar 23, 2023, at 17:11, Geert Uytterhoeven wrote: > On Thu, Mar 23, 2023 at 2:32 PM Arnd Bergmann <arnd@arndb.de> wrote: >> On Thu, Mar 23, 2023, at 13:42, Niklas Schnelle wrote: > > Through an immutable branch, else all dependencies have to wait > for v6.5? Sure, will do. I suspect that there will still be something left behind that doesn't make it into 6.4, so the final bit (dropping broken inb/outb implementations) will have to be 6.5 material anyway, but at least we can aim on getting most of it into 6.4. Arnd
diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig index 9dbce09eabac..55b4a4de8f1a 100644 --- a/drivers/leds/Kconfig +++ b/drivers/leds/Kconfig @@ -662,7 +662,7 @@ config LEDS_LM355x config LEDS_OT200 tristate "LED support for the Bachmann OT200" - depends on LEDS_CLASS && HAS_IOMEM && (X86_32 || COMPILE_TEST) + depends on LEDS_CLASS && HAS_IOPORT && (X86_32 || COMPILE_TEST) help This option enables support for the LEDs on the Bachmann OT200. Say Y to enable LEDs on the Bachmann OT200.