Re: [PATCH V10 05/19] block: introduce bvec_last_segment()

[Ming Lei]

On Thu, Nov 15, 2018 at 03:23:56PM -0800, Omar Sandoval wrote:
> On Thu, Nov 15, 2018 at 04:52:52PM +0800, Ming Lei wrote:
> > BTRFS and guard_bio_eod() need to get the last singlepage segment
> > from one multipage bvec, so introduce this helper to make them happy.
> > 
> > Cc: Dave Chinner 
> > Cc: Kent Overstreet 
> > Cc: Mike Snitzer 
> > Cc: dm-de...@redhat.com
> > Cc: Alexander Viro 
> > Cc: linux-fsde...@vger.kernel.org
> > Cc: Shaohua Li 
> > Cc: linux-r...@vger.kernel.org
> > Cc: linux-er...@lists.ozlabs.org
> > Cc: David Sterba 
> > Cc: linux-bt...@vger.kernel.org
> > Cc: Darrick J. Wong 
> > Cc: linux-...@vger.kernel.org
> > Cc: Gao Xiang 
> > Cc: Christoph Hellwig 
> > Cc: Theodore Ts'o 
> > Cc: linux-e...@vger.kernel.org
> > Cc: Coly Li 
> > Cc: linux-bca...@vger.kernel.org
> > Cc: Boaz Harrosh 
> > Cc: Bob Peterson 
> > Cc: cluster-de...@redhat.com
> 
> Reviewed-by: Omar Sandoval 
> 
> Minor comments below.
> 
> > Signed-off-by: Ming Lei 
> > ---
> >  include/linux/bvec.h | 25 +
> >  1 file changed, 25 insertions(+)
> > 
> > diff --git a/include/linux/bvec.h b/include/linux/bvec.h
> > index 3d61352cd8cf..01616a0b6220 100644
> > --- a/include/linux/bvec.h
> > +++ b/include/linux/bvec.h
> > @@ -216,4 +216,29 @@ static inline bool mp_bvec_iter_advance(const struct 
> > bio_vec *bv,
> > .bi_bvec_done   = 0,\
> >  }
> >  
> > +/*
> > + * Get the last singlepage segment from the multipage bvec and store it
> > + * in @seg
> > + */
> > +static inline void bvec_last_segment(const struct bio_vec *bvec,
> > +   struct bio_vec *seg)
> 
> Indentation is all messed up here.

Will fix it.

> 
> > +{
> > +   unsigned total = bvec->bv_offset + bvec->bv_len;
> > +   unsigned last_page = total / PAGE_SIZE;
> > +
> > +   if (last_page * PAGE_SIZE == total)
> > +   last_page--;
> 
> I think this could just be
> 
>   unsigned int last_page = (total - 1) / PAGE_SIZE;

This way is really elegant.

Thanks,
Ming

Re: [PATCH V10 05/19] block: introduce bvec_last_segment()

[Ming Lei]

On Thu, Nov 15, 2018 at 03:23:56PM -0800, Omar Sandoval wrote:
> On Thu, Nov 15, 2018 at 04:52:52PM +0800, Ming Lei wrote:
> > BTRFS and guard_bio_eod() need to get the last singlepage segment
> > from one multipage bvec, so introduce this helper to make them happy.
> > 
> > Cc: Dave Chinner 
> > Cc: Kent Overstreet 
> > Cc: Mike Snitzer 
> > Cc: dm-de...@redhat.com
> > Cc: Alexander Viro 
> > Cc: linux-fsde...@vger.kernel.org
> > Cc: Shaohua Li 
> > Cc: linux-r...@vger.kernel.org
> > Cc: linux-er...@lists.ozlabs.org
> > Cc: David Sterba 
> > Cc: linux-bt...@vger.kernel.org
> > Cc: Darrick J. Wong 
> > Cc: linux-...@vger.kernel.org
> > Cc: Gao Xiang 
> > Cc: Christoph Hellwig 
> > Cc: Theodore Ts'o 
> > Cc: linux-e...@vger.kernel.org
> > Cc: Coly Li 
> > Cc: linux-bca...@vger.kernel.org
> > Cc: Boaz Harrosh 
> > Cc: Bob Peterson 
> > Cc: cluster-de...@redhat.com
> 
> Reviewed-by: Omar Sandoval 
> 
> Minor comments below.
> 
> > Signed-off-by: Ming Lei 
> > ---
> >  include/linux/bvec.h | 25 +
> >  1 file changed, 25 insertions(+)
> > 
> > diff --git a/include/linux/bvec.h b/include/linux/bvec.h
> > index 3d61352cd8cf..01616a0b6220 100644
> > --- a/include/linux/bvec.h
> > +++ b/include/linux/bvec.h
> > @@ -216,4 +216,29 @@ static inline bool mp_bvec_iter_advance(const struct 
> > bio_vec *bv,
> > .bi_bvec_done   = 0,\
> >  }
> >  
> > +/*
> > + * Get the last singlepage segment from the multipage bvec and store it
> > + * in @seg
> > + */
> > +static inline void bvec_last_segment(const struct bio_vec *bvec,
> > +   struct bio_vec *seg)
> 
> Indentation is all messed up here.

Will fix it.

> 
> > +{
> > +   unsigned total = bvec->bv_offset + bvec->bv_len;
> > +   unsigned last_page = total / PAGE_SIZE;
> > +
> > +   if (last_page * PAGE_SIZE == total)
> > +   last_page--;
> 
> I think this could just be
> 
>   unsigned int last_page = (total - 1) / PAGE_SIZE;

This way is really elegant.

Thanks,
Ming

Re: [PATCH V10 04/19] block: use bio_for_each_bvec() to map sg

[Ming Lei]

On Fri, Nov 16, 2018 at 02:33:14PM +0100, Christoph Hellwig wrote:
> > +   if (!*sg)
> > +   return sglist;
> > +   else {
> 
> No need for an else after an early return.

OK, good catch!

Thanks,
Ming

Re: [PATCH V10 04/19] block: use bio_for_each_bvec() to map sg

[Ming Lei]

On Fri, Nov 16, 2018 at 02:33:14PM +0100, Christoph Hellwig wrote:
> > +   if (!*sg)
> > +   return sglist;
> > +   else {
> 
> No need for an else after an early return.

OK, good catch!

Thanks,
Ming

Re: [PATCH V10 03/19] block: use bio_for_each_bvec() to compute multi-page bvec count

[Ming Lei]

On Thu, Nov 15, 2018 at 12:20:28PM -0800, Omar Sandoval wrote:
> On Thu, Nov 15, 2018 at 04:52:50PM +0800, Ming Lei wrote:
> > First it is more efficient to use bio_for_each_bvec() in both
> > blk_bio_segment_split() and __blk_recalc_rq_segments() to compute how
> > many multi-page bvecs there are in the bio.
> > 
> > Secondly once bio_for_each_bvec() is used, the bvec may need to be
> > splitted because its length can be very longer than max segment size,
> > so we have to split the big bvec into several segments.
> > 
> > Thirdly when splitting multi-page bvec into segments, the max segment
> > limit may be reached, so the bio split need to be considered under
> > this situation too.
> > 
> > Cc: Dave Chinner 
> > Cc: Kent Overstreet 
> > Cc: Mike Snitzer 
> > Cc: dm-de...@redhat.com
> > Cc: Alexander Viro 
> > Cc: linux-fsde...@vger.kernel.org
> > Cc: Shaohua Li 
> > Cc: linux-r...@vger.kernel.org
> > Cc: linux-er...@lists.ozlabs.org
> > Cc: David Sterba 
> > Cc: linux-bt...@vger.kernel.org
> > Cc: Darrick J. Wong 
> > Cc: linux-...@vger.kernel.org
> > Cc: Gao Xiang 
> > Cc: Christoph Hellwig 
> > Cc: Theodore Ts'o 
> > Cc: linux-e...@vger.kernel.org
> > Cc: Coly Li 
> > Cc: linux-bca...@vger.kernel.org
> > Cc: Boaz Harrosh 
> > Cc: Bob Peterson 
> > Cc: cluster-de...@redhat.com
> > Signed-off-by: Ming Lei 
> > ---
> >  block/blk-merge.c | 90 
> > ++-
> >  1 file changed, 76 insertions(+), 14 deletions(-)
> > 
> > diff --git a/block/blk-merge.c b/block/blk-merge.c
> > index 91b2af332a84..6f7deb94a23f 100644
> > --- a/block/blk-merge.c
> > +++ b/block/blk-merge.c
> > @@ -160,6 +160,62 @@ static inline unsigned get_max_io_size(struct 
> > request_queue *q,
> > return sectors;
> >  }
> >  
> > +/*
> > + * Split the bvec @bv into segments, and update all kinds of
> > + * variables.
> > + */
> > +static bool bvec_split_segs(struct request_queue *q, struct bio_vec *bv,
> > +   unsigned *nsegs, unsigned *last_seg_size,
> > +   unsigned *front_seg_size, unsigned *sectors)
> > +{
> > +   bool need_split = false;
> > +   unsigned len = bv->bv_len;
> > +   unsigned total_len = 0;
> > +   unsigned new_nsegs = 0, seg_size = 0;
> 
> "unsigned int" here and everywhere else.
> 
> > +   if ((*nsegs >= queue_max_segments(q)) || !len)
> > +   return need_split;
> > +
> > +   /*
> > +* Multipage bvec may be too big to hold in one segment,
> > +* so the current bvec has to be splitted as multiple
> > +* segments.
> > +*/
> > +   while (new_nsegs + *nsegs < queue_max_segments(q)) {
> > +   seg_size = min(queue_max_segment_size(q), len);
> > +
> > +   new_nsegs++;
> > +   total_len += seg_size;
> > +   len -= seg_size;
> > +
> > +   if ((queue_virt_boundary(q) && ((bv->bv_offset +
> > +   total_len) & queue_virt_boundary(q))) || !len)
> > +   break;
> 
> Checking queue_virt_boundary(q) != 0 is superfluous, and the len check
> could just control the loop, i.e.,
> 
>   while (len && new_nsegs + *nsegs < queue_max_segments(q)) {
>   seg_size = min(queue_max_segment_size(q), len);
> 
>   new_nsegs++;
>   total_len += seg_size;
>   len -= seg_size;
> 
>   if ((bv->bv_offset + total_len) & queue_virt_boundary(q))
>   break;
>   }
> 
> And if you rewrite it this way, I _think_ you can get rid of this
> special case:
> 
>   if ((*nsegs >= queue_max_segments(q)) || !len)
>   return need_split;
> 
> above.

Good point, will do in next version.

> 
> > +   }
> > +
> > +   /* split in the middle of the bvec */
> > +   if (len)
> > +   need_split = true;
> 
> need_split is unnecessary, just return len != 0.

OK.

> 
> > +
> > +   /* update front segment size */
> > +   if (!*nsegs) {
> > +   unsigned first_seg_size = seg_size;
> > +
> > +   if (new_nsegs > 1)
> > +   first_seg_size = queue_max_segment_size(q);
> > +   if (*front_seg_size < first_seg_size)
> > +   *front_seg_size = first_seg_size;
> > +   }
> > +
> > +   /* update other varibles */
> > +   *last_seg_size = seg_size;
> > +   *nsegs += new_nsegs;
> > +   if (sectors)
> > +   *sectors += total_len >> 9;
> > +
> > +   return need_split;
> > +}
> > +
> >  static struct bio *blk_bio_segment_split(struct request_queue *q,
> >  struct bio *bio,
> >  struct bio_set *bs,
> > @@ -173,7 +229,7 @@ static struct bio *blk_bio_segment_split(struct 
> > request_queue *q,
> > struct bio *new = NULL;
> > const unsigned max_sectors = get_max_io_size(q, bio);
> >  
> > -   bio_for_each_segment(bv, bio, iter) {
> > +   bio_for_each_bvec(bv, bio, iter) {
> > /*
> >  * If the queue doesn't support SG gaps and adding this
> >  * offset would create 

Re: [PATCH V10 03/19] block: use bio_for_each_bvec() to compute multi-page bvec count

[Ming Lei]

On Thu, Nov 15, 2018 at 12:20:28PM -0800, Omar Sandoval wrote:
> On Thu, Nov 15, 2018 at 04:52:50PM +0800, Ming Lei wrote:
> > First it is more efficient to use bio_for_each_bvec() in both
> > blk_bio_segment_split() and __blk_recalc_rq_segments() to compute how
> > many multi-page bvecs there are in the bio.
> > 
> > Secondly once bio_for_each_bvec() is used, the bvec may need to be
> > splitted because its length can be very longer than max segment size,
> > so we have to split the big bvec into several segments.
> > 
> > Thirdly when splitting multi-page bvec into segments, the max segment
> > limit may be reached, so the bio split need to be considered under
> > this situation too.
> > 
> > Cc: Dave Chinner 
> > Cc: Kent Overstreet 
> > Cc: Mike Snitzer 
> > Cc: dm-de...@redhat.com
> > Cc: Alexander Viro 
> > Cc: linux-fsde...@vger.kernel.org
> > Cc: Shaohua Li 
> > Cc: linux-r...@vger.kernel.org
> > Cc: linux-er...@lists.ozlabs.org
> > Cc: David Sterba 
> > Cc: linux-bt...@vger.kernel.org
> > Cc: Darrick J. Wong 
> > Cc: linux-...@vger.kernel.org
> > Cc: Gao Xiang 
> > Cc: Christoph Hellwig 
> > Cc: Theodore Ts'o 
> > Cc: linux-e...@vger.kernel.org
> > Cc: Coly Li 
> > Cc: linux-bca...@vger.kernel.org
> > Cc: Boaz Harrosh 
> > Cc: Bob Peterson 
> > Cc: cluster-de...@redhat.com
> > Signed-off-by: Ming Lei 
> > ---
> >  block/blk-merge.c | 90 
> > ++-
> >  1 file changed, 76 insertions(+), 14 deletions(-)
> > 
> > diff --git a/block/blk-merge.c b/block/blk-merge.c
> > index 91b2af332a84..6f7deb94a23f 100644
> > --- a/block/blk-merge.c
> > +++ b/block/blk-merge.c
> > @@ -160,6 +160,62 @@ static inline unsigned get_max_io_size(struct 
> > request_queue *q,
> > return sectors;
> >  }
> >  
> > +/*
> > + * Split the bvec @bv into segments, and update all kinds of
> > + * variables.
> > + */
> > +static bool bvec_split_segs(struct request_queue *q, struct bio_vec *bv,
> > +   unsigned *nsegs, unsigned *last_seg_size,
> > +   unsigned *front_seg_size, unsigned *sectors)
> > +{
> > +   bool need_split = false;
> > +   unsigned len = bv->bv_len;
> > +   unsigned total_len = 0;
> > +   unsigned new_nsegs = 0, seg_size = 0;
> 
> "unsigned int" here and everywhere else.
> 
> > +   if ((*nsegs >= queue_max_segments(q)) || !len)
> > +   return need_split;
> > +
> > +   /*
> > +* Multipage bvec may be too big to hold in one segment,
> > +* so the current bvec has to be splitted as multiple
> > +* segments.
> > +*/
> > +   while (new_nsegs + *nsegs < queue_max_segments(q)) {
> > +   seg_size = min(queue_max_segment_size(q), len);
> > +
> > +   new_nsegs++;
> > +   total_len += seg_size;
> > +   len -= seg_size;
> > +
> > +   if ((queue_virt_boundary(q) && ((bv->bv_offset +
> > +   total_len) & queue_virt_boundary(q))) || !len)
> > +   break;
> 
> Checking queue_virt_boundary(q) != 0 is superfluous, and the len check
> could just control the loop, i.e.,
> 
>   while (len && new_nsegs + *nsegs < queue_max_segments(q)) {
>   seg_size = min(queue_max_segment_size(q), len);
> 
>   new_nsegs++;
>   total_len += seg_size;
>   len -= seg_size;
> 
>   if ((bv->bv_offset + total_len) & queue_virt_boundary(q))
>   break;
>   }
> 
> And if you rewrite it this way, I _think_ you can get rid of this
> special case:
> 
>   if ((*nsegs >= queue_max_segments(q)) || !len)
>   return need_split;
> 
> above.

Good point, will do in next version.

> 
> > +   }
> > +
> > +   /* split in the middle of the bvec */
> > +   if (len)
> > +   need_split = true;
> 
> need_split is unnecessary, just return len != 0.

OK.

> 
> > +
> > +   /* update front segment size */
> > +   if (!*nsegs) {
> > +   unsigned first_seg_size = seg_size;
> > +
> > +   if (new_nsegs > 1)
> > +   first_seg_size = queue_max_segment_size(q);
> > +   if (*front_seg_size < first_seg_size)
> > +   *front_seg_size = first_seg_size;
> > +   }
> > +
> > +   /* update other varibles */
> > +   *last_seg_size = seg_size;
> > +   *nsegs += new_nsegs;
> > +   if (sectors)
> > +   *sectors += total_len >> 9;
> > +
> > +   return need_split;
> > +}
> > +
> >  static struct bio *blk_bio_segment_split(struct request_queue *q,
> >  struct bio *bio,
> >  struct bio_set *bs,
> > @@ -173,7 +229,7 @@ static struct bio *blk_bio_segment_split(struct 
> > request_queue *q,
> > struct bio *new = NULL;
> > const unsigned max_sectors = get_max_io_size(q, bio);
> >  
> > -   bio_for_each_segment(bv, bio, iter) {
> > +   bio_for_each_bvec(bv, bio, iter) {
> > /*
> >  * If the queue doesn't support SG gaps and adding this
> >  * offset would create 

Re: [PATCH v2 3/3] mmc: sdhci-pci: only install voltage switch method when useful

[Adrian Hunter]

On 16/11/18 6:58 PM, Anisse Astier wrote:
> Hi Adrian,
> 
> On Tue, Oct 23, 2018 at 12:07:29PM +0200, Anisse Astier wrote:
>> If there's no ACPI DSM for voltage switch, it will just cause a lot of
>> debug info down the line, we only need one at startup.
>>
>> Signed-off-by: Anisse Astier 
>> ---
>>  drivers/mmc/host/sdhci-pci-core.c | 11 +++
>>  1 file changed, 11 insertions(+)
>>
>> diff --git a/drivers/mmc/host/sdhci-pci-core.c 
>> b/drivers/mmc/host/sdhci-pci-core.c
>> index f2c1fb339d66..95fdbb883c7e 100644
>> --- a/drivers/mmc/host/sdhci-pci-core.c
>> +++ b/drivers/mmc/host/sdhci-pci-core.c
>> @@ -723,6 +723,7 @@ static const struct dmi_system_id board_no_1_8v[] = {
>>  static void byt_probe_slot(struct sdhci_pci_slot *slot)
>>  {
>>  struct mmc_host_ops *ops = >host->mmc_host_ops;
>> +struct intel_host *intel_host = sdhci_pci_priv(slot);
>>  
>>  byt_read_dsm(slot);
>>  
>> @@ -733,6 +734,16 @@ static void byt_probe_slot(struct sdhci_pci_slot *slot)
>>  mmc_hostname(slot->host->mmc));
>>  slot->host->quirks2 |= SDHCI_QUIRK2_NO_1_8_V;
>>  }
>> +/* Check if we have the appropriate voltage switch DSM methods */
>> +if (!(intel_host->dsm_fns & (1 << INTEL_DSM_V18_SWITCH)) &&
>> +!(intel_host->dsm_fns & (1 << INTEL_DSM_V33_SWITCH))) {
>> +/* No voltage switching supported at all, there's no
>> + * point in installing the callback: return.
>> + */
>> +pr_debug("%s: No voltage switching ACPI DSM helper\n",
>> +mmc_hostname(slot->host->mmc));
>> +return;
>> +}
>>  ops->start_signal_voltage_switch = intel_start_signal_voltage_switch;
>>  }
>>  
>> -- 
>> 2.17.2
>>
> 
> What do you think of picking this last patch ? Or maybe you had
> different cleanups in mind when you said you wanted to rework this ?

Voltage switches are relatively rare, and dynamic debug allows control over
exactly which debug messages display, so I am not sure this patch is needed.

Re: [PATCH v2 3/3] mmc: sdhci-pci: only install voltage switch method when useful

[Adrian Hunter]

On 16/11/18 6:58 PM, Anisse Astier wrote:
> Hi Adrian,
> 
> On Tue, Oct 23, 2018 at 12:07:29PM +0200, Anisse Astier wrote:
>> If there's no ACPI DSM for voltage switch, it will just cause a lot of
>> debug info down the line, we only need one at startup.
>>
>> Signed-off-by: Anisse Astier 
>> ---
>>  drivers/mmc/host/sdhci-pci-core.c | 11 +++
>>  1 file changed, 11 insertions(+)
>>
>> diff --git a/drivers/mmc/host/sdhci-pci-core.c 
>> b/drivers/mmc/host/sdhci-pci-core.c
>> index f2c1fb339d66..95fdbb883c7e 100644
>> --- a/drivers/mmc/host/sdhci-pci-core.c
>> +++ b/drivers/mmc/host/sdhci-pci-core.c
>> @@ -723,6 +723,7 @@ static const struct dmi_system_id board_no_1_8v[] = {
>>  static void byt_probe_slot(struct sdhci_pci_slot *slot)
>>  {
>>  struct mmc_host_ops *ops = >host->mmc_host_ops;
>> +struct intel_host *intel_host = sdhci_pci_priv(slot);
>>  
>>  byt_read_dsm(slot);
>>  
>> @@ -733,6 +734,16 @@ static void byt_probe_slot(struct sdhci_pci_slot *slot)
>>  mmc_hostname(slot->host->mmc));
>>  slot->host->quirks2 |= SDHCI_QUIRK2_NO_1_8_V;
>>  }
>> +/* Check if we have the appropriate voltage switch DSM methods */
>> +if (!(intel_host->dsm_fns & (1 << INTEL_DSM_V18_SWITCH)) &&
>> +!(intel_host->dsm_fns & (1 << INTEL_DSM_V33_SWITCH))) {
>> +/* No voltage switching supported at all, there's no
>> + * point in installing the callback: return.
>> + */
>> +pr_debug("%s: No voltage switching ACPI DSM helper\n",
>> +mmc_hostname(slot->host->mmc));
>> +return;
>> +}
>>  ops->start_signal_voltage_switch = intel_start_signal_voltage_switch;
>>  }
>>  
>> -- 
>> 2.17.2
>>
> 
> What do you think of picking this last patch ? Or maybe you had
> different cleanups in mind when you said you wanted to rework this ?

Voltage switches are relatively rare, and dynamic debug allows control over
exactly which debug messages display, so I am not sure this patch is needed.

Re: [RCF PATCH,v2,2/2] pwm: imx: Configure output to GPIO in disabled state

[Linus Walleij]

On Wed, Nov 14, 2018 at 10:51 PM Uwe Kleine-König
 wrote:
> On Wed, Nov 14, 2018 at 12:34:49PM +0100, Thierry Reding wrote:
> > On Fri, Nov 09, 2018 at 05:55:55PM +0100, Uwe Kleine-König wrote:
> > > On Fri, Nov 09, 2018 at 02:24:42PM +, Vokáč Michal wrote:
> > > > On 8.11.2018 20:18, Uwe Kleine-König wrote:
> > > > > Taking your example with the backlight device you specify an "init" 
> > > > > and
> > > > > a "default" pinctrl and only "default" contains the muxing for the PWM
> > > > > pin everything should be as smooth as necessary: The pwm is only muxed
> > > > > when the backlight device is successfully bound.
> > > >
> > > > Have you tried that Uwe? The bad news is I tested that before and now
> > > > again and it does not work like that. We already discussed that earlier.
> > >
> > > The key is that the pinmux setting for the PWM pin should be part of the
> > > bl pinctrl, not the pwm pinctrl. Then "default" is only setup when the
> > > bl device is successfully bound which is after the bl's .probe callback
> > > called pwm_apply().
> >
> > No, that's not at all correct. Pinmux settings should reside with the
> > consumer of the pin. In this case, the PWM is the consumer of the pin,
> > whereas the backlight is the consumer of the *PWM*.
>
> This is news to me. Adding Linus W. to Cc, maybe he can comment?!
>
> Grepping through the arm device trees it really seems common to put the
> pinctrl for the pwm pin into the pwm device. I didn't search in depth,
> but I didn't find a counter example.
>
> For GPIOs it is common that the pinmuxing is included in the GPIO's
> consumer pinctrl. Ditto for mdio busses whose pinctrl is included in the
> ethernet pinctrl.

There is quite a discussion you folks have going on here. I tried to
grasp it but I can't. I can try to answer the above question specifically.

For pin control it is mainly paramount that the state is associated
with *a* consumer. The problem we were facing when fleshing out
the subsystem can be seen in horrific solutions such as in
Documentation/devicetree/bindings/gpio/gpio-twl4030.txt
where you see that pull-ups and pull-downs are set on the
PRODUCER side, which just make everything a complete
mess.

So compared to things like that (that we still have to support
forever) whatever you are doing here you're doing great as long
as it is consumer controlled.

Whether that consumer is the previous driver thingie in the
daisy-chain of consumers or the final end user consumer of
the pin doesn't really matter to pin control, as long as it is a
consumer. I would tend to say it is up to the subsystem,
and the old IETF motto "rough consensus and running code".

It seems in the current discussion the "rough consensus"
part is the problem, and I'm afraid I can't fix that.

Yours,
Linus Walleij

Re: [RCF PATCH,v2,2/2] pwm: imx: Configure output to GPIO in disabled state

[Linus Walleij]

On Wed, Nov 14, 2018 at 10:51 PM Uwe Kleine-König
 wrote:
> On Wed, Nov 14, 2018 at 12:34:49PM +0100, Thierry Reding wrote:
> > On Fri, Nov 09, 2018 at 05:55:55PM +0100, Uwe Kleine-König wrote:
> > > On Fri, Nov 09, 2018 at 02:24:42PM +, Vokáč Michal wrote:
> > > > On 8.11.2018 20:18, Uwe Kleine-König wrote:
> > > > > Taking your example with the backlight device you specify an "init" 
> > > > > and
> > > > > a "default" pinctrl and only "default" contains the muxing for the PWM
> > > > > pin everything should be as smooth as necessary: The pwm is only muxed
> > > > > when the backlight device is successfully bound.
> > > >
> > > > Have you tried that Uwe? The bad news is I tested that before and now
> > > > again and it does not work like that. We already discussed that earlier.
> > >
> > > The key is that the pinmux setting for the PWM pin should be part of the
> > > bl pinctrl, not the pwm pinctrl. Then "default" is only setup when the
> > > bl device is successfully bound which is after the bl's .probe callback
> > > called pwm_apply().
> >
> > No, that's not at all correct. Pinmux settings should reside with the
> > consumer of the pin. In this case, the PWM is the consumer of the pin,
> > whereas the backlight is the consumer of the *PWM*.
>
> This is news to me. Adding Linus W. to Cc, maybe he can comment?!
>
> Grepping through the arm device trees it really seems common to put the
> pinctrl for the pwm pin into the pwm device. I didn't search in depth,
> but I didn't find a counter example.
>
> For GPIOs it is common that the pinmuxing is included in the GPIO's
> consumer pinctrl. Ditto for mdio busses whose pinctrl is included in the
> ethernet pinctrl.

There is quite a discussion you folks have going on here. I tried to
grasp it but I can't. I can try to answer the above question specifically.

For pin control it is mainly paramount that the state is associated
with *a* consumer. The problem we were facing when fleshing out
the subsystem can be seen in horrific solutions such as in
Documentation/devicetree/bindings/gpio/gpio-twl4030.txt
where you see that pull-ups and pull-downs are set on the
PRODUCER side, which just make everything a complete
mess.

So compared to things like that (that we still have to support
forever) whatever you are doing here you're doing great as long
as it is consumer controlled.

Whether that consumer is the previous driver thingie in the
daisy-chain of consumers or the final end user consumer of
the pin doesn't really matter to pin control, as long as it is a
consumer. I would tend to say it is up to the subsystem,
and the old IETF motto "rough consensus and running code".

It seems in the current discussion the "rough consensus"
part is the problem, and I'm afraid I can't fix that.

Yours,
Linus Walleij

Re: [PATCH] pinctrl: zynq: Use define directive for PIN_CONFIG_IO_STANDARD

[Michal Simek]

On 17. 11. 18 2:56, Nathan Chancellor wrote:
> On Fri, Nov 16, 2018 at 09:40:45AM +0100, Michal Simek wrote:
>> On 09. 11. 18 16:36, Nathan Chancellor wrote:
>>> On Fri, Nov 09, 2018 at 10:33:00AM +0100, Michal Simek wrote:
 On 08. 11. 18 16:01, Nathan Chancellor wrote:
> On Thu, Nov 08, 2018 at 07:45:42AM +0100, Michal Simek wrote:
>> On 07. 11. 18 18:48, Nick Desaulniers wrote:
>>> On Wed, Nov 7, 2018 at 1:01 AM Michal Simek  
>>> wrote:

 On 07. 11. 18 9:55, Nathan Chancellor wrote:
> On Wed, Nov 07, 2018 at 09:46:12AM +0100, Michal Simek wrote:
>> On 01. 11. 18 1:57, Nathan Chancellor wrote:
>>> Clang warns when one enumerated type is implicitly converted to 
>>> another:
>>>
>>> drivers/pinctrl/pinctrl-zynq.c:985:18: warning: implicit conversion 
>>> from
>>> enumeration type 'enum zynq_pin_config_param' to different 
>>> enumeration
>>> type 'enum pin_config_param' [-Wenum-conversion]
>>> {"io-standard", PIN_CONFIG_IOSTANDARD, zynq_iostd_lvcmos18},
>>> ~   ^
>>> drivers/pinctrl/pinctrl-zynq.c:990:16: warning: implicit conversion 
>>> from
>>> enumeration type 'enum zynq_pin_config_param' to different 
>>> enumeration
>>> type 'enum pin_config_param' [-Wenum-conversion]
>>> = { PCONFDUMP(PIN_CONFIG_IOSTANDARD, "IO-standard", NULL, 
>>> true),
>>> 
>>> ~~^
>>> ./include/linux/pinctrl/pinconf-generic.h:163:11: note: expanded 
>>> from
>>> macro 'PCONFDUMP'
>>> .param = a, .display = b, .format = c, .has_arg = d \
>>>  ^
>>> 2 warnings generated.
>>
>> This is interesting. I have never tried to use llvm for building the
>> kernel. Do you have any description how this can be done?
>>
>
> Depending on what version of Clang you have access to, it is usually 
> just as
> simple as running 'make ARCH=arm CC=clang 
> CROSS_COMPILE=arm-linux-gnueabi-'.
>
> Clang 7.0+ is recommended but 6.0 might work too.

 TBH I would expect to download container and run this there to make 
 sure
 that I don't break anything else.
>>>
>>> This is the first request we've had for a container in order to test a
>>> patch.  If it comes up again from other folks, I think it makes sense
>>> to create one.  Until then, its nice to have.  It's definitely
>>> overkill for this patch.
>>
>> I have played with it to see that error and here are some steps I did.
>>
>> docker run --name test-clang -it --rm debian:latest bash
>> apt-get update
>> apt-get install gcc-arm-linux-gnueabi gcc-aarch64-linux-gnu clang git bc
>> build-essential bison flex make llvm vim libssl-dev sparse
>>
>> git clone
>> git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git --depth 
>> 1
>> cd linux
>>
>> export ARCH=arm64
>> export CROSS_COMPILE=aarch64-linux-gnu-
>>
>> make defconfig
>
> This should also have 'CC=clang' because compiler detection happens in
> Kconfig now so compiler flags get properly set. Other than that, looks
> good and I was able to build pinctrl-zynq.o without any issues with
> those commands.

 For arm32 I am still getting compilation issue (arm64 is fine)
 Below are my steps and version I use. Do you know what could be the
 problem?

 Thanks,
 Michal

 root@1e15921e6d15:~/linux# arm-linux-gnueabi-gcc --version
 arm-linux-gnueabi-gcc (Debian 6.3.0-18) 6.3.0 20170516
 Copyright (C) 2016 Free Software Foundation, Inc.
 This is free software; see the source for copying conditions.  There is NO
 warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

 root@1e15921e6d15:~/linux# clang --version
 clang version 3.8.1-24 (tags/RELEASE_381/final)
 Target: x86_64-pc-linux-gnu
 Thread model: posix
 InstalledDir: /usr/bin


 export ARCH=arm
 export CROSS_COMPILE=arm-linux-gnuaebi-
 make CC=clang defconfig
 make CC=clang drivers/pinctrl/pinctrl-zynq.o

 and I get
 clang: error: unsupported argument '-W' to option 'Wa,'
 scripts/Makefile.build:305: recipe for target 'scripts/mod/empty.o' failed
 make[2]: *** [scripts/mod/empty.o] Error 1
 scripts/Makefile.build:546: recipe for target 'scripts/mod' failed

>>>
>>> Ah because Debian's regular Clang is ancient.
>>>
>>> For testing, we use the builds from apt.llvm.org. Commands assuming
>>> you're using the normal Debian image:
>>>
>>> curl https://apt.llvm.org/llvm-snapshot.gpg.key | apt-key add -
>>> echo "deb 

Re: [PATCH] pinctrl: zynq: Use define directive for PIN_CONFIG_IO_STANDARD

[Michal Simek]

On 17. 11. 18 2:56, Nathan Chancellor wrote:
> On Fri, Nov 16, 2018 at 09:40:45AM +0100, Michal Simek wrote:
>> On 09. 11. 18 16:36, Nathan Chancellor wrote:
>>> On Fri, Nov 09, 2018 at 10:33:00AM +0100, Michal Simek wrote:
 On 08. 11. 18 16:01, Nathan Chancellor wrote:
> On Thu, Nov 08, 2018 at 07:45:42AM +0100, Michal Simek wrote:
>> On 07. 11. 18 18:48, Nick Desaulniers wrote:
>>> On Wed, Nov 7, 2018 at 1:01 AM Michal Simek  
>>> wrote:

 On 07. 11. 18 9:55, Nathan Chancellor wrote:
> On Wed, Nov 07, 2018 at 09:46:12AM +0100, Michal Simek wrote:
>> On 01. 11. 18 1:57, Nathan Chancellor wrote:
>>> Clang warns when one enumerated type is implicitly converted to 
>>> another:
>>>
>>> drivers/pinctrl/pinctrl-zynq.c:985:18: warning: implicit conversion 
>>> from
>>> enumeration type 'enum zynq_pin_config_param' to different 
>>> enumeration
>>> type 'enum pin_config_param' [-Wenum-conversion]
>>> {"io-standard", PIN_CONFIG_IOSTANDARD, zynq_iostd_lvcmos18},
>>> ~   ^
>>> drivers/pinctrl/pinctrl-zynq.c:990:16: warning: implicit conversion 
>>> from
>>> enumeration type 'enum zynq_pin_config_param' to different 
>>> enumeration
>>> type 'enum pin_config_param' [-Wenum-conversion]
>>> = { PCONFDUMP(PIN_CONFIG_IOSTANDARD, "IO-standard", NULL, 
>>> true),
>>> 
>>> ~~^
>>> ./include/linux/pinctrl/pinconf-generic.h:163:11: note: expanded 
>>> from
>>> macro 'PCONFDUMP'
>>> .param = a, .display = b, .format = c, .has_arg = d \
>>>  ^
>>> 2 warnings generated.
>>
>> This is interesting. I have never tried to use llvm for building the
>> kernel. Do you have any description how this can be done?
>>
>
> Depending on what version of Clang you have access to, it is usually 
> just as
> simple as running 'make ARCH=arm CC=clang 
> CROSS_COMPILE=arm-linux-gnueabi-'.
>
> Clang 7.0+ is recommended but 6.0 might work too.

 TBH I would expect to download container and run this there to make 
 sure
 that I don't break anything else.
>>>
>>> This is the first request we've had for a container in order to test a
>>> patch.  If it comes up again from other folks, I think it makes sense
>>> to create one.  Until then, its nice to have.  It's definitely
>>> overkill for this patch.
>>
>> I have played with it to see that error and here are some steps I did.
>>
>> docker run --name test-clang -it --rm debian:latest bash
>> apt-get update
>> apt-get install gcc-arm-linux-gnueabi gcc-aarch64-linux-gnu clang git bc
>> build-essential bison flex make llvm vim libssl-dev sparse
>>
>> git clone
>> git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git --depth 
>> 1
>> cd linux
>>
>> export ARCH=arm64
>> export CROSS_COMPILE=aarch64-linux-gnu-
>>
>> make defconfig
>
> This should also have 'CC=clang' because compiler detection happens in
> Kconfig now so compiler flags get properly set. Other than that, looks
> good and I was able to build pinctrl-zynq.o without any issues with
> those commands.

 For arm32 I am still getting compilation issue (arm64 is fine)
 Below are my steps and version I use. Do you know what could be the
 problem?

 Thanks,
 Michal

 root@1e15921e6d15:~/linux# arm-linux-gnueabi-gcc --version
 arm-linux-gnueabi-gcc (Debian 6.3.0-18) 6.3.0 20170516
 Copyright (C) 2016 Free Software Foundation, Inc.
 This is free software; see the source for copying conditions.  There is NO
 warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

 root@1e15921e6d15:~/linux# clang --version
 clang version 3.8.1-24 (tags/RELEASE_381/final)
 Target: x86_64-pc-linux-gnu
 Thread model: posix
 InstalledDir: /usr/bin


 export ARCH=arm
 export CROSS_COMPILE=arm-linux-gnuaebi-
 make CC=clang defconfig
 make CC=clang drivers/pinctrl/pinctrl-zynq.o

 and I get
 clang: error: unsupported argument '-W' to option 'Wa,'
 scripts/Makefile.build:305: recipe for target 'scripts/mod/empty.o' failed
 make[2]: *** [scripts/mod/empty.o] Error 1
 scripts/Makefile.build:546: recipe for target 'scripts/mod' failed

>>>
>>> Ah because Debian's regular Clang is ancient.
>>>
>>> For testing, we use the builds from apt.llvm.org. Commands assuming
>>> you're using the normal Debian image:
>>>
>>> curl https://apt.llvm.org/llvm-snapshot.gpg.key | apt-key add -
>>> echo "deb 

[PATCH] arm64:crc:accelerated-crc32-by-64bytes

[Rui Sun]

add 64 bytes loop to acceleration calculation

Signed-off-by: Rui Sun 
---
 arch/arm64/lib/crc32.S | 54 ++
 1 file changed, 50 insertions(+), 4 deletions(-)

diff --git a/arch/arm64/lib/crc32.S b/arch/arm64/lib/crc32.S
index 5bc1e85..2b37009 100644
--- a/arch/arm64/lib/crc32.S
+++ b/arch/arm64/lib/crc32.S
@@ -15,15 +15,61 @@
.cpugeneric+crc
 
.macro  __crc32, c
-0: subsx2, x2, #16
-   b.mi8f
+
+64: cmp x2, #64
+b.lt32f
+
+addsx11, x1, #16
+addsx12, x1, #32
+addsx13, x1, #48
+
+0 : subsx2, x2, #64
+b.mi32f
+
+ldp x3, x4, [x1], #64
+ldp x5, x6, [x11], #64
+ldp x7, x8, [x12], #64
+ldp x9, x10,[x13], #64
+
+ CPU_BE( rev x3, x3  )
+ CPU_BE( rev x4, x4  )
+ CPU_BE( rev x5, x5  )
+ CPU_BE( rev x6, x6  )
+ CPU_BE( rev x7, x7  )
+ CPU_BE( rev x8, x8  )
+ CPU_BE( rev x9, x9  )
+ CPU_BE( rev x10,x10 )
+
+crc32\c\()x w0, w0, x3
+crc32\c\()x w0, w0, x4
+crc32\c\()x w0, w0, x5
+crc32\c\()x w0, w0, x6
+crc32\c\()x w0, w0, x7
+crc32\c\()x w0, w0, x8
+crc32\c\()x w0, w0, x9
+crc32\c\()x w0, w0, x10
+
+b.ne   0b
+ret
+
+32: tbz x2, #5, 16f
+ldp x3, x4, [x1], #16
+ldp x5, x6, [x1], #16
+CPU_BE( rev x3, x3  )
+CPU_BE( rev x4, x4  )
+CPU_BE( rev x5, x5  )
+CPU_BE( rev x6, x6  )
+crc32\c\()x w0, w0, x3
+crc32\c\()x w0, w0, x4
+crc32\c\()x w0, w0, x5
+crc32\c\()x w0, w0, x6
+
+16: tbz x2, #4, 8f
ldp x3, x4, [x1], #16
 CPU_BE(rev x3, x3  )
 CPU_BE(rev x4, x4  )
crc32\c\()x w0, w0, x3
crc32\c\()x w0, w0, x4
-   b.ne0b
-   ret
 
 8: tbz x2, #3, 4f
ldr x3, [x1], #8
-- 
1.8.3.1

[PATCH] arm64:crc:accelerated-crc32-by-64bytes

[Rui Sun]

add 64 bytes loop to acceleration calculation

Signed-off-by: Rui Sun 
---
 arch/arm64/lib/crc32.S | 54 ++
 1 file changed, 50 insertions(+), 4 deletions(-)

diff --git a/arch/arm64/lib/crc32.S b/arch/arm64/lib/crc32.S
index 5bc1e85..2b37009 100644
--- a/arch/arm64/lib/crc32.S
+++ b/arch/arm64/lib/crc32.S
@@ -15,15 +15,61 @@
.cpugeneric+crc
 
.macro  __crc32, c
-0: subsx2, x2, #16
-   b.mi8f
+
+64: cmp x2, #64
+b.lt32f
+
+addsx11, x1, #16
+addsx12, x1, #32
+addsx13, x1, #48
+
+0 : subsx2, x2, #64
+b.mi32f
+
+ldp x3, x4, [x1], #64
+ldp x5, x6, [x11], #64
+ldp x7, x8, [x12], #64
+ldp x9, x10,[x13], #64
+
+ CPU_BE( rev x3, x3  )
+ CPU_BE( rev x4, x4  )
+ CPU_BE( rev x5, x5  )
+ CPU_BE( rev x6, x6  )
+ CPU_BE( rev x7, x7  )
+ CPU_BE( rev x8, x8  )
+ CPU_BE( rev x9, x9  )
+ CPU_BE( rev x10,x10 )
+
+crc32\c\()x w0, w0, x3
+crc32\c\()x w0, w0, x4
+crc32\c\()x w0, w0, x5
+crc32\c\()x w0, w0, x6
+crc32\c\()x w0, w0, x7
+crc32\c\()x w0, w0, x8
+crc32\c\()x w0, w0, x9
+crc32\c\()x w0, w0, x10
+
+b.ne   0b
+ret
+
+32: tbz x2, #5, 16f
+ldp x3, x4, [x1], #16
+ldp x5, x6, [x1], #16
+CPU_BE( rev x3, x3  )
+CPU_BE( rev x4, x4  )
+CPU_BE( rev x5, x5  )
+CPU_BE( rev x6, x6  )
+crc32\c\()x w0, w0, x3
+crc32\c\()x w0, w0, x4
+crc32\c\()x w0, w0, x5
+crc32\c\()x w0, w0, x6
+
+16: tbz x2, #4, 8f
ldp x3, x4, [x1], #16
 CPU_BE(rev x3, x3  )
 CPU_BE(rev x4, x4  )
crc32\c\()x w0, w0, x3
crc32\c\()x w0, w0, x4
-   b.ne0b
-   ret
 
 8: tbz x2, #3, 4f
ldr x3, [x1], #8
-- 
1.8.3.1

Re: [PATCH v2 1/4] dt-bindings: pinctrl: k3: Introduce pinmux definitions

[Tero Kristo]

On 17/11/2018 18:05, Nishanth Menon wrote:

On 11:31-20181113, Vignesh R wrote:

The dt-bindings header for TI K3 AM6 SoCs define a set of macros for
defining pinmux configs in human readable form, instead of raw-coded
hex values.

Signed-off-by: Vignesh R 
---
  MAINTAINERS  |  1 +
  include/dt-bindings/pinctrl/k3.h | 35 
  2 files changed, 36 insertions(+)
  create mode 100644 include/dt-bindings/pinctrl/k3.h

diff --git a/MAINTAINERS b/MAINTAINERS
index fa45ff36fde9..1574ad6d7ead 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2204,6 +2204,7 @@ S:Supported
  F:Documentation/devicetree/bindings/arm/ti/k3.txt
  F:arch/arm64/boot/dts/ti/Makefile
  F:arch/arm64/boot/dts/ti/k3-*
+F: include/dt-bindings/pinctrl/k3.h
  
  ARM/TEXAS INSTRUMENT KEYSTONE ARCHITECTURE

  M:Santosh Shilimkar 
diff --git a/include/dt-bindings/pinctrl/k3.h b/include/dt-bindings/pinctrl/k3.h
new file mode 100644
index ..463d845a9b36
--- /dev/null
+++ b/include/dt-bindings/pinctrl/k3.h
@@ -0,0 +1,35 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * This header provides constants for pinctrl bindings for TI's K3 SoC
+ * family.
+ *
+ * Copyright (C) 2018 Texas Instruments Incorporated - http://www.ti.com/
+ */
+#ifndef _DT_BINDINGS_PINCTRL_TI_K3_H
+#define _DT_BINDINGS_PINCTRL_TI_K3_H
+
+#define PULLUDEN_SHIFT (16)
+#define PULLTYPESEL_SHIFT  (17)
+#define RXACTIVE_SHIFT (18)
+
+#define PULL_DISABLE   (1 << PULLUDEN_SHIFT)
+#define PULL_ENABLE(0 << PULLUDEN_SHIFT)
+
+#define PULL_UP(1 << PULLTYPESEL_SHIFT | PULL_ENABLE)
+#define PULL_DOWN  (0 << PULLTYPESEL_SHIFT | PULL_ENABLE)
+
+#define INPUT_EN   (1 << RXACTIVE_SHIFT)
+#define INPUT_DISABLE  (0 << RXACTIVE_SHIFT)
+
+/* Only these macros are expected be used directly in device tree files */
+#define PIN_OUTPUT (INPUT_DISABLE | PULL_DISABLE)
+#define PIN_OUTPUT_PULLUP  (INPUT_DISABLE | PULL_UP)
+#define PIN_OUTPUT_PULLDOWN(INPUT_DISABLE | PULL_DOWN)
+#define PIN_INPUT  (INPUT_EN | PULL_DISABLE)
+#define PIN_INPUT_PULLUP   (INPUT_EN | PULL_UP)
+#define PIN_INPUT_PULLDOWN (INPUT_EN | PULL_DOWN)



Thanks for reducing the combinations down to the minimum needed. We can
worry about the DS and isolation bits when we have a real user for them.

Acked-by: Nishanth Menon 

Tero: v4.21-rc1 perhaps ?



Yeah, looks fine, queueing up for 4.21.

-Tero
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. 
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

Re: [PATCH v2 1/4] dt-bindings: pinctrl: k3: Introduce pinmux definitions

[Tero Kristo]

On 17/11/2018 18:05, Nishanth Menon wrote:

On 11:31-20181113, Vignesh R wrote:

The dt-bindings header for TI K3 AM6 SoCs define a set of macros for
defining pinmux configs in human readable form, instead of raw-coded
hex values.

Signed-off-by: Vignesh R 
---
  MAINTAINERS  |  1 +
  include/dt-bindings/pinctrl/k3.h | 35 
  2 files changed, 36 insertions(+)
  create mode 100644 include/dt-bindings/pinctrl/k3.h

diff --git a/MAINTAINERS b/MAINTAINERS
index fa45ff36fde9..1574ad6d7ead 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2204,6 +2204,7 @@ S:Supported
  F:Documentation/devicetree/bindings/arm/ti/k3.txt
  F:arch/arm64/boot/dts/ti/Makefile
  F:arch/arm64/boot/dts/ti/k3-*
+F: include/dt-bindings/pinctrl/k3.h
  
  ARM/TEXAS INSTRUMENT KEYSTONE ARCHITECTURE

  M:Santosh Shilimkar 
diff --git a/include/dt-bindings/pinctrl/k3.h b/include/dt-bindings/pinctrl/k3.h
new file mode 100644
index ..463d845a9b36
--- /dev/null
+++ b/include/dt-bindings/pinctrl/k3.h
@@ -0,0 +1,35 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * This header provides constants for pinctrl bindings for TI's K3 SoC
+ * family.
+ *
+ * Copyright (C) 2018 Texas Instruments Incorporated - http://www.ti.com/
+ */
+#ifndef _DT_BINDINGS_PINCTRL_TI_K3_H
+#define _DT_BINDINGS_PINCTRL_TI_K3_H
+
+#define PULLUDEN_SHIFT (16)
+#define PULLTYPESEL_SHIFT  (17)
+#define RXACTIVE_SHIFT (18)
+
+#define PULL_DISABLE   (1 << PULLUDEN_SHIFT)
+#define PULL_ENABLE(0 << PULLUDEN_SHIFT)
+
+#define PULL_UP(1 << PULLTYPESEL_SHIFT | PULL_ENABLE)
+#define PULL_DOWN  (0 << PULLTYPESEL_SHIFT | PULL_ENABLE)
+
+#define INPUT_EN   (1 << RXACTIVE_SHIFT)
+#define INPUT_DISABLE  (0 << RXACTIVE_SHIFT)
+
+/* Only these macros are expected be used directly in device tree files */
+#define PIN_OUTPUT (INPUT_DISABLE | PULL_DISABLE)
+#define PIN_OUTPUT_PULLUP  (INPUT_DISABLE | PULL_UP)
+#define PIN_OUTPUT_PULLDOWN(INPUT_DISABLE | PULL_DOWN)
+#define PIN_INPUT  (INPUT_EN | PULL_DISABLE)
+#define PIN_INPUT_PULLUP   (INPUT_EN | PULL_UP)
+#define PIN_INPUT_PULLDOWN (INPUT_EN | PULL_DOWN)



Thanks for reducing the combinations down to the minimum needed. We can
worry about the DS and isolation bits when we have a real user for them.

Acked-by: Nishanth Menon 

Tero: v4.21-rc1 perhaps ?



Yeah, looks fine, queueing up for 4.21.

-Tero
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. 
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

Re: [PATCH RFC] hist lookups

[Namhyung Kim]

On Sun, Nov 18, 2018 at 10:33:55PM -0800, David Miller wrote:
> From: Namhyung Kim 
> Date: Mon, 19 Nov 2018 15:28:37 +0900
> 
> > Hello David,
> > 
> > On Sun, Nov 18, 2018 at 08:52:43PM -0800, David Miller wrote:
> >> From: Jiri Olsa 
> >> Date: Tue, 13 Nov 2018 11:40:54 +0100
> >> 
> >> > I pushed/rebased what I have to perf/fixes branch again
> >> > 
> >> > please note I had to change our compile changes, because
> >> > they wouldn't compile on x86, but I can't verify on sparc,
> >> > so you might see some compile fails again
> >> 
> >> I just checked your current perf/fixes branch.
> >> 
> >> It builds on Sparc ;-)
> >> 
> >> And it behaves better too.  I do get tons of drops and lost events,
> >> but it seems to keep going even during the hardest load.
> >> 
> >> Eventually I end up with a lot of unresolvable histogram entries,
> >> so that is something to look into.
> > 
> > Did you record callchains as well?  I'd like to know whether it's
> > related to the children (cumulative) mode or not.
> 
> I did not have callchains on, just plain "./perf top"

OK, I need to think about it more..

Thanks,
Namhyung

Re: [PATCH RFC] hist lookups

[Namhyung Kim]

On Sun, Nov 18, 2018 at 10:33:55PM -0800, David Miller wrote:
> From: Namhyung Kim 
> Date: Mon, 19 Nov 2018 15:28:37 +0900
> 
> > Hello David,
> > 
> > On Sun, Nov 18, 2018 at 08:52:43PM -0800, David Miller wrote:
> >> From: Jiri Olsa 
> >> Date: Tue, 13 Nov 2018 11:40:54 +0100
> >> 
> >> > I pushed/rebased what I have to perf/fixes branch again
> >> > 
> >> > please note I had to change our compile changes, because
> >> > they wouldn't compile on x86, but I can't verify on sparc,
> >> > so you might see some compile fails again
> >> 
> >> I just checked your current perf/fixes branch.
> >> 
> >> It builds on Sparc ;-)
> >> 
> >> And it behaves better too.  I do get tons of drops and lost events,
> >> but it seems to keep going even during the hardest load.
> >> 
> >> Eventually I end up with a lot of unresolvable histogram entries,
> >> so that is something to look into.
> > 
> > Did you record callchains as well?  I'd like to know whether it's
> > related to the children (cumulative) mode or not.
> 
> I did not have callchains on, just plain "./perf top"

OK, I need to think about it more..

Thanks,
Namhyung

[PATCH 2/5 v7] regulator: fixed/gpio: Pull inversion/OD into gpiolib

[Linus Walleij]

This pushes the handling of inversion semantics and open drain
settings to the GPIO descriptor and gpiolib. All affected board
files are also augmented.

This is especially nice since we don't have to have any
confusing flags passed around to the left and right littering
the fixed and GPIO regulator drivers and the regulator core.
It is all just very straight-forward: the core asks the GPIO
line to be asserted or deasserted and gpiolib deals with the
rest depending on how the platform is configured: if the line
is active low, it deals with that, if the line is open drain,
it deals with that too.

Cc: Janusz Krzysztofik  # OMAP1
Cc: Alexander Shiyan  # i.MX boards user
Cc: Haojian Zhuang  # MMP2 maintainer
Cc: Aaro Koskinen  # OMAP1 maintainer
Cc: Tony Lindgren  # OMAP1,2,3 maintainer
Cc: Mike Rapoport  # EM-X270 maintainer
Cc: Robert Jarzmik  # EZX maintainer
Cc: Philipp Zabel  # Magician maintainer
Cc: Petr Cvek  # Magician
Cc: Robert Jarzmik  # PXA
Cc: Paul Parsons  # hx4700
Cc: Daniel Mack  # Raumfeld maintainer
Cc: Marc Zyngier  # Zeus maintainer
Cc: Geert Uytterhoeven  # SuperH pinctrl/GPIO 
maintainer
Cc: Russell King  # SA1100
Signed-off-by: Linus Walleij 
---
ChangeLog v6->v7:
- Fix a missed .enable_high on OMAP1.
ChangeLog v4->v6:
- Split out parts relation to GPIO regulator descriptor conversion
  to the right patch.
- Renumber to fit the rest of the series.
- Daniel Mack says he will probably delete the Raumfeld board file
  and replace it with a device tree, I suggest we just deal with that
  conflict upstream.
ChangeLog v3->v4:
- Rebase on fixed regulator changes.
ChangeLog v2->v3:
- Resending.
ChangeLog v1->v2:
- Rebase the patch series
- Cover the new user added in sa1100
---
 arch/arm/mach-imx/mach-mx21ads.c  |  1 -
 arch/arm/mach-imx/mach-mx27ads.c  |  2 +-
 arch/arm/mach-mmp/brownstone.c|  1 -
 arch/arm/mach-omap1/board-ams-delta.c |  2 --
 arch/arm/mach-omap2/pdata-quirks.c|  1 -
 arch/arm/mach-pxa/em-x270.c   |  1 -
 arch/arm/mach-pxa/ezx.c   |  3 +-
 arch/arm/mach-pxa/raumfeld.c  |  1 -
 arch/arm/mach-pxa/zeus.c  |  3 +-
 arch/arm/mach-sa1100/assabet.c|  1 -
 arch/sh/boards/mach-ecovec24/setup.c  |  2 --
 .../intel-mid/device_libs/platform_bcm43xx.c  |  1 -
 drivers/regulator/core.c  |  8 ++---
 drivers/regulator/da9055-regulator.c  |  1 -
 drivers/regulator/fixed.c | 35 +--
 include/linux/regulator/fixed.h   | 10 --
 include/linux/regulator/gpio-regulator.h  |  6 
 17 files changed, 13 insertions(+), 66 deletions(-)

diff --git a/arch/arm/mach-imx/mach-mx21ads.c b/arch/arm/mach-imx/mach-mx21ads.c
index 2e1e540f2e5a..d278fb672d40 100644
--- a/arch/arm/mach-imx/mach-mx21ads.c
+++ b/arch/arm/mach-imx/mach-mx21ads.c
@@ -205,7 +205,6 @@ static struct regulator_init_data 
mx21ads_lcd_regulator_init_data = {
 static struct fixed_voltage_config mx21ads_lcd_regulator_pdata = {
.supply_name= "LCD",
.microvolts = 330,
-   .enable_high= 1,
.init_data  = _lcd_regulator_init_data,
 };
 
diff --git a/arch/arm/mach-imx/mach-mx27ads.c b/arch/arm/mach-imx/mach-mx27ads.c
index f5e04047ed13..6dd7f57c332f 100644
--- a/arch/arm/mach-imx/mach-mx27ads.c
+++ b/arch/arm/mach-imx/mach-mx27ads.c
@@ -237,7 +237,7 @@ static struct fixed_voltage_config 
mx27ads_lcd_regulator_pdata = {
 static struct gpiod_lookup_table mx27ads_lcd_regulator_gpiod_table = {
.dev_id = "reg-fixed-voltage.0", /* Let's hope ID 0 is what we get */
.table = {
-   GPIO_LOOKUP("LCD", 0, NULL, GPIO_ACTIVE_HIGH),
+   GPIO_LOOKUP("LCD", 0, NULL, GPIO_ACTIVE_LOW),
{ },
},
 };
diff --git a/arch/arm/mach-mmp/brownstone.c b/arch/arm/mach-mmp/brownstone.c
index a04e249c654b..d2560fb1e835 100644
--- a/arch/arm/mach-mmp/brownstone.c
+++ b/arch/arm/mach-mmp/brownstone.c
@@ -149,7 +149,6 @@ static struct regulator_init_data brownstone_v_5vp_data = {
 static struct fixed_voltage_config brownstone_v_5vp = {
.supply_name= "v_5vp",
.microvolts = 500,
-   .enable_high= 1,
.enabled_at_boot= 1,
.init_data  = _v_5vp_data,
 };
diff --git a/arch/arm/mach-omap1/board-ams-delta.c 
b/arch/arm/mach-omap1/board-ams-delta.c
index 3d191fd52910..26e9b5969b0a 100644
--- a/arch/arm/mach-omap1/board-ams-delta.c
+++ b/arch/arm/mach-omap1/board-ams-delta.c
@@ -268,7 +268,6 @@ static struct fixed_voltage_config modem_nreset_config = {
.supply_name= "modem_nreset",
.microvolts = 330,
.startup_delay  = 25000,
-   .enable_high= 1,
.enabled_at_boot= 1,
.init_data  = _nreset_data,
 };
@@ -529,7 +528,6 @@ static struct 

[PATCH 4/5 v7] regulator: gpio: Simplify probe path

[Linus Walleij]

Use devm_* managed device resources and create a local
struct device *dev variable to simplify the code inside
probe().

Signed-off-by: Linus Walleij 
---
ChangeLog v6->v7:
- Resend with the rest.
ChangeLog v3->v6:
- Rebase on top of the other changes.
- Change numbering to fit the rest of the series.
ChangeLog v2->v3:
- Resending.
ChangeLog v1->v2:
- Rebase the patch on the other changes.
---
 drivers/regulator/gpio-regulator.c | 55 +-
 1 file changed, 23 insertions(+), 32 deletions(-)

diff --git a/drivers/regulator/gpio-regulator.c 
b/drivers/regulator/gpio-regulator.c
index 68a6c861bcad..62ddea4a5255 100644
--- a/drivers/regulator/gpio-regulator.c
+++ b/drivers/regulator/gpio-regulator.c
@@ -228,31 +228,33 @@ static struct regulator_ops gpio_regulator_current_ops = {
 
 static int gpio_regulator_probe(struct platform_device *pdev)
 {
-   struct gpio_regulator_config *config = dev_get_platdata(>dev);
-   struct device_node *np = pdev->dev.of_node;
+   struct device *dev = >dev;
+   struct gpio_regulator_config *config = dev_get_platdata(dev);
+   struct device_node *np = dev->of_node;
struct gpio_regulator_data *drvdata;
struct regulator_config cfg = { };
enum gpiod_flags gflags;
int ptr, ret, state, i;
 
-   drvdata = devm_kzalloc(>dev, sizeof(struct gpio_regulator_data),
+   drvdata = devm_kzalloc(dev, sizeof(struct gpio_regulator_data),
   GFP_KERNEL);
if (drvdata == NULL)
return -ENOMEM;
 
if (np) {
-   config = of_get_gpio_regulator_config(>dev, np,
+   config = of_get_gpio_regulator_config(dev, np,
  >desc);
if (IS_ERR(config))
return PTR_ERR(config);
}
 
-   drvdata->desc.name = kstrdup(config->supply_name, GFP_KERNEL);
+   drvdata->desc.name = devm_kstrdup(dev, config->supply_name, GFP_KERNEL);
if (drvdata->desc.name == NULL) {
-   dev_err(>dev, "Failed to allocate supply name\n");
+   dev_err(dev, "Failed to allocate supply name\n");
return -ENOMEM;
}
 
+
for (i = 0; i < config->ngpios; i++) {
drvdata->gpiods[i] = devm_gpiod_get_index(>dev,
  NULL,
@@ -265,14 +267,14 @@ static int gpio_regulator_probe(struct platform_device 
*pdev)
}
drvdata->nr_gpios = config->ngpios;
 
-   drvdata->states = kmemdup(config->states,
- config->nr_states *
-sizeof(struct gpio_regulator_state),
- GFP_KERNEL);
+   drvdata->states = devm_kmemdup(dev,
+  config->states,
+  config->nr_states *
+  sizeof(struct gpio_regulator_state),
+  GFP_KERNEL);
if (drvdata->states == NULL) {
-   dev_err(>dev, "Failed to allocate state data\n");
-   ret = -ENOMEM;
-   goto err_name;
+   dev_err(dev, "Failed to allocate state data\n");
+   return -ENOMEM;
}
drvdata->nr_states = config->nr_states;
 
@@ -291,9 +293,8 @@ static int gpio_regulator_probe(struct platform_device 
*pdev)
drvdata->desc.ops = _regulator_current_ops;
break;
default:
-   dev_err(>dev, "No regulator type set\n");
-   ret = -EINVAL;
-   goto err_memstate;
+   dev_err(dev, "No regulator type set\n");
+   return -EINVAL;
}
 
/* build initial state from gpio init data. */
@@ -304,7 +305,7 @@ static int gpio_regulator_probe(struct platform_device 
*pdev)
}
drvdata->state = state;
 
-   cfg.dev = >dev;
+   cfg.dev = dev;
cfg.init_data = config->init_data;
cfg.driver_data = drvdata;
cfg.of_node = np;
@@ -318,28 +319,20 @@ static int gpio_regulator_probe(struct platform_device 
*pdev)
else
gflags = GPIOD_OUT_LOW | GPIOD_FLAGS_BIT_NONEXCLUSIVE;
 
-   cfg.ena_gpiod = devm_gpiod_get_optional(>dev, "enable", gflags);
-   if (IS_ERR(cfg.ena_gpiod)) {
-   ret = PTR_ERR(cfg.ena_gpiod);
-   goto err_memstate;
-   }
+   cfg.ena_gpiod = devm_gpiod_get_optional(dev, "enable", gflags);
+   if (IS_ERR(cfg.ena_gpiod))
+   return PTR_ERR(cfg.ena_gpiod);
 
drvdata->dev = regulator_register(>desc, );
if (IS_ERR(drvdata->dev)) {
ret = PTR_ERR(drvdata->dev);
-   dev_err(>dev, "Failed to register regulator: %d\n", ret);
-   goto err_memstate;
+   dev_err(dev, "Failed to register regulator: %d\n", ret);
+   return 

[PATCH 3/5 v7] regulator: fixed/gpio: Update device tree bindings

[Linus Walleij]

Deprecate the open drain binding for fixed regulator and indicate
that we prefer this to be passed in the GPIO phandle flags.

Clarify that the line inversion semantics for fixed and GPIO
regulators completely overrides the active low flags in the
phandle flags.

Unfortunately this can not be changed to prefer that we pass
the flags in the phandle: the bindings have been specified and
deployed such that the presence/absence of this flag and only
that controls the line inversion semantics. The crucial semantic
is that the absence of the flag means the core will assume
the line is active low, which in GPIO terms is an exception,
as GPIO lines are normally assumed to be active high.

This special device tree semantic cannot be changed without
introducing a whole new compatible string for the fixed and
GPIO regulators, so we just contain the situation.

Cc: devicet...@vger.kernel.org
Reviewed-by: Rob Herring 
Signed-off-by: Linus Walleij 
---
ChangeLog v6->v7:
- Resend with the rest.
ChangeLog v3->v6:
- Resending.
ChangeLog v2->v3:
- Resending.
ChangeLog v1->v2:
- Collect Rob's ACK.
---
 .../bindings/regulator/fixed-regulator.txt  | 13 +++--
 .../bindings/regulator/gpio-regulator.txt   |  4 
 2 files changed, 15 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/regulator/fixed-regulator.txt 
b/Documentation/devicetree/bindings/regulator/fixed-regulator.txt
index 0c2a6c8a1536..a7a1cd0dfa6e 100644
--- a/Documentation/devicetree/bindings/regulator/fixed-regulator.txt
+++ b/Documentation/devicetree/bindings/regulator/fixed-regulator.txt
@@ -8,10 +8,19 @@ Optional properties:
 - gpio: gpio to use for enable control
 - startup-delay-us: startup time in microseconds
 - enable-active-high: Polarity of GPIO is Active high
-If this property is missing, the default assumed is Active low.
+  If this property is missing, the default assumed is Active low.
+  If the phandle flags to the GPIO handle also flag the line as active
+  low or high, that will be ignored for fixed regulators and the
+  presence or absence of this flag solely controls the inversion
+  semantics.
+-vin-supply: Input supply name.
+
+Deprecated properties:
 - gpio-open-drain: GPIO is open drain type.
   If this property is missing then default assumption is false.
--vin-supply: Input supply name.
+  Do not use this property in new device trees: instead use the
+  phandle flag to indicate to the GPIO provider that the line
+  should be handled as open drain.
 
 Any property defined as part of the core regulator
 binding, defined in regulator.txt, can also be used.
diff --git a/Documentation/devicetree/bindings/regulator/gpio-regulator.txt 
b/Documentation/devicetree/bindings/regulator/gpio-regulator.txt
index 1f496159e2bb..8fef3e5358a2 100644
--- a/Documentation/devicetree/bindings/regulator/gpio-regulator.txt
+++ b/Documentation/devicetree/bindings/regulator/gpio-regulator.txt
@@ -14,6 +14,10 @@ Optional properties:
  defualt is LOW if nothing is specified.
 - startup-delay-us : Startup time in microseconds.
 - enable-active-high   : Polarity of GPIO is active high (default is low).
+ If the phandle flags to the GPIO handle also flag the 
line as
+ active low or high, that will be ignored for fixed 
regulators
+ and the presence or absence of this flag solely 
controls the
+ inversion semantics.
 - regulator-type   : Specifies what is being regulated, must be either
  "voltage" or "current", defaults to voltage.
 
-- 
2.19.1

[PATCH 2/5 v7] regulator: fixed/gpio: Pull inversion/OD into gpiolib

[Linus Walleij]

This pushes the handling of inversion semantics and open drain
settings to the GPIO descriptor and gpiolib. All affected board
files are also augmented.

This is especially nice since we don't have to have any
confusing flags passed around to the left and right littering
the fixed and GPIO regulator drivers and the regulator core.
It is all just very straight-forward: the core asks the GPIO
line to be asserted or deasserted and gpiolib deals with the
rest depending on how the platform is configured: if the line
is active low, it deals with that, if the line is open drain,
it deals with that too.

Cc: Janusz Krzysztofik  # OMAP1
Cc: Alexander Shiyan  # i.MX boards user
Cc: Haojian Zhuang  # MMP2 maintainer
Cc: Aaro Koskinen  # OMAP1 maintainer
Cc: Tony Lindgren  # OMAP1,2,3 maintainer
Cc: Mike Rapoport  # EM-X270 maintainer
Cc: Robert Jarzmik  # EZX maintainer
Cc: Philipp Zabel  # Magician maintainer
Cc: Petr Cvek  # Magician
Cc: Robert Jarzmik  # PXA
Cc: Paul Parsons  # hx4700
Cc: Daniel Mack  # Raumfeld maintainer
Cc: Marc Zyngier  # Zeus maintainer
Cc: Geert Uytterhoeven  # SuperH pinctrl/GPIO 
maintainer
Cc: Russell King  # SA1100
Signed-off-by: Linus Walleij 
---
ChangeLog v6->v7:
- Fix a missed .enable_high on OMAP1.
ChangeLog v4->v6:
- Split out parts relation to GPIO regulator descriptor conversion
  to the right patch.
- Renumber to fit the rest of the series.
- Daniel Mack says he will probably delete the Raumfeld board file
  and replace it with a device tree, I suggest we just deal with that
  conflict upstream.
ChangeLog v3->v4:
- Rebase on fixed regulator changes.
ChangeLog v2->v3:
- Resending.
ChangeLog v1->v2:
- Rebase the patch series
- Cover the new user added in sa1100
---
 arch/arm/mach-imx/mach-mx21ads.c  |  1 -
 arch/arm/mach-imx/mach-mx27ads.c  |  2 +-
 arch/arm/mach-mmp/brownstone.c|  1 -
 arch/arm/mach-omap1/board-ams-delta.c |  2 --
 arch/arm/mach-omap2/pdata-quirks.c|  1 -
 arch/arm/mach-pxa/em-x270.c   |  1 -
 arch/arm/mach-pxa/ezx.c   |  3 +-
 arch/arm/mach-pxa/raumfeld.c  |  1 -
 arch/arm/mach-pxa/zeus.c  |  3 +-
 arch/arm/mach-sa1100/assabet.c|  1 -
 arch/sh/boards/mach-ecovec24/setup.c  |  2 --
 .../intel-mid/device_libs/platform_bcm43xx.c  |  1 -
 drivers/regulator/core.c  |  8 ++---
 drivers/regulator/da9055-regulator.c  |  1 -
 drivers/regulator/fixed.c | 35 +--
 include/linux/regulator/fixed.h   | 10 --
 include/linux/regulator/gpio-regulator.h  |  6 
 17 files changed, 13 insertions(+), 66 deletions(-)

diff --git a/arch/arm/mach-imx/mach-mx21ads.c b/arch/arm/mach-imx/mach-mx21ads.c
index 2e1e540f2e5a..d278fb672d40 100644
--- a/arch/arm/mach-imx/mach-mx21ads.c
+++ b/arch/arm/mach-imx/mach-mx21ads.c
@@ -205,7 +205,6 @@ static struct regulator_init_data 
mx21ads_lcd_regulator_init_data = {
 static struct fixed_voltage_config mx21ads_lcd_regulator_pdata = {
.supply_name= "LCD",
.microvolts = 330,
-   .enable_high= 1,
.init_data  = _lcd_regulator_init_data,
 };
 
diff --git a/arch/arm/mach-imx/mach-mx27ads.c b/arch/arm/mach-imx/mach-mx27ads.c
index f5e04047ed13..6dd7f57c332f 100644
--- a/arch/arm/mach-imx/mach-mx27ads.c
+++ b/arch/arm/mach-imx/mach-mx27ads.c
@@ -237,7 +237,7 @@ static struct fixed_voltage_config 
mx27ads_lcd_regulator_pdata = {
 static struct gpiod_lookup_table mx27ads_lcd_regulator_gpiod_table = {
.dev_id = "reg-fixed-voltage.0", /* Let's hope ID 0 is what we get */
.table = {
-   GPIO_LOOKUP("LCD", 0, NULL, GPIO_ACTIVE_HIGH),
+   GPIO_LOOKUP("LCD", 0, NULL, GPIO_ACTIVE_LOW),
{ },
},
 };
diff --git a/arch/arm/mach-mmp/brownstone.c b/arch/arm/mach-mmp/brownstone.c
index a04e249c654b..d2560fb1e835 100644
--- a/arch/arm/mach-mmp/brownstone.c
+++ b/arch/arm/mach-mmp/brownstone.c
@@ -149,7 +149,6 @@ static struct regulator_init_data brownstone_v_5vp_data = {
 static struct fixed_voltage_config brownstone_v_5vp = {
.supply_name= "v_5vp",
.microvolts = 500,
-   .enable_high= 1,
.enabled_at_boot= 1,
.init_data  = _v_5vp_data,
 };
diff --git a/arch/arm/mach-omap1/board-ams-delta.c 
b/arch/arm/mach-omap1/board-ams-delta.c
index 3d191fd52910..26e9b5969b0a 100644
--- a/arch/arm/mach-omap1/board-ams-delta.c
+++ b/arch/arm/mach-omap1/board-ams-delta.c
@@ -268,7 +268,6 @@ static struct fixed_voltage_config modem_nreset_config = {
.supply_name= "modem_nreset",
.microvolts = 330,
.startup_delay  = 25000,
-   .enable_high= 1,
.enabled_at_boot= 1,
.init_data  = _nreset_data,
 };
@@ -529,7 +528,6 @@ static struct 

[PATCH 4/5 v7] regulator: gpio: Simplify probe path

[Linus Walleij]

Use devm_* managed device resources and create a local
struct device *dev variable to simplify the code inside
probe().

Signed-off-by: Linus Walleij 
---
ChangeLog v6->v7:
- Resend with the rest.
ChangeLog v3->v6:
- Rebase on top of the other changes.
- Change numbering to fit the rest of the series.
ChangeLog v2->v3:
- Resending.
ChangeLog v1->v2:
- Rebase the patch on the other changes.
---
 drivers/regulator/gpio-regulator.c | 55 +-
 1 file changed, 23 insertions(+), 32 deletions(-)

diff --git a/drivers/regulator/gpio-regulator.c 
b/drivers/regulator/gpio-regulator.c
index 68a6c861bcad..62ddea4a5255 100644
--- a/drivers/regulator/gpio-regulator.c
+++ b/drivers/regulator/gpio-regulator.c
@@ -228,31 +228,33 @@ static struct regulator_ops gpio_regulator_current_ops = {
 
 static int gpio_regulator_probe(struct platform_device *pdev)
 {
-   struct gpio_regulator_config *config = dev_get_platdata(>dev);
-   struct device_node *np = pdev->dev.of_node;
+   struct device *dev = >dev;
+   struct gpio_regulator_config *config = dev_get_platdata(dev);
+   struct device_node *np = dev->of_node;
struct gpio_regulator_data *drvdata;
struct regulator_config cfg = { };
enum gpiod_flags gflags;
int ptr, ret, state, i;
 
-   drvdata = devm_kzalloc(>dev, sizeof(struct gpio_regulator_data),
+   drvdata = devm_kzalloc(dev, sizeof(struct gpio_regulator_data),
   GFP_KERNEL);
if (drvdata == NULL)
return -ENOMEM;
 
if (np) {
-   config = of_get_gpio_regulator_config(>dev, np,
+   config = of_get_gpio_regulator_config(dev, np,
  >desc);
if (IS_ERR(config))
return PTR_ERR(config);
}
 
-   drvdata->desc.name = kstrdup(config->supply_name, GFP_KERNEL);
+   drvdata->desc.name = devm_kstrdup(dev, config->supply_name, GFP_KERNEL);
if (drvdata->desc.name == NULL) {
-   dev_err(>dev, "Failed to allocate supply name\n");
+   dev_err(dev, "Failed to allocate supply name\n");
return -ENOMEM;
}
 
+
for (i = 0; i < config->ngpios; i++) {
drvdata->gpiods[i] = devm_gpiod_get_index(>dev,
  NULL,
@@ -265,14 +267,14 @@ static int gpio_regulator_probe(struct platform_device 
*pdev)
}
drvdata->nr_gpios = config->ngpios;
 
-   drvdata->states = kmemdup(config->states,
- config->nr_states *
-sizeof(struct gpio_regulator_state),
- GFP_KERNEL);
+   drvdata->states = devm_kmemdup(dev,
+  config->states,
+  config->nr_states *
+  sizeof(struct gpio_regulator_state),
+  GFP_KERNEL);
if (drvdata->states == NULL) {
-   dev_err(>dev, "Failed to allocate state data\n");
-   ret = -ENOMEM;
-   goto err_name;
+   dev_err(dev, "Failed to allocate state data\n");
+   return -ENOMEM;
}
drvdata->nr_states = config->nr_states;
 
@@ -291,9 +293,8 @@ static int gpio_regulator_probe(struct platform_device 
*pdev)
drvdata->desc.ops = _regulator_current_ops;
break;
default:
-   dev_err(>dev, "No regulator type set\n");
-   ret = -EINVAL;
-   goto err_memstate;
+   dev_err(dev, "No regulator type set\n");
+   return -EINVAL;
}
 
/* build initial state from gpio init data. */
@@ -304,7 +305,7 @@ static int gpio_regulator_probe(struct platform_device 
*pdev)
}
drvdata->state = state;
 
-   cfg.dev = >dev;
+   cfg.dev = dev;
cfg.init_data = config->init_data;
cfg.driver_data = drvdata;
cfg.of_node = np;
@@ -318,28 +319,20 @@ static int gpio_regulator_probe(struct platform_device 
*pdev)
else
gflags = GPIOD_OUT_LOW | GPIOD_FLAGS_BIT_NONEXCLUSIVE;
 
-   cfg.ena_gpiod = devm_gpiod_get_optional(>dev, "enable", gflags);
-   if (IS_ERR(cfg.ena_gpiod)) {
-   ret = PTR_ERR(cfg.ena_gpiod);
-   goto err_memstate;
-   }
+   cfg.ena_gpiod = devm_gpiod_get_optional(dev, "enable", gflags);
+   if (IS_ERR(cfg.ena_gpiod))
+   return PTR_ERR(cfg.ena_gpiod);
 
drvdata->dev = regulator_register(>desc, );
if (IS_ERR(drvdata->dev)) {
ret = PTR_ERR(drvdata->dev);
-   dev_err(>dev, "Failed to register regulator: %d\n", ret);
-   goto err_memstate;
+   dev_err(dev, "Failed to register regulator: %d\n", ret);
+   return 

[PATCH 3/5 v7] regulator: fixed/gpio: Update device tree bindings

[Linus Walleij]

Deprecate the open drain binding for fixed regulator and indicate
that we prefer this to be passed in the GPIO phandle flags.

Clarify that the line inversion semantics for fixed and GPIO
regulators completely overrides the active low flags in the
phandle flags.

Unfortunately this can not be changed to prefer that we pass
the flags in the phandle: the bindings have been specified and
deployed such that the presence/absence of this flag and only
that controls the line inversion semantics. The crucial semantic
is that the absence of the flag means the core will assume
the line is active low, which in GPIO terms is an exception,
as GPIO lines are normally assumed to be active high.

This special device tree semantic cannot be changed without
introducing a whole new compatible string for the fixed and
GPIO regulators, so we just contain the situation.

Cc: devicet...@vger.kernel.org
Reviewed-by: Rob Herring 
Signed-off-by: Linus Walleij 
---
ChangeLog v6->v7:
- Resend with the rest.
ChangeLog v3->v6:
- Resending.
ChangeLog v2->v3:
- Resending.
ChangeLog v1->v2:
- Collect Rob's ACK.
---
 .../bindings/regulator/fixed-regulator.txt  | 13 +++--
 .../bindings/regulator/gpio-regulator.txt   |  4 
 2 files changed, 15 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/regulator/fixed-regulator.txt 
b/Documentation/devicetree/bindings/regulator/fixed-regulator.txt
index 0c2a6c8a1536..a7a1cd0dfa6e 100644
--- a/Documentation/devicetree/bindings/regulator/fixed-regulator.txt
+++ b/Documentation/devicetree/bindings/regulator/fixed-regulator.txt
@@ -8,10 +8,19 @@ Optional properties:
 - gpio: gpio to use for enable control
 - startup-delay-us: startup time in microseconds
 - enable-active-high: Polarity of GPIO is Active high
-If this property is missing, the default assumed is Active low.
+  If this property is missing, the default assumed is Active low.
+  If the phandle flags to the GPIO handle also flag the line as active
+  low or high, that will be ignored for fixed regulators and the
+  presence or absence of this flag solely controls the inversion
+  semantics.
+-vin-supply: Input supply name.
+
+Deprecated properties:
 - gpio-open-drain: GPIO is open drain type.
   If this property is missing then default assumption is false.
--vin-supply: Input supply name.
+  Do not use this property in new device trees: instead use the
+  phandle flag to indicate to the GPIO provider that the line
+  should be handled as open drain.
 
 Any property defined as part of the core regulator
 binding, defined in regulator.txt, can also be used.
diff --git a/Documentation/devicetree/bindings/regulator/gpio-regulator.txt 
b/Documentation/devicetree/bindings/regulator/gpio-regulator.txt
index 1f496159e2bb..8fef3e5358a2 100644
--- a/Documentation/devicetree/bindings/regulator/gpio-regulator.txt
+++ b/Documentation/devicetree/bindings/regulator/gpio-regulator.txt
@@ -14,6 +14,10 @@ Optional properties:
  defualt is LOW if nothing is specified.
 - startup-delay-us : Startup time in microseconds.
 - enable-active-high   : Polarity of GPIO is active high (default is low).
+ If the phandle flags to the GPIO handle also flag the 
line as
+ active low or high, that will be ignored for fixed 
regulators
+ and the presence or absence of this flag solely 
controls the
+ inversion semantics.
 - regulator-type   : Specifies what is being regulated, must be either
  "voltage" or "current", defaults to voltage.
 
-- 
2.19.1

[PATCH 1/5 v7] regulator: gpio: Convert to use descriptors

[Linus Walleij]

This converts the GPIO regulator driver to use decriptors only.

We have to let go of the array gpio handling: the fetched descriptors
are handled individually anyway, and the array retrieveal function
does not make it possible to retrieve each GPIO descriptor with
unique flags. Instead get them one by one.

We request the "enable" GPIO separately as before, and make sure
that this line is requested as nonexclusive since enable lines can
be shared and the regulator core expects this.

Most users of the GPIO regulator are using device tree.

There are two boards in the kernel using the gpio regulator from a
non-devicetree path: PXA hx4700 and magician. Make sure to switch
these over to use descriptors as well.

Cc: Philipp Zabel  # Magician
Cc: Petr Cvek  # Magician
Cc: Robert Jarzmik  # PXA
Cc: Paul Parsons  # hx4700
Signed-off-by: Linus Walleij 
---
ChangeLog v6->v7:
- Resend with the rest.
ChangeLog v3->v6:
- Make sure to request the GPIO line nonexclusive as with other
  regulator GPIOs.
- Request the voltage controlling GPIOs from the name NULL as
  only "enable-gpio" is explicitly named.
- Make sure to delete all unused struct members and assignments
  in board files.
- Change numbering to fit the rest of the patches.
ChangeLog v2->v3:
- Resending.
ChangeLog v1->v2:
- Rebase the patch on the other changes.
---
 arch/arm/mach-pxa/hx4700.c   |  23 ++--
 arch/arm/mach-pxa/magician.c |  23 ++--
 drivers/regulator/gpio-regulator.c   | 146 ---
 include/linux/regulator/gpio-regulator.h |  12 +-
 4 files changed, 91 insertions(+), 113 deletions(-)

diff --git a/arch/arm/mach-pxa/hx4700.c b/arch/arm/mach-pxa/hx4700.c
index b79b757fdd41..51d38d5e776a 100644
--- a/arch/arm/mach-pxa/hx4700.c
+++ b/arch/arm/mach-pxa/hx4700.c
@@ -19,6 +19,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -702,9 +703,7 @@ static struct regulator_init_data bq24022_init_data = {
.consumer_supplies  = bq24022_consumers,
 };
 
-static struct gpio bq24022_gpios[] = {
-   { GPIO96_HX4700_BQ24022_ISET2, GPIOF_OUT_INIT_LOW, "bq24022_iset2" },
-};
+static enum gpiod_flags bq24022_gpiod_gflags[] = { GPIOD_OUT_LOW };
 
 static struct gpio_regulator_state bq24022_states[] = {
{ .value = 10, .gpios = (0 << 0) },
@@ -714,12 +713,10 @@ static struct gpio_regulator_state bq24022_states[] = {
 static struct gpio_regulator_config bq24022_info = {
.supply_name = "bq24022",
 
-   .enable_gpio = GPIO72_HX4700_BQ24022_nCHARGE_EN,
-   .enable_high = 0,
.enabled_at_boot = 0,
 
-   .gpios = bq24022_gpios,
-   .nr_gpios = ARRAY_SIZE(bq24022_gpios),
+   .gflags = bq24022_gpiod_gflags,
+   .ngpios = ARRAY_SIZE(bq24022_gpiod_gflags),
 
.states = bq24022_states,
.nr_states = ARRAY_SIZE(bq24022_states),
@@ -736,6 +733,17 @@ static struct platform_device bq24022 = {
},
 };
 
+static struct gpiod_lookup_table bq24022_gpiod_table = {
+   .dev_id = "gpio-regulator",
+   .table = {
+   GPIO_LOOKUP("gpio-pxa", GPIO96_HX4700_BQ24022_ISET2,
+   NULL, GPIO_ACTIVE_HIGH),
+   GPIO_LOOKUP("gpio-pxa", GPIO72_HX4700_BQ24022_nCHARGE_EN,
+   "enable", GPIO_ACTIVE_LOW),
+   { },
+   },
+};
+
 /*
  * StrataFlash
  */
@@ -878,6 +886,7 @@ static void __init hx4700_init(void)
pxa_set_btuart_info(NULL);
pxa_set_stuart_info(NULL);
 
+   gpiod_add_lookup_table(_gpiod_table);
platform_add_devices(devices, ARRAY_SIZE(devices));
pwm_add_table(hx4700_pwm_lookup, ARRAY_SIZE(hx4700_pwm_lookup));
 
diff --git a/arch/arm/mach-pxa/magician.c b/arch/arm/mach-pxa/magician.c
index 14c0f80bc9e7..5d21de79135b 100644
--- a/arch/arm/mach-pxa/magician.c
+++ b/arch/arm/mach-pxa/magician.c
@@ -645,9 +645,8 @@ static struct regulator_init_data bq24022_init_data = {
.consumer_supplies  = bq24022_consumers,
 };
 
-static struct gpio bq24022_gpios[] = {
-   { EGPIO_MAGICIAN_BQ24022_ISET2, GPIOF_OUT_INIT_LOW, "bq24022_iset2" },
-};
+
+static enum gpiod_flags bq24022_gpiod_gflags[] = { GPIOD_OUT_LOW };
 
 static struct gpio_regulator_state bq24022_states[] = {
{ .value = 10, .gpios = (0 << 0) },
@@ -657,12 +656,10 @@ static struct gpio_regulator_state bq24022_states[] = {
 static struct gpio_regulator_config bq24022_info = {
.supply_name= "bq24022",
 
-   .enable_gpio= GPIO30_MAGICIAN_BQ24022_nCHARGE_EN,
-   .enable_high= 0,
.enabled_at_boot= 1,
 
-   .gpios  = bq24022_gpios,
-   .nr_gpios   = ARRAY_SIZE(bq24022_gpios),
+   .gflags = bq24022_gpiod_gflags,
+   .ngpios = ARRAY_SIZE(bq24022_gpiod_gflags),
 
.states = bq24022_states,
.nr_states  = ARRAY_SIZE(bq24022_states),
@@ -679,6 +676,17 @@ static struct platform_device bq24022 

[PATCH 5/5 v7] regulator: core: Only support passing enable GPIO descriptors

[Linus Walleij]

Now that we changed all providers to pass descriptors into the core
for enable GPIOs instead of a global GPIO number, delete the support
for passing GPIO numbers in, and we get a cleanup and size reduction
in the core, and from a GPIO point of view we use the modern, cleaner
interface.

Signed-off-by: Linus Walleij 
---
ChangeLog v6->v7:
- Resend with the rest.
ChangeLog v4->v6:
- Rebase on top of the other changes.
- Renumber to fit the rest of the series.
ChangeLog v3->v4:
- Also drop ena_gpio_invert from driver data
ChangeLog v2->v3:
- Resending.
ChangeLog v1->v2:
- Rebase the patch on the other changes.
---
 drivers/regulator/core.c | 32 ++--
 include/linux/regulator/driver.h | 12 +---
 2 files changed, 7 insertions(+), 37 deletions(-)

diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
index 109bd2bee868..0eb5c48f1162 100644
--- a/drivers/regulator/core.c
+++ b/drivers/regulator/core.c
@@ -23,7 +23,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
@@ -2015,35 +2014,19 @@ static int regulator_ena_gpio_request(struct 
regulator_dev *rdev,
 {
struct regulator_enable_gpio *pin;
struct gpio_desc *gpiod;
-   int ret;
 
-   if (config->ena_gpiod)
-   gpiod = config->ena_gpiod;
-   else
-   gpiod = gpio_to_desc(config->ena_gpio);
+   gpiod = config->ena_gpiod;
 
list_for_each_entry(pin, _ena_gpio_list, list) {
if (pin->gpiod == gpiod) {
-   rdev_dbg(rdev, "GPIO %d is already used\n",
-   config->ena_gpio);
+   rdev_dbg(rdev, "GPIO is already used\n");
goto update_ena_gpio_to_rdev;
}
}
 
-   if (!config->ena_gpiod) {
-   ret = gpio_request_one(config->ena_gpio,
-  GPIOF_DIR_OUT | config->ena_gpio_flags,
-  rdev_get_name(rdev));
-   if (ret)
-   return ret;
-   }
-
pin = kzalloc(sizeof(struct regulator_enable_gpio), GFP_KERNEL);
-   if (pin == NULL) {
-   if (!config->ena_gpiod)
-   gpio_free(config->ena_gpio);
+   if (pin == NULL)
return -ENOMEM;
-   }
 
pin->gpiod = gpiod;
list_add(>list, _ena_gpio_list);
@@ -2066,7 +2049,6 @@ static void regulator_ena_gpio_free(struct regulator_dev 
*rdev)
if (pin->gpiod == rdev->ena_pin->gpiod) {
if (pin->request_count <= 1) {
pin->request_count = 0;
-   gpiod_put(pin->gpiod);
list_del(>list);
kfree(pin);
rdev->ena_pin = NULL;
@@ -4336,15 +4318,13 @@ regulator_register(const struct regulator_desc 
*regulator_desc,
goto clean;
}
 
-   if (config->ena_gpiod ||
-   ((config->ena_gpio || config->ena_gpio_initialized) &&
-gpio_is_valid(config->ena_gpio))) {
+   if (config->ena_gpiod) {
mutex_lock(_list_mutex);
ret = regulator_ena_gpio_request(rdev, config);
mutex_unlock(_list_mutex);
if (ret != 0) {
-   rdev_err(rdev, "Failed to request enable GPIO%d: %d\n",
-config->ena_gpio, ret);
+   rdev_err(rdev, "Failed to request enable GPIO: %d\n",
+ret);
goto clean;
}
}
diff --git a/include/linux/regulator/driver.h b/include/linux/regulator/driver.h
index a9c030192147..10ee158eac00 100644
--- a/include/linux/regulator/driver.h
+++ b/include/linux/regulator/driver.h
@@ -400,13 +400,7 @@ struct regulator_desc {
  *   NULL).
  * @regmap: regmap to use for core regmap helpers if dev_get_regmap() is
  *  insufficient.
- * @ena_gpio_initialized: GPIO controlling regulator enable was properly
- *initialized, meaning that >= 0 is a valid gpio
- *identifier and < 0 is a non existent gpio.
- * @ena_gpio: GPIO controlling regulator enable.
- * @ena_gpiod: GPIO descriptor controlling regulator enable.
- * @ena_gpio_invert: Sense for GPIO enable control.
- * @ena_gpio_flags: Flags to use when calling gpio_request_one()
+ * @ena_gpiod: GPIO controlling regulator enable.
  */
 struct regulator_config {
struct device *dev;
@@ -415,11 +409,7 @@ struct regulator_config {
struct device_node *of_node;
struct regmap *regmap;
 
-   bool ena_gpio_initialized;
-   int ena_gpio;
struct gpio_desc *ena_gpiod;
-   unsigned int ena_gpio_invert:1;
-   unsigned int ena_gpio_flags;
 };
 
 /*
-- 
2.19.1

[PATCH 1/5 v7] regulator: gpio: Convert to use descriptors

[Linus Walleij]

This converts the GPIO regulator driver to use decriptors only.

We have to let go of the array gpio handling: the fetched descriptors
are handled individually anyway, and the array retrieveal function
does not make it possible to retrieve each GPIO descriptor with
unique flags. Instead get them one by one.

We request the "enable" GPIO separately as before, and make sure
that this line is requested as nonexclusive since enable lines can
be shared and the regulator core expects this.

Most users of the GPIO regulator are using device tree.

There are two boards in the kernel using the gpio regulator from a
non-devicetree path: PXA hx4700 and magician. Make sure to switch
these over to use descriptors as well.

Cc: Philipp Zabel  # Magician
Cc: Petr Cvek  # Magician
Cc: Robert Jarzmik  # PXA
Cc: Paul Parsons  # hx4700
Signed-off-by: Linus Walleij 
---
ChangeLog v6->v7:
- Resend with the rest.
ChangeLog v3->v6:
- Make sure to request the GPIO line nonexclusive as with other
  regulator GPIOs.
- Request the voltage controlling GPIOs from the name NULL as
  only "enable-gpio" is explicitly named.
- Make sure to delete all unused struct members and assignments
  in board files.
- Change numbering to fit the rest of the patches.
ChangeLog v2->v3:
- Resending.
ChangeLog v1->v2:
- Rebase the patch on the other changes.
---
 arch/arm/mach-pxa/hx4700.c   |  23 ++--
 arch/arm/mach-pxa/magician.c |  23 ++--
 drivers/regulator/gpio-regulator.c   | 146 ---
 include/linux/regulator/gpio-regulator.h |  12 +-
 4 files changed, 91 insertions(+), 113 deletions(-)

diff --git a/arch/arm/mach-pxa/hx4700.c b/arch/arm/mach-pxa/hx4700.c
index b79b757fdd41..51d38d5e776a 100644
--- a/arch/arm/mach-pxa/hx4700.c
+++ b/arch/arm/mach-pxa/hx4700.c
@@ -19,6 +19,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -702,9 +703,7 @@ static struct regulator_init_data bq24022_init_data = {
.consumer_supplies  = bq24022_consumers,
 };
 
-static struct gpio bq24022_gpios[] = {
-   { GPIO96_HX4700_BQ24022_ISET2, GPIOF_OUT_INIT_LOW, "bq24022_iset2" },
-};
+static enum gpiod_flags bq24022_gpiod_gflags[] = { GPIOD_OUT_LOW };
 
 static struct gpio_regulator_state bq24022_states[] = {
{ .value = 10, .gpios = (0 << 0) },
@@ -714,12 +713,10 @@ static struct gpio_regulator_state bq24022_states[] = {
 static struct gpio_regulator_config bq24022_info = {
.supply_name = "bq24022",
 
-   .enable_gpio = GPIO72_HX4700_BQ24022_nCHARGE_EN,
-   .enable_high = 0,
.enabled_at_boot = 0,
 
-   .gpios = bq24022_gpios,
-   .nr_gpios = ARRAY_SIZE(bq24022_gpios),
+   .gflags = bq24022_gpiod_gflags,
+   .ngpios = ARRAY_SIZE(bq24022_gpiod_gflags),
 
.states = bq24022_states,
.nr_states = ARRAY_SIZE(bq24022_states),
@@ -736,6 +733,17 @@ static struct platform_device bq24022 = {
},
 };
 
+static struct gpiod_lookup_table bq24022_gpiod_table = {
+   .dev_id = "gpio-regulator",
+   .table = {
+   GPIO_LOOKUP("gpio-pxa", GPIO96_HX4700_BQ24022_ISET2,
+   NULL, GPIO_ACTIVE_HIGH),
+   GPIO_LOOKUP("gpio-pxa", GPIO72_HX4700_BQ24022_nCHARGE_EN,
+   "enable", GPIO_ACTIVE_LOW),
+   { },
+   },
+};
+
 /*
  * StrataFlash
  */
@@ -878,6 +886,7 @@ static void __init hx4700_init(void)
pxa_set_btuart_info(NULL);
pxa_set_stuart_info(NULL);
 
+   gpiod_add_lookup_table(_gpiod_table);
platform_add_devices(devices, ARRAY_SIZE(devices));
pwm_add_table(hx4700_pwm_lookup, ARRAY_SIZE(hx4700_pwm_lookup));
 
diff --git a/arch/arm/mach-pxa/magician.c b/arch/arm/mach-pxa/magician.c
index 14c0f80bc9e7..5d21de79135b 100644
--- a/arch/arm/mach-pxa/magician.c
+++ b/arch/arm/mach-pxa/magician.c
@@ -645,9 +645,8 @@ static struct regulator_init_data bq24022_init_data = {
.consumer_supplies  = bq24022_consumers,
 };
 
-static struct gpio bq24022_gpios[] = {
-   { EGPIO_MAGICIAN_BQ24022_ISET2, GPIOF_OUT_INIT_LOW, "bq24022_iset2" },
-};
+
+static enum gpiod_flags bq24022_gpiod_gflags[] = { GPIOD_OUT_LOW };
 
 static struct gpio_regulator_state bq24022_states[] = {
{ .value = 10, .gpios = (0 << 0) },
@@ -657,12 +656,10 @@ static struct gpio_regulator_state bq24022_states[] = {
 static struct gpio_regulator_config bq24022_info = {
.supply_name= "bq24022",
 
-   .enable_gpio= GPIO30_MAGICIAN_BQ24022_nCHARGE_EN,
-   .enable_high= 0,
.enabled_at_boot= 1,
 
-   .gpios  = bq24022_gpios,
-   .nr_gpios   = ARRAY_SIZE(bq24022_gpios),
+   .gflags = bq24022_gpiod_gflags,
+   .ngpios = ARRAY_SIZE(bq24022_gpiod_gflags),
 
.states = bq24022_states,
.nr_states  = ARRAY_SIZE(bq24022_states),
@@ -679,6 +676,17 @@ static struct platform_device bq24022 

[PATCH 5/5 v7] regulator: core: Only support passing enable GPIO descriptors

[Linus Walleij]

Now that we changed all providers to pass descriptors into the core
for enable GPIOs instead of a global GPIO number, delete the support
for passing GPIO numbers in, and we get a cleanup and size reduction
in the core, and from a GPIO point of view we use the modern, cleaner
interface.

Signed-off-by: Linus Walleij 
---
ChangeLog v6->v7:
- Resend with the rest.
ChangeLog v4->v6:
- Rebase on top of the other changes.
- Renumber to fit the rest of the series.
ChangeLog v3->v4:
- Also drop ena_gpio_invert from driver data
ChangeLog v2->v3:
- Resending.
ChangeLog v1->v2:
- Rebase the patch on the other changes.
---
 drivers/regulator/core.c | 32 ++--
 include/linux/regulator/driver.h | 12 +---
 2 files changed, 7 insertions(+), 37 deletions(-)

diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
index 109bd2bee868..0eb5c48f1162 100644
--- a/drivers/regulator/core.c
+++ b/drivers/regulator/core.c
@@ -23,7 +23,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
@@ -2015,35 +2014,19 @@ static int regulator_ena_gpio_request(struct 
regulator_dev *rdev,
 {
struct regulator_enable_gpio *pin;
struct gpio_desc *gpiod;
-   int ret;
 
-   if (config->ena_gpiod)
-   gpiod = config->ena_gpiod;
-   else
-   gpiod = gpio_to_desc(config->ena_gpio);
+   gpiod = config->ena_gpiod;
 
list_for_each_entry(pin, _ena_gpio_list, list) {
if (pin->gpiod == gpiod) {
-   rdev_dbg(rdev, "GPIO %d is already used\n",
-   config->ena_gpio);
+   rdev_dbg(rdev, "GPIO is already used\n");
goto update_ena_gpio_to_rdev;
}
}
 
-   if (!config->ena_gpiod) {
-   ret = gpio_request_one(config->ena_gpio,
-  GPIOF_DIR_OUT | config->ena_gpio_flags,
-  rdev_get_name(rdev));
-   if (ret)
-   return ret;
-   }
-
pin = kzalloc(sizeof(struct regulator_enable_gpio), GFP_KERNEL);
-   if (pin == NULL) {
-   if (!config->ena_gpiod)
-   gpio_free(config->ena_gpio);
+   if (pin == NULL)
return -ENOMEM;
-   }
 
pin->gpiod = gpiod;
list_add(>list, _ena_gpio_list);
@@ -2066,7 +2049,6 @@ static void regulator_ena_gpio_free(struct regulator_dev 
*rdev)
if (pin->gpiod == rdev->ena_pin->gpiod) {
if (pin->request_count <= 1) {
pin->request_count = 0;
-   gpiod_put(pin->gpiod);
list_del(>list);
kfree(pin);
rdev->ena_pin = NULL;
@@ -4336,15 +4318,13 @@ regulator_register(const struct regulator_desc 
*regulator_desc,
goto clean;
}
 
-   if (config->ena_gpiod ||
-   ((config->ena_gpio || config->ena_gpio_initialized) &&
-gpio_is_valid(config->ena_gpio))) {
+   if (config->ena_gpiod) {
mutex_lock(_list_mutex);
ret = regulator_ena_gpio_request(rdev, config);
mutex_unlock(_list_mutex);
if (ret != 0) {
-   rdev_err(rdev, "Failed to request enable GPIO%d: %d\n",
-config->ena_gpio, ret);
+   rdev_err(rdev, "Failed to request enable GPIO: %d\n",
+ret);
goto clean;
}
}
diff --git a/include/linux/regulator/driver.h b/include/linux/regulator/driver.h
index a9c030192147..10ee158eac00 100644
--- a/include/linux/regulator/driver.h
+++ b/include/linux/regulator/driver.h
@@ -400,13 +400,7 @@ struct regulator_desc {
  *   NULL).
  * @regmap: regmap to use for core regmap helpers if dev_get_regmap() is
  *  insufficient.
- * @ena_gpio_initialized: GPIO controlling regulator enable was properly
- *initialized, meaning that >= 0 is a valid gpio
- *identifier and < 0 is a non existent gpio.
- * @ena_gpio: GPIO controlling regulator enable.
- * @ena_gpiod: GPIO descriptor controlling regulator enable.
- * @ena_gpio_invert: Sense for GPIO enable control.
- * @ena_gpio_flags: Flags to use when calling gpio_request_one()
+ * @ena_gpiod: GPIO controlling regulator enable.
  */
 struct regulator_config {
struct device *dev;
@@ -415,11 +409,7 @@ struct regulator_config {
struct device_node *of_node;
struct regmap *regmap;
 
-   bool ena_gpio_initialized;
-   int ena_gpio;
struct gpio_desc *ena_gpiod;
-   unsigned int ena_gpio_invert:1;
-   unsigned int ena_gpio_flags;
 };
 
 /*
-- 
2.19.1

Re: [PATCH 1/2] dt-bindings: phy: Add Qualcomm Synopsys High-Speed USB PHY binding

[Vivek Gautam]

On Mon, Nov 19, 2018 at 12:29 PM Shawn Guo  wrote:
>
> On Sat, Nov 17, 2018 at 09:13:38AM -0600, Rob Herring wrote:
> 
> > > > > +- qcom,init-seq:
> > > > > +Value type: 
> > > > > +Definition: Should contain a sequence of  
> > > > > tuples to
> > > > > +program 'value' into phy register at 'offset' with 
> > > > > 'delay'
> > > > > +   in us afterwards.
> > > >
> > > > If we wanted this type of thing in DT, we'd have a generic binding (or
> > > > forth).
> > >
> > > Right now, this is a qualcomm usb phy specific bindings - first used in
> > > qcom,usb-hs-phy.txt and I extended it a bit for my phy.  As this is not
> > > a so good hardware description, I'm a little hesitated to make it
> > > generic for other platforms to use in general.  What about we put off it
> > > a little bit until we see more platforms need the same thing?
> >
> > I'm not saying I want it generic. Quite the opposite. I don't think we
> > should have it either generically or vendor specific. The main thing I
> > have a problem with is the timing information because then we're more
> > that just data. Without that we're talking about a bunch of properties
> > for register fields or just raw register values in DT. That becomes
> > more of a judgement call. There's not too much value in making a
> > driver translate a bunch of properties just to stuff them into
> > registers on init. But then just allowing any raw register value to be
> > in DT could be easily abused.
>
> Rob,
>
> I agree with your comments.  Honestly, I'm not comfortable with this
> 'qcom,init-seq' thing in the first impression.  The similar existence in
> mainline qcom,usb-hs-phy.txt makes me think it might be acceptable with
> the timing data added.  Okay, I know your position on this now.
>
> @Sriharsha,
>
> Seeing that 'qcom,init-seq' is being configured with the exactly same
> values for both HS phys in SoC level dts file (qcs404.dtsi), I think
> such settings can be moved into driver code as SoC specific data.
> Unless you have a different view on this, I will do it with v4.

phy-qcom-qmp and phy-qcom-qusb2 have been maintaining such SoC specific
init sequences in the drivers if you would like to have pointers from them.

Thanks
Vivek

>
> Shawn



-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation

Re: [PATCH 1/2] dt-bindings: phy: Add Qualcomm Synopsys High-Speed USB PHY binding

[Vivek Gautam]

On Mon, Nov 19, 2018 at 12:29 PM Shawn Guo  wrote:
>
> On Sat, Nov 17, 2018 at 09:13:38AM -0600, Rob Herring wrote:
> 
> > > > > +- qcom,init-seq:
> > > > > +Value type: 
> > > > > +Definition: Should contain a sequence of  
> > > > > tuples to
> > > > > +program 'value' into phy register at 'offset' with 
> > > > > 'delay'
> > > > > +   in us afterwards.
> > > >
> > > > If we wanted this type of thing in DT, we'd have a generic binding (or
> > > > forth).
> > >
> > > Right now, this is a qualcomm usb phy specific bindings - first used in
> > > qcom,usb-hs-phy.txt and I extended it a bit for my phy.  As this is not
> > > a so good hardware description, I'm a little hesitated to make it
> > > generic for other platforms to use in general.  What about we put off it
> > > a little bit until we see more platforms need the same thing?
> >
> > I'm not saying I want it generic. Quite the opposite. I don't think we
> > should have it either generically or vendor specific. The main thing I
> > have a problem with is the timing information because then we're more
> > that just data. Without that we're talking about a bunch of properties
> > for register fields or just raw register values in DT. That becomes
> > more of a judgement call. There's not too much value in making a
> > driver translate a bunch of properties just to stuff them into
> > registers on init. But then just allowing any raw register value to be
> > in DT could be easily abused.
>
> Rob,
>
> I agree with your comments.  Honestly, I'm not comfortable with this
> 'qcom,init-seq' thing in the first impression.  The similar existence in
> mainline qcom,usb-hs-phy.txt makes me think it might be acceptable with
> the timing data added.  Okay, I know your position on this now.
>
> @Sriharsha,
>
> Seeing that 'qcom,init-seq' is being configured with the exactly same
> values for both HS phys in SoC level dts file (qcs404.dtsi), I think
> such settings can be moved into driver code as SoC specific data.
> Unless you have a different view on this, I will do it with v4.

phy-qcom-qmp and phy-qcom-qusb2 have been maintaining such SoC specific
init sequences in the drivers if you would like to have pointers from them.

Thanks
Vivek

>
> Shawn



-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation

RE: [PATCH v2 2/2] dpaa_eth: add ethtool coalesce control

[Madalin-cristian Bucur]

> -Original Message-
> From: David Miller 
> Sent: Saturday, November 17, 2018 5:42 AM
> To: Madalin-cristian Bucur 
> Subject: Re: [PATCH v2 2/2] dpaa_eth: add ethtool coalesce control
> 
> From: Madalin Bucur 
> Date: Tue, 13 Nov 2018 18:29:51 +0200
> 
> > +   for_each_cpu(cpu, cpus) {
> > +   portal = qman_get_affine_portal(cpu);
> > +   res = qman_portal_set_iperiod(portal, period);
> > +   if (res)
> > +   return res;
> > +   res = qman_dqrr_set_ithresh(portal, thresh);
> > +   if (res)
> > +   return res;
> 
> Nope, you can't do it like this.
> 
> If any intermediate change fails, you have to unwind all of the
> changes made up until that point.
> 
> Which means you'll have to store the previous setting somewhere
> and reinstall those saved values in the error path.

Thank you, I'll come back with a v3.

Madalin

RE: [PATCH v2 2/2] dpaa_eth: add ethtool coalesce control

[Madalin-cristian Bucur]

> -Original Message-
> From: David Miller 
> Sent: Saturday, November 17, 2018 5:42 AM
> To: Madalin-cristian Bucur 
> Subject: Re: [PATCH v2 2/2] dpaa_eth: add ethtool coalesce control
> 
> From: Madalin Bucur 
> Date: Tue, 13 Nov 2018 18:29:51 +0200
> 
> > +   for_each_cpu(cpu, cpus) {
> > +   portal = qman_get_affine_portal(cpu);
> > +   res = qman_portal_set_iperiod(portal, period);
> > +   if (res)
> > +   return res;
> > +   res = qman_dqrr_set_ithresh(portal, thresh);
> > +   if (res)
> > +   return res;
> 
> Nope, you can't do it like this.
> 
> If any intermediate change fails, you have to unwind all of the
> changes made up until that point.
> 
> Which means you'll have to store the previous setting somewhere
> and reinstall those saved values in the error path.

Thank you, I'll come back with a v3.

Madalin

RE: [PATCH 3/3] PCI: imx: Add support for i.MX8MQ

[Richard Zhu]

Hi Andrey:
Thanks for your patch-set.
I have comment about the L1SS implementation below.
It's better to figure out one method to fix it.

BR
Richard

> -Original Message-
> From: Andrey Smirnov [mailto:andrew.smir...@gmail.com]
> Sent: 2018年11月18日 2:12
> To: linux-kernel@vger.kernel.org
> Cc: Andrey Smirnov ; bhelg...@google.com;
> Fabio Estevam ; cphe...@gmail.com;
> l.st...@pengutronix.de; Leonard Crestez ;
> Aisheng DONG ; Richard Zhu
> ; dl-linux-imx ;
> linux-arm-ker...@lists.infradead.org; linux-...@vger.kernel.org
> Subject: [PATCH 3/3] PCI: imx: Add support for i.MX8MQ
> 
> Cc: bhelg...@google.com
> Cc: Fabio Estevam 
> Cc: cphe...@gmail.com
> Cc: l.st...@pengutronix.de
> Cc: Leonard Crestez 
> Cc: "A.s. Dong" 
> Cc: Richard Zhu 
> Cc: linux-...@nxp.com
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: linux-kernel@vger.kernel.org
> Cc: linux-...@vger.kernel.org
> Signed-off-by: Andrey Smirnov 
> ---
>  drivers/pci/controller/dwc/Kconfig|   2 +-
>  drivers/pci/controller/dwc/pci-imx6.c | 117 --
>  2 files changed, 113 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/pci/controller/dwc/Kconfig
> b/drivers/pci/controller/dwc/Kconfig
> index 91b0194240a5..2b139acccf32 100644
> --- a/drivers/pci/controller/dwc/Kconfig
> +++ b/drivers/pci/controller/dwc/Kconfig
> @@ -90,7 +90,7 @@ config PCI_EXYNOS
> 
>  config PCI_IMX6
>   bool "Freescale i.MX6 PCIe controller"
> - depends on SOC_IMX6Q || (ARM && COMPILE_TEST)
> + depends on SOC_IMX8MQ || SOC_IMX6Q || (ARM && COMPILE_TEST)
>   depends on PCI_MSI_IRQ_DOMAIN
>   select PCIE_DW_HOST
> 
> diff --git a/drivers/pci/controller/dwc/pci-imx6.c
> b/drivers/pci/controller/dwc/pci-imx6.c
> index 3c3002861d25..8d1f310e41a6 100644
> --- a/drivers/pci/controller/dwc/pci-imx6.c
> +++ b/drivers/pci/controller/dwc/pci-imx6.c
> @@ -8,6 +8,7 @@
>   * Author: Sean Cross 
>   */
> 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -30,6 +31,14 @@
> 
>  #include "pcie-designware.h"
> 
> +#define IMX8MQ_PCIE_LINK_CAP_REG_OFFSET  0x7C
> +#define IMX8MQ_PCIE_LINK_CAP_L1EL_64US   (0x6 << 15)
> +
> +#define IMX8MQ_GPR_PCIE_REF_USE_PAD  BIT(9)
> +#define IMX8MQ_GPR_PCIE_CLK_REQ_OVERRIDE_EN  BIT(10)
> +#define IMX8MQ_GPR_PCIE_CLK_REQ_OVERRIDE BIT(11)
> +
> +
>  #define to_imx6_pcie(x)  dev_get_drvdata((x)->dev)
> 
>  enum imx6_pcie_variants {
> @@ -37,6 +46,7 @@ enum imx6_pcie_variants {
>   IMX6SX,
>   IMX6QP,
>   IMX7D,
> + IMX8MQ,
>  };
> 
>  struct imx6_pcie {
> @@ -48,8 +58,10 @@ struct imx6_pcie {
>   struct clk  *pcie_inbound_axi;
>   struct clk  *pcie;
>   struct regmap   *iomuxc_gpr;
> + u32 gpr1x;
>   struct reset_control*pciephy_reset;
>   struct reset_control*apps_reset;
> + struct reset_control*apps_clk_req;
>   struct reset_control*turnoff_reset;
>   enum imx6_pcie_variants variant;
>   u32 tx_deemph_gen1;
> @@ -59,6 +71,7 @@ struct imx6_pcie {
>   u32 tx_swing_low;
>   int link_gen;
>   struct regulator*vpcie;
> + u32 device_type[2];
>  };
> 
>  /* Parameters for the waiting for PCIe PHY PLL to lock on i.MX7 */ @@
> -245,7 +258,8 @@ static void imx6_pcie_reset_phy(struct imx6_pcie
> *imx6_pcie)  {
>   u32 tmp;
> 
> - if (imx6_pcie->variant == IMX7D)
> + if (imx6_pcie->variant == IMX7D ||
> + imx6_pcie->variant == IMX8MQ)
>   return;
> 
>   pcie_phy_read(imx6_pcie, PHY_RX_OVRD_IN_LO, ); @@ -261,6
> +275,7 @@ static void imx6_pcie_reset_phy(struct imx6_pcie *imx6_pcie)
>   pcie_phy_write(imx6_pcie, PHY_RX_OVRD_IN_LO, tmp);  }
> 
> +#ifdef CONFIG_ARM
>  /*  Added for PCI abort handling */
>  static int imx6q_pcie_abort_handler(unsigned long addr,
>   unsigned int fsr, struct pt_regs *regs) @@ -294,6 +309,7 @@ 
> static
> int imx6q_pcie_abort_handler(unsigned long addr,
> 
>   return 1;
>  }
> +#endif
> 
>  static void imx6_pcie_assert_core_reset(struct imx6_pcie *imx6_pcie)
> { @@ -301,6 +317,7 @@ static void imx6_pcie_assert_core_reset(struct
> imx6_pcie *imx6_pcie)
> 
>   switch (imx6_pcie->variant) {
>   case IMX7D:
> + case IMX8MQ: /* FALLTHROUGH */
>   reset_control_assert(imx6_pcie->pciephy_reset);
>   reset_control_assert(imx6_pcie->apps_reset);
>   break;
> @@ -369,6 +386,18 @@ static int imx6_pcie_enable_ref_clk(struct
> imx6_pcie *imx6_pcie)
>   break;
>   case IMX7D:
>   break;
> + case IMX8MQ:
> + /*
> +  * Set the over ride low and enabled
> +  * make sure that REF_CLK is turned on.
> +  */
> + regmap_update_bits(imx6_pcie->iomuxc_gpr, imx6_pcie->gpr1x,
> +IMX8MQ_GPR_PCIE_CLK_REQ_OVERRIDE,
> + 

RE: [PATCH 3/3] PCI: imx: Add support for i.MX8MQ

[Richard Zhu]

Hi Andrey:
Thanks for your patch-set.
I have comment about the L1SS implementation below.
It's better to figure out one method to fix it.

BR
Richard

> -Original Message-
> From: Andrey Smirnov [mailto:andrew.smir...@gmail.com]
> Sent: 2018年11月18日 2:12
> To: linux-kernel@vger.kernel.org
> Cc: Andrey Smirnov ; bhelg...@google.com;
> Fabio Estevam ; cphe...@gmail.com;
> l.st...@pengutronix.de; Leonard Crestez ;
> Aisheng DONG ; Richard Zhu
> ; dl-linux-imx ;
> linux-arm-ker...@lists.infradead.org; linux-...@vger.kernel.org
> Subject: [PATCH 3/3] PCI: imx: Add support for i.MX8MQ
> 
> Cc: bhelg...@google.com
> Cc: Fabio Estevam 
> Cc: cphe...@gmail.com
> Cc: l.st...@pengutronix.de
> Cc: Leonard Crestez 
> Cc: "A.s. Dong" 
> Cc: Richard Zhu 
> Cc: linux-...@nxp.com
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: linux-kernel@vger.kernel.org
> Cc: linux-...@vger.kernel.org
> Signed-off-by: Andrey Smirnov 
> ---
>  drivers/pci/controller/dwc/Kconfig|   2 +-
>  drivers/pci/controller/dwc/pci-imx6.c | 117 --
>  2 files changed, 113 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/pci/controller/dwc/Kconfig
> b/drivers/pci/controller/dwc/Kconfig
> index 91b0194240a5..2b139acccf32 100644
> --- a/drivers/pci/controller/dwc/Kconfig
> +++ b/drivers/pci/controller/dwc/Kconfig
> @@ -90,7 +90,7 @@ config PCI_EXYNOS
> 
>  config PCI_IMX6
>   bool "Freescale i.MX6 PCIe controller"
> - depends on SOC_IMX6Q || (ARM && COMPILE_TEST)
> + depends on SOC_IMX8MQ || SOC_IMX6Q || (ARM && COMPILE_TEST)
>   depends on PCI_MSI_IRQ_DOMAIN
>   select PCIE_DW_HOST
> 
> diff --git a/drivers/pci/controller/dwc/pci-imx6.c
> b/drivers/pci/controller/dwc/pci-imx6.c
> index 3c3002861d25..8d1f310e41a6 100644
> --- a/drivers/pci/controller/dwc/pci-imx6.c
> +++ b/drivers/pci/controller/dwc/pci-imx6.c
> @@ -8,6 +8,7 @@
>   * Author: Sean Cross 
>   */
> 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -30,6 +31,14 @@
> 
>  #include "pcie-designware.h"
> 
> +#define IMX8MQ_PCIE_LINK_CAP_REG_OFFSET  0x7C
> +#define IMX8MQ_PCIE_LINK_CAP_L1EL_64US   (0x6 << 15)
> +
> +#define IMX8MQ_GPR_PCIE_REF_USE_PAD  BIT(9)
> +#define IMX8MQ_GPR_PCIE_CLK_REQ_OVERRIDE_EN  BIT(10)
> +#define IMX8MQ_GPR_PCIE_CLK_REQ_OVERRIDE BIT(11)
> +
> +
>  #define to_imx6_pcie(x)  dev_get_drvdata((x)->dev)
> 
>  enum imx6_pcie_variants {
> @@ -37,6 +46,7 @@ enum imx6_pcie_variants {
>   IMX6SX,
>   IMX6QP,
>   IMX7D,
> + IMX8MQ,
>  };
> 
>  struct imx6_pcie {
> @@ -48,8 +58,10 @@ struct imx6_pcie {
>   struct clk  *pcie_inbound_axi;
>   struct clk  *pcie;
>   struct regmap   *iomuxc_gpr;
> + u32 gpr1x;
>   struct reset_control*pciephy_reset;
>   struct reset_control*apps_reset;
> + struct reset_control*apps_clk_req;
>   struct reset_control*turnoff_reset;
>   enum imx6_pcie_variants variant;
>   u32 tx_deemph_gen1;
> @@ -59,6 +71,7 @@ struct imx6_pcie {
>   u32 tx_swing_low;
>   int link_gen;
>   struct regulator*vpcie;
> + u32 device_type[2];
>  };
> 
>  /* Parameters for the waiting for PCIe PHY PLL to lock on i.MX7 */ @@
> -245,7 +258,8 @@ static void imx6_pcie_reset_phy(struct imx6_pcie
> *imx6_pcie)  {
>   u32 tmp;
> 
> - if (imx6_pcie->variant == IMX7D)
> + if (imx6_pcie->variant == IMX7D ||
> + imx6_pcie->variant == IMX8MQ)
>   return;
> 
>   pcie_phy_read(imx6_pcie, PHY_RX_OVRD_IN_LO, ); @@ -261,6
> +275,7 @@ static void imx6_pcie_reset_phy(struct imx6_pcie *imx6_pcie)
>   pcie_phy_write(imx6_pcie, PHY_RX_OVRD_IN_LO, tmp);  }
> 
> +#ifdef CONFIG_ARM
>  /*  Added for PCI abort handling */
>  static int imx6q_pcie_abort_handler(unsigned long addr,
>   unsigned int fsr, struct pt_regs *regs) @@ -294,6 +309,7 @@ 
> static
> int imx6q_pcie_abort_handler(unsigned long addr,
> 
>   return 1;
>  }
> +#endif
> 
>  static void imx6_pcie_assert_core_reset(struct imx6_pcie *imx6_pcie)
> { @@ -301,6 +317,7 @@ static void imx6_pcie_assert_core_reset(struct
> imx6_pcie *imx6_pcie)
> 
>   switch (imx6_pcie->variant) {
>   case IMX7D:
> + case IMX8MQ: /* FALLTHROUGH */
>   reset_control_assert(imx6_pcie->pciephy_reset);
>   reset_control_assert(imx6_pcie->apps_reset);
>   break;
> @@ -369,6 +386,18 @@ static int imx6_pcie_enable_ref_clk(struct
> imx6_pcie *imx6_pcie)
>   break;
>   case IMX7D:
>   break;
> + case IMX8MQ:
> + /*
> +  * Set the over ride low and enabled
> +  * make sure that REF_CLK is turned on.
> +  */
> + regmap_update_bits(imx6_pcie->iomuxc_gpr, imx6_pcie->gpr1x,
> +IMX8MQ_GPR_PCIE_CLK_REQ_OVERRIDE,
> + 

Re: [PATCH 1/2] dt-bindings: phy: Add Qualcomm Synopsys High-Speed USB PHY binding

[Shawn Guo]

On Sat, Nov 17, 2018 at 09:13:38AM -0600, Rob Herring wrote:

> > > > +- qcom,init-seq:
> > > > +Value type: 
> > > > +Definition: Should contain a sequence of  
> > > > tuples to
> > > > +program 'value' into phy register at 'offset' with 
> > > > 'delay'
> > > > +   in us afterwards.
> > >
> > > If we wanted this type of thing in DT, we'd have a generic binding (or
> > > forth).
> >
> > Right now, this is a qualcomm usb phy specific bindings - first used in
> > qcom,usb-hs-phy.txt and I extended it a bit for my phy.  As this is not
> > a so good hardware description, I'm a little hesitated to make it
> > generic for other platforms to use in general.  What about we put off it
> > a little bit until we see more platforms need the same thing?
> 
> I'm not saying I want it generic. Quite the opposite. I don't think we
> should have it either generically or vendor specific. The main thing I
> have a problem with is the timing information because then we're more
> that just data. Without that we're talking about a bunch of properties
> for register fields or just raw register values in DT. That becomes
> more of a judgement call. There's not too much value in making a
> driver translate a bunch of properties just to stuff them into
> registers on init. But then just allowing any raw register value to be
> in DT could be easily abused.

Rob,

I agree with your comments.  Honestly, I'm not comfortable with this
'qcom,init-seq' thing in the first impression.  The similar existence in
mainline qcom,usb-hs-phy.txt makes me think it might be acceptable with
the timing data added.  Okay, I know your position on this now.

@Sriharsha,

Seeing that 'qcom,init-seq' is being configured with the exactly same
values for both HS phys in SoC level dts file (qcs404.dtsi), I think
such settings can be moved into driver code as SoC specific data.
Unless you have a different view on this, I will do it with v4.

Shawn

Re: [PATCH 1/2] dt-bindings: phy: Add Qualcomm Synopsys High-Speed USB PHY binding

[Shawn Guo]

On Sat, Nov 17, 2018 at 09:13:38AM -0600, Rob Herring wrote:

> > > > +- qcom,init-seq:
> > > > +Value type: 
> > > > +Definition: Should contain a sequence of  
> > > > tuples to
> > > > +program 'value' into phy register at 'offset' with 
> > > > 'delay'
> > > > +   in us afterwards.
> > >
> > > If we wanted this type of thing in DT, we'd have a generic binding (or
> > > forth).
> >
> > Right now, this is a qualcomm usb phy specific bindings - first used in
> > qcom,usb-hs-phy.txt and I extended it a bit for my phy.  As this is not
> > a so good hardware description, I'm a little hesitated to make it
> > generic for other platforms to use in general.  What about we put off it
> > a little bit until we see more platforms need the same thing?
> 
> I'm not saying I want it generic. Quite the opposite. I don't think we
> should have it either generically or vendor specific. The main thing I
> have a problem with is the timing information because then we're more
> that just data. Without that we're talking about a bunch of properties
> for register fields or just raw register values in DT. That becomes
> more of a judgement call. There's not too much value in making a
> driver translate a bunch of properties just to stuff them into
> registers on init. But then just allowing any raw register value to be
> in DT could be easily abused.

Rob,

I agree with your comments.  Honestly, I'm not comfortable with this
'qcom,init-seq' thing in the first impression.  The similar existence in
mainline qcom,usb-hs-phy.txt makes me think it might be acceptable with
the timing data added.  Okay, I know your position on this now.

@Sriharsha,

Seeing that 'qcom,init-seq' is being configured with the exactly same
values for both HS phys in SoC level dts file (qcs404.dtsi), I think
such settings can be moved into driver code as SoC specific data.
Unless you have a different view on this, I will do it with v4.

Shawn

[PATCH 2/2] iio: adc: ti_am335x_tscadc: Improve accuracy of measurement

[Vignesh R]

When performing single ended measurements with TSCADC, its recommended
to set negative input (SEL_INM_SWC_3_0) of ADC step to ADC's VREFN in the
corresponding STEP_CONFIGx register.
Also, the positive(SEL_RFP_SWC_2_0) and negative(SEL_RFM_SWC_1_0)
reference voltage for ADC step needs to be set to VREFP and VREFN
respectively in STEP_CONFIGx register.
Without these changes, there may be variation of as much as ~2% in the
ADC's digital output which is bad for precise measurement.

Signed-off-by: Vignesh R 
---
 drivers/iio/adc/ti_am335x_adc.c  | 5 -
 include/linux/mfd/ti_am335x_tscadc.h | 4 
 2 files changed, 8 insertions(+), 1 deletion(-)

diff --git a/drivers/iio/adc/ti_am335x_adc.c b/drivers/iio/adc/ti_am335x_adc.c
index cafb1dcadc48..9d984f2a8ba7 100644
--- a/drivers/iio/adc/ti_am335x_adc.c
+++ b/drivers/iio/adc/ti_am335x_adc.c
@@ -142,7 +142,10 @@ static void tiadc_step_config(struct iio_dev *indio_dev)
stepconfig |= STEPCONFIG_MODE_SWCNT;
 
tiadc_writel(adc_dev, REG_STEPCONFIG(steps),
-   stepconfig | STEPCONFIG_INP(chan));
+   stepconfig | STEPCONFIG_INP(chan) |
+   STEPCONFIG_INM_ADCREFM |
+   STEPCONFIG_RFP_VREFP |
+   STEPCONFIG_RFM_VREFN);
 
if (adc_dev->open_delay[i] > STEPDELAY_OPEN_MASK) {
dev_warn(dev, "chan %d open delay truncating to 
0x3\n",
diff --git a/include/linux/mfd/ti_am335x_tscadc.h 
b/include/linux/mfd/ti_am335x_tscadc.h
index b9a53e013bff..483168403ae5 100644
--- a/include/linux/mfd/ti_am335x_tscadc.h
+++ b/include/linux/mfd/ti_am335x_tscadc.h
@@ -78,6 +78,8 @@
 #define STEPCONFIG_YNN BIT(8)
 #define STEPCONFIG_XNP BIT(9)
 #define STEPCONFIG_YPN BIT(10)
+#define STEPCONFIG_RFP(val)((val) << 12)
+#define STEPCONFIG_RFP_VREFP   (0x3 << 12)
 #define STEPCONFIG_INM_MASK(0xF << 15)
 #define STEPCONFIG_INM(val)((val) << 15)
 #define STEPCONFIG_INM_ADCREFM STEPCONFIG_INM(8)
@@ -86,6 +88,8 @@
 #define STEPCONFIG_INP_AN4 STEPCONFIG_INP(4)
 #define STEPCONFIG_INP_ADCREFM STEPCONFIG_INP(8)
 #define STEPCONFIG_FIFO1   BIT(26)
+#define STEPCONFIG_RFM(val)((val) << 23)
+#define STEPCONFIG_RFM_VREFN   (0x3 << 23)
 
 /* Delay register */
 #define STEPDELAY_OPEN_MASK(0x3 << 0)
-- 
2.19.1

[PATCH 2/2] iio: adc: ti_am335x_tscadc: Improve accuracy of measurement

[Vignesh R]

When performing single ended measurements with TSCADC, its recommended
to set negative input (SEL_INM_SWC_3_0) of ADC step to ADC's VREFN in the
corresponding STEP_CONFIGx register.
Also, the positive(SEL_RFP_SWC_2_0) and negative(SEL_RFM_SWC_1_0)
reference voltage for ADC step needs to be set to VREFP and VREFN
respectively in STEP_CONFIGx register.
Without these changes, there may be variation of as much as ~2% in the
ADC's digital output which is bad for precise measurement.

Signed-off-by: Vignesh R 
---
 drivers/iio/adc/ti_am335x_adc.c  | 5 -
 include/linux/mfd/ti_am335x_tscadc.h | 4 
 2 files changed, 8 insertions(+), 1 deletion(-)

diff --git a/drivers/iio/adc/ti_am335x_adc.c b/drivers/iio/adc/ti_am335x_adc.c
index cafb1dcadc48..9d984f2a8ba7 100644
--- a/drivers/iio/adc/ti_am335x_adc.c
+++ b/drivers/iio/adc/ti_am335x_adc.c
@@ -142,7 +142,10 @@ static void tiadc_step_config(struct iio_dev *indio_dev)
stepconfig |= STEPCONFIG_MODE_SWCNT;
 
tiadc_writel(adc_dev, REG_STEPCONFIG(steps),
-   stepconfig | STEPCONFIG_INP(chan));
+   stepconfig | STEPCONFIG_INP(chan) |
+   STEPCONFIG_INM_ADCREFM |
+   STEPCONFIG_RFP_VREFP |
+   STEPCONFIG_RFM_VREFN);
 
if (adc_dev->open_delay[i] > STEPDELAY_OPEN_MASK) {
dev_warn(dev, "chan %d open delay truncating to 
0x3\n",
diff --git a/include/linux/mfd/ti_am335x_tscadc.h 
b/include/linux/mfd/ti_am335x_tscadc.h
index b9a53e013bff..483168403ae5 100644
--- a/include/linux/mfd/ti_am335x_tscadc.h
+++ b/include/linux/mfd/ti_am335x_tscadc.h
@@ -78,6 +78,8 @@
 #define STEPCONFIG_YNN BIT(8)
 #define STEPCONFIG_XNP BIT(9)
 #define STEPCONFIG_YPN BIT(10)
+#define STEPCONFIG_RFP(val)((val) << 12)
+#define STEPCONFIG_RFP_VREFP   (0x3 << 12)
 #define STEPCONFIG_INM_MASK(0xF << 15)
 #define STEPCONFIG_INM(val)((val) << 15)
 #define STEPCONFIG_INM_ADCREFM STEPCONFIG_INM(8)
@@ -86,6 +88,8 @@
 #define STEPCONFIG_INP_AN4 STEPCONFIG_INP(4)
 #define STEPCONFIG_INP_ADCREFM STEPCONFIG_INP(8)
 #define STEPCONFIG_FIFO1   BIT(26)
+#define STEPCONFIG_RFM(val)((val) << 23)
+#define STEPCONFIG_RFM_VREFN   (0x3 << 23)
 
 /* Delay register */
 #define STEPDELAY_OPEN_MASK(0x3 << 0)
-- 
2.19.1

[PATCH 1/2] mfd: ti_am335x_tscadc: Provide unique name for child mfd cells

[Vignesh R]

Provide unique names for child mfd cells, this is required in order to
support registering of multiple instances of same ti_am335x_tscadc IP.

Signed-off-by: Vignesh R 
---
 drivers/mfd/ti_am335x_tscadc.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/mfd/ti_am335x_tscadc.c b/drivers/mfd/ti_am335x_tscadc.c
index c2d47d78705b..ee08af34f81d 100644
--- a/drivers/mfd/ti_am335x_tscadc.c
+++ b/drivers/mfd/ti_am335x_tscadc.c
@@ -248,7 +248,8 @@ static  int ti_tscadc_probe(struct platform_device 
*pdev)
if (tsc_wires > 0) {
tscadc->tsc_cell = tscadc->used_cells;
cell = >cells[tscadc->used_cells++];
-   cell->name = "TI-am335x-tsc";
+   cell->name = devm_kasprintf(>dev, GFP_KERNEL, "%s:%s",
+   dev_name(>dev), "tsc");
cell->of_compatible = "ti,am3359-tsc";
cell->platform_data = 
cell->pdata_size = sizeof(tscadc);
@@ -258,7 +259,8 @@ static  int ti_tscadc_probe(struct platform_device 
*pdev)
if (adc_channels > 0) {
tscadc->adc_cell = tscadc->used_cells;
cell = >cells[tscadc->used_cells++];
-   cell->name = "TI-am335x-adc";
+   cell->name = devm_kasprintf(>dev, GFP_KERNEL, "%s:%s",
+   dev_name(>dev), "adc");
cell->of_compatible = "ti,am3359-adc";
cell->platform_data = 
cell->pdata_size = sizeof(tscadc);
-- 
2.19.1

[PATCH 1/2] mfd: ti_am335x_tscadc: Provide unique name for child mfd cells

[Vignesh R]

Provide unique names for child mfd cells, this is required in order to
support registering of multiple instances of same ti_am335x_tscadc IP.

Signed-off-by: Vignesh R 
---
 drivers/mfd/ti_am335x_tscadc.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/mfd/ti_am335x_tscadc.c b/drivers/mfd/ti_am335x_tscadc.c
index c2d47d78705b..ee08af34f81d 100644
--- a/drivers/mfd/ti_am335x_tscadc.c
+++ b/drivers/mfd/ti_am335x_tscadc.c
@@ -248,7 +248,8 @@ static  int ti_tscadc_probe(struct platform_device 
*pdev)
if (tsc_wires > 0) {
tscadc->tsc_cell = tscadc->used_cells;
cell = >cells[tscadc->used_cells++];
-   cell->name = "TI-am335x-tsc";
+   cell->name = devm_kasprintf(>dev, GFP_KERNEL, "%s:%s",
+   dev_name(>dev), "tsc");
cell->of_compatible = "ti,am3359-tsc";
cell->platform_data = 
cell->pdata_size = sizeof(tscadc);
@@ -258,7 +259,8 @@ static  int ti_tscadc_probe(struct platform_device 
*pdev)
if (adc_channels > 0) {
tscadc->adc_cell = tscadc->used_cells;
cell = >cells[tscadc->used_cells++];
-   cell->name = "TI-am335x-adc";
+   cell->name = devm_kasprintf(>dev, GFP_KERNEL, "%s:%s",
+   dev_name(>dev), "adc");
cell->of_compatible = "ti,am3359-adc";
cell->platform_data = 
cell->pdata_size = sizeof(tscadc);
-- 
2.19.1

[PATCH 0/2] tscadc: Couple of fixes

[Vignesh R]

Couple of fixes for tscadc drivers that I found while adding support for
new SoC. Patches are standalone and can go via individual domain trees.

Vignesh R (2):
  mfd: ti_am335x_tscadc: Provide unique name for child mfd cells
  iio: adc: ti_am335x_tscadc: Improve accuracy of measurement

 drivers/iio/adc/ti_am335x_adc.c  | 5 -
 drivers/mfd/ti_am335x_tscadc.c   | 6 --
 include/linux/mfd/ti_am335x_tscadc.h | 4 
 3 files changed, 12 insertions(+), 3 deletions(-)

-- 
2.19.1

[PATCH 0/2] tscadc: Couple of fixes

[Vignesh R]

Couple of fixes for tscadc drivers that I found while adding support for
new SoC. Patches are standalone and can go via individual domain trees.

Vignesh R (2):
  mfd: ti_am335x_tscadc: Provide unique name for child mfd cells
  iio: adc: ti_am335x_tscadc: Improve accuracy of measurement

 drivers/iio/adc/ti_am335x_adc.c  | 5 -
 drivers/mfd/ti_am335x_tscadc.c   | 6 --
 include/linux/mfd/ti_am335x_tscadc.h | 4 
 3 files changed, 12 insertions(+), 3 deletions(-)

-- 
2.19.1

Re: [PATCH v4] drivers/vfio: Fix a redundant copy bug

[David Gibson]

On Mon, Oct 29, 2018 at 03:32:34PM -0600, Alex Williamson wrote:
> On Mon, 29 Oct 2018 13:56:54 -0500
> Wenwen Wang  wrote:
> 
> > Hello,
> > 
> > Could you please apply this patch? Thanks!
> 
> I'd like to see testing and/or review from David or Alexey since I also
> don't have an environment for spapr/eeh.  We're already late into the
> v4.20 merge window so this is probably v4.21 material.  Thanks,

I didn't spot this for ages, since I wasn't CCed, I'm guessing the
same is true for Alexey.

TBH, I don't think it's worth bothering with this.  It's a tiny amount
of extra work on a rare debug path.  A couple of code lines simplicity
is worth more than a few bytes worth of redundant copy here.

Testing is.. difficult, since the EEH is already so broken it's hard
to know what to compare against.  Sam Bobroff is already looking
medium-long term at a bunch of EEH rework, so it's quite possible this
will be rewritten then anyway.

> 
> Alex
> 
> > On Wed, Oct 17, 2018 at 2:18 PM Wenwen Wang  wrote:
> > >
> > > In vfio_spapr_iommu_eeh_ioctl(), if the ioctl command is VFIO_EEH_PE_OP,
> > > the user-space buffer 'arg' is copied to the kernel object 'op' and the
> > > 'argsz' and 'flags' fields of 'op' are checked. If the check fails, an
> > > error code EINVAL is returned. Otherwise, 'op.op' is further checked
> > > through a switch statement to invoke related handlers. If 'op.op' is
> > > VFIO_EEH_PE_INJECT_ERR, the whole user-space buffer 'arg' is copied again
> > > to 'op' to obtain the err information. However, in the following execution
> > > of this case, the fields of 'op', except the field 'err', are actually not
> > > used. That is, the second copy has a redundant part. Therefore, for
> > > performance consideration, the redundant part of the second copy should be
> > > removed.
> > >
> > > This patch removes such a part in the second copy. It only copies from
> > > 'err.type' to 'err.mask', which is exactly required by the
> > > VFIO_EEH_PE_INJECT_ERR op.
> > >
> > > Signed-off-by: Wenwen Wang 
> > > ---
> > >  drivers/vfio/vfio_spapr_eeh.c | 9 ++---
> > >  1 file changed, 6 insertions(+), 3 deletions(-)
> > >
> > > diff --git a/drivers/vfio/vfio_spapr_eeh.c b/drivers/vfio/vfio_spapr_eeh.c
> > > index 38edeb4..66634c6 100644
> > > --- a/drivers/vfio/vfio_spapr_eeh.c
> > > +++ b/drivers/vfio/vfio_spapr_eeh.c
> > > @@ -37,6 +37,7 @@ long vfio_spapr_iommu_eeh_ioctl(struct iommu_group 
> > > *group,
> > > struct eeh_pe *pe;
> > > struct vfio_eeh_pe_op op;
> > > unsigned long minsz;
> > > +   unsigned long start, end;
> > > long ret = -EINVAL;
> > >
> > > switch (cmd) {
> > > @@ -86,10 +87,12 @@ long vfio_spapr_iommu_eeh_ioctl(struct iommu_group 
> > > *group,
> > > ret = eeh_pe_configure(pe);
> > > break;
> > > case VFIO_EEH_PE_INJECT_ERR:
> > > -   minsz = offsetofend(struct vfio_eeh_pe_op, 
> > > err.mask);
> > > -   if (op.argsz < minsz)
> > > +   start = offsetof(struct vfio_eeh_pe_op, err.type);
> > > +   end = offsetofend(struct vfio_eeh_pe_op, 
> > > err.mask);
> > > +   if (op.argsz < end)
> > > return -EINVAL;
> > > -   if (copy_from_user(, (void __user *)arg, 
> > > minsz))
> > > +   if (copy_from_user(, (char __user *)arg +
> > > +   start, end - start))
> > > return -EFAULT;
> > >
> > > ret = eeh_pe_inject_err(pe, op.err.type, 
> > > op.err.func,
> 

-- 
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au  | minimalist, thank you.  NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson


signature.asc
Description: PGP signature

Re: [PATCH v4] drivers/vfio: Fix a redundant copy bug

[David Gibson]

On Mon, Oct 29, 2018 at 03:32:34PM -0600, Alex Williamson wrote:
> On Mon, 29 Oct 2018 13:56:54 -0500
> Wenwen Wang  wrote:
> 
> > Hello,
> > 
> > Could you please apply this patch? Thanks!
> 
> I'd like to see testing and/or review from David or Alexey since I also
> don't have an environment for spapr/eeh.  We're already late into the
> v4.20 merge window so this is probably v4.21 material.  Thanks,

I didn't spot this for ages, since I wasn't CCed, I'm guessing the
same is true for Alexey.

TBH, I don't think it's worth bothering with this.  It's a tiny amount
of extra work on a rare debug path.  A couple of code lines simplicity
is worth more than a few bytes worth of redundant copy here.

Testing is.. difficult, since the EEH is already so broken it's hard
to know what to compare against.  Sam Bobroff is already looking
medium-long term at a bunch of EEH rework, so it's quite possible this
will be rewritten then anyway.

> 
> Alex
> 
> > On Wed, Oct 17, 2018 at 2:18 PM Wenwen Wang  wrote:
> > >
> > > In vfio_spapr_iommu_eeh_ioctl(), if the ioctl command is VFIO_EEH_PE_OP,
> > > the user-space buffer 'arg' is copied to the kernel object 'op' and the
> > > 'argsz' and 'flags' fields of 'op' are checked. If the check fails, an
> > > error code EINVAL is returned. Otherwise, 'op.op' is further checked
> > > through a switch statement to invoke related handlers. If 'op.op' is
> > > VFIO_EEH_PE_INJECT_ERR, the whole user-space buffer 'arg' is copied again
> > > to 'op' to obtain the err information. However, in the following execution
> > > of this case, the fields of 'op', except the field 'err', are actually not
> > > used. That is, the second copy has a redundant part. Therefore, for
> > > performance consideration, the redundant part of the second copy should be
> > > removed.
> > >
> > > This patch removes such a part in the second copy. It only copies from
> > > 'err.type' to 'err.mask', which is exactly required by the
> > > VFIO_EEH_PE_INJECT_ERR op.
> > >
> > > Signed-off-by: Wenwen Wang 
> > > ---
> > >  drivers/vfio/vfio_spapr_eeh.c | 9 ++---
> > >  1 file changed, 6 insertions(+), 3 deletions(-)
> > >
> > > diff --git a/drivers/vfio/vfio_spapr_eeh.c b/drivers/vfio/vfio_spapr_eeh.c
> > > index 38edeb4..66634c6 100644
> > > --- a/drivers/vfio/vfio_spapr_eeh.c
> > > +++ b/drivers/vfio/vfio_spapr_eeh.c
> > > @@ -37,6 +37,7 @@ long vfio_spapr_iommu_eeh_ioctl(struct iommu_group 
> > > *group,
> > > struct eeh_pe *pe;
> > > struct vfio_eeh_pe_op op;
> > > unsigned long minsz;
> > > +   unsigned long start, end;
> > > long ret = -EINVAL;
> > >
> > > switch (cmd) {
> > > @@ -86,10 +87,12 @@ long vfio_spapr_iommu_eeh_ioctl(struct iommu_group 
> > > *group,
> > > ret = eeh_pe_configure(pe);
> > > break;
> > > case VFIO_EEH_PE_INJECT_ERR:
> > > -   minsz = offsetofend(struct vfio_eeh_pe_op, 
> > > err.mask);
> > > -   if (op.argsz < minsz)
> > > +   start = offsetof(struct vfio_eeh_pe_op, err.type);
> > > +   end = offsetofend(struct vfio_eeh_pe_op, 
> > > err.mask);
> > > +   if (op.argsz < end)
> > > return -EINVAL;
> > > -   if (copy_from_user(, (void __user *)arg, 
> > > minsz))
> > > +   if (copy_from_user(, (char __user *)arg +
> > > +   start, end - start))
> > > return -EFAULT;
> > >
> > > ret = eeh_pe_inject_err(pe, op.err.type, 
> > > op.err.func,
> 

-- 
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au  | minimalist, thank you.  NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson


signature.asc
Description: PGP signature

Re: [PATCH RFC] hist lookups

[David Miller]

From: Namhyung Kim 
Date: Mon, 19 Nov 2018 15:28:37 +0900

> Hello David,
> 
> On Sun, Nov 18, 2018 at 08:52:43PM -0800, David Miller wrote:
>> From: Jiri Olsa 
>> Date: Tue, 13 Nov 2018 11:40:54 +0100
>> 
>> > I pushed/rebased what I have to perf/fixes branch again
>> > 
>> > please note I had to change our compile changes, because
>> > they wouldn't compile on x86, but I can't verify on sparc,
>> > so you might see some compile fails again
>> 
>> I just checked your current perf/fixes branch.
>> 
>> It builds on Sparc ;-)
>> 
>> And it behaves better too.  I do get tons of drops and lost events,
>> but it seems to keep going even during the hardest load.
>> 
>> Eventually I end up with a lot of unresolvable histogram entries,
>> so that is something to look into.
> 
> Did you record callchains as well?  I'd like to know whether it's
> related to the children (cumulative) mode or not.

I did not have callchains on, just plain "./perf top"

Re: [PATCH RFC] hist lookups

[David Miller]

From: Namhyung Kim 
Date: Mon, 19 Nov 2018 15:28:37 +0900

> Hello David,
> 
> On Sun, Nov 18, 2018 at 08:52:43PM -0800, David Miller wrote:
>> From: Jiri Olsa 
>> Date: Tue, 13 Nov 2018 11:40:54 +0100
>> 
>> > I pushed/rebased what I have to perf/fixes branch again
>> > 
>> > please note I had to change our compile changes, because
>> > they wouldn't compile on x86, but I can't verify on sparc,
>> > so you might see some compile fails again
>> 
>> I just checked your current perf/fixes branch.
>> 
>> It builds on Sparc ;-)
>> 
>> And it behaves better too.  I do get tons of drops and lost events,
>> but it seems to keep going even during the hardest load.
>> 
>> Eventually I end up with a lot of unresolvable histogram entries,
>> so that is something to look into.
> 
> Did you record callchains as well?  I'd like to know whether it's
> related to the children (cumulative) mode or not.

I did not have callchains on, just plain "./perf top"

Re: [PATCH RFC] hist lookups

[Namhyung Kim]

Hello David,

On Sun, Nov 18, 2018 at 08:52:43PM -0800, David Miller wrote:
> From: Jiri Olsa 
> Date: Tue, 13 Nov 2018 11:40:54 +0100
> 
> > I pushed/rebased what I have to perf/fixes branch again
> > 
> > please note I had to change our compile changes, because
> > they wouldn't compile on x86, but I can't verify on sparc,
> > so you might see some compile fails again
> 
> I just checked your current perf/fixes branch.
> 
> It builds on Sparc ;-)
> 
> And it behaves better too.  I do get tons of drops and lost events,
> but it seems to keep going even during the hardest load.
> 
> Eventually I end up with a lot of unresolvable histogram entries,
> so that is something to look into.

Did you record callchains as well?  I'd like to know whether it's
related to the children (cumulative) mode or not.

Thanks,
Namhyung


> 
> I looked at your drop logic and it seems perfect, we avoid dropping
> all non-SAMPLE events which is what we want.  So that can't be the
> cause of the issues I am seeing.
> 

Re: [PATCH RFC] hist lookups

[Namhyung Kim]

Hello David,

On Sun, Nov 18, 2018 at 08:52:43PM -0800, David Miller wrote:
> From: Jiri Olsa 
> Date: Tue, 13 Nov 2018 11:40:54 +0100
> 
> > I pushed/rebased what I have to perf/fixes branch again
> > 
> > please note I had to change our compile changes, because
> > they wouldn't compile on x86, but I can't verify on sparc,
> > so you might see some compile fails again
> 
> I just checked your current perf/fixes branch.
> 
> It builds on Sparc ;-)
> 
> And it behaves better too.  I do get tons of drops and lost events,
> but it seems to keep going even during the hardest load.
> 
> Eventually I end up with a lot of unresolvable histogram entries,
> so that is something to look into.

Did you record callchains as well?  I'd like to know whether it's
related to the children (cumulative) mode or not.

Thanks,
Namhyung


> 
> I looked at your drop logic and it seems perfect, we avoid dropping
> all non-SAMPLE events which is what we want.  So that can't be the
> cause of the issues I am seeing.
> 

[Patch v3 ] drm/msm/dpu: Correct dpu destroy and disable order

[Jayant Shekhar]

In case of msm drm bind failure, pm runtime put sync
is called from dsi driver which issues an asynchronous
put on mdss device. Subsequently when dpu_mdss_destroy
is triggered the change will make sure to put the mdss
device in suspend and clearing pending work if not
scheduled.

Changes in v2:
   - Removed double spacings [Jeykumar]

Changes in v3:
   - Fix clock on issue during bootup [Rajendra]

Signed-off-by: Jayant Shekhar 
---
 drivers/gpu/drm/msm/disp/dpu1/dpu_mdss.c | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_mdss.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_mdss.c
index fd9c893..df8127b 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_mdss.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_mdss.c
@@ -156,18 +156,16 @@ static void dpu_mdss_destroy(struct drm_device *dev)
struct dpu_mdss *dpu_mdss = to_dpu_mdss(priv->mdss);
struct dss_module_power *mp = _mdss->mp;
 
+   pm_runtime_suspend(dev->dev);
+   pm_runtime_disable(dev->dev);
_dpu_mdss_irq_domain_fini(dpu_mdss);
-
free_irq(platform_get_irq(pdev, 0), dpu_mdss);
-
msm_dss_put_clk(mp->clk_config, mp->num_clk);
devm_kfree(>dev, mp->clk_config);
 
if (dpu_mdss->mmio)
devm_iounmap(>dev, dpu_mdss->mmio);
dpu_mdss->mmio = NULL;
-
-   pm_runtime_disable(dev->dev);
priv->mdss = NULL;
 }
 
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

[Patch v3 ] drm/msm/dpu: Correct dpu destroy and disable order

[Jayant Shekhar]

In case of msm drm bind failure, pm runtime put sync
is called from dsi driver which issues an asynchronous
put on mdss device. Subsequently when dpu_mdss_destroy
is triggered the change will make sure to put the mdss
device in suspend and clearing pending work if not
scheduled.

Changes in v2:
   - Removed double spacings [Jeykumar]

Changes in v3:
   - Fix clock on issue during bootup [Rajendra]

Signed-off-by: Jayant Shekhar 
---
 drivers/gpu/drm/msm/disp/dpu1/dpu_mdss.c | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_mdss.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_mdss.c
index fd9c893..df8127b 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_mdss.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_mdss.c
@@ -156,18 +156,16 @@ static void dpu_mdss_destroy(struct drm_device *dev)
struct dpu_mdss *dpu_mdss = to_dpu_mdss(priv->mdss);
struct dss_module_power *mp = _mdss->mp;
 
+   pm_runtime_suspend(dev->dev);
+   pm_runtime_disable(dev->dev);
_dpu_mdss_irq_domain_fini(dpu_mdss);
-
free_irq(platform_get_irq(pdev, 0), dpu_mdss);
-
msm_dss_put_clk(mp->clk_config, mp->num_clk);
devm_kfree(>dev, mp->clk_config);
 
if (dpu_mdss->mmio)
devm_iounmap(>dev, dpu_mdss->mmio);
dpu_mdss->mmio = NULL;
-
-   pm_runtime_disable(dev->dev);
priv->mdss = NULL;
 }
 
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [RFC PATCH] zinc chacha20 generic implementation using crypto API code

[Herbert Xu]

Hi Jason:

On Mon, Nov 19, 2018 at 07:13:07AM +0100, Jason A. Donenfeld wrote:
>
> Sorry, but there isn't a chance I'll agree to this. The whole idea is
> to have a clean place to focus on synchronous software
> implementations, and not keep it tangled up with the asynchronous API.

There is nothing asynchronous in the relevant crypto code at all.
The underlying CPU-based software implementations are all completely
synchronous, including the architecture-specific ones such as
x86/arm.

So I don't understand why you are rejecting it.

Cheers,
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: [RFC PATCH] zinc chacha20 generic implementation using crypto API code

[Herbert Xu]

Hi Jason:

On Mon, Nov 19, 2018 at 07:13:07AM +0100, Jason A. Donenfeld wrote:
>
> Sorry, but there isn't a chance I'll agree to this. The whole idea is
> to have a clean place to focus on synchronous software
> implementations, and not keep it tangled up with the asynchronous API.

There is nothing asynchronous in the relevant crypto code at all.
The underlying CPU-based software implementations are all completely
synchronous, including the architecture-specific ones such as
x86/arm.

So I don't understand why you are rejecting it.

Cheers,
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

RE: [LINUX PATCH v12 3/3] mtd: rawnand: arasan: Add support for Arasan NAND Flash Controller

[Naga Sureshkumar Relli]

H Boris,

> -Original Message-
> From: Boris Brezillon [mailto:boris.brezil...@bootlin.com]
> Sent: Monday, November 19, 2018 1:13 AM
> To: Naga Sureshkumar Relli 
> Cc: miquel.ray...@bootlin.com; rich...@nod.at; dw...@infradead.org;
> computersforpe...@gmail.com; marek.va...@gmail.com; 
> linux-...@lists.infradead.org; linux-
> ker...@vger.kernel.org; nagasures...@gmail.com; r...@kernel.org; Michal Simek
> 
> Subject: Re: [LINUX PATCH v12 3/3] mtd: rawnand: arasan: Add support for 
> Arasan NAND
> Flash Controller
> 
> On Thu, 15 Nov 2018 09:34:16 +
> Naga Sureshkumar Relli  wrote:
> 
> > Hi Boris & Miquel,
> >
> > I am updating the driver by addressing your comments, and I have one
> > concern,  especially in anfc_read_page_hwecc(), there I am checking for 
> > erased pages bit flips.
> > Since Arasan NAND controller doesn't have multibit error detection
> > beyond 24-bit( it can correct up to 24 bit), i.e. there is no indication 
> > from controller to detect
> uncorrectable error beyond 24bit.
> 
> Do you mean that you can't detect uncorrectable errors, or just that it's not 
> 100% sure to detect
> errors above max_strength?
Yes, in Arasan NAND controller there is no way to detect uncorrectable errors 
beyond 24-bit.
> 
> > So I took some error count as default value(MULTI_BIT_ERR_CNT  16, I
> > put this based on the error count that I got while reading erased page on 
> > Micron device).
> > And during a page read, will just read the error count register and
> > compare this value with the default error count(16) and if it is more Than 
> > default then I am
> checking for erased page bit flips.
> 
> Hm, that's wrong, especially if you set ecc_strength to something > 16.
Ok
> 
> > I am doubting that this will not work in all cases.
> 
> It definitely doesn't.
Ok
> 
> > In my case it is just working because the error count that it got on an 
> > erased page is 16.
> > Could you please suggest a way to do detect erased_page bit flips when 
> > reading a page with
> HW-ECC?.
> 
> I'm a bit lost. Is the problem only about bitflips in erase pages, or is it 
> also impacting reads of
> written pages that lead to uncorrectable errors.
Yes, it is for both. But in case of read errors that we can't detect beyond 
24-bit, then the answer from HW design team
Is that the flash part is bad.
Unfortunately till now we haven't ran into that situation(read errors of 
written pages beyond 24-bit).
But we are hitting this because of erased page reading(needed in case of ubifs).

> 
> Don't you have a bit (or several bits) reporting when the ECC engine was not 
> able to correct
> data? I you do, you should base the "detect bitflips in erase pages" logic on 
> this information.
Bit reporting for several bit errors is there only for Hamming(1bit correction 
and 2bit detection) but not in BCH.

Thanks,
Naga Sureshkumar Relli

RE: [LINUX PATCH v12 3/3] mtd: rawnand: arasan: Add support for Arasan NAND Flash Controller

[Naga Sureshkumar Relli]

H Boris,

> -Original Message-
> From: Boris Brezillon [mailto:boris.brezil...@bootlin.com]
> Sent: Monday, November 19, 2018 1:13 AM
> To: Naga Sureshkumar Relli 
> Cc: miquel.ray...@bootlin.com; rich...@nod.at; dw...@infradead.org;
> computersforpe...@gmail.com; marek.va...@gmail.com; 
> linux-...@lists.infradead.org; linux-
> ker...@vger.kernel.org; nagasures...@gmail.com; r...@kernel.org; Michal Simek
> 
> Subject: Re: [LINUX PATCH v12 3/3] mtd: rawnand: arasan: Add support for 
> Arasan NAND
> Flash Controller
> 
> On Thu, 15 Nov 2018 09:34:16 +
> Naga Sureshkumar Relli  wrote:
> 
> > Hi Boris & Miquel,
> >
> > I am updating the driver by addressing your comments, and I have one
> > concern,  especially in anfc_read_page_hwecc(), there I am checking for 
> > erased pages bit flips.
> > Since Arasan NAND controller doesn't have multibit error detection
> > beyond 24-bit( it can correct up to 24 bit), i.e. there is no indication 
> > from controller to detect
> uncorrectable error beyond 24bit.
> 
> Do you mean that you can't detect uncorrectable errors, or just that it's not 
> 100% sure to detect
> errors above max_strength?
Yes, in Arasan NAND controller there is no way to detect uncorrectable errors 
beyond 24-bit.
> 
> > So I took some error count as default value(MULTI_BIT_ERR_CNT  16, I
> > put this based on the error count that I got while reading erased page on 
> > Micron device).
> > And during a page read, will just read the error count register and
> > compare this value with the default error count(16) and if it is more Than 
> > default then I am
> checking for erased page bit flips.
> 
> Hm, that's wrong, especially if you set ecc_strength to something > 16.
Ok
> 
> > I am doubting that this will not work in all cases.
> 
> It definitely doesn't.
Ok
> 
> > In my case it is just working because the error count that it got on an 
> > erased page is 16.
> > Could you please suggest a way to do detect erased_page bit flips when 
> > reading a page with
> HW-ECC?.
> 
> I'm a bit lost. Is the problem only about bitflips in erase pages, or is it 
> also impacting reads of
> written pages that lead to uncorrectable errors.
Yes, it is for both. But in case of read errors that we can't detect beyond 
24-bit, then the answer from HW design team
Is that the flash part is bad.
Unfortunately till now we haven't ran into that situation(read errors of 
written pages beyond 24-bit).
But we are hitting this because of erased page reading(needed in case of ubifs).

> 
> Don't you have a bit (or several bits) reporting when the ECC engine was not 
> able to correct
> data? I you do, you should base the "detect bitflips in erase pages" logic on 
> this information.
Bit reporting for several bit errors is there only for Hamming(1bit correction 
and 2bit detection) but not in BCH.

Thanks,
Naga Sureshkumar Relli

Re: [RFC PATCH] zinc chacha20 generic implementation using crypto API code

[Jason A. Donenfeld]

Hi Herbert,

On Mon, Nov 19, 2018 at 6:25 AM Herbert Xu  wrote:
> My proposal is to merge the zinc interface as is, but to invert
> how we place the algorithm implementations.  IOW the implementations
> should stay where they are now, with in the crypto API.  However,
> we will provide direct access to them for zinc without going through
> the crypto API.  IOW we'll just export the functions directly.

Sorry, but there isn't a chance I'll agree to this. The whole idea is
to have a clean place to focus on synchronous software
implementations, and not keep it tangled up with the asynchronous API.
If WireGuard and Zinc go in, it's going to be done right, not in a way
that introduces more problems and organizational complexity. Avoiding
the solution proposed here is kind of the point. And given that
cryptographic code is so security sensitive, I want to make sure this
is done right, as opposed to rushing it with some half-baked
concoction that will be maybe possibly be replaced "later". From
talking to folks at Plumbers, I believe most of the remaining issues
are taken care of by the upcoming v9, and that you're overstating the
status of discussions regarding that.

I think the remaining issue right now is how to order my series and
Eric's series. If Eric's goes in first, it means that I can either a)
spend some time developing Zinc further _now_ to support chacha12 and
keep the top two conversion patches, or b) just drop the top two
conversion patches and work that out carefully with Eric after. I
think (b) would be better, but I'm happy to do (a) if you disagree.
And as I mentioned in the last email, I'd prefer Eric's work to go in
after Zinc, but I don't think the reasoning for that is particularly
strong, so it seems fine to merge Eric's work first.

I'll post v9 pretty soon and you can see how things are shaping up.
Hopefully before then Eric/Ard/you can provide some feedback on
whether you'd prefer (a) or (b) above.

Regards,
Jason

Re: [RFC PATCH] zinc chacha20 generic implementation using crypto API code

[Jason A. Donenfeld]

Hi Herbert,

On Mon, Nov 19, 2018 at 6:25 AM Herbert Xu  wrote:
> My proposal is to merge the zinc interface as is, but to invert
> how we place the algorithm implementations.  IOW the implementations
> should stay where they are now, with in the crypto API.  However,
> we will provide direct access to them for zinc without going through
> the crypto API.  IOW we'll just export the functions directly.

Sorry, but there isn't a chance I'll agree to this. The whole idea is
to have a clean place to focus on synchronous software
implementations, and not keep it tangled up with the asynchronous API.
If WireGuard and Zinc go in, it's going to be done right, not in a way
that introduces more problems and organizational complexity. Avoiding
the solution proposed here is kind of the point. And given that
cryptographic code is so security sensitive, I want to make sure this
is done right, as opposed to rushing it with some half-baked
concoction that will be maybe possibly be replaced "later". From
talking to folks at Plumbers, I believe most of the remaining issues
are taken care of by the upcoming v9, and that you're overstating the
status of discussions regarding that.

I think the remaining issue right now is how to order my series and
Eric's series. If Eric's goes in first, it means that I can either a)
spend some time developing Zinc further _now_ to support chacha12 and
keep the top two conversion patches, or b) just drop the top two
conversion patches and work that out carefully with Eric after. I
think (b) would be better, but I'm happy to do (a) if you disagree.
And as I mentioned in the last email, I'd prefer Eric's work to go in
after Zinc, but I don't think the reasoning for that is particularly
strong, so it seems fine to merge Eric's work first.

I'll post v9 pretty soon and you can see how things are shaping up.
Hopefully before then Eric/Ard/you can provide some feedback on
whether you'd prefer (a) or (b) above.

Regards,
Jason

[PATCH] iio: st_sensors: Fix the sleep time for sampling

[Jian-Hong Pan]

According to the description of st_sensor_settings and st_sensor_data
structures' comments:
- bootime: samples to discard when sensor passing from power-down to
power-up.
- odr: Output data rate of the sensor [Hz].

The sleep time should be
sdata->sensor_settings->bootime + 1000 / sdata->odr ms.

Signed-off-by: Jian-Hong Pan 
---
 drivers/iio/common/st_sensors/st_sensors_core.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/iio/common/st_sensors/st_sensors_core.c 
b/drivers/iio/common/st_sensors/st_sensors_core.c
index 26fbd1bd9413..6b87ea657a92 100644
--- a/drivers/iio/common/st_sensors/st_sensors_core.c
+++ b/drivers/iio/common/st_sensors/st_sensors_core.c
@@ -594,7 +594,7 @@ int st_sensors_read_info_raw(struct iio_dev *indio_dev,
if (err < 0)
goto out;
 
-   msleep((sdata->sensor_settings->bootime * 1000) / sdata->odr);
+   msleep(sdata->sensor_settings->bootime + 1000 / sdata->odr);
err = st_sensors_read_axis_data(indio_dev, ch, val);
if (err < 0)
goto out;
-- 
2.11.0

[PATCH] iio: st_sensors: Fix the sleep time for sampling

[Jian-Hong Pan]

According to the description of st_sensor_settings and st_sensor_data
structures' comments:
- bootime: samples to discard when sensor passing from power-down to
power-up.
- odr: Output data rate of the sensor [Hz].

The sleep time should be
sdata->sensor_settings->bootime + 1000 / sdata->odr ms.

Signed-off-by: Jian-Hong Pan 
---
 drivers/iio/common/st_sensors/st_sensors_core.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/iio/common/st_sensors/st_sensors_core.c 
b/drivers/iio/common/st_sensors/st_sensors_core.c
index 26fbd1bd9413..6b87ea657a92 100644
--- a/drivers/iio/common/st_sensors/st_sensors_core.c
+++ b/drivers/iio/common/st_sensors/st_sensors_core.c
@@ -594,7 +594,7 @@ int st_sensors_read_info_raw(struct iio_dev *indio_dev,
if (err < 0)
goto out;
 
-   msleep((sdata->sensor_settings->bootime * 1000) / sdata->odr);
+   msleep(sdata->sensor_settings->bootime + 1000 / sdata->odr);
err = st_sensors_read_axis_data(indio_dev, ch, val);
if (err < 0)
goto out;
-- 
2.11.0

Re: [PATCH v5 04/12] drm/mediatek: Add support for mmsys through a pdev

[CK Hu]

Hi, Matthias:

On Fri, 2018-11-16 at 13:54 +0100, matthias@kernel.org wrote:
> From: Matthias Brugger 
> 
> The MMSYS subsystem includes clocks and drm components.
> This patch adds an initailization path through a platform device
> for the clock part, so that both drivers get probed from the same
> device tree compatible.

Looks good to me except one coding style preference.

Reviewed-by: CK Hu 

> 
> Signed-off-by: Matthias Brugger 
> ---
>  drivers/gpu/drm/mediatek/mtk_drm_drv.c | 23 +++
>  drivers/gpu/drm/mediatek/mtk_drm_drv.h |  2 ++
>  2 files changed, 25 insertions(+)
> 
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c 
> b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> index 99dd612a6683..18fc761ba94f 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> @@ -199,6 +199,7 @@ static const struct mtk_mmsys_driver_data 
> mt2701_mmsys_driver_data = {
>   .ext_path = mt2701_mtk_ddp_ext,
>   .ext_len = ARRAY_SIZE(mt2701_mtk_ddp_ext),
>   .shadow_register = true,
> + .clk_drv_name = "clk-mt2701-mm",
>  };
>  
>  static const struct mtk_mmsys_driver_data mt2712_mmsys_driver_data = {
> @@ -215,6 +216,7 @@ static const struct mtk_mmsys_driver_data 
> mt8173_mmsys_driver_data = {
>   .main_len = ARRAY_SIZE(mt8173_mtk_ddp_main),
>   .ext_path = mt8173_mtk_ddp_ext,
>   .ext_len = ARRAY_SIZE(mt8173_mtk_ddp_ext),
> + .clk_drv_name = "clk-mt8173-mm",
>  };
>  
>  static int mtk_drm_kms_init(struct drm_device *drm)
> @@ -473,6 +475,24 @@ static int mtk_drm_probe(struct platform_device *pdev)
>   if (IS_ERR(private->config_regs))
>   return PTR_ERR(private->config_regs);
>  
> + /*
> +  * For legacy reasons we need to probe the clock driver via
> +  * a platfomr device. This is outdated and should not be used
> +  * in newer SoCs.
> +  */
> + if (private->data->clk_drv_name) {
> + private->clk_dev = platform_device_register_data(dev,
> + private->data->clk_drv_name, -1,
> + NULL, 0);
> +
> + if (IS_ERR(private->clk_dev)) {
> + pr_err("failed to register %s platform device\n",
> + private->data->clk_drv_name);

I would like to align to the right of '('.

Regards,
CK

> +
> + return PTR_ERR(private->clk_dev);
> + }
> + }
> +
>   /* Iterate over sibling DISP function blocks */
>   for_each_child_of_node(dev->of_node->parent, node) {
>   const struct of_device_id *of_id;
> @@ -577,6 +597,9 @@ static int mtk_drm_remove(struct platform_device *pdev)
>   for (i = 0; i < DDP_COMPONENT_ID_MAX; i++)
>   of_node_put(private->comp_node[i]);
>  
> + if (private->clk_dev)
> + platform_device_unregister(private->clk_dev);
> +
>   return 0;
>  }
>  
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.h 
> b/drivers/gpu/drm/mediatek/mtk_drm_drv.h
> index ab0adbd7d4ee..515ac4cae922 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_drv.h
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.h
> @@ -37,11 +37,13 @@ struct mtk_mmsys_driver_data {
>   unsigned int third_len;
>  
>   bool shadow_register;
> + const char *clk_drv_name;
>  };
>  
>  struct mtk_drm_private {
>   struct drm_device *drm;
>   struct device *dma_dev;
> + struct platform_device *clk_dev;
>  
>   unsigned int num_pipes;
>  

Re: [PATCH v5 04/12] drm/mediatek: Add support for mmsys through a pdev

[CK Hu]

Hi, Matthias:

On Fri, 2018-11-16 at 13:54 +0100, matthias@kernel.org wrote:
> From: Matthias Brugger 
> 
> The MMSYS subsystem includes clocks and drm components.
> This patch adds an initailization path through a platform device
> for the clock part, so that both drivers get probed from the same
> device tree compatible.

Looks good to me except one coding style preference.

Reviewed-by: CK Hu 

> 
> Signed-off-by: Matthias Brugger 
> ---
>  drivers/gpu/drm/mediatek/mtk_drm_drv.c | 23 +++
>  drivers/gpu/drm/mediatek/mtk_drm_drv.h |  2 ++
>  2 files changed, 25 insertions(+)
> 
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c 
> b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> index 99dd612a6683..18fc761ba94f 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> @@ -199,6 +199,7 @@ static const struct mtk_mmsys_driver_data 
> mt2701_mmsys_driver_data = {
>   .ext_path = mt2701_mtk_ddp_ext,
>   .ext_len = ARRAY_SIZE(mt2701_mtk_ddp_ext),
>   .shadow_register = true,
> + .clk_drv_name = "clk-mt2701-mm",
>  };
>  
>  static const struct mtk_mmsys_driver_data mt2712_mmsys_driver_data = {
> @@ -215,6 +216,7 @@ static const struct mtk_mmsys_driver_data 
> mt8173_mmsys_driver_data = {
>   .main_len = ARRAY_SIZE(mt8173_mtk_ddp_main),
>   .ext_path = mt8173_mtk_ddp_ext,
>   .ext_len = ARRAY_SIZE(mt8173_mtk_ddp_ext),
> + .clk_drv_name = "clk-mt8173-mm",
>  };
>  
>  static int mtk_drm_kms_init(struct drm_device *drm)
> @@ -473,6 +475,24 @@ static int mtk_drm_probe(struct platform_device *pdev)
>   if (IS_ERR(private->config_regs))
>   return PTR_ERR(private->config_regs);
>  
> + /*
> +  * For legacy reasons we need to probe the clock driver via
> +  * a platfomr device. This is outdated and should not be used
> +  * in newer SoCs.
> +  */
> + if (private->data->clk_drv_name) {
> + private->clk_dev = platform_device_register_data(dev,
> + private->data->clk_drv_name, -1,
> + NULL, 0);
> +
> + if (IS_ERR(private->clk_dev)) {
> + pr_err("failed to register %s platform device\n",
> + private->data->clk_drv_name);

I would like to align to the right of '('.

Regards,
CK

> +
> + return PTR_ERR(private->clk_dev);
> + }
> + }
> +
>   /* Iterate over sibling DISP function blocks */
>   for_each_child_of_node(dev->of_node->parent, node) {
>   const struct of_device_id *of_id;
> @@ -577,6 +597,9 @@ static int mtk_drm_remove(struct platform_device *pdev)
>   for (i = 0; i < DDP_COMPONENT_ID_MAX; i++)
>   of_node_put(private->comp_node[i]);
>  
> + if (private->clk_dev)
> + platform_device_unregister(private->clk_dev);
> +
>   return 0;
>  }
>  
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.h 
> b/drivers/gpu/drm/mediatek/mtk_drm_drv.h
> index ab0adbd7d4ee..515ac4cae922 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_drv.h
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.h
> @@ -37,11 +37,13 @@ struct mtk_mmsys_driver_data {
>   unsigned int third_len;
>  
>   bool shadow_register;
> + const char *clk_drv_name;
>  };
>  
>  struct mtk_drm_private {
>   struct drm_device *drm;
>   struct device *dma_dev;
> + struct platform_device *clk_dev;
>  
>   unsigned int num_pipes;
>  

linux-next: Tree for Nov 19

[Stephen Rothwell]

Hi all,

Changes since 20181116:

Removed trees:  (not updated in more that a year)
aio, drm-panel, edac, idle, keys, kvm-mips, lightnvm,
nand-fixes, realtek, sunxi-drm, uuid, vfs-miklos

The tip tree still had its build failure for which I applied a fix patch.

The akpm tree lost a patch that turned up elsewhere.

Non-merge commits (relative to Linus' tree): 3389
 3518 files changed, 137024 insertions(+), 108059 deletions(-)



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

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

Below is a summary of the state of the merge.

I am currently merging 286 trees (counting Linus' and 67 trees of bug
fix patches pending for the current merge release).

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

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

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

-- 
Cheers,
Stephen Rothwell

$ git checkout master
$ git reset --hard stable
Merging origin/master (9ff01193a20d Linux 4.20-rc3)
Merging fixes/master (7c6c54b505b8 Merge branch 'i2c/for-next' of 
git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux)
Merging kbuild-current/fixes (ccda4af0f4b9 Linux 4.20-rc2)
Merging arc-current/for-curr (121e38e5acdc ARC: mm: fix uninitialised signal 
code in do_page_fault)
Merging arm-current/fixes (e46daee53bb5 ARM: 8806/1: kprobes: Fix false 
positive with FORTIFY_SOURCE)
Merging arm64-fixes/for-next/fixes (24cc61d8cb5a arm64: memblock: don't permit 
memblock resizing until linear mapping is up)
Merging m68k-current/for-linus (58c116fb7dc6 m68k/sun3: Remove is_medusa and 
m68k_pgtable_cachemode)
Merging powerpc-fixes/fixes (b2fed34a628d selftests/powerpc: Adjust wild_bctr 
to build with old binutils)
Merging sparc/master (25e19c1fe421 Merge tag 'libnvdimm-fixes-4.20-rc3' of 
git://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm)
Merging fscrypt-current/for-stable (ae64f9bd1d36 Linux 4.15-rc2)
Merging net/master (1c1274a56999 tipc: don't assume linear buffer when reading 
ancillary data)
Merging bpf/master (569a933b03f3 bpf: allocate local storage buffers using 
GFP_ATOMIC)
Merging ipsec/master (ca92e173ab34 xfrm: Fix bucket count reported to userspace)
Merging netfilter/master (38d37baa8123 ipvs: call ip_vs_dst_notifier earlier 
than ipv6_dev_notf)
Merging ipvs/master (feb9f55c33e5 netfilter: nft_dynset: allow dynamic updates 
of non-anonymous set)
Merging wireless-drivers/master (1770f0fa978e mt76: fix uninitialized mutex 
access setting rts threshold)
Merging mac80211/master (113f3aaa81bd cfg80211: Prevent regulatory restore 
during STA disconnect in concurrent interfaces)
Merging rdma-fixes/for-rc (99b77fef3c6c net/mlx5: Fix XRC SRQ umem valid bits)
Merging sound-current/for-linus (d99501b8575d ALSA: hda/ca0132 - Call 
pci_iounmap() instead of iounmap())
Merging sound-asoc-fixes/for-linus (f75d53d33907 Merge branch 'asoc-4.20' into 
asoc-linus)
Merging regmap-fixes/for-linus (ccda4af0f4b9 Linux 4.20-rc2)
Merging regulator-fixes/for-linus (6b46411b9ed3 Merge branch 'regulator-4.20' 
into regulator-linus)
Merging spi-fixes/for-linus (5dbff5ab4135 Merge branch 'spi-4.20' into 
spi-linus)
Merging pci-current/for-linus (1a87119b7bcf Revert "ACPI/PCI: Pay attention to 
device-specific _PXM node values")
Merging driver-core.current/driver-core-linus (a66d972465d1 devres: Align 
data[] to ARCH_KMALLOC_MINALIGN)
Merging tty.current/tty-linus (ccda4af0f4b9 Linux 4.20-rc2)
Merging usb.current/usb-linus (2f31a67f01a8 usb: xhci: Prevent bus suspend if a 
port connect change or polling state is detected)
Merging usb-gadget-fixes/fixes (2fc6d4be35fb usb: dwc3: gadget: fix ISOC TRB 
type on unaligned transfers)
Merging 

linux-next: Tree for Nov 19

[Stephen Rothwell]

Hi all,

Changes since 20181116:

Removed trees:  (not updated in more that a year)
aio, drm-panel, edac, idle, keys, kvm-mips, lightnvm,
nand-fixes, realtek, sunxi-drm, uuid, vfs-miklos

The tip tree still had its build failure for which I applied a fix patch.

The akpm tree lost a patch that turned up elsewhere.

Non-merge commits (relative to Linus' tree): 3389
 3518 files changed, 137024 insertions(+), 108059 deletions(-)



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

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

Below is a summary of the state of the merge.

I am currently merging 286 trees (counting Linus' and 67 trees of bug
fix patches pending for the current merge release).

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

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

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

-- 
Cheers,
Stephen Rothwell

$ git checkout master
$ git reset --hard stable
Merging origin/master (9ff01193a20d Linux 4.20-rc3)
Merging fixes/master (7c6c54b505b8 Merge branch 'i2c/for-next' of 
git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux)
Merging kbuild-current/fixes (ccda4af0f4b9 Linux 4.20-rc2)
Merging arc-current/for-curr (121e38e5acdc ARC: mm: fix uninitialised signal 
code in do_page_fault)
Merging arm-current/fixes (e46daee53bb5 ARM: 8806/1: kprobes: Fix false 
positive with FORTIFY_SOURCE)
Merging arm64-fixes/for-next/fixes (24cc61d8cb5a arm64: memblock: don't permit 
memblock resizing until linear mapping is up)
Merging m68k-current/for-linus (58c116fb7dc6 m68k/sun3: Remove is_medusa and 
m68k_pgtable_cachemode)
Merging powerpc-fixes/fixes (b2fed34a628d selftests/powerpc: Adjust wild_bctr 
to build with old binutils)
Merging sparc/master (25e19c1fe421 Merge tag 'libnvdimm-fixes-4.20-rc3' of 
git://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm)
Merging fscrypt-current/for-stable (ae64f9bd1d36 Linux 4.15-rc2)
Merging net/master (1c1274a56999 tipc: don't assume linear buffer when reading 
ancillary data)
Merging bpf/master (569a933b03f3 bpf: allocate local storage buffers using 
GFP_ATOMIC)
Merging ipsec/master (ca92e173ab34 xfrm: Fix bucket count reported to userspace)
Merging netfilter/master (38d37baa8123 ipvs: call ip_vs_dst_notifier earlier 
than ipv6_dev_notf)
Merging ipvs/master (feb9f55c33e5 netfilter: nft_dynset: allow dynamic updates 
of non-anonymous set)
Merging wireless-drivers/master (1770f0fa978e mt76: fix uninitialized mutex 
access setting rts threshold)
Merging mac80211/master (113f3aaa81bd cfg80211: Prevent regulatory restore 
during STA disconnect in concurrent interfaces)
Merging rdma-fixes/for-rc (99b77fef3c6c net/mlx5: Fix XRC SRQ umem valid bits)
Merging sound-current/for-linus (d99501b8575d ALSA: hda/ca0132 - Call 
pci_iounmap() instead of iounmap())
Merging sound-asoc-fixes/for-linus (f75d53d33907 Merge branch 'asoc-4.20' into 
asoc-linus)
Merging regmap-fixes/for-linus (ccda4af0f4b9 Linux 4.20-rc2)
Merging regulator-fixes/for-linus (6b46411b9ed3 Merge branch 'regulator-4.20' 
into regulator-linus)
Merging spi-fixes/for-linus (5dbff5ab4135 Merge branch 'spi-4.20' into 
spi-linus)
Merging pci-current/for-linus (1a87119b7bcf Revert "ACPI/PCI: Pay attention to 
device-specific _PXM node values")
Merging driver-core.current/driver-core-linus (a66d972465d1 devres: Align 
data[] to ARCH_KMALLOC_MINALIGN)
Merging tty.current/tty-linus (ccda4af0f4b9 Linux 4.20-rc2)
Merging usb.current/usb-linus (2f31a67f01a8 usb: xhci: Prevent bus suspend if a 
port connect change or polling state is detected)
Merging usb-gadget-fixes/fixes (2fc6d4be35fb usb: dwc3: gadget: fix ISOC TRB 
type on unaligned transfers)
Merging 

Re: [PATCH 0/7] ACPI HMAT memory sysfs representation

[Anshuman Khandual]

On 11/16/2018 10:25 PM, Dave Hansen wrote:
> On 11/15/18 10:27 PM, Anshuman Khandual wrote:
>> Not able to see the patches from this series either on the list or on the
>> archive (https://lkml.org/lkml/2018/11/15/331). IIRC last time we discussed
>> about this and the concern which I raised was in absence of a broader NUMA
>> rework for multi attribute memory it might not a good idea to settle down
>> and freeze sysfs interface for the user space. 
> 

Hello Dave,

> This *is* the broader NUMA rework.  I think it's just a bit more
> incremental that what you originally had in mind.

IIUC NUMA re-work in principle involves these functional changes

1. Enumerating compute and memory nodes in heterogeneous environment 
(short/medium term)
2. Enumerating memory node attributes as seen from the compute nodes 
(short/medium term)
3. Changing core MM to accommodate multi attribute memory (long term)

The first two set of changes can get the user space applications
moving by identifying the right nodes and their attributes through
sysfs interface.

> 
> Did you have an alternative for how you wanted this to look?
> 

No. I did not get enough time this year to rework on the original
proposal I had. But will be able to help here to make this interface
more generic, abstract out these properties which is extensible in
the future.

- Anshuman

Re: [PATCH 0/7] ACPI HMAT memory sysfs representation

[Anshuman Khandual]

On 11/16/2018 10:25 PM, Dave Hansen wrote:
> On 11/15/18 10:27 PM, Anshuman Khandual wrote:
>> Not able to see the patches from this series either on the list or on the
>> archive (https://lkml.org/lkml/2018/11/15/331). IIRC last time we discussed
>> about this and the concern which I raised was in absence of a broader NUMA
>> rework for multi attribute memory it might not a good idea to settle down
>> and freeze sysfs interface for the user space. 
> 

Hello Dave,

> This *is* the broader NUMA rework.  I think it's just a bit more
> incremental that what you originally had in mind.

IIUC NUMA re-work in principle involves these functional changes

1. Enumerating compute and memory nodes in heterogeneous environment 
(short/medium term)
2. Enumerating memory node attributes as seen from the compute nodes 
(short/medium term)
3. Changing core MM to accommodate multi attribute memory (long term)

The first two set of changes can get the user space applications
moving by identifying the right nodes and their attributes through
sysfs interface.

> 
> Did you have an alternative for how you wanted this to look?
> 

No. I did not get enough time this year to rework on the original
proposal I had. But will be able to help here to make this interface
more generic, abstract out these properties which is extensible in
the future.

- Anshuman

[PATCH v1 2/2]: Documentation/admin-guide: introduce perf-security.rst file

[Alexey Budankov]

Implement initial version of perf-security.rst documentation file 
initially covering security concerns related to PCL/Perf performance 
monitoring in multiuser environments.

Suggested-by: Thomas Gleixner 
Signed-off-by: Alexey Budankov 
---
 Documentation/admin-guide/perf-security.rst | 83 +
 1 file changed, 83 insertions(+)

diff --git a/Documentation/admin-guide/perf-security.rst 
b/Documentation/admin-guide/perf-security.rst
new file mode 100644
index ..b9564066e686
--- /dev/null
+++ b/Documentation/admin-guide/perf-security.rst
@@ -0,0 +1,83 @@
+.. _perf_security:
+
+PCL/Perf security
+=
+
+Overview
+
+
+Usage of Performance Counters for Linux (PCL) [1]_ , [2]_ , [3]_ can impose a
+considerable risk of leaking sensitive data accessed by monitored processes.
+The data leakage is possible both in scenarios of direct usage of PCL system
+call API [2]_ and over data files generated by Perf tool user mode utility
+(Perf) [3]_ , [4]_ . The risk depends on the nature of data that PCL 
performance
+monitoring units (PMU) [2]_ collect and expose for performance analysis.
+Having that said PCL/Perf performance monitoring is the subject for security
+access control management [5]_ .
+
+PCL/Perf access control
+---
+
+For the purpose of performing security checks Linux implementation splits
+processes into two categories [6]_ : a) privileged processes (whose effective
+user ID is 0, referred to as superuser or root), and b) unprivileged processes
+(whose effective UID is nonzero). Privileged processes bypass all kernel
+security permission checks so PCL performance monitoring is fully available to
+privileged processes without *access*, *scope* and *resource* restrictions.
+Unprivileged processes are subject to full security permission check based
+on the process's credentials [5]_ (usually: effective UID, effective GID,
+and supplementary group list).
+
+PCL/Perf unprivileged users
+---
+
+PCL/Perf *scope* and *access* control for unprivileged processes is governed by
+perf_event_paranoid [2]_ setting:
+
+**-1**:
+ Impose no *scope* and *access* restrictions on using PCL performance
+ monitoring. Per-user per-cpu perf_event_mlock_kb [2]_ locking limit is
+ ignored when allocating memory buffers for storing performance data.
+ This is the least secure mode since allowed monitored *scope* is
+ maximized and no PCL specific limits are imposed on *resources*
+ allocated for performance monitoring.
+
+**>=0**:
+ *scope* includes per-process and system wide performance monitoring
+ but excludes raw tracepoints and ftrace function tracepoints monitoring.
+ CPU and system events happened when executing either in user or
+ in kernel space can be monitored and captured for later analysis.
+ Per-user per-cpu perf_event_mlock_kb locking limit is imposed but
+ ignored for unprivileged processes with CAP_IPC_LOCK [6]_ capability.
+
+**>=1**:
+ *scope* includes per-process performance monitoring only and excludes
+ system wide performance monitoring. CPU and system events happened when
+ executing either in user or in kernel space can be monitored and
+ captured for later analysis. Per-user per-cpu perf_event_mlock_kb
+ locking limit is imposed but ignored for unprivileged processes with
+ CAP_IPC_LOCK capability.
+
+**>=2**:
+ *scope* includes per-process performance monitoring only. CPU and system
+ events happened when executing in user space only can be monitored and
+ captured for later analysis. Per-user per-cpu perf_event_mlock_kb
+ locking limit is imposed but ignored for unprivileged processes with
+ CAP_IPC_LOCK capability.
+
+**>=3**:
+ Restrict *access* to PCL performance monitoring for unprivileged 
processes.
+ This is the default on Debian and Android [7]_ , [8]_ .
+
+Bibliography
+
+
+.. [1] ``_
+.. [2] ``_
+.. [3] ``_
+.. [4] ``_
+.. [5] ``_
+.. [6] ``_
+.. [7] ``_
+.. [8] ``_
+

[PATCH v1 2/2]: Documentation/admin-guide: introduce perf-security.rst file

[Alexey Budankov]

Implement initial version of perf-security.rst documentation file 
initially covering security concerns related to PCL/Perf performance 
monitoring in multiuser environments.

Suggested-by: Thomas Gleixner 
Signed-off-by: Alexey Budankov 
---
 Documentation/admin-guide/perf-security.rst | 83 +
 1 file changed, 83 insertions(+)

diff --git a/Documentation/admin-guide/perf-security.rst 
b/Documentation/admin-guide/perf-security.rst
new file mode 100644
index ..b9564066e686
--- /dev/null
+++ b/Documentation/admin-guide/perf-security.rst
@@ -0,0 +1,83 @@
+.. _perf_security:
+
+PCL/Perf security
+=
+
+Overview
+
+
+Usage of Performance Counters for Linux (PCL) [1]_ , [2]_ , [3]_ can impose a
+considerable risk of leaking sensitive data accessed by monitored processes.
+The data leakage is possible both in scenarios of direct usage of PCL system
+call API [2]_ and over data files generated by Perf tool user mode utility
+(Perf) [3]_ , [4]_ . The risk depends on the nature of data that PCL 
performance
+monitoring units (PMU) [2]_ collect and expose for performance analysis.
+Having that said PCL/Perf performance monitoring is the subject for security
+access control management [5]_ .
+
+PCL/Perf access control
+---
+
+For the purpose of performing security checks Linux implementation splits
+processes into two categories [6]_ : a) privileged processes (whose effective
+user ID is 0, referred to as superuser or root), and b) unprivileged processes
+(whose effective UID is nonzero). Privileged processes bypass all kernel
+security permission checks so PCL performance monitoring is fully available to
+privileged processes without *access*, *scope* and *resource* restrictions.
+Unprivileged processes are subject to full security permission check based
+on the process's credentials [5]_ (usually: effective UID, effective GID,
+and supplementary group list).
+
+PCL/Perf unprivileged users
+---
+
+PCL/Perf *scope* and *access* control for unprivileged processes is governed by
+perf_event_paranoid [2]_ setting:
+
+**-1**:
+ Impose no *scope* and *access* restrictions on using PCL performance
+ monitoring. Per-user per-cpu perf_event_mlock_kb [2]_ locking limit is
+ ignored when allocating memory buffers for storing performance data.
+ This is the least secure mode since allowed monitored *scope* is
+ maximized and no PCL specific limits are imposed on *resources*
+ allocated for performance monitoring.
+
+**>=0**:
+ *scope* includes per-process and system wide performance monitoring
+ but excludes raw tracepoints and ftrace function tracepoints monitoring.
+ CPU and system events happened when executing either in user or
+ in kernel space can be monitored and captured for later analysis.
+ Per-user per-cpu perf_event_mlock_kb locking limit is imposed but
+ ignored for unprivileged processes with CAP_IPC_LOCK [6]_ capability.
+
+**>=1**:
+ *scope* includes per-process performance monitoring only and excludes
+ system wide performance monitoring. CPU and system events happened when
+ executing either in user or in kernel space can be monitored and
+ captured for later analysis. Per-user per-cpu perf_event_mlock_kb
+ locking limit is imposed but ignored for unprivileged processes with
+ CAP_IPC_LOCK capability.
+
+**>=2**:
+ *scope* includes per-process performance monitoring only. CPU and system
+ events happened when executing in user space only can be monitored and
+ captured for later analysis. Per-user per-cpu perf_event_mlock_kb
+ locking limit is imposed but ignored for unprivileged processes with
+ CAP_IPC_LOCK capability.
+
+**>=3**:
+ Restrict *access* to PCL performance monitoring for unprivileged 
processes.
+ This is the default on Debian and Android [7]_ , [8]_ .
+
+Bibliography
+
+
+.. [1] ``_
+.. [2] ``_
+.. [3] ``_
+.. [4] ``_
+.. [5] ``_
+.. [6] ``_
+.. [7] ``_
+.. [8] ``_
+

[PATCH v1 1/2]: Documentation/admin-guide: update admin-guide index.rst

[Alexey Budankov]

Extend index.rst index file at admin-guide root directory with 
the reference to perf-security.rst file being introduced.

Signed-off-by: Alexey Budankov 
---
 Documentation/admin-guide/index.rst | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/admin-guide/index.rst 
b/Documentation/admin-guide/index.rst
index 0873685bab0f..885cc0de9114 100644
--- a/Documentation/admin-guide/index.rst
+++ b/Documentation/admin-guide/index.rst
@@ -75,6 +75,7 @@ configure specific aspects of kernel behavior to your liking.
thunderbolt
LSM/index
mm/index
+   perf-security
 
 .. only::  subproject and html

[PATCH v1 1/2]: Documentation/admin-guide: update admin-guide index.rst

[Alexey Budankov]

Extend index.rst index file at admin-guide root directory with 
the reference to perf-security.rst file being introduced.

Signed-off-by: Alexey Budankov 
---
 Documentation/admin-guide/index.rst | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/admin-guide/index.rst 
b/Documentation/admin-guide/index.rst
index 0873685bab0f..885cc0de9114 100644
--- a/Documentation/admin-guide/index.rst
+++ b/Documentation/admin-guide/index.rst
@@ -75,6 +75,7 @@ configure specific aspects of kernel behavior to your liking.
thunderbolt
LSM/index
mm/index
+   perf-security
 
 .. only::  subproject and html

Re: [PATCH v5 05/12] drm: mediatek: Omit warning on probe defers

[CK Hu]

Hi, Matthias:

On Fri, 2018-11-16 at 13:54 +0100, matthias@kernel.org wrote:
> From: Matthias Brugger 
> 
> It can happen that the mmsys clock drivers aren't probed before the
> platform driver gets invoked. The platform driver used to print a warning
> that the driver failed to get the clocks. Omit this error on
> the defered probe path.

This patch looks good to me, but you have not modified the sub driver in
HDMI path. We could let HDMI path print the warning and someone send
another patch later, or you modify for HDMI path in this patch.
> 
> Signed-off-by: Matthias Brugger 
> ---
>  drivers/gpu/drm/mediatek/mtk_disp_color.c | 4 +++-
>  drivers/gpu/drm/mediatek/mtk_disp_ovl.c   | 4 +++-
>  drivers/gpu/drm/mediatek/mtk_disp_rdma.c  | 4 +++-
>  drivers/gpu/drm/mediatek/mtk_drm_ddp.c| 3 ++-
>  drivers/gpu/drm/mediatek/mtk_dsi.c| 6 --
>  5 files changed, 15 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/gpu/drm/mediatek/mtk_disp_color.c 
> b/drivers/gpu/drm/mediatek/mtk_disp_color.c
> index f609b62b8be6..1ea3178d4c18 100644
> --- a/drivers/gpu/drm/mediatek/mtk_disp_color.c
> +++ b/drivers/gpu/drm/mediatek/mtk_disp_color.c
> @@ -126,7 +126,9 @@ static int mtk_disp_color_probe(struct platform_device 
> *pdev)
>   ret = mtk_ddp_comp_init(dev, dev->of_node, >ddp_comp, comp_id,
>   _disp_color_funcs);
>   if (ret) {
> - dev_err(dev, "Failed to initialize component: %d\n", ret);
> + if (ret != -EPROBE_DEFER)
> + dev_err(dev, "Failed to initialize component: %d\n",
> + ret);

I would like one more blank line here.

>   return ret;
>   }
>  
> diff --git a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c 
> b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
> index 28d191192945..5ebbcaa4e70e 100644
> --- a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
> +++ b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
> @@ -293,7 +293,9 @@ static int mtk_disp_ovl_probe(struct platform_device 
> *pdev)
>   ret = mtk_ddp_comp_init(dev, dev->of_node, >ddp_comp, comp_id,
>   _disp_ovl_funcs);
>   if (ret) {
> - dev_err(dev, "Failed to initialize component: %d\n", ret);
> + if (ret != -EPROBE_DEFER)
> + dev_err(dev, "Failed to initialize component: %d\n",
> + ret);

I would like to align to the right of '('.

Regards,
CK

>   return ret;
>   }
>  
> diff --git a/drivers/gpu/drm/mediatek/mtk_disp_rdma.c 
> b/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
> index b0a5cffe345a..59a08ed5fea5 100644
> --- a/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
> +++ b/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
> @@ -295,7 +295,9 @@ static int mtk_disp_rdma_probe(struct platform_device 
> *pdev)
>   ret = mtk_ddp_comp_init(dev, dev->of_node, >ddp_comp, comp_id,
>   _disp_rdma_funcs);
>   if (ret) {
> - dev_err(dev, "Failed to initialize component: %d\n", ret);
> + if (ret != -EPROBE_DEFER)
> + dev_err(dev, "Failed to initialize component: %d\n",
> + ret);
>   return ret;
>   }
>  
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c 
> b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> index b06cd9d4b525..b76a2d071a97 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> @@ -566,7 +566,8 @@ static int mtk_ddp_probe(struct platform_device *pdev)
>  
>   ddp->clk = devm_clk_get(dev, NULL);
>   if (IS_ERR(ddp->clk)) {
> - dev_err(dev, "Failed to get clock\n");
> + if (PTR_ERR(ddp->clk) != -EPROBE_DEFER)
> + dev_err(dev, "Failed to get clock\n");
>   return PTR_ERR(ddp->clk);
>   }
>  
> diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c 
> b/drivers/gpu/drm/mediatek/mtk_dsi.c
> index 90109a0d6fff..cc6de75636c3 100644
> --- a/drivers/gpu/drm/mediatek/mtk_dsi.c
> +++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
> @@ -1103,14 +1103,16 @@ static int mtk_dsi_probe(struct platform_device *pdev)
>   dsi->engine_clk = devm_clk_get(dev, "engine");
>   if (IS_ERR(dsi->engine_clk)) {
>   ret = PTR_ERR(dsi->engine_clk);
> - dev_err(dev, "Failed to get engine clock: %d\n", ret);
> + if (ret != -EPROBE_DEFER)
> + dev_err(dev, "Failed to get engine clock: %d\n", ret);
>   return ret;
>   }
>  
>   dsi->digital_clk = devm_clk_get(dev, "digital");
>   if (IS_ERR(dsi->digital_clk)) {
>   ret = PTR_ERR(dsi->digital_clk);
> - dev_err(dev, "Failed to get digital clock: %d\n", ret);
> + if (ret != -EPROBE_DEFER)
> + dev_err(dev, "Failed to get digital clock: %d\n", ret);
>   return ret;
>   }
>  

Re: [PATCH v5 05/12] drm: mediatek: Omit warning on probe defers

[CK Hu]

Hi, Matthias:

On Fri, 2018-11-16 at 13:54 +0100, matthias@kernel.org wrote:
> From: Matthias Brugger 
> 
> It can happen that the mmsys clock drivers aren't probed before the
> platform driver gets invoked. The platform driver used to print a warning
> that the driver failed to get the clocks. Omit this error on
> the defered probe path.

This patch looks good to me, but you have not modified the sub driver in
HDMI path. We could let HDMI path print the warning and someone send
another patch later, or you modify for HDMI path in this patch.
> 
> Signed-off-by: Matthias Brugger 
> ---
>  drivers/gpu/drm/mediatek/mtk_disp_color.c | 4 +++-
>  drivers/gpu/drm/mediatek/mtk_disp_ovl.c   | 4 +++-
>  drivers/gpu/drm/mediatek/mtk_disp_rdma.c  | 4 +++-
>  drivers/gpu/drm/mediatek/mtk_drm_ddp.c| 3 ++-
>  drivers/gpu/drm/mediatek/mtk_dsi.c| 6 --
>  5 files changed, 15 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/gpu/drm/mediatek/mtk_disp_color.c 
> b/drivers/gpu/drm/mediatek/mtk_disp_color.c
> index f609b62b8be6..1ea3178d4c18 100644
> --- a/drivers/gpu/drm/mediatek/mtk_disp_color.c
> +++ b/drivers/gpu/drm/mediatek/mtk_disp_color.c
> @@ -126,7 +126,9 @@ static int mtk_disp_color_probe(struct platform_device 
> *pdev)
>   ret = mtk_ddp_comp_init(dev, dev->of_node, >ddp_comp, comp_id,
>   _disp_color_funcs);
>   if (ret) {
> - dev_err(dev, "Failed to initialize component: %d\n", ret);
> + if (ret != -EPROBE_DEFER)
> + dev_err(dev, "Failed to initialize component: %d\n",
> + ret);

I would like one more blank line here.

>   return ret;
>   }
>  
> diff --git a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c 
> b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
> index 28d191192945..5ebbcaa4e70e 100644
> --- a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
> +++ b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
> @@ -293,7 +293,9 @@ static int mtk_disp_ovl_probe(struct platform_device 
> *pdev)
>   ret = mtk_ddp_comp_init(dev, dev->of_node, >ddp_comp, comp_id,
>   _disp_ovl_funcs);
>   if (ret) {
> - dev_err(dev, "Failed to initialize component: %d\n", ret);
> + if (ret != -EPROBE_DEFER)
> + dev_err(dev, "Failed to initialize component: %d\n",
> + ret);

I would like to align to the right of '('.

Regards,
CK

>   return ret;
>   }
>  
> diff --git a/drivers/gpu/drm/mediatek/mtk_disp_rdma.c 
> b/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
> index b0a5cffe345a..59a08ed5fea5 100644
> --- a/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
> +++ b/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
> @@ -295,7 +295,9 @@ static int mtk_disp_rdma_probe(struct platform_device 
> *pdev)
>   ret = mtk_ddp_comp_init(dev, dev->of_node, >ddp_comp, comp_id,
>   _disp_rdma_funcs);
>   if (ret) {
> - dev_err(dev, "Failed to initialize component: %d\n", ret);
> + if (ret != -EPROBE_DEFER)
> + dev_err(dev, "Failed to initialize component: %d\n",
> + ret);
>   return ret;
>   }
>  
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c 
> b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> index b06cd9d4b525..b76a2d071a97 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> @@ -566,7 +566,8 @@ static int mtk_ddp_probe(struct platform_device *pdev)
>  
>   ddp->clk = devm_clk_get(dev, NULL);
>   if (IS_ERR(ddp->clk)) {
> - dev_err(dev, "Failed to get clock\n");
> + if (PTR_ERR(ddp->clk) != -EPROBE_DEFER)
> + dev_err(dev, "Failed to get clock\n");
>   return PTR_ERR(ddp->clk);
>   }
>  
> diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c 
> b/drivers/gpu/drm/mediatek/mtk_dsi.c
> index 90109a0d6fff..cc6de75636c3 100644
> --- a/drivers/gpu/drm/mediatek/mtk_dsi.c
> +++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
> @@ -1103,14 +1103,16 @@ static int mtk_dsi_probe(struct platform_device *pdev)
>   dsi->engine_clk = devm_clk_get(dev, "engine");
>   if (IS_ERR(dsi->engine_clk)) {
>   ret = PTR_ERR(dsi->engine_clk);
> - dev_err(dev, "Failed to get engine clock: %d\n", ret);
> + if (ret != -EPROBE_DEFER)
> + dev_err(dev, "Failed to get engine clock: %d\n", ret);
>   return ret;
>   }
>  
>   dsi->digital_clk = devm_clk_get(dev, "digital");
>   if (IS_ERR(dsi->digital_clk)) {
>   ret = PTR_ERR(dsi->digital_clk);
> - dev_err(dev, "Failed to get digital clock: %d\n", ret);
> + if (ret != -EPROBE_DEFER)
> + dev_err(dev, "Failed to get digital clock: %d\n", ret);
>   return ret;
>   }
>  

[PATCH v1 0/2]: Documentation/admin-guide: introduce perf-security.rst file and extend perf_event_paranoid documentation

[Alexey Budankov]

To facilitate informed decision making by system administrators [1]
to permit and manage access to PCL/Perf [2],[3] performance monitoring 
for multiple users perf-security.rst document suggested by Thomas Gleixner 
is introduced [4] that:

a) states PCL/Perf access security concerns for multi user environment
b) refers to base Linux access control and management principles
c) extends documentation of possible perf_event_paranoid knob settings 

The file serves as single knowledge source for PCL/Perf security and 
access control related matter according to decisions, discussion and  
PoC prototype previously made here [5],[6].

The file can later be extended with information describing:

a) PCL/Perf usage models and its security implications
b) PCL/Perf user interface, its changes and related security implications
c) security related implications of monitoring by a specific PCL PMU [2]

---
 Alexey Budankov (2):
Documentation/admin-guide: update admin-guide index.rst
Documentation/admin-guide: introduce perf-security.rst file

 Documentation/admin-guide/index.rst |  1 +
 Documentation/admin-guide/perf-security.rst | 83 +
 2 files changed, 84 insertions(+)

---
[1] https://marc.info/?l=linux-kernel=153815883923913=2
[2] http://man7.org/linux/man-pages/man2/perf_event_open.2.html
[3] https://perf.wiki.kernel.org/index.php/Main_Page
[4] https://marc.info/?l=linux-kernel=153837512226838=2
[5] https://marc.info/?l=linux-kernel=153736008310781=2
[6] https://lkml.org/lkml/2018/5/21/156

[PATCH v1 0/2]: Documentation/admin-guide: introduce perf-security.rst file and extend perf_event_paranoid documentation

[Alexey Budankov]

To facilitate informed decision making by system administrators [1]
to permit and manage access to PCL/Perf [2],[3] performance monitoring 
for multiple users perf-security.rst document suggested by Thomas Gleixner 
is introduced [4] that:

a) states PCL/Perf access security concerns for multi user environment
b) refers to base Linux access control and management principles
c) extends documentation of possible perf_event_paranoid knob settings 

The file serves as single knowledge source for PCL/Perf security and 
access control related matter according to decisions, discussion and  
PoC prototype previously made here [5],[6].

The file can later be extended with information describing:

a) PCL/Perf usage models and its security implications
b) PCL/Perf user interface, its changes and related security implications
c) security related implications of monitoring by a specific PCL PMU [2]

---
 Alexey Budankov (2):
Documentation/admin-guide: update admin-guide index.rst
Documentation/admin-guide: introduce perf-security.rst file

 Documentation/admin-guide/index.rst |  1 +
 Documentation/admin-guide/perf-security.rst | 83 +
 2 files changed, 84 insertions(+)

---
[1] https://marc.info/?l=linux-kernel=153815883923913=2
[2] http://man7.org/linux/man-pages/man2/perf_event_open.2.html
[3] https://perf.wiki.kernel.org/index.php/Main_Page
[4] https://marc.info/?l=linux-kernel=153837512226838=2
[5] https://marc.info/?l=linux-kernel=153736008310781=2
[6] https://lkml.org/lkml/2018/5/21/156

Re: [PATCH v5 14/18] arm64: dts: qcom: qcs404: Add remoteproc nodes

[Sibi Sankar]

Hi Bjorn/Vinod,

On 2018-11-09 15:14, Vinod Koul wrote:

From: Bjorn Andersson 

Add the TrustZone based remoteproc nodes and their glink edges for
adsp, cdsp and wcss. Enable them for EVB common DTS.

Signed-off-by: Bjorn Andersson 
Signed-off-by: Vinod Koul 
---
 arch/arm64/boot/dts/qcom/qcs404-evb.dtsi | 12 +
 arch/arm64/boot/dts/qcom/qcs404.dtsi | 93 


 2 files changed, 105 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/qcs404-evb.dtsi
b/arch/arm64/boot/dts/qcom/qcs404-evb.dtsi
index db035fef67d9..a39924efebe4 100644
--- a/arch/arm64/boot/dts/qcom/qcs404-evb.dtsi
+++ b/arch/arm64/boot/dts/qcom/qcs404-evb.dtsi
@@ -21,6 +21,18 @@
};
 };

+_adsp {
+   status = "ok";
+};
+
+_cdsp {
+   status = "ok";
+};
+
+_wcss {
+   status = "ok";
+};
+
 _requests {
pms405-regulators {
compatible = "qcom,rpm-pms405-regulators";
diff --git a/arch/arm64/boot/dts/qcom/qcs404.dtsi
b/arch/arm64/boot/dts/qcom/qcs404.dtsi
index 46fce264c8fe..06607419c9d6 100644
--- a/arch/arm64/boot/dts/qcom/qcs404.dtsi
+++ b/arch/arm64/boot/dts/qcom/qcs404.dtsi
@@ -80,6 +80,99 @@
method = "smc";
};

+   remoteproc_adsp: remoteproc-adsp {
+   compatible = "qcom,qcs404-adsp-pas";
+
+   interrupts-extended = < GIC_SPI 293 IRQ_TYPE_EDGE_RISING>,
+ <_smp2p_in 0 IRQ_TYPE_EDGE_RISING>,
+ <_smp2p_in 1 IRQ_TYPE_EDGE_RISING>,
+ <_smp2p_in 2 IRQ_TYPE_EDGE_RISING>,
+ <_smp2p_in 3 IRQ_TYPE_EDGE_RISING>;
+   interrupt-names = "wdog", "fatal", "ready",
+ "handover", "stop-ack";
+
+   clocks = <_board>;
+   clock-names = "xo";
+
+   memory-region = <_fw_mem>;
+
+   qcom,smem-states = <_smp2p_out 0>;
+   qcom,smem-state-names = "stop";
+
+   status = "disabled";
+
+   glink-edge {
+   interrupts = ;
+
+   qcom,remote-pid = <2>;
+   mboxes = <_glb 8>;
+
+   label = "adsp";
+   };
+   };
+
+   remoteproc_cdsp: remoteproc-cdsp {
+   compatible = "qcom,qcs404-cdsp-pas";
+
+   interrupts-extended = < GIC_SPI 229 IRQ_TYPE_EDGE_RISING>,
+ <_smp2p_in 0 IRQ_TYPE_EDGE_RISING>,
+ <_smp2p_in 1 IRQ_TYPE_EDGE_RISING>,
+ <_smp2p_in 2 IRQ_TYPE_EDGE_RISING>,
+ <_smp2p_in 3 IRQ_TYPE_EDGE_RISING>;
+   interrupt-names = "wdog", "fatal", "ready",
+ "handover", "stop-ack";
+
+   clocks = <_board>;
+   clock-names = "xo";
+
+   memory-region = <_fw_mem>;
+
+   qcom,smem-states = <_smp2p_out 0>;
+   qcom,smem-state-names = "stop";
+
+   status = "disabled";
+
+   glink-edge {
+   interrupts = ;
+
+   qcom,remote-pid = <5>;
+   mboxes = <_glb 12>;
+
+   label = "cdsp";
+   };
+   };
+
+   remoteproc_wcss: remoteproc-wcss {
+   compatible = "qcom,qcs404-wcss-pas";
+
+   interrupts-extended = < GIC_SPI 153 IRQ_TYPE_EDGE_RISING>,
+ <_smp2p_in 0 IRQ_TYPE_EDGE_RISING>,
+ <_smp2p_in 1 IRQ_TYPE_EDGE_RISING>,
+ <_smp2p_in 2 IRQ_TYPE_EDGE_RISING>,
+ <_smp2p_in 3 IRQ_TYPE_EDGE_RISING>;
+   interrupt-names = "wdog", "fatal", "ready",
+ "handover", "stop-ack";


I can see that wcss remoteproc uses an additional smp2p interrupt called 
shutdown-ack
downstream you may want to skip wcss entry for now till the shutdown-ack 
gets posted,

reviewed and merged.


+
+   clocks = <_board>;
+   clock-names = "xo";
+
+   memory-region = <_fw_mem>;
+
+   qcom,smem-states = <_smp2p_out 0>;
+   qcom,smem-state-names = "stop";
+
+   status = "disabled";
+
+   glink-edge {
+   interrupts = ;
+
+   qcom,remote-pid = <1>;
+   mboxes = <_glb 16>;
+
+   label = "wcss";
+   };
+   };
+
reserved-memory {
#address-cells = <2>;
#size-cells = <2>;


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

Re: [PATCH v5 14/18] arm64: dts: qcom: qcs404: Add remoteproc nodes

[Sibi Sankar]

Hi Bjorn/Vinod,

On 2018-11-09 15:14, Vinod Koul wrote:

From: Bjorn Andersson 

Add the TrustZone based remoteproc nodes and their glink edges for
adsp, cdsp and wcss. Enable them for EVB common DTS.

Signed-off-by: Bjorn Andersson 
Signed-off-by: Vinod Koul 
---
 arch/arm64/boot/dts/qcom/qcs404-evb.dtsi | 12 +
 arch/arm64/boot/dts/qcom/qcs404.dtsi | 93 


 2 files changed, 105 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/qcs404-evb.dtsi
b/arch/arm64/boot/dts/qcom/qcs404-evb.dtsi
index db035fef67d9..a39924efebe4 100644
--- a/arch/arm64/boot/dts/qcom/qcs404-evb.dtsi
+++ b/arch/arm64/boot/dts/qcom/qcs404-evb.dtsi
@@ -21,6 +21,18 @@
};
 };

+_adsp {
+   status = "ok";
+};
+
+_cdsp {
+   status = "ok";
+};
+
+_wcss {
+   status = "ok";
+};
+
 _requests {
pms405-regulators {
compatible = "qcom,rpm-pms405-regulators";
diff --git a/arch/arm64/boot/dts/qcom/qcs404.dtsi
b/arch/arm64/boot/dts/qcom/qcs404.dtsi
index 46fce264c8fe..06607419c9d6 100644
--- a/arch/arm64/boot/dts/qcom/qcs404.dtsi
+++ b/arch/arm64/boot/dts/qcom/qcs404.dtsi
@@ -80,6 +80,99 @@
method = "smc";
};

+   remoteproc_adsp: remoteproc-adsp {
+   compatible = "qcom,qcs404-adsp-pas";
+
+   interrupts-extended = < GIC_SPI 293 IRQ_TYPE_EDGE_RISING>,
+ <_smp2p_in 0 IRQ_TYPE_EDGE_RISING>,
+ <_smp2p_in 1 IRQ_TYPE_EDGE_RISING>,
+ <_smp2p_in 2 IRQ_TYPE_EDGE_RISING>,
+ <_smp2p_in 3 IRQ_TYPE_EDGE_RISING>;
+   interrupt-names = "wdog", "fatal", "ready",
+ "handover", "stop-ack";
+
+   clocks = <_board>;
+   clock-names = "xo";
+
+   memory-region = <_fw_mem>;
+
+   qcom,smem-states = <_smp2p_out 0>;
+   qcom,smem-state-names = "stop";
+
+   status = "disabled";
+
+   glink-edge {
+   interrupts = ;
+
+   qcom,remote-pid = <2>;
+   mboxes = <_glb 8>;
+
+   label = "adsp";
+   };
+   };
+
+   remoteproc_cdsp: remoteproc-cdsp {
+   compatible = "qcom,qcs404-cdsp-pas";
+
+   interrupts-extended = < GIC_SPI 229 IRQ_TYPE_EDGE_RISING>,
+ <_smp2p_in 0 IRQ_TYPE_EDGE_RISING>,
+ <_smp2p_in 1 IRQ_TYPE_EDGE_RISING>,
+ <_smp2p_in 2 IRQ_TYPE_EDGE_RISING>,
+ <_smp2p_in 3 IRQ_TYPE_EDGE_RISING>;
+   interrupt-names = "wdog", "fatal", "ready",
+ "handover", "stop-ack";
+
+   clocks = <_board>;
+   clock-names = "xo";
+
+   memory-region = <_fw_mem>;
+
+   qcom,smem-states = <_smp2p_out 0>;
+   qcom,smem-state-names = "stop";
+
+   status = "disabled";
+
+   glink-edge {
+   interrupts = ;
+
+   qcom,remote-pid = <5>;
+   mboxes = <_glb 12>;
+
+   label = "cdsp";
+   };
+   };
+
+   remoteproc_wcss: remoteproc-wcss {
+   compatible = "qcom,qcs404-wcss-pas";
+
+   interrupts-extended = < GIC_SPI 153 IRQ_TYPE_EDGE_RISING>,
+ <_smp2p_in 0 IRQ_TYPE_EDGE_RISING>,
+ <_smp2p_in 1 IRQ_TYPE_EDGE_RISING>,
+ <_smp2p_in 2 IRQ_TYPE_EDGE_RISING>,
+ <_smp2p_in 3 IRQ_TYPE_EDGE_RISING>;
+   interrupt-names = "wdog", "fatal", "ready",
+ "handover", "stop-ack";


I can see that wcss remoteproc uses an additional smp2p interrupt called 
shutdown-ack
downstream you may want to skip wcss entry for now till the shutdown-ack 
gets posted,

reviewed and merged.


+
+   clocks = <_board>;
+   clock-names = "xo";
+
+   memory-region = <_fw_mem>;
+
+   qcom,smem-states = <_smp2p_out 0>;
+   qcom,smem-state-names = "stop";
+
+   status = "disabled";
+
+   glink-edge {
+   interrupts = ;
+
+   qcom,remote-pid = <1>;
+   mboxes = <_glb 16>;
+
+   label = "wcss";
+   };
+   };
+
reserved-memory {
#address-cells = <2>;
#size-cells = <2>;


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

Re: [PATCH RFC] hist lookups

[Namhyung Kim]

Hi Jirka

Sorry for late!

On Tue, Nov 06, 2018 at 12:54:36PM +0100, Jiri Olsa wrote:
> On Mon, Nov 05, 2018 at 08:53:42PM -0800, David Miller wrote:
> > 
> > Jiri,
> > 
> > Because you now run queued_events__queue() lockless with that condvar
> > trick, it is possible for top->qe.in to be seen as one past the data[]
> > array, this is because the rotate_queues() code goes:
> > 
> > if (++top->qe.in > >qe.data[1])
> > top->qe.in = >qe.data[0];
> > 
> > So for a brief moment top->qe.in is out of range and thus
> > perf_top__mmap_read_idx() can try to enqueue to top->qe.data[2]
> > 
> > We can just do:
> > 
> > if (top->qe.in == >qe.data[1])
> > top->qe.in = >qe.data[0];
> > else
> > top->qe.in = >qe.data[1];
> > 
> > Or, make top->qe.in an index, and simply go:
> > 
> > top->qe.in ^= 1;
> > 
> > Either way will fix the bug.
> 
> ah right.. I had originaly full mutex around that,
> then I switched it off in the last patch and did
> not realize this implication.. nice ;-)

I like the rotate_queues() using cond-variable.  Have you tried to use
the same for hists->lock in hists__get_rotate_entries_in() too?

Eventually it'd be nice to avoid locks when a single thread processes
all the events.

Thanks,
Namhyung

Re: [PATCH RFC] hist lookups

[Namhyung Kim]

Hi Jirka

Sorry for late!

On Tue, Nov 06, 2018 at 12:54:36PM +0100, Jiri Olsa wrote:
> On Mon, Nov 05, 2018 at 08:53:42PM -0800, David Miller wrote:
> > 
> > Jiri,
> > 
> > Because you now run queued_events__queue() lockless with that condvar
> > trick, it is possible for top->qe.in to be seen as one past the data[]
> > array, this is because the rotate_queues() code goes:
> > 
> > if (++top->qe.in > >qe.data[1])
> > top->qe.in = >qe.data[0];
> > 
> > So for a brief moment top->qe.in is out of range and thus
> > perf_top__mmap_read_idx() can try to enqueue to top->qe.data[2]
> > 
> > We can just do:
> > 
> > if (top->qe.in == >qe.data[1])
> > top->qe.in = >qe.data[0];
> > else
> > top->qe.in = >qe.data[1];
> > 
> > Or, make top->qe.in an index, and simply go:
> > 
> > top->qe.in ^= 1;
> > 
> > Either way will fix the bug.
> 
> ah right.. I had originaly full mutex around that,
> then I switched it off in the last patch and did
> not realize this implication.. nice ;-)

I like the rotate_queues() using cond-variable.  Have you tried to use
the same for hists->lock in hists__get_rotate_entries_in() too?

Eventually it'd be nice to avoid locks when a single thread processes
all the events.

Thanks,
Namhyung

Re: [PATCH v3 0/3] sh: system call table generation support

[Rob Landley]

On 11/13/18 10:32 PM, Firoz Khan wrote:
> The purpose of this patch series is, we can easily
> add/modify/delete system call table support by cha-
> nging entry in syscall.tbl file instead of manually
> changing many files. The other goal is to unify the 
> system call table generation support implementation 
> across all the architectures. 

I applied the patch in https://github.com/landley/mkroot and the result booted
under qemu-system-sh4, seems to work fine. Network's fine, it can read a block
device, etc.

Acked-and-or-tested-by: Rob Landley 

I assume that this is just git du jour and not your patch:

WARNING: CPU: 0 PID: 1 at mm/slub.c:2448 ___slab_alloc.constprop.34+0x196/0x288

CPU: 0 PID: 1 Comm: swapper Not tainted 4.20.0-rc3 #1
PC is at ___slab_alloc.constprop.34+0x196/0x288
PR is at __slab_alloc.constprop.33+0x2a/0x4c
PC  : 8c09d09a SP  : 8f829ea0 SR  : 400080f0
TEA : c0001240
R0  : 8c09cf04 R1  : 8c01cbec R2  :  R3  : 
R4  : 8f8020a0 R5  : 006080c0 R6  : 8c01d74a R7  : 8fff5180
R8  : 8c011a40 R9  : 8fff5180 R10 : 8f8020a0 R11 : 8000
R12 : 8c01d74a R13 : 006080c0 R14 : 8f80211c
MACH: 008e MACL: 0ae4849d GBR :  PR  : 8c09d1b6

Call trace:
 [<(ptrval)>] arch_local_irq_restore+0x0/0x24
 [<(ptrval)>] __slab_alloc.constprop.33+0x2a/0x4c
 [<(ptrval)>] arch_local_save_flags+0x0/0x8
 [<(ptrval)>] arch_local_irq_restore+0x0/0x24
 [<(ptrval)>] mm_init.isra.6+0xca/0x120
 [<(ptrval)>] kmem_cache_alloc+0x9a/0xf4
 [<(ptrval)>] mm_init.isra.6+0xca/0x120
 [<(ptrval)>] arch_local_irq_restore+0x0/0x24
 [<(ptrval)>] kmem_cache_alloc+0x9a/0xf4
 [<(ptrval)>] mm_alloc+0xe/0x48
 [<(ptrval)>] mm_init.isra.6+0xca/0x120
 [<(ptrval)>] memset+0x0/0x8c
 [<(ptrval)>] __do_execve_file+0x1de/0x574
 [<(ptrval)>] getname_kernel+0x1e/0xc8
 [<(ptrval)>] kmem_cache_alloc+0x0/0xf4
 [<(ptrval)>] do_execve+0x16/0x24
 [<(ptrval)>] arch_local_save_flags+0x0/0x8
 [<(ptrval)>] arch_local_irq_restore+0x0/0x24
 [<(ptrval)>] printk+0x0/0x24
 [<(ptrval)>] kernel_init+0x34/0xec
 [<(ptrval)>] ret_from_kernel_thread+0xc/0x14
 [<(ptrval)>] schedule_tail+0x0/0x58
 [<(ptrval)>] kernel_init+0x0/0xec

---[ end trace 6e84d1e05051e55d ]---

[RFC PATCH] zinc chacha20 generic implementation using crypto API code

[Herbert Xu]

On Sun, Nov 18, 2018 at 02:46:30PM +0100, Jason A. Donenfeld wrote:
> 
> Personally I'd prefer this be merged after Zinc, since there's work to
> be done on adjusting the 20->12 in chacha20. That's not really much of
> a reason though. But maybe we can just sidestep the ordering concern
> all together:

In response to Martin's patch-set which I merged last week, I think
here is quick way out for the zinc interface.

Going through the past zinc discussions it would appear that
everybody is quite happy with the zinc interface per se.  The
most contentious areas are in fact the algorithm implementations
under zinc, as well as the conversion of the crypto API algorithms
over to using the zinc interface (e.g., you can no longer access
specific implementations).

My proposal is to merge the zinc interface as is, but to invert
how we place the algorithm implementations.  IOW the implementations
should stay where they are now, with in the crypto API.  However,
we will provide direct access to them for zinc without going through
the crypto API.  IOW we'll just export the functions directly.

Here is a proof of concept patch to do it for chacha20-generic.
It basically replaces patch 3 in the October zinc patch series.
Actually this patch also exports the arm/x86 chacha20 functions
too so they are ready for use by zinc.

If everyone is happy with this then we can immediately add the
zinc interface and expose the existing crypto API algorithms
through it.  This would allow wireguard to be merged right away.

In parallel, the discussions over replacing the implementations
underneath can carry on without stalling the whole project.

PS This patch is totally untested :)

Thanks,

diff --git a/arch/arm/crypto/chacha20-neon-glue.c 
b/arch/arm/crypto/chacha20-neon-glue.c
index 59a7be08e80c..1f6239ff41ae 100644
--- a/arch/arm/crypto/chacha20-neon-glue.c
+++ b/arch/arm/crypto/chacha20-neon-glue.c
@@ -31,7 +31,7 @@
 asmlinkage void chacha20_block_xor_neon(u32 *state, u8 *dst, const u8 *src);
 asmlinkage void chacha20_4block_xor_neon(u32 *state, u8 *dst, const u8 *src);
 
-static void chacha20_doneon(u32 *state, u8 *dst, const u8 *src,
+void crypto_chacha20_doneon(u32 *state, u8 *dst, const u8 *src,
unsigned int bytes)
 {
u8 buf[CHACHA20_BLOCK_SIZE];
@@ -56,11 +56,12 @@ static void chacha20_doneon(u32 *state, u8 *dst, const u8 
*src,
memcpy(dst, buf, bytes);
}
 }
+EXPORT_SYMBOL_GPL(crypto_chacha20_doneon);
 
 static int chacha20_neon(struct skcipher_request *req)
 {
struct crypto_skcipher *tfm = crypto_skcipher_reqtfm(req);
-   struct chacha20_ctx *ctx = crypto_skcipher_ctx(tfm);
+   struct crypto_chacha20_ctx *ctx = crypto_skcipher_ctx(tfm);
struct skcipher_walk walk;
u32 state[16];
int err;
@@ -79,8 +80,8 @@ static int chacha20_neon(struct skcipher_request *req)
if (nbytes < walk.total)
nbytes = round_down(nbytes, walk.stride);
 
-   chacha20_doneon(state, walk.dst.virt.addr, walk.src.virt.addr,
-   nbytes);
+   crypto_chacha20_doneon(state, walk.dst.virt.addr,
+  walk.src.virt.addr, nbytes);
err = skcipher_walk_done(, walk.nbytes - nbytes);
}
kernel_neon_end();
@@ -93,7 +94,7 @@ static struct skcipher_alg alg = {
.base.cra_driver_name   = "chacha20-neon",
.base.cra_priority  = 300,
.base.cra_blocksize = 1,
-   .base.cra_ctxsize   = sizeof(struct chacha20_ctx),
+   .base.cra_ctxsize   = sizeof(struct crypto_chacha20_ctx),
.base.cra_module= THIS_MODULE,
 
.min_keysize= CHACHA20_KEY_SIZE,
diff --git a/arch/x86/crypto/chacha20_glue.c b/arch/x86/crypto/chacha20_glue.c
index 9fd84fe6ec09..519bbbf8c477 100644
--- a/arch/x86/crypto/chacha20_glue.c
+++ b/arch/x86/crypto/chacha20_glue.c
@@ -39,7 +39,7 @@ static unsigned int chacha20_advance(unsigned int len, 
unsigned int maxblocks)
return round_up(len, CHACHA20_BLOCK_SIZE) / CHACHA20_BLOCK_SIZE;
 }
 
-static void chacha20_dosimd(u32 *state, u8 *dst, const u8 *src,
+void crypto_chacha20_dosimd(u32 *state, u8 *dst, const u8 *src,
unsigned int bytes)
 {
 #ifdef CONFIG_AS_AVX2
@@ -85,11 +85,12 @@ static void chacha20_dosimd(u32 *state, u8 *dst, const u8 
*src,
state[12]++;
}
 }
+EXPORT_SYMBOL_GPL(crypto_chacha20_dosimd);
 
 static int chacha20_simd(struct skcipher_request *req)
 {
struct crypto_skcipher *tfm = crypto_skcipher_reqtfm(req);
-   struct chacha20_ctx *ctx = crypto_skcipher_ctx(tfm);
+   struct crypto_chacha20_ctx *ctx = crypto_skcipher_ctx(tfm);
u32 *state, state_buf[16 + 2] __aligned(8);
struct skcipher_walk walk;
int err;
@@ -112,8 +113,8 @@ static int chacha20_simd(struct skcipher_request *req)
if (nbytes < walk.total)
  

Re: [PATCH v3 0/3] sh: system call table generation support

[Rob Landley]

On 11/13/18 10:32 PM, Firoz Khan wrote:
> The purpose of this patch series is, we can easily
> add/modify/delete system call table support by cha-
> nging entry in syscall.tbl file instead of manually
> changing many files. The other goal is to unify the 
> system call table generation support implementation 
> across all the architectures. 

I applied the patch in https://github.com/landley/mkroot and the result booted
under qemu-system-sh4, seems to work fine. Network's fine, it can read a block
device, etc.

Acked-and-or-tested-by: Rob Landley 

I assume that this is just git du jour and not your patch:

WARNING: CPU: 0 PID: 1 at mm/slub.c:2448 ___slab_alloc.constprop.34+0x196/0x288

CPU: 0 PID: 1 Comm: swapper Not tainted 4.20.0-rc3 #1
PC is at ___slab_alloc.constprop.34+0x196/0x288
PR is at __slab_alloc.constprop.33+0x2a/0x4c
PC  : 8c09d09a SP  : 8f829ea0 SR  : 400080f0
TEA : c0001240
R0  : 8c09cf04 R1  : 8c01cbec R2  :  R3  : 
R4  : 8f8020a0 R5  : 006080c0 R6  : 8c01d74a R7  : 8fff5180
R8  : 8c011a40 R9  : 8fff5180 R10 : 8f8020a0 R11 : 8000
R12 : 8c01d74a R13 : 006080c0 R14 : 8f80211c
MACH: 008e MACL: 0ae4849d GBR :  PR  : 8c09d1b6

Call trace:
 [<(ptrval)>] arch_local_irq_restore+0x0/0x24
 [<(ptrval)>] __slab_alloc.constprop.33+0x2a/0x4c
 [<(ptrval)>] arch_local_save_flags+0x0/0x8
 [<(ptrval)>] arch_local_irq_restore+0x0/0x24
 [<(ptrval)>] mm_init.isra.6+0xca/0x120
 [<(ptrval)>] kmem_cache_alloc+0x9a/0xf4
 [<(ptrval)>] mm_init.isra.6+0xca/0x120
 [<(ptrval)>] arch_local_irq_restore+0x0/0x24
 [<(ptrval)>] kmem_cache_alloc+0x9a/0xf4
 [<(ptrval)>] mm_alloc+0xe/0x48
 [<(ptrval)>] mm_init.isra.6+0xca/0x120
 [<(ptrval)>] memset+0x0/0x8c
 [<(ptrval)>] __do_execve_file+0x1de/0x574
 [<(ptrval)>] getname_kernel+0x1e/0xc8
 [<(ptrval)>] kmem_cache_alloc+0x0/0xf4
 [<(ptrval)>] do_execve+0x16/0x24
 [<(ptrval)>] arch_local_save_flags+0x0/0x8
 [<(ptrval)>] arch_local_irq_restore+0x0/0x24
 [<(ptrval)>] printk+0x0/0x24
 [<(ptrval)>] kernel_init+0x34/0xec
 [<(ptrval)>] ret_from_kernel_thread+0xc/0x14
 [<(ptrval)>] schedule_tail+0x0/0x58
 [<(ptrval)>] kernel_init+0x0/0xec

---[ end trace 6e84d1e05051e55d ]---

[RFC PATCH] zinc chacha20 generic implementation using crypto API code

[Herbert Xu]

On Sun, Nov 18, 2018 at 02:46:30PM +0100, Jason A. Donenfeld wrote:
> 
> Personally I'd prefer this be merged after Zinc, since there's work to
> be done on adjusting the 20->12 in chacha20. That's not really much of
> a reason though. But maybe we can just sidestep the ordering concern
> all together:

In response to Martin's patch-set which I merged last week, I think
here is quick way out for the zinc interface.

Going through the past zinc discussions it would appear that
everybody is quite happy with the zinc interface per se.  The
most contentious areas are in fact the algorithm implementations
under zinc, as well as the conversion of the crypto API algorithms
over to using the zinc interface (e.g., you can no longer access
specific implementations).

My proposal is to merge the zinc interface as is, but to invert
how we place the algorithm implementations.  IOW the implementations
should stay where they are now, with in the crypto API.  However,
we will provide direct access to them for zinc without going through
the crypto API.  IOW we'll just export the functions directly.

Here is a proof of concept patch to do it for chacha20-generic.
It basically replaces patch 3 in the October zinc patch series.
Actually this patch also exports the arm/x86 chacha20 functions
too so they are ready for use by zinc.

If everyone is happy with this then we can immediately add the
zinc interface and expose the existing crypto API algorithms
through it.  This would allow wireguard to be merged right away.

In parallel, the discussions over replacing the implementations
underneath can carry on without stalling the whole project.

PS This patch is totally untested :)

Thanks,

diff --git a/arch/arm/crypto/chacha20-neon-glue.c 
b/arch/arm/crypto/chacha20-neon-glue.c
index 59a7be08e80c..1f6239ff41ae 100644
--- a/arch/arm/crypto/chacha20-neon-glue.c
+++ b/arch/arm/crypto/chacha20-neon-glue.c
@@ -31,7 +31,7 @@
 asmlinkage void chacha20_block_xor_neon(u32 *state, u8 *dst, const u8 *src);
 asmlinkage void chacha20_4block_xor_neon(u32 *state, u8 *dst, const u8 *src);
 
-static void chacha20_doneon(u32 *state, u8 *dst, const u8 *src,
+void crypto_chacha20_doneon(u32 *state, u8 *dst, const u8 *src,
unsigned int bytes)
 {
u8 buf[CHACHA20_BLOCK_SIZE];
@@ -56,11 +56,12 @@ static void chacha20_doneon(u32 *state, u8 *dst, const u8 
*src,
memcpy(dst, buf, bytes);
}
 }
+EXPORT_SYMBOL_GPL(crypto_chacha20_doneon);
 
 static int chacha20_neon(struct skcipher_request *req)
 {
struct crypto_skcipher *tfm = crypto_skcipher_reqtfm(req);
-   struct chacha20_ctx *ctx = crypto_skcipher_ctx(tfm);
+   struct crypto_chacha20_ctx *ctx = crypto_skcipher_ctx(tfm);
struct skcipher_walk walk;
u32 state[16];
int err;
@@ -79,8 +80,8 @@ static int chacha20_neon(struct skcipher_request *req)
if (nbytes < walk.total)
nbytes = round_down(nbytes, walk.stride);
 
-   chacha20_doneon(state, walk.dst.virt.addr, walk.src.virt.addr,
-   nbytes);
+   crypto_chacha20_doneon(state, walk.dst.virt.addr,
+  walk.src.virt.addr, nbytes);
err = skcipher_walk_done(, walk.nbytes - nbytes);
}
kernel_neon_end();
@@ -93,7 +94,7 @@ static struct skcipher_alg alg = {
.base.cra_driver_name   = "chacha20-neon",
.base.cra_priority  = 300,
.base.cra_blocksize = 1,
-   .base.cra_ctxsize   = sizeof(struct chacha20_ctx),
+   .base.cra_ctxsize   = sizeof(struct crypto_chacha20_ctx),
.base.cra_module= THIS_MODULE,
 
.min_keysize= CHACHA20_KEY_SIZE,
diff --git a/arch/x86/crypto/chacha20_glue.c b/arch/x86/crypto/chacha20_glue.c
index 9fd84fe6ec09..519bbbf8c477 100644
--- a/arch/x86/crypto/chacha20_glue.c
+++ b/arch/x86/crypto/chacha20_glue.c
@@ -39,7 +39,7 @@ static unsigned int chacha20_advance(unsigned int len, 
unsigned int maxblocks)
return round_up(len, CHACHA20_BLOCK_SIZE) / CHACHA20_BLOCK_SIZE;
 }
 
-static void chacha20_dosimd(u32 *state, u8 *dst, const u8 *src,
+void crypto_chacha20_dosimd(u32 *state, u8 *dst, const u8 *src,
unsigned int bytes)
 {
 #ifdef CONFIG_AS_AVX2
@@ -85,11 +85,12 @@ static void chacha20_dosimd(u32 *state, u8 *dst, const u8 
*src,
state[12]++;
}
 }
+EXPORT_SYMBOL_GPL(crypto_chacha20_dosimd);
 
 static int chacha20_simd(struct skcipher_request *req)
 {
struct crypto_skcipher *tfm = crypto_skcipher_reqtfm(req);
-   struct chacha20_ctx *ctx = crypto_skcipher_ctx(tfm);
+   struct crypto_chacha20_ctx *ctx = crypto_skcipher_ctx(tfm);
u32 *state, state_buf[16 + 2] __aligned(8);
struct skcipher_walk walk;
int err;
@@ -112,8 +113,8 @@ static int chacha20_simd(struct skcipher_request *req)
if (nbytes < walk.total)
  

Re: [PATCH v3 0/4] sparc: system call table generation support

[Firoz Khan]

Hi David,

On Mon, 19 Nov 2018 at 08:29, David Miller  wrote:
>
> From: Firoz Khan 
> Date: Wed, 14 Nov 2018 10:56:27 +0530
>
> > The purpose of this patch series is, we can easily
> > add/modify/delete system call table support by cha-
> > nging entry in syscall.tbl file instead of manually
> > changing many files. The other goal is to unify the
> > system call table generation support implementation
> > across all the architectures.
>  ...
>
> Series applied to sparc-next.

Sounds good. Thanks

Firoz

Re: [PATCH v3 0/4] sparc: system call table generation support

[Firoz Khan]

Hi David,

On Mon, 19 Nov 2018 at 08:29, David Miller  wrote:
>
> From: Firoz Khan 
> Date: Wed, 14 Nov 2018 10:56:27 +0530
>
> > The purpose of this patch series is, we can easily
> > add/modify/delete system call table support by cha-
> > nging entry in syscall.tbl file instead of manually
> > changing many files. The other goal is to unify the
> > system call table generation support implementation
> > across all the architectures.
>  ...
>
> Series applied to sparc-next.

Sounds good. Thanks

Firoz

Re: [PATCH v7 0/5] parisc: system call table generation support

[Firoz Khan]

Hi Helge,

On Sat, 17 Nov 2018 at 22:01, Helge Deller  wrote:
>
> * Arnd Bergmann :
> > On Fri, Nov 16, 2018 at 1:55 PM Helge Deller  wrote:
> > > > On Fri, 16 Nov 2018 at 01:01, Helge Deller  wrote:
> > > > >
> > > > > On 14.11.2018 07:34, Firoz Khan wrote:
> > > > > > The purpose of this patch series is, we can easily
> > > > > > add/modify/delete system call table support by cha-
> > > > > > nging entry in syscall.tbl file instead of manually
> > > > > > changing many files. The other goal is to unify the
> > > > > > system call table generation support implementation
> > > > > > across all the architectures.
> > > > > >
> > > > > > The system call tables are in different format in
> > > > > > all architecture. It will be difficult to manually
> > > > > > add, modify or delete the system calls in the resp-
> > > > > > ective files manually. To make it easy by keeping a
> > > > > > script and which'll generate uapi header file and
> > > > > > syscall table file.
> > > > > >
> > > > > > syscall.tbl contains the list of available system
> > > > > > calls along with system call number and correspond-
> > > > > > ing entry point. Add a new system call in this arch-
> > > > > > itecture will be possible by adding new entry in the
> > > > > > syscall.tbl file.
> > > > > >
> > > > > > Adding a new table entry consisting of:
> > > > > > - System call number.
> > > > > > - ABI.
> > > > > > - System call name.
> > > > > > - Entry point name.
> > > > > >
> > > > > > 
> > > > > > Firoz Khan (5):
> > > > > >   parisc: move __IGNORE* entries to non uapi header
> > > > > >   parisc: add __NR_syscalls along with __NR_Linux_syscalls
> > > > > >   parisc: add system call table generation support
> > > > > >   parisc: generate uapi header and system call table files
> > > > > >   parisc: syscalls: ignore nfsservctl for other architectures
> > > > >
> > > > > Firoz, you may add
> > > > > Acked-by: Helge Deller 
> > > > > to the whole parisc series.
> > > >
> > > > Sure, will do.
> > > > I'm on a vacation right now. will send mid next week.
> > >
> > > That's ok, there is no urgency.
> > >
> > > Actually, I noticed that the generated files unistd_32.h
> > > and unistd_64.h do have the same contents, since on parisc
> > > we keep the syscall numbers the same for 32- and 64-bit.
> > > With that in mind, we can simply generate on unistd.h
> > > file for both variants.
> >
> > It depends on what we want to do in the future. When we add
> > around 20 new system calls fro y2038, my plan was to
> > only add them for 32-bit architectures, leaving holes on
> > 64-bit ones.
>
> Ok, I didn't thought of that.
>
> > We can also assign the new numbers on parisc64 but they would have the
> > same entry point as existing calls.
>
> > If you prefer doing it like that, your patch seems fine for that,
> > it's just slightly inconsistent with the other 64-bit architectures
> > then.
>
> I really prefer to stay in sync with other major architectures.
> So, please drop my last patch.
>
> Instead please apply only the next one, which drops the NR_Linux
> offset value (which is 0 anyway).

This can be easily done. FYI, our intention is the generated file must be
same as the old one. That's why I kept the offset as it is. I can add
one extra patch to remove NR_Linux.

>
> Thanks,
> Helge
>
>
> diff --git a/arch/parisc/include/uapi/asm/unistd.h 
> b/arch/parisc/include/uapi/asm/unistd.h
> index 6e31f58ad6b5..98dc953656af 100644
> --- a/arch/parisc/include/uapi/asm/unistd.h
> +++ b/arch/parisc/include/uapi/asm/unistd.h
> @@ -2,7 +2,6 @@
>  #ifndef _UAPI_ASM_PARISC_UNISTD_H_
>  #define _UAPI_ASM_PARISC_UNISTD_H_
>
> -#define __NR_Linux 0
>  #ifdef __LP64__
>  #include 
>  #else
> diff --git a/arch/parisc/kernel/syscalls/Makefile 
> b/arch/parisc/kernel/syscalls/Makefile
> index defa8878f6d2..4dcc5c9ae7f2 100644
> --- a/arch/parisc/kernel/syscalls/Makefile
> +++ b/arch/parisc/kernel/syscalls/Makefile
> @@ -12,22 +12,18 @@ systbl := $(srctree)/$(src)/syscalltbl.sh
>  quiet_cmd_syshdr = SYSHDR  $@
>cmd_syshdr = $(CONFIG_SHELL) '$(syshdr)' '$<' '$@'   \
>'$(syshdr_abis_$(basetarget))'   \
> -  '$(syshdr_pfx_$(basetarget))'\
> -  '$(syshdr_offset_$(basetarget))'
> +  '$(syshdr_pfx_$(basetarget))'
>
>  quiet_cmd_systbl = SYSTBL  $@
>cmd_systbl = $(CONFIG_SHELL) '$(systbl)' '$<' '$@'   \
>'$(systbl_abis_$(basetarget))'   \
> -  '$(systbl_abi_$(basetarget))'\
> -  '$(systbl_offset_$(basetarget))'
> +  '$(systbl_abi_$(basetarget))'
>
>  syshdr_abis_unistd_32 := common,32
> -syshdr_offset_unistd_32 := __NR_Linux

I'll remove this line

>  $(uapi)/unistd_32.h: $(syscall) $(syshdr)
> $(call if_changed,syshdr)
>
>  syshdr_abis_unistd_64 := common,64
> -syshdr_offset_unistd_64 := __NR_Linux

And 

Re: [PATCH v7 0/5] parisc: system call table generation support

[Firoz Khan]

Hi Helge,

On Sat, 17 Nov 2018 at 22:01, Helge Deller  wrote:
>
> * Arnd Bergmann :
> > On Fri, Nov 16, 2018 at 1:55 PM Helge Deller  wrote:
> > > > On Fri, 16 Nov 2018 at 01:01, Helge Deller  wrote:
> > > > >
> > > > > On 14.11.2018 07:34, Firoz Khan wrote:
> > > > > > The purpose of this patch series is, we can easily
> > > > > > add/modify/delete system call table support by cha-
> > > > > > nging entry in syscall.tbl file instead of manually
> > > > > > changing many files. The other goal is to unify the
> > > > > > system call table generation support implementation
> > > > > > across all the architectures.
> > > > > >
> > > > > > The system call tables are in different format in
> > > > > > all architecture. It will be difficult to manually
> > > > > > add, modify or delete the system calls in the resp-
> > > > > > ective files manually. To make it easy by keeping a
> > > > > > script and which'll generate uapi header file and
> > > > > > syscall table file.
> > > > > >
> > > > > > syscall.tbl contains the list of available system
> > > > > > calls along with system call number and correspond-
> > > > > > ing entry point. Add a new system call in this arch-
> > > > > > itecture will be possible by adding new entry in the
> > > > > > syscall.tbl file.
> > > > > >
> > > > > > Adding a new table entry consisting of:
> > > > > > - System call number.
> > > > > > - ABI.
> > > > > > - System call name.
> > > > > > - Entry point name.
> > > > > >
> > > > > > 
> > > > > > Firoz Khan (5):
> > > > > >   parisc: move __IGNORE* entries to non uapi header
> > > > > >   parisc: add __NR_syscalls along with __NR_Linux_syscalls
> > > > > >   parisc: add system call table generation support
> > > > > >   parisc: generate uapi header and system call table files
> > > > > >   parisc: syscalls: ignore nfsservctl for other architectures
> > > > >
> > > > > Firoz, you may add
> > > > > Acked-by: Helge Deller 
> > > > > to the whole parisc series.
> > > >
> > > > Sure, will do.
> > > > I'm on a vacation right now. will send mid next week.
> > >
> > > That's ok, there is no urgency.
> > >
> > > Actually, I noticed that the generated files unistd_32.h
> > > and unistd_64.h do have the same contents, since on parisc
> > > we keep the syscall numbers the same for 32- and 64-bit.
> > > With that in mind, we can simply generate on unistd.h
> > > file for both variants.
> >
> > It depends on what we want to do in the future. When we add
> > around 20 new system calls fro y2038, my plan was to
> > only add them for 32-bit architectures, leaving holes on
> > 64-bit ones.
>
> Ok, I didn't thought of that.
>
> > We can also assign the new numbers on parisc64 but they would have the
> > same entry point as existing calls.
>
> > If you prefer doing it like that, your patch seems fine for that,
> > it's just slightly inconsistent with the other 64-bit architectures
> > then.
>
> I really prefer to stay in sync with other major architectures.
> So, please drop my last patch.
>
> Instead please apply only the next one, which drops the NR_Linux
> offset value (which is 0 anyway).

This can be easily done. FYI, our intention is the generated file must be
same as the old one. That's why I kept the offset as it is. I can add
one extra patch to remove NR_Linux.

>
> Thanks,
> Helge
>
>
> diff --git a/arch/parisc/include/uapi/asm/unistd.h 
> b/arch/parisc/include/uapi/asm/unistd.h
> index 6e31f58ad6b5..98dc953656af 100644
> --- a/arch/parisc/include/uapi/asm/unistd.h
> +++ b/arch/parisc/include/uapi/asm/unistd.h
> @@ -2,7 +2,6 @@
>  #ifndef _UAPI_ASM_PARISC_UNISTD_H_
>  #define _UAPI_ASM_PARISC_UNISTD_H_
>
> -#define __NR_Linux 0
>  #ifdef __LP64__
>  #include 
>  #else
> diff --git a/arch/parisc/kernel/syscalls/Makefile 
> b/arch/parisc/kernel/syscalls/Makefile
> index defa8878f6d2..4dcc5c9ae7f2 100644
> --- a/arch/parisc/kernel/syscalls/Makefile
> +++ b/arch/parisc/kernel/syscalls/Makefile
> @@ -12,22 +12,18 @@ systbl := $(srctree)/$(src)/syscalltbl.sh
>  quiet_cmd_syshdr = SYSHDR  $@
>cmd_syshdr = $(CONFIG_SHELL) '$(syshdr)' '$<' '$@'   \
>'$(syshdr_abis_$(basetarget))'   \
> -  '$(syshdr_pfx_$(basetarget))'\
> -  '$(syshdr_offset_$(basetarget))'
> +  '$(syshdr_pfx_$(basetarget))'
>
>  quiet_cmd_systbl = SYSTBL  $@
>cmd_systbl = $(CONFIG_SHELL) '$(systbl)' '$<' '$@'   \
>'$(systbl_abis_$(basetarget))'   \
> -  '$(systbl_abi_$(basetarget))'\
> -  '$(systbl_offset_$(basetarget))'
> +  '$(systbl_abi_$(basetarget))'
>
>  syshdr_abis_unistd_32 := common,32
> -syshdr_offset_unistd_32 := __NR_Linux

I'll remove this line

>  $(uapi)/unistd_32.h: $(syscall) $(syshdr)
> $(call if_changed,syshdr)
>
>  syshdr_abis_unistd_64 := common,64
> -syshdr_offset_unistd_64 := __NR_Linux

And 

Re: RFC: userspace exception fixups

[Jethro Beekman]

On 2018-11-18 18:32, Jarkko Sakkinen wrote:

On Sun, Nov 18, 2018 at 09:15:48AM +0200, Jarkko Sakkinen wrote:

On Thu, Nov 01, 2018 at 10:53:40AM -0700, Andy Lutomirski wrote:

Hi all-

The people working on SGX enablement are grappling with a somewhat
annoying issue: the x86 EENTER instruction is used from user code and
can, as part of its normal-ish operation, raise an exception.  It is
also highly likely to be used from a library, and signal handling in
libraries is unpleasant at best.

There's been some discussion of adding a vDSO entry point to wrap
EENTER and do something sensible with the exceptions, but I'm
wondering if a more general mechanism would be helpful.


I haven't really followed all of this discussion because I've been busy
working on the patch set but for me all of these approaches look awfully
complicated.

I'll throw my own suggestion and apologize if this has been already
suggested and discarded: return-to-AEP.

My idea is to do just a small extension to SGX AEX handling. At the
moment hardware will RAX, RBX and RCX with ERESUME parameters. We can
fill extend this by filling other three spare registers with exception
information.

AEP handler can then do whatever it wants to do with this information
or just do ERESUME.


A correction here. In practice this will add a requirement to have a bit
more complicated AEP code (check the regs for exceptions) than before
and not just bytes for ENCLU.

e.g. AEP handler should be along the lines

1. #PF (or #UD or) happens. Kernel fills the registers when it cannot
handle the exception and returns back to user space i.e. to the
AEP handler.
2. Check the registers containing exception information. If they have
been filled, take whatever actions user space wants to take.
3. Otherwise, just ERESUME.

 From my point of view this is making the AEP parameter useful. Its
standard use is just weird (always point to a place just containing
ENCLU bytes, why the heck it even exists).


I like this solution. Keeps things simple. One question: when an 
exception occurs, how does the kernel know whether to set special 
registers or send a signal?


--
Jethro Beekman | Fortanix




smime.p7s
Description: S/MIME Cryptographic Signature

Re: RFC: userspace exception fixups

[Jethro Beekman]

On 2018-11-18 18:32, Jarkko Sakkinen wrote:

On Sun, Nov 18, 2018 at 09:15:48AM +0200, Jarkko Sakkinen wrote:

On Thu, Nov 01, 2018 at 10:53:40AM -0700, Andy Lutomirski wrote:

Hi all-

The people working on SGX enablement are grappling with a somewhat
annoying issue: the x86 EENTER instruction is used from user code and
can, as part of its normal-ish operation, raise an exception.  It is
also highly likely to be used from a library, and signal handling in
libraries is unpleasant at best.

There's been some discussion of adding a vDSO entry point to wrap
EENTER and do something sensible with the exceptions, but I'm
wondering if a more general mechanism would be helpful.


I haven't really followed all of this discussion because I've been busy
working on the patch set but for me all of these approaches look awfully
complicated.

I'll throw my own suggestion and apologize if this has been already
suggested and discarded: return-to-AEP.

My idea is to do just a small extension to SGX AEX handling. At the
moment hardware will RAX, RBX and RCX with ERESUME parameters. We can
fill extend this by filling other three spare registers with exception
information.

AEP handler can then do whatever it wants to do with this information
or just do ERESUME.


A correction here. In practice this will add a requirement to have a bit
more complicated AEP code (check the regs for exceptions) than before
and not just bytes for ENCLU.

e.g. AEP handler should be along the lines

1. #PF (or #UD or) happens. Kernel fills the registers when it cannot
handle the exception and returns back to user space i.e. to the
AEP handler.
2. Check the registers containing exception information. If they have
been filled, take whatever actions user space wants to take.
3. Otherwise, just ERESUME.

 From my point of view this is making the AEP parameter useful. Its
standard use is just weird (always point to a place just containing
ENCLU bytes, why the heck it even exists).


I like this solution. Keeps things simple. One question: when an 
exception occurs, how does the kernel know whether to set special 
registers or send a signal?


--
Jethro Beekman | Fortanix




smime.p7s
Description: S/MIME Cryptographic Signature

Re: [PATCH v3 0/3] sh: system call table generation support

[Firoz Khan]

On Wed, 14 Nov 2018 at 10:02, Firoz Khan  wrote:
>
> The purpose of this patch series is, we can easily
> add/modify/delete system call table support by cha-
> nging entry in syscall.tbl file instead of manually
> changing many files. The other goal is to unify the
> system call table generation support implementation
> across all the architectures.
>
> The system call tables are in different format in
> all architecture. It will be difficult to manually
> add, modify or delete the system calls in the resp-
> ective files manually. To make it easy by keeping a
> script and which'll generate uapi header file and
> syscall table file.
>
> syscall.tbl contains the list of available system
> calls along with system call number and correspond-
> ing entry point. Add a new system call in this arch-
> itecture will be possible by adding new entry in
> the syscall.tbl file.
>
> Adding a new table entry consisting of:
> - System call number.
> - ABI.
> - System call name.
> - Entry point name.
>
> Please note, this support is only available for 32-bit
> kernel, not 64-bit kernel. As I came across the 64-bit
> kernel is not active for long time.
>
> ARM, s390 and x86 architecuture does exist the sim-
> ilar support. I leverage their implementation to come
> up with a generic solution.
>
> I have done the same support for work for alpha, ia64,
> m68k, microblaze, mips, parisc, powerpc, sparc, and
> xtensa. Below mentioned git repository contains more
> details about the workflow.
>
> https://github.com/frzkhn/system_call_table_generator/
>
> Finally, this is the ground work to solve the Y2038
> issue. We need to add two dozen of system calls to solve
> Y2038 issue. So this patch series will help to add new
> system calls easily by adding new entry in the syscall-
> .tbl.
>
> Changes since v2:
>  - changed from generic-y to generated-y in Kbuild.
>
> Changes since v1:
>  - optimized/updated the syscall table generation
>scripts.
>  - fixed all mixed indentation issues in syscall.tbl.
>  - added "comments" in syscall.tbl.
>
> Firoz Khan (3):
>   sh: add __NR_syscalls along with NR_syscalls
>   sh: add system call table generation support
>   sh: generate uapi header and syscall table header files

Gentle reminder!

Could someone review this patch series. I haven't received any
feedback till now.

FYI, this support is only available for 32-bit kernel, not 64-bit
kernel. As I came across the 64-bit kernel is not active for long time.

Thanks
Firoz

>
>  arch/sh/Makefile  |   3 +
>  arch/sh/include/asm/Kbuild|   1 +
>  arch/sh/include/asm/unistd.h  |   2 +
>  arch/sh/include/uapi/asm/Kbuild   |   1 +
>  arch/sh/include/uapi/asm/unistd_32.h  |   4 +-
>  arch/sh/include/uapi/asm/unistd_64.h  |   4 +-
>  arch/sh/kernel/syscalls/Makefile  |  38 
>  arch/sh/kernel/syscalls/syscall.tbl   | 392 
> ++
>  arch/sh/kernel/syscalls/syscallhdr.sh |  36 
>  arch/sh/kernel/syscalls/syscalltbl.sh |  32 +++
>  arch/sh/kernel/syscalls_32.S  | 387 +
>  11 files changed, 514 insertions(+), 386 deletions(-)
>  create mode 100644 arch/sh/kernel/syscalls/Makefile
>  create mode 100644 arch/sh/kernel/syscalls/syscall.tbl
>  create mode 100644 arch/sh/kernel/syscalls/syscallhdr.sh
>  create mode 100644 arch/sh/kernel/syscalls/syscalltbl.sh
>
> --
> 1.9.1
>

Re: [PATCH v3 0/3] sh: system call table generation support

[Firoz Khan]

On Wed, 14 Nov 2018 at 10:02, Firoz Khan  wrote:
>
> The purpose of this patch series is, we can easily
> add/modify/delete system call table support by cha-
> nging entry in syscall.tbl file instead of manually
> changing many files. The other goal is to unify the
> system call table generation support implementation
> across all the architectures.
>
> The system call tables are in different format in
> all architecture. It will be difficult to manually
> add, modify or delete the system calls in the resp-
> ective files manually. To make it easy by keeping a
> script and which'll generate uapi header file and
> syscall table file.
>
> syscall.tbl contains the list of available system
> calls along with system call number and correspond-
> ing entry point. Add a new system call in this arch-
> itecture will be possible by adding new entry in
> the syscall.tbl file.
>
> Adding a new table entry consisting of:
> - System call number.
> - ABI.
> - System call name.
> - Entry point name.
>
> Please note, this support is only available for 32-bit
> kernel, not 64-bit kernel. As I came across the 64-bit
> kernel is not active for long time.
>
> ARM, s390 and x86 architecuture does exist the sim-
> ilar support. I leverage their implementation to come
> up with a generic solution.
>
> I have done the same support for work for alpha, ia64,
> m68k, microblaze, mips, parisc, powerpc, sparc, and
> xtensa. Below mentioned git repository contains more
> details about the workflow.
>
> https://github.com/frzkhn/system_call_table_generator/
>
> Finally, this is the ground work to solve the Y2038
> issue. We need to add two dozen of system calls to solve
> Y2038 issue. So this patch series will help to add new
> system calls easily by adding new entry in the syscall-
> .tbl.
>
> Changes since v2:
>  - changed from generic-y to generated-y in Kbuild.
>
> Changes since v1:
>  - optimized/updated the syscall table generation
>scripts.
>  - fixed all mixed indentation issues in syscall.tbl.
>  - added "comments" in syscall.tbl.
>
> Firoz Khan (3):
>   sh: add __NR_syscalls along with NR_syscalls
>   sh: add system call table generation support
>   sh: generate uapi header and syscall table header files

Gentle reminder!

Could someone review this patch series. I haven't received any
feedback till now.

FYI, this support is only available for 32-bit kernel, not 64-bit
kernel. As I came across the 64-bit kernel is not active for long time.

Thanks
Firoz

>
>  arch/sh/Makefile  |   3 +
>  arch/sh/include/asm/Kbuild|   1 +
>  arch/sh/include/asm/unistd.h  |   2 +
>  arch/sh/include/uapi/asm/Kbuild   |   1 +
>  arch/sh/include/uapi/asm/unistd_32.h  |   4 +-
>  arch/sh/include/uapi/asm/unistd_64.h  |   4 +-
>  arch/sh/kernel/syscalls/Makefile  |  38 
>  arch/sh/kernel/syscalls/syscall.tbl   | 392 
> ++
>  arch/sh/kernel/syscalls/syscallhdr.sh |  36 
>  arch/sh/kernel/syscalls/syscalltbl.sh |  32 +++
>  arch/sh/kernel/syscalls_32.S  | 387 +
>  11 files changed, 514 insertions(+), 386 deletions(-)
>  create mode 100644 arch/sh/kernel/syscalls/Makefile
>  create mode 100644 arch/sh/kernel/syscalls/syscall.tbl
>  create mode 100644 arch/sh/kernel/syscalls/syscallhdr.sh
>  create mode 100644 arch/sh/kernel/syscalls/syscalltbl.sh
>
> --
> 1.9.1
>

Re: [PATCH v5 7/7] tpm: pass an array of tpm_bank_list structures to tpm_pcr_extend()

[Mimi Zohar]

On Sun, 2018-11-18 at 09:27 +0200, Jarkko Sakkinen wrote:
> On Fri, Nov 16, 2018 at 04:55:36PM +0100, Roberto Sassu wrote:
> > On 11/16/2018 4:03 PM, Jarkko Sakkinen wrote:
> > > On Wed, Nov 14, 2018 at 04:31:08PM +0100, Roberto Sassu wrote:
> > > > Currently, tpm_pcr_extend() accepts as an input only a SHA1 digest.
> > > > 
> > > > This patch modifies the definition of tpm_pcr_extend() to allow other
> > > > kernel subsystems to pass a digest for each algorithm supported by the 
> > > > TPM.
> > > > All digests are processed by the TPM in one operation.
> > > > 
> > > > If a tpm_pcr_extend() caller provides a subset of the supported 
> > > > algorithms,
> > > > the TPM driver extends the remaining PCR banks with the first digest
> > > > passed as an argument to the function.
> > > 
> > > What is the legit use case for this?
> > 
> > A subset could be chosen for better performance, or when a TPM algorithm
> > is not supported by the crypto subsystem.
> 
> Doesn't extending a subset a security concern?

Right, so instead of extending a subset of the allocated banks, all of
the allocated banks need to be extended, even for those banks that a
digest was not included.  This is no different than what is being done
today.  IMA is currently only calculating the SHA1 hash, padding the
digest with 0's, and extending the padded value(s) into all of the
allocated banks.

If there is a vulnerability with the hash algorithm, then any bank
extended with the padded/truncated digest would be susceptible.

IMA will need to become TPM 2.0 aware, calculating and extending
multiple banks and define a new measurement list format containing the
multiple digests.

Mimi

Re: [PATCH v5 7/7] tpm: pass an array of tpm_bank_list structures to tpm_pcr_extend()

[Mimi Zohar]

On Sun, 2018-11-18 at 09:27 +0200, Jarkko Sakkinen wrote:
> On Fri, Nov 16, 2018 at 04:55:36PM +0100, Roberto Sassu wrote:
> > On 11/16/2018 4:03 PM, Jarkko Sakkinen wrote:
> > > On Wed, Nov 14, 2018 at 04:31:08PM +0100, Roberto Sassu wrote:
> > > > Currently, tpm_pcr_extend() accepts as an input only a SHA1 digest.
> > > > 
> > > > This patch modifies the definition of tpm_pcr_extend() to allow other
> > > > kernel subsystems to pass a digest for each algorithm supported by the 
> > > > TPM.
> > > > All digests are processed by the TPM in one operation.
> > > > 
> > > > If a tpm_pcr_extend() caller provides a subset of the supported 
> > > > algorithms,
> > > > the TPM driver extends the remaining PCR banks with the first digest
> > > > passed as an argument to the function.
> > > 
> > > What is the legit use case for this?
> > 
> > A subset could be chosen for better performance, or when a TPM algorithm
> > is not supported by the crypto subsystem.
> 
> Doesn't extending a subset a security concern?

Right, so instead of extending a subset of the allocated banks, all of
the allocated banks need to be extended, even for those banks that a
digest was not included.  This is no different than what is being done
today.  IMA is currently only calculating the SHA1 hash, padding the
digest with 0's, and extending the padded value(s) into all of the
allocated banks.

If there is a vulnerability with the hash algorithm, then any bank
extended with the padded/truncated digest would be susceptible.

IMA will need to become TPM 2.0 aware, calculating and extending
multiple banks and define a new measurement list format containing the
multiple digests.

Mimi

Re: [PATCH RFC] hist lookups

[David Miller]

From: Jiri Olsa 
Date: Tue, 13 Nov 2018 11:40:54 +0100

> I pushed/rebased what I have to perf/fixes branch again
> 
> please note I had to change our compile changes, because
> they wouldn't compile on x86, but I can't verify on sparc,
> so you might see some compile fails again

I just checked your current perf/fixes branch.

It builds on Sparc ;-)

And it behaves better too.  I do get tons of drops and lost events,
but it seems to keep going even during the hardest load.

Eventually I end up with a lot of unresolvable histogram entries,
so that is something to look into.

I looked at your drop logic and it seems perfect, we avoid dropping
all non-SAMPLE events which is what we want.  So that can't be the
cause of the issues I am seeing.

Re: [PATCH RFC] hist lookups

[David Miller]

From: Jiri Olsa 
Date: Tue, 13 Nov 2018 11:40:54 +0100

> I pushed/rebased what I have to perf/fixes branch again
> 
> please note I had to change our compile changes, because
> they wouldn't compile on x86, but I can't verify on sparc,
> so you might see some compile fails again

I just checked your current perf/fixes branch.

It builds on Sparc ;-)

And it behaves better too.  I do get tons of drops and lost events,
but it seems to keep going even during the hardest load.

Eventually I end up with a lot of unresolvable histogram entries,
so that is something to look into.

I looked at your drop logic and it seems perfect, we avoid dropping
all non-SAMPLE events which is what we want.  So that can't be the
cause of the issues I am seeing.

Re: [PATCH -next] exportfs: fix 'passing zero to ERR_PTR()' warning

[Al Viro]

On Mon, Nov 19, 2018 at 11:32:41AM +0800, YueHaibing wrote:
> Fix a static code checker warning:
>   fs/exportfs/expfs.c:171 reconnect_one() warn: passing zero to 'ERR_PTR'
> 
> The error path for lookup_one_len_unlocked failure
> should set err to PTR_ERR.
> 
> Fixes: bbf7a8a3562f ("exportfs: move most of reconnect_path to helper 
> function")
> Signed-off-by: YueHaibing 

Applied.

Re: [PATCH -next] exportfs: fix 'passing zero to ERR_PTR()' warning

[Al Viro]

On Mon, Nov 19, 2018 at 11:32:41AM +0800, YueHaibing wrote:
> Fix a static code checker warning:
>   fs/exportfs/expfs.c:171 reconnect_one() warn: passing zero to 'ERR_PTR'
> 
> The error path for lookup_one_len_unlocked failure
> should set err to PTR_ERR.
> 
> Fixes: bbf7a8a3562f ("exportfs: move most of reconnect_path to helper 
> function")
> Signed-off-by: YueHaibing 

Applied.

Re: [PATCH 21/34] kernfs, sysfs, cgroup, intel_rdt: Support fs_context [ver #12]

[Andrei Vagin]

On Fri, Sep 21, 2018 at 05:33:01PM +0100, David Howells wrote:
> Make kernfs support superblock creation/mount/remount with fs_context.
> 
> This requires that sysfs, cgroup and intel_rdt, which are built on kernfs,
> be made to support fs_context also.
> 
> Notes:
> 
>  (1) A kernfs_fs_context struct is created to wrap fs_context and the
>  kernfs mount parameters are moved in here (or are in fs_context).
> 
>  (2) kernfs_mount{,_ns}() are made into kernfs_get_tree().  The extra
>  namespace tag parameter is passed in the context if desired
> 
>  (3) kernfs_free_fs_context() is provided as a destructor for the
>  kernfs_fs_context struct, but for the moment it does nothing except
>  get called in the right places.
> 
>  (4) sysfs doesn't wrap kernfs_fs_context since it has no parameters to
>  pass, but possibly this should be done anyway in case someone wants to
>  add a parameter in future.
> 
>  (5) A cgroup_fs_context struct is created to wrap kernfs_fs_context and
>  the cgroup v1 and v2 mount parameters are all moved there.
> 
>  (6) cgroup1 parameter parsing error messages are now handled by invalf(),
>  which allows userspace to collect them directly.
> 
>  (7) cgroup1 parameter cleanup is now done in the context destructor rather
>  than in the mount/get_tree and remount functions.
> 
> Weirdies:
> 
>  (*) cgroup_do_get_tree() calls cset_cgroup_from_root() with locks held,
>  but then uses the resulting pointer after dropping the locks.  I'm
>  told this is okay and needs commenting.
> 
>  (*) The cgroup refcount web.  This really needs documenting.
> 
>  (*) cgroup2 only has one root?
> 
> Add a suggestion from Thomas Gleixner in which the RDT enablement code is
> placed into its own function.
> 
> Signed-off-by: David Howells 
> cc: Greg Kroah-Hartman 
> cc: Tejun Heo 
> cc: Li Zefan 
> cc: Johannes Weiner 
> cc: cgro...@vger.kernel.org
> cc: fenghua...@intel.com
> ---
> 
>  arch/x86/kernel/cpu/intel_rdt.h  |   15 +
>  arch/x86/kernel/cpu/intel_rdt_rdtgroup.c |  183 ++--
>  fs/kernfs/mount.c|   88 
>  fs/sysfs/mount.c |   67 --
>  include/linux/cgroup.h   |3 
>  include/linux/kernfs.h   |   39 ++-
>  kernel/cgroup/cgroup-internal.h  |   50 +++-
>  kernel/cgroup/cgroup-v1.c|  345 
> --
>  kernel/cgroup/cgroup.c   |  264 +++
>  kernel/cgroup/cpuset.c   |4 
>  10 files changed, 640 insertions(+), 418 deletions(-)
> 
> diff --git a/arch/x86/kernel/cpu/intel_rdt.h b/arch/x86/kernel/cpu/intel_rdt.h
> index 4e588f36228f..1461adc2c5e8 100644
> --- a/arch/x86/kernel/cpu/intel_rdt.h
> +++ b/arch/x86/kernel/cpu/intel_rdt.h
> @@ -33,6 +33,21 @@
>  #define RMID_VAL_ERROR   BIT_ULL(63)
>  #define RMID_VAL_UNAVAIL BIT_ULL(62)
>  
> +
> +struct rdt_fs_context {
> + struct kernfs_fs_contextkfc;
> + boolenable_cdpl2;
> + boolenable_cdpl3;
> + boolenable_mba_mbps;
> +};
> +
> +static inline struct rdt_fs_context *rdt_fc2context(struct fs_context *fc)
> +{
> + struct kernfs_fs_context *kfc = fc->fs_private;
> +
> + return container_of(kfc, struct rdt_fs_context, kfc);
> +}
> +
>  DECLARE_STATIC_KEY_FALSE(rdt_enable_key);
>  
>  /**
> diff --git a/arch/x86/kernel/cpu/intel_rdt_rdtgroup.c 
> b/arch/x86/kernel/cpu/intel_rdt_rdtgroup.c
> index d6cb04c3a28b..34733a221669 100644
> --- a/arch/x86/kernel/cpu/intel_rdt_rdtgroup.c
> +++ b/arch/x86/kernel/cpu/intel_rdt_rdtgroup.c
> @@ -24,6 +24,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -1707,43 +1708,6 @@ static void cdp_disable_all(void)
>   cdpl2_disable();
>  }
>  
> -static int parse_rdtgroupfs_options(char *data)
> -{
> - char *token, *o = data;
> - int ret = 0;
> -
> - while ((token = strsep(, ",")) != NULL) {
> - if (!*token) {
> - ret = -EINVAL;
> - goto out;
> - }
> -
> - if (!strcmp(token, "cdp")) {
> - ret = cdpl3_enable();
> - if (ret)
> - goto out;
> - } else if (!strcmp(token, "cdpl2")) {
> - ret = cdpl2_enable();
> - if (ret)
> - goto out;
> - } else if (!strcmp(token, "mba_MBps")) {
> - ret = set_mba_sc(true);
> - if (ret)
> - goto out;
> - } else {
> - ret = -EINVAL;
> - goto out;
> - }
> - }
> -
> - return 0;
> -
> -out:
> - pr_err("Invalid mount option \"%s\"\n", token);
> -
> - return ret;

Re: [PATCH 21/34] kernfs, sysfs, cgroup, intel_rdt: Support fs_context [ver #12]

[Andrei Vagin]

On Fri, Sep 21, 2018 at 05:33:01PM +0100, David Howells wrote:
> Make kernfs support superblock creation/mount/remount with fs_context.
> 
> This requires that sysfs, cgroup and intel_rdt, which are built on kernfs,
> be made to support fs_context also.
> 
> Notes:
> 
>  (1) A kernfs_fs_context struct is created to wrap fs_context and the
>  kernfs mount parameters are moved in here (or are in fs_context).
> 
>  (2) kernfs_mount{,_ns}() are made into kernfs_get_tree().  The extra
>  namespace tag parameter is passed in the context if desired
> 
>  (3) kernfs_free_fs_context() is provided as a destructor for the
>  kernfs_fs_context struct, but for the moment it does nothing except
>  get called in the right places.
> 
>  (4) sysfs doesn't wrap kernfs_fs_context since it has no parameters to
>  pass, but possibly this should be done anyway in case someone wants to
>  add a parameter in future.
> 
>  (5) A cgroup_fs_context struct is created to wrap kernfs_fs_context and
>  the cgroup v1 and v2 mount parameters are all moved there.
> 
>  (6) cgroup1 parameter parsing error messages are now handled by invalf(),
>  which allows userspace to collect them directly.
> 
>  (7) cgroup1 parameter cleanup is now done in the context destructor rather
>  than in the mount/get_tree and remount functions.
> 
> Weirdies:
> 
>  (*) cgroup_do_get_tree() calls cset_cgroup_from_root() with locks held,
>  but then uses the resulting pointer after dropping the locks.  I'm
>  told this is okay and needs commenting.
> 
>  (*) The cgroup refcount web.  This really needs documenting.
> 
>  (*) cgroup2 only has one root?
> 
> Add a suggestion from Thomas Gleixner in which the RDT enablement code is
> placed into its own function.
> 
> Signed-off-by: David Howells 
> cc: Greg Kroah-Hartman 
> cc: Tejun Heo 
> cc: Li Zefan 
> cc: Johannes Weiner 
> cc: cgro...@vger.kernel.org
> cc: fenghua...@intel.com
> ---
> 
>  arch/x86/kernel/cpu/intel_rdt.h  |   15 +
>  arch/x86/kernel/cpu/intel_rdt_rdtgroup.c |  183 ++--
>  fs/kernfs/mount.c|   88 
>  fs/sysfs/mount.c |   67 --
>  include/linux/cgroup.h   |3 
>  include/linux/kernfs.h   |   39 ++-
>  kernel/cgroup/cgroup-internal.h  |   50 +++-
>  kernel/cgroup/cgroup-v1.c|  345 
> --
>  kernel/cgroup/cgroup.c   |  264 +++
>  kernel/cgroup/cpuset.c   |4 
>  10 files changed, 640 insertions(+), 418 deletions(-)
> 
> diff --git a/arch/x86/kernel/cpu/intel_rdt.h b/arch/x86/kernel/cpu/intel_rdt.h
> index 4e588f36228f..1461adc2c5e8 100644
> --- a/arch/x86/kernel/cpu/intel_rdt.h
> +++ b/arch/x86/kernel/cpu/intel_rdt.h
> @@ -33,6 +33,21 @@
>  #define RMID_VAL_ERROR   BIT_ULL(63)
>  #define RMID_VAL_UNAVAIL BIT_ULL(62)
>  
> +
> +struct rdt_fs_context {
> + struct kernfs_fs_contextkfc;
> + boolenable_cdpl2;
> + boolenable_cdpl3;
> + boolenable_mba_mbps;
> +};
> +
> +static inline struct rdt_fs_context *rdt_fc2context(struct fs_context *fc)
> +{
> + struct kernfs_fs_context *kfc = fc->fs_private;
> +
> + return container_of(kfc, struct rdt_fs_context, kfc);
> +}
> +
>  DECLARE_STATIC_KEY_FALSE(rdt_enable_key);
>  
>  /**
> diff --git a/arch/x86/kernel/cpu/intel_rdt_rdtgroup.c 
> b/arch/x86/kernel/cpu/intel_rdt_rdtgroup.c
> index d6cb04c3a28b..34733a221669 100644
> --- a/arch/x86/kernel/cpu/intel_rdt_rdtgroup.c
> +++ b/arch/x86/kernel/cpu/intel_rdt_rdtgroup.c
> @@ -24,6 +24,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -1707,43 +1708,6 @@ static void cdp_disable_all(void)
>   cdpl2_disable();
>  }
>  
> -static int parse_rdtgroupfs_options(char *data)
> -{
> - char *token, *o = data;
> - int ret = 0;
> -
> - while ((token = strsep(, ",")) != NULL) {
> - if (!*token) {
> - ret = -EINVAL;
> - goto out;
> - }
> -
> - if (!strcmp(token, "cdp")) {
> - ret = cdpl3_enable();
> - if (ret)
> - goto out;
> - } else if (!strcmp(token, "cdpl2")) {
> - ret = cdpl2_enable();
> - if (ret)
> - goto out;
> - } else if (!strcmp(token, "mba_MBps")) {
> - ret = set_mba_sc(true);
> - if (ret)
> - goto out;
> - } else {
> - ret = -EINVAL;
> - goto out;
> - }
> - }
> -
> - return 0;
> -
> -out:
> - pr_err("Invalid mount option \"%s\"\n", token);
> -
> - return ret;

[PATCH] ARM64: dts: meson-gxbb-wetek: fix hwmon temperature sensor output

[Christian Hewitt]

Add  and supporting vddio_ao18 nodes to fix hwmon temperature
readings on the WeTek Hub and Play2 devices. Without these nodes the
temp is reported as 4294967295 degrees C.

Thanks to Martin Blumenstingl for assisting debug and the winning
guess at what was missing.

Signed-off-by: Christian Hewitt 
---
 arch/arm64/boot/dts/amlogic/meson-gxbb-wetek.dtsi | 12 
 1 file changed, 12 insertions(+)

diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-wetek.dtsi 
b/arch/arm64/boot/dts/amlogic/meson-gxbb-wetek.dtsi
index 70325b2..dd12e02 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxbb-wetek.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-wetek.dtsi
@@ -59,6 +59,13 @@
regulator-max-microvolt = <330>;
};
 
+   vddio_ao18: regulator-vddio_ao18 {
+   compatible = "regulator-fixed";
+   regulator-name = "VDDIO_AO18";
+   regulator-min-microvolt = <180>;
+   regulator-max-microvolt = <180>;
+   };
+
vcc_3v3: regulator-vcc_3v3 {
compatible = "regulator-fixed";
regulator-name = "VCC_3V3";
@@ -173,6 +180,11 @@
clock-names = "clkin0";
 };
 
+ {
+   status = "okay";
+   vref-supply = <_ao18>;
+};
+
 /* Wireless SDIO Module */
 _emmc_a {
status = "okay";
-- 
2.7.4

[PATCH] ARM64: dts: meson-gxbb-wetek: fix hwmon temperature sensor output

[Christian Hewitt]

Add  and supporting vddio_ao18 nodes to fix hwmon temperature
readings on the WeTek Hub and Play2 devices. Without these nodes the
temp is reported as 4294967295 degrees C.

Thanks to Martin Blumenstingl for assisting debug and the winning
guess at what was missing.

Signed-off-by: Christian Hewitt 
---
 arch/arm64/boot/dts/amlogic/meson-gxbb-wetek.dtsi | 12 
 1 file changed, 12 insertions(+)

diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-wetek.dtsi 
b/arch/arm64/boot/dts/amlogic/meson-gxbb-wetek.dtsi
index 70325b2..dd12e02 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxbb-wetek.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-wetek.dtsi
@@ -59,6 +59,13 @@
regulator-max-microvolt = <330>;
};
 
+   vddio_ao18: regulator-vddio_ao18 {
+   compatible = "regulator-fixed";
+   regulator-name = "VDDIO_AO18";
+   regulator-min-microvolt = <180>;
+   regulator-max-microvolt = <180>;
+   };
+
vcc_3v3: regulator-vcc_3v3 {
compatible = "regulator-fixed";
regulator-name = "VCC_3V3";
@@ -173,6 +180,11 @@
clock-names = "clkin0";
 };
 
+ {
+   status = "okay";
+   vref-supply = <_ao18>;
+};
+
 /* Wireless SDIO Module */
 _emmc_a {
status = "okay";
-- 
2.7.4

Re: [PATCH] rhashtable: detect when object movement between tables might have invalidated a lookup

[David Miller]

From: Herbert Xu 
Date: Mon, 19 Nov 2018 12:06:34 +0800

> On Mon, Nov 19, 2018 at 11:56:35AM +0800, Herbert Xu wrote:
>>
>> I take that back.  Because of your shift which cancels out the
>> shift in NULLS_MARKER, it would appear that this should work just
>> fine with RHT_NULLS_MARRKER(0), no? IOW, it would appear that
>> 
>>  RHT_NULLS_MARKER(0) = RHT_NULLS_MARKER(RHT_NULLS_MARKER(0))
> 
> My emails to Neil are bouncing:
> 
>   ne...@suse.com
> host smtp.glb1.softwaregrp.com [15.124.2.87]
> SMTP error from remote mail server after RCPT TO::
> 550 Cannot process address

Yeah this just started happening 2 days ago.

Re: [PATCH] rhashtable: detect when object movement between tables might have invalidated a lookup

[David Miller]

From: Herbert Xu 
Date: Mon, 19 Nov 2018 12:06:34 +0800

> On Mon, Nov 19, 2018 at 11:56:35AM +0800, Herbert Xu wrote:
>>
>> I take that back.  Because of your shift which cancels out the
>> shift in NULLS_MARKER, it would appear that this should work just
>> fine with RHT_NULLS_MARRKER(0), no? IOW, it would appear that
>> 
>>  RHT_NULLS_MARKER(0) = RHT_NULLS_MARKER(RHT_NULLS_MARKER(0))
> 
> My emails to Neil are bouncing:
> 
>   ne...@suse.com
> host smtp.glb1.softwaregrp.com [15.124.2.87]
> SMTP error from remote mail server after RCPT TO::
> 550 Cannot process address

Yeah this just started happening 2 days ago.