All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sergey Shtylyov <s.shtylyov@omp.ru>
To: Geert Uytterhoeven <geert@linux-m68k.org>, Rob Landley <rob@landley.net>
Cc: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>,
	Rich Felker <dalias@libc.org>,
	Linux-sh list <linux-sh@vger.kernel.org>,
	"Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>,
	Yoshinori Sato <ysato@users.sourceforge.jp>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Subject: Re: [PATCH v3] sh: avoid using IRQ0 on SH3/4
Date: Tue, 3 May 2022 22:33:15 +0300	[thread overview]
Message-ID: <520ab5ce-021a-bbd9-7303-3f7695631ba5@omp.ru> (raw)
In-Reply-To: <59faed1d-3878-ce75-9f62-aaf4338d0ad1@omp.ru>

On 5/2/22 11:56 PM, Sergey Shtylyov wrote:

[...]
>>>>> Using IRQ0 by the platform devices is going to be disallowed soon (see [1])
>>>>> and even now, when IRQ0 is about to be returned by platfrom_get_irq(), you
>>>>> see a big warning.  The code supporting SH3/4 SoCs maps the IRQ #s starting
>>>>> at 0 -- modify that code to start the IRQ #s from 16 instead.
>>>>>
>>>>> The patch should mostly affect the AP-SH4A-3A/AP-SH4AD-0A boards as they
>>>>> indeed use IRQ0 for the SMSC911x compatible Ethernet chip...
>>
>>> As I told him in IRC, the problem is still that sh4 never gives me a shell
>>> prompt with this patch applied. I just reconfirmed it against current git:
>>>
>>> Freeing unused kernel image (initmem) memory: 124K
>>> This architecture does not have kernel memory protection.
>>> Run /init as init process
>>> mountpoint: dev/pts: No such file or directory
>>> 8139cp 0000:00:02.0 eth0: link up, 100Mbps, full-duplex, lpa 0x05E1
>>>
>>> It makes it partway through the init script, but it hangs with qemu-system-sh4
>>> stuck in a CPU-eating loop before finishing. Without the patch, I get a shell
>>> prompt.
>>
>> I regularly test on qemu rts7751r2d, but couldn't produce your
>> issue.  Until I tried "ifconfig eth0 up", which causes a lock-up.
>> Interestingly, the 8139 irq was 112 with and without Sergey's patch,
>> so there must be an irq remapping missing.
>>
>> I also test regularly on landisk, where 8139 Ethernet works fine.
>> Turns out landisk uses arch/sh/drivers/pci/fixups-landisk.c to fixup
>> the irq...
>>
>> arch/sh/include/mach-common/mach/r2d.h has:
>> #define R2D_FPGA_IRQ_BASE       100
>> Subtracting 16 here does not help.
> 
>    Why subtract when you contrariwise need to add? :-)
> 
>> With this (gmail-whitespace-damaged) patch:
>>
>> --- a/arch/sh/drivers/pci/fixups-rts7751r2d.c
>> +++ b/arch/sh/drivers/pci/fixups-rts7751r2d.c
>> @@ -31,9 +31,9 @@ static char lboxre2_irq_tab[] = {
>>  int pcibios_map_platform_irq(const struct pci_dev *pdev, u8 slot, u8 pin)
>>  {
>>         if (mach_is_lboxre2())
>> -               return lboxre2_irq_tab[slot];
>> +               return lboxre2_irq_tab[slot] - 16;
> 
>    This table contains the values #define'd via evt2irq(), so
> shouldn't need to subtract anything...
> 
>>         else
>> -               return rts7751r2d_irq_tab[slot];
>> +               return rts7751r2d_irq_tab[slot] - 16;
> 
>    How about + 16?
> 
>>  }
>>
>>  int pci_fixup_pcic(struct pci_channel *chan)
>>
>> it no longer crashes, but ifconfig still fails:
>>
>> / # ifconfig eth0 up
>> ifconfig: ioctl 0x8914 failed: Invalid argument
> 
>    I'm still not sure you used the correct IRQ #s...
> 
>> Note that there are more implementations of pcibios_map_platform_irq()
>> that do not use evt2irq(), and thus are probably broken by this patch.
> 
>    That doesn't sound encouraging... :-/

   Actually, of those only Dreamcast didn't use evt2irq()...
   Now I'm wondering whether all #define *_IRQ_BASE should be visited as well...

>> Gr{oetje,eeting}s,
>>
>>                         Geert

MBR, Sergey

      parent reply	other threads:[~2022-05-03 19:33 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-04-27 18:46 [PATCH v3] sh: avoid using IRQ0 on SH3/4 Sergey Shtylyov
2022-04-27 19:24 ` Sergey Shtylyov
2022-04-29 14:24 ` John Paul Adrian Glaubitz
2022-04-29 14:39   ` Greg Kroah-Hartman
2022-04-29 17:16   ` Rich Felker
2022-05-01 17:58     ` Sergey Shtylyov
2022-05-01 18:09       ` Sergey Shtylyov
2022-04-30 10:30   ` Rob Landley
2022-05-01 10:19     ` John Paul Adrian Glaubitz
2022-05-02  8:37     ` Geert Uytterhoeven
2022-05-02 20:07       ` Rob Landley
2022-05-03  7:02         ` Geert Uytterhoeven
2022-05-03 19:46           ` Maciej W. Rozycki
2022-05-02 20:56       ` Sergey Shtylyov
2022-05-03  6:58         ` Geert Uytterhoeven
2022-05-03 19:33         ` Sergey Shtylyov [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=520ab5ce-021a-bbd9-7303-3f7695631ba5@omp.ru \
    --to=s.shtylyov@omp.ru \
    --cc=dalias@libc.org \
    --cc=geert@linux-m68k.org \
    --cc=glaubitz@physik.fu-berlin.de \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-sh@vger.kernel.org \
    --cc=rob@landley.net \
    --cc=ysato@users.sourceforge.jp \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.