linux-serial.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Robin Murphy <robin.murphy@arm.com>
To: Bing Fan <hptsfb@gmail.com>,
	gregkh@linuxfoundation.org, Russell King <linux@armlinux.org.uk>
Cc: linux-serial@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v6] arm pl011 serial: support multi-irq request
Date: Mon, 16 Aug 2021 11:19:53 +0100	[thread overview]
Message-ID: <0366a4e9-cc8a-499e-4b8a-bbd6fa088591@arm.com> (raw)
In-Reply-To: <5b68f69c-f9cd-b0a4-45dd-d6db6d09fd65@gmail.com>

On 2021-08-16 08:42, Bing Fan wrote:
> 
> At present, i think a focus of our discussion is whether this patch is 
> necessary.
> 
> As for the other points you mentioned, I think they can be used as code 
> review comments.
> 
> 
> Yes, as you described below, most dts files have only one interrupt, but 
> not all platforms are like this.
> 
> The scene I'm encountering now is the latter: the interrupt lines of the 
> uart is connected to the gic separately
> 
> so the dts should be define like this:
> 
>                 duart1: serial@5E139000 {
>                          compatible = "arm,pl011", "arm,primecell";
>                          reg = <0x00 0x5E139000 0x0 0x1000>;
>                          interrupts = <GIC_SPI 178 IRQ_TYPE_LEVEL_HIGH>,
>                                  <GIC_SPI 179 IRQ_TYPE_LEVEL_HIGH>,
>                                  <GIC_SPI 180 IRQ_TYPE_LEVEL_HIGH>,
>                                  <GIC_SPI 181 IRQ_TYPE_LEVEL_HIGH>;
>                          clocks = <&sysclk>;
>                          clock-names = "apb_pclk";
>                  };

Apologies for being unclear - the point I was implying is that of course 
you can do that in practice, but if you run that DTS through `make 
dtbs_check` it will fail. The binding needs extending to make it valid 
to specify more than one interrupt, and that's a separate patch and 
discussion in itself (simply increasing "maxitems" for the "interrupts" 
property is not enough to be robust).

Robin.

> The current tty-master code cannot meet this scenario, so I submitted 
> this patch.
> 
> 
> 
> 
> 
> 在 2021/8/13 下午10:37, Robin Murphy 写道:
>> [ +Russell as the listed PL011 maintainer ]
>>
>> On 2021-08-13 04:31, Bing Fan wrote:
>>> From: Bing Fan <tombinfan@tencent.com>
>>>
>>> In order to make pl011 work better, multiple interrupts are
>>> required, such as TXIM, RXIM, RTIM, error interrupt(FE/PE/BE/OE);
>>> at the same time, pl011 to GIC does not merge the interrupt
>>> lines(each serial-interrupt corresponding to different GIC hardware
>>> interrupt), so need to enable and request multiple gic interrupt
>>> numbers in the driver.
>>>
>>> Signed-off-by: Bing Fan <tombinfan@tencent.com>
>>> ---
>>>   drivers/tty/serial/amba-pl011.c | 39 +++++++++++++++++++++++++++++++--
>>>   1 file changed, 37 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/drivers/tty/serial/amba-pl011.c 
>>> b/drivers/tty/serial/amba-pl011.c
>>> index e14f3378b8a0..eaac3431459c 100644
>>> --- a/drivers/tty/serial/amba-pl011.c
>>> +++ b/drivers/tty/serial/amba-pl011.c
>>> @@ -1701,6 +1701,41 @@ static void pl011_write_lcr_h(struct 
>>> uart_amba_port *uap, unsigned int lcr_h)
>>>       }
>>>   }
>>>   +static void pl011_release_multi_irqs(struct uart_amba_port *uap, 
>>> unsigned int max_cnt)
>>> +{
>>> +    struct amba_device *amba_dev = container_of(uap->port.dev, 
>>> struct amba_device, dev);
>>> +    int i;
>>> +
>>> +    for (i = 0; i < max_cnt; i++)
>>> +        if (amba_dev->irq[i])
>>> +            free_irq(amba_dev->irq[i], uap);
>>
>> When you request the IRQs you break at the first zero, so this could 
>> potentially try to free IRQs that you haven't requested, if there 
>> happen to be any nonzero values beyond that. Maybe that can never 
>> happen, but there seems little need for deliberate inconsistency here.
>>
>>> +}
>>> +
>>> +static int pl011_allocate_multi_irqs(struct uart_amba_port *uap)
>>> +{
>>> +    int ret = 0;
>>> +    int i;
>>> +    unsigned int virq;
>>> +    struct amba_device *amba_dev = container_of(uap->port.dev, 
>>> struct amba_device, dev);
>>> +
>>> +    pl011_write(uap->im, uap, REG_IMSC);
>>> +
>>> +    for (i = 0; i < AMBA_NR_IRQS; i++) {
>>
>> It's not clear where these extra IRQs are expected to come from given 
>> that the DT binding explicitly defines only one :/
>>
>>> +        virq = amba_dev->irq[i];
>>> +        if (virq == 0)
>>> +            break;
>>> +
>>> +        ret = request_irq(virq, pl011_int, IRQF_SHARED, 
>>> dev_name(&amba_dev->dev), uap);
>>
>> Note that using dev_name() here technically breaks user ABI - scripts 
>> looking in /proc for an irq named "uart-pl011" will no longer find it.
>>
>> Furthermore, the "dev" cookie passed to request_irq is supposed to be 
>> globally unique, which "uap" isn't once you start registering it 
>> multiple times. If firmware did describe all the individual PL011 IRQ 
>> outputs on a system where they are muxed to the same physical IRQ 
>> anyway, you'd end up registering ambiguous IRQ actions here. Of course 
>> in practice you might still get away with that, but it is technically 
>> wrong.
>>
>> Robin.
>>
>>> +        if (ret) {
>>> +            dev_err(uap->port.dev, "request %u interrupt failed\n", 
>>> virq);
>>> +            pl011_release_multi_irqs(uap, i - 1);
>>> +            break;
>>> +        }
>>> +    }
>>> +
>>> +    return ret;
>>> +}
>>> +
>>>   static int pl011_allocate_irq(struct uart_amba_port *uap)
>>>   {
>>>       pl011_write(uap->im, uap, REG_IMSC);
>>> @@ -1753,7 +1788,7 @@ static int pl011_startup(struct uart_port *port)
>>>       if (retval)
>>>           goto clk_dis;
>>>   -    retval = pl011_allocate_irq(uap);
>>> +    retval = pl011_allocate_multi_irqs(uap);
>>>       if (retval)
>>>           goto clk_dis;
>>>   @@ -1864,7 +1899,7 @@ static void pl011_shutdown(struct uart_port 
>>> *port)
>>>         pl011_dma_shutdown(uap);
>>>   -    free_irq(uap->port.irq, uap);
>>> +    pl011_release_multi_irqs(uap, AMBA_NR_IRQS);
>>>         pl011_disable_uart(uap);
>>>

  parent reply	other threads:[~2021-08-16 10:20 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-08-13  3:31 [PATCH v6] arm pl011 serial: support multi-irq request Bing Fan
2021-08-13  7:19 ` Greg KH
     [not found]   ` <9c3a4336-b6c4-d96e-9a9d-8001dddcee20@gmail.com>
2021-08-13  8:17     ` Greg KH
2021-08-13 14:08       ` Robin Murphy
2021-08-13 15:04         ` Greg KH
2021-08-13 15:17           ` Robin Murphy
2021-08-13 14:37 ` Robin Murphy
     [not found]   ` <5b68f69c-f9cd-b0a4-45dd-d6db6d09fd65@gmail.com>
2021-08-16 10:19     ` Robin Murphy [this message]
2021-08-16 10:34   ` Russell King (Oracle)

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=0366a4e9-cc8a-499e-4b8a-bbd6fa088591@arm.com \
    --to=robin.murphy@arm.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=hptsfb@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-serial@vger.kernel.org \
    --cc=linux@armlinux.org.uk \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).