Re: Delivery Status Notification (Failure)

2018-05-14 Thread Pintu Kumar
On Mon, May 14, 2018 at 6:41 PM, Lucas Stach  wrote:
> Am Montag, den 14.05.2018, 17:42 +0530 schrieb Pintu Kumar:
>> Hi,
>>
>> Is there any work around possible to set IRQ affinity for some GPIO
>> interrupt ?
>> How to avoid CPU0 to receive the current GPIO interrupt ?
>> How do we assign GPIO interrupts to any CPU other than CPU0 ?
>> Is it possible to isolate CPU0 for a sometime, from my GPIO driver so
>> that GPIO interrupt can be served by another CPU ?
>>
>> Need your inputs to decide whether it is still possible to set
>> affinity for GPIO interrupt, or its impossible ?
>
> This is not possible. The GPIO IRQs are aggregated into one GPC/GIC IRQ
> line per GPIO bank, so it is not possible to change affinity of a
> single GPIO interrupt to another CPU.

OK. Thanks for your confirmation.

> Best we could do is change the
> affinity of the whole bank,

OK. How can we do this on the fly from my driver code.
If you have any reference please let me know.
This is required only for experimental purpose to prove the point to be mgmt.
My idea is, from the driver, change the affinity of the whole bank.
So, the GPIO interrupt can be delivered on to this specific CPU bank.
Once I am done, I will revert back to the old bank.
Please give me some hint on how to do this from my kernel module


> but given the limited usefulness of
> something like that, nobody bothered to implement such a thing.
>
> Regards,
> Lucas
>
>>
>>
>> On Fri, May 11, 2018 at 8:07 PM, Pintu Kumar 
>> wrote:
>> > On Fri, May 11, 2018 at 6:34 PM, Lucas Stach > > e> wrote:
>> > > Am Freitag, den 11.05.2018, 13:39 +0100 schrieb Russell King -
>> > > ARM Linux:
>> > > > On Fri, May 11, 2018 at 05:07:37PM +0530, Pintu Kumar wrote:
>> > > > > Hi,
>> > > > >
>> > > > > I need one help.
>> > > > > I am using i.MX7 Sabre board with kernel version 4.1.15
>> > > > >
>> > > > > Let's say I am interested in GPIO number: 21
>> > > > > I wanted to set CPU affinity for particular GPIO->IRQ number,
>> > > > > so I
>> > > > > tried the below steps:
>> > > > > root@10:~# echo 21 > /sys/class/gpio/export
>> > > > > root@10:~# echo "rising" > /sys/class/gpio/gpio21/edge
>> > > > > root@10:~# cat /proc/interrupts | grep 21
>> > > > >   47: 0 0 gpio-mxc 21 Edge gpiolib
>> > > > > root@10:~# cat /sys/class/gpio/gpio21/direction
>> > > > > in
>> > > > > root@10:~# cat /proc/irq/47/smp_affinity
>> > > > > 3
>> > > > > root@10:~# echo 2 > /proc/irq/47/smp_affinity
>> > > > > -bash: echo: write error: Input/output error
>> > > > >
>> > > > > But I get input/output error.
>> > > > > When I debug further, found that irq_can_set_affinity is
>> > > > > returning 0:
>> > > > > [0.00] genirq: irq_can_set_affinity (0): balance: 1,
>> > > > > irq_data.chip: a81b7e48, irq_set_affinity:   (null)
>> > > > > [0.00] write_irq_affinity: FAIL
>> > > > >
>> > > > > I also tried first setting /proc/irq/default_smp_affinity to
>> > > > > 2 (from 3).
>> > > > > This change is working, but the smp_affinity setting for the
>> > > > > new IRQ
>> > > > > is not working.
>> > > > >
>> > > > > When I try to set smp_affinity for mmc0, then it works.
>> > > > > # cat /proc/interrupts | grep mmc
>> > > > > 295: 55  0 GPCV2  22 Edge  mmc0
>> > > > > 296:  0  0 GPCV2  23 Edge  mmc1
>> > > > > 297: 52  0 GPCV2  24 Edge  mmc2
>> > > > >
>> > > > > root@10:~# echo 2 > /proc/irq/295/smp_affinity
>> > > > > root@10:~#
>> > > > >
>> > > > >
>> > > > > So, I wanted to know what are the conditions for which
>> > > > > setting
>> > > > > smp_affinity for an IRQ will work ?
>> > > > >
>> > > > > Is there any way by which I can set CPU affinity to a GPIO ->
>> > > > > IRQ ?
>> > > > > Whether, irq_set_affinity_hint() will work in this case ?
>> > > >
>> > > > IRQ affinity is only supported where interrupts are _directly_
>> > > > wired to
>> > > > the GIC.  It's the GIC which does the interrupt steering to the
>> > > > CPU
>> > > > cores.
>> > > >
>> > > > Interrupts on downstream interrupt controllers (such as GPCV2)
>> > > > have no
>> > > > ability to be directed independently to other CPUs - the only
>> > > > possible
>> > > > way to change the mapping is to move _all_ interrupts on that
>> > > > controller,
>> > > > and any downstream chained interrupts at GIC level.
>> > > >
>> > > > Hence why Interrupt 295 has no irq_set_affinity function: there
>> > > > is no way
>> > > > for the interrupt controller itself to change the affinity of
>> > > > the input
>> > > > interrupt.
>> > >
>> > > The GPCv2 though is a secondary IRQ controller which has a 1:1
>> > > mapping
>> > > of its input IRQs to the upstream GIC IRQ lines. Affinity can
>> > > thus be
>> > > handled by forwarding the request to the GIC by
>> > > irq_chip_set_affinity_parent().
>> > >
>> > > As this is handled correctly in the upstream kernel since the
>> > > first
>> > > commit 

Re: Delivery Status Notification (Failure)

2018-05-14 Thread Lucas Stach
Am Montag, den 14.05.2018, 17:42 +0530 schrieb Pintu Kumar:
> Hi,
> 
> Is there any work around possible to set IRQ affinity for some GPIO
> interrupt ?
> How to avoid CPU0 to receive the current GPIO interrupt ?
> How do we assign GPIO interrupts to any CPU other than CPU0 ?
> Is it possible to isolate CPU0 for a sometime, from my GPIO driver so
> that GPIO interrupt can be served by another CPU ?
> 
> Need your inputs to decide whether it is still possible to set
> affinity for GPIO interrupt, or its impossible ?

This is not possible. The GPIO IRQs are aggregated into one GPC/GIC IRQ
line per GPIO bank, so it is not possible to change affinity of a
single GPIO interrupt to another CPU. Best we could do is change the
affinity of the whole bank, but given the limited usefulness of
something like that, nobody bothered to implement such a thing.

Regards,
Lucas

> 
> 
> On Fri, May 11, 2018 at 8:07 PM, Pintu Kumar 
> wrote:
> > On Fri, May 11, 2018 at 6:34 PM, Lucas Stach  > e> wrote:
> > > Am Freitag, den 11.05.2018, 13:39 +0100 schrieb Russell King -
> > > ARM Linux:
> > > > On Fri, May 11, 2018 at 05:07:37PM +0530, Pintu Kumar wrote:
> > > > > Hi,
> > > > > 
> > > > > I need one help.
> > > > > I am using i.MX7 Sabre board with kernel version 4.1.15
> > > > > 
> > > > > Let's say I am interested in GPIO number: 21
> > > > > I wanted to set CPU affinity for particular GPIO->IRQ number,
> > > > > so I
> > > > > tried the below steps:
> > > > > root@10:~# echo 21 > /sys/class/gpio/export
> > > > > root@10:~# echo "rising" > /sys/class/gpio/gpio21/edge
> > > > > root@10:~# cat /proc/interrupts | grep 21
> > > > >   47: 0 0 gpio-mxc 21 Edge gpiolib
> > > > > root@10:~# cat /sys/class/gpio/gpio21/direction
> > > > > in
> > > > > root@10:~# cat /proc/irq/47/smp_affinity
> > > > > 3
> > > > > root@10:~# echo 2 > /proc/irq/47/smp_affinity
> > > > > -bash: echo: write error: Input/output error
> > > > > 
> > > > > But I get input/output error.
> > > > > When I debug further, found that irq_can_set_affinity is
> > > > > returning 0:
> > > > > [0.00] genirq: irq_can_set_affinity (0): balance: 1,
> > > > > irq_data.chip: a81b7e48, irq_set_affinity:   (null)
> > > > > [0.00] write_irq_affinity: FAIL
> > > > > 
> > > > > I also tried first setting /proc/irq/default_smp_affinity to
> > > > > 2 (from 3).
> > > > > This change is working, but the smp_affinity setting for the
> > > > > new IRQ
> > > > > is not working.
> > > > > 
> > > > > When I try to set smp_affinity for mmc0, then it works.
> > > > > # cat /proc/interrupts | grep mmc
> > > > > 295: 55  0 GPCV2  22 Edge  mmc0
> > > > > 296:  0  0 GPCV2  23 Edge  mmc1
> > > > > 297: 52  0 GPCV2  24 Edge  mmc2
> > > > > 
> > > > > root@10:~# echo 2 > /proc/irq/295/smp_affinity
> > > > > root@10:~#
> > > > > 
> > > > > 
> > > > > So, I wanted to know what are the conditions for which
> > > > > setting
> > > > > smp_affinity for an IRQ will work ?
> > > > > 
> > > > > Is there any way by which I can set CPU affinity to a GPIO ->
> > > > > IRQ ?
> > > > > Whether, irq_set_affinity_hint() will work in this case ?
> > > > 
> > > > IRQ affinity is only supported where interrupts are _directly_
> > > > wired to
> > > > the GIC.  It's the GIC which does the interrupt steering to the
> > > > CPU
> > > > cores.
> > > > 
> > > > Interrupts on downstream interrupt controllers (such as GPCV2)
> > > > have no
> > > > ability to be directed independently to other CPUs - the only
> > > > possible
> > > > way to change the mapping is to move _all_ interrupts on that
> > > > controller,
> > > > and any downstream chained interrupts at GIC level.
> > > > 
> > > > Hence why Interrupt 295 has no irq_set_affinity function: there
> > > > is no way
> > > > for the interrupt controller itself to change the affinity of
> > > > the input
> > > > interrupt.
> > > 
> > > The GPCv2 though is a secondary IRQ controller which has a 1:1
> > > mapping
> > > of its input IRQs to the upstream GIC IRQ lines. Affinity can
> > > thus be
> > > handled by forwarding the request to the GIC by
> > > irq_chip_set_affinity_parent().
> > > 
> > > As this is handled correctly in the upstream kernel since the
> > > first
> > > commit introducing support for the GPCv2, it seems the issue is
> > > only
> > > present in some downstream kernel.
> > > 
> > 
> > OK. Thanks so much for your reply.
> > 
> > I saw some of the drivers using irq_set_affinity_hint() to force
> > the
> > IRQ affinity to a particular CPU.
> > This is the sample:
> > {
> > cpumask_clear(mask);
> > cpumask_set_cpu(cpu, mask);
> > irq_set_affinity_hint(irq, mask);
> > }
> > 
> > Whether this logic will work for a particular GPIO pin ?
> > 
> > 
> > > Regards,
> > > Lucas

___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org

Re: Eudyptula (Was: Kernelnewbies Digest, Vol 89, Issue 14)

2018-05-14 Thread justin . skists

> On 14 May 2018 at 08:43 Aleix Roca Nonell  wrote:
> 
> 
> On Wed, May 02, 2018 at 04:55:09PM +0200, Aleix Roca Nonell wrote:
> > On Thu, Apr 26, 2018 at 10:01:18PM +0100, justin.ski...@juzza.co.uk wrote:
> > > 
> > > > On 20 April 2018 at 07:28 Aleix Roca Nonell  
> > > > wrote:
> > > > 
> > > > I just wanted to ask the same question. I'm still doing the challenge
> > > > but it has been amost two months since I sent my last solution and
> > > > there has not been any answer yet (except the usual auto-response of
> > > > task received). Does somebody knows if it is still alive even for old
> > > > challengers?
> > > 
> > > I usually get a response when I'm about to go on holiday or AFK for a
> > > few days or so! :)
> > > 
> > > You need to remember that the maintainers who run the challenge are
> > > very busy people. The merge window for 4.17 was recently closed (and
> > > before that was the Spectre/Meltdown mess) so the maintainers are
> > > probably catching up on patches in their inbox.
> > > 
> > > Justin.
> > 
> > Oh! I understand. Thank you very much! :) In fact, I received a response
> > just a few days ago, so the challenge continues!
> > 
> > Thank you Justin! :)
> 
> Sorry I messed it up with mutt and sent the last reply only to Justin -_-'

:)

I was hoping there would be enough time for the reviewers to get to my last 
submission. Maybe changing my email address away from my gmail account had 
delayed matters.

Justin.

___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies


Re: Delivery Status Notification (Failure)

2018-05-14 Thread Pintu Kumar
Hi,

Is there any work around possible to set IRQ affinity for some GPIO interrupt ?
How to avoid CPU0 to receive the current GPIO interrupt ?
How do we assign GPIO interrupts to any CPU other than CPU0 ?
Is it possible to isolate CPU0 for a sometime, from my GPIO driver so
that GPIO interrupt can be served by another CPU ?

Need your inputs to decide whether it is still possible to set
affinity for GPIO interrupt, or its impossible ?


Thanks,
Pintu



On Fri, May 11, 2018 at 8:07 PM, Pintu Kumar  wrote:
> On Fri, May 11, 2018 at 6:34 PM, Lucas Stach  wrote:
>> Am Freitag, den 11.05.2018, 13:39 +0100 schrieb Russell King - ARM Linux:
>>> On Fri, May 11, 2018 at 05:07:37PM +0530, Pintu Kumar wrote:
>>> > Hi,
>>> >
>>> > I need one help.
>>> > I am using i.MX7 Sabre board with kernel version 4.1.15
>>> >
>>> > Let's say I am interested in GPIO number: 21
>>> > I wanted to set CPU affinity for particular GPIO->IRQ number, so I
>>> > tried the below steps:
>>> > root@10:~# echo 21 > /sys/class/gpio/export
>>> > root@10:~# echo "rising" > /sys/class/gpio/gpio21/edge
>>> > root@10:~# cat /proc/interrupts | grep 21
>>> >   47: 0 0 gpio-mxc 21 Edge gpiolib
>>> > root@10:~# cat /sys/class/gpio/gpio21/direction
>>> > in
>>> > root@10:~# cat /proc/irq/47/smp_affinity
>>> > 3
>>> > root@10:~# echo 2 > /proc/irq/47/smp_affinity
>>> > -bash: echo: write error: Input/output error
>>> >
>>> > But I get input/output error.
>>> > When I debug further, found that irq_can_set_affinity is returning 0:
>>> > [0.00] genirq: irq_can_set_affinity (0): balance: 1,
>>> > irq_data.chip: a81b7e48, irq_set_affinity:   (null)
>>> > [0.00] write_irq_affinity: FAIL
>>> >
>>> > I also tried first setting /proc/irq/default_smp_affinity to 2 (from 3).
>>> > This change is working, but the smp_affinity setting for the new IRQ
>>> > is not working.
>>> >
>>> > When I try to set smp_affinity for mmc0, then it works.
>>> > # cat /proc/interrupts | grep mmc
>>> > 295: 55  0 GPCV2  22 Edge  mmc0
>>> > 296:  0  0 GPCV2  23 Edge  mmc1
>>> > 297: 52  0 GPCV2  24 Edge  mmc2
>>> >
>>> > root@10:~# echo 2 > /proc/irq/295/smp_affinity
>>> > root@10:~#
>>> >
>>> >
>>> > So, I wanted to know what are the conditions for which setting
>>> > smp_affinity for an IRQ will work ?
>>> >
>>> > Is there any way by which I can set CPU affinity to a GPIO -> IRQ ?
>>> > Whether, irq_set_affinity_hint() will work in this case ?
>>>
>>> IRQ affinity is only supported where interrupts are _directly_ wired to
>>> the GIC.  It's the GIC which does the interrupt steering to the CPU
>>> cores.
>>>
>>> Interrupts on downstream interrupt controllers (such as GPCV2) have no
>>> ability to be directed independently to other CPUs - the only possible
>>> way to change the mapping is to move _all_ interrupts on that controller,
>>> and any downstream chained interrupts at GIC level.
>>>
>>> Hence why Interrupt 295 has no irq_set_affinity function: there is no way
>>> for the interrupt controller itself to change the affinity of the input
>>> interrupt.
>>
>> The GPCv2 though is a secondary IRQ controller which has a 1:1 mapping
>> of its input IRQs to the upstream GIC IRQ lines. Affinity can thus be
>> handled by forwarding the request to the GIC by
>> irq_chip_set_affinity_parent().
>>
>> As this is handled correctly in the upstream kernel since the first
>> commit introducing support for the GPCv2, it seems the issue is only
>> present in some downstream kernel.
>>
>
> OK. Thanks so much for your reply.
>
> I saw some of the drivers using irq_set_affinity_hint() to force the
> IRQ affinity to a particular CPU.
> This is the sample:
> {
> cpumask_clear(mask);
> cpumask_set_cpu(cpu, mask);
> irq_set_affinity_hint(irq, mask);
> }
>
> Whether this logic will work for a particular GPIO pin ?
>
>
>> Regards,
>> Lucas

___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies


Re: Eudyptula (Was: Kernelnewbies Digest, Vol 89, Issue 14)

2018-05-14 Thread Aleix Roca Nonell
On Wed, May 02, 2018 at 04:55:09PM +0200, Aleix Roca Nonell wrote:
> On Thu, Apr 26, 2018 at 10:01:18PM +0100, justin.ski...@juzza.co.uk wrote:
> > 
> > > On 20 April 2018 at 07:28 Aleix Roca Nonell  wrote:
> > > 
> > > I just wanted to ask the same question. I'm still doing the challenge
> > > but it has been amost two months since I sent my last solution and
> > > there has not been any answer yet (except the usual auto-response of
> > > task received). Does somebody knows if it is still alive even for old
> > > challengers?
> > 
> > I usually get a response when I'm about to go on holiday or AFK for a
> > few days or so! :)
> > 
> > You need to remember that the maintainers who run the challenge are
> > very busy people. The merge window for 4.17 was recently closed (and
> > before that was the Spectre/Meltdown mess) so the maintainers are
> > probably catching up on patches in their inbox.
> > 
> > Justin.
> 
> Oh! I understand. Thank you very much! :) In fact, I received a response
> just a few days ago, so the challenge continues!
> 
> Thank you Justin! :)

Sorry I messed it up with mutt and sent the last reply only to Justin -_-'

___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies


Ioctl TCSBRK in a ldisc driver

2018-05-14 Thread Oliver Graute
Hello list,

I try to handle some ioctl by my ldisc driver. Especially ioctl TCSBRK.
After wondering why I didn't receive TCSBRK ioctl I stumbled accros this
comments:

include/linux/tty_ldisc.h

* int  (*ioctl)(struct tty_struct * tty, struct file * file,
*   unsigned int cmd, unsigned long arg);
*
*  This function is called when the user requests an ioctl which
*  is not handled by the tty layer or the low-level tty driver.
*  It is intended for ioctls which affect line discpline
*  operation.  Note that the search order for ioctls is (1) tty
*  layer, (2) tty low-level driver, (3) line discpline.  So a
*  low-level driver can "grab" an ioctl request before the line
*  discpline has a chance to see it.

and the corresponding tty_ioctl() implementation in tty_io.c.

Am I correct that the TCSBRK is grabbed here before receiving it in any
ldisc driver code?

Is there a way to change the order without major changes in the tty_io.c
code?

I want to intercept the TCSBRK because my hardware needs some handling
here and for userspace applications it should be transparent.

Best regards,

Oliver

___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies