Re: [Xen-devel] [PATCH] xen, fbfront: fix connecting to backend

[Jan Beulich]

>>> On 23.03.17 at 13:52,  wrote:
> Connecting to the backend isn't working reliably in xen-fbfront: in
> case XenbusStateInitWait of the backend has been missed the backend
> transition to XenbusStateConnected will trigger the connected state
> only without doing the actions required when the backend has
> connected.

Looks like xen-kbdfront does exactly the same - shouldn't it also be
changed then?

Jan

Re: [Xen-devel] [PATCH] xen, fbfront: fix connecting to backend

[Jan Beulich]

>>> On 23.03.17 at 13:52,  wrote:
> Connecting to the backend isn't working reliably in xen-fbfront: in
> case XenbusStateInitWait of the backend has been missed the backend
> transition to XenbusStateConnected will trigger the connected state
> only without doing the actions required when the backend has
> connected.

Looks like xen-kbdfront does exactly the same - shouldn't it also be
changed then?

Jan

Re: [Xen-devel] [PATCH] xen, fbfront: fix connecting to backend

[Juergen Gross]

On 23/03/17 14:37, Jan Beulich wrote:
 On 23.03.17 at 13:52,  wrote:
>> Connecting to the backend isn't working reliably in xen-fbfront: in
>> case XenbusStateInitWait of the backend has been missed the backend
>> transition to XenbusStateConnected will trigger the connected state
>> only without doing the actions required when the backend has
>> connected.
> 
> Looks like xen-kbdfront does exactly the same - shouldn't it also be
> changed then?

I posted that patch 2 days ago. :-)


Juergen

Re: [Xen-devel] [PATCH] xen, fbfront: fix connecting to backend

[Juergen Gross]

On 23/03/17 14:37, Jan Beulich wrote:
 On 23.03.17 at 13:52,  wrote:
>> Connecting to the backend isn't working reliably in xen-fbfront: in
>> case XenbusStateInitWait of the backend has been missed the backend
>> transition to XenbusStateConnected will trigger the connected state
>> only without doing the actions required when the backend has
>> connected.
> 
> Looks like xen-kbdfront does exactly the same - shouldn't it also be
> changed then?

I posted that patch 2 days ago. :-)


Juergen

Re: [PATCH] power: supply: Add driver for TI BQ2416X battery charger

[Sebastian Reichel]

Hi,

On Wed, Mar 22, 2017 at 01:53:19PM +, Wojciech Ziemba wrote:
> [...]
>
> >> and a number of knobs for controlling the charging process
> > missing sysfs ABI documentation. Most of them are probably either
> > not needed, or should become standard POWER_SUPPLY_PROP_ properties.
> 
> Well, it is up to you. POWER_SUPPLY props are already there.
> If any new POWER_SUPPLY props should be introduced, it is an open question.
> I agree sysfs knobs could be not needed, but many PSY drivers
> still use them. Couldn't them still be useful even if don't fit the model 
> directly?
> Especially for more specialized embedded systems?

Yes they may, they also may not. Let's add them once they are
needed, because adding them means, that they become ABI.

> [...]
>
> >> +- ti,safety-timer:  Safety timer. enum:
> >> +- TMR_27MIN (0)
> >> +- TMR_6H (1)
> >> +- TMR_9H (2)
> >> +- TMR_OFF (3)
> > This does not belong into DT. Just always set it to 27 minutes and
> > properly reset the timer in the driver. You will also need a suspend
> > handler, that disables the timer (or wakeup every now and then to
> > reset it).
> 
> Do you mean, more flexible safety timer based on minimal 27min reset?
> Will address wakeup in suspend, separately in this driver.

I mean just always use TMR_27MIN in the driver + watchdog to keep
the system charging. You can change the timer to something bigger
in the suspend routine.

-- Sebastian


signature.asc
Description: PGP signature

Re: [PATCH] power: supply: Add driver for TI BQ2416X battery charger

[Sebastian Reichel]

Hi,

On Wed, Mar 22, 2017 at 01:53:19PM +, Wojciech Ziemba wrote:
> [...]
>
> >> and a number of knobs for controlling the charging process
> > missing sysfs ABI documentation. Most of them are probably either
> > not needed, or should become standard POWER_SUPPLY_PROP_ properties.
> 
> Well, it is up to you. POWER_SUPPLY props are already there.
> If any new POWER_SUPPLY props should be introduced, it is an open question.
> I agree sysfs knobs could be not needed, but many PSY drivers
> still use them. Couldn't them still be useful even if don't fit the model 
> directly?
> Especially for more specialized embedded systems?

Yes they may, they also may not. Let's add them once they are
needed, because adding them means, that they become ABI.

> [...]
>
> >> +- ti,safety-timer:  Safety timer. enum:
> >> +- TMR_27MIN (0)
> >> +- TMR_6H (1)
> >> +- TMR_9H (2)
> >> +- TMR_OFF (3)
> > This does not belong into DT. Just always set it to 27 minutes and
> > properly reset the timer in the driver. You will also need a suspend
> > handler, that disables the timer (or wakeup every now and then to
> > reset it).
> 
> Do you mean, more flexible safety timer based on minimal 27min reset?
> Will address wakeup in suspend, separately in this driver.

I mean just always use TMR_27MIN in the driver + watchdog to keep
the system charging. You can change the timer to something bigger
in the suspend routine.

-- Sebastian


signature.asc
Description: PGP signature

Re: [Outreachy kernel] [RESEND PATCH v2] staging:speakup: Fix alignment with parenthesis.

[Julia Lawall]

It should be staging: speakup:, not staging:speakup:

On Thu, 23 Mar 2017, Arushi Singhal wrote:

> Fix checkpatch issues: "CHECK: Alignment should match open parenthesis".

It would really be better to say what the patch does, not just say what
error message you have fixed.

julia

> Signed-off-by: Arushi Singhal 
> ---
> changes in v2
>  - change the commit message.
>
>  drivers/staging/speakup/speakup_apollo.c | 2 +-
>  drivers/staging/speakup/speakup_decext.c | 4 ++--
>  2 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/staging/speakup/speakup_apollo.c
> b/drivers/staging/speakup/speakup_apollo.c
> index 9cfdbbfb9742..6ad83dc642c4 100644
> --- a/drivers/staging/speakup/speakup_apollo.c
> +++ b/drivers/staging/speakup/speakup_apollo.c
> @@ -173,7 +173,7 @@ static void do_catch_up(struct spk_synth *synth)
>                 if (!synth->io_ops->synth_out(synth, ch)) {
>                         outb(UART_MCR_DTR, speakup_info.port_tts +
> UART_MCR);
>                         outb(UART_MCR_DTR | UART_MCR_RTS,
> -                                       speakup_info.port_tts + UART_MCR);
> +                            speakup_info.port_tts + UART_MCR);
>                         schedule_timeout(msecs_to_jiffies(full_time_val));
>                         continue;
>                 }
> diff --git a/drivers/staging/speakup/speakup_decext.c
> b/drivers/staging/speakup/speakup_decext.c
> index 929a28d618dc..c564bf8e1531 100644
> --- a/drivers/staging/speakup/speakup_decext.c
> +++ b/drivers/staging/speakup/speakup_decext.c
> @@ -206,11 +206,11 @@ static void do_catch_up(struct spk_synth *synth)
>                                 if (!in_escape)
>                                         synth->io_ops->synth_out(synth,
> PROCSPEECH);
>                                 spin_lock_irqsave(_info.spinlock,
> -                                                       flags);
> +                                                 flags);
>                                 jiffy_delta_val = jiffy_delta->u.n.value;
>                                 delay_time_val = delay_time->u.n.value;
>                                
> spin_unlock_irqrestore(_info.spinlock,
> -                                                       flags);
> +                                                      flags);
>                                 schedule_timeout(msecs_to_jiffies
>                                                  (delay_time_val));
>                                 jiff_max = jiffies + jiffy_delta_val;
> --
> 2.11.0
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "outreachy-kernel" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to outreachy-kernel+unsubscr...@googlegroups.com.
> To post to this group, send email to outreachy-ker...@googlegroups.com.
> To view this discussion on the web 
> visithttps://groups.google.com/d/msgid/outreachy-kernel/CA%2BXqjF9fNHFEUopsZH5rf
> iuha-Pv0WA%2B8oACvT_cNxwiSX-rjg%40mail.gmail.com.
> For more options, visit https://groups.google.com/d/optout.
>
>

Re: [Outreachy kernel] [RESEND PATCH v2] staging:speakup: Fix alignment with parenthesis.

[Julia Lawall]

It should be staging: speakup:, not staging:speakup:

On Thu, 23 Mar 2017, Arushi Singhal wrote:

> Fix checkpatch issues: "CHECK: Alignment should match open parenthesis".

It would really be better to say what the patch does, not just say what
error message you have fixed.

julia

> Signed-off-by: Arushi Singhal 
> ---
> changes in v2
>  - change the commit message.
>
>  drivers/staging/speakup/speakup_apollo.c | 2 +-
>  drivers/staging/speakup/speakup_decext.c | 4 ++--
>  2 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/staging/speakup/speakup_apollo.c
> b/drivers/staging/speakup/speakup_apollo.c
> index 9cfdbbfb9742..6ad83dc642c4 100644
> --- a/drivers/staging/speakup/speakup_apollo.c
> +++ b/drivers/staging/speakup/speakup_apollo.c
> @@ -173,7 +173,7 @@ static void do_catch_up(struct spk_synth *synth)
>                 if (!synth->io_ops->synth_out(synth, ch)) {
>                         outb(UART_MCR_DTR, speakup_info.port_tts +
> UART_MCR);
>                         outb(UART_MCR_DTR | UART_MCR_RTS,
> -                                       speakup_info.port_tts + UART_MCR);
> +                            speakup_info.port_tts + UART_MCR);
>                         schedule_timeout(msecs_to_jiffies(full_time_val));
>                         continue;
>                 }
> diff --git a/drivers/staging/speakup/speakup_decext.c
> b/drivers/staging/speakup/speakup_decext.c
> index 929a28d618dc..c564bf8e1531 100644
> --- a/drivers/staging/speakup/speakup_decext.c
> +++ b/drivers/staging/speakup/speakup_decext.c
> @@ -206,11 +206,11 @@ static void do_catch_up(struct spk_synth *synth)
>                                 if (!in_escape)
>                                         synth->io_ops->synth_out(synth,
> PROCSPEECH);
>                                 spin_lock_irqsave(_info.spinlock,
> -                                                       flags);
> +                                                 flags);
>                                 jiffy_delta_val = jiffy_delta->u.n.value;
>                                 delay_time_val = delay_time->u.n.value;
>                                
> spin_unlock_irqrestore(_info.spinlock,
> -                                                       flags);
> +                                                      flags);
>                                 schedule_timeout(msecs_to_jiffies
>                                                  (delay_time_val));
>                                 jiff_max = jiffies + jiffy_delta_val;
> --
> 2.11.0
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "outreachy-kernel" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to outreachy-kernel+unsubscr...@googlegroups.com.
> To post to this group, send email to outreachy-ker...@googlegroups.com.
> To view this discussion on the web 
> visithttps://groups.google.com/d/msgid/outreachy-kernel/CA%2BXqjF9fNHFEUopsZH5rf
> iuha-Pv0WA%2B8oACvT_cNxwiSX-rjg%40mail.gmail.com.
> For more options, visit https://groups.google.com/d/optout.
>
>

Re: security, hugetlbfs: write to user memory in hugetlbfs_destroy_inode

[Tetsuo Handa]

Dmitry Vyukov wrote:
> On Thu, Mar 23, 2017 at 2:06 PM, Dmitry Vyukov  wrote:
> > Hello,
> >
> > I've got the following report while running syzkaller fuzzer on
> > 093b995e3b55a0ae0670226ddfcb05bfbf0099ae. Note the preceding injected
> > kmalloc failure in inode_alloc_security, most likely it's the root
> > cause.

I don't think inode_alloc_security() failure is the root cause.
I think this is a bug in hugetlbfs or mm part.

If inode_alloc_security() fails, inode->i_security remains NULL
which was initialized to NULL at security_inode_alloc(). Thus,
security_inode_alloc() is irrelevant to this problem.

inode_init_always() returned -ENOMEM due to fault injection and

if (unlikely(inode_init_always(sb, inode))) {
if (inode->i_sb->s_op->destroy_inode)
inode->i_sb->s_op->destroy_inode(inode);
else
kmem_cache_free(inode_cachep, inode);
return NULL;
}

hugetlbfs_destroy_inode() was called via inode->i_sb->s_op->destroy_inode()
when inode initialization failed

static void hugetlbfs_destroy_inode(struct inode *inode)
{
hugetlbfs_inc_free_inodes(HUGETLBFS_SB(inode->i_sb));
mpol_free_shared_policy(_I(inode)->policy);
call_rcu(>i_rcu, hugetlbfs_i_callback);
}

but mpol_shared_policy_init() is called only when new_inode() succeeds.

inode = new_inode(sb);
if (inode) {
(...snipped...)
info = HUGETLBFS_I(inode);
/*
 * The policy is initialized here even if we are creating a
 * private inode because initialization simply creates an
 * an empty rb tree and calls rwlock_init(), later when we
 * call mpol_free_shared_policy() it will just return because
 * the rb tree will still be empty.
 */
mpol_shared_policy_init(>policy, NULL);

Re: security, hugetlbfs: write to user memory in hugetlbfs_destroy_inode

[Tetsuo Handa]

Dmitry Vyukov wrote:
> On Thu, Mar 23, 2017 at 2:06 PM, Dmitry Vyukov  wrote:
> > Hello,
> >
> > I've got the following report while running syzkaller fuzzer on
> > 093b995e3b55a0ae0670226ddfcb05bfbf0099ae. Note the preceding injected
> > kmalloc failure in inode_alloc_security, most likely it's the root
> > cause.

I don't think inode_alloc_security() failure is the root cause.
I think this is a bug in hugetlbfs or mm part.

If inode_alloc_security() fails, inode->i_security remains NULL
which was initialized to NULL at security_inode_alloc(). Thus,
security_inode_alloc() is irrelevant to this problem.

inode_init_always() returned -ENOMEM due to fault injection and

if (unlikely(inode_init_always(sb, inode))) {
if (inode->i_sb->s_op->destroy_inode)
inode->i_sb->s_op->destroy_inode(inode);
else
kmem_cache_free(inode_cachep, inode);
return NULL;
}

hugetlbfs_destroy_inode() was called via inode->i_sb->s_op->destroy_inode()
when inode initialization failed

static void hugetlbfs_destroy_inode(struct inode *inode)
{
hugetlbfs_inc_free_inodes(HUGETLBFS_SB(inode->i_sb));
mpol_free_shared_policy(_I(inode)->policy);
call_rcu(>i_rcu, hugetlbfs_i_callback);
}

but mpol_shared_policy_init() is called only when new_inode() succeeds.

inode = new_inode(sb);
if (inode) {
(...snipped...)
info = HUGETLBFS_I(inode);
/*
 * The policy is initialized here even if we are creating a
 * private inode because initialization simply creates an
 * an empty rb tree and calls rwlock_init(), later when we
 * call mpol_free_shared_policy() it will just return because
 * the rb tree will still be empty.
 */
mpol_shared_policy_init(>policy, NULL);

Re: [PATCH v2 5/9] mfd: t7l66xb: make use of raw_spinlock variants

[Lee Jones]

On Tue, 21 Mar 2017, Julia Cartwright wrote:

> The t7l66xb mfd driver currently implements an irq_chip for handling
> interrupts; due to how irq_chip handling is done, it's necessary for the
> irq_chip methods to be invoked from hardirq context, even on a a
> real-time kernel.  Because the spinlock_t type becomes a "sleeping"
> spinlock w/ RT kernels, it is not suitable to be used with irq_chips.
> 
> A quick audit of the operations under the lock reveal that they do only
> minimal, bounded work, and are therefore safe to do under a raw spinlock.
> 
> Acked-for-MFD-by: Lee Jones 
> Signed-off-by: Julia Cartwright 
> ---
> v1 -> v2:
>   - No functional change.  Added Lee's ack.
> 
>  drivers/mfd/t7l66xb.c | 20 ++--
>  1 file changed, 10 insertions(+), 10 deletions(-)

Applied, thanks.

> diff --git a/drivers/mfd/t7l66xb.c b/drivers/mfd/t7l66xb.c
> index 94bd89cb1f06..22c811396edc 100644
> --- a/drivers/mfd/t7l66xb.c
> +++ b/drivers/mfd/t7l66xb.c
> @@ -69,7 +69,7 @@ static const struct resource t7l66xb_mmc_resources[] = {
>  struct t7l66xb {
>   void __iomem*scr;
>   /* Lock to protect registers requiring read/modify/write ops. */
> - spinlock_t  lock;
> + raw_spinlock_t  lock;
>  
>   struct resource rscr;
>   struct clk  *clk48m;
> @@ -89,13 +89,13 @@ static int t7l66xb_mmc_enable(struct platform_device *mmc)
>  
>   clk_prepare_enable(t7l66xb->clk32k);
>  
> - spin_lock_irqsave(>lock, flags);
> + raw_spin_lock_irqsave(>lock, flags);
>  
>   dev_ctl = tmio_ioread8(t7l66xb->scr + SCR_DEV_CTL);
>   dev_ctl |= SCR_DEV_CTL_MMC;
>   tmio_iowrite8(dev_ctl, t7l66xb->scr + SCR_DEV_CTL);
>  
> - spin_unlock_irqrestore(>lock, flags);
> + raw_spin_unlock_irqrestore(>lock, flags);
>  
>   tmio_core_mmc_enable(t7l66xb->scr + 0x200, 0,
>   t7l66xb_mmc_resources[0].start & 0xfffe);
> @@ -110,13 +110,13 @@ static int t7l66xb_mmc_disable(struct platform_device 
> *mmc)
>   unsigned long flags;
>   u8 dev_ctl;
>  
> - spin_lock_irqsave(>lock, flags);
> + raw_spin_lock_irqsave(>lock, flags);
>  
>   dev_ctl = tmio_ioread8(t7l66xb->scr + SCR_DEV_CTL);
>   dev_ctl &= ~SCR_DEV_CTL_MMC;
>   tmio_iowrite8(dev_ctl, t7l66xb->scr + SCR_DEV_CTL);
>  
> - spin_unlock_irqrestore(>lock, flags);
> + raw_spin_unlock_irqrestore(>lock, flags);
>  
>   clk_disable_unprepare(t7l66xb->clk32k);
>  
> @@ -206,11 +206,11 @@ static void t7l66xb_irq_mask(struct irq_data *data)
>   unsigned long   flags;
>   u8 imr;
>  
> - spin_lock_irqsave(>lock, flags);
> + raw_spin_lock_irqsave(>lock, flags);
>   imr = tmio_ioread8(t7l66xb->scr + SCR_IMR);
>   imr |= 1 << (data->irq - t7l66xb->irq_base);
>   tmio_iowrite8(imr, t7l66xb->scr + SCR_IMR);
> - spin_unlock_irqrestore(>lock, flags);
> + raw_spin_unlock_irqrestore(>lock, flags);
>  }
>  
>  static void t7l66xb_irq_unmask(struct irq_data *data)
> @@ -219,11 +219,11 @@ static void t7l66xb_irq_unmask(struct irq_data *data)
>   unsigned long flags;
>   u8 imr;
>  
> - spin_lock_irqsave(>lock, flags);
> + raw_spin_lock_irqsave(>lock, flags);
>   imr = tmio_ioread8(t7l66xb->scr + SCR_IMR);
>   imr &= ~(1 << (data->irq - t7l66xb->irq_base));
>   tmio_iowrite8(imr, t7l66xb->scr + SCR_IMR);
> - spin_unlock_irqrestore(>lock, flags);
> + raw_spin_unlock_irqrestore(>lock, flags);
>  }
>  
>  static struct irq_chip t7l66xb_chip = {
> @@ -321,7 +321,7 @@ static int t7l66xb_probe(struct platform_device *dev)
>   if (!t7l66xb)
>   return -ENOMEM;
>  
> - spin_lock_init(>lock);
> + raw_spin_lock_init(>lock);
>  
>   platform_set_drvdata(dev, t7l66xb);
>  

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

Re: [PATCH v2 6/9] mfd: tc6393xb: make use of raw_spinlock variants

[Lee Jones]

On Tue, 21 Mar 2017, Julia Cartwright wrote:

> The tc6393xb mfd driver currently implements an irq_chip for handling
> interrupts; due to how irq_chip handling is done, it's necessary for the
> irq_chip methods to be invoked from hardirq context, even on a a
> real-time kernel.  Because the spinlock_t type becomes a "sleeping"
> spinlock w/ RT kernels, it is not suitable to be used with irq_chips.
> 
> A quick audit of the operations under the lock reveal that they do only
> minimal, bounded work, and are therefore safe to do under a raw spinlock.
> 
> Acked-for-MFD-by: Lee Jones 
> Signed-off-by: Julia Cartwright 
> ---
> v1 -> v2:
>   - No functional change.  Added Lee's ack.
> 
>  drivers/mfd/tc6393xb.c | 52 
> +-
>  1 file changed, 26 insertions(+), 26 deletions(-)

Applied, thanks.

> diff --git a/drivers/mfd/tc6393xb.c b/drivers/mfd/tc6393xb.c
> index d42d322ac7ca..d16e71bd9482 100644
> --- a/drivers/mfd/tc6393xb.c
> +++ b/drivers/mfd/tc6393xb.c
> @@ -95,7 +95,7 @@ struct tc6393xb {
>  
>   struct clk  *clk; /* 3,6 Mhz */
>  
> - spinlock_t  lock; /* protects RMW cycles */
> + raw_spinlock_t  lock; /* protects RMW cycles */
>  
>   struct {
>   u8  fer;
> @@ -126,13 +126,13 @@ static int tc6393xb_nand_enable(struct platform_device 
> *nand)
>   struct tc6393xb *tc6393xb = platform_get_drvdata(dev);
>   unsigned long flags;
>  
> - spin_lock_irqsave(>lock, flags);
> + raw_spin_lock_irqsave(>lock, flags);
>  
>   /* SMD buffer on */
>   dev_dbg(>dev, "SMD buffer on\n");
>   tmio_iowrite8(0xff, tc6393xb->scr + SCR_GPI_BCR(1));
>  
> - spin_unlock_irqrestore(>lock, flags);
> + raw_spin_unlock_irqrestore(>lock, flags);
>  
>   return 0;
>  }
> @@ -226,7 +226,7 @@ static int tc6393xb_ohci_enable(struct platform_device 
> *dev)
>   u16 ccr;
>   u8 fer;
>  
> - spin_lock_irqsave(>lock, flags);
> + raw_spin_lock_irqsave(>lock, flags);
>  
>   ccr = tmio_ioread16(tc6393xb->scr + SCR_CCR);
>   ccr |= SCR_CCR_USBCK;
> @@ -236,7 +236,7 @@ static int tc6393xb_ohci_enable(struct platform_device 
> *dev)
>   fer |= SCR_FER_USBEN;
>   tmio_iowrite8(fer, tc6393xb->scr + SCR_FER);
>  
> - spin_unlock_irqrestore(>lock, flags);
> + raw_spin_unlock_irqrestore(>lock, flags);
>  
>   return 0;
>  }
> @@ -248,7 +248,7 @@ static int tc6393xb_ohci_disable(struct platform_device 
> *dev)
>   u16 ccr;
>   u8 fer;
>  
> - spin_lock_irqsave(>lock, flags);
> + raw_spin_lock_irqsave(>lock, flags);
>  
>   fer = tmio_ioread8(tc6393xb->scr + SCR_FER);
>   fer &= ~SCR_FER_USBEN;
> @@ -258,7 +258,7 @@ static int tc6393xb_ohci_disable(struct platform_device 
> *dev)
>   ccr &= ~SCR_CCR_USBCK;
>   tmio_iowrite16(ccr, tc6393xb->scr + SCR_CCR);
>  
> - spin_unlock_irqrestore(>lock, flags);
> + raw_spin_unlock_irqrestore(>lock, flags);
>  
>   return 0;
>  }
> @@ -280,14 +280,14 @@ static int tc6393xb_fb_enable(struct platform_device 
> *dev)
>   unsigned long flags;
>   u16 ccr;
>  
> - spin_lock_irqsave(>lock, flags);
> + raw_spin_lock_irqsave(>lock, flags);
>  
>   ccr = tmio_ioread16(tc6393xb->scr + SCR_CCR);
>   ccr &= ~SCR_CCR_MCLK_MASK;
>   ccr |= SCR_CCR_MCLK_48;
>   tmio_iowrite16(ccr, tc6393xb->scr + SCR_CCR);
>  
> - spin_unlock_irqrestore(>lock, flags);
> + raw_spin_unlock_irqrestore(>lock, flags);
>  
>   return 0;
>  }
> @@ -298,14 +298,14 @@ static int tc6393xb_fb_disable(struct platform_device 
> *dev)
>   unsigned long flags;
>   u16 ccr;
>  
> - spin_lock_irqsave(>lock, flags);
> + raw_spin_lock_irqsave(>lock, flags);
>  
>   ccr = tmio_ioread16(tc6393xb->scr + SCR_CCR);
>   ccr &= ~SCR_CCR_MCLK_MASK;
>   ccr |= SCR_CCR_MCLK_OFF;
>   tmio_iowrite16(ccr, tc6393xb->scr + SCR_CCR);
>  
> - spin_unlock_irqrestore(>lock, flags);
> + raw_spin_unlock_irqrestore(>lock, flags);
>  
>   return 0;
>  }
> @@ -317,7 +317,7 @@ int tc6393xb_lcd_set_power(struct platform_device *fb, 
> bool on)
>   u8 fer;
>   unsigned long flags;
>  
> - spin_lock_irqsave(>lock, flags);
> + raw_spin_lock_irqsave(>lock, flags);
>  
>   fer = ioread8(tc6393xb->scr + SCR_FER);
>   if (on)
> @@ -326,7 +326,7 @@ int tc6393xb_lcd_set_power(struct platform_device *fb, 
> bool on)
>   fer &= ~SCR_FER_SLCDEN;
>   iowrite8(fer, tc6393xb->scr + SCR_FER);
>  
> - spin_unlock_irqrestore(>lock, flags);
> + raw_spin_unlock_irqrestore(>lock, flags);
>  
>   return 0;
>  }
> @@ -338,12 +338,12 @@ int tc6393xb_lcd_mode(struct platform_device *fb,
>   struct tc6393xb *tc6393xb = platform_get_drvdata(dev);
>   unsigned long flags;
>  
> - spin_lock_irqsave(>lock, flags);
> + raw_spin_lock_irqsave(>lock, flags);
>  
>   

Re: [PATCH v2 5/9] mfd: t7l66xb: make use of raw_spinlock variants

[Lee Jones]

On Tue, 21 Mar 2017, Julia Cartwright wrote:

> The t7l66xb mfd driver currently implements an irq_chip for handling
> interrupts; due to how irq_chip handling is done, it's necessary for the
> irq_chip methods to be invoked from hardirq context, even on a a
> real-time kernel.  Because the spinlock_t type becomes a "sleeping"
> spinlock w/ RT kernels, it is not suitable to be used with irq_chips.
> 
> A quick audit of the operations under the lock reveal that they do only
> minimal, bounded work, and are therefore safe to do under a raw spinlock.
> 
> Acked-for-MFD-by: Lee Jones 
> Signed-off-by: Julia Cartwright 
> ---
> v1 -> v2:
>   - No functional change.  Added Lee's ack.
> 
>  drivers/mfd/t7l66xb.c | 20 ++--
>  1 file changed, 10 insertions(+), 10 deletions(-)

Applied, thanks.

> diff --git a/drivers/mfd/t7l66xb.c b/drivers/mfd/t7l66xb.c
> index 94bd89cb1f06..22c811396edc 100644
> --- a/drivers/mfd/t7l66xb.c
> +++ b/drivers/mfd/t7l66xb.c
> @@ -69,7 +69,7 @@ static const struct resource t7l66xb_mmc_resources[] = {
>  struct t7l66xb {
>   void __iomem*scr;
>   /* Lock to protect registers requiring read/modify/write ops. */
> - spinlock_t  lock;
> + raw_spinlock_t  lock;
>  
>   struct resource rscr;
>   struct clk  *clk48m;
> @@ -89,13 +89,13 @@ static int t7l66xb_mmc_enable(struct platform_device *mmc)
>  
>   clk_prepare_enable(t7l66xb->clk32k);
>  
> - spin_lock_irqsave(>lock, flags);
> + raw_spin_lock_irqsave(>lock, flags);
>  
>   dev_ctl = tmio_ioread8(t7l66xb->scr + SCR_DEV_CTL);
>   dev_ctl |= SCR_DEV_CTL_MMC;
>   tmio_iowrite8(dev_ctl, t7l66xb->scr + SCR_DEV_CTL);
>  
> - spin_unlock_irqrestore(>lock, flags);
> + raw_spin_unlock_irqrestore(>lock, flags);
>  
>   tmio_core_mmc_enable(t7l66xb->scr + 0x200, 0,
>   t7l66xb_mmc_resources[0].start & 0xfffe);
> @@ -110,13 +110,13 @@ static int t7l66xb_mmc_disable(struct platform_device 
> *mmc)
>   unsigned long flags;
>   u8 dev_ctl;
>  
> - spin_lock_irqsave(>lock, flags);
> + raw_spin_lock_irqsave(>lock, flags);
>  
>   dev_ctl = tmio_ioread8(t7l66xb->scr + SCR_DEV_CTL);
>   dev_ctl &= ~SCR_DEV_CTL_MMC;
>   tmio_iowrite8(dev_ctl, t7l66xb->scr + SCR_DEV_CTL);
>  
> - spin_unlock_irqrestore(>lock, flags);
> + raw_spin_unlock_irqrestore(>lock, flags);
>  
>   clk_disable_unprepare(t7l66xb->clk32k);
>  
> @@ -206,11 +206,11 @@ static void t7l66xb_irq_mask(struct irq_data *data)
>   unsigned long   flags;
>   u8 imr;
>  
> - spin_lock_irqsave(>lock, flags);
> + raw_spin_lock_irqsave(>lock, flags);
>   imr = tmio_ioread8(t7l66xb->scr + SCR_IMR);
>   imr |= 1 << (data->irq - t7l66xb->irq_base);
>   tmio_iowrite8(imr, t7l66xb->scr + SCR_IMR);
> - spin_unlock_irqrestore(>lock, flags);
> + raw_spin_unlock_irqrestore(>lock, flags);
>  }
>  
>  static void t7l66xb_irq_unmask(struct irq_data *data)
> @@ -219,11 +219,11 @@ static void t7l66xb_irq_unmask(struct irq_data *data)
>   unsigned long flags;
>   u8 imr;
>  
> - spin_lock_irqsave(>lock, flags);
> + raw_spin_lock_irqsave(>lock, flags);
>   imr = tmio_ioread8(t7l66xb->scr + SCR_IMR);
>   imr &= ~(1 << (data->irq - t7l66xb->irq_base));
>   tmio_iowrite8(imr, t7l66xb->scr + SCR_IMR);
> - spin_unlock_irqrestore(>lock, flags);
> + raw_spin_unlock_irqrestore(>lock, flags);
>  }
>  
>  static struct irq_chip t7l66xb_chip = {
> @@ -321,7 +321,7 @@ static int t7l66xb_probe(struct platform_device *dev)
>   if (!t7l66xb)
>   return -ENOMEM;
>  
> - spin_lock_init(>lock);
> + raw_spin_lock_init(>lock);
>  
>   platform_set_drvdata(dev, t7l66xb);
>  

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

Re: [PATCH v2 6/9] mfd: tc6393xb: make use of raw_spinlock variants

[Lee Jones]

On Tue, 21 Mar 2017, Julia Cartwright wrote:

> The tc6393xb mfd driver currently implements an irq_chip for handling
> interrupts; due to how irq_chip handling is done, it's necessary for the
> irq_chip methods to be invoked from hardirq context, even on a a
> real-time kernel.  Because the spinlock_t type becomes a "sleeping"
> spinlock w/ RT kernels, it is not suitable to be used with irq_chips.
> 
> A quick audit of the operations under the lock reveal that they do only
> minimal, bounded work, and are therefore safe to do under a raw spinlock.
> 
> Acked-for-MFD-by: Lee Jones 
> Signed-off-by: Julia Cartwright 
> ---
> v1 -> v2:
>   - No functional change.  Added Lee's ack.
> 
>  drivers/mfd/tc6393xb.c | 52 
> +-
>  1 file changed, 26 insertions(+), 26 deletions(-)

Applied, thanks.

> diff --git a/drivers/mfd/tc6393xb.c b/drivers/mfd/tc6393xb.c
> index d42d322ac7ca..d16e71bd9482 100644
> --- a/drivers/mfd/tc6393xb.c
> +++ b/drivers/mfd/tc6393xb.c
> @@ -95,7 +95,7 @@ struct tc6393xb {
>  
>   struct clk  *clk; /* 3,6 Mhz */
>  
> - spinlock_t  lock; /* protects RMW cycles */
> + raw_spinlock_t  lock; /* protects RMW cycles */
>  
>   struct {
>   u8  fer;
> @@ -126,13 +126,13 @@ static int tc6393xb_nand_enable(struct platform_device 
> *nand)
>   struct tc6393xb *tc6393xb = platform_get_drvdata(dev);
>   unsigned long flags;
>  
> - spin_lock_irqsave(>lock, flags);
> + raw_spin_lock_irqsave(>lock, flags);
>  
>   /* SMD buffer on */
>   dev_dbg(>dev, "SMD buffer on\n");
>   tmio_iowrite8(0xff, tc6393xb->scr + SCR_GPI_BCR(1));
>  
> - spin_unlock_irqrestore(>lock, flags);
> + raw_spin_unlock_irqrestore(>lock, flags);
>  
>   return 0;
>  }
> @@ -226,7 +226,7 @@ static int tc6393xb_ohci_enable(struct platform_device 
> *dev)
>   u16 ccr;
>   u8 fer;
>  
> - spin_lock_irqsave(>lock, flags);
> + raw_spin_lock_irqsave(>lock, flags);
>  
>   ccr = tmio_ioread16(tc6393xb->scr + SCR_CCR);
>   ccr |= SCR_CCR_USBCK;
> @@ -236,7 +236,7 @@ static int tc6393xb_ohci_enable(struct platform_device 
> *dev)
>   fer |= SCR_FER_USBEN;
>   tmio_iowrite8(fer, tc6393xb->scr + SCR_FER);
>  
> - spin_unlock_irqrestore(>lock, flags);
> + raw_spin_unlock_irqrestore(>lock, flags);
>  
>   return 0;
>  }
> @@ -248,7 +248,7 @@ static int tc6393xb_ohci_disable(struct platform_device 
> *dev)
>   u16 ccr;
>   u8 fer;
>  
> - spin_lock_irqsave(>lock, flags);
> + raw_spin_lock_irqsave(>lock, flags);
>  
>   fer = tmio_ioread8(tc6393xb->scr + SCR_FER);
>   fer &= ~SCR_FER_USBEN;
> @@ -258,7 +258,7 @@ static int tc6393xb_ohci_disable(struct platform_device 
> *dev)
>   ccr &= ~SCR_CCR_USBCK;
>   tmio_iowrite16(ccr, tc6393xb->scr + SCR_CCR);
>  
> - spin_unlock_irqrestore(>lock, flags);
> + raw_spin_unlock_irqrestore(>lock, flags);
>  
>   return 0;
>  }
> @@ -280,14 +280,14 @@ static int tc6393xb_fb_enable(struct platform_device 
> *dev)
>   unsigned long flags;
>   u16 ccr;
>  
> - spin_lock_irqsave(>lock, flags);
> + raw_spin_lock_irqsave(>lock, flags);
>  
>   ccr = tmio_ioread16(tc6393xb->scr + SCR_CCR);
>   ccr &= ~SCR_CCR_MCLK_MASK;
>   ccr |= SCR_CCR_MCLK_48;
>   tmio_iowrite16(ccr, tc6393xb->scr + SCR_CCR);
>  
> - spin_unlock_irqrestore(>lock, flags);
> + raw_spin_unlock_irqrestore(>lock, flags);
>  
>   return 0;
>  }
> @@ -298,14 +298,14 @@ static int tc6393xb_fb_disable(struct platform_device 
> *dev)
>   unsigned long flags;
>   u16 ccr;
>  
> - spin_lock_irqsave(>lock, flags);
> + raw_spin_lock_irqsave(>lock, flags);
>  
>   ccr = tmio_ioread16(tc6393xb->scr + SCR_CCR);
>   ccr &= ~SCR_CCR_MCLK_MASK;
>   ccr |= SCR_CCR_MCLK_OFF;
>   tmio_iowrite16(ccr, tc6393xb->scr + SCR_CCR);
>  
> - spin_unlock_irqrestore(>lock, flags);
> + raw_spin_unlock_irqrestore(>lock, flags);
>  
>   return 0;
>  }
> @@ -317,7 +317,7 @@ int tc6393xb_lcd_set_power(struct platform_device *fb, 
> bool on)
>   u8 fer;
>   unsigned long flags;
>  
> - spin_lock_irqsave(>lock, flags);
> + raw_spin_lock_irqsave(>lock, flags);
>  
>   fer = ioread8(tc6393xb->scr + SCR_FER);
>   if (on)
> @@ -326,7 +326,7 @@ int tc6393xb_lcd_set_power(struct platform_device *fb, 
> bool on)
>   fer &= ~SCR_FER_SLCDEN;
>   iowrite8(fer, tc6393xb->scr + SCR_FER);
>  
> - spin_unlock_irqrestore(>lock, flags);
> + raw_spin_unlock_irqrestore(>lock, flags);
>  
>   return 0;
>  }
> @@ -338,12 +338,12 @@ int tc6393xb_lcd_mode(struct platform_device *fb,
>   struct tc6393xb *tc6393xb = platform_get_drvdata(dev);
>   unsigned long flags;
>  
> - spin_lock_irqsave(>lock, flags);
> + raw_spin_lock_irqsave(>lock, flags);
>  
>   iowrite16(mode->pixclock, tc6393xb->scr + SCR_PLL1CR + 

[PATCH v2] net: stmmac: add set_mac to the stmmac_ops

[Corentin Labbe]

Two different set_mac functions exists but stmmac_dwmac4_set_mac() is
only used for enabling and never for disabling.
So on dwmac4, the MAC RX/TX is never disabled.

This patch add a generic function pointer set_mac() to stmmac_ops and
replace all call to stmmac_set_mac/stmmac_dwmac4_set_mac by a call to
this pointer.

Since dwmac4_ops is const, set_mac cannot be modified after, and so dwmac4_ops
is duplioacted like dwmac4_dma_ops.

Signed-off-by: Corentin Labbe 
---
 drivers/net/ethernet/stmicro/stmmac/common.h   |  2 ++
 .../net/ethernet/stmicro/stmmac/dwmac1000_core.c   |  1 +
 .../net/ethernet/stmicro/stmmac/dwmac100_core.c|  1 +
 drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c  | 39 --
 drivers/net/ethernet/stmicro/stmmac/stmmac_main.c  | 11 +++---
 5 files changed, 45 insertions(+), 9 deletions(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/common.h 
b/drivers/net/ethernet/stmicro/stmmac/common.h
index 572cf8b..90d28bc 100644
--- a/drivers/net/ethernet/stmicro/stmmac/common.h
+++ b/drivers/net/ethernet/stmicro/stmmac/common.h
@@ -474,6 +474,8 @@ struct mac_device_info;
 struct stmmac_ops {
/* MAC core initialization */
void (*core_init)(struct mac_device_info *hw, int mtu);
+   /* Enable the MAC RX/TX */
+   void (*set_mac)(void __iomem *ioaddr, bool enable);
/* Enable and verify that the IPC module is supported */
int (*rx_ipc)(struct mac_device_info *hw);
/* Enable RX Queues */
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac1000_core.c 
b/drivers/net/ethernet/stmicro/stmmac/dwmac1000_core.c
index 7f78f77..f3d9305 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac1000_core.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac1000_core.c
@@ -490,6 +490,7 @@ static void dwmac1000_debug(void __iomem *ioaddr, struct 
stmmac_extra_stats *x,
 
 static const struct stmmac_ops dwmac1000_ops = {
.core_init = dwmac1000_core_init,
+   .set_mac = stmmac_set_mac,
.rx_ipc = dwmac1000_rx_ipc_enable,
.dump_regs = dwmac1000_dump_regs,
.host_irq_status = dwmac1000_irq_status,
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac100_core.c 
b/drivers/net/ethernet/stmicro/stmmac/dwmac100_core.c
index 524135e..1b36091 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac100_core.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac100_core.c
@@ -150,6 +150,7 @@ static void dwmac100_pmt(struct mac_device_info *hw, 
unsigned long mode)
 
 static const struct stmmac_ops dwmac100_ops = {
.core_init = dwmac100_core_init,
+   .set_mac = stmmac_set_mac,
.rx_ipc = dwmac100_rx_ipc_enable,
.dump_regs = dwmac100_dump_mac_regs,
.host_irq_status = dwmac100_irq_status,
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c 
b/drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c
index 40ce202..48793f2 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c
@@ -669,6 +669,38 @@ static void dwmac4_debug(void __iomem *ioaddr, struct 
stmmac_extra_stats *x,
 
 static const struct stmmac_ops dwmac4_ops = {
.core_init = dwmac4_core_init,
+   .set_mac = stmmac_set_mac,
+   .rx_ipc = dwmac4_rx_ipc_enable,
+   .rx_queue_enable = dwmac4_rx_queue_enable,
+   .rx_queue_prio = dwmac4_rx_queue_priority,
+   .tx_queue_prio = dwmac4_tx_queue_priority,
+   .rx_queue_routing = dwmac4_tx_queue_routing,
+   .prog_mtl_rx_algorithms = dwmac4_prog_mtl_rx_algorithms,
+   .prog_mtl_tx_algorithms = dwmac4_prog_mtl_tx_algorithms,
+   .set_mtl_tx_queue_weight = dwmac4_set_mtl_tx_queue_weight,
+   .map_mtl_to_dma = dwmac4_map_mtl_dma,
+   .config_cbs = dwmac4_config_cbs,
+   .dump_regs = dwmac4_dump_regs,
+   .host_irq_status = dwmac4_irq_status,
+   .host_mtl_irq_status = dwmac4_irq_mtl_status,
+   .flow_ctrl = dwmac4_flow_ctrl,
+   .pmt = dwmac4_pmt,
+   .set_umac_addr = dwmac4_set_umac_addr,
+   .get_umac_addr = dwmac4_get_umac_addr,
+   .set_eee_mode = dwmac4_set_eee_mode,
+   .reset_eee_mode = dwmac4_reset_eee_mode,
+   .set_eee_timer = dwmac4_set_eee_timer,
+   .set_eee_pls = dwmac4_set_eee_pls,
+   .pcs_ctrl_ane = dwmac4_ctrl_ane,
+   .pcs_rane = dwmac4_rane,
+   .pcs_get_adv_lp = dwmac4_get_adv_lp,
+   .debug = dwmac4_debug,
+   .set_filter = dwmac4_set_filter,
+};
+
+static const struct stmmac_ops dwmac410_ops = {
+   .core_init = dwmac4_core_init,
+   .set_mac = stmmac_dwmac4_set_mac,
.rx_ipc = dwmac4_rx_ipc_enable,
.rx_queue_enable = dwmac4_rx_queue_enable,
.rx_queue_prio = dwmac4_rx_queue_priority,
@@ -715,8 +747,6 @@ struct mac_device_info *dwmac4_setup(void __iomem *ioaddr, 
int mcbins,
if (mac->multicast_filter_bins)
mac->mcast_bits_log2 = ilog2(mac->multicast_filter_bins);
 
-   mac->mac = _ops;
-
mac->link.port = 

[PATCH v2] net: stmmac: add set_mac to the stmmac_ops

[Corentin Labbe]

Two different set_mac functions exists but stmmac_dwmac4_set_mac() is
only used for enabling and never for disabling.
So on dwmac4, the MAC RX/TX is never disabled.

This patch add a generic function pointer set_mac() to stmmac_ops and
replace all call to stmmac_set_mac/stmmac_dwmac4_set_mac by a call to
this pointer.

Since dwmac4_ops is const, set_mac cannot be modified after, and so dwmac4_ops
is duplioacted like dwmac4_dma_ops.

Signed-off-by: Corentin Labbe 
---
 drivers/net/ethernet/stmicro/stmmac/common.h   |  2 ++
 .../net/ethernet/stmicro/stmmac/dwmac1000_core.c   |  1 +
 .../net/ethernet/stmicro/stmmac/dwmac100_core.c|  1 +
 drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c  | 39 --
 drivers/net/ethernet/stmicro/stmmac/stmmac_main.c  | 11 +++---
 5 files changed, 45 insertions(+), 9 deletions(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/common.h 
b/drivers/net/ethernet/stmicro/stmmac/common.h
index 572cf8b..90d28bc 100644
--- a/drivers/net/ethernet/stmicro/stmmac/common.h
+++ b/drivers/net/ethernet/stmicro/stmmac/common.h
@@ -474,6 +474,8 @@ struct mac_device_info;
 struct stmmac_ops {
/* MAC core initialization */
void (*core_init)(struct mac_device_info *hw, int mtu);
+   /* Enable the MAC RX/TX */
+   void (*set_mac)(void __iomem *ioaddr, bool enable);
/* Enable and verify that the IPC module is supported */
int (*rx_ipc)(struct mac_device_info *hw);
/* Enable RX Queues */
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac1000_core.c 
b/drivers/net/ethernet/stmicro/stmmac/dwmac1000_core.c
index 7f78f77..f3d9305 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac1000_core.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac1000_core.c
@@ -490,6 +490,7 @@ static void dwmac1000_debug(void __iomem *ioaddr, struct 
stmmac_extra_stats *x,
 
 static const struct stmmac_ops dwmac1000_ops = {
.core_init = dwmac1000_core_init,
+   .set_mac = stmmac_set_mac,
.rx_ipc = dwmac1000_rx_ipc_enable,
.dump_regs = dwmac1000_dump_regs,
.host_irq_status = dwmac1000_irq_status,
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac100_core.c 
b/drivers/net/ethernet/stmicro/stmmac/dwmac100_core.c
index 524135e..1b36091 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac100_core.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac100_core.c
@@ -150,6 +150,7 @@ static void dwmac100_pmt(struct mac_device_info *hw, 
unsigned long mode)
 
 static const struct stmmac_ops dwmac100_ops = {
.core_init = dwmac100_core_init,
+   .set_mac = stmmac_set_mac,
.rx_ipc = dwmac100_rx_ipc_enable,
.dump_regs = dwmac100_dump_mac_regs,
.host_irq_status = dwmac100_irq_status,
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c 
b/drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c
index 40ce202..48793f2 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c
@@ -669,6 +669,38 @@ static void dwmac4_debug(void __iomem *ioaddr, struct 
stmmac_extra_stats *x,
 
 static const struct stmmac_ops dwmac4_ops = {
.core_init = dwmac4_core_init,
+   .set_mac = stmmac_set_mac,
+   .rx_ipc = dwmac4_rx_ipc_enable,
+   .rx_queue_enable = dwmac4_rx_queue_enable,
+   .rx_queue_prio = dwmac4_rx_queue_priority,
+   .tx_queue_prio = dwmac4_tx_queue_priority,
+   .rx_queue_routing = dwmac4_tx_queue_routing,
+   .prog_mtl_rx_algorithms = dwmac4_prog_mtl_rx_algorithms,
+   .prog_mtl_tx_algorithms = dwmac4_prog_mtl_tx_algorithms,
+   .set_mtl_tx_queue_weight = dwmac4_set_mtl_tx_queue_weight,
+   .map_mtl_to_dma = dwmac4_map_mtl_dma,
+   .config_cbs = dwmac4_config_cbs,
+   .dump_regs = dwmac4_dump_regs,
+   .host_irq_status = dwmac4_irq_status,
+   .host_mtl_irq_status = dwmac4_irq_mtl_status,
+   .flow_ctrl = dwmac4_flow_ctrl,
+   .pmt = dwmac4_pmt,
+   .set_umac_addr = dwmac4_set_umac_addr,
+   .get_umac_addr = dwmac4_get_umac_addr,
+   .set_eee_mode = dwmac4_set_eee_mode,
+   .reset_eee_mode = dwmac4_reset_eee_mode,
+   .set_eee_timer = dwmac4_set_eee_timer,
+   .set_eee_pls = dwmac4_set_eee_pls,
+   .pcs_ctrl_ane = dwmac4_ctrl_ane,
+   .pcs_rane = dwmac4_rane,
+   .pcs_get_adv_lp = dwmac4_get_adv_lp,
+   .debug = dwmac4_debug,
+   .set_filter = dwmac4_set_filter,
+};
+
+static const struct stmmac_ops dwmac410_ops = {
+   .core_init = dwmac4_core_init,
+   .set_mac = stmmac_dwmac4_set_mac,
.rx_ipc = dwmac4_rx_ipc_enable,
.rx_queue_enable = dwmac4_rx_queue_enable,
.rx_queue_prio = dwmac4_rx_queue_priority,
@@ -715,8 +747,6 @@ struct mac_device_info *dwmac4_setup(void __iomem *ioaddr, 
int mcbins,
if (mac->multicast_filter_bins)
mac->mcast_bits_log2 = ilog2(mac->multicast_filter_bins);
 
-   mac->mac = _ops;
-
mac->link.port = GMAC_CONFIG_PS;

Re: [BUG] 4.11.0-rc3 xterm hung in D state on exit, wchan is tty_release_struct

[Rob Herring]

On Thu, Mar 23, 2017 at 12:30:18AM -0700, l...@pengaru.com wrote:
> On Wed, Mar 22, 2017 at 11:44:18PM -0700, l...@pengaru.com wrote:
> > On Wed, Mar 22, 2017 at 07:08:46PM -0700, l...@pengaru.com wrote:
> > > Hello list,
> > > 
> > > After approximately one day day of running 4.11.0-rc3 with 7e54d9d 
> > > reverted to
> > > enable regular use, this happened upon destroying an xterm:
> > > 
> > > [80817.525112] BUG: unable to handle kernel paging request at 
> > > 2260
> > > [80817.525239] IP: n_tty_receive_buf_common+0x68/0xab0
> > > [80817.525312] PGD 0 
> > > 
> > > [80817.525387] Oops:  [#1] PREEMPT SMP
> > > [80817.525452] CPU: 0 PID: 9532 Comm: kworker/u4:3 Not tainted 
> > > 4.11.0-rc3-1-gc56a355 #53
> > > [80817.525564] Hardware name: LENOVO 7668CTO/7668CTO, BIOS 7NETC2WW (2.22 
> > > ) 03/22/2011
> > > [80817.525673] Workqueue: events_unbound flush_to_ldisc
> > > [80817.525752] task: 967d91d8 task.stack: 9add81f4
> > > [80817.525839] RIP: 0010:n_tty_receive_buf_common+0x68/0xab0
> > > [80817.525917] RSP: 0018:9add81f43d38 EFLAGS: 00010297
> > > [80817.525992] RAX:  RBX: 967d91c98c00 RCX: 
> > > 0001
> > > [80817.526035] RDX: 967e73bba58d RSI: 967e73bba48d RDI: 
> > > 967d91c98cc0
> > > [80817.526035] RBP: 9add81f43dd0 R08: 0001 R09: 
> > > 
> > > [80817.526035] R10: 4980cbe001e0 R11:  R12: 
> > > 967d87aacf20
> > > [80817.526035] R13: 967e73bba58d R14: 0001 R15: 
> > > 967e74aa8008
> > > [80817.526035] FS:  () GS:967e7bc0() 
> > > knlGS:
> > > [80817.526035] CS:  0010 DS:  ES:  CR0: 80050033
> > > [80817.526035] CR2: 2260 CR3: 99009000 CR4: 
> > > 06f0
> > > [80817.526035] Call Trace:
> > > [80817.526035]  ? update_curr+0xbb/0x1a0
> > > [80817.526035]  n_tty_receive_buf2+0xf/0x20
> > > [80817.526035]  tty_ldisc_receive_buf+0x1d/0x50
> > > [80817.526035]  tty_port_default_receive_buf+0x40/0x60
> > > [80817.526035]  flush_to_ldisc+0x94/0xa0
> > > [80817.526035]  process_one_work+0x13b/0x3e0
> > > [80817.526035]  worker_thread+0x64/0x4a0
> > > [80817.526035]  kthread+0x10f/0x150
> > > [80817.526035]  ? process_one_work+0x3e0/0x3e0
> > > [80817.526035]  ? __kthread_create_on_node+0x150/0x150
> > > [80817.526035]  ret_from_fork+0x29/0x40
> > > [80817.526035] Code: 85 70 ff ff ff e8 59 75 57 00 48 8d 83 00 02 00 00 
> > > c7 45 c8 00 00 00 00 48 89 45 98 48 8d 83 28 02 00 00 48 89 45 90 48 8b 
> > > 45 b8 <48> 8b b0 60 22 00 00 48 8b 08 89 f0 29 c8 f6 83 10 01 00 00 08 
> > > [80817.526035] RIP: n_tty_receive_buf_common+0x68/0xab0 RSP: 
> > > 9add81f43d38
> > > [80817.526035] CR2: 2260
> > > [80817.526035] ---[ end trace 640aec4765d350f2 ]---
> > > 
> > > 
> > > That xterm process is stuck, and I am unable to start any new xterms, 
> > > switching to virtual consoles proves useless, presumably there's an 
> > > important lock held.
> > > 
> > 
> > 
> > At a casual glance of the v4.10..v4.11-rc3 changes affecting drivers/tty, 
> > the
> > commit c3485e looks suspicious to me, these hunks in particular:

Have you tried reverting it to confirm?

I'm not completely surprised. I did ask folks to look at this part.

> > 
> > @@ -465,16 +465,6 @@ static void flush_to_ldisc(struct work_struct *work)
> >  {
> > struct tty_port *port = container_of(work, struct tty_port, 
> > buf.work);
> > struct tty_bufhead *buf = >buf;
> > -   struct tty_struct *tty;
> > -   struct tty_ldisc *disc;
> > -
> > -   tty = READ_ONCE(port->itty);
> > -   if (tty == NULL)
> > -   return;
> > -
> > -   disc = tty_ldisc_ref(tty);
> > -   if (disc == NULL)
> > -   return;
> >  
> > mutex_lock(>lock);
> >  
> > @@ -504,7 +494,7 @@ static void flush_to_ldisc(struct work_struct *work)
> > continue;
> > }
> >  
> > -   count = receive_buf(disc, head, count);
> > +   count = receive_buf(port, head, count);
> > if (!count)
> > break;
> > head->read += count;
> > @@ -512,7 +502,6 @@ static void flush_to_ldisc(struct work_struct *work)
> >  
> > mutex_unlock(>lock);
> >  
> > -   tty_ldisc_deref(disc);
> >  }
> >  
> >  /**
> > 
> > 
> > 
> > I'm not familiar with this code at all, but port->buf is part of port, and 
> > if
> > the port is destroyed as part of the tty, then perhaps port->buf (and
> > port->buf->lock) may become invalid on us without these:
> > 
> > -   tty = READ_ONCE(port->itty);
> > -   if (tty == NULL)
> > -   return;
> > -
> > -   disc = tty_ldisc_ref(tty);
> > -   if (disc == NULL)
> > -   return;

AIUI, the lifetime of the port is tied to the lifetime of the device 
while the lifetime of the tty is tied to the 

Re: [BUG] 4.11.0-rc3 xterm hung in D state on exit, wchan is tty_release_struct

[Rob Herring]

On Thu, Mar 23, 2017 at 12:30:18AM -0700, l...@pengaru.com wrote:
> On Wed, Mar 22, 2017 at 11:44:18PM -0700, l...@pengaru.com wrote:
> > On Wed, Mar 22, 2017 at 07:08:46PM -0700, l...@pengaru.com wrote:
> > > Hello list,
> > > 
> > > After approximately one day day of running 4.11.0-rc3 with 7e54d9d 
> > > reverted to
> > > enable regular use, this happened upon destroying an xterm:
> > > 
> > > [80817.525112] BUG: unable to handle kernel paging request at 
> > > 2260
> > > [80817.525239] IP: n_tty_receive_buf_common+0x68/0xab0
> > > [80817.525312] PGD 0 
> > > 
> > > [80817.525387] Oops:  [#1] PREEMPT SMP
> > > [80817.525452] CPU: 0 PID: 9532 Comm: kworker/u4:3 Not tainted 
> > > 4.11.0-rc3-1-gc56a355 #53
> > > [80817.525564] Hardware name: LENOVO 7668CTO/7668CTO, BIOS 7NETC2WW (2.22 
> > > ) 03/22/2011
> > > [80817.525673] Workqueue: events_unbound flush_to_ldisc
> > > [80817.525752] task: 967d91d8 task.stack: 9add81f4
> > > [80817.525839] RIP: 0010:n_tty_receive_buf_common+0x68/0xab0
> > > [80817.525917] RSP: 0018:9add81f43d38 EFLAGS: 00010297
> > > [80817.525992] RAX:  RBX: 967d91c98c00 RCX: 
> > > 0001
> > > [80817.526035] RDX: 967e73bba58d RSI: 967e73bba48d RDI: 
> > > 967d91c98cc0
> > > [80817.526035] RBP: 9add81f43dd0 R08: 0001 R09: 
> > > 
> > > [80817.526035] R10: 4980cbe001e0 R11:  R12: 
> > > 967d87aacf20
> > > [80817.526035] R13: 967e73bba58d R14: 0001 R15: 
> > > 967e74aa8008
> > > [80817.526035] FS:  () GS:967e7bc0() 
> > > knlGS:
> > > [80817.526035] CS:  0010 DS:  ES:  CR0: 80050033
> > > [80817.526035] CR2: 2260 CR3: 99009000 CR4: 
> > > 06f0
> > > [80817.526035] Call Trace:
> > > [80817.526035]  ? update_curr+0xbb/0x1a0
> > > [80817.526035]  n_tty_receive_buf2+0xf/0x20
> > > [80817.526035]  tty_ldisc_receive_buf+0x1d/0x50
> > > [80817.526035]  tty_port_default_receive_buf+0x40/0x60
> > > [80817.526035]  flush_to_ldisc+0x94/0xa0
> > > [80817.526035]  process_one_work+0x13b/0x3e0
> > > [80817.526035]  worker_thread+0x64/0x4a0
> > > [80817.526035]  kthread+0x10f/0x150
> > > [80817.526035]  ? process_one_work+0x3e0/0x3e0
> > > [80817.526035]  ? __kthread_create_on_node+0x150/0x150
> > > [80817.526035]  ret_from_fork+0x29/0x40
> > > [80817.526035] Code: 85 70 ff ff ff e8 59 75 57 00 48 8d 83 00 02 00 00 
> > > c7 45 c8 00 00 00 00 48 89 45 98 48 8d 83 28 02 00 00 48 89 45 90 48 8b 
> > > 45 b8 <48> 8b b0 60 22 00 00 48 8b 08 89 f0 29 c8 f6 83 10 01 00 00 08 
> > > [80817.526035] RIP: n_tty_receive_buf_common+0x68/0xab0 RSP: 
> > > 9add81f43d38
> > > [80817.526035] CR2: 2260
> > > [80817.526035] ---[ end trace 640aec4765d350f2 ]---
> > > 
> > > 
> > > That xterm process is stuck, and I am unable to start any new xterms, 
> > > switching to virtual consoles proves useless, presumably there's an 
> > > important lock held.
> > > 
> > 
> > 
> > At a casual glance of the v4.10..v4.11-rc3 changes affecting drivers/tty, 
> > the
> > commit c3485e looks suspicious to me, these hunks in particular:

Have you tried reverting it to confirm?

I'm not completely surprised. I did ask folks to look at this part.

> > 
> > @@ -465,16 +465,6 @@ static void flush_to_ldisc(struct work_struct *work)
> >  {
> > struct tty_port *port = container_of(work, struct tty_port, 
> > buf.work);
> > struct tty_bufhead *buf = >buf;
> > -   struct tty_struct *tty;
> > -   struct tty_ldisc *disc;
> > -
> > -   tty = READ_ONCE(port->itty);
> > -   if (tty == NULL)
> > -   return;
> > -
> > -   disc = tty_ldisc_ref(tty);
> > -   if (disc == NULL)
> > -   return;
> >  
> > mutex_lock(>lock);
> >  
> > @@ -504,7 +494,7 @@ static void flush_to_ldisc(struct work_struct *work)
> > continue;
> > }
> >  
> > -   count = receive_buf(disc, head, count);
> > +   count = receive_buf(port, head, count);
> > if (!count)
> > break;
> > head->read += count;
> > @@ -512,7 +502,6 @@ static void flush_to_ldisc(struct work_struct *work)
> >  
> > mutex_unlock(>lock);
> >  
> > -   tty_ldisc_deref(disc);
> >  }
> >  
> >  /**
> > 
> > 
> > 
> > I'm not familiar with this code at all, but port->buf is part of port, and 
> > if
> > the port is destroyed as part of the tty, then perhaps port->buf (and
> > port->buf->lock) may become invalid on us without these:
> > 
> > -   tty = READ_ONCE(port->itty);
> > -   if (tty == NULL)
> > -   return;
> > -
> > -   disc = tty_ldisc_ref(tty);
> > -   if (disc == NULL)
> > -   return;

AIUI, the lifetime of the port is tied to the lifetime of the device 
while the lifetime of the tty is tied to the 

Re: [PATCH] drm/i915/kvmgt: avoid dereferencing a potentially null info pointer

[Frans Klaver]

On Thu, Mar 23, 2017 at 1:22 PM, Colin King  wrote:
> From: Colin Ian King 
>
> info is being checked to see if it is a null pointer, however, vpgu is
> dereferencing info before this check, leading to a potential null
> pointer dereference.  If info is null, then the error message being
> printed by macro gvt_vgpu_err and this requires vpgu to exist. We can
> use a null vpgu as the macro has a sanity check to see if vpgu is null,
> so this is OK.
>
> Detected with CoverityScan, CID#1420672 ("Dereference nefore null check")

s,nefore,before,


>
> Fixes: 695fbc08d80f ("drm/i915/gvt: replace the gvt_err with gvt_vgpu_err")
> Signed-off-by: Colin Ian King 
> ---
>  drivers/gpu/drm/i915/gvt/kvmgt.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gvt/kvmgt.c 
> b/drivers/gpu/drm/i915/gvt/kvmgt.c
> index 1ea3eb270de8..f8619a772c44 100644
> --- a/drivers/gpu/drm/i915/gvt/kvmgt.c
> +++ b/drivers/gpu/drm/i915/gvt/kvmgt.c
> @@ -1339,9 +1339,9 @@ static int kvmgt_guest_init(struct mdev_device *mdev)
>
>  static bool kvmgt_guest_exit(struct kvmgt_guest_info *info)
>  {
> -   struct intel_vgpu *vgpu = info->vgpu;
> -
> if (!info) {
> +   struct intel_vgpu *vgpu = NULL;
> +
> gvt_vgpu_err("kvmgt_guest_info invalid\n");
> return false;
> }

Does this mean the original gvt_err() macro is no longer there?

And apparently gvt_vgpu_err is a macro that depends on the specifics
of its environment? Yikes.

Cheers,
Frans

Re: [PATCH] drm/i915/kvmgt: avoid dereferencing a potentially null info pointer

[Frans Klaver]

On Thu, Mar 23, 2017 at 1:22 PM, Colin King  wrote:
> From: Colin Ian King 
>
> info is being checked to see if it is a null pointer, however, vpgu is
> dereferencing info before this check, leading to a potential null
> pointer dereference.  If info is null, then the error message being
> printed by macro gvt_vgpu_err and this requires vpgu to exist. We can
> use a null vpgu as the macro has a sanity check to see if vpgu is null,
> so this is OK.
>
> Detected with CoverityScan, CID#1420672 ("Dereference nefore null check")

s,nefore,before,


>
> Fixes: 695fbc08d80f ("drm/i915/gvt: replace the gvt_err with gvt_vgpu_err")
> Signed-off-by: Colin Ian King 
> ---
>  drivers/gpu/drm/i915/gvt/kvmgt.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gvt/kvmgt.c 
> b/drivers/gpu/drm/i915/gvt/kvmgt.c
> index 1ea3eb270de8..f8619a772c44 100644
> --- a/drivers/gpu/drm/i915/gvt/kvmgt.c
> +++ b/drivers/gpu/drm/i915/gvt/kvmgt.c
> @@ -1339,9 +1339,9 @@ static int kvmgt_guest_init(struct mdev_device *mdev)
>
>  static bool kvmgt_guest_exit(struct kvmgt_guest_info *info)
>  {
> -   struct intel_vgpu *vgpu = info->vgpu;
> -
> if (!info) {
> +   struct intel_vgpu *vgpu = NULL;
> +
> gvt_vgpu_err("kvmgt_guest_info invalid\n");
> return false;
> }

Does this mean the original gvt_err() macro is no longer there?

And apparently gvt_vgpu_err is a macro that depends on the specifics
of its environment? Yikes.

Cheers,
Frans

Re: [PATCH v2 4/9] mfd: asic3: make use of raw_spinlock variants

[Lee Jones]

On Tue, 21 Mar 2017, Julia Cartwright wrote:

> The asic3 mfd driver currently implements an irq_chip for handling
> interrupts; due to how irq_chip handling is done, it's necessary for the
> irq_chip methods to be invoked from hardirq context, even on a a
> real-time kernel.  Because the spinlock_t type becomes a "sleeping"
> spinlock w/ RT kernels, it is not suitable to be used with irq_chips.
> 
> A quick audit of the operations under the lock reveal that they do only
> minimal, bounded work, and are therefore safe to do under a raw spinlock.
> 
> Acked-for-MFD-by: Lee Jones 
> Signed-off-by: Julia Cartwright 
> ---
> v1 -> v2:
>   - No functional change.  Added Lee's ack.
> 
>  drivers/mfd/asic3.c | 56 
> ++---
>  1 file changed, 28 insertions(+), 28 deletions(-)

Applied, thanks.

> diff --git a/drivers/mfd/asic3.c b/drivers/mfd/asic3.c
> index 0413c8159551..cf2e25ab2940 100644
> --- a/drivers/mfd/asic3.c
> +++ b/drivers/mfd/asic3.c
> @@ -78,7 +78,7 @@ struct asic3 {
>   unsigned int bus_shift;
>   unsigned int irq_nr;
>   unsigned int irq_base;
> - spinlock_t lock;
> + raw_spinlock_t lock;
>   u16 irq_bothedge[4];
>   struct gpio_chip gpio;
>   struct device *dev;
> @@ -108,14 +108,14 @@ static void asic3_set_register(struct asic3 *asic, u32 
> reg, u32 bits, bool set)
>   unsigned long flags;
>   u32 val;
>  
> - spin_lock_irqsave(>lock, flags);
> + raw_spin_lock_irqsave(>lock, flags);
>   val = asic3_read_register(asic, reg);
>   if (set)
>   val |= bits;
>   else
>   val &= ~bits;
>   asic3_write_register(asic, reg, val);
> - spin_unlock_irqrestore(>lock, flags);
> + raw_spin_unlock_irqrestore(>lock, flags);
>  }
>  
>  /* IRQs */
> @@ -129,13 +129,13 @@ static void asic3_irq_flip_edge(struct asic3 *asic,
>   u16 edge;
>   unsigned long flags;
>  
> - spin_lock_irqsave(>lock, flags);
> + raw_spin_lock_irqsave(>lock, flags);
>   edge = asic3_read_register(asic,
>  base + ASIC3_GPIO_EDGE_TRIGGER);
>   edge ^= bit;
>   asic3_write_register(asic,
>base + ASIC3_GPIO_EDGE_TRIGGER, edge);
> - spin_unlock_irqrestore(>lock, flags);
> + raw_spin_unlock_irqrestore(>lock, flags);
>  }
>  
>  static void asic3_irq_demux(struct irq_desc *desc)
> @@ -151,10 +151,10 @@ static void asic3_irq_demux(struct irq_desc *desc)
>   u32 status;
>   int bank;
>  
> - spin_lock_irqsave(>lock, flags);
> + raw_spin_lock_irqsave(>lock, flags);
>   status = asic3_read_register(asic,
>ASIC3_OFFSET(INTR, P_INT_STAT));
> - spin_unlock_irqrestore(>lock, flags);
> + raw_spin_unlock_irqrestore(>lock, flags);
>  
>   /* Check all ten register bits */
>   if ((status & 0x3ff) == 0)
> @@ -167,7 +167,7 @@ static void asic3_irq_demux(struct irq_desc *desc)
>  
>   base = ASIC3_GPIO_A_BASE
>  + bank * ASIC3_GPIO_BASE_INCR;
> - spin_lock_irqsave(>lock, flags);
> + raw_spin_lock_irqsave(>lock, flags);
>   istat = asic3_read_register(asic,
>   base +
>   
> ASIC3_GPIO_INT_STATUS);
> @@ -175,7 +175,7 @@ static void asic3_irq_demux(struct irq_desc *desc)
>   asic3_write_register(asic,
>base +
>ASIC3_GPIO_INT_STATUS, 0);
> - spin_unlock_irqrestore(>lock, flags);
> + raw_spin_unlock_irqrestore(>lock, flags);
>  
>   for (i = 0; i < ASIC3_GPIOS_PER_BANK; i++) {
>   int bit = (1 << i);
> @@ -230,11 +230,11 @@ static void asic3_mask_gpio_irq(struct irq_data *data)
>   bank = asic3_irq_to_bank(asic, data->irq);
>   index = asic3_irq_to_index(asic, data->irq);
>  
> - spin_lock_irqsave(>lock, flags);
> + raw_spin_lock_irqsave(>lock, flags);
>   val = asic3_read_register(asic, bank + ASIC3_GPIO_MASK);
>   val |= 1 << index;
>   asic3_write_register(asic, bank + ASIC3_GPIO_MASK, val);
> - spin_unlock_irqrestore(>lock, flags);
> + raw_spin_unlock_irqrestore(>lock, flags);
>  }
>  
>  static void asic3_mask_irq(struct irq_data *data)
> @@ -243,7 +243,7 @@ static void asic3_mask_irq(struct irq_data *data)
>   int regval;
>   unsigned long flags;
>  
> - spin_lock_irqsave(>lock, flags);
> + raw_spin_lock_irqsave(>lock, flags);
>   regval = asic3_read_register(asic,
>   

Re: [PATCH v2 4/9] mfd: asic3: make use of raw_spinlock variants

[Lee Jones]

On Tue, 21 Mar 2017, Julia Cartwright wrote:

> The asic3 mfd driver currently implements an irq_chip for handling
> interrupts; due to how irq_chip handling is done, it's necessary for the
> irq_chip methods to be invoked from hardirq context, even on a a
> real-time kernel.  Because the spinlock_t type becomes a "sleeping"
> spinlock w/ RT kernels, it is not suitable to be used with irq_chips.
> 
> A quick audit of the operations under the lock reveal that they do only
> minimal, bounded work, and are therefore safe to do under a raw spinlock.
> 
> Acked-for-MFD-by: Lee Jones 
> Signed-off-by: Julia Cartwright 
> ---
> v1 -> v2:
>   - No functional change.  Added Lee's ack.
> 
>  drivers/mfd/asic3.c | 56 
> ++---
>  1 file changed, 28 insertions(+), 28 deletions(-)

Applied, thanks.

> diff --git a/drivers/mfd/asic3.c b/drivers/mfd/asic3.c
> index 0413c8159551..cf2e25ab2940 100644
> --- a/drivers/mfd/asic3.c
> +++ b/drivers/mfd/asic3.c
> @@ -78,7 +78,7 @@ struct asic3 {
>   unsigned int bus_shift;
>   unsigned int irq_nr;
>   unsigned int irq_base;
> - spinlock_t lock;
> + raw_spinlock_t lock;
>   u16 irq_bothedge[4];
>   struct gpio_chip gpio;
>   struct device *dev;
> @@ -108,14 +108,14 @@ static void asic3_set_register(struct asic3 *asic, u32 
> reg, u32 bits, bool set)
>   unsigned long flags;
>   u32 val;
>  
> - spin_lock_irqsave(>lock, flags);
> + raw_spin_lock_irqsave(>lock, flags);
>   val = asic3_read_register(asic, reg);
>   if (set)
>   val |= bits;
>   else
>   val &= ~bits;
>   asic3_write_register(asic, reg, val);
> - spin_unlock_irqrestore(>lock, flags);
> + raw_spin_unlock_irqrestore(>lock, flags);
>  }
>  
>  /* IRQs */
> @@ -129,13 +129,13 @@ static void asic3_irq_flip_edge(struct asic3 *asic,
>   u16 edge;
>   unsigned long flags;
>  
> - spin_lock_irqsave(>lock, flags);
> + raw_spin_lock_irqsave(>lock, flags);
>   edge = asic3_read_register(asic,
>  base + ASIC3_GPIO_EDGE_TRIGGER);
>   edge ^= bit;
>   asic3_write_register(asic,
>base + ASIC3_GPIO_EDGE_TRIGGER, edge);
> - spin_unlock_irqrestore(>lock, flags);
> + raw_spin_unlock_irqrestore(>lock, flags);
>  }
>  
>  static void asic3_irq_demux(struct irq_desc *desc)
> @@ -151,10 +151,10 @@ static void asic3_irq_demux(struct irq_desc *desc)
>   u32 status;
>   int bank;
>  
> - spin_lock_irqsave(>lock, flags);
> + raw_spin_lock_irqsave(>lock, flags);
>   status = asic3_read_register(asic,
>ASIC3_OFFSET(INTR, P_INT_STAT));
> - spin_unlock_irqrestore(>lock, flags);
> + raw_spin_unlock_irqrestore(>lock, flags);
>  
>   /* Check all ten register bits */
>   if ((status & 0x3ff) == 0)
> @@ -167,7 +167,7 @@ static void asic3_irq_demux(struct irq_desc *desc)
>  
>   base = ASIC3_GPIO_A_BASE
>  + bank * ASIC3_GPIO_BASE_INCR;
> - spin_lock_irqsave(>lock, flags);
> + raw_spin_lock_irqsave(>lock, flags);
>   istat = asic3_read_register(asic,
>   base +
>   
> ASIC3_GPIO_INT_STATUS);
> @@ -175,7 +175,7 @@ static void asic3_irq_demux(struct irq_desc *desc)
>   asic3_write_register(asic,
>base +
>ASIC3_GPIO_INT_STATUS, 0);
> - spin_unlock_irqrestore(>lock, flags);
> + raw_spin_unlock_irqrestore(>lock, flags);
>  
>   for (i = 0; i < ASIC3_GPIOS_PER_BANK; i++) {
>   int bit = (1 << i);
> @@ -230,11 +230,11 @@ static void asic3_mask_gpio_irq(struct irq_data *data)
>   bank = asic3_irq_to_bank(asic, data->irq);
>   index = asic3_irq_to_index(asic, data->irq);
>  
> - spin_lock_irqsave(>lock, flags);
> + raw_spin_lock_irqsave(>lock, flags);
>   val = asic3_read_register(asic, bank + ASIC3_GPIO_MASK);
>   val |= 1 << index;
>   asic3_write_register(asic, bank + ASIC3_GPIO_MASK, val);
> - spin_unlock_irqrestore(>lock, flags);
> + raw_spin_unlock_irqrestore(>lock, flags);
>  }
>  
>  static void asic3_mask_irq(struct irq_data *data)
> @@ -243,7 +243,7 @@ static void asic3_mask_irq(struct irq_data *data)
>   int regval;
>   unsigned long flags;
>  
> - spin_lock_irqsave(>lock, flags);
> + raw_spin_lock_irqsave(>lock, flags);
>   regval = asic3_read_register(asic,
>

Re: [PATCH 3/4] zram: implement deduplication in zram

[Sergey Senozhatsky]

Hello Joonsoo,

On (03/16/17 11:46), js1...@gmail.com wrote:
[..]
> +static bool zram_entry_put(struct zram *zram, struct zram_meta *meta,
> + struct zram_entry *entry, bool populated)
> +{
> + struct zram_hash *hash;
> + u32 checksum;
> +
> + if (!populated)
> + goto free;
> +
> + checksum = entry->checksum;
> + hash = >hash[checksum % meta->hash_size];
> +
> + spin_lock(>lock);
> + entry->refcount--;
> + if (!entry->refcount) {
> + populated = false;
> + rb_erase(>rb_node, >rb_root);
> + RB_CLEAR_NODE(>rb_node);
> + }
> + spin_unlock(>lock);
> +
> +free:
> + if (!populated)
> + zram_entry_free(zram, meta, entry);
> +
> + return populated;
> +}

[ 2935.830100] BUG: unable to handle kernel NULL pointer dereference at 
0154
[ 2935.830106] IP: zram_entry_put+0x15/0xbb [zram]
[ 2935.830107] PGD 4063aa067 
[ 2935.830108] P4D 4063aa067 
[ 2935.830108] PUD 19d426067 
[ 2935.830109] PMD 0 

[ 2935.830110] Oops:  [#1] PREEMPT SMP
[ 2935.830111] Modules linked in: lzo zram(-) zsmalloc mousedev nls_iso8859_1 
nls_cp437 vfat fat psmouse serio_raw atkbd libps2 coretemp hwmon iwlmvm 
crc32c_intel i2c_i801 r8169 iwlwifi lpc_ich mii mfd_core ie31200_edac edac_core 
thermal i8042 serio wmi evdev acpi_cpufreq sd_mod
[ 2935.830127] CPU: 3 PID: 1599 Comm: rmmod Tainted: GW   
4.11.0-rc3-next-20170323-dbg-00012-gdda44065c67c-dirty #155
[ 2935.830128] task: 8804061c14c0 task.stack: 8801f7908000
[ 2935.830130] RIP: 0010:zram_entry_put+0x15/0xbb [zram]
[ 2935.830131] RSP: 0018:8801f790bdc0 EFLAGS: 00010246
[ 2935.830132] RAX:  RBX: 88041cdbfce0 RCX: 0001
[ 2935.830132] RDX: 880405f4cdb8 RSI: 88041cdbfce0 RDI: 
[ 2935.830133] RBP: 8801f790bde8 R08: ff80 R09: 00ff
[ 2935.830134] R10: 8801f790bd90 R11:  R12: 
[ 2935.830134] R13: 88041cdbfce0 R14: 88041cdbfd00 R15: 88041cdbfce0
[ 2935.830135] FS:  7fb350b62b40() GS:88042fac() 
knlGS:
[ 2935.830136] CS:  0010 DS:  ES:  CR0: 80050033
[ 2935.830137] CR2: 0154 CR3: 0002d3f53000 CR4: 001406e0
[ 2935.830137] Call Trace:
[ 2935.830139]  zram_meta_free+0x50/0x7e [zram]
[ 2935.830141]  zram_reset_device+0xd2/0xe5 [zram]
[ 2935.830142]  zram_remove+0x9f/0xf1 [zram]
[ 2935.830143]  ? zram_remove+0xf1/0xf1 [zram]
[ 2935.830145]  zram_remove_cb+0x11/0x15 [zram]
[ 2935.830148]  idr_for_each+0x3b/0x87
[ 2935.830149]  destroy_devices+0x2a/0x56 [zram]
[ 2935.830150]  zram_exit+0x9/0x6f6 [zram]
[ 2935.830153]  SyS_delete_module+0xf1/0x181
[ 2935.830156]  entry_SYSCALL_64_fastpath+0x18/0xad
[ 2935.830157] RIP: 0033:0x7fb3502659b7
[ 2935.830158] RSP: 002b:7fff90ca5468 EFLAGS: 0202 ORIG_RAX: 
00b0
[ 2935.830159] RAX: ffda RBX: 0003 RCX: 7fb3502659b7
[ 2935.830159] RDX: 000a RSI: 0800 RDI: 02187208
[ 2935.830160] RBP:  R08: 7fff90ca43e1 R09: 000a
[ 2935.830161] R10: 0892 R11: 0202 R12: 021871a0
[ 2935.830162] R13: 7fff90ca4450 R14: 021871a0 R15: 02186010
[ 2935.830163] Code: 1e 6f fb ff 4c 89 e7 e8 9e 05 f5 e0 48 89 d8 5b 41 5c 41 
5d 5d c3 0f 1f 44 00 00 55 48 89 e5 41 57 41 56 41 55 49 89 f5 41 54 53 <83> bf 
54 01 00 00 00 48 89 d3 75 0e 48 8b 7e 08 48 89 d6 e8 0b 
[ 2935.830184] RIP: zram_entry_put+0x15/0xbb [zram] RSP: 8801f790bdc0
[ 2935.830184] CR2: 0154
[ 2935.838309] ---[ end trace f7f95fd0ed6c72a0 ]---

-ss

Re: [PATCH 3/4] zram: implement deduplication in zram

[Sergey Senozhatsky]

Hello Joonsoo,

On (03/16/17 11:46), js1...@gmail.com wrote:
[..]
> +static bool zram_entry_put(struct zram *zram, struct zram_meta *meta,
> + struct zram_entry *entry, bool populated)
> +{
> + struct zram_hash *hash;
> + u32 checksum;
> +
> + if (!populated)
> + goto free;
> +
> + checksum = entry->checksum;
> + hash = >hash[checksum % meta->hash_size];
> +
> + spin_lock(>lock);
> + entry->refcount--;
> + if (!entry->refcount) {
> + populated = false;
> + rb_erase(>rb_node, >rb_root);
> + RB_CLEAR_NODE(>rb_node);
> + }
> + spin_unlock(>lock);
> +
> +free:
> + if (!populated)
> + zram_entry_free(zram, meta, entry);
> +
> + return populated;
> +}

[ 2935.830100] BUG: unable to handle kernel NULL pointer dereference at 
0154
[ 2935.830106] IP: zram_entry_put+0x15/0xbb [zram]
[ 2935.830107] PGD 4063aa067 
[ 2935.830108] P4D 4063aa067 
[ 2935.830108] PUD 19d426067 
[ 2935.830109] PMD 0 

[ 2935.830110] Oops:  [#1] PREEMPT SMP
[ 2935.830111] Modules linked in: lzo zram(-) zsmalloc mousedev nls_iso8859_1 
nls_cp437 vfat fat psmouse serio_raw atkbd libps2 coretemp hwmon iwlmvm 
crc32c_intel i2c_i801 r8169 iwlwifi lpc_ich mii mfd_core ie31200_edac edac_core 
thermal i8042 serio wmi evdev acpi_cpufreq sd_mod
[ 2935.830127] CPU: 3 PID: 1599 Comm: rmmod Tainted: GW   
4.11.0-rc3-next-20170323-dbg-00012-gdda44065c67c-dirty #155
[ 2935.830128] task: 8804061c14c0 task.stack: 8801f7908000
[ 2935.830130] RIP: 0010:zram_entry_put+0x15/0xbb [zram]
[ 2935.830131] RSP: 0018:8801f790bdc0 EFLAGS: 00010246
[ 2935.830132] RAX:  RBX: 88041cdbfce0 RCX: 0001
[ 2935.830132] RDX: 880405f4cdb8 RSI: 88041cdbfce0 RDI: 
[ 2935.830133] RBP: 8801f790bde8 R08: ff80 R09: 00ff
[ 2935.830134] R10: 8801f790bd90 R11:  R12: 
[ 2935.830134] R13: 88041cdbfce0 R14: 88041cdbfd00 R15: 88041cdbfce0
[ 2935.830135] FS:  7fb350b62b40() GS:88042fac() 
knlGS:
[ 2935.830136] CS:  0010 DS:  ES:  CR0: 80050033
[ 2935.830137] CR2: 0154 CR3: 0002d3f53000 CR4: 001406e0
[ 2935.830137] Call Trace:
[ 2935.830139]  zram_meta_free+0x50/0x7e [zram]
[ 2935.830141]  zram_reset_device+0xd2/0xe5 [zram]
[ 2935.830142]  zram_remove+0x9f/0xf1 [zram]
[ 2935.830143]  ? zram_remove+0xf1/0xf1 [zram]
[ 2935.830145]  zram_remove_cb+0x11/0x15 [zram]
[ 2935.830148]  idr_for_each+0x3b/0x87
[ 2935.830149]  destroy_devices+0x2a/0x56 [zram]
[ 2935.830150]  zram_exit+0x9/0x6f6 [zram]
[ 2935.830153]  SyS_delete_module+0xf1/0x181
[ 2935.830156]  entry_SYSCALL_64_fastpath+0x18/0xad
[ 2935.830157] RIP: 0033:0x7fb3502659b7
[ 2935.830158] RSP: 002b:7fff90ca5468 EFLAGS: 0202 ORIG_RAX: 
00b0
[ 2935.830159] RAX: ffda RBX: 0003 RCX: 7fb3502659b7
[ 2935.830159] RDX: 000a RSI: 0800 RDI: 02187208
[ 2935.830160] RBP:  R08: 7fff90ca43e1 R09: 000a
[ 2935.830161] R10: 0892 R11: 0202 R12: 021871a0
[ 2935.830162] R13: 7fff90ca4450 R14: 021871a0 R15: 02186010
[ 2935.830163] Code: 1e 6f fb ff 4c 89 e7 e8 9e 05 f5 e0 48 89 d8 5b 41 5c 41 
5d 5d c3 0f 1f 44 00 00 55 48 89 e5 41 57 41 56 41 55 49 89 f5 41 54 53 <83> bf 
54 01 00 00 00 48 89 d3 75 0e 48 8b 7e 08 48 89 d6 e8 0b 
[ 2935.830184] RIP: zram_entry_put+0x15/0xbb [zram] RSP: 8801f790bdc0
[ 2935.830184] CR2: 0154
[ 2935.838309] ---[ end trace f7f95fd0ed6c72a0 ]---

-ss

Re: [PATCH 4/4] tty/serial: sh-sci: remove uneeded IS_ERR_OR_NULL calls

[Linus Walleij]

On Thu, Mar 23, 2017 at 1:34 PM, Uwe Kleine-König
 wrote:

> Maybe we can make gpiod_get_optional look like this:
>
> if (!dev->of_node && isnt_a_acpi_device(dev) && !IS_ENABLED(GPIOLIB))
> return NULL;
> else
> return -ENOSYS;
>
> I don't know how isnt_a_acpi_device looks like, probably it involves
> CONFIG_ACPI and/or dev->acpi_node.
>
> This should be safe and still comfortable for legacy platforms, isn't it?

I like the looks of this.

Can we revert Dmitry's patch and apply something like this instead?

Dmitry, how do you feel about this?

Yours,
Linus Walleij

Re: [PATCH 4/4] tty/serial: sh-sci: remove uneeded IS_ERR_OR_NULL calls

[Linus Walleij]

On Thu, Mar 23, 2017 at 1:34 PM, Uwe Kleine-König
 wrote:

> Maybe we can make gpiod_get_optional look like this:
>
> if (!dev->of_node && isnt_a_acpi_device(dev) && !IS_ENABLED(GPIOLIB))
> return NULL;
> else
> return -ENOSYS;
>
> I don't know how isnt_a_acpi_device looks like, probably it involves
> CONFIG_ACPI and/or dev->acpi_node.
>
> This should be safe and still comfortable for legacy platforms, isn't it?

I like the looks of this.

Can we revert Dmitry's patch and apply something like this instead?

Dmitry, how do you feel about this?

Yours,
Linus Walleij

[PATCH v2] staging:speakup: Fix alignment with parenthesis.

[Arushi Singhal]

Fix checkpatch issues: "CHECK: Alignment should match open parenthesis".

Signed-off-by: Arushi Singhal 
---
changes in v2
 - change the commit message.

 drivers/staging/speakup/speakup_apollo.c | 2 +-
 drivers/staging/speakup/speakup_decext.c | 4 ++--
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/staging/speakup/speakup_apollo.c 
b/drivers/staging/speakup/speakup_apollo.c
index 9cfdbbfb9742..6ad83dc642c4 100644
--- a/drivers/staging/speakup/speakup_apollo.c
+++ b/drivers/staging/speakup/speakup_apollo.c
@@ -173,7 +173,7 @@ static void do_catch_up(struct spk_synth *synth)
if (!synth->io_ops->synth_out(synth, ch)) {
outb(UART_MCR_DTR, speakup_info.port_tts + UART_MCR);
outb(UART_MCR_DTR | UART_MCR_RTS,
-   speakup_info.port_tts + UART_MCR);
+speakup_info.port_tts + UART_MCR);
schedule_timeout(msecs_to_jiffies(full_time_val));
continue;
}
diff --git a/drivers/staging/speakup/speakup_decext.c 
b/drivers/staging/speakup/speakup_decext.c
index 929a28d618dc..c564bf8e1531 100644
--- a/drivers/staging/speakup/speakup_decext.c
+++ b/drivers/staging/speakup/speakup_decext.c
@@ -206,11 +206,11 @@ static void do_catch_up(struct spk_synth *synth)
if (!in_escape)
synth->io_ops->synth_out(synth, 
PROCSPEECH);
spin_lock_irqsave(_info.spinlock,
-   flags);
+ flags);
jiffy_delta_val = jiffy_delta->u.n.value;
delay_time_val = delay_time->u.n.value;
spin_unlock_irqrestore(_info.spinlock,
-   flags);
+  flags);
schedule_timeout(msecs_to_jiffies
 (delay_time_val));
jiff_max = jiffies + jiffy_delta_val;
-- 
2.11.0

[PATCH v2] staging:speakup: Fix alignment with parenthesis.

[Arushi Singhal]

Fix checkpatch issues: "CHECK: Alignment should match open parenthesis".

Signed-off-by: Arushi Singhal 
---
changes in v2
 - change the commit message.

 drivers/staging/speakup/speakup_apollo.c | 2 +-
 drivers/staging/speakup/speakup_decext.c | 4 ++--
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/staging/speakup/speakup_apollo.c 
b/drivers/staging/speakup/speakup_apollo.c
index 9cfdbbfb9742..6ad83dc642c4 100644
--- a/drivers/staging/speakup/speakup_apollo.c
+++ b/drivers/staging/speakup/speakup_apollo.c
@@ -173,7 +173,7 @@ static void do_catch_up(struct spk_synth *synth)
if (!synth->io_ops->synth_out(synth, ch)) {
outb(UART_MCR_DTR, speakup_info.port_tts + UART_MCR);
outb(UART_MCR_DTR | UART_MCR_RTS,
-   speakup_info.port_tts + UART_MCR);
+speakup_info.port_tts + UART_MCR);
schedule_timeout(msecs_to_jiffies(full_time_val));
continue;
}
diff --git a/drivers/staging/speakup/speakup_decext.c 
b/drivers/staging/speakup/speakup_decext.c
index 929a28d618dc..c564bf8e1531 100644
--- a/drivers/staging/speakup/speakup_decext.c
+++ b/drivers/staging/speakup/speakup_decext.c
@@ -206,11 +206,11 @@ static void do_catch_up(struct spk_synth *synth)
if (!in_escape)
synth->io_ops->synth_out(synth, 
PROCSPEECH);
spin_lock_irqsave(_info.spinlock,
-   flags);
+ flags);
jiffy_delta_val = jiffy_delta->u.n.value;
delay_time_val = delay_time->u.n.value;
spin_unlock_irqrestore(_info.spinlock,
-   flags);
+  flags);
schedule_timeout(msecs_to_jiffies
 (delay_time_val));
jiff_max = jiffies + jiffy_delta_val;
-- 
2.11.0

Re: [PATCH 4/4] tty/serial: sh-sci: remove uneeded IS_ERR_OR_NULL calls

[Linus Walleij]

On Thu, Mar 23, 2017 at 11:10 AM, Uwe Kleine-König
 wrote:

> So you exchanged many obvious and easy to fix problems with a few hard
> ones. I don't agree that's a good idea, but you seem to be willing to
> try it. Good luck.

I think instead of going to sarcastic remarks you can say you NACK the
patch and suggest that it be reverted?

The problem I have here as maintainer is that both you and Dmitry are
very smart people and I have a great deal of trust invested in both of you.

When two valued contributors give me very different advice I get a bit
confused and maybe the best option is not to change anything at all
right now, and just revert Dmitry's patch.

git grep -e 'gpio.*optional(' | wc -l
gives 154 use sites outside drivers/gpio, so it is not impossible to fix
this if we want a good and strict order to it. I'm just a bit overworked to
do it myself right now.

What do you all say, is it better to revert Dmitry's patch and instead go
around and fix the consumers to do it correctly everywhere, after
hammering down the exact semantics?

Yours,
Linus Walleij

Re: [PATCH 4/4] tty/serial: sh-sci: remove uneeded IS_ERR_OR_NULL calls

[Linus Walleij]

On Thu, Mar 23, 2017 at 11:10 AM, Uwe Kleine-König
 wrote:

> So you exchanged many obvious and easy to fix problems with a few hard
> ones. I don't agree that's a good idea, but you seem to be willing to
> try it. Good luck.

I think instead of going to sarcastic remarks you can say you NACK the
patch and suggest that it be reverted?

The problem I have here as maintainer is that both you and Dmitry are
very smart people and I have a great deal of trust invested in both of you.

When two valued contributors give me very different advice I get a bit
confused and maybe the best option is not to change anything at all
right now, and just revert Dmitry's patch.

git grep -e 'gpio.*optional(' | wc -l
gives 154 use sites outside drivers/gpio, so it is not impossible to fix
this if we want a good and strict order to it. I'm just a bit overworked to
do it myself right now.

What do you all say, is it better to revert Dmitry's patch and instead go
around and fix the consumers to do it correctly everywhere, after
hammering down the exact semantics?

Yours,
Linus Walleij

Re: [PATCH] staging: media: atomisp: use kvmalloc and kvfree

[Greg Kroah-Hartman]

On Thu, Mar 23, 2017 at 09:12:39PM +0800, Geliang Tang wrote:
> Use kvmalloc() and kvfree() instead of open-coding.

These functions are not in Linus's tree, so I can't apply this patch
without breaking things :(

thanks,

greg k-h

Re: [PATCH] staging: media: atomisp: use kvmalloc and kvfree

[Greg Kroah-Hartman]

On Thu, Mar 23, 2017 at 09:12:39PM +0800, Geliang Tang wrote:
> Use kvmalloc() and kvfree() instead of open-coding.

These functions are not in Linus's tree, so I can't apply this patch
without breaking things :(

thanks,

greg k-h

Re: [PATCH v2] staging: radio-bcm2048: fixed bare use of unsigned int

[Greg Kroah-Hartman]

On Wed, Mar 22, 2017 at 01:33:39PM +1100, Eddie Youseph wrote:
> Fixed checkpatch WARNING: Prefer 'unsigned int' to bare use of 'unsigned'
> 
> Signed-off-by: Eddie Youseph 
> ---
> Changes in v2:
>   - Added changelog

Did you actually build this change?

Please do so...

thanks,

greg k-h

Re: [PATCH v2] staging: radio-bcm2048: fixed bare use of unsigned int

[Greg Kroah-Hartman]

On Wed, Mar 22, 2017 at 01:33:39PM +1100, Eddie Youseph wrote:
> Fixed checkpatch WARNING: Prefer 'unsigned int' to bare use of 'unsigned'
> 
> Signed-off-by: Eddie Youseph 
> ---
> Changes in v2:
>   - Added changelog

Did you actually build this change?

Please do so...

thanks,

greg k-h

Re: [PATCH] staging:fbtft/fbtft-io: Fix incorrect type in assignment

[Greg Kroah-Hartman]

On Thu, Mar 23, 2017 at 03:08:38PM +0800, Zhengyi Shen wrote:
> Fix endian sparse warnings of incorrect type in assignment.
> This patch changes type to the appropriate endian specific versions.
> 
> 
> Signed-off-by: Zhengyi Shen 
> ---
>  drivers/staging/fbtft/fbtft-io.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/staging/fbtft/fbtft-io.c 
> b/drivers/staging/fbtft/fbtft-io.c
> index d868405..ffb9a3b 100644
> --- a/drivers/staging/fbtft/fbtft-io.c
> +++ b/drivers/staging/fbtft/fbtft-io.c
> @@ -71,7 +71,7 @@ int fbtft_write_spi_emulate_9(struct fbtft_par *par, void 
> *buf, size_t len)
>   src++;
>   }
>   tmp |= ((*src & 0x0100) ? 1 : 0);
> - *(u64 *)dst = cpu_to_be64(tmp);
> + *(__be64 *)dst = cpu_to_be64(tmp);

Really?  I need an ack from a maintainer of this code before I'll take
this mess...

thanks,

greg k-h

Re: [PATCH] staging:fbtft/fbtft-io: Fix incorrect type in assignment

[Greg Kroah-Hartman]

On Thu, Mar 23, 2017 at 03:08:38PM +0800, Zhengyi Shen wrote:
> Fix endian sparse warnings of incorrect type in assignment.
> This patch changes type to the appropriate endian specific versions.
> 
> 
> Signed-off-by: Zhengyi Shen 
> ---
>  drivers/staging/fbtft/fbtft-io.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/staging/fbtft/fbtft-io.c 
> b/drivers/staging/fbtft/fbtft-io.c
> index d868405..ffb9a3b 100644
> --- a/drivers/staging/fbtft/fbtft-io.c
> +++ b/drivers/staging/fbtft/fbtft-io.c
> @@ -71,7 +71,7 @@ int fbtft_write_spi_emulate_9(struct fbtft_par *par, void 
> *buf, size_t len)
>   src++;
>   }
>   tmp |= ((*src & 0x0100) ? 1 : 0);
> - *(u64 *)dst = cpu_to_be64(tmp);
> + *(__be64 *)dst = cpu_to_be64(tmp);

Really?  I need an ack from a maintainer of this code before I'll take
this mess...

thanks,

greg k-h

Re: [PATCH] asm-generic: fix compilation failure in cmpxchg_double()

[Arnd Bergmann]

On Thu, Mar 23, 2017 at 9:49 AM, Dmitry Vyukov  wrote:
> On Wed, Mar 22, 2017 at 10:27 PM, Arnd Bergmann  wrote:
>> On Wed, Mar 22, 2017 at 12:27 PM, Arnd Bergmann  wrote:
>>> On Wed, Mar 22, 2017 at 12:10 PM, Dmitry Vyukov  wrote:
 Arnd reported that the new code leads to compilation failures
 with some versions of gcc. I've filed gcc issue 72873,
 but we need a kernel fix as well.

 Remove instrumentation from cmpxchg_double() for now.
>>>
>>> Thanks, I also checked that fixes the build error for me.
>>
>> I got a new variant of the bug in
>> arch/x86/include/asm/cmpxchg_32.h:set_64bit() now.
>>
>> In file included from /git/arm-soc/arch/x86/include/asm/cmpxchg.h:142:0,
>>  from /git/arm-soc/arch/x86/include/asm/atomic.h:7,
>>  from /git/arm-soc/arch/x86/include/asm/msr.h:66,
>>  from /git/arm-soc/arch/x86/include/asm/processor.h:20,
>>  from /git/arm-soc/arch/x86/include/asm/cpufeature.h:4,
>>  from /git/arm-soc/arch/x86/include/asm/thread_info.h:52,
>>  from /git/arm-soc/include/linux/thread_info.h:25,
>>  from /git/arm-soc/arch/x86/include/asm/preempt.h:6,
>>  from /git/arm-soc/include/linux/preempt.h:80,
>>  from /git/arm-soc/include/linux/spinlock.h:50,
>>  from /git/arm-soc/include/linux/mmzone.h:7,
>>  from /git/arm-soc/include/linux/gfp.h:5,
>>  from /git/arm-soc/include/linux/mm.h:9,
>>  from /git/arm-soc/mm/khugepaged.c:3:
>> /git/arm-soc/mm/khugepaged.c: In function 'khugepaged':
>> /git/arm-soc/arch/x86/include/asm/cmpxchg_32.h:29:2: error: 'asm'
>> operand has impossible constraints
>>   asm volatile("\n1:\t"
>>
>> Defconfig is at http://pastebin.com/raw/Pthhv5iU
>
>
> I can't reproduce it with gcc 4.8.4, 7.0.0, 7.0.1.
>
> Are you sure it's related to my recent change? I did not touch set_64bit.

You are right, this is different, it just appeared on the same day with
almost exactly the same symptom as the other one, so I mistakenly
assumed it was the same root cause.

Reverting your patches doesn't fix it, and I only see it with the
latest gcc-7.0.1 snapshot, not with one from a few weeks ago.
I'll open a gcc bug for it.

   Arnd

Re: [PATCH] asm-generic: fix compilation failure in cmpxchg_double()

[Arnd Bergmann]

On Thu, Mar 23, 2017 at 9:49 AM, Dmitry Vyukov  wrote:
> On Wed, Mar 22, 2017 at 10:27 PM, Arnd Bergmann  wrote:
>> On Wed, Mar 22, 2017 at 12:27 PM, Arnd Bergmann  wrote:
>>> On Wed, Mar 22, 2017 at 12:10 PM, Dmitry Vyukov  wrote:
 Arnd reported that the new code leads to compilation failures
 with some versions of gcc. I've filed gcc issue 72873,
 but we need a kernel fix as well.

 Remove instrumentation from cmpxchg_double() for now.
>>>
>>> Thanks, I also checked that fixes the build error for me.
>>
>> I got a new variant of the bug in
>> arch/x86/include/asm/cmpxchg_32.h:set_64bit() now.
>>
>> In file included from /git/arm-soc/arch/x86/include/asm/cmpxchg.h:142:0,
>>  from /git/arm-soc/arch/x86/include/asm/atomic.h:7,
>>  from /git/arm-soc/arch/x86/include/asm/msr.h:66,
>>  from /git/arm-soc/arch/x86/include/asm/processor.h:20,
>>  from /git/arm-soc/arch/x86/include/asm/cpufeature.h:4,
>>  from /git/arm-soc/arch/x86/include/asm/thread_info.h:52,
>>  from /git/arm-soc/include/linux/thread_info.h:25,
>>  from /git/arm-soc/arch/x86/include/asm/preempt.h:6,
>>  from /git/arm-soc/include/linux/preempt.h:80,
>>  from /git/arm-soc/include/linux/spinlock.h:50,
>>  from /git/arm-soc/include/linux/mmzone.h:7,
>>  from /git/arm-soc/include/linux/gfp.h:5,
>>  from /git/arm-soc/include/linux/mm.h:9,
>>  from /git/arm-soc/mm/khugepaged.c:3:
>> /git/arm-soc/mm/khugepaged.c: In function 'khugepaged':
>> /git/arm-soc/arch/x86/include/asm/cmpxchg_32.h:29:2: error: 'asm'
>> operand has impossible constraints
>>   asm volatile("\n1:\t"
>>
>> Defconfig is at http://pastebin.com/raw/Pthhv5iU
>
>
> I can't reproduce it with gcc 4.8.4, 7.0.0, 7.0.1.
>
> Are you sure it's related to my recent change? I did not touch set_64bit.

You are right, this is different, it just appeared on the same day with
almost exactly the same symptom as the other one, so I mistakenly
assumed it was the same root cause.

Reverting your patches doesn't fix it, and I only see it with the
latest gcc-7.0.1 snapshot, not with one from a few weeks ago.
I'll open a gcc bug for it.

   Arnd

Re: [PATCH v2] kasan: report only the first error by default

[Mark Rutland]

On Thu, Mar 23, 2017 at 04:06:59PM +0300, Andrey Ryabinin wrote:
> On 03/23/2017 03:41 PM, Mark Rutland wrote:

> > Rather than trying to pick an arbitrarily large number, how about we use
> > separate flags to determine whether we're in multi-shot mode, and
> > whether a (oneshot) report has been made.
> > 
> > How about the below?
>  
> Yes, it deferentially looks better.
> Can you send a patch with a changelog, or do you want me to care of it?

Would you be happy to take care of it, along with the fixup you
suggested below, as v3?

You can add my:

Signed-off-by: Mark Rutland 

Thanks,
Mark.


> >  
> > +#include 
> >  #include 
> 
> We also need  for __setup().
> 
> >  #include 
> >  #include 
> > @@ -293,6 +294,40 @@ static void kasan_report_error(struct 
> > kasan_access_info *info)

Re: [PATCH v2] kasan: report only the first error by default

[Mark Rutland]

On Thu, Mar 23, 2017 at 04:06:59PM +0300, Andrey Ryabinin wrote:
> On 03/23/2017 03:41 PM, Mark Rutland wrote:

> > Rather than trying to pick an arbitrarily large number, how about we use
> > separate flags to determine whether we're in multi-shot mode, and
> > whether a (oneshot) report has been made.
> > 
> > How about the below?
>  
> Yes, it deferentially looks better.
> Can you send a patch with a changelog, or do you want me to care of it?

Would you be happy to take care of it, along with the fixup you
suggested below, as v3?

You can add my:

Signed-off-by: Mark Rutland 

Thanks,
Mark.


> >  
> > +#include 
> >  #include 
> 
> We also need  for __setup().
> 
> >  #include 
> >  #include 
> > @@ -293,6 +294,40 @@ static void kasan_report_error(struct 
> > kasan_access_info *info)

RE: Query on DT overlay support.

[Nava kishore Manne]

Hi,

    This mail is regarding the DT overlay support in the Linux 
kernel
    I am able to make the device-tree overlay work out of box by 
using my own dtc complier (I mean I used the dtc compiler
    Available here 
http://www.embedded-things.com/bbb/patching-the-device-tree-compiler-for-ubuntu/
  )
    When can I expect the same changes in the scripts/dtc in 
mainline 
    In case of any support needed for testing I can help on testing 
the same I works in Xilinx and we had a lot of combinations to test overlay ☺ 

    

Regards,
Navakishore.

RE: Query on DT overlay support.

[Nava kishore Manne]

Hi,

    This mail is regarding the DT overlay support in the Linux 
kernel
    I am able to make the device-tree overlay work out of box by 
using my own dtc complier (I mean I used the dtc compiler
    Available here 
http://www.embedded-things.com/bbb/patching-the-device-tree-compiler-for-ubuntu/
  )
    When can I expect the same changes in the scripts/dtc in 
mainline 
    In case of any support needed for testing I can help on testing 
the same I works in Xilinx and we had a lot of combinations to test overlay ☺ 

    

Regards,
Navakishore.

[PATCH] auxdisplay: hd44780: Fix DT properties to include units of measurement

[Geert Uytterhoeven]

DT properties specifying physical properties should contain appropriate
suffices indicating the units of measurement.

Hence amend the HD44780 DT bindings to add "chars" suffixes to the
"display-height" and "display-width" properties, and update the driver
to parse them.

Fixes: dd9502a9e9156dd8 ("dt-bindings: auxdisplay: Add bindings for Hitachi 
HD44780")
Fixes: d47d88361feea2ce ("auxdisplay: Add HD44780 Character LCD support")
Signed-off-by: Geert Uytterhoeven 
---
Against char-misc-next

 Documentation/devicetree/bindings/auxdisplay/hit,hd44780.txt | 11 ++-
 drivers/auxdisplay/hd44780.c |  5 +++--
 2 files changed, 9 insertions(+), 7 deletions(-)

diff --git a/Documentation/devicetree/bindings/auxdisplay/hit,hd44780.txt 
b/Documentation/devicetree/bindings/auxdisplay/hit,hd44780.txt
index ee4054da458d412f..2aa24b8899236882 100644
--- a/Documentation/devicetree/bindings/auxdisplay/hit,hd44780.txt
+++ b/Documentation/devicetree/bindings/auxdisplay/hit,hd44780.txt
@@ -15,8 +15,8 @@ Required properties:
   - rs-gpios: Must contain a GPIO specifier, referring to the GPIO pin
 connected to the "RS" (Register Select) signal line of the LCD Controller's
 bus interface,
-  - display-height: Height of the display, in character cells,
-  - display-width: Width of the display, in character cells.
+  - display-height-chars: Height of the display, in character cells,
+  - display-width-chars: Width of the display, in character cells.
 
 Optional properties:
   - rw-gpios: Must contain a GPIO specifier, referring to the GPIO pin
@@ -25,7 +25,8 @@ Optional properties:
   - backlight-gpios: Must contain a GPIO specifier, referring to the GPIO pin
 used for enabling the LCD's backlight,
   - internal-buffer-width: Internal buffer width (default is 40 for displays
-with 1 or 2 lines, and display-width for displays with more than 2 lines).
+with 1 or 2 lines, and display-width-chars for displays with more than 2
+lines).
 
 Example:
 
@@ -39,6 +40,6 @@ Example:
enable-gpios = < 4 GPIO_ACTIVE_HIGH>;
rs-gpios = < 5 GPIO_ACTIVE_HIGH>;
 
-   display-height = <2>;
-   display-width = <16>;
+   display-height-chars = <2>;
+   display-width-chars = <16>;
};
diff --git a/drivers/auxdisplay/hd44780.c b/drivers/auxdisplay/hd44780.c
index 1665ac6ef9ffcb31..036eec40428943b7 100644
--- a/drivers/auxdisplay/hd44780.c
+++ b/drivers/auxdisplay/hd44780.c
@@ -264,10 +264,11 @@ static int hd44780_probe(struct platform_device *pdev)
}
 
/* Required properties */
-   ret = device_property_read_u32(dev, "display-height", >height);
+   ret = device_property_read_u32(dev, "display-height-chars",
+  >height);
if (ret)
goto fail;
-   ret = device_property_read_u32(dev, "display-width", >width);
+   ret = device_property_read_u32(dev, "display-width-chars", >width);
if (ret)
goto fail;
 
-- 
2.7.4

[PATCH] auxdisplay: hd44780: Fix DT properties to include units of measurement

[Geert Uytterhoeven]

DT properties specifying physical properties should contain appropriate
suffices indicating the units of measurement.

Hence amend the HD44780 DT bindings to add "chars" suffixes to the
"display-height" and "display-width" properties, and update the driver
to parse them.

Fixes: dd9502a9e9156dd8 ("dt-bindings: auxdisplay: Add bindings for Hitachi 
HD44780")
Fixes: d47d88361feea2ce ("auxdisplay: Add HD44780 Character LCD support")
Signed-off-by: Geert Uytterhoeven 
---
Against char-misc-next

 Documentation/devicetree/bindings/auxdisplay/hit,hd44780.txt | 11 ++-
 drivers/auxdisplay/hd44780.c |  5 +++--
 2 files changed, 9 insertions(+), 7 deletions(-)

diff --git a/Documentation/devicetree/bindings/auxdisplay/hit,hd44780.txt 
b/Documentation/devicetree/bindings/auxdisplay/hit,hd44780.txt
index ee4054da458d412f..2aa24b8899236882 100644
--- a/Documentation/devicetree/bindings/auxdisplay/hit,hd44780.txt
+++ b/Documentation/devicetree/bindings/auxdisplay/hit,hd44780.txt
@@ -15,8 +15,8 @@ Required properties:
   - rs-gpios: Must contain a GPIO specifier, referring to the GPIO pin
 connected to the "RS" (Register Select) signal line of the LCD Controller's
 bus interface,
-  - display-height: Height of the display, in character cells,
-  - display-width: Width of the display, in character cells.
+  - display-height-chars: Height of the display, in character cells,
+  - display-width-chars: Width of the display, in character cells.
 
 Optional properties:
   - rw-gpios: Must contain a GPIO specifier, referring to the GPIO pin
@@ -25,7 +25,8 @@ Optional properties:
   - backlight-gpios: Must contain a GPIO specifier, referring to the GPIO pin
 used for enabling the LCD's backlight,
   - internal-buffer-width: Internal buffer width (default is 40 for displays
-with 1 or 2 lines, and display-width for displays with more than 2 lines).
+with 1 or 2 lines, and display-width-chars for displays with more than 2
+lines).
 
 Example:
 
@@ -39,6 +40,6 @@ Example:
enable-gpios = < 4 GPIO_ACTIVE_HIGH>;
rs-gpios = < 5 GPIO_ACTIVE_HIGH>;
 
-   display-height = <2>;
-   display-width = <16>;
+   display-height-chars = <2>;
+   display-width-chars = <16>;
};
diff --git a/drivers/auxdisplay/hd44780.c b/drivers/auxdisplay/hd44780.c
index 1665ac6ef9ffcb31..036eec40428943b7 100644
--- a/drivers/auxdisplay/hd44780.c
+++ b/drivers/auxdisplay/hd44780.c
@@ -264,10 +264,11 @@ static int hd44780_probe(struct platform_device *pdev)
}
 
/* Required properties */
-   ret = device_property_read_u32(dev, "display-height", >height);
+   ret = device_property_read_u32(dev, "display-height-chars",
+  >height);
if (ret)
goto fail;
-   ret = device_property_read_u32(dev, "display-width", >width);
+   ret = device_property_read_u32(dev, "display-width-chars", >width);
if (ret)
goto fail;
 
-- 
2.7.4

ata: WARNING in ata_qc_issue

[Dmitry Vyukov]

Hello,

The following program triggers WARNING in ata_qc_issue:
https://gist.githubusercontent.com/dvyukov/3503afce181b7d48dabb421e10e70b00/raw/d049bd2128a8b1089497beb6104ba48c5550b4a8/gistfile1.txt

[ cut here ]
WARNING: CPU: 3 PID: 2956 at drivers/ata/libata-core.c:5317
ata_qc_issue+0xd14/0x1040 drivers/ata/libata-core.c:5316
CPU: 3 PID: 2956 Comm: a.out Not tainted 4.11.0-rc3+ #365
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
Call Trace:
 __dump_stack lib/dump_stack.c:16 [inline]
 dump_stack+0x1b8/0x28d lib/dump_stack.c:52
 panic+0x20c/0x423 kernel/panic.c:180
 __warn+0x1c4/0x1e0 kernel/panic.c:541
 warn_slowpath_null+0x2c/0x40 kernel/panic.c:584
 ata_qc_issue+0xd14/0x1040 drivers/ata/libata-core.c:5316
 ata_scsi_translate+0x34a/0x5e0 drivers/ata/libata-scsi.c:2021
 __ata_scsi_queuecmd drivers/ata/libata-scsi.c:4249 [inline]
 ata_scsi_queuecmd+0x2ae/0x660 drivers/ata/libata-scsi.c:4298
 scsi_dispatch_cmd+0x43e/0xb70 drivers/scsi/scsi_lib.c:1665
 scsi_request_fn+0x13dc/0x1ec0 drivers/scsi/scsi_lib.c:1800
 __blk_run_queue_uncond block/blk-core.c:305 [inline]
 __blk_run_queue+0xe3/0x150 block/blk-core.c:323
 __elv_add_request+0x494/0xce0 block/elevator.c:677
 blk_execute_rq_nowait+0x214/0x370 block/blk-exec.c:78
 blk_execute_rq+0x1ca/0x280 block/blk-exec.c:103
 sg_scsi_ioctl+0x3d0/0x7f0 block/scsi_ioctl.c:510
 sg_ioctl+0x1fdd/0x2f00 drivers/scsi/sg.c:1075
 vfs_ioctl fs/ioctl.c:45 [inline]
 do_vfs_ioctl+0x1af/0x16d0 fs/ioctl.c:685
 SYSC_ioctl fs/ioctl.c:700 [inline]
 SyS_ioctl+0x8f/0xc0 fs/ioctl.c:691
 entry_SYSCALL_64_fastpath+0x1f/0xc2
RIP: 0033:0x434cd9
RSP: 002b:7ffc5cd86308 EFLAGS: 0286 ORIG_RAX: 0010
RAX: ffda RBX: 004002b0 RCX: 00434cd9
RDX: 20001000 RSI: 0001 RDI: 0003
RBP: 0086 R08:  R09: 
R10:  R11: 0286 R12: 
R13: 00401a30 R14: 00401ac0 R15: 

On commit 093b995e3b55a0ae0670226ddfcb05bfbf0099ae

ata: WARNING in ata_qc_issue

[Dmitry Vyukov]

Hello,

The following program triggers WARNING in ata_qc_issue:
https://gist.githubusercontent.com/dvyukov/3503afce181b7d48dabb421e10e70b00/raw/d049bd2128a8b1089497beb6104ba48c5550b4a8/gistfile1.txt

[ cut here ]
WARNING: CPU: 3 PID: 2956 at drivers/ata/libata-core.c:5317
ata_qc_issue+0xd14/0x1040 drivers/ata/libata-core.c:5316
CPU: 3 PID: 2956 Comm: a.out Not tainted 4.11.0-rc3+ #365
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
Call Trace:
 __dump_stack lib/dump_stack.c:16 [inline]
 dump_stack+0x1b8/0x28d lib/dump_stack.c:52
 panic+0x20c/0x423 kernel/panic.c:180
 __warn+0x1c4/0x1e0 kernel/panic.c:541
 warn_slowpath_null+0x2c/0x40 kernel/panic.c:584
 ata_qc_issue+0xd14/0x1040 drivers/ata/libata-core.c:5316
 ata_scsi_translate+0x34a/0x5e0 drivers/ata/libata-scsi.c:2021
 __ata_scsi_queuecmd drivers/ata/libata-scsi.c:4249 [inline]
 ata_scsi_queuecmd+0x2ae/0x660 drivers/ata/libata-scsi.c:4298
 scsi_dispatch_cmd+0x43e/0xb70 drivers/scsi/scsi_lib.c:1665
 scsi_request_fn+0x13dc/0x1ec0 drivers/scsi/scsi_lib.c:1800
 __blk_run_queue_uncond block/blk-core.c:305 [inline]
 __blk_run_queue+0xe3/0x150 block/blk-core.c:323
 __elv_add_request+0x494/0xce0 block/elevator.c:677
 blk_execute_rq_nowait+0x214/0x370 block/blk-exec.c:78
 blk_execute_rq+0x1ca/0x280 block/blk-exec.c:103
 sg_scsi_ioctl+0x3d0/0x7f0 block/scsi_ioctl.c:510
 sg_ioctl+0x1fdd/0x2f00 drivers/scsi/sg.c:1075
 vfs_ioctl fs/ioctl.c:45 [inline]
 do_vfs_ioctl+0x1af/0x16d0 fs/ioctl.c:685
 SYSC_ioctl fs/ioctl.c:700 [inline]
 SyS_ioctl+0x8f/0xc0 fs/ioctl.c:691
 entry_SYSCALL_64_fastpath+0x1f/0xc2
RIP: 0033:0x434cd9
RSP: 002b:7ffc5cd86308 EFLAGS: 0286 ORIG_RAX: 0010
RAX: ffda RBX: 004002b0 RCX: 00434cd9
RDX: 20001000 RSI: 0001 RDI: 0003
RBP: 0086 R08:  R09: 
R10:  R11: 0286 R12: 
R13: 00401a30 R14: 00401ac0 R15: 

On commit 093b995e3b55a0ae0670226ddfcb05bfbf0099ae

Re: [PATCH v2 02/10] x86: assembly, FUNC_START for fn, DATA_START for data

[Josh Poimboeuf]

On Thu, Mar 23, 2017 at 08:38:20AM +0100, Ingo Molnar wrote:
> 
> * Josh Poimboeuf  wrote:
> 
> > On Wed, Mar 22, 2017 at 08:46:16AM +0100, Ingo Molnar wrote:
> > > 
> > > * Jiri Slaby  wrote:
> > > 
> > > > On 03/22/2017, 08:25 AM, Ingo Molnar wrote:
> > > > > 
> > > > > * Pavel Machek  wrote:
> > > > > 
> > > > >> Hi!
> > > > >>
> > > > >>> -ENTRY(saved_rbp)   .quad   0
> > > > >>> -ENTRY(saved_rsi)   .quad   0
> > > > >>> -ENTRY(saved_rdi)   .quad   0
> > > > >>> -ENTRY(saved_rbx)   .quad   0
> > > > >>> +SYM_DATA_START(saved_rbp)  .quad   0
> > > > >>> +SYM_DATA_START(saved_rsi)  .quad   0
> > > > >>> +SYM_DATA_START(saved_rdi)  .quad   0
> > > > >>> +SYM_DATA_START(saved_rbx)  .quad   0
> > > > >>
> > > > >> Does it make sense to call it SYM_DATA_*START* when there's no
> > > > >> corresponding end?
> > > > > 
> > > > > That looks like a bug - I think we should strive for them to always 
> > > > > be in pairs.
> > > > > 
> > > > > Jiri, Josh, could objtool help here perhaps, to detect 
> > > > > 'non-terminated' 
> > > > > SYM_*_START() uses? This could be done by emitting debug data into a 
> > > > > special 
> > > > > section and then analyzing that section for unpaired entries. The 
> > > > > section can be 
> > > > > discarded in the final link, it won't show up in the kernel image.
> > > > 
> > > > It should be easier than that. No introduction of other info needed --
> > > > every global symbol without a ".type" or ".size" (i.e. SYM_*_END) should
> > > > be a bug now.
> > > 
> > > I'm all for that!
> > 
> > It would be easy to add this checking to objtool since it already reads
> > the symbol table.  The hard part is figuring out the logistics. :-)
> > 
> > - Should the warnings be on by default?
> 
> Yes, if objtool is running. Keep it simple.
> 
> > - Part of the "objtool check" command or something else?
> 
> Yes - I think it's still within the 'object file check' functionality.
> 
> > - Separate config option or just include it with
> >   CONFIG_STACK_VALIDATION?
> 
> Yeah, but I'd rename CONFIG_STACK_VALIDATION to CONFIG_OBJ_VALIDATION or 
> such. As 
> I predicted early on, objtool will go beyond stack checking! ;-)
> 
> > - Should all asm files be checked, including those currently skipped by
> >   objtool with OBJECT_FILES_NON_STANDARD?
> 
> The symbol syntax check should definitely be for all files, yes.

That all sounds reasonable.  I'll work something up.

> Could we perhaps emit 'non-standard stack frames' information into the .o 
> itself 
> (via a flag or a special section?), so that objtool can decide on its own 
> whether 
> to complain about any weirdnesses there?

For the OBJECT_FILES_NON_STANDARD case, where the whole file is
"special", we can just provide a flag to "objtool check" to tell it to
skip stack checking for that file, but still do the symbol checks.

> > > Can we detect double ends as well - i.e. do a build check of the full 
> > > syntax of 
> > > these symbol definition primitives?
> > 
> > Detecting double ends would be a little trickier.  The second SYM_*_END
> > supersedes the first, so that information isn't in the ELF symbol table.
> 
> Indeed.
> 
> > We could use a special section to annotate all the macro uses and have
> > objtool do the checking, similar to what you suggested earlier.
> 
> That might be useful for other purposes as well - such as the non-standard 
> stack 
> frame annotations?

To start with we can try going without all the special sections (other
than the SYM_END double end check).  If we end up finding another case
which isn't covered then we can always add the special sections later.

-- 
Josh

Re: [PATCH v2 02/10] x86: assembly, FUNC_START for fn, DATA_START for data

[Josh Poimboeuf]

On Thu, Mar 23, 2017 at 08:38:20AM +0100, Ingo Molnar wrote:
> 
> * Josh Poimboeuf  wrote:
> 
> > On Wed, Mar 22, 2017 at 08:46:16AM +0100, Ingo Molnar wrote:
> > > 
> > > * Jiri Slaby  wrote:
> > > 
> > > > On 03/22/2017, 08:25 AM, Ingo Molnar wrote:
> > > > > 
> > > > > * Pavel Machek  wrote:
> > > > > 
> > > > >> Hi!
> > > > >>
> > > > >>> -ENTRY(saved_rbp)   .quad   0
> > > > >>> -ENTRY(saved_rsi)   .quad   0
> > > > >>> -ENTRY(saved_rdi)   .quad   0
> > > > >>> -ENTRY(saved_rbx)   .quad   0
> > > > >>> +SYM_DATA_START(saved_rbp)  .quad   0
> > > > >>> +SYM_DATA_START(saved_rsi)  .quad   0
> > > > >>> +SYM_DATA_START(saved_rdi)  .quad   0
> > > > >>> +SYM_DATA_START(saved_rbx)  .quad   0
> > > > >>
> > > > >> Does it make sense to call it SYM_DATA_*START* when there's no
> > > > >> corresponding end?
> > > > > 
> > > > > That looks like a bug - I think we should strive for them to always 
> > > > > be in pairs.
> > > > > 
> > > > > Jiri, Josh, could objtool help here perhaps, to detect 
> > > > > 'non-terminated' 
> > > > > SYM_*_START() uses? This could be done by emitting debug data into a 
> > > > > special 
> > > > > section and then analyzing that section for unpaired entries. The 
> > > > > section can be 
> > > > > discarded in the final link, it won't show up in the kernel image.
> > > > 
> > > > It should be easier than that. No introduction of other info needed --
> > > > every global symbol without a ".type" or ".size" (i.e. SYM_*_END) should
> > > > be a bug now.
> > > 
> > > I'm all for that!
> > 
> > It would be easy to add this checking to objtool since it already reads
> > the symbol table.  The hard part is figuring out the logistics. :-)
> > 
> > - Should the warnings be on by default?
> 
> Yes, if objtool is running. Keep it simple.
> 
> > - Part of the "objtool check" command or something else?
> 
> Yes - I think it's still within the 'object file check' functionality.
> 
> > - Separate config option or just include it with
> >   CONFIG_STACK_VALIDATION?
> 
> Yeah, but I'd rename CONFIG_STACK_VALIDATION to CONFIG_OBJ_VALIDATION or 
> such. As 
> I predicted early on, objtool will go beyond stack checking! ;-)
> 
> > - Should all asm files be checked, including those currently skipped by
> >   objtool with OBJECT_FILES_NON_STANDARD?
> 
> The symbol syntax check should definitely be for all files, yes.

That all sounds reasonable.  I'll work something up.

> Could we perhaps emit 'non-standard stack frames' information into the .o 
> itself 
> (via a flag or a special section?), so that objtool can decide on its own 
> whether 
> to complain about any weirdnesses there?

For the OBJECT_FILES_NON_STANDARD case, where the whole file is
"special", we can just provide a flag to "objtool check" to tell it to
skip stack checking for that file, but still do the symbol checks.

> > > Can we detect double ends as well - i.e. do a build check of the full 
> > > syntax of 
> > > these symbol definition primitives?
> > 
> > Detecting double ends would be a little trickier.  The second SYM_*_END
> > supersedes the first, so that information isn't in the ELF symbol table.
> 
> Indeed.
> 
> > We could use a special section to annotate all the macro uses and have
> > objtool do the checking, similar to what you suggested earlier.
> 
> That might be useful for other purposes as well - such as the non-standard 
> stack 
> frame annotations?

To start with we can try going without all the special sections (other
than the SYM_END double end check).  If we end up finding another case
which isn't covered then we can always add the special sections later.

-- 
Josh

Re: [PATCH] hibernation: on 32-bit x86, disabled in favor of KASLR

[Evgenii Shatokhin]

On 23.03.2017 03:27, Kees Cook wrote:

This is a modified revert of commit 65fe935dd238 ("x86/KASLR, x86/power:
Remove x86 hibernation restrictions"), since it appears that 32-bit
hibernation still can't support KASLR. 64-bit is fine. Since people have
been running with KASLR by default on 32-bit since v4.8, this disables
hibernation (with a warning). Booting with "nokaslr" will disable KASLR
and enable hibernation.

Reported-by: Evgenii Shatokhin 
Signed-off-by: Kees Cook 
Cc: sta...@vger.kernel.org # v4.8+


The patch does not work as intended on my system, unfortunately.

I tried the mainline kernel v4.11-rc3 and added this patch. With 
"nokaslr" in the kernel command line, the system fails to hibernate. It 
complains this way in the log:


<...>
kernel: PM: writing image.
kernel: PM: Cannot find swap device, try swapon -a.
kernel: PM: Cannot get swap writer
kernel: PM: Basic memory bitmaps freed
kernel: Restarting tasks ... done.
systemd[1]: Time has been changed
systemd[3948]: Time has been changed
systemd[14825]: Time has been changed
systemd[1]: systemd-hibernate.service: main process exited, code=exited, 
status=1/FAILURE

systemd[1]: Failed to start Hibernate.
<...>

The swap device (swap file, actually) is available, however:
-
# swapon -s
Filename  Type  SizeUsed  Priority
/swap file  6297596 0 -1
-

I built the same kernel without this patch then, added "nokaslr" in the 
kernel command line again, and the system hibernates and resumes fine.



---
  Documentation/admin-guide/kernel-parameters.txt |  5 +
  arch/x86/boot/compressed/kaslr.c|  3 +++
  kernel/power/hibernate.c| 18 +-
  3 files changed, 25 insertions(+), 1 deletion(-)

diff --git a/Documentation/admin-guide/kernel-parameters.txt 
b/Documentation/admin-guide/kernel-parameters.txt
index 2ba45caabada..6f899c7f587d 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -1725,6 +1725,11 @@
kernel and module base offset ASLR (Address Space
Layout Randomization).

+   On 32-bit x86 with CONFIG_HIBERNATION, hibernation
+   is disabled if KASLR is enabled. If "nokaslr" is
+   specified, KASLR will be diabled and hibernation
+   will be enabled.
+
keepinitrd  [HW,ARM]

kernelcore= [KNL,X86,IA-64,PPC]
diff --git a/arch/x86/boot/compressed/kaslr.c b/arch/x86/boot/compressed/kaslr.c
index 8b7c9e75edcb..b694af45f1e0 100644
--- a/arch/x86/boot/compressed/kaslr.c
+++ b/arch/x86/boot/compressed/kaslr.c
@@ -572,6 +572,9 @@ void choose_random_location(unsigned long input,
return;
}

+   if (IS_ENABLED(CONFIG_X86_32) && IS_ENABLED(CONFIG_HIBERNATION))
+   warn("KASLR active: hibernation disabled on 32-bit x86.");
+
boot_params->hdr.loadflags |= KASLR_FLAG;

/* Prepare to add new identity pagetables on demand. */
diff --git a/kernel/power/hibernate.c b/kernel/power/hibernate.c
index a8b978c35a6a..1d8f1fe1b7f4 100644
--- a/kernel/power/hibernate.c
+++ b/kernel/power/hibernate.c
@@ -37,9 +37,14 @@
  #include "power.h"


-static int nocompress;
+#if defined(CONFIG_X86_32) && defined(CONFIG_RANDOMIZE_BASE)
+static int noresume = 1;
+static int nohibernate = 1;
+#else
  static int noresume;
  static int nohibernate;
+#endif
+static int nocompress;
  static int resume_wait;
  static unsigned int resume_delay;
  static char resume_file[256] = CONFIG_PM_STD_PARTITION;
@@ -1194,3 +1199,14 @@ __setup("hibernate=", hibernate_setup);
  __setup("resumewait", resumewait_setup);
  __setup("resumedelay=", resumedelay_setup);
  __setup("nohibernate", nohibernate_setup);
+
+/* Allow hibernation to be disabled in favor of KASLR on 32-bit x86. */
+#if defined(CONFIG_X86_32) && defined(CONFIG_RANDOMIZE_BASE)
+static int __init nokaslr_hibernate_setup(char *str)
+{
+   noresume = 0;
+   nohibernate = 0;
+   return 1;
+}
+__setup("nokaslr", nokaslr_hibernate_setup);
+#endif

Re: [PATCH] hibernation: on 32-bit x86, disabled in favor of KASLR

[Evgenii Shatokhin]

On 23.03.2017 03:27, Kees Cook wrote:

This is a modified revert of commit 65fe935dd238 ("x86/KASLR, x86/power:
Remove x86 hibernation restrictions"), since it appears that 32-bit
hibernation still can't support KASLR. 64-bit is fine. Since people have
been running with KASLR by default on 32-bit since v4.8, this disables
hibernation (with a warning). Booting with "nokaslr" will disable KASLR
and enable hibernation.

Reported-by: Evgenii Shatokhin 
Signed-off-by: Kees Cook 
Cc: sta...@vger.kernel.org # v4.8+


The patch does not work as intended on my system, unfortunately.

I tried the mainline kernel v4.11-rc3 and added this patch. With 
"nokaslr" in the kernel command line, the system fails to hibernate. It 
complains this way in the log:


<...>
kernel: PM: writing image.
kernel: PM: Cannot find swap device, try swapon -a.
kernel: PM: Cannot get swap writer
kernel: PM: Basic memory bitmaps freed
kernel: Restarting tasks ... done.
systemd[1]: Time has been changed
systemd[3948]: Time has been changed
systemd[14825]: Time has been changed
systemd[1]: systemd-hibernate.service: main process exited, code=exited, 
status=1/FAILURE

systemd[1]: Failed to start Hibernate.
<...>

The swap device (swap file, actually) is available, however:
-
# swapon -s
Filename  Type  SizeUsed  Priority
/swap file  6297596 0 -1
-

I built the same kernel without this patch then, added "nokaslr" in the 
kernel command line again, and the system hibernates and resumes fine.



---
  Documentation/admin-guide/kernel-parameters.txt |  5 +
  arch/x86/boot/compressed/kaslr.c|  3 +++
  kernel/power/hibernate.c| 18 +-
  3 files changed, 25 insertions(+), 1 deletion(-)

diff --git a/Documentation/admin-guide/kernel-parameters.txt 
b/Documentation/admin-guide/kernel-parameters.txt
index 2ba45caabada..6f899c7f587d 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -1725,6 +1725,11 @@
kernel and module base offset ASLR (Address Space
Layout Randomization).

+   On 32-bit x86 with CONFIG_HIBERNATION, hibernation
+   is disabled if KASLR is enabled. If "nokaslr" is
+   specified, KASLR will be diabled and hibernation
+   will be enabled.
+
keepinitrd  [HW,ARM]

kernelcore= [KNL,X86,IA-64,PPC]
diff --git a/arch/x86/boot/compressed/kaslr.c b/arch/x86/boot/compressed/kaslr.c
index 8b7c9e75edcb..b694af45f1e0 100644
--- a/arch/x86/boot/compressed/kaslr.c
+++ b/arch/x86/boot/compressed/kaslr.c
@@ -572,6 +572,9 @@ void choose_random_location(unsigned long input,
return;
}

+   if (IS_ENABLED(CONFIG_X86_32) && IS_ENABLED(CONFIG_HIBERNATION))
+   warn("KASLR active: hibernation disabled on 32-bit x86.");
+
boot_params->hdr.loadflags |= KASLR_FLAG;

/* Prepare to add new identity pagetables on demand. */
diff --git a/kernel/power/hibernate.c b/kernel/power/hibernate.c
index a8b978c35a6a..1d8f1fe1b7f4 100644
--- a/kernel/power/hibernate.c
+++ b/kernel/power/hibernate.c
@@ -37,9 +37,14 @@
  #include "power.h"


-static int nocompress;
+#if defined(CONFIG_X86_32) && defined(CONFIG_RANDOMIZE_BASE)
+static int noresume = 1;
+static int nohibernate = 1;
+#else
  static int noresume;
  static int nohibernate;
+#endif
+static int nocompress;
  static int resume_wait;
  static unsigned int resume_delay;
  static char resume_file[256] = CONFIG_PM_STD_PARTITION;
@@ -1194,3 +1199,14 @@ __setup("hibernate=", hibernate_setup);
  __setup("resumewait", resumewait_setup);
  __setup("resumedelay=", resumedelay_setup);
  __setup("nohibernate", nohibernate_setup);
+
+/* Allow hibernation to be disabled in favor of KASLR on 32-bit x86. */
+#if defined(CONFIG_X86_32) && defined(CONFIG_RANDOMIZE_BASE)
+static int __init nokaslr_hibernate_setup(char *str)
+{
+   noresume = 0;
+   nohibernate = 0;
+   return 1;
+}
+__setup("nokaslr", nokaslr_hibernate_setup);
+#endif

Re: Updates, autofocus, 5Mpix mode on N900? Re: [RFC 08/13] smiapp-pll: Take existing divisor into account in minimum divisor check

[Pavel Machek]

Hi!

> > Plus I have played with v4l-utils, and managed to implement autofocus
> > and autoexposure -- it was easier than expected. I believe you
> > mentioned you had some patches to automatically initialize the
> > pipeline. Do you and can I have them?
> 
> It was an early prototype and it wasn't really functional yet.
> 
> Given a video node, it can find possible pipelines to the image sources with
> common formats. I.e. the ccdc -> rsz path is not available for raw
> cameras.

> C (especially without helper libraries) wasn't particularly suitable for the
> task, the data structures I had didn't end up too nice. What would also be
> necessary is to associate library or application specific data to entities,
> this could be as simple as key-value pairs with both key and value being
> pointers.

Could I get a copy, anyway? Need not be perfect, but starting point
would be welcome.

Thanks,
Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature

Re: Updates, autofocus, 5Mpix mode on N900? Re: [RFC 08/13] smiapp-pll: Take existing divisor into account in minimum divisor check

[Pavel Machek]

Hi!

> > Plus I have played with v4l-utils, and managed to implement autofocus
> > and autoexposure -- it was easier than expected. I believe you
> > mentioned you had some patches to automatically initialize the
> > pipeline. Do you and can I have them?
> 
> It was an early prototype and it wasn't really functional yet.
> 
> Given a video node, it can find possible pipelines to the image sources with
> common formats. I.e. the ccdc -> rsz path is not available for raw
> cameras.

> C (especially without helper libraries) wasn't particularly suitable for the
> task, the data structures I had didn't end up too nice. What would also be
> necessary is to associate library or application specific data to entities,
> this could be as simple as key-value pairs with both key and value being
> pointers.

Could I get a copy, anyway? Need not be perfect, but starting point
would be welcome.

Thanks,
Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature

Re: [PATCH] drivers/staging/dgnc: Removing manual function tracing using dev_dbg

[Greg Kroah-Hartman]

On Thu, Mar 23, 2017 at 02:20:53PM +0530, Pushkar Jambhlekar wrote:
> Current implementation manually traces function using 'dev_dbg'. This way is 
> not needed because of ftrace, making these calls redundant.


Always wrap your changelog lines properly.

Also, someone else sent this same patch in right before you did, sorry.

greg k-h

Re: [PATCH] drivers/staging/dgnc: Removing manual function tracing using dev_dbg

[Greg Kroah-Hartman]

On Thu, Mar 23, 2017 at 02:20:53PM +0530, Pushkar Jambhlekar wrote:
> Current implementation manually traces function using 'dev_dbg'. This way is 
> not needed because of ftrace, making these calls redundant.


Always wrap your changelog lines properly.

Also, someone else sent this same patch in right before you did, sorry.

greg k-h

[PATCH] nvmem: imx-ocotp: fix usage of "dev" pointers

[Richard Leitner]

Assign the correct dev pointer to struct ocotp_priv during probe. This
is needed to display dev_* messages correctly. Furthermore harmonize
the usage of dev (instead of >dev) in the probe function.

Signed-off-by: Richard Leitner 
---
 drivers/nvmem/imx-ocotp.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/nvmem/imx-ocotp.c b/drivers/nvmem/imx-ocotp.c
index b8ca1e6..549177d 100644
--- a/drivers/nvmem/imx-ocotp.c
+++ b/drivers/nvmem/imx-ocotp.c
@@ -90,12 +90,14 @@ static int imx_ocotp_probe(struct platform_device *pdev)
if (!priv)
return -ENOMEM;
 
+   priv->dev = dev;
+
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
priv->base = devm_ioremap_resource(dev, res);
if (IS_ERR(priv->base))
return PTR_ERR(priv->base);
 
-   priv->clk = devm_clk_get(>dev, NULL);
+   priv->clk = devm_clk_get(dev, NULL);
if (IS_ERR(priv->clk))
return PTR_ERR(priv->clk);
 
-- 
2.1.4

[PATCH] nvmem: imx-ocotp: fix usage of "dev" pointers

[Richard Leitner]

Assign the correct dev pointer to struct ocotp_priv during probe. This
is needed to display dev_* messages correctly. Furthermore harmonize
the usage of dev (instead of >dev) in the probe function.

Signed-off-by: Richard Leitner 
---
 drivers/nvmem/imx-ocotp.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/nvmem/imx-ocotp.c b/drivers/nvmem/imx-ocotp.c
index b8ca1e6..549177d 100644
--- a/drivers/nvmem/imx-ocotp.c
+++ b/drivers/nvmem/imx-ocotp.c
@@ -90,12 +90,14 @@ static int imx_ocotp_probe(struct platform_device *pdev)
if (!priv)
return -ENOMEM;
 
+   priv->dev = dev;
+
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
priv->base = devm_ioremap_resource(dev, res);
if (IS_ERR(priv->base))
return PTR_ERR(priv->base);
 
-   priv->clk = devm_clk_get(>dev, NULL);
+   priv->clk = devm_clk_get(dev, NULL);
if (IS_ERR(priv->clk))
return PTR_ERR(priv->clk);
 
-- 
2.1.4

Re: [PATCH 11/11] staging: speakup: Fix alignment with parenthesis.

[Greg KH]

On Tue, Mar 21, 2017 at 05:12:35PM +0530, Arushi Singhal wrote:
> This patch fixes the warnings reported by checkpatch.pl
> for please use a blank line after function/struct/union/enum
> declarations.

That's not what this patch does at all!

Please be more careful.

greg k-h

Re: [PATCH 11/11] staging: speakup: Fix alignment with parenthesis.

[Greg KH]

On Tue, Mar 21, 2017 at 05:12:35PM +0530, Arushi Singhal wrote:
> This patch fixes the warnings reported by checkpatch.pl
> for please use a blank line after function/struct/union/enum
> declarations.

That's not what this patch does at all!

Please be more careful.

greg k-h

Re: [PATCH 09/11] staging: speakup: Simplify the NULL comparisons

[Greg KH]

On Tue, Mar 21, 2017 at 05:12:33PM +0530, Arushi Singhal wrote:
> Fixed coding style for null comparisons in speakup driver to be more
> consistant with the rest of the kernel coding style.
> Replaced 'x != NULL' with 'x' and 'x = NULL' with '!x'.
> 
> Signed-off-by: Arushi Singhal 
> ---
>  drivers/staging/speakup/fakekey.c |  2 +-
>  drivers/staging/speakup/main.c| 32 
>  2 files changed, 17 insertions(+), 17 deletions(-)

You used this same subject line in this series, not good :(

greg k-h

Re: [PATCH 09/11] staging: speakup: Simplify the NULL comparisons

[Greg KH]

On Tue, Mar 21, 2017 at 05:12:33PM +0530, Arushi Singhal wrote:
> Fixed coding style for null comparisons in speakup driver to be more
> consistant with the rest of the kernel coding style.
> Replaced 'x != NULL' with 'x' and 'x = NULL' with '!x'.
> 
> Signed-off-by: Arushi Singhal 
> ---
>  drivers/staging/speakup/fakekey.c |  2 +-
>  drivers/staging/speakup/main.c| 32 
>  2 files changed, 17 insertions(+), 17 deletions(-)

You used this same subject line in this series, not good :(

greg k-h

Re: [PATCH 05/11] staging: speakup: Remove multiple assignments

[Greg KH]

On Tue, Mar 21, 2017 at 05:12:29PM +0530, Arushi Singhal wrote:
> This patch fixes the checkpatch.pl warning "multiple assignments
> should be avoided."
> 
> Signed-off-by: Arushi Singhal 
> ---
>  drivers/staging/speakup/main.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/staging/speakup/main.c b/drivers/staging/speakup/main.c
> index 21e76b031449..c10445624e92 100644
> --- a/drivers/staging/speakup/main.c
> +++ b/drivers/staging/speakup/main.c
> @@ -2106,7 +2106,8 @@ speakup_key(struct vc_data *vc, int shift_state, int 
> keycode, u_short keysym,
>   spk_keydown = 0;
>   goto out;
>   }
> - value = spk_lastkey = pad_chars[value];
> + value = pad_chars[value];
> + spk_lastkey = value;

Also harder to read now :(

Re: [PATCH 05/11] staging: speakup: Remove multiple assignments

[Greg KH]

On Tue, Mar 21, 2017 at 05:12:29PM +0530, Arushi Singhal wrote:
> This patch fixes the checkpatch.pl warning "multiple assignments
> should be avoided."
> 
> Signed-off-by: Arushi Singhal 
> ---
>  drivers/staging/speakup/main.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/staging/speakup/main.c b/drivers/staging/speakup/main.c
> index 21e76b031449..c10445624e92 100644
> --- a/drivers/staging/speakup/main.c
> +++ b/drivers/staging/speakup/main.c
> @@ -2106,7 +2106,8 @@ speakup_key(struct vc_data *vc, int shift_state, int 
> keycode, u_short keysym,
>   spk_keydown = 0;
>   goto out;
>   }
> - value = spk_lastkey = pad_chars[value];
> + value = pad_chars[value];
> + spk_lastkey = value;

Also harder to read now :(

Re: [PATCH 02/11] staging: speakup: Remove multiple assignments

[Greg KH]

On Tue, Mar 21, 2017 at 05:12:26PM +0530, Arushi Singhal wrote:
> This patch fixes the checkpatch.pl warning "multiple assignments
> should be avoided."
> 
> Signed-off-by: Arushi Singhal 
> ---
>  drivers/staging/speakup/main.c | 18 --
>  1 file changed, 12 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/staging/speakup/main.c b/drivers/staging/speakup/main.c
> index f71206878363..f8fccc8bf6b2 100644
> --- a/drivers/staging/speakup/main.c
> +++ b/drivers/staging/speakup/main.c
> @@ -270,9 +270,12 @@ static unsigned char get_attributes(struct vc_data *vc, 
> u16 *pos)
>  
>  static void speakup_date(struct vc_data *vc)
>  {
> - spk_x = spk_cx = vc->vc_x;
> - spk_y = spk_cy = vc->vc_y;
> - spk_pos = spk_cp = vc->vc_pos;
> + spk_x = vc->vc_x;
> + spk_cx = spk_x;
> + spk_y = vc->vc_y;
> + spk_cy = spk_y;
> + spk_pos = vc->vc_pos;
> + spk_cp = spk_pos;

Ick, this is harder to read now, don't you think?

not good.

greg k-h

Re: [PATCH 02/11] staging: speakup: Remove multiple assignments

[Greg KH]

On Tue, Mar 21, 2017 at 05:12:26PM +0530, Arushi Singhal wrote:
> This patch fixes the checkpatch.pl warning "multiple assignments
> should be avoided."
> 
> Signed-off-by: Arushi Singhal 
> ---
>  drivers/staging/speakup/main.c | 18 --
>  1 file changed, 12 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/staging/speakup/main.c b/drivers/staging/speakup/main.c
> index f71206878363..f8fccc8bf6b2 100644
> --- a/drivers/staging/speakup/main.c
> +++ b/drivers/staging/speakup/main.c
> @@ -270,9 +270,12 @@ static unsigned char get_attributes(struct vc_data *vc, 
> u16 *pos)
>  
>  static void speakup_date(struct vc_data *vc)
>  {
> - spk_x = spk_cx = vc->vc_x;
> - spk_y = spk_cy = vc->vc_y;
> - spk_pos = spk_cp = vc->vc_pos;
> + spk_x = vc->vc_x;
> + spk_cx = spk_x;
> + spk_y = vc->vc_y;
> + spk_cy = spk_y;
> + spk_pos = vc->vc_pos;
> + spk_cp = spk_pos;

Ick, this is harder to read now, don't you think?

not good.

greg k-h

Re: kvm: use-after-free function call in kvm_io_bus_destroy

[David Hildenbrand]

On 23.03.2017 13:33, Dmitry Vyukov wrote:
> Hello,
> 
> I've got the following report while running syzkaller fuzzer on
> 093b995e3b55a0ae0670226ddfcb05bfbf0099ae. Note the preceding injected
> kmalloc failure, most likely it's the root cause.
> 
> 
> FAULT_INJECTION: forcing a failure.
> name failslab, interval 1, probability 0, space 0, times 0
> CPU: 0 PID: 14650 Comm: syz-executor2 Not tainted 4.11.0-rc3+ #364
> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
> Call Trace:
>  __dump_stack lib/dump_stack.c:16 [inline]
>  dump_stack+0x1b8/0x28d lib/dump_stack.c:52
>  fail_dump lib/fault-inject.c:45 [inline]
>  should_fail+0x78a/0x870 lib/fault-inject.c:154
>  should_failslab+0xec/0x120 mm/failslab.c:31
>  slab_pre_alloc_hook mm/slab.h:434 [inline]
>  slab_alloc mm/slab.c:3394 [inline]
>  __do_kmalloc mm/slab.c:3734 [inline]
>  __kmalloc+0x220/0x730 mm/slab.c:3745
>  kmalloc include/linux/slab.h:495 [inline]
>  kvm_io_bus_unregister_dev+0x1a2/0x300
> arch/x86/kvm/../../../virt/kvm/kvm_main.c:3594
>  kvm_free_pit+0x58/0x110 arch/x86/kvm/i8254.c:727
>  kvm_arch_sync_events+0x35/0x40 arch/x86/kvm/x86.c:8078
>  kvm_destroy_vm arch/x86/kvm/../../../virt/kvm/kvm_main.c:727 [inline]
>  kvm_put_kvm+0x27f/0xa70 arch/x86/kvm/../../../virt/kvm/kvm_main.c:761
>  kvm_vm_release+0x42/0x50 arch/x86/kvm/../../../virt/kvm/kvm_main.c:772
>  __fput+0x327/0x7f0 fs/file_table.c:209
>  fput+0x15/0x20 fs/file_table.c:245
>  task_work_run+0x1a4/0x270 kernel/task_work.c:116
>  tracehook_notify_resume include/linux/tracehook.h:191 [inline]
>  exit_to_usermode_loop+0x24d/0x2d0 arch/x86/entry/common.c:161
>  prepare_exit_to_usermode arch/x86/entry/common.c:191 [inline]
>  syscall_return_slowpath+0x3bd/0x460 arch/x86/entry/common.c:260
>  entry_SYSCALL_64_fastpath+0xc0/0xc2
> RIP: 0033:0x445b79
> RSP: 002b:7f6e094bc858 EFLAGS: 0292 ORIG_RAX: 0021
> RAX: 001c RBX: 00708000 RCX: 00445b79
> RDX:  RSI: 001c RDI: 001b
> RBP: 0430 R08:  R09: 
> R10:  R11: 0292 R12: 006de4f0
> R13: 001c R14:  R15: 001b
> ==
> BUG: KASAN: use-after-free in kvm_io_bus_destroy
> include/kvm/iodev.h:72 [inline] at addr 88003bfb7d40
> BUG: KASAN: use-after-free in kvm_destroy_vm
> arch/x86/kvm/../../../virt/kvm/kvm_main.c:733 [inline] at addr
> 88003bfb7d40
> BUG: KASAN: use-after-free in kvm_put_kvm+0x932/0xa70
> arch/x86/kvm/../../../virt/kvm/kvm_main.c:761 at addr 88003bfb7d40
> Read of size 8 by task syz-executor2/14650
> CPU: 0 PID: 14650 Comm: syz-executor2 Not tainted 4.11.0-rc3+ #364
> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
> Call Trace:
>  __dump_stack lib/dump_stack.c:16 [inline]
>  dump_stack+0x1b8/0x28d lib/dump_stack.c:52
>  kasan_object_err+0x1c/0x70 mm/kasan/report.c:166
>  print_address_description mm/kasan/report.c:210 [inline]
>  kasan_report_error mm/kasan/report.c:294 [inline]
>  kasan_report.part.2+0x1be/0x480 mm/kasan/report.c:316
>  kasan_report mm/kasan/report.c:337 [inline]
>  __asan_report_load8_noabort+0x29/0x30 mm/kasan/report.c:337
>  kvm_io_bus_destroy include/kvm/iodev.h:72 [inline]
>  kvm_destroy_vm arch/x86/kvm/../../../virt/kvm/kvm_main.c:733 [inline]
>  kvm_put_kvm+0x932/0xa70 arch/x86/kvm/../../../virt/kvm/kvm_main.c:761
>  kvm_vm_release+0x42/0x50 arch/x86/kvm/../../../virt/kvm/kvm_main.c:772
>  __fput+0x327/0x7f0 fs/file_table.c:209
>  fput+0x15/0x20 fs/file_table.c:245
>  task_work_run+0x1a4/0x270 kernel/task_work.c:116
>  tracehook_notify_resume include/linux/tracehook.h:191 [inline]
>  exit_to_usermode_loop+0x24d/0x2d0 arch/x86/entry/common.c:161
>  prepare_exit_to_usermode arch/x86/entry/common.c:191 [inline]
>  syscall_return_slowpath+0x3bd/0x460 arch/x86/entry/common.c:260
>  entry_SYSCALL_64_fastpath+0xc0/0xc2
> RIP: 0033:0x445b79
> RSP: 002b:7f6e094bc858 EFLAGS: 0292 ORIG_RAX: 0021
> RAX: 001c RBX: 00708000 RCX: 00445b79
> RDX:  RSI: 001c RDI: 001b
> RBP: 0430 R08:  R09: 
> R10:  R11: 0292 R12: 006de4f0
> R13: 001c R14:  R15: 001b
> Object at 88003bfb7d40, in cache kmalloc-512 size: 512
> Allocated:
> PID = 14650
>  save_stack_trace+0x16/0x20 arch/x86/kernel/stacktrace.c:59
>  save_stack+0x43/0xd0 mm/kasan/kasan.c:517
>  set_track mm/kasan/kasan.c:529 [inline]
>  kasan_kmalloc+0xbc/0xf0 mm/kasan/kasan.c:620
>  kmem_cache_alloc_trace+0x11a/0x720 mm/slab.c:3638
>  kmalloc include/linux/slab.h:490 [inline]
>  kzalloc include/linux/slab.h:663 [inline]
>  kvm_create_pit+0xc2/0x8b0 arch/x86/kvm/i8254.c:656
>  kvm_arch_vm_ioctl+0x1339/0x2190 

Re: kvm: use-after-free function call in kvm_io_bus_destroy

[David Hildenbrand]

On 23.03.2017 13:33, Dmitry Vyukov wrote:
> Hello,
> 
> I've got the following report while running syzkaller fuzzer on
> 093b995e3b55a0ae0670226ddfcb05bfbf0099ae. Note the preceding injected
> kmalloc failure, most likely it's the root cause.
> 
> 
> FAULT_INJECTION: forcing a failure.
> name failslab, interval 1, probability 0, space 0, times 0
> CPU: 0 PID: 14650 Comm: syz-executor2 Not tainted 4.11.0-rc3+ #364
> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
> Call Trace:
>  __dump_stack lib/dump_stack.c:16 [inline]
>  dump_stack+0x1b8/0x28d lib/dump_stack.c:52
>  fail_dump lib/fault-inject.c:45 [inline]
>  should_fail+0x78a/0x870 lib/fault-inject.c:154
>  should_failslab+0xec/0x120 mm/failslab.c:31
>  slab_pre_alloc_hook mm/slab.h:434 [inline]
>  slab_alloc mm/slab.c:3394 [inline]
>  __do_kmalloc mm/slab.c:3734 [inline]
>  __kmalloc+0x220/0x730 mm/slab.c:3745
>  kmalloc include/linux/slab.h:495 [inline]
>  kvm_io_bus_unregister_dev+0x1a2/0x300
> arch/x86/kvm/../../../virt/kvm/kvm_main.c:3594
>  kvm_free_pit+0x58/0x110 arch/x86/kvm/i8254.c:727
>  kvm_arch_sync_events+0x35/0x40 arch/x86/kvm/x86.c:8078
>  kvm_destroy_vm arch/x86/kvm/../../../virt/kvm/kvm_main.c:727 [inline]
>  kvm_put_kvm+0x27f/0xa70 arch/x86/kvm/../../../virt/kvm/kvm_main.c:761
>  kvm_vm_release+0x42/0x50 arch/x86/kvm/../../../virt/kvm/kvm_main.c:772
>  __fput+0x327/0x7f0 fs/file_table.c:209
>  fput+0x15/0x20 fs/file_table.c:245
>  task_work_run+0x1a4/0x270 kernel/task_work.c:116
>  tracehook_notify_resume include/linux/tracehook.h:191 [inline]
>  exit_to_usermode_loop+0x24d/0x2d0 arch/x86/entry/common.c:161
>  prepare_exit_to_usermode arch/x86/entry/common.c:191 [inline]
>  syscall_return_slowpath+0x3bd/0x460 arch/x86/entry/common.c:260
>  entry_SYSCALL_64_fastpath+0xc0/0xc2
> RIP: 0033:0x445b79
> RSP: 002b:7f6e094bc858 EFLAGS: 0292 ORIG_RAX: 0021
> RAX: 001c RBX: 00708000 RCX: 00445b79
> RDX:  RSI: 001c RDI: 001b
> RBP: 0430 R08:  R09: 
> R10:  R11: 0292 R12: 006de4f0
> R13: 001c R14:  R15: 001b
> ==
> BUG: KASAN: use-after-free in kvm_io_bus_destroy
> include/kvm/iodev.h:72 [inline] at addr 88003bfb7d40
> BUG: KASAN: use-after-free in kvm_destroy_vm
> arch/x86/kvm/../../../virt/kvm/kvm_main.c:733 [inline] at addr
> 88003bfb7d40
> BUG: KASAN: use-after-free in kvm_put_kvm+0x932/0xa70
> arch/x86/kvm/../../../virt/kvm/kvm_main.c:761 at addr 88003bfb7d40
> Read of size 8 by task syz-executor2/14650
> CPU: 0 PID: 14650 Comm: syz-executor2 Not tainted 4.11.0-rc3+ #364
> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
> Call Trace:
>  __dump_stack lib/dump_stack.c:16 [inline]
>  dump_stack+0x1b8/0x28d lib/dump_stack.c:52
>  kasan_object_err+0x1c/0x70 mm/kasan/report.c:166
>  print_address_description mm/kasan/report.c:210 [inline]
>  kasan_report_error mm/kasan/report.c:294 [inline]
>  kasan_report.part.2+0x1be/0x480 mm/kasan/report.c:316
>  kasan_report mm/kasan/report.c:337 [inline]
>  __asan_report_load8_noabort+0x29/0x30 mm/kasan/report.c:337
>  kvm_io_bus_destroy include/kvm/iodev.h:72 [inline]
>  kvm_destroy_vm arch/x86/kvm/../../../virt/kvm/kvm_main.c:733 [inline]
>  kvm_put_kvm+0x932/0xa70 arch/x86/kvm/../../../virt/kvm/kvm_main.c:761
>  kvm_vm_release+0x42/0x50 arch/x86/kvm/../../../virt/kvm/kvm_main.c:772
>  __fput+0x327/0x7f0 fs/file_table.c:209
>  fput+0x15/0x20 fs/file_table.c:245
>  task_work_run+0x1a4/0x270 kernel/task_work.c:116
>  tracehook_notify_resume include/linux/tracehook.h:191 [inline]
>  exit_to_usermode_loop+0x24d/0x2d0 arch/x86/entry/common.c:161
>  prepare_exit_to_usermode arch/x86/entry/common.c:191 [inline]
>  syscall_return_slowpath+0x3bd/0x460 arch/x86/entry/common.c:260
>  entry_SYSCALL_64_fastpath+0xc0/0xc2
> RIP: 0033:0x445b79
> RSP: 002b:7f6e094bc858 EFLAGS: 0292 ORIG_RAX: 0021
> RAX: 001c RBX: 00708000 RCX: 00445b79
> RDX:  RSI: 001c RDI: 001b
> RBP: 0430 R08:  R09: 
> R10:  R11: 0292 R12: 006de4f0
> R13: 001c R14:  R15: 001b
> Object at 88003bfb7d40, in cache kmalloc-512 size: 512
> Allocated:
> PID = 14650
>  save_stack_trace+0x16/0x20 arch/x86/kernel/stacktrace.c:59
>  save_stack+0x43/0xd0 mm/kasan/kasan.c:517
>  set_track mm/kasan/kasan.c:529 [inline]
>  kasan_kmalloc+0xbc/0xf0 mm/kasan/kasan.c:620
>  kmem_cache_alloc_trace+0x11a/0x720 mm/slab.c:3638
>  kmalloc include/linux/slab.h:490 [inline]
>  kzalloc include/linux/slab.h:663 [inline]
>  kvm_create_pit+0xc2/0x8b0 arch/x86/kvm/i8254.c:656
>  kvm_arch_vm_ioctl+0x1339/0x2190 

Re: [PATCH staging/speakup v3 3/3] use speakup_allocate as per required context

[Greg KH]

On Tue, Mar 21, 2017 at 12:40:24PM +0530, Pranay Kr. Srivastava wrote:
> speakup_allocate used GFP_ATOMIC for allocations
> even while during initialization due to it's use
> in notifier call.
> 
> Pass GFP_ flags as well to speakup_allocate depending
> on the context it is called in.
> 
> Signed-off-by: Pranay Kr. Srivastava 
> ---
>  drivers/staging/speakup/main.c | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)

This patch didn't apply to my staging-testing branch, but the 2 others
did, odd.  Can you rebase it and resend?

thanks,

greg k-h

Re: [PATCH 2/2 v2] xen/acpi: upload PM state from init-domain to Xen

[Stanislaw Gruszka]

On Wed, Mar 22, 2017 at 10:56:02AM -0700, Ankur Arora wrote:
> >It is ok to do upload_pm_data() with delay i.e. after some other
> >resume actions are done and possibly xen-acpi-processor is in
> >running state ?
> The state uploaded is ACPI P and C state from struct acpi_processor
> which AFAICS is stable once inited so a delay would not lead to
> invalid state.
> The only concern would be the ACPI pCPU hotplug logic in
> acpi_processor_add() which could add a new entry in
> per_cpu(processors) but that also looks okay because either we
> get a NULL or we get a pointer to an inited structure.
> 
> As for the hypervisor -- that falls back to more limited state after
> resume (because some of this state is thrown away at suspend) and so
> uses that until it gets the uploaded PM state from the initial-domain.

Patch looks good to me then.

Reviewed-by: Stanislaw Gruszka 

Re: [PATCH staging/speakup v3 3/3] use speakup_allocate as per required context

[Greg KH]

On Tue, Mar 21, 2017 at 12:40:24PM +0530, Pranay Kr. Srivastava wrote:
> speakup_allocate used GFP_ATOMIC for allocations
> even while during initialization due to it's use
> in notifier call.
> 
> Pass GFP_ flags as well to speakup_allocate depending
> on the context it is called in.
> 
> Signed-off-by: Pranay Kr. Srivastava 
> ---
>  drivers/staging/speakup/main.c | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)

This patch didn't apply to my staging-testing branch, but the 2 others
did, odd.  Can you rebase it and resend?

thanks,

greg k-h

Re: [PATCH 2/2 v2] xen/acpi: upload PM state from init-domain to Xen

[Stanislaw Gruszka]

On Wed, Mar 22, 2017 at 10:56:02AM -0700, Ankur Arora wrote:
> >It is ok to do upload_pm_data() with delay i.e. after some other
> >resume actions are done and possibly xen-acpi-processor is in
> >running state ?
> The state uploaded is ACPI P and C state from struct acpi_processor
> which AFAICS is stable once inited so a delay would not lead to
> invalid state.
> The only concern would be the ACPI pCPU hotplug logic in
> acpi_processor_add() which could add a new entry in
> per_cpu(processors) but that also looks okay because either we
> get a NULL or we get a pointer to an inited structure.
> 
> As for the hypervisor -- that falls back to more limited state after
> resume (because some of this state is thrown away at suspend) and so
> uses that until it gets the uploaded PM state from the initial-domain.

Patch looks good to me then.

Reviewed-by: Stanislaw Gruszka 

[PATCH] microblaze: use sg_phys()

[Geliang Tang]

Use sg_phys() instead of open-coding it.

Signed-off-by: Geliang Tang 
---
 arch/microblaze/kernel/dma.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/arch/microblaze/kernel/dma.c b/arch/microblaze/kernel/dma.c
index 12e093a..e45ada8 100644
--- a/arch/microblaze/kernel/dma.c
+++ b/arch/microblaze/kernel/dma.c
@@ -65,8 +65,7 @@ static int dma_direct_map_sg(struct device *dev, struct 
scatterlist *sgl,
if (attrs & DMA_ATTR_SKIP_CPU_SYNC)
continue;
 
-   __dma_sync(page_to_phys(sg_page(sg)) + sg->offset,
-   sg->length, direction);
+   __dma_sync(sg_phys(sg), sg->length, direction);
}
 
return nents;
-- 
2.9.3

[PATCH] microblaze: use sg_phys()

[Geliang Tang]

Use sg_phys() instead of open-coding it.

Signed-off-by: Geliang Tang 
---
 arch/microblaze/kernel/dma.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/arch/microblaze/kernel/dma.c b/arch/microblaze/kernel/dma.c
index 12e093a..e45ada8 100644
--- a/arch/microblaze/kernel/dma.c
+++ b/arch/microblaze/kernel/dma.c
@@ -65,8 +65,7 @@ static int dma_direct_map_sg(struct device *dev, struct 
scatterlist *sgl,
if (attrs & DMA_ATTR_SKIP_CPU_SYNC)
continue;
 
-   __dma_sync(page_to_phys(sg_page(sg)) + sg->offset,
-   sg->length, direction);
+   __dma_sync(sg_phys(sg), sg->length, direction);
}
 
return nents;
-- 
2.9.3

[PATCH] qla2xxx: use sg_virt()

[Geliang Tang]

Use sg_virt() instead of open-coding it.

Signed-off-by: Geliang Tang 
---
 drivers/scsi/qla2xxx/qla_isr.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/scsi/qla2xxx/qla_isr.c b/drivers/scsi/qla2xxx/qla_isr.c
index 3203367..9610d85 100644
--- a/drivers/scsi/qla2xxx/qla_isr.c
+++ b/drivers/scsi/qla2xxx/qla_isr.c
@@ -1991,7 +1991,7 @@ qla2x00_handle_dif_error(srb_t *sp, struct sts_entry_24xx 
*sts24)
return 1;
}
 
-   spt = page_address(sg_page(sg)) + sg->offset;
+   spt = sg_virt(sg);
spt += j;
 
spt->app_tag = 0x;
-- 
2.9.3

[PATCH] qla2xxx: use sg_virt()

[Geliang Tang]

Use sg_virt() instead of open-coding it.

Signed-off-by: Geliang Tang 
---
 drivers/scsi/qla2xxx/qla_isr.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/scsi/qla2xxx/qla_isr.c b/drivers/scsi/qla2xxx/qla_isr.c
index 3203367..9610d85 100644
--- a/drivers/scsi/qla2xxx/qla_isr.c
+++ b/drivers/scsi/qla2xxx/qla_isr.c
@@ -1991,7 +1991,7 @@ qla2x00_handle_dif_error(srb_t *sp, struct sts_entry_24xx 
*sts24)
return 1;
}
 
-   spt = page_address(sg_page(sg)) + sg->offset;
+   spt = sg_virt(sg);
spt += j;
 
spt->app_tag = 0x;
-- 
2.9.3

[PATCH] iommu: use sg_phys()

[Geliang Tang]

Use sg_phys() instead of open-coding it.

Signed-off-by: Geliang Tang 
---
 drivers/iommu/intel-iommu.c | 2 +-
 drivers/iommu/iommu.c   | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
index d412a31..9d09a9e 100644
--- a/drivers/iommu/intel-iommu.c
+++ b/drivers/iommu/intel-iommu.c
@@ -3892,7 +3892,7 @@ static int intel_nontranslate_map_sg(struct device *hddev,
 
for_each_sg(sglist, sg, nelems, i) {
BUG_ON(!sg_page(sg));
-   sg->dma_address = page_to_phys(sg_page(sg)) + sg->offset;
+   sg->dma_address = sg_phys(sg);
sg->dma_length = sg->length;
}
return nelems;
diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
index 3b67144..26f57b3 100644
--- a/drivers/iommu/iommu.c
+++ b/drivers/iommu/iommu.c
@@ -1603,7 +1603,7 @@ size_t default_iommu_map_sg(struct iommu_domain *domain, 
unsigned long iova,
min_pagesz = 1 << __ffs(domain->pgsize_bitmap);
 
for_each_sg(sg, s, nents, i) {
-   phys_addr_t phys = page_to_phys(sg_page(s)) + s->offset;
+   phys_addr_t phys = sg_phys(s);
 
/*
 * We are mapping on IOMMU page boundaries, so offset within
-- 
2.9.3

[PATCH] crypto: ixp4xx - Use sg_virt()

[Geliang Tang]

Use sg_virt() instead of open-coding it.

Signed-off-by: Geliang Tang 
---
 drivers/crypto/ixp4xx_crypto.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/crypto/ixp4xx_crypto.c b/drivers/crypto/ixp4xx_crypto.c
index 7868765..771dd26 100644
--- a/drivers/crypto/ixp4xx_crypto.c
+++ b/drivers/crypto/ixp4xx_crypto.c
@@ -806,7 +806,7 @@ static struct buffer_desc *chainup_buffers(struct device 
*dev,
void *ptr;
 
nbytes -= len;
-   ptr = page_address(sg_page(sg)) + sg->offset;
+   ptr = sg_virt(sg);
next_buf = dma_pool_alloc(buffer_pool, flags, _buf_phys);
if (!next_buf) {
buf = NULL;
-- 
2.9.3

[PATCH] iommu: use sg_phys()

[Geliang Tang]

Use sg_phys() instead of open-coding it.

Signed-off-by: Geliang Tang 
---
 drivers/iommu/intel-iommu.c | 2 +-
 drivers/iommu/iommu.c   | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
index d412a31..9d09a9e 100644
--- a/drivers/iommu/intel-iommu.c
+++ b/drivers/iommu/intel-iommu.c
@@ -3892,7 +3892,7 @@ static int intel_nontranslate_map_sg(struct device *hddev,
 
for_each_sg(sglist, sg, nelems, i) {
BUG_ON(!sg_page(sg));
-   sg->dma_address = page_to_phys(sg_page(sg)) + sg->offset;
+   sg->dma_address = sg_phys(sg);
sg->dma_length = sg->length;
}
return nelems;
diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
index 3b67144..26f57b3 100644
--- a/drivers/iommu/iommu.c
+++ b/drivers/iommu/iommu.c
@@ -1603,7 +1603,7 @@ size_t default_iommu_map_sg(struct iommu_domain *domain, 
unsigned long iova,
min_pagesz = 1 << __ffs(domain->pgsize_bitmap);
 
for_each_sg(sg, s, nents, i) {
-   phys_addr_t phys = page_to_phys(sg_page(s)) + s->offset;
+   phys_addr_t phys = sg_phys(s);
 
/*
 * We are mapping on IOMMU page boundaries, so offset within
-- 
2.9.3

[PATCH] crypto: ixp4xx - Use sg_virt()

[Geliang Tang]

Use sg_virt() instead of open-coding it.

Signed-off-by: Geliang Tang 
---
 drivers/crypto/ixp4xx_crypto.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/crypto/ixp4xx_crypto.c b/drivers/crypto/ixp4xx_crypto.c
index 7868765..771dd26 100644
--- a/drivers/crypto/ixp4xx_crypto.c
+++ b/drivers/crypto/ixp4xx_crypto.c
@@ -806,7 +806,7 @@ static struct buffer_desc *chainup_buffers(struct device 
*dev,
void *ptr;
 
nbytes -= len;
-   ptr = page_address(sg_page(sg)) + sg->offset;
+   ptr = sg_virt(sg);
next_buf = dma_pool_alloc(buffer_pool, flags, _buf_phys);
if (!next_buf) {
buf = NULL;
-- 
2.9.3

[PATCH] isdn: use setup_timer

[Geliang Tang]

Use setup_timer() instead of init_timer() to simplify the code.

Signed-off-by: Geliang Tang 
---
 drivers/isdn/divert/isdn_divert.c   |  9 +++--
 drivers/isdn/hardware/eicon/divasi.c|  5 ++---
 drivers/isdn/hardware/mISDN/hfcmulti.c  | 10 --
 drivers/isdn/hardware/mISDN/hfcpci.c|  9 +++--
 drivers/isdn/hardware/mISDN/mISDNipac.c |  5 ++---
 drivers/isdn/hardware/mISDN/mISDNisar.c | 10 --
 drivers/isdn/hardware/mISDN/w6692.c |  5 ++---
 drivers/isdn/hisax/amd7930_fn.c |  4 +---
 drivers/isdn/hisax/arcofi.c |  4 +---
 drivers/isdn/hisax/diva.c   |  5 ++---
 drivers/isdn/hisax/elsa.c   |  4 +---
 drivers/isdn/hisax/fsm.c|  4 +---
 drivers/isdn/hisax/hfc4s8s_l1.c |  5 ++---
 drivers/isdn/hisax/hfc_2bds0.c  |  4 +---
 drivers/isdn/hisax/hfc_pci.c|  8 ++--
 drivers/isdn/hisax/hfc_sx.c |  8 ++--
 drivers/isdn/hisax/hfc_usb.c|  8 ++--
 drivers/isdn/hisax/hfcscard.c   |  4 +---
 drivers/isdn/hisax/icc.c|  4 +---
 drivers/isdn/hisax/ipacx.c  |  4 +---
 drivers/isdn/hisax/isac.c   |  4 +---
 drivers/isdn/hisax/isar.c   | 10 --
 drivers/isdn/hisax/isdnl3.c |  4 +---
 drivers/isdn/hisax/teleint.c|  4 +---
 drivers/isdn/hisax/w6692.c  |  5 ++---
 drivers/isdn/i4l/isdn_ppp.c |  5 ++---
 drivers/isdn/i4l/isdn_tty.c |  5 ++---
 drivers/isdn/mISDN/dsp_core.c   |  4 +---
 drivers/isdn/mISDN/fsm.c|  4 +---
 drivers/isdn/mISDN/l1oip_core.c |  4 +---
 30 files changed, 54 insertions(+), 114 deletions(-)

diff --git a/drivers/isdn/divert/isdn_divert.c 
b/drivers/isdn/divert/isdn_divert.c
index 50749a7..060d357 100644
--- a/drivers/isdn/divert/isdn_divert.c
+++ b/drivers/isdn/divert/isdn_divert.c
@@ -157,10 +157,8 @@ int cf_command(int drvid, int mode,
/* allocate mem for information struct */
if (!(cs = kmalloc(sizeof(struct call_struc), GFP_ATOMIC)))
return (-ENOMEM); /* no memory */
-   init_timer(>timer);
+   setup_timer(>timer, deflect_timer_expire, (ulong)cs);
cs->info[0] = '\0';
-   cs->timer.function = deflect_timer_expire;
-   cs->timer.data = (ulong) cs; /* pointer to own structure */
cs->ics.driver = drvid;
cs->ics.command = ISDN_CMD_PROT_IO; /* protocol specific io */
cs->ics.arg = DSS1_CMD_INVOKE; /* invoke supplementary service */
@@ -452,10 +450,9 @@ static int isdn_divert_icall(isdn_ctrl *ic)
return (0); /* no external deflection 
needed */
if (!(cs = kmalloc(sizeof(struct call_struc), 
GFP_ATOMIC)))
return (0); /* no memory */
-   init_timer(>timer);
+   setup_timer(>timer, deflect_timer_expire,
+   (ulong)cs);
cs->info[0] = '\0';
-   cs->timer.function = deflect_timer_expire;
-   cs->timer.data = (ulong) cs; /* pointer to own 
structure */
 
cs->ics = *ic; /* copy incoming data */
if (!cs->ics.parm.setup.phone[0]) 
strcpy(cs->ics.parm.setup.phone, "0");
diff --git a/drivers/isdn/hardware/eicon/divasi.c 
b/drivers/isdn/hardware/eicon/divasi.c
index cb88090..c610495 100644
--- a/drivers/isdn/hardware/eicon/divasi.c
+++ b/drivers/isdn/hardware/eicon/divasi.c
@@ -300,9 +300,8 @@ static int um_idi_open_adapter(struct file *file, int 
adapter_nr)
p_os = (diva_um_idi_os_context_t *) diva_um_id_get_os_context(e);
init_waitqueue_head(_os->read_wait);
init_waitqueue_head(_os->close_wait);
-   init_timer(_os->diva_timer_id);
-   p_os->diva_timer_id.function = (void *) diva_um_timer_function;
-   p_os->diva_timer_id.data = (unsigned long) p_os;
+   setup_timer(_os->diva_timer_id, (void *)diva_um_timer_function,
+   (unsigned long)p_os);
p_os->aborted = 0;
p_os->adapter_nr = adapter_nr;
return (1);
diff --git a/drivers/isdn/hardware/mISDN/hfcmulti.c 
b/drivers/isdn/hardware/mISDN/hfcmulti.c
index 480c2d7..961c07e 100644
--- a/drivers/isdn/hardware/mISDN/hfcmulti.c
+++ b/drivers/isdn/hardware/mISDN/hfcmulti.c
@@ -3878,9 +3878,8 @@ hfcmulti_initmode(struct dchannel *dch)
if (hc->dnum[pt]) {
mode_hfcmulti(hc, dch->slot, dch->dev.D.protocol,
  -1, 0, -1, 0);
-   dch->timer.function = (void *) hfcmulti_dbusy_timer;
-   dch->timer.data = (long) dch;
-   init_timer(>timer);
+   setup_timer(>timer, (void *)hfcmulti_dbusy_timer,
+   (long)dch);
}
  

[PATCH] isdn: use setup_timer

[Geliang Tang]

Use setup_timer() instead of init_timer() to simplify the code.

Signed-off-by: Geliang Tang 
---
 drivers/isdn/divert/isdn_divert.c   |  9 +++--
 drivers/isdn/hardware/eicon/divasi.c|  5 ++---
 drivers/isdn/hardware/mISDN/hfcmulti.c  | 10 --
 drivers/isdn/hardware/mISDN/hfcpci.c|  9 +++--
 drivers/isdn/hardware/mISDN/mISDNipac.c |  5 ++---
 drivers/isdn/hardware/mISDN/mISDNisar.c | 10 --
 drivers/isdn/hardware/mISDN/w6692.c |  5 ++---
 drivers/isdn/hisax/amd7930_fn.c |  4 +---
 drivers/isdn/hisax/arcofi.c |  4 +---
 drivers/isdn/hisax/diva.c   |  5 ++---
 drivers/isdn/hisax/elsa.c   |  4 +---
 drivers/isdn/hisax/fsm.c|  4 +---
 drivers/isdn/hisax/hfc4s8s_l1.c |  5 ++---
 drivers/isdn/hisax/hfc_2bds0.c  |  4 +---
 drivers/isdn/hisax/hfc_pci.c|  8 ++--
 drivers/isdn/hisax/hfc_sx.c |  8 ++--
 drivers/isdn/hisax/hfc_usb.c|  8 ++--
 drivers/isdn/hisax/hfcscard.c   |  4 +---
 drivers/isdn/hisax/icc.c|  4 +---
 drivers/isdn/hisax/ipacx.c  |  4 +---
 drivers/isdn/hisax/isac.c   |  4 +---
 drivers/isdn/hisax/isar.c   | 10 --
 drivers/isdn/hisax/isdnl3.c |  4 +---
 drivers/isdn/hisax/teleint.c|  4 +---
 drivers/isdn/hisax/w6692.c  |  5 ++---
 drivers/isdn/i4l/isdn_ppp.c |  5 ++---
 drivers/isdn/i4l/isdn_tty.c |  5 ++---
 drivers/isdn/mISDN/dsp_core.c   |  4 +---
 drivers/isdn/mISDN/fsm.c|  4 +---
 drivers/isdn/mISDN/l1oip_core.c |  4 +---
 30 files changed, 54 insertions(+), 114 deletions(-)

diff --git a/drivers/isdn/divert/isdn_divert.c 
b/drivers/isdn/divert/isdn_divert.c
index 50749a7..060d357 100644
--- a/drivers/isdn/divert/isdn_divert.c
+++ b/drivers/isdn/divert/isdn_divert.c
@@ -157,10 +157,8 @@ int cf_command(int drvid, int mode,
/* allocate mem for information struct */
if (!(cs = kmalloc(sizeof(struct call_struc), GFP_ATOMIC)))
return (-ENOMEM); /* no memory */
-   init_timer(>timer);
+   setup_timer(>timer, deflect_timer_expire, (ulong)cs);
cs->info[0] = '\0';
-   cs->timer.function = deflect_timer_expire;
-   cs->timer.data = (ulong) cs; /* pointer to own structure */
cs->ics.driver = drvid;
cs->ics.command = ISDN_CMD_PROT_IO; /* protocol specific io */
cs->ics.arg = DSS1_CMD_INVOKE; /* invoke supplementary service */
@@ -452,10 +450,9 @@ static int isdn_divert_icall(isdn_ctrl *ic)
return (0); /* no external deflection 
needed */
if (!(cs = kmalloc(sizeof(struct call_struc), 
GFP_ATOMIC)))
return (0); /* no memory */
-   init_timer(>timer);
+   setup_timer(>timer, deflect_timer_expire,
+   (ulong)cs);
cs->info[0] = '\0';
-   cs->timer.function = deflect_timer_expire;
-   cs->timer.data = (ulong) cs; /* pointer to own 
structure */
 
cs->ics = *ic; /* copy incoming data */
if (!cs->ics.parm.setup.phone[0]) 
strcpy(cs->ics.parm.setup.phone, "0");
diff --git a/drivers/isdn/hardware/eicon/divasi.c 
b/drivers/isdn/hardware/eicon/divasi.c
index cb88090..c610495 100644
--- a/drivers/isdn/hardware/eicon/divasi.c
+++ b/drivers/isdn/hardware/eicon/divasi.c
@@ -300,9 +300,8 @@ static int um_idi_open_adapter(struct file *file, int 
adapter_nr)
p_os = (diva_um_idi_os_context_t *) diva_um_id_get_os_context(e);
init_waitqueue_head(_os->read_wait);
init_waitqueue_head(_os->close_wait);
-   init_timer(_os->diva_timer_id);
-   p_os->diva_timer_id.function = (void *) diva_um_timer_function;
-   p_os->diva_timer_id.data = (unsigned long) p_os;
+   setup_timer(_os->diva_timer_id, (void *)diva_um_timer_function,
+   (unsigned long)p_os);
p_os->aborted = 0;
p_os->adapter_nr = adapter_nr;
return (1);
diff --git a/drivers/isdn/hardware/mISDN/hfcmulti.c 
b/drivers/isdn/hardware/mISDN/hfcmulti.c
index 480c2d7..961c07e 100644
--- a/drivers/isdn/hardware/mISDN/hfcmulti.c
+++ b/drivers/isdn/hardware/mISDN/hfcmulti.c
@@ -3878,9 +3878,8 @@ hfcmulti_initmode(struct dchannel *dch)
if (hc->dnum[pt]) {
mode_hfcmulti(hc, dch->slot, dch->dev.D.protocol,
  -1, 0, -1, 0);
-   dch->timer.function = (void *) hfcmulti_dbusy_timer;
-   dch->timer.data = (long) dch;
-   init_timer(>timer);
+   setup_timer(>timer, (void *)hfcmulti_dbusy_timer,
+   (long)dch);
}
for (i = 1; i <= 31; 

[PATCH] pstore: remove unused vmalloc.h in pmsg

[Geliang Tang]

Since the vmalloc code has been removed from write_pmsg() in the commit
"5bf6d1b pstore/pmsg: drop bounce buffer", remove the unused header
vmalloc.h.

Signed-off-by: Geliang Tang 
---
 fs/pstore/pmsg.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/fs/pstore/pmsg.c b/fs/pstore/pmsg.c
index c16a247..209755e 100644
--- a/fs/pstore/pmsg.c
+++ b/fs/pstore/pmsg.c
@@ -15,7 +15,6 @@
 #include 
 #include 
 #include 
-#include 
 #include "internal.h"
 
 static DEFINE_MUTEX(pmsg_lock);
-- 
2.9.3

[PATCH] pstore: remove unused vmalloc.h in pmsg

[Geliang Tang]

Since the vmalloc code has been removed from write_pmsg() in the commit
"5bf6d1b pstore/pmsg: drop bounce buffer", remove the unused header
vmalloc.h.

Signed-off-by: Geliang Tang 
---
 fs/pstore/pmsg.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/fs/pstore/pmsg.c b/fs/pstore/pmsg.c
index c16a247..209755e 100644
--- a/fs/pstore/pmsg.c
+++ b/fs/pstore/pmsg.c
@@ -15,7 +15,6 @@
 #include 
 #include 
 #include 
-#include 
 #include "internal.h"
 
 static DEFINE_MUTEX(pmsg_lock);
-- 
2.9.3

Re: [PATCH v1] mfd: core: Preserve PLATFORM_DEVID_NONE

[Andy Shevchenko]

On Thu, 2017-03-23 at 11:21 +, Lee Jones wrote:
> On Thu, 16 Mar 2017, Andy Shevchenko wrote:
> 
> > There is a potential flaw if cell has id > 0 and is going to be
> > registered with PLATFORM_DEVID_NONE.
> > 
> > Ignore if PLATFORM_DEVID_NONE is supplied.
> 
> This is a substantial change to a pretty tried and tested piece of
> sub-system code.  Can you put some more meat on the bones in the
> commit log, and include examples.

Example in pseudo code:

cells = {
 [0] = { .id = 0, .name = "moduleX", },
 [1] = { .id = 1, .name = "moduleY", },
 [2] = { .id = 2, .name = "moduleZ", },
 ...
};

mfd_add_devices(..., PLATFORM_DEVID_NONE, cells, ARRAY_SIZE(cells),
...);

Output (names of the devices in the drivers):
"moduleX"
"moduleY.0"
"moduleX.1"

Desired output:
"moduleX"
"moduleY"
"moduleZ"

Is it by design?

> 
> > Signed-off-by: Andy Shevchenko 
> > ---
> >  drivers/mfd/mfd-core.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/drivers/mfd/mfd-core.c b/drivers/mfd/mfd-core.c
> > index c57e407020f1..c9583f895058 100644
> > --- a/drivers/mfd/mfd-core.c
> > +++ b/drivers/mfd/mfd-core.c
> > @@ -149,7 +149,7 @@ static int mfd_add_device(struct device *parent,
> > int id,
> >     int platform_id;
> >     int r;
> >  
> > -   if (id == PLATFORM_DEVID_AUTO)
> > +   if (id < 0)
> >     platform_id = id;
> >     else
> >     platform_id = id + cell->id;
> 
> 

-- 
Andy Shevchenko 
Intel Finland Oy

Re: [PATCH v1] mfd: core: Preserve PLATFORM_DEVID_NONE

[Andy Shevchenko]

On Thu, 2017-03-23 at 11:21 +, Lee Jones wrote:
> On Thu, 16 Mar 2017, Andy Shevchenko wrote:
> 
> > There is a potential flaw if cell has id > 0 and is going to be
> > registered with PLATFORM_DEVID_NONE.
> > 
> > Ignore if PLATFORM_DEVID_NONE is supplied.
> 
> This is a substantial change to a pretty tried and tested piece of
> sub-system code.  Can you put some more meat on the bones in the
> commit log, and include examples.

Example in pseudo code:

cells = {
 [0] = { .id = 0, .name = "moduleX", },
 [1] = { .id = 1, .name = "moduleY", },
 [2] = { .id = 2, .name = "moduleZ", },
 ...
};

mfd_add_devices(..., PLATFORM_DEVID_NONE, cells, ARRAY_SIZE(cells),
...);

Output (names of the devices in the drivers):
"moduleX"
"moduleY.0"
"moduleX.1"

Desired output:
"moduleX"
"moduleY"
"moduleZ"

Is it by design?

> 
> > Signed-off-by: Andy Shevchenko 
> > ---
> >  drivers/mfd/mfd-core.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/drivers/mfd/mfd-core.c b/drivers/mfd/mfd-core.c
> > index c57e407020f1..c9583f895058 100644
> > --- a/drivers/mfd/mfd-core.c
> > +++ b/drivers/mfd/mfd-core.c
> > @@ -149,7 +149,7 @@ static int mfd_add_device(struct device *parent,
> > int id,
> >     int platform_id;
> >     int r;
> >  
> > -   if (id == PLATFORM_DEVID_AUTO)
> > +   if (id < 0)
> >     platform_id = id;
> >     else
> >     platform_id = id + cell->id;
> 
> 

-- 
Andy Shevchenko 
Intel Finland Oy

[PATCH] staging: media: atomisp: use kvmalloc and kvfree

[Geliang Tang]

Use kvmalloc() and kvfree() instead of open-coding.

Signed-off-by: Geliang Tang 
---
 drivers/staging/media/atomisp/pci/atomisp2/atomisp_cmd.c | 10 ++
 1 file changed, 2 insertions(+), 8 deletions(-)

diff --git a/drivers/staging/media/atomisp/pci/atomisp2/atomisp_cmd.c 
b/drivers/staging/media/atomisp/pci/atomisp2/atomisp_cmd.c
index 94bc793..c7b9320 100644
--- a/drivers/staging/media/atomisp/pci/atomisp2/atomisp_cmd.c
+++ b/drivers/staging/media/atomisp/pci/atomisp2/atomisp_cmd.c
@@ -90,10 +90,7 @@ union host {
 void *atomisp_kernel_malloc(size_t bytes)
 {
/* vmalloc() is preferable if allocating more than 1 page */
-   if (bytes > PAGE_SIZE)
-   return vmalloc(bytes);
-
-   return kmalloc(bytes, GFP_KERNEL);
+   return kvmalloc(bytes, GFP_KERNEL);
 }
 
 /*
@@ -118,10 +115,7 @@ void *atomisp_kernel_zalloc(size_t bytes, bool zero_mem)
 void atomisp_kernel_free(void *ptr)
 {
/* Verify if buffer was allocated by vmalloc() or kmalloc() */
-   if (is_vmalloc_addr(ptr))
-   vfree(ptr);
-   else
-   kfree(ptr);
+   kvfree(ptr);
 }
 
 /*
-- 
2.9.3

[PATCH] staging: media: atomisp: use kvmalloc and kvfree

[Geliang Tang]

Use kvmalloc() and kvfree() instead of open-coding.

Signed-off-by: Geliang Tang 
---
 drivers/staging/media/atomisp/pci/atomisp2/atomisp_cmd.c | 10 ++
 1 file changed, 2 insertions(+), 8 deletions(-)

diff --git a/drivers/staging/media/atomisp/pci/atomisp2/atomisp_cmd.c 
b/drivers/staging/media/atomisp/pci/atomisp2/atomisp_cmd.c
index 94bc793..c7b9320 100644
--- a/drivers/staging/media/atomisp/pci/atomisp2/atomisp_cmd.c
+++ b/drivers/staging/media/atomisp/pci/atomisp2/atomisp_cmd.c
@@ -90,10 +90,7 @@ union host {
 void *atomisp_kernel_malloc(size_t bytes)
 {
/* vmalloc() is preferable if allocating more than 1 page */
-   if (bytes > PAGE_SIZE)
-   return vmalloc(bytes);
-
-   return kmalloc(bytes, GFP_KERNEL);
+   return kvmalloc(bytes, GFP_KERNEL);
 }
 
 /*
@@ -118,10 +115,7 @@ void *atomisp_kernel_zalloc(size_t bytes, bool zero_mem)
 void atomisp_kernel_free(void *ptr)
 {
/* Verify if buffer was allocated by vmalloc() or kmalloc() */
-   if (is_vmalloc_addr(ptr))
-   vfree(ptr);
-   else
-   kfree(ptr);
+   kvfree(ptr);
 }
 
 /*
-- 
2.9.3

[PATCH] staging: media: atomisp: fix build error

[Geliang Tang]

Fix the following build error:

  CC  drivers/staging/media/atomisp/pci/atomisp2/hmm/hmm.o
drivers/staging/media/atomisp/pci/atomisp2/hmm/hmm.c:52:2:
 error: excess elements in array initializer [-Werror]
  "i", /* ion */
  ^~~
drivers/staging/media/atomisp/pci/atomisp2/hmm/hmm.c:52:2:
 note: (near initialization for ‘hmm_bo_type_strings’)
cc1: all warnings being treated as errors
scripts/Makefile.build:294: recipe for target
'drivers/staging/media/atomisp/pci/atomisp2/hmm/hmm.o' failed

Signed-off-by: Geliang Tang 
---
 drivers/staging/media/atomisp/pci/atomisp2/hmm/hmm.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/staging/media/atomisp/pci/atomisp2/hmm/hmm.c 
b/drivers/staging/media/atomisp/pci/atomisp2/hmm/hmm.c
index a362b49..e78f02f 100644
--- a/drivers/staging/media/atomisp/pci/atomisp2/hmm/hmm.c
+++ b/drivers/staging/media/atomisp/pci/atomisp2/hmm/hmm.c
@@ -49,7 +49,9 @@ const char *hmm_bo_type_strings[HMM_BO_LAST] = {
"p", /* private */
"s", /* shared */
"u", /* user */
+#ifdef CONFIG_ION
"i", /* ion */
+#endif
 };
 
 static ssize_t bo_show(struct device *dev, struct device_attribute *attr,
-- 
2.9.3

[PATCH] staging: media: atomisp: fix build error

[Geliang Tang]

Fix the following build error:

  CC  drivers/staging/media/atomisp/pci/atomisp2/hmm/hmm.o
drivers/staging/media/atomisp/pci/atomisp2/hmm/hmm.c:52:2:
 error: excess elements in array initializer [-Werror]
  "i", /* ion */
  ^~~
drivers/staging/media/atomisp/pci/atomisp2/hmm/hmm.c:52:2:
 note: (near initialization for ‘hmm_bo_type_strings’)
cc1: all warnings being treated as errors
scripts/Makefile.build:294: recipe for target
'drivers/staging/media/atomisp/pci/atomisp2/hmm/hmm.o' failed

Signed-off-by: Geliang Tang 
---
 drivers/staging/media/atomisp/pci/atomisp2/hmm/hmm.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/staging/media/atomisp/pci/atomisp2/hmm/hmm.c 
b/drivers/staging/media/atomisp/pci/atomisp2/hmm/hmm.c
index a362b49..e78f02f 100644
--- a/drivers/staging/media/atomisp/pci/atomisp2/hmm/hmm.c
+++ b/drivers/staging/media/atomisp/pci/atomisp2/hmm/hmm.c
@@ -49,7 +49,9 @@ const char *hmm_bo_type_strings[HMM_BO_LAST] = {
"p", /* private */
"s", /* shared */
"u", /* user */
+#ifdef CONFIG_ION
"i", /* ion */
+#endif
 };
 
 static ssize_t bo_show(struct device *dev, struct device_attribute *attr,
-- 
2.9.3

Re: [PATCH 1/5] w83627ehf: Use hwmon_device_register_with_info and sensor groups

[Guenter Roeck]

On 03/23/2017 06:05 AM, Peter Hüwe wrote:

This is of course v2 of the series
Forgot to add it to git-send-email, sorry.
Shall I resend with v2 in subject?



No, it's ok. At least you have a change log :-).

Thanks,
Guenter

Re: [PATCH 1/5] w83627ehf: Use hwmon_device_register_with_info and sensor groups

[Guenter Roeck]

On 03/23/2017 06:05 AM, Peter Hüwe wrote:

This is of course v2 of the series
Forgot to add it to git-send-email, sorry.
Shall I resend with v2 in subject?



No, it's ok. At least you have a change log :-).

Thanks,
Guenter

Re: [PATCH V1] mmc: core: fix still flush cache when eMMC cache off

[Ulf Hansson]

On 23 March 2017 at 11:45, Bean Huo (beanhuo)  wrote:
> Hi,
>
>>On 19 March 2017 at 01:45, Bean Huo (beanhuo)  wrote:
>>> This patch fixes the issue that mmc_blk_issue_rq still flushes cache
>>> when eMMC cache has already been off through user space tool, such as
>>> mmc-utils.
>>> The reason is that card->ext_csd.cache_ctrl isn't reset.
>>
>>First, why do you want to turn of the cache ctrl? Is the eMMC device having
>>issues with it? Then we should invent a card quirk instead.
>
>
> Why I turn off it? because I did power loss testing and validation, I should 
> switch it off and on.
> When I do some performance and power loss case validation on several Linux 
> release versions,
> I need to switch off or on cache through user space tool.
> I can't confirm every user that likes me, But I think at least it is not 
> reasonable to
> flush eMMC cache, when internal eMMC cache is off.

Ah, I see. Your use-case seems reasonable while validating robustness
of the eMMC!

>
>>Second, what errors do you encounter when the mmc core tries to flush the
>>cache when it has been turned off? Can you please elaborate on this?
>
>
> No error found, but firstly, please think about overhead introduced by 
> useless flush cache, Unless you
> Don't care this tiny time. second, under the condition of cache off, 
> additional flush cache request still has impact on
> Internal eMMC logic. I don't know What and how impact, but at least it is 
> really exist.

Got it!

However I still don't like the mmc ioctls API to compensate and deal
with all "crazy-ness" that user-space may cause. Cache-ctrl is only
one case out of many.

I see two viable options to solve your problem.
1) Extend mmc_test with a new test(s) for cache ctrl and perhaps
suspend/resume. Isn't this actually exactly what you want?
2) Extend debugfs to be able to turn cache ctrl on/off.

[...]

Kind regards
Uffe

Re: [PATCH V1] mmc: core: fix still flush cache when eMMC cache off

[Ulf Hansson]

On 23 March 2017 at 11:45, Bean Huo (beanhuo)  wrote:
> Hi,
>
>>On 19 March 2017 at 01:45, Bean Huo (beanhuo)  wrote:
>>> This patch fixes the issue that mmc_blk_issue_rq still flushes cache
>>> when eMMC cache has already been off through user space tool, such as
>>> mmc-utils.
>>> The reason is that card->ext_csd.cache_ctrl isn't reset.
>>
>>First, why do you want to turn of the cache ctrl? Is the eMMC device having
>>issues with it? Then we should invent a card quirk instead.
>
>
> Why I turn off it? because I did power loss testing and validation, I should 
> switch it off and on.
> When I do some performance and power loss case validation on several Linux 
> release versions,
> I need to switch off or on cache through user space tool.
> I can't confirm every user that likes me, But I think at least it is not 
> reasonable to
> flush eMMC cache, when internal eMMC cache is off.

Ah, I see. Your use-case seems reasonable while validating robustness
of the eMMC!

>
>>Second, what errors do you encounter when the mmc core tries to flush the
>>cache when it has been turned off? Can you please elaborate on this?
>
>
> No error found, but firstly, please think about overhead introduced by 
> useless flush cache, Unless you
> Don't care this tiny time. second, under the condition of cache off, 
> additional flush cache request still has impact on
> Internal eMMC logic. I don't know What and how impact, but at least it is 
> really exist.

Got it!

However I still don't like the mmc ioctls API to compensate and deal
with all "crazy-ness" that user-space may cause. Cache-ctrl is only
one case out of many.

I see two viable options to solve your problem.
1) Extend mmc_test with a new test(s) for cache ctrl and perhaps
suspend/resume. Isn't this actually exactly what you want?
2) Extend debugfs to be able to turn cache ctrl on/off.

[...]

Kind regards
Uffe

Re: [PATCH v5 08/13] powerpc/perf: PMU functions for Core IMC and hotplugging

[Gautham R Shenoy]

Hi Maddy, Hemant, Anju,

On Thu, Mar 16, 2017 at 01:05:02PM +0530, Madhavan Srinivasan wrote:

[..snip..]

> +
> +static void core_imc_change_cpu_context(int old_cpu, int new_cpu)
> +{
> + if (!core_imc_pmu)
> + return;
> + perf_pmu_migrate_context(_imc_pmu->pmu, old_cpu, new_cpu);
> +}
> +
> +
> +static int ppc_core_imc_cpu_online(unsigned int cpu)
> +{
> + int ret;
> +
> + /* If a cpu for this core is already set, then, don't do anything */
> + ret = cpumask_any_and(_imc_cpumask,
> +  cpu_sibling_mask(cpu));
> + if (ret < nr_cpu_ids)
> + return 0;
> +
> + /* Else, set the cpu in the mask, and change the context */
> + cpumask_set_cpu(cpu, _imc_cpumask);
> + core_imc_change_cpu_context(-1, cpu);

So, in the core case, we are ok as long as any cpu in the core is
present in the imc_cpumask. It need not have to be the smallest online
cpu in the core.

Can the same logic be applied to the earlier nest case ?

We can have a single function for cpu_offline and cpu_online which
implements these checks and sets the cpu bit if required.

ppc_entity_imc_cpu_offline(unsigned int cpu, cpumask_t
   entity_imc_mask,
   entity_imc_change_cpu_context_fn)
{
.
.
.

}


static ppc_nest_imc_cpu_offline(unsigned int cpu)
{
return ppc_entity_imc_cpu_offline(cpu, nest_imc_mask,
  nest_imc_change_cpu_context);
}

And similar ones for core imc and thread imc.

Does this sound reasonable ?

> + return 0;
> +}
> +
> +static int ppc_core_imc_cpu_offline(unsigned int cpu)
> +{
> + int target;
> + unsigned int ncpu;
> +
> + /*
> +  * clear this cpu out of the mask, if not present in the mask,
> +  * don't bother doing anything.
> +  */
> + if (!cpumask_test_and_clear_cpu(cpu, _imc_cpumask))
> + return 0;
> +
> + /* Find any online cpu in that core except the current "cpu" */
> + ncpu = cpumask_any_but(cpu_sibling_mask(cpu), cpu);
> +
> + if (ncpu < nr_cpu_ids) {
> + target = ncpu;
> + cpumask_set_cpu(target, _imc_cpumask);
> + } else
> + target = -1;
> +
> + /* migrate the context */
> + core_imc_change_cpu_context(cpu, target);
> +
> + return 0;
> +}
> +

--
Thanks and Regards
gautham.

Re: [PATCH v5 08/13] powerpc/perf: PMU functions for Core IMC and hotplugging

[Gautham R Shenoy]

Hi Maddy, Hemant, Anju,

On Thu, Mar 16, 2017 at 01:05:02PM +0530, Madhavan Srinivasan wrote:

[..snip..]

> +
> +static void core_imc_change_cpu_context(int old_cpu, int new_cpu)
> +{
> + if (!core_imc_pmu)
> + return;
> + perf_pmu_migrate_context(_imc_pmu->pmu, old_cpu, new_cpu);
> +}
> +
> +
> +static int ppc_core_imc_cpu_online(unsigned int cpu)
> +{
> + int ret;
> +
> + /* If a cpu for this core is already set, then, don't do anything */
> + ret = cpumask_any_and(_imc_cpumask,
> +  cpu_sibling_mask(cpu));
> + if (ret < nr_cpu_ids)
> + return 0;
> +
> + /* Else, set the cpu in the mask, and change the context */
> + cpumask_set_cpu(cpu, _imc_cpumask);
> + core_imc_change_cpu_context(-1, cpu);

So, in the core case, we are ok as long as any cpu in the core is
present in the imc_cpumask. It need not have to be the smallest online
cpu in the core.

Can the same logic be applied to the earlier nest case ?

We can have a single function for cpu_offline and cpu_online which
implements these checks and sets the cpu bit if required.

ppc_entity_imc_cpu_offline(unsigned int cpu, cpumask_t
   entity_imc_mask,
   entity_imc_change_cpu_context_fn)
{
.
.
.

}


static ppc_nest_imc_cpu_offline(unsigned int cpu)
{
return ppc_entity_imc_cpu_offline(cpu, nest_imc_mask,
  nest_imc_change_cpu_context);
}

And similar ones for core imc and thread imc.

Does this sound reasonable ?

> + return 0;
> +}
> +
> +static int ppc_core_imc_cpu_offline(unsigned int cpu)
> +{
> + int target;
> + unsigned int ncpu;
> +
> + /*
> +  * clear this cpu out of the mask, if not present in the mask,
> +  * don't bother doing anything.
> +  */
> + if (!cpumask_test_and_clear_cpu(cpu, _imc_cpumask))
> + return 0;
> +
> + /* Find any online cpu in that core except the current "cpu" */
> + ncpu = cpumask_any_but(cpu_sibling_mask(cpu), cpu);
> +
> + if (ncpu < nr_cpu_ids) {
> + target = ncpu;
> + cpumask_set_cpu(target, _imc_cpumask);
> + } else
> + target = -1;
> +
> + /* migrate the context */
> + core_imc_change_cpu_context(cpu, target);
> +
> + return 0;
> +}
> +

--
Thanks and Regards
gautham.

Re: security, hugetlbfs: write to user memory in hugetlbfs_destroy_inode

[Dmitry Vyukov]

On Thu, Mar 23, 2017 at 2:06 PM, Dmitry Vyukov  wrote:
> Hello,
>
> I've got the following report while running syzkaller fuzzer on
> 093b995e3b55a0ae0670226ddfcb05bfbf0099ae. Note the preceding injected
> kmalloc failure in inode_alloc_security, most likely it's the root
> cause.
>
>
> FAULT_INJECTION: forcing a failure.
> name failslab, interval 1, probability 0, space 0, times 0
> CPU: 3 PID: 14086 Comm: syz-executor6 Not tainted 4.11.0-rc3+ #364
> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
> Call Trace:
>  __dump_stack lib/dump_stack.c:16 [inline]
>  dump_stack+0x1b8/0x28d lib/dump_stack.c:52
>  fail_dump lib/fault-inject.c:45 [inline]
>  should_fail+0x78a/0x870 lib/fault-inject.c:154
>  should_failslab+0xec/0x120 mm/failslab.c:31
>  slab_pre_alloc_hook mm/slab.h:434 [inline]
>  slab_alloc mm/slab.c:3394 [inline]
>  kmem_cache_alloc+0x200/0x720 mm/slab.c:3570
>  kmem_cache_zalloc include/linux/slab.h:653 [inline]
>  inode_alloc_security security/selinux/hooks.c:221 [inline]
>  selinux_inode_alloc_security+0xf9/0x390 security/selinux/hooks.c:2833
>  security_inode_alloc+0x90/0xd0 security/security.c:387
>  inode_init_always+0x5af/0xc20 fs/inode.c:166
>  alloc_inode+0x82/0x180 fs/inode.c:214
>  new_inode_pseudo+0x69/0x190 fs/inode.c:889
>  new_inode+0x1c/0x40 fs/inode.c:918
>  hugetlbfs_get_inode+0x40/0x420 fs/hugetlbfs/inode.c:734
>  hugetlb_file_setup+0x329/0x9f0 fs/hugetlbfs/inode.c:1282
>  newseg+0x422/0xd30 ipc/shm.c:575
>  ipcget_new ipc/util.c:285 [inline]
>  ipcget+0x21e/0x580 ipc/util.c:639
>  SYSC_shmget ipc/shm.c:673 [inline]
>  SyS_shmget+0x158/0x230 ipc/shm.c:657
>  entry_SYSCALL_64_fastpath+0x1f/0xc2
> RIP: 0033:0x445b79
> RSP: 002b:7f9dcc5df858 EFLAGS: 0282 ORIG_RAX: 001d
> RAX: ffda RBX: 00708000 RCX: 00445b79
> RDX: 0800 RSI: 3000 RDI: 
> RBP: 0086 R08:  R09: 
> R10: 20207000 R11: 0282 R12: 004a7e31
> R13:  R14: 7f9dcc5df618 R15: 7f9dcc5df788
> ==
> BUG: KASAN: user-memory-access in atomic_inc
> include/asm-generic/atomic-instrumented.h:87 [inline] at addr
> 00131730bd7a
> BUG: KASAN: user-memory-access in __lock_acquire+0x21a/0x3a80
> kernel/locking/lockdep.c:3239 at addr 00131730bd7a
> Write of size 4 by task syz-executor6/14086
> CPU: 3 PID: 14086 Comm: syz-executor6 Not tainted 4.11.0-rc3+ #364
> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
> Call Trace:
>  __dump_stack lib/dump_stack.c:16 [inline]
>  dump_stack+0x1b8/0x28d lib/dump_stack.c:52
>  kasan_report_error mm/kasan/report.c:291 [inline]
>  kasan_report.part.2+0x34a/0x480 mm/kasan/report.c:316
>  kasan_report+0x21/0x30 mm/kasan/report.c:303
>  check_memory_region_inline mm/kasan/kasan.c:326 [inline]
>  check_memory_region+0x137/0x190 mm/kasan/kasan.c:333
>  kasan_check_write+0x14/0x20 mm/kasan/kasan.c:344
>  atomic_inc include/asm-generic/atomic-instrumented.h:87 [inline]
>  __lock_acquire+0x21a/0x3a80 kernel/locking/lockdep.c:3239
>  lock_acquire+0x1ee/0x590 kernel/locking/lockdep.c:3762
>  __raw_write_lock include/linux/rwlock_api_smp.h:210 [inline]
>  _raw_write_lock+0x33/0x50 kernel/locking/spinlock.c:295
>  mpol_free_shared_policy+0x43/0xb0 mm/mempolicy.c:2536
>  hugetlbfs_destroy_inode+0xca/0x120 fs/hugetlbfs/inode.c:952
>  alloc_inode+0x10d/0x180 fs/inode.c:216
>  new_inode_pseudo+0x69/0x190 fs/inode.c:889
>  new_inode+0x1c/0x40 fs/inode.c:918
>  hugetlbfs_get_inode+0x40/0x420 fs/hugetlbfs/inode.c:734
>  hugetlb_file_setup+0x329/0x9f0 fs/hugetlbfs/inode.c:1282
>  newseg+0x422/0xd30 ipc/shm.c:575
>  ipcget_new ipc/util.c:285 [inline]
>  ipcget+0x21e/0x580 ipc/util.c:639
>  SYSC_shmget ipc/shm.c:673 [inline]
>  SyS_shmget+0x158/0x230 ipc/shm.c:657
>  entry_SYSCALL_64_fastpath+0x1f/0xc2
> RIP: 0033:0x445b79
> RSP: 002b:7f9dcc5df858 EFLAGS: 0282 ORIG_RAX: 001d
> RAX: ffda RBX: 00708000 RCX: 00445b79
> RDX: 0800 RSI: 3000 RDI: 
> RBP: 0086 R08:  R09: 
> R10: 20207000 R11: 0282 R12: 004a7e31
> R13:  R14: 7f9dcc5df618 R15: 7f9dcc5df788
> ==


Similar on address 0x2d302e31312e35c7, looks like uninit.

==
BUG: KASAN: wild-memory-access in atomic_inc
include/asm-generic/atomic-instrumented.h:87 [inline] at addr
2d302e31312e35c7
BUG: KASAN: wild-memory-access in __lock_acquire+0x21a/0x3a80
kernel/locking/lockdep.c:3239 at addr 2d302e31312e35c7
Write of size 4 by task syz-executor1/9446
CPU: 1 PID: 9446 Comm: syz-executor1 Not tainted 4.11.0-rc3+ #364
Hardware name: QEMU Standard PC 

Re: security, hugetlbfs: write to user memory in hugetlbfs_destroy_inode

[Dmitry Vyukov]

On Thu, Mar 23, 2017 at 2:06 PM, Dmitry Vyukov  wrote:
> Hello,
>
> I've got the following report while running syzkaller fuzzer on
> 093b995e3b55a0ae0670226ddfcb05bfbf0099ae. Note the preceding injected
> kmalloc failure in inode_alloc_security, most likely it's the root
> cause.
>
>
> FAULT_INJECTION: forcing a failure.
> name failslab, interval 1, probability 0, space 0, times 0
> CPU: 3 PID: 14086 Comm: syz-executor6 Not tainted 4.11.0-rc3+ #364
> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
> Call Trace:
>  __dump_stack lib/dump_stack.c:16 [inline]
>  dump_stack+0x1b8/0x28d lib/dump_stack.c:52
>  fail_dump lib/fault-inject.c:45 [inline]
>  should_fail+0x78a/0x870 lib/fault-inject.c:154
>  should_failslab+0xec/0x120 mm/failslab.c:31
>  slab_pre_alloc_hook mm/slab.h:434 [inline]
>  slab_alloc mm/slab.c:3394 [inline]
>  kmem_cache_alloc+0x200/0x720 mm/slab.c:3570
>  kmem_cache_zalloc include/linux/slab.h:653 [inline]
>  inode_alloc_security security/selinux/hooks.c:221 [inline]
>  selinux_inode_alloc_security+0xf9/0x390 security/selinux/hooks.c:2833
>  security_inode_alloc+0x90/0xd0 security/security.c:387
>  inode_init_always+0x5af/0xc20 fs/inode.c:166
>  alloc_inode+0x82/0x180 fs/inode.c:214
>  new_inode_pseudo+0x69/0x190 fs/inode.c:889
>  new_inode+0x1c/0x40 fs/inode.c:918
>  hugetlbfs_get_inode+0x40/0x420 fs/hugetlbfs/inode.c:734
>  hugetlb_file_setup+0x329/0x9f0 fs/hugetlbfs/inode.c:1282
>  newseg+0x422/0xd30 ipc/shm.c:575
>  ipcget_new ipc/util.c:285 [inline]
>  ipcget+0x21e/0x580 ipc/util.c:639
>  SYSC_shmget ipc/shm.c:673 [inline]
>  SyS_shmget+0x158/0x230 ipc/shm.c:657
>  entry_SYSCALL_64_fastpath+0x1f/0xc2
> RIP: 0033:0x445b79
> RSP: 002b:7f9dcc5df858 EFLAGS: 0282 ORIG_RAX: 001d
> RAX: ffda RBX: 00708000 RCX: 00445b79
> RDX: 0800 RSI: 3000 RDI: 
> RBP: 0086 R08:  R09: 
> R10: 20207000 R11: 0282 R12: 004a7e31
> R13:  R14: 7f9dcc5df618 R15: 7f9dcc5df788
> ==
> BUG: KASAN: user-memory-access in atomic_inc
> include/asm-generic/atomic-instrumented.h:87 [inline] at addr
> 00131730bd7a
> BUG: KASAN: user-memory-access in __lock_acquire+0x21a/0x3a80
> kernel/locking/lockdep.c:3239 at addr 00131730bd7a
> Write of size 4 by task syz-executor6/14086
> CPU: 3 PID: 14086 Comm: syz-executor6 Not tainted 4.11.0-rc3+ #364
> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
> Call Trace:
>  __dump_stack lib/dump_stack.c:16 [inline]
>  dump_stack+0x1b8/0x28d lib/dump_stack.c:52
>  kasan_report_error mm/kasan/report.c:291 [inline]
>  kasan_report.part.2+0x34a/0x480 mm/kasan/report.c:316
>  kasan_report+0x21/0x30 mm/kasan/report.c:303
>  check_memory_region_inline mm/kasan/kasan.c:326 [inline]
>  check_memory_region+0x137/0x190 mm/kasan/kasan.c:333
>  kasan_check_write+0x14/0x20 mm/kasan/kasan.c:344
>  atomic_inc include/asm-generic/atomic-instrumented.h:87 [inline]
>  __lock_acquire+0x21a/0x3a80 kernel/locking/lockdep.c:3239
>  lock_acquire+0x1ee/0x590 kernel/locking/lockdep.c:3762
>  __raw_write_lock include/linux/rwlock_api_smp.h:210 [inline]
>  _raw_write_lock+0x33/0x50 kernel/locking/spinlock.c:295
>  mpol_free_shared_policy+0x43/0xb0 mm/mempolicy.c:2536
>  hugetlbfs_destroy_inode+0xca/0x120 fs/hugetlbfs/inode.c:952
>  alloc_inode+0x10d/0x180 fs/inode.c:216
>  new_inode_pseudo+0x69/0x190 fs/inode.c:889
>  new_inode+0x1c/0x40 fs/inode.c:918
>  hugetlbfs_get_inode+0x40/0x420 fs/hugetlbfs/inode.c:734
>  hugetlb_file_setup+0x329/0x9f0 fs/hugetlbfs/inode.c:1282
>  newseg+0x422/0xd30 ipc/shm.c:575
>  ipcget_new ipc/util.c:285 [inline]
>  ipcget+0x21e/0x580 ipc/util.c:639
>  SYSC_shmget ipc/shm.c:673 [inline]
>  SyS_shmget+0x158/0x230 ipc/shm.c:657
>  entry_SYSCALL_64_fastpath+0x1f/0xc2
> RIP: 0033:0x445b79
> RSP: 002b:7f9dcc5df858 EFLAGS: 0282 ORIG_RAX: 001d
> RAX: ffda RBX: 00708000 RCX: 00445b79
> RDX: 0800 RSI: 3000 RDI: 
> RBP: 0086 R08:  R09: 
> R10: 20207000 R11: 0282 R12: 004a7e31
> R13:  R14: 7f9dcc5df618 R15: 7f9dcc5df788
> ==


Similar on address 0x2d302e31312e35c7, looks like uninit.

==
BUG: KASAN: wild-memory-access in atomic_inc
include/asm-generic/atomic-instrumented.h:87 [inline] at addr
2d302e31312e35c7
BUG: KASAN: wild-memory-access in __lock_acquire+0x21a/0x3a80
kernel/locking/lockdep.c:3239 at addr 2d302e31312e35c7
Write of size 4 by task syz-executor1/9446
CPU: 1 PID: 9446 Comm: syz-executor1 Not tainted 4.11.0-rc3+ #364
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), 

security, hugetlbfs: write to user memory in hugetlbfs_destroy_inode

[Dmitry Vyukov]

Hello,

I've got the following report while running syzkaller fuzzer on
093b995e3b55a0ae0670226ddfcb05bfbf0099ae. Note the preceding injected
kmalloc failure in inode_alloc_security, most likely it's the root
cause.


FAULT_INJECTION: forcing a failure.
name failslab, interval 1, probability 0, space 0, times 0
CPU: 3 PID: 14086 Comm: syz-executor6 Not tainted 4.11.0-rc3+ #364
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
Call Trace:
 __dump_stack lib/dump_stack.c:16 [inline]
 dump_stack+0x1b8/0x28d lib/dump_stack.c:52
 fail_dump lib/fault-inject.c:45 [inline]
 should_fail+0x78a/0x870 lib/fault-inject.c:154
 should_failslab+0xec/0x120 mm/failslab.c:31
 slab_pre_alloc_hook mm/slab.h:434 [inline]
 slab_alloc mm/slab.c:3394 [inline]
 kmem_cache_alloc+0x200/0x720 mm/slab.c:3570
 kmem_cache_zalloc include/linux/slab.h:653 [inline]
 inode_alloc_security security/selinux/hooks.c:221 [inline]
 selinux_inode_alloc_security+0xf9/0x390 security/selinux/hooks.c:2833
 security_inode_alloc+0x90/0xd0 security/security.c:387
 inode_init_always+0x5af/0xc20 fs/inode.c:166
 alloc_inode+0x82/0x180 fs/inode.c:214
 new_inode_pseudo+0x69/0x190 fs/inode.c:889
 new_inode+0x1c/0x40 fs/inode.c:918
 hugetlbfs_get_inode+0x40/0x420 fs/hugetlbfs/inode.c:734
 hugetlb_file_setup+0x329/0x9f0 fs/hugetlbfs/inode.c:1282
 newseg+0x422/0xd30 ipc/shm.c:575
 ipcget_new ipc/util.c:285 [inline]
 ipcget+0x21e/0x580 ipc/util.c:639
 SYSC_shmget ipc/shm.c:673 [inline]
 SyS_shmget+0x158/0x230 ipc/shm.c:657
 entry_SYSCALL_64_fastpath+0x1f/0xc2
RIP: 0033:0x445b79
RSP: 002b:7f9dcc5df858 EFLAGS: 0282 ORIG_RAX: 001d
RAX: ffda RBX: 00708000 RCX: 00445b79
RDX: 0800 RSI: 3000 RDI: 
RBP: 0086 R08:  R09: 
R10: 20207000 R11: 0282 R12: 004a7e31
R13:  R14: 7f9dcc5df618 R15: 7f9dcc5df788
==
BUG: KASAN: user-memory-access in atomic_inc
include/asm-generic/atomic-instrumented.h:87 [inline] at addr
00131730bd7a
BUG: KASAN: user-memory-access in __lock_acquire+0x21a/0x3a80
kernel/locking/lockdep.c:3239 at addr 00131730bd7a
Write of size 4 by task syz-executor6/14086
CPU: 3 PID: 14086 Comm: syz-executor6 Not tainted 4.11.0-rc3+ #364
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
Call Trace:
 __dump_stack lib/dump_stack.c:16 [inline]
 dump_stack+0x1b8/0x28d lib/dump_stack.c:52
 kasan_report_error mm/kasan/report.c:291 [inline]
 kasan_report.part.2+0x34a/0x480 mm/kasan/report.c:316
 kasan_report+0x21/0x30 mm/kasan/report.c:303
 check_memory_region_inline mm/kasan/kasan.c:326 [inline]
 check_memory_region+0x137/0x190 mm/kasan/kasan.c:333
 kasan_check_write+0x14/0x20 mm/kasan/kasan.c:344
 atomic_inc include/asm-generic/atomic-instrumented.h:87 [inline]
 __lock_acquire+0x21a/0x3a80 kernel/locking/lockdep.c:3239
 lock_acquire+0x1ee/0x590 kernel/locking/lockdep.c:3762
 __raw_write_lock include/linux/rwlock_api_smp.h:210 [inline]
 _raw_write_lock+0x33/0x50 kernel/locking/spinlock.c:295
 mpol_free_shared_policy+0x43/0xb0 mm/mempolicy.c:2536
 hugetlbfs_destroy_inode+0xca/0x120 fs/hugetlbfs/inode.c:952
 alloc_inode+0x10d/0x180 fs/inode.c:216
 new_inode_pseudo+0x69/0x190 fs/inode.c:889
 new_inode+0x1c/0x40 fs/inode.c:918
 hugetlbfs_get_inode+0x40/0x420 fs/hugetlbfs/inode.c:734
 hugetlb_file_setup+0x329/0x9f0 fs/hugetlbfs/inode.c:1282
 newseg+0x422/0xd30 ipc/shm.c:575
 ipcget_new ipc/util.c:285 [inline]
 ipcget+0x21e/0x580 ipc/util.c:639
 SYSC_shmget ipc/shm.c:673 [inline]
 SyS_shmget+0x158/0x230 ipc/shm.c:657
 entry_SYSCALL_64_fastpath+0x1f/0xc2
RIP: 0033:0x445b79
RSP: 002b:7f9dcc5df858 EFLAGS: 0282 ORIG_RAX: 001d
RAX: ffda RBX: 00708000 RCX: 00445b79
RDX: 0800 RSI: 3000 RDI: 
RBP: 0086 R08:  R09: 
R10: 20207000 R11: 0282 R12: 004a7e31
R13:  R14: 7f9dcc5df618 R15: 7f9dcc5df788
==

security, hugetlbfs: write to user memory in hugetlbfs_destroy_inode

[Dmitry Vyukov]

Hello,

I've got the following report while running syzkaller fuzzer on
093b995e3b55a0ae0670226ddfcb05bfbf0099ae. Note the preceding injected
kmalloc failure in inode_alloc_security, most likely it's the root
cause.


FAULT_INJECTION: forcing a failure.
name failslab, interval 1, probability 0, space 0, times 0
CPU: 3 PID: 14086 Comm: syz-executor6 Not tainted 4.11.0-rc3+ #364
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
Call Trace:
 __dump_stack lib/dump_stack.c:16 [inline]
 dump_stack+0x1b8/0x28d lib/dump_stack.c:52
 fail_dump lib/fault-inject.c:45 [inline]
 should_fail+0x78a/0x870 lib/fault-inject.c:154
 should_failslab+0xec/0x120 mm/failslab.c:31
 slab_pre_alloc_hook mm/slab.h:434 [inline]
 slab_alloc mm/slab.c:3394 [inline]
 kmem_cache_alloc+0x200/0x720 mm/slab.c:3570
 kmem_cache_zalloc include/linux/slab.h:653 [inline]
 inode_alloc_security security/selinux/hooks.c:221 [inline]
 selinux_inode_alloc_security+0xf9/0x390 security/selinux/hooks.c:2833
 security_inode_alloc+0x90/0xd0 security/security.c:387
 inode_init_always+0x5af/0xc20 fs/inode.c:166
 alloc_inode+0x82/0x180 fs/inode.c:214
 new_inode_pseudo+0x69/0x190 fs/inode.c:889
 new_inode+0x1c/0x40 fs/inode.c:918
 hugetlbfs_get_inode+0x40/0x420 fs/hugetlbfs/inode.c:734
 hugetlb_file_setup+0x329/0x9f0 fs/hugetlbfs/inode.c:1282
 newseg+0x422/0xd30 ipc/shm.c:575
 ipcget_new ipc/util.c:285 [inline]
 ipcget+0x21e/0x580 ipc/util.c:639
 SYSC_shmget ipc/shm.c:673 [inline]
 SyS_shmget+0x158/0x230 ipc/shm.c:657
 entry_SYSCALL_64_fastpath+0x1f/0xc2
RIP: 0033:0x445b79
RSP: 002b:7f9dcc5df858 EFLAGS: 0282 ORIG_RAX: 001d
RAX: ffda RBX: 00708000 RCX: 00445b79
RDX: 0800 RSI: 3000 RDI: 
RBP: 0086 R08:  R09: 
R10: 20207000 R11: 0282 R12: 004a7e31
R13:  R14: 7f9dcc5df618 R15: 7f9dcc5df788
==
BUG: KASAN: user-memory-access in atomic_inc
include/asm-generic/atomic-instrumented.h:87 [inline] at addr
00131730bd7a
BUG: KASAN: user-memory-access in __lock_acquire+0x21a/0x3a80
kernel/locking/lockdep.c:3239 at addr 00131730bd7a
Write of size 4 by task syz-executor6/14086
CPU: 3 PID: 14086 Comm: syz-executor6 Not tainted 4.11.0-rc3+ #364
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
Call Trace:
 __dump_stack lib/dump_stack.c:16 [inline]
 dump_stack+0x1b8/0x28d lib/dump_stack.c:52
 kasan_report_error mm/kasan/report.c:291 [inline]
 kasan_report.part.2+0x34a/0x480 mm/kasan/report.c:316
 kasan_report+0x21/0x30 mm/kasan/report.c:303
 check_memory_region_inline mm/kasan/kasan.c:326 [inline]
 check_memory_region+0x137/0x190 mm/kasan/kasan.c:333
 kasan_check_write+0x14/0x20 mm/kasan/kasan.c:344
 atomic_inc include/asm-generic/atomic-instrumented.h:87 [inline]
 __lock_acquire+0x21a/0x3a80 kernel/locking/lockdep.c:3239
 lock_acquire+0x1ee/0x590 kernel/locking/lockdep.c:3762
 __raw_write_lock include/linux/rwlock_api_smp.h:210 [inline]
 _raw_write_lock+0x33/0x50 kernel/locking/spinlock.c:295
 mpol_free_shared_policy+0x43/0xb0 mm/mempolicy.c:2536
 hugetlbfs_destroy_inode+0xca/0x120 fs/hugetlbfs/inode.c:952
 alloc_inode+0x10d/0x180 fs/inode.c:216
 new_inode_pseudo+0x69/0x190 fs/inode.c:889
 new_inode+0x1c/0x40 fs/inode.c:918
 hugetlbfs_get_inode+0x40/0x420 fs/hugetlbfs/inode.c:734
 hugetlb_file_setup+0x329/0x9f0 fs/hugetlbfs/inode.c:1282
 newseg+0x422/0xd30 ipc/shm.c:575
 ipcget_new ipc/util.c:285 [inline]
 ipcget+0x21e/0x580 ipc/util.c:639
 SYSC_shmget ipc/shm.c:673 [inline]
 SyS_shmget+0x158/0x230 ipc/shm.c:657
 entry_SYSCALL_64_fastpath+0x1f/0xc2
RIP: 0033:0x445b79
RSP: 002b:7f9dcc5df858 EFLAGS: 0282 ORIG_RAX: 001d
RAX: ffda RBX: 00708000 RCX: 00445b79
RDX: 0800 RSI: 3000 RDI: 
RBP: 0086 R08:  R09: 
R10: 20207000 R11: 0282 R12: 004a7e31
R13:  R14: 7f9dcc5df618 R15: 7f9dcc5df788
==

[RFC PATCH v0.2] PCI: Add support for tango PCIe host bridge

[Mason]

I think this version is ready for review.
It has all the required bits and pieces.
I still have a few questions, embedded as comments in the code.
(Missing are ancillary changes to Kconfig, Makefile)
---
 drivers/pci/host/pcie-tango.c | 350 ++
 1 file changed, 350 insertions(+)
 create mode 100644 drivers/pci/host/pcie-tango.c

diff --git a/drivers/pci/host/pcie-tango.c b/drivers/pci/host/pcie-tango.c
new file mode 100644
index ..b2e6448aed2d
--- /dev/null
+++ b/drivers/pci/host/pcie-tango.c
@@ -0,0 +1,350 @@
+#include 
+#include 
+#include 
+#include 
+
+#define MSI_COUNT 32
+
+struct tango_pcie {
+   void __iomem *mux;
+   void __iomem *msi_status;
+   void __iomem *msi_mask;
+   phys_addr_t msi_doorbell;
+   struct mutex lock; /* lock for updating msi_mask */
+   struct irq_domain *irq_domain;
+   struct irq_domain *msi_domain;
+   int irq;
+};
+
+/*** MSI CONTROLLER SUPPORT ***/
+
+static void tango_msi_isr(struct irq_desc *desc)
+{
+   struct irq_chip *chip = irq_desc_get_chip(desc);
+   struct tango_pcie *pcie;
+   unsigned long status, virq;
+   int pos;
+
+   chained_irq_enter(chip, desc);
+   pcie = irq_desc_get_handler_data(desc);
+
+   status = readl_relaxed(pcie->msi_status);
+   writel_relaxed(status, pcie->msi_status); /* clear IRQs */
+
+   for_each_set_bit(pos, , MSI_COUNT) {
+   virq = irq_find_mapping(pcie->irq_domain, pos);
+   if (virq)
+   generic_handle_irq(virq);
+   else
+   pr_err("Unhandled MSI: %d\n", pos);
+   }
+
+   chained_irq_exit(chip, desc);
+}
+
+static struct irq_chip tango_msi_irq_chip = {
+   .name = "MSI",
+   .irq_mask = pci_msi_mask_irq,
+   .irq_unmask = pci_msi_unmask_irq,
+};
+
+static struct msi_domain_info msi_domain_info = {
+   .flags  = MSI_FLAG_USE_DEF_DOM_OPS | MSI_FLAG_USE_DEF_CHIP_OPS,
+   .chip   = _msi_irq_chip,
+};
+
+static void tango_compose_msi_msg(struct irq_data *data, struct msi_msg *msg)
+{
+   struct tango_pcie *pcie = irq_data_get_irq_chip_data(data);
+
+   msg->address_lo = lower_32_bits(pcie->msi_doorbell);
+   msg->address_hi = upper_32_bits(pcie->msi_doorbell);
+   msg->data = data->hwirq;
+}
+
+static int tango_set_affinity(struct irq_data *irq_data,
+   const struct cpumask *mask, bool force)
+{
+return -EINVAL;
+}
+
+static struct irq_chip tango_msi_chip = {
+   .name   = "MSI",
+   .irq_compose_msi_msg= tango_compose_msi_msg,
+   .irq_set_affinity   = tango_set_affinity,
+};
+
+static int tango_irq_domain_alloc(struct irq_domain *domain, unsigned int virq,
+   unsigned int nr_irqs, void *args)
+{
+   struct tango_pcie *pcie = domain->host_data;
+   int pos, err = 0;
+   u32 mask;
+
+   if (nr_irqs != 1) /* When does that happen? */
+   return -EINVAL;
+
+   mutex_lock(>lock);
+
+   mask = readl_relaxed(pcie->msi_mask);
+   pos = find_first_zero_bit(, MSI_COUNT);
+   if (pos < MSI_COUNT)
+   writel(mask | BIT(pos), pcie->msi_mask);
+   else
+   err = -ENOSPC;
+
+   mutex_unlock(>lock);
+
+   irq_domain_set_info(domain, virq, pos, _msi_chip,
+   domain->host_data, handle_simple_irq, NULL, NULL);
+
+   return err;
+}
+
+static void tango_irq_domain_free(struct irq_domain *domain,
+  unsigned int virq, unsigned int nr_irqs)
+{
+   struct irq_data *d = irq_domain_get_irq_data(domain, virq);
+   struct tango_pcie *pcie = irq_data_get_irq_chip_data(d);
+   int pos = d->hwirq;
+   u32 mask;
+
+   mutex_lock(>lock);
+
+   mask = readl(pcie->msi_mask);
+   writel(mask & ~BIT(pos), pcie->msi_mask);
+
+   mutex_unlock(>lock);
+}
+
+static const struct irq_domain_ops msi_domain_ops = {
+   .alloc  = tango_irq_domain_alloc,
+   .free   = tango_irq_domain_free,
+};
+
+static int tango_msi_remove(struct platform_device *pdev)
+{
+   struct tango_pcie *msi = platform_get_drvdata(pdev);
+
+   irq_set_chained_handler(msi->irq, NULL);
+   irq_set_handler_data(msi->irq, NULL);
+   /* irq_set_chained_handler_and_data(msi->irq, NULL, NULL); instead? */
+
+   irq_domain_remove(msi->msi_domain);
+   irq_domain_remove(msi->irq_domain);
+
+   return 0;
+}
+
+static int tango_msi_probe(struct platform_device *pdev, struct tango_pcie 
*pcie)
+{
+   int virq;
+   struct fwnode_handle *fwnode = of_node_to_fwnode(pdev->dev.of_node);
+   struct irq_domain *msi_dom, *irq_dom;
+
+   mutex_init(>lock);
+   writel(0, pcie->msi_mask);
+
+   /* Why is fwnode for this call? */
+   irq_dom = irq_domain_add_linear(NULL, MSI_COUNT, _domain_ops, pcie);
+   if (!irq_dom) {
+   pr_err("Failed to create IRQ domain\n");
+   

[RFC PATCH v0.2] PCI: Add support for tango PCIe host bridge

[Mason]

I think this version is ready for review.
It has all the required bits and pieces.
I still have a few questions, embedded as comments in the code.
(Missing are ancillary changes to Kconfig, Makefile)
---
 drivers/pci/host/pcie-tango.c | 350 ++
 1 file changed, 350 insertions(+)
 create mode 100644 drivers/pci/host/pcie-tango.c

diff --git a/drivers/pci/host/pcie-tango.c b/drivers/pci/host/pcie-tango.c
new file mode 100644
index ..b2e6448aed2d
--- /dev/null
+++ b/drivers/pci/host/pcie-tango.c
@@ -0,0 +1,350 @@
+#include 
+#include 
+#include 
+#include 
+
+#define MSI_COUNT 32
+
+struct tango_pcie {
+   void __iomem *mux;
+   void __iomem *msi_status;
+   void __iomem *msi_mask;
+   phys_addr_t msi_doorbell;
+   struct mutex lock; /* lock for updating msi_mask */
+   struct irq_domain *irq_domain;
+   struct irq_domain *msi_domain;
+   int irq;
+};
+
+/*** MSI CONTROLLER SUPPORT ***/
+
+static void tango_msi_isr(struct irq_desc *desc)
+{
+   struct irq_chip *chip = irq_desc_get_chip(desc);
+   struct tango_pcie *pcie;
+   unsigned long status, virq;
+   int pos;
+
+   chained_irq_enter(chip, desc);
+   pcie = irq_desc_get_handler_data(desc);
+
+   status = readl_relaxed(pcie->msi_status);
+   writel_relaxed(status, pcie->msi_status); /* clear IRQs */
+
+   for_each_set_bit(pos, , MSI_COUNT) {
+   virq = irq_find_mapping(pcie->irq_domain, pos);
+   if (virq)
+   generic_handle_irq(virq);
+   else
+   pr_err("Unhandled MSI: %d\n", pos);
+   }
+
+   chained_irq_exit(chip, desc);
+}
+
+static struct irq_chip tango_msi_irq_chip = {
+   .name = "MSI",
+   .irq_mask = pci_msi_mask_irq,
+   .irq_unmask = pci_msi_unmask_irq,
+};
+
+static struct msi_domain_info msi_domain_info = {
+   .flags  = MSI_FLAG_USE_DEF_DOM_OPS | MSI_FLAG_USE_DEF_CHIP_OPS,
+   .chip   = _msi_irq_chip,
+};
+
+static void tango_compose_msi_msg(struct irq_data *data, struct msi_msg *msg)
+{
+   struct tango_pcie *pcie = irq_data_get_irq_chip_data(data);
+
+   msg->address_lo = lower_32_bits(pcie->msi_doorbell);
+   msg->address_hi = upper_32_bits(pcie->msi_doorbell);
+   msg->data = data->hwirq;
+}
+
+static int tango_set_affinity(struct irq_data *irq_data,
+   const struct cpumask *mask, bool force)
+{
+return -EINVAL;
+}
+
+static struct irq_chip tango_msi_chip = {
+   .name   = "MSI",
+   .irq_compose_msi_msg= tango_compose_msi_msg,
+   .irq_set_affinity   = tango_set_affinity,
+};
+
+static int tango_irq_domain_alloc(struct irq_domain *domain, unsigned int virq,
+   unsigned int nr_irqs, void *args)
+{
+   struct tango_pcie *pcie = domain->host_data;
+   int pos, err = 0;
+   u32 mask;
+
+   if (nr_irqs != 1) /* When does that happen? */
+   return -EINVAL;
+
+   mutex_lock(>lock);
+
+   mask = readl_relaxed(pcie->msi_mask);
+   pos = find_first_zero_bit(, MSI_COUNT);
+   if (pos < MSI_COUNT)
+   writel(mask | BIT(pos), pcie->msi_mask);
+   else
+   err = -ENOSPC;
+
+   mutex_unlock(>lock);
+
+   irq_domain_set_info(domain, virq, pos, _msi_chip,
+   domain->host_data, handle_simple_irq, NULL, NULL);
+
+   return err;
+}
+
+static void tango_irq_domain_free(struct irq_domain *domain,
+  unsigned int virq, unsigned int nr_irqs)
+{
+   struct irq_data *d = irq_domain_get_irq_data(domain, virq);
+   struct tango_pcie *pcie = irq_data_get_irq_chip_data(d);
+   int pos = d->hwirq;
+   u32 mask;
+
+   mutex_lock(>lock);
+
+   mask = readl(pcie->msi_mask);
+   writel(mask & ~BIT(pos), pcie->msi_mask);
+
+   mutex_unlock(>lock);
+}
+
+static const struct irq_domain_ops msi_domain_ops = {
+   .alloc  = tango_irq_domain_alloc,
+   .free   = tango_irq_domain_free,
+};
+
+static int tango_msi_remove(struct platform_device *pdev)
+{
+   struct tango_pcie *msi = platform_get_drvdata(pdev);
+
+   irq_set_chained_handler(msi->irq, NULL);
+   irq_set_handler_data(msi->irq, NULL);
+   /* irq_set_chained_handler_and_data(msi->irq, NULL, NULL); instead? */
+
+   irq_domain_remove(msi->msi_domain);
+   irq_domain_remove(msi->irq_domain);
+
+   return 0;
+}
+
+static int tango_msi_probe(struct platform_device *pdev, struct tango_pcie 
*pcie)
+{
+   int virq;
+   struct fwnode_handle *fwnode = of_node_to_fwnode(pdev->dev.of_node);
+   struct irq_domain *msi_dom, *irq_dom;
+
+   mutex_init(>lock);
+   writel(0, pcie->msi_mask);
+
+   /* Why is fwnode for this call? */
+   irq_dom = irq_domain_add_linear(NULL, MSI_COUNT, _domain_ops, pcie);
+   if (!irq_dom) {
+   pr_err("Failed to create IRQ domain\n");
+