linux-kernel - Re: [linux-sunxi] [PATCH 2/8] pinctrl: sunxi: Add support for the Allwinner H616 pin controller

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <f7ea5698-de8d-65d5-ea12-287aaac88b8d@arm.com>
Date:   Mon, 7 Dec 2020 01:45:23 +0000
From:   André Przywara <andre.przywara@....com>
To:     Icenowy Zheng <icenowy@...c.io>,
        Jernej Škrabec <jernej.skrabec@...l.net>,
        Clément Péron <peron.clem@...il.com>
Cc:     Maxime Ripard <mripard@...nel.org>, Chen-Yu Tsai <wens@...e.org>,
        Icenowy Zheng <icenowy@...c.xyz>,
        linux-arm-kernel <linux-arm-kernel@...ts.infradead.org>,
        linux-sunxi <linux-sunxi@...glegroups.com>,
        Linus Walleij <linus.walleij@...aro.org>,
        Rob Herring <robh+dt@...nel.org>,
        Yangtao Li <frank@...winnertech.com>,
        linux-kernel <linux-kernel@...r.kernel.org>,
        linux-gpio@...r.kernel.org, Yangtao Li <tiny.windzz@...il.com>,
        Shuosheng Huang <huangshuosheng@...winnertech.com>
Subject: Re: [linux-sunxi] [PATCH 2/8] pinctrl: sunxi: Add support for the
 Allwinner H616 pin controller

On 07/12/2020 01:07, André Przywara wrote:
> On 06/12/2020 16:01, Icenowy Zheng wrote:
> 
> Hi,
> 

....

>>>>>> +                 SUNXI_FUNCTION_IRQ_BANK(0x6, 4, 16)), /*
>>> PI_EINT16 */
>>>>>> +};
>>>>>> +static const unsigned int h616_irq_bank_map[] = { 2, 5, 6, 7, 8 };
>>>>>
>>>>> The BSP driver seems to have more than 5 IRQ Banks.
>>>>>
>>>>> static const unsigned sun50iw9p1_irq_bank_base[] = {
>>>>> SUNXI_PIO_BANK_BASE(PA_BASE, 0),
>>>>> SUNXI_PIO_BANK_BASE(PC_BASE, 1),
>>>>> SUNXI_PIO_BANK_BASE(PD_BASE, 2),
>>>>> SUNXI_PIO_BANK_BASE(PE_BASE, 3),
>>>>> SUNXI_PIO_BANK_BASE(PF_BASE, 4),
>>>>> SUNXI_PIO_BANK_BASE(PG_BASE, 5),
>>>>> SUNXI_PIO_BANK_BASE(PH_BASE, 6),
>>>>> SUNXI_PIO_BANK_BASE(PI_BASE, 7),
>>>>> };
>>>>>
>>>>> So maybe it should be somethings like this:
>>>>> static const unsigned int h616_irq_bank_map[] = { 0, 2, 3, 4, 5, 6,
>>> 7, 8 };
>>>>
>>>> While that's true, I don't see a need for IRQ bank on port A - this
>>> port is 
>>>> internal (not exposed on pins) and none of the functionality on that
>>> port 
>>>> needs IRQ.
>>>
>>> I agree here, since port A isn't even mentioned in the manual (neither
>>
>> I think if we ignore it we have the risk of DT binding issues
>> when we need to add it afterwards.
> 
> You have a point, but which interrupt shall I assign in the .dtsi?

Ah, of course they mention it in their -pinctrl.dtsi...

> And as Jernej mentioned, there is little sense in having those pins as
> interrupt sources, since we cannot use them as GPIOs in a useful way. We
> could bitbang I2C, but I don't see much sense in doing this.
> 
> And to be honest: that issue is a shortcoming of our binding. By moving
> this simple array into the DT we could avoid this problem entirely.
> 
>>> is PortD or PortE),
> 
> I had a look at PortD and PortE in the BSP: they describe LCD, LVDS and
> CSI, mostly, all interfaces which the chip does not support anymore.
> Even if the peripherals are still in, there is no use for having those
> signals internally. And there are surely no pads connected to them
> (there are simply no balls left on the package, according to the datasheet).
> 
> So my theory is that those peripherals are just left in because it was
> too much trouble to remove them (and it doesn't hurt having them in), or
> there is another package variant which exposes those pins.
> 
> So I would lean to not expose those ports (PD, PE) and their interrupts
> (for PA, PD, PE).
> 
> Opinions?

So with those numbers from their .dtsi I can offer to use the array as
Clément showed above, and adjust the indicies in the pin arrays above.
Then have the IRQ numbers as shown in the BSP in our .dtsi.
But I would not have SUNXI_FUNCTION_IRQ_BANK statements for those
unknown ports, in fact no mentions of PortD and PortE at all.

Does that sound acceptable?

Cheers,
Andre

> 
>> I would refrain from listing it here prematurely.
>>> Plus we actually don't know their interrupt numbers: the manual only
>>> mentions GPIOE on top of the already listed interrupts.
>>>
>>> The interrupts work by their index, so skipping ports is not an issue.
>>> I
>>> just tested the PIO interrupt on PortC, and it works.
>>>
>>> Cheers,
>>> Andre
>>>
>>>>>
>>>>>> +
>>>>>> +static const struct sunxi_pinctrl_desc h616_pinctrl_data = {
>>>>>> +       .pins = h616_pins,
>>>>>> +       .npins = ARRAY_SIZE(h616_pins),
>>>>>> +       .irq_banks = 5,
>>>>>
>>>>>  .irq_banks = ARAY_SIZE(h616_irq_bank_map) is better no ?
>>>>>
>>>>>> +       .irq_bank_map = h616_irq_bank_map,
>>>>>> +       .irq_read_needs_mux = true,
>>>>>> +       .io_bias_cfg_variant = BIAS_VOLTAGE_PIO_POW_MODE_SEL,
>>>>>> +};
>>>>>> +
>>>>>> +static int h616_pinctrl_probe(struct platform_device *pdev)
>>>>>> +{
>>>>>> +       return sunxi_pinctrl_init(pdev,
>>>>>> +                                 &h616_pinctrl_data);
>>>>>> +}
>>>>>> +
>>>>>> +static const struct of_device_id h616_pinctrl_match[] = {
>>>>>> +       { .compatible = "allwinner,sun50i-h616-pinctrl", },
>>>>>
>>>>> This is a new compatible and should be documented.
>>>>>
>>>>> Regards,
>>>>> Clement
>>>>>
>>>>>> +       {}
>>>>>> +};
>>>>>> +
>>>>>> +static struct platform_driver h616_pinctrl_driver = {
>>>>>> +       .probe  = h616_pinctrl_probe,
>>>>>> +       .driver = {
>>>>>> +               .name           = "sun50i-h616-pinctrl",
>>>>>> +               .of_match_table = h616_pinctrl_match,
>>>>>> +       },
>>>>>> +};
>>>>>> +builtin_platform_driver(h616_pinctrl_driver);
>>>>>> --
>>>>>> 2.17.5
>>>>>>
>>>>>> --
>>
>