| Message ID | 1467991490-24895-1-git-send-email-b.zolnierkie@samsung.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Friday, July 8, 2016 5:24:41 PM CEST Bartlomiej Zolnierkiewicz wrote: > This patch disables deprecated IDE subsystem in assabet_defconfig > (no IDE host drivers are selected in this config so there is no > valid reason to enable IDE subsystem itself). > > Cc: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com> > Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> I think the series makes a lot of sense. I have checked your assertions in the changelogs and found no flaws in your logic, so I think we should take them all through arm-soc unless there are other concerns. Do you have a list of ARM defconfigs that keep using CONFIG_IDE and how you determined that they need it? I know that ARCH_RPC/ARCH_ACORN has a couple of special drivers that have no libata replacement, are there any others like that, or are they all platforms that should in theory work with libata but need testing? Arnd
Hi, On Friday, July 08, 2016 10:23:48 PM Arnd Bergmann wrote: > On Friday, July 8, 2016 5:24:41 PM CEST Bartlomiej Zolnierkiewicz wrote: > > This patch disables deprecated IDE subsystem in assabet_defconfig > > (no IDE host drivers are selected in this config so there is no > > valid reason to enable IDE subsystem itself). > > > > Cc: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com> > > Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> > > I think the series makes a lot of sense. I have checked your assertions > in the changelogs and found no flaws in your logic, so I think we should > take them all through arm-soc unless there are other concerns. Thank you. Should I resend everything or just patches that were not reposted yet (the ones that were marked as RFT initially and got no feedback)? > Do you have a list of ARM defconfigs that keep using CONFIG_IDE and > how you determined that they need it? The only such defconfig is davinci_all_defconfig which uses palm_bk3710 host driver (CONFIG_BLK_DEV_PALMCHIP_BK3710). > I know that ARCH_RPC/ARCH_ACORN has a couple of special drivers that > have no libata replacement, are there any others like that, or are > they all platforms that should in theory work with libata but need > testing? All platforms except ARCH_ACORN, ARCH_DAVINCI & ARCH_RPC should work with libata. Best regards, -- Bartlomiej Zolnierkiewicz Samsung R&D Institute Poland Samsung Electronics
On Wednesday, July 13, 2016 12:59:23 PM CEST Bartlomiej Zolnierkiewicz wrote: > > On Friday, July 08, 2016 10:23:48 PM Arnd Bergmann wrote: > > On Friday, July 8, 2016 5:24:41 PM CEST Bartlomiej Zolnierkiewicz wrote: > > > This patch disables deprecated IDE subsystem in assabet_defconfig > > > (no IDE host drivers are selected in this config so there is no > > > valid reason to enable IDE subsystem itself). > > > > > > Cc: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com> > > > Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> > > > > I think the series makes a lot of sense. I have checked your assertions > > in the changelogs and found no flaws in your logic, so I think we should > > take them all through arm-soc unless there are other concerns. > > Thank you. > > Should I resend everything or just patches that were not reposted yet > (the ones that were marked as RFT initially and got no feedback)? I'd be fine with just getting a pull request with all the patches that had no negative feedback and that were not already applied (if any). > > Do you have a list of ARM defconfigs that keep using CONFIG_IDE and > > how you determined that they need it? > > The only such defconfig is davinci_all_defconfig which uses > palm_bk3710 host driver (CONFIG_BLK_DEV_PALMCHIP_BK3710). > > > I know that ARCH_RPC/ARCH_ACORN has a couple of special drivers that > > have no libata replacement, are there any others like that, or are > > they all platforms that should in theory work with libata but need > > testing? > > All platforms except ARCH_ACORN, ARCH_DAVINCI & ARCH_RPC should work > with libata. Adding Sekhar and Kevin for DaVinci: At first sight, palm_bk3710 looks fairly straightforward (meaning someone has to do a few day's work) to convert into a libata driver. As this is on on-chip controller that is part of a dm644x and dm646x, it should also not be hard to test (as long as someone can find a hard drive to plug in). Arnd
On Wed, Jul 13, 2016 at 04:37:31PM +0200, Arnd Bergmann wrote: > On Wednesday, July 13, 2016 12:59:23 PM CEST Bartlomiej Zolnierkiewicz wrote: > > > > On Friday, July 08, 2016 10:23:48 PM Arnd Bergmann wrote: > > > On Friday, July 8, 2016 5:24:41 PM CEST Bartlomiej Zolnierkiewicz wrote: > > > > This patch disables deprecated IDE subsystem in assabet_defconfig > > > > (no IDE host drivers are selected in this config so there is no > > > > valid reason to enable IDE subsystem itself). > > > > > > > > Cc: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com> > > > > Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> > > > > > > I think the series makes a lot of sense. I have checked your assertions > > > in the changelogs and found no flaws in your logic, so I think we should > > > take them all through arm-soc unless there are other concerns. > > > > Thank you. > > > > Should I resend everything or just patches that were not reposted yet > > (the ones that were marked as RFT initially and got no feedback)? > > I'd be fine with just getting a pull request with all the patches that > had no negative feedback and that were not already applied (if any). I'd actually say be very careful about this - there's a big difference between the ATA subsystem and IDE subsystem. I've had situations with old platforms where stuff works with IDE and not ATA. For example, using the CY82C693 driver used to work with the IDE subsystem before it got broken on ARM systems with DMA disabled (because the CY82C693 deadlocks the PCI bus on any BM-DMA). From what I remember, ATA provided no easy way to disable DMA on such interfaces. I also looked at using ATA on EBSA110, and it was far from trivial due to munged address lines and access size problems: with IDE, it was easy to work around by redirecting the in*/out* appropriately on a per-driver basis. I forget exactly why ATA didn't work, but it didn't and I came to the conclusion that it was not feasible to fix. So, please don't assume that ATA can be simply slotted in instead of IDE.
Hi, On Wednesday, July 13, 2016 06:45:12 PM Russell King - ARM Linux wrote: > On Wed, Jul 13, 2016 at 04:37:31PM +0200, Arnd Bergmann wrote: > > On Wednesday, July 13, 2016 12:59:23 PM CEST Bartlomiej Zolnierkiewicz wrote: > > > > > > On Friday, July 08, 2016 10:23:48 PM Arnd Bergmann wrote: > > > > On Friday, July 8, 2016 5:24:41 PM CEST Bartlomiej Zolnierkiewicz wrote: > > > > > This patch disables deprecated IDE subsystem in assabet_defconfig > > > > > (no IDE host drivers are selected in this config so there is no > > > > > valid reason to enable IDE subsystem itself). > > > > > > > > > > Cc: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com> > > > > > Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> > > > > > > > > I think the series makes a lot of sense. I have checked your assertions > > > > in the changelogs and found no flaws in your logic, so I think we should > > > > take them all through arm-soc unless there are other concerns. > > > > > > Thank you. > > > > > > Should I resend everything or just patches that were not reposted yet > > > (the ones that were marked as RFT initially and got no feedback)? > > > > I'd be fine with just getting a pull request with all the patches that > > had no negative feedback and that were not already applied (if any). > > I'd actually say be very careful about this - there's a big difference > between the ATA subsystem and IDE subsystem. I've had situations with > old platforms where stuff works with IDE and not ATA. > > For example, using the CY82C693 driver used to work with the IDE > subsystem before it got broken on ARM systems with DMA disabled (because > the CY82C693 deadlocks the PCI bus on any BM-DMA). From what I remember, > ATA provided no easy way to disable DMA on such interfaces. You can do this using libata.dma kernel parameter: libata.dma= [LIBATA] DMA control libata.dma=0 Disable all PATA and SATA DMA libata.dma=1 PATA and SATA Disk DMA only libata.dma=2 ATAPI (CDROM) DMA only libata.dma=4 Compact Flash DMA only Combinations also work, so libata.dma=3 enables DMA for disks and CDROMs, but not CFs. Or even force specific speed for chosen device using libata.force kernel parameter: libata.force= [LIBATA] Force configurations. The format is comma separated list of "[ID:]VAL" where ID is PORT[.DEVICE]. PORT and DEVICE are decimal numbers matching port, link or device. Basically, it matches the ATA ID string printed on console by libata. If the whole ID part is omitted, the last PORT and DEVICE values are used. If ID hasn't been specified yet, the configuration applies to all ports, links and devices. If only DEVICE is omitted, the parameter applies to the port and all links and devices behind it. DEVICE number of 0 either selects the first device or the first fan-out link behind PMP device. It does not select the host link. DEVICE number of 15 selects the host link and device attached to it. The VAL specifies the configuration to force. As long as there's no ambiguity shortcut notation is allowed. For example, both 1.5 and 1.5G would work for 1.5Gbps. The following configurations can be forced. ... * Transfer mode: pio[0-7], mwdma[0-4] and udma[0-7]. udma[/][16,25,33,44,66,100,133] notation is also allowed. ... However it would be the best to detect affected platforms from ATA host driver and not enable DMA on them automatically (same is true for IDE subsystem host driver equivalent). > I also looked at using ATA on EBSA110, and it was far from trivial due > to munged address lines and access size problems: with IDE, it was > easy to work around by redirecting the in*/out* appropriately on a > per-driver basis. I forget exactly why ATA didn't work, but it didn't > and I came to the conclusion that it was not feasible to fix. You can define your own transport helpers in ATA subsystem (same is true for IDE subsystem BTW) hacking in*()/out*() helpers is not how it should be done. Please just post patches / questions and I would be glad to help with making ATA subsystem work on hardware that is currently limited to IDE subsystem. [ BTW from looking at examples given it seems that they don't work even with IDE subsystem nowadays. ] > So, please don't assume that ATA can be simply slotted in instead of > IDE. I don't assume it. Each case was reviewed separately and I replaced only that host drivers in defconfigs that looked OK after doing full code comparison between IDE and ATA versions. If you know about specific cases that won't work after my patches please let me know. Best regards, -- Bartlomiej Zolnierkiewicz Samsung R&D Institute Poland Samsung Electronics
Arnd Bergmann <arnd@arndb.de> writes: > On Wednesday, July 13, 2016 12:59:23 PM CEST Bartlomiej Zolnierkiewicz wrote: >> >> On Friday, July 08, 2016 10:23:48 PM Arnd Bergmann wrote: >> > On Friday, July 8, 2016 5:24:41 PM CEST Bartlomiej Zolnierkiewicz wrote: >> > > This patch disables deprecated IDE subsystem in assabet_defconfig >> > > (no IDE host drivers are selected in this config so there is no >> > > valid reason to enable IDE subsystem itself). >> > > >> > > Cc: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com> >> > > Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> >> > >> > I think the series makes a lot of sense. I have checked your assertions >> > in the changelogs and found no flaws in your logic, so I think we should >> > take them all through arm-soc unless there are other concerns. >> >> Thank you. >> >> Should I resend everything or just patches that were not reposted yet >> (the ones that were marked as RFT initially and got no feedback)? > > I'd be fine with just getting a pull request with all the patches that > had no negative feedback and that were not already applied (if any). > >> > Do you have a list of ARM defconfigs that keep using CONFIG_IDE and >> > how you determined that they need it? >> >> The only such defconfig is davinci_all_defconfig which uses >> palm_bk3710 host driver (CONFIG_BLK_DEV_PALMCHIP_BK3710). >> >> > I know that ARCH_RPC/ARCH_ACORN has a couple of special drivers that >> > have no libata replacement, are there any others like that, or are >> > they all platforms that should in theory work with libata but need >> > testing? >> >> All platforms except ARCH_ACORN, ARCH_DAVINCI & ARCH_RPC should work >> with libata. > > Adding Sekhar and Kevin for DaVinci: At first sight, palm_bk3710 looks > fairly straightforward (meaning someone has to do a few day's work) > to convert into a libata driver. > > As this is on on-chip controller that is part of a dm644x and dm646x, > it should also not be hard to test (as long as someone can find > a hard drive to plug in). I have a hard drive, but don't have any dm64xx hardware anymore to test this. My last working dm644x board died last year. Kevin
On Friday 15 July 2016 08:45 PM, Kevin Hilman wrote: > Arnd Bergmann <arnd@arndb.de> writes: > >> On Wednesday, July 13, 2016 12:59:23 PM CEST Bartlomiej Zolnierkiewicz wrote: >>> >>> On Friday, July 08, 2016 10:23:48 PM Arnd Bergmann wrote: >>>> On Friday, July 8, 2016 5:24:41 PM CEST Bartlomiej Zolnierkiewicz wrote: >>>>> This patch disables deprecated IDE subsystem in assabet_defconfig >>>>> (no IDE host drivers are selected in this config so there is no >>>>> valid reason to enable IDE subsystem itself). >>>>> >>>>> Cc: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com> >>>>> Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> >>>> >>>> I think the series makes a lot of sense. I have checked your assertions >>>> in the changelogs and found no flaws in your logic, so I think we should >>>> take them all through arm-soc unless there are other concerns. >>> >>> Thank you. >>> >>> Should I resend everything or just patches that were not reposted yet >>> (the ones that were marked as RFT initially and got no feedback)? >> >> I'd be fine with just getting a pull request with all the patches that >> had no negative feedback and that were not already applied (if any). >> >>>> Do you have a list of ARM defconfigs that keep using CONFIG_IDE and >>>> how you determined that they need it? >>> >>> The only such defconfig is davinci_all_defconfig which uses >>> palm_bk3710 host driver (CONFIG_BLK_DEV_PALMCHIP_BK3710). >>> >>>> I know that ARCH_RPC/ARCH_ACORN has a couple of special drivers that >>>> have no libata replacement, are there any others like that, or are >>>> they all platforms that should in theory work with libata but need >>>> testing? >>> >>> All platforms except ARCH_ACORN, ARCH_DAVINCI & ARCH_RPC should work >>> with libata. >> >> Adding Sekhar and Kevin for DaVinci: At first sight, palm_bk3710 looks >> fairly straightforward (meaning someone has to do a few day's work) >> to convert into a libata driver. >> >> As this is on on-chip controller that is part of a dm644x and dm646x, >> it should also not be hard to test (as long as someone can find >> a hard drive to plug in). > > I have a hard drive, but don't have any dm64xx hardware anymore to test > this. My last working dm644x board died last year. I have a working DM6446 EVM. I was able to connect a hard drive to it and do some basic tests with v4.6 kernel. I will look into converting the driver to libata. Might take some time because this is unfamiliar territory for me. Thanks, Sekhar
On Wed, Oct 26, 2016 at 07:01:12PM +0200, Bartlomiej Zolnierkiewicz wrote: > > Hi, > > On Wednesday, July 13, 2016 04:37:31 PM Arnd Bergmann wrote: > > On Wednesday, July 13, 2016 12:59:23 PM CEST Bartlomiej Zolnierkiewicz wrote: > > > > > > On Friday, July 08, 2016 10:23:48 PM Arnd Bergmann wrote: > > > > On Friday, July 8, 2016 5:24:41 PM CEST Bartlomiej Zolnierkiewicz wrote: > > > > > This patch disables deprecated IDE subsystem in assabet_defconfig > > > > > (no IDE host drivers are selected in this config so there is no > > > > > valid reason to enable IDE subsystem itself). > > > > > > > > > > Cc: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com> > > > > > Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> > > > > > > > > I think the series makes a lot of sense. I have checked your assertions > > > > in the changelogs and found no flaws in your logic, so I think we should > > > > take them all through arm-soc unless there are other concerns. > > > > > > Thank you. > > > > > > Should I resend everything or just patches that were not reposted yet > > > (the ones that were marked as RFT initially and got no feedback)? > > > > I'd be fine with just getting a pull request with all the patches that > > had no negative feedback and that were not already applied (if any). > > Here it is (sorry for taking so long). I've just been digging in the dmesg logs from when I was using the Assabet+Neponset as my firewall, and it was having to use the IDE ide-cs driver rather than the pata pcmcia driver. I don't recall whether the pata pcmcia driver was a problem or not, as the PCMCIA interface can't cope with _any_ 32-bit accesses. I think PATA tries to use the "highest" possible access size by default...
Hi, On Monday, October 31, 2016 03:46:22 PM Russell King - ARM Linux wrote: > On Wed, Oct 26, 2016 at 07:01:12PM +0200, Bartlomiej Zolnierkiewicz wrote: > > > > Hi, > > > > On Wednesday, July 13, 2016 04:37:31 PM Arnd Bergmann wrote: > > > On Wednesday, July 13, 2016 12:59:23 PM CEST Bartlomiej Zolnierkiewicz wrote: > > > > > > > > On Friday, July 08, 2016 10:23:48 PM Arnd Bergmann wrote: > > > > > On Friday, July 8, 2016 5:24:41 PM CEST Bartlomiej Zolnierkiewicz wrote: > > > > > > This patch disables deprecated IDE subsystem in assabet_defconfig > > > > > > (no IDE host drivers are selected in this config so there is no > > > > > > valid reason to enable IDE subsystem itself). > > > > > > > > > > > > Cc: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com> > > > > > > Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> > > > > > > > > > > I think the series makes a lot of sense. I have checked your assertions > > > > > in the changelogs and found no flaws in your logic, so I think we should > > > > > take them all through arm-soc unless there are other concerns. > > > > > > > > Thank you. > > > > > > > > Should I resend everything or just patches that were not reposted yet > > > > (the ones that were marked as RFT initially and got no feedback)? > > > > > > I'd be fine with just getting a pull request with all the patches that > > > had no negative feedback and that were not already applied (if any). > > > > Here it is (sorry for taking so long). > > I've just been digging in the dmesg logs from when I was using the > Assabet+Neponset as my firewall, and it was having to use the IDE > ide-cs driver rather than the pata pcmcia driver. > > I don't recall whether the pata pcmcia driver was a problem or not, > as the PCMCIA interface can't cope with _any_ 32-bit accesses. I > think PATA tries to use the "highest" possible access size by > default... It doesn't actually - it defaults to 16-bits for PIO data access and you must explicitly enable 32-bits using ATA_PFLAG_PIO32 port flag (pata_pcmcia doesn't set it so it should be okay). Also taskfile registers are accessed using 8-bits access by default transport functions (which are used by pata_pcmcia). Best regards, -- Bartlomiej Zolnierkiewicz Samsung R&D Institute Poland Samsung Electronics
On Monday, October 31, 2016 07:14:13 PM Bartlomiej Zolnierkiewicz wrote: > > Hi, > > On Monday, October 31, 2016 03:46:22 PM Russell King - ARM Linux wrote: > > On Wed, Oct 26, 2016 at 07:01:12PM +0200, Bartlomiej Zolnierkiewicz wrote: > > > > > > Hi, > > > > > > On Wednesday, July 13, 2016 04:37:31 PM Arnd Bergmann wrote: > > > > On Wednesday, July 13, 2016 12:59:23 PM CEST Bartlomiej Zolnierkiewicz wrote: > > > > > > > > > > On Friday, July 08, 2016 10:23:48 PM Arnd Bergmann wrote: > > > > > > On Friday, July 8, 2016 5:24:41 PM CEST Bartlomiej Zolnierkiewicz wrote: > > > > > > > This patch disables deprecated IDE subsystem in assabet_defconfig > > > > > > > (no IDE host drivers are selected in this config so there is no > > > > > > > valid reason to enable IDE subsystem itself). > > > > > > > > > > > > > > Cc: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com> > > > > > > > Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> > > > > > > > > > > > > I think the series makes a lot of sense. I have checked your assertions > > > > > > in the changelogs and found no flaws in your logic, so I think we should > > > > > > take them all through arm-soc unless there are other concerns. > > > > > > > > > > Thank you. > > > > > > > > > > Should I resend everything or just patches that were not reposted yet > > > > > (the ones that were marked as RFT initially and got no feedback)? > > > > > > > > I'd be fine with just getting a pull request with all the patches that > > > > had no negative feedback and that were not already applied (if any). > > > > > > Here it is (sorry for taking so long). > > > > I've just been digging in the dmesg logs from when I was using the > > Assabet+Neponset as my firewall, and it was having to use the IDE > > ide-cs driver rather than the pata pcmcia driver. > > > > I don't recall whether the pata pcmcia driver was a problem or not, > > as the PCMCIA interface can't cope with _any_ 32-bit accesses. I > > think PATA tries to use the "highest" possible access size by > > default... > > It doesn't actually - it defaults to 16-bits for PIO data access and > you must explicitly enable 32-bits using ATA_PFLAG_PIO32 port flag > (pata_pcmcia doesn't set it so it should be okay). Also taskfile > registers are accessed using 8-bits access by default transport > functions (which are used by pata_pcmcia). Please also note that: - assebet_defconfig currently doesn't even enable ide-cs (CONFIG_BLK_DEV_IDECS) in the mainline kernel - neponset_defconfig doesn't even enable IDE (CONFIG_IDE) in the mainline kernel so there is no risk of breaking anything.. :-) Best regards, -- Bartlomiej Zolnierkiewicz Samsung R&D Institute Poland Samsung Electronics
On Monday, October 31, 2016 7:24:46 PM CET Bartlomiej Zolnierkiewicz wrote: > On Monday, October 31, 2016 07:14:13 PM Bartlomiej Zolnierkiewicz wrote: > > On Monday, October 31, 2016 03:46:22 PM Russell King - ARM Linux wrote: > > > On Wed, Oct 26, 2016 at 07:01:12PM +0200, Bartlomiej Zolnierkiewicz wrote: > > > > > I'd be fine with just getting a pull request with all the patches that > > > > > had no negative feedback and that were not already applied (if any). > > > > > > > > Here it is (sorry for taking so long). > > > > > > I've just been digging in the dmesg logs from when I was using the > > > Assabet+Neponset as my firewall, and it was having to use the IDE > > > ide-cs driver rather than the pata pcmcia driver. > > > > > > I don't recall whether the pata pcmcia driver was a problem or not, > > > as the PCMCIA interface can't cope with _any_ 32-bit accesses. I > > > think PATA tries to use the "highest" possible access size by > > > default... > > > > It doesn't actually - it defaults to 16-bits for PIO data access and > > you must explicitly enable 32-bits using ATA_PFLAG_PIO32 port flag > > (pata_pcmcia doesn't set it so it should be okay). Also taskfile > > registers are accessed using 8-bits access by default transport > > functions (which are used by pata_pcmcia). > > Please also note that: > > - assebet_defconfig currently doesn't even enable ide-cs > (CONFIG_BLK_DEV_IDECS) in the mainline kernel > > - neponset_defconfig doesn't even enable IDE (CONFIG_IDE) > in the mainline kernel > > so there is no risk of breaking anything.. I noticed this older pull request in my todo folder, my interpretation is that the concern was resolved and we simply missed it. I've pulled it into next/defconfig for v4.10 now, with the above in the merge commit text for reference. Thanks, Arnd
Hi, On Monday, July 18, 2016 08:15:08 PM Sekhar Nori wrote: > On Friday 15 July 2016 08:45 PM, Kevin Hilman wrote: > > Arnd Bergmann <arnd@arndb.de> writes: > > > >> On Wednesday, July 13, 2016 12:59:23 PM CEST Bartlomiej Zolnierkiewicz wrote: > >>> > >>> On Friday, July 08, 2016 10:23:48 PM Arnd Bergmann wrote: > >>>> On Friday, July 8, 2016 5:24:41 PM CEST Bartlomiej Zolnierkiewicz wrote: > >>>>> This patch disables deprecated IDE subsystem in assabet_defconfig > >>>>> (no IDE host drivers are selected in this config so there is no > >>>>> valid reason to enable IDE subsystem itself). > >>>>> > >>>>> Cc: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com> > >>>>> Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> > >>>> > >>>> I think the series makes a lot of sense. I have checked your assertions > >>>> in the changelogs and found no flaws in your logic, so I think we should > >>>> take them all through arm-soc unless there are other concerns. > >>> > >>> Thank you. > >>> > >>> Should I resend everything or just patches that were not reposted yet > >>> (the ones that were marked as RFT initially and got no feedback)? > >> > >> I'd be fine with just getting a pull request with all the patches that > >> had no negative feedback and that were not already applied (if any). > >> > >>>> Do you have a list of ARM defconfigs that keep using CONFIG_IDE and > >>>> how you determined that they need it? > >>> > >>> The only such defconfig is davinci_all_defconfig which uses > >>> palm_bk3710 host driver (CONFIG_BLK_DEV_PALMCHIP_BK3710). > >>> > >>>> I know that ARCH_RPC/ARCH_ACORN has a couple of special drivers that > >>>> have no libata replacement, are there any others like that, or are > >>>> they all platforms that should in theory work with libata but need > >>>> testing? > >>> > >>> All platforms except ARCH_ACORN, ARCH_DAVINCI & ARCH_RPC should work > >>> with libata. > >> > >> Adding Sekhar and Kevin for DaVinci: At first sight, palm_bk3710 looks > >> fairly straightforward (meaning someone has to do a few day's work) > >> to convert into a libata driver. > >> > >> As this is on on-chip controller that is part of a dm644x and dm646x, > >> it should also not be hard to test (as long as someone can find > >> a hard drive to plug in). > > > > I have a hard drive, but don't have any dm64xx hardware anymore to test > > this. My last working dm644x board died last year. > > I have a working DM6446 EVM. I was able to connect a hard drive to it > and do some basic tests with v4.6 kernel. > > I will look into converting the driver to libata. Might take some time > because this is unfamiliar territory for me. Do you need some help with it? I can provide you with draft driver patch if you want. I'm also on #kernel IRC channel in case you have some questions.. Best regards, -- Bartlomiej Zolnierkiewicz Samsung R&D Institute Poland Samsung Electronics
Hi Bartlomiej, On Monday 12 December 2016 06:15 PM, Bartlomiej Zolnierkiewicz wrote: > > Hi, > > On Monday, July 18, 2016 08:15:08 PM Sekhar Nori wrote: >> On Friday 15 July 2016 08:45 PM, Kevin Hilman wrote: >>> Arnd Bergmann <arnd@arndb.de> writes: >>> >>>> On Wednesday, July 13, 2016 12:59:23 PM CEST Bartlomiej Zolnierkiewicz wrote: >>>>> >>>>> On Friday, July 08, 2016 10:23:48 PM Arnd Bergmann wrote: >>>>>> On Friday, July 8, 2016 5:24:41 PM CEST Bartlomiej Zolnierkiewicz wrote: >>>>>>> This patch disables deprecated IDE subsystem in assabet_defconfig >>>>>>> (no IDE host drivers are selected in this config so there is no >>>>>>> valid reason to enable IDE subsystem itself). >>>>>>> >>>>>>> Cc: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com> >>>>>>> Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> >>>>>> >>>>>> I think the series makes a lot of sense. I have checked your assertions >>>>>> in the changelogs and found no flaws in your logic, so I think we should >>>>>> take them all through arm-soc unless there are other concerns. >>>>> >>>>> Thank you. >>>>> >>>>> Should I resend everything or just patches that were not reposted yet >>>>> (the ones that were marked as RFT initially and got no feedback)? >>>> >>>> I'd be fine with just getting a pull request with all the patches that >>>> had no negative feedback and that were not already applied (if any). >>>> >>>>>> Do you have a list of ARM defconfigs that keep using CONFIG_IDE and >>>>>> how you determined that they need it? >>>>> >>>>> The only such defconfig is davinci_all_defconfig which uses >>>>> palm_bk3710 host driver (CONFIG_BLK_DEV_PALMCHIP_BK3710). >>>>> >>>>>> I know that ARCH_RPC/ARCH_ACORN has a couple of special drivers that >>>>>> have no libata replacement, are there any others like that, or are >>>>>> they all platforms that should in theory work with libata but need >>>>>> testing? >>>>> >>>>> All platforms except ARCH_ACORN, ARCH_DAVINCI & ARCH_RPC should work >>>>> with libata. >>>> >>>> Adding Sekhar and Kevin for DaVinci: At first sight, palm_bk3710 looks >>>> fairly straightforward (meaning someone has to do a few day's work) >>>> to convert into a libata driver. >>>> >>>> As this is on on-chip controller that is part of a dm644x and dm646x, >>>> it should also not be hard to test (as long as someone can find >>>> a hard drive to plug in). >>> >>> I have a hard drive, but don't have any dm64xx hardware anymore to test >>> this. My last working dm644x board died last year. >> >> I have a working DM6446 EVM. I was able to connect a hard drive to it >> and do some basic tests with v4.6 kernel. >> >> I will look into converting the driver to libata. Might take some time >> because this is unfamiliar territory for me. > > Do you need some help with it? > > I can provide you with draft driver patch if you want. A draft driver patch will really help. I can test/debug. Otherwise, not sure when I will really be able to get to this. Regards, Sekhar
diff --git a/arch/arm/configs/assabet_defconfig b/arch/arm/configs/assabet_defconfig index 558ecd8..ab19ff1 100644 --- a/arch/arm/configs/assabet_defconfig +++ b/arch/arm/configs/assabet_defconfig @@ -34,7 +34,6 @@ CONFIG_MTD_CFI_INTELEXT=y CONFIG_MTD_SA1100=y CONFIG_BLK_DEV_LOOP=m CONFIG_BLK_DEV_RAM=y -CONFIG_IDE=y CONFIG_NETDEVICES=y CONFIG_NET_ETHERNET=y CONFIG_NET_PCMCIA=y
This patch disables deprecated IDE subsystem in assabet_defconfig (no IDE host drivers are selected in this config so there is no valid reason to enable IDE subsystem itself). Cc: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com> Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> --- arch/arm/configs/assabet_defconfig | 1 - 1 file changed, 1 deletion(-)