| Message ID | cover.1585311091.git.michal.simek@xilinx.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | powerpc: Remove support for ppc405/440 Xilinx platforms | expand |
On Fri, Mar 27, 2020 at 01:54:33PM +0100, Arnd Bergmann wrote: > On Fri, Mar 27, 2020 at 1:12 PM Michal Simek <michal.simek@xilinx.com> wrote: > > > > recently we wanted to update xilinx intc driver and we found that function > > which we wanted to remove is still wired by ancient Xilinx PowerPC > > platforms. Here is the thread about it. > > https://lore.kernel.org/linux-next/48d3232d-0f1d-42ea-3109-f44bbabfa2e8@xilinx.com/ > > > > I have been talking about it internally and there is no interest in these > > platforms and it is also orphan for quite a long time. None is really > > running/testing these platforms regularly that's why I think it makes sense > > to remove them also with drivers which are specific to this platform. > > > > U-Boot support was removed in 2017 without anybody complain about it > > https://github.com/Xilinx/u-boot-xlnx/commit/98f705c9cefdfdba62c069821bbba10273a0a8ed > > > > Based on current ppc/next. > > > > If anyone has any objection about it, please let me know. > > Acked-by: Arnd Bergmann <arnd@arndb.de> > > This looks reasonable to me as well, in particular as the code only > supports the two > ppc44x virtex developer boards and no commercial products. > > It does raise a follow-up question about ppc40x though: is it time to > retire all of it? Who knows? I have in possession nice WD My Book Live, based on this architecture, and I won't it gone from modern kernel support. OTOH I understand that amount of real users not too big. Ah, and I have Amiga board, but that one is being used only for testing, so, I don't care much. > The other ppc405 machines appear to have seen even fewer updates after the > OpenBlockS 600 got added in 2011, so it's possible nobody is using them any more > with modern kernels. > > I see that OpenWRT removed both ppc40x and ppc44x exactly a year ago after > they had not been maintained for years. > > However, 44x (in its ppc476 incarnation) is clearly still is used > through the fsp2 platform, > and can not be deprecated at least until that is known to have stopped > getting kernel > updates. > > Arnd
On Fri, Mar 27, 2020 at 03:10:26PM +0200, Andy Shevchenko wrote: > On Fri, Mar 27, 2020 at 01:54:33PM +0100, Arnd Bergmann wrote: > > On Fri, Mar 27, 2020 at 1:12 PM Michal Simek <michal.simek@xilinx.com> wrote: > > > > > > recently we wanted to update xilinx intc driver and we found that function > > > which we wanted to remove is still wired by ancient Xilinx PowerPC > > > platforms. Here is the thread about it. > > > https://lore.kernel.org/linux-next/48d3232d-0f1d-42ea-3109-f44bbabfa2e8@xilinx.com/ > > > > > > I have been talking about it internally and there is no interest in these > > > platforms and it is also orphan for quite a long time. None is really > > > running/testing these platforms regularly that's why I think it makes sense > > > to remove them also with drivers which are specific to this platform. > > > > > > U-Boot support was removed in 2017 without anybody complain about it > > > https://github.com/Xilinx/u-boot-xlnx/commit/98f705c9cefdfdba62c069821bbba10273a0a8ed > > > > > > Based on current ppc/next. > > > > > > If anyone has any objection about it, please let me know. > > > > Acked-by: Arnd Bergmann <arnd@arndb.de> > > > > This looks reasonable to me as well, in particular as the code only > > supports the two > > ppc44x virtex developer boards and no commercial products. > > > > It does raise a follow-up question about ppc40x though: is it time to > > retire all of it? > > Who knows? > > I have in possession nice WD My Book Live, based on this architecture, and I > won't it gone from modern kernel support. OTOH I understand that amount of real > users not too big. +Cc: Christian Lamparter, whom I owe for that WD box. > > Ah, and I have Amiga board, but that one is being used only for testing, so, > I don't care much. > > > The other ppc405 machines appear to have seen even fewer updates after the > > OpenBlockS 600 got added in 2011, so it's possible nobody is using them any more > > with modern kernels. > > > > I see that OpenWRT removed both ppc40x and ppc44x exactly a year ago after > > they had not been maintained for years. > > > > However, 44x (in its ppc476 incarnation) is clearly still is used > > through the fsp2 platform, > > and can not be deprecated at least until that is known to have stopped > > getting kernel > > updates. > > > > Arnd > > -- > With Best Regards, > Andy Shevchenko > >
On Fri, Mar 27, 2020 at 02:22:55PM +0100, Arnd Bergmann wrote: > On Fri, Mar 27, 2020 at 2:15 PM Andy Shevchenko > <andriy.shevchenko@linux.intel.com> wrote: > > On Fri, Mar 27, 2020 at 03:10:26PM +0200, Andy Shevchenko wrote: > > > On Fri, Mar 27, 2020 at 01:54:33PM +0100, Arnd Bergmann wrote: > > > > On Fri, Mar 27, 2020 at 1:12 PM Michal Simek <michal.simek@xilinx.com> wrote: ... > > > > It does raise a follow-up question about ppc40x though: is it time to > > > > retire all of it? > > > > > > Who knows? > > > > > > I have in possession nice WD My Book Live, based on this architecture, and I > > > won't it gone from modern kernel support. OTOH I understand that amount of real > > > users not too big. > > > > +Cc: Christian Lamparter, whom I owe for that WD box. > > According to https://openwrt.org/toh/wd/mybooklive, that one is based on > APM82181/ppc464, so it is about several generations newer than what I > asked about (ppc40x). > > > > Ah, and I have Amiga board, but that one is being used only for testing, so, > > > I don't care much. > > I think there are a couple of ppc440 based Amiga boards, but again, not 405 > to my knowledge. Ah, you are right. No objections from ppc40x removal!
Le 27/03/2020 à 15:14, Andy Shevchenko a écrit : > On Fri, Mar 27, 2020 at 02:22:55PM +0100, Arnd Bergmann wrote: >> On Fri, Mar 27, 2020 at 2:15 PM Andy Shevchenko >> <andriy.shevchenko@linux.intel.com> wrote: >>> On Fri, Mar 27, 2020 at 03:10:26PM +0200, Andy Shevchenko wrote: >>>> On Fri, Mar 27, 2020 at 01:54:33PM +0100, Arnd Bergmann wrote: >>>>> On Fri, Mar 27, 2020 at 1:12 PM Michal Simek <michal.simek@xilinx.com> wrote: > > ... > >>>>> It does raise a follow-up question about ppc40x though: is it time to >>>>> retire all of it? >>>> >>>> Who knows? >>>> >>>> I have in possession nice WD My Book Live, based on this architecture, and I >>>> won't it gone from modern kernel support. OTOH I understand that amount of real >>>> users not too big. >>> >>> +Cc: Christian Lamparter, whom I owe for that WD box. >> >> According to https://openwrt.org/toh/wd/mybooklive, that one is based on >> APM82181/ppc464, so it is about several generations newer than what I >> asked about (ppc40x). >> >>>> Ah, and I have Amiga board, but that one is being used only for testing, so, >>>> I don't care much. >> >> I think there are a couple of ppc440 based Amiga boards, but again, not 405 >> to my knowledge. > > Ah, you are right. No objections from ppc40x removal! > Removing 40x would help cleaning things a bit. For instance 40x is the last platform still having PTE_ATOMIC_UPDATES. So if we can remove 40x we can get rid of PTE_ATOMIC_UPDATES completely. If no one objects, I can prepare a series to drop support for 40x completely. Michael, any thought ? Christophe
Christophe Leroy <christophe.leroy@c-s.fr> writes: > Le 27/03/2020 à 15:14, Andy Shevchenko a écrit : >> On Fri, Mar 27, 2020 at 02:22:55PM +0100, Arnd Bergmann wrote: >>> On Fri, Mar 27, 2020 at 2:15 PM Andy Shevchenko >>> <andriy.shevchenko@linux.intel.com> wrote: >>>> On Fri, Mar 27, 2020 at 03:10:26PM +0200, Andy Shevchenko wrote: >>>>> On Fri, Mar 27, 2020 at 01:54:33PM +0100, Arnd Bergmann wrote: >>>>>> On Fri, Mar 27, 2020 at 1:12 PM Michal Simek <michal.simek@xilinx.com> wrote: >> ... >> >>>>>> It does raise a follow-up question about ppc40x though: is it time to >>>>>> retire all of it? >>>>> >>>>> Who knows? >>>>> >>>>> I have in possession nice WD My Book Live, based on this architecture, and I >>>>> won't it gone from modern kernel support. OTOH I understand that amount of real >>>>> users not too big. >>>> >>>> +Cc: Christian Lamparter, whom I owe for that WD box. >>> >>> According to https://openwrt.org/toh/wd/mybooklive, that one is based on >>> APM82181/ppc464, so it is about several generations newer than what I >>> asked about (ppc40x). >>> >>>>> Ah, and I have Amiga board, but that one is being used only for testing, so, >>>>> I don't care much. >>> >>> I think there are a couple of ppc440 based Amiga boards, but again, not 405 >>> to my knowledge. >> >> Ah, you are right. No objections from ppc40x removal! > > Removing 40x would help cleaning things a bit. For instance 40x is the > last platform still having PTE_ATOMIC_UPDATES. So if we can remove 40x > we can get rid of PTE_ATOMIC_UPDATES completely. > > If no one objects, I can prepare a series to drop support for 40x > completely. > > Michael, any thought ? I have no attachment to 40x, and I'd certainly be happy to have less code in the tree, we struggle to keep even the modern platforms well maintained. At the same time I don't want to render anyone's hardware obsolete unnecessarily. But if there's really no one using 40x then we should remove it, it could well be broken already. So I guess post a series to do the removal and we'll see if anyone speaks up. cheers
Le 31/03/2020 à 07:30, Michael Ellerman a écrit : > Christophe Leroy <christophe.leroy@c-s.fr> writes: >> Le 27/03/2020 à 15:14, Andy Shevchenko a écrit : >>> On Fri, Mar 27, 2020 at 02:22:55PM +0100, Arnd Bergmann wrote: >>>> On Fri, Mar 27, 2020 at 2:15 PM Andy Shevchenko >>>> <andriy.shevchenko@linux.intel.com> wrote: >>>>> On Fri, Mar 27, 2020 at 03:10:26PM +0200, Andy Shevchenko wrote: >>>>>> On Fri, Mar 27, 2020 at 01:54:33PM +0100, Arnd Bergmann wrote: >>>>>>> On Fri, Mar 27, 2020 at 1:12 PM Michal Simek <michal.simek@xilinx.com> wrote: >>> ... >>> >>>>>>> It does raise a follow-up question about ppc40x though: is it time to >>>>>>> retire all of it? >>>>>> >>>>>> Who knows? >>>>>> >>>>>> I have in possession nice WD My Book Live, based on this architecture, and I >>>>>> won't it gone from modern kernel support. OTOH I understand that amount of real >>>>>> users not too big. >>>>> >>>>> +Cc: Christian Lamparter, whom I owe for that WD box. >>>> >>>> According to https://openwrt.org/toh/wd/mybooklive, that one is based on >>>> APM82181/ppc464, so it is about several generations newer than what I >>>> asked about (ppc40x). >>>> >>>>>> Ah, and I have Amiga board, but that one is being used only for testing, so, >>>>>> I don't care much. >>>> >>>> I think there are a couple of ppc440 based Amiga boards, but again, not 405 >>>> to my knowledge. >>> >>> Ah, you are right. No objections from ppc40x removal! >> >> Removing 40x would help cleaning things a bit. For instance 40x is the >> last platform still having PTE_ATOMIC_UPDATES. So if we can remove 40x >> we can get rid of PTE_ATOMIC_UPDATES completely. >> >> If no one objects, I can prepare a series to drop support for 40x >> completely. >> >> Michael, any thought ? > > I have no attachment to 40x, and I'd certainly be happy to have less > code in the tree, we struggle to keep even the modern platforms well > maintained. > > At the same time I don't want to render anyone's hardware obsolete > unnecessarily. But if there's really no one using 40x then we should > remove it, it could well be broken already. > > So I guess post a series to do the removal and we'll see if anyone > speaks up. > Ok, series sent out, see https://patchwork.ozlabs.org/project/linuxppc-dev/list/?series=167757 While we are at it, can we also remove the 601 ? This one is also full of workarounds and diverges a bit from other 6xx. I'm unable to find its end of life date, but it was on the market in 1994, so I guess it must be outdated by more than 10-15 yr old now ? Christophe
On 31. 03. 20 8:56, Christophe Leroy wrote: > > > Le 31/03/2020 à 07:30, Michael Ellerman a écrit : >> Christophe Leroy <christophe.leroy@c-s.fr> writes: >>> Le 27/03/2020 à 15:14, Andy Shevchenko a écrit : >>>> On Fri, Mar 27, 2020 at 02:22:55PM +0100, Arnd Bergmann wrote: >>>>> On Fri, Mar 27, 2020 at 2:15 PM Andy Shevchenko >>>>> <andriy.shevchenko@linux.intel.com> wrote: >>>>>> On Fri, Mar 27, 2020 at 03:10:26PM +0200, Andy Shevchenko wrote: >>>>>>> On Fri, Mar 27, 2020 at 01:54:33PM +0100, Arnd Bergmann wrote: >>>>>>>> On Fri, Mar 27, 2020 at 1:12 PM Michal Simek >>>>>>>> <michal.simek@xilinx.com> wrote: >>>> ... >>>> >>>>>>>> It does raise a follow-up question about ppc40x though: is it >>>>>>>> time to >>>>>>>> retire all of it? >>>>>>> >>>>>>> Who knows? >>>>>>> >>>>>>> I have in possession nice WD My Book Live, based on this >>>>>>> architecture, and I >>>>>>> won't it gone from modern kernel support. OTOH I understand that >>>>>>> amount of real >>>>>>> users not too big. >>>>>> >>>>>> +Cc: Christian Lamparter, whom I owe for that WD box. >>>>> >>>>> According to https://openwrt.org/toh/wd/mybooklive, that one is >>>>> based on >>>>> APM82181/ppc464, so it is about several generations newer than what I >>>>> asked about (ppc40x). >>>>> >>>>>>> Ah, and I have Amiga board, but that one is being used only for >>>>>>> testing, so, >>>>>>> I don't care much. >>>>> >>>>> I think there are a couple of ppc440 based Amiga boards, but again, >>>>> not 405 >>>>> to my knowledge. >>>> >>>> Ah, you are right. No objections from ppc40x removal! >>> >>> Removing 40x would help cleaning things a bit. For instance 40x is the >>> last platform still having PTE_ATOMIC_UPDATES. So if we can remove 40x >>> we can get rid of PTE_ATOMIC_UPDATES completely. >>> >>> If no one objects, I can prepare a series to drop support for 40x >>> completely. >>> >>> Michael, any thought ? >> >> I have no attachment to 40x, and I'd certainly be happy to have less >> code in the tree, we struggle to keep even the modern platforms well >> maintained. >> >> At the same time I don't want to render anyone's hardware obsolete >> unnecessarily. But if there's really no one using 40x then we should >> remove it, it could well be broken already. >> >> So I guess post a series to do the removal and we'll see if anyone >> speaks up. >> > > Ok, series sent out, see > https://patchwork.ozlabs.org/project/linuxppc-dev/list/?series=167757 ok. I see you have done it completely independently of my patchset. Would be better if you can base it on the top of my 2 patches because they are in conflict now and I need to also remove virtex 44x platform also with alsa driver. Thanks, Michal
Le 31/03/2020 à 08:59, Michal Simek a écrit : > On 31. 03. 20 8:56, Christophe Leroy wrote: >> >> >> Le 31/03/2020 à 07:30, Michael Ellerman a écrit : >>> Christophe Leroy <christophe.leroy@c-s.fr> writes: >>>> Le 27/03/2020 à 15:14, Andy Shevchenko a écrit : >>>>> On Fri, Mar 27, 2020 at 02:22:55PM +0100, Arnd Bergmann wrote: >>>>>> On Fri, Mar 27, 2020 at 2:15 PM Andy Shevchenko >>>>>> <andriy.shevchenko@linux.intel.com> wrote: >>>>>>> On Fri, Mar 27, 2020 at 03:10:26PM +0200, Andy Shevchenko wrote: >>>>>>>> On Fri, Mar 27, 2020 at 01:54:33PM +0100, Arnd Bergmann wrote: >>>>>>>>> On Fri, Mar 27, 2020 at 1:12 PM Michal Simek >>>>>>>>> <michal.simek@xilinx.com> wrote: >>>>> ... >>>>> >>>>>>>>> It does raise a follow-up question about ppc40x though: is it >>>>>>>>> time to >>>>>>>>> retire all of it? >>>>>>>> >>>>>>>> Who knows? >>>>>>>> >>>>>>>> I have in possession nice WD My Book Live, based on this >>>>>>>> architecture, and I >>>>>>>> won't it gone from modern kernel support. OTOH I understand that >>>>>>>> amount of real >>>>>>>> users not too big. >>>>>>> >>>>>>> +Cc: Christian Lamparter, whom I owe for that WD box. >>>>>> >>>>>> According to https://openwrt.org/toh/wd/mybooklive, that one is >>>>>> based on >>>>>> APM82181/ppc464, so it is about several generations newer than what I >>>>>> asked about (ppc40x). >>>>>> >>>>>>>> Ah, and I have Amiga board, but that one is being used only for >>>>>>>> testing, so, >>>>>>>> I don't care much. >>>>>> >>>>>> I think there are a couple of ppc440 based Amiga boards, but again, >>>>>> not 405 >>>>>> to my knowledge. >>>>> >>>>> Ah, you are right. No objections from ppc40x removal! >>>> >>>> Removing 40x would help cleaning things a bit. For instance 40x is the >>>> last platform still having PTE_ATOMIC_UPDATES. So if we can remove 40x >>>> we can get rid of PTE_ATOMIC_UPDATES completely. >>>> >>>> If no one objects, I can prepare a series to drop support for 40x >>>> completely. >>>> >>>> Michael, any thought ? >>> >>> I have no attachment to 40x, and I'd certainly be happy to have less >>> code in the tree, we struggle to keep even the modern platforms well >>> maintained. >>> >>> At the same time I don't want to render anyone's hardware obsolete >>> unnecessarily. But if there's really no one using 40x then we should >>> remove it, it could well be broken already. >>> >>> So I guess post a series to do the removal and we'll see if anyone >>> speaks up. >>> >> >> Ok, series sent out, see >> https://patchwork.ozlabs.org/project/linuxppc-dev/list/?series=167757 > > ok. I see you have done it completely independently of my patchset. > Would be better if you can base it on the top of my 2 patches because > they are in conflict now and I need to also remove virtex 44x platform > also with alsa driver. > I can't see your first patch, only the second one shows up in the series, see https://patchwork.ozlabs.org/project/linuxppc-dev/list/?series=167757 Christophe
Le 31/03/2020 à 09:19, Christophe Leroy a écrit : > > > Le 31/03/2020 à 08:59, Michal Simek a écrit : >> On 31. 03. 20 8:56, Christophe Leroy wrote: >>> >>> >>> Le 31/03/2020 à 07:30, Michael Ellerman a écrit : >>>> Christophe Leroy <christophe.leroy@c-s.fr> writes: >>>>> Le 27/03/2020 à 15:14, Andy Shevchenko a écrit : >>>>>> On Fri, Mar 27, 2020 at 02:22:55PM +0100, Arnd Bergmann wrote: >>>>>>> On Fri, Mar 27, 2020 at 2:15 PM Andy Shevchenko >>>>>>> <andriy.shevchenko@linux.intel.com> wrote: >>>>>>>> On Fri, Mar 27, 2020 at 03:10:26PM +0200, Andy Shevchenko wrote: >>>>>>>>> On Fri, Mar 27, 2020 at 01:54:33PM +0100, Arnd Bergmann wrote: >>>>>>>>>> On Fri, Mar 27, 2020 at 1:12 PM Michal Simek >>>>>>>>>> <michal.simek@xilinx.com> wrote: >>>>>> ... >>>>>> >>>>>>>>>> It does raise a follow-up question about ppc40x though: is it >>>>>>>>>> time to >>>>>>>>>> retire all of it? >>>>>>>>> >>>>>>>>> Who knows? >>>>>>>>> >>>>>>>>> I have in possession nice WD My Book Live, based on this >>>>>>>>> architecture, and I >>>>>>>>> won't it gone from modern kernel support. OTOH I understand that >>>>>>>>> amount of real >>>>>>>>> users not too big. >>>>>>>> >>>>>>>> +Cc: Christian Lamparter, whom I owe for that WD box. >>>>>>> >>>>>>> According to https://openwrt.org/toh/wd/mybooklive, that one is >>>>>>> based on >>>>>>> APM82181/ppc464, so it is about several generations newer than >>>>>>> what I >>>>>>> asked about (ppc40x). >>>>>>> >>>>>>>>> Ah, and I have Amiga board, but that one is being used only for >>>>>>>>> testing, so, >>>>>>>>> I don't care much. >>>>>>> >>>>>>> I think there are a couple of ppc440 based Amiga boards, but again, >>>>>>> not 405 >>>>>>> to my knowledge. >>>>>> >>>>>> Ah, you are right. No objections from ppc40x removal! >>>>> >>>>> Removing 40x would help cleaning things a bit. For instance 40x is the >>>>> last platform still having PTE_ATOMIC_UPDATES. So if we can remove 40x >>>>> we can get rid of PTE_ATOMIC_UPDATES completely. >>>>> >>>>> If no one objects, I can prepare a series to drop support for 40x >>>>> completely. >>>>> >>>>> Michael, any thought ? >>>> >>>> I have no attachment to 40x, and I'd certainly be happy to have less >>>> code in the tree, we struggle to keep even the modern platforms well >>>> maintained. >>>> >>>> At the same time I don't want to render anyone's hardware obsolete >>>> unnecessarily. But if there's really no one using 40x then we should >>>> remove it, it could well be broken already. >>>> >>>> So I guess post a series to do the removal and we'll see if anyone >>>> speaks up. >>>> >>> >>> Ok, series sent out, see >>> https://patchwork.ozlabs.org/project/linuxppc-dev/list/?series=167757 >> >> ok. I see you have done it completely independently of my patchset. >> Would be better if you can base it on the top of my 2 patches because >> they are in conflict now and I need to also remove virtex 44x platform >> also with alsa driver. >> > > I can't see your first patch, only the second one shows up in the > series, see > https://patchwork.ozlabs.org/project/linuxppc-dev/list/?series=167757 > Ok, I found your first patch on another patchwork, it doesn't touch any file in arch/powerpc/ I sent a v2 series with your powerpc patch as patch 2/11 See https://patchwork.ozlabs.org/project/linuxppc-dev/list/?series=167766 Christophe
On 31. 03. 20 11:49, Christophe Leroy wrote: > > > Le 31/03/2020 à 09:19, Christophe Leroy a écrit : >> >> >> Le 31/03/2020 à 08:59, Michal Simek a écrit : >>> On 31. 03. 20 8:56, Christophe Leroy wrote: >>>> >>>> >>>> Le 31/03/2020 à 07:30, Michael Ellerman a écrit : >>>>> Christophe Leroy <christophe.leroy@c-s.fr> writes: >>>>>> Le 27/03/2020 à 15:14, Andy Shevchenko a écrit : >>>>>>> On Fri, Mar 27, 2020 at 02:22:55PM +0100, Arnd Bergmann wrote: >>>>>>>> On Fri, Mar 27, 2020 at 2:15 PM Andy Shevchenko >>>>>>>> <andriy.shevchenko@linux.intel.com> wrote: >>>>>>>>> On Fri, Mar 27, 2020 at 03:10:26PM +0200, Andy Shevchenko wrote: >>>>>>>>>> On Fri, Mar 27, 2020 at 01:54:33PM +0100, Arnd Bergmann wrote: >>>>>>>>>>> On Fri, Mar 27, 2020 at 1:12 PM Michal Simek >>>>>>>>>>> <michal.simek@xilinx.com> wrote: >>>>>>> ... >>>>>>> >>>>>>>>>>> It does raise a follow-up question about ppc40x though: is it >>>>>>>>>>> time to >>>>>>>>>>> retire all of it? >>>>>>>>>> >>>>>>>>>> Who knows? >>>>>>>>>> >>>>>>>>>> I have in possession nice WD My Book Live, based on this >>>>>>>>>> architecture, and I >>>>>>>>>> won't it gone from modern kernel support. OTOH I understand that >>>>>>>>>> amount of real >>>>>>>>>> users not too big. >>>>>>>>> >>>>>>>>> +Cc: Christian Lamparter, whom I owe for that WD box. >>>>>>>> >>>>>>>> According to https://openwrt.org/toh/wd/mybooklive, that one is >>>>>>>> based on >>>>>>>> APM82181/ppc464, so it is about several generations newer than >>>>>>>> what I >>>>>>>> asked about (ppc40x). >>>>>>>> >>>>>>>>>> Ah, and I have Amiga board, but that one is being used only for >>>>>>>>>> testing, so, >>>>>>>>>> I don't care much. >>>>>>>> >>>>>>>> I think there are a couple of ppc440 based Amiga boards, but again, >>>>>>>> not 405 >>>>>>>> to my knowledge. >>>>>>> >>>>>>> Ah, you are right. No objections from ppc40x removal! >>>>>> >>>>>> Removing 40x would help cleaning things a bit. For instance 40x is >>>>>> the >>>>>> last platform still having PTE_ATOMIC_UPDATES. So if we can remove >>>>>> 40x >>>>>> we can get rid of PTE_ATOMIC_UPDATES completely. >>>>>> >>>>>> If no one objects, I can prepare a series to drop support for 40x >>>>>> completely. >>>>>> >>>>>> Michael, any thought ? >>>>> >>>>> I have no attachment to 40x, and I'd certainly be happy to have less >>>>> code in the tree, we struggle to keep even the modern platforms well >>>>> maintained. >>>>> >>>>> At the same time I don't want to render anyone's hardware obsolete >>>>> unnecessarily. But if there's really no one using 40x then we should >>>>> remove it, it could well be broken already. >>>>> >>>>> So I guess post a series to do the removal and we'll see if anyone >>>>> speaks up. >>>>> >>>> >>>> Ok, series sent out, see >>>> https://patchwork.ozlabs.org/project/linuxppc-dev/list/?series=167757 >>> >>> ok. I see you have done it completely independently of my patchset. >>> Would be better if you can base it on the top of my 2 patches because >>> they are in conflict now and I need to also remove virtex 44x platform >>> also with alsa driver. >>> >> >> I can't see your first patch, only the second one shows up in the >> series, see >> https://patchwork.ozlabs.org/project/linuxppc-dev/list/?series=167757 >> > > > Ok, I found your first patch on another patchwork, it doesn't touch any > file in arch/powerpc/ There was just driver dependency on symbol which is removed by 2/2. Let's see what you get from kbuild if any symbol is removed but still used in drivers folder. > > I sent a v2 series with your powerpc patch as patch 2/11 > > See https://patchwork.ozlabs.org/project/linuxppc-dev/list/?series=167766 Thanks, Michal
Le 31/03/2020 à 12:04, Michal Simek a écrit : > On 31. 03. 20 11:49, Christophe Leroy wrote: >> >> >> Le 31/03/2020 à 09:19, Christophe Leroy a écrit : >>> >>> >>> Le 31/03/2020 à 08:59, Michal Simek a écrit : >>>> On 31. 03. 20 8:56, Christophe Leroy wrote: >>>>> >>>>> >>>>> Le 31/03/2020 à 07:30, Michael Ellerman a écrit : >>>>>> Christophe Leroy <christophe.leroy@c-s.fr> writes: >>>>>>> Le 27/03/2020 à 15:14, Andy Shevchenko a écrit : >>>>>>>> On Fri, Mar 27, 2020 at 02:22:55PM +0100, Arnd Bergmann wrote: >>>>>>>>> On Fri, Mar 27, 2020 at 2:15 PM Andy Shevchenko >>>>>>>>> <andriy.shevchenko@linux.intel.com> wrote: >>>>>>>>>> On Fri, Mar 27, 2020 at 03:10:26PM +0200, Andy Shevchenko wrote: >>>>>>>>>>> On Fri, Mar 27, 2020 at 01:54:33PM +0100, Arnd Bergmann wrote: >>>>>>>>>>>> On Fri, Mar 27, 2020 at 1:12 PM Michal Simek >>>>>>>>>>>> <michal.simek@xilinx.com> wrote: >>>>>>>> ... >>>>>>>> >>>>>>>>>>>> It does raise a follow-up question about ppc40x though: is it >>>>>>>>>>>> time to >>>>>>>>>>>> retire all of it? >>>>>>>>>>> >>>>>>>>>>> Who knows? >>>>>>>>>>> >>>>>>>>>>> I have in possession nice WD My Book Live, based on this >>>>>>>>>>> architecture, and I >>>>>>>>>>> won't it gone from modern kernel support. OTOH I understand that >>>>>>>>>>> amount of real >>>>>>>>>>> users not too big. >>>>>>>>>> >>>>>>>>>> +Cc: Christian Lamparter, whom I owe for that WD box. >>>>>>>>> >>>>>>>>> According to https://openwrt.org/toh/wd/mybooklive, that one is >>>>>>>>> based on >>>>>>>>> APM82181/ppc464, so it is about several generations newer than >>>>>>>>> what I >>>>>>>>> asked about (ppc40x). >>>>>>>>> >>>>>>>>>>> Ah, and I have Amiga board, but that one is being used only for >>>>>>>>>>> testing, so, >>>>>>>>>>> I don't care much. >>>>>>>>> >>>>>>>>> I think there are a couple of ppc440 based Amiga boards, but again, >>>>>>>>> not 405 >>>>>>>>> to my knowledge. >>>>>>>> >>>>>>>> Ah, you are right. No objections from ppc40x removal! >>>>>>> >>>>>>> Removing 40x would help cleaning things a bit. For instance 40x is >>>>>>> the >>>>>>> last platform still having PTE_ATOMIC_UPDATES. So if we can remove >>>>>>> 40x >>>>>>> we can get rid of PTE_ATOMIC_UPDATES completely. >>>>>>> >>>>>>> If no one objects, I can prepare a series to drop support for 40x >>>>>>> completely. >>>>>>> >>>>>>> Michael, any thought ? >>>>>> >>>>>> I have no attachment to 40x, and I'd certainly be happy to have less >>>>>> code in the tree, we struggle to keep even the modern platforms well >>>>>> maintained. >>>>>> >>>>>> At the same time I don't want to render anyone's hardware obsolete >>>>>> unnecessarily. But if there's really no one using 40x then we should >>>>>> remove it, it could well be broken already. >>>>>> >>>>>> So I guess post a series to do the removal and we'll see if anyone >>>>>> speaks up. >>>>>> >>>>> >>>>> Ok, series sent out, see >>>>> https://patchwork.ozlabs.org/project/linuxppc-dev/list/?series=167757 >>>> >>>> ok. I see you have done it completely independently of my patchset. >>>> Would be better if you can base it on the top of my 2 patches because >>>> they are in conflict now and I need to also remove virtex 44x platform >>>> also with alsa driver. >>>> >>> >>> I can't see your first patch, only the second one shows up in the >>> series, see >>> https://patchwork.ozlabs.org/project/linuxppc-dev/list/?series=167757 >>> >> >> >> Ok, I found your first patch on another patchwork, it doesn't touch any >> file in arch/powerpc/ > > There was just driver dependency on symbol which is removed by 2/2. > Let's see what you get from kbuild if any symbol is removed but still > used in drivers folder. Nothing bad apparently, see build test at http://kisskb.ellerman.id.au/kisskb/head/a4890e3fb046950e9a62dc3eff5b37469551e823/ Christophe
On Tue, Mar 31, 2020 at 08:56:23AM +0200, Christophe Leroy wrote: > While we are at it, can we also remove the 601 ? This one is also full > of workarounds and diverges a bit from other 6xx. > > I'm unable to find its end of life date, but it was on the market in > 1994, so I guess it must be outdated by more than 10-15 yr old now ? There probably are still some people running Linux on 601 powermacs. Segher
On Tue, Mar 31, 2020 at 7:51 PM Segher Boessenkool <segher@kernel.crashing.org> wrote: > > On Tue, Mar 31, 2020 at 08:56:23AM +0200, Christophe Leroy wrote: > > While we are at it, can we also remove the 601 ? This one is also full > > of workarounds and diverges a bit from other 6xx. > > > > I'm unable to find its end of life date, but it was on the market in > > 1994, so I guess it must be outdated by more than 10-15 yr old now ? > > There probably are still some people running Linux on 601 powermacs. It could be marked as "BROKEN" for a year to find out for sure ;-) Apparently there were only two or three models that are old enough to have a 601 and new enough to run Linux with PCI and OF: 7200/8200 and 7500. These were sold for less than 18 months around 1996, though one can still find them on eBay. Arnd
On Tue, 2020-03-31 at 16:30 +1100, Michael Ellerman wrote: > I have no attachment to 40x, and I'd certainly be happy to have less > code in the tree, we struggle to keep even the modern platforms well > maintained. > > At the same time I don't want to render anyone's hardware obsolete > unnecessarily. But if there's really no one using 40x then we should > remove it, it could well be broken already. > > So I guess post a series to do the removal and we'll see if anyone > speaks up. We shouldn't remove 40x completely. Just remove the Xilinx 405 stuff. Cheers, Ben.
On Wed, Apr 1, 2020 at 11:07 PM Arnd Bergmann <arnd@arndb.de> wrote: > > On Tue, Mar 31, 2020 at 7:51 PM Segher Boessenkool > <segher@kernel.crashing.org> wrote: > > > > On Tue, Mar 31, 2020 at 08:56:23AM +0200, Christophe Leroy wrote: > > > While we are at it, can we also remove the 601 ? This one is also full > > > of workarounds and diverges a bit from other 6xx. > > > > > > I'm unable to find its end of life date, but it was on the market in > > > 1994, so I guess it must be outdated by more than 10-15 yr old now ? > > > > There probably are still some people running Linux on 601 powermacs. > > It could be marked as "BROKEN" for a year to find out for sure ;-) > > Apparently there were only two or three models that are old enough to > have a 601 and new enough to run Linux with PCI and OF: 7200/8200 > and 7500. These were sold for less than 18 months around 1996, > though one can still find them on eBay. A. Wilcox said on IRC regarding 601 support in Adélie Linux: "right now we are primarily targeting G3, though 603 should be supported. 601/601e support is planned to be added for 2.0 (next year)." Arnd
Benjamin Herrenschmidt <benh@kernel.crashing.org> writes: > On Tue, 2020-03-31 at 16:30 +1100, Michael Ellerman wrote: >> I have no attachment to 40x, and I'd certainly be happy to have less >> code in the tree, we struggle to keep even the modern platforms well >> maintained. >> >> At the same time I don't want to render anyone's hardware obsolete >> unnecessarily. But if there's really no one using 40x then we should >> remove it, it could well be broken already. >> >> So I guess post a series to do the removal and we'll see if anyone >> speaks up. > > We shouldn't remove 40x completely. Just remove the Xilinx 405 stuff. Congratulations on becoming the 40x maintainer! cheers
On Fri, 2020-04-03 at 15:59 +1100, Michael Ellerman wrote: > Benjamin Herrenschmidt <benh@kernel.crashing.org> writes: > > On Tue, 2020-03-31 at 16:30 +1100, Michael Ellerman wrote: > > > I have no attachment to 40x, and I'd certainly be happy to have > > > less > > > code in the tree, we struggle to keep even the modern platforms > > > well > > > maintained. > > > > > > At the same time I don't want to render anyone's hardware > > > obsolete > > > unnecessarily. But if there's really no one using 40x then we > > > should > > > remove it, it could well be broken already. > > > > > > So I guess post a series to do the removal and we'll see if > > > anyone > > > speaks up. > > > > We shouldn't remove 40x completely. Just remove the Xilinx 405 > > stuff. > > Congratulations on becoming the 40x maintainer! Didn't I give you my last 40x system ? :-) IBM still put 40x cores inside POWER chips no ? Cheers, Ben.
Hi Ben, On Wed, Apr 8, 2020 at 1:34 AM Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote: > On Fri, 2020-04-03 at 15:59 +1100, Michael Ellerman wrote: > > Benjamin Herrenschmidt <benh@kernel.crashing.org> writes: > > > On Tue, 2020-03-31 at 16:30 +1100, Michael Ellerman wrote: > > > > I have no attachment to 40x, and I'd certainly be happy to have > > > > less > > > > code in the tree, we struggle to keep even the modern platforms > > > > well > > > > maintained. > > > > > > > > At the same time I don't want to render anyone's hardware > > > > obsolete > > > > unnecessarily. But if there's really no one using 40x then we > > > > should > > > > remove it, it could well be broken already. > > > > > > > > So I guess post a series to do the removal and we'll see if > > > > anyone > > > > speaks up. > > > > > > We shouldn't remove 40x completely. Just remove the Xilinx 405 > > > stuff. > > > > Congratulations on becoming the 40x maintainer! > > Didn't I give you my last 40x system ? :-) IBM still put 40x cores > inside POWER chips no ? Good to know! Are they still big-endian, or have they been corrupted by the LE frenzy, too? ;) Gr{oetje,eeting}s, Geert
Le 08/04/2020 à 01:32, Benjamin Herrenschmidt a écrit : > On Fri, 2020-04-03 at 15:59 +1100, Michael Ellerman wrote: >> Benjamin Herrenschmidt <benh@kernel.crashing.org> writes: >>> On Tue, 2020-03-31 at 16:30 +1100, Michael Ellerman wrote: >>>> I have no attachment to 40x, and I'd certainly be happy to have >>>> less >>>> code in the tree, we struggle to keep even the modern platforms >>>> well >>>> maintained. >>>> >>>> At the same time I don't want to render anyone's hardware >>>> obsolete >>>> unnecessarily. But if there's really no one using 40x then we >>>> should >>>> remove it, it could well be broken already. >>>> >>>> So I guess post a series to do the removal and we'll see if >>>> anyone >>>> speaks up. >>> >>> We shouldn't remove 40x completely. Just remove the Xilinx 405 >>> stuff. >> >> Congratulations on becoming the 40x maintainer! > > Didn't I give you my last 40x system ? :-) IBM still put 40x cores > inside POWER chips no ? > According to Wikipedia (https://en.wikipedia.org/wiki/PowerPC_400), 405 cores are used in modern equipments (how modern ?), however 403 has never reached the market. Can we start removing 403 stuff ? That's not a lot, but still. Does anybody knows anything about this ERRATUM 77 stuff ? Is that still an issue with all 405 cores or has this been fixed long time ago and can be removed ? Christophe
Benjamin Herrenschmidt <benh@kernel.crashing.org> writes: > On Fri, 2020-04-03 at 15:59 +1100, Michael Ellerman wrote: >> Benjamin Herrenschmidt <benh@kernel.crashing.org> writes: >> > On Tue, 2020-03-31 at 16:30 +1100, Michael Ellerman wrote: >> > > I have no attachment to 40x, and I'd certainly be happy to have >> > > less >> > > code in the tree, we struggle to keep even the modern platforms >> > > well >> > > maintained. >> > > >> > > At the same time I don't want to render anyone's hardware >> > > obsolete >> > > unnecessarily. But if there's really no one using 40x then we >> > > should >> > > remove it, it could well be broken already. >> > > >> > > So I guess post a series to do the removal and we'll see if >> > > anyone >> > > speaks up. >> > >> > We shouldn't remove 40x completely. Just remove the Xilinx 405 >> > stuff. >> >> Congratulations on becoming the 40x maintainer! > > Didn't I give you my last 40x system ? :-) Probably, but my desk is nearly as messy as yours so it's probably buried under some even more obscure hardware :P > IBM still put 40x cores inside POWER chips no ? Oh yeah that's true. I guess most folks don't know that, or that they run RHEL on them. cheers
+On Wed, Apr 8, 2020 at 2:04 PM Michael Ellerman <mpe@ellerman.id.au> wrote: > Benjamin Herrenschmidt <benh@kernel.crashing.org> writes: > > On Fri, 2020-04-03 at 15:59 +1100, Michael Ellerman wrote: > >> Benjamin Herrenschmidt <benh@kernel.crashing.org> writes: > > IBM still put 40x cores inside POWER chips no ? > > Oh yeah that's true. I guess most folks don't know that, or that they > run RHEL on them. Is there a reason for not having those dts files in mainline then? If nothing else, it would document what machines are still being used with future kernels. Also, if that's the only 405 based product that is still relevant with a 5.7+ kernel, it may be useful to know at which point they move to a 476 core and stop updating kernels on the old ones. Arnd
Arnd Bergmann <arnd@arndb.de> writes: > +On Wed, Apr 8, 2020 at 2:04 PM Michael Ellerman <mpe@ellerman.id.au> wrote: >> Benjamin Herrenschmidt <benh@kernel.crashing.org> writes: >> > On Fri, 2020-04-03 at 15:59 +1100, Michael Ellerman wrote: >> >> Benjamin Herrenschmidt <benh@kernel.crashing.org> writes: >> > IBM still put 40x cores inside POWER chips no ? >> >> Oh yeah that's true. I guess most folks don't know that, or that they >> run RHEL on them. > > Is there a reason for not having those dts files in mainline then? > If nothing else, it would document what machines are still being > used with future kernels. Sorry that part was a joke :D Those chips don't run Linux. cheers
Le 21/05/2020 à 09:02, Michael Ellerman a écrit : > Arnd Bergmann <arnd@arndb.de> writes: >> +On Wed, Apr 8, 2020 at 2:04 PM Michael Ellerman <mpe@ellerman.id.au> wrote: >>> Benjamin Herrenschmidt <benh@kernel.crashing.org> writes: >>>> On Fri, 2020-04-03 at 15:59 +1100, Michael Ellerman wrote: >>>>> Benjamin Herrenschmidt <benh@kernel.crashing.org> writes: >>>> IBM still put 40x cores inside POWER chips no ? >>> >>> Oh yeah that's true. I guess most folks don't know that, or that they >>> run RHEL on them. >> >> Is there a reason for not having those dts files in mainline then? >> If nothing else, it would document what machines are still being >> used with future kernels. > > Sorry that part was a joke :D Those chips don't run Linux. > Nice to know :) What's the plan then, do we still want to keep 40x in the kernel ? If yes, is it ok to drop the oldies anyway as done in my series https://patchwork.ozlabs.org/project/linuxppc-dev/list/?series=172630 ? (Note that this series will conflict with my series on hugepages on 8xx due to the PTE_ATOMIC_UPDATES stuff. I can rebase the 40x modernisation series on top of the 8xx hugepages series if it is worth it) Christophe
Christophe Leroy <christophe.leroy@csgroup.eu> writes: > Le 21/05/2020 à 09:02, Michael Ellerman a écrit : >> Arnd Bergmann <arnd@arndb.de> writes: >>> +On Wed, Apr 8, 2020 at 2:04 PM Michael Ellerman <mpe@ellerman.id.au> wrote: >>>> Benjamin Herrenschmidt <benh@kernel.crashing.org> writes: >>>>> On Fri, 2020-04-03 at 15:59 +1100, Michael Ellerman wrote: >>>>>> Benjamin Herrenschmidt <benh@kernel.crashing.org> writes: >>>>> IBM still put 40x cores inside POWER chips no ? >>>> >>>> Oh yeah that's true. I guess most folks don't know that, or that they >>>> run RHEL on them. >>> >>> Is there a reason for not having those dts files in mainline then? >>> If nothing else, it would document what machines are still being >>> used with future kernels. >> >> Sorry that part was a joke :D Those chips don't run Linux. >> > > Nice to know :) > > What's the plan then, do we still want to keep 40x in the kernel ? I guess we keep it for now. Perhaps we mark it BROKEN for a few releases and see if anyone complains? > If yes, is it ok to drop the oldies anyway as done in my series > https://patchwork.ozlabs.org/project/linuxppc-dev/list/?series=172630 ? Yeah let's do it. I would love to get rid of that horrible PPC405_ERR77() sprinkled all through our atomics. > (Note that this series will conflict with my series on hugepages on 8xx > due to the PTE_ATOMIC_UPDATES stuff. I can rebase the 40x modernisation > series on top of the 8xx hugepages series if it is worth it) Yeah if you can rebase that would be great. cheers
On 21. 05. 20 15:53, Michael Ellerman wrote: > Christophe Leroy <christophe.leroy@csgroup.eu> writes: >> Le 21/05/2020 à 09:02, Michael Ellerman a écrit : >>> Arnd Bergmann <arnd@arndb.de> writes: >>>> +On Wed, Apr 8, 2020 at 2:04 PM Michael Ellerman <mpe@ellerman.id.au> wrote: >>>>> Benjamin Herrenschmidt <benh@kernel.crashing.org> writes: >>>>>> On Fri, 2020-04-03 at 15:59 +1100, Michael Ellerman wrote: >>>>>>> Benjamin Herrenschmidt <benh@kernel.crashing.org> writes: >>>>>> IBM still put 40x cores inside POWER chips no ? >>>>> >>>>> Oh yeah that's true. I guess most folks don't know that, or that they >>>>> run RHEL on them. >>>> >>>> Is there a reason for not having those dts files in mainline then? >>>> If nothing else, it would document what machines are still being >>>> used with future kernels. >>> >>> Sorry that part was a joke :D Those chips don't run Linux. >>> >> >> Nice to know :) >> >> What's the plan then, do we still want to keep 40x in the kernel ? > > I guess we keep it for now. > > Perhaps we mark it BROKEN for a few releases and see if anyone > complains? I would like to get at least that xilinx patch to the tree to unblock our changes on interrupt controller. Thanks, Michal
Le 21/05/2020 à 12:38, Christophe Leroy a écrit : > > > Le 21/05/2020 à 09:02, Michael Ellerman a écrit : >> Arnd Bergmann <arnd@arndb.de> writes: >>> +On Wed, Apr 8, 2020 at 2:04 PM Michael Ellerman <mpe@ellerman.id.au> wrote: >>>> Benjamin Herrenschmidt <benh@kernel.crashing.org> writes: >>>>> On Fri, 2020-04-03 at 15:59 +1100, Michael Ellerman wrote: >>>>>> Benjamin Herrenschmidt <benh@kernel.crashing.org> writes: >>>>> IBM still put 40x cores inside POWER chips no ? >>>> >>>> Oh yeah that's true. I guess most folks don't know that, or that they >>>> run RHEL on them. >>> >>> Is there a reason for not having those dts files in mainline then? >>> If nothing else, it would document what machines are still being >>> used with future kernels. >> >> Sorry that part was a joke :D Those chips don't run Linux. >> > > Nice to know :) > > What's the plan then, do we still want to keep 40x in the kernel ? > > If yes, is it ok to drop the oldies anyway as done in my series > https://patchwork.ozlabs.org/project/linuxppc-dev/list/?series=172630 ? > > (Note that this series will conflict with my series on hugepages on 8xx due to the > PTE_ATOMIC_UPDATES stuff. I can rebase the 40x modernisation series on top of the 8xx hugepages > series if it is worth it) > Do we still want to keep 40x in the kernel ? We don't even have a running 40x QEMU machine as far as I know. I'm asking because I'd like to drop the non CONFIG_VMAP_STACK code to simplify and ease stuff (code that works with vmalloc'ed stacks also works with stacks in linear memory), but I can't do it because 40x doesn't have VMAP_STACK and should I implement it for 40x, I have to means to test it. So it would ease things if we could drop 40x completely, unless someone there has a 40x platform to test stuff. Thanks Christophe