[PATCH 0/2] sh: Fix IDE on landisk

[PATCH 0/2] sh: Fix IDE on landisk

[Daniel Palmer]

I dug out my landisk to look at kexec for Geert. Since I'm lazy and
LLMs are good at fixing bitrot I let my LLM work out how to get
it to boot again.

There are some other issues (perf is apparently borken, there are
some issues with the decompresor and big kernels..) but this
seems to be the only thing stopping it booting with the defconfig.

Disclaimer since we don't need to give LLM tags anymore:
- LLM debugged the issue.
- It has been checked on real hardware.
- I have checked the IDE driver patch, cleaned it up and
  cleaned out massive walls of text that LLMs seem to like
  to add but I have left its summary of the issue in the commit
  message.

Daniel Palmer (2):
  ata: pata_artop: read the ATP865 mode register through pci_iomap
  sh: landisk_defconfig: enable PATA_ARTOP for the ATP865

 arch/sh/configs/landisk_defconfig |  2 +-
 drivers/ata/pata_artop.c          | 12 ++++++++++--
 2 files changed, 11 insertions(+), 3 deletions(-)

-- 
2.55.0

[PATCH 1/2] ata: pata_artop: read the ATP865 mode register through pci_iomap

[Daniel Palmer]

artop_init_one() probes the 6280's "fast" bit with inb() on the raw
start address of BAR 4.  That address is a PCI I/O address, which is
only a usable port number on platforms whose I/O port base maps PCI I/O
space one to one.  On an SH7751 LANDISK (identity io_port_base, PCI I/O
window at 0xfe240000) the resource starts at 0x1400 and inb(0x1400)
dereferences that address:

  BUG: unable to handle kernel paging request at 00001400
  PC is at artop_init_one+0x10e/0x170

Map the BAR with pci_iomap() and use ioread8(), as libata-sff does for
the BMDMA registers later on.

Signed-off-by: Daniel Palmer <daniel@0x0f.com>
---
 drivers/ata/pata_artop.c | 12 ++++++++++--
 1 file changed, 10 insertions(+), 2 deletions(-)

diff --git a/drivers/ata/pata_artop.c b/drivers/ata/pata_artop.c
index 9f8d41639a62..351ff4c8e48e 100644
--- a/drivers/ata/pata_artop.c
+++ b/drivers/ata/pata_artop.c
@@ -405,13 +405,21 @@ static int artop_init_one (struct pci_dev *pdev, const struct pci_device_id *id)
 	case 1:		/* 6260 */
 		ppi[0] = &info_626x;
 		break;
-	case 2:		/* 6280 or 6280 + fast */
-		if (inb(pci_resource_start(pdev, 4)) & 0x10)
+	case 2: {	/* 6280 or 6280 + fast */
+		void __iomem *bmdma = pci_iomap(pdev, 4, 1);
+		u8 cfg;
+
+		if (!bmdma)
+			return -ENOMEM;
+		cfg = ioread8(bmdma);
+		pci_iounmap(pdev, bmdma);
+		if (cfg & 0x10)
 			ppi[0] = &info_628x_fast;
 		else
 			ppi[0] = &info_628x;
 		break;
 	}
+	}
 
 	BUG_ON(ppi[0] == NULL);
 
-- 
2.55.0

Re: [PATCH 1/2] ata: pata_artop: read the ATP865 mode register through pci_iomap

[Florian Fuchs]

Hi Daniel,

On 17 Oct 13:14, Daniel Palmer wrote:
> artop_init_one() probes the 6280's "fast" bit with inb() on the raw
> start address of BAR 4.  That address is a PCI I/O address, which is
> only a usable port number on platforms whose I/O port base maps PCI I/O
> space one to one.  On an SH7751 LANDISK (identity io_port_base, PCI I/O
> window at 0xfe240000) the resource starts at 0x1400 and inb(0x1400)
> dereferences that address:
> 
>   BUG: unable to handle kernel paging request at 00001400
>   PC is at artop_init_one+0x10e/0x170
> 
> Map the BAR with pci_iomap() and use ioread8(), as libata-sff does for
> the BMDMA registers later on.
> 
> Signed-off-by: Daniel Palmer <daniel@0x0f.com>
> ---
>  drivers/ata/pata_artop.c | 12 ++++++++++--
>  1 file changed, 10 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/ata/pata_artop.c b/drivers/ata/pata_artop.c
> index 9f8d41639a62..351ff4c8e48e 100644
> --- a/drivers/ata/pata_artop.c
> +++ b/drivers/ata/pata_artop.c
> @@ -405,13 +405,21 @@ static int artop_init_one (struct pci_dev *pdev, const struct pci_device_id *id)
>  	case 1:		/* 6260 */
>  		ppi[0] = &info_626x;
>  		break;
> -	case 2:		/* 6280 or 6280 + fast */
> -		if (inb(pci_resource_start(pdev, 4)) & 0x10)
> +	case 2: {	/* 6280 or 6280 + fast */
> +		void __iomem *bmdma = pci_iomap(pdev, 4, 1);
> +		u8 cfg;
> +
> +		if (!bmdma)
> +			return -ENOMEM;
> +		cfg = ioread8(bmdma);
> +		pci_iounmap(pdev, bmdma);
> +		if (cfg & 0x10)
>  			ppi[0] = &info_628x_fast;
>  		else
>  			ppi[0] = &info_628x;
>  		break;
>  	}
> +	}
>  
>  	BUG_ON(ppi[0] == NULL);
>  
> -- 
> 2.55.0
> 

There is a small logic change, where -ENOMEM is returned, when BAR 4 is
unassigned, where libata would fallback to PIO [0], so maybe it
shouldn't fail when BAR 4 is unassigned?

Tested-by: Florian Fuchs <fuchsfl@gmail.com> # on PX-EH40L (LANDISK HDL-U, ATP865 1191:0009 rev 10)

I also tested forced PIO4 mode via libata.force=pio4, which also works
on the device. (ata1.00: FORCE: xfer_mask set to pio4)

[0] https://github.com/torvalds/linux/blob/master/drivers/ata/libata-sff.c#L3088

Regards
Florian

Re: [PATCH 1/2] ata: pata_artop: read the ATP865 mode register through pci_iomap

[John Paul Adrian Glaubitz]

Hi Daniel,

On Sat, 2026-10-17 at 13:14 +0900, Daniel Palmer wrote:
> artop_init_one() probes the 6280's "fast" bit with inb() on the raw
> start address of BAR 4.  That address is a PCI I/O address, which is
> only a usable port number on platforms whose I/O port base maps PCI I/O
> space one to one.  On an SH7751 LANDISK (identity io_port_base, PCI I/O
> window at 0xfe240000) the resource starts at 0x1400 and inb(0x1400)
> dereferences that address:
> 
>   BUG: unable to handle kernel paging request at 00001400
>   PC is at artop_init_one+0x10e/0x170
> 
> Map the BAR with pci_iomap() and use ioread8(), as libata-sff does for
> the BMDMA registers later on.
> 
> Signed-off-by: Daniel Palmer <daniel@0x0f.com>
> ---
>  drivers/ata/pata_artop.c | 12 ++++++++++--
>  1 file changed, 10 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/ata/pata_artop.c b/drivers/ata/pata_artop.c
> index 9f8d41639a62..351ff4c8e48e 100644
> --- a/drivers/ata/pata_artop.c
> +++ b/drivers/ata/pata_artop.c
> @@ -405,13 +405,21 @@ static int artop_init_one (struct pci_dev *pdev, const struct pci_device_id *id)
>  	case 1:		/* 6260 */
>  		ppi[0] = &info_626x;
>  		break;
> -	case 2:		/* 6280 or 6280 + fast */
> -		if (inb(pci_resource_start(pdev, 4)) & 0x10)
> +	case 2: {	/* 6280 or 6280 + fast */
> +		void __iomem *bmdma = pci_iomap(pdev, 4, 1);
> +		u8 cfg;
> +
> +		if (!bmdma)
> +			return -ENOMEM;
> +		cfg = ioread8(bmdma);
> +		pci_iounmap(pdev, bmdma);
> +		if (cfg & 0x10)
>  			ppi[0] = &info_628x_fast;
>  		else
>  			ppi[0] = &info_628x;
>  		break;
>  	}
> +	}
>  
>  	BUG_ON(ppi[0] == NULL);
>  

Since neither of the two maintainers of this driver has responded yet, I can't
take this patch through my tree. Either Damien or Niklas should ack this change
(according to ./scripts/get_maintainer.pl drivers/ata/pata_artop.c).

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: [PATCH 1/2] ata: pata_artop: read the ATP865 mode register through pci_iomap

[Damien Le Moal]

On 2026/10/17 6:14, Daniel Palmer wrote:
> artop_init_one() probes the 6280's "fast" bit with inb() on the raw
> start address of BAR 4.  That address is a PCI I/O address, which is
> only a usable port number on platforms whose I/O port base maps PCI I/O
> space one to one.  On an SH7751 LANDISK (identity io_port_base, PCI I/O
> window at 0xfe240000) the resource starts at 0x1400 and inb(0x1400)
> dereferences that address:
> 
>   BUG: unable to handle kernel paging request at 00001400
>   PC is at artop_init_one+0x10e/0x170
> 
> Map the BAR with pci_iomap() and use ioread8(), as libata-sff does for
> the BMDMA registers later on.
> 
> Signed-off-by: Daniel Palmer <daniel@0x0f.com>
> ---
>  drivers/ata/pata_artop.c | 12 ++++++++++--
>  1 file changed, 10 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/ata/pata_artop.c b/drivers/ata/pata_artop.c
> index 9f8d41639a62..351ff4c8e48e 100644
> --- a/drivers/ata/pata_artop.c
> +++ b/drivers/ata/pata_artop.c
> @@ -405,13 +405,21 @@ static int artop_init_one (struct pci_dev *pdev, const struct pci_device_id *id)
>  	case 1:		/* 6260 */
>  		ppi[0] = &info_626x;
>  		break;
> -	case 2:		/* 6280 or 6280 + fast */
> -		if (inb(pci_resource_start(pdev, 4)) & 0x10)
> +	case 2: {	/* 6280 or 6280 + fast */
> +		void __iomem *bmdma = pci_iomap(pdev, 4, 1);
> +		u8 cfg;
> +
> +		if (!bmdma)
> +			return -ENOMEM;
> +		cfg = ioread8(bmdma);
> +		pci_iounmap(pdev, bmdma);
> +		if (cfg & 0x10)
>  			ppi[0] = &info_628x_fast;
>  		else
>  			ppi[0] = &info_628x;
>  		break;
>  	}
> +	}

This is really ugly... Please move the "case 2" variable declarations to the top
of the function so that you do not have to do something like this.

Of note also is that this switch does not have a "default" case, which is really
bad practice, even though in this case, we should never hit unknown values.
But I would still prefer seeing something like:

	default:
		pr_warn("Invalid driver data\n");
		pci_disable_device(pdev);
		return -ENODEV;
	}

or a big hammer:

	default:
		BUG();
	}

>  
>  	BUG_ON(ppi[0] == NULL);
>  


-- 
Damien Le Moal
Western Digital Research

Re: [PATCH 1/2] ata: pata_artop: read the ATP865 mode register through pci_iomap

[Daniel Palmer]

Hi Damien,

On Thu, 22 Oct 2026 at 16:01, Damien Le Moal <dlemoal@kernel.org> wrote:
> > +     case 2: {       /* 6280 or 6280 + fast */
> > +             void __iomem *bmdma = pci_iomap(pdev, 4, 1);
> > +             u8 cfg;
> > +
> > +             if (!bmdma)
> > +                     return -ENOMEM;
> > +             cfg = ioread8(bmdma);
> > +             pci_iounmap(pdev, bmdma);
> > +             if (cfg & 0x10)
> >                       ppi[0] = &info_628x_fast;
> >               else
> >                       ppi[0] = &info_628x;
> >               break;
> >       }
> > +     }
>
> This is really ugly... Please move the "case 2" variable declarations to the top
> of the function so that you do not have to do something like this.

That's fair. I'll fix that up.

> Of note also is that this switch does not have a "default" case, which is really
> bad practice, even though in this case, we should never hit unknown values.
> But I would still prefer seeing something like:
>
>         default:
>                 pr_warn("Invalid driver data\n");
>                 pci_disable_device(pdev);
>                 return -ENODEV;
>         }

Can we fix that later or should I roll it into this patch? Being an
old driver I think it probably has a bunch of preexisting style issues
that need to be fixed but that seems like a separate issue from making
it functional again.

Cheers,

Daniel

Re: [PATCH 1/2] ata: pata_artop: read the ATP865 mode register through pci_iomap

[Damien Le Moal]

On 2026/10/22 11:17, Daniel Palmer wrote:
> Hi Damien,
> 
> On Thu, 22 Oct 2026 at 16:01, Damien Le Moal <dlemoal@kernel.org> wrote:
>>> +     case 2: {       /* 6280 or 6280 + fast */
>>> +             void __iomem *bmdma = pci_iomap(pdev, 4, 1);
>>> +             u8 cfg;
>>> +
>>> +             if (!bmdma)
>>> +                     return -ENOMEM;
>>> +             cfg = ioread8(bmdma);
>>> +             pci_iounmap(pdev, bmdma);
>>> +             if (cfg & 0x10)
>>>                       ppi[0] = &info_628x_fast;
>>>               else
>>>                       ppi[0] = &info_628x;
>>>               break;
>>>       }
>>> +     }
>>
>> This is really ugly... Please move the "case 2" variable declarations to the top
>> of the function so that you do not have to do something like this.
> 
> That's fair. I'll fix that up.
> 
>> Of note also is that this switch does not have a "default" case, which is really
>> bad practice, even though in this case, we should never hit unknown values.
>> But I would still prefer seeing something like:
>>
>>         default:
>>                 pr_warn("Invalid driver data\n");
>>                 pci_disable_device(pdev);
>>                 return -ENODEV;
>>         }
> 
> Can we fix that later or should I roll it into this patch? Being an
> old driver I think it probably has a bunch of preexisting style issues
> that need to be fixed but that seems like a separate issue from making
> it functional again.

Later is fine.

> 
> Cheers,
> 
> Daniel


-- 
Damien Le Moal
Western Digital Research

[PATCH 2/2] sh: landisk_defconfig: enable PATA_ARTOP for the ATP865

[Daniel Palmer]

The landisk defconfig currently has a similar but incorrect IDE
driver selected so IDE doesn't work out of the box.

Select the right one.

Signed-off-by: Daniel Palmer <daniel@0x0f.com>
---
 arch/sh/configs/landisk_defconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/sh/configs/landisk_defconfig b/arch/sh/configs/landisk_defconfig
index 2b7e10c9acee..6b5ec1f3ad71 100644
--- a/arch/sh/configs/landisk_defconfig
+++ b/arch/sh/configs/landisk_defconfig
@@ -28,7 +28,7 @@ CONFIG_BLK_DEV_LOOP=y
 CONFIG_BLK_DEV_RAM=y
 CONFIG_ATA=y
 CONFIG_ATA_GENERIC=y
-CONFIG_PATA_ATP867X=y
+CONFIG_PATA_ARTOP=y
 CONFIG_SCSI=y
 CONFIG_BLK_DEV_SD=y
 CONFIG_BLK_DEV_SR=y
-- 
2.55.0

Re: [PATCH 2/2] sh: landisk_defconfig: enable PATA_ARTOP for the ATP865

[Florian Fuchs]

On 17 Oct 13:14, Daniel Palmer wrote:
> The landisk defconfig currently has a similar but incorrect IDE
> driver selected so IDE doesn't work out of the box.
> 
> Select the right one.
> 
> Signed-off-by: Daniel Palmer <daniel@0x0f.com>
> ---
>  arch/sh/configs/landisk_defconfig | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/sh/configs/landisk_defconfig b/arch/sh/configs/landisk_defconfig
> index 2b7e10c9acee..6b5ec1f3ad71 100644
> --- a/arch/sh/configs/landisk_defconfig
> +++ b/arch/sh/configs/landisk_defconfig
> @@ -28,7 +28,7 @@ CONFIG_BLK_DEV_LOOP=y
>  CONFIG_BLK_DEV_RAM=y
>  CONFIG_ATA=y
>  CONFIG_ATA_GENERIC=y
> -CONFIG_PATA_ATP867X=y
> +CONFIG_PATA_ARTOP=y
>  CONFIG_SCSI=y
>  CONFIG_BLK_DEV_SD=y
>  CONFIG_BLK_DEV_SR=y
> -- 
> 2.55.0
> 

I can confirm the PATA_ARTOP is the right option for the Plextor PX-EH40L
(which is like LANDISK HDL-U), the mismatch of options was btw introduced in 
Fixes: b7aaf16d10bd ("sh: remove CONFIG_IDE from most defconfig")

which changed CONFIG_BLK_DEV_AEC62XX (which supported ATP865) to
CONFIG_PATA_ATP867X. To my knowledge there is no sh landisk device with
an ATP867 chip.

Reviewed-by: Florian Fuchs <fuchsfl@gmail.com>

My PX-EH40L has btw this lspci:

00:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8100/8101L/8139 PCI Fast Ethernet Adapter (rev 20)
00:01.0 Mass storage controller: Artop Electronic Corp ATP865 (rev 10)
00:02.0 USB controller: NEC Corporation OHCI USB Controller (rev 43)
00:02.1 USB controller: NEC Corporation OHCI USB Controller (rev 43)
00:02.2 USB controller: NEC Corporation uPD72010x USB 2.0 Controller (rev 04)

Regards
Florian

Re: [PATCH 0/2] sh: Fix IDE on landisk

[John Paul Adrian Glaubitz]

Hi Daniel,

On Sat, 2026-10-17 at 13:14 +0900, Daniel Palmer wrote:
> I dug out my landisk to look at kexec for Geert. Since I'm lazy and
> LLMs are good at fixing bitrot I let my LLM work out how to get
> it to boot again.
> 
> There are some other issues (perf is apparently borken, there are
> some issues with the decompresor and big kernels..) but this
> seems to be the only thing stopping it booting with the defconfig.
> 
> Disclaimer since we don't need to give LLM tags anymore:
> - LLM debugged the issue.
> - It has been checked on real hardware.
> - I have checked the IDE driver patch, cleaned it up and
>   cleaned out massive walls of text that LLMs seem to like
>   to add but I have left its summary of the issue in the commit
>   message.
> 
> Daniel Palmer (2):
>   ata: pata_artop: read the ATP865 mode register through pci_iomap
>   sh: landisk_defconfig: enable PATA_ARTOP for the ATP865
> 
>  arch/sh/configs/landisk_defconfig |  2 +-
>  drivers/ata/pata_artop.c          | 12 ++++++++++--
>  2 files changed, 11 insertions(+), 3 deletions(-)

Great, thanks for fixing this. While I have LANDISK hardware myself,
I cannot probably set it up fast enough now to test your patches as
I don't know where I put it after moving places.

I hope Geert can test and review your patches and I'll pick them up
with his Reviewed-by and Tested-by signatures.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: [PATCH 0/2] sh: Fix IDE on landisk

[Geert Uytterhoeven]

Hi Daniel,

On Sat, 17 Oct 2026 at 09:48, John Paul Adrian Glaubitz
<glaubitz@physik.fu-berlin.de> wrote:
> On Sat, 2026-10-17 at 13:14 +0900, Daniel Palmer wrote:
> > I dug out my landisk to look at kexec for Geert. Since I'm lazy and
> > LLMs are good at fixing bitrot I let my LLM work out how to get
> > it to boot again.
> >
> > There are some other issues (perf is apparently borken, there are
> > some issues with the decompresor and big kernels..) but this
> > seems to be the only thing stopping it booting with the defconfig.
> >
> > Disclaimer since we don't need to give LLM tags anymore:
> > - LLM debugged the issue.
> > - It has been checked on real hardware.
> > - I have checked the IDE driver patch, cleaned it up and
> >   cleaned out massive walls of text that LLMs seem to like
> >   to add but I have left its summary of the issue in the commit
> >   message.
> >
> > Daniel Palmer (2):
> >   ata: pata_artop: read the ATP865 mode register through pci_iomap
> >   sh: landisk_defconfig: enable PATA_ARTOP for the ATP865
> >
> >  arch/sh/configs/landisk_defconfig |  2 +-
> >  drivers/ata/pata_artop.c          | 12 ++++++++++--
> >  2 files changed, 11 insertions(+), 3 deletions(-)
>
> Great, thanks for fixing this. While I have LANDISK hardware myself,
> I cannot probably set it up fast enough now to test your patches as
> I don't know where I put it after moving places.
>
> I hope Geert can test and review your patches and I'll pick them up
> with his Reviewed-by and Tested-by signatures.

Sorry, I must have different hardware, as mine doesn't have an
ATP865 PCI device:

    # lspci
    00:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd.
RTL-8139/8139C/8139C+ (rev 20)
    00:02.0 USB Controller: NEC Corporation USB (rev 43)
    00:02.1 USB Controller: NEC Corporation USB (rev 43)
    00:02.2 USB Controller: NEC Corporation USB 2.0 (rev 04)

My CF rootfs uses pata_platform, which is enabled in my working .config.
landisk_defconfig lacks CONFIG_PATA_PLATFORM=y, so it hangs during
boot. After enabling that, the boot gets further, but it still hangs:

    INIT: Id "1" respawning too fast: disabled for 5 minutes
    INIT: Id "2" respawning too fast: disabled for 5 minutes
    INIT: no more processes left in this runlevel

Adding

    CONFIG_DEVTMPFS=y
    CONFIG_DEVTMPFS_MOUNT=y

to landisk_defconfig fixes that.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCH 0/2] sh: Fix IDE on landisk

[Daniel Palmer]

Hi Geert,

On Sun, 18 Oct 2026 at 23:48, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> > I hope Geert can test and review your patches and I'll pick them up
> > with his Reviewed-by and Tested-by signatures.
>
> Sorry, I must have different hardware, as mine doesn't have an
> ATP865 PCI device:
>
>     # lspci
>     00:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd.
> RTL-8139/8139C/8139C+ (rev 20)
>     00:02.0 USB Controller: NEC Corporation USB (rev 43)
>     00:02.1 USB Controller: NEC Corporation USB (rev 43)
>     00:02.2 USB Controller: NEC Corporation USB 2.0 (rev 04)
>
> My CF rootfs uses pata_platform, which is enabled in my working .config.
> landisk_defconfig lacks CONFIG_PATA_PLATFORM=y, so it hangs during
> boot. After enabling that, the boot gets further, but it still hangs:

I guess you have something like the USL-5P that uses the SH's onboard
CF interface.
Since Florian has confirmed their hardware has the PCI IDE controller
like mine and reviewed the change I think we're good.

Daniel

Re: [PATCH 0/2] sh: Fix IDE on landisk

[yoshinori.sato]

On Mon, 19 Oct 2026 08:04:46 +0900,
Daniel Palmer wrote:
> 
> Hi Geert,
> 
> On Sun, 18 Oct 2026 at 23:48, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> > > I hope Geert can test and review your patches and I'll pick them up
> > > with his Reviewed-by and Tested-by signatures.
> >
> > Sorry, I must have different hardware, as mine doesn't have an
> > ATP865 PCI device:
> >
> >     # lspci
> >     00:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd.
> > RTL-8139/8139C/8139C+ (rev 20)
> >     00:02.0 USB Controller: NEC Corporation USB (rev 43)
> >     00:02.1 USB Controller: NEC Corporation USB (rev 43)
> >     00:02.2 USB Controller: NEC Corporation USB 2.0 (rev 04)
> >
> > My CF rootfs uses pata_platform, which is enabled in my working .config.
> > landisk_defconfig lacks CONFIG_PATA_PLATFORM=y, so it hangs during
> > boot. After enabling that, the boot gets further, but it still hangs:
> 
> I guess you have something like the USL-5P that uses the SH's onboard
> CF interface.
> Since Florian has confirmed their hardware has the PCI IDE controller
> like mine and reviewed the change I think we're good.
> 
> Daniel

Yes.
LANDISK and USL-5P have almost the same hardware configuration,
but the only difference is the IDE part.
This issue needs to be confirmed with LANDISK hardware.

The LANDISK that I have cannot be used immediately, but here is qemu
that can emulate LANDISK hardware.
https://gitlab.com/yoshinori.sato/qemu/-/tree/landisk?ref_type=heads
This will allow you to check if it is not broken.

-- 
Yosinori Sato

Re: [PATCH 0/2] sh: Fix IDE on landisk

[John Paul Adrian Glaubitz]

Hi Daniel,

On Mon, 2026-10-19 at 08:04 +0900, Daniel Palmer wrote:
> Hi Geert,
> 
> On Sun, 18 Oct 2026 at 23:48, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> > > I hope Geert can test and review your patches and I'll pick them up
> > > with his Reviewed-by and Tested-by signatures.
> > 
> > Sorry, I must have different hardware, as mine doesn't have an
> > ATP865 PCI device:
> > 
> >     # lspci
> >     00:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd.
> > RTL-8139/8139C/8139C+ (rev 20)
> >     00:02.0 USB Controller: NEC Corporation USB (rev 43)
> >     00:02.1 USB Controller: NEC Corporation USB (rev 43)
> >     00:02.2 USB Controller: NEC Corporation USB 2.0 (rev 04)
> > 
> > My CF rootfs uses pata_platform, which is enabled in my working .config.
> > landisk_defconfig lacks CONFIG_PATA_PLATFORM=y, so it hangs during
> > boot. After enabling that, the boot gets further, but it still hangs:
> 
> I guess you have something like the USL-5P that uses the SH's onboard
> CF interface.
> Since Florian has confirmed their hardware has the PCI IDE controller
> like mine and reviewed the change I think we're good.

Is disabling CONFIG_PATA_ATP867X still correct or would that brick the
boot on USL-5P? I guess you are using any of the HDL-XXXU devices [1],
aren't you?

I actually own both as I did quite a SuperH shopping spree in Japan some
ten years ago.

Adrian

> [1] https://www.iodata.jp/product/nas/personal/hdl-u/

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: [PATCH 0/2] sh: Fix IDE on landisk

[Colton Pawielski]

Hi Daniel,

This is my first message to the mailing list so please correct me if I've
done anything improper or non-standard.

I tested this series on three I-O DATA LANDISK HDL-U boards (v7.3 +
this series, landisk_defconfig + DEVTMPFS as mentioned by Geert).
All three boot from disk, and the ATP865 is detected as
"PATA max UDMA/100".

I have different drives in each of my LANDISK devices:
- Maxtor 7Y250P0 (native PATA): UDMA/100
- SATA SSD behind a PATA-SATA adapter: UDMA/66 (my adapter
  gives ICRC errors at UDMA/100)
- CF card in a CF-IDE adapter: UDMA/33

lspci from two of them:

00:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd.
RTL-8100/8101L/8139 PCI Fast Ethernet Adapter (rev 20)
00:01.0 Mass storage controller: Artop Electronic Corp ATP865 (rev 07)
00:02.0 USB controller: NEC Corporation OHCI USB Controller (rev 43)
00:02.1 USB controller: NEC Corporation OHCI USB Controller (rev 43)
00:02.2 USB controller: NEC Corporation uPD72010x USB 2.0 Controller (rev 04)

The third is identical except for the ATP865 revision:

00:01.0 Mass storage controller: Artop Electronic Corp ATP865 (rev 06)

In testing I could often lock up the board when transferring data over
SSH. I don't believe it's related to this series and am fairly sure it's
in the 8139cp driver. I have a candidate fix that I plan to send in
a couple of days once I've tested it further and there's no more
lockups on my hardware.

Tested-by: Colton Pawielski <colton.pawielski@gmail.com> # 3x LANDISK
HDL-U, ATP865 rev 06/07

Thanks,
Colton

Re: [PATCH 0/2] sh: Fix IDE on landisk

[Geert Uytterhoeven]

Hi Colton,

On Wed, 21 Oct 2026 at 03:05, Colton Pawielski
<colton.pawielski@gmail.com> wrote:
> This is my first message to the mailing list so please correct me if I've
> done anything improper or non-standard.

Thanks, LGTM.

> In testing I could often lock up the board when transferring data over
> SSH. I don't believe it's related to this series and am fairly sure it's
> in the 8139cp driver. I have a candidate fix that I plan to send in
> a couple of days once I've tested it further and there's no more
> lockups on my hardware.

8139cp is udeed not very reliable, hence nfsroot didn't work well for me.

> Tested-by: Colton Pawielski <colton.pawielski@gmail.com> # 3x LANDISK
> HDL-U, ATP865 rev 06/07

Thanks!

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCH 0/2] sh: Fix IDE on landisk

[Daniel Palmer]

Hi Colton,

On Wed, 21 Oct 2026 at 10:05, Colton Pawielski
<colton.pawielski@gmail.com> wrote:
> In testing I could often lock up the board when transferring data over
> SSH. I don't believe it's related to this series and am fairly sure it's
> in the 8139cp driver. I have a candidate fix that I plan to send in
> a couple of days once I've tested it further and there's no more
> lockups on my hardware.

There seems to be two issues: One it interrupts for every packet when
the 8139cp can hold off and not storm the processor, and there is some
issue with the chip refusing to send small skbs so the network layer
starts locking up/timing out. I was planning to send fixes this
weekend but if your fix is one of those, send your version, cc me and
I'll test it out.

Thanks,

Daniel

Re: [PATCH 0/2] sh: Fix IDE on landisk

[Colton Pawielski]

Hi Daniel,

On Wed, 21 Oct 2026 at 05:55, Daniel Palmer <daniel@0x0f.com> wrote:
> There seems to be two issues: One it interrupts for every packet when
> the 8139cp can hold off and not storm the processor, and there is some
> issue with the chip refusing to send small skbs so the network layer
> starts locking up/timing out. I was planning to send fixes this
> weekend but if your fix is one of those, send your version, cc me and
> I'll test it out.

My fix turned out to be neither of those, so please go ahead and send
yours. It's a race in cp_rx_poll(): napi_complete_done() runs before
cp->lock is taken, so an interrupt in between can leave Rx unmasked
while NAPI is still scheduled, and the level-triggered IRQ then storms
until the board hard-hangs. I've sent it to netdev with you on cc:

https://lore.kernel.org/all/20261021-b4-8139cp-napi-v1-1-c9b683d9564b@gmail.com/

It should be independent of your two fixes. Please cc me when you
send yours and I'll test them on my boards.

Thanks,
Colton