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: <e872bc39-a941-d552-5145-49f40d6fa657@somainline.org>
Date:   Tue, 12 Jan 2021 18:49:53 +0100
From:   AngeloGioacchino Del Regno 
        <angelogioacchino.delregno@...ainline.org>
To:     Mark Brown <broonie@...nel.org>
Cc:     linux-arm-msm@...r.kernel.org, agross@...nel.org,
        bjorn.andersson@...aro.org, lgirdwood@...il.com,
        robh+dt@...nel.org, sumit.semwal@...aro.org,
        linux-kernel@...r.kernel.org, devicetree@...r.kernel.org,
        phone-devel@...r.kernel.org, konrad.dybcio@...ainline.org,
        marijn.suijten@...ainline.org, martin.botka@...ainline.org
Subject: Re: [PATCH 5/7] regulator: qcom-labibb: Implement short-circuit and
 over-current IRQs

Il 12/01/21 18:29, Mark Brown ha scritto:
> On Mon, Jan 11, 2021 at 10:06:18PM +0100, AngeloGioacchino Del Regno wrote:
> 
>> ...which was already a requirement before I touched it.
>> Now, this leaves two options here:
>> 1. Keep the of_get_irq way, or
>> 2. Move the interrupts, change the documentation (currently, only
>> pmi8998.dtsi) and also fix pmi8998.dtsi to reflect the new changes.
> 
>> I am asking before proceeding because I know that changing a schema that is
>> already set sometimes gets "negated".
> 
> Well, if the binding isn't actually used changing it is a possibility.
> If we keep the current binding you can still continue to use
> of_get_irq() even from within the probe function, you know the name of
> the node it's supposed to be in so you don't need to iterate or anything
> to get it so not really any reason to use the callback.
> 

I had understood that you didn't want to see of_* functions used in the 
driver, that's why I was hesitant about the first one.

I would be more for keeping the binding (that, by the way, is not really 
used, the interrupts weren't implemented at all in the driver before me 
doing that) for just one reason, which I'm going to explain with "sort 
of" pseudocode (just to be shorter):

EXAMPLE 1:
labibb {
     interrupts = <0 0>, <1 0>, <2 0>, <3 0>;
     interrupt-names = "lab-sc", "lab-ocp", "ibb-sc", "ibb-ocp";
     lab { };
     ibb { };
};

for (i = 0; i < max_vregs; i++) {
     short_circuit = platform_get_irq(pdev, i * 2);
     overcurrent = platform_get_irq(pdev, ((i * 2) + 1));
}

EXAMPLE 2:

snprintf strings for {lab,ibb}_{shortcircuit,overcurrent}, use 
platform_get_irq_byname
(pdev, blah);

EXAMPLE 3:
labibb {

     lab {
       interrupts = <0 0>, <1 0>;


       interrupt-names = "sc", "ocp";

     };

     ibb {

       interrupts = <2 0>, <3 0>;


       interrupt-names = "sc", "ocp";


     };

};



for (i = 0; i < max_vregs; i++) {

     short_circuit = of_irq_get_byname(node, "sc");

     overcurrent = of_irq_get_byname(node, "ocp");

}


First of all, in the *EXAMPLE 1*, we may be declaring interrupts for 
both LAB and IBB, but actually disabling one of the two regulators: in 
this specific case (I have no idea why anyone would want to do that, but 
evaluating all the cases anyway) the human readability would be way 
lower, in my opinion, as that'd add a possible layer of confusion.
Also, I don't really like having to preallocate an array of chars and 
snprintf names here and there (EXAMPLE 2) on the fly: in my eyes, it 
looks a bit of a mess, but that's a highly personal opinion, many may 
disagree.

In *EXAMPLE 3* everything looks more human readable and, in some way, 
less error-prone, as we can just use two fixed strings and that's it, 
without multiplying this and adding that.


I would go for keeping the current binding for the aforementioned 
reasons. Before I go on sending a V2, I would like to know your opinion.
Do you agree?

Thanks,
-- Angelo

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ