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:	Wed, 23 Oct 2013 10:27:46 +0400
From:	Alexander Shiyan <shc_work@...l.ru>
To:	David Cohen <david.a.cohen@...ux.intel.com>
Cc:	gregkh@...uxfoundation.org, jslaby@...e.cz, ning.li@...el.com,
	ivan.gorinov@...el.com, linux-kernel@...r.kernel.org,
	linux-serial@...r.kernel.org
Subject: Re: [PATCH 2/2] mrst_max3110: fix SPI UART interrupt parameters

> On 10/22/2013 01:30 PM, David Cohen wrote:
> > On 10/22/2013 12:46 PM, Alexander Shiyan wrote:
> >>> The change in the max3110 driver makes the IRQ handling threaded, now
> >>> the handler is called only once per received character. Without that
> >>> change, we had many (more than 100) interrupts per one received
> >>> character.
> >>>
> >>> Unfortunately, SFI interface does not support IRQ polarity and
> >>> triggering modes, so we have to keep the hacks as hard-coded device
> >>> names and IRQ numbers until we switch to ACPI.
> >>>
> >>> Edge-triggered IRQ still supported to keep old platforms working.
> >>> Use platform data to pass the irq mode argument.
> >>>
> >>> Signed-off-by: Ivan Gorinov <ivan.gorinov@...el.com>
> >>> Signed-off-by: Li Ning <ning.li@...el.com>
> >>> Signed-off-by: David Cohen <david.a.cohen@...ux.intel.com>
> >> ...
> >>> +++ b/include/linux/serial_max3110.h
> >>> @@ -0,0 +1,16 @@
> >>> +#ifndef _LINUX_SERIAL_MAX3110_H
> >>> +#define _LINUX_SERIAL_MAX3110_H
> >>> +
> >>> +/**
> >>> + * struct plat_max3110 - MAX3110 SPI UART platform data
> >>> + * @irq_edge_trigger: if IRQ is edge triggered
> >>> + *
> >>> + * You should use this structure in your machine description to specify
> >>> + * how the MAX3110 is connected.
> >>> + *
> >>> + */
> >>> +struct plat_max3110 {
> >>> +    int irq_edge_triggered;
> >>> +};
> >>> +
> >>> +#endif
> >>> --
> >>
> >> Is just resource->flags for IRQ can be reused for handle such case?
> >
> > I believe your suggestion makes perfect sense. I'll rework it.
> 
> Looks like isp_device has no place for 'resource'. In this case pdata 
> seems to be the way to go here.
> Or maybe there's a better way to recommend?

What do you mean by the isp_device?

My idea is always use threaded irq and passing flags into request.
Like as:
unsigned long flags = res->flags & IORESOURCE_BITS;
...
request_threaded_irq(max->irq, serial_m3110_irq, IRQF_ONESHOT | flags, "max3110", max);

---

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ