linux-kernel - Re: [PATCH v1 0/6] mmc: sdhci-pci: Add some CD GPIO related quirks

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 for Android: free password hash cracker in your pocket

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

Date:   Thu, 7 Oct 2021 21:03:37 +0300
From:   Adrian Hunter <adrian.hunter@...el.com>
To:     Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
        Ulf Hansson <ulf.hansson@...aro.org>,
        Eric Biggers <ebiggers@...gle.com>,
        Raul E Rangel <rrangel@...omium.org>,
        linux-kernel@...r.kernel.org, linux-mmc@...r.kernel.org
Subject: Re: [PATCH v1 0/6] mmc: sdhci-pci: Add some CD GPIO related quirks

On 07/10/2021 19:42, Andy Shevchenko wrote:
> On Tue, Oct 05, 2021 at 01:24:24PM +0300, Andy Shevchenko wrote:
>> It appears that one of the supported platform magically worked with the
>> custom IRQ handler (any hints how?) while having two PCB designs with
>> an opposite CD sense level. Here is an attempt to fix it by quirking out
>> CD GPIO.
>>
>> Patch 1 introduces two additional quirks (it's done this way due to
>> patch 3, see below). Patch 2 is an actual fix for the mentioned platform.
>> If backported need to be taken with patch 1 together. Patch 3 is (RFT)
>> clean up. The questionable part here is the locking scheme. Shouldn't
>> we do something similar in the generic IRQ handler of SDHCI? Or Broxton
>> case has something quite different in mind?
>>
>> Patches 4-6 are dead-code removals. Patch 4 accompanying patch 2, patches
>> 5-6 just similar to it, but (functionally) independent. Would like to hear
>> if it's okay to do.
>>
>> Any comments, hints, advice are welcome!
> 
> Adrian, Ulf, any comments on this? At least first two fix the regression and
> would be nice to have them in sooner than later (I can split them separately
> if required).

I am not sure we need new quirks, given that we can just hook the callback
and do anything that way.  However I really haven't had time to look closely
yet, sorry.