This small series cleans up pata_ep93xx to allow COMPILE_TEST on
non-ARM platforms. Patch 1 avoids including ARM-specific asm headers,
patch 2 switches to unsigned long for the data variable, and patch 3
enables COMPILE_TEST.

Rosen Penev (3):
  ata: pata_ep93xx: avoid asm on non ARM
  ata: pata_ep93xx: use unsigned long for data
  ata: pata_ep93xx: add COMPILE_TEST support

 drivers/ata/Kconfig       | 2 +-
 drivers/ata/pata_ep93xx.c | 7 ++++++-
 2 files changed, 7 insertions(+), 2 deletions(-)

-- 
2.54.0

On Fri, 29 May 2026 17:36:24 -0700, Rosen Penev wrote:
> This small series cleans up pata_ep93xx to allow COMPILE_TEST on
> non-ARM platforms. Patch 1 avoids including ARM-specific asm headers,
> patch 2 switches to unsigned long for the data variable, and patch 3
> enables COMPILE_TEST.
> 
> Rosen Penev (3):
>   ata: pata_ep93xx: avoid asm on non ARM
>   ata: pata_ep93xx: use unsigned long for data
>   ata: pata_ep93xx: add COMPILE_TEST support
> 
> [...]

Hello Rosen,

I applied this series:

Applied to libata/linux.git (for-7.2), thanks!

[1/3] ata: pata_ep93xx: avoid asm on non ARM
      https://git.kernel.org/libata/linux/c/cde1e86e
[2/3] ata: pata_ep93xx: use unsigned long for data
      https://git.kernel.org/libata/linux/c/8bbb394e
[3/3] ata: pata_ep93xx: add COMPILE_TEST support
      https://git.kernel.org/libata/linux/c/590da526



I can see that you have also sent out a bunch of stand-alone patches for
this driver. I'm not sure why you have an interest in this driver
specifically, but considering that a bunch of your fixes were sent out
with only a few minutes apart, I doubt that you can have tested them on
real hardware.

For these ancient drivers, we are mostly interested in real world problems
that you can reproduce on real hardware.

We don't really care that much for theoretical problems reported by AI.
If these problems were serious enough, most likely someone would have
encountered and fixed the problem by now.

One option would be to do like netdev and just remove some of these
ancient PATA drivers.


Kind regards,
Niklas

Hello Rosen,

On Fri, May 29, 2026 at 05:36:24PM -0700, Rosen Penev wrote:
> This small series cleans up pata_ep93xx to allow COMPILE_TEST on
> non-ARM platforms. Patch 1 avoids including ARM-specific asm headers,
> patch 2 switches to unsigned long for the data variable, and patch 3
> enables COMPILE_TEST.
> 
> Rosen Penev (3):
>   ata: pata_ep93xx: avoid asm on non ARM
>   ata: pata_ep93xx: use unsigned long for data
>   ata: pata_ep93xx: add COMPILE_TEST support
> 
>  drivers/ata/Kconfig       | 2 +-
>  drivers/ata/pata_ep93xx.c | 7 ++++++-
>  2 files changed, 7 insertions(+), 2 deletions(-)

Your series looks good to me.

I do not think that you need to address the pre-existing issues reported
by Sashiko.

Intend to wait 1-2 days before picking this up, to hopefully get R-b tag
or two.


Kind regards,
Niklas

On Mon, Jun 1, 2026 at 1:54 AM Niklas Cassel <cassel@kernel.org> wrote:
>
> Hello Rosen,
>
> On Fri, May 29, 2026 at 05:36:24PM -0700, Rosen Penev wrote:
> > This small series cleans up pata_ep93xx to allow COMPILE_TEST on
> > non-ARM platforms. Patch 1 avoids including ARM-specific asm headers,
> > patch 2 switches to unsigned long for the data variable, and patch 3
> > enables COMPILE_TEST.
> >
> > Rosen Penev (3):
> >   ata: pata_ep93xx: avoid asm on non ARM
> >   ata: pata_ep93xx: use unsigned long for data
> >   ata: pata_ep93xx: add COMPILE_TEST support
> >
> >  drivers/ata/Kconfig       | 2 +-
> >  drivers/ata/pata_ep93xx.c | 7 ++++++-
> >  2 files changed, 7 insertions(+), 2 deletions(-)
>
> Your series looks good to me.
>
> I do not think that you need to address the pre-existing issues reported
> by Sashiko.
In retrospect, it might make sense to do so such that those fixes get
backported to stable kernels.
>
> Intend to wait 1-2 days before picking this up, to hopefully get R-b tag
> or two.
>
>
> Kind regards,
> Niklas

On Mon, Jun 01, 2026 at 11:12:33AM -0700, Rosen Penev wrote:
> On Mon, Jun 1, 2026 at 1:54 AM Niklas Cassel <cassel@kernel.org> wrote:
> >
> > Hello Rosen,
> >
> > On Fri, May 29, 2026 at 05:36:24PM -0700, Rosen Penev wrote:
> > > This small series cleans up pata_ep93xx to allow COMPILE_TEST on
> > > non-ARM platforms. Patch 1 avoids including ARM-specific asm headers,
> > > patch 2 switches to unsigned long for the data variable, and patch 3
> > > enables COMPILE_TEST.
> > >
> > > Rosen Penev (3):
> > >   ata: pata_ep93xx: avoid asm on non ARM
> > >   ata: pata_ep93xx: use unsigned long for data
> > >   ata: pata_ep93xx: add COMPILE_TEST support
> > >
> > >  drivers/ata/Kconfig       | 2 +-
> > >  drivers/ata/pata_ep93xx.c | 7 ++++++-
> > >  2 files changed, 7 insertions(+), 2 deletions(-)
> >
> > Your series looks good to me.
> >
> > I do not think that you need to address the pre-existing issues reported
> > by Sashiko.
> In retrospect, it might make sense to do so such that those fixes get
> backported to stable kernels.

Oh, don't get me wrong.

If you want to fix up the pre-existing issues, we are happy to accept
patches :)

I just meant that it is not a prerequisite to get this series merged.


Kind regards,
Niklas

On Mon, Jun 1, 2026 at 11:34 AM Niklas Cassel <cassel@kernel.org> wrote:
>
> On Mon, Jun 01, 2026 at 11:12:33AM -0700, Rosen Penev wrote:
> > On Mon, Jun 1, 2026 at 1:54 AM Niklas Cassel <cassel@kernel.org> wrote:
> > >
> > > Hello Rosen,
> > >
> > > On Fri, May 29, 2026 at 05:36:24PM -0700, Rosen Penev wrote:
> > > > This small series cleans up pata_ep93xx to allow COMPILE_TEST on
> > > > non-ARM platforms. Patch 1 avoids including ARM-specific asm headers,
> > > > patch 2 switches to unsigned long for the data variable, and patch 3
> > > > enables COMPILE_TEST.
> > > >
> > > > Rosen Penev (3):
> > > >   ata: pata_ep93xx: avoid asm on non ARM
> > > >   ata: pata_ep93xx: use unsigned long for data
> > > >   ata: pata_ep93xx: add COMPILE_TEST support
> > > >
> > > >  drivers/ata/Kconfig       | 2 +-
> > > >  drivers/ata/pata_ep93xx.c | 7 ++++++-
> > > >  2 files changed, 7 insertions(+), 2 deletions(-)
> > >
> > > Your series looks good to me.
> > >
> > > I do not think that you need to address the pre-existing issues reported
> > > by Sashiko.
> > In retrospect, it might make sense to do so such that those fixes get
> > backported to stable kernels.
>
> Oh, don't get me wrong.
>
> If you want to fix up the pre-existing issues, we are happy to accept
> patches :)
Just sent. Hopefully no issues this time.
>
> I just meant that it is not a prerequisite to get this series merged.
One of those patches conflicts with the first here.
>
>
> Kind regards,
> Niklas