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 PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Fri, 16 Dec 2022 04:07:20 +0000 From: <Arun.Ramadoss@...rochip.com> To: <linux-kernel@...r.kernel.org>, <netdev@...r.kernel.org>, <ceggers@...i.de>, <pabeni@...hat.com> CC: <olteanv@...il.com>, <UNGLinuxDriver@...rochip.com>, <vivien.didelot@...il.com>, <andrew@...n.ch>, <linux@...linux.org.uk>, <Tristram.Ha@...rochip.com>, <f.fainelli@...il.com>, <kuba@...nel.org>, <edumazet@...gle.com>, <Woojung.Huh@...rochip.com>, <davem@...emloft.net> Subject: Re: [Patch net] net: dsa: microchip: remove IRQF_TRIGGER_FALLING in request_threaded_irq Hi Christian, On Thu, 2022-12-15 at 14:50 +0100, Christian Eggers wrote: > EXTERNAL EMAIL: Do not click links or open attachments unless you > know the content is safe > > Hi Paolo, > > On Thursday, 15 December 2022, 12:29:22 CET, Paolo Abeni wrote: > > On Tue, 2022-12-13 at 15:44 +0530, Arun Ramadoss wrote: > > > KSZ swithes used interrupts for detecting the phy link up and > > > down. > > > During registering the interrupt handler, it used > > > IRQF_TRIGGER_FALLING > > > flag. But this flag has to be retrieved from device tree instead > > > of hard > > > coding in the driver, > > > > Out of sheer ignorance, why? > > As far as I know, some IRQF_ flags should be set through the firmware > (e.g. device tree) instead hard coding them into the driver. On my > platform, I have to use IRQF_TRIGGER_LOW instead of > IRQF_TRIGGER_FALLING. > If the value is hard coded into the driver, the value from the driver > will have precedence. > > See also: https://stackoverflow.com/a/40051191 > > > > so removing the flag. > > > > It looks like the device tree currently lack such item, so this is > > effecivelly breaking phy linkup/linkdown? > > What is "the" device tree. Do you mean the device tree for your > specific > board, or the example under > Documentation/devicetree/bindings/net/dsa/microchip,ksz.yaml? > The latter doesn't mention the irq at all. > > BTW: In my kernel log I get the following messages: > > > ksz9477-switch 0-005f: configuring for fixed/rmii link mode > > ksz9477-switch 0-005f lan0 (uninitialized): PHY [dsa-0.0:00] driver > > [Microchip KSZ9477] (irq=POLL) > > ksz9477-switch 0-005f: Link is Up - 100Mbps/Full - flow control off > > ksz9477-switch 0-005f lan1 (uninitialized): PHY [dsa-0.0:01] driver > > [Microchip KSZ9477] (irq=POLL) > > Should I see something different than "irq=POLL" when an > irq line is provided in the device tree? If the device tree is provided *interrupt controller and interrupt cells*, the kernel message should print the irq number like (irq=67) instead of POLL. (67 is random number). Following is the device tree snippet, ksz9563: switch@0 { compatible = "microchip,ksz9563"; reg = <0>; spi-max-frequency = <44000000>; interrupt-parent = <&pioB>; interrupts = <28 IRQ_TYPE_LEVEL_LOW>; interrupt-controller; #interrupt-cells = <2>; resetb-gpios = <&pioD 18 GPIO_ACTIVE_LOW>; pinctrl-0 = <&pinctrl_spi_ksz_rst>; status = "okay"; .... } > > regards > Christian > > >
Powered by blists - more mailing lists