Re: [linux-sunxi] [PATCH 1/3] ASoC: sun4i-i2s: Add set_tdm_slot functionality

[Code Kipper]

On 29 January 2018 at 08:38, Chen-Yu Tsai  wrote:
> On Mon, Jan 29, 2018 at 3:34 PM, Code Kipper  wrote:
>> On 29 January 2018 at 02:50, Chen-Yu Tsai  wrote:
>>> On Wed, Jan 24, 2018 at 10:10 PM,   wrote:
 From: Marcus Cooper 

 Some codecs require a different amount of a bit clocks per frame than
 what is calculated by the sample width. Use the tdm slot bindings to
 provide this mechanism.

 Signed-off-by: Marcus Cooper 
 ---
  sound/soc/sunxi/sun4i-i2s.c | 23 +--
  1 file changed, 21 insertions(+), 2 deletions(-)

 diff --git a/sound/soc/sunxi/sun4i-i2s.c b/sound/soc/sunxi/sun4i-i2s.c
 index dca1143c1150..d7a9141514cf 100644
 --- a/sound/soc/sunxi/sun4i-i2s.c
 +++ b/sound/soc/sunxi/sun4i-i2s.c
 @@ -96,6 +96,7 @@
  #define SUN8I_I2S_CTRL_BCLK_OUTBIT(18)
  #define SUN8I_I2S_CTRL_LRCK_OUTBIT(17)

 +#define SUN8I_I2S_FMT0_LRCK_MAX_PERIOD (GENMASK(17, 8) >> 8)
  #define SUN8I_I2S_FMT0_LRCK_PERIOD_MASKGENMASK(17, 8)
  #define SUN8I_I2S_FMT0_LRCK_PERIOD(period) ((period - 1) << 8)

 @@ -193,6 +194,9 @@ struct sun4i_i2s {
 struct regmap_field *field_rxchansel;

 const struct sun4i_i2s_quirks   *variant;
 +
 +   unsigned inttdm_slots;
 +   unsigned intslot_width;
  };

  struct sun4i_i2s_clk_div {
 @@ -344,7 +348,7 @@ static int sun4i_i2s_set_clk_rate(struct snd_soc_dai 
 *dai,
 if (i2s->variant->has_fmt_set_lrck_period)
 regmap_update_bits(i2s->regmap, SUN4I_I2S_FMT0_REG,
SUN8I_I2S_FMT0_LRCK_PERIOD_MASK,
 -  SUN8I_I2S_FMT0_LRCK_PERIOD(32));
 +  SUN8I_I2S_FMT0_LRCK_PERIOD(word_size));

 return 0;
  }
 @@ -418,7 +422,8 @@ static int sun4i_i2s_hw_params(struct 
 snd_pcm_substream *substream,
sr + i2s->variant->fmt_offset);

 return sun4i_i2s_set_clk_rate(dai, params_rate(params),
 - params_width(params));
 + i2s->tdm_slots ?
 + i2s->slot_width : 
 params_width(params));
  }

  static int sun4i_i2s_set_fmt(struct snd_soc_dai *dai, unsigned int fmt)
 @@ -691,6 +696,19 @@ static int sun4i_i2s_set_sysclk(struct snd_soc_dai 
 *dai, int clk_id,
 return 0;
  }

 +static int sun4i_i2s_set_dai_tdm_slot(struct snd_soc_dai *dai,
 +   unsigned int tx_mask, unsigned int rx_mask,
 +   int slots, int width)
 +{
 +   struct sun4i_i2s *i2s = snd_soc_dai_get_drvdata(dai);
 +
 +   i2s->tdm_slots = slots;
 +
 +   i2s->slot_width = width;
 +
 +   return 0;
 +}
 +
>>>
>>> IIRC some of the DAI controllers actually support TDM. Would this
>>> change conflict with that in the future?
>>
>> Hi Wens,
>> I'm not sure..I was looking for a clean example of being able to
>> override the number of bclks in the lrclk width and some other
>> devices(Rpi) were doing it this way.  I open to suggestions,
>
> I'm not familiar with the issue either. If Mark doesn't have any
> objections, we could merge it for now, and fix it later if there
> are any complications.
>
> BTW, you didn't provide a device tree example (if any) for how
> to use this.

Hi Wens,

here is an example that I use for the Pine64 audio hat.
https://github.com/codekipper/linux-sunxi/commit/faa9dfba955bf71ca23b089b1cb678a14443216f#diff-1473a38b339685d191c5a87aab9c0fdfR80

I've done the same on the A64 for HDMI and analog audio which both use
the i2s and seem to require 32bit LRCK width.

BR,
CK

>
> ChenYu
>
>> BR,
>> CK
>>>
>>> Thanks
>>> ChenYu
>>>
  static const struct snd_soc_dai_ops sun4i_i2s_dai_ops = {
 .hw_params  = sun4i_i2s_hw_params,
 .set_fmt= sun4i_i2s_set_fmt,
 @@ -698,6 +716,7 @@ static const struct snd_soc_dai_ops sun4i_i2s_dai_ops 
 = {
 .shutdown   = sun4i_i2s_shutdown,
 .startup= sun4i_i2s_startup,
 .trigger= sun4i_i2s_trigger,
 +   .set_tdm_slot   = sun4i_i2s_set_dai_tdm_slot,
  };

  static int sun4i_i2s_dai_probe(struct snd_soc_dai *dai)
 --
 2.16.0

 --
 You received this message because you are subscribed to the Google Groups 
 "linux-sunxi" group.
 To unsubscribe from this group and stop receiving emails from it, send an 
 email to linux-sunxi+unsubscr...@googlegroups.com.
 For more options, visit https://groups.google.com/d/optout.

Re: [linux-sunxi] [PATCH 1/3] ASoC: sun4i-i2s: Add set_tdm_slot functionality

[Code Kipper]

On 29 January 2018 at 08:38, Chen-Yu Tsai  wrote:
> On Mon, Jan 29, 2018 at 3:34 PM, Code Kipper  wrote:
>> On 29 January 2018 at 02:50, Chen-Yu Tsai  wrote:
>>> On Wed, Jan 24, 2018 at 10:10 PM,   wrote:
 From: Marcus Cooper 

 Some codecs require a different amount of a bit clocks per frame than
 what is calculated by the sample width. Use the tdm slot bindings to
 provide this mechanism.

 Signed-off-by: Marcus Cooper 
 ---
  sound/soc/sunxi/sun4i-i2s.c | 23 +--
  1 file changed, 21 insertions(+), 2 deletions(-)

 diff --git a/sound/soc/sunxi/sun4i-i2s.c b/sound/soc/sunxi/sun4i-i2s.c
 index dca1143c1150..d7a9141514cf 100644
 --- a/sound/soc/sunxi/sun4i-i2s.c
 +++ b/sound/soc/sunxi/sun4i-i2s.c
 @@ -96,6 +96,7 @@
  #define SUN8I_I2S_CTRL_BCLK_OUTBIT(18)
  #define SUN8I_I2S_CTRL_LRCK_OUTBIT(17)

 +#define SUN8I_I2S_FMT0_LRCK_MAX_PERIOD (GENMASK(17, 8) >> 8)
  #define SUN8I_I2S_FMT0_LRCK_PERIOD_MASKGENMASK(17, 8)
  #define SUN8I_I2S_FMT0_LRCK_PERIOD(period) ((period - 1) << 8)

 @@ -193,6 +194,9 @@ struct sun4i_i2s {
 struct regmap_field *field_rxchansel;

 const struct sun4i_i2s_quirks   *variant;
 +
 +   unsigned inttdm_slots;
 +   unsigned intslot_width;
  };

  struct sun4i_i2s_clk_div {
 @@ -344,7 +348,7 @@ static int sun4i_i2s_set_clk_rate(struct snd_soc_dai 
 *dai,
 if (i2s->variant->has_fmt_set_lrck_period)
 regmap_update_bits(i2s->regmap, SUN4I_I2S_FMT0_REG,
SUN8I_I2S_FMT0_LRCK_PERIOD_MASK,
 -  SUN8I_I2S_FMT0_LRCK_PERIOD(32));
 +  SUN8I_I2S_FMT0_LRCK_PERIOD(word_size));

 return 0;
  }
 @@ -418,7 +422,8 @@ static int sun4i_i2s_hw_params(struct 
 snd_pcm_substream *substream,
sr + i2s->variant->fmt_offset);

 return sun4i_i2s_set_clk_rate(dai, params_rate(params),
 - params_width(params));
 + i2s->tdm_slots ?
 + i2s->slot_width : 
 params_width(params));
  }

  static int sun4i_i2s_set_fmt(struct snd_soc_dai *dai, unsigned int fmt)
 @@ -691,6 +696,19 @@ static int sun4i_i2s_set_sysclk(struct snd_soc_dai 
 *dai, int clk_id,
 return 0;
  }

 +static int sun4i_i2s_set_dai_tdm_slot(struct snd_soc_dai *dai,
 +   unsigned int tx_mask, unsigned int rx_mask,
 +   int slots, int width)
 +{
 +   struct sun4i_i2s *i2s = snd_soc_dai_get_drvdata(dai);
 +
 +   i2s->tdm_slots = slots;
 +
 +   i2s->slot_width = width;
 +
 +   return 0;
 +}
 +
>>>
>>> IIRC some of the DAI controllers actually support TDM. Would this
>>> change conflict with that in the future?
>>
>> Hi Wens,
>> I'm not sure..I was looking for a clean example of being able to
>> override the number of bclks in the lrclk width and some other
>> devices(Rpi) were doing it this way.  I open to suggestions,
>
> I'm not familiar with the issue either. If Mark doesn't have any
> objections, we could merge it for now, and fix it later if there
> are any complications.
>
> BTW, you didn't provide a device tree example (if any) for how
> to use this.

Hi Wens,

here is an example that I use for the Pine64 audio hat.
https://github.com/codekipper/linux-sunxi/commit/faa9dfba955bf71ca23b089b1cb678a14443216f#diff-1473a38b339685d191c5a87aab9c0fdfR80

I've done the same on the A64 for HDMI and analog audio which both use
the i2s and seem to require 32bit LRCK width.

BR,
CK

>
> ChenYu
>
>> BR,
>> CK
>>>
>>> Thanks
>>> ChenYu
>>>
  static const struct snd_soc_dai_ops sun4i_i2s_dai_ops = {
 .hw_params  = sun4i_i2s_hw_params,
 .set_fmt= sun4i_i2s_set_fmt,
 @@ -698,6 +716,7 @@ static const struct snd_soc_dai_ops sun4i_i2s_dai_ops 
 = {
 .shutdown   = sun4i_i2s_shutdown,
 .startup= sun4i_i2s_startup,
 .trigger= sun4i_i2s_trigger,
 +   .set_tdm_slot   = sun4i_i2s_set_dai_tdm_slot,
  };

  static int sun4i_i2s_dai_probe(struct snd_soc_dai *dai)
 --
 2.16.0

 --
 You received this message because you are subscribed to the Google Groups 
 "linux-sunxi" group.
 To unsubscribe from this group and stop receiving emails from it, send an 
 email to linux-sunxi+unsubscr...@googlegroups.com.
 For more options, visit https://groups.google.com/d/optout.

Re: [f2fs-dev] [PATCH 1/3] f2fs: support passing down write hints given by users to block layer

[Chao Yu]

On 2018/1/29 9:49, Hyunchul Lee wrote:
> 
> On 01/26/2018 11:10 AM, Chao Yu wrote:
>> On 2018/1/26 7:46, Hyunchul Lee wrote:
>>> On 01/25/2018 05:01 PM, Chao Yu wrote:
 Hi Hyunchul,

 On 2018/1/25 10:47, Hyunchul Lee wrote:
> Hi Chao,
>
> On 01/25/2018 12:32 AM, Chao Yu wrote:
>> On 2018/1/22 18:49, Hyunchul Lee wrote:
>>> From: Hyunchul Lee 
>>>
>>> Add the 'whint_mode' mount option that controls which write
>>> hints are passed down to block layer. There are "off" and
>>> "user-based" mode. The default mode is "off".
>>>
>>> 1) whint_mode=user-based. F2FS tries to pass down hints given
>>> by users.
>>
>> Minor,
>>
>> 1) whint_mode=off. F2FS only passes down WRITE_LIFE_NOT_SET
>>
>> 2) whint_mode=user-based. F2FS tries to pass down hints given by users.
>> ...
>>
>
> Okay, I will reflect this.
>
>> How about changing all comments and codes with above order?
>>
>>>
>>> User  F2FS Block
>>>    -
>>>   META WRITE_LIFE_NOT_SET
>>>   HOT_NODE "
>>>   WARM_NODE"
>>>   COLD_NODE"
>>> ioctl(COLD)   COLD_DATAWRITE_LIFE_EXTREME
>>> extension list""
>>>
>>> -- buffered io
>>> WRITE_LIFE_EXTREMECOLD_DATAWRITE_LIFE_EXTREME
>>> WRITE_LIFE_SHORT  HOT_DATA WRITE_LIFE_SHORT
>>> WRITE_LIFE_NOT_SETWARM_DATAWRITE_LIFE_NOT_SET
>>> WRITE_LIFE_NONE   ""
>>> WRITE_LIFE_MEDIUM ""
>>> WRITE_LIFE_LONG   ""
>>>
>>> -- direct io
>>> WRITE_LIFE_EXTREMECOLD_DATAWRITE_LIFE_EXTREME
>>> WRITE_LIFE_SHORT  HOT_DATA WRITE_LIFE_SHORT
>>> WRITE_LIFE_NOT_SETWARM_DATAWRITE_LIFE_NOT_SET
>>> WRITE_LIFE_NONE   "WRITE_LIFE_NONE
>>> WRITE_LIFE_MEDIUM "WRITE_LIFE_MEDIUM
>>> WRITE_LIFE_LONG   "WRITE_LIFE_LONG
>>>
>>> 2) whint_mode=off. F2FS only passes down WRITE_LIFE_NOT_SET.
>>>
>>> Many thanks to Chao Yu and Jaegeuk Kim for comments to
>>> implement this patch.
>>>
>>> Signed-off-by: Hyunchul Lee 
>>> ---
>>>  fs/f2fs/data.c| 27 -
>>>  fs/f2fs/f2fs.h|  9 +
>>>  fs/f2fs/segment.c | 59 
>>> +++
>>>  fs/f2fs/super.c   | 24 +-
>>>  4 files changed, 113 insertions(+), 6 deletions(-)
>>>
>>> diff --git a/fs/f2fs/data.c b/fs/f2fs/data.c
>>> index 6cba74e..c76ddc2 100644
>>> --- a/fs/f2fs/data.c
>>> +++ b/fs/f2fs/data.c
>>> @@ -175,15 +175,22 @@ static bool __same_bdev(struct f2fs_sb_info *sbi,
>>>   */
>>>  static struct bio *__bio_alloc(struct f2fs_sb_info *sbi, block_t 
>>> blk_addr,
>>> struct writeback_control *wbc,
>>> -   int npages, bool is_read)
>>> +   int npages, bool is_read,
>>> +   enum page_type type, enum temp_type 
>>> temp)
>>>  {
>>> struct bio *bio;
>>>  
>>> bio = f2fs_bio_alloc(sbi, npages, true);
>>>  
>>> f2fs_target_device(sbi, blk_addr, bio);
>>> -   bio->bi_end_io = is_read ? f2fs_read_end_io : f2fs_write_end_io;
>>> -   bio->bi_private = is_read ? NULL : sbi;
>>> +   if (is_read) {
>>> +   bio->bi_end_io = f2fs_read_end_io;
>>> +   bio->bi_private = NULL;
>>> +   } else {
>>> +   bio->bi_end_io = f2fs_write_end_io;
>>> +   bio->bi_private = sbi;
>>> +   bio->bi_write_hint = io_type_to_rw_hint(sbi, type, 
>>> temp);
>>> +   }
>>> if (wbc)
>>> wbc_init_bio(wbc, bio);
>>>  
>>> @@ -382,7 +389,7 @@ int f2fs_submit_page_bio(struct f2fs_io_info *fio)
>>>  
>>> /* Allocate a new bio */
>>> bio = __bio_alloc(fio->sbi, fio->new_blkaddr, fio->io_wbc,
>>> -   1, is_read_io(fio->op));
>>> +   1, is_read_io(fio->op), fio->type, 
>>> fio->temp);
>>>  
>>> if (bio_add_page(bio, page, PAGE_SIZE, 0) < PAGE_SIZE) {
>>> bio_put(bio);
>>> @@ -445,7 +452,8 @@ int f2fs_submit_page_write(struct f2fs_io_info *fio)
>>> goto out_fail;

Re: [f2fs-dev] [PATCH 1/3] f2fs: support passing down write hints given by users to block layer

[Chao Yu]

On 2018/1/29 9:49, Hyunchul Lee wrote:
> 
> On 01/26/2018 11:10 AM, Chao Yu wrote:
>> On 2018/1/26 7:46, Hyunchul Lee wrote:
>>> On 01/25/2018 05:01 PM, Chao Yu wrote:
 Hi Hyunchul,

 On 2018/1/25 10:47, Hyunchul Lee wrote:
> Hi Chao,
>
> On 01/25/2018 12:32 AM, Chao Yu wrote:
>> On 2018/1/22 18:49, Hyunchul Lee wrote:
>>> From: Hyunchul Lee 
>>>
>>> Add the 'whint_mode' mount option that controls which write
>>> hints are passed down to block layer. There are "off" and
>>> "user-based" mode. The default mode is "off".
>>>
>>> 1) whint_mode=user-based. F2FS tries to pass down hints given
>>> by users.
>>
>> Minor,
>>
>> 1) whint_mode=off. F2FS only passes down WRITE_LIFE_NOT_SET
>>
>> 2) whint_mode=user-based. F2FS tries to pass down hints given by users.
>> ...
>>
>
> Okay, I will reflect this.
>
>> How about changing all comments and codes with above order?
>>
>>>
>>> User  F2FS Block
>>>    -
>>>   META WRITE_LIFE_NOT_SET
>>>   HOT_NODE "
>>>   WARM_NODE"
>>>   COLD_NODE"
>>> ioctl(COLD)   COLD_DATAWRITE_LIFE_EXTREME
>>> extension list""
>>>
>>> -- buffered io
>>> WRITE_LIFE_EXTREMECOLD_DATAWRITE_LIFE_EXTREME
>>> WRITE_LIFE_SHORT  HOT_DATA WRITE_LIFE_SHORT
>>> WRITE_LIFE_NOT_SETWARM_DATAWRITE_LIFE_NOT_SET
>>> WRITE_LIFE_NONE   ""
>>> WRITE_LIFE_MEDIUM ""
>>> WRITE_LIFE_LONG   ""
>>>
>>> -- direct io
>>> WRITE_LIFE_EXTREMECOLD_DATAWRITE_LIFE_EXTREME
>>> WRITE_LIFE_SHORT  HOT_DATA WRITE_LIFE_SHORT
>>> WRITE_LIFE_NOT_SETWARM_DATAWRITE_LIFE_NOT_SET
>>> WRITE_LIFE_NONE   "WRITE_LIFE_NONE
>>> WRITE_LIFE_MEDIUM "WRITE_LIFE_MEDIUM
>>> WRITE_LIFE_LONG   "WRITE_LIFE_LONG
>>>
>>> 2) whint_mode=off. F2FS only passes down WRITE_LIFE_NOT_SET.
>>>
>>> Many thanks to Chao Yu and Jaegeuk Kim for comments to
>>> implement this patch.
>>>
>>> Signed-off-by: Hyunchul Lee 
>>> ---
>>>  fs/f2fs/data.c| 27 -
>>>  fs/f2fs/f2fs.h|  9 +
>>>  fs/f2fs/segment.c | 59 
>>> +++
>>>  fs/f2fs/super.c   | 24 +-
>>>  4 files changed, 113 insertions(+), 6 deletions(-)
>>>
>>> diff --git a/fs/f2fs/data.c b/fs/f2fs/data.c
>>> index 6cba74e..c76ddc2 100644
>>> --- a/fs/f2fs/data.c
>>> +++ b/fs/f2fs/data.c
>>> @@ -175,15 +175,22 @@ static bool __same_bdev(struct f2fs_sb_info *sbi,
>>>   */
>>>  static struct bio *__bio_alloc(struct f2fs_sb_info *sbi, block_t 
>>> blk_addr,
>>> struct writeback_control *wbc,
>>> -   int npages, bool is_read)
>>> +   int npages, bool is_read,
>>> +   enum page_type type, enum temp_type 
>>> temp)
>>>  {
>>> struct bio *bio;
>>>  
>>> bio = f2fs_bio_alloc(sbi, npages, true);
>>>  
>>> f2fs_target_device(sbi, blk_addr, bio);
>>> -   bio->bi_end_io = is_read ? f2fs_read_end_io : f2fs_write_end_io;
>>> -   bio->bi_private = is_read ? NULL : sbi;
>>> +   if (is_read) {
>>> +   bio->bi_end_io = f2fs_read_end_io;
>>> +   bio->bi_private = NULL;
>>> +   } else {
>>> +   bio->bi_end_io = f2fs_write_end_io;
>>> +   bio->bi_private = sbi;
>>> +   bio->bi_write_hint = io_type_to_rw_hint(sbi, type, 
>>> temp);
>>> +   }
>>> if (wbc)
>>> wbc_init_bio(wbc, bio);
>>>  
>>> @@ -382,7 +389,7 @@ int f2fs_submit_page_bio(struct f2fs_io_info *fio)
>>>  
>>> /* Allocate a new bio */
>>> bio = __bio_alloc(fio->sbi, fio->new_blkaddr, fio->io_wbc,
>>> -   1, is_read_io(fio->op));
>>> +   1, is_read_io(fio->op), fio->type, 
>>> fio->temp);
>>>  
>>> if (bio_add_page(bio, page, PAGE_SIZE, 0) < PAGE_SIZE) {
>>> bio_put(bio);
>>> @@ -445,7 +452,8 @@ int f2fs_submit_page_write(struct f2fs_io_info *fio)
>>> goto out_fail;
>>> }
>>>

Re: [PATCH 3/3] Revert "e1000e: Do not read ICR in Other interrupt"

[Benjamin Poirier]

On 2018/01/26 13:01, Alexander Duyck wrote:
> On Fri, Jan 26, 2018 at 1:12 AM, Benjamin Poirier  wrote:
> > This reverts commit 16ecba59bc333d6282ee057fb02339f77a880beb.
> >
> > It was reported that emulated e1000e devices in vmware esxi 6.5 Build
> > 7526125 do not link up after commit 4aea7a5c5e94 ("e1000e: Avoid receiver
> > overrun interrupt bursts"). Some tracing shows that after
> > e1000e_trigger_lsc() is called, ICR reads out as 0x0 in e1000_msix_other()
> > on emulated e1000e devices. In comparison, on real e1000e 82574 hardware,
> > icr=0x8004 (_INT_ASSERTED | _LSC) in the same situation.
> >
> > Some experimentation showed that this flaw in vmware e1000e emulation can
> > be worked around by not setting Other in EIAC. This is how it was before
> > commit 16ecba59bc33 ("e1000e: Do not read ICR in Other interrupt").
> >
> > Since the ICR read in the Other interrupt handler has already been
> > restored, this patch effectively reverts the remainder of commit
> > 16ecba59bc33 ("e1000e: Do not read ICR in Other interrupt").
> >
> > Fixes: 4aea7a5c5e94 ("e1000e: Avoid receiver overrun interrupt bursts")
> > Signed-off-by: Benjamin Poirier 
> > ---
> >  drivers/net/ethernet/intel/e1000e/netdev.c | 10 --
> >  1 file changed, 8 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/net/ethernet/intel/e1000e/netdev.c 
> > b/drivers/net/ethernet/intel/e1000e/netdev.c
> > index ed103b9a8d3a..fffc1f0e3895 100644
> > --- a/drivers/net/ethernet/intel/e1000e/netdev.c
> > +++ b/drivers/net/ethernet/intel/e1000e/netdev.c
> > @@ -1916,6 +1916,13 @@ static irqreturn_t e1000_msix_other(int 
> > __always_unused irq, void *data)
> > struct e1000_hw *hw = >hw;
> > u32 icr = er32(ICR);
> >
> > +   /* Certain events (such as RXO) which trigger Other do not set
> > +* INT_ASSERTED. In that case, read to clear of icr does not take
> > +* place.
> > +*/
> > +   if (!(icr & E1000_ICR_INT_ASSERTED))
> > +   ew32(ICR, E1000_ICR_OTHER);
> > +
> 
> This piece doesn't make sense to me. Why are we clearing OTHER if
> ICR_INT_ASSERTED is not set?

Datasheet §10.2.4.1 ("Interrupt Cause Read Register") says that ICR read
to clear only occurs if INT_ASSERTED is set. This corresponds to what I
observed.

However, while working on these issues, I noticed that when there is an rxo
event, INT_ASSERTED is not always set even though the interrupt is raised. I
think this is a hardware flaw.

For example, if doing
ew32(ICS, E1000_ICS_LSC | E1000_ICS_OTHER);
we enter e1000_msix_other() and two consecutive reads of ICR result in
0x8104
0x

If doing
ew32(ICS, E1000_ICS_RXO | E1000_ICS_OTHER);
we enter e1000_msix_other() and two consecutive reads of ICR result in
0x0141
0x0141

Consequently, we must clear OTHER manually from ICR, otherwise the
interrupt is immediately re-raised after exiting the handler.

These observations are the same whether the interrupt is triggered via a
write to ICS or in hardware.

Furthermore, I tested that this behavior is the same for other Other
events (MDAC, SRPD, ACK, MNG). Those were tested via a write to ICS
only, not in hardware.

This is a version of the test patch that I used to trigger lsc and rxo in
software and hardware. It applies over this patch series.

diff --git a/drivers/net/ethernet/intel/e1000e/defines.h 
b/drivers/net/ethernet/intel/e1000e/defines.h
index 0641c0098738..f54e7ac9c934 100644
--- a/drivers/net/ethernet/intel/e1000e/defines.h
+++ b/drivers/net/ethernet/intel/e1000e/defines.h
@@ -398,6 +398,7 @@
 #define E1000_ICR_LSC   0x0004 /* Link Status Change */
 #define E1000_ICR_RXSEQ 0x0008 /* Rx sequence error */
 #define E1000_ICR_RXDMT00x0010 /* Rx desc min. threshold (0) */
+#define E1000_ICR_RXO   0x0040 /* rx overrun */
 #define E1000_ICR_RXT0  0x0080 /* Rx timer intr (ring 0) */
 #define E1000_ICR_ECCER 0x0040 /* Uncorrectable ECC Error */
 /* If this bit asserted, the driver should claim the interrupt */
diff --git a/drivers/net/ethernet/intel/e1000e/ethtool.c 
b/drivers/net/ethernet/intel/e1000e/ethtool.c
index 003cbd605799..4933c1beac74 100644
--- a/drivers/net/ethernet/intel/e1000e/ethtool.c
+++ b/drivers/net/ethernet/intel/e1000e/ethtool.c
@@ -1802,98 +1802,20 @@ static void e1000_diag_test(struct net_device *netdev,
struct ethtool_test *eth_test, u64 *data)
 {
struct e1000_adapter *adapter = netdev_priv(netdev);
-   u16 autoneg_advertised;
-   u8 forced_speed_duplex;
-   u8 autoneg;
-   bool if_running = netif_running(netdev);
+   struct e1000_hw *hw = >hw;
 
pm_runtime_get_sync(netdev->dev.parent);
 
set_bit(__E1000_TESTING, >state);
 
-   if (!if_running) {
-   /* Get control of and reset hardware */
-   if (adapter->flags & FLAG_HAS_AMT)
-   

Re: [PATCH 3/3] Revert "e1000e: Do not read ICR in Other interrupt"

[Benjamin Poirier]

On 2018/01/26 13:01, Alexander Duyck wrote:
> On Fri, Jan 26, 2018 at 1:12 AM, Benjamin Poirier  wrote:
> > This reverts commit 16ecba59bc333d6282ee057fb02339f77a880beb.
> >
> > It was reported that emulated e1000e devices in vmware esxi 6.5 Build
> > 7526125 do not link up after commit 4aea7a5c5e94 ("e1000e: Avoid receiver
> > overrun interrupt bursts"). Some tracing shows that after
> > e1000e_trigger_lsc() is called, ICR reads out as 0x0 in e1000_msix_other()
> > on emulated e1000e devices. In comparison, on real e1000e 82574 hardware,
> > icr=0x8004 (_INT_ASSERTED | _LSC) in the same situation.
> >
> > Some experimentation showed that this flaw in vmware e1000e emulation can
> > be worked around by not setting Other in EIAC. This is how it was before
> > commit 16ecba59bc33 ("e1000e: Do not read ICR in Other interrupt").
> >
> > Since the ICR read in the Other interrupt handler has already been
> > restored, this patch effectively reverts the remainder of commit
> > 16ecba59bc33 ("e1000e: Do not read ICR in Other interrupt").
> >
> > Fixes: 4aea7a5c5e94 ("e1000e: Avoid receiver overrun interrupt bursts")
> > Signed-off-by: Benjamin Poirier 
> > ---
> >  drivers/net/ethernet/intel/e1000e/netdev.c | 10 --
> >  1 file changed, 8 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/net/ethernet/intel/e1000e/netdev.c 
> > b/drivers/net/ethernet/intel/e1000e/netdev.c
> > index ed103b9a8d3a..fffc1f0e3895 100644
> > --- a/drivers/net/ethernet/intel/e1000e/netdev.c
> > +++ b/drivers/net/ethernet/intel/e1000e/netdev.c
> > @@ -1916,6 +1916,13 @@ static irqreturn_t e1000_msix_other(int 
> > __always_unused irq, void *data)
> > struct e1000_hw *hw = >hw;
> > u32 icr = er32(ICR);
> >
> > +   /* Certain events (such as RXO) which trigger Other do not set
> > +* INT_ASSERTED. In that case, read to clear of icr does not take
> > +* place.
> > +*/
> > +   if (!(icr & E1000_ICR_INT_ASSERTED))
> > +   ew32(ICR, E1000_ICR_OTHER);
> > +
> 
> This piece doesn't make sense to me. Why are we clearing OTHER if
> ICR_INT_ASSERTED is not set?

Datasheet §10.2.4.1 ("Interrupt Cause Read Register") says that ICR read
to clear only occurs if INT_ASSERTED is set. This corresponds to what I
observed.

However, while working on these issues, I noticed that when there is an rxo
event, INT_ASSERTED is not always set even though the interrupt is raised. I
think this is a hardware flaw.

For example, if doing
ew32(ICS, E1000_ICS_LSC | E1000_ICS_OTHER);
we enter e1000_msix_other() and two consecutive reads of ICR result in
0x8104
0x

If doing
ew32(ICS, E1000_ICS_RXO | E1000_ICS_OTHER);
we enter e1000_msix_other() and two consecutive reads of ICR result in
0x0141
0x0141

Consequently, we must clear OTHER manually from ICR, otherwise the
interrupt is immediately re-raised after exiting the handler.

These observations are the same whether the interrupt is triggered via a
write to ICS or in hardware.

Furthermore, I tested that this behavior is the same for other Other
events (MDAC, SRPD, ACK, MNG). Those were tested via a write to ICS
only, not in hardware.

This is a version of the test patch that I used to trigger lsc and rxo in
software and hardware. It applies over this patch series.

diff --git a/drivers/net/ethernet/intel/e1000e/defines.h 
b/drivers/net/ethernet/intel/e1000e/defines.h
index 0641c0098738..f54e7ac9c934 100644
--- a/drivers/net/ethernet/intel/e1000e/defines.h
+++ b/drivers/net/ethernet/intel/e1000e/defines.h
@@ -398,6 +398,7 @@
 #define E1000_ICR_LSC   0x0004 /* Link Status Change */
 #define E1000_ICR_RXSEQ 0x0008 /* Rx sequence error */
 #define E1000_ICR_RXDMT00x0010 /* Rx desc min. threshold (0) */
+#define E1000_ICR_RXO   0x0040 /* rx overrun */
 #define E1000_ICR_RXT0  0x0080 /* Rx timer intr (ring 0) */
 #define E1000_ICR_ECCER 0x0040 /* Uncorrectable ECC Error */
 /* If this bit asserted, the driver should claim the interrupt */
diff --git a/drivers/net/ethernet/intel/e1000e/ethtool.c 
b/drivers/net/ethernet/intel/e1000e/ethtool.c
index 003cbd605799..4933c1beac74 100644
--- a/drivers/net/ethernet/intel/e1000e/ethtool.c
+++ b/drivers/net/ethernet/intel/e1000e/ethtool.c
@@ -1802,98 +1802,20 @@ static void e1000_diag_test(struct net_device *netdev,
struct ethtool_test *eth_test, u64 *data)
 {
struct e1000_adapter *adapter = netdev_priv(netdev);
-   u16 autoneg_advertised;
-   u8 forced_speed_duplex;
-   u8 autoneg;
-   bool if_running = netif_running(netdev);
+   struct e1000_hw *hw = >hw;
 
pm_runtime_get_sync(netdev->dev.parent);
 
set_bit(__E1000_TESTING, >state);
 
-   if (!if_running) {
-   /* Get control of and reset hardware */
-   if (adapter->flags & FLAG_HAS_AMT)
-   e1000e_get_hw_control(adapter);
-
-   

Re: [linux-sunxi] [PATCH 1/3] ASoC: sun4i-i2s: Add set_tdm_slot functionality

[Chen-Yu Tsai]

On Mon, Jan 29, 2018 at 3:34 PM, Code Kipper  wrote:
> On 29 January 2018 at 02:50, Chen-Yu Tsai  wrote:
>> On Wed, Jan 24, 2018 at 10:10 PM,   wrote:
>>> From: Marcus Cooper 
>>>
>>> Some codecs require a different amount of a bit clocks per frame than
>>> what is calculated by the sample width. Use the tdm slot bindings to
>>> provide this mechanism.
>>>
>>> Signed-off-by: Marcus Cooper 
>>> ---
>>>  sound/soc/sunxi/sun4i-i2s.c | 23 +--
>>>  1 file changed, 21 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/sound/soc/sunxi/sun4i-i2s.c b/sound/soc/sunxi/sun4i-i2s.c
>>> index dca1143c1150..d7a9141514cf 100644
>>> --- a/sound/soc/sunxi/sun4i-i2s.c
>>> +++ b/sound/soc/sunxi/sun4i-i2s.c
>>> @@ -96,6 +96,7 @@
>>>  #define SUN8I_I2S_CTRL_BCLK_OUTBIT(18)
>>>  #define SUN8I_I2S_CTRL_LRCK_OUTBIT(17)
>>>
>>> +#define SUN8I_I2S_FMT0_LRCK_MAX_PERIOD (GENMASK(17, 8) >> 8)
>>>  #define SUN8I_I2S_FMT0_LRCK_PERIOD_MASKGENMASK(17, 8)
>>>  #define SUN8I_I2S_FMT0_LRCK_PERIOD(period) ((period - 1) << 8)
>>>
>>> @@ -193,6 +194,9 @@ struct sun4i_i2s {
>>> struct regmap_field *field_rxchansel;
>>>
>>> const struct sun4i_i2s_quirks   *variant;
>>> +
>>> +   unsigned inttdm_slots;
>>> +   unsigned intslot_width;
>>>  };
>>>
>>>  struct sun4i_i2s_clk_div {
>>> @@ -344,7 +348,7 @@ static int sun4i_i2s_set_clk_rate(struct snd_soc_dai 
>>> *dai,
>>> if (i2s->variant->has_fmt_set_lrck_period)
>>> regmap_update_bits(i2s->regmap, SUN4I_I2S_FMT0_REG,
>>>SUN8I_I2S_FMT0_LRCK_PERIOD_MASK,
>>> -  SUN8I_I2S_FMT0_LRCK_PERIOD(32));
>>> +  SUN8I_I2S_FMT0_LRCK_PERIOD(word_size));
>>>
>>> return 0;
>>>  }
>>> @@ -418,7 +422,8 @@ static int sun4i_i2s_hw_params(struct snd_pcm_substream 
>>> *substream,
>>>sr + i2s->variant->fmt_offset);
>>>
>>> return sun4i_i2s_set_clk_rate(dai, params_rate(params),
>>> - params_width(params));
>>> + i2s->tdm_slots ?
>>> + i2s->slot_width : 
>>> params_width(params));
>>>  }
>>>
>>>  static int sun4i_i2s_set_fmt(struct snd_soc_dai *dai, unsigned int fmt)
>>> @@ -691,6 +696,19 @@ static int sun4i_i2s_set_sysclk(struct snd_soc_dai 
>>> *dai, int clk_id,
>>> return 0;
>>>  }
>>>
>>> +static int sun4i_i2s_set_dai_tdm_slot(struct snd_soc_dai *dai,
>>> +   unsigned int tx_mask, unsigned int rx_mask,
>>> +   int slots, int width)
>>> +{
>>> +   struct sun4i_i2s *i2s = snd_soc_dai_get_drvdata(dai);
>>> +
>>> +   i2s->tdm_slots = slots;
>>> +
>>> +   i2s->slot_width = width;
>>> +
>>> +   return 0;
>>> +}
>>> +
>>
>> IIRC some of the DAI controllers actually support TDM. Would this
>> change conflict with that in the future?
>
> Hi Wens,
> I'm not sure..I was looking for a clean example of being able to
> override the number of bclks in the lrclk width and some other
> devices(Rpi) were doing it this way.  I open to suggestions,

I'm not familiar with the issue either. If Mark doesn't have any
objections, we could merge it for now, and fix it later if there
are any complications.

BTW, you didn't provide a device tree example (if any) for how
to use this.

ChenYu

> BR,
> CK
>>
>> Thanks
>> ChenYu
>>
>>>  static const struct snd_soc_dai_ops sun4i_i2s_dai_ops = {
>>> .hw_params  = sun4i_i2s_hw_params,
>>> .set_fmt= sun4i_i2s_set_fmt,
>>> @@ -698,6 +716,7 @@ static const struct snd_soc_dai_ops sun4i_i2s_dai_ops = 
>>> {
>>> .shutdown   = sun4i_i2s_shutdown,
>>> .startup= sun4i_i2s_startup,
>>> .trigger= sun4i_i2s_trigger,
>>> +   .set_tdm_slot   = sun4i_i2s_set_dai_tdm_slot,
>>>  };
>>>
>>>  static int sun4i_i2s_dai_probe(struct snd_soc_dai *dai)
>>> --
>>> 2.16.0
>>>
>>> --
>>> You received this message because you are subscribed to the Google Groups 
>>> "linux-sunxi" group.
>>> To unsubscribe from this group and stop receiving emails from it, send an 
>>> email to linux-sunxi+unsubscr...@googlegroups.com.
>>> For more options, visit https://groups.google.com/d/optout.

Re: [linux-sunxi] [PATCH 1/3] ASoC: sun4i-i2s: Add set_tdm_slot functionality

[Chen-Yu Tsai]

On Mon, Jan 29, 2018 at 3:34 PM, Code Kipper  wrote:
> On 29 January 2018 at 02:50, Chen-Yu Tsai  wrote:
>> On Wed, Jan 24, 2018 at 10:10 PM,   wrote:
>>> From: Marcus Cooper 
>>>
>>> Some codecs require a different amount of a bit clocks per frame than
>>> what is calculated by the sample width. Use the tdm slot bindings to
>>> provide this mechanism.
>>>
>>> Signed-off-by: Marcus Cooper 
>>> ---
>>>  sound/soc/sunxi/sun4i-i2s.c | 23 +--
>>>  1 file changed, 21 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/sound/soc/sunxi/sun4i-i2s.c b/sound/soc/sunxi/sun4i-i2s.c
>>> index dca1143c1150..d7a9141514cf 100644
>>> --- a/sound/soc/sunxi/sun4i-i2s.c
>>> +++ b/sound/soc/sunxi/sun4i-i2s.c
>>> @@ -96,6 +96,7 @@
>>>  #define SUN8I_I2S_CTRL_BCLK_OUTBIT(18)
>>>  #define SUN8I_I2S_CTRL_LRCK_OUTBIT(17)
>>>
>>> +#define SUN8I_I2S_FMT0_LRCK_MAX_PERIOD (GENMASK(17, 8) >> 8)
>>>  #define SUN8I_I2S_FMT0_LRCK_PERIOD_MASKGENMASK(17, 8)
>>>  #define SUN8I_I2S_FMT0_LRCK_PERIOD(period) ((period - 1) << 8)
>>>
>>> @@ -193,6 +194,9 @@ struct sun4i_i2s {
>>> struct regmap_field *field_rxchansel;
>>>
>>> const struct sun4i_i2s_quirks   *variant;
>>> +
>>> +   unsigned inttdm_slots;
>>> +   unsigned intslot_width;
>>>  };
>>>
>>>  struct sun4i_i2s_clk_div {
>>> @@ -344,7 +348,7 @@ static int sun4i_i2s_set_clk_rate(struct snd_soc_dai 
>>> *dai,
>>> if (i2s->variant->has_fmt_set_lrck_period)
>>> regmap_update_bits(i2s->regmap, SUN4I_I2S_FMT0_REG,
>>>SUN8I_I2S_FMT0_LRCK_PERIOD_MASK,
>>> -  SUN8I_I2S_FMT0_LRCK_PERIOD(32));
>>> +  SUN8I_I2S_FMT0_LRCK_PERIOD(word_size));
>>>
>>> return 0;
>>>  }
>>> @@ -418,7 +422,8 @@ static int sun4i_i2s_hw_params(struct snd_pcm_substream 
>>> *substream,
>>>sr + i2s->variant->fmt_offset);
>>>
>>> return sun4i_i2s_set_clk_rate(dai, params_rate(params),
>>> - params_width(params));
>>> + i2s->tdm_slots ?
>>> + i2s->slot_width : 
>>> params_width(params));
>>>  }
>>>
>>>  static int sun4i_i2s_set_fmt(struct snd_soc_dai *dai, unsigned int fmt)
>>> @@ -691,6 +696,19 @@ static int sun4i_i2s_set_sysclk(struct snd_soc_dai 
>>> *dai, int clk_id,
>>> return 0;
>>>  }
>>>
>>> +static int sun4i_i2s_set_dai_tdm_slot(struct snd_soc_dai *dai,
>>> +   unsigned int tx_mask, unsigned int rx_mask,
>>> +   int slots, int width)
>>> +{
>>> +   struct sun4i_i2s *i2s = snd_soc_dai_get_drvdata(dai);
>>> +
>>> +   i2s->tdm_slots = slots;
>>> +
>>> +   i2s->slot_width = width;
>>> +
>>> +   return 0;
>>> +}
>>> +
>>
>> IIRC some of the DAI controllers actually support TDM. Would this
>> change conflict with that in the future?
>
> Hi Wens,
> I'm not sure..I was looking for a clean example of being able to
> override the number of bclks in the lrclk width and some other
> devices(Rpi) were doing it this way.  I open to suggestions,

I'm not familiar with the issue either. If Mark doesn't have any
objections, we could merge it for now, and fix it later if there
are any complications.

BTW, you didn't provide a device tree example (if any) for how
to use this.

ChenYu

> BR,
> CK
>>
>> Thanks
>> ChenYu
>>
>>>  static const struct snd_soc_dai_ops sun4i_i2s_dai_ops = {
>>> .hw_params  = sun4i_i2s_hw_params,
>>> .set_fmt= sun4i_i2s_set_fmt,
>>> @@ -698,6 +716,7 @@ static const struct snd_soc_dai_ops sun4i_i2s_dai_ops = 
>>> {
>>> .shutdown   = sun4i_i2s_shutdown,
>>> .startup= sun4i_i2s_startup,
>>> .trigger= sun4i_i2s_trigger,
>>> +   .set_tdm_slot   = sun4i_i2s_set_dai_tdm_slot,
>>>  };
>>>
>>>  static int sun4i_i2s_dai_probe(struct snd_soc_dai *dai)
>>> --
>>> 2.16.0
>>>
>>> --
>>> You received this message because you are subscribed to the Google Groups 
>>> "linux-sunxi" group.
>>> To unsubscribe from this group and stop receiving emails from it, send an 
>>> email to linux-sunxi+unsubscr...@googlegroups.com.
>>> For more options, visit https://groups.google.com/d/optout.

Re: [PATCH v2] of: use hash based search in of_find_node_by_phandle

[Chintan Pandya]

I was curious, so I implemented it. It ends up being similar to Rasmus's
1st suggestion. The difference is we don't try to store all entries, but
rather implement a hash table that doesn't handle collisions. Relying on
the fact that phandles are just linearly allocated from 0, we just mask
the high bits of the phandle to get the index.

I think this is most resourceful way.

Can you try out on your setup and try different
array sizes.

Here are my test results. However, I simply considered overall boot time to
compare different scenarios because profiling of_find_node_by_phandle() in
early boot fails.

Scenarios:
[1] Cache size 1024 + early cache build up [Small change in your cache 
patch,

    see the patch below]
[2] Hash 64 approach[my original v2 patch]
[3] Cache size 64
[4] Cache size 128
[5] Cache size 256
[6] Base build

Result (boot to shell in sec):
[1] 14.292498 14.370994 14.313537 --> 850ms avg gain
[2] 14.340981 14.395900 14.398149 --> 800ms avg gain
[3] 14.546429 14.488783 14.468694 --> 680ms avg gain
[4] 14.506007 14.497487 14.523062 --> 670ms avg gain
[5] 14.671100 14.643344 14.731853 --> 500ms avg gain
[6] 15.263386 15.246155 15.041847 --> 0

Previously reported 400ms gain for [2] was from different set up. These 
tests

and new data is from my own debug set up. When we take any of these patch to
production, result might deviate accordingly.

Chintan Pandya

Patch for the case [1]
<--->

diff --git a/drivers/of/base.c b/drivers/of/base.c
index a0bccb5..671e7cf 100644
--- a/drivers/of/base.c
+++ b/drivers/of/base.c
@@ -1084,6 +1084,8 @@ int of_modalias_node(struct device_node *node, 
char *modalias, int len)

 }
 EXPORT_SYMBOL_GPL(of_modalias_node);

+struct device_node *phandle_cache[PHANDLE_CACHE_SZ];
+
 /**
  * of_find_node_by_phandle - Find a node given a phandle
  * @handle:    phandle of the node to find
@@ -1100,9 +1102,15 @@ struct device_node 
*of_find_node_by_phandle(phandle handle)

    return NULL;

    raw_spin_lock_irqsave(_lock, flags);
-   for_each_of_allnodes(np)
-   if (np->phandle == handle)
-   break;
+   np = phandle_cache[PHANDLE_CACHE_HASH(handle)];
+   if (!np || np->phandle != handle) {
+   for_each_of_allnodes(np)
+   if (np->phandle == handle) {
+ phandle_cache[PHANDLE_CACHE_HASH(handle)] = np;
+   break;
+   }
+
+   }
    of_node_get(np);
    raw_spin_unlock_irqrestore(_lock, flags);
    return np;
diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
index c0914fb..e90a458 100644
--- a/drivers/of/fdt.c
+++ b/drivers/of/fdt.c
@@ -227,6 +227,9 @@ static void populate_properties(const void *blob,
    pprev  = >next;
    }

+   if (!dryrun && np->phandle)
+   phandle_cache[PHANDLE_CACHE_HASH(np->phandle)] = np;
+
    /* With version 0x10 we may not have the name property,
 * recreate it here from the unit name if absent
 */
diff --git a/include/linux/of.h b/include/linux/of.h
index 299aeb1..b1200be 100644
--- a/include/linux/of.h
+++ b/include/linux/of.h
@@ -92,6 +92,10 @@ struct of_phandle_iterator {
    struct device_node *node;
 };

+#define PHANDLE_CACHE_SZ   1024
+#define PHANDLE_CACHE_HASH(x)  ((x) & (PHANDLE_CACHE_SZ - 1))
+extern struct device_node *phandle_cache[PHANDLE_CACHE_SZ];
+
 struct of_reconfig_data {
    struct device_node  *dn;
    struct property *prop;

--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH v2] of: use hash based search in of_find_node_by_phandle

[Chintan Pandya]

I was curious, so I implemented it. It ends up being similar to Rasmus's
1st suggestion. The difference is we don't try to store all entries, but
rather implement a hash table that doesn't handle collisions. Relying on
the fact that phandles are just linearly allocated from 0, we just mask
the high bits of the phandle to get the index.

I think this is most resourceful way.

Can you try out on your setup and try different
array sizes.

Here are my test results. However, I simply considered overall boot time to
compare different scenarios because profiling of_find_node_by_phandle() in
early boot fails.

Scenarios:
[1] Cache size 1024 + early cache build up [Small change in your cache 
patch,

    see the patch below]
[2] Hash 64 approach[my original v2 patch]
[3] Cache size 64
[4] Cache size 128
[5] Cache size 256
[6] Base build

Result (boot to shell in sec):
[1] 14.292498 14.370994 14.313537 --> 850ms avg gain
[2] 14.340981 14.395900 14.398149 --> 800ms avg gain
[3] 14.546429 14.488783 14.468694 --> 680ms avg gain
[4] 14.506007 14.497487 14.523062 --> 670ms avg gain
[5] 14.671100 14.643344 14.731853 --> 500ms avg gain
[6] 15.263386 15.246155 15.041847 --> 0

Previously reported 400ms gain for [2] was from different set up. These 
tests

and new data is from my own debug set up. When we take any of these patch to
production, result might deviate accordingly.

Chintan Pandya

Patch for the case [1]
<--->

diff --git a/drivers/of/base.c b/drivers/of/base.c
index a0bccb5..671e7cf 100644
--- a/drivers/of/base.c
+++ b/drivers/of/base.c
@@ -1084,6 +1084,8 @@ int of_modalias_node(struct device_node *node, 
char *modalias, int len)

 }
 EXPORT_SYMBOL_GPL(of_modalias_node);

+struct device_node *phandle_cache[PHANDLE_CACHE_SZ];
+
 /**
  * of_find_node_by_phandle - Find a node given a phandle
  * @handle:    phandle of the node to find
@@ -1100,9 +1102,15 @@ struct device_node 
*of_find_node_by_phandle(phandle handle)

    return NULL;

    raw_spin_lock_irqsave(_lock, flags);
-   for_each_of_allnodes(np)
-   if (np->phandle == handle)
-   break;
+   np = phandle_cache[PHANDLE_CACHE_HASH(handle)];
+   if (!np || np->phandle != handle) {
+   for_each_of_allnodes(np)
+   if (np->phandle == handle) {
+ phandle_cache[PHANDLE_CACHE_HASH(handle)] = np;
+   break;
+   }
+
+   }
    of_node_get(np);
    raw_spin_unlock_irqrestore(_lock, flags);
    return np;
diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
index c0914fb..e90a458 100644
--- a/drivers/of/fdt.c
+++ b/drivers/of/fdt.c
@@ -227,6 +227,9 @@ static void populate_properties(const void *blob,
    pprev  = >next;
    }

+   if (!dryrun && np->phandle)
+   phandle_cache[PHANDLE_CACHE_HASH(np->phandle)] = np;
+
    /* With version 0x10 we may not have the name property,
 * recreate it here from the unit name if absent
 */
diff --git a/include/linux/of.h b/include/linux/of.h
index 299aeb1..b1200be 100644
--- a/include/linux/of.h
+++ b/include/linux/of.h
@@ -92,6 +92,10 @@ struct of_phandle_iterator {
    struct device_node *node;
 };

+#define PHANDLE_CACHE_SZ   1024
+#define PHANDLE_CACHE_HASH(x)  ((x) & (PHANDLE_CACHE_SZ - 1))
+extern struct device_node *phandle_cache[PHANDLE_CACHE_SZ];
+
 struct of_reconfig_data {
    struct device_node  *dn;
    struct property *prop;

--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [linux-sunxi] [PATCH 1/3] ASoC: sun4i-i2s: Add set_tdm_slot functionality

[Code Kipper]

On 29 January 2018 at 02:50, Chen-Yu Tsai  wrote:
> On Wed, Jan 24, 2018 at 10:10 PM,   wrote:
>> From: Marcus Cooper 
>>
>> Some codecs require a different amount of a bit clocks per frame than
>> what is calculated by the sample width. Use the tdm slot bindings to
>> provide this mechanism.
>>
>> Signed-off-by: Marcus Cooper 
>> ---
>>  sound/soc/sunxi/sun4i-i2s.c | 23 +--
>>  1 file changed, 21 insertions(+), 2 deletions(-)
>>
>> diff --git a/sound/soc/sunxi/sun4i-i2s.c b/sound/soc/sunxi/sun4i-i2s.c
>> index dca1143c1150..d7a9141514cf 100644
>> --- a/sound/soc/sunxi/sun4i-i2s.c
>> +++ b/sound/soc/sunxi/sun4i-i2s.c
>> @@ -96,6 +96,7 @@
>>  #define SUN8I_I2S_CTRL_BCLK_OUTBIT(18)
>>  #define SUN8I_I2S_CTRL_LRCK_OUTBIT(17)
>>
>> +#define SUN8I_I2S_FMT0_LRCK_MAX_PERIOD (GENMASK(17, 8) >> 8)
>>  #define SUN8I_I2S_FMT0_LRCK_PERIOD_MASKGENMASK(17, 8)
>>  #define SUN8I_I2S_FMT0_LRCK_PERIOD(period) ((period - 1) << 8)
>>
>> @@ -193,6 +194,9 @@ struct sun4i_i2s {
>> struct regmap_field *field_rxchansel;
>>
>> const struct sun4i_i2s_quirks   *variant;
>> +
>> +   unsigned inttdm_slots;
>> +   unsigned intslot_width;
>>  };
>>
>>  struct sun4i_i2s_clk_div {
>> @@ -344,7 +348,7 @@ static int sun4i_i2s_set_clk_rate(struct snd_soc_dai 
>> *dai,
>> if (i2s->variant->has_fmt_set_lrck_period)
>> regmap_update_bits(i2s->regmap, SUN4I_I2S_FMT0_REG,
>>SUN8I_I2S_FMT0_LRCK_PERIOD_MASK,
>> -  SUN8I_I2S_FMT0_LRCK_PERIOD(32));
>> +  SUN8I_I2S_FMT0_LRCK_PERIOD(word_size));
>>
>> return 0;
>>  }
>> @@ -418,7 +422,8 @@ static int sun4i_i2s_hw_params(struct snd_pcm_substream 
>> *substream,
>>sr + i2s->variant->fmt_offset);
>>
>> return sun4i_i2s_set_clk_rate(dai, params_rate(params),
>> - params_width(params));
>> + i2s->tdm_slots ?
>> + i2s->slot_width : 
>> params_width(params));
>>  }
>>
>>  static int sun4i_i2s_set_fmt(struct snd_soc_dai *dai, unsigned int fmt)
>> @@ -691,6 +696,19 @@ static int sun4i_i2s_set_sysclk(struct snd_soc_dai 
>> *dai, int clk_id,
>> return 0;
>>  }
>>
>> +static int sun4i_i2s_set_dai_tdm_slot(struct snd_soc_dai *dai,
>> +   unsigned int tx_mask, unsigned int rx_mask,
>> +   int slots, int width)
>> +{
>> +   struct sun4i_i2s *i2s = snd_soc_dai_get_drvdata(dai);
>> +
>> +   i2s->tdm_slots = slots;
>> +
>> +   i2s->slot_width = width;
>> +
>> +   return 0;
>> +}
>> +
>
> IIRC some of the DAI controllers actually support TDM. Would this
> change conflict with that in the future?

Hi Wens,
I'm not sure..I was looking for a clean example of being able to
override the number of bclks in the lrclk width and some other
devices(Rpi) were doing it this way.  I open to suggestions,
BR,
CK
>
> Thanks
> ChenYu
>
>>  static const struct snd_soc_dai_ops sun4i_i2s_dai_ops = {
>> .hw_params  = sun4i_i2s_hw_params,
>> .set_fmt= sun4i_i2s_set_fmt,
>> @@ -698,6 +716,7 @@ static const struct snd_soc_dai_ops sun4i_i2s_dai_ops = {
>> .shutdown   = sun4i_i2s_shutdown,
>> .startup= sun4i_i2s_startup,
>> .trigger= sun4i_i2s_trigger,
>> +   .set_tdm_slot   = sun4i_i2s_set_dai_tdm_slot,
>>  };
>>
>>  static int sun4i_i2s_dai_probe(struct snd_soc_dai *dai)
>> --
>> 2.16.0
>>
>> --
>> You received this message because you are subscribed to the Google Groups 
>> "linux-sunxi" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to linux-sunxi+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.

Re: [linux-sunxi] [PATCH 1/3] ASoC: sun4i-i2s: Add set_tdm_slot functionality

[Code Kipper]

On 29 January 2018 at 02:50, Chen-Yu Tsai  wrote:
> On Wed, Jan 24, 2018 at 10:10 PM,   wrote:
>> From: Marcus Cooper 
>>
>> Some codecs require a different amount of a bit clocks per frame than
>> what is calculated by the sample width. Use the tdm slot bindings to
>> provide this mechanism.
>>
>> Signed-off-by: Marcus Cooper 
>> ---
>>  sound/soc/sunxi/sun4i-i2s.c | 23 +--
>>  1 file changed, 21 insertions(+), 2 deletions(-)
>>
>> diff --git a/sound/soc/sunxi/sun4i-i2s.c b/sound/soc/sunxi/sun4i-i2s.c
>> index dca1143c1150..d7a9141514cf 100644
>> --- a/sound/soc/sunxi/sun4i-i2s.c
>> +++ b/sound/soc/sunxi/sun4i-i2s.c
>> @@ -96,6 +96,7 @@
>>  #define SUN8I_I2S_CTRL_BCLK_OUTBIT(18)
>>  #define SUN8I_I2S_CTRL_LRCK_OUTBIT(17)
>>
>> +#define SUN8I_I2S_FMT0_LRCK_MAX_PERIOD (GENMASK(17, 8) >> 8)
>>  #define SUN8I_I2S_FMT0_LRCK_PERIOD_MASKGENMASK(17, 8)
>>  #define SUN8I_I2S_FMT0_LRCK_PERIOD(period) ((period - 1) << 8)
>>
>> @@ -193,6 +194,9 @@ struct sun4i_i2s {
>> struct regmap_field *field_rxchansel;
>>
>> const struct sun4i_i2s_quirks   *variant;
>> +
>> +   unsigned inttdm_slots;
>> +   unsigned intslot_width;
>>  };
>>
>>  struct sun4i_i2s_clk_div {
>> @@ -344,7 +348,7 @@ static int sun4i_i2s_set_clk_rate(struct snd_soc_dai 
>> *dai,
>> if (i2s->variant->has_fmt_set_lrck_period)
>> regmap_update_bits(i2s->regmap, SUN4I_I2S_FMT0_REG,
>>SUN8I_I2S_FMT0_LRCK_PERIOD_MASK,
>> -  SUN8I_I2S_FMT0_LRCK_PERIOD(32));
>> +  SUN8I_I2S_FMT0_LRCK_PERIOD(word_size));
>>
>> return 0;
>>  }
>> @@ -418,7 +422,8 @@ static int sun4i_i2s_hw_params(struct snd_pcm_substream 
>> *substream,
>>sr + i2s->variant->fmt_offset);
>>
>> return sun4i_i2s_set_clk_rate(dai, params_rate(params),
>> - params_width(params));
>> + i2s->tdm_slots ?
>> + i2s->slot_width : 
>> params_width(params));
>>  }
>>
>>  static int sun4i_i2s_set_fmt(struct snd_soc_dai *dai, unsigned int fmt)
>> @@ -691,6 +696,19 @@ static int sun4i_i2s_set_sysclk(struct snd_soc_dai 
>> *dai, int clk_id,
>> return 0;
>>  }
>>
>> +static int sun4i_i2s_set_dai_tdm_slot(struct snd_soc_dai *dai,
>> +   unsigned int tx_mask, unsigned int rx_mask,
>> +   int slots, int width)
>> +{
>> +   struct sun4i_i2s *i2s = snd_soc_dai_get_drvdata(dai);
>> +
>> +   i2s->tdm_slots = slots;
>> +
>> +   i2s->slot_width = width;
>> +
>> +   return 0;
>> +}
>> +
>
> IIRC some of the DAI controllers actually support TDM. Would this
> change conflict with that in the future?

Hi Wens,
I'm not sure..I was looking for a clean example of being able to
override the number of bclks in the lrclk width and some other
devices(Rpi) were doing it this way.  I open to suggestions,
BR,
CK
>
> Thanks
> ChenYu
>
>>  static const struct snd_soc_dai_ops sun4i_i2s_dai_ops = {
>> .hw_params  = sun4i_i2s_hw_params,
>> .set_fmt= sun4i_i2s_set_fmt,
>> @@ -698,6 +716,7 @@ static const struct snd_soc_dai_ops sun4i_i2s_dai_ops = {
>> .shutdown   = sun4i_i2s_shutdown,
>> .startup= sun4i_i2s_startup,
>> .trigger= sun4i_i2s_trigger,
>> +   .set_tdm_slot   = sun4i_i2s_set_dai_tdm_slot,
>>  };
>>
>>  static int sun4i_i2s_dai_probe(struct snd_soc_dai *dai)
>> --
>> 2.16.0
>>
>> --
>> You received this message because you are subscribed to the Google Groups 
>> "linux-sunxi" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to linux-sunxi+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.

Re: [PATCH v3 1/2] perf stat: Add support to print counts for fixed times

[Jiri Olsa]

On Fri, Jan 26, 2018 at 10:06:56AM +0100, ufo19890607 wrote:

SNIP

> @@ -1891,6 +1902,8 @@ static const struct option stat_options[] = {
>   "command to run after to the measured command"),
>   OPT_UINTEGER('I', "interval-print", _config.interval,
>   "print counts at regular interval in ms (>= 10)"),
> + OPT_INTEGER(0, "interval-count", _config.times,
> + "print counts for fixed number of times"),
>   OPT_SET_UINT(0, "per-socket", _config.aggr_mode,
>"aggregate counts per processor socket", AGGR_SOCKET),
>   OPT_SET_UINT(0, "per-core", _config.aggr_mode,
> @@ -2689,6 +2702,7 @@ int cmd_stat(int argc, const char **argv)
>   const char *mode;
>   FILE *output = stderr;
>   unsigned int interval;
> + int times;
>   const char * const stat_subcommands[] = { "record", "report" };
>  
>   setlocale(LC_ALL, "");
> @@ -2719,6 +2733,7 @@ int cmd_stat(int argc, const char **argv)
>   return __cmd_report(argc, argv);
>  
>   interval = stat_config.interval;
> + times = stat_config.times;
>  
>   /*
>* For record command the -o is already taken care of.
> @@ -2870,6 +2885,15 @@ int cmd_stat(int argc, const char **argv)
>  "The overhead percentage could be high in 
> some cases. "
>  "Please proceed with caution.\n");
>   }
> + if (times && interval)
> + interval_count = true;
> + else if (times && !interval) {

you can use stat_config.times in here, no need for 'times' copy

jirka

> + pr_err("interval-count option should be used together with "
> + "interval-print.\n");
> + parse_options_usage(stat_usage, stat_options, "interval-count", 
> 0);
> + parse_options_usage(stat_usage, stat_options, "I", 1);
> + goto out;
> + }
>  
>   if (perf_evlist__alloc_stats(evsel_list, interval))
>   goto out;
> diff --git a/tools/perf/util/stat.h b/tools/perf/util/stat.h
> index dbc6f7134f61..b2f8a347d358 100644
> --- a/tools/perf/util/stat.h
> +++ b/tools/perf/util/stat.h
> @@ -90,6 +90,7 @@ struct perf_stat_config {
>   boolscale;
>   FILE*output;
>   unsigned intinterval;
> + int times;
>   struct runtime_stat *stats;
>   int stats_num;
>  };
> -- 
> 2.14.1
> 

Re: [PATCH v3 1/2] perf stat: Add support to print counts for fixed times

[Jiri Olsa]

On Fri, Jan 26, 2018 at 10:06:56AM +0100, ufo19890607 wrote:

SNIP

> @@ -1891,6 +1902,8 @@ static const struct option stat_options[] = {
>   "command to run after to the measured command"),
>   OPT_UINTEGER('I', "interval-print", _config.interval,
>   "print counts at regular interval in ms (>= 10)"),
> + OPT_INTEGER(0, "interval-count", _config.times,
> + "print counts for fixed number of times"),
>   OPT_SET_UINT(0, "per-socket", _config.aggr_mode,
>"aggregate counts per processor socket", AGGR_SOCKET),
>   OPT_SET_UINT(0, "per-core", _config.aggr_mode,
> @@ -2689,6 +2702,7 @@ int cmd_stat(int argc, const char **argv)
>   const char *mode;
>   FILE *output = stderr;
>   unsigned int interval;
> + int times;
>   const char * const stat_subcommands[] = { "record", "report" };
>  
>   setlocale(LC_ALL, "");
> @@ -2719,6 +2733,7 @@ int cmd_stat(int argc, const char **argv)
>   return __cmd_report(argc, argv);
>  
>   interval = stat_config.interval;
> + times = stat_config.times;
>  
>   /*
>* For record command the -o is already taken care of.
> @@ -2870,6 +2885,15 @@ int cmd_stat(int argc, const char **argv)
>  "The overhead percentage could be high in 
> some cases. "
>  "Please proceed with caution.\n");
>   }
> + if (times && interval)
> + interval_count = true;
> + else if (times && !interval) {

you can use stat_config.times in here, no need for 'times' copy

jirka

> + pr_err("interval-count option should be used together with "
> + "interval-print.\n");
> + parse_options_usage(stat_usage, stat_options, "interval-count", 
> 0);
> + parse_options_usage(stat_usage, stat_options, "I", 1);
> + goto out;
> + }
>  
>   if (perf_evlist__alloc_stats(evsel_list, interval))
>   goto out;
> diff --git a/tools/perf/util/stat.h b/tools/perf/util/stat.h
> index dbc6f7134f61..b2f8a347d358 100644
> --- a/tools/perf/util/stat.h
> +++ b/tools/perf/util/stat.h
> @@ -90,6 +90,7 @@ struct perf_stat_config {
>   boolscale;
>   FILE*output;
>   unsigned intinterval;
> + int times;
>   struct runtime_stat *stats;
>   int stats_num;
>  };
> -- 
> 2.14.1
> 

Re: [PATCH v3 1/2] perf stat: Add support to print counts for fixed times

[Jiri Olsa]

On Fri, Jan 26, 2018 at 10:06:56AM +0100, ufo19890607 wrote:

SNIP

> --- a/tools/perf/builtin-stat.c
> +++ b/tools/perf/builtin-stat.c
> @@ -168,6 +168,7 @@ static struct timespecref_time;
>  static struct cpu_map*aggr_map;
>  static aggr_get_id_t aggr_get_id;
>  static bool  append_file;
> +static bool  interval_count;
>  static const char*output_name;
>  static int   output_fd;
>  static int   print_free_counters_hint;
> @@ -571,6 +572,7 @@ static struct perf_evsel 
> *perf_evsel__reset_weak_group(struct perf_evsel *evsel)
>  static int __run_perf_stat(int argc, const char **argv)
>  {
>   int interval = stat_config.interval;
> + int times = stat_config.times;
>   char msg[BUFSIZ];
>   unsigned long long t0, t1;
>   struct perf_evsel *counter;
> @@ -700,6 +702,10 @@ static int __run_perf_stat(int argc, const char **argv)
>   while (!waitpid(child_pid, , WNOHANG)) {
>   nanosleep(, NULL);
>   process_interval();
> + if (interval_count == true) {
> + if (--times == 0)
> + break;

why not single line in here?

if (interval_count && !(--times))

> + }
>   }
>   }
>   waitpid(child_pid, , 0);
> @@ -716,8 +722,13 @@ static int __run_perf_stat(int argc, const char **argv)
>   enable_counters();
>   while (!done) {
>   nanosleep(, NULL);
> - if (interval)
> + if (interval) {
>   process_interval();
> + if (interval_count == true) {
> + if (--times == 0)
> + break;

same here

SNIP

>   }
> + if (times && interval)
> + interval_count = true;
> + else if (times && !interval) {
> + pr_err("interval-count option should be used together with "
> + "interval-print.\n");
> + parse_options_usage(stat_usage, stat_options, "interval-count", 
> 0);
> + parse_options_usage(stat_usage, stat_options, "I", 1);
> + goto out;
> + }
>  
>   if (perf_evlist__alloc_stats(evsel_list, interval))
>   goto out;
> diff --git a/tools/perf/util/stat.h b/tools/perf/util/stat.h
> index dbc6f7134f61..b2f8a347d358 100644
> --- a/tools/perf/util/stat.h
> +++ b/tools/perf/util/stat.h
> @@ -90,6 +90,7 @@ struct perf_stat_config {
>   boolscale;
>   FILE*output;
>   unsigned intinterval;
> + int times;

wrong indent

thanks,
jirka

>   struct runtime_stat *stats;
>   int stats_num;
>  };
> -- 
> 2.14.1
> 

Re: [PATCH 1/3] Partial revert "e1000e: Avoid receiver overrun interrupt bursts"

[Benjamin Poirier]

On 2018/01/26 08:50, Alexander Duyck wrote:
> On Fri, Jan 26, 2018 at 1:12 AM, Benjamin Poirier  wrote:
> > This reverts commit 4aea7a5c5e940c1723add439f4088844cd26196d.
> >
> > We keep the fix for the first part of the problem (1) described in the log
> > of that commit however we use the implementation of e1000_msix_other() from
> > before commit 16ecba59bc33 ("e1000e: Do not read ICR in Other interrupt").
> > We remove the fix for the second part of the problem (2).
> >
> > Bursts of "Other" interrupts may once again occur during rxo (receive
> > overflow) traffic conditions. This is deemed acceptable in the interest of
> > reverting driver code back to its previous state. The e1000e driver should
> > be in "maintenance" mode and we want to avoid unforeseen fallout from
> > changes that are not strictly necessary.
> >
> > Link: https://www.spinics.net/lists/netdev/msg480675.html
> > Signed-off-by: Benjamin Poirier 
> 
> Thanks for doing this.
> 
> Only a few minor tweaks I would recommend. Otherwise it looks good.
> 
> > ---
> >  drivers/net/ethernet/intel/e1000e/defines.h |  1 -
> >  drivers/net/ethernet/intel/e1000e/netdev.c  | 32 
> > +++--
> >  2 files changed, 12 insertions(+), 21 deletions(-)
> >
> > diff --git a/drivers/net/ethernet/intel/e1000e/defines.h 
> > b/drivers/net/ethernet/intel/e1000e/defines.h
> > index afb7ebe20b24..0641c0098738 100644
> > --- a/drivers/net/ethernet/intel/e1000e/defines.h
> > +++ b/drivers/net/ethernet/intel/e1000e/defines.h
> > @@ -398,7 +398,6 @@
> >  #define E1000_ICR_LSC   0x0004 /* Link Status Change */
> >  #define E1000_ICR_RXSEQ 0x0008 /* Rx sequence error */
> >  #define E1000_ICR_RXDMT00x0010 /* Rx desc min. threshold (0) */
> > -#define E1000_ICR_RXO   0x0040 /* Receiver Overrun */
> >  #define E1000_ICR_RXT0  0x0080 /* Rx timer intr (ring 0) */
> >  #define E1000_ICR_ECCER 0x0040 /* Uncorrectable ECC Error */
> >  /* If this bit asserted, the driver should claim the interrupt */
> > diff --git a/drivers/net/ethernet/intel/e1000e/netdev.c 
> > b/drivers/net/ethernet/intel/e1000e/netdev.c
> > index 9f18d39bdc8f..398e940436f8 100644
> > --- a/drivers/net/ethernet/intel/e1000e/netdev.c
> > +++ b/drivers/net/ethernet/intel/e1000e/netdev.c
> > @@ -1914,30 +1914,23 @@ static irqreturn_t e1000_msix_other(int 
> > __always_unused irq, void *data)
> > struct net_device *netdev = data;
> > struct e1000_adapter *adapter = netdev_priv(netdev);
> > struct e1000_hw *hw = >hw;
> > -   u32 icr;
> > -   bool enable = true;
> > -
> > -   icr = er32(ICR);
> > -   if (icr & E1000_ICR_RXO) {
> > -   ew32(ICR, E1000_ICR_RXO);
> > -   enable = false;
> > -   /* napi poll will re-enable Other, make sure it runs */
> > -   if (napi_schedule_prep(>napi)) {
> > -   adapter->total_rx_bytes = 0;
> > -   adapter->total_rx_packets = 0;
> > -   __napi_schedule(>napi);
> > -   }
> > -   }
> > -   if (icr & E1000_ICR_LSC) {
> > -   ew32(ICR, E1000_ICR_LSC);
> > +   u32 icr = er32(ICR);
> > +
> > +   if (icr & adapter->eiac_mask)
> > +   ew32(ICS, (icr & adapter->eiac_mask));
> 
> I'm not sure about this bit as it includes queue interrupts if I am
> not mistaken. What we should be focusing on are the bits that are not
> auto-cleared so this should probably be icr & ~adapter->eiac_mask.
> Actually what you might do is something like:
> icr &= ~adapter->eiac_mask;
> if (icr)
> ew32(ICS, icr);
> 
> Also a comment explaining that we have to clear the bits that are not
> automatically cleared by other interrupt causes might be useful.

I've re-read your comment many times and I think you misunderstood what
that code is doing.

This:
> > +   if (icr & adapter->eiac_mask)
> > +   ew32(ICS, (icr & adapter->eiac_mask));

re-raises the queue interrupts in case the txq or rxq bits were set in
icr and the Other interrupt handler read and cleared icr before the
queue interrupt was raised. It's not about "clear the bits that are not
automatically cleared". It's a write to ICS, not ICR.

> 
> > +   if (icr & E1000_ICR_OTHER) {
> > +   if (!(icr & E1000_ICR_LSC))
> > +   goto no_link_interrupt;
> 
> I wouldn't bother with the jump tag. Let's just make this one if
> statement checking both OTHER && LSC.
> 
> > hw->mac.get_link_status = true;
> > /* guard against interrupt when we're going down */
> > if (!test_bit(__E1000_DOWN, >state))
> > mod_timer(>watchdog_timer, jiffies + 1);
> > }
> >
> > -   if (enable && !test_bit(__E1000_DOWN, >state))
> > -   ew32(IMS, E1000_IMS_OTHER);
> > +no_link_interrupt:
> 
> If you 

Re: [PATCH 1/3] Partial revert "e1000e: Avoid receiver overrun interrupt bursts"

[Benjamin Poirier]

On 2018/01/26 08:50, Alexander Duyck wrote:
> On Fri, Jan 26, 2018 at 1:12 AM, Benjamin Poirier  wrote:
> > This reverts commit 4aea7a5c5e940c1723add439f4088844cd26196d.
> >
> > We keep the fix for the first part of the problem (1) described in the log
> > of that commit however we use the implementation of e1000_msix_other() from
> > before commit 16ecba59bc33 ("e1000e: Do not read ICR in Other interrupt").
> > We remove the fix for the second part of the problem (2).
> >
> > Bursts of "Other" interrupts may once again occur during rxo (receive
> > overflow) traffic conditions. This is deemed acceptable in the interest of
> > reverting driver code back to its previous state. The e1000e driver should
> > be in "maintenance" mode and we want to avoid unforeseen fallout from
> > changes that are not strictly necessary.
> >
> > Link: https://www.spinics.net/lists/netdev/msg480675.html
> > Signed-off-by: Benjamin Poirier 
> 
> Thanks for doing this.
> 
> Only a few minor tweaks I would recommend. Otherwise it looks good.
> 
> > ---
> >  drivers/net/ethernet/intel/e1000e/defines.h |  1 -
> >  drivers/net/ethernet/intel/e1000e/netdev.c  | 32 
> > +++--
> >  2 files changed, 12 insertions(+), 21 deletions(-)
> >
> > diff --git a/drivers/net/ethernet/intel/e1000e/defines.h 
> > b/drivers/net/ethernet/intel/e1000e/defines.h
> > index afb7ebe20b24..0641c0098738 100644
> > --- a/drivers/net/ethernet/intel/e1000e/defines.h
> > +++ b/drivers/net/ethernet/intel/e1000e/defines.h
> > @@ -398,7 +398,6 @@
> >  #define E1000_ICR_LSC   0x0004 /* Link Status Change */
> >  #define E1000_ICR_RXSEQ 0x0008 /* Rx sequence error */
> >  #define E1000_ICR_RXDMT00x0010 /* Rx desc min. threshold (0) */
> > -#define E1000_ICR_RXO   0x0040 /* Receiver Overrun */
> >  #define E1000_ICR_RXT0  0x0080 /* Rx timer intr (ring 0) */
> >  #define E1000_ICR_ECCER 0x0040 /* Uncorrectable ECC Error */
> >  /* If this bit asserted, the driver should claim the interrupt */
> > diff --git a/drivers/net/ethernet/intel/e1000e/netdev.c 
> > b/drivers/net/ethernet/intel/e1000e/netdev.c
> > index 9f18d39bdc8f..398e940436f8 100644
> > --- a/drivers/net/ethernet/intel/e1000e/netdev.c
> > +++ b/drivers/net/ethernet/intel/e1000e/netdev.c
> > @@ -1914,30 +1914,23 @@ static irqreturn_t e1000_msix_other(int 
> > __always_unused irq, void *data)
> > struct net_device *netdev = data;
> > struct e1000_adapter *adapter = netdev_priv(netdev);
> > struct e1000_hw *hw = >hw;
> > -   u32 icr;
> > -   bool enable = true;
> > -
> > -   icr = er32(ICR);
> > -   if (icr & E1000_ICR_RXO) {
> > -   ew32(ICR, E1000_ICR_RXO);
> > -   enable = false;
> > -   /* napi poll will re-enable Other, make sure it runs */
> > -   if (napi_schedule_prep(>napi)) {
> > -   adapter->total_rx_bytes = 0;
> > -   adapter->total_rx_packets = 0;
> > -   __napi_schedule(>napi);
> > -   }
> > -   }
> > -   if (icr & E1000_ICR_LSC) {
> > -   ew32(ICR, E1000_ICR_LSC);
> > +   u32 icr = er32(ICR);
> > +
> > +   if (icr & adapter->eiac_mask)
> > +   ew32(ICS, (icr & adapter->eiac_mask));
> 
> I'm not sure about this bit as it includes queue interrupts if I am
> not mistaken. What we should be focusing on are the bits that are not
> auto-cleared so this should probably be icr & ~adapter->eiac_mask.
> Actually what you might do is something like:
> icr &= ~adapter->eiac_mask;
> if (icr)
> ew32(ICS, icr);
> 
> Also a comment explaining that we have to clear the bits that are not
> automatically cleared by other interrupt causes might be useful.

I've re-read your comment many times and I think you misunderstood what
that code is doing.

This:
> > +   if (icr & adapter->eiac_mask)
> > +   ew32(ICS, (icr & adapter->eiac_mask));

re-raises the queue interrupts in case the txq or rxq bits were set in
icr and the Other interrupt handler read and cleared icr before the
queue interrupt was raised. It's not about "clear the bits that are not
automatically cleared". It's a write to ICS, not ICR.

> 
> > +   if (icr & E1000_ICR_OTHER) {
> > +   if (!(icr & E1000_ICR_LSC))
> > +   goto no_link_interrupt;
> 
> I wouldn't bother with the jump tag. Let's just make this one if
> statement checking both OTHER && LSC.
> 
> > hw->mac.get_link_status = true;
> > /* guard against interrupt when we're going down */
> > if (!test_bit(__E1000_DOWN, >state))
> > mod_timer(>watchdog_timer, jiffies + 1);
> > }
> >
> > -   if (enable && !test_bit(__E1000_DOWN, >state))
> > -   ew32(IMS, E1000_IMS_OTHER);
> > +no_link_interrupt:
> 
> If you just combine the if statement logic the 

Re: [PATCH v3 1/2] perf stat: Add support to print counts for fixed times

[Jiri Olsa]

On Fri, Jan 26, 2018 at 10:06:56AM +0100, ufo19890607 wrote:

SNIP

> --- a/tools/perf/builtin-stat.c
> +++ b/tools/perf/builtin-stat.c
> @@ -168,6 +168,7 @@ static struct timespecref_time;
>  static struct cpu_map*aggr_map;
>  static aggr_get_id_t aggr_get_id;
>  static bool  append_file;
> +static bool  interval_count;
>  static const char*output_name;
>  static int   output_fd;
>  static int   print_free_counters_hint;
> @@ -571,6 +572,7 @@ static struct perf_evsel 
> *perf_evsel__reset_weak_group(struct perf_evsel *evsel)
>  static int __run_perf_stat(int argc, const char **argv)
>  {
>   int interval = stat_config.interval;
> + int times = stat_config.times;
>   char msg[BUFSIZ];
>   unsigned long long t0, t1;
>   struct perf_evsel *counter;
> @@ -700,6 +702,10 @@ static int __run_perf_stat(int argc, const char **argv)
>   while (!waitpid(child_pid, , WNOHANG)) {
>   nanosleep(, NULL);
>   process_interval();
> + if (interval_count == true) {
> + if (--times == 0)
> + break;

why not single line in here?

if (interval_count && !(--times))

> + }
>   }
>   }
>   waitpid(child_pid, , 0);
> @@ -716,8 +722,13 @@ static int __run_perf_stat(int argc, const char **argv)
>   enable_counters();
>   while (!done) {
>   nanosleep(, NULL);
> - if (interval)
> + if (interval) {
>   process_interval();
> + if (interval_count == true) {
> + if (--times == 0)
> + break;

same here

SNIP

>   }
> + if (times && interval)
> + interval_count = true;
> + else if (times && !interval) {
> + pr_err("interval-count option should be used together with "
> + "interval-print.\n");
> + parse_options_usage(stat_usage, stat_options, "interval-count", 
> 0);
> + parse_options_usage(stat_usage, stat_options, "I", 1);
> + goto out;
> + }
>  
>   if (perf_evlist__alloc_stats(evsel_list, interval))
>   goto out;
> diff --git a/tools/perf/util/stat.h b/tools/perf/util/stat.h
> index dbc6f7134f61..b2f8a347d358 100644
> --- a/tools/perf/util/stat.h
> +++ b/tools/perf/util/stat.h
> @@ -90,6 +90,7 @@ struct perf_stat_config {
>   boolscale;
>   FILE*output;
>   unsigned intinterval;
> + int times;

wrong indent

thanks,
jirka

>   struct runtime_stat *stats;
>   int stats_num;
>  };
> -- 
> 2.14.1
> 

Re: [RFC PATCH V5 5/5] workqueue: introduce a way to set workqueue's scheduler

[Mike Galbraith]

On Mon, 2018-01-29 at 14:33 +0800, Lai Jiangshan wrote:
> On Mon, Jan 29, 2018 at 12:41 PM, Mike Galbraith  wrote:
> > On Mon, 2018-01-29 at 12:15 +0800, Lai Jiangshan wrote:
> >> I think adding priority boost to workqueue(flush_work()) is the best
> >> way to fix the problem.
> >
> > I disagree, priority boosting is needlessly invasive, takes control out
> > of user hands.  The kernel wanting to run a workqueue does not justify
> > perturbing the user's critical task.
> 
> The kworkers doesn't belong to any user, it is really needlessly invasive
> if we give the ability to any user to control the priority of the kworkers.

In a scenario where box is being saturated by RT, every last bit of the
box is likely in the (hopefully capable) hands of a solo box pilot.
 With a prio-boosting scheme, which user gets to choose the boost
priority for the global resource?
 
> If the user's critical task calls flush_work(). the critical task should
> boost one responsible kworker. (the kwoker scheduled for
> the work item, or the first idle kworker or the manager kworker,
> the kwoker for the later two cases is changing, need to migrate
> the boosting to a new kworker when needed)
> 
> The boosted work items need to be moved to a prio list in the pool
> too for the boosted kworker to pick it up.

Userspace knows which of its actions are wired up to what kernel
mechanism?  New workers are never spawned, stepping on any
prioritization userspace does?

I don't want to argue about it really, I'm just expressing my opinion
on the matter.  I have a mechanism in place to let users safely do
whatever they like, have for years, and it's not going anywhere.  That
mechanism was born from the needs of users, not mine.  First came a
user with a long stable product that suddenly ceased to function due to
workqueues learning to spawn new threads, then came a few cases where
users were absolutely convinced that they really really did need to be
able to safely saturate.  I could have said tough titty, adapt your
product to use a dedicated kthread to the one, and no you just think
you need to do that to the others, but I'm not (quite) that arrogant,
gave them the control they wanted instead.

-Mike

Re: [RFC PATCH V5 5/5] workqueue: introduce a way to set workqueue's scheduler

[Mike Galbraith]

On Mon, 2018-01-29 at 14:33 +0800, Lai Jiangshan wrote:
> On Mon, Jan 29, 2018 at 12:41 PM, Mike Galbraith  wrote:
> > On Mon, 2018-01-29 at 12:15 +0800, Lai Jiangshan wrote:
> >> I think adding priority boost to workqueue(flush_work()) is the best
> >> way to fix the problem.
> >
> > I disagree, priority boosting is needlessly invasive, takes control out
> > of user hands.  The kernel wanting to run a workqueue does not justify
> > perturbing the user's critical task.
> 
> The kworkers doesn't belong to any user, it is really needlessly invasive
> if we give the ability to any user to control the priority of the kworkers.

In a scenario where box is being saturated by RT, every last bit of the
box is likely in the (hopefully capable) hands of a solo box pilot.
 With a prio-boosting scheme, which user gets to choose the boost
priority for the global resource?
 
> If the user's critical task calls flush_work(). the critical task should
> boost one responsible kworker. (the kwoker scheduled for
> the work item, or the first idle kworker or the manager kworker,
> the kwoker for the later two cases is changing, need to migrate
> the boosting to a new kworker when needed)
> 
> The boosted work items need to be moved to a prio list in the pool
> too for the boosted kworker to pick it up.

Userspace knows which of its actions are wired up to what kernel
mechanism?  New workers are never spawned, stepping on any
prioritization userspace does?

I don't want to argue about it really, I'm just expressing my opinion
on the matter.  I have a mechanism in place to let users safely do
whatever they like, have for years, and it's not going anywhere.  That
mechanism was born from the needs of users, not mine.  First came a
user with a long stable product that suddenly ceased to function due to
workqueues learning to spawn new threads, then came a few cases where
users were absolutely convinced that they really really did need to be
able to safely saturate.  I could have said tough titty, adapt your
product to use a dedicated kthread to the one, and no you just think
you need to do that to the others, but I'm not (quite) that arrogant,
gave them the control they wanted instead.

-Mike

Re: [netfilter-core] kernel panic: Out of memory and no killable processes... (2)

[Florian Westphal]

Tetsuo Handa  wrote:
> syzbot wrote:
> > syzbot hit the following crash on net-next commit
> > 6bb46bc57c8e9ce947cc605e555b7204b44d2b10 (Fri Jan 26 16:00:23 2018 +)
> > Merge branch 'cxgb4-fix-dump-collection-when-firmware-crashed'
> > 
> > C reproducer is attached.
> > syzkaller reproducer is attached.
> > Raw console output is attached.
> > compiler: gcc (GCC) 7.1.1 20170620
> > .config is attached.
> > 
> > IMPORTANT: if you fix the bug, please add the following tag to the commit:
> > Reported-by: syzbot+8630e35fc7287b392...@syzkaller.appspotmail.com
> > It will help syzbot understand when the bug is fixed. See footer for  
> > details.
> > If you forward the report, please keep this part and the footer.
> > 
> > [ 3685] 0  3685178211   1843200 0 sshd
> > [ 3692] 0  3692 43760327680 0  
> > syzkaller025682
> > [ 3695] 0  3695 43760368640 0  
> > syzkaller025682
> > Kernel panic - not syncing: Out of memory and no killable processes...
> > 
> 
> This sounds like too huge vmalloc() request where size is controlled by 
> userspace.

Right.

Before eacd86ca3b036e55e172b7279f101cef4a6ff3a4
this used 

  info = __vmalloc(sz, GFP_KERNEL | __GFP_NOWARN | __GFP_NORETRY,

would it help to re-add that?

> vmalloc() once became killable by commit 5d17a73a2ebeb8d1 ("vmalloc: back
> off when the current task is killed") but then became unkillable by commit
> b8c8a338f75e052d ("Revert "vmalloc: back off when the current task is
> killed""). Therefore, we can't handle this problem from MM side.
> Please consider adding some limit from networking side.

I don't know what "some limit" would be.  I would prefer if there was
a way to supress OOM Killer in first place so we can just -ENOMEM user.

AFAIU NOWARN|NORETRY does that, so I would propose to just read-add it?

Re: [netfilter-core] kernel panic: Out of memory and no killable processes... (2)

[Florian Westphal]

Tetsuo Handa  wrote:
> syzbot wrote:
> > syzbot hit the following crash on net-next commit
> > 6bb46bc57c8e9ce947cc605e555b7204b44d2b10 (Fri Jan 26 16:00:23 2018 +)
> > Merge branch 'cxgb4-fix-dump-collection-when-firmware-crashed'
> > 
> > C reproducer is attached.
> > syzkaller reproducer is attached.
> > Raw console output is attached.
> > compiler: gcc (GCC) 7.1.1 20170620
> > .config is attached.
> > 
> > IMPORTANT: if you fix the bug, please add the following tag to the commit:
> > Reported-by: syzbot+8630e35fc7287b392...@syzkaller.appspotmail.com
> > It will help syzbot understand when the bug is fixed. See footer for  
> > details.
> > If you forward the report, please keep this part and the footer.
> > 
> > [ 3685] 0  3685178211   1843200 0 sshd
> > [ 3692] 0  3692 43760327680 0  
> > syzkaller025682
> > [ 3695] 0  3695 43760368640 0  
> > syzkaller025682
> > Kernel panic - not syncing: Out of memory and no killable processes...
> > 
> 
> This sounds like too huge vmalloc() request where size is controlled by 
> userspace.

Right.

Before eacd86ca3b036e55e172b7279f101cef4a6ff3a4
this used 

  info = __vmalloc(sz, GFP_KERNEL | __GFP_NOWARN | __GFP_NORETRY,

would it help to re-add that?

> vmalloc() once became killable by commit 5d17a73a2ebeb8d1 ("vmalloc: back
> off when the current task is killed") but then became unkillable by commit
> b8c8a338f75e052d ("Revert "vmalloc: back off when the current task is
> killed""). Therefore, we can't handle this problem from MM side.
> Please consider adding some limit from networking side.

I don't know what "some limit" would be.  I would prefer if there was
a way to supress OOM Killer in first place so we can just -ENOMEM user.

AFAIU NOWARN|NORETRY does that, so I would propose to just read-add it?

RE: [PATCH] USB TYPEC: RT1711H Type-C Chip Driver

[李書帆]

Hi Guenter,

  We try to use the TCPCI driver on RT1711H and here are some questions.

  Q1. Is current TCPCI driver written according to TypeC Port Controller 
Interface Specification Revision 1.0 & Version 1.2?
  Q2. Because 0x80~0xFF are vendor defined registers. Some of them are needed 
to be initialized in tcpci_init for RT1711H (or other chips also).
In the future TCPCI driver, will an initial interface that is called in 
tcpci_init be released for different vendors to implement.
Or, we should directly copy tcpci.c to tcpci_rt1711h.c and add the different 
parts?
  Q3. If there are IRQs defined in vendor defined registers, will an interface 
that is called in tcpci_irq be released for different vendors to implement.
So that they can handle their own IRQs first?
If the suggestion of Q2 is to copy tcpci.c to tcpci_rt1711h.c, then Q3 will not 
be a problem.
  Q4. According to TCPCI Specification Revision 1.0, we should set DRP = 1 and 
role to Rp/Rp or Rd/Rd and set LOOK4CONNECTION command to start toggle.
So we modify the tcpci_start_drp_toggling in TCPCI driver as following. Here we 
write Rd/Rd and DRP = 0 simultaneously so that Rd/Rd takes effect.
Then we write DRP = 1 and set LOOK4CONNECTION command to start toggling.

static int tcpci_start_drp_toggling(struct tcpc_dev *tcpc,
 enum typec_cc_status cc)
 {
+int ret = 0;
 struct tcpci *tcpci = tcpc_to_tcpci(tcpc);
-unsigned int reg = TCPC_ROLE_CTRL_DRP;
+u32 reg = (TCPC_ROLE_CTRL_CC_RD << TCPC_ROLE_CTRL_CC1_SHIFT) |
+(TCPC_ROLE_CTRL_CC_RD << TCPC_ROLE_CTRL_CC2_SHIFT);

 switch (cc) {
 default:
@@ -125,8 +672,19 @@ static int tcpci_start_drp_toggling(stru
 TCPC_ROLE_CTRL_RP_VAL_SHIFT);
 break;
 }
-
-return regmap_write(tcpci->regmap, TCPC_ROLE_CTRL, reg);
+ret = regmap_write(tcpci->regmap, TCPC_ROLE_CTRL, reg);
+if (ret < 0)
+return ret;
+mdelay(1);
+reg |= TCPC_ROLE_CTRL_DRP;
+ret = regmap_write(tcpci->regmap, TCPC_ROLE_CTRL, reg);
+if (ret < 0)
+return ret;
+ret = regmap_write(tcpci->regmap, TCPC_COMMAND,
+TCPC_CMD_LOOK4CONNECTION);
+if (ret < 0)
+return ret;
+return 0;
 }

  Q5. The tcpci_set_vbus in TCPCI driver uses command to control Sink/Source 
VBUS.
If our chip does not support power path, i.e. Sink & Source are controlled by 
other charger IC. Our chip will do nothing while setting these commands.
In the future TCPCI driver, will a framework be applied to notify these events. 
i.g. power_supply or notifier.

Best Regards,
*
Shu-Fan Lee
Richtek Technology Corporation
TEL: +886-3-5526789 #2359
FAX: +886-3-5526612
*

-Original Message-
From: Guenter Roeck [mailto:groe...@gmail.com] On Behalf Of Guenter Roeck
Sent: Tuesday, January 23, 2018 2:51 AM
To: shufan_lee(李書帆)
Cc: Heikki Krogerus; 'Jun Li'; ShuFanLee; cy_huang(黃啟原); 
linux-kernel@vger.kernel.org; linux-...@vger.kernel.org
Subject: Re: [PATCH] USB TYPEC: RT1711H Type-C Chip Driver

On Mon, Jan 22, 2018 at 02:01:13AM +, shufan_lee(李書帆) wrote:
> Dear Heikki and Guenter,
>
>   Because there are still other controls of RT1711H that are different from 
> standard TCPCI, e.x. flow of drp toggling.
>
>   Is the suggestion to customize the difference based on tcpci.c for RT1711H?
>

In general, I would say yes. However, I won't have ime to review the 
differences between tcpci and the RT1711H. On a high level, if RT1711H claims 
to suport TCPCI, it should use (or, rather, extend) the TCPCI driver.

Note that the TCPCI driver does not claim to be complete; there is a reason why 
it is still in staging. However, I would prefer if new devices claiming to 
support TCPCI would use it instead of going their own way. I don't have 
problems extending it with chip specific details if needed. Such extensions may 
be implemented in tcpci.c, or maybe better in a chip specific file.

Even if you don't use the existing driver, I don't really see why it would make 
sense to redeclare all its defines.

Either case, you might want to run checkpatch --strict on your driver. Most of 
that it reports is really unnecessary.
Also, some of the code, such as

+#ifndef BIT
+#define BIT(x) (1 << (x))
+#endif

is _really_ odd and, at least in this case, simply wrong.

Guenter

> Best Regards,
> *
> Shu-Fan Lee
> Richtek Technology Corporation
> TEL: +886-3-5526789 #2359
> FAX: +886-3-5526612
> *
>
> -Original Message-
> From: Guenter Roeck [mailto:groe...@gmail.com] On Behalf Of Guenter
> Roeck
> Sent: Saturday, January 20, 2018 12:03 AM
> To: Heikki Krogerus
> Cc: shufan_lee(李書帆); 'Jun Li'; ShuFanLee; cy_huang(黃啟原);
> linux-kernel@vger.kernel.org; linux-...@vger.kernel.org
> Subject: Re: [PATCH] USB TYPEC: RT1711H Type-C Chip Driver
>
> On Fri, Jan 19, 2018 at 11:24:13AM +0200, Heikki Krogerus wrote:
> > Hi,
> >
> > On Fri, Jan 19, 2018 at 09:01:24AM +, shufan_lee(?|) wrote:
> > > Hi Heikki,
> > >
> > >   For example, the flow of tcpci_init is a little bit different.
> > >   In 

RE: [PATCH] USB TYPEC: RT1711H Type-C Chip Driver

[李書帆]

Hi Guenter,

  We try to use the TCPCI driver on RT1711H and here are some questions.

  Q1. Is current TCPCI driver written according to TypeC Port Controller 
Interface Specification Revision 1.0 & Version 1.2?
  Q2. Because 0x80~0xFF are vendor defined registers. Some of them are needed 
to be initialized in tcpci_init for RT1711H (or other chips also).
In the future TCPCI driver, will an initial interface that is called in 
tcpci_init be released for different vendors to implement.
Or, we should directly copy tcpci.c to tcpci_rt1711h.c and add the different 
parts?
  Q3. If there are IRQs defined in vendor defined registers, will an interface 
that is called in tcpci_irq be released for different vendors to implement.
So that they can handle their own IRQs first?
If the suggestion of Q2 is to copy tcpci.c to tcpci_rt1711h.c, then Q3 will not 
be a problem.
  Q4. According to TCPCI Specification Revision 1.0, we should set DRP = 1 and 
role to Rp/Rp or Rd/Rd and set LOOK4CONNECTION command to start toggle.
So we modify the tcpci_start_drp_toggling in TCPCI driver as following. Here we 
write Rd/Rd and DRP = 0 simultaneously so that Rd/Rd takes effect.
Then we write DRP = 1 and set LOOK4CONNECTION command to start toggling.

static int tcpci_start_drp_toggling(struct tcpc_dev *tcpc,
 enum typec_cc_status cc)
 {
+int ret = 0;
 struct tcpci *tcpci = tcpc_to_tcpci(tcpc);
-unsigned int reg = TCPC_ROLE_CTRL_DRP;
+u32 reg = (TCPC_ROLE_CTRL_CC_RD << TCPC_ROLE_CTRL_CC1_SHIFT) |
+(TCPC_ROLE_CTRL_CC_RD << TCPC_ROLE_CTRL_CC2_SHIFT);

 switch (cc) {
 default:
@@ -125,8 +672,19 @@ static int tcpci_start_drp_toggling(stru
 TCPC_ROLE_CTRL_RP_VAL_SHIFT);
 break;
 }
-
-return regmap_write(tcpci->regmap, TCPC_ROLE_CTRL, reg);
+ret = regmap_write(tcpci->regmap, TCPC_ROLE_CTRL, reg);
+if (ret < 0)
+return ret;
+mdelay(1);
+reg |= TCPC_ROLE_CTRL_DRP;
+ret = regmap_write(tcpci->regmap, TCPC_ROLE_CTRL, reg);
+if (ret < 0)
+return ret;
+ret = regmap_write(tcpci->regmap, TCPC_COMMAND,
+TCPC_CMD_LOOK4CONNECTION);
+if (ret < 0)
+return ret;
+return 0;
 }

  Q5. The tcpci_set_vbus in TCPCI driver uses command to control Sink/Source 
VBUS.
If our chip does not support power path, i.e. Sink & Source are controlled by 
other charger IC. Our chip will do nothing while setting these commands.
In the future TCPCI driver, will a framework be applied to notify these events. 
i.g. power_supply or notifier.

Best Regards,
*
Shu-Fan Lee
Richtek Technology Corporation
TEL: +886-3-5526789 #2359
FAX: +886-3-5526612
*

-Original Message-
From: Guenter Roeck [mailto:groe...@gmail.com] On Behalf Of Guenter Roeck
Sent: Tuesday, January 23, 2018 2:51 AM
To: shufan_lee(李書帆)
Cc: Heikki Krogerus; 'Jun Li'; ShuFanLee; cy_huang(黃啟原); 
linux-kernel@vger.kernel.org; linux-...@vger.kernel.org
Subject: Re: [PATCH] USB TYPEC: RT1711H Type-C Chip Driver

On Mon, Jan 22, 2018 at 02:01:13AM +, shufan_lee(李書帆) wrote:
> Dear Heikki and Guenter,
>
>   Because there are still other controls of RT1711H that are different from 
> standard TCPCI, e.x. flow of drp toggling.
>
>   Is the suggestion to customize the difference based on tcpci.c for RT1711H?
>

In general, I would say yes. However, I won't have ime to review the 
differences between tcpci and the RT1711H. On a high level, if RT1711H claims 
to suport TCPCI, it should use (or, rather, extend) the TCPCI driver.

Note that the TCPCI driver does not claim to be complete; there is a reason why 
it is still in staging. However, I would prefer if new devices claiming to 
support TCPCI would use it instead of going their own way. I don't have 
problems extending it with chip specific details if needed. Such extensions may 
be implemented in tcpci.c, or maybe better in a chip specific file.

Even if you don't use the existing driver, I don't really see why it would make 
sense to redeclare all its defines.

Either case, you might want to run checkpatch --strict on your driver. Most of 
that it reports is really unnecessary.
Also, some of the code, such as

+#ifndef BIT
+#define BIT(x) (1 << (x))
+#endif

is _really_ odd and, at least in this case, simply wrong.

Guenter

> Best Regards,
> *
> Shu-Fan Lee
> Richtek Technology Corporation
> TEL: +886-3-5526789 #2359
> FAX: +886-3-5526612
> *
>
> -Original Message-
> From: Guenter Roeck [mailto:groe...@gmail.com] On Behalf Of Guenter
> Roeck
> Sent: Saturday, January 20, 2018 12:03 AM
> To: Heikki Krogerus
> Cc: shufan_lee(李書帆); 'Jun Li'; ShuFanLee; cy_huang(黃啟原);
> linux-kernel@vger.kernel.org; linux-...@vger.kernel.org
> Subject: Re: [PATCH] USB TYPEC: RT1711H Type-C Chip Driver
>
> On Fri, Jan 19, 2018 at 11:24:13AM +0200, Heikki Krogerus wrote:
> > Hi,
> >
> > On Fri, Jan 19, 2018 at 09:01:24AM +, shufan_lee(?|) wrote:
> > > Hi Heikki,
> > >
> > >   For example, the flow of tcpci_init is a little bit different.
> > >   In 

Re: [PATCH v3 char-misc 1/1] Drivers: hv: vmbus: Implement Direct Mode for stimer0

[Greg KH]

On Sun, Jan 28, 2018 at 09:06:48PM +, Michael Kelley (EOSG) wrote:
> From: Michael Kelley 
> 
> The 2016 version of Hyper-V offers the option to operate the guest VM
> per-vcpu stimer's in Direct Mode, which means the timer interupts on its
> own vector rather than queueing a VMbus message. Direct Mode reduces
> timer processing overhead in both the hypervisor and the guest, and
> avoids having timer interrupts pollute the VMbus interrupt stream for
> the synthetic NIC and storage.  This patch enables Direct Mode by
> default on stimer0 when running on a version of Hyper-V that supports it,
> with a hv_vmbus module parameter for disabling Direct Mode and reverting
> to the old behavior.

You didn't change the text here as there is no more module parameter :(

> --- a/drivers/hv/hv.c
> +++ b/drivers/hv/hv.c
> @@ -27,8 +27,9 @@
>  #include 
>  #include 
>  #include 
> -#include 
> +#include 
>  #include 
> +#include 

Still need this .h file?

thanks,

greg k-h

Re: [PATCH v3 char-misc 1/1] Drivers: hv: vmbus: Implement Direct Mode for stimer0

[Greg KH]

On Sun, Jan 28, 2018 at 09:06:48PM +, Michael Kelley (EOSG) wrote:
> From: Michael Kelley 
> 
> The 2016 version of Hyper-V offers the option to operate the guest VM
> per-vcpu stimer's in Direct Mode, which means the timer interupts on its
> own vector rather than queueing a VMbus message. Direct Mode reduces
> timer processing overhead in both the hypervisor and the guest, and
> avoids having timer interrupts pollute the VMbus interrupt stream for
> the synthetic NIC and storage.  This patch enables Direct Mode by
> default on stimer0 when running on a version of Hyper-V that supports it,
> with a hv_vmbus module parameter for disabling Direct Mode and reverting
> to the old behavior.

You didn't change the text here as there is no more module parameter :(

> --- a/drivers/hv/hv.c
> +++ b/drivers/hv/hv.c
> @@ -27,8 +27,9 @@
>  #include 
>  #include 
>  #include 
> -#include 
> +#include 
>  #include 
> +#include 

Still need this .h file?

thanks,

greg k-h

Re: [PATCH 1/2] tools lib symbol: Use strtoul instead of hex2u64 in kallsyms__parse

[Jiri Olsa]

On Fri, Jan 26, 2018 at 07:27:06PM +0200, Andy Shevchenko wrote:
> On Fri, Jan 26, 2018 at 7:22 PM, Andy Shevchenko
>  wrote:
> > On Fri, Jan 19, 2018 at 6:11 PM, Jiri Olsa  wrote:
> >> Current kallsyms__parse uses hex2u64, which gives
> >> no indication of error. Using strtoul to checkup
> >> on failed attempt to parse the number and stop the
> >> rest of the kallsyms__parse processing early.
> >
> >> +   start = strtoul(line, , 16);
> >> +   if (line == endptr)
> >> +   continue;
> >> +
> >> +   len = endptr - line + 1;
> >>
> >> -   len++;
> >> if (len + 2 >= line_len)
> >> continue;
> >
> > https://patchwork.kernel.org/patch/4087681/
> 
> Even second attempt including recent ping left without consideration.
> 
> http://lkml.iu.edu/hypermail/linux/kernel/1407.0/02791.html

I see, sry we overlooked it.. could you please repost it?

thanks,
jirka

Re: [PATCH 1/2] tools lib symbol: Use strtoul instead of hex2u64 in kallsyms__parse

[Jiri Olsa]

On Fri, Jan 26, 2018 at 07:27:06PM +0200, Andy Shevchenko wrote:
> On Fri, Jan 26, 2018 at 7:22 PM, Andy Shevchenko
>  wrote:
> > On Fri, Jan 19, 2018 at 6:11 PM, Jiri Olsa  wrote:
> >> Current kallsyms__parse uses hex2u64, which gives
> >> no indication of error. Using strtoul to checkup
> >> on failed attempt to parse the number and stop the
> >> rest of the kallsyms__parse processing early.
> >
> >> +   start = strtoul(line, , 16);
> >> +   if (line == endptr)
> >> +   continue;
> >> +
> >> +   len = endptr - line + 1;
> >>
> >> -   len++;
> >> if (len + 2 >= line_len)
> >> continue;
> >
> > https://patchwork.kernel.org/patch/4087681/
> 
> Even second attempt including recent ping left without consideration.
> 
> http://lkml.iu.edu/hypermail/linux/kernel/1407.0/02791.html

I see, sry we overlooked it.. could you please repost it?

thanks,
jirka

Re: [PATCH net-next 00/12] ptr_ring fixes

[Jason Wang]

On 2018年01月26日 07:36, Michael S. Tsirkin wrote:

This fixes a bunch of issues around ptr_ring use in net core.
One of these: "tap: fix use-after-free" is also needed on net,
but can't be backported cleanly.

I will post a net patch separately.

Lightly tested - Jason, could you pls confirm this
addresses the security issue you saw with ptr_ring?
Testing reports would be appreciated too.

Michael S. Tsirkin (12):
   ptr_ring: keep consumer_head valid at all times
   ptr_ring: clean up documentation
   ptr_ring: READ/WRITE_ONCE for __ptr_ring_empty
   tap: fix use-after-free
   ptr_ring: disallow lockless __ptr_ring_full
   Revert "net: ptr_ring: otherwise safe empty checks can overrun array
 bounds"
   skb_array: use __ptr_ring_empty
   ptr_ring: prevent queue load/store tearing
   tools/virtio: switch to __ptr_ring_empty
   tools/virtio: more stubs to fix tools build
   tools/virtio: copy READ/WRITE_ONCE
   tools/virtio: fix smp_mb on x86

  drivers/net/tap.c|  3 --
  include/linux/ptr_ring.h | 86 ++--
  include/linux/skb_array.h|  2 +-
  tools/virtio/linux/kernel.h  |  2 +-
  tools/virtio/linux/thread_info.h |  1 +
  tools/virtio/ringtest/main.h | 59 ++-
  tools/virtio/ringtest/ptr_ring.c |  2 +-
  7 files changed, 110 insertions(+), 45 deletions(-)
  create mode 100644 tools/virtio/linux/thread_info.h



For the series:

Tested-by: Jason Wang 
Acked-by: Jason Wang 

Thanks

Re: [PATCH net-next 00/12] ptr_ring fixes

[Jason Wang]

On 2018年01月26日 07:36, Michael S. Tsirkin wrote:

This fixes a bunch of issues around ptr_ring use in net core.
One of these: "tap: fix use-after-free" is also needed on net,
but can't be backported cleanly.

I will post a net patch separately.

Lightly tested - Jason, could you pls confirm this
addresses the security issue you saw with ptr_ring?
Testing reports would be appreciated too.

Michael S. Tsirkin (12):
   ptr_ring: keep consumer_head valid at all times
   ptr_ring: clean up documentation
   ptr_ring: READ/WRITE_ONCE for __ptr_ring_empty
   tap: fix use-after-free
   ptr_ring: disallow lockless __ptr_ring_full
   Revert "net: ptr_ring: otherwise safe empty checks can overrun array
 bounds"
   skb_array: use __ptr_ring_empty
   ptr_ring: prevent queue load/store tearing
   tools/virtio: switch to __ptr_ring_empty
   tools/virtio: more stubs to fix tools build
   tools/virtio: copy READ/WRITE_ONCE
   tools/virtio: fix smp_mb on x86

  drivers/net/tap.c|  3 --
  include/linux/ptr_ring.h | 86 ++--
  include/linux/skb_array.h|  2 +-
  tools/virtio/linux/kernel.h  |  2 +-
  tools/virtio/linux/thread_info.h |  1 +
  tools/virtio/ringtest/main.h | 59 ++-
  tools/virtio/ringtest/ptr_ring.c |  2 +-
  7 files changed, 110 insertions(+), 45 deletions(-)
  create mode 100644 tools/virtio/linux/thread_info.h



For the series:

Tested-by: Jason Wang 
Acked-by: Jason Wang 

Thanks

Re: [PATCH net-next 05/12] ptr_ring: disallow lockless __ptr_ring_full

[Jason Wang]

On 2018年01月29日 12:41, Michael S. Tsirkin wrote:

On Mon, Jan 29, 2018 at 11:36:09AM +0800, Jason Wang wrote:


On 2018年01月26日 10:46, Michael S. Tsirkin wrote:

On 2018年01月26日 07:36, Michael S. Tsirkin wrote:

Similar to bcecb4bbf88a ("net: ptr_ring: otherwise safe empty checks can
overrun array bounds") a lockless use of __ptr_ring_full might
cause an out of bounds access.

We can fix this, but it's easier to just disallow lockless
__ptr_ring_full for now.

It looks to me that just fix this is better than disallow through doc (which
is easily to be ignored ...).

Thanks

lockless is tricky, and I'd rather not sprinkle READ/WRITE_ONCE where
they aren't necessary.


The problem is then API looks a little bit strange. Lockless were only
allowed to be done at __ptr_ring_empty() but not __ptr_ring_full().

Thanks

So __ptr_ring_empty doesn't really work lockless. It merely does not crash.
I don't believe we can do anything to remove the need to read the
docs unless people use the safe non __ variants.



Ok, then I will ack the series.

Thanks

Re: [PATCH net-next 05/12] ptr_ring: disallow lockless __ptr_ring_full

[Jason Wang]

On 2018年01月29日 12:41, Michael S. Tsirkin wrote:

On Mon, Jan 29, 2018 at 11:36:09AM +0800, Jason Wang wrote:


On 2018年01月26日 10:46, Michael S. Tsirkin wrote:

On 2018年01月26日 07:36, Michael S. Tsirkin wrote:

Similar to bcecb4bbf88a ("net: ptr_ring: otherwise safe empty checks can
overrun array bounds") a lockless use of __ptr_ring_full might
cause an out of bounds access.

We can fix this, but it's easier to just disallow lockless
__ptr_ring_full for now.

It looks to me that just fix this is better than disallow through doc (which
is easily to be ignored ...).

Thanks

lockless is tricky, and I'd rather not sprinkle READ/WRITE_ONCE where
they aren't necessary.


The problem is then API looks a little bit strange. Lockless were only
allowed to be done at __ptr_ring_empty() but not __ptr_ring_full().

Thanks

So __ptr_ring_empty doesn't really work lockless. It merely does not crash.
I don't believe we can do anything to remove the need to read the
docs unless people use the safe non __ variants.



Ok, then I will ack the series.

Thanks

Re: [GIT PULL tools] Linux kernel memory model

[Ingo Molnar]

hi Paul,

* Paul E. McKenney  wrote:

> Hello, Ingo,
> 
> This pull request contains a single commit that adds a memory model to
> the tools directory.  This memory model can (roughly speaking) be thought
> of as an automated version of memory-barriers.txt.  It is written in the
> "cat" language, which is executable by the externally provided "herd7"
> simulator, which exhaustively explores the state space of small litmus
> tests.
> 
> This memory model is accompanied by extensive documentation on its use
> and its design.  Two versions have been sent to LKML and feedback
> incorporated:
> 
> 1.http://lkml.kernel.org/r/20171113184031.ga26...@linux.vnet.ibm.com
> 2.http://lkml.kernel.org/r/20180119035855.ga29...@linux.vnet.ibm.com
> 
> This model has been presented and demoed at a number of Linux gatherings,
> including the 2016 LinuxCon EU, the 2016 Linux Plumbers Conference,
> the 2016 Linux Kernel Summit, the 2017 linux.conf.au, and the 2017 Linux
> Plumbers Conference, which featured a workshop helping a number of Linux
> kernel hackers install and use the tool.
> 
> This memory model has matured to the point where it would be good to include
> it in the Linux kernel, for example, to allow it to track changes as new
> hardware and use cases are added.  We expect the rate of change to be similar
> to that of Documentation/memory-barriers.txt.
> 
> This memory model is available in the git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git 
> 
> for you to fetch changes up to 1c27b644c0fdbc61e113b8faee14baeb8df32486:
> 
>   Automate memory-barriers.txt; provide Linux-kernel memory model (2018-01-24 
> 20:53:49 -0800)

Looks good to me, but the commit is not in the master branch of your tree, 
which 
branch should I pull?

Thanks,

Ingo

Re: [GIT PULL tools] Linux kernel memory model

[Ingo Molnar]

hi Paul,

* Paul E. McKenney  wrote:

> Hello, Ingo,
> 
> This pull request contains a single commit that adds a memory model to
> the tools directory.  This memory model can (roughly speaking) be thought
> of as an automated version of memory-barriers.txt.  It is written in the
> "cat" language, which is executable by the externally provided "herd7"
> simulator, which exhaustively explores the state space of small litmus
> tests.
> 
> This memory model is accompanied by extensive documentation on its use
> and its design.  Two versions have been sent to LKML and feedback
> incorporated:
> 
> 1.http://lkml.kernel.org/r/20171113184031.ga26...@linux.vnet.ibm.com
> 2.http://lkml.kernel.org/r/20180119035855.ga29...@linux.vnet.ibm.com
> 
> This model has been presented and demoed at a number of Linux gatherings,
> including the 2016 LinuxCon EU, the 2016 Linux Plumbers Conference,
> the 2016 Linux Kernel Summit, the 2017 linux.conf.au, and the 2017 Linux
> Plumbers Conference, which featured a workshop helping a number of Linux
> kernel hackers install and use the tool.
> 
> This memory model has matured to the point where it would be good to include
> it in the Linux kernel, for example, to allow it to track changes as new
> hardware and use cases are added.  We expect the rate of change to be similar
> to that of Documentation/memory-barriers.txt.
> 
> This memory model is available in the git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git 
> 
> for you to fetch changes up to 1c27b644c0fdbc61e113b8faee14baeb8df32486:
> 
>   Automate memory-barriers.txt; provide Linux-kernel memory model (2018-01-24 
> 20:53:49 -0800)

Looks good to me, but the commit is not in the master branch of your tree, 
which 
branch should I pull?

Thanks,

Ingo

Re: [PATCH] auxdisplay: charlcd: delete mdelay in long_sleep

[Willy Tarreau]

Hi,

On Fri, Jan 26, 2018 at 11:19:15PM +0800, Jia-Ju Bai wrote:
> The function long_sleep() calls mdelay() when in an interrupt handler.
> But only charlcd_clear_display() and charlcd_init_display calls 
> long_sleep(), and my tool finds that the two functions 
> are never called in an interrupt handler.
> Thus mdelay() and in_interrupt() are not necessary.
> 
> This is found by a static analysis tool named DCNS written by myself.

Looks good. This code is extremely old (started in 2.2) so I'm not
surprised at all that after many changes such parts are not used
anymore.

Acked-by: Willy Tarreau 

Willy

Re: [PATCH] auxdisplay: charlcd: delete mdelay in long_sleep

[Willy Tarreau]

Hi,

On Fri, Jan 26, 2018 at 11:19:15PM +0800, Jia-Ju Bai wrote:
> The function long_sleep() calls mdelay() when in an interrupt handler.
> But only charlcd_clear_display() and charlcd_init_display calls 
> long_sleep(), and my tool finds that the two functions 
> are never called in an interrupt handler.
> Thus mdelay() and in_interrupt() are not necessary.
> 
> This is found by a static analysis tool named DCNS written by myself.

Looks good. This code is extremely old (started in 2.2) so I'm not
surprised at all that after many changes such parts are not used
anymore.

Acked-by: Willy Tarreau 

Willy

[PATCH v2] dmaengine: dmatest: fix container_of member in dmatest_callback

[Yang Shunyong]

The type of arg passed to dmatest_callback is struct dmatest_done.
It refers to test_done in struct dmatest_thread, not done_wait.

Fixes: 6f6a23a213be ("dmaengine: dmatest: move callback wait ...")
Signed-off-by: Yang Shunyong 
Signed-off-by: Vinod Koul 
---

v2: change arg to done in container_of().

---
 drivers/dma/dmatest.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/dma/dmatest.c b/drivers/dma/dmatest.c
index ec5f9d2bc820..80cc2be6483c 100644
--- a/drivers/dma/dmatest.c
+++ b/drivers/dma/dmatest.c
@@ -355,7 +355,7 @@ static void dmatest_callback(void *arg)
 {
struct dmatest_done *done = arg;
struct dmatest_thread *thread =
-   container_of(arg, struct dmatest_thread, done_wait);
+   container_of(done, struct dmatest_thread, test_done);
if (!thread->done) {
done->done = true;
wake_up_all(done->wait);
-- 
1.8.3.1

[PATCH v2] dmaengine: dmatest: fix container_of member in dmatest_callback

[Yang Shunyong]

The type of arg passed to dmatest_callback is struct dmatest_done.
It refers to test_done in struct dmatest_thread, not done_wait.

Fixes: 6f6a23a213be ("dmaengine: dmatest: move callback wait ...")
Signed-off-by: Yang Shunyong 
Signed-off-by: Vinod Koul 
---

v2: change arg to done in container_of().

---
 drivers/dma/dmatest.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/dma/dmatest.c b/drivers/dma/dmatest.c
index ec5f9d2bc820..80cc2be6483c 100644
--- a/drivers/dma/dmatest.c
+++ b/drivers/dma/dmatest.c
@@ -355,7 +355,7 @@ static void dmatest_callback(void *arg)
 {
struct dmatest_done *done = arg;
struct dmatest_thread *thread =
-   container_of(arg, struct dmatest_thread, done_wait);
+   container_of(done, struct dmatest_thread, test_done);
if (!thread->done) {
done->done = true;
wake_up_all(done->wait);
-- 
1.8.3.1

Re: [PATCH v1] mm: hwpoison: disable memory error handling on 1GB hugepage

[Naoya Horiguchi]

My apology, I forgot to CC to the mailing lists.

On Mon, Jan 29, 2018 at 03:28:03PM +0900, Naoya Horiguchi wrote:
> Recently the following BUG was reported:
> 
> Injecting memory failure for pfn 0x3c at process virtual address 
> 0x7fe3
> Memory failure: 0x3c: recovery action for huge page: Recovered
> BUG: unable to handle kernel paging request at 8dfcc0003000
> IP: gup_pgd_range+0x1f0/0xc20
> PGD 17ae72067 P4D 17ae72067 PUD 0
> Oops:  [#1] SMP PTI
> ...
> CPU: 3 PID: 5467 Comm: hugetlb_1gb Not tainted 4.15.0-rc8-mm1-abc+ #3
> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.9.3-1.fc25 
> 04/01/2014
> 
> You can easily reproduce this by calling madvise(MADV_HWPOISON) twice on
> a 1GB hugepage. This happens because get_user_pages_fast() is not aware
> of a migration entry on pud that was created in the 1st madvise() event.
> 
> I think that conversion to pud-aligned migration entry is working,
> but other MM code walking over page table isn't prepared for it.
> We need some time and effort to make all this work properly, so
> this patch avoids the reported bug by just disabling error handling
> for 1GB hugepage.
> 
> Signed-off-by: Naoya Horiguchi 
> ---
>  include/linux/mm.h  | 1 +
>  mm/memory-failure.c | 7 +++
>  2 files changed, 8 insertions(+)
> 
> diff --git v4.15-rc8-mmotm-2018-01-18-16-31/include/linux/mm.h 
> v4.15-rc8-mmotm-2018-01-18-16-31_patched/include/linux/mm.h
> index 63f7ba1..166864e 100644
> --- v4.15-rc8-mmotm-2018-01-18-16-31/include/linux/mm.h
> +++ v4.15-rc8-mmotm-2018-01-18-16-31_patched/include/linux/mm.h
> @@ -2607,6 +2607,7 @@ enum mf_action_page_type {
>   MF_MSG_POISONED_HUGE,
>   MF_MSG_HUGE,
>   MF_MSG_FREE_HUGE,
> + MF_MSG_GIGANTIC,
>   MF_MSG_UNMAP_FAILED,
>   MF_MSG_DIRTY_SWAPCACHE,
>   MF_MSG_CLEAN_SWAPCACHE,
> diff --git v4.15-rc8-mmotm-2018-01-18-16-31/mm/memory-failure.c 
> v4.15-rc8-mmotm-2018-01-18-16-31_patched/mm/memory-failure.c
> index d530ac1..c497588 100644
> --- v4.15-rc8-mmotm-2018-01-18-16-31/mm/memory-failure.c
> +++ v4.15-rc8-mmotm-2018-01-18-16-31_patched/mm/memory-failure.c
> @@ -508,6 +508,7 @@ static const char * const action_page_types[] = {
>   [MF_MSG_POISONED_HUGE]  = "huge page already hardware poisoned",
>   [MF_MSG_HUGE]   = "huge page",
>   [MF_MSG_FREE_HUGE]  = "free huge page",
> + [MF_MSG_GIGANTIC]   = "gigantic page",
>   [MF_MSG_UNMAP_FAILED]   = "unmapping failed page",
>   [MF_MSG_DIRTY_SWAPCACHE]= "dirty swapcache page",
>   [MF_MSG_CLEAN_SWAPCACHE]= "clean swapcache page",
> @@ -1090,6 +1091,12 @@ static int memory_failure_hugetlb(unsigned long pfn, 
> int trapno, int flags)
>   return 0;
>   }
>  
> + if (hstate_is_gigantic(page_hstate(head))) {
> + action_result(pfn, MF_MSG_GIGANTIC, MF_IGNORED);
> + res = -EBUSY;
> + goto out;
> + }
> +
>   if (!hwpoison_user_mappings(p, pfn, trapno, flags, )) {
>   action_result(pfn, MF_MSG_UNMAP_FAILED, MF_IGNORED);
>   res = -EBUSY;
> -- 
> 2.7.0
> 
> 

Re: [PATCH v1] mm: hwpoison: disable memory error handling on 1GB hugepage

[Naoya Horiguchi]

My apology, I forgot to CC to the mailing lists.

On Mon, Jan 29, 2018 at 03:28:03PM +0900, Naoya Horiguchi wrote:
> Recently the following BUG was reported:
> 
> Injecting memory failure for pfn 0x3c at process virtual address 
> 0x7fe3
> Memory failure: 0x3c: recovery action for huge page: Recovered
> BUG: unable to handle kernel paging request at 8dfcc0003000
> IP: gup_pgd_range+0x1f0/0xc20
> PGD 17ae72067 P4D 17ae72067 PUD 0
> Oops:  [#1] SMP PTI
> ...
> CPU: 3 PID: 5467 Comm: hugetlb_1gb Not tainted 4.15.0-rc8-mm1-abc+ #3
> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.9.3-1.fc25 
> 04/01/2014
> 
> You can easily reproduce this by calling madvise(MADV_HWPOISON) twice on
> a 1GB hugepage. This happens because get_user_pages_fast() is not aware
> of a migration entry on pud that was created in the 1st madvise() event.
> 
> I think that conversion to pud-aligned migration entry is working,
> but other MM code walking over page table isn't prepared for it.
> We need some time and effort to make all this work properly, so
> this patch avoids the reported bug by just disabling error handling
> for 1GB hugepage.
> 
> Signed-off-by: Naoya Horiguchi 
> ---
>  include/linux/mm.h  | 1 +
>  mm/memory-failure.c | 7 +++
>  2 files changed, 8 insertions(+)
> 
> diff --git v4.15-rc8-mmotm-2018-01-18-16-31/include/linux/mm.h 
> v4.15-rc8-mmotm-2018-01-18-16-31_patched/include/linux/mm.h
> index 63f7ba1..166864e 100644
> --- v4.15-rc8-mmotm-2018-01-18-16-31/include/linux/mm.h
> +++ v4.15-rc8-mmotm-2018-01-18-16-31_patched/include/linux/mm.h
> @@ -2607,6 +2607,7 @@ enum mf_action_page_type {
>   MF_MSG_POISONED_HUGE,
>   MF_MSG_HUGE,
>   MF_MSG_FREE_HUGE,
> + MF_MSG_GIGANTIC,
>   MF_MSG_UNMAP_FAILED,
>   MF_MSG_DIRTY_SWAPCACHE,
>   MF_MSG_CLEAN_SWAPCACHE,
> diff --git v4.15-rc8-mmotm-2018-01-18-16-31/mm/memory-failure.c 
> v4.15-rc8-mmotm-2018-01-18-16-31_patched/mm/memory-failure.c
> index d530ac1..c497588 100644
> --- v4.15-rc8-mmotm-2018-01-18-16-31/mm/memory-failure.c
> +++ v4.15-rc8-mmotm-2018-01-18-16-31_patched/mm/memory-failure.c
> @@ -508,6 +508,7 @@ static const char * const action_page_types[] = {
>   [MF_MSG_POISONED_HUGE]  = "huge page already hardware poisoned",
>   [MF_MSG_HUGE]   = "huge page",
>   [MF_MSG_FREE_HUGE]  = "free huge page",
> + [MF_MSG_GIGANTIC]   = "gigantic page",
>   [MF_MSG_UNMAP_FAILED]   = "unmapping failed page",
>   [MF_MSG_DIRTY_SWAPCACHE]= "dirty swapcache page",
>   [MF_MSG_CLEAN_SWAPCACHE]= "clean swapcache page",
> @@ -1090,6 +1091,12 @@ static int memory_failure_hugetlb(unsigned long pfn, 
> int trapno, int flags)
>   return 0;
>   }
>  
> + if (hstate_is_gigantic(page_hstate(head))) {
> + action_result(pfn, MF_MSG_GIGANTIC, MF_IGNORED);
> + res = -EBUSY;
> + goto out;
> + }
> +
>   if (!hwpoison_user_mappings(p, pfn, trapno, flags, )) {
>   action_result(pfn, MF_MSG_UNMAP_FAILED, MF_IGNORED);
>   res = -EBUSY;
> -- 
> 2.7.0
> 
> 

Re: [RFC 04/10] x86/mm: Only flush indirect branches when switching into non dumpable process

[Jon Masters]

Hi Peter, David, all,

First a quick note on David's earlier comment, about this optimization
being still up for debate. The problem with this optimization as-is is
that it doesn't protect userspace-to-userspace unless applications are
rebuilt and we get the infrastructure to handle that (ELF, whatever).

But...

On 01/21/2018 06:22 AM, Peter Zijlstra wrote:
> On Sat, Jan 20, 2018 at 08:22:55PM +0100, KarimAllah Ahmed wrote:
>> From: Tim Chen 
>>
>> Flush indirect branches when switching into a process that marked
>> itself non dumpable.  This protects high value processes like gpg
>> better, without having too high performance overhead.
> 
> So if I understand it right, this is only needed if the 'other'
> executable itself is susceptible to spectre. If say someone audited gpg
> for spectre-v1 and build it with retpoline, it would be safe to not
> issue the IBPB, right?

More importantly, rebuilding the world introduces a lot of challenges
that need to be discussed heavily before they happen (I would like to
see someone run a session at one of the various upcoming events on
userspace, I've already prodded a few people to nudge that forward). In
particular, we don't have the infrastructure in gcc/glibc to dynamically
patch userspace call sites to enable/disable retpolines.

We discussed nasty hacks last year (I even suggested an ugly kernel
exported page similar to VDSO that could be implementation patched for
different uarches), but the bottom line is there isn't anything in place
to provide a similar userspace experience to what the kernel can do, and
that would need to be solved in addition to the ELF/ABI bits.

> So would it make sense to provide an ELF flag / personality thing such
> that userspace can indicate its spectre-safe?
> 
> I realize that this is all future work, because so far auditing for v1
> is a lot of pain (we need better tools), but would it be something that
> makes sense in the longer term?

So I would just caution that doing this isn't necessarily bad, but it's
far more than just ELF bits and rebuilding. Once userspace is rebuilt
with un-nopable retpolines, they're there whether you need them on
$future_hardware or not, and that fancy branch predictor is useless. So
we really need a way to allow for userspace patchable calls, or at least
some kind of plan before everyone runs away with rebuilding.

(unless they're embedded/Gentoo/whatever...have fun in that case)

Jon.

P.S. This is why for certain downstream distros you'll see IBPB use like
prior to this patch - it'll prevent certain attacks that can't be
otherwise mitigated without going and properly solving the tools issue.

Re: [RFC 04/10] x86/mm: Only flush indirect branches when switching into non dumpable process

[Jon Masters]

Hi Peter, David, all,

First a quick note on David's earlier comment, about this optimization
being still up for debate. The problem with this optimization as-is is
that it doesn't protect userspace-to-userspace unless applications are
rebuilt and we get the infrastructure to handle that (ELF, whatever).

But...

On 01/21/2018 06:22 AM, Peter Zijlstra wrote:
> On Sat, Jan 20, 2018 at 08:22:55PM +0100, KarimAllah Ahmed wrote:
>> From: Tim Chen 
>>
>> Flush indirect branches when switching into a process that marked
>> itself non dumpable.  This protects high value processes like gpg
>> better, without having too high performance overhead.
> 
> So if I understand it right, this is only needed if the 'other'
> executable itself is susceptible to spectre. If say someone audited gpg
> for spectre-v1 and build it with retpoline, it would be safe to not
> issue the IBPB, right?

More importantly, rebuilding the world introduces a lot of challenges
that need to be discussed heavily before they happen (I would like to
see someone run a session at one of the various upcoming events on
userspace, I've already prodded a few people to nudge that forward). In
particular, we don't have the infrastructure in gcc/glibc to dynamically
patch userspace call sites to enable/disable retpolines.

We discussed nasty hacks last year (I even suggested an ugly kernel
exported page similar to VDSO that could be implementation patched for
different uarches), but the bottom line is there isn't anything in place
to provide a similar userspace experience to what the kernel can do, and
that would need to be solved in addition to the ELF/ABI bits.

> So would it make sense to provide an ELF flag / personality thing such
> that userspace can indicate its spectre-safe?
> 
> I realize that this is all future work, because so far auditing for v1
> is a lot of pain (we need better tools), but would it be something that
> makes sense in the longer term?

So I would just caution that doing this isn't necessarily bad, but it's
far more than just ELF bits and rebuilding. Once userspace is rebuilt
with un-nopable retpolines, they're there whether you need them on
$future_hardware or not, and that fancy branch predictor is useless. So
we really need a way to allow for userspace patchable calls, or at least
some kind of plan before everyone runs away with rebuilding.

(unless they're embedded/Gentoo/whatever...have fun in that case)

Jon.

P.S. This is why for certain downstream distros you'll see IBPB use like
prior to this patch - it'll prevent certain attacks that can't be
otherwise mitigated without going and properly solving the tools issue.

Re: [RFC PATCH V5 5/5] workqueue: introduce a way to set workqueue's scheduler

[Lai Jiangshan]

On Mon, Jan 29, 2018 at 12:41 PM, Mike Galbraith  wrote:
> On Mon, 2018-01-29 at 12:15 +0800, Lai Jiangshan wrote:
>> I think adding priority boost to workqueue(flush_work()) is the best
>> way to fix the problem.
>
> I disagree, priority boosting is needlessly invasive, takes control out
> of user hands.  The kernel wanting to run a workqueue does not justify
> perturbing the user's critical task.

The kworkers doesn't belong to any user, it is really needlessly invasive
if we give the ability to any user to control the priority of the kworkers.

If the user's critical task calls flush_work(). the critical task should
boost one responsible kworker. (the kwoker scheduled for
the work item, or the first idle kworker or the manager kworker,
the kwoker for the later two cases is changing, need to migrate
the boosting to a new kworker when needed)

The boosted work items need to be moved to a prio list in the pool
too for the boosted kworker to pick it up.

>
> I think "give userspace rope" is always the best option, how rope is
> used is none of our business.  Giving the user a means to draw a simple
> line in the sand, above which they run only critical stuff, below
> which, they can do whatever they want, sane in our opinions or not,
> lets users do whatever craziness they want/need to do, and puts the
> responsibility for consequences squarely on the right set of shoulders.
>
> -Mike

Re: [RFC PATCH V5 5/5] workqueue: introduce a way to set workqueue's scheduler

[Lai Jiangshan]

On Mon, Jan 29, 2018 at 12:41 PM, Mike Galbraith  wrote:
> On Mon, 2018-01-29 at 12:15 +0800, Lai Jiangshan wrote:
>> I think adding priority boost to workqueue(flush_work()) is the best
>> way to fix the problem.
>
> I disagree, priority boosting is needlessly invasive, takes control out
> of user hands.  The kernel wanting to run a workqueue does not justify
> perturbing the user's critical task.

The kworkers doesn't belong to any user, it is really needlessly invasive
if we give the ability to any user to control the priority of the kworkers.

If the user's critical task calls flush_work(). the critical task should
boost one responsible kworker. (the kwoker scheduled for
the work item, or the first idle kworker or the manager kworker,
the kwoker for the later two cases is changing, need to migrate
the boosting to a new kworker when needed)

The boosted work items need to be moved to a prio list in the pool
too for the boosted kworker to pick it up.

>
> I think "give userspace rope" is always the best option, how rope is
> used is none of our business.  Giving the user a means to draw a simple
> line in the sand, above which they run only critical stuff, below
> which, they can do whatever they want, sane in our opinions or not,
> lets users do whatever craziness they want/need to do, and puts the
> responsibility for consequences squarely on the right set of shoulders.
>
> -Mike

Re: 答复: Re: [RFC PATCH V5 5/5] workqueue: introduce a way to setworkqueue's scheduler

[Mike Galbraith]

On Mon, 2018-01-29 at 13:50 +0800, wen.yan...@zte.com.cn wrote:
> 
> > What happens when a new kworker needs to be spawned?
> create_worker -> worker_attach_to_pool, in the function
> worker_attach_to_pool，  we add this chunk:
> 
> --- a/kernel/workqueue.c
> +++ b/kernel/workqueue.c
> @@ -1699,6 +1699,7 @@ static void worker_attach_to_pool(struct worker *worker,
>          * online CPUs.  It'll be re-applied when any of the CPUs come up.
>          */
>         set_cpus_allowed_ptr(worker->task, pool->attrs->cpumask);
> +       sched_setattr(worker->task, >attrs->sched_attr);
>  
>         /*
>          * The pool->attach_mutex ensures %POOL_DISASSOCIATED remains
>    
> pool->attach_mutex may guarante it, add  sched_setattr may apply the
> wq's sched_attr to the spawned kworer.

That doesn't help kthreadd get to a CPU in a box being saturated by RT.

As long as you are careful, it's not a problem, I just mentioned it
because it's a hole.

-Mike

Re: 答复: Re: [RFC PATCH V5 5/5] workqueue: introduce a way to setworkqueue's scheduler

[Mike Galbraith]

On Mon, 2018-01-29 at 13:50 +0800, wen.yan...@zte.com.cn wrote:
> 
> > What happens when a new kworker needs to be spawned?
> create_worker -> worker_attach_to_pool, in the function
> worker_attach_to_pool，  we add this chunk:
> 
> --- a/kernel/workqueue.c
> +++ b/kernel/workqueue.c
> @@ -1699,6 +1699,7 @@ static void worker_attach_to_pool(struct worker *worker,
>          * online CPUs.  It'll be re-applied when any of the CPUs come up.
>          */
>         set_cpus_allowed_ptr(worker->task, pool->attrs->cpumask);
> +       sched_setattr(worker->task, >attrs->sched_attr);
>  
>         /*
>          * The pool->attach_mutex ensures %POOL_DISASSOCIATED remains
>    
> pool->attach_mutex may guarante it, add  sched_setattr may apply the
> wq's sched_attr to the spawned kworer.

That doesn't help kthreadd get to a CPU in a box being saturated by RT.

As long as you are careful, it's not a problem, I just mentioned it
because it's a hole.

-Mike

Re: [PATCH v3 4/5] powerpc/mm: Allow up to 64 low slices

[Aneesh Kumar K.V]

Christophe Leroy  writes:

> While the implementation of the "slices" address space allows
> a significant amount of high slices, it limits the number of
> low slices to 16 due to the use of a single u64 low_slices_psize
> element in struct mm_context_t
>
> On the 8xx, the minimum slice size is the size of the area
> covered by a single PMD entry, ie 4M in 4K pages mode and 64M in
> 16K pages mode. This means we could have at least 64 slices.
>
> In order to override this limitation, this patch switches the
> handling of low_slices_psize to char array as done already for
> high_slices_psize. This allows to increase the number of low
> slices to 64 on the 8xx.
>

Maybe update the subject to "make low slice also a bitmap".Also indicate
that the bitmap functions optimize the operation if the bitmapsize les
<= long ?

Also switch the 8xx to higher value in the another patch?

> Signed-off-by: Christophe Leroy 
> ---
>  v2: Usign slice_bitmap_xxx() macros instead of bitmap_xxx() functions.
>  v3: keep low_slices as a u64, this allows 64 slices which is enough.
>  
>  arch/powerpc/include/asm/book3s/64/mmu.h |  3 +-
>  arch/powerpc/include/asm/mmu-8xx.h   |  7 +++-
>  arch/powerpc/include/asm/paca.h  |  2 +-
>  arch/powerpc/include/asm/slice.h |  1 -
>  arch/powerpc/include/asm/slice_32.h  |  2 ++
>  arch/powerpc/include/asm/slice_64.h  |  2 ++
>  arch/powerpc/kernel/paca.c   |  3 +-
>  arch/powerpc/mm/hash_utils_64.c  | 13 
>  arch/powerpc/mm/slb_low.S|  8 +++--
>  arch/powerpc/mm/slice.c  | 57 
> +---
>  10 files changed, 56 insertions(+), 42 deletions(-)
>
> diff --git a/arch/powerpc/include/asm/book3s/64/mmu.h 
> b/arch/powerpc/include/asm/book3s/64/mmu.h
> index c9448e19847a..b076a2d74c69 100644
> --- a/arch/powerpc/include/asm/book3s/64/mmu.h
> +++ b/arch/powerpc/include/asm/book3s/64/mmu.h
> @@ -91,7 +91,8 @@ typedef struct {
>   struct npu_context *npu_context;
>  
>  #ifdef CONFIG_PPC_MM_SLICES
> - u64 low_slices_psize;   /* SLB page size encodings */
> +  /* SLB page size encodings*/
> + unsigned char low_slices_psize[BITS_PER_LONG / BITS_PER_BYTE];
>   unsigned char high_slices_psize[SLICE_ARRAY_SIZE];
>   unsigned long slb_addr_limit;
>  #else
> diff --git a/arch/powerpc/include/asm/mmu-8xx.h 
> b/arch/powerpc/include/asm/mmu-8xx.h
> index 5f89b6010453..5f37ba06b56c 100644
> --- a/arch/powerpc/include/asm/mmu-8xx.h
> +++ b/arch/powerpc/include/asm/mmu-8xx.h
> @@ -164,6 +164,11 @@
>   */
>  #define SPRN_M_TW799
>  
> +#ifdef CONFIG_PPC_MM_SLICES
> +#include 
> +#define SLICE_ARRAY_SIZE (1 << (32 - SLICE_LOW_SHIFT - 1))
> +#endif
> +
>  #ifndef __ASSEMBLY__
>  typedef struct {
>   unsigned int id;
> @@ -171,7 +176,7 @@ typedef struct {
>   unsigned long vdso_base;
>  #ifdef CONFIG_PPC_MM_SLICES
>   u16 user_psize; /* page size index */
> - u64 low_slices_psize;   /* page size encodings */
> + unsigned char low_slices_psize[SLICE_ARRAY_SIZE];
>   unsigned char high_slices_psize[0];
>   unsigned long slb_addr_limit;
>  #endif
> diff --git a/arch/powerpc/include/asm/paca.h b/arch/powerpc/include/asm/paca.h
> index 23ac7fc0af23..a3e531fe9ac7 100644
> --- a/arch/powerpc/include/asm/paca.h
> +++ b/arch/powerpc/include/asm/paca.h
> @@ -141,7 +141,7 @@ struct paca_struct {
>  #ifdef CONFIG_PPC_BOOK3S
>   mm_context_id_t mm_ctx_id;
>  #ifdef CONFIG_PPC_MM_SLICES
> - u64 mm_ctx_low_slices_psize;
> + unsigned char mm_ctx_low_slices_psize[BITS_PER_LONG / BITS_PER_BYTE];
>   unsigned char mm_ctx_high_slices_psize[SLICE_ARRAY_SIZE];
>   unsigned long mm_ctx_slb_addr_limit;
>  #else
> diff --git a/arch/powerpc/include/asm/slice.h 
> b/arch/powerpc/include/asm/slice.h
> index 2b4b70de7e71..b67ba8faa507 100644
> --- a/arch/powerpc/include/asm/slice.h
> +++ b/arch/powerpc/include/asm/slice.h
> @@ -16,7 +16,6 @@
>  #define HAVE_ARCH_UNMAPPED_AREA
>  #define HAVE_ARCH_UNMAPPED_AREA_TOPDOWN
>  
> -#define SLICE_LOW_SHIFT  28
>  #define SLICE_LOW_TOP(0x1ull)
>  #define SLICE_NUM_LOW(SLICE_LOW_TOP >> SLICE_LOW_SHIFT)
>  #define GET_LOW_SLICE_INDEX(addr)((addr) >> SLICE_LOW_SHIFT)
> diff --git a/arch/powerpc/include/asm/slice_32.h 
> b/arch/powerpc/include/asm/slice_32.h
> index 7e27c0dfb913..349187c20100 100644
> --- a/arch/powerpc/include/asm/slice_32.h
> +++ b/arch/powerpc/include/asm/slice_32.h
> @@ -2,6 +2,8 @@
>  #ifndef _ASM_POWERPC_SLICE_32_H
>  #define _ASM_POWERPC_SLICE_32_H
>  
> +#define SLICE_LOW_SHIFT  26  /* 64 slices */
> +
>  #define SLICE_HIGH_SHIFT 0
>  #define SLICE_NUM_HIGH   0ul
>  #define GET_HIGH_SLICE_INDEX(addr)   (addr & 0)
> diff --git a/arch/powerpc/include/asm/slice_64.h 
> b/arch/powerpc/include/asm/slice_64.h
> index 9d1c97b83010..0959475239c6 100644
> --- 

Re: [PATCH v3 4/5] powerpc/mm: Allow up to 64 low slices

[Aneesh Kumar K.V]

Christophe Leroy  writes:

> While the implementation of the "slices" address space allows
> a significant amount of high slices, it limits the number of
> low slices to 16 due to the use of a single u64 low_slices_psize
> element in struct mm_context_t
>
> On the 8xx, the minimum slice size is the size of the area
> covered by a single PMD entry, ie 4M in 4K pages mode and 64M in
> 16K pages mode. This means we could have at least 64 slices.
>
> In order to override this limitation, this patch switches the
> handling of low_slices_psize to char array as done already for
> high_slices_psize. This allows to increase the number of low
> slices to 64 on the 8xx.
>

Maybe update the subject to "make low slice also a bitmap".Also indicate
that the bitmap functions optimize the operation if the bitmapsize les
<= long ?

Also switch the 8xx to higher value in the another patch?

> Signed-off-by: Christophe Leroy 
> ---
>  v2: Usign slice_bitmap_xxx() macros instead of bitmap_xxx() functions.
>  v3: keep low_slices as a u64, this allows 64 slices which is enough.
>  
>  arch/powerpc/include/asm/book3s/64/mmu.h |  3 +-
>  arch/powerpc/include/asm/mmu-8xx.h   |  7 +++-
>  arch/powerpc/include/asm/paca.h  |  2 +-
>  arch/powerpc/include/asm/slice.h |  1 -
>  arch/powerpc/include/asm/slice_32.h  |  2 ++
>  arch/powerpc/include/asm/slice_64.h  |  2 ++
>  arch/powerpc/kernel/paca.c   |  3 +-
>  arch/powerpc/mm/hash_utils_64.c  | 13 
>  arch/powerpc/mm/slb_low.S|  8 +++--
>  arch/powerpc/mm/slice.c  | 57 
> +---
>  10 files changed, 56 insertions(+), 42 deletions(-)
>
> diff --git a/arch/powerpc/include/asm/book3s/64/mmu.h 
> b/arch/powerpc/include/asm/book3s/64/mmu.h
> index c9448e19847a..b076a2d74c69 100644
> --- a/arch/powerpc/include/asm/book3s/64/mmu.h
> +++ b/arch/powerpc/include/asm/book3s/64/mmu.h
> @@ -91,7 +91,8 @@ typedef struct {
>   struct npu_context *npu_context;
>  
>  #ifdef CONFIG_PPC_MM_SLICES
> - u64 low_slices_psize;   /* SLB page size encodings */
> +  /* SLB page size encodings*/
> + unsigned char low_slices_psize[BITS_PER_LONG / BITS_PER_BYTE];
>   unsigned char high_slices_psize[SLICE_ARRAY_SIZE];
>   unsigned long slb_addr_limit;
>  #else
> diff --git a/arch/powerpc/include/asm/mmu-8xx.h 
> b/arch/powerpc/include/asm/mmu-8xx.h
> index 5f89b6010453..5f37ba06b56c 100644
> --- a/arch/powerpc/include/asm/mmu-8xx.h
> +++ b/arch/powerpc/include/asm/mmu-8xx.h
> @@ -164,6 +164,11 @@
>   */
>  #define SPRN_M_TW799
>  
> +#ifdef CONFIG_PPC_MM_SLICES
> +#include 
> +#define SLICE_ARRAY_SIZE (1 << (32 - SLICE_LOW_SHIFT - 1))
> +#endif
> +
>  #ifndef __ASSEMBLY__
>  typedef struct {
>   unsigned int id;
> @@ -171,7 +176,7 @@ typedef struct {
>   unsigned long vdso_base;
>  #ifdef CONFIG_PPC_MM_SLICES
>   u16 user_psize; /* page size index */
> - u64 low_slices_psize;   /* page size encodings */
> + unsigned char low_slices_psize[SLICE_ARRAY_SIZE];
>   unsigned char high_slices_psize[0];
>   unsigned long slb_addr_limit;
>  #endif
> diff --git a/arch/powerpc/include/asm/paca.h b/arch/powerpc/include/asm/paca.h
> index 23ac7fc0af23..a3e531fe9ac7 100644
> --- a/arch/powerpc/include/asm/paca.h
> +++ b/arch/powerpc/include/asm/paca.h
> @@ -141,7 +141,7 @@ struct paca_struct {
>  #ifdef CONFIG_PPC_BOOK3S
>   mm_context_id_t mm_ctx_id;
>  #ifdef CONFIG_PPC_MM_SLICES
> - u64 mm_ctx_low_slices_psize;
> + unsigned char mm_ctx_low_slices_psize[BITS_PER_LONG / BITS_PER_BYTE];
>   unsigned char mm_ctx_high_slices_psize[SLICE_ARRAY_SIZE];
>   unsigned long mm_ctx_slb_addr_limit;
>  #else
> diff --git a/arch/powerpc/include/asm/slice.h 
> b/arch/powerpc/include/asm/slice.h
> index 2b4b70de7e71..b67ba8faa507 100644
> --- a/arch/powerpc/include/asm/slice.h
> +++ b/arch/powerpc/include/asm/slice.h
> @@ -16,7 +16,6 @@
>  #define HAVE_ARCH_UNMAPPED_AREA
>  #define HAVE_ARCH_UNMAPPED_AREA_TOPDOWN
>  
> -#define SLICE_LOW_SHIFT  28
>  #define SLICE_LOW_TOP(0x1ull)
>  #define SLICE_NUM_LOW(SLICE_LOW_TOP >> SLICE_LOW_SHIFT)
>  #define GET_LOW_SLICE_INDEX(addr)((addr) >> SLICE_LOW_SHIFT)
> diff --git a/arch/powerpc/include/asm/slice_32.h 
> b/arch/powerpc/include/asm/slice_32.h
> index 7e27c0dfb913..349187c20100 100644
> --- a/arch/powerpc/include/asm/slice_32.h
> +++ b/arch/powerpc/include/asm/slice_32.h
> @@ -2,6 +2,8 @@
>  #ifndef _ASM_POWERPC_SLICE_32_H
>  #define _ASM_POWERPC_SLICE_32_H
>  
> +#define SLICE_LOW_SHIFT  26  /* 64 slices */
> +
>  #define SLICE_HIGH_SHIFT 0
>  #define SLICE_NUM_HIGH   0ul
>  #define GET_HIGH_SLICE_INDEX(addr)   (addr & 0)
> diff --git a/arch/powerpc/include/asm/slice_64.h 
> b/arch/powerpc/include/asm/slice_64.h
> index 9d1c97b83010..0959475239c6 100644
> --- a/arch/powerpc/include/asm/slice_64.h
> +++ 

Re: Re: [PATCH 1/2] dmaengine: dmatest: change symbolic permissions to octal values

[Yang, Shunyong]

Hi, Vinod

On Mon, 2018-01-29 at 10:18 +0530, Vinod Koul wrote:
> On Mon, Jan 22, 2018 at 06:44:40PM +0800, Yang Shunyong wrote:
> > 
> > Current coding style prefers octal permissions values. This patch
> > changes symbolic permissions to octal values.
> Is this preference documented anywhere?
> 

When using symbolic permissions like "S_IRUGO | S_IWUSR". The
checkpatch.pl will output some warnings to suggest to use octal values.
I quote following lines from checkpatch.pl,

# check for uses of S_ that could be octal for readability
...
if (WARN("SYMBOLIC_PERMS",
 "Symbolic permissions '$oval' are not
preferred. Consider using octal permissions '$octal'.\n" . $herecurr)
&&
$fix) {
$fixed[$fixlinenr] =~ s/$val/$octal/;
}

Thanks.
Shunyong

Re: Re: [PATCH 1/2] dmaengine: dmatest: change symbolic permissions to octal values

[Yang, Shunyong]

Hi, Vinod

On Mon, 2018-01-29 at 10:18 +0530, Vinod Koul wrote:
> On Mon, Jan 22, 2018 at 06:44:40PM +0800, Yang Shunyong wrote:
> > 
> > Current coding style prefers octal permissions values. This patch
> > changes symbolic permissions to octal values.
> Is this preference documented anywhere?
> 

When using symbolic permissions like "S_IRUGO | S_IWUSR". The
checkpatch.pl will output some warnings to suggest to use octal values.
I quote following lines from checkpatch.pl,

# check for uses of S_ that could be octal for readability
...
if (WARN("SYMBOLIC_PERMS",
 "Symbolic permissions '$oval' are not
preferred. Consider using octal permissions '$octal'.\n" . $herecurr)
&&
$fix) {
$fixed[$fixlinenr] =~ s/$val/$octal/;
}

Thanks.
Shunyong

Re: [PATCH 3/3] syscalls: Add a bit of documentation to __SYSCALL_DEFINE

[Al Viro]

On Sun, Jan 28, 2018 at 10:50:31PM +, Al Viro wrote:
> On Sun, Jan 28, 2018 at 12:42:24PM -0800, Linus Torvalds wrote:
> 
> > The 64-bit argument for 32-bit case would end up having to have a few
> > more of those architecture-specific oddities. So not just
> > "argument1(ptregs)", but "argument2_32_64(ptregs)" or something that
> > says "get me argument 2, when the first argument is 32-bit and I want
> > a 64-bit one".
> 
> Yeah, but...  You either get to give SYSCALL_DEFINE more than just
> the number of arguments (SYSCALL_DEFINE_WDDW) or you need to go
> for rather grotty macros to pick that information.  That's pretty
> much what I'd tried; it hadn't been fun at all...

FWIW, going through the notes from back then (with some personal
comments censored - parts of that were definitely in the actionable
territory):

--

* s390 aside, the headache comes from combination of calling conventions
for 64bit arguments on 32bit and [speculation regarding libc maintainers
qualities]

* All architectures in question[1] treat syscall arguments as either
32bit (arith types <= 32bit, pointers) or 64bit.  Prototypical case
is f(int a1, int a2, ); let L1, L2, ... be the sequence of locations
used to pass them (might be GPR, might be stack locations).  Anything
that doesn't involve long long uses the same sequence; in theory, we could
have different sets of registers for e.g. pointers and integers, but nothing
we care about seems to be doing that.

* wrt 64bit ints there are two variants: one is to simply treat them as pair
of 32bit ones (i.e. take the next two elements of the sequence), another is
to skip an element and then use the next two.  Some architectures always
go for the first variant; x86, s390 and, surprisingly, sparc are that way.
arm, mips, parisc, ppc and tile go for the second variant when odd number
of 32bit values had been passed so far.

* argument passing for syscalls is something almost, but not entirely different.
First of all, we don't want to pass them on stack (no surprise); mips o32
ABI is trouble in that respect, everything else manages to use registers
(so do other mips ABI variants).  Next, we are generally limited to 6 words.
No worries, right?  We don't have syscalls with more than 6 arguments, and
ones with 64bit args still fit into 32*6 bits.  Too fucking bad - akpm has
introduced int sys_fadvise64(int fd, loff_t offset, size_t len, int advice)
and then topped it with
long sys_fadvise64_64(int fd, loff_t offset, loff_t len, int advice)
Note that this sucker already has 32*6 bits total *AND* 64bit argument in odd
position.  arm, mips and ppc folks were not amused (IIRC, rmk got downright
sarcastic at the time; not quite Patrician-level, what with the lack of
resources, but...)
That had been compounded by sync_file_range(2), with identical braind^WAPI.
The latter got a saner variant (sync_file_range2(2)) and newer architectures
should take that.  fadvise64_64(2) has not.  BTW, that had been a headache
for other 32bit architectures as well - at least c6x and metag are in the
same boat.  Different solutions with that one - some split those 64bit into
32bit on C level and repackage them into 64bit in stubs, some reorder the
arguments so that 64bit ones are at good offsets.

* for syscalls like pread64/pwrite64, the situation is less dire.  Some still
pass the misaligned 64bit arg as a pair of C-level 32bit ones, some accept
the padding.

* to make things even more interesting, libc (all of them) pass a bunch of
64bit args as explicit pairs.  Which creates no end of amusing situations -
will this argument of this syscall end up with LSB first?  Last?  According
to endianness?  Opposite?  Different rules for different architectures?
Onna stick.  Inna bun.  And that's cuttin' me own throat... [speculations
regarding various habits of libc maintainers]

* it might be possible to teach COMPAT_SYSCALL_DEFINE to insert padding and
combine the halves.  Cost: collecting the information about the number of
words passed so far; messy, but maybe I'm missing some clever solution.
However, that doesn't do a damn thing for libc-inflicted idiocies, so it
might or might not be worth it.  In some cases the mapping from what
libc is feeding to the kernel to actual long long passed from the glue
into C side of things is just too fucking irregular[2].

--

[1] i.e. 32bit side of biarch ones; I was interested in COMPAT_SYSCALL_DEFINE
back then.
[2] looking at that now, parisc has fanotify_mark() passing halves of 64bit
arg in the order opposite to that for truncate64().  On the same parisc.
>From the same libc.  And then there's lookup_dcookie(), which might or
might not be correct there.

Re: [PATCH 3/3] syscalls: Add a bit of documentation to __SYSCALL_DEFINE

[Al Viro]

On Sun, Jan 28, 2018 at 10:50:31PM +, Al Viro wrote:
> On Sun, Jan 28, 2018 at 12:42:24PM -0800, Linus Torvalds wrote:
> 
> > The 64-bit argument for 32-bit case would end up having to have a few
> > more of those architecture-specific oddities. So not just
> > "argument1(ptregs)", but "argument2_32_64(ptregs)" or something that
> > says "get me argument 2, when the first argument is 32-bit and I want
> > a 64-bit one".
> 
> Yeah, but...  You either get to give SYSCALL_DEFINE more than just
> the number of arguments (SYSCALL_DEFINE_WDDW) or you need to go
> for rather grotty macros to pick that information.  That's pretty
> much what I'd tried; it hadn't been fun at all...

FWIW, going through the notes from back then (with some personal
comments censored - parts of that were definitely in the actionable
territory):

--

* s390 aside, the headache comes from combination of calling conventions
for 64bit arguments on 32bit and [speculation regarding libc maintainers
qualities]

* All architectures in question[1] treat syscall arguments as either
32bit (arith types <= 32bit, pointers) or 64bit.  Prototypical case
is f(int a1, int a2, ); let L1, L2, ... be the sequence of locations
used to pass them (might be GPR, might be stack locations).  Anything
that doesn't involve long long uses the same sequence; in theory, we could
have different sets of registers for e.g. pointers and integers, but nothing
we care about seems to be doing that.

* wrt 64bit ints there are two variants: one is to simply treat them as pair
of 32bit ones (i.e. take the next two elements of the sequence), another is
to skip an element and then use the next two.  Some architectures always
go for the first variant; x86, s390 and, surprisingly, sparc are that way.
arm, mips, parisc, ppc and tile go for the second variant when odd number
of 32bit values had been passed so far.

* argument passing for syscalls is something almost, but not entirely different.
First of all, we don't want to pass them on stack (no surprise); mips o32
ABI is trouble in that respect, everything else manages to use registers
(so do other mips ABI variants).  Next, we are generally limited to 6 words.
No worries, right?  We don't have syscalls with more than 6 arguments, and
ones with 64bit args still fit into 32*6 bits.  Too fucking bad - akpm has
introduced int sys_fadvise64(int fd, loff_t offset, size_t len, int advice)
and then topped it with
long sys_fadvise64_64(int fd, loff_t offset, loff_t len, int advice)
Note that this sucker already has 32*6 bits total *AND* 64bit argument in odd
position.  arm, mips and ppc folks were not amused (IIRC, rmk got downright
sarcastic at the time; not quite Patrician-level, what with the lack of
resources, but...)
That had been compounded by sync_file_range(2), with identical braind^WAPI.
The latter got a saner variant (sync_file_range2(2)) and newer architectures
should take that.  fadvise64_64(2) has not.  BTW, that had been a headache
for other 32bit architectures as well - at least c6x and metag are in the
same boat.  Different solutions with that one - some split those 64bit into
32bit on C level and repackage them into 64bit in stubs, some reorder the
arguments so that 64bit ones are at good offsets.

* for syscalls like pread64/pwrite64, the situation is less dire.  Some still
pass the misaligned 64bit arg as a pair of C-level 32bit ones, some accept
the padding.

* to make things even more interesting, libc (all of them) pass a bunch of
64bit args as explicit pairs.  Which creates no end of amusing situations -
will this argument of this syscall end up with LSB first?  Last?  According
to endianness?  Opposite?  Different rules for different architectures?
Onna stick.  Inna bun.  And that's cuttin' me own throat... [speculations
regarding various habits of libc maintainers]

* it might be possible to teach COMPAT_SYSCALL_DEFINE to insert padding and
combine the halves.  Cost: collecting the information about the number of
words passed so far; messy, but maybe I'm missing some clever solution.
However, that doesn't do a damn thing for libc-inflicted idiocies, so it
might or might not be worth it.  In some cases the mapping from what
libc is feeding to the kernel to actual long long passed from the glue
into C side of things is just too fucking irregular[2].

--

[1] i.e. 32bit side of biarch ones; I was interested in COMPAT_SYSCALL_DEFINE
back then.
[2] looking at that now, parisc has fanotify_mark() passing halves of 64bit
arg in the order opposite to that for truncate64().  On the same parisc.
>From the same libc.  And then there's lookup_dcookie(), which might or
might not be correct there.

Re: [PATCH] dmaengine: dmatest: fix container_of member in dmatest_callback

[Yang, Shunyong]

Hi, Vinod,

On Mon, 2018-01-29 at 10:15 +0530, Vinod Koul wrote:
> On Mon, Jan 22, 2018 at 03:28:28PM +0800, Yang Shunyong wrote:
> > 
> > The type of arg passed to dmatest_callback is struct dmatest_done.
> > It refers to test_done in struct dmatest_thread, not done_wait.
> > 
> > Fixes: 6f6a23a213be ("dmaengine: dmatest: move callback wait ...")
> > Signed-off-by: Yang Shunyong 
> > ---
> >  drivers/dma/dmatest.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/drivers/dma/dmatest.c b/drivers/dma/dmatest.c
> > index ec5f9d2bc820..906e85d6dedc 100644
> > --- a/drivers/dma/dmatest.c
> > +++ b/drivers/dma/dmatest.c
> > @@ -355,7 +355,7 @@ static void dmatest_callback(void *arg)
> >  {
> >     struct dmatest_done *done = arg;
> >     struct dmatest_thread *thread =
> > -   container_of(arg, struct dmatest_thread,
> > done_wait);
> > +   container_of(arg, struct dmatest_thread,
> > test_done);
> This fixes it but one of the reason why compilers didn't catch this
> was the void arg. I just tested and used 'done' as the argument here
> rather than 'arg' and compiler was quick to point out the error.
> 
> So a better fix IMO would be:
> 
> -- >8 --
> 
> diff --git a/drivers/dma/dmatest.c b/drivers/dma/dmatest.c
> index ec5f9d2bc820..80cc2be6483c 100644
> --- a/drivers/dma/dmatest.c
> +++ b/drivers/dma/dmatest.c
> @@ -355,7 +355,7 @@ static void dmatest_callback(void *arg)
>  {
> struct dmatest_done *done = arg;
> struct dmatest_thread *thread =
> -   container_of(arg, struct dmatest_thread, done_wait);
> +   container_of(done, struct dmatest_thread, test_done);
> if (!thread->done) {
> done->done = true;
> wake_up_all(done->wait);
> 

Thanks. I will send out v2 patch soon.

Shunyong

Re: [PATCH] dmaengine: dmatest: fix container_of member in dmatest_callback

[Yang, Shunyong]

Hi, Vinod,

On Mon, 2018-01-29 at 10:15 +0530, Vinod Koul wrote:
> On Mon, Jan 22, 2018 at 03:28:28PM +0800, Yang Shunyong wrote:
> > 
> > The type of arg passed to dmatest_callback is struct dmatest_done.
> > It refers to test_done in struct dmatest_thread, not done_wait.
> > 
> > Fixes: 6f6a23a213be ("dmaengine: dmatest: move callback wait ...")
> > Signed-off-by: Yang Shunyong 
> > ---
> >  drivers/dma/dmatest.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/drivers/dma/dmatest.c b/drivers/dma/dmatest.c
> > index ec5f9d2bc820..906e85d6dedc 100644
> > --- a/drivers/dma/dmatest.c
> > +++ b/drivers/dma/dmatest.c
> > @@ -355,7 +355,7 @@ static void dmatest_callback(void *arg)
> >  {
> >     struct dmatest_done *done = arg;
> >     struct dmatest_thread *thread =
> > -   container_of(arg, struct dmatest_thread,
> > done_wait);
> > +   container_of(arg, struct dmatest_thread,
> > test_done);
> This fixes it but one of the reason why compilers didn't catch this
> was the void arg. I just tested and used 'done' as the argument here
> rather than 'arg' and compiler was quick to point out the error.
> 
> So a better fix IMO would be:
> 
> -- >8 --
> 
> diff --git a/drivers/dma/dmatest.c b/drivers/dma/dmatest.c
> index ec5f9d2bc820..80cc2be6483c 100644
> --- a/drivers/dma/dmatest.c
> +++ b/drivers/dma/dmatest.c
> @@ -355,7 +355,7 @@ static void dmatest_callback(void *arg)
>  {
> struct dmatest_done *done = arg;
> struct dmatest_thread *thread =
> -   container_of(arg, struct dmatest_thread, done_wait);
> +   container_of(done, struct dmatest_thread, test_done);
> if (!thread->done) {
> done->done = true;
> wake_up_all(done->wait);
> 

Thanks. I will send out v2 patch soon.

Shunyong

Re: [PATCH v3 1/5] powerpc/mm: Remove intermediate bitmap copy in 'slices'

[Aneesh Kumar K.V]

Christophe Leroy  writes:

> bitmap_or() and bitmap_andnot() can work properly with dst identical
> to src1 or src2. There is no need of an intermediate result bitmap
> that is copied back to dst in a second step.
>
Reviewed-by: Aneesh Kumar K.V 
> Signed-off-by: Christophe Leroy 
> ---
>  v2: New in v2
>  v3: patch moved up front of the serie to avoid ephemeral slice_bitmap_copy() 
> function in following patch
>
>  arch/powerpc/mm/slice.c | 12 
>  1 file changed, 4 insertions(+), 8 deletions(-)
>
> diff --git a/arch/powerpc/mm/slice.c b/arch/powerpc/mm/slice.c
> index 23ec2c5e3b78..98b53d48968f 100644
> --- a/arch/powerpc/mm/slice.c
> +++ b/arch/powerpc/mm/slice.c
> @@ -388,21 +388,17 @@ static unsigned long slice_find_area(struct mm_struct 
> *mm, unsigned long len,
>  
>  static inline void slice_or_mask(struct slice_mask *dst, struct slice_mask 
> *src)
>  {
> - DECLARE_BITMAP(result, SLICE_NUM_HIGH);
> -
>   dst->low_slices |= src->low_slices;
> - bitmap_or(result, dst->high_slices, src->high_slices, SLICE_NUM_HIGH);
> - bitmap_copy(dst->high_slices, result, SLICE_NUM_HIGH);
> + bitmap_or(dst->high_slices, dst->high_slices, src->high_slices,
> +   SLICE_NUM_HIGH);
>  }
>  
>  static inline void slice_andnot_mask(struct slice_mask *dst, struct 
> slice_mask *src)
>  {
> - DECLARE_BITMAP(result, SLICE_NUM_HIGH);
> -
>   dst->low_slices &= ~src->low_slices;
>  
> - bitmap_andnot(result, dst->high_slices, src->high_slices, 
> SLICE_NUM_HIGH);
> - bitmap_copy(dst->high_slices, result, SLICE_NUM_HIGH);
> + bitmap_andnot(dst->high_slices, dst->high_slices, src->high_slices,
> +   SLICE_NUM_HIGH);
>  }
>  
>  #ifdef CONFIG_PPC_64K_PAGES
> -- 
> 2.13.3

Re: [PATCH v3 1/5] powerpc/mm: Remove intermediate bitmap copy in 'slices'

[Aneesh Kumar K.V]

Christophe Leroy  writes:

> bitmap_or() and bitmap_andnot() can work properly with dst identical
> to src1 or src2. There is no need of an intermediate result bitmap
> that is copied back to dst in a second step.
>
Reviewed-by: Aneesh Kumar K.V 
> Signed-off-by: Christophe Leroy 
> ---
>  v2: New in v2
>  v3: patch moved up front of the serie to avoid ephemeral slice_bitmap_copy() 
> function in following patch
>
>  arch/powerpc/mm/slice.c | 12 
>  1 file changed, 4 insertions(+), 8 deletions(-)
>
> diff --git a/arch/powerpc/mm/slice.c b/arch/powerpc/mm/slice.c
> index 23ec2c5e3b78..98b53d48968f 100644
> --- a/arch/powerpc/mm/slice.c
> +++ b/arch/powerpc/mm/slice.c
> @@ -388,21 +388,17 @@ static unsigned long slice_find_area(struct mm_struct 
> *mm, unsigned long len,
>  
>  static inline void slice_or_mask(struct slice_mask *dst, struct slice_mask 
> *src)
>  {
> - DECLARE_BITMAP(result, SLICE_NUM_HIGH);
> -
>   dst->low_slices |= src->low_slices;
> - bitmap_or(result, dst->high_slices, src->high_slices, SLICE_NUM_HIGH);
> - bitmap_copy(dst->high_slices, result, SLICE_NUM_HIGH);
> + bitmap_or(dst->high_slices, dst->high_slices, src->high_slices,
> +   SLICE_NUM_HIGH);
>  }
>  
>  static inline void slice_andnot_mask(struct slice_mask *dst, struct 
> slice_mask *src)
>  {
> - DECLARE_BITMAP(result, SLICE_NUM_HIGH);
> -
>   dst->low_slices &= ~src->low_slices;
>  
> - bitmap_andnot(result, dst->high_slices, src->high_slices, 
> SLICE_NUM_HIGH);
> - bitmap_copy(dst->high_slices, result, SLICE_NUM_HIGH);
> + bitmap_andnot(dst->high_slices, dst->high_slices, src->high_slices,
> +   SLICE_NUM_HIGH);
>  }
>  
>  #ifdef CONFIG_PPC_64K_PAGES
> -- 
> 2.13.3

[PATCH] ACPI: Parse entire table as a term_list for Dell XPS 9570 and Precision M5530

[Kai-Heng Feng]

The i2c touchpad on Dell XPS 9570 and Precision M5530 doesn't work out
of box.

The touchpad relies on its _INI method to update its _HID value from
 to SYNA2393.
Also, the _STA relies on value of I2CN to report correct status.

Set acpi_gbl_parse_table_as_term_list so the value of I2CN can be
correctly set up, and _INI can get run. The ACPI table in this machine
is designed to get parsed this way.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=198515
Cc: Mario Limonciello 
Signed-off-by: Kai-Heng Feng 
---
 drivers/acpi/bus.c | 41 +
 1 file changed, 41 insertions(+)

diff --git a/drivers/acpi/bus.c b/drivers/acpi/bus.c
index 4d0979e02a28..4da34d67e23d 100644
--- a/drivers/acpi/bus.c
+++ b/drivers/acpi/bus.c
@@ -88,6 +86,45 @@ static const struct dmi_system_id dsdt_dmi_table[] 
__initconst = {
 };
 #endif
 
+#ifdef CONFIG_X86
+static int set_gbl_term_list(const struct dmi_system_id *id)
+{
+   pr_notice("%s detected - parse the entire table as a term_list\n",
+ id->ident);
+   acpi_gbl_parse_table_as_term_list = 1;
+   return 0;
+}
+
+static const struct dmi_system_id gbl_term_list_dmi_table[] __initconst = {
+   /*
+* Touchpad on Dell XPS 9570/Precision M5530 doesn't work under I2C
+* mode.
+* https://bugzilla.kernel.org/show_bug.cgi?id=198515
+*/
+   {
+   .callback = set_gbl_term_list,
+   .ident = "Dell Precision M5530",
+   .matches = {
+   DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc."),
+   DMI_MATCH(DMI_PRODUCT_NAME, "Precision M5530"),
+   },
+   },
+   {
+   .callback = set_gbl_term_list,
+   .ident = "Dell XPS 15 9570",
+   .matches = {
+   DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc."),
+   DMI_MATCH(DMI_PRODUCT_NAME, "XPS 15 9570"),
+   },
+   },
+   {}
+};
+#else
+static const struct dmi_system_id gbl_term_list_dmi_table[] __initconst = {
+   {}
+};
+#endif
+
 /* --
 Device Management
-- 
*/
@@ -1007,6 +1046,8 @@ void __init acpi_early_init(void)
 */
dmi_check_system(dsdt_dmi_table);
 
+   dmi_check_system(gbl_term_list_dmi_table);
+
status = acpi_reallocate_root_table();
if (ACPI_FAILURE(status)) {
printk(KERN_ERR PREFIX
-- 
2.15.1

[PATCH] ACPI: Parse entire table as a term_list for Dell XPS 9570 and Precision M5530

[Kai-Heng Feng]

The i2c touchpad on Dell XPS 9570 and Precision M5530 doesn't work out
of box.

The touchpad relies on its _INI method to update its _HID value from
 to SYNA2393.
Also, the _STA relies on value of I2CN to report correct status.

Set acpi_gbl_parse_table_as_term_list so the value of I2CN can be
correctly set up, and _INI can get run. The ACPI table in this machine
is designed to get parsed this way.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=198515
Cc: Mario Limonciello 
Signed-off-by: Kai-Heng Feng 
---
 drivers/acpi/bus.c | 41 +
 1 file changed, 41 insertions(+)

diff --git a/drivers/acpi/bus.c b/drivers/acpi/bus.c
index 4d0979e02a28..4da34d67e23d 100644
--- a/drivers/acpi/bus.c
+++ b/drivers/acpi/bus.c
@@ -88,6 +86,45 @@ static const struct dmi_system_id dsdt_dmi_table[] 
__initconst = {
 };
 #endif
 
+#ifdef CONFIG_X86
+static int set_gbl_term_list(const struct dmi_system_id *id)
+{
+   pr_notice("%s detected - parse the entire table as a term_list\n",
+ id->ident);
+   acpi_gbl_parse_table_as_term_list = 1;
+   return 0;
+}
+
+static const struct dmi_system_id gbl_term_list_dmi_table[] __initconst = {
+   /*
+* Touchpad on Dell XPS 9570/Precision M5530 doesn't work under I2C
+* mode.
+* https://bugzilla.kernel.org/show_bug.cgi?id=198515
+*/
+   {
+   .callback = set_gbl_term_list,
+   .ident = "Dell Precision M5530",
+   .matches = {
+   DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc."),
+   DMI_MATCH(DMI_PRODUCT_NAME, "Precision M5530"),
+   },
+   },
+   {
+   .callback = set_gbl_term_list,
+   .ident = "Dell XPS 15 9570",
+   .matches = {
+   DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc."),
+   DMI_MATCH(DMI_PRODUCT_NAME, "XPS 15 9570"),
+   },
+   },
+   {}
+};
+#else
+static const struct dmi_system_id gbl_term_list_dmi_table[] __initconst = {
+   {}
+};
+#endif
+
 /* --
 Device Management
-- 
*/
@@ -1007,6 +1046,8 @@ void __init acpi_early_init(void)
 */
dmi_check_system(dsdt_dmi_table);
 
+   dmi_check_system(gbl_term_list_dmi_table);
+
status = acpi_reallocate_root_table();
if (ACPI_FAILURE(status)) {
printk(KERN_ERR PREFIX
-- 
2.15.1

linux-next: manual merge of the nvdimm tree with the powerpc tree

[Stephen Rothwell]

Hi Dan,

Today's linux-next merge of the nvdimm tree got a conflict in:

  arch/powerpc/sysdev/axonram.c

between commit:

  1d65b1c886be ("powerpc/cell: Remove axonram driver")

from the powerpc tree and commit:

  785a3fab4adb ("mm, dax: introduce pfn_t_special()")

from the nvdimm tree.

I fixed it up (I just removed the file) and can carry the fix as
necessary. This is now fixed as far as linux-next is concerned, but any
non trivial conflicts should be mentioned to your upstream maintainer
when your tree is submitted for merging.  You may also want to consider
cooperating with the maintainer of the conflicting tree to minimise any
particularly complex conflicts.

-- 
Cheers,
Stephen Rothwell

linux-next: manual merge of the nvdimm tree with the powerpc tree

[Stephen Rothwell]

Hi Dan,

Today's linux-next merge of the nvdimm tree got a conflict in:

  arch/powerpc/sysdev/axonram.c

between commit:

  1d65b1c886be ("powerpc/cell: Remove axonram driver")

from the powerpc tree and commit:

  785a3fab4adb ("mm, dax: introduce pfn_t_special()")

from the nvdimm tree.

I fixed it up (I just removed the file) and can carry the fix as
necessary. This is now fixed as far as linux-next is concerned, but any
non trivial conflicts should be mentioned to your upstream maintainer
when your tree is submitted for merging.  You may also want to consider
cooperating with the maintainer of the conflicting tree to minimise any
particularly complex conflicts.

-- 
Cheers,
Stephen Rothwell

linux-next: manual merge of the nvdimm tree with the powerpc tree

[Stephen Rothwell]

Hi Dan,

Today's linux-next merge of the nvdimm tree got a conflict in:

  arch/powerpc/platforms/Kconfig

between commit:

  1d65b1c886be ("powerpc/cell: Remove axonram driver")

from the powerpc tree and commit:

  569d0365f571 ("dax: require 'struct page' by default for filesystem dax")

from the nvdimm tree.

I fixed it up (I just used the former version) and can carry the fix as
necessary. This is now fixed as far as linux-next is concerned, but any
non trivial conflicts should be mentioned to your upstream maintainer
when your tree is submitted for merging.  You may also want to consider
cooperating with the maintainer of the conflicting tree to minimise any
particularly complex conflicts.

-- 
Cheers,
Stephen Rothwell

linux-next: manual merge of the nvdimm tree with the powerpc tree

[Stephen Rothwell]

Hi Dan,

Today's linux-next merge of the nvdimm tree got a conflict in:

  arch/powerpc/platforms/Kconfig

between commit:

  1d65b1c886be ("powerpc/cell: Remove axonram driver")

from the powerpc tree and commit:

  569d0365f571 ("dax: require 'struct page' by default for filesystem dax")

from the nvdimm tree.

I fixed it up (I just used the former version) and can carry the fix as
necessary. This is now fixed as far as linux-next is concerned, but any
non trivial conflicts should be mentioned to your upstream maintainer
when your tree is submitted for merging.  You may also want to consider
cooperating with the maintainer of the conflicting tree to minimise any
particularly complex conflicts.

-- 
Cheers,
Stephen Rothwell

Re: [2/3] i2c: piix4: fix number of ports on Family 16h Model 30h

[Guenter Roeck]

On Mon, Jan 29, 2018 at 01:54:19PM +1000, Andrew Cooks wrote:
> Prevent bus timeouts and resets on Family 16h Model 30h), by not
> probing reserved Ports 3 and 4.
> 
> According to the AMD BIOS and Kernel Developer's Guides (BKDG), Port 3
> and Port 4 are reserved on the following devices:
>  - Family 15h Model 60h-6Fh,
>  - Family 15h Model 70h-7Fh,
>  - Family 16h Models 30h-3Fh,
> 
> Signed-off-by: Andrew Cooks 
> ---
>  drivers/i2c/busses/i2c-piix4.c | 31 ++-
>  1 file changed, 22 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/i2c/busses/i2c-piix4.c b/drivers/i2c/busses/i2c-piix4.c
> index 89692f4..9763241 100644
> --- a/drivers/i2c/busses/i2c-piix4.c
> +++ b/drivers/i2c/busses/i2c-piix4.c
> @@ -82,6 +82,13 @@
>  /* Multi-port constants */
>  #define PIIX4_MAX_ADAPTERS 4
>  
> +/*
> + * Main adapter port count. At least one (Port 0) plus up to 3 additional
> + * (Ports 2-4)
> + */

This is a bit misleading. Which adapter has only one port ?

> +#define SB800_MAIN_PORTS 4
> +#define HUDSON2_MAIN_PORTS 2 /* HUDSON2, reserves Port 3 and Port 4 */
> +
A tab between define and value might be helpful. 
Not sure though why both PIIX4_MAX_ADAPTERS and SB800_MAIN_PORTS
are needed.

>  /* SB800 constants */
>  #define SB800_PIIX4_SMB_IDX  0xcd6
>  
> @@ -800,6 +807,7 @@ MODULE_DEVICE_TABLE (pci, piix4_ids);
>  
>  static struct i2c_adapter *piix4_main_adapters[PIIX4_MAX_ADAPTERS];
>  static struct i2c_adapter *piix4_aux_adapter;
> +static int piix4_adapter_count;

This variable is never set, only decreased.

>  
>  static int piix4_add_adapter(struct pci_dev *dev, unsigned short smba,
>bool sb800_main, u8 port, bool notify_imc,
> @@ -856,10 +864,17 @@ static int piix4_add_adapters_sb800(struct pci_dev 
> *dev, unsigned short smba,
>   bool notify_imc)
>  {
>   struct i2c_piix4_adapdata *adapdata;
> - int port;
> + int port, port_count;
>   int retval;
>  
> - for (port = 0; port < PIIX4_MAX_ADAPTERS; port++) {
> + if (dev->device == PCI_DEVICE_ID_AMD_HUDSON2_SMBUS ||
> + dev->device == PCI_DEVICE_ID_AMD_KERNCZ_SMBUS) {
> + port_count = HUDSON2_MAIN_PORTS;
> + } else {
> + port_count = SB800_MAIN_PORTS;
> + }
> +
> + for (port = 0; port < port_count; port++) {
>   retval = piix4_add_adapter(dev, smba, true, port, notify_imc,
>  piix4_main_port_names_sb800[port],
>  _main_adapters[port]);
> @@ -872,7 +887,7 @@ static int piix4_add_adapters_sb800(struct pci_dev *dev, 
> unsigned short smba,
>  error:
>   dev_err(>dev,
>   "Error setting up SB800 adapters. Unregistering!\n");
> - while (--port >= 0) {
> + while (--piix4_adapter_count >= 0) {

This is wrong, even if piix4_adapter_count was initialized.

>   adapdata = i2c_get_adapdata(piix4_main_adapters[port]);
>   if (adapdata->smba) {
>   i2c_del_adapter(piix4_main_adapters[port]);
> @@ -993,12 +1008,10 @@ static void piix4_adap_remove(struct i2c_adapter *adap)
>  
>  static void piix4_remove(struct pci_dev *dev)
>  {
> - int port = PIIX4_MAX_ADAPTERS;

A one line change would do it just as well.
int port = piix4_adapter_count;

> -
> - while (--port >= 0) {
> - if (piix4_main_adapters[port]) {
> - piix4_adap_remove(piix4_main_adapters[port]);
> - piix4_main_adapters[port] = NULL;
> + while (--piix4_adapter_count >= 0) {
> + if (piix4_main_adapters[piix4_adapter_count]) {
> + 
> piix4_adap_remove(piix4_main_adapters[piix4_adapter_count]);
> + piix4_main_adapters[piix4_adapter_count] = NULL;
>   }
>   }
>  

Re: [2/3] i2c: piix4: fix number of ports on Family 16h Model 30h

[Guenter Roeck]

On Mon, Jan 29, 2018 at 01:54:19PM +1000, Andrew Cooks wrote:
> Prevent bus timeouts and resets on Family 16h Model 30h), by not
> probing reserved Ports 3 and 4.
> 
> According to the AMD BIOS and Kernel Developer's Guides (BKDG), Port 3
> and Port 4 are reserved on the following devices:
>  - Family 15h Model 60h-6Fh,
>  - Family 15h Model 70h-7Fh,
>  - Family 16h Models 30h-3Fh,
> 
> Signed-off-by: Andrew Cooks 
> ---
>  drivers/i2c/busses/i2c-piix4.c | 31 ++-
>  1 file changed, 22 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/i2c/busses/i2c-piix4.c b/drivers/i2c/busses/i2c-piix4.c
> index 89692f4..9763241 100644
> --- a/drivers/i2c/busses/i2c-piix4.c
> +++ b/drivers/i2c/busses/i2c-piix4.c
> @@ -82,6 +82,13 @@
>  /* Multi-port constants */
>  #define PIIX4_MAX_ADAPTERS 4
>  
> +/*
> + * Main adapter port count. At least one (Port 0) plus up to 3 additional
> + * (Ports 2-4)
> + */

This is a bit misleading. Which adapter has only one port ?

> +#define SB800_MAIN_PORTS 4
> +#define HUDSON2_MAIN_PORTS 2 /* HUDSON2, reserves Port 3 and Port 4 */
> +
A tab between define and value might be helpful. 
Not sure though why both PIIX4_MAX_ADAPTERS and SB800_MAIN_PORTS
are needed.

>  /* SB800 constants */
>  #define SB800_PIIX4_SMB_IDX  0xcd6
>  
> @@ -800,6 +807,7 @@ MODULE_DEVICE_TABLE (pci, piix4_ids);
>  
>  static struct i2c_adapter *piix4_main_adapters[PIIX4_MAX_ADAPTERS];
>  static struct i2c_adapter *piix4_aux_adapter;
> +static int piix4_adapter_count;

This variable is never set, only decreased.

>  
>  static int piix4_add_adapter(struct pci_dev *dev, unsigned short smba,
>bool sb800_main, u8 port, bool notify_imc,
> @@ -856,10 +864,17 @@ static int piix4_add_adapters_sb800(struct pci_dev 
> *dev, unsigned short smba,
>   bool notify_imc)
>  {
>   struct i2c_piix4_adapdata *adapdata;
> - int port;
> + int port, port_count;
>   int retval;
>  
> - for (port = 0; port < PIIX4_MAX_ADAPTERS; port++) {
> + if (dev->device == PCI_DEVICE_ID_AMD_HUDSON2_SMBUS ||
> + dev->device == PCI_DEVICE_ID_AMD_KERNCZ_SMBUS) {
> + port_count = HUDSON2_MAIN_PORTS;
> + } else {
> + port_count = SB800_MAIN_PORTS;
> + }
> +
> + for (port = 0; port < port_count; port++) {
>   retval = piix4_add_adapter(dev, smba, true, port, notify_imc,
>  piix4_main_port_names_sb800[port],
>  _main_adapters[port]);
> @@ -872,7 +887,7 @@ static int piix4_add_adapters_sb800(struct pci_dev *dev, 
> unsigned short smba,
>  error:
>   dev_err(>dev,
>   "Error setting up SB800 adapters. Unregistering!\n");
> - while (--port >= 0) {
> + while (--piix4_adapter_count >= 0) {

This is wrong, even if piix4_adapter_count was initialized.

>   adapdata = i2c_get_adapdata(piix4_main_adapters[port]);
>   if (adapdata->smba) {
>   i2c_del_adapter(piix4_main_adapters[port]);
> @@ -993,12 +1008,10 @@ static void piix4_adap_remove(struct i2c_adapter *adap)
>  
>  static void piix4_remove(struct pci_dev *dev)
>  {
> - int port = PIIX4_MAX_ADAPTERS;

A one line change would do it just as well.
int port = piix4_adapter_count;

> -
> - while (--port >= 0) {
> - if (piix4_main_adapters[port]) {
> - piix4_adap_remove(piix4_main_adapters[port]);
> - piix4_main_adapters[port] = NULL;
> + while (--piix4_adapter_count >= 0) {
> + if (piix4_main_adapters[piix4_adapter_count]) {
> + 
> piix4_adap_remove(piix4_main_adapters[piix4_adapter_count]);
> + piix4_main_adapters[piix4_adapter_count] = NULL;
>   }
>   }
>  

[PATCH] ACPI / battery: Add quirk for Asus UX360UA and UX410UAK

[Kai-Heng Feng]

Same issue as other Asus laptops, ACPI incorrectly reports discharging
when battery is full and AC is plugged.

Use the same battery quirk can workaround the issue.

BugLink: https://bugs.launchpad.net/bugs/1661876
BugLink: https://bugs.launchpad.net/bugs/1745032
Signed-off-by: Kai-Heng Feng 
---
 drivers/acpi/battery.c | 16 
 1 file changed, 16 insertions(+)

diff --git a/drivers/acpi/battery.c b/drivers/acpi/battery.c
index 19bc440820e6..7128488a3a72 100644
--- a/drivers/acpi/battery.c
+++ b/drivers/acpi/battery.c
@@ -1209,6 +1209,22 @@ static const struct dmi_system_id bat_dmi_table[] 
__initconst = {
DMI_MATCH(DMI_PRODUCT_NAME, "UX305LA"),
},
},
+   {
+   .callback = battery_full_discharging_quirk,
+   .ident = "ASUS UX360UA",
+   .matches = {
+   DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),
+   DMI_MATCH(DMI_PRODUCT_NAME, "UX360UA"),
+   },
+   },
+   {
+   .callback = battery_full_discharging_quirk,
+   .ident = "ASUS UX410UAK",
+   .matches = {
+   DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),
+   DMI_MATCH(DMI_PRODUCT_NAME, "UX410UAK"),
+   },
+   },
{},
 };
 
-- 
2.15.1

[PATCH] ACPI / battery: Add quirk for Asus UX360UA and UX410UAK

[Kai-Heng Feng]

Same issue as other Asus laptops, ACPI incorrectly reports discharging
when battery is full and AC is plugged.

Use the same battery quirk can workaround the issue.

BugLink: https://bugs.launchpad.net/bugs/1661876
BugLink: https://bugs.launchpad.net/bugs/1745032
Signed-off-by: Kai-Heng Feng 
---
 drivers/acpi/battery.c | 16 
 1 file changed, 16 insertions(+)

diff --git a/drivers/acpi/battery.c b/drivers/acpi/battery.c
index 19bc440820e6..7128488a3a72 100644
--- a/drivers/acpi/battery.c
+++ b/drivers/acpi/battery.c
@@ -1209,6 +1209,22 @@ static const struct dmi_system_id bat_dmi_table[] 
__initconst = {
DMI_MATCH(DMI_PRODUCT_NAME, "UX305LA"),
},
},
+   {
+   .callback = battery_full_discharging_quirk,
+   .ident = "ASUS UX360UA",
+   .matches = {
+   DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),
+   DMI_MATCH(DMI_PRODUCT_NAME, "UX360UA"),
+   },
+   },
+   {
+   .callback = battery_full_discharging_quirk,
+   .ident = "ASUS UX410UAK",
+   .matches = {
+   DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),
+   DMI_MATCH(DMI_PRODUCT_NAME, "UX410UAK"),
+   },
+   },
{},
 };
 
-- 
2.15.1

[PATCH] ALSA: usb-audio: Fix UAC2 get_ctl request with a RANGE attribute

[Kirill Marinushkin]

The layout of the UAC2 Control request and response varies depending on
the request type. With the current implementation, only the Layout 2
Parameter Block (with the 2-byte sized RANGE attribute) is handled
properly. For the Control requests with the 1-byte sized RANGE attribute
(Bass Control, Mid Control, Tremble Control), the response is parsed
incorrectly.

This commit:
* fixes the wLength field value in the request
* fixes parsing the range values from the response

Fixes: 23caaf19b11e ("ALSA: usb-mixer: Add support for Audio Class v2.0")
Signed-off-by: Kirill Marinushkin 
Cc: Jaroslav Kysela 
Cc: Takashi Iwai 
Cc: Jaejoong Kim 
Cc: Bhumika Goyal 
Cc: Stephen Barber 
Cc: Julian Scheel 
Cc: alsa-de...@alsa-project.org
Cc: linux-kernel@vger.kernel.org
---
 sound/usb/mixer.c | 18 +++---
 1 file changed, 11 insertions(+), 7 deletions(-)

diff --git a/sound/usb/mixer.c b/sound/usb/mixer.c
index 2b4ceda36291..20b28a5a1456 100644
--- a/sound/usb/mixer.c
+++ b/sound/usb/mixer.c
@@ -347,17 +347,20 @@ static int get_ctl_value_v2(struct usb_mixer_elem_info 
*cval, int request,
int validx, int *value_ret)
 {
struct snd_usb_audio *chip = cval->head.mixer->chip;
-   unsigned char buf[4 + 3 * sizeof(__u32)]; /* enough space for one range 
*/
+   /* enough space for one range */
+   unsigned char buf[sizeof(__u16) + 3 * sizeof(__u32)];
unsigned char *val;
-   int idx = 0, ret, size;
+   int idx = 0, ret, val_size, size;
__u8 bRequest;
 
+   val_size = uac2_ctl_value_size(cval->val_type);
+
if (request == UAC_GET_CUR) {
bRequest = UAC2_CS_CUR;
-   size = uac2_ctl_value_size(cval->val_type);
+   size = val_size;
} else {
bRequest = UAC2_CS_RANGE;
-   size = sizeof(buf);
+   size = sizeof(__u16) + 3 * val_size;
}
 
memset(buf, 0, sizeof(buf));
@@ -390,16 +393,17 @@ static int get_ctl_value_v2(struct usb_mixer_elem_info 
*cval, int request,
val = buf + sizeof(__u16);
break;
case UAC_GET_MAX:
-   val = buf + sizeof(__u16) * 2;
+   val = buf + sizeof(__u16) + val_size;
break;
case UAC_GET_RES:
-   val = buf + sizeof(__u16) * 3;
+   val = buf + sizeof(__u16) + val_size * 2;
break;
default:
return -EINVAL;
}
 
-   *value_ret = convert_signed_value(cval, snd_usb_combine_bytes(val, 
sizeof(__u16)));
+   *value_ret = convert_signed_value(cval,
+ snd_usb_combine_bytes(val, val_size));
 
return 0;
 }
-- 
2.13.6

[PATCH] ALSA: usb-audio: Fix UAC2 get_ctl request with a RANGE attribute

[Kirill Marinushkin]

The layout of the UAC2 Control request and response varies depending on
the request type. With the current implementation, only the Layout 2
Parameter Block (with the 2-byte sized RANGE attribute) is handled
properly. For the Control requests with the 1-byte sized RANGE attribute
(Bass Control, Mid Control, Tremble Control), the response is parsed
incorrectly.

This commit:
* fixes the wLength field value in the request
* fixes parsing the range values from the response

Fixes: 23caaf19b11e ("ALSA: usb-mixer: Add support for Audio Class v2.0")
Signed-off-by: Kirill Marinushkin 
Cc: Jaroslav Kysela 
Cc: Takashi Iwai 
Cc: Jaejoong Kim 
Cc: Bhumika Goyal 
Cc: Stephen Barber 
Cc: Julian Scheel 
Cc: alsa-de...@alsa-project.org
Cc: linux-kernel@vger.kernel.org
---
 sound/usb/mixer.c | 18 +++---
 1 file changed, 11 insertions(+), 7 deletions(-)

diff --git a/sound/usb/mixer.c b/sound/usb/mixer.c
index 2b4ceda36291..20b28a5a1456 100644
--- a/sound/usb/mixer.c
+++ b/sound/usb/mixer.c
@@ -347,17 +347,20 @@ static int get_ctl_value_v2(struct usb_mixer_elem_info 
*cval, int request,
int validx, int *value_ret)
 {
struct snd_usb_audio *chip = cval->head.mixer->chip;
-   unsigned char buf[4 + 3 * sizeof(__u32)]; /* enough space for one range 
*/
+   /* enough space for one range */
+   unsigned char buf[sizeof(__u16) + 3 * sizeof(__u32)];
unsigned char *val;
-   int idx = 0, ret, size;
+   int idx = 0, ret, val_size, size;
__u8 bRequest;
 
+   val_size = uac2_ctl_value_size(cval->val_type);
+
if (request == UAC_GET_CUR) {
bRequest = UAC2_CS_CUR;
-   size = uac2_ctl_value_size(cval->val_type);
+   size = val_size;
} else {
bRequest = UAC2_CS_RANGE;
-   size = sizeof(buf);
+   size = sizeof(__u16) + 3 * val_size;
}
 
memset(buf, 0, sizeof(buf));
@@ -390,16 +393,17 @@ static int get_ctl_value_v2(struct usb_mixer_elem_info 
*cval, int request,
val = buf + sizeof(__u16);
break;
case UAC_GET_MAX:
-   val = buf + sizeof(__u16) * 2;
+   val = buf + sizeof(__u16) + val_size;
break;
case UAC_GET_RES:
-   val = buf + sizeof(__u16) * 3;
+   val = buf + sizeof(__u16) + val_size * 2;
break;
default:
return -EINVAL;
}
 
-   *value_ret = convert_signed_value(cval, snd_usb_combine_bytes(val, 
sizeof(__u16)));
+   *value_ret = convert_signed_value(cval,
+ snd_usb_combine_bytes(val, val_size));
 
return 0;
 }
-- 
2.13.6

Re: ppc elf_map breakage with MAP_FIXED_NOREPLACE

[Anshuman Khandual]

On 01/29/2018 08:17 AM, Anshuman Khandual wrote:
> On 01/26/2018 07:34 PM, Michal Hocko wrote:
>> On Fri 26-01-18 18:04:27, Anshuman Khandual wrote:
>> [...]
>>> I tried to instrument mmap_region() for a single instance of 'sed'
>>> binary and traced all it's VMA creation. But there is no trace when
>>> that 'anon' VMA got created which suddenly shows up during subsequent
>>> elf_map() call eventually failing it. Please note that the following
>>> VMA was never created through call into map_region() in the process
>>> which is strange.
>>
>> Could you share your debugging patch?
> 
> Please find the debug patch at the end.
> 
>>
>>> =
>>> [9.076867] Details for VMA[3] c01fce42b7c0
>>> [9.076925] vma c01fce42b7c0 start 1003 end 
>>> 1004
>>> next c01fce42b580 prev c01fce42b880 mm c01fce40fa00
>>> prot 8104 anon_vma   (null) vm_ops   (null)
>>> pgoff 1003 file   (null) private_data   (null)
>>> flags: 0x100073(read|write|mayread|maywrite|mayexec|account)
>>> =
>>
>> Isn't this vdso or some other special mapping? It is not really an
>> anonymous vma. Please hook into __install_special_mapping
> 
> Yeah, will do. Its not an anon mapping as it does not have a anon_vma
> structure ?

Okay, this colliding VMA seems to be getting loaded from load_elf_binary()
function as well.

[9.422410] vma c01fceedbc40 start 1003 end 1004
next c01fceedbe80 prev c01fceedb700 mm c01fceea8200
prot 8104 anon_vma   (null) vm_ops   (null)
pgoff 1003 file   (null) private_data   (null)
flags: 0x100073(read|write|mayread|maywrite|mayexec|account)
[9.422576] CPU: 46 PID: 7457 Comm: sed Not tainted 4.14.0-dirty #158
[9.422610] Call Trace:
[9.422623] [c01fdc4f79b0] [c0b17ac0] dump_stack+0xb0/0xf0 
(unreliable)
[9.422670] [c01fdc4f79f0] [c02dafb8] do_brk_flags+0x2d8/0x440
[9.422708] [c01fdc4f7ac0] [c02db3d0] vm_brk_flags+0x80/0x130
[9.422747] [c01fdc4f7b20] [c03d23a4] set_brk+0x80/0xdc
[9.422785] [c01fdc4f7b60] [c03d1f24] 
load_elf_binary+0x1304/0x158c
[9.422830] [c01fdc4f7c80] [c035d3e0] 
search_binary_handler+0xd0/0x270
[9.422881] [c01fdc4f7d10] [c035f338] 
do_execveat_common.isra.31+0x658/0x890
[9.422926] [c01fdc4f7df0] [c035f980] SyS_execve+0x40/0x50
[9.423588] [c01fdc4f7e30] [c000b220] system_call+0x58/0x6c

which is getting hit after adding some more debug.

@@ -2949,6 +2997,13 @@ static int do_brk_flags(unsigned long addr, unsigned 
long request, unsigned long
if (flags & VM_LOCKED)
mm->locked_vm += (len >> PAGE_SHIFT);
vma->vm_flags |= VM_SOFTDIRTY;
+
+   if (!strcmp(current->comm, "sed")) {
+   if (just_init && (mm_ptr == vma->vm_mm)) {
+   dump_vma(vma);
+   dump_stack();
+   }
+   }
return 0;
 }

Re: ppc elf_map breakage with MAP_FIXED_NOREPLACE

[Anshuman Khandual]

On 01/29/2018 08:17 AM, Anshuman Khandual wrote:
> On 01/26/2018 07:34 PM, Michal Hocko wrote:
>> On Fri 26-01-18 18:04:27, Anshuman Khandual wrote:
>> [...]
>>> I tried to instrument mmap_region() for a single instance of 'sed'
>>> binary and traced all it's VMA creation. But there is no trace when
>>> that 'anon' VMA got created which suddenly shows up during subsequent
>>> elf_map() call eventually failing it. Please note that the following
>>> VMA was never created through call into map_region() in the process
>>> which is strange.
>>
>> Could you share your debugging patch?
> 
> Please find the debug patch at the end.
> 
>>
>>> =
>>> [9.076867] Details for VMA[3] c01fce42b7c0
>>> [9.076925] vma c01fce42b7c0 start 1003 end 
>>> 1004
>>> next c01fce42b580 prev c01fce42b880 mm c01fce40fa00
>>> prot 8104 anon_vma   (null) vm_ops   (null)
>>> pgoff 1003 file   (null) private_data   (null)
>>> flags: 0x100073(read|write|mayread|maywrite|mayexec|account)
>>> =
>>
>> Isn't this vdso or some other special mapping? It is not really an
>> anonymous vma. Please hook into __install_special_mapping
> 
> Yeah, will do. Its not an anon mapping as it does not have a anon_vma
> structure ?

Okay, this colliding VMA seems to be getting loaded from load_elf_binary()
function as well.

[9.422410] vma c01fceedbc40 start 1003 end 1004
next c01fceedbe80 prev c01fceedb700 mm c01fceea8200
prot 8104 anon_vma   (null) vm_ops   (null)
pgoff 1003 file   (null) private_data   (null)
flags: 0x100073(read|write|mayread|maywrite|mayexec|account)
[9.422576] CPU: 46 PID: 7457 Comm: sed Not tainted 4.14.0-dirty #158
[9.422610] Call Trace:
[9.422623] [c01fdc4f79b0] [c0b17ac0] dump_stack+0xb0/0xf0 
(unreliable)
[9.422670] [c01fdc4f79f0] [c02dafb8] do_brk_flags+0x2d8/0x440
[9.422708] [c01fdc4f7ac0] [c02db3d0] vm_brk_flags+0x80/0x130
[9.422747] [c01fdc4f7b20] [c03d23a4] set_brk+0x80/0xdc
[9.422785] [c01fdc4f7b60] [c03d1f24] 
load_elf_binary+0x1304/0x158c
[9.422830] [c01fdc4f7c80] [c035d3e0] 
search_binary_handler+0xd0/0x270
[9.422881] [c01fdc4f7d10] [c035f338] 
do_execveat_common.isra.31+0x658/0x890
[9.422926] [c01fdc4f7df0] [c035f980] SyS_execve+0x40/0x50
[9.423588] [c01fdc4f7e30] [c000b220] system_call+0x58/0x6c

which is getting hit after adding some more debug.

@@ -2949,6 +2997,13 @@ static int do_brk_flags(unsigned long addr, unsigned 
long request, unsigned long
if (flags & VM_LOCKED)
mm->locked_vm += (len >> PAGE_SHIFT);
vma->vm_flags |= VM_SOFTDIRTY;
+
+   if (!strcmp(current->comm, "sed")) {
+   if (just_init && (mm_ptr == vma->vm_mm)) {
+   dump_vma(vma);
+   dump_stack();
+   }
+   }
return 0;
 }

Re: [patch V2 1/2] sysfs/cpu: Add vulnerability folder

[Jon Masters]

On 01/07/2018 04:48 PM, Thomas Gleixner wrote:

> +#ifdef CONFIG_GENERIC_CPU_VULNERABILITIES
> +
> +ssize_t __weak cpu_show_meltdown(struct device *dev,
> +  struct device_attribute *attr, char *buf)
> +{
> + return sprintf(buf, "Not affected\n");
> +}
> +
> +ssize_t __weak cpu_show_spectre_v1(struct device *dev,
> +struct device_attribute *attr, char *buf)
> +{
> + return sprintf(buf, "Not affected\n");
> +}
> +
> +ssize_t __weak cpu_show_spectre_v2(struct device *dev,
> +struct device_attribute *attr, char *buf)
> +{
> + return sprintf(buf, "Not affected\n");
> +}

Just wondering aloud (after the merge) here but shouldn't the default be
"unknown", at least for Spectre? It's pervasive enough.

Jon.

Re: [patch V2 1/2] sysfs/cpu: Add vulnerability folder

[Jon Masters]

On 01/07/2018 04:48 PM, Thomas Gleixner wrote:

> +#ifdef CONFIG_GENERIC_CPU_VULNERABILITIES
> +
> +ssize_t __weak cpu_show_meltdown(struct device *dev,
> +  struct device_attribute *attr, char *buf)
> +{
> + return sprintf(buf, "Not affected\n");
> +}
> +
> +ssize_t __weak cpu_show_spectre_v1(struct device *dev,
> +struct device_attribute *attr, char *buf)
> +{
> + return sprintf(buf, "Not affected\n");
> +}
> +
> +ssize_t __weak cpu_show_spectre_v2(struct device *dev,
> +struct device_attribute *attr, char *buf)
> +{
> + return sprintf(buf, "Not affected\n");
> +}

Just wondering aloud (after the merge) here but shouldn't the default be
"unknown", at least for Spectre? It's pervasive enough.

Jon.

Re: KASAN: use-after-free Write in irq_bypass_register_consumer

[Tianyu Lan]

On 1/27/2018 7:27 AM, Eric Biggers wrote:

On Sat, Dec 16, 2017 at 04:37:02PM +0800, Lan, Tianyu wrote:

The root cause is that kvm_irqfd_assign() and kvm_irqfd_deassign() can't
be run in parallel. Some data structure(e.g, irqfd->consumer) will be
crashed because irqfd may be freed in deassign path before they are used
in assign path. The other data maybe used in deassign path before
initialization. Syzbot test hit such case. Add mutx between
kvm_irqfd_assign() and kvm_irqfd_deassign() can fix such issue. Will
send patch to fix it.

On 12/16/2017 12:53 PM, Tianyu Lan wrote:

I reproduced the issue. Will have a look.

-- Best regards Tianyu Lan 2017-12-15 18:14 GMT+08:00 syzbot
:

syzkaller has found reproducer for the following crash on
82bcf1def3b5f1251177ad47c44f7e17af039b4b
git://git.cmpxchg.org/linux-mmots.git/master
compiler: gcc (GCC) 7.1.1 20170620
.config is attached
Raw console output is attached.
C reproducer is attached
syzkaller reproducer is attached. Seehttps://goo.gl/kgGztJ
for information about syzkaller reproducers


==
BUG: KASAN: use-after-free in __list_add include/linux/list.h:64 [inline]
BUG: KASAN: use-after-free in list_add include/linux/list.h:79 [inline]
BUG: KASAN: use-after-free in irq_bypass_register_consumer+0x4b4/0x500
virt/lib/irqbypass.c:217
Write of size 8 at addr 8801cdf51180 by task syzkaller436086/15031

CPU: 1 PID: 15031 Comm: syzkaller436086 Not tainted 4.15.0-rc2-mm1+ #39
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Call Trace:
   __dump_stack lib/dump_stack.c:17 [inline]
   dump_stack+0x194/0x257 lib/dump_stack.c:53
   print_address_description+0x73/0x250 mm/kasan/report.c:252
   kasan_report_error mm/kasan/report.c:351 [inline]
   kasan_report+0x25b/0x340 mm/kasan/report.c:409
   __asan_report_store8_noabort+0x17/0x20 mm/kasan/report.c:435
   __list_add include/linux/list.h:64 [inline]
   list_add include/linux/list.h:79 [inline]
   irq_bypass_register_consumer+0x4b4/0x500 virt/lib/irqbypass.c:217
   kvm_irqfd_assign arch/x86/kvm/../../../virt/kvm/eventfd.c:417 [inline]
   kvm_irqfd+0x137f/0x1d50 arch/x86/kvm/../../../virt/kvm/eventfd.c:572
   kvm_vm_ioctl+0x1079/0x1c40 arch/x86/kvm/../../../virt/kvm/kvm_main.c:2992
   vfs_ioctl fs/ioctl.c:46 [inline]
   do_vfs_ioctl+0x1b1/0x1530 fs/ioctl.c:686
   SYSC_ioctl fs/ioctl.c:701 [inline]
   SyS_ioctl+0x8f/0xc0 fs/ioctl.c:692
   entry_SYSCALL_64_fastpath+0x1f/0x96
RIP: 0033:0x44d379
RSP: 002b:7fc5ff9a9d08 EFLAGS: 0246 ORIG_RAX: 0010
RAX: ffda RBX: 7fc5ff9aa700 RCX: 0044d379
RDX: 20080fe0 RSI: 4020ae76 RDI: 0005
RBP: 007ff900 R08: 7fc5ff9aa700 R09: 7fc5ff9aa700
R10: 7fc5ff9aa700 R11: 0246 R12: 
R13: 007ff8ff R14: 7fc5ff9aa9c0 R15: 

Allocated by task 15031:
   save_stack+0x43/0xd0 mm/kasan/kasan.c:447
   set_track mm/kasan/kasan.c:459 [inline]
   kasan_kmalloc+0xad/0xe0 mm/kasan/kasan.c:551
   kmem_cache_alloc_trace+0x136/0x750 mm/slab.c:3614
   kmalloc include/linux/slab.h:516 [inline]
   kzalloc include/linux/slab.h:705 [inline]
   kvm_irqfd_assign arch/x86/kvm/../../../virt/kvm/eventfd.c:296 [inline]
   kvm_irqfd+0x16c/0x1d50 arch/x86/kvm/../../../virt/kvm/eventfd.c:572
   kvm_vm_ioctl+0x1079/0x1c40 arch/x86/kvm/../../../virt/kvm/kvm_main.c:2992
   vfs_ioctl fs/ioctl.c:46 [inline]
   do_vfs_ioctl+0x1b1/0x1530 fs/ioctl.c:686
   SYSC_ioctl fs/ioctl.c:701 [inline]
   SyS_ioctl+0x8f/0xc0 fs/ioctl.c:692
   entry_SYSCALL_64_fastpath+0x1f/0x96

Freed by task 1402:
   save_stack+0x43/0xd0 mm/kasan/kasan.c:447
   set_track mm/kasan/kasan.c:459 [inline]
   kasan_slab_free+0x71/0xc0 mm/kasan/kasan.c:524
   __cache_free mm/slab.c:3492 [inline]
   kfree+0xca/0x250 mm/slab.c:3807
   irqfd_shutdown+0x13c/0x1a0 arch/x86/kvm/../../../virt/kvm/eventfd.c:148
   process_one_work+0xbfd/0x1bc0 kernel/workqueue.c:2113
   worker_thread+0x223/0x1990 kernel/workqueue.c:2247
   kthread+0x37a/0x440 kernel/kthread.c:238
   ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:524

The buggy address belongs to the object at 8801cdf51000
   which belongs to the cache kmalloc-512 of size 512
The buggy address is located 384 bytes inside of
   512-byte region [8801cdf51000, 8801cdf51200)
The buggy address belongs to the page:
page:d08a0d63 count:1 mapcount:0 mapping:d54c7be6 index:0x0
flags: 0x2fffc000100(slab)
raw: 02fffc000100 8801cdf51000  00010006
raw: ea00073a7660 ea000737f3a0 8801dac00940 
page dumped because: kasan: bad access detected

Memory state around the buggy address:
   8801cdf51080: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
   8801cdf51100: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb

8801cdf51180: 

Re: KASAN: use-after-free Write in irq_bypass_register_consumer

[Tianyu Lan]

On 1/27/2018 7:27 AM, Eric Biggers wrote:

On Sat, Dec 16, 2017 at 04:37:02PM +0800, Lan, Tianyu wrote:

The root cause is that kvm_irqfd_assign() and kvm_irqfd_deassign() can't
be run in parallel. Some data structure(e.g, irqfd->consumer) will be
crashed because irqfd may be freed in deassign path before they are used
in assign path. The other data maybe used in deassign path before
initialization. Syzbot test hit such case. Add mutx between
kvm_irqfd_assign() and kvm_irqfd_deassign() can fix such issue. Will
send patch to fix it.

On 12/16/2017 12:53 PM, Tianyu Lan wrote:

I reproduced the issue. Will have a look.

-- Best regards Tianyu Lan 2017-12-15 18:14 GMT+08:00 syzbot
:

syzkaller has found reproducer for the following crash on
82bcf1def3b5f1251177ad47c44f7e17af039b4b
git://git.cmpxchg.org/linux-mmots.git/master
compiler: gcc (GCC) 7.1.1 20170620
.config is attached
Raw console output is attached.
C reproducer is attached
syzkaller reproducer is attached. Seehttps://goo.gl/kgGztJ
for information about syzkaller reproducers


==
BUG: KASAN: use-after-free in __list_add include/linux/list.h:64 [inline]
BUG: KASAN: use-after-free in list_add include/linux/list.h:79 [inline]
BUG: KASAN: use-after-free in irq_bypass_register_consumer+0x4b4/0x500
virt/lib/irqbypass.c:217
Write of size 8 at addr 8801cdf51180 by task syzkaller436086/15031

CPU: 1 PID: 15031 Comm: syzkaller436086 Not tainted 4.15.0-rc2-mm1+ #39
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Call Trace:
   __dump_stack lib/dump_stack.c:17 [inline]
   dump_stack+0x194/0x257 lib/dump_stack.c:53
   print_address_description+0x73/0x250 mm/kasan/report.c:252
   kasan_report_error mm/kasan/report.c:351 [inline]
   kasan_report+0x25b/0x340 mm/kasan/report.c:409
   __asan_report_store8_noabort+0x17/0x20 mm/kasan/report.c:435
   __list_add include/linux/list.h:64 [inline]
   list_add include/linux/list.h:79 [inline]
   irq_bypass_register_consumer+0x4b4/0x500 virt/lib/irqbypass.c:217
   kvm_irqfd_assign arch/x86/kvm/../../../virt/kvm/eventfd.c:417 [inline]
   kvm_irqfd+0x137f/0x1d50 arch/x86/kvm/../../../virt/kvm/eventfd.c:572
   kvm_vm_ioctl+0x1079/0x1c40 arch/x86/kvm/../../../virt/kvm/kvm_main.c:2992
   vfs_ioctl fs/ioctl.c:46 [inline]
   do_vfs_ioctl+0x1b1/0x1530 fs/ioctl.c:686
   SYSC_ioctl fs/ioctl.c:701 [inline]
   SyS_ioctl+0x8f/0xc0 fs/ioctl.c:692
   entry_SYSCALL_64_fastpath+0x1f/0x96
RIP: 0033:0x44d379
RSP: 002b:7fc5ff9a9d08 EFLAGS: 0246 ORIG_RAX: 0010
RAX: ffda RBX: 7fc5ff9aa700 RCX: 0044d379
RDX: 20080fe0 RSI: 4020ae76 RDI: 0005
RBP: 007ff900 R08: 7fc5ff9aa700 R09: 7fc5ff9aa700
R10: 7fc5ff9aa700 R11: 0246 R12: 
R13: 007ff8ff R14: 7fc5ff9aa9c0 R15: 

Allocated by task 15031:
   save_stack+0x43/0xd0 mm/kasan/kasan.c:447
   set_track mm/kasan/kasan.c:459 [inline]
   kasan_kmalloc+0xad/0xe0 mm/kasan/kasan.c:551
   kmem_cache_alloc_trace+0x136/0x750 mm/slab.c:3614
   kmalloc include/linux/slab.h:516 [inline]
   kzalloc include/linux/slab.h:705 [inline]
   kvm_irqfd_assign arch/x86/kvm/../../../virt/kvm/eventfd.c:296 [inline]
   kvm_irqfd+0x16c/0x1d50 arch/x86/kvm/../../../virt/kvm/eventfd.c:572
   kvm_vm_ioctl+0x1079/0x1c40 arch/x86/kvm/../../../virt/kvm/kvm_main.c:2992
   vfs_ioctl fs/ioctl.c:46 [inline]
   do_vfs_ioctl+0x1b1/0x1530 fs/ioctl.c:686
   SYSC_ioctl fs/ioctl.c:701 [inline]
   SyS_ioctl+0x8f/0xc0 fs/ioctl.c:692
   entry_SYSCALL_64_fastpath+0x1f/0x96

Freed by task 1402:
   save_stack+0x43/0xd0 mm/kasan/kasan.c:447
   set_track mm/kasan/kasan.c:459 [inline]
   kasan_slab_free+0x71/0xc0 mm/kasan/kasan.c:524
   __cache_free mm/slab.c:3492 [inline]
   kfree+0xca/0x250 mm/slab.c:3807
   irqfd_shutdown+0x13c/0x1a0 arch/x86/kvm/../../../virt/kvm/eventfd.c:148
   process_one_work+0xbfd/0x1bc0 kernel/workqueue.c:2113
   worker_thread+0x223/0x1990 kernel/workqueue.c:2247
   kthread+0x37a/0x440 kernel/kthread.c:238
   ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:524

The buggy address belongs to the object at 8801cdf51000
   which belongs to the cache kmalloc-512 of size 512
The buggy address is located 384 bytes inside of
   512-byte region [8801cdf51000, 8801cdf51200)
The buggy address belongs to the page:
page:d08a0d63 count:1 mapcount:0 mapping:d54c7be6 index:0x0
flags: 0x2fffc000100(slab)
raw: 02fffc000100 8801cdf51000  00010006
raw: ea00073a7660 ea000737f3a0 8801dac00940 
page dumped because: kasan: bad access detected

Memory state around the buggy address:
   8801cdf51080: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
   8801cdf51100: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb

8801cdf51180: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb

 ^

[PATCH 02/15] ARM: dts: ipq4019: Add a few peripheral nodes

[Sricharan R]

Now with the driver updates for some peripherals being there,
add i2c, spi, pcie, bam, qpic-nand, scm nodes to enhance the available
peripheral support.

Signed-off-by: Sricharan R 
---
 arch/arm/boot/dts/qcom-ipq4019.dtsi | 134 
 1 file changed, 134 insertions(+)

diff --git a/arch/arm/boot/dts/qcom-ipq4019.dtsi 
b/arch/arm/boot/dts/qcom-ipq4019.dtsi
index 10d112a..e38fffa 100644
--- a/arch/arm/boot/dts/qcom-ipq4019.dtsi
+++ b/arch/arm/boot/dts/qcom-ipq4019.dtsi
@@ -25,7 +25,9 @@
 
aliases {
spi0 = _0;
+   spi1 = _1;
i2c0 = _0;
+   i2c1 = _1;
};
 
cpus {
@@ -104,6 +106,12 @@
};
};
 
+   firmware {
+   scm {
+   compatible = "qcom,scm-ipq4019";
+   };
+   };
+
timer {
compatible = "arm,armv7-timer";
interrupts = <1 2 0xf08>,
@@ -172,6 +180,22 @@
clock-names = "core", "iface";
#address-cells = <1>;
#size-cells = <0>;
+   dmas = <_dma 5>, <_dma 4>;
+   dma-names = "rx", "tx";
+   status = "disabled";
+   };
+
+   spi_1: spi@78b6000 { /* BLSP1 QUP2 */
+   compatible = "qcom,spi-qup-v2.2.1";
+   reg = <0x78b6000 0x600>;
+   interrupts = ;
+   clocks = < GCC_BLSP1_QUP2_SPI_APPS_CLK>,
+   < GCC_BLSP1_AHB_CLK>;
+   clock-names = "core", "iface";
+   #address-cells = <1>;
+   #size-cells = <0>;
+   dmas = <_dma 7>, <_dma 6>;
+   dma-names = "rx", "tx";
status = "disabled";
};
 
@@ -184,9 +208,24 @@
clock-names = "iface", "core";
#address-cells = <1>;
#size-cells = <0>;
+   dmas = <_dma 9>, <_dma 8>;
+   dma-names = "rx", "tx";
status = "disabled";
};
 
+   i2c_1: i2c@78b8000 { /* BLSP1 QUP4 */
+   compatible = "qcom,i2c-qup-v2.2.1";
+   reg = <0x78b8000 0x600>;
+   interrupts = ;
+   clocks = < GCC_BLSP1_AHB_CLK>,
+< GCC_BLSP1_QUP2_I2C_APPS_CLK>;
+   clock-names = "iface", "core";
+   #address-cells = <1>;
+   #size-cells = <0>;
+   dmas = <_dma 11>, <_dma 10>;
+   dma-names = "rx", "tx";
+   status = "disabled";
+   };
 
cryptobam: dma@8e04000 {
compatible = "qcom,bam-v1.7.0";
@@ -293,6 +332,101 @@
reg = <0x4ab000 0x4>;
};
 
+   pcie0: pci@4000 {
+   compatible = "qcom,pcie-ipq4019", "snps,dw-pcie";
+   reg =  <0x4000 0xf1d
+   0x4f20 0xa8
+   0x8 0x2000
+   0x4010 0x1000>;
+   reg-names = "dbi", "elbi", "parf", "config";
+   device_type = "pci";
+   linux,pci-domain = <0>;
+   bus-range = <0x00 0xff>;
+   num-lanes = <1>;
+   #address-cells = <3>;
+   #size-cells = <2>;
+
+   ranges = <0x8100 0 0x4020 0x4020 0 
0x0010
+ 0x8200 0 0x4800 0x4800 0 
0x1000>;
+
+   interrupts = ;
+   interrupt-names = "msi";
+   #interrupt-cells = <1>;
+   interrupt-map-mask = <0 0 0 0x7>;
+   interrupt-map = <0 0 0 1  0 142 
IRQ_TYPE_LEVEL_HIGH>, /* int_a */
+   <0 0 0 2  0 143 
IRQ_TYPE_LEVEL_HIGH>, /* int_b */
+   <0 0 0 3  0 144 
IRQ_TYPE_LEVEL_HIGH>, /* int_c */
+   <0 0 0 4  0 145 
IRQ_TYPE_LEVEL_HIGH>; /* int_d */
+   clocks = < GCC_PCIE_AHB_CLK>,
+< GCC_PCIE_AXI_M_CLK>,
+< GCC_PCIE_AXI_S_CLK>;
+   clock-names = "aux",
+ "master_bus",
+ "slave_bus";
+
+   resets = < PCIE_AXI_M_ARES>,
+< PCIE_AXI_S_ARES>,
+< PCIE_PIPE_ARES>,
+< 

[PATCH 02/15] ARM: dts: ipq4019: Add a few peripheral nodes

[Sricharan R]

Now with the driver updates for some peripherals being there,
add i2c, spi, pcie, bam, qpic-nand, scm nodes to enhance the available
peripheral support.

Signed-off-by: Sricharan R 
---
 arch/arm/boot/dts/qcom-ipq4019.dtsi | 134 
 1 file changed, 134 insertions(+)

diff --git a/arch/arm/boot/dts/qcom-ipq4019.dtsi 
b/arch/arm/boot/dts/qcom-ipq4019.dtsi
index 10d112a..e38fffa 100644
--- a/arch/arm/boot/dts/qcom-ipq4019.dtsi
+++ b/arch/arm/boot/dts/qcom-ipq4019.dtsi
@@ -25,7 +25,9 @@
 
aliases {
spi0 = _0;
+   spi1 = _1;
i2c0 = _0;
+   i2c1 = _1;
};
 
cpus {
@@ -104,6 +106,12 @@
};
};
 
+   firmware {
+   scm {
+   compatible = "qcom,scm-ipq4019";
+   };
+   };
+
timer {
compatible = "arm,armv7-timer";
interrupts = <1 2 0xf08>,
@@ -172,6 +180,22 @@
clock-names = "core", "iface";
#address-cells = <1>;
#size-cells = <0>;
+   dmas = <_dma 5>, <_dma 4>;
+   dma-names = "rx", "tx";
+   status = "disabled";
+   };
+
+   spi_1: spi@78b6000 { /* BLSP1 QUP2 */
+   compatible = "qcom,spi-qup-v2.2.1";
+   reg = <0x78b6000 0x600>;
+   interrupts = ;
+   clocks = < GCC_BLSP1_QUP2_SPI_APPS_CLK>,
+   < GCC_BLSP1_AHB_CLK>;
+   clock-names = "core", "iface";
+   #address-cells = <1>;
+   #size-cells = <0>;
+   dmas = <_dma 7>, <_dma 6>;
+   dma-names = "rx", "tx";
status = "disabled";
};
 
@@ -184,9 +208,24 @@
clock-names = "iface", "core";
#address-cells = <1>;
#size-cells = <0>;
+   dmas = <_dma 9>, <_dma 8>;
+   dma-names = "rx", "tx";
status = "disabled";
};
 
+   i2c_1: i2c@78b8000 { /* BLSP1 QUP4 */
+   compatible = "qcom,i2c-qup-v2.2.1";
+   reg = <0x78b8000 0x600>;
+   interrupts = ;
+   clocks = < GCC_BLSP1_AHB_CLK>,
+< GCC_BLSP1_QUP2_I2C_APPS_CLK>;
+   clock-names = "iface", "core";
+   #address-cells = <1>;
+   #size-cells = <0>;
+   dmas = <_dma 11>, <_dma 10>;
+   dma-names = "rx", "tx";
+   status = "disabled";
+   };
 
cryptobam: dma@8e04000 {
compatible = "qcom,bam-v1.7.0";
@@ -293,6 +332,101 @@
reg = <0x4ab000 0x4>;
};
 
+   pcie0: pci@4000 {
+   compatible = "qcom,pcie-ipq4019", "snps,dw-pcie";
+   reg =  <0x4000 0xf1d
+   0x4f20 0xa8
+   0x8 0x2000
+   0x4010 0x1000>;
+   reg-names = "dbi", "elbi", "parf", "config";
+   device_type = "pci";
+   linux,pci-domain = <0>;
+   bus-range = <0x00 0xff>;
+   num-lanes = <1>;
+   #address-cells = <3>;
+   #size-cells = <2>;
+
+   ranges = <0x8100 0 0x4020 0x4020 0 
0x0010
+ 0x8200 0 0x4800 0x4800 0 
0x1000>;
+
+   interrupts = ;
+   interrupt-names = "msi";
+   #interrupt-cells = <1>;
+   interrupt-map-mask = <0 0 0 0x7>;
+   interrupt-map = <0 0 0 1  0 142 
IRQ_TYPE_LEVEL_HIGH>, /* int_a */
+   <0 0 0 2  0 143 
IRQ_TYPE_LEVEL_HIGH>, /* int_b */
+   <0 0 0 3  0 144 
IRQ_TYPE_LEVEL_HIGH>, /* int_c */
+   <0 0 0 4  0 145 
IRQ_TYPE_LEVEL_HIGH>; /* int_d */
+   clocks = < GCC_PCIE_AHB_CLK>,
+< GCC_PCIE_AXI_M_CLK>,
+< GCC_PCIE_AXI_S_CLK>;
+   clock-names = "aux",
+ "master_bus",
+ "slave_bus";
+
+   resets = < PCIE_AXI_M_ARES>,
+< PCIE_AXI_S_ARES>,
+< PCIE_PIPE_ARES>,
+< PCIE_AXI_M_VMIDMT_ARES>,
+ 

Re: [PATCH] mm/swap.c: fix kernel-doc functions and parameters

[Matthew Wilcox]

On Sun, Jan 28, 2018 at 08:01:08PM -0800, Randy Dunlap wrote:
> @@ -400,6 +400,10 @@ void mark_page_accessed(struct page *pag
>  }
>  EXPORT_SYMBOL(mark_page_accessed);
>  
> +/**
> + * __lru_cache_add: add a page to the page lists
> + * @page: the page to add
> + */
>  static void __lru_cache_add(struct page *page)
>  {
>   struct pagevec *pvec = _cpu_var(lru_add_pvec);
> @@ -410,10 +414,6 @@ static void __lru_cache_add(struct page
>   put_cpu_var(lru_add_pvec);
>  }
>  
> -/**
> - * lru_cache_add: add a page to the page lists
> - * @page: the page to add
> - */
>  void lru_cache_add_anon(struct page *page)
>  {
>   if (PageActive(page))

I don't see the point in adding kernel-doc for a static function while
deleting it for a non-static function?  I'd change the name of the
function in the second hunk and drop the first hunk.

Also, the comment doesn't actually fit the kernel-doc format (colon
versus hyphen; missing capitalisation and full-stop).

> @@ -913,11 +913,11 @@ EXPORT_SYMBOL(__pagevec_lru_add);
>   * @pvec:Where the resulting entries are placed
>   * @mapping: The address_space to search
>   * @start:   The starting entry index
> - * @nr_entries:  The maximum number of entries
> + * @nr_pages:The maximum number of entries
>   * @indices: The cache indices corresponding to the entries in @pvec
>   *
>   * pagevec_lookup_entries() will search for and return a group of up
> - * to @nr_entries pages and shadow entries in the mapping.  All
> + * to @nr_pages pages and shadow entries in the mapping.  All
>   * entries are placed in @pvec.  pagevec_lookup_entries() takes a
>   * reference against actual pages in @pvec.
>   *

I think the documentation has the right name here; it is the number of
entries and not the number of pages which is returned.  We should change
the code to match the documentation here ;-)

[PATCH 01/15] firmware: qcom: scm: Add ipq4019 soc compatible

[Sricharan R]

Add the compatible for ipq4019.
This does not need clocks to do scm calls.

Signed-off-by: Sricharan R 
---
 Documentation/devicetree/bindings/firmware/qcom,scm.txt | 3 ++-
 drivers/firmware/qcom_scm.c | 3 +++
 2 files changed, 5 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/firmware/qcom,scm.txt 
b/Documentation/devicetree/bindings/firmware/qcom,scm.txt
index 7b40054..fcf6979 100644
--- a/Documentation/devicetree/bindings/firmware/qcom,scm.txt
+++ b/Documentation/devicetree/bindings/firmware/qcom,scm.txt
@@ -11,9 +11,10 @@ Required properties:
  * "qcom,scm-msm8660" for MSM8660 platforms
  * "qcom,scm-msm8690" for MSM8690 platforms
  * "qcom,scm-msm8996" for MSM8996 platforms
+ * "qcom,scm-ipq4019" for IPQ4019 platforms
  * "qcom,scm" for later processors (MSM8916, APQ8084, MSM8974, etc)
 - clocks: One to three clocks may be required based on compatible.
- * No clock required for "qcom,scm-msm8996"
+ * No clock required for "qcom,scm-msm8996", "qcom,scm-ipq4019"
  * Only core clock required for "qcom,scm-apq8064", "qcom,scm-msm8660", and 
"qcom,scm-msm8960"
  * Core, iface, and bus clocks required for "qcom,scm"
 - clock-names: Must contain "core" for the core clock, "iface" for the 
interface
diff --git a/drivers/firmware/qcom_scm.c b/drivers/firmware/qcom_scm.c
index af4c752..ddc9ea8 100644
--- a/drivers/firmware/qcom_scm.c
+++ b/drivers/firmware/qcom_scm.c
@@ -603,6 +603,9 @@ static void qcom_scm_shutdown(struct platform_device *pdev)
{ .compatible = "qcom,scm-msm8996",
  .data = NULL, /* no clocks */
},
+   { .compatible = "qcom,scm-ipq4019",
+ .data = NULL, /* no clocks */
+   },
{ .compatible = "qcom,scm",
  .data = (void *)(SCM_HAS_CORE_CLK
   | SCM_HAS_IFACE_CLK
-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of 
Code Aurora Forum, hosted by The Linux Foundation

Re: [PATCH] mm/swap.c: fix kernel-doc functions and parameters

[Matthew Wilcox]

On Sun, Jan 28, 2018 at 08:01:08PM -0800, Randy Dunlap wrote:
> @@ -400,6 +400,10 @@ void mark_page_accessed(struct page *pag
>  }
>  EXPORT_SYMBOL(mark_page_accessed);
>  
> +/**
> + * __lru_cache_add: add a page to the page lists
> + * @page: the page to add
> + */
>  static void __lru_cache_add(struct page *page)
>  {
>   struct pagevec *pvec = _cpu_var(lru_add_pvec);
> @@ -410,10 +414,6 @@ static void __lru_cache_add(struct page
>   put_cpu_var(lru_add_pvec);
>  }
>  
> -/**
> - * lru_cache_add: add a page to the page lists
> - * @page: the page to add
> - */
>  void lru_cache_add_anon(struct page *page)
>  {
>   if (PageActive(page))

I don't see the point in adding kernel-doc for a static function while
deleting it for a non-static function?  I'd change the name of the
function in the second hunk and drop the first hunk.

Also, the comment doesn't actually fit the kernel-doc format (colon
versus hyphen; missing capitalisation and full-stop).

> @@ -913,11 +913,11 @@ EXPORT_SYMBOL(__pagevec_lru_add);
>   * @pvec:Where the resulting entries are placed
>   * @mapping: The address_space to search
>   * @start:   The starting entry index
> - * @nr_entries:  The maximum number of entries
> + * @nr_pages:The maximum number of entries
>   * @indices: The cache indices corresponding to the entries in @pvec
>   *
>   * pagevec_lookup_entries() will search for and return a group of up
> - * to @nr_entries pages and shadow entries in the mapping.  All
> + * to @nr_pages pages and shadow entries in the mapping.  All
>   * entries are placed in @pvec.  pagevec_lookup_entries() takes a
>   * reference against actual pages in @pvec.
>   *

I think the documentation has the right name here; it is the number of
entries and not the number of pages which is returned.  We should change
the code to match the documentation here ;-)

[PATCH 01/15] firmware: qcom: scm: Add ipq4019 soc compatible

[Sricharan R]

Add the compatible for ipq4019.
This does not need clocks to do scm calls.

Signed-off-by: Sricharan R 
---
 Documentation/devicetree/bindings/firmware/qcom,scm.txt | 3 ++-
 drivers/firmware/qcom_scm.c | 3 +++
 2 files changed, 5 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/firmware/qcom,scm.txt 
b/Documentation/devicetree/bindings/firmware/qcom,scm.txt
index 7b40054..fcf6979 100644
--- a/Documentation/devicetree/bindings/firmware/qcom,scm.txt
+++ b/Documentation/devicetree/bindings/firmware/qcom,scm.txt
@@ -11,9 +11,10 @@ Required properties:
  * "qcom,scm-msm8660" for MSM8660 platforms
  * "qcom,scm-msm8690" for MSM8690 platforms
  * "qcom,scm-msm8996" for MSM8996 platforms
+ * "qcom,scm-ipq4019" for IPQ4019 platforms
  * "qcom,scm" for later processors (MSM8916, APQ8084, MSM8974, etc)
 - clocks: One to three clocks may be required based on compatible.
- * No clock required for "qcom,scm-msm8996"
+ * No clock required for "qcom,scm-msm8996", "qcom,scm-ipq4019"
  * Only core clock required for "qcom,scm-apq8064", "qcom,scm-msm8660", and 
"qcom,scm-msm8960"
  * Core, iface, and bus clocks required for "qcom,scm"
 - clock-names: Must contain "core" for the core clock, "iface" for the 
interface
diff --git a/drivers/firmware/qcom_scm.c b/drivers/firmware/qcom_scm.c
index af4c752..ddc9ea8 100644
--- a/drivers/firmware/qcom_scm.c
+++ b/drivers/firmware/qcom_scm.c
@@ -603,6 +603,9 @@ static void qcom_scm_shutdown(struct platform_device *pdev)
{ .compatible = "qcom,scm-msm8996",
  .data = NULL, /* no clocks */
},
+   { .compatible = "qcom,scm-ipq4019",
+ .data = NULL, /* no clocks */
+   },
{ .compatible = "qcom,scm",
  .data = (void *)(SCM_HAS_CORE_CLK
   | SCM_HAS_IFACE_CLK
-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of 
Code Aurora Forum, hosted by The Linux Foundation

[PATCH 08/15] ARM: dts: ipq4019: Add qcom-ipq4019-ap.dk04.1-c5 board file

[Sricharan R]

dk04.1-c5 has a spinand connected to spi bus0 chipselect 1.

Signed-off-by: Sricharan R 
---
 arch/arm/boot/dts/Makefile  |  1 +
 arch/arm/boot/dts/qcom-ipq4019-ap.dk04.1-c5.dts | 23 +++
 2 files changed, 24 insertions(+)
 create mode 100644 arch/arm/boot/dts/qcom-ipq4019-ap.dk04.1-c5.dts

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 1a8ab050..68e4b15 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -726,6 +726,7 @@ dtb-$(CONFIG_ARCH_QCOM) += \
qcom-ipq4019-ap.dk01.1-c1.dtb \
qcom-ipq4019-ap.dk01.1-c2.dtb \
qcom-ipq4019-ap.dk04.1-c1.dtb \
+   qcom-ipq4019-ap.dk04.1-c5.dtb \
qcom-ipq8064-ap148.dtb \
qcom-msm8660-surf.dtb \
qcom-msm8960-cdp.dtb \
diff --git a/arch/arm/boot/dts/qcom-ipq4019-ap.dk04.1-c5.dts 
b/arch/arm/boot/dts/qcom-ipq4019-ap.dk04.1-c5.dts
new file mode 100644
index 000..270b197
--- /dev/null
+++ b/arch/arm/boot/dts/qcom-ipq4019-ap.dk04.1-c5.dts
@@ -0,0 +1,23 @@
+// SPDX-License-Identifier: GPL-2.0
+// Copyright (c) 2017, The Linux Foundation. All rights reserved.
+
+#include "qcom-ipq4019-ap.dk04.1.dtsi"
+/ {
+   model = "Qualcomm Technologies, Inc. IPQ4019/AP-DK04.1-C5";
+
+   soc {
+   spi_0: spi@78b5000 { /* BLSP1 QUP1 */
+   status = "ok";
+   cs-gpios = < 12 0>, < 45 0>;
+   num-cs = <2>;
+
+   mt29f@1 {
+   #address-cells = <1>;
+   #size-cells = <1>;
+   compatible = "spinand,mt29f";
+   reg = <1>;
+   spi-max-frequency = <2400>;
+   };
+   };
+   };
+};
-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of 
Code Aurora Forum, hosted by The Linux Foundation

[PATCH 08/15] ARM: dts: ipq4019: Add qcom-ipq4019-ap.dk04.1-c5 board file

[Sricharan R]

dk04.1-c5 has a spinand connected to spi bus0 chipselect 1.

Signed-off-by: Sricharan R 
---
 arch/arm/boot/dts/Makefile  |  1 +
 arch/arm/boot/dts/qcom-ipq4019-ap.dk04.1-c5.dts | 23 +++
 2 files changed, 24 insertions(+)
 create mode 100644 arch/arm/boot/dts/qcom-ipq4019-ap.dk04.1-c5.dts

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 1a8ab050..68e4b15 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -726,6 +726,7 @@ dtb-$(CONFIG_ARCH_QCOM) += \
qcom-ipq4019-ap.dk01.1-c1.dtb \
qcom-ipq4019-ap.dk01.1-c2.dtb \
qcom-ipq4019-ap.dk04.1-c1.dtb \
+   qcom-ipq4019-ap.dk04.1-c5.dtb \
qcom-ipq8064-ap148.dtb \
qcom-msm8660-surf.dtb \
qcom-msm8960-cdp.dtb \
diff --git a/arch/arm/boot/dts/qcom-ipq4019-ap.dk04.1-c5.dts 
b/arch/arm/boot/dts/qcom-ipq4019-ap.dk04.1-c5.dts
new file mode 100644
index 000..270b197
--- /dev/null
+++ b/arch/arm/boot/dts/qcom-ipq4019-ap.dk04.1-c5.dts
@@ -0,0 +1,23 @@
+// SPDX-License-Identifier: GPL-2.0
+// Copyright (c) 2017, The Linux Foundation. All rights reserved.
+
+#include "qcom-ipq4019-ap.dk04.1.dtsi"
+/ {
+   model = "Qualcomm Technologies, Inc. IPQ4019/AP-DK04.1-C5";
+
+   soc {
+   spi_0: spi@78b5000 { /* BLSP1 QUP1 */
+   status = "ok";
+   cs-gpios = < 12 0>, < 45 0>;
+   num-cs = <2>;
+
+   mt29f@1 {
+   #address-cells = <1>;
+   #size-cells = <1>;
+   compatible = "spinand,mt29f";
+   reg = <1>;
+   spi-max-frequency = <2400>;
+   };
+   };
+   };
+};
-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of 
Code Aurora Forum, hosted by The Linux Foundation

[PATCH 05/15] ARM: dts: ipq4019: Add ipq4019-ap-dk01-c2 board file

[Sricharan R]

The board has a spi-nand interface on spi0 bus chipselect1.

Signed-off-by: Sricharan R 
---
 arch/arm/boot/dts/Makefile  |  1 +
 arch/arm/boot/dts/qcom-ipq4019-ap.dk01.1-c2.dts | 25 +
 2 files changed, 26 insertions(+)
 create mode 100644 arch/arm/boot/dts/qcom-ipq4019-ap.dk01.1-c2.dts

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index d0381e9..21ed56d 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -724,6 +724,7 @@ dtb-$(CONFIG_ARCH_QCOM) += \
qcom-apq8084-ifc6540.dtb \
qcom-apq8084-mtp.dtb \
qcom-ipq4019-ap.dk01.1-c1.dtb \
+   qcom-ipq4019-ap.dk01.1-c2.dtb \
qcom-ipq8064-ap148.dtb \
qcom-msm8660-surf.dtb \
qcom-msm8960-cdp.dtb \
diff --git a/arch/arm/boot/dts/qcom-ipq4019-ap.dk01.1-c2.dts 
b/arch/arm/boot/dts/qcom-ipq4019-ap.dk01.1-c2.dts
new file mode 100644
index 000..e3442da
--- /dev/null
+++ b/arch/arm/boot/dts/qcom-ipq4019-ap.dk01.1-c2.dts
@@ -0,0 +1,25 @@
+// SPDX-License-Identifier: GPL-2.0
+// Copyright (c) 2017, The Linux Foundation. All rights reserved.
+
+#include "qcom-ipq4019-ap.dk01.1.dtsi"
+
+/ {
+   model = "Qualcomm Technologies, Inc. IPQ40xx/AP-DK01.1-C2";
+
+   soc {
+   spi_0: spi@78b5000 { /* BLSP1 QUP1 */
+   status = "ok";
+   cs-gpios = < 54 0>, < 59 0>;
+   num-cs = <2>;
+
+   mt29f@1 {
+   #address-cells = <1>;
+   #size-cells = <1>;
+   compatible = "spinand,mt29f";
+   reg = <1>;
+   spi-max-frequency = <2400>;
+   };
+
+   };
+   };
+};
-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of 
Code Aurora Forum, hosted by The Linux Foundation

[PATCH 05/15] ARM: dts: ipq4019: Add ipq4019-ap-dk01-c2 board file

[Sricharan R]

The board has a spi-nand interface on spi0 bus chipselect1.

Signed-off-by: Sricharan R 
---
 arch/arm/boot/dts/Makefile  |  1 +
 arch/arm/boot/dts/qcom-ipq4019-ap.dk01.1-c2.dts | 25 +
 2 files changed, 26 insertions(+)
 create mode 100644 arch/arm/boot/dts/qcom-ipq4019-ap.dk01.1-c2.dts

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index d0381e9..21ed56d 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -724,6 +724,7 @@ dtb-$(CONFIG_ARCH_QCOM) += \
qcom-apq8084-ifc6540.dtb \
qcom-apq8084-mtp.dtb \
qcom-ipq4019-ap.dk01.1-c1.dtb \
+   qcom-ipq4019-ap.dk01.1-c2.dtb \
qcom-ipq8064-ap148.dtb \
qcom-msm8660-surf.dtb \
qcom-msm8960-cdp.dtb \
diff --git a/arch/arm/boot/dts/qcom-ipq4019-ap.dk01.1-c2.dts 
b/arch/arm/boot/dts/qcom-ipq4019-ap.dk01.1-c2.dts
new file mode 100644
index 000..e3442da
--- /dev/null
+++ b/arch/arm/boot/dts/qcom-ipq4019-ap.dk01.1-c2.dts
@@ -0,0 +1,25 @@
+// SPDX-License-Identifier: GPL-2.0
+// Copyright (c) 2017, The Linux Foundation. All rights reserved.
+
+#include "qcom-ipq4019-ap.dk01.1.dtsi"
+
+/ {
+   model = "Qualcomm Technologies, Inc. IPQ40xx/AP-DK01.1-C2";
+
+   soc {
+   spi_0: spi@78b5000 { /* BLSP1 QUP1 */
+   status = "ok";
+   cs-gpios = < 54 0>, < 59 0>;
+   num-cs = <2>;
+
+   mt29f@1 {
+   #address-cells = <1>;
+   #size-cells = <1>;
+   compatible = "spinand,mt29f";
+   reg = <1>;
+   spi-max-frequency = <2400>;
+   };
+
+   };
+   };
+};
-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of 
Code Aurora Forum, hosted by The Linux Foundation

[PATCH 13/15] ARM: dts: ipq8074: Add peripheral nodes

[Sricharan R]

Add serial, i2c, bam, spi, qpic peripheral nodes.

Signed-off-by: Sricharan R 
---
 arch/arm64/boot/dts/qcom/ipq8074.dtsi | 103 ++
 1 file changed, 103 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/ipq8074.dtsi 
b/arch/arm64/boot/dts/qcom/ipq8074.dtsi
index 2bc5dec..07d3bf7 100644
--- a/arch/arm64/boot/dts/qcom/ipq8074.dtsi
+++ b/arch/arm64/boot/dts/qcom/ipq8074.dtsi
@@ -124,6 +124,109 @@
clock-names = "core", "iface";
status = "disabled";
};
+
+   blsp_dma: dma@7884000 {
+   compatible = "qcom,bam-v1.7.0";
+   reg = <0x07884000 0x2b000>;
+   interrupts = ;
+   clocks = < GCC_BLSP1_AHB_CLK>;
+   clock-names = "bam_clk";
+   #dma-cells = <1>;
+   qcom,ee = <0>;
+   };
+
+   serial_blsp0: serial@78af000 {
+   compatible = "qcom,msm-uartdm-v1.4", "qcom,msm-uartdm";
+   reg = <0x78af000 0x200>;
+   interrupts = ;
+   clocks = < GCC_BLSP1_UART1_APPS_CLK>,
+< GCC_BLSP1_AHB_CLK>;
+   clock-names = "core", "iface";
+   status = "disabled";
+   };
+
+   serial_blsp2: serial@78B1000 {
+   compatible = "qcom,msm-uartdm-v1.4", "qcom,msm-uartdm";
+   reg = <0x78B1000 0x200>;
+   interrupts = ;
+   clocks = < GCC_BLSP1_UART3_APPS_CLK>,
+   < GCC_BLSP1_AHB_CLK>;
+   clock-names = "core", "iface";
+   dmas = <_dma 4>,
+   <_dma 5>;
+   dma-names = "tx", "rx";
+   status = "disabled";
+   };
+
+   spi_0: spi@78b5000 {
+   compatible = "qcom,spi-qup-v2.2.1";
+   #address-cells = <1>;
+   #size-cells = <0>;
+   reg = <0x78b5000 0x600>;
+   interrupts = ;
+   spi-max-frequency = <5000>;
+   clocks = < GCC_BLSP1_QUP1_SPI_APPS_CLK>,
+   < GCC_BLSP1_AHB_CLK>;
+   clock-names = "core", "iface";
+   dmas = <_dma 12>, <_dma 13>;
+   dma-names = "tx", "rx";
+   status = "disabled";
+   };
+
+   i2c_0: i2c@78b6000 {
+   compatible = "qcom,i2c-qup-v2.2.1";
+   #address-cells = <1>;
+   #size-cells = <0>;
+   reg = <0x78b6000 0x600>;
+   interrupts = ;
+   clocks = < GCC_BLSP1_AHB_CLK>,
+   < GCC_BLSP1_QUP2_I2C_APPS_CLK>;
+   clock-names = "iface", "core";
+   clock-frequency  = <40>;
+   dmas = <_dma 15>, <_dma 14>;
+   dma-names = "rx", "tx";
+   };
+
+   i2c_1: i2c@78b7000 {
+   compatible = "qcom,i2c-qup-v2.2.1";
+   #address-cells = <1>;
+   #size-cells = <0>;
+   reg = <0x78b7000 0x600>;
+   interrupts = ;
+   clocks = < GCC_BLSP1_AHB_CLK>,
+   < GCC_BLSP1_QUP3_I2C_APPS_CLK>;
+   clock-names = "iface", "core";
+   clock-frequency  = <10>;
+   dmas = <_dma 17>, <_dma 16>;
+   dma-names = "rx", "tx";
+   };
+
+   qpic_bam: dma@7984000 {
+   compatible = "qcom,bam-v1.7.0";
+   reg = <0x7984000 0x1a000>;
+   interrupts = ;
+   clocks = < GCC_QPIC_AHB_CLK>;
+   clock-names = "bam_clk";
+   #dma-cells = <1>;
+   qcom,ee = <0>;
+   status = "disabled";
+   };
+
+   qpic_nand: nand@79b {
+   compatible = "qcom,ipq8074-nand";
+   reg = <0x79b 0x1>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+   clocks = < GCC_QPIC_CLK>,
+< GCC_QPIC_AHB_CLK>;
+   clock-names = "core", "aon";
+
+   dmas = <_bam 0>,
+  <_bam 1>,
+  <_bam 2>;
+   dma-names = "tx", "rx", "cmd";
+   status = "disabled";
+   

[PATCH 10/15] ARM: dts: ipq4019: Add ipq4019-ap.dk07.1 common data

[Sricharan R]

Add the common data for all dk07 based boards.

Signed-off-by: Sricharan R 
---
 arch/arm/boot/dts/qcom-ipq4019-ap.dk07.1.dtsi | 128 ++
 1 file changed, 128 insertions(+)
 create mode 100644 arch/arm/boot/dts/qcom-ipq4019-ap.dk07.1.dtsi

diff --git a/arch/arm/boot/dts/qcom-ipq4019-ap.dk07.1.dtsi 
b/arch/arm/boot/dts/qcom-ipq4019-ap.dk07.1.dtsi
new file mode 100644
index 000..af4e99d
--- /dev/null
+++ b/arch/arm/boot/dts/qcom-ipq4019-ap.dk07.1.dtsi
@@ -0,0 +1,128 @@
+// SPDX-License-Identifier: GPL-2.0
+// Copyright (c) 2017, The Linux Foundation. All rights reserved.
+
+#include "qcom-ipq4019.dtsi"
+#include 
+#include 
+
+/ {
+   model = "Qualcomm Technologies, Inc. IPQ4019/AP-DK07.1";
+   compatible = "qcom,ipq4019";
+
+   memory {
+   device_type = "memory";
+   reg = <0x8000 0x2000>; /* 512MB */
+   };
+
+   reserved-memory {
+   #address-cells = <1>;
+   #size-cells = <1>;
+   ranges;
+
+   rsvd1@8700 {
+   /* Reserved for other subsystem */
+   reg = <0x8700 0x50>;
+   no-map;
+   };
+
+   wifi_dump@8750 {
+   reg = <0x8750 0x60>;
+   no-map;
+   };
+
+   rsvd2@87B0 {
+   /* Reserved for other subsystem */
+   reg = <0x87B0 0x50>;
+   no-map;
+   };
+   };
+
+   soc {
+   pinctrl@100 {
+   serial_0_pins: serial0_pinmux {
+   mux {
+   pins = "gpio16", "gpio17";
+   function = "blsp_uart0";
+   bias-disable;
+   };
+   };
+
+   spi_1_pins: spi_1_pinmux {
+   mux {
+   pins = "gpio44", "gpio46", "gpio47";
+   function = "blsp_spi1";
+   bias-disable;
+   };
+   host_int {
+   pins = "gpio42";
+   function = "gpio";
+   input;
+   };
+   cs {
+   pins = "gpio45";
+   function = "gpio";
+   bias-pull-up;
+   };
+   wake {
+   pins = "gpio31";
+   function = "gpio";
+   output-high;
+   };
+   reset {
+   pins = "gpio49";
+   function = "gpio";
+   output-high;
+   };
+   };
+
+   i2c_0_pins: i2c_0_pinmux {
+   mux {
+   pins = "gpio20", "gpio21";
+   function = "blsp_i2c0";
+   bias-disable;
+   };
+   };
+   };
+
+   serial@78af000 {
+   pinctrl-0 = <_0_pins>;
+   pinctrl-names = "default";
+   status = "ok";
+   };
+
+   spi_1: spi@78b6000 { /* BLSP1 QUP2 */
+   pinctrl-0 = <_1_pins>;
+   pinctrl-names = "default";
+   status = "disabled";
+
+   spidev1: spi@1 {
+   compatible = "spidev";
+   reg = <0>;
+   spi-max-frequency = <2400>;
+   };
+   };
+
+   blsp_dma: dma@7884000 {
+   status = "ok";
+   };
+
+   i2c_0: i2c@78b7000 { /* BLSP1 QUP2 */
+   pinctrl-0 = <_0_pins>;
+   pinctrl-names = "default";
+   status = "ok";
+   };
+
+   pcie0: pci@4000 {
+   status = "ok";
+   perst-gpio = < 38 0x1>;
+   };
+
+   qpic_bam: dma@7984000{
+   status = "ok";
+   };
+
+   nand: qpic-nand@79b {
+   status = "ok";
+   };
+   };
+};
-- 
QUALCOMM INDIA, 

[PATCH 13/15] ARM: dts: ipq8074: Add peripheral nodes

[Sricharan R]

Add serial, i2c, bam, spi, qpic peripheral nodes.

Signed-off-by: Sricharan R 
---
 arch/arm64/boot/dts/qcom/ipq8074.dtsi | 103 ++
 1 file changed, 103 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/ipq8074.dtsi 
b/arch/arm64/boot/dts/qcom/ipq8074.dtsi
index 2bc5dec..07d3bf7 100644
--- a/arch/arm64/boot/dts/qcom/ipq8074.dtsi
+++ b/arch/arm64/boot/dts/qcom/ipq8074.dtsi
@@ -124,6 +124,109 @@
clock-names = "core", "iface";
status = "disabled";
};
+
+   blsp_dma: dma@7884000 {
+   compatible = "qcom,bam-v1.7.0";
+   reg = <0x07884000 0x2b000>;
+   interrupts = ;
+   clocks = < GCC_BLSP1_AHB_CLK>;
+   clock-names = "bam_clk";
+   #dma-cells = <1>;
+   qcom,ee = <0>;
+   };
+
+   serial_blsp0: serial@78af000 {
+   compatible = "qcom,msm-uartdm-v1.4", "qcom,msm-uartdm";
+   reg = <0x78af000 0x200>;
+   interrupts = ;
+   clocks = < GCC_BLSP1_UART1_APPS_CLK>,
+< GCC_BLSP1_AHB_CLK>;
+   clock-names = "core", "iface";
+   status = "disabled";
+   };
+
+   serial_blsp2: serial@78B1000 {
+   compatible = "qcom,msm-uartdm-v1.4", "qcom,msm-uartdm";
+   reg = <0x78B1000 0x200>;
+   interrupts = ;
+   clocks = < GCC_BLSP1_UART3_APPS_CLK>,
+   < GCC_BLSP1_AHB_CLK>;
+   clock-names = "core", "iface";
+   dmas = <_dma 4>,
+   <_dma 5>;
+   dma-names = "tx", "rx";
+   status = "disabled";
+   };
+
+   spi_0: spi@78b5000 {
+   compatible = "qcom,spi-qup-v2.2.1";
+   #address-cells = <1>;
+   #size-cells = <0>;
+   reg = <0x78b5000 0x600>;
+   interrupts = ;
+   spi-max-frequency = <5000>;
+   clocks = < GCC_BLSP1_QUP1_SPI_APPS_CLK>,
+   < GCC_BLSP1_AHB_CLK>;
+   clock-names = "core", "iface";
+   dmas = <_dma 12>, <_dma 13>;
+   dma-names = "tx", "rx";
+   status = "disabled";
+   };
+
+   i2c_0: i2c@78b6000 {
+   compatible = "qcom,i2c-qup-v2.2.1";
+   #address-cells = <1>;
+   #size-cells = <0>;
+   reg = <0x78b6000 0x600>;
+   interrupts = ;
+   clocks = < GCC_BLSP1_AHB_CLK>,
+   < GCC_BLSP1_QUP2_I2C_APPS_CLK>;
+   clock-names = "iface", "core";
+   clock-frequency  = <40>;
+   dmas = <_dma 15>, <_dma 14>;
+   dma-names = "rx", "tx";
+   };
+
+   i2c_1: i2c@78b7000 {
+   compatible = "qcom,i2c-qup-v2.2.1";
+   #address-cells = <1>;
+   #size-cells = <0>;
+   reg = <0x78b7000 0x600>;
+   interrupts = ;
+   clocks = < GCC_BLSP1_AHB_CLK>,
+   < GCC_BLSP1_QUP3_I2C_APPS_CLK>;
+   clock-names = "iface", "core";
+   clock-frequency  = <10>;
+   dmas = <_dma 17>, <_dma 16>;
+   dma-names = "rx", "tx";
+   };
+
+   qpic_bam: dma@7984000 {
+   compatible = "qcom,bam-v1.7.0";
+   reg = <0x7984000 0x1a000>;
+   interrupts = ;
+   clocks = < GCC_QPIC_AHB_CLK>;
+   clock-names = "bam_clk";
+   #dma-cells = <1>;
+   qcom,ee = <0>;
+   status = "disabled";
+   };
+
+   qpic_nand: nand@79b {
+   compatible = "qcom,ipq8074-nand";
+   reg = <0x79b 0x1>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+   clocks = < GCC_QPIC_CLK>,
+< GCC_QPIC_AHB_CLK>;
+   clock-names = "core", "aon";
+
+   dmas = <_bam 0>,
+  <_bam 1>,
+  <_bam 2>;
+   dma-names = "tx", "rx", "cmd";
+   status = "disabled";
+   };
};
 

[PATCH 10/15] ARM: dts: ipq4019: Add ipq4019-ap.dk07.1 common data

[Sricharan R]

Add the common data for all dk07 based boards.

Signed-off-by: Sricharan R 
---
 arch/arm/boot/dts/qcom-ipq4019-ap.dk07.1.dtsi | 128 ++
 1 file changed, 128 insertions(+)
 create mode 100644 arch/arm/boot/dts/qcom-ipq4019-ap.dk07.1.dtsi

diff --git a/arch/arm/boot/dts/qcom-ipq4019-ap.dk07.1.dtsi 
b/arch/arm/boot/dts/qcom-ipq4019-ap.dk07.1.dtsi
new file mode 100644
index 000..af4e99d
--- /dev/null
+++ b/arch/arm/boot/dts/qcom-ipq4019-ap.dk07.1.dtsi
@@ -0,0 +1,128 @@
+// SPDX-License-Identifier: GPL-2.0
+// Copyright (c) 2017, The Linux Foundation. All rights reserved.
+
+#include "qcom-ipq4019.dtsi"
+#include 
+#include 
+
+/ {
+   model = "Qualcomm Technologies, Inc. IPQ4019/AP-DK07.1";
+   compatible = "qcom,ipq4019";
+
+   memory {
+   device_type = "memory";
+   reg = <0x8000 0x2000>; /* 512MB */
+   };
+
+   reserved-memory {
+   #address-cells = <1>;
+   #size-cells = <1>;
+   ranges;
+
+   rsvd1@8700 {
+   /* Reserved for other subsystem */
+   reg = <0x8700 0x50>;
+   no-map;
+   };
+
+   wifi_dump@8750 {
+   reg = <0x8750 0x60>;
+   no-map;
+   };
+
+   rsvd2@87B0 {
+   /* Reserved for other subsystem */
+   reg = <0x87B0 0x50>;
+   no-map;
+   };
+   };
+
+   soc {
+   pinctrl@100 {
+   serial_0_pins: serial0_pinmux {
+   mux {
+   pins = "gpio16", "gpio17";
+   function = "blsp_uart0";
+   bias-disable;
+   };
+   };
+
+   spi_1_pins: spi_1_pinmux {
+   mux {
+   pins = "gpio44", "gpio46", "gpio47";
+   function = "blsp_spi1";
+   bias-disable;
+   };
+   host_int {
+   pins = "gpio42";
+   function = "gpio";
+   input;
+   };
+   cs {
+   pins = "gpio45";
+   function = "gpio";
+   bias-pull-up;
+   };
+   wake {
+   pins = "gpio31";
+   function = "gpio";
+   output-high;
+   };
+   reset {
+   pins = "gpio49";
+   function = "gpio";
+   output-high;
+   };
+   };
+
+   i2c_0_pins: i2c_0_pinmux {
+   mux {
+   pins = "gpio20", "gpio21";
+   function = "blsp_i2c0";
+   bias-disable;
+   };
+   };
+   };
+
+   serial@78af000 {
+   pinctrl-0 = <_0_pins>;
+   pinctrl-names = "default";
+   status = "ok";
+   };
+
+   spi_1: spi@78b6000 { /* BLSP1 QUP2 */
+   pinctrl-0 = <_1_pins>;
+   pinctrl-names = "default";
+   status = "disabled";
+
+   spidev1: spi@1 {
+   compatible = "spidev";
+   reg = <0>;
+   spi-max-frequency = <2400>;
+   };
+   };
+
+   blsp_dma: dma@7884000 {
+   status = "ok";
+   };
+
+   i2c_0: i2c@78b7000 { /* BLSP1 QUP2 */
+   pinctrl-0 = <_0_pins>;
+   pinctrl-names = "default";
+   status = "ok";
+   };
+
+   pcie0: pci@4000 {
+   status = "ok";
+   perst-gpio = < 38 0x1>;
+   };
+
+   qpic_bam: dma@7984000{
+   status = "ok";
+   };
+
+   nand: qpic-nand@79b {
+   status = "ok";
+   };
+   };
+};
-- 
QUALCOMM INDIA, on behalf of Qualcomm 

[PATCH 12/15] ARM: dts: ipq4019: Add qcom-ipq4019-ap.dk07.1-c2 board file

[Sricharan R]

Signed-off-by: Sricharan R 
---
 arch/arm/boot/dts/Makefile  |  1 +
 arch/arm/boot/dts/qcom-ipq4019-ap.dk07.1-c2.dts | 78 +
 2 files changed, 79 insertions(+)
 create mode 100644 arch/arm/boot/dts/qcom-ipq4019-ap.dk07.1-c2.dts

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index ef5b133..b4339ae 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -729,6 +729,7 @@ dtb-$(CONFIG_ARCH_QCOM) += \
qcom-ipq4019-ap.dk04.1-c5.dtb \
qcom-ipq4019-ap.dk04.1-c3.dtb \
qcom-ipq4019-ap.dk07.1-c1.dtb \
+   qcom-ipq4019-ap.dk07.1-c2.dtb \
qcom-ipq8064-ap148.dtb \
qcom-msm8660-surf.dtb \
qcom-msm8960-cdp.dtb \
diff --git a/arch/arm/boot/dts/qcom-ipq4019-ap.dk07.1-c2.dts 
b/arch/arm/boot/dts/qcom-ipq4019-ap.dk07.1-c2.dts
new file mode 100644
index 000..d4ee52d
--- /dev/null
+++ b/arch/arm/boot/dts/qcom-ipq4019-ap.dk07.1-c2.dts
@@ -0,0 +1,78 @@
+// SPDX-License-Identifier: GPL-2.0
+// Copyright (c) 2017, The Linux Foundation. All rights reserved.
+
+#include "qcom-ipq4019-ap.dk07.1.dtsi"
+
+/ {
+   model = "Qualcomm Technologies, Inc. IPQ40xx/AP-DK07.1-C2";
+
+   soc {
+   pcie0: pci@4000 {
+   status = "disabled";
+   };
+
+   pinctrl@100 {
+   serial_1_pins: serial1_pinmux {
+   mux {
+   pins = "gpio8", "gpio9";
+   function = "blsp_uart1";
+   bias-disable;
+   };
+   };
+
+   spi_0_pins: spi_0_pinmux {
+   mux {
+   pins = "gpio13", "gpio14", "gpio15";
+   function = "blsp_spi0";
+   bias-disable;
+   };
+   cs1 {
+   pins = "gpio12";
+   function = "gpio";
+   };
+   host_int1 {
+   pins = "gpio10";
+   function = "gpio";
+   input;
+   };
+   cs2 {
+   pins = "gpio45";
+   function = "gpio";
+   };
+   host_int2 {
+   pins = "gpio61";
+   function = "gpio";
+   input;
+   };
+   rst {
+   pins = "gpio36";
+   function = "gpio";
+   output-high;
+   };
+   };
+   };
+
+   serial@78b {
+   pinctrl-0 = <_1_pins>;
+   pinctrl-names = "default";
+   status = "ok";
+   };
+
+   spi_0: spi@78b5000 { /* BLSP1 QUP1 */
+   pinctrl-0 = <_0_pins>;
+   pinctrl-names = "default";
+   status = "ok";
+
+   spidev0_0 {
+   compatible = "spidev";
+   reg = <0>;
+   spi-max-frequency = <2400>;
+   };
+   spidev0_1 {
+   compatible = "spidev";
+   reg = <1>;
+   spi-max-frequency = <2400>;
+   };
+   };
+   };
+};
-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of 
Code Aurora Forum, hosted by The Linux Foundation

[PATCH 12/15] ARM: dts: ipq4019: Add qcom-ipq4019-ap.dk07.1-c2 board file

[Sricharan R]

Signed-off-by: Sricharan R 
---
 arch/arm/boot/dts/Makefile  |  1 +
 arch/arm/boot/dts/qcom-ipq4019-ap.dk07.1-c2.dts | 78 +
 2 files changed, 79 insertions(+)
 create mode 100644 arch/arm/boot/dts/qcom-ipq4019-ap.dk07.1-c2.dts

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index ef5b133..b4339ae 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -729,6 +729,7 @@ dtb-$(CONFIG_ARCH_QCOM) += \
qcom-ipq4019-ap.dk04.1-c5.dtb \
qcom-ipq4019-ap.dk04.1-c3.dtb \
qcom-ipq4019-ap.dk07.1-c1.dtb \
+   qcom-ipq4019-ap.dk07.1-c2.dtb \
qcom-ipq8064-ap148.dtb \
qcom-msm8660-surf.dtb \
qcom-msm8960-cdp.dtb \
diff --git a/arch/arm/boot/dts/qcom-ipq4019-ap.dk07.1-c2.dts 
b/arch/arm/boot/dts/qcom-ipq4019-ap.dk07.1-c2.dts
new file mode 100644
index 000..d4ee52d
--- /dev/null
+++ b/arch/arm/boot/dts/qcom-ipq4019-ap.dk07.1-c2.dts
@@ -0,0 +1,78 @@
+// SPDX-License-Identifier: GPL-2.0
+// Copyright (c) 2017, The Linux Foundation. All rights reserved.
+
+#include "qcom-ipq4019-ap.dk07.1.dtsi"
+
+/ {
+   model = "Qualcomm Technologies, Inc. IPQ40xx/AP-DK07.1-C2";
+
+   soc {
+   pcie0: pci@4000 {
+   status = "disabled";
+   };
+
+   pinctrl@100 {
+   serial_1_pins: serial1_pinmux {
+   mux {
+   pins = "gpio8", "gpio9";
+   function = "blsp_uart1";
+   bias-disable;
+   };
+   };
+
+   spi_0_pins: spi_0_pinmux {
+   mux {
+   pins = "gpio13", "gpio14", "gpio15";
+   function = "blsp_spi0";
+   bias-disable;
+   };
+   cs1 {
+   pins = "gpio12";
+   function = "gpio";
+   };
+   host_int1 {
+   pins = "gpio10";
+   function = "gpio";
+   input;
+   };
+   cs2 {
+   pins = "gpio45";
+   function = "gpio";
+   };
+   host_int2 {
+   pins = "gpio61";
+   function = "gpio";
+   input;
+   };
+   rst {
+   pins = "gpio36";
+   function = "gpio";
+   output-high;
+   };
+   };
+   };
+
+   serial@78b {
+   pinctrl-0 = <_1_pins>;
+   pinctrl-names = "default";
+   status = "ok";
+   };
+
+   spi_0: spi@78b5000 { /* BLSP1 QUP1 */
+   pinctrl-0 = <_0_pins>;
+   pinctrl-names = "default";
+   status = "ok";
+
+   spidev0_0 {
+   compatible = "spidev";
+   reg = <0>;
+   spi-max-frequency = <2400>;
+   };
+   spidev0_1 {
+   compatible = "spidev";
+   reg = <1>;
+   spi-max-frequency = <2400>;
+   };
+   };
+   };
+};
-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of 
Code Aurora Forum, hosted by The Linux Foundation

[PATCH 09/15] ARM: dts: ipq4019: Add qcom-ipq4019-ap.dk04.1-c3 board file

[Sricharan R]

Signed-off-by: Sricharan R 
---
 arch/arm/boot/dts/Makefile  |  1 +
 arch/arm/boot/dts/qcom-ipq4019-ap.dk04.1-c3.dts | 14 ++
 2 files changed, 15 insertions(+)
 create mode 100644 arch/arm/boot/dts/qcom-ipq4019-ap.dk04.1-c3.dts

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 68e4b15..0104ba2 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -727,6 +727,7 @@ dtb-$(CONFIG_ARCH_QCOM) += \
qcom-ipq4019-ap.dk01.1-c2.dtb \
qcom-ipq4019-ap.dk04.1-c1.dtb \
qcom-ipq4019-ap.dk04.1-c5.dtb \
+   qcom-ipq4019-ap.dk04.1-c3.dtb \
qcom-ipq8064-ap148.dtb \
qcom-msm8660-surf.dtb \
qcom-msm8960-cdp.dtb \
diff --git a/arch/arm/boot/dts/qcom-ipq4019-ap.dk04.1-c3.dts 
b/arch/arm/boot/dts/qcom-ipq4019-ap.dk04.1-c3.dts
new file mode 100644
index 000..7a93fc4
--- /dev/null
+++ b/arch/arm/boot/dts/qcom-ipq4019-ap.dk04.1-c3.dts
@@ -0,0 +1,14 @@
+// SPDX-License-Identifier: GPL-2.0
+// Copyright (c) 2017, The Linux Foundation. All rights reserved.
+
+#include "qcom-ipq4019-ap.dk04.1.dtsi"
+
+/ {
+   model = "Qualcomm Technologies, Inc. IPQ4019/AP-DK04.1-C3";
+
+   soc {
+   nand: qpic-nand@79b {
+   status = "disabled";
+   };
+   };
+};
-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of 
Code Aurora Forum, hosted by The Linux Foundation

[PATCH 11/15] ARM: dts: ipq4019: Add qcom-ipq4019-ap.dk07.1-c1 board file

[Sricharan R]

Signed-off-by: Sricharan R 
---
 arch/arm/boot/dts/Makefile  |  1 +
 arch/arm/boot/dts/qcom-ipq4019-ap.dk07.1-c1.dts | 60 +
 2 files changed, 61 insertions(+)
 create mode 100644 arch/arm/boot/dts/qcom-ipq4019-ap.dk07.1-c1.dts

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 0104ba2..ef5b133 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -728,6 +728,7 @@ dtb-$(CONFIG_ARCH_QCOM) += \
qcom-ipq4019-ap.dk04.1-c1.dtb \
qcom-ipq4019-ap.dk04.1-c5.dtb \
qcom-ipq4019-ap.dk04.1-c3.dtb \
+   qcom-ipq4019-ap.dk07.1-c1.dtb \
qcom-ipq8064-ap148.dtb \
qcom-msm8660-surf.dtb \
qcom-msm8960-cdp.dtb \
diff --git a/arch/arm/boot/dts/qcom-ipq4019-ap.dk07.1-c1.dts 
b/arch/arm/boot/dts/qcom-ipq4019-ap.dk07.1-c1.dts
new file mode 100644
index 000..c2eed44
--- /dev/null
+++ b/arch/arm/boot/dts/qcom-ipq4019-ap.dk07.1-c1.dts
@@ -0,0 +1,60 @@
+// SPDX-License-Identifier: GPL-2.0
+// Copyright (c) 2017, The Linux Foundation. All rights reserved.
+
+#include "qcom-ipq4019-ap.dk07.1.dtsi"
+
+/ {
+   model = "Qualcomm Technologies, Inc. IPQ40xx/AP-DK07.1-C1";
+
+   soc {
+   spi_1: spi@78b6000 { /* BLSP1 QUP2 */
+   status = "ok";
+   };
+
+   pinctrl@100 {
+   serial_1_pins: serial1_pinmux {
+   mux {
+   pins = "gpio8", "gpio9",
+   "gpio10", "gpio11";
+   function = "blsp_uart1";
+   bias-disable;
+   };
+   };
+
+   spi_0_pins: spi_0_pinmux {
+   pinmux {
+   function = "blsp_spi0";
+   pins = "gpio13", "gpio14", "gpio15";
+   bias-disable;
+   };
+   pinmux_cs {
+   function = "gpio";
+   pins = "gpio12";
+   bias-disable;
+   output-high;
+   };
+   };
+   };
+
+   serial@78b {
+   pinctrl-0 = <_1_pins>;
+   pinctrl-names = "default";
+   status = "ok";
+   };
+
+   spi_0: spi@78b5000 { /* BLSP1 QUP1 */
+   pinctrl-0 = <_0_pins>;
+   pinctrl-names = "default";
+   status = "ok";
+   cs-gpios = < 12 0>;
+
+   m25p80@0 {
+   #address-cells = <1>;
+   #size-cells = <1>;
+   reg = <0>;
+   compatible = "n25q128a11";
+   spi-max-frequency = <2400>;
+   };
+   };
+   };
+};
-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of 
Code Aurora Forum, hosted by The Linux Foundation

[PATCH 07/15] ARM: dts: ipq4019: Add ipq4019-ap.dk04.1-c1 board file

[Sricharan R]

Signed-off-by: Sricharan R 
---
 arch/arm/boot/dts/Makefile  | 1 +
 arch/arm/boot/dts/qcom-ipq4019-ap.dk04.1-c1.dts | 8 
 2 files changed, 9 insertions(+)
 create mode 100644 arch/arm/boot/dts/qcom-ipq4019-ap.dk04.1-c1.dts

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 21ed56d..1a8ab050 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -725,6 +725,7 @@ dtb-$(CONFIG_ARCH_QCOM) += \
qcom-apq8084-mtp.dtb \
qcom-ipq4019-ap.dk01.1-c1.dtb \
qcom-ipq4019-ap.dk01.1-c2.dtb \
+   qcom-ipq4019-ap.dk04.1-c1.dtb \
qcom-ipq8064-ap148.dtb \
qcom-msm8660-surf.dtb \
qcom-msm8960-cdp.dtb \
diff --git a/arch/arm/boot/dts/qcom-ipq4019-ap.dk04.1-c1.dts 
b/arch/arm/boot/dts/qcom-ipq4019-ap.dk04.1-c1.dts
new file mode 100644
index 000..41123be
--- /dev/null
+++ b/arch/arm/boot/dts/qcom-ipq4019-ap.dk04.1-c1.dts
@@ -0,0 +1,8 @@
+// SPDX-License-Identifier: GPL-2.0
+// Copyright (c) 2017, The Linux Foundation. All rights reserved.
+
+#include "qcom-ipq4019-ap.dk04.1.dtsi"
+
+/ {
+   model = "Qualcomm Technologies, Inc. IPQ4019/AP-DK04.1-C1";
+};
-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of 
Code Aurora Forum, hosted by The Linux Foundation

[PATCH 14/15] ARM: dts: ipq8074: Add pcie nodes

[Sricharan R]

The driver/phy support for ipq8074 is available now.
So enabling the nodes in DT.

Signed-off-by: Sricharan R 
---
 arch/arm64/boot/dts/qcom/ipq8074.dtsi | 155 +-
 1 file changed, 154 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/qcom/ipq8074.dtsi 
b/arch/arm64/boot/dts/qcom/ipq8074.dtsi
index 07d3bf7..9bfbad9 100644
--- a/arch/arm64/boot/dts/qcom/ipq8074.dtsi
+++ b/arch/arm64/boot/dts/qcom/ipq8074.dtsi
@@ -24,7 +24,7 @@
ranges = <0 0 0 0x>;
compatible = "simple-bus";
 
-   pinctrl@100 {
+   tlmm: pinctrl@100 {
compatible = "qcom,ipq8074-pinctrl";
reg = <0x100 0x30>;
interrupts = ;
@@ -227,6 +227,159 @@
dma-names = "tx", "rx", "cmd";
status = "disabled";
};
+
+   pcie_phy0: phy@86000 {
+   compatible = "qcom,ipq8074-qmp-pcie-phy";
+   reg = <0x86000 0x1000>;
+   #phy-cells = <0>;
+   clocks = < GCC_PCIE0_PIPE_CLK>;
+   clock-names = "pipe_clk";
+   clock-output-names = "pcie20_phy0_pipe_clk";
+
+   resets = < GCC_PCIE0_PHY_BCR>,
+   < GCC_PCIE0PHY_PHY_BCR>;
+   reset-names = "phy",
+ "common";
+   };
+
+   pcie0: pci@2000 {
+   compatible = "qcom,pcie-ipq8074";
+   reg =  <0x2000 0xf1d
+   0x2F20 0xa8
+   0x8 0x2000
+   0x2010 0x1000>;
+   reg-names = "dbi", "elbi", "parf", "config";
+   device_type = "pci";
+   linux,pci-domain = <0>;
+   bus-range = <0x00 0xff>;
+   num-lanes = <1>;
+   #address-cells = <3>;
+   #size-cells = <2>;
+
+   phys = <_phy0>;
+   phy-names = "pciephy";
+
+   ranges = <0x8100 0 0x2020 0x2020
+ 0 0x0010   /* downstream I/O */
+ 0x8200 0 0x2030 0x2030
+ 0 0x00d0>; /* non-prefetchable memory */
+
+   interrupts = ;
+   interrupt-names = "msi";
+   #interrupt-cells = <1>;
+   interrupt-map-mask = <0 0 0 0x7>;
+   interrupt-map = <0 0 0 1  0 75
+IRQ_TYPE_LEVEL_HIGH>, /* int_a */
+   <0 0 0 2  0 78
+IRQ_TYPE_LEVEL_HIGH>, /* int_b */
+   <0 0 0 3  0 79
+IRQ_TYPE_LEVEL_HIGH>, /* int_c */
+   <0 0 0 4  0 83
+IRQ_TYPE_LEVEL_HIGH>; /* int_d */
+
+   clocks = < GCC_SYS_NOC_PCIE0_AXI_CLK>,
+< GCC_PCIE0_AXI_M_CLK>,
+< GCC_PCIE0_AXI_S_CLK>,
+< GCC_PCIE0_AHB_CLK>,
+< GCC_PCIE0_AUX_CLK>;
+
+   clock-names = "iface",
+ "axi_m",
+ "axi_s",
+ "ahb",
+ "aux";
+   resets = < GCC_PCIE0_PIPE_ARES>,
+< GCC_PCIE0_SLEEP_ARES>,
+< GCC_PCIE0_CORE_STICKY_ARES>,
+< GCC_PCIE0_AXI_MASTER_ARES>,
+< GCC_PCIE0_AXI_SLAVE_ARES>,
+< GCC_PCIE0_AHB_ARES>,
+< GCC_PCIE0_AXI_MASTER_STICKY_ARES>;
+   reset-names = "pipe",
+ "sleep",
+ "sticky",
+ "axi_m",
+ "axi_s",
+ "ahb",
+ "axi_m_sticky";
+   status = "disabled";
+   };
+
+   pcie_phy1: phy@8e000 {
+   compatible = "qcom,ipq8074-qmp-pcie-phy";
+   reg = <0x8e000 0x1000>;
+   #phy-cells = <0>;
+   clocks = < GCC_PCIE1_PIPE_CLK>;
+   clock-names = "pipe_clk";
+   clock-output-names = 

[PATCH 09/15] ARM: dts: ipq4019: Add qcom-ipq4019-ap.dk04.1-c3 board file

[Sricharan R]

Signed-off-by: Sricharan R 
---
 arch/arm/boot/dts/Makefile  |  1 +
 arch/arm/boot/dts/qcom-ipq4019-ap.dk04.1-c3.dts | 14 ++
 2 files changed, 15 insertions(+)
 create mode 100644 arch/arm/boot/dts/qcom-ipq4019-ap.dk04.1-c3.dts

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 68e4b15..0104ba2 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -727,6 +727,7 @@ dtb-$(CONFIG_ARCH_QCOM) += \
qcom-ipq4019-ap.dk01.1-c2.dtb \
qcom-ipq4019-ap.dk04.1-c1.dtb \
qcom-ipq4019-ap.dk04.1-c5.dtb \
+   qcom-ipq4019-ap.dk04.1-c3.dtb \
qcom-ipq8064-ap148.dtb \
qcom-msm8660-surf.dtb \
qcom-msm8960-cdp.dtb \
diff --git a/arch/arm/boot/dts/qcom-ipq4019-ap.dk04.1-c3.dts 
b/arch/arm/boot/dts/qcom-ipq4019-ap.dk04.1-c3.dts
new file mode 100644
index 000..7a93fc4
--- /dev/null
+++ b/arch/arm/boot/dts/qcom-ipq4019-ap.dk04.1-c3.dts
@@ -0,0 +1,14 @@
+// SPDX-License-Identifier: GPL-2.0
+// Copyright (c) 2017, The Linux Foundation. All rights reserved.
+
+#include "qcom-ipq4019-ap.dk04.1.dtsi"
+
+/ {
+   model = "Qualcomm Technologies, Inc. IPQ4019/AP-DK04.1-C3";
+
+   soc {
+   nand: qpic-nand@79b {
+   status = "disabled";
+   };
+   };
+};
-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of 
Code Aurora Forum, hosted by The Linux Foundation

[PATCH 11/15] ARM: dts: ipq4019: Add qcom-ipq4019-ap.dk07.1-c1 board file

[Sricharan R]

Signed-off-by: Sricharan R 
---
 arch/arm/boot/dts/Makefile  |  1 +
 arch/arm/boot/dts/qcom-ipq4019-ap.dk07.1-c1.dts | 60 +
 2 files changed, 61 insertions(+)
 create mode 100644 arch/arm/boot/dts/qcom-ipq4019-ap.dk07.1-c1.dts

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 0104ba2..ef5b133 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -728,6 +728,7 @@ dtb-$(CONFIG_ARCH_QCOM) += \
qcom-ipq4019-ap.dk04.1-c1.dtb \
qcom-ipq4019-ap.dk04.1-c5.dtb \
qcom-ipq4019-ap.dk04.1-c3.dtb \
+   qcom-ipq4019-ap.dk07.1-c1.dtb \
qcom-ipq8064-ap148.dtb \
qcom-msm8660-surf.dtb \
qcom-msm8960-cdp.dtb \
diff --git a/arch/arm/boot/dts/qcom-ipq4019-ap.dk07.1-c1.dts 
b/arch/arm/boot/dts/qcom-ipq4019-ap.dk07.1-c1.dts
new file mode 100644
index 000..c2eed44
--- /dev/null
+++ b/arch/arm/boot/dts/qcom-ipq4019-ap.dk07.1-c1.dts
@@ -0,0 +1,60 @@
+// SPDX-License-Identifier: GPL-2.0
+// Copyright (c) 2017, The Linux Foundation. All rights reserved.
+
+#include "qcom-ipq4019-ap.dk07.1.dtsi"
+
+/ {
+   model = "Qualcomm Technologies, Inc. IPQ40xx/AP-DK07.1-C1";
+
+   soc {
+   spi_1: spi@78b6000 { /* BLSP1 QUP2 */
+   status = "ok";
+   };
+
+   pinctrl@100 {
+   serial_1_pins: serial1_pinmux {
+   mux {
+   pins = "gpio8", "gpio9",
+   "gpio10", "gpio11";
+   function = "blsp_uart1";
+   bias-disable;
+   };
+   };
+
+   spi_0_pins: spi_0_pinmux {
+   pinmux {
+   function = "blsp_spi0";
+   pins = "gpio13", "gpio14", "gpio15";
+   bias-disable;
+   };
+   pinmux_cs {
+   function = "gpio";
+   pins = "gpio12";
+   bias-disable;
+   output-high;
+   };
+   };
+   };
+
+   serial@78b {
+   pinctrl-0 = <_1_pins>;
+   pinctrl-names = "default";
+   status = "ok";
+   };
+
+   spi_0: spi@78b5000 { /* BLSP1 QUP1 */
+   pinctrl-0 = <_0_pins>;
+   pinctrl-names = "default";
+   status = "ok";
+   cs-gpios = < 12 0>;
+
+   m25p80@0 {
+   #address-cells = <1>;
+   #size-cells = <1>;
+   reg = <0>;
+   compatible = "n25q128a11";
+   spi-max-frequency = <2400>;
+   };
+   };
+   };
+};
-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of 
Code Aurora Forum, hosted by The Linux Foundation

[PATCH 07/15] ARM: dts: ipq4019: Add ipq4019-ap.dk04.1-c1 board file

[Sricharan R]

Signed-off-by: Sricharan R 
---
 arch/arm/boot/dts/Makefile  | 1 +
 arch/arm/boot/dts/qcom-ipq4019-ap.dk04.1-c1.dts | 8 
 2 files changed, 9 insertions(+)
 create mode 100644 arch/arm/boot/dts/qcom-ipq4019-ap.dk04.1-c1.dts

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 21ed56d..1a8ab050 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -725,6 +725,7 @@ dtb-$(CONFIG_ARCH_QCOM) += \
qcom-apq8084-mtp.dtb \
qcom-ipq4019-ap.dk01.1-c1.dtb \
qcom-ipq4019-ap.dk01.1-c2.dtb \
+   qcom-ipq4019-ap.dk04.1-c1.dtb \
qcom-ipq8064-ap148.dtb \
qcom-msm8660-surf.dtb \
qcom-msm8960-cdp.dtb \
diff --git a/arch/arm/boot/dts/qcom-ipq4019-ap.dk04.1-c1.dts 
b/arch/arm/boot/dts/qcom-ipq4019-ap.dk04.1-c1.dts
new file mode 100644
index 000..41123be
--- /dev/null
+++ b/arch/arm/boot/dts/qcom-ipq4019-ap.dk04.1-c1.dts
@@ -0,0 +1,8 @@
+// SPDX-License-Identifier: GPL-2.0
+// Copyright (c) 2017, The Linux Foundation. All rights reserved.
+
+#include "qcom-ipq4019-ap.dk04.1.dtsi"
+
+/ {
+   model = "Qualcomm Technologies, Inc. IPQ4019/AP-DK04.1-C1";
+};
-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of 
Code Aurora Forum, hosted by The Linux Foundation

[PATCH 14/15] ARM: dts: ipq8074: Add pcie nodes

[Sricharan R]

The driver/phy support for ipq8074 is available now.
So enabling the nodes in DT.

Signed-off-by: Sricharan R 
---
 arch/arm64/boot/dts/qcom/ipq8074.dtsi | 155 +-
 1 file changed, 154 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/qcom/ipq8074.dtsi 
b/arch/arm64/boot/dts/qcom/ipq8074.dtsi
index 07d3bf7..9bfbad9 100644
--- a/arch/arm64/boot/dts/qcom/ipq8074.dtsi
+++ b/arch/arm64/boot/dts/qcom/ipq8074.dtsi
@@ -24,7 +24,7 @@
ranges = <0 0 0 0x>;
compatible = "simple-bus";
 
-   pinctrl@100 {
+   tlmm: pinctrl@100 {
compatible = "qcom,ipq8074-pinctrl";
reg = <0x100 0x30>;
interrupts = ;
@@ -227,6 +227,159 @@
dma-names = "tx", "rx", "cmd";
status = "disabled";
};
+
+   pcie_phy0: phy@86000 {
+   compatible = "qcom,ipq8074-qmp-pcie-phy";
+   reg = <0x86000 0x1000>;
+   #phy-cells = <0>;
+   clocks = < GCC_PCIE0_PIPE_CLK>;
+   clock-names = "pipe_clk";
+   clock-output-names = "pcie20_phy0_pipe_clk";
+
+   resets = < GCC_PCIE0_PHY_BCR>,
+   < GCC_PCIE0PHY_PHY_BCR>;
+   reset-names = "phy",
+ "common";
+   };
+
+   pcie0: pci@2000 {
+   compatible = "qcom,pcie-ipq8074";
+   reg =  <0x2000 0xf1d
+   0x2F20 0xa8
+   0x8 0x2000
+   0x2010 0x1000>;
+   reg-names = "dbi", "elbi", "parf", "config";
+   device_type = "pci";
+   linux,pci-domain = <0>;
+   bus-range = <0x00 0xff>;
+   num-lanes = <1>;
+   #address-cells = <3>;
+   #size-cells = <2>;
+
+   phys = <_phy0>;
+   phy-names = "pciephy";
+
+   ranges = <0x8100 0 0x2020 0x2020
+ 0 0x0010   /* downstream I/O */
+ 0x8200 0 0x2030 0x2030
+ 0 0x00d0>; /* non-prefetchable memory */
+
+   interrupts = ;
+   interrupt-names = "msi";
+   #interrupt-cells = <1>;
+   interrupt-map-mask = <0 0 0 0x7>;
+   interrupt-map = <0 0 0 1  0 75
+IRQ_TYPE_LEVEL_HIGH>, /* int_a */
+   <0 0 0 2  0 78
+IRQ_TYPE_LEVEL_HIGH>, /* int_b */
+   <0 0 0 3  0 79
+IRQ_TYPE_LEVEL_HIGH>, /* int_c */
+   <0 0 0 4  0 83
+IRQ_TYPE_LEVEL_HIGH>; /* int_d */
+
+   clocks = < GCC_SYS_NOC_PCIE0_AXI_CLK>,
+< GCC_PCIE0_AXI_M_CLK>,
+< GCC_PCIE0_AXI_S_CLK>,
+< GCC_PCIE0_AHB_CLK>,
+< GCC_PCIE0_AUX_CLK>;
+
+   clock-names = "iface",
+ "axi_m",
+ "axi_s",
+ "ahb",
+ "aux";
+   resets = < GCC_PCIE0_PIPE_ARES>,
+< GCC_PCIE0_SLEEP_ARES>,
+< GCC_PCIE0_CORE_STICKY_ARES>,
+< GCC_PCIE0_AXI_MASTER_ARES>,
+< GCC_PCIE0_AXI_SLAVE_ARES>,
+< GCC_PCIE0_AHB_ARES>,
+< GCC_PCIE0_AXI_MASTER_STICKY_ARES>;
+   reset-names = "pipe",
+ "sleep",
+ "sticky",
+ "axi_m",
+ "axi_s",
+ "ahb",
+ "axi_m_sticky";
+   status = "disabled";
+   };
+
+   pcie_phy1: phy@8e000 {
+   compatible = "qcom,ipq8074-qmp-pcie-phy";
+   reg = <0x8e000 0x1000>;
+   #phy-cells = <0>;
+   clocks = < GCC_PCIE1_PIPE_CLK>;
+   clock-names = "pipe_clk";
+   clock-output-names = "pcie20_phy1_pipe_clk";
+
+

[PATCH 15/15] ARM: dts: ipq8074: Enable few peripherals for hk01 board

[Sricharan R]

Signed-off-by: Sricharan R 
---
 arch/arm64/boot/dts/qcom/ipq8074-hk01.dts | 99 +++
 1 file changed, 99 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/ipq8074-hk01.dts 
b/arch/arm64/boot/dts/qcom/ipq8074-hk01.dts
index 6a838b5..69a1b0c 100644
--- a/arch/arm64/boot/dts/qcom/ipq8074-hk01.dts
+++ b/arch/arm64/boot/dts/qcom/ipq8074-hk01.dts
@@ -21,6 +21,7 @@
 
aliases {
serial0 = _uart5;
+   serial1 = _blsp2;
};
 
chosen {
@@ -41,6 +42,46 @@
bias-disable;
};
};
+
+i2c_0_pins: i2c_0_pinmux {
+ mux {
+  pins = "gpio42", "gpio43";
+  function = "blsp1_i2c";
+  drive-strength = <8>;
+  bias-disable;
+ };
+};
+
+spi_0_pins: spi_0_pins {
+ mux {
+  pins = "gpio38", "gpio39", "gpio40", 
"gpio41";
+  function = "blsp0_spi";
+  drive-strength = <8>;
+  bias-disable;
+ };
+};
+
+hsuart_pins: hsuart_pins {
+ mux {
+  pins = "gpio46", "gpio47", "gpio48", 
"gpio49";
+  function = "blsp2_uart";
+  drive-strength = <8>;
+  bias-disable;
+ };
+};
+
+qpic_pins: qpic_pins {
+   mux {
+  pins = "gpio0", "gpio1", "gpio2", 
"gpio3", "gpio4",
+   "gpio5", "gpio6", "gpio7", 
"gpio8", "gpio9",
+  "gpio10", "gpio11", 
"gpio12", "gpio13",
+   "gpio14", "gpio15", "gpio16", 
"gpio17";
+  function = "qpic";
+  drive-strength = <8>;
+  bias-disable;
+ };
+   };
+
};
 
serial@78b3000 {
@@ -48,5 +89,63 @@
pinctrl-names = "default";
status = "ok";
};
+
+   spi_0: spi@78b5000 {
+pinctrl-0 = <_0_pins>;
+pinctrl-names = "default";
+status = "ok";
+
+m25p80@0 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+   compatible = "n25q128a11", "jedec,spi-nor";
+ reg = <0>;
+ spi-max-frequency = <5000>;
+};
+   };
+
+   serial_blsp2: serial@78B1000 {
+pinctrl-0 = <_pins>;
+pinctrl-names = "default";
+status = "ok";
+   };
+
+   i2c_0@78b6000 {
+pinctrl-0 = <_0_pins>;
+pinctrl-names = "default";
+status = "ok";
+   };
+
+   i2c_1@78b7000 {
+status = "disabled";
+   };
+
+   dma@7984000 {
+status = "ok";
+   };
+
+   nand@79b {
+pinctrl-0 = <_pins>;
+pinctrl-names = "default";
+status = "ok";
+
+   nand@0 {
+   reg = <0>;
+   nand-ecc-strength = <4>;
+   nand-ecc-step-size = <512>;
+   nand-bus-width = <8>;
+   };
+
+   };
+
+   pcie0: pci@2000 {
+   status = "ok";
+   perst-gpio = < 58 0x1>;
+   };
+
+   pcie1: pci@1000 {
+   status = "ok";
+   perst-gpio = < 61 0x1>;
+   };
};
 };
-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of 
Code Aurora Forum, hosted by The Linux Foundation

[PATCH 06/15] ARM: dts: ipq4019: Add ipq4019-ap.dk04.dtsi

[Sricharan R]

Add the common parts for the dk04 boards.

Signed-off-by: Sricharan R 
---
 arch/arm/boot/dts/qcom-ipq4019-ap.dk04.1.dtsi | 147 ++
 1 file changed, 147 insertions(+)
 create mode 100644 arch/arm/boot/dts/qcom-ipq4019-ap.dk04.1.dtsi

diff --git a/arch/arm/boot/dts/qcom-ipq4019-ap.dk04.1.dtsi 
b/arch/arm/boot/dts/qcom-ipq4019-ap.dk04.1.dtsi
new file mode 100644
index 000..c25f3e3
--- /dev/null
+++ b/arch/arm/boot/dts/qcom-ipq4019-ap.dk04.1.dtsi
@@ -0,0 +1,147 @@
+// SPDX-License-Identifier: GPL-2.0
+// Copyright (c) 2017, The Linux Foundation. All rights reserved.
+
+#include "qcom-ipq4019.dtsi"
+#include 
+#include 
+
+/ {
+   model = "Qualcomm Technologies, Inc. IPQ4019/AP-DK04.1";
+   compatible = "qcom,ipq4019";
+
+   memory {
+   device_type = "memory";
+   reg = <0x8000 0x1000>; /* 256MB */
+   };
+
+   reserved-memory {
+   #address-cells = <1>;
+   #size-cells = <1>;
+   ranges;
+
+   rsvd1@8700 {
+   /* Reserved for other subsystem */
+   reg = <0x8700 0x50>;
+   no-map;
+   };
+
+   wifi_dump@8750 {
+   reg = <0x8750 0x60>;
+   no-map;
+   };
+
+   rsvd2@87B0 {
+   /* Reserved for other subsystem */
+   reg = <0x87B0 0x50>;
+   no-map;
+   };
+   };
+
+   soc {
+   pinctrl@100 {
+   serial_0_pins: serial0_pinmux {
+   mux {
+   pins = "gpio16", "gpio17";
+   function = "blsp_uart0";
+   bias-disable;
+   };
+   };
+
+   serial_1_pins: serial1_pinmux {
+   mux {
+   pins = "gpio8", "gpio9",
+   "gpio10", "gpio11";
+   function = "blsp_uart1";
+   bias-disable;
+   };
+   };
+
+   spi_0_pins: spi_0_pinmux {
+   pinmux {
+   function = "blsp_spi0";
+   pins = "gpio13", "gpio14", "gpio15";
+   bias-disable;
+   };
+   pinmux_cs {
+   function = "gpio";
+   pins = "gpio12";
+   bias-disable;
+   output-high;
+   };
+   };
+
+   i2c_0_pins: i2c_0_pinmux {
+   mux {
+   pins = "gpio20", "gpio21";
+   function = "blsp_i2c0";
+   bias-disable;
+   };
+   };
+
+   nand_pins: nand_pins {
+   pullups {
+   pins = "gpio52", "gpio53", "gpio58",
+   "gpio59";
+   function = "qpic";
+   bias-pull-up;
+   };
+
+   pulldowns {
+   pins = "gpio54", "gpio55", "gpio56",
+   "gpio57", "gpio60", "gpio61",
+   "gpio62", "gpio63", "gpio64",
+   "gpio65", "gpio66", "gpio67",
+   "gpio68", "gpio69";
+   function = "qpic";
+   bias-pull-down;
+   };
+   };
+   };
+
+   serial@78af000 {
+   pinctrl-0 = <_0_pins>;
+   pinctrl-names = "default";
+   status = "ok";
+   };
+
+   serial@78b {
+   pinctrl-0 = <_1_pins>;
+   pinctrl-names = "default";
+   status = "ok";
+   };
+
+   blsp_dma: dma@7884000 {
+   status = "ok";
+   };
+
+   spi_0: spi@78b5000 { /* BLSP1 QUP1 */
+   pinctrl-0 = <_0_pins>;
+