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] [day] [month] [year] [list]
Message-ID: <875xjhwewg.ffs@tglx>
Date: Sun, 06 Apr 2025 16:19:59 +0200
From: Thomas Gleixner <tglx@...utronix.de>
To: Huacai Chen <chenhuacai@...il.com>
Cc: Huacai Chen <chenhuacai@...ngson.cn>, loongarch@...ts.linux.dev,
 linux-kernel@...r.kernel.org, Xuefeng Li <lixuefeng@...ngson.cn>, Jiaxun
 Yang <jiaxun.yang@...goat.com>, stable@...r.kernel.org, Yinbo Zhu
 <zhuyinbo@...ngson.cn>
Subject: Re: [PATCH] irqchip/loongson-liointc: Support to set
 IRQ_TYPE_EDGE_BOTH

On Sun, Apr 06 2025 at 20:46, Huacai Chen wrote:
> On Sun, Apr 6, 2025 at 6:18 PM Thomas Gleixner <tglx@...utronix.de> wrote:
>> On Sun, Apr 06 2025 at 17:46, Huacai Chen wrote:
>> > On Thu, Apr 3, 2025 at 11:48 PM Thomas Gleixner <tglx@...utronix.de> wrote:
>> >> But it won't trigger on both. So no, you cannot claim that this fixes
>> >> anything.
>> > Yes, it won't trigger on both (not perfect), but it allows drivers
>> > that request "both" work (better than fail to request), and there are
>>
>> By some definition of 'work'. There is probably a good technical reason
>> why those drivers expect EDGE_BOTH to work correctly and otherwise fail
>> to load.
> The real problem we encounter is the MMC driver. In
> drivers/mmc/core/slot-gpio.c there is
> devm_request_threaded_irq(host->parent, irq,
>                         NULL, ctx->cd_gpio_isr,
>                         IRQF_TRIGGER_RISING | IRQF_TRIGGER_FALLING |
> IRQF_ONESHOT,
>                         ctx->cd_label, host);
>
> "IRQF_TRIGGER_RISING | IRQF_TRIGGER_FALLING" is an alias of
> "IRQ_TYPE_EDGE_RISING | IRQ_TYPE_EDGE_FALLING", and
> "IRQ_TYPE_EDGE_RISING | IRQ_TYPE_EDGE_FALLING" is
> "IRQ_TYPE_EDGE_BOTH".

I know that.

> Except MMC, "grep IRQ_TYPE_EDGE_BOTH drivers" can give some more examples.

Sure, but you still do not explain why this works even when the driver
is obviously depending on EDGE_BOTH. If it does not then the driver is
bogus.

Looking at it, there is obviously a reason for this particular driver to
request BOTH. Why?

This is the card change detection and it uses a GPIO. Insert raises one
edge and remove the opposite one.

Which means whatever edge you chose randomly the detection will only
work in one direction. Please don't tell me that this is correct by any
meaning of correct. It's not. 

The driver is perfectly fine, when the request fails. It then does the
obvious right thing to poll the card detection pin.

So your change makes it worse as it screws up the detection mechanism.

What are you actually making "work"?

Thanks,

        tglx

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ