Re: [PATCH 37/45] drivers: use req op accessor

[Mike Christie]

On 08/03/2016 07:30 PM, Shaun Tancheff wrote:
> On Wed, Aug 3, 2016 at 6:47 PM, Mike Christie  wrote:
>> On 08/03/2016 05:33 PM, Ross Zwisler wrote:
>>> On Sun, Jun 5, 2016 at 1:32 PM,   wrote:
 From: Mike Christie 

 The req operation REQ_OP is separated from the rq_flag_bits
 definition. This converts the block layer drivers to
 use req_op to get the op from the request struct.

 Signed-off-by: Mike Christie 
 ---
  drivers/block/loop.c  |  6 +++---
  drivers/block/mtip32xx/mtip32xx.c |  2 +-
  drivers/block/nbd.c   |  2 +-
  drivers/block/rbd.c   |  4 ++--
  drivers/block/xen-blkfront.c  |  8 +---
  drivers/ide/ide-floppy.c  |  2 +-
  drivers/md/dm.c   |  2 +-
  drivers/mmc/card/block.c  |  7 +++
  drivers/mmc/card/queue.c  |  6 ++
>>>
>>> Dave Chinner reported a deadlock with XFS + DAX, which I reproduced
>>> and bisected to this commit:
>>>
>>> commit c2df40dfb8c015211ec55f4b1dd0587f875c7b34
>>> Author: Mike Christie 
>>> Date:   Sun Jun 5 14:32:17 2016 -0500
>>> drivers: use req op accessor
>>>
>>> Here are the steps to reproduce the deadlock with a BRD ramdisk:
>>>
>>> mkfs.xfs -f /dev/ram0
>>> mount -o dax /dev/ram0 /mnt/scratch
>>
>> When using ramdisks, we need the attached patch like in your other bug
>> report. I think it will fix some hangs people are seeing.
>>
>> I do not think that it should cause the failure to run issue you saw
>> when doing generic/008 and ext2.
>>
> 
> I think the translation in loop.c is suspicious here:
> 
> "if use DIO && not (a flush_flag or discard_flag)"
> should translate to:
> "if use DIO && not ((a flush_flag) || op == discard)"
> 
> But in the patch I read:
> "if use DIO && ((not a flush_flag) || op == discard)
> 
> Which would have DIO && discards follow the AIO path?
> 
> So I would humbly suggest something like the following
> (on top of commit c2df40dfb8c015211ec55f4b1dd0587f875c7b34):
> [Please excuse the messed up patch format ... gmail eats tabs]
> 
> diff --git a/drivers/block/loop.c b/drivers/block/loop.c
> index b9b737c..0754d83 100644
> --- a/drivers/block/loop.c
> +++ b/drivers/block/loop.c
> @@ -1659,8 +1659,9 @@ static int loop_queue_rq(struct blk_mq_hw_ctx *hctx,
> if (lo->lo_state != Lo_bound)
> return -EIO;
> 
> -   if (lo->use_dio && (!(cmd->rq->cmd_flags & REQ_FLUSH) ||
> -   req_op(cmd->rq) == REQ_OP_DISCARD))
> +   if (lo->use_dio && !(
> +   (cmd->rq->cmd_flags & REQ_FLUSH) ||
> +req_op(cmd->rq) == REQ_OP_DISCARD))
> cmd->use_aio = true;
> else
> cmd->use_aio = false;
> 

You are right. The translation was bad and your code above is correct.

I think we need my patch in the other mail though too, because for the
rw_page user case if WB_SYNC_ALL is set, then the IO gets sent down as a
read instead of a write.

Re: [PATCH 37/45] drivers: use req op accessor

[Mike Christie]

On 08/03/2016 07:30 PM, Shaun Tancheff wrote:
> On Wed, Aug 3, 2016 at 6:47 PM, Mike Christie  wrote:
>> On 08/03/2016 05:33 PM, Ross Zwisler wrote:
>>> On Sun, Jun 5, 2016 at 1:32 PM,   wrote:
 From: Mike Christie 

 The req operation REQ_OP is separated from the rq_flag_bits
 definition. This converts the block layer drivers to
 use req_op to get the op from the request struct.

 Signed-off-by: Mike Christie 
 ---
  drivers/block/loop.c  |  6 +++---
  drivers/block/mtip32xx/mtip32xx.c |  2 +-
  drivers/block/nbd.c   |  2 +-
  drivers/block/rbd.c   |  4 ++--
  drivers/block/xen-blkfront.c  |  8 +---
  drivers/ide/ide-floppy.c  |  2 +-
  drivers/md/dm.c   |  2 +-
  drivers/mmc/card/block.c  |  7 +++
  drivers/mmc/card/queue.c  |  6 ++
>>>
>>> Dave Chinner reported a deadlock with XFS + DAX, which I reproduced
>>> and bisected to this commit:
>>>
>>> commit c2df40dfb8c015211ec55f4b1dd0587f875c7b34
>>> Author: Mike Christie 
>>> Date:   Sun Jun 5 14:32:17 2016 -0500
>>> drivers: use req op accessor
>>>
>>> Here are the steps to reproduce the deadlock with a BRD ramdisk:
>>>
>>> mkfs.xfs -f /dev/ram0
>>> mount -o dax /dev/ram0 /mnt/scratch
>>
>> When using ramdisks, we need the attached patch like in your other bug
>> report. I think it will fix some hangs people are seeing.
>>
>> I do not think that it should cause the failure to run issue you saw
>> when doing generic/008 and ext2.
>>
> 
> I think the translation in loop.c is suspicious here:
> 
> "if use DIO && not (a flush_flag or discard_flag)"
> should translate to:
> "if use DIO && not ((a flush_flag) || op == discard)"
> 
> But in the patch I read:
> "if use DIO && ((not a flush_flag) || op == discard)
> 
> Which would have DIO && discards follow the AIO path?
> 
> So I would humbly suggest something like the following
> (on top of commit c2df40dfb8c015211ec55f4b1dd0587f875c7b34):
> [Please excuse the messed up patch format ... gmail eats tabs]
> 
> diff --git a/drivers/block/loop.c b/drivers/block/loop.c
> index b9b737c..0754d83 100644
> --- a/drivers/block/loop.c
> +++ b/drivers/block/loop.c
> @@ -1659,8 +1659,9 @@ static int loop_queue_rq(struct blk_mq_hw_ctx *hctx,
> if (lo->lo_state != Lo_bound)
> return -EIO;
> 
> -   if (lo->use_dio && (!(cmd->rq->cmd_flags & REQ_FLUSH) ||
> -   req_op(cmd->rq) == REQ_OP_DISCARD))
> +   if (lo->use_dio && !(
> +   (cmd->rq->cmd_flags & REQ_FLUSH) ||
> +req_op(cmd->rq) == REQ_OP_DISCARD))
> cmd->use_aio = true;
> else
> cmd->use_aio = false;
> 

You are right. The translation was bad and your code above is correct.

I think we need my patch in the other mail though too, because for the
rw_page user case if WB_SYNC_ALL is set, then the IO gets sent down as a
read instead of a write.

Re: [PATCH v3] virtio_blk: Fix a slient kernel panic

[Minfei Huang]

Hi, Michael.

Since Stefan and Cornelia have review-acked this patch, could you mind
helping review this patch?

Thanks
Minfei

> On Jul 29, 2016, at 16:26, Stefan Hajnoczi  wrote:
> 
> On Tue, Jul 19, 2016 at 5:32 AM, Minfei Huang  wrote:
>> From: Minfei Huang 
>> 
>> We do a lot of memory allocation in function init_vq, and don't handle
>> the allocation failure properly. Then this function will return 0,
>> although initialization fails due to lacking memory. At that moment,
>> kernel will panic in guest machine, if virtio is used to drive disk.
>> 
>> To fix this bug, we should take care of allocation failure, and return
>> correct value to let caller know what happen.
>> 
>> Tested-by: Chao Fan 
>> Signed-off-by: Minfei Huang 
>> Signed-off-by: Minfei Huang 
>> ---
>> v2:
>> - Remove useless initialisation to NULL
>> v1:
>> - Refactor the patch to make code more readable
>> ---
>> drivers/block/virtio_blk.c | 26 --
>> 1 file changed, 8 insertions(+), 18 deletions(-)
> 
> Reviewed-by: Stefan Hajnoczi 



smime.p7s
Description: S/MIME cryptographic signature

Re: [PATCH v3] virtio_blk: Fix a slient kernel panic

[Minfei Huang]

Hi, Michael.

Since Stefan and Cornelia have review-acked this patch, could you mind
helping review this patch?

Thanks
Minfei

> On Jul 29, 2016, at 16:26, Stefan Hajnoczi  wrote:
> 
> On Tue, Jul 19, 2016 at 5:32 AM, Minfei Huang  wrote:
>> From: Minfei Huang 
>> 
>> We do a lot of memory allocation in function init_vq, and don't handle
>> the allocation failure properly. Then this function will return 0,
>> although initialization fails due to lacking memory. At that moment,
>> kernel will panic in guest machine, if virtio is used to drive disk.
>> 
>> To fix this bug, we should take care of allocation failure, and return
>> correct value to let caller know what happen.
>> 
>> Tested-by: Chao Fan 
>> Signed-off-by: Minfei Huang 
>> Signed-off-by: Minfei Huang 
>> ---
>> v2:
>> - Remove useless initialisation to NULL
>> v1:
>> - Refactor the patch to make code more readable
>> ---
>> drivers/block/virtio_blk.c | 26 --
>> 1 file changed, 8 insertions(+), 18 deletions(-)
> 
> Reviewed-by: Stefan Hajnoczi 



smime.p7s
Description: S/MIME cryptographic signature

Re: [PATCH] iio: humidity: hdc100x: use i2c_master_recv to read sensor data

[Peter Meerwald-Stadler]

> > Replace the i2c_smbus_read_byte commmands used to retrieve the sensor
> > data with an i2c_master_recv command.
> >
> > The smbus read byte method fails because the device does not expect a
> > stop condition after sending the first byte. When we issue the second
> > read, we are getting the first byte again. Net effect is that of the 14
> > bits used for the measurement, the 8 most significant bits are correct,
> > the lower 6 are not.
> >
> > None of the smbus read protocols follow the pattern this device requires
> > (S Addr Rd [A] Data [A] Data NA P), hence the switch to an i2c receive
> > transaction.
> >
> > Signed-off-by: Alison Schofield 
> > Cc: Daniel Baluta 
> > ---
> >  drivers/iio/humidity/hdc100x.c | 27 +++
> >  1 file changed, 7 insertions(+), 20 deletions(-)
> >
> > diff --git a/drivers/iio/humidity/hdc100x.c b/drivers/iio/humidity/hdc100x.c
> > index a03832a..643a42d 100644
> > --- a/drivers/iio/humidity/hdc100x.c
> > +++ b/drivers/iio/humidity/hdc100x.c
> > @@ -142,7 +142,7 @@ static int hdc100x_get_measurement(struct hdc100x_data 
> > *data,
> > struct i2c_client *client = data->client;
> > int delay = data->adc_int_us[chan->address];
> > int ret;
> > -   int val;
> > +   u8 buf[2];

__le16 val;

> >
> > /* start measurement */
> > ret = i2c_smbus_write_byte(client, chan->address);
> > @@ -154,26 +154,13 @@ static int hdc100x_get_measurement(struct 
> > hdc100x_data *data,
> > /* wait for integration time to pass */
> > usleep_range(delay, delay + 1000);
> >
> > -   /*
> > -* i2c_smbus_read_word_data cannot() be used here due to the command
> > -* value not being understood and causes NAKs preventing any reading
> > -* from being accessed.
> > -*/
> > -   ret = i2c_smbus_read_byte(client);
> > +   /* read the 2 byte measurement */
> > +   ret = i2c_master_recv(data->client, buf, 2);
> > if (ret < 0) {
> > -   dev_err(>dev, "cannot read high byte measurement");
> > +   dev_err(>dev, "cannot read sensor data\n");
> > return ret;
> > }
> > -   val = ret << 8;
> > -
> > -   ret = i2c_smbus_read_byte(client);
> > -   if (ret < 0) {
> > -   dev_err(>dev, "cannot read low byte measurement");
> > -   return ret;
> > -   }
> > -   val |= ret;
> > -
> > -   return val;
> > +   return (int)(buf[0] << 8 | buf[1]);
> 
> Pretty sure you don't need to cast to int type here.

return le16_to_cpu(val);

> 
> >  }
> >
> >  static int hdc100x_get_heater_status(struct hdc100x_data *data)
> > @@ -272,8 +259,8 @@ static int hdc100x_probe(struct i2c_client *client,
> > struct iio_dev *indio_dev;
> > struct hdc100x_data *data;
> >
> > -   if (!i2c_check_functionality(client->adapter,
> > -   I2C_FUNC_SMBUS_WORD_DATA | 
> > I2C_FUNC_SMBUS_BYTE))
> > +   if (!i2c_check_functionality(client->adapter, 
> > I2C_FUNC_SMBUS_WORD_DATA |
> > +I2C_FUNC_SMBUS_BYTE | I2C_FUNC_I2C))
> 
> Not sure we want to kill smbus support for this device...  iwe should
> have two read methods for i2c and smbus (see the PulsedLight LIDAR
> driver) in this case.
> 
> Ideally I wouldn't have written it with only smbus in mind, but can
> kill backwards compatibility unless we have a good reason.
> 
> Thanks,
> 
> Matt
> 
> > return -EOPNOTSUPP;
> >
> > indio_dev = devm_iio_device_alloc(>dev, sizeof(*data));
> > --
> > 2.1.4
> >
> 

-- 

Peter Meerwald-Stadler
+43-664-218 (mobile)

Re: [PATCH] iio: humidity: hdc100x: use i2c_master_recv to read sensor data

[Peter Meerwald-Stadler]

> > Replace the i2c_smbus_read_byte commmands used to retrieve the sensor
> > data with an i2c_master_recv command.
> >
> > The smbus read byte method fails because the device does not expect a
> > stop condition after sending the first byte. When we issue the second
> > read, we are getting the first byte again. Net effect is that of the 14
> > bits used for the measurement, the 8 most significant bits are correct,
> > the lower 6 are not.
> >
> > None of the smbus read protocols follow the pattern this device requires
> > (S Addr Rd [A] Data [A] Data NA P), hence the switch to an i2c receive
> > transaction.
> >
> > Signed-off-by: Alison Schofield 
> > Cc: Daniel Baluta 
> > ---
> >  drivers/iio/humidity/hdc100x.c | 27 +++
> >  1 file changed, 7 insertions(+), 20 deletions(-)
> >
> > diff --git a/drivers/iio/humidity/hdc100x.c b/drivers/iio/humidity/hdc100x.c
> > index a03832a..643a42d 100644
> > --- a/drivers/iio/humidity/hdc100x.c
> > +++ b/drivers/iio/humidity/hdc100x.c
> > @@ -142,7 +142,7 @@ static int hdc100x_get_measurement(struct hdc100x_data 
> > *data,
> > struct i2c_client *client = data->client;
> > int delay = data->adc_int_us[chan->address];
> > int ret;
> > -   int val;
> > +   u8 buf[2];

__le16 val;

> >
> > /* start measurement */
> > ret = i2c_smbus_write_byte(client, chan->address);
> > @@ -154,26 +154,13 @@ static int hdc100x_get_measurement(struct 
> > hdc100x_data *data,
> > /* wait for integration time to pass */
> > usleep_range(delay, delay + 1000);
> >
> > -   /*
> > -* i2c_smbus_read_word_data cannot() be used here due to the command
> > -* value not being understood and causes NAKs preventing any reading
> > -* from being accessed.
> > -*/
> > -   ret = i2c_smbus_read_byte(client);
> > +   /* read the 2 byte measurement */
> > +   ret = i2c_master_recv(data->client, buf, 2);
> > if (ret < 0) {
> > -   dev_err(>dev, "cannot read high byte measurement");
> > +   dev_err(>dev, "cannot read sensor data\n");
> > return ret;
> > }
> > -   val = ret << 8;
> > -
> > -   ret = i2c_smbus_read_byte(client);
> > -   if (ret < 0) {
> > -   dev_err(>dev, "cannot read low byte measurement");
> > -   return ret;
> > -   }
> > -   val |= ret;
> > -
> > -   return val;
> > +   return (int)(buf[0] << 8 | buf[1]);
> 
> Pretty sure you don't need to cast to int type here.

return le16_to_cpu(val);

> 
> >  }
> >
> >  static int hdc100x_get_heater_status(struct hdc100x_data *data)
> > @@ -272,8 +259,8 @@ static int hdc100x_probe(struct i2c_client *client,
> > struct iio_dev *indio_dev;
> > struct hdc100x_data *data;
> >
> > -   if (!i2c_check_functionality(client->adapter,
> > -   I2C_FUNC_SMBUS_WORD_DATA | 
> > I2C_FUNC_SMBUS_BYTE))
> > +   if (!i2c_check_functionality(client->adapter, 
> > I2C_FUNC_SMBUS_WORD_DATA |
> > +I2C_FUNC_SMBUS_BYTE | I2C_FUNC_I2C))
> 
> Not sure we want to kill smbus support for this device...  iwe should
> have two read methods for i2c and smbus (see the PulsedLight LIDAR
> driver) in this case.
> 
> Ideally I wouldn't have written it with only smbus in mind, but can
> kill backwards compatibility unless we have a good reason.
> 
> Thanks,
> 
> Matt
> 
> > return -EOPNOTSUPP;
> >
> > indio_dev = devm_iio_device_alloc(>dev, sizeof(*data));
> > --
> > 2.1.4
> >
> 

-- 

Peter Meerwald-Stadler
+43-664-218 (mobile)

[patch] CRIS v32: remove some double unlocks

[Dan Carpenter]

We unlocked a few lines earlier so we can delete these unlocks.

Signed-off-by: Dan Carpenter 

diff --git a/arch/cris/arch-v32/mach-a3/dma.c b/arch/cris/arch-v32/mach-a3/dma.c
index 47c64bf..11f417f 100644
--- a/arch/cris/arch-v32/mach-a3/dma.c
+++ b/arch/cris/arch-v32/mach-a3/dma.c
@@ -41,7 +41,6 @@ int crisv32_request_dma(unsigned int dmanr, const char 
*device_id,
 
if (options & DMA_PANIC_ON_ERROR)
panic("request_dma error!");
-   spin_unlock_irqrestore(_lock, flags);
return -EBUSY;
}
clk_ctrl = REG_RD(clkgen, regi_clkgen, rw_clk_ctrl);
diff --git a/arch/cris/arch-v32/mach-fs/dma.c b/arch/cris/arch-v32/mach-fs/dma.c
index fc6416a..7c93679 100644
--- a/arch/cris/arch-v32/mach-fs/dma.c
+++ b/arch/cris/arch-v32/mach-fs/dma.c
@@ -43,7 +43,6 @@ int crisv32_request_dma(unsigned int dmanr, const char 
*device_id,
}
if (options & DMA_PANIC_ON_ERROR)
panic("request_dma error!");
-   spin_unlock_irqrestore(_lock, flags);
return -EBUSY;
}
clk_ctrl = REG_RD(config, regi_config, rw_clk_ctrl);

[patch] CRIS v32: remove some double unlocks

[Dan Carpenter]

We unlocked a few lines earlier so we can delete these unlocks.

Signed-off-by: Dan Carpenter 

diff --git a/arch/cris/arch-v32/mach-a3/dma.c b/arch/cris/arch-v32/mach-a3/dma.c
index 47c64bf..11f417f 100644
--- a/arch/cris/arch-v32/mach-a3/dma.c
+++ b/arch/cris/arch-v32/mach-a3/dma.c
@@ -41,7 +41,6 @@ int crisv32_request_dma(unsigned int dmanr, const char 
*device_id,
 
if (options & DMA_PANIC_ON_ERROR)
panic("request_dma error!");
-   spin_unlock_irqrestore(_lock, flags);
return -EBUSY;
}
clk_ctrl = REG_RD(clkgen, regi_clkgen, rw_clk_ctrl);
diff --git a/arch/cris/arch-v32/mach-fs/dma.c b/arch/cris/arch-v32/mach-fs/dma.c
index fc6416a..7c93679 100644
--- a/arch/cris/arch-v32/mach-fs/dma.c
+++ b/arch/cris/arch-v32/mach-fs/dma.c
@@ -43,7 +43,6 @@ int crisv32_request_dma(unsigned int dmanr, const char 
*device_id,
}
if (options & DMA_PANIC_ON_ERROR)
panic("request_dma error!");
-   spin_unlock_irqrestore(_lock, flags);
return -EBUSY;
}
clk_ctrl = REG_RD(config, regi_config, rw_clk_ctrl);

[patch] mailbox: bcm-pdc: potential NULL dereference in pdc_shutdown()

[Dan Carpenter]

We can't pass NULL pointers to pdc_ring_free() so I moved the check for
NULL.

Signed-off-by: Dan Carpenter 

diff --git a/drivers/mailbox/bcm-pdc-mailbox.c 
b/drivers/mailbox/bcm-pdc-mailbox.c
index cbe0c1e..c56d4d0 100644
--- a/drivers/mailbox/bcm-pdc-mailbox.c
+++ b/drivers/mailbox/bcm-pdc-mailbox.c
@@ -1191,10 +1191,11 @@ static void pdc_shutdown(struct mbox_chan *chan)
 {
struct pdc_state *pdcs = chan->con_priv;
 
-   if (pdcs)
-   dev_dbg(>pdev->dev,
-   "Shutdown mailbox channel for PDC %u", pdcs->pdc_idx);
+   if (!pdcs)
+   return;
 
+   dev_dbg(>pdev->dev,
+   "Shutdown mailbox channel for PDC %u", pdcs->pdc_idx);
pdc_ring_free(pdcs);
 }
 

[patch] mailbox: bcm-pdc: potential NULL dereference in pdc_shutdown()

[Dan Carpenter]

We can't pass NULL pointers to pdc_ring_free() so I moved the check for
NULL.

Signed-off-by: Dan Carpenter 

diff --git a/drivers/mailbox/bcm-pdc-mailbox.c 
b/drivers/mailbox/bcm-pdc-mailbox.c
index cbe0c1e..c56d4d0 100644
--- a/drivers/mailbox/bcm-pdc-mailbox.c
+++ b/drivers/mailbox/bcm-pdc-mailbox.c
@@ -1191,10 +1191,11 @@ static void pdc_shutdown(struct mbox_chan *chan)
 {
struct pdc_state *pdcs = chan->con_priv;
 
-   if (pdcs)
-   dev_dbg(>pdev->dev,
-   "Shutdown mailbox channel for PDC %u", pdcs->pdc_idx);
+   if (!pdcs)
+   return;
 
+   dev_dbg(>pdev->dev,
+   "Shutdown mailbox channel for PDC %u", pdcs->pdc_idx);
pdc_ring_free(pdcs);
 }
 

Re: [RFC][PATCH 3/4] power: reset: Add sram-reboot-mode driver

[Bjorn Andersson]

On Wed 03 Aug 20:08 PDT 2016, John Stultz wrote:

> On Wed, Aug 3, 2016 at 6:03 PM, Bjorn Andersson
>  wrote:
> > On Wed 03 Aug 16:05 PDT 2016, John Stultz wrote:
> >
> > [..]
> >> diff --git a/drivers/power/reset/sram-reboot-mode.c 
> >> b/drivers/power/reset/sram-reboot-mode.c
[..]
> >> + ret = reboot_mode_register(_rbm->reboot);
> >
> > I think you should take the time to throw in a
> > devm_reboot_mode_register(), it would save you from the
> > dev_set_drvdata() and you can drop the remove function.
> 
> So I've only got a vague sense of what your suggesting here. Do you
> have a pointer to a good example?
> 

https://patchwork.kernel.org/patch/9262691/
https://patchwork.kernel.org/patch/9262693/

Regards,
Bjorn

Re: [RFC][PATCH 3/4] power: reset: Add sram-reboot-mode driver

[Bjorn Andersson]

On Wed 03 Aug 20:08 PDT 2016, John Stultz wrote:

> On Wed, Aug 3, 2016 at 6:03 PM, Bjorn Andersson
>  wrote:
> > On Wed 03 Aug 16:05 PDT 2016, John Stultz wrote:
> >
> > [..]
> >> diff --git a/drivers/power/reset/sram-reboot-mode.c 
> >> b/drivers/power/reset/sram-reboot-mode.c
[..]
> >> + ret = reboot_mode_register(_rbm->reboot);
> >
> > I think you should take the time to throw in a
> > devm_reboot_mode_register(), it would save you from the
> > dev_set_drvdata() and you can drop the remove function.
> 
> So I've only got a vague sense of what your suggesting here. Do you
> have a pointer to a good example?
> 

https://patchwork.kernel.org/patch/9262691/
https://patchwork.kernel.org/patch/9262693/

Regards,
Bjorn

[patch] rapidio: dereferencing an error pointer

[Dan Carpenter]

If riocm_ch_alloc() fails then we end up dereferencing the error
pointer.

The problem is that we're not unwinding in the reverse order from how
we allocate things so it gets confusing.  I've changed this around so
now "ch" is NULL when we are done with it after we call
riocm_put_channel().  That way we can check if it's NULL and avoid
calling riocm_put_channel() on it twice.

I renamed err_nodev to err_put_new_ch so that it better reflects what
the goto does.

Then because we had flipping things around, it means we don't neeed to
initialize the pointers to NULL and we can remove an if statement and
pull things in an indent level.

Signed-off-by: Dan Carpenter 

diff --git a/drivers/rapidio/rio_cm.c b/drivers/rapidio/rio_cm.c
index cecc15a..3fa17ac 100644
--- a/drivers/rapidio/rio_cm.c
+++ b/drivers/rapidio/rio_cm.c
@@ -1080,8 +1080,8 @@ static int riocm_send_ack(struct rio_channel *ch)
 static struct rio_channel *riocm_ch_accept(u16 ch_id, u16 *new_ch_id,
   long timeout)
 {
-   struct rio_channel *ch = NULL;
-   struct rio_channel *new_ch = NULL;
+   struct rio_channel *ch;
+   struct rio_channel *new_ch;
struct conn_req *req;
struct cm_peer *peer;
int found = 0;
@@ -1155,6 +1155,7 @@ static struct rio_channel *riocm_ch_accept(u16 ch_id, u16 
*new_ch_id,
 
spin_unlock_bh(>lock);
riocm_put_channel(ch);
+   ch = NULL;
kfree(req);
 
down_read(_sem);
@@ -1172,7 +1173,7 @@ static struct rio_channel *riocm_ch_accept(u16 ch_id, u16 
*new_ch_id,
if (!found) {
/* If peer device object not found, simply ignore the request */
err = -ENODEV;
-   goto err_nodev;
+   goto err_put_new_ch;
}
 
new_ch->rdev = peer->rdev;
@@ -1184,15 +1185,16 @@ static struct rio_channel *riocm_ch_accept(u16 ch_id, 
u16 *new_ch_id,
 
*new_ch_id = new_ch->id;
return new_ch;
+
+err_put_new_ch:
+   spin_lock_bh(_lock);
+   idr_remove(_idr, new_ch->id);
+   spin_unlock_bh(_lock);
+   riocm_put_channel(new_ch);
+
 err_put:
-   riocm_put_channel(ch);
-err_nodev:
-   if (new_ch) {
-   spin_lock_bh(_lock);
-   idr_remove(_idr, new_ch->id);
-   spin_unlock_bh(_lock);
-   riocm_put_channel(new_ch);
-   }
+   if (ch)
+   riocm_put_channel(ch);
*new_ch_id = 0;
return ERR_PTR(err);
 }

[patch] rapidio: dereferencing an error pointer

[Dan Carpenter]

If riocm_ch_alloc() fails then we end up dereferencing the error
pointer.

The problem is that we're not unwinding in the reverse order from how
we allocate things so it gets confusing.  I've changed this around so
now "ch" is NULL when we are done with it after we call
riocm_put_channel().  That way we can check if it's NULL and avoid
calling riocm_put_channel() on it twice.

I renamed err_nodev to err_put_new_ch so that it better reflects what
the goto does.

Then because we had flipping things around, it means we don't neeed to
initialize the pointers to NULL and we can remove an if statement and
pull things in an indent level.

Signed-off-by: Dan Carpenter 

diff --git a/drivers/rapidio/rio_cm.c b/drivers/rapidio/rio_cm.c
index cecc15a..3fa17ac 100644
--- a/drivers/rapidio/rio_cm.c
+++ b/drivers/rapidio/rio_cm.c
@@ -1080,8 +1080,8 @@ static int riocm_send_ack(struct rio_channel *ch)
 static struct rio_channel *riocm_ch_accept(u16 ch_id, u16 *new_ch_id,
   long timeout)
 {
-   struct rio_channel *ch = NULL;
-   struct rio_channel *new_ch = NULL;
+   struct rio_channel *ch;
+   struct rio_channel *new_ch;
struct conn_req *req;
struct cm_peer *peer;
int found = 0;
@@ -1155,6 +1155,7 @@ static struct rio_channel *riocm_ch_accept(u16 ch_id, u16 
*new_ch_id,
 
spin_unlock_bh(>lock);
riocm_put_channel(ch);
+   ch = NULL;
kfree(req);
 
down_read(_sem);
@@ -1172,7 +1173,7 @@ static struct rio_channel *riocm_ch_accept(u16 ch_id, u16 
*new_ch_id,
if (!found) {
/* If peer device object not found, simply ignore the request */
err = -ENODEV;
-   goto err_nodev;
+   goto err_put_new_ch;
}
 
new_ch->rdev = peer->rdev;
@@ -1184,15 +1185,16 @@ static struct rio_channel *riocm_ch_accept(u16 ch_id, 
u16 *new_ch_id,
 
*new_ch_id = new_ch->id;
return new_ch;
+
+err_put_new_ch:
+   spin_lock_bh(_lock);
+   idr_remove(_idr, new_ch->id);
+   spin_unlock_bh(_lock);
+   riocm_put_channel(new_ch);
+
 err_put:
-   riocm_put_channel(ch);
-err_nodev:
-   if (new_ch) {
-   spin_lock_bh(_lock);
-   idr_remove(_idr, new_ch->id);
-   spin_unlock_bh(_lock);
-   riocm_put_channel(new_ch);
-   }
+   if (ch)
+   riocm_put_channel(ch);
*new_ch_id = 0;
return ERR_PTR(err);
 }

[patch] mfd: 88pm80x: Double shifting bug in suspend/resume

[Dan Carpenter]

set_bit() and clear_bit() take the bit number so this code is really
doing "1 << (1 << irq)" which is a double shift bug.  It's done
consistently so it won't cause a problem unless "irq" is more than 4.

Fixes: 70c6cce04066 ('mfd: Support 88pm80x in 80x driver')
Signed-off-by: Dan Carpenter 

diff --git a/include/linux/mfd/88pm80x.h b/include/linux/mfd/88pm80x.h
index d409ceb..c118a7e 100644
--- a/include/linux/mfd/88pm80x.h
+++ b/include/linux/mfd/88pm80x.h
@@ -350,7 +350,7 @@ static inline int pm80x_dev_suspend(struct device *dev)
int irq = platform_get_irq(pdev, 0);
 
if (device_may_wakeup(dev))
-   set_bit((1 << irq), >wu_flag);
+   set_bit(irq, >wu_flag);
 
return 0;
 }
@@ -362,7 +362,7 @@ static inline int pm80x_dev_resume(struct device *dev)
int irq = platform_get_irq(pdev, 0);
 
if (device_may_wakeup(dev))
-   clear_bit((1 << irq), >wu_flag);
+   clear_bit(irq, >wu_flag);
 
return 0;
 }

[patch] mfd: 88pm80x: Double shifting bug in suspend/resume

[Dan Carpenter]

set_bit() and clear_bit() take the bit number so this code is really
doing "1 << (1 << irq)" which is a double shift bug.  It's done
consistently so it won't cause a problem unless "irq" is more than 4.

Fixes: 70c6cce04066 ('mfd: Support 88pm80x in 80x driver')
Signed-off-by: Dan Carpenter 

diff --git a/include/linux/mfd/88pm80x.h b/include/linux/mfd/88pm80x.h
index d409ceb..c118a7e 100644
--- a/include/linux/mfd/88pm80x.h
+++ b/include/linux/mfd/88pm80x.h
@@ -350,7 +350,7 @@ static inline int pm80x_dev_suspend(struct device *dev)
int irq = platform_get_irq(pdev, 0);
 
if (device_may_wakeup(dev))
-   set_bit((1 << irq), >wu_flag);
+   set_bit(irq, >wu_flag);
 
return 0;
 }
@@ -362,7 +362,7 @@ static inline int pm80x_dev_resume(struct device *dev)
int irq = platform_get_irq(pdev, 0);
 
if (device_may_wakeup(dev))
-   clear_bit((1 << irq), >wu_flag);
+   clear_bit(irq, >wu_flag);
 
return 0;
 }

Re: "run seccomp after ptrace" changes expose "missing PTRACE_EVENT_EXIT" bug

[Kees Cook]

On Wed, Aug 3, 2016 at 4:51 PM, Robert O'Callahan  wrote:
> I work on rr (http://rr-project.org/), a record-and-replay reverse-execution
> debugger which is a heavy user of ptrace and seccomp. The recent change to
> perform syscall-entry PTRACE_SYSCALL stops before PTRACE_EVENT_SECCOMP stops
> broke rr, which is fine because I'm fixing rr and this change actually makes
> rr faster (thanks!). However, it exposed an existing kernel bug which
> creates a problem for us, and which I'm not sure how to fix.
>
> The problem is that if a tracee task is in a PTRACE_EVENT_SECCOMP trap, or
> has been resumed after such a trap but not yet been scheduled, and another
> task in the thread-group calls exit_group(), then the tracee task exits
> without the ptracer receiving a PTRACE_EVENT_EXIT notification. Small-ish
> testcase here:
> https://gist.github.com/rocallahan/1344f7d01183c233d08a2c6b93413068.
>
> The bug happens because when __seccomp_filter() detects
> fatal_signal_pending(), it calls do_exit() without dequeuing the fatal
> signal. When do_exit() sends the PTRACE_EVENT_EXIT notification and that
> task is descheduled, __schedule() notices that there is a fatal signal
> pending and changes its state from TASK_TRACED to TASK_RUNNING. That
> prevents the ptracer's waitpid() from returning the ptrace event. A more
> detailed analysis is here:
> https://github.com/mozilla/rr/issues/1762#issuecomment-237396255.
>
> This bug has been in the kernel for a while. rr never hit it before because
> we trace all threads and mostly run only one tracee thread at a time.
> Immediately after each PTRACE_EVENT_SECCOMP notification we'd issue a
> PTRACE_SYSCALL to get that task to the syscall-entry PTRACE_SYSCALL stop, so
> there was never an opportunity for one tracee thread to call exit_group
> while another tracee was in the problematic part of __seccomp_filter().
> Unfortunately now there is no way for us to avoid that possibility.
>
> My guess is that __seccomp_filter() should dequeue the fatal signal it
> detects before calling do_exit(), to behave more like get_signal(). Is that
> correct, and if so, what would be the right way to do that?

Thanks for the detailed analysis! I'll take a look at what can be done
here. Off the top of my head, I don't see a problem with what you're
suggesting. Let me see what I can come up with.

-Kees

>
> Thanks,
> Robert O'Callahan
> --
> lbir ye,ea yer.tnietoehr  rdn rdsme,anea lurpr  edna e hnysnenh hhe uresyf
> toD
> selthor  stor  edna  siewaoeodm  or v sstvr  esBa  kbvted,t
> rdsme,aoreseoouoto
> o l euetiuruewFa  kbn e hnystoivateweh uresyf tulsa rehr  rdm  or rnea lurpr
> .a war hsrer holsa rodvted,t  nenh hneireseoouot.tniesiewaoeivatewt sstvr
> esn



-- 
Kees Cook
Brillo & Chrome OS Security

Re: "run seccomp after ptrace" changes expose "missing PTRACE_EVENT_EXIT" bug

[Kees Cook]

On Wed, Aug 3, 2016 at 4:51 PM, Robert O'Callahan  wrote:
> I work on rr (http://rr-project.org/), a record-and-replay reverse-execution
> debugger which is a heavy user of ptrace and seccomp. The recent change to
> perform syscall-entry PTRACE_SYSCALL stops before PTRACE_EVENT_SECCOMP stops
> broke rr, which is fine because I'm fixing rr and this change actually makes
> rr faster (thanks!). However, it exposed an existing kernel bug which
> creates a problem for us, and which I'm not sure how to fix.
>
> The problem is that if a tracee task is in a PTRACE_EVENT_SECCOMP trap, or
> has been resumed after such a trap but not yet been scheduled, and another
> task in the thread-group calls exit_group(), then the tracee task exits
> without the ptracer receiving a PTRACE_EVENT_EXIT notification. Small-ish
> testcase here:
> https://gist.github.com/rocallahan/1344f7d01183c233d08a2c6b93413068.
>
> The bug happens because when __seccomp_filter() detects
> fatal_signal_pending(), it calls do_exit() without dequeuing the fatal
> signal. When do_exit() sends the PTRACE_EVENT_EXIT notification and that
> task is descheduled, __schedule() notices that there is a fatal signal
> pending and changes its state from TASK_TRACED to TASK_RUNNING. That
> prevents the ptracer's waitpid() from returning the ptrace event. A more
> detailed analysis is here:
> https://github.com/mozilla/rr/issues/1762#issuecomment-237396255.
>
> This bug has been in the kernel for a while. rr never hit it before because
> we trace all threads and mostly run only one tracee thread at a time.
> Immediately after each PTRACE_EVENT_SECCOMP notification we'd issue a
> PTRACE_SYSCALL to get that task to the syscall-entry PTRACE_SYSCALL stop, so
> there was never an opportunity for one tracee thread to call exit_group
> while another tracee was in the problematic part of __seccomp_filter().
> Unfortunately now there is no way for us to avoid that possibility.
>
> My guess is that __seccomp_filter() should dequeue the fatal signal it
> detects before calling do_exit(), to behave more like get_signal(). Is that
> correct, and if so, what would be the right way to do that?

Thanks for the detailed analysis! I'll take a look at what can be done
here. Off the top of my head, I don't see a problem with what you're
suggesting. Let me see what I can come up with.

-Kees

>
> Thanks,
> Robert O'Callahan
> --
> lbir ye,ea yer.tnietoehr  rdn rdsme,anea lurpr  edna e hnysnenh hhe uresyf
> toD
> selthor  stor  edna  siewaoeodm  or v sstvr  esBa  kbvted,t
> rdsme,aoreseoouoto
> o l euetiuruewFa  kbn e hnystoivateweh uresyf tulsa rehr  rdm  or rnea lurpr
> .a war hsrer holsa rodvted,t  nenh hneireseoouot.tniesiewaoeivatewt sstvr
> esn



-- 
Kees Cook
Brillo & Chrome OS Security

Re: [GIT PULL] Thermal SoC management updates for v4.8-rc1

[Zhang Rui]

On 三, 2016-08-03 at 16:26 -0700, Eduardo Valentin wrote:
> On Wed, Aug 03, 2016 at 03:58:47PM -0700, Eduardo Valentin wrote:
> > 
> > Hello Rui,
> > 
> > Please pull from
> So, forgot to mention that I have been away from upstream work for
> some
> time now, and I am still catching up on my emails.
> 
> I've just realized that this may be a bit too late for the pull. I
> saw
> that you had some comments on the thermal subsystem reorg. Let me
> know
> if this pull still causes troubles. We can always post pone to next
> merge window.
> 
Yes, there are two updated patch from me to fix two different problems,
which are not included in your pull request, plus, I believe there is
still another problem reported by lkp, which is not addressed yet.
> 
> Let me know how you want to handle this one.
> 
I believe a new pull request without the thermal reorg and locking
changes is needed.

thanks,
rui

Re: [GIT PULL] Thermal SoC management updates for v4.8-rc1

[Zhang Rui]

On 三, 2016-08-03 at 16:26 -0700, Eduardo Valentin wrote:
> On Wed, Aug 03, 2016 at 03:58:47PM -0700, Eduardo Valentin wrote:
> > 
> > Hello Rui,
> > 
> > Please pull from
> So, forgot to mention that I have been away from upstream work for
> some
> time now, and I am still catching up on my emails.
> 
> I've just realized that this may be a bit too late for the pull. I
> saw
> that you had some comments on the thermal subsystem reorg. Let me
> know
> if this pull still causes troubles. We can always post pone to next
> merge window.
> 
Yes, there are two updated patch from me to fix two different problems,
which are not included in your pull request, plus, I believe there is
still another problem reported by lkp, which is not addressed yet.
> 
> Let me know how you want to handle this one.
> 
I believe a new pull request without the thermal reorg and locking
changes is needed.

thanks,
rui

[PATCH] .mailmap: Correct entries for Mauro Carvalho Chehab and Shuah Khan

[Joe Perches]

mailmap entries may not use more than 2 email addresses per line.

Signed-off-by: Joe Perches 
---
 .mailmap | 13 +++--
 1 file changed, 11 insertions(+), 2 deletions(-)

diff --git a/.mailmap b/.mailmap
index c0d5704..2a91c14c 100644
--- a/.mailmap
+++ b/.mailmap
@@ -96,7 +96,13 @@ Linus Lüssing  

 Linus Lüssing  
 Mark Brown 
 Matthieu CASTET 
-Mauro Carvalho Chehab   
   
 
+Mauro Carvalho Chehab  
+Mauro Carvalho Chehab  
+Mauro Carvalho Chehab  
+Mauro Carvalho Chehab  
+Mauro Carvalho Chehab  
+Mauro Carvalho Chehab  
+Mauro Carvalho Chehab  
 Matt Ranostay  Matthew Ranostay 

 Matt Ranostay  
 Mayuresh Janorkar 
@@ -132,7 +138,10 @@ Santosh Shilimkar 
 Sascha Hauer 
 S.Çağlar Onur 
 Shiraz Hashim  
-Shuah Khan    
 
+Shuah Khan  
+Shuah Khan  
+Shuah Khan  
+Shuah Khan  
 Simon Kelley 
 Stéphane Witzmann 
 Stephen Hemminger 
-- 
2.8.0.rc4.16.g56331f8

[PATCH] .mailmap: Correct entries for Mauro Carvalho Chehab and Shuah Khan

[Joe Perches]

mailmap entries may not use more than 2 email addresses per line.

Signed-off-by: Joe Perches 
---
 .mailmap | 13 +++--
 1 file changed, 11 insertions(+), 2 deletions(-)

diff --git a/.mailmap b/.mailmap
index c0d5704..2a91c14c 100644
--- a/.mailmap
+++ b/.mailmap
@@ -96,7 +96,13 @@ Linus Lüssing  

 Linus Lüssing  
 Mark Brown 
 Matthieu CASTET 
-Mauro Carvalho Chehab   
   
 
+Mauro Carvalho Chehab  
+Mauro Carvalho Chehab  
+Mauro Carvalho Chehab  
+Mauro Carvalho Chehab  
+Mauro Carvalho Chehab  
+Mauro Carvalho Chehab  
+Mauro Carvalho Chehab  
 Matt Ranostay  Matthew Ranostay 

 Matt Ranostay  
 Mayuresh Janorkar 
@@ -132,7 +138,10 @@ Santosh Shilimkar 
 Sascha Hauer 
 S.Çağlar Onur 
 Shiraz Hashim  
-Shuah Khan
 
+Shuah Khan  
+Shuah Khan  
+Shuah Khan  
+Shuah Khan  
 Simon Kelley 
 Stéphane Witzmann 
 Stephen Hemminger 
-- 
2.8.0.rc4.16.g56331f8

RE: Kernel panics while creating RAID volume on latest stable 4.6.2 kernel beacuse of "[PATCH v2 3/3] ses: fix discovery of SATA devices in SAS enclosures"

[Chaitra Basappa]

Any updates on this ???

Thanks,
 Chaitra

-Original Message-
From: Chaitra Basappa [mailto:chaitra.basa...@broadcom.com]
Sent: Friday, June 17, 2016 4:04 PM
To: linux-kernel@vger.kernel.org; Linux SCSI Mailinglist; James Bottomley
Subject: Kernel panics while creating RAID volume on latest stable 4.6.2
kernel beacuse of "[PATCH v2 3/3] ses: fix discovery of SATA devices in SAS
enclosures"
Importance: High

Hi,
 Try creating RAID volume on latest stable 4.6.2 kernel, as soon as the
volume gets created kernel panics , below are the logs...

Carried out same experimentation on 4.4.13 kernel, issue was not
observed.After learning diff b/w 4.4.13 & 4.6.2 kernels "[PATCH v2  3/3]
ses: fix discovery of SATA devices in SAS enclosures" patch looks to be
suspicious.
commit 3f8d6f2a0797e8c650a47e5c1b5c2601a46f4293

And hence reverted above mentioned patch changes from 4.6.2 kernel and tried
volume creation, volume created successfully and issue is not observed.

>>Kernel panic logs:

root@dhcp-135-24-192-112 ~]# sd 0:1:0:0: [sdw] No Caching mode page found sd
0:1:0:0: [sdw] Assuming drive cache: write through [ cut
here ] kernel BUG at drivers/scsi/scsi_transport_sas.c:164!
invalid opcode:  [#1] SMP
Modules linked in: mptctl mptbase ses enclosure ebtable_nat ebtables
xt_CHECKSUM iptable_mangle bridge autofs4 8021q garp stp llc ipt_REJECT
nf_reject_ipv4 nf_conntrack_ipv4 nf_defrag_ipv4 iptable_filter ip_tables
ip6t_REJECT nf_reject_ipv6 nf_conntrack_ipv6 nf_defrag_ipv6 xt_state
nf_conntrack ip6table_filter ip6_tables ipv6 vhost_net macvtap macvlan vhost
tun kvm_intel kvm irqbypass uinput ipmi_devintf iTCO_wdt iTCO_vendor_support
dcdbas pcspkr ipmi_si ipmi_msghandler acpi_pad sb_edac edac_core wmi sg
lpc_ich mfd_core shpchp tg3 ptp pps_core joydev ioatdma dca ext4(E)
mbcache(E) jbd2(E) sd_mod(E) ahci(E) libahci(E) mpt3sas(E)
scsi_transport_sas(E) raid_class(E) dm_mirror(E) dm_region_hash(E)
dm_log(E) dm_mod(E) [last unloaded: speedstep_lib]
CPU: 1 PID: 375 Comm: kworker/u96:4 Tainted: GE   4.6.2 #1
Hardware name: Dell Inc. PowerEdge T420/03015M, BIOS 2.2.0 02/06/2014
Workqueue: fw_event_mpt3sas0 _firmware_event_work [mpt3sas]
task: 8800377f6480 ti: 8800c62c8000 task.ti: 8800c62c8000
RIP: 0010:[]  []
sas_get_address+0x26/0x30 [scsi_transport_sas]
RSP: 0018:8800c62cb8a8  EFLAGS: 00010282
RAX: 8800c6986208 RBX: 8800b04ec800 RCX: 8800b3deaac4
RDX: 002b RSI:  RDI: 8800b04ec800
RBP: 8800c62cb8a8 R08:  R09: 0008
R10:  R11: 0001 R12: 8800b04ec800
R13:  R14: 8800b04ec998 R15: 
FS:  () GS:88012f02()
knlGS:
CS:  0010 DS:  ES:  CR0: 80050033
CR2: ff600400 CR3: 01c06000 CR4: 000406e0
Stack:
 8800c62cb8d8 a066bc62  
 8800b04ecc68 880128ee8000 8800c62cb938 a066bd5c
 8800b04ecef8 81608333 8800b04ec800 8800b04ecc68 Call
Trace:
 [] ses_match_to_enclosure+0x72/0x80 [ses]
[] ses_intf_add+0xec/0x494 [ses]  [] ?
preempt_schedule_common+0x23/0x40  []
device_add+0x278/0x440  [] ? __pm_runtime_resume+0x6c/0x90
[] scsi_sysfs_add_sdev+0xee/0x2b0  []
scsi_add_lun+0x437/0x580  []
scsi_probe_and_add_lun+0x1bb/0x4e0
 [] ? get_device+0x19/0x20  [] ?
scsi_alloc_target+0x293/0x320  [] ?
__pm_runtime_resume+0x6c/0x90  []
__scsi_add_device+0x10f/0x130  []
scsi_add_device+0x11/0x30  []
_scsih_sas_volume_add+0xf9/0x1b0 [mpt3sas]  []
_scsih_sas_ir_config_change_event+0xdb/0x210
[mpt3sas]
 [] _mpt3sas_fw_work+0xc1/0x480 [mpt3sas]
[] ? pwq_dec_nr_in_flight+0x50/0xa0  []
_firmware_event_work+0x19/0x20 [mpt3sas]  []
process_one_work+0x189/0x4e0  [] ?
del_timer_sync+0x4c/0x60  [] ?
maybe_create_worker+0x8e/0x110  [] ? schedule+0x40/0xb0
[] worker_thread+0x16d/0x520  [] ?
default_wake_function+0x12/0x20  [] ?
__wake_up_common+0x56/0x90  [] ?
maybe_create_worker+0x110/0x110  [] ? schedule+0x40/0xb0
[] ? maybe_create_worker+0x110/0x110  []
kthread+0xcc/0xf0  [] ? schedule_tail+0x1e/0xc0
[] ret_from_fork+0x22/0x40  [] ?
kthread_freezable_should_stop+0x70/0x70
Code: 0f 1f 44 00 00 55 48 89 e5 66 66 66 66 90 48 8b 87 28 01 00 00 48 8b
40 28 83 b8 d0 02 00 00 01 75 09 48 8b 80 e0 02 00 00 c9 c3 <0f> 0b eb fe
66 0f 1f 44 00 00 55 48 89 e5 53 48 83 ec 08 66 66 RIP  []
sas_get_address+0x26/0x30 [scsi_transport_sas]  RSP
 ---[ end trace c8c9da69e1dcb8a1 ]---
BUG: unable to handle kernel paging request at ffd8
IP: [] kthread_data+0x10/0x20 PGD 1c07067 PUD 1c09067 PMD
0
Oops:  [#2] SMP
Modules linked in: mptctl mptbase ses enclosure ebtable_nat ebtables
xt_CHECKSUM iptable_mangle bridge autofs4 8021q garp stp llc ipt_REJECT
nf_reject_ipv4 nf_conntrack_ipv4 nf_defrag_ipv4 iptable_filter ip_tables
ip6t_REJECT nf_reject_ipv6 nf_conntrack_ipv6 nf_defrag_ipv6 xt_state
nf_conntrack 

RE: Kernel panics while creating RAID volume on latest stable 4.6.2 kernel beacuse of "[PATCH v2 3/3] ses: fix discovery of SATA devices in SAS enclosures"

[Chaitra Basappa]

Any updates on this ???

Thanks,
 Chaitra

-Original Message-
From: Chaitra Basappa [mailto:chaitra.basa...@broadcom.com]
Sent: Friday, June 17, 2016 4:04 PM
To: linux-kernel@vger.kernel.org; Linux SCSI Mailinglist; James Bottomley
Subject: Kernel panics while creating RAID volume on latest stable 4.6.2
kernel beacuse of "[PATCH v2 3/3] ses: fix discovery of SATA devices in SAS
enclosures"
Importance: High

Hi,
 Try creating RAID volume on latest stable 4.6.2 kernel, as soon as the
volume gets created kernel panics , below are the logs...

Carried out same experimentation on 4.4.13 kernel, issue was not
observed.After learning diff b/w 4.4.13 & 4.6.2 kernels "[PATCH v2  3/3]
ses: fix discovery of SATA devices in SAS enclosures" patch looks to be
suspicious.
commit 3f8d6f2a0797e8c650a47e5c1b5c2601a46f4293

And hence reverted above mentioned patch changes from 4.6.2 kernel and tried
volume creation, volume created successfully and issue is not observed.

>>Kernel panic logs:

root@dhcp-135-24-192-112 ~]# sd 0:1:0:0: [sdw] No Caching mode page found sd
0:1:0:0: [sdw] Assuming drive cache: write through [ cut
here ] kernel BUG at drivers/scsi/scsi_transport_sas.c:164!
invalid opcode:  [#1] SMP
Modules linked in: mptctl mptbase ses enclosure ebtable_nat ebtables
xt_CHECKSUM iptable_mangle bridge autofs4 8021q garp stp llc ipt_REJECT
nf_reject_ipv4 nf_conntrack_ipv4 nf_defrag_ipv4 iptable_filter ip_tables
ip6t_REJECT nf_reject_ipv6 nf_conntrack_ipv6 nf_defrag_ipv6 xt_state
nf_conntrack ip6table_filter ip6_tables ipv6 vhost_net macvtap macvlan vhost
tun kvm_intel kvm irqbypass uinput ipmi_devintf iTCO_wdt iTCO_vendor_support
dcdbas pcspkr ipmi_si ipmi_msghandler acpi_pad sb_edac edac_core wmi sg
lpc_ich mfd_core shpchp tg3 ptp pps_core joydev ioatdma dca ext4(E)
mbcache(E) jbd2(E) sd_mod(E) ahci(E) libahci(E) mpt3sas(E)
scsi_transport_sas(E) raid_class(E) dm_mirror(E) dm_region_hash(E)
dm_log(E) dm_mod(E) [last unloaded: speedstep_lib]
CPU: 1 PID: 375 Comm: kworker/u96:4 Tainted: GE   4.6.2 #1
Hardware name: Dell Inc. PowerEdge T420/03015M, BIOS 2.2.0 02/06/2014
Workqueue: fw_event_mpt3sas0 _firmware_event_work [mpt3sas]
task: 8800377f6480 ti: 8800c62c8000 task.ti: 8800c62c8000
RIP: 0010:[]  []
sas_get_address+0x26/0x30 [scsi_transport_sas]
RSP: 0018:8800c62cb8a8  EFLAGS: 00010282
RAX: 8800c6986208 RBX: 8800b04ec800 RCX: 8800b3deaac4
RDX: 002b RSI:  RDI: 8800b04ec800
RBP: 8800c62cb8a8 R08:  R09: 0008
R10:  R11: 0001 R12: 8800b04ec800
R13:  R14: 8800b04ec998 R15: 
FS:  () GS:88012f02()
knlGS:
CS:  0010 DS:  ES:  CR0: 80050033
CR2: ff600400 CR3: 01c06000 CR4: 000406e0
Stack:
 8800c62cb8d8 a066bc62  
 8800b04ecc68 880128ee8000 8800c62cb938 a066bd5c
 8800b04ecef8 81608333 8800b04ec800 8800b04ecc68 Call
Trace:
 [] ses_match_to_enclosure+0x72/0x80 [ses]
[] ses_intf_add+0xec/0x494 [ses]  [] ?
preempt_schedule_common+0x23/0x40  []
device_add+0x278/0x440  [] ? __pm_runtime_resume+0x6c/0x90
[] scsi_sysfs_add_sdev+0xee/0x2b0  []
scsi_add_lun+0x437/0x580  []
scsi_probe_and_add_lun+0x1bb/0x4e0
 [] ? get_device+0x19/0x20  [] ?
scsi_alloc_target+0x293/0x320  [] ?
__pm_runtime_resume+0x6c/0x90  []
__scsi_add_device+0x10f/0x130  []
scsi_add_device+0x11/0x30  []
_scsih_sas_volume_add+0xf9/0x1b0 [mpt3sas]  []
_scsih_sas_ir_config_change_event+0xdb/0x210
[mpt3sas]
 [] _mpt3sas_fw_work+0xc1/0x480 [mpt3sas]
[] ? pwq_dec_nr_in_flight+0x50/0xa0  []
_firmware_event_work+0x19/0x20 [mpt3sas]  []
process_one_work+0x189/0x4e0  [] ?
del_timer_sync+0x4c/0x60  [] ?
maybe_create_worker+0x8e/0x110  [] ? schedule+0x40/0xb0
[] worker_thread+0x16d/0x520  [] ?
default_wake_function+0x12/0x20  [] ?
__wake_up_common+0x56/0x90  [] ?
maybe_create_worker+0x110/0x110  [] ? schedule+0x40/0xb0
[] ? maybe_create_worker+0x110/0x110  []
kthread+0xcc/0xf0  [] ? schedule_tail+0x1e/0xc0
[] ret_from_fork+0x22/0x40  [] ?
kthread_freezable_should_stop+0x70/0x70
Code: 0f 1f 44 00 00 55 48 89 e5 66 66 66 66 90 48 8b 87 28 01 00 00 48 8b
40 28 83 b8 d0 02 00 00 01 75 09 48 8b 80 e0 02 00 00 c9 c3 <0f> 0b eb fe
66 0f 1f 44 00 00 55 48 89 e5 53 48 83 ec 08 66 66 RIP  []
sas_get_address+0x26/0x30 [scsi_transport_sas]  RSP
 ---[ end trace c8c9da69e1dcb8a1 ]---
BUG: unable to handle kernel paging request at ffd8
IP: [] kthread_data+0x10/0x20 PGD 1c07067 PUD 1c09067 PMD
0
Oops:  [#2] SMP
Modules linked in: mptctl mptbase ses enclosure ebtable_nat ebtables
xt_CHECKSUM iptable_mangle bridge autofs4 8021q garp stp llc ipt_REJECT
nf_reject_ipv4 nf_conntrack_ipv4 nf_defrag_ipv4 iptable_filter ip_tables
ip6t_REJECT nf_reject_ipv6 nf_conntrack_ipv6 nf_defrag_ipv6 xt_state
nf_conntrack 

[PATCH 2/2] power: reset: syscon-reboot-mode: Use managed resource API

[Bjorn Andersson]

Use the managed resource version of reboot_mode_register().

Cc: John Stultz 
Signed-off-by: Bjorn Andersson 
---

John, here's a "pointer" to what I meant with my comment on your
sram-reboot-mode patch. Only compile tested though.

 drivers/power/reset/syscon-reboot-mode.c | 12 +---
 1 file changed, 1 insertion(+), 11 deletions(-)

diff --git a/drivers/power/reset/syscon-reboot-mode.c 
b/drivers/power/reset/syscon-reboot-mode.c
index 9e1cba5dd58e..1ecb51d67149 100644
--- a/drivers/power/reset/syscon-reboot-mode.c
+++ b/drivers/power/reset/syscon-reboot-mode.c
@@ -53,8 +53,6 @@ static int syscon_reboot_mode_probe(struct platform_device 
*pdev)
syscon_rbm->reboot.write = syscon_reboot_mode_write;
syscon_rbm->mask = 0x;
 
-   dev_set_drvdata(>dev, syscon_rbm);
-
syscon_rbm->map = syscon_node_to_regmap(pdev->dev.parent->of_node);
if (IS_ERR(syscon_rbm->map))
return PTR_ERR(syscon_rbm->map);
@@ -65,20 +63,13 @@ static int syscon_reboot_mode_probe(struct platform_device 
*pdev)
 
of_property_read_u32(pdev->dev.of_node, "mask", _rbm->mask);
 
-   ret = reboot_mode_register(_rbm->reboot);
+   ret = devm_reboot_mode_register(>dev, _rbm->reboot);
if (ret)
dev_err(>dev, "can't register reboot mode\n");
 
return ret;
 }
 
-static int syscon_reboot_mode_remove(struct platform_device *pdev)
-{
-   struct syscon_reboot_mode *syscon_rbm = dev_get_drvdata(>dev);
-
-   return reboot_mode_unregister(_rbm->reboot);
-}
-
 static const struct of_device_id syscon_reboot_mode_of_match[] = {
{ .compatible = "syscon-reboot-mode" },
{}
@@ -86,7 +77,6 @@ static const struct of_device_id 
syscon_reboot_mode_of_match[] = {
 
 static struct platform_driver syscon_reboot_mode_driver = {
.probe = syscon_reboot_mode_probe,
-   .remove = syscon_reboot_mode_remove,
.driver = {
.name = "syscon-reboot-mode",
.of_match_table = syscon_reboot_mode_of_match,
-- 
2.5.0

[bug, 4.8] /proc/meminfo: counter values are very wrong

[Dave Chinner]

Hi folks,

I just noticed a whacky memory usage profile when running some basic
IO tests on a current 4.8 tree. It looked like there was a massive
memory leak from my monitoring graphs - doing buffered IO was
causing huge amounts of memory to be considered used, but the cache
size was not increasing.

Looking at /proc/meminfo:

$ cat /proc/meminfo
MemTotal:   16395408 kB
MemFree:   79424 kB
MemAvailable:2497240 kB
Buffers:4372 kB
Cached:   558744 kB
SwapCached:   48 kB
Active:  2127212 kB
Inactive: 100400 kB
Active(anon):  25348 kB
Inactive(anon):79424 kB
Active(file):2101864 kB
Inactive(file):20976 kB
Unevictable:13612980 kB <
Mlocked:3516 kB
SwapTotal:497976 kB
SwapFree: 497188 kB
Dirty: 0 kB
Writeback: 0 kB
AnonPages: 38784 kB
Mapped:15880 kB
Shmem:  8808 kB
Slab: 460408 kB
SReclaimable: 428496 kB
SUnreclaim:31912 kB
KernelStack:6112 kB
PageTables: 6740 kB
NFS_Unstable:  0 kB
Bounce:0 kB
WritebackTmp:  0 kB
CommitLimit: 8695680 kB
Committed_AS: 177456 kB
VmallocTotal:   34359738367 kB
VmallocUsed:   0 kB
VmallocChunk:  0 kB
HugePages_Total:   0
HugePages_Free:0
HugePages_Rsvd:0
HugePages_Surp:0
Hugepagesize:   2048 kB
DirectMap4k:   14204 kB
DirectMap2M:16762880 kB

It seems that whatever was happening was causing unevictable memory
to pile up. But when I look at the per-node stats, the memory is all
accounted as active file pages:

$ cat /sys/bus/node/devices/node0/meminfo 
Node 0 MemTotal:4029052 kB
Node 0 MemFree:   33276 kB
Node 0 MemUsed: 3995776 kB
Node 0 Active:  3283280 kB
Node 0 Inactive: 580668 kB
Node 0 Active(anon):   3564 kB
Node 0 Inactive(anon): 4716 kB
Node 0 Active(file):3279716 kB 
Node 0 Inactive(file):   575952 kB
Node 0 Unevictable:1648 kB
Node 0 Mlocked:1648 kB
Node 0 Dirty: 8 kB
Node 0 Writeback: 0 kB
Node 0 FilePages: 78796 kB
Node 0 Mapped: 5540 kB
Node 0 AnonPages:  8020 kB
Node 0 Shmem:   256 kB
Node 0 KernelStack:2352 kB
Node 0 PageTables: 1976 kB
Node 0 NFS_Unstable:  0 kB
Node 0 Bounce:0 kB
Node 0 WritebackTmp:  0 kB
Node 0 Slab: 109012 kB
Node 0 SReclaimable:  99156 kB
Node 0 SUnreclaim: 9856 kB
Node 0 HugePages_Total: 0
Node 0 HugePages_Free:  0
Node 0 HugePages_Surp:  0
$ cat /sys/bus/node/devices/node1/meminfo 
Node 1 MemTotal:4127912 kB
Node 1 MemFree:   13888 kB
Node 1 MemUsed: 4114024 kB
Node 1 Active:  3455400 kB
Node 1 Inactive: 522156 kB
Node 1 Active(anon):   5556 kB
Node 1 Inactive(anon): 6784 kB
Node 1 Active(file):3449844 kB
Node 1 Inactive(file):   515372 kB
Node 1 Unevictable:  52 kB
Node 1 Mlocked:  52 kB
Node 1 Dirty:16 kB
Node 1 Writeback: 0 kB
Node 1 FilePages:155684 kB
Node 1 Mapped: 2216 kB
Node 1 AnonPages: 12320 kB
Node 1 Shmem:16 kB
Node 1 KernelStack: 720 kB
Node 1 PageTables: 1120 kB
Node 1 NFS_Unstable:  0 kB
Node 1 Bounce:0 kB
Node 1 WritebackTmp:  0 kB
Node 1 Slab: 117340 kB
Node 1 SReclaimable: 111472 kB
Node 1 SUnreclaim: 5868 kB
Node 1 HugePages_Total: 0
Node 1 HugePages_Free:  0
Node 1 HugePages_Surp:  0
$ cat /sys/bus/node/devices/node2/meminfo 
Node 2 MemTotal:4127912 kB
Node 2 MemFree:   21308 kB
Node 2 MemUsed: 4106604 kB
Node 2 Active:  3453056 kB
Node 2 Inactive: 517824 kB
Node 2 Active(anon):   3224 kB
Node 2 Inactive(anon): 4356 kB
Node 2 Active(file):3449832 kB
Node 2 Inactive(file):   513468 kB
Node 2 Unevictable: 556 kB
Node 2 Mlocked: 556 kB
Node 2 Dirty: 0 kB
Node 2 Writeback: 0 kB
Node 2 FilePages:150120 kB
Node 2 Mapped: 1840 kB
Node 2 AnonPages:  7476 kB
Node 2 Shmem:   232 kB
Node 2 KernelStack:1184 kB
Node 2 PageTables: 1360 kB
Node 2 NFS_Unstable:  0 kB
Node 2 Bounce:0 kB
Node 2 WritebackTmp:  0 kB
Node 2 Slab: 114288 kB
Node 2 SReclaimable: 107616 kB
Node 2 SUnreclaim: 6672 kB
Node 2 HugePages_Total: 0
Node 2 HugePages_Free:  0
Node 2 HugePages_Surp:  0
$ cat /sys/bus/node/devices/node3/meminfo 
Node 3 MemTotal:4110532 kB
Node 3 MemFree:   10224 kB
Node 3 MemUsed: 4100308 kB
Node 3 Active:  3442224 kB
Node 3 Inactive: 506564 kB
Node 3 Active(anon):   8636 kB
Node 3 Inactive(anon): 9492 kB

[PATCH 2/2] power: reset: syscon-reboot-mode: Use managed resource API

[Bjorn Andersson]

Use the managed resource version of reboot_mode_register().

Cc: John Stultz 
Signed-off-by: Bjorn Andersson 
---

John, here's a "pointer" to what I meant with my comment on your
sram-reboot-mode patch. Only compile tested though.

 drivers/power/reset/syscon-reboot-mode.c | 12 +---
 1 file changed, 1 insertion(+), 11 deletions(-)

diff --git a/drivers/power/reset/syscon-reboot-mode.c 
b/drivers/power/reset/syscon-reboot-mode.c
index 9e1cba5dd58e..1ecb51d67149 100644
--- a/drivers/power/reset/syscon-reboot-mode.c
+++ b/drivers/power/reset/syscon-reboot-mode.c
@@ -53,8 +53,6 @@ static int syscon_reboot_mode_probe(struct platform_device 
*pdev)
syscon_rbm->reboot.write = syscon_reboot_mode_write;
syscon_rbm->mask = 0x;
 
-   dev_set_drvdata(>dev, syscon_rbm);
-
syscon_rbm->map = syscon_node_to_regmap(pdev->dev.parent->of_node);
if (IS_ERR(syscon_rbm->map))
return PTR_ERR(syscon_rbm->map);
@@ -65,20 +63,13 @@ static int syscon_reboot_mode_probe(struct platform_device 
*pdev)
 
of_property_read_u32(pdev->dev.of_node, "mask", _rbm->mask);
 
-   ret = reboot_mode_register(_rbm->reboot);
+   ret = devm_reboot_mode_register(>dev, _rbm->reboot);
if (ret)
dev_err(>dev, "can't register reboot mode\n");
 
return ret;
 }
 
-static int syscon_reboot_mode_remove(struct platform_device *pdev)
-{
-   struct syscon_reboot_mode *syscon_rbm = dev_get_drvdata(>dev);
-
-   return reboot_mode_unregister(_rbm->reboot);
-}
-
 static const struct of_device_id syscon_reboot_mode_of_match[] = {
{ .compatible = "syscon-reboot-mode" },
{}
@@ -86,7 +77,6 @@ static const struct of_device_id 
syscon_reboot_mode_of_match[] = {
 
 static struct platform_driver syscon_reboot_mode_driver = {
.probe = syscon_reboot_mode_probe,
-   .remove = syscon_reboot_mode_remove,
.driver = {
.name = "syscon-reboot-mode",
.of_match_table = syscon_reboot_mode_of_match,
-- 
2.5.0

[bug, 4.8] /proc/meminfo: counter values are very wrong

[Dave Chinner]

Hi folks,

I just noticed a whacky memory usage profile when running some basic
IO tests on a current 4.8 tree. It looked like there was a massive
memory leak from my monitoring graphs - doing buffered IO was
causing huge amounts of memory to be considered used, but the cache
size was not increasing.

Looking at /proc/meminfo:

$ cat /proc/meminfo
MemTotal:   16395408 kB
MemFree:   79424 kB
MemAvailable:2497240 kB
Buffers:4372 kB
Cached:   558744 kB
SwapCached:   48 kB
Active:  2127212 kB
Inactive: 100400 kB
Active(anon):  25348 kB
Inactive(anon):79424 kB
Active(file):2101864 kB
Inactive(file):20976 kB
Unevictable:13612980 kB <
Mlocked:3516 kB
SwapTotal:497976 kB
SwapFree: 497188 kB
Dirty: 0 kB
Writeback: 0 kB
AnonPages: 38784 kB
Mapped:15880 kB
Shmem:  8808 kB
Slab: 460408 kB
SReclaimable: 428496 kB
SUnreclaim:31912 kB
KernelStack:6112 kB
PageTables: 6740 kB
NFS_Unstable:  0 kB
Bounce:0 kB
WritebackTmp:  0 kB
CommitLimit: 8695680 kB
Committed_AS: 177456 kB
VmallocTotal:   34359738367 kB
VmallocUsed:   0 kB
VmallocChunk:  0 kB
HugePages_Total:   0
HugePages_Free:0
HugePages_Rsvd:0
HugePages_Surp:0
Hugepagesize:   2048 kB
DirectMap4k:   14204 kB
DirectMap2M:16762880 kB

It seems that whatever was happening was causing unevictable memory
to pile up. But when I look at the per-node stats, the memory is all
accounted as active file pages:

$ cat /sys/bus/node/devices/node0/meminfo 
Node 0 MemTotal:4029052 kB
Node 0 MemFree:   33276 kB
Node 0 MemUsed: 3995776 kB
Node 0 Active:  3283280 kB
Node 0 Inactive: 580668 kB
Node 0 Active(anon):   3564 kB
Node 0 Inactive(anon): 4716 kB
Node 0 Active(file):3279716 kB 
Node 0 Inactive(file):   575952 kB
Node 0 Unevictable:1648 kB
Node 0 Mlocked:1648 kB
Node 0 Dirty: 8 kB
Node 0 Writeback: 0 kB
Node 0 FilePages: 78796 kB
Node 0 Mapped: 5540 kB
Node 0 AnonPages:  8020 kB
Node 0 Shmem:   256 kB
Node 0 KernelStack:2352 kB
Node 0 PageTables: 1976 kB
Node 0 NFS_Unstable:  0 kB
Node 0 Bounce:0 kB
Node 0 WritebackTmp:  0 kB
Node 0 Slab: 109012 kB
Node 0 SReclaimable:  99156 kB
Node 0 SUnreclaim: 9856 kB
Node 0 HugePages_Total: 0
Node 0 HugePages_Free:  0
Node 0 HugePages_Surp:  0
$ cat /sys/bus/node/devices/node1/meminfo 
Node 1 MemTotal:4127912 kB
Node 1 MemFree:   13888 kB
Node 1 MemUsed: 4114024 kB
Node 1 Active:  3455400 kB
Node 1 Inactive: 522156 kB
Node 1 Active(anon):   5556 kB
Node 1 Inactive(anon): 6784 kB
Node 1 Active(file):3449844 kB
Node 1 Inactive(file):   515372 kB
Node 1 Unevictable:  52 kB
Node 1 Mlocked:  52 kB
Node 1 Dirty:16 kB
Node 1 Writeback: 0 kB
Node 1 FilePages:155684 kB
Node 1 Mapped: 2216 kB
Node 1 AnonPages: 12320 kB
Node 1 Shmem:16 kB
Node 1 KernelStack: 720 kB
Node 1 PageTables: 1120 kB
Node 1 NFS_Unstable:  0 kB
Node 1 Bounce:0 kB
Node 1 WritebackTmp:  0 kB
Node 1 Slab: 117340 kB
Node 1 SReclaimable: 111472 kB
Node 1 SUnreclaim: 5868 kB
Node 1 HugePages_Total: 0
Node 1 HugePages_Free:  0
Node 1 HugePages_Surp:  0
$ cat /sys/bus/node/devices/node2/meminfo 
Node 2 MemTotal:4127912 kB
Node 2 MemFree:   21308 kB
Node 2 MemUsed: 4106604 kB
Node 2 Active:  3453056 kB
Node 2 Inactive: 517824 kB
Node 2 Active(anon):   3224 kB
Node 2 Inactive(anon): 4356 kB
Node 2 Active(file):3449832 kB
Node 2 Inactive(file):   513468 kB
Node 2 Unevictable: 556 kB
Node 2 Mlocked: 556 kB
Node 2 Dirty: 0 kB
Node 2 Writeback: 0 kB
Node 2 FilePages:150120 kB
Node 2 Mapped: 1840 kB
Node 2 AnonPages:  7476 kB
Node 2 Shmem:   232 kB
Node 2 KernelStack:1184 kB
Node 2 PageTables: 1360 kB
Node 2 NFS_Unstable:  0 kB
Node 2 Bounce:0 kB
Node 2 WritebackTmp:  0 kB
Node 2 Slab: 114288 kB
Node 2 SReclaimable: 107616 kB
Node 2 SUnreclaim: 6672 kB
Node 2 HugePages_Total: 0
Node 2 HugePages_Free:  0
Node 2 HugePages_Surp:  0
$ cat /sys/bus/node/devices/node3/meminfo 
Node 3 MemTotal:4110532 kB
Node 3 MemFree:   10224 kB
Node 3 MemUsed: 4100308 kB
Node 3 Active:  3442224 kB
Node 3 Inactive: 506564 kB
Node 3 Active(anon):   8636 kB
Node 3 Inactive(anon): 9492 kB

[PATCH 1/2] power: reset: reboot-mode: Add managed resource API

[Bjorn Andersson]

Provide managed resource version of reboot_mode_register() and
reboot_mode_unregister() to simplify implementations.

Cc: John Stultz 
Signed-off-by: Bjorn Andersson 
---

John, here's a "pointer" to what I meant with my comment on your
sram-reboot-mode patch. Only compile tested though.

 Documentation/driver-model/devres.txt |  4 +++
 drivers/power/reset/reboot-mode.c | 59 +++
 drivers/power/reset/reboot-mode.h |  4 +++
 3 files changed, 67 insertions(+)

diff --git a/Documentation/driver-model/devres.txt 
b/Documentation/driver-model/devres.txt
index f5e522342ee5..fbb9fde1aad3 100644
--- a/Documentation/driver-model/devres.txt
+++ b/Documentation/driver-model/devres.txt
@@ -342,6 +342,10 @@ PINCTRL
   devm_pinctrl_register()
   devm_pinctrl_unregister()
 
+POWER
+  devm_reboot_mode_register()
+  devm_reboot_mode_unregister()
+
 PWM
   devm_pwm_get()
   devm_pwm_put()
diff --git a/drivers/power/reset/reboot-mode.c 
b/drivers/power/reset/reboot-mode.c
index 2dfbbce0f817..fb512183ace3 100644
--- a/drivers/power/reset/reboot-mode.c
+++ b/drivers/power/reset/reboot-mode.c
@@ -135,6 +135,65 @@ int reboot_mode_unregister(struct reboot_mode_driver 
*reboot)
 }
 EXPORT_SYMBOL_GPL(reboot_mode_unregister);
 
+static void devm_reboot_mode_release(struct device *dev, void *res)
+{
+   reboot_mode_unregister(*(struct reboot_mode_driver **)res);
+}
+
+/**
+ * devm_reboot_mode_register() - resource managed reboot_mode_register()
+ * @dev: device to associate this resource with
+ * @reboot: reboot mode driver
+ *
+ * Returns: 0 on success or a negative error code on failure.
+ */
+int devm_reboot_mode_register(struct device *dev,
+ struct reboot_mode_driver *reboot)
+{
+   struct reboot_mode_driver **dr;
+   int rc;
+
+   dr = devres_alloc(devm_reboot_mode_release, sizeof(*dr), GFP_KERNEL);
+   if (!dr)
+   return -ENOMEM;
+
+   rc = reboot_mode_register(reboot);
+   if (rc) {
+   devres_free(dr);
+   return rc;
+   }
+
+   *dr = reboot;
+   devres_add(dev, dr);
+
+   return 0;
+}
+EXPORT_SYMBOL_GPL(devm_reboot_mode_register);
+
+static int devm_reboot_mode_match(struct device *dev, void *res, void *data)
+{
+   struct reboot_mode_driver **p = res;
+
+   if (WARN_ON(!p || !*p))
+   return 0;
+
+   return *p == data;
+}
+
+/**
+ * devm_reboot_mode_unregister() - resource managed reboot_mode_unregister()
+ * @dev: device to associate this resource with
+ * @reboot: reboot mode driver
+ */
+void devm_reboot_mode_unregister(struct device *dev,
+struct reboot_mode_driver *reboot)
+{
+   WARN_ON(devres_release(dev,
+  devm_reboot_mode_release,
+  devm_reboot_mode_match, reboot));
+}
+EXPORT_SYMBOL_GPL(devm_reboot_mode_unregister);
+
 MODULE_AUTHOR("Andy Yan 

Re: [RFC PATCH v7 1/7] Restartable sequences system call

[Andy Lutomirski]

On Wed, Aug 3, 2016 at 9:27 PM, Boqun Feng  wrote:
> On Wed, Aug 03, 2016 at 09:37:57AM -0700, Andy Lutomirski wrote:
>> On Wed, Aug 3, 2016 at 5:27 AM, Peter Zijlstra  wrote:
>> > On Tue, Jul 26, 2016 at 03:02:19AM +, Mathieu Desnoyers wrote:
>> >> We really care about preemption here. Every migration implies a
>> >> preemption from a user-space perspective. If we would only care
>> >> about keeping the CPU id up-to-date, hooking into migration would be
>> >> enough. But since we want atomicity guarantees for restartable
>> >> sequences, we need to hook into preemption.
>> >
>> >> It allows user-space to perform update operations on per-cpu data without
>> >> requiring heavy-weight atomic operations.
>> >
>> > Well, a CMPXCHG without LOCK prefix isn't all that expensive on x86.
>> >
>> > It is however on PPC and possibly other architectures, so in name of
>> > simplicity supporting only the one variant makes sense.
>> >
>>
>> I wouldn't want to depend on CMPXCHG.  But imagine we had primitives
>> that were narrower than the full abort-on-preemption primitive.
>> Specifically, suppose we had abort if (actual cpu != expected_cpu ||
>> *aptr != aval).  We could do things like:
>>
>> expected_cpu = cpu;
>> aval = NULL;  // disarm for now
>> begin();
>> aval = event_count[cpu] + 1;
>> event_count[cpu] = aval;
>> event_count[cpu]++;
>
> This line is redundant, right? Because it will guarantee a failure even
> in no-contention cases.
>
>>
>> ... compute something ...
>>
>> // arm the rest of it
>> aptr = _count[cpu];
>> if (*aptr != aval)
>>   goto fail;
>>
>> *thing_im_writing = value_i_computed;
>> end();
>>
>> The idea here is that we don't rely on the scheduler to increment the
>> event count at all, which means that we get to determine the scope of
>> what kinds of access conflicts we care about ourselves.
>>
>
> If we increase the event count in userspace, how could we prevent two
> userspace threads from racing on the event_count[cpu] field? For
> example:
>
> CPU 0
> 
> {event_count[0] is initially 0}
>
> [Thread 1]
> begin();
> aval = event_count[cpu] + 1; // 1
>
> (preempted)
> [Thread 2]
> begin();
> aval = event_count[cpu] + 1; // 1, too
> event_count[cpu] = aval; // event_count[0] is 1
>

You're right :(  This would work with an xadd instruction, but that's
very slow and doesn't exist on most architectures.  It could also work
if we did:

aval = some_tls_value++;

where some_tls_value is set up such that no two threads could ever end
up with the same values (using high bits as thread ids, perhaps), but
that's messy.  Maybe my idea is no good.

[PATCH 1/2] power: reset: reboot-mode: Add managed resource API

[Bjorn Andersson]

Provide managed resource version of reboot_mode_register() and
reboot_mode_unregister() to simplify implementations.

Cc: John Stultz 
Signed-off-by: Bjorn Andersson 
---

John, here's a "pointer" to what I meant with my comment on your
sram-reboot-mode patch. Only compile tested though.

 Documentation/driver-model/devres.txt |  4 +++
 drivers/power/reset/reboot-mode.c | 59 +++
 drivers/power/reset/reboot-mode.h |  4 +++
 3 files changed, 67 insertions(+)

diff --git a/Documentation/driver-model/devres.txt 
b/Documentation/driver-model/devres.txt
index f5e522342ee5..fbb9fde1aad3 100644
--- a/Documentation/driver-model/devres.txt
+++ b/Documentation/driver-model/devres.txt
@@ -342,6 +342,10 @@ PINCTRL
   devm_pinctrl_register()
   devm_pinctrl_unregister()
 
+POWER
+  devm_reboot_mode_register()
+  devm_reboot_mode_unregister()
+
 PWM
   devm_pwm_get()
   devm_pwm_put()
diff --git a/drivers/power/reset/reboot-mode.c 
b/drivers/power/reset/reboot-mode.c
index 2dfbbce0f817..fb512183ace3 100644
--- a/drivers/power/reset/reboot-mode.c
+++ b/drivers/power/reset/reboot-mode.c
@@ -135,6 +135,65 @@ int reboot_mode_unregister(struct reboot_mode_driver 
*reboot)
 }
 EXPORT_SYMBOL_GPL(reboot_mode_unregister);
 
+static void devm_reboot_mode_release(struct device *dev, void *res)
+{
+   reboot_mode_unregister(*(struct reboot_mode_driver **)res);
+}
+
+/**
+ * devm_reboot_mode_register() - resource managed reboot_mode_register()
+ * @dev: device to associate this resource with
+ * @reboot: reboot mode driver
+ *
+ * Returns: 0 on success or a negative error code on failure.
+ */
+int devm_reboot_mode_register(struct device *dev,
+ struct reboot_mode_driver *reboot)
+{
+   struct reboot_mode_driver **dr;
+   int rc;
+
+   dr = devres_alloc(devm_reboot_mode_release, sizeof(*dr), GFP_KERNEL);
+   if (!dr)
+   return -ENOMEM;
+
+   rc = reboot_mode_register(reboot);
+   if (rc) {
+   devres_free(dr);
+   return rc;
+   }
+
+   *dr = reboot;
+   devres_add(dev, dr);
+
+   return 0;
+}
+EXPORT_SYMBOL_GPL(devm_reboot_mode_register);
+
+static int devm_reboot_mode_match(struct device *dev, void *res, void *data)
+{
+   struct reboot_mode_driver **p = res;
+
+   if (WARN_ON(!p || !*p))
+   return 0;
+
+   return *p == data;
+}
+
+/**
+ * devm_reboot_mode_unregister() - resource managed reboot_mode_unregister()
+ * @dev: device to associate this resource with
+ * @reboot: reboot mode driver
+ */
+void devm_reboot_mode_unregister(struct device *dev,
+struct reboot_mode_driver *reboot)
+{
+   WARN_ON(devres_release(dev,
+  devm_reboot_mode_release,
+  devm_reboot_mode_match, reboot));
+}
+EXPORT_SYMBOL_GPL(devm_reboot_mode_unregister);
+
 MODULE_AUTHOR("Andy Yan 

Re: [RFC PATCH v7 1/7] Restartable sequences system call

[Andy Lutomirski]

On Wed, Aug 3, 2016 at 9:27 PM, Boqun Feng  wrote:
> On Wed, Aug 03, 2016 at 09:37:57AM -0700, Andy Lutomirski wrote:
>> On Wed, Aug 3, 2016 at 5:27 AM, Peter Zijlstra  wrote:
>> > On Tue, Jul 26, 2016 at 03:02:19AM +, Mathieu Desnoyers wrote:
>> >> We really care about preemption here. Every migration implies a
>> >> preemption from a user-space perspective. If we would only care
>> >> about keeping the CPU id up-to-date, hooking into migration would be
>> >> enough. But since we want atomicity guarantees for restartable
>> >> sequences, we need to hook into preemption.
>> >
>> >> It allows user-space to perform update operations on per-cpu data without
>> >> requiring heavy-weight atomic operations.
>> >
>> > Well, a CMPXCHG without LOCK prefix isn't all that expensive on x86.
>> >
>> > It is however on PPC and possibly other architectures, so in name of
>> > simplicity supporting only the one variant makes sense.
>> >
>>
>> I wouldn't want to depend on CMPXCHG.  But imagine we had primitives
>> that were narrower than the full abort-on-preemption primitive.
>> Specifically, suppose we had abort if (actual cpu != expected_cpu ||
>> *aptr != aval).  We could do things like:
>>
>> expected_cpu = cpu;
>> aval = NULL;  // disarm for now
>> begin();
>> aval = event_count[cpu] + 1;
>> event_count[cpu] = aval;
>> event_count[cpu]++;
>
> This line is redundant, right? Because it will guarantee a failure even
> in no-contention cases.
>
>>
>> ... compute something ...
>>
>> // arm the rest of it
>> aptr = _count[cpu];
>> if (*aptr != aval)
>>   goto fail;
>>
>> *thing_im_writing = value_i_computed;
>> end();
>>
>> The idea here is that we don't rely on the scheduler to increment the
>> event count at all, which means that we get to determine the scope of
>> what kinds of access conflicts we care about ourselves.
>>
>
> If we increase the event count in userspace, how could we prevent two
> userspace threads from racing on the event_count[cpu] field? For
> example:
>
> CPU 0
> 
> {event_count[0] is initially 0}
>
> [Thread 1]
> begin();
> aval = event_count[cpu] + 1; // 1
>
> (preempted)
> [Thread 2]
> begin();
> aval = event_count[cpu] + 1; // 1, too
> event_count[cpu] = aval; // event_count[0] is 1
>

You're right :(  This would work with an xadd instruction, but that's
very slow and doesn't exist on most architectures.  It could also work
if we did:

aval = some_tls_value++;

where some_tls_value is set up such that no two threads could ever end
up with the same values (using high bits as thread ids, perhaps), but
that's messy.  Maybe my idea is no good.

Re: [RFC PATCH v7 1/7] Restartable sequences system call

[Andy Lutomirski]

On Aug 3, 2016 11:31 AM, "Christoph Lameter"  wrote:
>
> On Wed, 3 Aug 2016, Andy Lutomirski wrote:
>
> > > Well, a CMPXCHG without LOCK prefix isn't all that expensive on x86.
> > >
> > > It is however on PPC and possibly other architectures, so in name of
> > > simplicity supporting only the one variant makes sense.
> > >
> >
> > I wouldn't want to depend on CMPXCHG.  But imagine we had primitives
> > that were narrower than the full abort-on-preemption primitive.
> > Specifically, suppose we had abort if (actual cpu != expected_cpu ||
> > *aptr != aval).  We could do things like:
> >
>
> The latency issues that are addressed by restartable sequences require
> minimim instruction overhead. Lockless CMPXCHG is very important in that
> area and I would not simply remove it from consideration.

What I mean is: I think the solution shouldn't depend on the
x86-specific unlocked CMPXCHG instruction if it can be avoided.

Re: [RFC PATCH v7 1/7] Restartable sequences system call

[Andy Lutomirski]

On Aug 3, 2016 11:31 AM, "Christoph Lameter"  wrote:
>
> On Wed, 3 Aug 2016, Andy Lutomirski wrote:
>
> > > Well, a CMPXCHG without LOCK prefix isn't all that expensive on x86.
> > >
> > > It is however on PPC and possibly other architectures, so in name of
> > > simplicity supporting only the one variant makes sense.
> > >
> >
> > I wouldn't want to depend on CMPXCHG.  But imagine we had primitives
> > that were narrower than the full abort-on-preemption primitive.
> > Specifically, suppose we had abort if (actual cpu != expected_cpu ||
> > *aptr != aval).  We could do things like:
> >
>
> The latency issues that are addressed by restartable sequences require
> minimim instruction overhead. Lockless CMPXCHG is very important in that
> area and I would not simply remove it from consideration.

What I mean is: I think the solution shouldn't depend on the
x86-specific unlocked CMPXCHG instruction if it can be avoided.

Re: [PATCH] iio: humidity: hdc100x: use i2c_master_recv to read sensor data

[Matt Ranostay]

On Wed, Aug 3, 2016 at 8:33 PM, Alison Schofield  wrote:
> Replace the i2c_smbus_read_byte commmands used to retrieve the sensor
> data with an i2c_master_recv command.
>
> The smbus read byte method fails because the device does not expect a
> stop condition after sending the first byte. When we issue the second
> read, we are getting the first byte again. Net effect is that of the 14
> bits used for the measurement, the 8 most significant bits are correct,
> the lower 6 are not.
>
> None of the smbus read protocols follow the pattern this device requires
> (S Addr Rd [A] Data [A] Data NA P), hence the switch to an i2c receive
> transaction.
>
> Signed-off-by: Alison Schofield 
> Cc: Daniel Baluta 
> ---
>  drivers/iio/humidity/hdc100x.c | 27 +++
>  1 file changed, 7 insertions(+), 20 deletions(-)
>
> diff --git a/drivers/iio/humidity/hdc100x.c b/drivers/iio/humidity/hdc100x.c
> index a03832a..643a42d 100644
> --- a/drivers/iio/humidity/hdc100x.c
> +++ b/drivers/iio/humidity/hdc100x.c
> @@ -142,7 +142,7 @@ static int hdc100x_get_measurement(struct hdc100x_data 
> *data,
> struct i2c_client *client = data->client;
> int delay = data->adc_int_us[chan->address];
> int ret;
> -   int val;
> +   u8 buf[2];
>
> /* start measurement */
> ret = i2c_smbus_write_byte(client, chan->address);
> @@ -154,26 +154,13 @@ static int hdc100x_get_measurement(struct hdc100x_data 
> *data,
> /* wait for integration time to pass */
> usleep_range(delay, delay + 1000);
>
> -   /*
> -* i2c_smbus_read_word_data cannot() be used here due to the command
> -* value not being understood and causes NAKs preventing any reading
> -* from being accessed.
> -*/
> -   ret = i2c_smbus_read_byte(client);
> +   /* read the 2 byte measurement */
> +   ret = i2c_master_recv(data->client, buf, 2);
> if (ret < 0) {
> -   dev_err(>dev, "cannot read high byte measurement");
> +   dev_err(>dev, "cannot read sensor data\n");
> return ret;
> }
> -   val = ret << 8;
> -
> -   ret = i2c_smbus_read_byte(client);
> -   if (ret < 0) {
> -   dev_err(>dev, "cannot read low byte measurement");
> -   return ret;
> -   }
> -   val |= ret;
> -
> -   return val;
> +   return (int)(buf[0] << 8 | buf[1]);

Pretty sure you don't need to cast to int type here.

>  }
>
>  static int hdc100x_get_heater_status(struct hdc100x_data *data)
> @@ -272,8 +259,8 @@ static int hdc100x_probe(struct i2c_client *client,
> struct iio_dev *indio_dev;
> struct hdc100x_data *data;
>
> -   if (!i2c_check_functionality(client->adapter,
> -   I2C_FUNC_SMBUS_WORD_DATA | 
> I2C_FUNC_SMBUS_BYTE))
> +   if (!i2c_check_functionality(client->adapter, 
> I2C_FUNC_SMBUS_WORD_DATA |
> +I2C_FUNC_SMBUS_BYTE | I2C_FUNC_I2C))

Not sure we want to kill smbus support for this device...  iwe should
have two read methods for i2c and smbus (see the PulsedLight LIDAR
driver) in this case.

Ideally I wouldn't have written it with only smbus in mind, but can
kill backwards compatibility unless we have a good reason.

Thanks,

Matt

> return -EOPNOTSUPP;
>
> indio_dev = devm_iio_device_alloc(>dev, sizeof(*data));
> --
> 2.1.4
>

Re: [PATCH] iio: humidity: hdc100x: use i2c_master_recv to read sensor data

[Matt Ranostay]

On Wed, Aug 3, 2016 at 8:33 PM, Alison Schofield  wrote:
> Replace the i2c_smbus_read_byte commmands used to retrieve the sensor
> data with an i2c_master_recv command.
>
> The smbus read byte method fails because the device does not expect a
> stop condition after sending the first byte. When we issue the second
> read, we are getting the first byte again. Net effect is that of the 14
> bits used for the measurement, the 8 most significant bits are correct,
> the lower 6 are not.
>
> None of the smbus read protocols follow the pattern this device requires
> (S Addr Rd [A] Data [A] Data NA P), hence the switch to an i2c receive
> transaction.
>
> Signed-off-by: Alison Schofield 
> Cc: Daniel Baluta 
> ---
>  drivers/iio/humidity/hdc100x.c | 27 +++
>  1 file changed, 7 insertions(+), 20 deletions(-)
>
> diff --git a/drivers/iio/humidity/hdc100x.c b/drivers/iio/humidity/hdc100x.c
> index a03832a..643a42d 100644
> --- a/drivers/iio/humidity/hdc100x.c
> +++ b/drivers/iio/humidity/hdc100x.c
> @@ -142,7 +142,7 @@ static int hdc100x_get_measurement(struct hdc100x_data 
> *data,
> struct i2c_client *client = data->client;
> int delay = data->adc_int_us[chan->address];
> int ret;
> -   int val;
> +   u8 buf[2];
>
> /* start measurement */
> ret = i2c_smbus_write_byte(client, chan->address);
> @@ -154,26 +154,13 @@ static int hdc100x_get_measurement(struct hdc100x_data 
> *data,
> /* wait for integration time to pass */
> usleep_range(delay, delay + 1000);
>
> -   /*
> -* i2c_smbus_read_word_data cannot() be used here due to the command
> -* value not being understood and causes NAKs preventing any reading
> -* from being accessed.
> -*/
> -   ret = i2c_smbus_read_byte(client);
> +   /* read the 2 byte measurement */
> +   ret = i2c_master_recv(data->client, buf, 2);
> if (ret < 0) {
> -   dev_err(>dev, "cannot read high byte measurement");
> +   dev_err(>dev, "cannot read sensor data\n");
> return ret;
> }
> -   val = ret << 8;
> -
> -   ret = i2c_smbus_read_byte(client);
> -   if (ret < 0) {
> -   dev_err(>dev, "cannot read low byte measurement");
> -   return ret;
> -   }
> -   val |= ret;
> -
> -   return val;
> +   return (int)(buf[0] << 8 | buf[1]);

Pretty sure you don't need to cast to int type here.

>  }
>
>  static int hdc100x_get_heater_status(struct hdc100x_data *data)
> @@ -272,8 +259,8 @@ static int hdc100x_probe(struct i2c_client *client,
> struct iio_dev *indio_dev;
> struct hdc100x_data *data;
>
> -   if (!i2c_check_functionality(client->adapter,
> -   I2C_FUNC_SMBUS_WORD_DATA | 
> I2C_FUNC_SMBUS_BYTE))
> +   if (!i2c_check_functionality(client->adapter, 
> I2C_FUNC_SMBUS_WORD_DATA |
> +I2C_FUNC_SMBUS_BYTE | I2C_FUNC_I2C))

Not sure we want to kill smbus support for this device...  iwe should
have two read methods for i2c and smbus (see the PulsedLight LIDAR
driver) in this case.

Ideally I wouldn't have written it with only smbus in mind, but can
kill backwards compatibility unless we have a good reason.

Thanks,

Matt

> return -EOPNOTSUPP;
>
> indio_dev = devm_iio_device_alloc(>dev, sizeof(*data));
> --
> 2.1.4
>

Re: [PATCH v15 04/10] arm64: Kprobes with single stepping support

[David Long]

On 07/29/2016 05:01 AM, Daniel Thompson wrote:
> On 28/07/16 15:40, Catalin Marinas wrote:
>> On Wed, Jul 27, 2016 at 06:13:37PM -0400, David Long wrote:
>>> On 07/27/2016 07:50 AM, Daniel Thompson wrote:
 On 25/07/16 23:27, David Long wrote:
> On 07/25/2016 01:13 PM, Catalin Marinas wrote:
>> The problem is that the original design was done on x86 for its 
>> PCS and
>> it doesn't always fit other architectures. So we could either 
>> ignore the
>> problem, hoping that no probed function requires argument passing on
>> stack or we copy all the valid data on the kernel stack:
>>
>> diff --git a/arch/arm64/include/asm/kprobes.h
>> b/arch/arm64/include/asm/kprobes.h
>> index 61b49150dfa3..157fd0d0aa08 100644
>> --- a/arch/arm64/include/asm/kprobes.h
>> +++ b/arch/arm64/include/asm/kprobes.h
>> @@ -22,7 +22,7 @@
>>
>>  #define __ARCH_WANT_KPROBES_INSN_SLOT
>>  #define MAX_INSN_SIZE1
>> -#define MAX_STACK_SIZE128
>> +#define MAX_STACK_SIZETHREAD_SIZE
>>
>>  #define flush_insn_slot(p)do { } while (0)
>>  #define kretprobe_blacklist_size0
>
> I doubt the ARM PCS is unusual.  At any rate I'm certain there are 
> other
> architectures that pass aggregate parameters on the stack. I suspect
> other RISC(-ish) architectures have similar PCS issues and I think 
> this
> is at least a big part of where this simple copy with a 64/128 limit
> comes from, or at least why it continues to exist.  That said, I'm not
> enthusiastic about researching that assertion in detail as it could be
> time consuming.

 Given Mark shared a test program I *was* curious enough to take a look
 at this.

 The only architecture I can find that behaves like arm64 with the
 implicit pass-by-reference described by Catalin/Mark is sparc64.

 In contrast alpha, arm (32-bit), hppa64, mips64 and powerpc64 all use a
 hybrid approach where the first fragments of the structure are 
 passed in
 registers and the remainder on the stack.
>>>
>>> That's interesting.  It also looks like sparc64 does not copy any 
>>> stack for
>>> jprobes. I guess that approach at least makes it clear what will and 
>>> won't
>>> work.
>>
>> I suggest we do the same for arm64 - avoid the copying entirely as it's
>> not safe anyway. We don't know how much to copy, nor can we be sure it
>> is safe (see Dave's DMA to the stack example). This would need to be
>> documented in the kprobes.txt file and MAX_STACK_SIZE removed from the
>> arm64 kprobes support.
>>
>> There is also the case that Daniel was talking about - passing more than
>> 8 arguments. I don't think it's worth handling this
> 
> Its actually quite hard to document the (architecture specific) "no big 
> structures" *and* the "8 argument" limits. It ends up as something like:
> 
>Structures/unions >16 bytes must not be passed by value and the
>size of all arguments, after padding each to an 8 byte boundary, must
>be less than 64 bytes.
> 
> We cannot avoid tackling big structures through documentation but when 
> we impose additional limits like "only 8 arguments" we are swapping an 
> architecture neutral "gotcha" that affects almost all jprobes uses (and 
> can be inferred from the documentation) with an architecture specific one!
> 

See new patch below.  The documentation change in it could use some scrutiny.
I've tested with one-off jprobes functions in a test module and I've
verified NET_TCPPROBE doesn't cause misbehavior.

> 
>  > but we should at
>> least add a warning and skip the probe:
>>
>> diff --git a/arch/arm64/kernel/probes/kprobes.c 
>> b/arch/arm64/kernel/probes/kprobes.c
>> index bf9768588288..84e02606ec3d 100644
>> --- a/arch/arm64/kernel/probes/kprobes.c
>> +++ b/arch/arm64/kernel/probes/kprobes.c
>> @@ -491,6 +491,10 @@ int __kprobes setjmp_pre_handler(struct kprobe 
>> *p, struct pt_regs *regs)
>>  struct kprobe_ctlblk *kcb = get_kprobe_ctlblk();
>>  long stack_ptr = kernel_stack_pointer(regs);
>>
>> +/* do not allow arguments passed on the stack */
>> +if (WARN_ON_ONCE(regs->sp != regs->regs[29]))
>> +return 0;
>> +
> 
> I don't really understand this test.
> 
> If we could reliably assume that the frame record was at the lowest 
> address within a stack frame then we could exploit that to store the 
> stacked arguments without risking overwriting volatile variables on the 
> stack.
> 
> 
> Daniel.
> 

I'm assuming the consensus is to not use the above snippet of code.

Thanks,
-dl

--cut here


>From b451caa1adaf1d03e08a44b5dad3fca31cebd97a Mon Sep 17 00:00:00 2001
From: "David A. Long" 
Date: Thu, 4 Aug 2016 00:35:33 -0400
Subject: [PATCH] arm64: Remove stack duplicating code from jprobes

Because the arm64 calling standard allows stacked function arguments to be
anywhere in the stack frame, do 

Re: [PATCH v15 04/10] arm64: Kprobes with single stepping support

[David Long]

On 07/29/2016 05:01 AM, Daniel Thompson wrote:
> On 28/07/16 15:40, Catalin Marinas wrote:
>> On Wed, Jul 27, 2016 at 06:13:37PM -0400, David Long wrote:
>>> On 07/27/2016 07:50 AM, Daniel Thompson wrote:
 On 25/07/16 23:27, David Long wrote:
> On 07/25/2016 01:13 PM, Catalin Marinas wrote:
>> The problem is that the original design was done on x86 for its 
>> PCS and
>> it doesn't always fit other architectures. So we could either 
>> ignore the
>> problem, hoping that no probed function requires argument passing on
>> stack or we copy all the valid data on the kernel stack:
>>
>> diff --git a/arch/arm64/include/asm/kprobes.h
>> b/arch/arm64/include/asm/kprobes.h
>> index 61b49150dfa3..157fd0d0aa08 100644
>> --- a/arch/arm64/include/asm/kprobes.h
>> +++ b/arch/arm64/include/asm/kprobes.h
>> @@ -22,7 +22,7 @@
>>
>>  #define __ARCH_WANT_KPROBES_INSN_SLOT
>>  #define MAX_INSN_SIZE1
>> -#define MAX_STACK_SIZE128
>> +#define MAX_STACK_SIZETHREAD_SIZE
>>
>>  #define flush_insn_slot(p)do { } while (0)
>>  #define kretprobe_blacklist_size0
>
> I doubt the ARM PCS is unusual.  At any rate I'm certain there are 
> other
> architectures that pass aggregate parameters on the stack. I suspect
> other RISC(-ish) architectures have similar PCS issues and I think 
> this
> is at least a big part of where this simple copy with a 64/128 limit
> comes from, or at least why it continues to exist.  That said, I'm not
> enthusiastic about researching that assertion in detail as it could be
> time consuming.

 Given Mark shared a test program I *was* curious enough to take a look
 at this.

 The only architecture I can find that behaves like arm64 with the
 implicit pass-by-reference described by Catalin/Mark is sparc64.

 In contrast alpha, arm (32-bit), hppa64, mips64 and powerpc64 all use a
 hybrid approach where the first fragments of the structure are 
 passed in
 registers and the remainder on the stack.
>>>
>>> That's interesting.  It also looks like sparc64 does not copy any 
>>> stack for
>>> jprobes. I guess that approach at least makes it clear what will and 
>>> won't
>>> work.
>>
>> I suggest we do the same for arm64 - avoid the copying entirely as it's
>> not safe anyway. We don't know how much to copy, nor can we be sure it
>> is safe (see Dave's DMA to the stack example). This would need to be
>> documented in the kprobes.txt file and MAX_STACK_SIZE removed from the
>> arm64 kprobes support.
>>
>> There is also the case that Daniel was talking about - passing more than
>> 8 arguments. I don't think it's worth handling this
> 
> Its actually quite hard to document the (architecture specific) "no big 
> structures" *and* the "8 argument" limits. It ends up as something like:
> 
>Structures/unions >16 bytes must not be passed by value and the
>size of all arguments, after padding each to an 8 byte boundary, must
>be less than 64 bytes.
> 
> We cannot avoid tackling big structures through documentation but when 
> we impose additional limits like "only 8 arguments" we are swapping an 
> architecture neutral "gotcha" that affects almost all jprobes uses (and 
> can be inferred from the documentation) with an architecture specific one!
> 

See new patch below.  The documentation change in it could use some scrutiny.
I've tested with one-off jprobes functions in a test module and I've
verified NET_TCPPROBE doesn't cause misbehavior.

> 
>  > but we should at
>> least add a warning and skip the probe:
>>
>> diff --git a/arch/arm64/kernel/probes/kprobes.c 
>> b/arch/arm64/kernel/probes/kprobes.c
>> index bf9768588288..84e02606ec3d 100644
>> --- a/arch/arm64/kernel/probes/kprobes.c
>> +++ b/arch/arm64/kernel/probes/kprobes.c
>> @@ -491,6 +491,10 @@ int __kprobes setjmp_pre_handler(struct kprobe 
>> *p, struct pt_regs *regs)
>>  struct kprobe_ctlblk *kcb = get_kprobe_ctlblk();
>>  long stack_ptr = kernel_stack_pointer(regs);
>>
>> +/* do not allow arguments passed on the stack */
>> +if (WARN_ON_ONCE(regs->sp != regs->regs[29]))
>> +return 0;
>> +
> 
> I don't really understand this test.
> 
> If we could reliably assume that the frame record was at the lowest 
> address within a stack frame then we could exploit that to store the 
> stacked arguments without risking overwriting volatile variables on the 
> stack.
> 
> 
> Daniel.
> 

I'm assuming the consensus is to not use the above snippet of code.

Thanks,
-dl

--cut here


>From b451caa1adaf1d03e08a44b5dad3fca31cebd97a Mon Sep 17 00:00:00 2001
From: "David A. Long" 
Date: Thu, 4 Aug 2016 00:35:33 -0400
Subject: [PATCH] arm64: Remove stack duplicating code from jprobes

Because the arm64 calling standard allows stacked function arguments to be
anywhere in the stack frame, do not attempt to 

Build error in -next due to 'sh: add working futex atomic ops on userspace addresses for smp'

[Guenter Roeck]

Hi,

I see the following build error in -next when building sh:shx3_defconfig.

{standard input}: Assembler messages:
{standard input}:177: Error: unknown opcode
{standard input}:7760: Error: unknown opcode

{standard input}:163: Error: displacement to defined symbol .L24 overflows 
8-bit field
{standard input}:6826: Error: displacement to defined symbol .L1409 overflows 
12-bit field
{standard input}:7051: Error: displacement to defined symbol .L1469 overflows 
12-bit field
[many more of those]

{standard input}:148: Error: pcrel too far
{standard input}:7549: Error: negative offset
[several more of those]

This is seen when building kernel/futex.o.

I initially thought that the problem was due to an old compiler/toolchain,
but using a new toolchain did not help.

Toolchain:
sh4-linux-gcc.br_real (Buildroot 2016.05) 5.3.0
GNU ld (GNU Binutils) 2.26.20160125

When using gcc 4.6.3 (from the kernel.org toolchain), the error is reported as:

{standard input}: Assembler messages:
{standard input}:318: Error: unknown opcode
{standard input}:7282: Error: unknown opcode

Bisect (for both toolchains) points to 'sh: add working futex atomic ops on 
userspace
addresses for smp' as the culprit. Bisect log is attached.

Guenter

---
# bad: [4d9dc2a0baee551d44e853e28a69cec881308655] Add linux-next specific files 
for 20160804
# good: [523d939ef98fd712632d93a5a2b588e477a7565e] Linux 4.7
git bisect start 'HEAD' 'v4.7'
# good: [b0c4e2acdd6175a07107474f3cd7bdc062cf4d3d] Merge branch 'for-next' of 
git://git.samba.org/sfrench/cifs-2.6
git bisect good b0c4e2acdd6175a07107474f3cd7bdc062cf4d3d
# good: [77a87824ed676ca8ff8482e4157d3adb284fd381] clocksource/drivers/clps_711x: 
fixup for "ARM: clps711x:
git bisect good 77a87824ed676ca8ff8482e4157d3adb284fd381
# good: [221bb8a46e230b9824204ae86537183d9991ff2a] Merge tag 'for-linus' of 
git://git.kernel.org/pub/scm/virt/kvm/kvm
git bisect good 221bb8a46e230b9824204ae86537183d9991ff2a
# bad: [5134a4ec4905a332a460709acd4e08afe749d6fc] Merge remote-tracking branch 
'befs/for-next'
git bisect bad 5134a4ec4905a332a460709acd4e08afe749d6fc
# good: [f0936155f2204720655aefbc2f17c25a2c80a59e] Merge 
git://git.kernel.org/pub/scm/linux/kernel/git/davem/net
git bisect good f0936155f2204720655aefbc2f17c25a2c80a59e
# good: [50e4cfe7f334833aba4e5b69bbe6450aeed56732] Merge remote-tracking branch 
'samsung-krzk/for-next'
git bisect good 50e4cfe7f334833aba4e5b69bbe6450aeed56732
# good: [1a4db2bf7d3c1e26a42337b5bb1e81b6b7cfce2b] Merge remote-tracking branch 
'parisc-hd/for-next'
git bisect good 1a4db2bf7d3c1e26a42337b5bb1e81b6b7cfce2b
# bad: [a0f556c518531ec412b1dfeae008d175fd0b203e] Merge remote-tracking branch 
'sh/for-next'
git bisect bad a0f556c518531ec412b1dfeae008d175fd0b203e
# good: [d844e279152c27e5b1a56dc40de08ddfd99176f3] powerpc/ptrace: Enable in 
transaction NT_PPC_VMX ptrace requests
git bisect good d844e279152c27e5b1a56dc40de08ddfd99176f3
# bad: [38396cc1e27e0fee33a70dcbe2bc5ad343144b8e] sh: add SMP support for J2
git bisect bad 38396cc1e27e0fee33a70dcbe2bc5ad343144b8e
# good: [f368d475871e8aafdfcffc858aad9647ced82fa2] sh: make 
board-secureedge5410 explicitly non-modular
git bisect good f368d475871e8aafdfcffc858aad9647ced82fa2
# good: [7213f0d9421066fd4e31c1230c150103d88431a4] sh: add support for J-Core 
J2 processor
git bisect good 7213f0d9421066fd4e31c1230c150103d88431a4
# good: [172e33b70901310162b981236f0612956e68eb8a] sh: add J2 atomics using the 
cas.l instruction
git bisect good 172e33b70901310162b981236f0612956e68eb8a
# bad: [7d582a9edd130847f9712fc7012f1a643b8b8f26] sh: SMP support for SH2 
entry.S
git bisect bad 7d582a9edd130847f9712fc7012f1a643b8b8f26
# bad: [3adc5aa28659f0f6e9defb915a1ccc67d76704b7] sh: add working futex atomic 
ops on userspace addresses for smp
git bisect bad 3adc5aa28659f0f6e9defb915a1ccc67d76704b7
# first bad commit: [3adc5aa28659f0f6e9defb915a1ccc67d76704b7] sh: add working 
futex atomic ops on userspace addresses for smp

Build error in -next due to 'sh: add working futex atomic ops on userspace addresses for smp'

[Guenter Roeck]

Hi,

I see the following build error in -next when building sh:shx3_defconfig.

{standard input}: Assembler messages:
{standard input}:177: Error: unknown opcode
{standard input}:7760: Error: unknown opcode

{standard input}:163: Error: displacement to defined symbol .L24 overflows 
8-bit field
{standard input}:6826: Error: displacement to defined symbol .L1409 overflows 
12-bit field
{standard input}:7051: Error: displacement to defined symbol .L1469 overflows 
12-bit field
[many more of those]

{standard input}:148: Error: pcrel too far
{standard input}:7549: Error: negative offset
[several more of those]

This is seen when building kernel/futex.o.

I initially thought that the problem was due to an old compiler/toolchain,
but using a new toolchain did not help.

Toolchain:
sh4-linux-gcc.br_real (Buildroot 2016.05) 5.3.0
GNU ld (GNU Binutils) 2.26.20160125

When using gcc 4.6.3 (from the kernel.org toolchain), the error is reported as:

{standard input}: Assembler messages:
{standard input}:318: Error: unknown opcode
{standard input}:7282: Error: unknown opcode

Bisect (for both toolchains) points to 'sh: add working futex atomic ops on 
userspace
addresses for smp' as the culprit. Bisect log is attached.

Guenter

---
# bad: [4d9dc2a0baee551d44e853e28a69cec881308655] Add linux-next specific files 
for 20160804
# good: [523d939ef98fd712632d93a5a2b588e477a7565e] Linux 4.7
git bisect start 'HEAD' 'v4.7'
# good: [b0c4e2acdd6175a07107474f3cd7bdc062cf4d3d] Merge branch 'for-next' of 
git://git.samba.org/sfrench/cifs-2.6
git bisect good b0c4e2acdd6175a07107474f3cd7bdc062cf4d3d
# good: [77a87824ed676ca8ff8482e4157d3adb284fd381] clocksource/drivers/clps_711x: 
fixup for "ARM: clps711x:
git bisect good 77a87824ed676ca8ff8482e4157d3adb284fd381
# good: [221bb8a46e230b9824204ae86537183d9991ff2a] Merge tag 'for-linus' of 
git://git.kernel.org/pub/scm/virt/kvm/kvm
git bisect good 221bb8a46e230b9824204ae86537183d9991ff2a
# bad: [5134a4ec4905a332a460709acd4e08afe749d6fc] Merge remote-tracking branch 
'befs/for-next'
git bisect bad 5134a4ec4905a332a460709acd4e08afe749d6fc
# good: [f0936155f2204720655aefbc2f17c25a2c80a59e] Merge 
git://git.kernel.org/pub/scm/linux/kernel/git/davem/net
git bisect good f0936155f2204720655aefbc2f17c25a2c80a59e
# good: [50e4cfe7f334833aba4e5b69bbe6450aeed56732] Merge remote-tracking branch 
'samsung-krzk/for-next'
git bisect good 50e4cfe7f334833aba4e5b69bbe6450aeed56732
# good: [1a4db2bf7d3c1e26a42337b5bb1e81b6b7cfce2b] Merge remote-tracking branch 
'parisc-hd/for-next'
git bisect good 1a4db2bf7d3c1e26a42337b5bb1e81b6b7cfce2b
# bad: [a0f556c518531ec412b1dfeae008d175fd0b203e] Merge remote-tracking branch 
'sh/for-next'
git bisect bad a0f556c518531ec412b1dfeae008d175fd0b203e
# good: [d844e279152c27e5b1a56dc40de08ddfd99176f3] powerpc/ptrace: Enable in 
transaction NT_PPC_VMX ptrace requests
git bisect good d844e279152c27e5b1a56dc40de08ddfd99176f3
# bad: [38396cc1e27e0fee33a70dcbe2bc5ad343144b8e] sh: add SMP support for J2
git bisect bad 38396cc1e27e0fee33a70dcbe2bc5ad343144b8e
# good: [f368d475871e8aafdfcffc858aad9647ced82fa2] sh: make 
board-secureedge5410 explicitly non-modular
git bisect good f368d475871e8aafdfcffc858aad9647ced82fa2
# good: [7213f0d9421066fd4e31c1230c150103d88431a4] sh: add support for J-Core 
J2 processor
git bisect good 7213f0d9421066fd4e31c1230c150103d88431a4
# good: [172e33b70901310162b981236f0612956e68eb8a] sh: add J2 atomics using the 
cas.l instruction
git bisect good 172e33b70901310162b981236f0612956e68eb8a
# bad: [7d582a9edd130847f9712fc7012f1a643b8b8f26] sh: SMP support for SH2 
entry.S
git bisect bad 7d582a9edd130847f9712fc7012f1a643b8b8f26
# bad: [3adc5aa28659f0f6e9defb915a1ccc67d76704b7] sh: add working futex atomic 
ops on userspace addresses for smp
git bisect bad 3adc5aa28659f0f6e9defb915a1ccc67d76704b7
# first bad commit: [3adc5aa28659f0f6e9defb915a1ccc67d76704b7] sh: add working 
futex atomic ops on userspace addresses for smp

[GIT PULL] target updates for v4.8-rc1

[Nicholas A. Bellinger]

Hello Linus,

Here are the target-pending updates for v4.8-rc1.  Please go ahead and
pull from:

  git://git.kernel.org/pub/scm/linux/kernel/git/nab/target-pending.git for-next

The most notable item is IBM virtual SCSI target driver, that was
originally ported to target-core back in 2010 by Tomo-san, and has been
brought forward to v4.x code by Bryant Ly, Michael Cyr and Co. over the
last months.

Also included are two ORDERED task related bug-fixes Bryant + Michael
found along the way using ibmvscsis with AIX guests, plus a few
miscellaneous target-core + iscsi-target bug-fixes with associated
stable tags.

Thank you,

--nab

Bryant G. Ly (1):
  ibmvscsis: Initial commit of IBM VSCSI Tgt Driver

Colin Ian King (1):
  target: fix spelling mistake: "limitiation" -> "limitation"

Feng Li (1):
  iscsi-target: Fix panic when adding second TCP connection to iSCSI
session

Hannes Reinecke (1):
  tcm_fc: set and unset FCP_SPPF_TARG_FCN

Mike Christie (1):
  target: Fix max_unmap_lba_count calc overflow

Nicholas Bellinger (4):
  target: Fix missing complete during ABORT_TASK + CMD_T_FABRIC_STOP
  target: Fix race between iscsi-target connection shutdown + ABORT_TASK
  target: Fix ordered task target_setup_cmd_from_cdb exception hang
  target: Fix ordered task CHECK_CONDITION early exception handling

Sumit Rai (1):
  target: Fix residual overflow handling in
target_complete_cmd_with_length

 MAINTAINERS   |   10 +-
 drivers/scsi/Kconfig  |   17 +
 drivers/scsi/Makefile |1 +
 drivers/scsi/ibmvscsi/ibmvfc.h|2 +-
 drivers/scsi/ibmvscsi/ibmvscsi.h  |2 +-
 drivers/scsi/ibmvscsi/viosrp.h|  225 --
 drivers/scsi/ibmvscsi_tgt/Makefile|3 +
 drivers/scsi/ibmvscsi_tgt/ibmvscsi_tgt.c  | 4087 +
 drivers/scsi/ibmvscsi_tgt/ibmvscsi_tgt.h  |  346 +++
 drivers/scsi/ibmvscsi_tgt/libsrp.c|  427 +++
 drivers/scsi/ibmvscsi_tgt/libsrp.h|  123 +
 drivers/target/iscsi/iscsi_target.c   |   22 +-
 drivers/target/iscsi/iscsi_target_login.c |5 +-
 drivers/target/target_core_device.c   |8 +-
 drivers/target/target_core_file.c |5 +-
 drivers/target/target_core_iblock.c   |3 +-
 drivers/target/target_core_internal.h |1 +
 drivers/target/target_core_sbc.c  |2 +-
 drivers/target/target_core_transport.c|   94 +-
 drivers/target/tcm_fc/tfc_sess.c  |2 +
 include/scsi/viosrp.h |  220 ++
 include/target/target_core_backend.h  |2 +-
 include/target/target_core_base.h |1 +
 include/target/target_core_fabric.h   |1 -
 24 files changed, 5326 insertions(+), 283 deletions(-)
 delete mode 100644 drivers/scsi/ibmvscsi/viosrp.h
 create mode 100644 drivers/scsi/ibmvscsi_tgt/Makefile
 create mode 100644 drivers/scsi/ibmvscsi_tgt/ibmvscsi_tgt.c
 create mode 100644 drivers/scsi/ibmvscsi_tgt/ibmvscsi_tgt.h
 create mode 100644 drivers/scsi/ibmvscsi_tgt/libsrp.c
 create mode 100644 drivers/scsi/ibmvscsi_tgt/libsrp.h
 create mode 100644 include/scsi/viosrp.h

[GIT PULL] target updates for v4.8-rc1

[Nicholas A. Bellinger]

Hello Linus,

Here are the target-pending updates for v4.8-rc1.  Please go ahead and
pull from:

  git://git.kernel.org/pub/scm/linux/kernel/git/nab/target-pending.git for-next

The most notable item is IBM virtual SCSI target driver, that was
originally ported to target-core back in 2010 by Tomo-san, and has been
brought forward to v4.x code by Bryant Ly, Michael Cyr and Co. over the
last months.

Also included are two ORDERED task related bug-fixes Bryant + Michael
found along the way using ibmvscsis with AIX guests, plus a few
miscellaneous target-core + iscsi-target bug-fixes with associated
stable tags.

Thank you,

--nab

Bryant G. Ly (1):
  ibmvscsis: Initial commit of IBM VSCSI Tgt Driver

Colin Ian King (1):
  target: fix spelling mistake: "limitiation" -> "limitation"

Feng Li (1):
  iscsi-target: Fix panic when adding second TCP connection to iSCSI
session

Hannes Reinecke (1):
  tcm_fc: set and unset FCP_SPPF_TARG_FCN

Mike Christie (1):
  target: Fix max_unmap_lba_count calc overflow

Nicholas Bellinger (4):
  target: Fix missing complete during ABORT_TASK + CMD_T_FABRIC_STOP
  target: Fix race between iscsi-target connection shutdown + ABORT_TASK
  target: Fix ordered task target_setup_cmd_from_cdb exception hang
  target: Fix ordered task CHECK_CONDITION early exception handling

Sumit Rai (1):
  target: Fix residual overflow handling in
target_complete_cmd_with_length

 MAINTAINERS   |   10 +-
 drivers/scsi/Kconfig  |   17 +
 drivers/scsi/Makefile |1 +
 drivers/scsi/ibmvscsi/ibmvfc.h|2 +-
 drivers/scsi/ibmvscsi/ibmvscsi.h  |2 +-
 drivers/scsi/ibmvscsi/viosrp.h|  225 --
 drivers/scsi/ibmvscsi_tgt/Makefile|3 +
 drivers/scsi/ibmvscsi_tgt/ibmvscsi_tgt.c  | 4087 +
 drivers/scsi/ibmvscsi_tgt/ibmvscsi_tgt.h  |  346 +++
 drivers/scsi/ibmvscsi_tgt/libsrp.c|  427 +++
 drivers/scsi/ibmvscsi_tgt/libsrp.h|  123 +
 drivers/target/iscsi/iscsi_target.c   |   22 +-
 drivers/target/iscsi/iscsi_target_login.c |5 +-
 drivers/target/target_core_device.c   |8 +-
 drivers/target/target_core_file.c |5 +-
 drivers/target/target_core_iblock.c   |3 +-
 drivers/target/target_core_internal.h |1 +
 drivers/target/target_core_sbc.c  |2 +-
 drivers/target/target_core_transport.c|   94 +-
 drivers/target/tcm_fc/tfc_sess.c  |2 +
 include/scsi/viosrp.h |  220 ++
 include/target/target_core_backend.h  |2 +-
 include/target/target_core_base.h |1 +
 include/target/target_core_fabric.h   |1 -
 24 files changed, 5326 insertions(+), 283 deletions(-)
 delete mode 100644 drivers/scsi/ibmvscsi/viosrp.h
 create mode 100644 drivers/scsi/ibmvscsi_tgt/Makefile
 create mode 100644 drivers/scsi/ibmvscsi_tgt/ibmvscsi_tgt.c
 create mode 100644 drivers/scsi/ibmvscsi_tgt/ibmvscsi_tgt.h
 create mode 100644 drivers/scsi/ibmvscsi_tgt/libsrp.c
 create mode 100644 drivers/scsi/ibmvscsi_tgt/libsrp.h
 create mode 100644 include/scsi/viosrp.h

[PATCH v6 2/2] clocksource: add J-Core timer/clocksource driver

[Rich Felker]

At the hardware level, the J-Core PIT is integrated with the interrupt
controller, but it is represented as its own device and has an
independent programming interface. It provides a 12-bit countdown
timer, which is not presently used, and a periodic timer. The interval
length for the latter is programmable via a 32-bit throttle register
whose units are determined by a bus-period register. The periodic
timer is used to implement both periodic and oneshot clock event
modes; in oneshot mode the interrupt handler simply disables the timer
as soon as it fires.

Despite its device tree node representing an interrupt for the PIT,
the actual irq generated is programmable, not hard-wired. The driver
is responsible for programming the PIT to generate the hardware irq
number that the DT assigns to it.

On SMP configurations, J-Core provides cpu-local instances of the PIT;
no broadcast timer is needed. This driver supports the creation of the
necessary per-cpu clock_event_device instances. The code has been
tested and works on SMP, but will not be usable without additional
J-Core SMP-support patches and appropriate hardware capable of running
SMP.

A nanosecond-resolution clocksource is provided using the J-Core "RTC"
registers, which give a 64-bit seconds count and 32-bit nanoseconds.
The driver converts these to a 64-bit nanoseconds count.

Signed-off-by: Rich Felker 
---
 drivers/clocksource/Kconfig |   9 ++
 drivers/clocksource/Makefile|   1 +
 drivers/clocksource/jcore-pit.c | 242 
 include/linux/cpuhotplug.h  |   1 +
 4 files changed, 253 insertions(+)
 create mode 100644 drivers/clocksource/jcore-pit.c

diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig
index 5677886..3210ca5 100644
--- a/drivers/clocksource/Kconfig
+++ b/drivers/clocksource/Kconfig
@@ -407,6 +407,15 @@ config SYS_SUPPORTS_SH_TMU
 config SYS_SUPPORTS_EM_STI
 bool
 
+config CLKSRC_JCORE_PIT
+   bool "J-Core PIT timer driver"
+   depends on OF && (SUPERH || COMPILE_TEST)
+   depends on GENERIC_CLOCKEVENTS
+   depends on HAS_IOMEM
+   help
+ This enables build of clocksource and clockevent driver for
+ the integrated PIT in the J-Core synthesizable, open source SoC.
+
 config SH_TIMER_CMT
bool "Renesas CMT timer driver" if COMPILE_TEST
depends on GENERIC_CLOCKEVENTS
diff --git a/drivers/clocksource/Makefile b/drivers/clocksource/Makefile
index fd9d6df..cf87f40 100644
--- a/drivers/clocksource/Makefile
+++ b/drivers/clocksource/Makefile
@@ -5,6 +5,7 @@ obj-$(CONFIG_ATMEL_TCB_CLKSRC)  += tcb_clksrc.o
 obj-$(CONFIG_X86_PM_TIMER) += acpi_pm.o
 obj-$(CONFIG_SCx200HR_TIMER)   += scx200_hrt.o
 obj-$(CONFIG_CS5535_CLOCK_EVENT_SRC)   += cs5535-clockevt.o
+obj-$(CONFIG_CLKSRC_JCORE_PIT) += jcore-pit.o
 obj-$(CONFIG_SH_TIMER_CMT) += sh_cmt.o
 obj-$(CONFIG_SH_TIMER_MTU2)+= sh_mtu2.o
 obj-$(CONFIG_SH_TIMER_TMU) += sh_tmu.o
diff --git a/drivers/clocksource/jcore-pit.c b/drivers/clocksource/jcore-pit.c
new file mode 100644
index 000..23dee50
--- /dev/null
+++ b/drivers/clocksource/jcore-pit.c
@@ -0,0 +1,242 @@
+/*
+ * J-Core SoC PIT/clocksource driver
+ *
+ * Copyright (C) 2015-2016 Smart Energy Instruments, Inc.
+ *
+ * This file is subject to the terms and conditions of the GNU General Public
+ * License.  See the file "COPYING" in the main directory of this archive
+ * for more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define PIT_IRQ_SHIFT  12
+#define PIT_PRIO_SHIFT 20
+#define PIT_ENABLE_SHIFT   26
+#define PIT_IRQ_MASK   0x3f
+#define PIT_PRIO_MASK  0xf
+
+#define REG_PITEN  0x00
+#define REG_THROT  0x10
+#define REG_COUNT  0x14
+#define REG_BUSPD  0x18
+#define REG_SECHI  0x20
+#define REG_SECLO  0x24
+#define REG_NSEC   0x28
+
+struct jcore_pit {
+   struct clock_event_device   ced;
+   __iomem void*base;
+   unsigned long   periodic_delta;
+   unsignedcpu;
+   u32 enable_val;
+};
+
+static __iomem void*jcore_pit_base;
+static struct clocksource  jcore_cs;
+struct jcore_pit __percpu  *jcore_pit_percpu;
+
+static notrace u64 jcore_sched_clock_read(void)
+{
+   u32 seclo, nsec, seclo0;
+   __iomem void *base = jcore_pit_base;
+
+   seclo = __raw_readl(base + REG_SECLO);
+   do {
+   seclo0 = seclo;
+   nsec  = __raw_readl(base + REG_NSEC);
+   seclo = __raw_readl(base + REG_SECLO);
+   } while (seclo0 != seclo);
+
+   return seclo * NSEC_PER_SEC + nsec;
+}
+
+static cycle_t jcore_clocksource_read(struct clocksource *cs)
+{
+   return jcore_sched_clock_read();
+}
+
+static int 

[PATCH v6 2/2] clocksource: add J-Core timer/clocksource driver

[Rich Felker]

At the hardware level, the J-Core PIT is integrated with the interrupt
controller, but it is represented as its own device and has an
independent programming interface. It provides a 12-bit countdown
timer, which is not presently used, and a periodic timer. The interval
length for the latter is programmable via a 32-bit throttle register
whose units are determined by a bus-period register. The periodic
timer is used to implement both periodic and oneshot clock event
modes; in oneshot mode the interrupt handler simply disables the timer
as soon as it fires.

Despite its device tree node representing an interrupt for the PIT,
the actual irq generated is programmable, not hard-wired. The driver
is responsible for programming the PIT to generate the hardware irq
number that the DT assigns to it.

On SMP configurations, J-Core provides cpu-local instances of the PIT;
no broadcast timer is needed. This driver supports the creation of the
necessary per-cpu clock_event_device instances. The code has been
tested and works on SMP, but will not be usable without additional
J-Core SMP-support patches and appropriate hardware capable of running
SMP.

A nanosecond-resolution clocksource is provided using the J-Core "RTC"
registers, which give a 64-bit seconds count and 32-bit nanoseconds.
The driver converts these to a 64-bit nanoseconds count.

Signed-off-by: Rich Felker 
---
 drivers/clocksource/Kconfig |   9 ++
 drivers/clocksource/Makefile|   1 +
 drivers/clocksource/jcore-pit.c | 242 
 include/linux/cpuhotplug.h  |   1 +
 4 files changed, 253 insertions(+)
 create mode 100644 drivers/clocksource/jcore-pit.c

diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig
index 5677886..3210ca5 100644
--- a/drivers/clocksource/Kconfig
+++ b/drivers/clocksource/Kconfig
@@ -407,6 +407,15 @@ config SYS_SUPPORTS_SH_TMU
 config SYS_SUPPORTS_EM_STI
 bool
 
+config CLKSRC_JCORE_PIT
+   bool "J-Core PIT timer driver"
+   depends on OF && (SUPERH || COMPILE_TEST)
+   depends on GENERIC_CLOCKEVENTS
+   depends on HAS_IOMEM
+   help
+ This enables build of clocksource and clockevent driver for
+ the integrated PIT in the J-Core synthesizable, open source SoC.
+
 config SH_TIMER_CMT
bool "Renesas CMT timer driver" if COMPILE_TEST
depends on GENERIC_CLOCKEVENTS
diff --git a/drivers/clocksource/Makefile b/drivers/clocksource/Makefile
index fd9d6df..cf87f40 100644
--- a/drivers/clocksource/Makefile
+++ b/drivers/clocksource/Makefile
@@ -5,6 +5,7 @@ obj-$(CONFIG_ATMEL_TCB_CLKSRC)  += tcb_clksrc.o
 obj-$(CONFIG_X86_PM_TIMER) += acpi_pm.o
 obj-$(CONFIG_SCx200HR_TIMER)   += scx200_hrt.o
 obj-$(CONFIG_CS5535_CLOCK_EVENT_SRC)   += cs5535-clockevt.o
+obj-$(CONFIG_CLKSRC_JCORE_PIT) += jcore-pit.o
 obj-$(CONFIG_SH_TIMER_CMT) += sh_cmt.o
 obj-$(CONFIG_SH_TIMER_MTU2)+= sh_mtu2.o
 obj-$(CONFIG_SH_TIMER_TMU) += sh_tmu.o
diff --git a/drivers/clocksource/jcore-pit.c b/drivers/clocksource/jcore-pit.c
new file mode 100644
index 000..23dee50
--- /dev/null
+++ b/drivers/clocksource/jcore-pit.c
@@ -0,0 +1,242 @@
+/*
+ * J-Core SoC PIT/clocksource driver
+ *
+ * Copyright (C) 2015-2016 Smart Energy Instruments, Inc.
+ *
+ * This file is subject to the terms and conditions of the GNU General Public
+ * License.  See the file "COPYING" in the main directory of this archive
+ * for more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define PIT_IRQ_SHIFT  12
+#define PIT_PRIO_SHIFT 20
+#define PIT_ENABLE_SHIFT   26
+#define PIT_IRQ_MASK   0x3f
+#define PIT_PRIO_MASK  0xf
+
+#define REG_PITEN  0x00
+#define REG_THROT  0x10
+#define REG_COUNT  0x14
+#define REG_BUSPD  0x18
+#define REG_SECHI  0x20
+#define REG_SECLO  0x24
+#define REG_NSEC   0x28
+
+struct jcore_pit {
+   struct clock_event_device   ced;
+   __iomem void*base;
+   unsigned long   periodic_delta;
+   unsignedcpu;
+   u32 enable_val;
+};
+
+static __iomem void*jcore_pit_base;
+static struct clocksource  jcore_cs;
+struct jcore_pit __percpu  *jcore_pit_percpu;
+
+static notrace u64 jcore_sched_clock_read(void)
+{
+   u32 seclo, nsec, seclo0;
+   __iomem void *base = jcore_pit_base;
+
+   seclo = __raw_readl(base + REG_SECLO);
+   do {
+   seclo0 = seclo;
+   nsec  = __raw_readl(base + REG_NSEC);
+   seclo = __raw_readl(base + REG_SECLO);
+   } while (seclo0 != seclo);
+
+   return seclo * NSEC_PER_SEC + nsec;
+}
+
+static cycle_t jcore_clocksource_read(struct clocksource *cs)
+{
+   return jcore_sched_clock_read();
+}
+
+static int jcore_pit_disable(struct 

Re: [PATCH v5 2/2] spi: add driver for J-Core SPI controller

[Rich Felker]

On Wed, Aug 03, 2016 at 08:16:43AM -0500, Rob Herring wrote:
> On Sun, Apr 3, 2016 at 12:12 AM, Rich Felker  wrote:
> 
> The date on your patch emails is way off.

Thanks for catching this. I tweaked my email-prep scripts to improve
coverage of who to send to, and somehow lost the part that deletes the
bogus Date: headers from git-format-patch output. I'll resend since
the messages were probably missed by their intended recipients.


> > The J-Core "spi2" device is a PIO-based SPI master controller. It
> > differs from "bitbang" devices in that that it's clocked in hardware
> > rather than via soft clock modulation over gpio, and performs
> > byte-at-a-time transfers between the cpu and SPI controller.
> >
> > This driver will be extended to support future versions of the J-Core
> > SPI controller with DMA transfers when they become available.
> >
> > Signed-off-by: Rich Felker 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-sh" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v5 2/2] spi: add driver for J-Core SPI controller

[Rich Felker]

On Wed, Aug 03, 2016 at 08:16:43AM -0500, Rob Herring wrote:
> On Sun, Apr 3, 2016 at 12:12 AM, Rich Felker  wrote:
> 
> The date on your patch emails is way off.

Thanks for catching this. I tweaked my email-prep scripts to improve
coverage of who to send to, and somehow lost the part that deletes the
bogus Date: headers from git-format-patch output. I'll resend since
the messages were probably missed by their intended recipients.


> > The J-Core "spi2" device is a PIO-based SPI master controller. It
> > differs from "bitbang" devices in that that it's clocked in hardware
> > rather than via soft clock modulation over gpio, and performs
> > byte-at-a-time transfers between the cpu and SPI controller.
> >
> > This driver will be extended to support future versions of the J-Core
> > SPI controller with DMA transfers when they become available.
> >
> > Signed-off-by: Rich Felker 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-sh" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v5 1/2] of: add J-Core SPI master bindings

[Rich Felker]

Signed-off-by: Rich Felker 
---
 .../devicetree/bindings/spi/jcore,spi.txt  | 34 ++
 1 file changed, 34 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/spi/jcore,spi.txt

diff --git a/Documentation/devicetree/bindings/spi/jcore,spi.txt 
b/Documentation/devicetree/bindings/spi/jcore,spi.txt
new file mode 100644
index 000..93936d1
--- /dev/null
+++ b/Documentation/devicetree/bindings/spi/jcore,spi.txt
@@ -0,0 +1,34 @@
+J-Core SPI master
+
+Required properties:
+
+- compatible: Must be "jcore,spi2".
+
+- reg: Memory region for registers.
+
+- #address-cells: Must be 1.
+
+- #size-cells: Must be 0.
+
+Optional properties:
+
+- clocks: If a phandle named "ref_clk" is present, SPI clock speed
+  programming is relative to the frequency of the indicated clock.
+  Necessary only if the input clock rate is something other than a
+  fixed 50 MHz.
+
+- clock-names: Clock names, one for each phandle in clocks.
+
+See spi-bus.txt for additional properties not specific to this device.
+
+Example:
+
+spi@40 {
+   compatible = "jcore,spi2";
+   #address-cells = <1>;
+   #size-cells = <0>;
+   reg = <0x40 0x8>;
+   spi-max-frequency = <2500>;
+   clocks = <_clk>;
+   clock-names = "ref_clk";
+}
-- 
2.8.1

[PATCH v5 2/2] spi: add driver for J-Core SPI controller

[Rich Felker]

The J-Core "spi2" device is a PIO-based SPI master controller. It
differs from "bitbang" devices in that that it's clocked in hardware
rather than via soft clock modulation over gpio, and performs
byte-at-a-time transfers between the cpu and SPI controller.

This driver will be extended to support future versions of the J-Core
SPI controller with DMA transfers when they become available.

Signed-off-by: Rich Felker 
---
 drivers/spi/Kconfig |   7 ++
 drivers/spi/Makefile|   1 +
 drivers/spi/spi-jcore.c | 232 
 3 files changed, 240 insertions(+)
 create mode 100644 drivers/spi/spi-jcore.c

diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
index d6fb8d4..1abb3d7 100644
--- a/drivers/spi/Kconfig
+++ b/drivers/spi/Kconfig
@@ -285,6 +285,13 @@ config SPI_IMX
  This enables using the Freescale i.MX SPI controllers in master
  mode.
 
+config SPI_JCORE
+   tristate "J-Core SPI Master"
+   depends on OF && (SUPERH || COMPILE_TEST)
+   help
+ This enables support for the SPI master controller in the J-Core
+ synthesizable, open source SoC.
+
 config SPI_LM70_LLP
tristate "Parallel port adapter for LM70 eval board (DEVELOPMENT)"
depends on PARPORT
diff --git a/drivers/spi/Makefile b/drivers/spi/Makefile
index 185367e..8715fec 100644
--- a/drivers/spi/Makefile
+++ b/drivers/spi/Makefile
@@ -46,6 +46,7 @@ obj-$(CONFIG_SPI_FSL_SPI) += spi-fsl-spi.o
 obj-$(CONFIG_SPI_GPIO) += spi-gpio.o
 obj-$(CONFIG_SPI_IMG_SPFI) += spi-img-spfi.o
 obj-$(CONFIG_SPI_IMX)  += spi-imx.o
+obj-$(CONFIG_SPI_JCORE)+= spi-jcore.o
 obj-$(CONFIG_SPI_LM70_LLP) += spi-lm70llp.o
 obj-$(CONFIG_SPI_LP8841_RTC)   += spi-lp8841-rtc.o
 obj-$(CONFIG_SPI_MESON_SPIFC)  += spi-meson-spifc.o
diff --git a/drivers/spi/spi-jcore.c b/drivers/spi/spi-jcore.c
new file mode 100644
index 000..7d2044a
--- /dev/null
+++ b/drivers/spi/spi-jcore.c
@@ -0,0 +1,232 @@
+/*
+ * J-Core SPI controller driver
+ *
+ * Copyright (C) 2012-2016 Smart Energy Instruments, Inc.
+ *
+ * Current version by Rich Felker
+ * Based loosely on initial version by Oleksandr G Zhadan
+ *
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define DRV_NAME   "jcore_spi"
+
+#define CTRL_REG   0x0
+#define DATA_REG   0x4
+
+#define JCORE_SPI_CTRL_XMIT0x02
+#define JCORE_SPI_STAT_BUSY0x02
+#define JCORE_SPI_CTRL_LOOP0x08
+#define JCORE_SPI_CTRL_CS_BITS 0x15
+
+#define JCORE_SPI_WAIT_RDY_MAX_LOOP200
+
+struct jcore_spi {
+   struct spi_master *master;
+   void __iomem *base;
+   unsigned int cs_reg;
+   unsigned int speed_reg;
+   unsigned int speed_hz;
+   unsigned int clock_freq;
+};
+
+static int jcore_spi_wait(void __iomem *ctrl_reg)
+{
+   unsigned timeout = JCORE_SPI_WAIT_RDY_MAX_LOOP;
+
+   do {
+   if (!(readl(ctrl_reg) & JCORE_SPI_STAT_BUSY))
+   return 0;
+   cpu_relax();
+   } while (--timeout);
+
+   return -EBUSY;
+}
+
+static void jcore_spi_program(struct jcore_spi *hw)
+{
+   void __iomem *ctrl_reg = hw->base + CTRL_REG;
+
+   if (jcore_spi_wait(ctrl_reg))
+   dev_err(hw->master->dev.parent,
+   "timeout waiting to program ctrl reg.\n");
+
+   writel(hw->cs_reg | hw->speed_reg, ctrl_reg);
+}
+
+static void jcore_spi_chipsel(struct spi_device *spi, bool value)
+{
+   struct jcore_spi *hw = spi_master_get_devdata(spi->master);
+   u32 csbit = 1U << (2 * spi->chip_select);
+
+   dev_dbg(hw->master->dev.parent, "chipselect %d\n", spi->chip_select);
+
+   if (value)
+   hw->cs_reg |= csbit;
+   else
+   hw->cs_reg &= ~csbit;
+
+   jcore_spi_program(hw);
+}
+
+static void jcore_spi_baudrate(struct jcore_spi *hw, int speed)
+{
+   if (speed == hw->speed_hz) return;
+   hw->speed_hz = speed;
+   if (speed >= hw->clock_freq / 2)
+   hw->speed_reg = 0;
+   else
+   hw->speed_reg = ((hw->clock_freq / 2 / speed) - 1) << 27;
+   jcore_spi_program(hw);
+   dev_dbg(hw->master->dev.parent, "speed=%d reg=0x%x\n",
+   speed, hw->speed_reg);
+}
+
+static int jcore_spi_txrx(struct spi_master *master, struct spi_device *spi,
+ struct spi_transfer *t)
+{
+   struct jcore_spi *hw = spi_master_get_devdata(master);
+
+   void __iomem *ctrl_reg = hw->base + CTRL_REG;
+   void __iomem *data_reg = hw->base + DATA_REG;
+   u32 xmit;
+
+   /* data buffers */
+   const unsigned char *tx;
+   unsigned char *rx;
+   unsigned int len;
+   unsigned int count;
+
+   jcore_spi_baudrate(hw, t->speed_hz);
+
+   xmit = hw->cs_reg | 

[PATCH v6 0/2] J-Core timer support

[Rich Felker]

Updated to include changes requested by Thomas Gleixner. Aside from
minor style improvements, the main changes are moving from the old cpu
notifier framework for cpu starting to the cpuhotplug framework. Since
the new framework does not easily facilitate multiple driver instances
without significant additional code, and since there is presently no
need for multiple instances, the (now-only-nominal) support for
multiple instances was removed; this simplifies some of the code. Use
of the full 64-bit clocksource was also replaced by 32-bit to avoid
expensive (non-native, software) 64-bit arithmetic in hot paths.

I've also removed a comment about Linux implementation details from
the DT binding document since it's not actually part of the bindings.

Finally, driver was made conditional in Kconfig to avoid it showing up
in configurations where it's not relevant.

Rich


Rich Felker (2):
  of: add J-Core timer bindings
  clocksource: add J-Core timer/clocksource driver

 .../devicetree/bindings/timer/jcore,pit.txt|  24 ++
 drivers/clocksource/Kconfig|   9 +
 drivers/clocksource/Makefile   |   1 +
 drivers/clocksource/jcore-pit.c| 242 +
 include/linux/cpuhotplug.h |   1 +
 5 files changed, 277 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/timer/jcore,pit.txt
 create mode 100644 drivers/clocksource/jcore-pit.c

-- 
2.8.1

[PATCH v5 1/2] of: add J-Core SPI master bindings

[Rich Felker]

Signed-off-by: Rich Felker 
---
 .../devicetree/bindings/spi/jcore,spi.txt  | 34 ++
 1 file changed, 34 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/spi/jcore,spi.txt

diff --git a/Documentation/devicetree/bindings/spi/jcore,spi.txt 
b/Documentation/devicetree/bindings/spi/jcore,spi.txt
new file mode 100644
index 000..93936d1
--- /dev/null
+++ b/Documentation/devicetree/bindings/spi/jcore,spi.txt
@@ -0,0 +1,34 @@
+J-Core SPI master
+
+Required properties:
+
+- compatible: Must be "jcore,spi2".
+
+- reg: Memory region for registers.
+
+- #address-cells: Must be 1.
+
+- #size-cells: Must be 0.
+
+Optional properties:
+
+- clocks: If a phandle named "ref_clk" is present, SPI clock speed
+  programming is relative to the frequency of the indicated clock.
+  Necessary only if the input clock rate is something other than a
+  fixed 50 MHz.
+
+- clock-names: Clock names, one for each phandle in clocks.
+
+See spi-bus.txt for additional properties not specific to this device.
+
+Example:
+
+spi@40 {
+   compatible = "jcore,spi2";
+   #address-cells = <1>;
+   #size-cells = <0>;
+   reg = <0x40 0x8>;
+   spi-max-frequency = <2500>;
+   clocks = <_clk>;
+   clock-names = "ref_clk";
+}
-- 
2.8.1

[PATCH v5 2/2] spi: add driver for J-Core SPI controller

[Rich Felker]

The J-Core "spi2" device is a PIO-based SPI master controller. It
differs from "bitbang" devices in that that it's clocked in hardware
rather than via soft clock modulation over gpio, and performs
byte-at-a-time transfers between the cpu and SPI controller.

This driver will be extended to support future versions of the J-Core
SPI controller with DMA transfers when they become available.

Signed-off-by: Rich Felker 
---
 drivers/spi/Kconfig |   7 ++
 drivers/spi/Makefile|   1 +
 drivers/spi/spi-jcore.c | 232 
 3 files changed, 240 insertions(+)
 create mode 100644 drivers/spi/spi-jcore.c

diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
index d6fb8d4..1abb3d7 100644
--- a/drivers/spi/Kconfig
+++ b/drivers/spi/Kconfig
@@ -285,6 +285,13 @@ config SPI_IMX
  This enables using the Freescale i.MX SPI controllers in master
  mode.
 
+config SPI_JCORE
+   tristate "J-Core SPI Master"
+   depends on OF && (SUPERH || COMPILE_TEST)
+   help
+ This enables support for the SPI master controller in the J-Core
+ synthesizable, open source SoC.
+
 config SPI_LM70_LLP
tristate "Parallel port adapter for LM70 eval board (DEVELOPMENT)"
depends on PARPORT
diff --git a/drivers/spi/Makefile b/drivers/spi/Makefile
index 185367e..8715fec 100644
--- a/drivers/spi/Makefile
+++ b/drivers/spi/Makefile
@@ -46,6 +46,7 @@ obj-$(CONFIG_SPI_FSL_SPI) += spi-fsl-spi.o
 obj-$(CONFIG_SPI_GPIO) += spi-gpio.o
 obj-$(CONFIG_SPI_IMG_SPFI) += spi-img-spfi.o
 obj-$(CONFIG_SPI_IMX)  += spi-imx.o
+obj-$(CONFIG_SPI_JCORE)+= spi-jcore.o
 obj-$(CONFIG_SPI_LM70_LLP) += spi-lm70llp.o
 obj-$(CONFIG_SPI_LP8841_RTC)   += spi-lp8841-rtc.o
 obj-$(CONFIG_SPI_MESON_SPIFC)  += spi-meson-spifc.o
diff --git a/drivers/spi/spi-jcore.c b/drivers/spi/spi-jcore.c
new file mode 100644
index 000..7d2044a
--- /dev/null
+++ b/drivers/spi/spi-jcore.c
@@ -0,0 +1,232 @@
+/*
+ * J-Core SPI controller driver
+ *
+ * Copyright (C) 2012-2016 Smart Energy Instruments, Inc.
+ *
+ * Current version by Rich Felker
+ * Based loosely on initial version by Oleksandr G Zhadan
+ *
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define DRV_NAME   "jcore_spi"
+
+#define CTRL_REG   0x0
+#define DATA_REG   0x4
+
+#define JCORE_SPI_CTRL_XMIT0x02
+#define JCORE_SPI_STAT_BUSY0x02
+#define JCORE_SPI_CTRL_LOOP0x08
+#define JCORE_SPI_CTRL_CS_BITS 0x15
+
+#define JCORE_SPI_WAIT_RDY_MAX_LOOP200
+
+struct jcore_spi {
+   struct spi_master *master;
+   void __iomem *base;
+   unsigned int cs_reg;
+   unsigned int speed_reg;
+   unsigned int speed_hz;
+   unsigned int clock_freq;
+};
+
+static int jcore_spi_wait(void __iomem *ctrl_reg)
+{
+   unsigned timeout = JCORE_SPI_WAIT_RDY_MAX_LOOP;
+
+   do {
+   if (!(readl(ctrl_reg) & JCORE_SPI_STAT_BUSY))
+   return 0;
+   cpu_relax();
+   } while (--timeout);
+
+   return -EBUSY;
+}
+
+static void jcore_spi_program(struct jcore_spi *hw)
+{
+   void __iomem *ctrl_reg = hw->base + CTRL_REG;
+
+   if (jcore_spi_wait(ctrl_reg))
+   dev_err(hw->master->dev.parent,
+   "timeout waiting to program ctrl reg.\n");
+
+   writel(hw->cs_reg | hw->speed_reg, ctrl_reg);
+}
+
+static void jcore_spi_chipsel(struct spi_device *spi, bool value)
+{
+   struct jcore_spi *hw = spi_master_get_devdata(spi->master);
+   u32 csbit = 1U << (2 * spi->chip_select);
+
+   dev_dbg(hw->master->dev.parent, "chipselect %d\n", spi->chip_select);
+
+   if (value)
+   hw->cs_reg |= csbit;
+   else
+   hw->cs_reg &= ~csbit;
+
+   jcore_spi_program(hw);
+}
+
+static void jcore_spi_baudrate(struct jcore_spi *hw, int speed)
+{
+   if (speed == hw->speed_hz) return;
+   hw->speed_hz = speed;
+   if (speed >= hw->clock_freq / 2)
+   hw->speed_reg = 0;
+   else
+   hw->speed_reg = ((hw->clock_freq / 2 / speed) - 1) << 27;
+   jcore_spi_program(hw);
+   dev_dbg(hw->master->dev.parent, "speed=%d reg=0x%x\n",
+   speed, hw->speed_reg);
+}
+
+static int jcore_spi_txrx(struct spi_master *master, struct spi_device *spi,
+ struct spi_transfer *t)
+{
+   struct jcore_spi *hw = spi_master_get_devdata(master);
+
+   void __iomem *ctrl_reg = hw->base + CTRL_REG;
+   void __iomem *data_reg = hw->base + DATA_REG;
+   u32 xmit;
+
+   /* data buffers */
+   const unsigned char *tx;
+   unsigned char *rx;
+   unsigned int len;
+   unsigned int count;
+
+   jcore_spi_baudrate(hw, t->speed_hz);
+
+   xmit = hw->cs_reg | hw->speed_reg | 

[PATCH v6 0/2] J-Core timer support

[Rich Felker]

Updated to include changes requested by Thomas Gleixner. Aside from
minor style improvements, the main changes are moving from the old cpu
notifier framework for cpu starting to the cpuhotplug framework. Since
the new framework does not easily facilitate multiple driver instances
without significant additional code, and since there is presently no
need for multiple instances, the (now-only-nominal) support for
multiple instances was removed; this simplifies some of the code. Use
of the full 64-bit clocksource was also replaced by 32-bit to avoid
expensive (non-native, software) 64-bit arithmetic in hot paths.

I've also removed a comment about Linux implementation details from
the DT binding document since it's not actually part of the bindings.

Finally, driver was made conditional in Kconfig to avoid it showing up
in configurations where it's not relevant.

Rich


Rich Felker (2):
  of: add J-Core timer bindings
  clocksource: add J-Core timer/clocksource driver

 .../devicetree/bindings/timer/jcore,pit.txt|  24 ++
 drivers/clocksource/Kconfig|   9 +
 drivers/clocksource/Makefile   |   1 +
 drivers/clocksource/jcore-pit.c| 242 +
 include/linux/cpuhotplug.h |   1 +
 5 files changed, 277 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/timer/jcore,pit.txt
 create mode 100644 drivers/clocksource/jcore-pit.c

-- 
2.8.1

[PATCH v6 1/2] of: add J-Core timer bindings

[Rich Felker]

Signed-off-by: Rich Felker 
---
 .../devicetree/bindings/timer/jcore,pit.txt| 24 ++
 1 file changed, 24 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/timer/jcore,pit.txt

diff --git a/Documentation/devicetree/bindings/timer/jcore,pit.txt 
b/Documentation/devicetree/bindings/timer/jcore,pit.txt
new file mode 100644
index 000..af5dd35
--- /dev/null
+++ b/Documentation/devicetree/bindings/timer/jcore,pit.txt
@@ -0,0 +1,24 @@
+J-Core Programmable Interval Timer and Clocksource
+
+Required properties:
+
+- compatible: Must be "jcore,pit".
+
+- reg: Memory region(s) for timer/clocksource registers. For SMP,
+  there should be one region per cpu, indexed by the sequential,
+  zero-based hardware cpu number.
+
+- interrupts: An interrupt to assign for the timer. The actual pit
+  core is integrated with the aic and allows the timer interrupt
+  assignment to be programmed by software, but this property is
+  required in order to reserve an interrupt number that doesn't
+  conflict with other devices.
+
+
+Example:
+
+timer@200 {
+   compatible = "jcore,pit";
+   reg = < 0x200 0x30 0x500 0x30 >;
+   interrupts = < 0x48 >;
+};
-- 
2.8.1

[PATCH v5 0/2] J-Core SPI controller support

[Rich Felker]

Updates based on requests by Mark Brown. Driver has been made
conditional in Kconfig to avoid it showing up in configurations where
it's not relevant. Lots of small style improvements have been made,
and the input clock frequency is now handled via the clk framework
rather than a fixed clock-frequency property in the DT. Corresponding
changes were made to the DT binding patch.

Rich



Rich Felker (2):
  of: add J-Core SPI master bindings
  spi: add driver for J-Core SPI controller

 .../devicetree/bindings/spi/jcore,spi.txt  |  34 +++
 drivers/spi/Kconfig|   7 +
 drivers/spi/Makefile   |   1 +
 drivers/spi/spi-jcore.c| 232 +
 4 files changed, 274 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/spi/jcore,spi.txt
 create mode 100644 drivers/spi/spi-jcore.c

-- 
2.8.1

[PATCH v5 0/2] J-Core SPI controller support

[Rich Felker]

Updates based on requests by Mark Brown. Driver has been made
conditional in Kconfig to avoid it showing up in configurations where
it's not relevant. Lots of small style improvements have been made,
and the input clock frequency is now handled via the clk framework
rather than a fixed clock-frequency property in the DT. Corresponding
changes were made to the DT binding patch.

Rich



Rich Felker (2):
  of: add J-Core SPI master bindings
  spi: add driver for J-Core SPI controller

 .../devicetree/bindings/spi/jcore,spi.txt  |  34 +++
 drivers/spi/Kconfig|   7 +
 drivers/spi/Makefile   |   1 +
 drivers/spi/spi-jcore.c| 232 +
 4 files changed, 274 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/spi/jcore,spi.txt
 create mode 100644 drivers/spi/spi-jcore.c

-- 
2.8.1

[PATCH v6 1/2] of: add J-Core timer bindings

[Rich Felker]

Signed-off-by: Rich Felker 
---
 .../devicetree/bindings/timer/jcore,pit.txt| 24 ++
 1 file changed, 24 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/timer/jcore,pit.txt

diff --git a/Documentation/devicetree/bindings/timer/jcore,pit.txt 
b/Documentation/devicetree/bindings/timer/jcore,pit.txt
new file mode 100644
index 000..af5dd35
--- /dev/null
+++ b/Documentation/devicetree/bindings/timer/jcore,pit.txt
@@ -0,0 +1,24 @@
+J-Core Programmable Interval Timer and Clocksource
+
+Required properties:
+
+- compatible: Must be "jcore,pit".
+
+- reg: Memory region(s) for timer/clocksource registers. For SMP,
+  there should be one region per cpu, indexed by the sequential,
+  zero-based hardware cpu number.
+
+- interrupts: An interrupt to assign for the timer. The actual pit
+  core is integrated with the aic and allows the timer interrupt
+  assignment to be programmed by software, but this property is
+  required in order to reserve an interrupt number that doesn't
+  conflict with other devices.
+
+
+Example:
+
+timer@200 {
+   compatible = "jcore,pit";
+   reg = < 0x200 0x30 0x500 0x30 >;
+   interrupts = < 0x48 >;
+};
-- 
2.8.1

Re: [PATCH v2 1/3] mtd: introduce the mtd_pairing_scheme concept

[Brian Norris]

Hi Boris,

On Mon, Jun 20, 2016 at 03:50:16PM +0200, Boris Brezillon wrote:
> MLC and TLC NAND devices are using NAND cells exposing more than one bit,
> but instead of attaching all the bits in a given cell to a single NAND
> page, each bit is usually attached to a different page. This concept is
> called 'page pairing', and has significant impacts on the flash storage
> usage.
> The main problem showed by these devices is that interrupting a page
> program operation may not only corrupt the page we are programming
> but also the page it is paired with, hence the need to expose to MTD
> users the pairing scheme information.
> 
> The pairing APIs allows one to query pairing information attached to a
> given page (here called wunit), or the other way around (the wunit
> pointed by pairing information).
> It also provides several helpers to help the conversion between absolute
> offsets and wunits, and query the number of pairing groups.
> 
> Signed-off-by: Boris Brezillon 

Overall, the comments and documentation are a lot better on this one.
Thanks for doing that! I only have a few more small comments, and with
those, I think it's ready to land IMO. I'll try to review the NAND
implementation bits too (look OK for now), but I'm not as worried about
that, if we agree on the high-level API.

BTW, I don't know if we're likely to hit any conflicts on the
mtdcore and mtd.h bits. Perhaps it will make sense for us to apply this
first patch as a mini-branch to both our trees? Maybe if you just fixup
any last comments, you can send me a trivial pull request / tag /
whatever (doesn't need to be formal), with just this patch.

> ---
>  drivers/mtd/mtdcore.c   |  94 ++
>  drivers/mtd/mtdpart.c   |   1 +
>  include/linux/mtd/mtd.h | 106 
> 
>  3 files changed, 201 insertions(+)
> 
> diff --git a/drivers/mtd/mtdcore.c b/drivers/mtd/mtdcore.c
> index e3936b847c6b..decceb9fdf32 100644
> --- a/drivers/mtd/mtdcore.c
> +++ b/drivers/mtd/mtdcore.c
> @@ -376,6 +376,100 @@ static int mtd_reboot_notifier(struct notifier_block 
> *n, unsigned long state,
>  }
>  
>  /**
> + * mtd_wunit_to_pairing_info - get pairing information of a wunit
> + * @mtd: pointer to new MTD device info structure
> + * @wunit: write unit we are interrested in

s/interrested/interested/

> + * @info: pairing information struct

Maybe something to indicate this is the return value? e.g., "returned
pairing information"?

> + *
> + * Retrieve pairing information associated to the wunit.
> + * This is mainly useful when dealing with MLC/TLC NANDs where pages can be
> + * paired together, and where programming a page may influence the page it is
> + * paired with.
> + * The notion of page is replaced by the term wunit (write-unit) to stay
> + * consistent with the ->writesize field.
> + *
> + * The @wunit argument can be extracted from an absolute offset using
> + * mtd_offset_to_wunit(). @info is filled with the pairing information 
> attached
> + * to @wunit.
> + *
> + * From the pairing info the MTD user can find all the wunits paired with
> + * @wunit using the following loop:
> + *
> + * for (i = 0; i < mtd_pairing_groups(mtd); i++) {
> + *   info.pair = i;
> + *   mtd_pairing_info_to_wunit(mtd, );
> + *   ...
> + * }
> + */
> +void mtd_wunit_to_pairing_info(struct mtd_info *mtd, int wunit,
> +struct mtd_pairing_info *info)
> +{

Do we want to do any range-checking here? i.e., make this return int? Or
is that too paranoid? We've done similarly on most of the rest of the
MTD API.

Notably, I think we're probably safe keeping the ->pairing->get_info()
callback as returning void, since the driver can expect this core helper
to do the range checking for us.

> + if (!mtd->pairing || !mtd->pairing->get_info) {
> + info->group = 0;
> + info->pair = wunit;
> + } else {
> + mtd->pairing->get_info(mtd, wunit, info);
> + }
> +}
> +EXPORT_SYMBOL_GPL(mtd_wunit_to_pairing_info);
> +
> +/**
> + * mtd_wunit_to_pairing_info - get wunit from pairing information
> + * @mtd: pointer to new MTD device info structure
> + * @info: pairing information struct
> + *
> + * Returns a positive number representing the wunit associated to the info
> + * struct, or a negative error code.
> + *
> + * This is the reverse of mtd_wunit_to_pairing_info(), and can help one to
> + * iterate over all wunits of a given pair (see mtd_wunit_to_pairing_info()
> + * doc).
> + *
> + * It can also be used to only program the first page of each pair (i.e.
> + * page attached to group 0), which allows one to use an MLC NAND in
> + * software-emulated SLC mode:
> + *
> + * info.group = 0;
> + * for (info.pair = 0; info < mtd_wunit_per_eb(mtd); info.pair++) {

(I know it's just example code, but...) the second clause should have
'info.pair < ...', not 'info < ...'.

> + *   wunit = 

[PATCH v5] usb: ohci-at91: Forcibly suspend ports while USB suspend

[Wenyou Yang]

The usb controller does not managed correctly the suspend mode for
the ehci. In echi mode, there is no way to have utmi_suspend_o_n[1]
suspend without any device connected to it. This is why this specific
control is added to fix this issue. The suspend mode works in ohci
mode.

This specific control is by setting the SUSPEND_A/B/C fields of
SFR_OHCIICR(OHCI Interrupt Configuration Register) in the SFR
while OHCI USB suspend.

This setting operation must be done before the USB clock disabled,
clear them after the USB clock enabled.

Signed-off-by: Wenyou Yang 
Reviewed-by: Alexandre Belloni 
Acked-by: Nicolas Ferre 
---

Changes in v5:
 - Use the USB_PORT_FEAT_SUSPEND subcase of the SetPortFeature case
   to take care it.
 - Update the commit log.

Changes in v4:
 - To check whether the SFR node with "atmel,sama5d2-sfr" compatible
   is present or not to decide if this feature is applied or not
   when USB OHCI suspend/resume, instead of new compatible.
 - Drop the compatible "atmel,sama5d2-ohci".
 - Drop [PATCH 2/2] ARM: at91/dt: sama5d2: Use new compatible for
   ohci node.
 - Drop include/soc/at91/at91_sfr.h, move the macro definitions to
   atmel-sfr.h which already exists.
 - Change the defines to align the exists.

Changes in v3:
 - Change the compatible description for more precise.

Changes in v2:
 - Add compatible to support forcibly suspend the ports.
 - Add soc/at91/at91_sfr.h to accommodate the defines.
 - Add error checking for .sfr_regmap.
 - Remove unnecessary regmap_read() statement.

 drivers/usb/host/ohci-at91.c | 72 ++--
 include/soc/at91/atmel-sfr.h |  3 ++
 2 files changed, 73 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/host/ohci-at91.c b/drivers/usb/host/ohci-at91.c
index d177372..4d7d7a0 100644
--- a/drivers/usb/host/ohci-at91.c
+++ b/drivers/usb/host/ohci-at91.c
@@ -21,8 +21,11 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 #include 
 #include 
+#include 
 
 #include "ohci.h"
 
@@ -51,6 +54,7 @@ struct ohci_at91_priv {
struct clk *hclk;
bool clocked;
bool wakeup;/* Saved wake-up state for resume */
+   struct regmap *sfr_regmap;
 };
 /* interface and function clocks; sometimes also an AHB clock */
 
@@ -134,6 +138,17 @@ static void at91_stop_hc(struct platform_device *pdev)
 
 static void usb_hcd_at91_remove (struct usb_hcd *, struct platform_device *);
 
+struct regmap *at91_dt_syscon_sfr(void)
+{
+   struct regmap *regmap;
+
+   regmap = syscon_regmap_lookup_by_compatible("atmel,sama5d2-sfr");
+   if (IS_ERR(regmap))
+   regmap = NULL;
+
+   return regmap;
+}
+
 /* configure so an HC device and id are always provided */
 /* always called with process context; sleeping is OK */
 
@@ -197,6 +212,10 @@ static int usb_hcd_at91_probe(const struct hc_driver 
*driver,
goto err;
}
 
+   ohci_at91->sfr_regmap = at91_dt_syscon_sfr();
+   if (!ohci_at91->sfr_regmap)
+   dev_warn(dev, "failed to find sfr node\n");
+
board = hcd->self.controller->platform_data;
ohci = hcd_to_ohci(hcd);
ohci->num_ports = board->ports;
@@ -282,6 +301,28 @@ static int ohci_at91_hub_status_data(struct usb_hcd *hcd, 
char *buf)
return length;
 }
 
+static int ohci_at91_port_ctrl(struct regmap *regmap, u16 port, u8 set)
+{
+   u32 regval;
+   int ret;
+
+   if (!regmap)
+   return 0;
+
+   ret = regmap_read(regmap, AT91_SFR_OHCIICR, );
+   if (ret)
+   return ret;
+
+   if (set)
+   regval |= AT91_OHCIICR_SUSPEND(port);
+   else
+   regval &= ~AT91_OHCIICR_SUSPEND(port);
+
+   regmap_write(regmap, AT91_SFR_OHCIICR, regval);
+
+   return 0;
+}
+
 /*
  * Look at the control requests to the root hub and see if we need to override.
  */
@@ -289,6 +330,7 @@ static int ohci_at91_hub_control(struct usb_hcd *hcd, u16 
typeReq, u16 wValue,
 u16 wIndex, char *buf, u16 wLength)
 {
struct at91_usbh_data *pdata = dev_get_platdata(hcd->self.controller);
+   struct ohci_at91_priv *ohci_at91 = hcd_to_ohci_at91_priv(hcd);
struct usb_hub_descriptor *desc;
int ret = -EINVAL;
u32 *data = (u32 *)buf;
@@ -301,7 +343,8 @@ static int ohci_at91_hub_control(struct usb_hcd *hcd, u16 
typeReq, u16 wValue,
 
switch (typeReq) {
case SetPortFeature:
-   if (wValue == USB_PORT_FEAT_POWER) {
+   switch (wValue) {
+   case USB_PORT_FEAT_POWER:
dev_dbg(hcd->self.controller, "SetPortFeat: POWER\n");
if (valid_port(wIndex)) {
ohci_at91_usb_set_power(pdata, wIndex, 1);
@@ -309,6 +352,11 @@ static int ohci_at91_hub_control(struct usb_hcd *hcd, u16 
typeReq, u16 wValue,
   

Re: [PATCH v2 1/3] mtd: introduce the mtd_pairing_scheme concept

[Brian Norris]

Hi Boris,

On Mon, Jun 20, 2016 at 03:50:16PM +0200, Boris Brezillon wrote:
> MLC and TLC NAND devices are using NAND cells exposing more than one bit,
> but instead of attaching all the bits in a given cell to a single NAND
> page, each bit is usually attached to a different page. This concept is
> called 'page pairing', and has significant impacts on the flash storage
> usage.
> The main problem showed by these devices is that interrupting a page
> program operation may not only corrupt the page we are programming
> but also the page it is paired with, hence the need to expose to MTD
> users the pairing scheme information.
> 
> The pairing APIs allows one to query pairing information attached to a
> given page (here called wunit), or the other way around (the wunit
> pointed by pairing information).
> It also provides several helpers to help the conversion between absolute
> offsets and wunits, and query the number of pairing groups.
> 
> Signed-off-by: Boris Brezillon 

Overall, the comments and documentation are a lot better on this one.
Thanks for doing that! I only have a few more small comments, and with
those, I think it's ready to land IMO. I'll try to review the NAND
implementation bits too (look OK for now), but I'm not as worried about
that, if we agree on the high-level API.

BTW, I don't know if we're likely to hit any conflicts on the
mtdcore and mtd.h bits. Perhaps it will make sense for us to apply this
first patch as a mini-branch to both our trees? Maybe if you just fixup
any last comments, you can send me a trivial pull request / tag /
whatever (doesn't need to be formal), with just this patch.

> ---
>  drivers/mtd/mtdcore.c   |  94 ++
>  drivers/mtd/mtdpart.c   |   1 +
>  include/linux/mtd/mtd.h | 106 
> 
>  3 files changed, 201 insertions(+)
> 
> diff --git a/drivers/mtd/mtdcore.c b/drivers/mtd/mtdcore.c
> index e3936b847c6b..decceb9fdf32 100644
> --- a/drivers/mtd/mtdcore.c
> +++ b/drivers/mtd/mtdcore.c
> @@ -376,6 +376,100 @@ static int mtd_reboot_notifier(struct notifier_block 
> *n, unsigned long state,
>  }
>  
>  /**
> + * mtd_wunit_to_pairing_info - get pairing information of a wunit
> + * @mtd: pointer to new MTD device info structure
> + * @wunit: write unit we are interrested in

s/interrested/interested/

> + * @info: pairing information struct

Maybe something to indicate this is the return value? e.g., "returned
pairing information"?

> + *
> + * Retrieve pairing information associated to the wunit.
> + * This is mainly useful when dealing with MLC/TLC NANDs where pages can be
> + * paired together, and where programming a page may influence the page it is
> + * paired with.
> + * The notion of page is replaced by the term wunit (write-unit) to stay
> + * consistent with the ->writesize field.
> + *
> + * The @wunit argument can be extracted from an absolute offset using
> + * mtd_offset_to_wunit(). @info is filled with the pairing information 
> attached
> + * to @wunit.
> + *
> + * From the pairing info the MTD user can find all the wunits paired with
> + * @wunit using the following loop:
> + *
> + * for (i = 0; i < mtd_pairing_groups(mtd); i++) {
> + *   info.pair = i;
> + *   mtd_pairing_info_to_wunit(mtd, );
> + *   ...
> + * }
> + */
> +void mtd_wunit_to_pairing_info(struct mtd_info *mtd, int wunit,
> +struct mtd_pairing_info *info)
> +{

Do we want to do any range-checking here? i.e., make this return int? Or
is that too paranoid? We've done similarly on most of the rest of the
MTD API.

Notably, I think we're probably safe keeping the ->pairing->get_info()
callback as returning void, since the driver can expect this core helper
to do the range checking for us.

> + if (!mtd->pairing || !mtd->pairing->get_info) {
> + info->group = 0;
> + info->pair = wunit;
> + } else {
> + mtd->pairing->get_info(mtd, wunit, info);
> + }
> +}
> +EXPORT_SYMBOL_GPL(mtd_wunit_to_pairing_info);
> +
> +/**
> + * mtd_wunit_to_pairing_info - get wunit from pairing information
> + * @mtd: pointer to new MTD device info structure
> + * @info: pairing information struct
> + *
> + * Returns a positive number representing the wunit associated to the info
> + * struct, or a negative error code.
> + *
> + * This is the reverse of mtd_wunit_to_pairing_info(), and can help one to
> + * iterate over all wunits of a given pair (see mtd_wunit_to_pairing_info()
> + * doc).
> + *
> + * It can also be used to only program the first page of each pair (i.e.
> + * page attached to group 0), which allows one to use an MLC NAND in
> + * software-emulated SLC mode:
> + *
> + * info.group = 0;
> + * for (info.pair = 0; info < mtd_wunit_per_eb(mtd); info.pair++) {

(I know it's just example code, but...) the second clause should have
'info.pair < ...', not 'info < ...'.

> + *   wunit = mtd_pairing_info_to_wunit(mtd, );
> + *   mtd_write(mtd, 

[PATCH v5] usb: ohci-at91: Forcibly suspend ports while USB suspend

[Wenyou Yang]

The usb controller does not managed correctly the suspend mode for
the ehci. In echi mode, there is no way to have utmi_suspend_o_n[1]
suspend without any device connected to it. This is why this specific
control is added to fix this issue. The suspend mode works in ohci
mode.

This specific control is by setting the SUSPEND_A/B/C fields of
SFR_OHCIICR(OHCI Interrupt Configuration Register) in the SFR
while OHCI USB suspend.

This setting operation must be done before the USB clock disabled,
clear them after the USB clock enabled.

Signed-off-by: Wenyou Yang 
Reviewed-by: Alexandre Belloni 
Acked-by: Nicolas Ferre 
---

Changes in v5:
 - Use the USB_PORT_FEAT_SUSPEND subcase of the SetPortFeature case
   to take care it.
 - Update the commit log.

Changes in v4:
 - To check whether the SFR node with "atmel,sama5d2-sfr" compatible
   is present or not to decide if this feature is applied or not
   when USB OHCI suspend/resume, instead of new compatible.
 - Drop the compatible "atmel,sama5d2-ohci".
 - Drop [PATCH 2/2] ARM: at91/dt: sama5d2: Use new compatible for
   ohci node.
 - Drop include/soc/at91/at91_sfr.h, move the macro definitions to
   atmel-sfr.h which already exists.
 - Change the defines to align the exists.

Changes in v3:
 - Change the compatible description for more precise.

Changes in v2:
 - Add compatible to support forcibly suspend the ports.
 - Add soc/at91/at91_sfr.h to accommodate the defines.
 - Add error checking for .sfr_regmap.
 - Remove unnecessary regmap_read() statement.

 drivers/usb/host/ohci-at91.c | 72 ++--
 include/soc/at91/atmel-sfr.h |  3 ++
 2 files changed, 73 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/host/ohci-at91.c b/drivers/usb/host/ohci-at91.c
index d177372..4d7d7a0 100644
--- a/drivers/usb/host/ohci-at91.c
+++ b/drivers/usb/host/ohci-at91.c
@@ -21,8 +21,11 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 #include 
 #include 
+#include 
 
 #include "ohci.h"
 
@@ -51,6 +54,7 @@ struct ohci_at91_priv {
struct clk *hclk;
bool clocked;
bool wakeup;/* Saved wake-up state for resume */
+   struct regmap *sfr_regmap;
 };
 /* interface and function clocks; sometimes also an AHB clock */
 
@@ -134,6 +138,17 @@ static void at91_stop_hc(struct platform_device *pdev)
 
 static void usb_hcd_at91_remove (struct usb_hcd *, struct platform_device *);
 
+struct regmap *at91_dt_syscon_sfr(void)
+{
+   struct regmap *regmap;
+
+   regmap = syscon_regmap_lookup_by_compatible("atmel,sama5d2-sfr");
+   if (IS_ERR(regmap))
+   regmap = NULL;
+
+   return regmap;
+}
+
 /* configure so an HC device and id are always provided */
 /* always called with process context; sleeping is OK */
 
@@ -197,6 +212,10 @@ static int usb_hcd_at91_probe(const struct hc_driver 
*driver,
goto err;
}
 
+   ohci_at91->sfr_regmap = at91_dt_syscon_sfr();
+   if (!ohci_at91->sfr_regmap)
+   dev_warn(dev, "failed to find sfr node\n");
+
board = hcd->self.controller->platform_data;
ohci = hcd_to_ohci(hcd);
ohci->num_ports = board->ports;
@@ -282,6 +301,28 @@ static int ohci_at91_hub_status_data(struct usb_hcd *hcd, 
char *buf)
return length;
 }
 
+static int ohci_at91_port_ctrl(struct regmap *regmap, u16 port, u8 set)
+{
+   u32 regval;
+   int ret;
+
+   if (!regmap)
+   return 0;
+
+   ret = regmap_read(regmap, AT91_SFR_OHCIICR, );
+   if (ret)
+   return ret;
+
+   if (set)
+   regval |= AT91_OHCIICR_SUSPEND(port);
+   else
+   regval &= ~AT91_OHCIICR_SUSPEND(port);
+
+   regmap_write(regmap, AT91_SFR_OHCIICR, regval);
+
+   return 0;
+}
+
 /*
  * Look at the control requests to the root hub and see if we need to override.
  */
@@ -289,6 +330,7 @@ static int ohci_at91_hub_control(struct usb_hcd *hcd, u16 
typeReq, u16 wValue,
 u16 wIndex, char *buf, u16 wLength)
 {
struct at91_usbh_data *pdata = dev_get_platdata(hcd->self.controller);
+   struct ohci_at91_priv *ohci_at91 = hcd_to_ohci_at91_priv(hcd);
struct usb_hub_descriptor *desc;
int ret = -EINVAL;
u32 *data = (u32 *)buf;
@@ -301,7 +343,8 @@ static int ohci_at91_hub_control(struct usb_hcd *hcd, u16 
typeReq, u16 wValue,
 
switch (typeReq) {
case SetPortFeature:
-   if (wValue == USB_PORT_FEAT_POWER) {
+   switch (wValue) {
+   case USB_PORT_FEAT_POWER:
dev_dbg(hcd->self.controller, "SetPortFeat: POWER\n");
if (valid_port(wIndex)) {
ohci_at91_usb_set_power(pdata, wIndex, 1);
@@ -309,6 +352,11 @@ static int ohci_at91_hub_control(struct usb_hcd *hcd, u16 
typeReq, u16 wValue,
}
 
goto out;
+
+   case 

[PATCH v6 2/2] irqchip: add J-Core AIC driver

[Rich Felker]

There are two versions of the J-Core interrupt controller in use, aic1
which generates interrupts with programmable priorities, but only
supports 8 irq lines and maps them to cpu traps in the range 17 to 24,
and aic2 which uses traps in the range 64-127 and supports up to 128
irqs, with priorities dependent on the interrupt number. The Linux
driver does not make use of priorities anyway.

For simplicity, there is no aic1-specific logic in the driver beyond
setting the priority register, which is necessary for interrupts to
work at all. Eventually aic1 will likely be phased out, but it's
currently in use in deployments and all released bitstream binaries.

Signed-off-by: Rich Felker 
---
 drivers/irqchip/Kconfig |  7 +++
 drivers/irqchip/Makefile|  1 +
 drivers/irqchip/irq-jcore-aic.c | 94 +
 3 files changed, 102 insertions(+)
 create mode 100644 drivers/irqchip/irq-jcore-aic.c

diff --git a/drivers/irqchip/Kconfig b/drivers/irqchip/Kconfig
index 5495a5b..ab84ce3 100644
--- a/drivers/irqchip/Kconfig
+++ b/drivers/irqchip/Kconfig
@@ -156,6 +156,13 @@ config PIC32_EVIC
select GENERIC_IRQ_CHIP
select IRQ_DOMAIN
 
+config JCORE_AIC
+   bool "J-Core integrated AIC"
+   depends on OF && (SUPERH || COMPILE_TEST)
+   select IRQ_DOMAIN
+   help
+ Support for the J-Core integrated AIC.
+
 config RENESAS_INTC_IRQPIN
bool
select IRQ_DOMAIN
diff --git a/drivers/irqchip/Makefile b/drivers/irqchip/Makefile
index 4c203b6..ee7e3ca 100644
--- a/drivers/irqchip/Makefile
+++ b/drivers/irqchip/Makefile
@@ -40,6 +40,7 @@ obj-$(CONFIG_I8259)   += irq-i8259.o
 obj-$(CONFIG_IMGPDC_IRQ)   += irq-imgpdc.o
 obj-$(CONFIG_IRQ_MIPS_CPU) += irq-mips-cpu.o
 obj-$(CONFIG_SIRF_IRQ) += irq-sirfsoc.o
+obj-$(CONFIG_JCORE_AIC)+= irq-jcore-aic.o
 obj-$(CONFIG_RENESAS_INTC_IRQPIN)  += irq-renesas-intc-irqpin.o
 obj-$(CONFIG_RENESAS_IRQC) += irq-renesas-irqc.o
 obj-$(CONFIG_VERSATILE_FPGA_IRQ)   += irq-versatile-fpga.o
diff --git a/drivers/irqchip/irq-jcore-aic.c b/drivers/irqchip/irq-jcore-aic.c
new file mode 100644
index 000..5e5e3bb
--- /dev/null
+++ b/drivers/irqchip/irq-jcore-aic.c
@@ -0,0 +1,94 @@
+/*
+ * J-Core SoC AIC driver
+ *
+ * Copyright (C) 2015-2016 Smart Energy Instruments, Inc.
+ *
+ * This file is subject to the terms and conditions of the GNU General Public
+ * License.  See the file "COPYING" in the main directory of this archive
+ * for more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define JCORE_AIC_MAX_HWIRQ127
+#define JCORE_AIC1_MIN_HWIRQ   16
+#define JCORE_AIC2_MIN_HWIRQ   64
+
+#define JCORE_AIC1_INTPRI_REG  8
+
+static struct irq_chip jcore_aic;
+
+static int jcore_aic_irqdomain_map(struct irq_domain *d, unsigned int irq,
+  irq_hw_number_t hwirq)
+{
+   struct irq_chip *aic = d->host_data;
+
+   irq_set_chip_and_handler(irq, aic, handle_simple_irq);
+
+   return 0;
+}
+
+static const struct irq_domain_ops jcore_aic_irqdomain_ops = {
+   .map = jcore_aic_irqdomain_map,
+   .xlate = irq_domain_xlate_onecell,
+};
+
+static void noop(struct irq_data *data)
+{
+}
+
+int __init aic_irq_of_init(struct device_node *node, struct device_node 
*parent)
+{
+   unsigned min_irq = JCORE_AIC2_MIN_HWIRQ;
+   unsigned dom_sz = JCORE_AIC_MAX_HWIRQ+1;
+   struct irq_domain *domain;
+
+   pr_info("Initializing J-Core AIC\n");
+
+   /* AIC1 needs priority initialization to receive interrupts. */
+   if (of_device_is_compatible(node, "jcore,aic1")) {
+   unsigned cpu;
+
+   for_each_present_cpu(cpu) {
+   void __iomem *base = of_iomap(node, cpu);
+
+   if (!base) {
+   pr_err("Unable to map AIC for cpu %u\n", cpu);
+   return -ENOMEM;
+   }
+   __raw_writel(0x, base + JCORE_AIC1_INTPRI_REG);
+   iounmap(base);
+   }
+   min_irq = JCORE_AIC1_MIN_HWIRQ;
+   }
+
+   /*
+* The irq chip framework requires either mask/unmask or enable/disable
+* function pointers to be provided, but the hardware does not have any
+* such mechanism; the only interrupt masking is at the cpu level and
+* it affects all interrupts. We provide dummy mask/unmask. The hardware
+* handles all interrupt control and clears pending status when the cpu
+* accepts the interrupt.
+*/
+   jcore_aic.irq_mask = noop;
+   jcore_aic.irq_unmask = noop;
+   jcore_aic.name = "AIC";
+
+   domain = irq_domain_add_linear(node, dom_sz, _aic_irqdomain_ops,
+  _aic);
+   if (!domain)
+ 

[PATCH v6 0/2] J-Core interrupt controller support

[Rich Felker]

Updated based on feedback from Thomas Gleixner. Removal of unnecessary
data allowed some simplification. Magic numbers have been replaced
with meaningful (I hope) macro constants, comments added, and minor
style issues fixed.

Also, driver was made conditional in Kconfig to avoid it showing up in
configurations where it's not relevant.

Rich


Rich Felker (2):
  of: add J-Core interrupt controller bindings
  irqchip: add J-Core AIC driver

 .../bindings/interrupt-controller/jcore,aic.txt| 26 ++
 drivers/irqchip/Kconfig|  7 ++
 drivers/irqchip/Makefile   |  1 +
 drivers/irqchip/irq-jcore-aic.c| 94 ++
 4 files changed, 128 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/interrupt-controller/jcore,aic.txt
 create mode 100644 drivers/irqchip/irq-jcore-aic.c

-- 
2.8.1

[PATCH v6 1/2] of: add J-Core interrupt controller bindings

[Rich Felker]

Signed-off-by: Rich Felker 
Acked-by: Rob Herring 
---
 .../bindings/interrupt-controller/jcore,aic.txt| 26 ++
 1 file changed, 26 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/interrupt-controller/jcore,aic.txt

diff --git 
a/Documentation/devicetree/bindings/interrupt-controller/jcore,aic.txt 
b/Documentation/devicetree/bindings/interrupt-controller/jcore,aic.txt
new file mode 100644
index 000..ee2ad36
--- /dev/null
+++ b/Documentation/devicetree/bindings/interrupt-controller/jcore,aic.txt
@@ -0,0 +1,26 @@
+J-Core Advanced Interrupt Controller
+
+Required properties:
+
+- compatible: Should be "jcore,aic1" for the (obsolete) first-generation aic
+  with 8 interrupt lines with programmable priorities, or "jcore,aic2" for
+  the "aic2" core with 64 interrupts.
+
+- reg: Memory region(s) for configuration. For SMP, there should be one
+  region per cpu, indexed by the sequential, zero-based hardware cpu
+  number.
+
+- interrupt-controller: Identifies the node as an interrupt controller
+
+- #interrupt-cells: Specifies the number of cells needed to encode an
+  interrupt source. The value shall be 1.
+
+
+Example:
+
+aic: interrupt-controller@200 {
+   compatible = "jcore,aic2";
+   reg = < 0x200 0x30 0x500 0x30 >;
+   interrupt-controller;
+   #interrupt-cells = <1>;
+};
-- 
2.8.1

[PATCH v6 0/2] J-Core interrupt controller support

[Rich Felker]

Updated based on feedback from Thomas Gleixner. Removal of unnecessary
data allowed some simplification. Magic numbers have been replaced
with meaningful (I hope) macro constants, comments added, and minor
style issues fixed.

Also, driver was made conditional in Kconfig to avoid it showing up in
configurations where it's not relevant.

Rich


Rich Felker (2):
  of: add J-Core interrupt controller bindings
  irqchip: add J-Core AIC driver

 .../bindings/interrupt-controller/jcore,aic.txt| 26 ++
 drivers/irqchip/Kconfig|  7 ++
 drivers/irqchip/Makefile   |  1 +
 drivers/irqchip/irq-jcore-aic.c| 94 ++
 4 files changed, 128 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/interrupt-controller/jcore,aic.txt
 create mode 100644 drivers/irqchip/irq-jcore-aic.c

-- 
2.8.1

[PATCH v6 1/2] of: add J-Core interrupt controller bindings

[Rich Felker]

Signed-off-by: Rich Felker 
Acked-by: Rob Herring 
---
 .../bindings/interrupt-controller/jcore,aic.txt| 26 ++
 1 file changed, 26 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/interrupt-controller/jcore,aic.txt

diff --git 
a/Documentation/devicetree/bindings/interrupt-controller/jcore,aic.txt 
b/Documentation/devicetree/bindings/interrupt-controller/jcore,aic.txt
new file mode 100644
index 000..ee2ad36
--- /dev/null
+++ b/Documentation/devicetree/bindings/interrupt-controller/jcore,aic.txt
@@ -0,0 +1,26 @@
+J-Core Advanced Interrupt Controller
+
+Required properties:
+
+- compatible: Should be "jcore,aic1" for the (obsolete) first-generation aic
+  with 8 interrupt lines with programmable priorities, or "jcore,aic2" for
+  the "aic2" core with 64 interrupts.
+
+- reg: Memory region(s) for configuration. For SMP, there should be one
+  region per cpu, indexed by the sequential, zero-based hardware cpu
+  number.
+
+- interrupt-controller: Identifies the node as an interrupt controller
+
+- #interrupt-cells: Specifies the number of cells needed to encode an
+  interrupt source. The value shall be 1.
+
+
+Example:
+
+aic: interrupt-controller@200 {
+   compatible = "jcore,aic2";
+   reg = < 0x200 0x30 0x500 0x30 >;
+   interrupt-controller;
+   #interrupt-cells = <1>;
+};
-- 
2.8.1

[PATCH v6 2/2] irqchip: add J-Core AIC driver

[Rich Felker]

There are two versions of the J-Core interrupt controller in use, aic1
which generates interrupts with programmable priorities, but only
supports 8 irq lines and maps them to cpu traps in the range 17 to 24,
and aic2 which uses traps in the range 64-127 and supports up to 128
irqs, with priorities dependent on the interrupt number. The Linux
driver does not make use of priorities anyway.

For simplicity, there is no aic1-specific logic in the driver beyond
setting the priority register, which is necessary for interrupts to
work at all. Eventually aic1 will likely be phased out, but it's
currently in use in deployments and all released bitstream binaries.

Signed-off-by: Rich Felker 
---
 drivers/irqchip/Kconfig |  7 +++
 drivers/irqchip/Makefile|  1 +
 drivers/irqchip/irq-jcore-aic.c | 94 +
 3 files changed, 102 insertions(+)
 create mode 100644 drivers/irqchip/irq-jcore-aic.c

diff --git a/drivers/irqchip/Kconfig b/drivers/irqchip/Kconfig
index 5495a5b..ab84ce3 100644
--- a/drivers/irqchip/Kconfig
+++ b/drivers/irqchip/Kconfig
@@ -156,6 +156,13 @@ config PIC32_EVIC
select GENERIC_IRQ_CHIP
select IRQ_DOMAIN
 
+config JCORE_AIC
+   bool "J-Core integrated AIC"
+   depends on OF && (SUPERH || COMPILE_TEST)
+   select IRQ_DOMAIN
+   help
+ Support for the J-Core integrated AIC.
+
 config RENESAS_INTC_IRQPIN
bool
select IRQ_DOMAIN
diff --git a/drivers/irqchip/Makefile b/drivers/irqchip/Makefile
index 4c203b6..ee7e3ca 100644
--- a/drivers/irqchip/Makefile
+++ b/drivers/irqchip/Makefile
@@ -40,6 +40,7 @@ obj-$(CONFIG_I8259)   += irq-i8259.o
 obj-$(CONFIG_IMGPDC_IRQ)   += irq-imgpdc.o
 obj-$(CONFIG_IRQ_MIPS_CPU) += irq-mips-cpu.o
 obj-$(CONFIG_SIRF_IRQ) += irq-sirfsoc.o
+obj-$(CONFIG_JCORE_AIC)+= irq-jcore-aic.o
 obj-$(CONFIG_RENESAS_INTC_IRQPIN)  += irq-renesas-intc-irqpin.o
 obj-$(CONFIG_RENESAS_IRQC) += irq-renesas-irqc.o
 obj-$(CONFIG_VERSATILE_FPGA_IRQ)   += irq-versatile-fpga.o
diff --git a/drivers/irqchip/irq-jcore-aic.c b/drivers/irqchip/irq-jcore-aic.c
new file mode 100644
index 000..5e5e3bb
--- /dev/null
+++ b/drivers/irqchip/irq-jcore-aic.c
@@ -0,0 +1,94 @@
+/*
+ * J-Core SoC AIC driver
+ *
+ * Copyright (C) 2015-2016 Smart Energy Instruments, Inc.
+ *
+ * This file is subject to the terms and conditions of the GNU General Public
+ * License.  See the file "COPYING" in the main directory of this archive
+ * for more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define JCORE_AIC_MAX_HWIRQ127
+#define JCORE_AIC1_MIN_HWIRQ   16
+#define JCORE_AIC2_MIN_HWIRQ   64
+
+#define JCORE_AIC1_INTPRI_REG  8
+
+static struct irq_chip jcore_aic;
+
+static int jcore_aic_irqdomain_map(struct irq_domain *d, unsigned int irq,
+  irq_hw_number_t hwirq)
+{
+   struct irq_chip *aic = d->host_data;
+
+   irq_set_chip_and_handler(irq, aic, handle_simple_irq);
+
+   return 0;
+}
+
+static const struct irq_domain_ops jcore_aic_irqdomain_ops = {
+   .map = jcore_aic_irqdomain_map,
+   .xlate = irq_domain_xlate_onecell,
+};
+
+static void noop(struct irq_data *data)
+{
+}
+
+int __init aic_irq_of_init(struct device_node *node, struct device_node 
*parent)
+{
+   unsigned min_irq = JCORE_AIC2_MIN_HWIRQ;
+   unsigned dom_sz = JCORE_AIC_MAX_HWIRQ+1;
+   struct irq_domain *domain;
+
+   pr_info("Initializing J-Core AIC\n");
+
+   /* AIC1 needs priority initialization to receive interrupts. */
+   if (of_device_is_compatible(node, "jcore,aic1")) {
+   unsigned cpu;
+
+   for_each_present_cpu(cpu) {
+   void __iomem *base = of_iomap(node, cpu);
+
+   if (!base) {
+   pr_err("Unable to map AIC for cpu %u\n", cpu);
+   return -ENOMEM;
+   }
+   __raw_writel(0x, base + JCORE_AIC1_INTPRI_REG);
+   iounmap(base);
+   }
+   min_irq = JCORE_AIC1_MIN_HWIRQ;
+   }
+
+   /*
+* The irq chip framework requires either mask/unmask or enable/disable
+* function pointers to be provided, but the hardware does not have any
+* such mechanism; the only interrupt masking is at the cpu level and
+* it affects all interrupts. We provide dummy mask/unmask. The hardware
+* handles all interrupt control and clears pending status when the cpu
+* accepts the interrupt.
+*/
+   jcore_aic.irq_mask = noop;
+   jcore_aic.irq_unmask = noop;
+   jcore_aic.name = "AIC";
+
+   domain = irq_domain_add_linear(node, dom_sz, _aic_irqdomain_ops,
+  _aic);
+   if (!domain)
+   return 

Re: Generic section maintainers

[Josh Poimboeuf]

On Wed, Aug 03, 2016 at 12:56:22PM -0700, Luis R. Rodriguez wrote:
> Arnd, Josh,
> 
> In my linker table work [0], other than the linker table work and
> section ranges stuff, I'm adding:
> 
> o include/linux/sections.h
> o include/asm-generic/section-core.h (not in RFC v3 but it is in my
> RFC v4 series not yet posted, splitting this up fixes compilation on
> powerpc which otherwise creates a header issue nightmare to resolve)
> 
> I extend include/asm-generic/sections.h to then include
> , and furthermore provide the beginning of
> a central place to document in a central place all common sections.
> 
> As per checkpatch complaints I'll be adding myself to MAINTAINERS for
> the linker table headers, section ranges, but noticed then we don't
> have anyone in particularly looking carefully after
> include/asm-generic/sections.h other than the default which is Arnd.
> Given this work on streamlining the section stuff, I'd like to help so
> am considering adding a specific entry on MAINTAINRERS for generic
> sections and adding myself to it along with Arnd. Wanted to check if
> this is OK. While at it, it occurred to me that you might be
> interested in this a swell Josh, given your work with objtool. Would
> anyone else like to help with active maintenance / review of these ?
> 
> So is this OK to merge into my series into the patch "sections.h: add
> sections header to collect all section info".
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 49b354cb455a..9919277c66ae 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -5190,6 +5190,18 @@ S: Supported
>  F: drivers/base/power/domain*.c
>  F: include/linux/pm_domain.h
> 
> +GENERIC SECTIONS
> +M: "Luis R. Rodriguez" 
> +M: Josh Poimboeuf 
> +M: Arnd Bergmann 
> +L: linux-a...@vger.kernel.org
> +L: linux-kernel@vger.kernel.org
> +S: Supported
> +F: include/asm-generic/section-core.h
> +F: include/asm-generic/sections.h
> +F: include/asm-generic/vmlinux.lds.h
> +F: Documentation/DocBook/sections.tmpl

Hi Luis,

Thanks to my past work with objtool and kpatch, I know far more than I
ever wanted to know about all the kernel's custom ELF sections.  So it's
fine with me if you want to add me as a maintainer for those files.

-- 
Josh

Re: Generic section maintainers

[Josh Poimboeuf]

On Wed, Aug 03, 2016 at 12:56:22PM -0700, Luis R. Rodriguez wrote:
> Arnd, Josh,
> 
> In my linker table work [0], other than the linker table work and
> section ranges stuff, I'm adding:
> 
> o include/linux/sections.h
> o include/asm-generic/section-core.h (not in RFC v3 but it is in my
> RFC v4 series not yet posted, splitting this up fixes compilation on
> powerpc which otherwise creates a header issue nightmare to resolve)
> 
> I extend include/asm-generic/sections.h to then include
> , and furthermore provide the beginning of
> a central place to document in a central place all common sections.
> 
> As per checkpatch complaints I'll be adding myself to MAINTAINERS for
> the linker table headers, section ranges, but noticed then we don't
> have anyone in particularly looking carefully after
> include/asm-generic/sections.h other than the default which is Arnd.
> Given this work on streamlining the section stuff, I'd like to help so
> am considering adding a specific entry on MAINTAINRERS for generic
> sections and adding myself to it along with Arnd. Wanted to check if
> this is OK. While at it, it occurred to me that you might be
> interested in this a swell Josh, given your work with objtool. Would
> anyone else like to help with active maintenance / review of these ?
> 
> So is this OK to merge into my series into the patch "sections.h: add
> sections header to collect all section info".
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 49b354cb455a..9919277c66ae 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -5190,6 +5190,18 @@ S: Supported
>  F: drivers/base/power/domain*.c
>  F: include/linux/pm_domain.h
> 
> +GENERIC SECTIONS
> +M: "Luis R. Rodriguez" 
> +M: Josh Poimboeuf 
> +M: Arnd Bergmann 
> +L: linux-a...@vger.kernel.org
> +L: linux-kernel@vger.kernel.org
> +S: Supported
> +F: include/asm-generic/section-core.h
> +F: include/asm-generic/sections.h
> +F: include/asm-generic/vmlinux.lds.h
> +F: Documentation/DocBook/sections.tmpl

Hi Luis,

Thanks to my past work with objtool and kpatch, I know far more than I
ever wanted to know about all the kernel's custom ELF sections.  So it's
fine with me if you want to add me as a maintainer for those files.

-- 
Josh

Re: [RFC PATCH v7 1/7] Restartable sequences system call

[Boqun Feng]

On Wed, Aug 03, 2016 at 09:37:57AM -0700, Andy Lutomirski wrote:
> On Wed, Aug 3, 2016 at 5:27 AM, Peter Zijlstra  wrote:
> > On Tue, Jul 26, 2016 at 03:02:19AM +, Mathieu Desnoyers wrote:
> >> We really care about preemption here. Every migration implies a
> >> preemption from a user-space perspective. If we would only care
> >> about keeping the CPU id up-to-date, hooking into migration would be
> >> enough. But since we want atomicity guarantees for restartable
> >> sequences, we need to hook into preemption.
> >
> >> It allows user-space to perform update operations on per-cpu data without
> >> requiring heavy-weight atomic operations.
> >
> > Well, a CMPXCHG without LOCK prefix isn't all that expensive on x86.
> >
> > It is however on PPC and possibly other architectures, so in name of
> > simplicity supporting only the one variant makes sense.
> >
> 
> I wouldn't want to depend on CMPXCHG.  But imagine we had primitives
> that were narrower than the full abort-on-preemption primitive.
> Specifically, suppose we had abort if (actual cpu != expected_cpu ||
> *aptr != aval).  We could do things like:
> 
> expected_cpu = cpu;
> aval = NULL;  // disarm for now
> begin();
> aval = event_count[cpu] + 1;
> event_count[cpu] = aval;
> event_count[cpu]++;

This line is redundant, right? Because it will guarantee a failure even
in no-contention cases.

> 
> ... compute something ...
> 
> // arm the rest of it
> aptr = _count[cpu];
> if (*aptr != aval)
>   goto fail;
> 
> *thing_im_writing = value_i_computed;
> end();
> 
> The idea here is that we don't rely on the scheduler to increment the
> event count at all, which means that we get to determine the scope of
> what kinds of access conflicts we care about ourselves.
> 

If we increase the event count in userspace, how could we prevent two
userspace threads from racing on the event_count[cpu] field? For
example:

CPU 0

{event_count[0] is initially 0}

[Thread 1]
begin();
aval = event_count[cpu] + 1; // 1

(preempted)
[Thread 2]
begin();
aval = event_count[cpu] + 1; // 1, too
event_count[cpu] = aval; // event_count[0] is 1

(preempted)
[Thread 1]
event_count[cpu] = aval; // event_count[0] is 1

... 

aptr = _count[cpu];
if (*aptr != aval) // false.
...

[Thread 2]
aptr = _count[cpu];
if (*aptr != aval) // false.
...

, in which case, both the critical sections are successful, and Thread 1
and Thread 2 will race on *thing_im_writing.

Am I missing your point here?

Regards,
Boqun

> This has an obvious downside: it's more complicated.
> 
> It has several benefits, I think.  It's debuggable without hassle
> (unless someone, accidentally or otherwise, sets aval incorrectly).
> It also allows much longer critical sections to work well, as merely
> being preempted in the middle won't cause an abort any more.
> 
> So I'm hoping to understand whether we could make something like this
> work.  This whole thing is roughly equivalent to abort-if-migrated
> plus an atomic "if (*aptr == aval) *b = c;" operation.
> 
> (I think that, if this worked, we could improve it a bit by making the
> abort operation jump back to the "if (*aptr != aval) goto fail;" code,
> which should reduce the scope for error a bit and also reduces the
> need for extra code paths that only execute on an abort.)


signature.asc
Description: PGP signature

Re: [RFC PATCH v7 1/7] Restartable sequences system call

[Boqun Feng]

On Wed, Aug 03, 2016 at 09:37:57AM -0700, Andy Lutomirski wrote:
> On Wed, Aug 3, 2016 at 5:27 AM, Peter Zijlstra  wrote:
> > On Tue, Jul 26, 2016 at 03:02:19AM +, Mathieu Desnoyers wrote:
> >> We really care about preemption here. Every migration implies a
> >> preemption from a user-space perspective. If we would only care
> >> about keeping the CPU id up-to-date, hooking into migration would be
> >> enough. But since we want atomicity guarantees for restartable
> >> sequences, we need to hook into preemption.
> >
> >> It allows user-space to perform update operations on per-cpu data without
> >> requiring heavy-weight atomic operations.
> >
> > Well, a CMPXCHG without LOCK prefix isn't all that expensive on x86.
> >
> > It is however on PPC and possibly other architectures, so in name of
> > simplicity supporting only the one variant makes sense.
> >
> 
> I wouldn't want to depend on CMPXCHG.  But imagine we had primitives
> that were narrower than the full abort-on-preemption primitive.
> Specifically, suppose we had abort if (actual cpu != expected_cpu ||
> *aptr != aval).  We could do things like:
> 
> expected_cpu = cpu;
> aval = NULL;  // disarm for now
> begin();
> aval = event_count[cpu] + 1;
> event_count[cpu] = aval;
> event_count[cpu]++;

This line is redundant, right? Because it will guarantee a failure even
in no-contention cases.

> 
> ... compute something ...
> 
> // arm the rest of it
> aptr = _count[cpu];
> if (*aptr != aval)
>   goto fail;
> 
> *thing_im_writing = value_i_computed;
> end();
> 
> The idea here is that we don't rely on the scheduler to increment the
> event count at all, which means that we get to determine the scope of
> what kinds of access conflicts we care about ourselves.
> 

If we increase the event count in userspace, how could we prevent two
userspace threads from racing on the event_count[cpu] field? For
example:

CPU 0

{event_count[0] is initially 0}

[Thread 1]
begin();
aval = event_count[cpu] + 1; // 1

(preempted)
[Thread 2]
begin();
aval = event_count[cpu] + 1; // 1, too
event_count[cpu] = aval; // event_count[0] is 1

(preempted)
[Thread 1]
event_count[cpu] = aval; // event_count[0] is 1

... 

aptr = _count[cpu];
if (*aptr != aval) // false.
...

[Thread 2]
aptr = _count[cpu];
if (*aptr != aval) // false.
...

, in which case, both the critical sections are successful, and Thread 1
and Thread 2 will race on *thing_im_writing.

Am I missing your point here?

Regards,
Boqun

> This has an obvious downside: it's more complicated.
> 
> It has several benefits, I think.  It's debuggable without hassle
> (unless someone, accidentally or otherwise, sets aval incorrectly).
> It also allows much longer critical sections to work well, as merely
> being preempted in the middle won't cause an abort any more.
> 
> So I'm hoping to understand whether we could make something like this
> work.  This whole thing is roughly equivalent to abort-if-migrated
> plus an atomic "if (*aptr == aval) *b = c;" operation.
> 
> (I think that, if this worked, we could improve it a bit by making the
> abort operation jump back to the "if (*aptr != aval) goto fail;" code,
> which should reduce the scope for error a bit and also reduces the
> need for extra code paths that only execute on an abort.)


signature.asc
Description: PGP signature

linux-next: Tree for Aug 4

[Stephen Rothwell]

Hi all,

Please do not add material destined for v4.9 to your linux-next included
branches until after v4.8-rc1 has been released.

Changes since 20160803:

The v4l-dvb tree gained a conflict against Linus' tree.

The thermal-soc tree gained a conflict against the thermal tree.

Non-merge commits (relative to Linus' tree): 973
 1499 files changed, 45968 insertions(+), 74088 deletions(-)



I have created today's linux-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
(patches at http://www.kernel.org/pub/linux/kernel/next/ ).  If you
are tracking the linux-next tree using git, you should not use "git pull"
to do so as that will try to merge the new linux-next release with the
old one.  You should use "git fetch" and checkout or reset to the new
master.

You can see which trees have been included by looking in the Next/Trees
file in the source.  There are also quilt-import.log and merge.log
files in the Next directory.  Between each merge, the tree was built
with a ppc64_defconfig for powerpc and an allmodconfig (with
CONFIG_BUILD_DOCSRC=n) for x86_64, a multi_v7_defconfig for arm and a
native build of tools/perf. After the final fixups (if any), I do an
x86_64 modules_install followed by builds for x86_64 allnoconfig,
powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig, allyesconfig
(this fails its final link) and pseries_le_defconfig and i386, sparc
and sparc64 defconfig.

Below is a summary of the state of the merge.

I am currently merging 241 trees (counting Linus' and 35 trees of patches
pending for Linus' tree).

Stats about the size of the tree over time can be seen at
http://neuling.org/linux-next-size.html .

Status of my local build tests will be at
http://kisskb.ellerman.id.au/linux-next .  If maintainers want to give
advice about cross compilers/configs that work, we are always open to add
more builds.

Thanks to Randy Dunlap for doing many randconfig builds.  And to Paul
Gortmaker for triage and bug fixes.

-- 
Cheers,
Stephen Rothwell

$ git checkout master
$ git reset --hard stable
Merging origin/master (4620a06e4b3c shmem: Fix link error if huge pages support 
is disabled)
Merging fixes/master (77a87824ed67 clocksource/drivers/clps_711x: fixup for 
"ARM: clps711x:)
Merging kbuild-current/rc-fixes (b36fad65d61f kbuild: Initialize exported 
variables)
Merging arc-current/for-curr (9bd54517ee86 arc: unwind: warn only once if 
DW2_UNWIND is disabled)
Merging arm-current/fixes (f6492164ecb1 ARM: 8577/1: Fix Cortex-A15 798181 
errata initialization)
Merging m68k-current/for-linus (6bd80f372371 m68k/defconfig: Update defconfigs 
for v4.7-rc2)
Merging metag-fixes/fixes (0164a711c97b metag: Fix ioremap_wc/ioremap_cached 
build errors)
Merging powerpc-fixes/fixes (bad60e6f259a Merge tag 'powerpc-4.8-1' of 
git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux)
Merging powerpc-merge-mpe/fixes (bc0195aad0da Linux 4.2-rc2)
Merging sparc/master (4620a06e4b3c shmem: Fix link error if huge pages support 
is disabled)
Merging net/master (7cf210dc2678 Merge branch 'qlcnic-fixes')
Merging ipsec/master (6916fb3b10b3 xfrm: Ignore socket policies when rebuilding 
hash tables)
Merging netfilter/master (43dcff349f09 net: qlcnic: avoid superfluous 
assignement)
Merging ipvs/master (ea43f860d984 Merge branch 'ethoc-fixes')
Merging wireless-drivers/master (034fdd4a17ff Merge ath-current from ath.git)
Merging mac80211/master (c37a54ac37e7 mac80211: mesh: flush stations before 
beacons are stopped)
Merging sound-current/for-linus (fd48331f9b71 ALSA: hda: add AMD Bonaire AZ PCI 
ID with proper driver caps)
Merging pci-current/for-linus (ef0dab4aae14 PCI: Fix unaligned accesses in VC 
code)
Merging driver-core.current/driver-core-linus (523d939ef98f Linux 4.7)
Merging tty.current/tty-linus (0e06f5c0deee Merge branch 'akpm' (patches from 
Andrew))
Merging usb.current/usb-linus (e65805251f2d Merge branch 'irq-core-for-linus' 
of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip)
Merging usb-gadget-fixes/fixes (50c763f8c1ba usb: dwc3: Set the ClearPendIN bit 
on Clear Stall EP command)
Merging usb-serial-fixes/usb-linus (4c2e07c6a29e Linux 4.7-rc5)
Merging usb-chipidea-fixes/ci-for-usb-stable (ea1d39a31d3b usb: common: 
otg-fsm: add license to usb-otg-fsm)
Merging staging.current/staging-linus (0e06f5c0deee Merge branch 'akpm' 
(patches from Andrew))
Merging char-misc.current/char-misc-linus (0e06f5c0deee Merge branch 'akpm' 
(patches from Andrew))
Merging input-current/for-linus (080888286377 Merge branch 'next' into 
for-linus)
Merging crypto-current/master (8cf740ae85df crypto: marvell - Don't copy IV 
vectors from the _process op for ciphers)
Merging ide/master (797cee982eef Merge branch 'stable-4.8' of 
git://git.infradead.org/users/pcmoore/audit)
Merging rr-fixes/fixes (8244062ef1e5 modules: fix longstanding /proc/kallsyms 
vs module insertion race.)
Merging vfio-fixes/for-lin

linux-next: Tree for Aug 4

[Stephen Rothwell]

Hi all,

Please do not add material destined for v4.9 to your linux-next included
branches until after v4.8-rc1 has been released.

Changes since 20160803:

The v4l-dvb tree gained a conflict against Linus' tree.

The thermal-soc tree gained a conflict against the thermal tree.

Non-merge commits (relative to Linus' tree): 973
 1499 files changed, 45968 insertions(+), 74088 deletions(-)



I have created today's linux-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
(patches at http://www.kernel.org/pub/linux/kernel/next/ ).  If you
are tracking the linux-next tree using git, you should not use "git pull"
to do so as that will try to merge the new linux-next release with the
old one.  You should use "git fetch" and checkout or reset to the new
master.

You can see which trees have been included by looking in the Next/Trees
file in the source.  There are also quilt-import.log and merge.log
files in the Next directory.  Between each merge, the tree was built
with a ppc64_defconfig for powerpc and an allmodconfig (with
CONFIG_BUILD_DOCSRC=n) for x86_64, a multi_v7_defconfig for arm and a
native build of tools/perf. After the final fixups (if any), I do an
x86_64 modules_install followed by builds for x86_64 allnoconfig,
powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig, allyesconfig
(this fails its final link) and pseries_le_defconfig and i386, sparc
and sparc64 defconfig.

Below is a summary of the state of the merge.

I am currently merging 241 trees (counting Linus' and 35 trees of patches
pending for Linus' tree).

Stats about the size of the tree over time can be seen at
http://neuling.org/linux-next-size.html .

Status of my local build tests will be at
http://kisskb.ellerman.id.au/linux-next .  If maintainers want to give
advice about cross compilers/configs that work, we are always open to add
more builds.

Thanks to Randy Dunlap for doing many randconfig builds.  And to Paul
Gortmaker for triage and bug fixes.

-- 
Cheers,
Stephen Rothwell

$ git checkout master
$ git reset --hard stable
Merging origin/master (4620a06e4b3c shmem: Fix link error if huge pages support 
is disabled)
Merging fixes/master (77a87824ed67 clocksource/drivers/clps_711x: fixup for 
"ARM: clps711x:)
Merging kbuild-current/rc-fixes (b36fad65d61f kbuild: Initialize exported 
variables)
Merging arc-current/for-curr (9bd54517ee86 arc: unwind: warn only once if 
DW2_UNWIND is disabled)
Merging arm-current/fixes (f6492164ecb1 ARM: 8577/1: Fix Cortex-A15 798181 
errata initialization)
Merging m68k-current/for-linus (6bd80f372371 m68k/defconfig: Update defconfigs 
for v4.7-rc2)
Merging metag-fixes/fixes (0164a711c97b metag: Fix ioremap_wc/ioremap_cached 
build errors)
Merging powerpc-fixes/fixes (bad60e6f259a Merge tag 'powerpc-4.8-1' of 
git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux)
Merging powerpc-merge-mpe/fixes (bc0195aad0da Linux 4.2-rc2)
Merging sparc/master (4620a06e4b3c shmem: Fix link error if huge pages support 
is disabled)
Merging net/master (7cf210dc2678 Merge branch 'qlcnic-fixes')
Merging ipsec/master (6916fb3b10b3 xfrm: Ignore socket policies when rebuilding 
hash tables)
Merging netfilter/master (43dcff349f09 net: qlcnic: avoid superfluous 
assignement)
Merging ipvs/master (ea43f860d984 Merge branch 'ethoc-fixes')
Merging wireless-drivers/master (034fdd4a17ff Merge ath-current from ath.git)
Merging mac80211/master (c37a54ac37e7 mac80211: mesh: flush stations before 
beacons are stopped)
Merging sound-current/for-linus (fd48331f9b71 ALSA: hda: add AMD Bonaire AZ PCI 
ID with proper driver caps)
Merging pci-current/for-linus (ef0dab4aae14 PCI: Fix unaligned accesses in VC 
code)
Merging driver-core.current/driver-core-linus (523d939ef98f Linux 4.7)
Merging tty.current/tty-linus (0e06f5c0deee Merge branch 'akpm' (patches from 
Andrew))
Merging usb.current/usb-linus (e65805251f2d Merge branch 'irq-core-for-linus' 
of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip)
Merging usb-gadget-fixes/fixes (50c763f8c1ba usb: dwc3: Set the ClearPendIN bit 
on Clear Stall EP command)
Merging usb-serial-fixes/usb-linus (4c2e07c6a29e Linux 4.7-rc5)
Merging usb-chipidea-fixes/ci-for-usb-stable (ea1d39a31d3b usb: common: 
otg-fsm: add license to usb-otg-fsm)
Merging staging.current/staging-linus (0e06f5c0deee Merge branch 'akpm' 
(patches from Andrew))
Merging char-misc.current/char-misc-linus (0e06f5c0deee Merge branch 'akpm' 
(patches from Andrew))
Merging input-current/for-linus (080888286377 Merge branch 'next' into 
for-linus)
Merging crypto-current/master (8cf740ae85df crypto: marvell - Don't copy IV 
vectors from the _process op for ciphers)
Merging ide/master (797cee982eef Merge branch 'stable-4.8' of 
git://git.infradead.org/users/pcmoore/audit)
Merging rr-fixes/fixes (8244062ef1e5 modules: fix longstanding /proc/kallsyms 
vs module insertion race.)
Merging vfio-fixes/for-lin

Re: [PATCH v3 2/6] extcon: Add the support for extcon property according to extcon type

[Guenter Roeck]

On Wed, Aug 3, 2016 at 5:42 PM, Chanwoo Choi  wrote:
> Hi Roger,
>
> On 2016년 08월 03일 18:46, Roger Quadros wrote:
>> Hi Chanwoo,
>>

[ ... ]

> +  /*
> +   * Check whether the external connector is attached.
> +   * If external connector is detached, the user can not
> +   * get the property value.
> +   */

 How will this work for USB case? We need to know VBUS and ID states
 even if the USB cable is detached.
>>>
>>> When USB is detached, extcon_get_property return the default value without 
>>> any operation.
>>> The default value of supported property are 0 (zero). If new property need 
>>> the differnt default
>>> value, I'll support it.
>>
>> Is the property a property of the connector or of the cable?
>>
>> In my opinion, ID and VBUS are properties of the USB connector and not of
>> the USB cable. So extcon must provide valid status for those properties
>> even if USB cable or USB_HOST cable is detached.
>
> I don't understand about that if USB and USB_HOST are detached,
> how can the USB be operating? As you mentioned that, extcon must
> provide the valid status for both state and properties.
>

Correct. No cable means that the polarity is unknown, and VBUS must not be
active (for USB_HOST), or it can not be active (for USB).

Only question might be EXTCON_PROP_USB_ID; I am not sure I understand
what it is supposed to return. Maybe it would be worthwhile to document it ?

> So, I already mentioned, When USB and USB_HOST are detached,
> extcon return the default value instead of error value.
> I think that it is reasonable. Why is it not a valid?
>

I agree; I don't know what else could be returned if no cable is
attached, even if we wanted to.

Guenter

Re: [PATCH v3 2/6] extcon: Add the support for extcon property according to extcon type

[Guenter Roeck]

On Wed, Aug 3, 2016 at 5:42 PM, Chanwoo Choi  wrote:
> Hi Roger,
>
> On 2016년 08월 03일 18:46, Roger Quadros wrote:
>> Hi Chanwoo,
>>

[ ... ]

> +  /*
> +   * Check whether the external connector is attached.
> +   * If external connector is detached, the user can not
> +   * get the property value.
> +   */

 How will this work for USB case? We need to know VBUS and ID states
 even if the USB cable is detached.
>>>
>>> When USB is detached, extcon_get_property return the default value without 
>>> any operation.
>>> The default value of supported property are 0 (zero). If new property need 
>>> the differnt default
>>> value, I'll support it.
>>
>> Is the property a property of the connector or of the cable?
>>
>> In my opinion, ID and VBUS are properties of the USB connector and not of
>> the USB cable. So extcon must provide valid status for those properties
>> even if USB cable or USB_HOST cable is detached.
>
> I don't understand about that if USB and USB_HOST are detached,
> how can the USB be operating? As you mentioned that, extcon must
> provide the valid status for both state and properties.
>

Correct. No cable means that the polarity is unknown, and VBUS must not be
active (for USB_HOST), or it can not be active (for USB).

Only question might be EXTCON_PROP_USB_ID; I am not sure I understand
what it is supposed to return. Maybe it would be worthwhile to document it ?

> So, I already mentioned, When USB and USB_HOST are detached,
> extcon return the default value instead of error value.
> I think that it is reasonable. Why is it not a valid?
>

I agree; I don't know what else could be returned if no cable is
attached, even if we wanted to.

Guenter

A question about transparent hugepages

[zhong jiang]

according to the total_mapcount,  Different process can map any subpages of the
transparent hugepages.   How it can happen to ? 

A question about transparent hugepages

[zhong jiang]

according to the total_mapcount,  Different process can map any subpages of the
transparent hugepages.   How it can happen to ? 

Re: [PATCH v2] powerpc/32: fix csum_partial_copy_generic()

[Scott Wood]

On Tue, 2016-08-02 at 10:07 +0200, Christophe Leroy wrote:
> commit 7aef4136566b0 ("powerpc32: rewrite csum_partial_copy_generic()
> based on copy_tofrom_user()") introduced a bug when destination
> address is odd and initial csum is not null
> 
> In that (rare) case the initial csum value has to be rotated one byte
> as well as the resulting value is
> 
> This patch also fixes related comments
> 
> Fixes: 7aef4136566b0 ("powerpc32: rewrite csum_partial_copy_generic()
> based on copy_tofrom_user()")
> Cc: sta...@vger.kernel.org
> 
> Signed-off-by: Christophe Leroy 
> ---
>  v2: updated comments as suggested by Segher
> 
>  arch/powerpc/lib/checksum_32.S | 7 ---
>  1 file changed, 4 insertions(+), 3 deletions(-)

Alessio, can you confirm whether this fixes the problem you reported?

-Scott

> 
> diff --git a/arch/powerpc/lib/checksum_32.S b/arch/powerpc/lib/checksum_32.S
> index d90870a..0a57fe6 100644
> --- a/arch/powerpc/lib/checksum_32.S
> +++ b/arch/powerpc/lib/checksum_32.S
> @@ -127,8 +127,9 @@ _GLOBAL(csum_partial_copy_generic)
>   stw r7,12(r1)
>   stw r8,8(r1)
>  
> - andi.   r0,r4,1 /* is destination
> address even ? */
> - cmplwi  cr7,r0,0
> + rlwinm  r0,r4,3,0x8
> + rlwnm   r6,r6,r0,0,31   /* odd destination address:
> rotate one byte */
> + cmplwi  cr7,r0,0/* is destination address even ? */
>   addic   r12,r6,0
>   addir6,r4,-4
>   neg r0,r4
> @@ -237,7 +238,7 @@ _GLOBAL(csum_partial_copy_generic)
>  66:  addze   r3,r12
>   addir1,r1,16
>   beqlr+  cr7
> - rlwinm  r3,r3,8,0,31/* swap bytes for odd destination
> */
> + rlwinm  r3,r3,8,0,31/* odd destination address:
> rotate one byte */
>   blr
>  
>  /* read fault */

Re: [PATCH v2] powerpc/32: fix csum_partial_copy_generic()

[Scott Wood]

On Tue, 2016-08-02 at 10:07 +0200, Christophe Leroy wrote:
> commit 7aef4136566b0 ("powerpc32: rewrite csum_partial_copy_generic()
> based on copy_tofrom_user()") introduced a bug when destination
> address is odd and initial csum is not null
> 
> In that (rare) case the initial csum value has to be rotated one byte
> as well as the resulting value is
> 
> This patch also fixes related comments
> 
> Fixes: 7aef4136566b0 ("powerpc32: rewrite csum_partial_copy_generic()
> based on copy_tofrom_user()")
> Cc: sta...@vger.kernel.org
> 
> Signed-off-by: Christophe Leroy 
> ---
>  v2: updated comments as suggested by Segher
> 
>  arch/powerpc/lib/checksum_32.S | 7 ---
>  1 file changed, 4 insertions(+), 3 deletions(-)

Alessio, can you confirm whether this fixes the problem you reported?

-Scott

> 
> diff --git a/arch/powerpc/lib/checksum_32.S b/arch/powerpc/lib/checksum_32.S
> index d90870a..0a57fe6 100644
> --- a/arch/powerpc/lib/checksum_32.S
> +++ b/arch/powerpc/lib/checksum_32.S
> @@ -127,8 +127,9 @@ _GLOBAL(csum_partial_copy_generic)
>   stw r7,12(r1)
>   stw r8,8(r1)
>  
> - andi.   r0,r4,1 /* is destination
> address even ? */
> - cmplwi  cr7,r0,0
> + rlwinm  r0,r4,3,0x8
> + rlwnm   r6,r6,r0,0,31   /* odd destination address:
> rotate one byte */
> + cmplwi  cr7,r0,0/* is destination address even ? */
>   addic   r12,r6,0
>   addir6,r4,-4
>   neg r0,r4
> @@ -237,7 +238,7 @@ _GLOBAL(csum_partial_copy_generic)
>  66:  addze   r3,r12
>   addir1,r1,16
>   beqlr+  cr7
> - rlwinm  r3,r3,8,0,31/* swap bytes for odd destination
> */
> + rlwinm  r3,r3,8,0,31/* odd destination address:
> rotate one byte */
>   blr
>  
>  /* read fault */

RE: [PATCH] usb: ohci-at91: Suspend the ports while USB suspending

[Yang, Wenyou]

Hi Alan,

From: Alan Stern [st...@rowland.harvard.edu]
Sent: Friday, May 13, 2016 2:11
To: Yang, Wenyou
Cc: Greg Kroah-Hartman; Ferre, Nicolas; linux-...@vger.kernel.org; 
linux-kernel@vger.kernel.org; linux-arm-ker...@lists.infradead.org
Subject: Re: [PATCH] usb: ohci-at91: Suspend the ports while USB suspending

On Thu, 12 May 2016, Wenyou Yang wrote:

> In order to get lower consumption, as a workaround, suspend
> the USB PORTA/B/C via set the SUSPEND_A/B/C bits of OHCI Interrupt
> Configuration Register while OHCI USB suspending.

What does this mean?  What does suspending a port do?  Is it the same
as a normal USB port suspend?

If it is the same, why doesn't the USB_PORT_FEAT_SUSPEND subcase of the
SetPortFeature case in ohci_hub_control() already take care of this?

Yes, you are right. 

We can use  the USB_PORT_FEAT_SUSPEND subcase of the
SetPortFeature case to take care this.

I will send a new patch, please help review it. Thanks a lot.

> This suspend operation must be done before stopping the USB clock,
> resume after the USB clock enabled.
>
> Signed-off-by: Wenyou Yang 
> ---

> @@ -132,6 +135,17 @@ static void at91_stop_hc(struct platform_device *pdev)
>
>  /*-*/
>
> +struct regmap *at91_dt_syscon_sfr(void)
> +{
> + struct regmap *regmap;
> +
> + regmap = syscon_regmap_lookup_by_compatible("atmel,sama5d2-sfr");
> + if (IS_ERR(regmap))
> + return NULL;

If you get an error, the regmap pointer is set to NULL...

> @@ -197,6 +211,8 @@ static int usb_hcd_at91_probe(const struct hc_driver 
> *driver,
>   goto err;
>   }
>
> + ohci_at91->sfr_regmap = at91_dt_syscon_sfr();

With no other error checking...

> +
>   board = hcd->self.controller->platform_data;
>   ohci = hcd_to_ohci(hcd);
>   ohci->num_ports = board->ports;

> +static int ohci_at91_port_ctrl(struct regmap *regmap, bool enable)
> +{
> + u32 regval;
> + int ret;
> +
> + if (IS_ERR(regmap))
> + return PTR_ERR(regmap);
> +
> + ret = regmap_read(regmap, SFR_OHCIICR, );

And now what happens if regmap is NULL?  Hint: It won't be pretty...

Alan Stern


Best Regards,
Wenyou Yang

RE: [PATCH] usb: ohci-at91: Suspend the ports while USB suspending

[Yang, Wenyou]

Hi Alan,

From: Alan Stern [st...@rowland.harvard.edu]
Sent: Friday, May 13, 2016 2:11
To: Yang, Wenyou
Cc: Greg Kroah-Hartman; Ferre, Nicolas; linux-...@vger.kernel.org; 
linux-kernel@vger.kernel.org; linux-arm-ker...@lists.infradead.org
Subject: Re: [PATCH] usb: ohci-at91: Suspend the ports while USB suspending

On Thu, 12 May 2016, Wenyou Yang wrote:

> In order to get lower consumption, as a workaround, suspend
> the USB PORTA/B/C via set the SUSPEND_A/B/C bits of OHCI Interrupt
> Configuration Register while OHCI USB suspending.

What does this mean?  What does suspending a port do?  Is it the same
as a normal USB port suspend?

If it is the same, why doesn't the USB_PORT_FEAT_SUSPEND subcase of the
SetPortFeature case in ohci_hub_control() already take care of this?

Yes, you are right. 

We can use  the USB_PORT_FEAT_SUSPEND subcase of the
SetPortFeature case to take care this.

I will send a new patch, please help review it. Thanks a lot.

> This suspend operation must be done before stopping the USB clock,
> resume after the USB clock enabled.
>
> Signed-off-by: Wenyou Yang 
> ---

> @@ -132,6 +135,17 @@ static void at91_stop_hc(struct platform_device *pdev)
>
>  /*-*/
>
> +struct regmap *at91_dt_syscon_sfr(void)
> +{
> + struct regmap *regmap;
> +
> + regmap = syscon_regmap_lookup_by_compatible("atmel,sama5d2-sfr");
> + if (IS_ERR(regmap))
> + return NULL;

If you get an error, the regmap pointer is set to NULL...

> @@ -197,6 +211,8 @@ static int usb_hcd_at91_probe(const struct hc_driver 
> *driver,
>   goto err;
>   }
>
> + ohci_at91->sfr_regmap = at91_dt_syscon_sfr();

With no other error checking...

> +
>   board = hcd->self.controller->platform_data;
>   ohci = hcd_to_ohci(hcd);
>   ohci->num_ports = board->ports;

> +static int ohci_at91_port_ctrl(struct regmap *regmap, bool enable)
> +{
> + u32 regval;
> + int ret;
> +
> + if (IS_ERR(regmap))
> + return PTR_ERR(regmap);
> +
> + ret = regmap_read(regmap, SFR_OHCIICR, );

And now what happens if regmap is NULL?  Hint: It won't be pretty...

Alan Stern


Best Regards,
Wenyou Yang

Re: [RFC PATCH v2 1/4] Documentation: DT: net: Add Xilinx gmiitorgmii converter device tree binding documentation

[Florian Fainelli]

On 27/07/2016 01:05, Andrew Lunn wrote:
> Hi Appana
> 
> Here is roughly what i was thinking:
> 
> struct priv {
>phy_device *master;
>phy_device *slave;
>struct phy_driver *slave_drv;
> };
> 
> phy_status_clone(phy_device *master, phy_device *slave)
> {
>   master->speed = slave->speed;
>   master->duplex = slave->duplex;
>   master->pause = slave->pause;
> }
> 
> read_status(struct phy_device *phydev)
> {
>   struct priv *priv = phydev->priv;
> 
>   /* Get the status from the slave, and duplicate in into the
>* master */
>slave_drv->read_status(priv->slave);
>phy_status_clone(priv->master, priv->slave);
> 
>/* Update the gmiitorgmii with the current link parameters */
>update_link(master);
> }
> 
> config_init(struct phy_device *phydev)
> {
>   struct priv *priv = phydev->priv;
> 
>   /* Configure the slave, and duplicate in into the master */
>   slave_drv->config_init(priv->slave);
>   phy_status_clone(priv->master, priv->slave);
> }
> 
> struct phy_driver master_drv = {
>.read_status = read_status,
>.config_init = config_init,
>.soft_reset  = ...
>.suspend = ...
> };
> 
> probe(mdio_device *mdio)
> {
>   struct priv *priv = devm_alloc();
> 
>   /* Use the phy-handle property to find the slave phy */
>   node_phy = of_parse_phandle(mdio->of_node, "phy", 0);
>   priv->slave = of_phy_find_device(node_phy);
> 
>   /* Create the master phy on the control address. Use the phy
>  ID from the slave. */
>   priv->master = phy_device_create(mdio->bus, mdio->addr,
>phy->slave->phy_id,
>phy->slave->is_c45,
>phy->slave->c45_ids);
> 
>   slave_dev_drv = phydev->mdio.dev.driver;
>   priv->slave_drv = to_phy_driver(slave_dev_drv);
>   priv->master->mdio.dev.driver = master_drv;

The key here is really that except for the phy_driver::read_status
callback, we want to defer every operation to the slave (full MDIO
register range compatible) PHY.

> }
> 
> It would however be nice to only have one phydev structure, so you are
> not copying status and settings backwards and forwards from one to the
> other all the time, and need a wrapper for every function in
> phy_driver. Studying the structures a bit, that might be possible. You
> would then only need to wrap the read_status(), so that when the link
> speed/duplex changes, you can configure the converter as appropriate.

Agreed.
--
Florian

Re: [RFC PATCH v2 1/4] Documentation: DT: net: Add Xilinx gmiitorgmii converter device tree binding documentation

[Florian Fainelli]

On 27/07/2016 01:05, Andrew Lunn wrote:
> Hi Appana
> 
> Here is roughly what i was thinking:
> 
> struct priv {
>phy_device *master;
>phy_device *slave;
>struct phy_driver *slave_drv;
> };
> 
> phy_status_clone(phy_device *master, phy_device *slave)
> {
>   master->speed = slave->speed;
>   master->duplex = slave->duplex;
>   master->pause = slave->pause;
> }
> 
> read_status(struct phy_device *phydev)
> {
>   struct priv *priv = phydev->priv;
> 
>   /* Get the status from the slave, and duplicate in into the
>* master */
>slave_drv->read_status(priv->slave);
>phy_status_clone(priv->master, priv->slave);
> 
>/* Update the gmiitorgmii with the current link parameters */
>update_link(master);
> }
> 
> config_init(struct phy_device *phydev)
> {
>   struct priv *priv = phydev->priv;
> 
>   /* Configure the slave, and duplicate in into the master */
>   slave_drv->config_init(priv->slave);
>   phy_status_clone(priv->master, priv->slave);
> }
> 
> struct phy_driver master_drv = {
>.read_status = read_status,
>.config_init = config_init,
>.soft_reset  = ...
>.suspend = ...
> };
> 
> probe(mdio_device *mdio)
> {
>   struct priv *priv = devm_alloc();
> 
>   /* Use the phy-handle property to find the slave phy */
>   node_phy = of_parse_phandle(mdio->of_node, "phy", 0);
>   priv->slave = of_phy_find_device(node_phy);
> 
>   /* Create the master phy on the control address. Use the phy
>  ID from the slave. */
>   priv->master = phy_device_create(mdio->bus, mdio->addr,
>phy->slave->phy_id,
>phy->slave->is_c45,
>phy->slave->c45_ids);
> 
>   slave_dev_drv = phydev->mdio.dev.driver;
>   priv->slave_drv = to_phy_driver(slave_dev_drv);
>   priv->master->mdio.dev.driver = master_drv;

The key here is really that except for the phy_driver::read_status
callback, we want to defer every operation to the slave (full MDIO
register range compatible) PHY.

> }
> 
> It would however be nice to only have one phydev structure, so you are
> not copying status and settings backwards and forwards from one to the
> other all the time, and need a wrapper for every function in
> phy_driver. Studying the structures a bit, that might be possible. You
> would then only need to wrap the read_status(), so that when the link
> speed/duplex changes, you can configure the converter as appropriate.

Agreed.
--
Florian

Re: [kernel-hardening] Re: [PATCH 1/2] security, perf: allow further restriction of perf_event_open

[Eric W. Biederman]

Peter Zijlstra  writes:

> On Wed, Aug 03, 2016 at 11:53:41AM -0700, Kees Cook wrote:
>> > Kees Cook  writes:
>> >
>> >> On Tue, Aug 2, 2016 at 1:30 PM, Peter Zijlstra  
>> >> wrote:
>> >> Let me take this another way instead. What would be a better way to
>> >> provide a mechanism for system owners to disable perf without an LSM?
>> >> (Since far fewer folks run with an enforcing "big" LSM: I'm seeking as
>> >> wide a coverage as possible.)
>> >
>> > I vote for sandboxes.  Perhaps seccomp.  Perhaps a per userns sysctl.
>> > Perhaps something else.
>> 
>> Peter, did you happen to see Eric's solution to this problem for
>> namespaces? Basically, a per-userns sysctl instead of a global sysctl.
>> Is that something that would be acceptable here?
>
> Someone would have to educate me on what a userns is and how that would
> help here.

userns is an abbreviation for user namespace.

How it might help is that it is an easy unescapable context for
processes.  Essentialy the idea is to limit the scope of the sysctl to a
container.

User namespaces run into flack because while tremendously simple in
themselves the code takes advantage of the fact that suid root
executables in a user namespace do not have privileges on anything
outside of the user namespace.  Which means that it is semantically safe
to allow operations like creating mount namespaces, mount filesystems,
creating network namespaces, manipulating the network stack etc.  All of
which allows unprivileged users (that can create network namespaces) to
exercise more kernel code and exercise those bugs.

Fundamentally user namespaces as objects you can create need limits on
the maximum number of user namespaces you can create to cawtch run away
processes.  Set the limit you can create to 0 and you get what Kees
wants.

In my pending patches that were not quite ready for the merge window, I
added a sysctl that described the maximum number of user namepaces that
could be created (default value threads-max), and implemented the sysctl
in a per user way.  Such that counts and limits were kept for every user
namespace.  In a nested user namespace (which are all of them except for
the initial user namspace) the count and limit would be checked in the
current user namepsace, then the count would be incremented in the parent
and verified the count was below the limit in the parent user namespace.

What this means in practice is user namespaces can be enabled by default
on a system, and yet you can easily disable them in a sandbox that was
built with a user namespace.

I named the new sysctls in my patch:
/proc/sys/userns/max_user_namespaces
/proc/sys/userns/max_pid_namespaces
/proc/sys/userns/max_net_namespaces
/proc/sys/userns/max_uts_namespaces
/proc/sys/userns/max_ipc_namespaces
/proc/sys/userns/max_cgroup_namespaces
/proc/sys/userns/max_mnt_namespaces

What Kees was suggesting was to add a similar sysctl say:
/proc/sys/userns/perf_event_enabled

And have the ability to disable perf events in each user namespaces.
While still being able to leave usage perf events enabled by default.

I don't know if any of that is a good fit for perf events.

For purposes of this discussion I assume we are limiting ourselves to
discussing userspace tracing, which semantically is 100% fine for
access by userspace.

Eric

Re: [kernel-hardening] Re: [PATCH 1/2] security, perf: allow further restriction of perf_event_open

[Eric W. Biederman]

Peter Zijlstra  writes:

> On Wed, Aug 03, 2016 at 11:53:41AM -0700, Kees Cook wrote:
>> > Kees Cook  writes:
>> >
>> >> On Tue, Aug 2, 2016 at 1:30 PM, Peter Zijlstra  
>> >> wrote:
>> >> Let me take this another way instead. What would be a better way to
>> >> provide a mechanism for system owners to disable perf without an LSM?
>> >> (Since far fewer folks run with an enforcing "big" LSM: I'm seeking as
>> >> wide a coverage as possible.)
>> >
>> > I vote for sandboxes.  Perhaps seccomp.  Perhaps a per userns sysctl.
>> > Perhaps something else.
>> 
>> Peter, did you happen to see Eric's solution to this problem for
>> namespaces? Basically, a per-userns sysctl instead of a global sysctl.
>> Is that something that would be acceptable here?
>
> Someone would have to educate me on what a userns is and how that would
> help here.

userns is an abbreviation for user namespace.

How it might help is that it is an easy unescapable context for
processes.  Essentialy the idea is to limit the scope of the sysctl to a
container.

User namespaces run into flack because while tremendously simple in
themselves the code takes advantage of the fact that suid root
executables in a user namespace do not have privileges on anything
outside of the user namespace.  Which means that it is semantically safe
to allow operations like creating mount namespaces, mount filesystems,
creating network namespaces, manipulating the network stack etc.  All of
which allows unprivileged users (that can create network namespaces) to
exercise more kernel code and exercise those bugs.

Fundamentally user namespaces as objects you can create need limits on
the maximum number of user namespaces you can create to cawtch run away
processes.  Set the limit you can create to 0 and you get what Kees
wants.

In my pending patches that were not quite ready for the merge window, I
added a sysctl that described the maximum number of user namepaces that
could be created (default value threads-max), and implemented the sysctl
in a per user way.  Such that counts and limits were kept for every user
namespace.  In a nested user namespace (which are all of them except for
the initial user namspace) the count and limit would be checked in the
current user namepsace, then the count would be incremented in the parent
and verified the count was below the limit in the parent user namespace.

What this means in practice is user namespaces can be enabled by default
on a system, and yet you can easily disable them in a sandbox that was
built with a user namespace.

I named the new sysctls in my patch:
/proc/sys/userns/max_user_namespaces
/proc/sys/userns/max_pid_namespaces
/proc/sys/userns/max_net_namespaces
/proc/sys/userns/max_uts_namespaces
/proc/sys/userns/max_ipc_namespaces
/proc/sys/userns/max_cgroup_namespaces
/proc/sys/userns/max_mnt_namespaces

What Kees was suggesting was to add a similar sysctl say:
/proc/sys/userns/perf_event_enabled

And have the ability to disable perf events in each user namespaces.
While still being able to leave usage perf events enabled by default.

I don't know if any of that is a good fit for perf events.

For purposes of this discussion I assume we are limiting ourselves to
discussing userspace tracing, which semantically is 100% fine for
access by userspace.

Eric

Re: [PATCH v1] net: phy: micrel: Add specific suspend

[Florian Fainelli]

On 03/08/2016 17:21, Wenyou Yang wrote:
> Disable all interrupts when suspend, they will be enabled
> when resume. Otherwise, the suspend/resume process will be
> blocked occasionally.

This seems like something fairly generic actually, we could imagine
having the core library do something like this:

- if interrupts are valid and enabled for the PHY, call
phydrv->config_intr() with PHY_INTERRUPT_DISABLED
- call genphy_suspend

Of course if none of this fits the generic model, the PHY driver can
still provide a suspend callback. Might be worth auditing other drivers
for that pattern and look at those that need specific handling like
keeping specific interrupt sources active for e.g: wake-on-LAN.

> 
> Signed-off-by: Wenyou Yang 
> Acked-by: Nicolas Ferre 
> ---
> 
>  drivers/net/phy/micrel.c | 19 ++-
>  1 file changed, 18 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/net/phy/micrel.c b/drivers/net/phy/micrel.c
> index 5a8fefc..8cb778a 100644
> --- a/drivers/net/phy/micrel.c
> +++ b/drivers/net/phy/micrel.c
> @@ -647,6 +647,23 @@ static void kszphy_get_stats(struct phy_device *phydev,
>   data[i] = kszphy_get_stat(phydev, i);
>  }
>  
> +int kszphy_suspend(struct phy_device *phydev)
> +{
> + int value;
> +
> + mutex_lock(>lock);
> +
> + /* disable interrupts */
> + phy_write(phydev, MII_KSZPHY_INTCS, 0x0);
> +
> + value = phy_read(phydev, MII_BMCR);
> + phy_write(phydev, MII_BMCR, value | BMCR_PDOWN);
> +
> + mutex_unlock(>lock);
> +
> + return 0;
> +}
> +
>  static int kszphy_resume(struct phy_device *phydev)
>  {
>   int value;
> @@ -870,7 +887,7 @@ static struct phy_driver ksphy_driver[] = {
>   .get_sset_count = kszphy_get_sset_count,
>   .get_strings= kszphy_get_strings,
>   .get_stats  = kszphy_get_stats,
> - .suspend= genphy_suspend,
> + .suspend= kszphy_suspend,
>   .resume = kszphy_resume,
>  }, {
>   .phy_id = PHY_ID_KSZ8061,
> 

Re: [PATCH v1] net: phy: micrel: Add specific suspend

[Florian Fainelli]

On 03/08/2016 17:21, Wenyou Yang wrote:
> Disable all interrupts when suspend, they will be enabled
> when resume. Otherwise, the suspend/resume process will be
> blocked occasionally.

This seems like something fairly generic actually, we could imagine
having the core library do something like this:

- if interrupts are valid and enabled for the PHY, call
phydrv->config_intr() with PHY_INTERRUPT_DISABLED
- call genphy_suspend

Of course if none of this fits the generic model, the PHY driver can
still provide a suspend callback. Might be worth auditing other drivers
for that pattern and look at those that need specific handling like
keeping specific interrupt sources active for e.g: wake-on-LAN.

> 
> Signed-off-by: Wenyou Yang 
> Acked-by: Nicolas Ferre 
> ---
> 
>  drivers/net/phy/micrel.c | 19 ++-
>  1 file changed, 18 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/net/phy/micrel.c b/drivers/net/phy/micrel.c
> index 5a8fefc..8cb778a 100644
> --- a/drivers/net/phy/micrel.c
> +++ b/drivers/net/phy/micrel.c
> @@ -647,6 +647,23 @@ static void kszphy_get_stats(struct phy_device *phydev,
>   data[i] = kszphy_get_stat(phydev, i);
>  }
>  
> +int kszphy_suspend(struct phy_device *phydev)
> +{
> + int value;
> +
> + mutex_lock(>lock);
> +
> + /* disable interrupts */
> + phy_write(phydev, MII_KSZPHY_INTCS, 0x0);
> +
> + value = phy_read(phydev, MII_BMCR);
> + phy_write(phydev, MII_BMCR, value | BMCR_PDOWN);
> +
> + mutex_unlock(>lock);
> +
> + return 0;
> +}
> +
>  static int kszphy_resume(struct phy_device *phydev)
>  {
>   int value;
> @@ -870,7 +887,7 @@ static struct phy_driver ksphy_driver[] = {
>   .get_sset_count = kszphy_get_sset_count,
>   .get_strings= kszphy_get_strings,
>   .get_stats  = kszphy_get_stats,
> - .suspend= genphy_suspend,
> + .suspend= kszphy_suspend,
>   .resume = kszphy_resume,
>  }, {
>   .phy_id = PHY_ID_KSZ8061,
> 

Re: [PATCH v2 1/3] mm: memcontrol: fix swap counter leak on swapout from offline cgroup

[Vladimir Davydov]

On Wed, Aug 03, 2016 at 01:09:42PM +0200, Michal Hocko wrote:
> On Wed 03-08-16 12:50:49, Vladimir Davydov wrote:
> > On Tue, Aug 02, 2016 at 06:00:26PM +0200, Michal Hocko wrote:
> > > On Tue 02-08-16 18:00:48, Vladimir Davydov wrote:
> > ...
> > > > diff --git a/mm/memcontrol.c b/mm/memcontrol.c
> > > > index 3be791afd372..4ae12effe347 100644
> > > > --- a/mm/memcontrol.c
> > > > +++ b/mm/memcontrol.c
> > > > @@ -4036,6 +4036,24 @@ static void mem_cgroup_id_get(struct mem_cgroup 
> > > > *memcg)
> > > > atomic_inc(>id.ref);
> > > >  }
> > > >  
> > > > +static struct mem_cgroup *mem_cgroup_id_get_active(struct mem_cgroup 
> > > > *memcg)
> > > > +{
> > > > +   while (!atomic_inc_not_zero(>id.ref)) {
> > > > +   /*
> > > > +* The root cgroup cannot be destroyed, so it's 
> > > > refcount must
> > > > +* always be >= 1.
> > > > +*/
> > > > +   if (memcg == root_mem_cgroup) {
> > > > +   VM_BUG_ON(1);
> > > > +   break;
> > > > +   }
> > > 
> > > why not simply VM_BUG_ON(memcg == root_mem_cgroup)?
> > 
> > Because with DEBUG_VM disabled we could wind up looping forever here if
> > the refcount of the root_mem_cgroup got screwed up. On production
> > kernels, it's better to break the loop and carry on closing eyes on
> > diverging counters rather than getting a lockup.
> 
> Wouldn't this just paper over a real bug? Anyway I will not insist but
> making the code more complex just to pretend we can handle a situation
> gracefully doesn't sound right to me.

But we can handle this IMO. AFAICS diverging id refcount will typically
result in leaking swap charges, which aren't even a real resource. At
worst, we can leak an offline mem_cgroup, which is also not critical
enough to crash the production system.

I see your concern of papering over a bug though. What about adding a
warning there?

diff --git a/mm/memcontrol.c b/mm/memcontrol.c
index 1c0aa59fd333..8c8e68becee9 100644
--- a/mm/memcontrol.c
+++ b/mm/memcontrol.c
@@ -4044,7 +4044,7 @@ static struct mem_cgroup *mem_cgroup_id_get_online(struct 
mem_cgroup *memcg)
 * The root cgroup cannot be destroyed, so it's refcount must
 * always be >= 1.
 */
-   if (memcg == root_mem_cgroup) {
+   if (WARN_ON_ONCE(memcg == root_mem_cgroup)) {
VM_BUG_ON(1);
break;
}

[PATCH] iio: humidity: hdc100x: use i2c_master_recv to read sensor data

[Alison Schofield]

Replace the i2c_smbus_read_byte commmands used to retrieve the sensor
data with an i2c_master_recv command.

The smbus read byte method fails because the device does not expect a
stop condition after sending the first byte. When we issue the second
read, we are getting the first byte again. Net effect is that of the 14
bits used for the measurement, the 8 most significant bits are correct,
the lower 6 are not.

None of the smbus read protocols follow the pattern this device requires
(S Addr Rd [A] Data [A] Data NA P), hence the switch to an i2c receive
transaction.

Signed-off-by: Alison Schofield 
Cc: Daniel Baluta 
---
 drivers/iio/humidity/hdc100x.c | 27 +++
 1 file changed, 7 insertions(+), 20 deletions(-)

diff --git a/drivers/iio/humidity/hdc100x.c b/drivers/iio/humidity/hdc100x.c
index a03832a..643a42d 100644
--- a/drivers/iio/humidity/hdc100x.c
+++ b/drivers/iio/humidity/hdc100x.c
@@ -142,7 +142,7 @@ static int hdc100x_get_measurement(struct hdc100x_data 
*data,
struct i2c_client *client = data->client;
int delay = data->adc_int_us[chan->address];
int ret;
-   int val;
+   u8 buf[2];
 
/* start measurement */
ret = i2c_smbus_write_byte(client, chan->address);
@@ -154,26 +154,13 @@ static int hdc100x_get_measurement(struct hdc100x_data 
*data,
/* wait for integration time to pass */
usleep_range(delay, delay + 1000);
 
-   /*
-* i2c_smbus_read_word_data cannot() be used here due to the command
-* value not being understood and causes NAKs preventing any reading
-* from being accessed.
-*/
-   ret = i2c_smbus_read_byte(client);
+   /* read the 2 byte measurement */
+   ret = i2c_master_recv(data->client, buf, 2);
if (ret < 0) {
-   dev_err(>dev, "cannot read high byte measurement");
+   dev_err(>dev, "cannot read sensor data\n");
return ret;
}
-   val = ret << 8;
-
-   ret = i2c_smbus_read_byte(client);
-   if (ret < 0) {
-   dev_err(>dev, "cannot read low byte measurement");
-   return ret;
-   }
-   val |= ret;
-
-   return val;
+   return (int)(buf[0] << 8 | buf[1]);
 }
 
 static int hdc100x_get_heater_status(struct hdc100x_data *data)
@@ -272,8 +259,8 @@ static int hdc100x_probe(struct i2c_client *client,
struct iio_dev *indio_dev;
struct hdc100x_data *data;
 
-   if (!i2c_check_functionality(client->adapter,
-   I2C_FUNC_SMBUS_WORD_DATA | I2C_FUNC_SMBUS_BYTE))
+   if (!i2c_check_functionality(client->adapter, I2C_FUNC_SMBUS_WORD_DATA |
+I2C_FUNC_SMBUS_BYTE | I2C_FUNC_I2C))
return -EOPNOTSUPP;
 
indio_dev = devm_iio_device_alloc(>dev, sizeof(*data));
-- 
2.1.4

Re: [PATCH v2 1/3] mm: memcontrol: fix swap counter leak on swapout from offline cgroup

[Vladimir Davydov]

On Wed, Aug 03, 2016 at 01:09:42PM +0200, Michal Hocko wrote:
> On Wed 03-08-16 12:50:49, Vladimir Davydov wrote:
> > On Tue, Aug 02, 2016 at 06:00:26PM +0200, Michal Hocko wrote:
> > > On Tue 02-08-16 18:00:48, Vladimir Davydov wrote:
> > ...
> > > > diff --git a/mm/memcontrol.c b/mm/memcontrol.c
> > > > index 3be791afd372..4ae12effe347 100644
> > > > --- a/mm/memcontrol.c
> > > > +++ b/mm/memcontrol.c
> > > > @@ -4036,6 +4036,24 @@ static void mem_cgroup_id_get(struct mem_cgroup 
> > > > *memcg)
> > > > atomic_inc(>id.ref);
> > > >  }
> > > >  
> > > > +static struct mem_cgroup *mem_cgroup_id_get_active(struct mem_cgroup 
> > > > *memcg)
> > > > +{
> > > > +   while (!atomic_inc_not_zero(>id.ref)) {
> > > > +   /*
> > > > +* The root cgroup cannot be destroyed, so it's 
> > > > refcount must
> > > > +* always be >= 1.
> > > > +*/
> > > > +   if (memcg == root_mem_cgroup) {
> > > > +   VM_BUG_ON(1);
> > > > +   break;
> > > > +   }
> > > 
> > > why not simply VM_BUG_ON(memcg == root_mem_cgroup)?
> > 
> > Because with DEBUG_VM disabled we could wind up looping forever here if
> > the refcount of the root_mem_cgroup got screwed up. On production
> > kernels, it's better to break the loop and carry on closing eyes on
> > diverging counters rather than getting a lockup.
> 
> Wouldn't this just paper over a real bug? Anyway I will not insist but
> making the code more complex just to pretend we can handle a situation
> gracefully doesn't sound right to me.

But we can handle this IMO. AFAICS diverging id refcount will typically
result in leaking swap charges, which aren't even a real resource. At
worst, we can leak an offline mem_cgroup, which is also not critical
enough to crash the production system.

I see your concern of papering over a bug though. What about adding a
warning there?

diff --git a/mm/memcontrol.c b/mm/memcontrol.c
index 1c0aa59fd333..8c8e68becee9 100644
--- a/mm/memcontrol.c
+++ b/mm/memcontrol.c
@@ -4044,7 +4044,7 @@ static struct mem_cgroup *mem_cgroup_id_get_online(struct 
mem_cgroup *memcg)
 * The root cgroup cannot be destroyed, so it's refcount must
 * always be >= 1.
 */
-   if (memcg == root_mem_cgroup) {
+   if (WARN_ON_ONCE(memcg == root_mem_cgroup)) {
VM_BUG_ON(1);
break;
}

[PATCH] iio: humidity: hdc100x: use i2c_master_recv to read sensor data

[Alison Schofield]

Replace the i2c_smbus_read_byte commmands used to retrieve the sensor
data with an i2c_master_recv command.

The smbus read byte method fails because the device does not expect a
stop condition after sending the first byte. When we issue the second
read, we are getting the first byte again. Net effect is that of the 14
bits used for the measurement, the 8 most significant bits are correct,
the lower 6 are not.

None of the smbus read protocols follow the pattern this device requires
(S Addr Rd [A] Data [A] Data NA P), hence the switch to an i2c receive
transaction.

Signed-off-by: Alison Schofield 
Cc: Daniel Baluta 
---
 drivers/iio/humidity/hdc100x.c | 27 +++
 1 file changed, 7 insertions(+), 20 deletions(-)

diff --git a/drivers/iio/humidity/hdc100x.c b/drivers/iio/humidity/hdc100x.c
index a03832a..643a42d 100644
--- a/drivers/iio/humidity/hdc100x.c
+++ b/drivers/iio/humidity/hdc100x.c
@@ -142,7 +142,7 @@ static int hdc100x_get_measurement(struct hdc100x_data 
*data,
struct i2c_client *client = data->client;
int delay = data->adc_int_us[chan->address];
int ret;
-   int val;
+   u8 buf[2];
 
/* start measurement */
ret = i2c_smbus_write_byte(client, chan->address);
@@ -154,26 +154,13 @@ static int hdc100x_get_measurement(struct hdc100x_data 
*data,
/* wait for integration time to pass */
usleep_range(delay, delay + 1000);
 
-   /*
-* i2c_smbus_read_word_data cannot() be used here due to the command
-* value not being understood and causes NAKs preventing any reading
-* from being accessed.
-*/
-   ret = i2c_smbus_read_byte(client);
+   /* read the 2 byte measurement */
+   ret = i2c_master_recv(data->client, buf, 2);
if (ret < 0) {
-   dev_err(>dev, "cannot read high byte measurement");
+   dev_err(>dev, "cannot read sensor data\n");
return ret;
}
-   val = ret << 8;
-
-   ret = i2c_smbus_read_byte(client);
-   if (ret < 0) {
-   dev_err(>dev, "cannot read low byte measurement");
-   return ret;
-   }
-   val |= ret;
-
-   return val;
+   return (int)(buf[0] << 8 | buf[1]);
 }
 
 static int hdc100x_get_heater_status(struct hdc100x_data *data)
@@ -272,8 +259,8 @@ static int hdc100x_probe(struct i2c_client *client,
struct iio_dev *indio_dev;
struct hdc100x_data *data;
 
-   if (!i2c_check_functionality(client->adapter,
-   I2C_FUNC_SMBUS_WORD_DATA | I2C_FUNC_SMBUS_BYTE))
+   if (!i2c_check_functionality(client->adapter, I2C_FUNC_SMBUS_WORD_DATA |
+I2C_FUNC_SMBUS_BYTE | I2C_FUNC_I2C))
return -EOPNOTSUPP;
 
indio_dev = devm_iio_device_alloc(>dev, sizeof(*data));
-- 
2.1.4

Re: [PATCH] powerpc: move hmi.c to arch/powerpc/kvm/

[Daniel Axtens]

Paolo Bonzini  writes:

> hmi.c functions are unused unless sibling_subcore_state is nonzero, and
> that in turn happens only if KVM is in use.  So move the code to
> arch/powerpc/kvm/, putting it under CONFIG_KVM_BOOK3S_64_HANDLER
> rather than CONFIG_PPC_BOOK3S_64.  The sibling_subcore_state is also
> included in struct paca_struct only if KVM is supported by the kernel.

Ok. Initially I was concerned because there are a bunch of non-KVM
related HMI causes (e.g. the CAPP will raise an HMI if it loses the link
to the CAPI card.)
https://github.com/open-power/skiboot/blob/master/core/hmi.c lists lots
of HMIs created by hardware events.

Having said that, you're right that this particular file is KVM
specific.

Reviewed-by: Daniel Axtens 

Mahesh: is there a way to cause the TB to desynchronise and then test if
this resynchronisation works?

Regards,
Daniel

>
> Cc: Paul Mackerras 
> Cc: Michael Ellerman 
> Cc: Mahesh Salgaonkar 
> Cc: linuxppc-...@lists.ozlabs.org
> Cc: kvm-...@vger.kernel.org
> Cc: k...@vger.kernel.org
> Signed-off-by: Paolo Bonzini 
> ---
>   It would be nice to have this in 4.8, to minimize any 4.9 conflicts.
>   Build-tested only, with and without KVM enabled.
>
>  arch/powerpc/include/asm/hmi.h |  2 +-
>  arch/powerpc/include/asm/paca.h| 10 +-
>  arch/powerpc/kernel/Makefile   |  2 +-
>  arch/powerpc/kvm/Makefile  |  1 +
>  arch/powerpc/{kernel/hmi.c => kvm/book3s_hv_hmi.c} |  0
>  5 files changed, 8 insertions(+), 7 deletions(-)
>  rename arch/powerpc/{kernel/hmi.c => kvm/book3s_hv_hmi.c} (100%)
>
> diff --git a/arch/powerpc/include/asm/hmi.h b/arch/powerpc/include/asm/hmi.h
> index 88b4901ac4ee..d3b6ad6e137c 100644
> --- a/arch/powerpc/include/asm/hmi.h
> +++ b/arch/powerpc/include/asm/hmi.h
> @@ -21,7 +21,7 @@
>  #ifndef __ASM_PPC64_HMI_H__
>  #define __ASM_PPC64_HMI_H__
>  
> -#ifdef CONFIG_PPC_BOOK3S_64
> +#ifdef CONFIG_KVM_BOOK3S_64_HANDLER
>  
>  #define  CORE_TB_RESYNC_REQ_BIT  63
>  #define MAX_SUBCORE_PER_CORE 4
> diff --git a/arch/powerpc/include/asm/paca.h b/arch/powerpc/include/asm/paca.h
> index 148303e7771f..625321e7e581 100644
> --- a/arch/powerpc/include/asm/paca.h
> +++ b/arch/powerpc/include/asm/paca.h
> @@ -183,11 +183,6 @@ struct paca_struct {
>*/
>   u16 in_mce;
>   u8 hmi_event_available;  /* HMI event is available */
> - /*
> -  * Bitmap for sibling subcore status. See kvm/book3s_hv_ras.c for
> -  * more details
> -  */
> - struct sibling_subcore_state *sibling_subcore_state;
>  #endif
>  
>   /* Stuff for accurate time accounting */
> @@ -202,6 +197,11 @@ struct paca_struct {
>   struct kvmppc_book3s_shadow_vcpu shadow_vcpu;
>  #endif
>   struct kvmppc_host_state kvm_hstate;
> + /*
> +  * Bitmap for sibling subcore status. See kvm/book3s_hv_ras.c for
> +  * more details
> +  */
> + struct sibling_subcore_state *sibling_subcore_state;
>  #endif
>  };
>  
> diff --git a/arch/powerpc/kernel/Makefile b/arch/powerpc/kernel/Makefile
> index b2027a5cf508..fe4c075bcf50 100644
> --- a/arch/powerpc/kernel/Makefile
> +++ b/arch/powerpc/kernel/Makefile
> @@ -41,7 +41,7 @@ obj-$(CONFIG_VDSO32)+= vdso32/
>  obj-$(CONFIG_HAVE_HW_BREAKPOINT) += hw_breakpoint.o
>  obj-$(CONFIG_PPC_BOOK3S_64)  += cpu_setup_ppc970.o cpu_setup_pa6t.o
>  obj-$(CONFIG_PPC_BOOK3S_64)  += cpu_setup_power.o
> -obj-$(CONFIG_PPC_BOOK3S_64)  += mce.o mce_power.o hmi.o
> +obj-$(CONFIG_PPC_BOOK3S_64)  += mce.o mce_power.o
>  obj-$(CONFIG_PPC_BOOK3E_64)  += exceptions-64e.o idle_book3e.o
>  obj-$(CONFIG_PPC64)  += vdso64/
>  obj-$(CONFIG_ALTIVEC)+= vecemu.o
> diff --git a/arch/powerpc/kvm/Makefile b/arch/powerpc/kvm/Makefile
> index 1f9e5529e692..855d4b95d752 100644
> --- a/arch/powerpc/kvm/Makefile
> +++ b/arch/powerpc/kvm/Makefile
> @@ -78,6 +78,7 @@ kvm-book3s_64-builtin-xics-objs-$(CONFIG_KVM_XICS) := \
>  
>  ifdef CONFIG_KVM_BOOK3S_HV_POSSIBLE
>  kvm-book3s_64-builtin-objs-$(CONFIG_KVM_BOOK3S_64_HANDLER) += \
> + book3s_hv_hmi.o \
>   book3s_hv_rmhandlers.o \
>   book3s_hv_rm_mmu.o \
>   book3s_hv_ras.o \
> diff --git a/arch/powerpc/kernel/hmi.c b/arch/powerpc/kvm/book3s_hv_hmi.c
> similarity index 100%
> rename from arch/powerpc/kernel/hmi.c
> rename to arch/powerpc/kvm/book3s_hv_hmi.c
> -- 
> 1.8.3.1
>
> ___
> Linuxppc-dev mailing list
> linuxppc-...@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev


signature.asc
Description: PGP signature

Re: [PATCH] powerpc: move hmi.c to arch/powerpc/kvm/

[Daniel Axtens]

Paolo Bonzini  writes:

> hmi.c functions are unused unless sibling_subcore_state is nonzero, and
> that in turn happens only if KVM is in use.  So move the code to
> arch/powerpc/kvm/, putting it under CONFIG_KVM_BOOK3S_64_HANDLER
> rather than CONFIG_PPC_BOOK3S_64.  The sibling_subcore_state is also
> included in struct paca_struct only if KVM is supported by the kernel.

Ok. Initially I was concerned because there are a bunch of non-KVM
related HMI causes (e.g. the CAPP will raise an HMI if it loses the link
to the CAPI card.)
https://github.com/open-power/skiboot/blob/master/core/hmi.c lists lots
of HMIs created by hardware events.

Having said that, you're right that this particular file is KVM
specific.

Reviewed-by: Daniel Axtens 

Mahesh: is there a way to cause the TB to desynchronise and then test if
this resynchronisation works?

Regards,
Daniel

>
> Cc: Paul Mackerras 
> Cc: Michael Ellerman 
> Cc: Mahesh Salgaonkar 
> Cc: linuxppc-...@lists.ozlabs.org
> Cc: kvm-...@vger.kernel.org
> Cc: k...@vger.kernel.org
> Signed-off-by: Paolo Bonzini 
> ---
>   It would be nice to have this in 4.8, to minimize any 4.9 conflicts.
>   Build-tested only, with and without KVM enabled.
>
>  arch/powerpc/include/asm/hmi.h |  2 +-
>  arch/powerpc/include/asm/paca.h| 10 +-
>  arch/powerpc/kernel/Makefile   |  2 +-
>  arch/powerpc/kvm/Makefile  |  1 +
>  arch/powerpc/{kernel/hmi.c => kvm/book3s_hv_hmi.c} |  0
>  5 files changed, 8 insertions(+), 7 deletions(-)
>  rename arch/powerpc/{kernel/hmi.c => kvm/book3s_hv_hmi.c} (100%)
>
> diff --git a/arch/powerpc/include/asm/hmi.h b/arch/powerpc/include/asm/hmi.h
> index 88b4901ac4ee..d3b6ad6e137c 100644
> --- a/arch/powerpc/include/asm/hmi.h
> +++ b/arch/powerpc/include/asm/hmi.h
> @@ -21,7 +21,7 @@
>  #ifndef __ASM_PPC64_HMI_H__
>  #define __ASM_PPC64_HMI_H__
>  
> -#ifdef CONFIG_PPC_BOOK3S_64
> +#ifdef CONFIG_KVM_BOOK3S_64_HANDLER
>  
>  #define  CORE_TB_RESYNC_REQ_BIT  63
>  #define MAX_SUBCORE_PER_CORE 4
> diff --git a/arch/powerpc/include/asm/paca.h b/arch/powerpc/include/asm/paca.h
> index 148303e7771f..625321e7e581 100644
> --- a/arch/powerpc/include/asm/paca.h
> +++ b/arch/powerpc/include/asm/paca.h
> @@ -183,11 +183,6 @@ struct paca_struct {
>*/
>   u16 in_mce;
>   u8 hmi_event_available;  /* HMI event is available */
> - /*
> -  * Bitmap for sibling subcore status. See kvm/book3s_hv_ras.c for
> -  * more details
> -  */
> - struct sibling_subcore_state *sibling_subcore_state;
>  #endif
>  
>   /* Stuff for accurate time accounting */
> @@ -202,6 +197,11 @@ struct paca_struct {
>   struct kvmppc_book3s_shadow_vcpu shadow_vcpu;
>  #endif
>   struct kvmppc_host_state kvm_hstate;
> + /*
> +  * Bitmap for sibling subcore status. See kvm/book3s_hv_ras.c for
> +  * more details
> +  */
> + struct sibling_subcore_state *sibling_subcore_state;
>  #endif
>  };
>  
> diff --git a/arch/powerpc/kernel/Makefile b/arch/powerpc/kernel/Makefile
> index b2027a5cf508..fe4c075bcf50 100644
> --- a/arch/powerpc/kernel/Makefile
> +++ b/arch/powerpc/kernel/Makefile
> @@ -41,7 +41,7 @@ obj-$(CONFIG_VDSO32)+= vdso32/
>  obj-$(CONFIG_HAVE_HW_BREAKPOINT) += hw_breakpoint.o
>  obj-$(CONFIG_PPC_BOOK3S_64)  += cpu_setup_ppc970.o cpu_setup_pa6t.o
>  obj-$(CONFIG_PPC_BOOK3S_64)  += cpu_setup_power.o
> -obj-$(CONFIG_PPC_BOOK3S_64)  += mce.o mce_power.o hmi.o
> +obj-$(CONFIG_PPC_BOOK3S_64)  += mce.o mce_power.o
>  obj-$(CONFIG_PPC_BOOK3E_64)  += exceptions-64e.o idle_book3e.o
>  obj-$(CONFIG_PPC64)  += vdso64/
>  obj-$(CONFIG_ALTIVEC)+= vecemu.o
> diff --git a/arch/powerpc/kvm/Makefile b/arch/powerpc/kvm/Makefile
> index 1f9e5529e692..855d4b95d752 100644
> --- a/arch/powerpc/kvm/Makefile
> +++ b/arch/powerpc/kvm/Makefile
> @@ -78,6 +78,7 @@ kvm-book3s_64-builtin-xics-objs-$(CONFIG_KVM_XICS) := \
>  
>  ifdef CONFIG_KVM_BOOK3S_HV_POSSIBLE
>  kvm-book3s_64-builtin-objs-$(CONFIG_KVM_BOOK3S_64_HANDLER) += \
> + book3s_hv_hmi.o \
>   book3s_hv_rmhandlers.o \
>   book3s_hv_rm_mmu.o \
>   book3s_hv_ras.o \
> diff --git a/arch/powerpc/kernel/hmi.c b/arch/powerpc/kvm/book3s_hv_hmi.c
> similarity index 100%
> rename from arch/powerpc/kernel/hmi.c
> rename to arch/powerpc/kvm/book3s_hv_hmi.c
> -- 
> 1.8.3.1
>
> ___
> Linuxppc-dev mailing list
> linuxppc-...@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev


signature.asc
Description: PGP signature

Re: [RFC PATCH v2 0/3] perf/tracefs: Container-aware tracing support

[Eric W. Biederman]

Hari Bathini  writes:

> This RFC patch set supports filtering container specific events
> when perf tool is executed inside a container. The patches apply
> cleanly on v4.7.0-rc7
>
> Changes from v1:
> 1/3. Revived earlier approach[1] with cgroup namespace instead
>  of pid namespace
> 2/3. New patch that adds instance support for uprobe events in
>  tracefs filesystem
> 3/3. New patch that adds "newinstance" mount option for tracefs
>  filesystem
   "newinstace" ick no.

I see no justification anywhere why the perf cgroup is not enough for
this.

Eric

Re: [RFC PATCH v2 0/3] perf/tracefs: Container-aware tracing support

[Eric W. Biederman]

Hari Bathini  writes:

> This RFC patch set supports filtering container specific events
> when perf tool is executed inside a container. The patches apply
> cleanly on v4.7.0-rc7
>
> Changes from v1:
> 1/3. Revived earlier approach[1] with cgroup namespace instead
>  of pid namespace
> 2/3. New patch that adds instance support for uprobe events in
>  tracefs filesystem
> 3/3. New patch that adds "newinstance" mount option for tracefs
>  filesystem
   "newinstace" ick no.

I see no justification anywhere why the perf cgroup is not enough for
this.

Eric

Re: [RFC][PATCH 3/4] power: reset: Add sram-reboot-mode driver

[John Stultz]

On Wed, Aug 3, 2016 at 6:03 PM, Bjorn Andersson
 wrote:
> On Wed 03 Aug 16:05 PDT 2016, John Stultz wrote:
>
> [..]
>> diff --git a/drivers/power/reset/sram-reboot-mode.c 
>> b/drivers/power/reset/sram-reboot-mode.c
> [..]
>> +
>> +struct sram_reboot_mode {
>> + struct reboot_mode_driver reboot;
>> + void __iomem *reboot_reason_val_addr;
>
> 23 characters is...a lot of characters...

Fair enough. Renamed to reason_addr.


>> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>> + if (!res)
>> + return PTR_ERR(res);
>> +
>> + sram_rbm->reboot_reason_val_addr = devm_ioremap(>dev, res->start,
>> +  resource_size(res));
>
> Use devm_ioremap_resource() instead, it saves you the return value check
> on platform_get_resource() and is cleaner.

Ok. Done.


>> + if (IS_ERR(sram_rbm->reboot_reason_val_addr))
>> + return PTR_ERR(sram_rbm->reboot_reason_val_addr);
>> +
>> + ret = reboot_mode_register(_rbm->reboot);
>
> I think you should take the time to throw in a
> devm_reboot_mode_register(), it would save you from the
> dev_set_drvdata() and you can drop the remove function.

So I've only got a vague sense of what your suggesting here. Do you
have a pointer to a good example?

thanks
-john

xfstests xfs fuzzers fail with DAX

[Xiong Zhou]

Hi,

A few xfs fuzzers in xfstests fail with dax mount option, pass without dax.
They are xfs/086 xfs/088 xfs/089 xfs/091.

xfstests to commit 4470ad4c7e  (Jul 26)
kernel   to commit dd95069545  (Jul 24)

+ ./check xfs/091
FSTYP -- xfs (non-debug)
PLATFORM  -- Linux/x86_64 rhel73 4.7.0+
MKFS_OPTIONS  -- -f -bsize=4096 /dev/pmem1
MOUNT_OPTIONS -- -o context=system_u:object_r:nfs_t:s0 /dev/pmem1 /daxsch

xfs/091  104s
Ran: xfs/091
Passed all 1 tests

+ echo 'MOUNT_OPTIONS="-o dax"'
+ ./check xfs/091
FSTYP -- xfs (non-debug)
PLATFORM  -- Linux/x86_64 rhel73 4.7.0+
MKFS_OPTIONS  -- -f -bsize=4096 /dev/pmem1
MOUNT_OPTIONS -- -o dax -o context=system_u:object_r:nfs_t:s0 /dev/pmem1 /daxsch

xfs/091 104s ...  - output mismatch (see 
/root/xfstests/results//xfs/091.out.bad)
--- tests/xfs/091.out   2016-07-18 02:57:47.67000 -0400
+++ /root/xfstests/results//xfs/091.out.bad 2016-08-03 22:38:14.94800 
-0400
@@ -6,6 +6,70 @@
 + corrupt image
 + mount image
 + modify files
+pwrite64: Structure needs cleaning
+pwrite64: Structure needs cleaning
+pwrite64: Structure needs cleaning
+pwrite64: Structure needs cleaning
...
(Run 'diff -u tests/xfs/091.out /root/xfstests/results//xfs/091.out.bad'  
to see the entire diff)
Ran: xfs/091
Failures: xfs/091
Failed 1 of 1 tests

# diff -u xfstests/tests/xfs/091.out /root/xfstests/results//xfs/091.out.bad
--- xfstests/tests/xfs/091.out  2016-07-18 02:57:47.67000 -0400
+++ /root/xfstests/results//xfs/091.out.bad 2016-08-03 22:38:14.94800 
-0400
@@ -6,6 +6,70 @@
 + corrupt image
 + mount image
 + modify files
+pwrite64: Structure needs cleaning

+pwrite64: Structure needs cleaning
 + repair fs
 + mount image
 + chattr -R -i


Thanks,
Xiong

[PATCH v2 7/7] drm/mediatek: Fix mtk_atomic_complete for runtime_pm

[Bibby Hsieh]

To properly implement atomic w/ runtime pm, we move
drm_atomic_helper_commit_modeset_enables() above
drm_atomic_helper_commit_planes() to ensure CRTCs are enabled before
modifying plane registers, and set active_only to true to filter out
plane update notifications when the CRTC is disabled.

According to the document from linux kernel:
Set the active_only parameters to true in order not to receive plane
update notifications related to a disabled CRTC. This avoids the need
to manually ignore plane updates in driver code when the driver and/or
hardware can't or just don't need to deal with updates on disabled
CRTCs, for example when supporting runtime PM.

Signed-off-by: Bibby Hsieh 
Signed-off-by: Daniel Kurtz 
---
 drivers/gpu/drm/mediatek/mtk_drm_drv.c |   17 -
 1 file changed, 16 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c 
b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
index b1223d5..507392a 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
@@ -61,10 +61,25 @@ static void mtk_atomic_complete(struct mtk_drm_private 
*private,
 
mtk_atomic_wait_for_fences(state);
 
+   /*
+* Mediatek drm supports runtime PM, so plane registers cannot be
+* written when their crtc is disabled.
+*
+* The comment for drm_atomic_helper_commit states:
+* For drivers supporting runtime PM the recommended sequence is
+*
+* drm_atomic_helper_commit_modeset_disables(dev, state);
+* drm_atomic_helper_commit_modeset_enables(dev, state);
+* drm_atomic_helper_commit_planes(dev, state, true);
+*
+* See the kerneldoc entries for these three functions for more details.
+*/
drm_atomic_helper_commit_modeset_disables(drm, state);
-   drm_atomic_helper_commit_planes(drm, state, false);
drm_atomic_helper_commit_modeset_enables(drm, state);
+   drm_atomic_helper_commit_planes(drm, state, true);
+
drm_atomic_helper_wait_for_vblanks(drm, state);
+
drm_atomic_helper_cleanup_planes(drm, state);
drm_atomic_state_free(state);
 }
-- 
1.7.9.5

[PATCH v2 2/7] drm/mediatek: plane: Remove plane zpos/index

[Bibby Hsieh]

From: Daniel Kurtz 

It is not actually useful to a mtk plane to know its zpos/index, so just
remove this field.

This let's completely remove struct mtk_drm_plane in a follow up patch.

Signed-off-by: Daniel Kurtz 
Signed-off-by: Bibby Hsieh 
---
 drivers/gpu/drm/mediatek/mtk_drm_crtc.c  |2 +-
 drivers/gpu/drm/mediatek/mtk_drm_plane.c |4 +---
 drivers/gpu/drm/mediatek/mtk_drm_plane.h |4 +---
 3 files changed, 3 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c 
b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
index 24aa3ba..18211ab 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
@@ -559,7 +559,7 @@ int mtk_drm_crtc_create(struct drm_device *drm_dev,
(zpos == 1) ? DRM_PLANE_TYPE_CURSOR :
DRM_PLANE_TYPE_OVERLAY;
ret = mtk_plane_init(drm_dev, _crtc->planes[zpos],
-BIT(pipe), type, zpos);
+BIT(pipe), type);
if (ret)
goto unprepare;
}
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_plane.c 
b/drivers/gpu/drm/mediatek/mtk_drm_plane.c
index 5f2516f..32a8e55 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_plane.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_plane.c
@@ -189,8 +189,7 @@ static const struct drm_plane_helper_funcs 
mtk_plane_helper_funcs = {
 };
 
 int mtk_plane_init(struct drm_device *dev, struct mtk_drm_plane *mtk_plane,
-  unsigned long possible_crtcs, enum drm_plane_type type,
-  unsigned int zpos)
+  unsigned long possible_crtcs, enum drm_plane_type type)
 {
int err;
 
@@ -203,7 +202,6 @@ int mtk_plane_init(struct drm_device *dev, struct 
mtk_drm_plane *mtk_plane,
}
 
drm_plane_helper_add(_plane->base, _plane_helper_funcs);
-   mtk_plane->idx = zpos;
 
return 0;
 }
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_plane.h 
b/drivers/gpu/drm/mediatek/mtk_drm_plane.h
index 72a7b3e..74dbeda 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_plane.h
+++ b/drivers/gpu/drm/mediatek/mtk_drm_plane.h
@@ -20,7 +20,6 @@
 
 struct mtk_drm_plane {
struct drm_planebase;
-   unsigned intidx;
 };
 
 struct mtk_plane_pending_state {
@@ -53,7 +52,6 @@ to_mtk_plane_state(struct drm_plane_state *state)
 }
 
 int mtk_plane_init(struct drm_device *dev, struct mtk_drm_plane *mtk_plane,
-  unsigned long possible_crtcs, enum drm_plane_type type,
-  unsigned int zpos);
+  unsigned long possible_crtcs, enum drm_plane_type type);
 
 #endif
-- 
1.7.9.5

Re: [RFC][PATCH 3/4] power: reset: Add sram-reboot-mode driver

[John Stultz]

On Wed, Aug 3, 2016 at 6:03 PM, Bjorn Andersson
 wrote:
> On Wed 03 Aug 16:05 PDT 2016, John Stultz wrote:
>
> [..]
>> diff --git a/drivers/power/reset/sram-reboot-mode.c 
>> b/drivers/power/reset/sram-reboot-mode.c
> [..]
>> +
>> +struct sram_reboot_mode {
>> + struct reboot_mode_driver reboot;
>> + void __iomem *reboot_reason_val_addr;
>
> 23 characters is...a lot of characters...

Fair enough. Renamed to reason_addr.


>> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>> + if (!res)
>> + return PTR_ERR(res);
>> +
>> + sram_rbm->reboot_reason_val_addr = devm_ioremap(>dev, res->start,
>> +  resource_size(res));
>
> Use devm_ioremap_resource() instead, it saves you the return value check
> on platform_get_resource() and is cleaner.

Ok. Done.


>> + if (IS_ERR(sram_rbm->reboot_reason_val_addr))
>> + return PTR_ERR(sram_rbm->reboot_reason_val_addr);
>> +
>> + ret = reboot_mode_register(_rbm->reboot);
>
> I think you should take the time to throw in a
> devm_reboot_mode_register(), it would save you from the
> dev_set_drvdata() and you can drop the remove function.

So I've only got a vague sense of what your suggesting here. Do you
have a pointer to a good example?

thanks
-john

xfstests xfs fuzzers fail with DAX

[Xiong Zhou]

Hi,

A few xfs fuzzers in xfstests fail with dax mount option, pass without dax.
They are xfs/086 xfs/088 xfs/089 xfs/091.

xfstests to commit 4470ad4c7e  (Jul 26)
kernel   to commit dd95069545  (Jul 24)

+ ./check xfs/091
FSTYP -- xfs (non-debug)
PLATFORM  -- Linux/x86_64 rhel73 4.7.0+
MKFS_OPTIONS  -- -f -bsize=4096 /dev/pmem1
MOUNT_OPTIONS -- -o context=system_u:object_r:nfs_t:s0 /dev/pmem1 /daxsch

xfs/091  104s
Ran: xfs/091
Passed all 1 tests

+ echo 'MOUNT_OPTIONS="-o dax"'
+ ./check xfs/091
FSTYP -- xfs (non-debug)
PLATFORM  -- Linux/x86_64 rhel73 4.7.0+
MKFS_OPTIONS  -- -f -bsize=4096 /dev/pmem1
MOUNT_OPTIONS -- -o dax -o context=system_u:object_r:nfs_t:s0 /dev/pmem1 /daxsch

xfs/091 104s ...  - output mismatch (see 
/root/xfstests/results//xfs/091.out.bad)
--- tests/xfs/091.out   2016-07-18 02:57:47.67000 -0400
+++ /root/xfstests/results//xfs/091.out.bad 2016-08-03 22:38:14.94800 
-0400
@@ -6,6 +6,70 @@
 + corrupt image
 + mount image
 + modify files
+pwrite64: Structure needs cleaning
+pwrite64: Structure needs cleaning
+pwrite64: Structure needs cleaning
+pwrite64: Structure needs cleaning
...
(Run 'diff -u tests/xfs/091.out /root/xfstests/results//xfs/091.out.bad'  
to see the entire diff)
Ran: xfs/091
Failures: xfs/091
Failed 1 of 1 tests

# diff -u xfstests/tests/xfs/091.out /root/xfstests/results//xfs/091.out.bad
--- xfstests/tests/xfs/091.out  2016-07-18 02:57:47.67000 -0400
+++ /root/xfstests/results//xfs/091.out.bad 2016-08-03 22:38:14.94800 
-0400
@@ -6,6 +6,70 @@
 + corrupt image
 + mount image
 + modify files
+pwrite64: Structure needs cleaning

+pwrite64: Structure needs cleaning
 + repair fs
 + mount image
 + chattr -R -i


Thanks,
Xiong