linuxsh-dev

Re: rts7751r2d cf_ide rework

[Paul M. <le...@li...>]

On Fri, Nov 09, 2007 at 09:36:38PM +0900, Magnus Damm wrote:
> On Nov 8, 2007 8:34 PM, shinkoi2005 <shi...@gm...> wrote:
> > I suspect that your R2D-1 is fpga rev1.0.
> > rev1.0 and rev1.1 IRL table is following.
> 
> Yeah, maybe it is related to fpga version. I sort of assumed that the
> option CONFIG_RTS7751R2D_REV11 was a complicated way of switching
> between R2D-PLUS and R2D-1. But maybe it's related to fpga version as
> you suggest. I have no idea.
> 
This config option predates the creation of the R2D+ board completely, so
it being FPGA-relative would seem logical. Anyways, mapping out the
differing IRL tables depending on FPGA version at boot time isn't much
more of a hassle than the current R2D-1 and R2D+ decoupling.

Re: rts7751r2d cf_ide rework

[Magnus D. <mag...@gm...>]

Hi there,

Thanks for the reply!

On Nov 8, 2007 8:34 PM, shinkoi2005 <shi...@gm...> wrote:
>  > Aoi Shinkai, are you there? Does CF work for you with rc2 on R2D-1?
> CF works fine with vanilla 2.6.24-rc2 on R2D-1.
> (R2D-1 can boot from CF's rootfs with vanilla 2.6.24-rc2.)

I'm glad that it works on your R2D-1. Both my R2D-1 boards do not have
working CF. Just to double-check - are using a R2D with one or two pci
slots?

> I suspect that your R2D-1 is fpga rev1.0.
> rev1.0 and rev1.1 IRL table is following.

Yeah, maybe it is related to fpga version. I sort of assumed that the
option CONFIG_RTS7751R2D_REV11 was a complicated way of switching
between R2D-PLUS and R2D-1. But maybe it's related to fpga version as
you suggest. I have no idea.

> (That is taken from old include/asm-sh/rts7751r2d.h.)
>
> ------
> #if defined(CONFIG_RTS7751R2D_REV11)
> #define IRQ_PCIETH     0               /* PCI Ethernet IRQ */
> #define IRQ_CFCARD     1               /* CF Card IRQ */
> #define IRQ_CFINST     2               /* CF Card Insert IRQ */
> #define IRQ_PCMCIA     3               /* PCMCIA IRQ */
> #define IRQ_VOYAGER    4               /* VOYAGER IRQ */
> #define IRQ_ONETH      5               /* On board Ethernet IRQ */
> #else
> #define IRQ_KEYIN      0               /* Key Input IRQ */
> #define IRQ_PCIETH     1               /* PCI Ethernet IRQ */
> #define IRQ_CFCARD     2               /* CF Card IRQ */
> #define IRQ_CFINST     3               /* CF Card Insert IRQ */
> #define IRQ_PCMCIA     4               /* PCMCIA IRQ */
> #define IRQ_VOYAGER    5               /* VOYAGER IRQ */
> #endif

Right. It looks like the IRL level should differ, but I get the same
IRL level for both R2D-1 and R2D-PLUS.  Maybe my R2D-1 boards are
special...

> And I guess that recent implementation is only for rev1.1.

Not sure which revision, but everything except CF works for my R2D-1
and R2D-PLUS boards...

> I think that it's worth changing IRL table for rev1.0....

Sure, if that what it takes. I need to look into this more.

Can you please post the BVERREG and VERREG register values from your
R2D-1? Then I'll post mine when I get back into the office.

Have a nice weekend!

/ magnus

[GIT PULL] sh updates for 2.6.24-rc3

[Paul M. <le...@li...>]

The only thing of note here (depending on whether one has a sadistic
inclination towards page colouring or not) is basically some of the
kmap_coherent() interfacing which fixes up regressions observed on some
old parts with 2-way aliasing VIPT dcaches. The clear_user_highpage() and
copy_user_highpage() bits are more or less directly adapted from MIPS,
with the PG_dcache_dirty/PG_mapped logic for lazy dcache writeback
flipped. These particular regressions started showing up in 2.6.23 after
the initial interface was merged. The rest is just idle bug fixing and
killing off some dead code.

sh64 also had a total of 1 trivial changeset, so that got pulled in to
this update as well for general completeness.

Please pull from:

	master.kernel.org:/pub/scm/linux/kernel/git/lethal/sh-2.6.git

Which contains:

Jiri Olsa (1):
      sh: remove dead config symbols from SH code

Mike Frysinger (1):
      sh: remove PTRACE_O_TRACESYSGOOD from asm/ptrace.h

Nobuhiro Iwamatsu (4):
      sh: Add SH7705 and other to the support of Solution Engine.
      sh: Fix compression method when making uImage.
      sh: Remove SCI_NPORTS from sh-sci.h
      sh: Fix heartbeart on Solution Engine series

Paul Mundt (22):
      sh64: Kill off duplicate includes.
      sh: Kill off duplicate includes.
      sh: ubc wakeup for SH-4 only.
      sh: Fix up kgdb-on-NMI branch target.
      sh: Export __{s,u}divsi3_i4i on all CPUs.
      sh: Fix up kgdb build with modular sh-sci.
      sh: Add -Werror for clean directories.
      sh: kgdb sysrq depends on magic sysrq.
      superhyway: Handle device_register() retval properly.
      sh: Kill off the remaining ST40 cruft.
      sh: Wire up clear_user_highpage().
      sh: Optimized copy_{to,from}_user_page() for SH-4.
      sh: Kill off __{copy,clear}_user_page().
      sh: hs7751rvoip: irq.c needs linux/interrupt.h.
      sh: hs7751rvoip: Kill off dead IPR IRQ mappings.
      sh: Fix up PAGE_KERNEL_PCC() for nommu.
      rtc: sh-rtc: Handle rtc_device_register() failure properly.
      rtc: rtc-sh: Zero out tm value for invalid rtc states.
      sh: Add a dummy vga.h.
      sh: Kill off broken snapgear ds1302 code.
      Merge branch 'page_colouring_despair'
      Merge master.kernel.org:/.../lethal/sh64-2.6

 arch/sh/Kconfig                             |   10 +-
 arch/sh/Kconfig.debug                       |    3 +-
 arch/sh/boards/renesas/hs7751rvoip/irq.c    |    1 +
 arch/sh/boards/renesas/hs7751rvoip/setup.c  |   19 +-
 arch/sh/boards/renesas/sh7710voipgw/setup.c |    1 -
 arch/sh/boards/se/7206/irq.c                |    1 -
 arch/sh/boards/se/770x/setup.c              |    1 +
 arch/sh/boards/se/7722/setup.c              |    8 +
 arch/sh/boards/se/7780/setup.c              |    8 +
 arch/sh/boards/snapgear/Makefile            |    3 +-
 arch/sh/boards/snapgear/rtc.c               |  309 -----------------
 arch/sh/boards/snapgear/setup.c             |   16 +-
 arch/sh/boot/Makefile                       |    2 +-
 arch/sh/cchips/hd6446x/Makefile             |    2 +
 arch/sh/cchips/voyagergx/Makefile           |    1 +
 arch/sh/drivers/pci/Makefile                |    1 -
 arch/sh/drivers/pci/pci-st40.c              |  488 ---------------------------
 arch/sh/drivers/pci/pci-st40.h              |  136 --------
 arch/sh/kernel/Makefile                     |    3 +-
 arch/sh/kernel/cpu/sh3/ex.S                 |    2 +-
 arch/sh/kernel/cpu/sh4/probe.c              |    8 -
 arch/sh/kernel/irq.c                        |    1 -
 arch/sh/kernel/kgdb_stub.c                  |    9 +-
 arch/sh/kernel/setup.c                      |    1 -
 arch/sh/kernel/sh_ksyms.c                   |    2 -
 arch/sh/lib/Makefile                        |    2 +
 arch/sh/mm/Kconfig                          |   21 +--
 arch/sh/mm/Makefile                         |    2 +
 arch/sh/mm/clear_page.S                     |   45 ---
 arch/sh/mm/copy_page.S                      |   61 ----
 arch/sh/mm/pg-sh4.c                         |   75 +++--
 arch/sh/oprofile/Makefile                   |    1 +
 arch/sh64/kernel/process.c                  |   10 +-
 arch/sh64/kernel/traps.c                    |    5 -
 drivers/rtc/rtc-sh.c                        |    6 +-
 drivers/serial/sh-sci.h                     |   19 +-
 drivers/sh/superhyway/superhyway.c          |    7 +-
 include/asm-sh/cacheflush.h                 |   18 +-
 include/asm-sh/cpu-sh3/timer.h              |    6 +-
 include/asm-sh/page.h                       |   11 +-
 include/asm-sh/pgtable.h                    |    4 +-
 include/asm-sh/processor.h                  |    2 +-
 include/asm-sh/ptrace.h                     |    3 -
 include/asm-sh/vga.h                        |    6 +
 include/asm-sh64/ptrace.h                   |    2 -
 45 files changed, 148 insertions(+), 1194 deletions(-)

Re: [PATCH] SH - remove dead config symbol from SH code

[Paul M. <le...@li...>]

On Thu, Nov 08, 2007 at 06:17:45PM +0100, Jiri Olsa wrote:
> remove dead config symbols from SH code
> Signed-off-by: Jiri Olsa <ols...@gm...>
> 
Applied, thanks.

Re: [PATCH 1/2 take #2] libata: Support PIO polling-only hosts.

[Jeff G. <je...@ga...>]

On Thu, Nov 08, 2007 at 11:14:56AM +0900, Paul Mundt wrote:
> By default ata_host_activate() expects a valid IRQ in order to
> successfully register the host. This patch enables a special case
> for registering polling-only hosts that either don't have IRQs
> or have buggy IRQ generation (either in terms of handling or
> sensing), which otherwise work fine.
> 
> Hosts that want to use polling mode can simply set ATA_FLAG_PIO_POLLING
> and pass in an invalid IRQ.
> 
> Signed-off-by: Paul Mundt <le...@li...>
> 

applied 1-2

Re: rts7751r2d cf_ide rework

[shinkoi2005 <shi...@gm...>]

 > Aoi Shinkai, are you there? Does CF work for you with rc2 on R2D-1?
CF works fine with vanilla 2.6.24-rc2 on R2D-1.
(R2D-1 can boot from CF's rootfs with vanilla 2.6.24-rc2.)

I suspect that your R2D-1 is fpga rev1.0.
rev1.0 and rev1.1 IRL table is following.
(That is taken from old include/asm-sh/rts7751r2d.h.)

------
#if defined(CONFIG_RTS7751R2D_REV11)
#define IRQ_PCIETH     0               /* PCI Ethernet IRQ */
#define IRQ_CFCARD     1               /* CF Card IRQ */
#define IRQ_CFINST     2               /* CF Card Insert IRQ */
#define IRQ_PCMCIA     3               /* PCMCIA IRQ */
#define IRQ_VOYAGER    4               /* VOYAGER IRQ */
#define IRQ_ONETH      5               /* On board Ethernet IRQ */
#else
#define IRQ_KEYIN      0               /* Key Input IRQ */
#define IRQ_PCIETH     1               /* PCI Ethernet IRQ */
#define IRQ_CFCARD     2               /* CF Card IRQ */
#define IRQ_CFINST     3               /* CF Card Insert IRQ */
#define IRQ_PCMCIA     4               /* PCMCIA IRQ */
#define IRQ_VOYAGER    5               /* VOYAGER IRQ */
#endif
#define IRQ_RTCALM     6               /* RTC Alarm IRQ */
#define IRQ_RTCTIME    7               /* RTC Timer IRQ */
#define IRQ_SDCARD     8               /* SD Card IRQ */
#define IRQ_PCISLOT1   9               /* PCI Slot #1 IRQ */
#define IRQ_PCISLOT2   10              /* PCI Slot #2 IRQ */
#define IRQ_EXTENTION   11              /* EXTn IRQ */
-------

And I guess that recent implementation is only for rev1.1.

arch/sh/boards/renesas/rts7751r2d/irq.c:L65
-------
/* IRLn to IRQ table for R2D-1 */
static unsigned char irl2irq_r2d_1[R2D_NR_IRL] __initdata = {
         IRQ_PCI_INTD, IRQ_CF_IDE, IRQ_CF_CD, IRQ_PCI_INTC,
         IRQ_VOYAGER, IRQ_AX88796, IRQ_RTC_A, IRQ_RTC_T,
         IRQ_SDCARD, IRQ_PCI_INTA, IRQ_PCI_INTB, IRQ_EXT,
         IRQ_TP,
};
-------

I think that it's worth changing IRL table for rev1.0....

Re: [PATCH 1/2 take #2] libata: Support PIO polling-only hosts.

[Alan C. <al...@lx...>]

On Thu, 8 Nov 2007 11:14:56 +0900
Paul Mundt <le...@li...> wrote:

> By default ata_host_activate() expects a valid IRQ in order to
> successfully register the host. This patch enables a special case
> for registering polling-only hosts that either don't have IRQs
> or have buggy IRQ generation (either in terms of handling or
> sensing), which otherwise work fine.
> 
> Hosts that want to use polling mode can simply set ATA_FLAG_PIO_POLLING
> and pass in an invalid IRQ.
> 
> Signed-off-by: Paul Mundt <le...@li...>

Acked-by: Alan Cox <al...@re...>


May need to tweak polled isapnp support (or add it) to avoid the WARN but
I will take care of it

Re: rts7751r2d cf_ide rework

[Paul M. <le...@li...>]

On Thu, Nov 08, 2007 at 05:30:08PM +0900, Magnus Damm wrote:
> On Nov 7, 2007 12:06 PM, Paul Mundt <le...@li...> wrote:
> > On Wed, Nov 07, 2007 at 11:38:42AM +0900, Magnus Damm wrote:
> > > I'm guessing that something is wrong with trigger level. The R2D-1
> > > documentation does say something about the CF IDE interrupt level to
> > > be H while the rest of the sources are L what ever that means. I don't
> > > think we can control it in the FPGA either.
> > >
> > That suggestions that R2D-1 is using level high. It's possible to set the
> > sense selection on this already at request_irq() time, blackfin ended up
> > having to do this, and so added the ability to pass on IRQ flags via
> > private data. See pata_platform_info->irq_flags in linux/pata_platform.h.
> > I suppose we should be setting the sense selection level high for all of
> > the R2D boards, in that case.
> 
> But does setting these flags really change anything in the interrupt
> code? There are unfortunately no registers to set the actual sense
> configuration in the fpga so whatever you pass to request_irq() will
> be ignored since we have no means to change the sense settings.
> 
No, if the IRQ controller has no ability to change the sense selection,
there's not a lot we can do with it.

FPGAs being uselessly implemented are unfortunately nothing new, and
neither are hardware designers screwing up IRQ assignments. We already
have plenty of cases where edge-only SuperIOs are interfaced to
level-only pins, leading to ethernet performance comparable to SLIP on a
broken serial cable.

At least we can fix the FPGAs. Fixing the hardware designers is generally
socially frowned upon ;-)

Re: rts7751r2d cf_ide rework

[Magnus D. <mag...@gm...>]

On Nov 7, 2007 12:06 PM, Paul Mundt <le...@li...> wrote:
> On Wed, Nov 07, 2007 at 11:38:42AM +0900, Magnus Damm wrote:
> > On Nov 7, 2007 8:49 AM, Paul Mundt <le...@li...> wrote:
> > > On Tue, Nov 06, 2007 at 08:43:16PM +0900, Magnus Damm wrote:
> > > > I happen to have two of these R2D-1 boards and I can't get CF working
> > > > using the latest kernel (latest sh-2.6 git, post 2.6.24-rc1) :
> > > >
> > > > ...
> > > > irq 107: nobody cared (try booting with the "irqpoll" option)
> > > > [stack dump]
> > > > [call trace]
> > > > handlers:
> > > > [<8c24f660>] (ata_interrupt+0x0/0x240)
> > > > Disabling IRQ #107
> > > > ...
> > > >
> > > Did R2D-1 CF work for you with IRQs prior to this change? And does
> > > reverting it fix get R2D-1 CF working again? The nobody cared thing is
> > > curious, if you can provide the stack dump/call trace and register state
> > > it might shed some light on why ata_interrupt isn't handling it.
> >
> > The CF for R2D-1 was disabled without this patch - mainly because I
> > had trouble trying to use it. I thought it had something to do with
> > the access size and this patch would solve it, but apparently not. I
> > wonder if CF support in 2.6.24-rc2 works on R2D-1 for other people...
> >
> The access size problem causes a bus lock, so that's still a problem,
> even if IRQs are hosed.

Sure. But the author of this patch - Aoi Shinkai - claims that he
could use a root file system on CF so I assume that he had something
working there.

Aoi Shinkai, are you there? Does CF work for you with rc2 on R2D-1?

> > I'm guessing that something is wrong with trigger level. The R2D-1
> > documentation does say something about the CF IDE interrupt level to
> > be H while the rest of the sources are L what ever that means. I don't
> > think we can control it in the FPGA either.
> >
> That suggestions that R2D-1 is using level high. It's possible to set the
> sense selection on this already at request_irq() time, blackfin ended up
> having to do this, and so added the ability to pass on IRQ flags via
> private data. See pata_platform_info->irq_flags in linux/pata_platform.h.
> I suppose we should be setting the sense selection level high for all of
> the R2D boards, in that case.

But does setting these flags really change anything in the interrupt
code? There are unfortunately no registers to set the actual sense
configuration in the fpga so whatever you pass to request_irq() will
be ignored since we have no means to change the sense settings.

> > > > I can get things working by hacking in code to enable polling in
> > > > pata_platform.c though, so I assume that the IO-ports are ok.
> > > >
> > > It might be worthwhile making the polling configurable, if you want to
> > > tidy up a patch for that we can see if it's something work abstracting.
> > > It's handy for debugging, at least.
> >
> > The generic ata code needed an IRQ last time i checked. Otherwise i'd
> > prefer to not set the interrupt in the platform data to enable
> > polling. In the end the only thing required is this (mangled patch
> > hunk):
> >
> That's easy enough to fix. How about this?

Looks good. I have not tested your patch, but I'd be happy to see such
a feature go in. I happen to know a few different boards that would be
more than happy to make use of this kind of feature...

Thanks.

/ magnus

Re: CF problem on sh3 (620lx/660lx hp machines)

[Magnus D. <mag...@gm...>]

Hi there,

On Nov 7, 2007 11:36 PM, Rafael Ignacio Zurita <riz...@ya...> wrote:
> Hello,
>   We have not fixed a problem with CF and libata on
> old sh3 hp machines (620lx and 660lx at least) which
> gives us a "qc timeout" on boot time.
>
>   I know that the patch below fixes that one,
> but I don't know how we should solve that problem
> in the correct way.
>
> Any idea?

Yes, I suspect this is because IRQs are not configured properly on
your platform. I may be wrong, but I think older kernels may have used
PINT for CF IRQs. The SH3 PINT code was removed a while ago since it
didn't compile anymore. So now you are most likely without working
interrupt support for devices that are hooked up to the PINT
controller.

Enabling polling in the ata code is of course one option, but fixing
up the interrupts sounds like the proper way to fix this imo...

I'd like to help you guys and add working PINT support to the kernel,
but first someone has to figure out how the CF interrupt is connected
to the processor. Which pin basically. If someone can find that then
we have something to work with.

I don't have any such HP hardware myself, so it's kind of difficult
for me to solve this alone. If CF support used to work at some point
then a complete working kernel with source would help as well.

Thanks,

/ magnus

Re: [patch] audit support for SH

[Yuichi N. <yn...@hi...>]

On Wed, 7 Nov 2007 10:15:33 -0500
Steve Grubb  wrote:
> On Wednesday 07 November 2007 12:04:46 am Yuichi Nakamura wrote:
> > I found syscall audit does not work on SH(SuperH).
> > I made patch to support syscall audit for SH.
> 
> I think this is close, but it looks like you missed the syscall classification 
> piece. You can find an example here:
> 
> arch/x86_64/kernel/audit.c
> 
> Its used for determining which syscalls we are interested in for watches. 
Thanks, I did not know that.
arch/sh is 32 bit only, so I think lib/audit.c is enough for sh.


> Also, IBM and HP both have released audit test suites. You should run the CAPP 
> tests at a minimum to see if you have hooked everything that is expected. If 
> you have SE Linux enabled for that platform, you may want to try the LSPP 
> tests but you would need have the MLS policy installed.
> 
> IBM's announcement is here:
> 
> https://www.redhat.com/archives/redhat-lspp/2007-August/msg00002.html
> 
> and HP's here:
> 
> https://www.redhat.com/archives/linux-audit/2007-August/msg00030.html
> 
> And...user space would need an update for the syscall table and arches so that 
> you can run the tests. Please send that patch to linux-audit mail list.
> 
> Thanks,
> -Steve

-- 
Yuichi Nakamura
Hitachi Software Engineering Co., Ltd.
Japan SELinux Users Group(JSELUG): http://www.selinux.gr.jp/
SELinux Policy Editor: http://seedit.sourceforge.net/

Re: 2.6.23: random segfaults

[Manuel L. <ma...@ro...>]

> I look forward to the day when the L1 dcache set associativity doubles
> again, so we can avoid all of this colouring tedium in the future. On
> 4-way it's already a bit of a toss-up. Now if only people would stop
> using antiquated direct-mapped and 2-way CPUs.. ;-)

That might start when Renesas actually ships those things outside of
Japan ;-) (Actually it depends on the business unit: The SHMobile chips
(7722/7723) are apparently _way_ easier to get than the 7780 series)

	Manuel Lauss

Re: 2.6.23: random segfaults

[Paul M. <le...@li...>]

On Thu, Nov 08, 2007 at 08:26:20AM +0100, Manuel Lauss wrote:
> On Mon, Nov 05, 2007 at 04:37:07PM +0900, Paul Mundt wrote:
> > Well, no luck reproducing things on SH7751R or SH7760. If you have a
> > reproduceable workload, that would really help.
> > 
> > On the other hand, there was at least one bug in the page colouring, so
> > I've ripped out the old code and made the kmap_coherent() interface more
> > consistently used. This implementation can still be optimized with
> > regards to the page's dcache state, but I'm more concerned about
> > correctness at the moment. See how the following patch works for you.
> 
> The patch seems to help. The GCC build has not finished yet but is in the
> final stages; if there were problems it would've failed a _lot_ sooner.
> 
> Thank you very much!
> 
Good to hear, I'll queue this for -rc3 then. Magnus still reports a bug
with 4k pages on SH7751R, which doesn't show up when using 64k pages, so
there may still be some issues to iron out on certain workloads.

There are also some additional patches to switch the lazy D-cache
writeback method for even lazier writeback, but these are 2.6.25 material
at this point, especially since SH7751R may still have some issues with
the current interface.

I look forward to the day when the L1 dcache set associativity doubles
again, so we can avoid all of this colouring tedium in the future. On
4-way it's already a bit of a toss-up. Now if only people would stop
using antiquated direct-mapped and 2-way CPUs.. ;-)

Re: 2.6.23: random segfaults

[Manuel L. <ma...@ro...>]

Hello Paul,

On Mon, Nov 05, 2007 at 04:37:07PM +0900, Paul Mundt wrote:
> On Wed, Oct 17, 2007 at 12:32:45PM -0400, Mike Frysinger wrote:
> > On Wednesday 17 October 2007, Paul Mundt wrote:
> > i'm seeing random crashes on my lantank running 2.6.23 ... rebooting into 
> > 2.6.16.xx works fine.
> > 
> > that has a SH7751R with 2-way caches in write-back mode ... havent had time to 
> Well, no luck reproducing things on SH7751R or SH7760. If you have a
> reproduceable workload, that would really help.
> 
> On the other hand, there was at least one bug in the page colouring, so
> I've ripped out the old code and made the kmap_coherent() interface more
> consistently used. This implementation can still be optimized with
> regards to the page's dcache state, but I'm more concerned about
> correctness at the moment. See how the following patch works for you.

The patch seems to help. The GCC build has not finished yet but is in the
final stages; if there were problems it would've failed a _lot_ sooner.

Thank you very much!

	Manuel Lauss

[PATCH 2/2 take #2] libata: pata_platform: Support polling-mode configuration.

[Paul M. <le...@li...>]

Some SH boards (old R2D-1 boards) have generally not had working CF
under libata, due to both buswidth issues (handled by Aoi Shinkai
in 43f4b8c7578b928892b6f01d374346ae14e5eb70), and buggy interrupt
controllers. For these sorts of boards simply disabling the IRQ and
polling ends up working fine.

This conditionalizes the IRQ resource for pata_platform and lets
platforms that want to use polling mode simply omit the resource
entirely.

Signed-off-by: Paul Mundt <le...@li...>

---

 drivers/ata/pata_platform.c |   35 ++++++++++++++++++++++++++++-------
 1 file changed, 28 insertions(+), 7 deletions(-)

diff --git a/drivers/ata/pata_platform.c b/drivers/ata/pata_platform.c
index fc72a96..ac03a90 100644
--- a/drivers/ata/pata_platform.c
+++ b/drivers/ata/pata_platform.c
@@ -1,7 +1,7 @@
 /*
  * Generic platform device PATA driver
  *
- * Copyright (C) 2006  Paul Mundt
+ * Copyright (C) 2006 - 2007  Paul Mundt
  *
  * Based on pata_pcmcia:
  *
@@ -22,7 +22,7 @@
 #include <linux/pata_platform.h>
 
 #define DRV_NAME "pata_platform"
-#define DRV_VERSION "1.1"
+#define DRV_VERSION "1.2"
 
 static int pio_mask = 1;
 
@@ -120,15 +120,20 @@ static void pata_platform_setup_port(struct ata_ioports *ioaddr,
  *	Register a platform bus IDE interface. Such interfaces are PIO and we
  *	assume do not support IRQ sharing.
  *
- *	Platform devices are expected to contain 3 resources per port:
+ *	Platform devices are expected to contain at least 2 resources per port:
  *
  *		- I/O Base (IORESOURCE_IO or IORESOURCE_MEM)
  *		- CTL Base (IORESOURCE_IO or IORESOURCE_MEM)
+ *
+ *	and optionally:
+ *
  *		- IRQ	   (IORESOURCE_IRQ)
  *
  *	If the base resources are both mem types, the ioremap() is handled
  *	here. For IORESOURCE_IO, it's assumed that there's no remapping
  *	necessary.
+ *
+ *	If no IRQ resource is present, PIO polling mode is used instead.
  */
 static int __devinit pata_platform_probe(struct platform_device *pdev)
 {
@@ -137,11 +142,12 @@ static int __devinit pata_platform_probe(struct platform_device *pdev)
 	struct ata_port *ap;
 	struct pata_platform_info *pp_info;
 	unsigned int mmio;
+	int irq;
 
 	/*
 	 * Simple resource validation ..
 	 */
-	if (unlikely(pdev->num_resources != 3)) {
+	if ((pdev->num_resources != 3) && (pdev->num_resources != 2)) {
 		dev_err(&pdev->dev, "invalid number of resources\n");
 		return -EINVAL;
 	}
@@ -173,6 +179,13 @@ static int __devinit pata_platform_probe(struct platform_device *pdev)
 		(ctl_res->flags == IORESOURCE_MEM));
 
 	/*
+	 * And the IRQ
+	 */
+	irq = platform_get_irq(pdev, 0);
+	if (irq < 0)
+		irq = 0;	/* no irq */
+
+	/*
 	 * Now that that's out of the way, wire up the port..
 	 */
 	host = ata_host_alloc(&pdev->dev, 1);
@@ -185,6 +198,14 @@ static int __devinit pata_platform_probe(struct platform_device *pdev)
 	ap->flags |= ATA_FLAG_SLAVE_POSS;
 
 	/*
+	 * Use polling mode if there's no IRQ
+	 */
+	if (!irq) {
+		ap->flags |= ATA_FLAG_PIO_POLLING;
+		ata_port_desc(ap, "no IRQ, using PIO polling");
+	}
+
+	/*
 	 * Handle the MMIO case
 	 */
 	if (mmio) {
@@ -213,9 +234,9 @@ static int __devinit pata_platform_probe(struct platform_device *pdev)
 		      (unsigned long long)ctl_res->start);
 
 	/* activate */
-	return ata_host_activate(host, platform_get_irq(pdev, 0),
-				 ata_interrupt, pp_info ? pp_info->irq_flags
-				 : 0, &pata_platform_sht);
+	return ata_host_activate(host, irq, irq ? ata_interrupt : NULL,
+				 pp_info ? pp_info->irq_flags : 0,
+				 &pata_platform_sht);
 }
 
 /**

[PATCH 1/2 take #2] libata: Support PIO polling-only hosts.

[Paul M. <le...@li...>]

By default ata_host_activate() expects a valid IRQ in order to
successfully register the host. This patch enables a special case
for registering polling-only hosts that either don't have IRQs
or have buggy IRQ generation (either in terms of handling or
sensing), which otherwise work fine.

Hosts that want to use polling mode can simply set ATA_FLAG_PIO_POLLING
and pass in an invalid IRQ.

Signed-off-by: Paul Mundt <le...@li...>

---

 drivers/ata/libata-core.c |   10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c
index ec3ce12..89fd0e9 100644
--- a/drivers/ata/libata-core.c
+++ b/drivers/ata/libata-core.c
@@ -7178,6 +7178,10 @@ int ata_host_register(struct ata_host *host, struct scsi_host_template *sht)
  *	request IRQ and register it.  This helper takes necessasry
  *	arguments and performs the three steps in one go.
  *
+ *	An invalid IRQ skips the IRQ registration and expects the host to
+ *	have set polling mode on the port. In this case, @irq_handler
+ *	should be NULL.
+ *
  *	LOCKING:
  *	Inherited from calling layer (may sleep).
  *
@@ -7194,6 +7198,12 @@ int ata_host_activate(struct ata_host *host, int irq,
 	if (rc)
 		return rc;
 
+	/* Special case for polling mode */
+	if (!irq) {
+		WARN_ON(irq_handler);
+		return ata_host_register(host, sht);
+	}
+
 	rc = devm_request_irq(host->dev, irq, irq_handler, irq_flags,
 			      dev_driver_string(host->dev), host);
 	if (rc)

Re: [PATCH 1/2] libata: Support PIO polling-only hosts.

[Alan C. <al...@lx...>]

> So I'll change the check to IRQ#0 == invalid, but if that's to be
> enforced kernel-wide, then all of the existing NO_IRQ cases should be
> ripped out and set to 0. This way at least people are getting screwed
> consistently, rather than just in particular subsystems.

Thats been gradually happening. Its now pretty clean except for powerpc
and odd bits of ARM stuff

Alan

Re: [patch] audit support for SH

[Paul M. <le...@li...>]

On Wed, Nov 07, 2007 at 10:15:33AM -0500, Steve Grubb wrote:
> On Wednesday 07 November 2007 12:04:46 am Yuichi Nakamura wrote:
> > I found syscall audit does not work on SH(SuperH).
> > I made patch to support syscall audit for SH.
> 
> I think this is close, but it looks like you missed the syscall classification 
> piece. You can find an example here:
> 
> arch/x86_64/kernel/audit.c
> 
> Its used for determining which syscalls we are interested in for watches. 
> 
Looking at this, it seems like the classification stuff for 32-bit is
generic, it's just the compat bits that are special cased and wrap back
in through the 32-bit classifier.

Is there any point in keeping the 32-bit audit.c rather than simply
moving it to kernel/ or lib/ and leaving the arch/ bits as compat
wrappers only?

At least powerpc, x86, and ia64 look like they could go that way.

Re: [PATCH 1/2] libata: Support PIO polling-only hosts.

[Alan C. <al...@lx...>]

> > Zero is "no IRQ", please use that for polling not "< 0"
> > 
> However, platform_get_irq() will happily return IRQ#0, and it's a valid
> vector on plenty of machines. NO_IRQ is also < 0 on at least FR-V, ARM,
> blackin, PA-RISC, some PowerPC, and even IDE.

No it is not. The platform IRQ code is responsible for ensuring that 0 is
not a real IRQ and doing any neccessary remapping.

Large parts of the kernel assume that
	-	IRQ 0 is "no IRQ assigned" (serial, pci, ide etc )
	-	IRQ is *unsigned*

> We do have some devices that are physically on IRQ#0 that otherwise work
> fine, they aren't ATA devices mind you, but to claim that IRQ#0 isn't a
> valid vector is not in line with what hardware actually does, whether
> it's a good idea or not. In our case the IRQ vector maps to an exception
> offset, which we bump down to zero. We could force an off-by-1 there so
> that the math that indexes IRQ#0 is bumped up one, but that entails
> fixing up every one of our IRQ numbers for no obvious gain.
> 
> I don't really see any value in purposely crippling the range of
> allowable vectors for these machines. Though I don't mind switching to a
> NO_IRQ comparison instead of the < 0 case, so both can be handled.

NO_IRQ is an obsolete old-IDE hack.

http://www.uwsg.indiana.edu/hypermail/linux/kernel/0511.2/2197.html

http://www.uwsg.indiana.edu/hypermail/linux/kernel/0511.2/1789.html

Alan

Re: CF problem on sh3 (620lx/660lx hp machines)

[Paul M. <le...@li...>]

On Wed, Nov 07, 2007 at 06:36:32AM -0800, Rafael Ignacio Zurita wrote:
> Hello,
>   We have not fixed a problem with CF and libata on
> old sh3 hp machines (620lx and 660lx at least) which
> gives us a "qc timeout" on boot time.
> 
>   I know that the patch below fixes that one,
> but I don't know how we should solve that problem
> in the correct way.
> 
For starters, this is horribly line wrapped. Please fix your mailer.

Re: [PATCH 1/2] libata: Support PIO polling-only hosts.

[Paul M. <le...@li...>]

On Wed, Nov 07, 2007 at 09:09:30AM -0500, Mark Lord wrote:
> Paul Mundt wrote:
> >On Wed, Nov 07, 2007 at 01:09:40PM +0000, Alan Cox wrote:
> >>On Wed, 7 Nov 2007 17:10:52 +0900
> >>Paul Mundt <le...@li...> wrote:
> >>>By default ata_host_activate() expects a valid IRQ in order to
> >>>successfully register the host. This patch enables a special case
> >>>for registering polling-only hosts that either don't have IRQs
> >>>or have buggy IRQ generation (either in terms of handling or
> >>>sensing), which otherwise work fine.
> >>>
> >>>Hosts that want to use polling mode can simply set ATA_FLAG_PIO_POLLING
> >>>and pass in a NULL IRQ handler or invalid (< 0) IRQ.
> >>NAK
> >>
> >>Zero is "no IRQ", please use that for polling not "< 0"
> >>
> >However, platform_get_irq() will happily return IRQ#0, and it's a valid
> >vector on plenty of machines. NO_IRQ is also < 0 on at least FR-V, ARM,
> >blackin, PA-RISC, some PowerPC, and even IDE.
> 
> Too bad.  The Penultimate Penguin wants zero to continue to mean "no IRQ".
> 
> Dig into the archives for multiple threads on this exact topic.
> The end result is that "0" means "no IRQ".  If your physical IRQ actually
> is the number 0, then reencode it to some other value for this purpose.
> 
I've read the threads, but this does little to do with the fact it's
still a perfectly valid vector, and I'm not about to force every IRQ
vector on my platform off-by-1 in order to satisfy a religious point of
view with zero reflection on what the hardware actually looks like.

So I'll change the check to IRQ#0 == invalid, but if that's to be
enforced kernel-wide, then all of the existing NO_IRQ cases should be
ripped out and set to 0. This way at least people are getting screwed
consistently, rather than just in particular subsystems.

> Yes, a bit of pain, but that's how many parts of the kernel expect it,

Just as many parts of the kernel make no such assumption.

> and in the end it's no more overall hassle than doing it differently might
> have been.
> 
Spoken like someone who doesn't have to contend with off-by-1 IRQ
vectors as a result of an entirely cosmetic change. It's certainly easier
to parrot a party line when you aren't being bitten by it.

So again, I'll make the change, but it's utter nonsense.

CF problem on sh3 (620lx/660lx hp machines)

[Rafael I. Z. <riz...@ya...>]

Hello,
  We have not fixed a problem with CF and libata on
old sh3 hp machines (620lx and 660lx at least) which
gives us a "qc timeout" on boot time.

  I know that the patch below fixes that one,
but I don't know how we should solve that problem
in the correct way.

Any idea?
Regards

--- a/drivers/ata/libata-core.c 2007-11-07
11:07:18.000000000 -0300
+++ b/drivers/ata/libata-core.c 2007-11-07
11:11:23.000000000 -0300
@@ -327,7 +327,7 @@ int ata_build_rw_tf(struct
ata_taskfile 
                    u64 block, u32 n_block, unsigned
int tf_flags,
                    unsigned int tag)
 {
-       tf->flags |= ATA_TFLAG_ISADDR |
ATA_TFLAG_DEVICE;
+       tf->flags |= ATA_TFLAG_ISADDR |
ATA_TFLAG_DEVICE | ATA_TFLAG_POLLING;
        tf->flags |= tf_flags;
 
        if (ata_ncq_enabled(dev) && likely(tag !=
ATA_TAG_INTERNAL)) {
@@ -4502,7 +4502,7 @@ static unsigned int
ata_dev_init_params(
 
        ata_tf_init(dev, &tf);
        tf.command = ATA_CMD_INIT_DEV_PARAMS;
-       tf.flags |= ATA_TFLAG_ISADDR |
ATA_TFLAG_DEVICE;
+       tf.flags |= ATA_TFLAG_ISADDR |
ATA_TFLAG_DEVICE | ATA_TFLAG_POLLING;
        tf.protocol = ATA_PROT_NODATA;
        tf.nsect = sectors;
        tf.device |= (heads - 1) & 0x0f; /* max head =
num. of heads - 1 */



__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

Re: [PATCH 1/2] libata: Support PIO polling-only hosts.

[Paul M. <le...@li...>]

On Wed, Nov 07, 2007 at 01:09:40PM +0000, Alan Cox wrote:
> On Wed, 7 Nov 2007 17:10:52 +0900
> Paul Mundt <le...@li...> wrote:
> > By default ata_host_activate() expects a valid IRQ in order to
> > successfully register the host. This patch enables a special case
> > for registering polling-only hosts that either don't have IRQs
> > or have buggy IRQ generation (either in terms of handling or
> > sensing), which otherwise work fine.
> > 
> > Hosts that want to use polling mode can simply set ATA_FLAG_PIO_POLLING
> > and pass in a NULL IRQ handler or invalid (< 0) IRQ.
> 
> NAK
> 
> Zero is "no IRQ", please use that for polling not "< 0"
> 
However, platform_get_irq() will happily return IRQ#0, and it's a valid
vector on plenty of machines. NO_IRQ is also < 0 on at least FR-V, ARM,
blackin, PA-RISC, some PowerPC, and even IDE.

We do have some devices that are physically on IRQ#0 that otherwise work
fine, they aren't ATA devices mind you, but to claim that IRQ#0 isn't a
valid vector is not in line with what hardware actually does, whether
it's a good idea or not. In our case the IRQ vector maps to an exception
offset, which we bump down to zero. We could force an off-by-1 there so
that the math that indexes IRQ#0 is bumped up one, but that entails
fixing up every one of our IRQ numbers for no obvious gain.

I don't really see any value in purposely crippling the range of
allowable vectors for these machines. Though I don't mind switching to a
NO_IRQ comparison instead of the < 0 case, so both can be handled.

Re: The great ST40 purge of 2007

[Paul M. <le...@li...>]

On Wed, Nov 07, 2007 at 11:19:11AM +0000, Stuart MENEFY wrote:
> Paul Mundt wrote:
> > ST can resurrect the ST40 support for 2.6.25 if they feel like it, or
> > simply continue to keep it out-of-tree.
> 
> As of last week I finally got all our stuff working on a 2.6.23 kernel.
> It still needs a bit of tidying, but I was planning to start submitting
> it over the next few weeks.
> 
Ho hum,

sh-2.6.24 $ git diff --shortstat v2.6.23..
 9704 files changed, 750316 insertions(+), 462288 deletions(-)

You might want to re-examine your development methodology. Fork-driven
development doesn't scale, as you've probably realized :-)

Hopefully once it's all synced up it will be less of a pain to keep on
top of!

Re: The great ST40 purge of 2007

[Stuart M. <stu...@st...>]

Paul Mundt wrote:
> On Wed, Jul 25, 2007 at 12:10:12PM +0900, Paul Mundt wrote:
>> On Wed, Jul 25, 2007 at 09:51:22AM +0900, Paul Mundt wrote:
>>> On Tue, Jul 24, 2007 at 11:46:52PM +0900, Magnus Damm wrote:
>>>> sh: remove support for sh73180 and solution engine 73180
>>>>
>>>> This patch removes old dead code:
>>>> - kill off sh73180 cpu support
>>>> - get rid of broken solution engine 73180 board support
>>>>
>>>> Signed-off-by: Magnus Damm <da...@ig...>
>>> Looks fine, thanks.
>>>
>> Since we're in the purging mood, perhaps it's also worth looking at some
>> others:
>>
> I've also ripped out the left over ST40 cruft, which has been broken
> in-tree the majority of the time since its last update, over 3 years ago
> (at present it randomly breaks randconfigs, which is simply not good
> form). I'll push the ST40 purge for 2.6.24-rc3, it's basically pretty
> uninteresting:
> 
>  arch/sh/drivers/pci/Makefile   |    1
>  arch/sh/drivers/pci/pci-st40.c |  488 ----------------------------------------- arch/sh/drivers/pci/pci-st40.h |  136 -----------
>  arch/sh/kernel/cpu/sh4/probe.c |    8
>  arch/sh/kernel/setup.c         |    1
>  arch/sh/mm/Kconfig             |   21 -
>  drivers/serial/sh-sci.h        |   18 -
>  include/asm-sh/processor.h     |    2
>  8 files changed, 3 insertions(+), 672 deletions(-)
> 
> ST can resurrect the ST40 support for 2.6.25 if they feel like it, or
> simply continue to keep it out-of-tree.

As of last week I finally got all our stuff working on a 2.6.23 kernel. It still
needs a bit of tidying, but I was planning to start submitting it over the
next few weeks.

But what was in the git tree was so out of date, removing it is no great loss!

Stuart