Re: [PATCH] serial: sc16is7xx: fix missing requested irq type setting

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Sun, 04 Oct 2015 22:12:20 +0100, Vladimir Zapolskiy wrote:
> Hi Jakub,
> 
> On 03.10.2015 19:23, Jakub Kicinski wrote:
> > On Wed, 30 Sep 2015 23:57:57 +0300, Vladimir Zapolskiy wrote:
> >> Hardcode IC irq type to IRQF_TRIGGER_FALLING for both platform and OF
> >> cases. According to the datasheet IC irq line is active low, reflect
> >> this fact in the driver.
> >>
> >> If sc16is7xx device is described in devicetree, the change fixes
> >> the following problem and makes the driver working correctly:
> >>
> >>     root@devkit3250:~# stty -F /dev/ttySC1 115200
> >>     INFO: rcu_preempt self-detected stall on CPU
> >>     	0: (2100 ticks this GP) idle=a79/140000000000002/0 softirq=1759/1759 fqs=0
> >>     	 (t=2100 jiffies g=910 c=909 q=2)
> >>     rcu_preempt kthread starved for 2100 jiffies! g910 c909 f0x0 s3 ->state=0x1
> >>     Task dump for CPU 0:
> >>     stty            R running      0   698    696 0x00000002
> >>     ......
> >>
> >> Signed-off-by: Vladimir Zapolskiy <vz@xxxxxxxxx>
> > 
> > NAK
> > 
> > I'm with Alexander on this one.  Did you honestly configure the device
> > in a wrong way by mistake or is it a hypothetical problem?
> 
> this is an actually met problem, but I do admit that it might be a
> misconfiguration on my side, problem in the discussed driver or an
> indicator of another IRQ chip platform problem, I know at least one
> critical issue within the current implementation of IRQ controller
> driver on LPC32xx. To give you more evidence I have to retest sc16is7xx
> driver, and unfortunately I don't have access to the hardware for one week.

OK, my thougth was that maybe we should improve the documentation
somehow.  Although, I'm not sure where to put it, the binding file
is probably not right for the IRQ information.

> Meanwhile I would be glad to get answers to two questions regarding
> sc16is7xx / irq type:
> 
> 1) how is it intended to specify proper IRQ type in the driver, if
> interrupt controller's #interrupt-cells property has only one cell?

Do you mean the controller does not provide a way to specify the
triggering edge etc.?

> 2) if you stay for flexibility, why does sc16is7xx realization in
> platform device description case hardcode IRQF_TRIGGER_FALLING?

AFAIR it's the default.  I did not write that code, though.
--
To unsubscribe from this list: send the line "unsubscribe linux-serial" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Kernel Newbies]     [Security]     [Netfilter]     [Bugtraq]     [Linux PPP]     [Linux FS]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Video 4 Linux]     [Linmodem]     [Device Mapper]     [Linux Kernel for ARM]

  Powered by Linux