linux-kernel - Re: [PATCH 4/4] ARM: dts: r8a7742-iwg21d-q7: Enable SD2 LED indication

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: <CA+V-a8so3b7A-KdVN5DZEEwUwPckut_v0DDnw6r_ci=wL9owUw@mail.gmail.com>
Date:   Mon, 7 Sep 2020 16:23:09 +0100
From:   "Lad, Prabhakar" <prabhakar.csengg@...il.com>
To:     Geert Uytterhoeven <geert@...ux-m68k.org>
Cc:     Lad Prabhakar <prabhakar.mahadev-lad.rj@...renesas.com>,
        Magnus Damm <magnus.damm@...il.com>,
        Rob Herring <robh+dt@...nel.org>,
        Linux-Renesas <linux-renesas-soc@...r.kernel.org>,
        "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" 
        <devicetree@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 4/4] ARM: dts: r8a7742-iwg21d-q7: Enable SD2 LED indication

Hi Geert,

On Mon, Sep 7, 2020 at 8:55 AM Geert Uytterhoeven <geert@...ux-m68k.org> wrote:
>
> Hi Prabhakar,
>
> On Fri, Sep 4, 2020 at 7:15 PM Lad, Prabhakar
> <prabhakar.csengg@...il.com> wrote:
> > On Thu, Sep 3, 2020 at 1:20 PM Geert Uytterhoeven <geert@...ux-m68k.org> wrote:
> > > On Tue, Aug 25, 2020 at 6:28 PM Lad Prabhakar
> > > <prabhakar.mahadev-lad.rj@...renesas.com> wrote:
> > > > Add support for LED trigger on SD2 interface.
> > > >
> > > > Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@...renesas.com>
> > > > Reviewed-by: Chris Paterson <Chris.Paterson2@...esas.com>
> > >
> > > > --- a/arch/arm/boot/dts/r8a7742-iwg21d-q7.dts
> > > > +++ b/arch/arm/boot/dts/r8a7742-iwg21d-q7.dts
> > > > @@ -63,6 +63,16 @@
> > > >                 enable-gpios = <&gpio3 11 GPIO_ACTIVE_HIGH>;
> > > >         };
> > > >
> > > > +       leds {
> > > > +               compatible = "gpio-leds";
> > > > +
> > > > +               sdhi2_led {
> > > > +                       label = "sdio-led";
> > > > +                       gpios = <&gpio5 22 GPIO_ACTIVE_LOW>;
> > >
> > > GPIO_ACTIVE_HIGH?
> > >
> > > The LED is driven by an NPN transistor, with the LED between 3.3V and
> > > the transistor's collector.
>
> Oops, 3.3V is not VCC_3V3, but SD_3V3, so it is not always-on, but
> controlled by SDIO_PWR.
>
> > I did try with GPIO_ACTIVE_HIGH and it didn't work as expected. To
> > make sure I can control the LED through sysfs I deleted the node from
> > DTS and exported the pin GP5_22 (858) and writing the value "out"
> > direction and setting the values 0/1 to value did not toggle the SDIO
> > LED as expected and it stayed OFF all the time.
>
> Hence when SDIO_PWR is turned off, you cannot control the LED just by
> toggling GP5_22.
>
> > Looks like there is some information missing in the schematics.
> >
> > I did some experiments. I completely removed the SDHI, LED and
> > regulator  nodes and  booted the system and exported GP1_27 (989) and
> > wrote values 0/1  and this toggled the SDIO_LED.
> >
> > U-boot sets the below, so in u-boot the SDIO_LED is ON:
> >     gpio_direction_output(GPIO_GP_1_27, 0); /* power on */
> >     gpio_set_value(GPIO_GP_1_27, 0);
> >     gpio_direction_output(GPIO_GP_5_22, 0); /* LED  */
> >     gpio_set_value(GPIO_GP_5_22, 1);
> >     gpio_direction_output(GPIO_GP_1_8, 0); /* 1: 3.3V, 0: 1.8V*/
> >     gpio_set_value(GPIO_GP_1_8, 1);
> >
> > So in comparison we would need a hog node as below (and with this the
> > LED triggers correctly as expected),
> >
> > &gpio5 {
> >     sdio-led-gpio {
> >         gpio-hog;
> >         gpios = <22 GPIO_ACTIVE_HIGH>;
> >         output-high;
> >         line-name = "sdio-led-gpio";
> >     };
> > };
> >
> > Let me know if you are OK with the above.
>
> The above means the LED is always lit when SDIO_PWR is enabled.
> While I agree that's some kind of SD activity indicator, probably it's less
> fine-grained than using the mmc1 trigger?
> I assume the mmc1 trigger is only activated when SDIO_PWR is enabled.
> Are you sure this doesn't work?
> Perhaps your kernel was missing SD trigger support, or "mmc1" is the
> wrong SD instance?
>
> > Looks like the SDIO_PWR is tied up with an SDIO_LED pin and the
> > information is missing from schematics.
>
> No, I think we just misread the schematics.
>
My bad I misinterpreted the trigger, with GP5_22 being GPIO_ACTIVE_LOW
the LED remained ON when the card was inserted and turned OFF when the
card was pulled out.

When GP5_22 being GPIO_ACTIVE_HIGH the LED blinked and stayed OFF when
the card was inserted and remained OFF when the card was pulled out.
As a result I misinterpreted it.

I can confirm when GP5_22 is GPIO_ACTIVE_HIGH and there is any
activity on SD (read/write) the led turns ON.

Cheers,
Prabhakar