[GIT PULL] GPIO fixes for the v5.0 series

[Linus Walleij]

Hi Linus,

some final polish for GPIO for v5.0.

Both patches are also tagged for stable.

Please pull them in!

Yours,
Linus Walleij


The following changes since commit 8834f5600cf3c8db365e18a3d5cac2c2780c81e5:

  Linux 5.0-rc5 (2019-02-03 13:48:04 -0800)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio.git
tags/gpio-v5.0-4

for you to fetch changes up to af14b2c98adb85e9517390bb88309338b9075350:

  gpio: pxa: avoid attempting to set pin direction via pinctrl on MMP2
(2019-02-14 10:06:03 +0100)


Two GPIO fixes for the v5.0 series:
- Per-instance irqchip on the MT7621
- Avoid direction setting using pin control on MMP2


Lubomir Rintel (1):
  gpio: pxa: avoid attempting to set pin direction via pinctrl on MMP2

René van Dorst (1):
  gpio: MT7621: use a per instance irq_chip structure

 drivers/gpio/gpio-mt7621.c | 20 ++--
 drivers/gpio/gpio-pxa.c|  1 +
 2 files changed, 11 insertions(+), 10 deletions(-)

Re: [PATCH v1 0/2] rsnd: dts: change to use extended audio dmac register

[Geert Uytterhoeven]

Hi Jiada,

On Wed, Feb 20, 2019 at 6:25 AM Jiada Wang  wrote:
> According to user reference manual for R-CAR H3 and M3-W SoCs,
> in order to access busif4 ~ busif7, extended audio dmac registers
> (PDMASAREn, PDMADAREn, PDMACHCREn)
> need to be used, rather than basic audio dmac registers
> (PDMASARn, PDMADARn, PDMACHCRn)
>
> This patch set updates H3 (= r8a7795) and M3-W (= r8a7796)
> to use extended audio dmac registers

The same change should be applied for M3-N and RZ/G2M, right?

R-Car E3 and RZ/G2E already use the extended register set, as they do not
have the basic set.

For SoCs having both, this feels a bit like describing software policy, instead
of hardware, to me. Would it make sense to extend the audio bindings, and
allow describing both the basic and extended register sets, and let the driver
make the decision which one to use?

Thanks!

Gr{oetje,eeting}s,

Geert


--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

Re: [PATCH v1 2/2] arm64: dts: renesas: r8a7796: use extended audio dmac register

[Geert Uytterhoeven]

On Wed, Feb 20, 2019 at 6:25 AM Jiada Wang  wrote:
> Basic audio dmac register only supports busif from 0 to 3,
> in order to use busif4 ~ busif7, extended audio dmac register
> need to be used
>
> Signed-off-by: Jiada Wang 

Reviewed-by: Geert Uytterhoeven 
but please consider my comments to the cover letter.

Gr{oetje,eeting}s,

Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

Re: [PATCH v1 1/2] arm64: dts: renesas: r8a7795: use extended audio dmac register

[Geert Uytterhoeven]

On Wed, Feb 20, 2019 at 6:25 AM Jiada Wang  wrote:
> Basic audio dmac register only supports busif from 0 to 3,
> in order to use busif4 ~ busif7, extended audio dmac register
> need to be used.
>
> Signed-off-by: Jiada Wang 

Reviewed-by: Geert Uytterhoeven 
but please consider my comments to the cover letter.

Gr{oetje,eeting}s,

Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

Re: [PATCH v2] jffs2: safely remove obsolete dirent from the f->dents list

[Richard Weinberger]

Am Samstag, 16. Februar 2019, 09:53:35 CET schrieb yuyufen:
> ping?

Sorry for the delay.

I didn't forget (completely) about this one.
The thing is, I don't really maintain jffs2 but I will collect and test patches
for the upcoming merge window and carry them via my ubifs tree. 

David, I hope I have by end of the week a list with potential patches ready
such that you can have a final look and veto what you don't like. :-)

Thanks,
//richard
> 
> On 2019/1/23 15:22, Yufen Yu wrote:
> > We may delete a bunch of directory entries, operating such as:
> > getdents(), unlink(), getdents()..., until the end of the directory.
> > jffs2 handles f_pos on the directory merely as the position on the
> > f->dents list. So, the next getdents() may skip some entries
> > before f_pos, if we remove some entries from the list between two
> > getdents(), resulting in some entries of the directory cannot be deleted.
> >
> > Commit 15953580e79b is introduced to resolve this bug by not
> > removing delete entries from the list immediately.
> >
> > However, when CONFIG_JFFS2_SUMMARY is not set, it can cause the
> > following issues:
> >
> > * 'deletion' dirents is always in the f->dents list, wasting memory
> >  resource. For example:
> >  There is a file named 'file1'. Then we rename it:
> >  mv file1 file2;
> >  mv file2 file3;
> >  ...
> >  mv file9 file100
> >
> >  All of file1~file100 dirents always in the f->dents list.
> >
> > * Though, the list we're traversing is already ordered by CRC,
> > it could waste much CPU time when the list is very long.
> >
> > To fix, we define two variables in struct jffs2_inode_info: nr_dir_opening,
> > obsolete_count, and two new functions: jffs2_dir_open(), 
> > jffs2_dir_release().
> >
> > When open a directory, jffs2_dir_open() will increase nr_dir_opening,
> > which will be decreased by jffs2_dir_release(). if the value is 0,
> > it means nobody open the dir and nobody in getdents()/seek() semantics.
> > Thus, we can remove all obsolete dirent from the list.
> >
> > When delete a file, jffs2_do_unlink() can remove the dirent directly if
> > nobody open the directory(i.e. nr_dir_opending == 0). Otherwise, it just
> > increase obsolete_count, denoting obsolete dirent count of the list.
> >
> > Fixes: 15953580e79b ("[JFFS2] Improve getdents vs. f_pos handling on NOR 
> > flash.")
> > Signed-off-by: Yufen Yu 
> > ---
> >   fs/jffs2/dir.c | 49 
> > ++
> >   fs/jffs2/jffs2_fs_i.h  |  7 +++
> >   fs/jffs2/super.c   |  4 
> >   fs/jffs2/write.c   | 30 +++-
> >   include/uapi/linux/jffs2.h |  4 
> >   5 files changed, 85 insertions(+), 9 deletions(-)
> >
> > diff --git a/fs/jffs2/dir.c b/fs/jffs2/dir.c
> > index f20cff1194bb..aed872dcd0ca 100644
> > --- a/fs/jffs2/dir.c
> > +++ b/fs/jffs2/dir.c
> > @@ -37,6 +37,8 @@ static int jffs2_mknod (struct inode *,struct dentry 
> > *,umode_t,dev_t);
> >   static int jffs2_rename (struct inode *, struct dentry *,
> >  struct inode *, struct dentry *,
> >  unsigned int);
> > +static int jffs2_dir_release (struct inode *, struct file *);
> > +static int jffs2_dir_open (struct inode *, struct file *);
> >   
> >   const struct file_operations jffs2_dir_operations =
> >   {
> > @@ -45,6 +47,8 @@ const struct file_operations jffs2_dir_operations =
> > .unlocked_ioctl=jffs2_ioctl,
> > .fsync =jffs2_fsync,
> > .llseek =   generic_file_llseek,
> > +   .open = jffs2_dir_open,
> > +   .release =  jffs2_dir_release,
> >   };
> >   
> >   
> > @@ -865,3 +869,48 @@ static int jffs2_rename (struct inode *old_dir_i, 
> > struct dentry *old_dentry,
> > return 0;
> >   }
> >   
> > +static int jffs2_dir_open(struct inode *dir_i, struct file *filp)
> > +{
> > +#ifndef CONFIG_JFFS2_SUMMARY
> > +   struct jffs2_inode_info *dir_f = JFFS2_INODE_INFO(dir_i);
> > +   atomic_inc(_f->nr_dir_opening);
> > +#endif
> > +
> > +   return 0;
> > +}
> > +
> > +static int jffs2_dir_release(struct inode *dir_i, struct file *filp)
> > +{
> > +#ifndef CONFIG_JFFS2_SUMMARY
> > +   struct jffs2_inode_info *dir_f = JFFS2_INODE_INFO(dir_i);
> > +
> > +   BUG_ON(atomic_read(_f->nr_dir_opening) <= 0);
> > +
> > +   mutex_lock(_f->sem);
> > +   /* jffs2_dir_open may increase nr_dir_opening after
> > +* atomic_dec_and_test() returning true.
> > +* However, it cannot traverse the list until hold
> > +* mutex dir_f->sem lock, so that we can go on
> > +* removing.*/
> > +   if (atomic_dec_and_test(_f->nr_dir_opening) &&
> > +   dir_f->obsolete_count > JFFS2_OBS_DIRENT_LIMIT) {
> > +   struct jffs2_full_dirent **prev = _f->dents;
> > +
> > +   /* remove all obsolete dirent from the list, which
> > +* can save memory space and reduce CPU time for
> > +* traverse the list */
> > +

[GIT PULL] pin control fixes for v5.0

[Linus Walleij]

Hi Linus,

some final pin control fixes (I hope) to round off the v5.0 pin control
development cycle.

Only driver fixes, one for stable.

Please pull them in!

Yours,
Linus Walleij


The following changes since commit d13937116f1e82bf508a6325111b322c30c85eb9:

  Linux 5.0-rc6 (2019-02-10 14:42:20 -0800)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl.git
tags/pinctrl-v5.0-3

for you to fetch changes up to c17abcfa93bf0be5e48bb011607d237ac2bfc839:

  pinctrl: meson: meson8b: fix the sdxc_a data 1..3 pins (2019-02-17
22:24:32 +0100)


Pin control fixes for the v5.0 series:
- Meson8B fixup for the sdc pins
- Fix SDC tile position for Qualcomm QCS404


Bjorn Andersson (1):
  pinctrl: qcom: qcs404: Correct SDC tile

Martin Blumenstingl (1):
  pinctrl: meson: meson8b: fix the sdxc_a data 1..3 pins

 drivers/pinctrl/meson/pinctrl-meson8b.c | 2 +-
 drivers/pinctrl/qcom/pinctrl-qcs404.c   | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

Re: [PATCH 1/2 v2] kprobe: Do not use uaccess functions to access kernel memory that can fault

[Masami Hiramatsu]

On Tue, 19 Feb 2019 14:03:30 -0500
Steven Rostedt  wrote:

> > > Basically, a kprobe is mostly used for debugging what's happening in a
> > > live kernel, to read any address.  
> > 
> > My point is that "any address" is not sufficient to begin with. You
> > need "kernel or user".
> > 
> > Having a flag for what _kind_ of kernel address is ok might then be
> > required for other cases if they might not be ok with following page
> > tables to IO space..
> > 
> 
> Good point. Looks like we should add a new flag for kprobe
> trace parameters, that tell kprobes if the address is expected to be
> user or kernel. That would be good regardless of the duplicate
> meanings, as we could use copy_from_user without touching KERNEL_DS, if
> the probe argument specifically states "this is user space". For
> example, when probing do_sys_open, and you want to read what path string
> was passed into the kernel.
> 
> Masami, thoughts?

Let me ensure what you want. So you want to access a "string" in user-space,
not a data structure? In that case, it is very easy to me. It is enough to
add a "ustring" type to kprobe events. For example, do_sys_opsn's path 
variable is one example. That will be +0(+0(%si)):ustring, and fetcher
finally copy the string using strncpy_from_user() instead of 
strncpy_from_unsafe(). (*)

But if you consider to access a field in a data-structure in user space,
it might need some more work (E.g. ioctl's parameter), becase if the __user
pointer to the data structure is on the memory, we have to dereference 
the address inside kernel using probe_kernel_read(), but after getting 
the data strucutre address, we have to dereference the address with 
copy_from_user().
At this moment, we have no such strong syntax... 

To solve that, maybe we need to introduce something like "back reference"
of arguments in the event, e.g.

p somewhere user_data=+0(%si) field_val=+8(\user_data):u32:user

or

p somewhere +0(%si) field_val=+8(\1):u32:user

This ":user" additional suffix tells kprobe events to change fetching method 
to fetch the data by copy_from_user().

(*) BTW, there is another concern to use _from_user APIs in kprobe. Are those
APIs might sleep??


Thank you,

-- 
Masami Hiramatsu 

RE: [PATCH] arm64: dts: ls1028a: Add Audio DT nodes

[Alison Wang]

Hi, Shawn,

> On Wed, Jan 23, 2019 at 01:21:35PM +0800, Alison Wang wrote:
> > This patch adds Audio DT nodes for LS1028ARDB and LS1028AQDS boards.
> >
> > Signed-off-by: Alison Wang 
> > ---
> >  arch/arm64/boot/dts/freescale/fsl-ls1028a-qds.dts |   62
> 
> >  arch/arm64/boot/dts/freescale/fsl-ls1028a-rdb.dts |   63
> +
> >  arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi|   57
> +++
> >  3 files changed, 182 insertions(+), 0 deletions(-)
> >
> > diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1028a-qds.dts
> b/arch/arm64/boot/dts/freescale/fsl-ls1028a-qds.dts
> > index 14c79f4..139728e 100644
> > --- a/arch/arm64/boot/dts/freescale/fsl-ls1028a-qds.dts
> > +++ b/arch/arm64/boot/dts/freescale/fsl-ls1028a-qds.dts
> > @@ -32,6 +32,49 @@
> > device_type = "memory";
> > reg = <0x0 0x8000 0x1 0x>;
> > };
> > +
> > +   sys_mclk: clock-mclk {
> > +   compatible = "fixed-clock";
> > +   #clock-cells = <0>;
> > +   clock-frequency = <2500>;
> > +   };
> > +
> > +   reg_1p8v: regulator-1p8v {
> > +   compatible = "regulator-fixed";
> > +   regulator-name = "1P8V";
> > +   regulator-min-microvolt = <180>;
> > +   regulator-max-microvolt = <180>;
> > +   regulator-always-on;
> > +   };
> > +
> > 
> > +
> > +   codec: sgtl5000@a {
> > +   #sound-dai-cells = <0>;
> > +   compatible = "fsl,sgtl5000";
> > +   reg = <0xa>;
> > +   VDDA-supply = <_1p8v>;
> > +   VDDIO-supply = <_1p8v>;
> > +   clocks = <_mclk>;
> > +   sclk-strength = <3>;
> 
> What is this property?
[Alison] It is a new property. I have submitted a patch for this new property 
https://lkml.org/lkml/2018/12/25/123. This patch is already merged in 
linux-next.

For other items you mentioned, I will modify them in v2. Thanks a lot for your 
review.


Best Regards,
Alison Wang

[PATCH 0/3] regulator: tps65218: Fix LS3 and add LS2

[Christian Hohnstaedt]

The patch-series fixes issues in the LS3 configuration
and adds support for the LS2 regulator in the tps65218

Christian Hohnstaedt (3):
  regulator: tps65218.c: fix LS3 issues
  dt-bindings: regulator: Add LS2 load switch
  regulator: tps65218: Add support for LS2

 .../devicetree/bindings/regulator/tps65218.txt |  9 +++--
 drivers/regulator/tps65218-regulator.c | 23 +++---
 2 files changed, 23 insertions(+), 9 deletions(-)

-- 
2.7.4

Re: [PATCH] HID: roccat: Mark expected switch fall-through

[Stefan Achatz]

Am Dienstag, den 19.02.2019, 14:16 +0100 schrieb Jiri Kosina:
> On Mon, 11 Feb 2019, Gustavo A. R. Silva wrote:
>
> > In preparation to enabling -Wimplicit-fallthrough, mark switch
> > cases where we are expecting to fall through.
> >
> > This patch fixes the following warning:
> >
> > drivers/hid/hid-roccat-kone.c: In function
> > ‘kone_keep_values_up_to_date’:
> > drivers/hid/hid-roccat-kone.c:784:20: warning: this statement may
> > fall through [-Wimplicit-fallthrough=]
> >kone->actual_dpi = kone->profiles[event->value - 1].
> >~^~~
> >  startup_dpi;
> >  ~~~
> > drivers/hid/hid-roccat-kone.c:786:2: note: here
> >   case kone_mouse_event_osd_profile:
> >   ^~~~
> >
> > Warning level 3 was used: -Wimplicit-fallthrough=3
> >
> > This patch is part of the ongoing efforts to enable
> > -Wimplicit-fallthrough.
> >
> > Signed-off-by: Gustavo A. R. Silva 
> > ---
> >  drivers/hid/hid-roccat-kone.c | 1 +
> >  1 file changed, 1 insertion(+)
> >
> > diff --git a/drivers/hid/hid-roccat-kone.c b/drivers/hid/hid-
> > roccat-kone.c
> > index bf4675a27396..c4dd6162c1d6 100644
> > --- a/drivers/hid/hid-roccat-kone.c
> > +++ b/drivers/hid/hid-roccat-kone.c
> > @@ -783,6 +783,7 @@ static void kone_keep_values_up_to_date(struct
> > kone_device *kone,
> > case kone_mouse_event_switch_profile:
> > kone->actual_dpi = kone->profiles[event->value -
> > 1].
> > startup_dpi;
> > +   /* fall through */
> > case kone_mouse_event_osd_profile:
> > kone->actual_profile = event->value;
> > break;
>
> Stefan, could you please confirm that this is intended behavior?
>
> Thanks,

I already confirmed this 7 months ago but as I see only in a reply to
you.
Yes, this patch is correct.
Stefan

[PATCH 3/3] regulator: tps65218: Add support for LS2

[Christian Hohnstaedt]

Re-use the "tps65218_pmic_*_current_limit()" functions of LS3
and calculate the different required bit-shift by counting the
trailing 0s in "struct regulator_desc.csel_mask"

Signed-off-by: Christian Hohnstaedt 
---
 drivers/regulator/tps65218-regulator.c | 18 +-
 1 file changed, 13 insertions(+), 5 deletions(-)

diff --git a/drivers/regulator/tps65218-regulator.c 
b/drivers/regulator/tps65218-regulator.c
index 5dd559e..95708d3 100644
--- a/drivers/regulator/tps65218-regulator.c
+++ b/drivers/regulator/tps65218-regulator.c
@@ -205,7 +205,8 @@ static int tps65218_pmic_set_input_current_lim(struct 
regulator_dev *dev,
return -EINVAL;
 
return tps65218_set_bits(tps, dev->desc->csel_reg, dev->desc->csel_mask,
-index << 2, TPS65218_PROTECT_L1);
+index << __builtin_ctz(dev->desc->csel_mask),
+TPS65218_PROTECT_L1);
 }
 
 static int tps65218_pmic_set_current_limit(struct regulator_dev *dev,
@@ -224,7 +225,8 @@ static int tps65218_pmic_set_current_limit(struct 
regulator_dev *dev,
return -EINVAL;
 
return tps65218_set_bits(tps, dev->desc->csel_reg, dev->desc->csel_mask,
-index << 2, TPS65218_PROTECT_L1);
+index << __builtin_ctz(dev->desc->csel_mask),
+TPS65218_PROTECT_L1);
 }
 
 static int tps65218_pmic_get_current_limit(struct regulator_dev *dev)
@@ -237,12 +239,13 @@ static int tps65218_pmic_get_current_limit(struct 
regulator_dev *dev)
if (retval < 0)
return retval;
 
-   index = (index & dev->desc->csel_mask) >> 2;
+   index = (index & dev->desc->csel_mask) >>
+__builtin_ctz(dev->desc->csel_mask);
 
return ls3_currents[index];
 }
 
-static struct regulator_ops tps65218_ls3_ops = {
+static struct regulator_ops tps65218_ls23_ops = {
.is_enabled = regulator_is_enabled_regmap,
.enable = tps65218_pmic_enable,
.disable= tps65218_pmic_disable,
@@ -304,8 +307,13 @@ static const struct regulator_desc regulators[] = {
   TPS65218_ENABLE2_LDO1_EN, 0, 0, ldo1_dcdc3_ranges,
   2, 0, 0, TPS65218_REG_SEQ6,
   TPS65218_SEQ6_LDO1_SEQ_MASK),
+   TPS65218_REGULATOR("LS2", "regulator-ls2", TPS65218_LS_2,
+  REGULATOR_CURRENT, tps65218_ls23_ops, 0, 0, 0,
+  TPS65218_REG_ENABLE2, TPS65218_ENABLE2_LS2_EN,
+  TPS65218_REG_CONFIG2, TPS65218_CONFIG2_LS2ILIM_MASK,
+  NULL, 0, 0, 0, 0, 0),
TPS65218_REGULATOR("LS3", "regulator-ls3", TPS65218_LS_3,
-  REGULATOR_CURRENT, tps65218_ls3_ops, 0, 0, 0,
+  REGULATOR_CURRENT, tps65218_ls23_ops, 0, 0, 0,
   TPS65218_REG_ENABLE2, TPS65218_ENABLE2_LS3_EN,
   TPS65218_REG_CONFIG2, TPS65218_CONFIG2_LS3ILIM_MASK,
   NULL, 0, 0, 0, 0, 0),
-- 
2.7.4

[PATCH 1/3] regulator: tps65218.c: fix LS3 issues

[Christian Hohnstaedt]

- Fix list of valid LS3 currents from mA to µA
- Fix selection of min/max microAmps of LS3.
  Selecting one of the configured values as max value now really
  selects it instead of the next lower one

Signed-off-by: Christian Hohnstaedt 
---
 drivers/regulator/tps65218-regulator.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/regulator/tps65218-regulator.c 
b/drivers/regulator/tps65218-regulator.c
index 6209bee..5dd559e 100644
--- a/drivers/regulator/tps65218-regulator.c
+++ b/drivers/regulator/tps65218-regulator.c
@@ -188,7 +188,8 @@ static struct regulator_ops tps65218_ldo1_dcdc34_ops = {
.set_suspend_disable= tps65218_pmic_set_suspend_disable,
 };
 
-static const int ls3_currents[] = { 100, 200, 500, 1000 };
+static const int ls3_currents[] = { 10, 20, 50, 100 };
+
 
 static int tps65218_pmic_set_input_current_lim(struct regulator_dev *dev,
   int lim_uA)
@@ -214,7 +215,7 @@ static int tps65218_pmic_set_current_limit(struct 
regulator_dev *dev,
unsigned int num_currents = ARRAY_SIZE(ls3_currents);
struct tps65218 *tps = rdev_get_drvdata(dev);
 
-   while (index < num_currents && ls3_currents[index] < max_uA)
+   while (index < num_currents && ls3_currents[index] <= max_uA)
index++;
 
index--;
-- 
2.7.4

[PATCH 2/3] dt-bindings: regulator: Add LS2 load switch

[Christian Hohnstaedt]

and change units of LS3 example from microvolt to microamp

Signed-off-by: Christian Hohnstaedt 
---
 Documentation/devicetree/bindings/regulator/tps65218.txt | 9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/regulator/tps65218.txt 
b/Documentation/devicetree/bindings/regulator/tps65218.txt
index 02f0e9b..54aded3 100644
--- a/Documentation/devicetree/bindings/regulator/tps65218.txt
+++ b/Documentation/devicetree/bindings/regulator/tps65218.txt
@@ -71,8 +71,13 @@ tps65218: tps65218@24 {
regulator-always-on;
};
 
+   ls2: regulator-ls2 {
+   regulator-min-microamp = <10>;
+   regulator-max-microamp = <100>;
+   };
+
ls3: regulator-ls3 {
-   regulator-min-microvolt = <10>;
-   regulator-max-microvolt = <100>;
+   regulator-min-microamp = <10>;
+   regulator-max-microamp = <100>;
};
 };
-- 
2.7.4

Re: [RFC PATCH net-next v3 05/21] ethtool: netlink bitset handling

[Michal Kubecek]

On Tue, Feb 19, 2019 at 06:27:59PM -0800, Jakub Kicinski wrote:
> On Mon, 18 Feb 2019 19:21:49 +0100 (CET), Michal Kubecek wrote:
> > +   else if (is_u32)
> > +   bitmap_from_arr32(val, bitmap, nbits);
> > +   else
> > +   bitmap_copy(val, bitmap, nbits);
> > +   nla_for_each_nested(bit_attr, tb[ETHA_BITSET_BITS], rem) {
> > +   *err = ethnl_update_bit(val, mask, nbits, bit_attr,
> > +   is_list, names, legacy, info);
> > +   if (*err < 0)
> > +   goto out_free;
> > +   }
> > +   if (bitmask)
> > +   __bitmap_to_any(bitmask, mask, nbits, is_u32);
> > +   } else {
> > +   unsigned int change_words = DIV_ROUND_UP(change_bits, 32);
> > +
> > +   *err = 0;
> > +   if (change_bits == 0 && tb[ETHA_BITSET_MASK])
> > +   goto out_free;
> > +   *err = -EINVAL;
> > +   if (!tb[ETHA_BITSET_VALUE])
> > +   goto out_free;
> 
> !tb[ETHA_BITSET_BITS] && !tb[ETHA_BITSET_VALUE] is already rejected
> above.

Thank you. I'll drop this test.

Michal

Re: [PATCH] dt-bindings: imx: update scu resource id headfile

[Marco Felsch]

On 19-02-20 03:38, Aisheng Dong wrote:
> [...]
> 
> > > I don't like droping some ID's (e.g. IMX_SC_R_DC_0_CAPTURE0) by mark
> > > them as unused or even worse give them a other meaning. IMHO the
> > > scu-api should be stable since day 1 and the ID's should only be extended.
> > > Marking ID's as deprecated is much better than moving them around.
> > 
> > I agree the SCU APIs should be stable since day 1 and the ID should ONLY be
> > extended, but that is the best cases, the reality is, there are different
> > SoCs/Revision, some revisions may remove the resources ID defined in
> > pre-coded SCU firmware, like the IMX_SC_R_DC_0_CAPTURE0 etc., so SCU APIs
> > removes them after real silicon arrived, now latest SCU firmware marks them
> > as UNUSED, they could be replaced by some other new resources in later new
> > SoC, I am NOT sure, but if it happens, this resource ID table should be 
> > updated
> > anyway, leaving the out-of-date resource ID table there will have issues, 
> > since it
> > is NOT sync with SCU firmware.
> > 
> > So how to resolve such issue? We hope the SCU firmware should be stable
> > since day 1, but the truth is NOT, could be still some updates but NOT very
> > often. And I believe the updates will NOT break old kernel version.

Hi Anson,

Please don't mix the dt-bindings and the kernel related stuff.
Unfortunately the bindings are within the kernel repo which in fact is
great for us kernel developer but the bindings are also used in other
projects such as barebox or other kernels (don't know the BSD guys). So
you can't ensure that your change will break something. Please keep that
in mind.

IMHO solving that issue should be done by the scu firmware. I tought the
scu is a cortex-m4 with a bunch of embedded flash and ram (I don't know
that much about the scu since it is closed/black-boxed). Why do you
don't use a translation table within the scu? As I said earlier I don't
like the redefinition of ID's since they are now part of the dt-bindings.
The bindings can store up to 32bit values which is a large number ;)
IMHO wasting some ID's in favour of stability is a better solution.

Regards,
Marco

> > 
> 
> Please double check with SCU firmware owner what the removed ID are used 
> before?
> Any side effect if removing them.
> 
> And please also check if the combability can be maintained via 
> IMX_SC_RPC_VERSION?
> 
> Regards
> Dong Aisheng
> 
> > Anson.
> > 
> > >
> > > Regards,
> > > Marco
> > >
> > > >
> > > > Anson.
> > > >
> > > > >
> > > > > Regards,
> > > > > Marco
> > > > >
> > > > > > Signed-off-by: Anson Huang 
> > > > > > ---
> > > > > >  include/dt-bindings/firmware/imx/rsrc.h | 39
> > > > > > +++--
> > > > > >  1 file changed, 22 insertions(+), 17 deletions(-)
> > > > > >
> > > > > > diff --git a/include/dt-bindings/firmware/imx/rsrc.h
> > > > > > b/include/dt-bindings/firmware/imx/rsrc.h
> > > > > > index 4481f2d..ad747a8 100644
> > > > > > --- a/include/dt-bindings/firmware/imx/rsrc.h
> > > > > > +++ b/include/dt-bindings/firmware/imx/rsrc.h
> > > > > > @@ -36,15 +36,15 @@
> > > > > >  #define IMX_SC_R_DC_0_BLIT120
> > > > > >  #define IMX_SC_R_DC_0_BLIT221
> > > > > >  #define IMX_SC_R_DC_0_BLIT_OUT 22
> > > > > > -#define IMX_SC_R_DC_0_CAPTURE0 23
> > > > > > -#define IMX_SC_R_DC_0_CAPTURE1 24
> > > > > > +#define IMX_SC_R_PERF  23
> > > > > > +#define IMX_SC_R_UNUSED5   24
> > > > > >  #define IMX_SC_R_DC_0_WARP 25
> > > > > > -#define IMX_SC_R_DC_0_INTEGRAL026
> > > > > > -#define IMX_SC_R_DC_0_INTEGRAL127
> > > > > > +#define IMX_SC_R_UNUSED7   26
> > > > > > +#define IMX_SC_R_UNUSED8   27
> > > > > >  #define IMX_SC_R_DC_0_VIDEO0   28
> > > > > >  #define IMX_SC_R_DC_0_VIDEO1   29
> > > > > >  #define IMX_SC_R_DC_0_FRAC030
> > > > > > -#define IMX_SC_R_DC_0_FRAC131
> > > > > > +#define IMX_SC_R_UNUSED6   31
> > > > > >  #define IMX_SC_R_DC_0  32
> > > > > >  #define IMX_SC_R_GPU_2_PID033
> > > > > >  #define IMX_SC_R_DC_0_PLL_034
> > > > > > @@ -53,17 +53,17 @@
> > > > > >  #define IMX_SC_R_DC_1_BLIT137
> > > > > >  #define IMX_SC_R_DC_1_BLIT238
> > > > > >  #define IMX_SC_R_DC_1_BLIT_OUT 39
> > > > > > -#define IMX_SC_R_DC_1_CAPTURE0 40
> > > > > > -#define IMX_SC_R_DC_1_CAPTURE1 41
> > > > > > +#define IMX_SC_R_UNUSED9   40
> > > > > > +#define IMX_SC_R_UNUSED10  41
> > > > > >  #define IMX_SC_R_DC_1_WARP 42
> > > > > > -#define IMX_SC_R_DC_1_INTEGRAL043
> > > > > > -#define IMX_SC_R_DC_1_INTEGRAL144
> > > > > > +#define IMX_SC_R_UNUSED11  43
> > > > > > +#define IMX_SC_R_UNUSED12  44
> > > > > >  #define IMX_SC_R_DC_1_VIDEO0   45
> > > 

Re: [PATCH v3 5/5] arm64: dts: imx8mq-evk: Enable PCIE0 interface

[Lucas Stach]

Am Dienstag, den 19.02.2019, 17:58 -0800 schrieb Andrey Smirnov:
> Enable PCIE0 interface connected to BCM4356 WiFi/Bluetooth module.
> 
> Signed-off-by: Andrey Smirnov 
> Cc: Shawn Guo 
> Cc: Fabio Estevam 
> Cc: Chris Healy 
> Cc: Lucas Stach 
> 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

Reviewed-by: Lucas Stach 

> ---
>  arch/arm64/boot/dts/freescale/imx8mq-evk.dts | 42 
>  1 file changed, 42 insertions(+)
> 
> diff --git a/arch/arm64/boot/dts/freescale/imx8mq-evk.dts 
> b/arch/arm64/boot/dts/freescale/imx8mq-evk.dts
> index 64a4bfcb..226aeb9791a5 100644
> --- a/arch/arm64/boot/dts/freescale/imx8mq-evk.dts
> +++ b/arch/arm64/boot/dts/freescale/imx8mq-evk.dts
> @@ -31,6 +31,12 @@
>   gpio = < 19 GPIO_ACTIVE_HIGH>;
>   enable-active-high;
>   };
> +
> + pcie0_refclk: pcie0-refclk {
> + compatible = "fixed-clock";
> + #clock-cells = <0>;
> + clock-frequency = <1>;
> + };
>  };
>  
>   {
> @@ -40,6 +46,17 @@
>   status = "okay";
>  };
>  
> + {
> + pinctrl-names = "default";
> + pinctrl-0 = <_wifi_reset>;
> +
> + wl-reg-on {
> + gpio-hog;
> + gpios = <29 GPIO_ACTIVE_HIGH>;
> + output-high;
> + };
> +};
> +
>   {
>   clock-frequency = <10>;
>   pinctrl-names = "default";
> @@ -131,6 +148,18 @@
>   };
>  };
>  
> + {
> + pinctrl-names = "default";
> + pinctrl-0 = <_pcie0>;
> + reset-gpio = < 28 GPIO_ACTIVE_LOW>;
> + clocks = < IMX8MQ_CLK_PCIE1_ROOT>,
> +  < IMX8MQ_CLK_PCIE1_AUX>,
> +  < IMX8MQ_CLK_PCIE1_PHY>,
> +  <_refclk>;
> + clock-names = "pcie", "pcie_aux", "pcie_phy", "pcie_bus";
> + status = "okay";
> +};
> +
>   {
>   pinctrl-names = "default";
>   pinctrl-0 = <_uart1>;
> @@ -195,6 +224,13 @@
>   >;
>   };
>  
> + pinctrl_pcie0: pcie0grp {
> + fsl,pins = <
> + MX8MQ_IOMUXC_I2C4_SCL_PCIE1_CLKREQ_B0x76
> + MX8MQ_IOMUXC_UART4_RXD_GPIO5_IO28   0x16
> + >;
> + };
> +
>   pinctrl_reg_usdhc2: regusdhc2grpgpio {
>   fsl,pins = <
>   MX8MQ_IOMUXC_SD2_RESET_B_GPIO2_IO19 0x41
> @@ -300,4 +336,10 @@
>   MX8MQ_IOMUXC_GPIO1_IO02_WDOG1_WDOG_B0xc6
>   >;
>   };
> +
> + pinctrl_wifi_reset: wifiresetgrp {
> + fsl,pins = <
> + MX8MQ_IOMUXC_UART4_TXD_GPIO5_IO29   0x16
> + >;
> + };
>  };

Re: [PATCH] x86/asm: Pin sensitive CR4 bits

[Dominik Brodowski]

On Tue, Feb 19, 2019 at 04:54:49PM -0800, Kees Cook wrote:
> diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c
> index cb28e98a0659..7e0ea4470f8e 100644
> --- a/arch/x86/kernel/cpu/common.c
> +++ b/arch/x86/kernel/cpu/common.c
> @@ -312,10 +312,16 @@ static __init int setup_disable_smep(char *arg)
>  }
>  __setup("nosmep", setup_disable_smep);
>  
> +volatile unsigned long cr4_pin __ro_after_init;
> +EXPORT_SYMBOL_GPL(cr4_pin);

Where is this export needed?

Thanks,
Dominik

Re: [PATCH] soc: imx: gpcv2: Make use of regmap_read_poll_timeout()

[Lucas Stach]

Am Dienstag, den 19.02.2019, 18:14 -0800 schrieb Andrey Smirnov:
> Replace explicit polling loop with a call to
> regmap_read_poll_timeout() to avoid code repetition. Also fix
> misspelled "failed" while at it.
> 
> Signed-off-by: Andrey Smirnov 
> Cc: Lucas Stach 
> Cc: Chris Healy 
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: linux-kernel@vger.kernel.org

Reviewed-by: Lucas Stach 

> ---
>  drivers/soc/imx/gpcv2.c | 39 ++-
>  1 file changed, 14 insertions(+), 25 deletions(-)
> 
> diff --git a/drivers/soc/imx/gpcv2.c b/drivers/soc/imx/gpcv2.c
> index 176f473127b6..e06bf12a1e4b 100644
> --- a/drivers/soc/imx/gpcv2.c
> +++ b/drivers/soc/imx/gpcv2.c
> @@ -136,8 +136,8 @@ static int imx_gpc_pu_pgc_sw_pxx_req(struct 
> generic_pm_domain *genpd,
>   GPC_PU_PGC_SW_PUP_REQ : GPC_PU_PGC_SW_PDN_REQ;
>   const bool enable_power_control = !on;
>   const bool has_regulator = !IS_ERR(domain->regulator);
> - unsigned long deadline;
>   int i, ret = 0;
> + u32 pxx_req;
>  
>   regmap_update_bits(domain->regmap, GPC_PGC_CPU_MAPPING,
>  domain->bits.map, domain->bits.map);
> @@ -169,30 +169,19 @@ static int imx_gpc_pu_pgc_sw_pxx_req(struct 
> generic_pm_domain *genpd,
>* As per "5.5.9.4 Example Code 4" in IMX7DRM.pdf wait
>* for PUP_REQ/PDN_REQ bit to be cleared
>*/
> - deadline = jiffies + msecs_to_jiffies(1);
> - while (true) {
> - u32 pxx_req;
> -
> - regmap_read(domain->regmap, offset, _req);
> -
> - if (!(pxx_req & domain->bits.pxx))
> - break;
> -
> - if (time_after(jiffies, deadline)) {
> - dev_err(domain->dev, "falied to command PGC\n");
> - ret = -ETIMEDOUT;
> - /*
> -  * If we were in a process of enabling a
> -  * domain and failed we might as well disable
> -  * the regulator we just enabled. And if it
> -  * was the opposite situation and we failed to
> -  * power down -- keep the regulator on
> -  */
> - on = !on;
> - break;
> - }
> -
> - cpu_relax();
> + ret = regmap_read_poll_timeout(domain->regmap, offset, pxx_req,
> +!(pxx_req & domain->bits.pxx),
> +0, USEC_PER_MSEC);
> + if (ret) {
> + dev_err(domain->dev, "failed to command PGC\n");
> + /*
> +  * If we were in a process of enabling a
> +  * domain and failed we might as well disable
> +  * the regulator we just enabled. And if it
> +  * was the opposite situation and we failed to
> +  * power down -- keep the regulator on
> +  */
> + on = !on;
>   }
>  
>   if (enable_power_control)

[PATCH v3 -next] tpm: Fix the type of the return value in calc_tpm2_event_size()

[Yue Haibing]

calc_tpm2_event_size() has an invalid signature because
it returns a 'size_t' where as its signature says that
it returns 'int'.

Cc: 
Fixes: 4d23cc323cdb ("tpm: add securityfs support for TPM 2.0 firmware event 
log")
Suggested-by: Jarkko Sakkinen 
Signed-off-by: Yue Haibing 
---
v3: fix My real name and cc stable
v2: modify patch title and commit message as Jarkko suggested
---
 drivers/char/tpm/eventlog/tpm2.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/char/tpm/eventlog/tpm2.c b/drivers/char/tpm/eventlog/tpm2.c
index d8b7713..f824563 100644
--- a/drivers/char/tpm/eventlog/tpm2.c
+++ b/drivers/char/tpm/eventlog/tpm2.c
@@ -37,8 +37,8 @@
  *
  * Returns size of the event. If it is an invalid event, returns 0.
  */
-static int calc_tpm2_event_size(struct tcg_pcr_event2_head *event,
-   struct tcg_pcr_event *event_header)
+static size_t calc_tpm2_event_size(struct tcg_pcr_event2_head *event,
+  struct tcg_pcr_event *event_header)
 {
struct tcg_efi_specid_event_head *efispecid;
struct tcg_event_field *event_field;
-- 
2.7.0

Re: [PATCH] acpi/nfit: Fix bus command validation

[Johannes Thumshirn]

On 20/02/2019 03:58, Dan Williams wrote:
[...]

>>
>> Tricky code path, eh?
> 
> ioctl path, number one source of bugs / thrash in this subsystem. 2nd
> place, ARS.

Possibly unpopular idea, but should we maybe teach trinity/syzcaller
about these ioctl()s?

Better we find the bugs in a QA like environment than in the filed, I guess?

Byte,
Johannes
-- 
Johannes ThumshirnSUSE Labs Filesystems
jthumsh...@suse.de+49 911 74053 689
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)
Key fingerprint = EC38 9CAB C2C4 F25D 8600 D0D0 0393 969D 2D76 0850

Re: [PATCHv7] x86/kdump: bugfix, make the behavior of crashkernel=X consistent with kaslr

[Borislav Petkov]

On Mon, Feb 18, 2019 at 09:48:20AM +0800, Dave Young wrote:
> It is ideal if kernel can do it automatically, but I'm not sure if
> kernel can predict the swiotlb reserved size automatically.

Do you see how even more absurd this gets?

If the kernel cannot know the swiotlb reserved size automatically, how
is the normal user even supposed to know?!

I see swiotlb_size_or_default() so we have a sane default which we fall
back to. Now where's the problem with that?

-- 
Regards/Gruss,
Boris.

Good mailing practices for 400: avoid top-posting and trim the reply.

Re: [RFC PATCH] mm, memory_hotplug: fix off-by-one in is_pageblock_removable

[Oscar Salvador]

On Mon, Feb 18, 2019 at 07:15:44PM +0100, Michal Hocko wrote:
> From: Michal Hocko 

> Fixes: efad4e475c31 ("mm, memory_hotplug: is_mem_section_removable do not 
> pass the end of a zone")
> Reported-by: 
> Signed-off-by: Michal Hocko 

Looks good to me.
I glanced quickly over the memhotplug code and I did not see any other place
that could trigger the same problem.

Reviewed-by: Oscar Salvador 

-- 
Oscar Salvador
SUSE L3

Re: [PATCH v1 2/2] drm/mediatek: add mipi_tx driver for mt8183

[CK Hu]

Hi, Jitao:

On Tue, 2019-02-19 at 17:14 +0800, Jitao Shi wrote:
> This patch add mt8183 mipi_tx driver.
> And also support other chips that use the same binding and driver.
> 
> Signed-off-by: Jitao Shi 
> ---
>  drivers/gpu/drm/mediatek/mtk_mipi_tx.c|   2 +
>  drivers/gpu/drm/mediatek/mtk_mipi_tx.h|   1 +
>  drivers/gpu/drm/mediatek/mtk_mt8183_mipi_tx.c | 168 ++
>  3 files changed, 171 insertions(+)
>  create mode 100644 drivers/gpu/drm/mediatek/mtk_mt8183_mipi_tx.c
> 
> diff --git a/drivers/gpu/drm/mediatek/mtk_mipi_tx.c 
> b/drivers/gpu/drm/mediatek/mtk_mipi_tx.c
> index fa361c8be8d7..83fb7717d383 100644
> --- a/drivers/gpu/drm/mediatek/mtk_mipi_tx.c
> +++ b/drivers/gpu/drm/mediatek/mtk_mipi_tx.c
> @@ -198,6 +198,8 @@ static const struct of_device_id mtk_mipi_tx_match[] = {
> .data = _mipitx_data },
>   { .compatible = "mediatek,mt8173-mipi-tx",
> .data = _mipitx_data },
> + { .compatible = "mediatek,mt8183-mipi-tx",

This compatible string does not exist in [1], please add it.

[1]
https://www.kernel.org/doc/Documentation/devicetree/bindings/display/mediatek/mediatek%2Cdsi.txt

> +   .data = _mipitx_data },
>   { },
>  };
>  
> diff --git a/drivers/gpu/drm/mediatek/mtk_mipi_tx.h 
> b/drivers/gpu/drm/mediatek/mtk_mipi_tx.h
> index 2d7f05b0d6a7..af83023e81cf 100644
> --- a/drivers/gpu/drm/mediatek/mtk_mipi_tx.h
> +++ b/drivers/gpu/drm/mediatek/mtk_mipi_tx.h
> @@ -47,5 +47,6 @@ unsigned long mtk_mipi_tx_pll_recalc_rate(struct clk_hw *hw,
>  
>  extern const struct mtk_mipitx_data mt2701_mipitx_data;
>  extern const struct mtk_mipitx_data mt8173_mipitx_data;
> +extern const struct mtk_mipitx_data mt8183_mipitx_data;
>  
>  #endif
> diff --git a/drivers/gpu/drm/mediatek/mtk_mt8183_mipi_tx.c 
> b/drivers/gpu/drm/mediatek/mtk_mt8183_mipi_tx.c
> new file mode 100644
> index ..07f70a3cad13
> --- /dev/null
> +++ b/drivers/gpu/drm/mediatek/mtk_mt8183_mipi_tx.c
> @@ -0,0 +1,168 @@
> +/*
> + * Copyright (c) 2015 MediaTek Inc.

2019

> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + */

Please follow the license rule [1].

[1] https://www.kernel.org/doc/html/v4.20/process/license-rules.html

> +
> +#include "mtk_mipi_tx.h"
> +
> +#define MIPITX_LANE_CON  0x000c
> +#define RG_DSI_CPHY_T1DRV_EN BIT(0)
> +#define RG_DSI_ANA_CK_SELBIT(1)
> +#define RG_DSI_PHY_CK_SELBIT(2)
> +#define RG_DSI_CPHY_EN   BIT(3)
> +#define RG_DSI_PHYCK_INV_EN  BIT(4)
> +#define RG_DSI_PWR04_EN  BIT(5)
> +#define RG_DSI_BG_LPF_EN BIT(6)
> +#define RG_DSI_BG_CORE_ENBIT(7)
> +#define RG_DSI_PAD_TIEL_SEL  BIT(8)

Aligned to mt8173_mipi_tx.c, bitwise definition would add one more
'tab'.

> +
> +#define MIPITX_PLL_PWR   0x0028
> +#define MIPITX_PLL_CON0  0x002c
> +#define MIPITX_PLL_CON1  0x0030
> +#define MIPITX_PLL_CON2  0x0034
> +#define MIPITX_PLL_CON3  0x0038
> +#define MIPITX_PLL_CON4  0x003c
> +#define RG_DSI_PLL_IBIAS (3 << 10)
> +
> +#define MIPITX_D2_SW_CTL_EN  0x0144
> +#define MIPITX_D0_SW_CTL_EN  0x0244
> +#define MIPITX_CK_CKMODE_EN  0x0328
> +#define DSI_CK_CKMODE_EN BIT(0)
> +#define MIPITX_CK_SW_CTL_EN  0x0344
> +#define MIPITX_D1_SW_CTL_EN  0x0444
> +#define MIPITX_D3_SW_CTL_EN  0x0544
> +#define DSI_SW_CTL_ENBIT(0)
> +#define AD_DSI_PLL_SDM_PWR_ONBIT(0)
> +#define AD_DSI_PLL_SDM_ISO_ENBIT(1)
> +
> +#define RG_DSI_PLL_ENBIT(4)
> +#define RG_DSI_PLL_POSDIV(0x7 << 8)
> +
> +static int mtk_mipi_tx_pll_prepare(struct clk_hw *hw)
> +{
> + struct mtk_mipi_tx *mipi_tx = mtk_mipi_tx_from_clk_hw(hw);
> + unsigned int txdiv, txdiv0, txdiv1;

txdiv1 is useless, so remove it.

> + u64 pcw;
> + int ret;
> +
> + dev_dbg(mipi_tx->dev, "prepare: %u bps\n", mipi_tx->data_rate);
> +
> + if (mipi_tx->data_rate >= 20) {
> + txdiv = 1;
> + txdiv0 = 0;
> + txdiv1 = 0;
> + } else if (mipi_tx->data_rate >= 10) {
> + txdiv = 2;
> + txdiv0 = 1;
> + txdiv1 = 0;
> + } else if (mipi_tx->data_rate >= 5) {
> + txdiv = 4;
> + txdiv0 = 2;
> + txdiv1 = 0;
> + } else if (mipi_tx->data_rate > 25000) {
> + txdiv = 8;
> + txdiv0 = 3;
> + txdiv1 = 0;
> + } else if (mipi_tx->data_rate >= 12500) {
> + txdiv = 16;
> + txdiv0 = 4;
> + txdiv1 = 0;
> + } else {
> +

[PATCH v2 0/5] lib: rework bitmap_parselist and tests

[Yury Norov]

bitmap_parselist has been evolved from a pretty simple idea for long and
now lacks for refactoring. It is not structured, has nested loops and a
set of opaque-named variables. All this leads to extremely hard
understanding of the code. Once during the optimization of it I missed a
scenario which leads to kernel hangup. Tetsuo Handa spotted this and found
it simpler to rewrite the code instead fixing it. (Though, that attempt
had some flaws.)
https://lkml.org/lkml/2018/4/1/93 

Things are more complicated than they may be because bitmap_parselist()
is part of user interface, and its behavior should not change.

In this patchset 
 - __bitmap_parselist() is reworked (patches 2 and 3);
 - time measurement in test_bitmap_parselist switched to ktime_get
   (patch 4);
 - new tests introduced (patch 5), and
 - bitmap_parselist_user() testing enabled with the same testset as
   bitmap_parselist() (patch 6).

Patch 1 is a fix and may be applied separately.

V1: https://lkml.org/lkml/2018/12/23/50
v2: - use PTR_ERR() and ERR_PTR() where appropriate;
- fix parser logic (last byte of string handling);
- tests for bitmap_parselist_user() in patch 5.

Yury Norov (4):
  bitmap_parselist: don't calculate length of the input string
  bitmap_parselist: move non-parser logic to helpers
  bitmap_parselist: rework input string parser
  lib/test_bitmap: switch test_bitmap_parselist to ktime_get()
  lib/test_bitmap: add testcases for bitmap_parselist
  lib/test_bitmap: add tests for bitmap_parselist_user

 lib/bitmap.c  | 293 ++
 lib/test_bitmap.c |  67 +--
 2 files changed, 245 insertions(+), 115 deletions(-)

-- 
2.17.1

[PATCH 6/6] lib/test_bitmap: add tests for bitmap_parselist_user

[Yury Norov]

Propagate existing bitmap_parselist() tests to bitmap_parselist_user().

Signed-off-by: Yury Norov 
---
 lib/test_bitmap.c | 46 --
 1 file changed, 36 insertions(+), 10 deletions(-)

diff --git a/lib/test_bitmap.c b/lib/test_bitmap.c
index 709424a788ee..d4ecac0da160 100644
--- a/lib/test_bitmap.c
+++ b/lib/test_bitmap.c
@@ -11,6 +11,7 @@
 #include 
 #include 
 #include 
+#include 
 
 static unsigned total_tests __initdata;
 static unsigned failed_tests __initdata;
@@ -278,39 +279,63 @@ static const struct test_bitmap_parselist 
parselist_tests[] __initconst = {
{-EINVAL, "0-\n", NULL, 8, 0},
 };
 
-static void __init test_bitmap_parselist(void)
+static void __init __test_bitmap_parselist(int is_user)
 {
int i;
int err;
ktime_t time;
DECLARE_BITMAP(bmap, 2048);
+   char *mode = is_user ? "_user"  : "";
 
for (i = 0; i < ARRAY_SIZE(parselist_tests); i++) {
 #define ptest parselist_tests[i]
 
-   time = ktime_get();
-   err = bitmap_parselist(ptest.in, bmap, ptest.nbits);
-   time = ktime_get() - time;
+   if (is_user) {
+   mm_segment_t orig_fs = get_fs();
+   size_t len = strlen(ptest.in);
+
+   set_fs(KERNEL_DS);
+   time = ktime_get();
+   err = bitmap_parselist_user(ptest.in, len,
+   bmap, ptest.nbits);
+   time = ktime_get() - time;
+   set_fs(orig_fs);
+   } else {
+   time = ktime_get();
+   err = bitmap_parselist(ptest.in, bmap, ptest.nbits);
+   time = ktime_get() - time;
+   }
 
if (err != ptest.errno) {
-   pr_err("test %d: input is %s, errno is %d, expected 
%d\n",
-   i, ptest.in, err, ptest.errno);
+   pr_err("parselist%s: %d: input is %s, errno is %d, 
expected %d\n",
+   mode, i, ptest.in, err, ptest.errno);
continue;
}
 
if (!err && ptest.expected
 && !__bitmap_equal(bmap, ptest.expected, ptest.nbits)) 
{
-   pr_err("test %d: input is %s, result is 0x%lx, expected 
0x%lx\n",
-   i, ptest.in, bmap[0], *ptest.expected);
+   pr_err("parselist%s: %d: input is %s, result is 0x%lx, 
expected 0x%lx\n",
+   mode, i, ptest.in, bmap[0],
+   *ptest.expected);
continue;
}
 
if (ptest.flags & PARSE_TIME)
-   pr_err("test %d: input is '%s' OK, Time: %llu\n",
-   i, ptest.in, time);
+   pr_err("parselist%s: %d: input is '%s' OK, Time: 
%llu\n",
+   mode, i, ptest.in, time);
}
 }
 
+static void __init test_bitmap_parselist(void)
+{
+   __test_bitmap_parselist(0);
+}
+
+static void __init test_bitmap_parselist_user(void)
+{
+   __test_bitmap_parselist(1);
+}
+
 #define EXP_BYTES  (sizeof(exp) * 8)
 
 static void __init test_bitmap_arr32(void)
@@ -383,6 +408,7 @@ static int __init test_bitmap_init(void)
test_copy();
test_bitmap_arr32();
test_bitmap_parselist();
+   test_bitmap_parselist_user();
test_mem_optimisations();
 
if (failed_tests == 0)
-- 
2.17.1

[PATCH 2/6] bitmap_parselist: move non-parser logic to helpers

[Yury Norov]

Move region checking and setting functionality of __bitmap_parselist()
to helpers.

Signed-off-by: Yury Norov 
---
 lib/bitmap.c | 64 +++-
 1 file changed, 53 insertions(+), 11 deletions(-)

diff --git a/lib/bitmap.c b/lib/bitmap.c
index ad1fb7e6ad0e..307a1b20bead 100644
--- a/lib/bitmap.c
+++ b/lib/bitmap.c
@@ -477,6 +477,42 @@ int bitmap_print_to_pagebuf(bool list, char *buf, const 
unsigned long *maskp,
 }
 EXPORT_SYMBOL(bitmap_print_to_pagebuf);
 
+/*
+ * Region 9-38:4/10 describes the following bitmap structure:
+ * 0  9  1218  38
+ * .......
+ * ^  ^ ^   ^
+ *  start  off   grlenend
+ */
+struct region {
+   unsigned int start;
+   unsigned int off;
+   unsigned int grlen;
+   unsigned int end;
+};
+
+static int bitmap_set_region(const struct region *r,
+   unsigned long *bitmap, int nbits)
+{
+   unsigned int start;
+
+   if (r->end >= nbits)
+   return -ERANGE;
+
+   for (start = r->start; start <= r->end; start += r->grlen)
+   bitmap_set(bitmap, start, min(r->end - start + 1, r->off));
+
+   return 0;
+}
+
+static int bitmap_check_region(const struct region *r)
+{
+   if (r->start > r->end || r->grlen == 0 || r->off > r->grlen)
+   return -EINVAL;
+
+   return 0;
+}
+
 /**
  * __bitmap_parselist - convert list format ASCII string to bitmap
  * @buf: read nul-terminated user string from this buffer
@@ -507,10 +543,11 @@ static int __bitmap_parselist(const char *buf, unsigned 
int buflen,
int nmaskbits)
 {
unsigned int a, b, old_a, old_b;
-   unsigned int group_size, used_size, off;
+   unsigned int group_size, used_size;
int c, old_c, totaldigits, ndigits;
const char __user __force *ubuf = (const char __user __force *)buf;
-   int at_start, in_range, in_partial_range;
+   int at_start, in_range, in_partial_range, ret;
+   struct region r;
 
totaldigits = c = 0;
old_a = old_b = 0;
@@ -599,15 +636,20 @@ static int __bitmap_parselist(const char *buf, unsigned 
int buflen,
/* if no digit is after '-', it's wrong*/
if (at_start && in_range)
return -EINVAL;
-   if (!(a <= b) || group_size == 0 || !(used_size <= group_size))
-   return -EINVAL;
-   if (b >= nmaskbits)
-   return -ERANGE;
-   while (a <= b) {
-   off = min(b - a + 1, used_size);
-   bitmap_set(maskp, a, off);
-   a += group_size;
-   }
+
+   r.start = a;
+   r.off = used_size;
+   r.grlen = group_size;
+   r.end = b;
+
+   ret = bitmap_check_region();
+   if (ret)
+   return ret;
+
+   ret = bitmap_set_region(, maskp, nmaskbits);
+   if (ret)
+   return ret;
+
} while (buflen && c == ',');
return 0;
 }
-- 
2.17.1

[PATCH 3/6] bitmap_parselist: rework input string parser

[Yury Norov]

The requirement for this rework is to keep the __bitmap_parselist()
copy-less and single-pass but make it more readable and maintainable by
splitting into logical parts and removing explicit nested cycles and
opaque local variables.

__bitmap_parselist() can parse userspace inputs and therefore we cannot
use simple_strtoul() to parse numbers.

Signed-off-by: Yury Norov 
---
 lib/bitmap.c | 246 +++
 1 file changed, 148 insertions(+), 98 deletions(-)

diff --git a/lib/bitmap.c b/lib/bitmap.c
index 307a1b20bead..f1c42ee8b8f2 100644
--- a/lib/bitmap.c
+++ b/lib/bitmap.c
@@ -513,6 +513,139 @@ static int bitmap_check_region(const struct region *r)
return 0;
 }
 
+static long get_char(char *c, const char *str, int is_user)
+{
+   if (unlikely(is_user))
+   return __get_user(*c, (const char __force __user *)str);
+
+   *c = *str;
+   return 0;
+}
+
+static const char *bitmap_getnum(unsigned int *num, const char *str,
+   const char *const end, int is_user)
+{
+   unsigned int n = 0;
+   const char *_str;
+   long ret;
+   char c;
+
+   for (_str = str, *num = 0; _str <= end; _str++) {
+   ret = get_char(, _str, is_user);
+   if (ret)
+   return ERR_PTR(ret);
+
+   if (!isdigit(c)) {
+   if (_str == str)
+   return ERR_PTR(-EINVAL);
+
+   return _str;
+   }
+
+   *num = *num * 10 + (c - '0');
+   if (*num < n)
+   return ERR_PTR(-EOVERFLOW);
+
+   n = *num;
+   }
+
+   return _str;
+}
+
+static const char *bitmap_find_region(const char *str,
+   const char *const end, int is_user)
+{
+   long ret;
+   char c;
+
+   for (; str <= end; str++) {
+   ret = get_char(, str, is_user);
+   if (ret)
+   return ERR_PTR(ret);
+
+   /* Unexpected end of line. */
+   if (c == 0 || c == '\n')
+   return NULL;
+
+   /*
+* The format allows commas and whitespases
+* at the beginning of the region, so skip it.
+*/
+   if (!isspace(c) && c != ',')
+   break;
+   }
+
+   return str <= end ? str : NULL;
+}
+
+static const char *bitmap_parse_region(struct region *r, const char *str,
+const char *const end, int is_user)
+{
+   long ret;
+   char c;
+
+   str = bitmap_getnum(>start, str, end, is_user);
+   if (IS_ERR(str))
+   return str;
+
+   ret = get_char(, str, is_user);
+   if (ret)
+   return (char *)ret;
+
+   if (c == 0 || c == '\n') {
+   str = end + 1;
+   goto no_end;
+   }
+
+   if (isspace(c) || c == ',')
+   goto no_end;
+
+   if (c != '-')
+   return ERR_PTR(-EINVAL);
+
+   str = bitmap_getnum(>end, str + 1, end, is_user);
+   if (IS_ERR(str))
+   return str;
+
+   ret = get_char(, str, is_user);
+   if (ret)
+   return ERR_PTR(ret);
+
+   if (c == 0 || c == '\n') {
+   str = end + 1;
+   goto no_pattern;
+   }
+
+   if (isspace(c) || c == ',')
+   goto no_pattern;
+
+   if (c != ':')
+   return ERR_PTR(-EINVAL);
+
+   str = bitmap_getnum(>off, str + 1, end, is_user);
+   if (IS_ERR(str))
+   return str;
+
+   ret = get_char(, str, is_user);
+   if (ret)
+   return (char *)ret;
+
+   if (c != '/')
+   return ERR_PTR(-EINVAL);
+
+   str = bitmap_getnum(>grlen, str + 1, end, is_user);
+
+   return str;
+
+no_end:
+   r->end = r->start;
+no_pattern:
+   r->off = r->end + 1;
+   r->grlen = r->end + 1;
+
+   return str;
+}
+
 /**
  * __bitmap_parselist - convert list format ASCII string to bitmap
  * @buf: read nul-terminated user string from this buffer
@@ -534,113 +667,29 @@ static int bitmap_check_region(const struct region *r)
  *
  * Returns: 0 on success, -errno on invalid input strings. Error values:
  *
- *   - ``-EINVAL``: second number in range smaller than first
+ *   - ``-EINVAL``: wrong region format
  *   - ``-EINVAL``: invalid character in string
  *   - ``-ERANGE``: bit number specified too large for mask
+ *   - ``-EOVERFLOW``: integer overflow in the input parameters
  */
-static int __bitmap_parselist(const char *buf, unsigned int buflen,
+static int __bitmap_parselist(const char *buf, const char *const end,
int is_user, unsigned long *maskp,
int nmaskbits)
 {
-   unsigned int a, b, old_a, old_b;
-   unsigned int group_size, used_size;
-   int c, old_c, totaldigits, ndigits;
-   const char __user __force 

[PATCH 4/6] lib/test_bitmap: switch test_bitmap_parselist to ktime_get()

[Yury Norov]

test_bitmap_parselist currently uses get_cycles which is not
implemented on some platforms, so use ktime_get() instead.

Signed-off-by: Yury Norov 
---
 lib/test_bitmap.c | 9 -
 1 file changed, 4 insertions(+), 5 deletions(-)

diff --git a/lib/test_bitmap.c b/lib/test_bitmap.c
index 6cd7d0740005..b06e0fd3811b 100644
--- a/lib/test_bitmap.c
+++ b/lib/test_bitmap.c
@@ -266,15 +266,15 @@ static void __init test_bitmap_parselist(void)
 {
int i;
int err;
-   cycles_t cycles;
+   ktime_t time;
DECLARE_BITMAP(bmap, 2048);
 
for (i = 0; i < ARRAY_SIZE(parselist_tests); i++) {
 #define ptest parselist_tests[i]
 
-   cycles = get_cycles();
+   time = ktime_get();
err = bitmap_parselist(ptest.in, bmap, ptest.nbits);
-   cycles = get_cycles() - cycles;
+   time = ktime_get() - time;
 
if (err != ptest.errno) {
pr_err("test %d: input is %s, errno is %d, expected 
%d\n",
@@ -291,8 +291,7 @@ static void __init test_bitmap_parselist(void)
 
if (ptest.flags & PARSE_TIME)
pr_err("test %d: input is '%s' OK, Time: %llu\n",
-   i, ptest.in,
-   (unsigned long long)cycles);
+   i, ptest.in, time);
}
 }
 
-- 
2.17.1

[PATCH 5/6] lib/test_bitmap: add testcases for bitmap_parselist

[Yury Norov]

Add tests for non-number character, empty regions, integer overflow.

Signed-off-by: Yury Norov 
---
 lib/test_bitmap.c | 18 +-
 1 file changed, 17 insertions(+), 1 deletion(-)

diff --git a/lib/test_bitmap.c b/lib/test_bitmap.c
index b06e0fd3811b..709424a788ee 100644
--- a/lib/test_bitmap.c
+++ b/lib/test_bitmap.c
@@ -224,7 +224,8 @@ static const unsigned long exp[] __initconst = {
BITMAP_FROM_U64(0x),
BITMAP_FROM_U64(0xfffe),
BITMAP_FROM_U64(0xULL),
-   BITMAP_FROM_U64(0xULL)
+   BITMAP_FROM_U64(0xULL),
+   BITMAP_FROM_U64(0),
 };
 
 static const unsigned long exp2[] __initconst = {
@@ -247,19 +248,34 @@ static const struct test_bitmap_parselist 
parselist_tests[] __initconst = {
{0, "1-31:4/4", [9 * step], 32, 0},
{0, "0-31:1/4,32-63:2/4",   [10 * step], 64, 0},
{0, "0-31:3/4,32-63:4/4",   [11 * step], 64, 0},
+   {0, "  ,,  0-31:3/4  ,, 32-63:4/4  ,,  ",   [11 * step], 64, 0},
 
{0, "0-31:1/4,32-63:2/4,64-95:3/4,96-127:4/4",  exp2, 128, 0},
 
{0, "0-2047:128/256", NULL, 2048, PARSE_TIME},
 
+   {0, "", [12], 8, 0},
+   {0, "\n",   [12], 8, 0},
+   {0, ",,  ,,  , ,  ,",   [12], 8, 0},
+   {0, " ,  ,,  , ,   ",   [12], 8, 0},
+   {0, " ,  ,,  , ,   \n", [12], 8, 0},
+
{-EINVAL, "-1", NULL, 8, 0},
{-EINVAL, "-0", NULL, 8, 0},
{-EINVAL, "10-1", NULL, 8, 0},
{-EINVAL, "0-31:", NULL, 8, 0},
{-EINVAL, "0-31:0", NULL, 8, 0},
+   {-EINVAL, "0-31:0/", NULL, 8, 0},
{-EINVAL, "0-31:0/0", NULL, 8, 0},
{-EINVAL, "0-31:1/0", NULL, 8, 0},
{-EINVAL, "0-31:10/1", NULL, 8, 0},
+   {-EOVERFLOW, "0-98765432123456789:10/1", NULL, 8, 0},
+
+   {-EINVAL, "a-31", NULL, 8, 0},
+   {-EINVAL, "0-a1", NULL, 8, 0},
+   {-EINVAL, "a-31:10/1", NULL, 8, 0},
+   {-EINVAL, "0-31:a/1", NULL, 8, 0},
+   {-EINVAL, "0-\n", NULL, 8, 0},
 };
 
 static void __init test_bitmap_parselist(void)
-- 
2.17.1

[PATCH 1/6] bitmap_parselist: don't calculate length of the input string

[Yury Norov]

bitmap_parselist() calculates length of the input string before passing
it to the __bitmap_parselist(). But the end-of-line condition is checked
for every character in __bitmap_parselist() anyway. So doing it in wrapper
is a simple waste of time.

Signed-off-by: Yury Norov 
---
 lib/bitmap.c | 5 +
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/lib/bitmap.c b/lib/bitmap.c
index 98872e9025da..ad1fb7e6ad0e 100644
--- a/lib/bitmap.c
+++ b/lib/bitmap.c
@@ -614,10 +614,7 @@ static int __bitmap_parselist(const char *buf, unsigned 
int buflen,
 
 int bitmap_parselist(const char *bp, unsigned long *maskp, int nmaskbits)
 {
-   char *nl  = strchrnul(bp, '\n');
-   int len = nl - bp;
-
-   return __bitmap_parselist(bp, len, 0, maskp, nmaskbits);
+   return __bitmap_parselist(bp, UINT_MAX, 0, maskp, nmaskbits);
 }
 EXPORT_SYMBOL(bitmap_parselist);
 
-- 
2.17.1

Re: [PATCH v1 01/12] of: Add bindings of thermtrip for Tegra soctherm

[Wei Ni]

On 20/2/2019 9:22 AM, Eduardo Valentin wrote:
> On Fri, Dec 28, 2018 at 11:28:42AM +0800, Wei Ni wrote:
>>
>>
>> On 28/12/2018 7:06 AM, Rob Herring wrote:
>>> On Tue, Dec 18, 2018 at 03:34:33PM +0800, Wei Ni wrote:
 Add optional property "nvidia,thermtrips".
 If present, these trips will be used as HW shutdown trips,
 and critical trips will be used as SW shutdown trips.

 Signed-off-by: Wei Ni 
 ---
  .../bindings/thermal/nvidia,tegra124-soctherm.txt| 20 
 +---
  1 file changed, 17 insertions(+), 3 deletions(-)

 diff --git 
 a/Documentation/devicetree/bindings/thermal/nvidia,tegra124-soctherm.txt 
 b/Documentation/devicetree/bindings/thermal/nvidia,tegra124-soctherm.txt
 index b6c0ae53d4dc..ab66d6feab4b 100644
 --- 
 a/Documentation/devicetree/bindings/thermal/nvidia,tegra124-soctherm.txt
 +++ 
 b/Documentation/devicetree/bindings/thermal/nvidia,tegra124-soctherm.txt
 @@ -55,10 +55,21 @@ Required properties :
- #cooling-cells: Should be 1. This cooling device only support 
 on/off state.
  See ./thermal.txt for a description of this property.
  
 +Optional properties:
 +- nvidia,thermtrips : When present, this property specifies the 
 temperature at
 +  which the soctherm hardware will assert the thermal trigger signal to 
 the
 +  Power Management IC, which can be configured to reset or shutdown the 
 device.
 +  It is an array of pairs where each pair represents a tsensor id 
 followed by a
 +  temperature in milli Celcius. In the absence of this property the 
 critical
 +  trip point will be used for thermtrip temperature.
 +
  Note:
 -- the "critical" type trip points will be set to SOC_THERM hardware as the
 -shut down temperature. Once the temperature of this thermal zone is higher
 -than it, the system will be shutdown or reset by hardware.
 +- the "critical" type trip points will be used to set the temperature at 
 which
 +the SOC_THERM hardware will assert a thermal trigger if the 
 "nvidia,thermtrips"
 +property is missing. When the thermtrips property is present, the breach 
 of a
 +critical trip point is reported back to the thermal framework to implement
 +software shutdown.
>>>
>>> This hardly seems like a NVidia specific concept. A h/w shutdown 
>>> temperature... Come up with something common.
>>
>> Hi Rob,
>> In current thermal framework, it doesn't support to set h/w shutdown
>> trips, the "critical" trip is used for s/w shutdown. I noticed that in
>> rockchip-thermal driver, it also used "rockchip,hw-tshut-temp" to set
>> h/w shutdown temperature.
> 
> Why a critical trip point cannot be used for your hw shutdown too?

Hi Eduardo,
The thermal framework handle the critical type trip point in
handle_critical_trips(), it will call orderly_poweroff to shutdown
system gracefully.
"
if (trip_type == THERMAL_TRIP_CRITICAL) {
...
if (!power_off_triggered) {
/*
 * Queue a backup emergency shutdown in the event of
 * orderly_poweroff failure
 */
thermal_emergency_poweroff();
orderly_poweroff(true);
power_off_triggered = true;
}
"
And in this change, we added a new property to handle hw shutdown for
Tegra. When trigger the hw shutdown trip point, the hw will cut the
power to poweroff directly. If the temperature is raised very quickly,
the hardware can shutdown system before s/w shutdown.

Thanks.
Wei.

> 
>>
>>>
>>> Also, we already have a temperature table. Why do we need temperatures 
>>> in 2 places.
>>
>> Sorry, what do you mean temperature table? Do you mean the trip nodes?
>>
>> Thanks.
>> Wei.
>>
>>>
 +
  - the "hot" type trip points will be set to SOC_THERM hardware as the 
 throttle
  temperature. Once the the temperature of this thermal zone is higher
  than it, it will trigger the HW throttle event.
 @@ -79,6 +90,9 @@ Example :
  
#thermal-sensor-cells = <1>;
  
 +  nvidia,thermtrips = >>> +   TEGRA124_SOCTHERM_SENSOR_GPU 103000>;
 +
throttle-cfgs {
/*
 * When the "heavy" cooling device triggered,
 -- 
 2.7.4

Re: [PATCH] HID: roccat: Mark expected switch fall-through

[Jiri Kosina]

On Wed, 20 Feb 2019, Stefan Achatz wrote:

> I already confirmed this 7 months ago but as I see only in a reply to
> you.

I guess that fell in between cracks somewhere.

> Yes, this patch is correct.

Applied, thanks.

-- 
Jiri Kosina
SUSE Labs

Re: [PATCH v7 0/3] Fixes for Tegra soctherm

[Wei Ni]

On 20/2/2019 10:14 AM, Zhang Rui wrote:
> On 一, 2019-02-18 at 15:59 +0800, Wei Ni wrote:
>> Rui,
>> Will you take this serial?
>>
> it is already in my tree.
> I missed -rc6, thus I will queue them for 5.1-rc1.

Thanks.
I updated v8 patch per Daniel Lezcano's comment.
Please check it.

Wei.

> 
> thanks,
> rui
> 
>> Thanks.
>> Wei.
>>
>> On 21/1/2019 5:17 PM, Wei Ni wrote:
>>>
>>> Does there have any comments?
>>>
>>> Thanks.
>>> Wei.
>>>
>>> On 11/1/2019 10:20 AM, Wei Ni wrote:

 Hi Eduardo,
 Do you have any more comments, will you take this serial?

 Thanks.
 Wei.

 On 3/1/2019 6:12 PM, Wei Ni wrote:
>
> This series fixed some issues for Tegra soctherm,
> and add get_trend().
>
> Main changes from v6:
> 1. Per Eduardo's comment, we can remove the change:
> "thermal: tegra: parse sensor id before sensor register"
>
> Main changes from v5:
> 1. Move the get_trend() patch https://lkml.org/lkml/2018/11/20/
> 643
> into this serial.
>
> Main changes from v4:
> 1. fixed for the parsing sensor id.
> 2. keep warning for missing critical trips.
>
> Main changes from v3:
> 1. updated codes for parsing sensor id, per Thierry's comments
>
> Main changes from v2:
> 1. add codes to parse sensor id to avoid registration
> failure.
>
> Main changes from v1:
> 1. Acked by Thierry Reding  for the patch
> "thermal: tegra: fix memory allocation".
> 2. Print out the sensor name when register failed.
> 2. Remove patch "thermal: tegra: fix coverity defect"
>
> Wei Ni (3):
>   thermal: tegra: remove unnecessary warnings
>   thermal: tegra: fix memory allocation
>   thermal: tegra: add get_trend ops
>
>  drivers/thermal/tegra/soctherm.c | 40
> +---
>  1 file changed, 37 insertions(+), 3 deletions(-)
>

Re: linux-next: Fixes tag needs some work in the net-next tree

[Jiri Pirko]

Wed, Feb 20, 2019 at 07:48:13AM CET, da...@davemloft.net wrote:
>From: Vinod Koul 
>Date: Wed, 20 Feb 2019 10:10:55 +0530
>
>> On 20-02-19, 09:31, Stephen Rothwell wrote:
>>> Hi all,
>>> 
>>> In commit
>>> 
>>>   a968b5e9d587 ("net: dsa: qca8k: Enable delay for RGMII_ID mode")
>>> 
>>> Fixes tag
>>> 
>>>   Fixes: 40269aa9f40a ("net: dsa: qca8k: disable delay for RGMII mode")
>>> 
>>> has these problem(s):
>>> 
>>>   - Target SHA1 does not exist
>>> 
>>> Did you mean:
>>> 
>>>   Fixes: 5ecdd77c61c8 ("net: dsa: qca8k: disable delay for RGMII mode")
>> 
>> Yes looks like I messed up the commit id.. Not sure why :(
>> 
>> Dave would you like to drop this and me sending updated patch or
>> something else..
>> 
>> Sorry about the miss
>
>Doesn't work that way, something in my tree is there forever.

Would be good to have some robot checking "Fixes" sanity...

Re: [PATCH v2 5/5] base: soc: Export soc_device_register/unregister APIs

[Vaishali Thakkar]

On Wed, 20 Feb 2019 at 12:25, Greg KH  wrote:
>
> On Wed, Feb 20, 2019 at 10:29:46AM +0530, Vaishali Thakkar wrote:
> > From: Vinod Koul 
> >
> > Qcom Socinfo driver can be built as a module, so
> > export these two APIs.
> >
> > Signed-off-by: Vinod Koul 
> > Signed-off-by: Vaishali Thakkar 
> > ---
> > Changes since v1:
> >   - None
>
> This is fixing a build breakage introduced by an earlier patch.  Please
> rearange the patches so that breakage never happens.

Ok, yes. I'll put it as patch two [before adding socinfo driver].

> Also, any chance you can properly "thread" your patches so they all show
> up together?  git send-email does this automatically...

I'm using send-email only but I was sending it one by one. I believe
that's the reason why didn't come as a thread. I'll fix that in next version
too.

> thanks,
>
> greg k-h

Re: [PATCH] reset: Don't WARN if trying to get a used reset control

[Thierry Reding]

On Thu, Feb 07, 2019 at 09:27:51AM +0100, Thierry Reding wrote:
> On Wed, Feb 06, 2019 at 07:12:04PM +0100, Philipp Zabel wrote:
> > On Wed, 2019-02-06 at 17:00 +0100, Thierry Reding wrote:
> [...]
> > > That way we operate on the same reset control, but we wouldn't need to
> > > iterate over all existing reset controls in order to determine whether
> > > we can acquire or not.
> > 
> > How could we decide in reset_control_assert whether the provided rstc is
> > allowed to change the reset line if both rstc handles point to the same
> > struct reset_control?
> 
> The idea was that acquire/release would basically act as lock/unlock for
> the reset control. So consumers would always have to call acquire()
> before assert()/deassert()/reset() and they would be allowed to continue
> only if acquire() returns success. Of course that's something you can
> only enforce during code review, but that's pretty much the same as with
> any type of locking.
> 
> So basically the idea is that if a consumers acquire() call succeeds,
> the acquired flag gets set on the reset control and that consumer
> becomes the only user allowed to modify the reset control. Any other
> consumers would call acquire() and fail because the acquired is already
> true.
> 
> But what you proposed works for me. We can always find constructive ways
> to optimize this later if we need or want to.
> 
> Another possibility would be to keep an additional, separate list of the
> temporarily exclusive resets so that only that list would have to be
> iterated to find the ones that are relevant.
> 
> > > > if (WARN_ON(!rstc->shared || !shared))
> > > > return ERR_PTR(-EBUSY);
> > > 
> > > With the above I think we could just extend this list of conditions with
> > > 
> > >   || acquired
> > > 
> > > and things should work the same. Or perhaps I'm missing something.
> > >
> > > Other than that this really looks like a very nice solution.
> > 
> > Well, apart from the API function names...
> > devm_reset_control_get_optional_exclusive_released(dev, "id");
> > would be a mouthful.
> 
> Yeah, the combinations are somewhat awkward. However, I would expect the
> temporarily exclusive resets to be required in most cases, so that would
> at least make the name a little shorter.

Quick update: I finally had a bit of time to look at this and I've got
something that works. There were a couple of minor issues with the patch
and I had to extend support for acquire/release to reset arrays for this
particular use-case, but overall it seems to be working pretty well.

I'll clean up the patches that I have and then send out for review. It's
unfortunately going to be a bit of a mess staging these changes since
they are spread over three different subsystems and I think there can be
subtle failures between the PMC and SOR patches, so perhaps it'd be best
to apply those to one tree, or maybe even squash the changes into a
single commit to avoid any surprises.

Thierry


signature.asc
Description: PGP signature

[PATCH v2] arm64: dts: ls1028a: Add Audio DT nodes

[Alison Wang]

This patch adds Audio DT nodes for LS1028ARDB and LS1028AQDS boards.

Signed-off-by: Alison Wang 
---
Changes in v2:
 - Modify some nodes' names.
 - Use GIC_SPI and IRQ_TYPE_LEVEL_HIGH.

 arch/arm64/boot/dts/freescale/fsl-ls1028a-qds.dts |   62 
 arch/arm64/boot/dts/freescale/fsl-ls1028a-rdb.dts |   63 +
 arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi|   57 +++
 3 files changed, 182 insertions(+), 0 deletions(-)

diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1028a-qds.dts 
b/arch/arm64/boot/dts/freescale/fsl-ls1028a-qds.dts
index 14c79f4..b359068 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1028a-qds.dts
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1028a-qds.dts
@@ -32,6 +32,49 @@
device_type = "memory";
reg = <0x0 0x8000 0x1 0x>;
};
+
+   sys_mclk: clock-mclk {
+   compatible = "fixed-clock";
+   #clock-cells = <0>;
+   clock-frequency = <2500>;
+   };
+
+   reg_1p8v: regulator-1p8v {
+   compatible = "regulator-fixed";
+   regulator-name = "1P8V";
+   regulator-min-microvolt = <180>;
+   regulator-max-microvolt = <180>;
+   regulator-always-on;
+   };
+
+   sound {
+   compatible = "simple-audio-card";
+   simple-audio-card,format = "i2s";
+   simple-audio-card,widgets =
+   "Microphone", "Microphone Jack",
+   "Headphone", "Headphone Jack",
+   "Speaker", "Speaker Ext",
+   "Line", "Line In Jack";
+   simple-audio-card,routing =
+   "MIC_IN", "Microphone Jack",
+   "Microphone Jack", "Mic Bias",
+   "LINE_IN", "Line In Jack",
+   "Headphone Jack", "HP_OUT",
+   "Speaker Ext", "LINE_OUT";
+
+   simple-audio-card,cpu {
+   sound-dai = <>;
+   frame-master;
+   bitclock-master;
+   };
+
+   simple-audio-card,codec {
+   sound-dai = <>;
+   frame-master;
+   bitclock-master;
+   system-clock-frequency = <2500>;
+   };
+   };
 };
 
  {
@@ -89,5 +132,24 @@
reg = <0x57>;
};
};
+
+   i2c@5 {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   reg = <0x5>;
+
+   sgtl5000: audio-codec@a {
+   #sound-dai-cells = <0>;
+   compatible = "fsl,sgtl5000";
+   reg = <0xa>;
+   VDDA-supply = <_1p8v>;
+   VDDIO-supply = <_1p8v>;
+   clocks = <_mclk>;
+   };
+   };
};
 };
+
+ {
+   status = "okay";
+};
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1028a-rdb.dts 
b/arch/arm64/boot/dts/freescale/fsl-ls1028a-rdb.dts
index fdeb417..50ca51a 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1028a-rdb.dts
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1028a-rdb.dts
@@ -28,6 +28,49 @@
device_type = "memory";
reg = <0x0 0x8000 0x1 0x000>;
};
+
+   sys_mclk: clock-mclk {
+   compatible = "fixed-clock";
+   #clock-cells = <0>;
+   clock-frequency = <2500>;
+   };
+
+   reg_1p8v: regulator-1p8v {
+   compatible = "regulator-fixed";
+   regulator-name = "1P8V";
+   regulator-min-microvolt = <180>;
+   regulator-max-microvolt = <180>;
+   regulator-always-on;
+   };
+
+   sound {
+   compatible = "simple-audio-card";
+   simple-audio-card,format = "i2s";
+   simple-audio-card,widgets =
+   "Microphone", "Microphone Jack",
+   "Headphone", "Headphone Jack",
+   "Speaker", "Speaker Ext",
+   "Line", "Line In Jack";
+   simple-audio-card,routing =
+   "MIC_IN", "Microphone Jack",
+   "Microphone Jack", "Mic Bias",
+   "LINE_IN", "Line In Jack",
+   "Headphone Jack", "HP_OUT",
+   "Speaker Ext", "LINE_OUT";
+
+   simple-audio-card,cpu {
+   sound-dai = <>;
+   frame-master;
+   bitclock-master;
+   };
+
+   simple-audio-card,codec {
+   sound-dai = <>;
+   frame-master;
+   

RE: [PATCH V7 1/4] dt-bindings: fsl: scu: add thermal binding

[Anson Huang]

Best Regards!
Anson Huang

> -Original Message-
> From: Aisheng Dong
> Sent: 2019年2月20日 15:45
> To: Anson Huang ; mark.rutl...@arm.com;
> shawn...@kernel.org; s.ha...@pengutronix.de; ker...@pengutronix.de;
> feste...@gmail.com; catalin.mari...@arm.com; will.dea...@arm.com;
> rui.zh...@intel.com; edubez...@gmail.com; daniel.lezc...@linaro.org;
> ulf.hans...@linaro.org; Daniel Baluta ;
> horms+rene...@verge.net.au; Andy Gross ;
> he...@sntech.de; a...@arndb.de; o...@lixom.net;
> bjorn.anders...@linaro.org; ja...@amarulasolutions.com;
> enric.balle...@collabora.com; marc.w.gonza...@free.fr;
> devicet...@vger.kernel.org; linux-kernel@vger.kernel.org; linux-arm-
> ker...@lists.infradead.org; linux...@vger.kernel.org
> Cc: dl-linux-imx 
> Subject: RE: [PATCH V7 1/4] dt-bindings: fsl: scu: add thermal binding
> 
> > From: Anson Huang
> > Sent: Wednesday, February 20, 2019 2:54 PM
> >
> > NXP i.MX8QXP is an ARMv8 SoC with a Cortex-M4 core inside as system
> > controller, the system controller is in charge of system power, clock
> > and thermal sensors etc. management, Linux kernel has to communicate
> > with system controller via MU (message unit) IPC to get temperature
> > from thermal sensors, this patch adds binding doc for i.MX system
> controller thermal driver.
> >
> > Signed-off-by: Anson Huang 
> > Reviewed-by: Rob Herring 
> > ---
> > Changes since V6:
> > - put "imx,sensor-resource-id" property in thermal zone nodes.
> > ---
> >  .../devicetree/bindings/arm/freescale/fsl,scu.txt  | 27
> > ++
> >  1 file changed, 27 insertions(+)
> >
> > diff --git
> > a/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt
> > b/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt
> > index 72d481c..ad96881 100644
> > --- a/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt
> > +++ b/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt
> > @@ -122,6 +122,27 @@ RTC bindings based on SCU Message Protocol
> > Required properties:
> >  - compatible: should be "fsl,imx8qxp-sc-rtc";
> >
> > +Thermal bindings based on SCU Message Protocol
> > +
> > +
> > +Required properties:
> > +- compatible : Must be "fsl,imx-sc-thermal";
> > +- tsens-num : Total number of thermal sensors supported;
> 
> We properly don't need this property if the number of sensor is fixed on a
> specific SoC.

After further check, I think we can use " for_each_available_child_of_node "
to get every thermal zone's HW resource ID and remove this property.

> 
> > +- #thermal-sensor-cells : Should be 1. See
> > +
> Documentation/devicetree/bindings/thermal/thermal.txt
> > + for a description.
> > +
> > +Required properties for thermal zone nodes:
> > +- imx,sensor-resource-id : This property should be defined in each
> > +thermal
> 
> After a further looking at it, I wonder this property may not needed either.
> 

If we do NOT have such property, we have to do the mapping in driver to get
resource ID, for different SoC, we will have to create different mapping table,
the thermal zone ID given by common thermal framework is virtual ID starting
from 0. Adding this property in thermal zone node is to make SC thermal driver
more generic for other SoCs.

> > zone
> > +  of thermal-zones node, it passes each thermal
> zone's
> > +  resource id for thermal driver to get temperature
> via
> > +  SCU IPC.
> > +
> > +  For thermal zone nodes, please refer to below
> binding
> > +  doc for details:
> > +
> > +[1] Documentation/devicetree/bindings/thermal/thermal.txt
> > +
> >  Example (imx8qxp):
> >  -
> >  lsio_mu1: mailbox@5d1c {
> > @@ -168,6 +189,12 @@ firmware {
> > rtc: rtc {
> > compatible = "fsl,imx8qxp-sc-rtc";
> > };
> > +
> > +   tsens: thermal-sensor {
> > +   compatible = "fsl,imx8qxp-sc-thermal";
> > +   tsens-num = <1>;
> > +   #thermal-sensor-cells = <1>;
> 
> This looks may not correct if sensor cells is 1 but the sensor number Is also 
> 1.
> So we probably better remove tsens-num property.

Yes, this should be 0 if 1 thermal zone ONLY have 1 thermal sensor, later we 
will
add other thermal zone like DDR zone, currently there is still some issues so 
SCFW
does NOT provide support for this zone, after issue fixed, SCFW may add this 
thermal
zone's support. Will fix them in next version.

Thanks,
Anson.

> 
> Regards
> Dong Aisheng
> 
> > +   };
> > };
> >  };
> >
> > --
> > 2.7.4

Re: [PATCH v3 -next] tpm: Fix the type of the return value in calc_tpm2_event_size()

[Jarkko Sakkinen]

On Wed, Feb 20, 2019 at 04:25:38PM +0800, Yue Haibing wrote:
> calc_tpm2_event_size() has an invalid signature because
> it returns a 'size_t' where as its signature says that
> it returns 'int'.
> 
> Cc: 
> Fixes: 4d23cc323cdb ("tpm: add securityfs support for TPM 2.0 firmware event 
> log")
> Suggested-by: Jarkko Sakkinen 
> Signed-off-by: Yue Haibing 
> ---
> v3: fix My real name and cc stable
> v2: modify patch title and commit message as Jarkko suggested

Thanks,

Reviewed-by: Jarkko Sakkinen 

/Jarkko

Re: [tip:x86/cpu] x86/CPU/AMD: Set the CPB bit unconditionally on F17h

[Borislav Petkov]

On Fri, Jan 18, 2019 at 07:48:59AM -0800, tip-bot for Jiaxun Yang wrote:
> Commit-ID:  0237199186e7a4aa5310741f0a6498a20c820fd7
> Gitweb: 
> https://git.kernel.org/tip/0237199186e7a4aa5310741f0a6498a20c820fd7
> Author: Jiaxun Yang 
> AuthorDate: Tue, 20 Nov 2018 11:00:18 +0800
> Committer:  Borislav Petkov 
> CommitDate: Fri, 18 Jan 2019 16:44:03 +0100
> 
> x86/CPU/AMD: Set the CPB bit unconditionally on F17h
> 
> Some F17h models do not have CPB set in CPUID even though the CPU
> supports it. Set the feature bit unconditionally on all F17h.
> 
>  [ bp: Rewrite commit message and patch. ]
> 
> Signed-off-by: Jiaxun Yang 
> Signed-off-by: Borislav Petkov 
> Acked-by: Tom Lendacky 
> Cc: "H. Peter Anvin" 
> Cc: Ingo Molnar 
> Cc: Sherry Hurwitz 
> Cc: Suravee Suthikulpanit 
> Cc: Thomas Gleixner 
> Cc: x86-ml 
> Link: https://lkml.kernel.org/r/20181120030018.5185-1-jiaxun.y...@flygoat.com
> ---
>  arch/x86/kernel/cpu/amd.c | 8 +++-
>  1 file changed, 3 insertions(+), 5 deletions(-)
> 
> diff --git a/arch/x86/kernel/cpu/amd.c b/arch/x86/kernel/cpu/amd.c
> index 69f6bbb41be0..01004bfb1a1b 100644
> --- a/arch/x86/kernel/cpu/amd.c
> +++ b/arch/x86/kernel/cpu/amd.c
> @@ -819,11 +819,9 @@ static void init_amd_bd(struct cpuinfo_x86 *c)
>  static void init_amd_zn(struct cpuinfo_x86 *c)
>  {
>   set_cpu_cap(c, X86_FEATURE_ZEN);
> - /*
> -  * Fix erratum 1076: CPB feature bit not being set in CPUID. It affects
> -  * all up to and including B1.
> -  */
> - if (c->x86_model <= 1 && c->x86_stepping <= 1)
> +
> + /* Fix erratum 1076: CPB feature bit not being set in CPUID. */
> + if (!cpu_has(c, X86_FEATURE_CPB))
>   set_cpu_cap(c, X86_FEATURE_CPB);

Stable folks, please take this one above into those stable trees which
have backported

f7f3dc00f612 ("x86/cpu/AMD: Fix erratum 1076 (CPB bit)")

Thx.

-- 
Regards/Gruss,
Boris.

Good mailing practices for 400: avoid top-posting and trim the reply.

Re: [PATCH] s390/jump_label: Correct asm contraint

[Heiko Carstens]

On Sat, Feb 09, 2019 at 12:34:20PM -0800, Laura Abbott wrote:
> On 2/5/19 12:43 PM, Heiko Carstens wrote:
> >On Tue, Jan 29, 2019 at 08:25:58AM +0100, Laura Abbott wrote:
> >>On 1/23/19 5:24 AM, Heiko Carstens wrote:
> >>>On Wed, Jan 23, 2019 at 01:55:13PM +0100, Laura Abbott wrote:
> There's a build failure with gcc9:
> 
>   ./arch/s390/include/asm/jump_label.h: Assembler messages:
>   ./arch/s390/include/asm/jump_label.h:23: Error: bad expression
>   ./arch/s390/include/asm/jump_label.h:23: Error: junk at end of line, 
>  first unrecognized character is `r'
>   make[1]: *** [scripts/Makefile.build:277: init/main.o] Error 1
> >...
> >>I've had to turn off s390 in Fedora until this gets fixed :(
> >
> >Laura, the patch below should fix this (temporarily). If possible,
> >could you give it a try? It seems to work for me.
> >
> >Subject: [PATCH] s390: disable section anchors
> Tested-by: Laura Abbott <

The patch won't be used. In the meantime Ilya provided a gcc 9 and
kernel patch which should fix this. The kernel patch is available here
https://git.kernel.org/pub/scm/linux/kernel/git/s390/linux.git/commit/?h=features=146448524bddbf6dfc62de31957e428de001cbda
and will go upstream during the next merge window.

Note: this obviously also requires to update the gcc 9 version in
Fedora, so it contains Ilya's patch, to be able to compile the kernel.

Thanks,
Heiko

Re: [PATCH] ARM: dts: sun7i: add pinctrl for missing uart mux options

[Chen-Yu Tsai]

On Sun, Feb 17, 2019 at 2:21 AM Mans Rullgard  wrote:
>
> This adds pinctrl settings for various missing uart options.
>
> Signed-off-by: Mans Rullgard 
> ---
>  arch/arm/boot/dts/sun7i-a20.dtsi | 45 
>  1 file changed, 45 insertions(+)
>
> diff --git a/arch/arm/boot/dts/sun7i-a20.dtsi 
> b/arch/arm/boot/dts/sun7i-a20.dtsi
> index af5b067a5f83..2295ff5adf48 100644
> --- a/arch/arm/boot/dts/sun7i-a20.dtsi
> +++ b/arch/arm/boot/dts/sun7i-a20.dtsi
> @@ -944,6 +944,31 @@
> function = "uart0";
> };
>
> +   uart0_pf_pins: uart0-pf-pins {
> +   pins = "PF2", "PF4";
> +   function = "uart0";
> +   };

We've had the policy of not adding pinctrl nodes that aren't used in-tree,
to avoid bloating up the blob size. However DTC 1.4.7 introduced the new
/omit-if-no-ref/ directive, which would make the compiler discard marked
nodes if they aren't referenced.

So please add this to all the new nodes. It seems to work regardless whether
you add it before or after the label, though having it after the label seems
to make vim syntax highlighting happier.

Regards
ChenYu

Re: [PATCH] x86/nmi: ratelimit unknown nmi logs

[Peter Zijlstra]

On Tue, Feb 19, 2019 at 05:48:36PM -0800, Olof Johansson wrote:
> Getting notified of unknown NMIs is obviously important, but getting
> notified on every single one, especially on larger systems with slow
> (serial) console causes more harm than good when it's a known noisy
> non-relevant event.
> 
> So, let's ratelimit to avoid locking up the system.

What kind of bonghit broken crap system is that?

That is; this _really_ should not happen, and this is a bandaid, not
fixing the cause.

Re: [PATCH v2 1/1] gpio: add driver for Mellanox BlueField GPIO controller

[Bartosz Golaszewski]

wt., 19 lut 2019 o 21:55 Shravan Kumar Ramani  napisał(a):
>
> This patch adds support for the GPIO controller used by Mellanox
> BlueField SOCs.
>

Thanks for addressing the issues. A couple more things I missed the
last time are below.

> Reviewed-by: David Woods 
> Signed-off-by: Shravan Kumar Ramani 
> ---
>  drivers/gpio/Kconfig  |   6 ++
>  drivers/gpio/Makefile |   1 +
>  drivers/gpio/gpio-mlxbf.c | 246 
> ++
>  3 files changed, 253 insertions(+)
>  create mode 100644 drivers/gpio/gpio-mlxbf.c
>
> diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
> index b5a2845..c950fe8 100644
> --- a/drivers/gpio/Kconfig
> +++ b/drivers/gpio/Kconfig
> @@ -1292,6 +1292,12 @@ config GPIO_MERRIFIELD
> help
>   Say Y here to support Intel Merrifield GPIO.
>
> +config GPIO_MLXBF
> +   tristate "Mellanox BlueField SoC GPIO"
> +   depends on (MELLANOX_PLATFORM && ARM64 && ACPI) || COMPILE_TEST
> +   help
> + Say Y here if you want GPIO support on Mellanox BlueField SoC.
> +
>  config GPIO_ML_IOH
> tristate "OKI SEMICONDUCTOR ML7213 IOH GPIO support"
> depends on X86 || COMPILE_TEST
> diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
> index 37628f8..8d54279 100644
> --- a/drivers/gpio/Makefile
> +++ b/drivers/gpio/Makefile
> @@ -83,6 +83,7 @@ obj-$(CONFIG_GPIO_MENZ127)+= gpio-menz127.o
>  obj-$(CONFIG_GPIO_MERRIFIELD)  += gpio-merrifield.o
>  obj-$(CONFIG_GPIO_MC33880) += gpio-mc33880.o
>  obj-$(CONFIG_GPIO_MC9S08DZ60)  += gpio-mc9s08dz60.o
> +obj-$(CONFIG_GPIO_MLXBF)   += gpio-mlxbf.o
>  obj-$(CONFIG_GPIO_ML_IOH)  += gpio-ml-ioh.o
>  obj-$(CONFIG_GPIO_MM_LANTIQ)   += gpio-mm-lantiq.o
>  obj-$(CONFIG_GPIO_MOCKUP)  += gpio-mockup.o
> diff --git a/drivers/gpio/gpio-mlxbf.c b/drivers/gpio/gpio-mlxbf.c
> new file mode 100644
> index 000..bf197aa
> --- /dev/null
> +++ b/drivers/gpio/gpio-mlxbf.c
> @@ -0,0 +1,246 @@
> +// SPDX-License-Identifier: GPL-2.0
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 

The two headers above are not needed - you neither define any module
params nor use any pinctrl consumer API.

> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +/* Number of pins on BlueField */
> +#define MLXBF_GPIO_NR 54

The naming convention for symbols is not consistent. Could you use
mlxbf_gpio_ prefix for all symbols in this driver? Uppercase for
defines and lowercase for functions and structures.

> +
> +/* Pad Electrical Controls. */
> +#define GPIO_PAD_CONTROL__FIRST_WORD 0x0700
> +#define GPIO_PAD_CONTROL_1__FIRST_WORD 0x0708
> +#define GPIO_PAD_CONTROL_2__FIRST_WORD 0x0710
> +#define GPIO_PAD_CONTROL_3__FIRST_WORD 0x0718
> +
> +#define GPIO_PIN_DIR_I 0x1040
> +#define GPIO_PIN_DIR_O 0x1048
> +#define GPIO_PIN_STATE 0x1000
> +#define GPIO_SCRATCHPAD 0x20
> +
> +#ifdef CONFIG_PM
> +struct bluefield_context_save_regs {
> +   u64 gpio_scratchpad;
> +   u64 gpio_pad_control[MLXBF_GPIO_NR];
> +   u64 gpio_pin_dir_i;
> +   u64 gpio_pin_dir_o;
> +};
> +#endif
> +
> +/* Device state structure. */
> +struct gpio_state {
> +   struct gpio_chip gc;
> +
> +   /* Must hold this lock to modify shared data. */
> +   spinlock_t lock;
> +
> +   /* Memory Address */
> +   void __iomem *dc_base;
> +
> +#ifdef CONFIG_PM
> +   struct bluefield_context_save_regs csave_regs;
> +#endif
> +};
> +
> +static int gpio_bf_set_input(struct gpio_chip *chip, unsigned int offset)
> +{
> +   struct gpio_state *gs = gpiochip_get_data(chip);
> +   u64 in;
> +   u64 out;
> +
> +   out = readq(gs->dc_base + GPIO_PIN_DIR_O);
> +   in = readq(gs->dc_base + GPIO_PIN_DIR_I);
> +
> +   writeq(out & ~BIT(offset), gs->dc_base + GPIO_PIN_DIR_O);
> +   writeq(in | BIT(offset), gs->dc_base + GPIO_PIN_DIR_I);
> +
> +   return 0;
> +}
> +
> +static int gpio_bf_set_output(struct gpio_chip *chip, unsigned int offset)
> +{
> +   struct gpio_state *gs = gpiochip_get_data(chip);
> +   u64 in;
> +   u64 out;
> +
> +   out = readq(gs->dc_base + GPIO_PIN_DIR_O);
> +   in = readq(gs->dc_base + GPIO_PIN_DIR_I);
> +
> +   writeq(out | BIT(offset), gs->dc_base + GPIO_PIN_DIR_O);
> +   writeq(in & ~BIT(offset), gs->dc_base + GPIO_PIN_DIR_I);
> +
> +   return 0;
> +}
> +
> +static int gpio_bf_set_output_lock(struct gpio_chip *chip,
> +  unsigned int offset, int value)
> +{
> +   struct gpio_state *gs = gpiochip_get_data(chip);
> +
> +   spin_lock(>lock);
> +   gpio_bf_set_output(chip, offset);

There's no reason to split these functions into locked and unlocked
parts - please merge them.

> +   spin_unlock(>lock);
> +
> +   return 0;
> +}
> +
> +static int gpio_bf_set_input_lock(struct gpio_chip *chip, unsigned int 
> offset)
> +{
> +   struct gpio_state *gs = 

Re: [RFC PATCH v1 10/25] printk: redirect emit/store to new ringbuffer

[Petr Mladek]

On Tue 2019-02-12 15:29:48, John Ogness wrote:
> vprintk_emit and vprintk_store are the main functions that all printk
> variants eventually go through. Change these to store the message in
> the new printk ring buffer that the printk kthread is reading.

We need to switch the two buffers in a single commit
without disabling important functionality.

By other words, we need to change vprintk_emit(), vprintk_store(),
console_unlock(), syslog(), devkmsg(), and syslog in one patch.

The only exception might continuous lines handling. We might
temporary store them right away. It should not break bisectability.

The patch will be huge but I do not see other reasonable solution
at the moment. In each case, the patch should do only
a "straightforward" switch. Any refactoring or logical
changes should be done in preliminary patches.


> Remove functions no longer in use because of the changes to
> vprintk_emit and vprintk_store.
> 
> In order to handle interrupts and NMIs, a second per-cpu ring buffer
> (sprint_rb) is added. This ring buffer is used for NMI-safe memory
> allocation in order to format the printk messages.
> 
> NOTE: LOG_CONT is ignored for now and handled as individual messages.
>   LOG_CONT functions are masked behind "#if 0" blocks until their
>   functionality can be restored
> 
> Signed-off-by: John Ogness 
> ---
>  kernel/printk/printk.c | 319 
> -
>  1 file changed, 51 insertions(+), 268 deletions(-)
> 
> diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
> index 5a5a685bb128..b6a6f1002741 100644
> --- a/kernel/printk/printk.c
> +++ b/kernel/printk/printk.c
> @@ -584,54 +500,36 @@ static int log_store(int facility, int level,
>const char *text, u16 text_len)

>   memcpy(log_dict(msg), dict, dict_len);
>   msg->dict_len = dict_len;
>   msg->facility = facility;
>   msg->level = level & 7;
>   msg->flags = flags & 0x1f;

The existing struct printk_log is stored into the data field
of struct prb_entry. It is because printk_ring_buffer is supposed
to be a generic ring buffer.

It makes the code more complicated. Also it needs more space for
the size and seq items from struct prb_entry.

printk() is already very complicated code. We should not make
it unnecessarily worse.

Please, are there any candidates or plans to reuse the new ring
buffer implementation? For example, would it be usable
for ftrace? Steven?

If not, I would prefer to make it printk-specific
and hopefully simplify the code a bit.


> - if (ts_nsec > 0)
> - msg->ts_nsec = ts_nsec;
> - else
> - msg->ts_nsec = local_clock();
> - memset(log_dict(msg) + dict_len, 0, pad_len);
> + msg->ts_nsec = ts_nsec;
>   msg->len = size;
>  
>   /* insert message */
> - log_next_idx += msg->len;
> - log_next_seq++;
> + prb_commit();
>  
>   return msg->text_len;
>  }

[...]

>  int vprintk_store(int facility, int level,
> const char *dict, size_t dictlen,
> const char *fmt, va_list args)
>  {
> - static char textbuf[LOG_LINE_MAX];
> - char *text = textbuf;
> - size_t text_len;
> + return vprintk_emit(facility, level, dict, dictlen, fmt, args);
> +}
> +
> +/* ring buffer used as memory allocator for temporary sprint buffers */
> +DECLARE_STATIC_PRINTKRB(sprint_rb,
> + ilog2(PRINTK_RECORD_MAX + sizeof(struct prb_entry) +
> +   sizeof(long)) + 2, _cpulock);
> +
> +asmlinkage int vprintk_emit(int facility, int level,
> + const char *dict, size_t dictlen,
> + const char *fmt, va_list args)

[...]

> + rbuf = prb_reserve(, _rb, PRINTK_SPRINT_MAX);

The second ring buffer for temporary buffers is really interesting
idea.

Well, it brings some questions. For example, how many users might
need a reservation in parallel. Or if the nested use might cause
some problems when we decide to use printk-specific ring buffer
implementation. I still have to think about it.


> - /* If called from the scheduler, we can not call up(). */
> - if (!in_sched && pending_output) {
> - /*
> -  * Disable preemption to avoid being preempted while holding
> -  * console_sem which would prevent anyone from printing to
> -  * console
> -  */
> - preempt_disable();
> - /*
> -  * Try to acquire and then immediately release the console
> -  * semaphore.  The release will print out buffers and wake up
> -  * /dev/kmsg and syslog() users.
> -  */
> - if (console_trylock_spinning())
> - console_unlock();
> - preempt_enable();
> - }

I guess that it is clear from the other mails. But to be sure.
This patch should just switch the buffers. The console handling
optimizations/fixes should be done 

[v6 3/3] ahci: qoriq: add lx2160 platforms support

[Peng Ma]

Lx2160a is a new introduced soc which supports ATA3.0

Signed-off-by: Peng Ma 
---
changed for V6:
- Add ecc_initialized to ensure set sata bit once of
ECC error register
- Recovery AHCI_LS2088A platform

 drivers/ata/ahci_qoriq.c |   52 +++---
 1 files changed, 35 insertions(+), 17 deletions(-)

diff --git a/drivers/ata/ahci_qoriq.c b/drivers/ata/ahci_qoriq.c
index ce59253..08dbb86 100644
--- a/drivers/ata/ahci_qoriq.c
+++ b/drivers/ata/ahci_qoriq.c
@@ -58,6 +58,7 @@ enum ahci_qoriq_type {
AHCI_LS1046A,
AHCI_LS1088A,
AHCI_LS2088A,
+   AHCI_LX2160A,
 };
 
 struct ahci_qoriq_priv {
@@ -67,6 +68,8 @@ struct ahci_qoriq_priv {
bool is_dmacoherent;
 };
 
+static bool ecc_initialized;
+
 static const struct of_device_id ahci_qoriq_of_match[] = {
{ .compatible = "fsl,ls1021a-ahci", .data = (void *)AHCI_LS1021A},
{ .compatible = "fsl,ls1043a-ahci", .data = (void *)AHCI_LS1043A},
@@ -74,6 +77,7 @@ struct ahci_qoriq_priv {
{ .compatible = "fsl,ls1046a-ahci", .data = (void *)AHCI_LS1046A},
{ .compatible = "fsl,ls1088a-ahci", .data = (void *)AHCI_LS1088A},
{ .compatible = "fsl,ls2088a-ahci", .data = (void *)AHCI_LS2088A},
+   { .compatible = "fsl,lx2160a-ahci", .data = (void *)AHCI_LX2160A},
{},
 };
 MODULE_DEVICE_TABLE(of, ahci_qoriq_of_match);
@@ -165,9 +169,10 @@ static int ahci_qoriq_phy_init(struct ahci_host_priv 
*hpriv)
 
switch (qpriv->type) {
case AHCI_LS1021A:
-   if (!qpriv->ecc_addr)
+   if (!(qpriv->ecc_addr || ecc_initialized))
return -EINVAL;
-   writel(SATA_ECC_DISABLE, qpriv->ecc_addr);
+   else if (qpriv->ecc_addr && !ecc_initialized)
+   writel(SATA_ECC_DISABLE, qpriv->ecc_addr);
writel(AHCI_PORT_PHY_1_CFG, reg_base + PORT_PHY1);
writel(LS1021A_PORT_PHY2, reg_base + PORT_PHY2);
writel(LS1021A_PORT_PHY3, reg_base + PORT_PHY3);
@@ -180,10 +185,12 @@ static int ahci_qoriq_phy_init(struct ahci_host_priv 
*hpriv)
break;
 
case AHCI_LS1043A:
-   if (!qpriv->ecc_addr)
+   if (!(qpriv->ecc_addr || ecc_initialized))
return -EINVAL;
-   writel(readl(qpriv->ecc_addr) | ECC_DIS_ARMV8_CH2,
-   qpriv->ecc_addr);
+   else if (qpriv->ecc_addr && !ecc_initialized)
+   writel(readl(qpriv->ecc_addr) |
+  ECC_DIS_ARMV8_CH2,
+  qpriv->ecc_addr);
writel(AHCI_PORT_PHY_1_CFG, reg_base + PORT_PHY1);
writel(AHCI_PORT_PHY2_CFG, reg_base + PORT_PHY2);
writel(AHCI_PORT_PHY3_CFG, reg_base + PORT_PHY3);
@@ -202,10 +209,12 @@ static int ahci_qoriq_phy_init(struct ahci_host_priv 
*hpriv)
break;
 
case AHCI_LS1046A:
-   if (!qpriv->ecc_addr)
+   if (!(qpriv->ecc_addr || ecc_initialized))
return -EINVAL;
-   writel(readl(qpriv->ecc_addr) | ECC_DIS_ARMV8_CH2,
-   qpriv->ecc_addr);
+   else if (qpriv->ecc_addr && !ecc_initialized)
+   writel(readl(qpriv->ecc_addr) |
+  ECC_DIS_ARMV8_CH2,
+  qpriv->ecc_addr);
writel(AHCI_PORT_PHY_1_CFG, reg_base + PORT_PHY1);
writel(AHCI_PORT_PHY2_CFG, reg_base + PORT_PHY2);
writel(AHCI_PORT_PHY3_CFG, reg_base + PORT_PHY3);
@@ -215,10 +224,13 @@ static int ahci_qoriq_phy_init(struct ahci_host_priv 
*hpriv)
break;
 
case AHCI_LS1088A:
-   if (!qpriv->ecc_addr)
+   case AHCI_LX2160A:
+   if (!(qpriv->ecc_addr || ecc_initialized))
return -EINVAL;
-   writel(readl(qpriv->ecc_addr) | ECC_DIS_LS1088A,
-  qpriv->ecc_addr);
+   else if (qpriv->ecc_addr && !ecc_initialized)
+   writel(readl(qpriv->ecc_addr) |
+  ECC_DIS_LS1088A,
+  qpriv->ecc_addr);
writel(AHCI_PORT_PHY_1_CFG, reg_base + PORT_PHY1);
writel(AHCI_PORT_PHY2_CFG, reg_base + PORT_PHY2);
writel(AHCI_PORT_PHY3_CFG, reg_base + PORT_PHY3);
@@ -237,6 +249,7 @@ static int ahci_qoriq_phy_init(struct ahci_host_priv *hpriv)
break;
}
 
+   ecc_initialized = true;
return 0;
 }
 
@@ -264,13 +277,18 @@ static int ahci_qoriq_probe(struct platform_device *pdev)
 
qoriq_priv->type = (enum ahci_qoriq_type)of_id->data;
 
-   res = platform_get_resource_byname(pdev, IORESOURCE_MEM,
-   "sata-ecc");
-   if (res) {
-   qoriq_priv->ecc_addr = 

[v6 1/3] dt-bindings: ahci-fsl-qoriq: add lx2160a chip name to the list

[Peng Ma]

Add lx2160a compatible to bindings documentation.

Signed-off-by: Peng Ma 
---
changed for V6:
- no changed 

 .../devicetree/bindings/ata/ahci-fsl-qoriq.txt |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/Documentation/devicetree/bindings/ata/ahci-fsl-qoriq.txt 
b/Documentation/devicetree/bindings/ata/ahci-fsl-qoriq.txt
index 7c3ca0e..9ecc019 100644
--- a/Documentation/devicetree/bindings/ata/ahci-fsl-qoriq.txt
+++ b/Documentation/devicetree/bindings/ata/ahci-fsl-qoriq.txt
@@ -3,7 +3,7 @@ Binding for Freescale QorIQ AHCI SATA Controller
 Required properties:
   - reg: Physical base address and size of the controller's register area.
   - compatible: Compatibility string. Must be 'fsl,-ahci', where
-chip could be ls1021a, ls1043a, ls1046a, ls1088a, ls2080a etc.
+chip could be ls1021a, ls1043a, ls1046a, ls1088a, ls2080a, lx2160a, etc.
   - clocks: Input clock specifier. Refer to common clock bindings.
   - interrupts: Interrupt specifier. Refer to interrupt binding.
 
-- 
1.7.1

[v6 2/3] arm64: dts: lx2160a: add sata node support

[Peng Ma]

Add SATA device nodes for fsl-lx2160a and enable support
for QDS and RDB boards.

Signed-off-by: Peng Ma 
---
changed for V6:
- no change

 arch/arm64/boot/dts/freescale/fsl-lx2160a-qds.dts |   16 +++
 arch/arm64/boot/dts/freescale/fsl-lx2160a-rdb.dts |   16 +++
 arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi|   44 +
 3 files changed, 76 insertions(+), 0 deletions(-)

diff --git a/arch/arm64/boot/dts/freescale/fsl-lx2160a-qds.dts 
b/arch/arm64/boot/dts/freescale/fsl-lx2160a-qds.dts
index 99a22ab..1a5acf6 100644
--- a/arch/arm64/boot/dts/freescale/fsl-lx2160a-qds.dts
+++ b/arch/arm64/boot/dts/freescale/fsl-lx2160a-qds.dts
@@ -95,6 +95,22 @@
};
 };
 
+ {
+   status = "okay";
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   status = "okay";
+};
+
  {
status = "okay";
 };
diff --git a/arch/arm64/boot/dts/freescale/fsl-lx2160a-rdb.dts 
b/arch/arm64/boot/dts/freescale/fsl-lx2160a-rdb.dts
index 6481e5f..5b6799e 100644
--- a/arch/arm64/boot/dts/freescale/fsl-lx2160a-rdb.dts
+++ b/arch/arm64/boot/dts/freescale/fsl-lx2160a-rdb.dts
@@ -102,6 +102,22 @@
};
 };
 
+ {
+   status = "okay";
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   status = "okay";
+};
+
  {
status = "okay";
 };
diff --git a/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi 
b/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi
index a79f5c1..592034b 100644
--- a/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi
@@ -671,6 +671,50 @@
status = "disabled";
};
 
+   sata0: sata@320 {
+   compatible = "fsl,lx2160a-ahci";
+   reg = <0x0 0x320 0x0 0x1>,
+ <0x7 0x100520 0x0 0x4>;
+   reg-names = "ahci", "sata-ecc";
+   interrupts = ;
+   clocks = < 4 3>;
+   dma-coherent;
+   status = "disabled";
+   };
+
+   sata1: sata@321 {
+   compatible = "fsl,lx2160a-ahci";
+   reg = <0x0 0x321 0x0 0x1>,
+ <0x7 0x100520 0x0 0x4>;
+   reg-names = "ahci", "sata-ecc";
+   interrupts = ;
+   clocks = < 4 3>;
+   dma-coherent;
+   status = "disabled";
+   };
+
+   sata2: sata@322 {
+   compatible = "fsl,lx2160a-ahci";
+   reg = <0x0 0x322 0x0 0x1>,
+ <0x7 0x100520 0x0 0x4>;
+   reg-names = "ahci", "sata-ecc";
+   interrupts = ;
+   clocks = < 4 3>;
+   dma-coherent;
+   status = "disabled";
+   };
+
+   sata3: sata@323 {
+   compatible = "fsl,lx2160a-ahci";
+   reg = <0x0 0x323 0x0 0x1>,
+ <0x7 0x100520 0x0 0x4>;
+   reg-names = "ahci", "sata-ecc";
+   interrupts = ;
+   clocks = < 4 3>;
+   dma-coherent;
+   status = "disabled";
+   };
+
smmu: iommu@500 {
compatible = "arm,mmu-500";
reg = <0 0x500 0 0x80>;
-- 
1.7.1

Re: [PATCH 4.20 00/92] 4.20.11-stable review

[Greg Kroah-Hartman]

On Tue, Feb 19, 2019 at 09:39:11AM -0800, Guenter Roeck wrote:
> On 2/18/19 5:42 AM, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 4.20.11 release.
> > There are 92 patches in this series, all will be posted as a response
> > to this one.  If anyone has any issues with these being applied, please
> > let me know.
> > 
> > Responses should be made by Wed Feb 20 13:34:25 UTC 2019.
> > Anything received after that time might be too late.
> > 
> 
> Build results:
>   total: 159 pass: 156 fail: 3
> Failed builds:
>   csky:defconfig
>   csky:allnoconfig
>   csky:tinyconfig
> Qemu test results:
>   total: 343 pass: 343 fail: 0
> 
> 
> Building csky:defconfig ... failed
> --
> Error log:
> mm/memory.c: In function ‘__pte_alloc’:
> mm/memory.c:406:18: error: too many arguments to function ‘pte_alloc_one’
> 
> Commit d6caf1d0d553 ("csky: fixup compile error with pte_alloc")
> (upstream patch 2a60aa14a9a) needs to be removed; the offending patch
> is not in v4.20.y.
> 
> The automatic scripts seem to be a bit too aggressive.

Thanks for finding this.  I'll drop it before I do the release.  And
thanks for testing all of these and letting me know.

greg k-h

Re: [PATCH v3 1/9] s390: vfio_ap: link the vfio_ap devices to the vfio_ap bus subsystem

[Cornelia Huck]

On Tue, 19 Feb 2019 17:27:05 -0500
Tony Krowiak  wrote:

> On 2/18/19 11:57 AM, Cornelia Huck wrote:
> > On Mon, 18 Feb 2019 11:35:45 -0500
> > Tony Krowiak  wrote:
> >   
> >> On 2/18/19 7:01 AM, Cornelia Huck wrote:  
> >>> On Fri, 15 Feb 2019 16:59:33 -0500
> >>> Tony Krowiak  wrote:
> >>>  
>  On 2/15/19 4:11 AM, Cornelia Huck wrote:  
> > On Thu, 14 Feb 2019 13:30:59 -0500
> > Tony Krowiak  wrote:
> > 
> >> On 2/14/19 12:36 PM, Pierre Morel wrote:  
> >>> On 14/02/2019 17:57, Cornelia Huck wrote:  
> >>>  
>  (And reading further in the current code, it seems we clear that
>  structure _after_ the matrix device had been setup, so how can that
>  even work? Where am I confused?)  
> >>>
> >>> On device_register there were no bus, so the core just do not look 
> >>> for a
> >>> driver and this field was nor tested nor overwritten.  
> >
> > Hm... so has the callback in driver_for_each_device() in
> > vfio_ap_verify_queue_reserved() ever been invoked at all? It seems this
> > patch fixes more than just libudev issues...  
> 
>  It is this patch that rendered the driver_for_each_device() in
>  vfio_ap_verify_queue_reserved() erroneous. That function gets called
>  every time an adapter or domain is assigned to the mdev. This patch
>  introduced the problem with driver_for_each_device().  
> >>>
> >>> So, does this function need to be removed or called from another place,
> >>> then? (It looks like it was dead code before.)  
> >>
> >> I don't see why you think it's dead code:
> >>
> >> assign_adapter_store  
> >> ==> vfio_ap_mdev_verify_queues_reserved_for_apid
> >>   ==> vfio_ap_verify_queue_reserved
> >>   ==> driver_for_each_device  
> >>
> >> The only way that the vfio_ap_verify_queue_reserved - the function that
> >> calls driver_for_each_device - does not get called is if no bits have
> >> yet been set in matrix_mdev->matrix.aqm.  
> > 
> > What I don't see is how this can be called if no device has been, in
> > fact, bound to the driver in the driver core...  
> 
> Let's start with the fact that one can create an mdev device regardless
> of whether a queue has been bound to the vfio_ap driver. Once an mdev
> device is created, one can start assigning adapters, domains and control
> domains to it. Let's say the admin now attempts to assign an adapter, in
> which case the assign_adapter_store() function is invoked. After
> verifying that the APID passed in is a valid adapter number, the
> vfio_ap_mdev_verify_queues_reserved_for_apid() function is called.
> This function first checks if any domains have been assigned and if not,
> calls vfio_ap_verify_queue_reserved(, NULL). It is in this function
> that the driver_for_each_device() function is called. Since there are
> no devices bound to the vfio_ap device driver, the callback passed in to
> the driver_for_each_device() function will never get called, so the
> vfio_ap_mdev_verify_queues_reserved_for_apid() function will return
> -EADDRNOTAVAIL. A similar flow will occur if the first assignment is for
> a domain. The bottom line is, the driver_for_each_device() function is
> called every time an adapter or domain is assigned.

Indeed. I just got lost with the various drivers and devices in play
here :(

Re: [PATCH] ARM: dts: sun7i: add pinctrl for missing uart mux options

[Maxime Ripard]

On Wed, Feb 20, 2019 at 04:58:49PM +0800, Chen-Yu Tsai wrote:
> On Sun, Feb 17, 2019 at 2:21 AM Mans Rullgard  wrote:
> >
> > This adds pinctrl settings for various missing uart options.
> >
> > Signed-off-by: Mans Rullgard 
> > ---
> >  arch/arm/boot/dts/sun7i-a20.dtsi | 45 
> >  1 file changed, 45 insertions(+)
> >
> > diff --git a/arch/arm/boot/dts/sun7i-a20.dtsi 
> > b/arch/arm/boot/dts/sun7i-a20.dtsi
> > index af5b067a5f83..2295ff5adf48 100644
> > --- a/arch/arm/boot/dts/sun7i-a20.dtsi
> > +++ b/arch/arm/boot/dts/sun7i-a20.dtsi
> > @@ -944,6 +944,31 @@
> > function = "uart0";
> > };
> >
> > +   uart0_pf_pins: uart0-pf-pins {
> > +   pins = "PF2", "PF4";
> > +   function = "uart0";
> > +   };
> 
> We've had the policy of not adding pinctrl nodes that aren't used in-tree,
> to avoid bloating up the blob size. However DTC 1.4.7 introduced the new
> /omit-if-no-ref/ directive, which would make the compiler discard marked
> nodes if they aren't referenced.
> 
> So please add this to all the new nodes. It seems to work regardless whether
> you add it before or after the label, though having it after the label seems
> to make vim syntax highlighting happier.

It also works (both for dtc and vim) if we put it on the previous
line, so something like:

/omit-if-no-ref/
uart0_pf_pins: uart0-pf-pins {
};

And it does have the advantage of keeping the same line width, which
could get pretty long on some nodes.

Maxime

-- 
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com


signature.asc
Description: PGP signature

RE: [PATCH v4 2/2] irqchip: Add support for Renesas RZ/N1 GPIO interrupt multiplexer

[Phil Edworthy]

Hi Marc

On 19 February 2019 20:29 Marc Zyngier wrote:
> On Tue, 19 Feb 2019 15:55:11 + Phil Edworthy wrote:
> 
> + LinusW, who seem to have taken an interest in irqchip hierarchies...
> 
> > On RZ/N1 devices, there are 3 Synopsys DesignWare GPIO blocks each
> > configured to have 32 interrupt outputs, so we have a total of 96 GPIO
> > interrupts. All of these are passed to the GPIO IRQ Muxer, which
> > selects
> > 8 of the GPIO interrupts to pass onto the GIC. The interrupt signals
> > aren't latched, so there is nothing to do in this driver when an
> > interrupt is received, other than tell the corresponding GPIO block.
> >
> > Signed-off-by: Phil Edworthy 
> > ---
> > v4:
> >  - No change.
> > v3:
> >  - Use 'interrupt-map' DT property to map the interrupts, this is very 
> > similar
> >to PCIe MSI. The only difference is that we need to get hold of the
> interrupt
> >specifier for the interupts coming into the irqmux.
> >  - Do not use a chained interrupt controller.
> > v2:
> >  - Use interrupt-map to allow the GPIO controller info to be specified
> >as part of the irq.
> >  - Renamed struct and funcs from 'girq' to a more comprehenisble 'irqmux'.
> > ---
> >  drivers/irqchip/Kconfig|   9 ++
> >  drivers/irqchip/Makefile   |   1 +
> >  drivers/irqchip/rzn1-irq-mux.c | 205
> > +
> >  3 files changed, 215 insertions(+)
> >  create mode 100644 drivers/irqchip/rzn1-irq-mux.c
> >
> > diff --git a/drivers/irqchip/Kconfig b/drivers/irqchip/Kconfig index
> > 5dcb5456cd14..369f78d6b521 100644
> > --- a/drivers/irqchip/Kconfig
> > +++ b/drivers/irqchip/Kconfig
> > @@ -211,6 +211,15 @@ config RENESAS_IRQC
> > select GENERIC_IRQ_CHIP
> > select IRQ_DOMAIN
> >
> > +config RENESAS_RZN1_IRQ_MUX
> > +   bool "Renesas RZ/N1 GPIO IRQ multiplexer support"
> > +   depends on ARCH_RZN1
> > +   select IRQ_DOMAIN
> > +   help
> > + Say yes here to add support for the GPIO IRQ multiplexer
> embedded
> > + in Renesas RZ/N1 SoC devices. The GPIO IRQ Muxer selects which of
> > + the interrupts coming from the GPIO controllers are used.
> > +
> >  config ST_IRQCHIP
> > bool
> > select REGMAP
> > diff --git a/drivers/irqchip/Makefile b/drivers/irqchip/Makefile index
> > 7acd0e36d0b4..2edd42ef2182 100644
> > --- a/drivers/irqchip/Makefile
> > +++ b/drivers/irqchip/Makefile
> > @@ -46,6 +46,7 @@ obj-$(CONFIG_JCORE_AIC)   +=
> irq-jcore-aic.o
> >  obj-$(CONFIG_RDA_INTC) += irq-rda-intc.o
> >  obj-$(CONFIG_RENESAS_INTC_IRQPIN)  += irq-renesas-intc-irqpin.o
> >  obj-$(CONFIG_RENESAS_IRQC) += irq-renesas-irqc.o
> > +obj-$(CONFIG_RENESAS_RZN1_IRQ_MUX) += rzn1-irq-mux.o
> >  obj-$(CONFIG_VERSATILE_FPGA_IRQ)   += irq-versatile-fpga.o
> >  obj-$(CONFIG_ARCH_NSPIRE)  += irq-zevio.o
> >  obj-$(CONFIG_ARCH_VT8500)  += irq-vt8500.o
> > diff --git a/drivers/irqchip/rzn1-irq-mux.c
> > b/drivers/irqchip/rzn1-irq-mux.c new file mode 100644 index
> > ..ee7810b9b3f3
> > --- /dev/null
> > +++ b/drivers/irqchip/rzn1-irq-mux.c
> > @@ -0,0 +1,205 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +/*
> > + * RZ/N1 GPIO Interrupt Multiplexer
> > + *
> > + * Copyright (C) 2018 Renesas Electronics Europe Limited
> > + *
> > + * On RZ/N1 devices, there are 3 Synopsys DesignWare GPIO blocks each
> > +configured
> > + * to have 32 interrupt outputs, so we have a total of 96 GPIO interrupts.
> > + * All of these are passed to the GPIO IRQ Muxer, which selects 8 of
> > +the GPIO
> > + * interrupts to pass onto the GIC.
> 
> So that I get it right:
> 
> - 96 inputs
> - 8 outputs
> 
> This driver picks 8 of the inputs (and at most 8), and pass then down to the
> GIC. Do I understand that correctly?
Correct.

> > + */
> > +
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +
> > +#define MAX_NR_INPUT_IRQS  96
> > +#define MAX_NR_OUTPUT_IRQS 8
> > +
> > +/*
> > + * "interrupt-map" consists of 1 interrupt cell, 0 address cells,
> > +phandle to
> > + * interrupt parent, and parent interrupt specifier (3 cells for
> > +GIC), giving
> > + * a total of 5 cells.
> > + */
> > +#define IMAP_LENGTH5
> 
> Although the maths do check out, I find it rather dangerous. The versatile
> nature of DT makes me say that sooner or later, someone is going to punt
> this in front of something that will need more than 3 interrupt cells for the
> parent irqchip, and things will be...
> interesting. Even GICv3 in some configuration requires 4 cells.
> 
> You've been warned! ;-)
Warning noted! I would like to think that no one does this in HW again,
though history suggests otherwise.

> > +
> > +struct irqmux_priv;
> > +struct irqmux_one {
> > +   unsigned int irq;
> > +   unsigned int src_hwirq;
> > +   struct irqmux_priv *priv;
> > +};
> > +
> > +struct irqmux_priv {
> > +   struct device *dev;
> > +   struct irq_domain *irq_domain;
> > +   unsigned int 

Re: [PATCH 1/3] dt-bindings: dmaengine: Add one new cell to present hardware slave id

[Arnd Bergmann]

On Wed, Feb 20, 2019 at 4:13 AM Baolin Wang  wrote:
> On Tue, 19 Feb 2019 at 20:20, Vinod Koul  wrote:
> > On 19-02-19, 17:49, Baolin Wang wrote:
> > > On Tue, 19 Feb 2019 at 17:30, Geert Uytterhoeven  
> > > wrote:
> > > > On Tue, Feb 19, 2019 at 4:15 AM Baolin Wang  
> > > > wrote:
> > > > > On Mon, 18 Feb 2019 at 20:23, Arnd Bergmann  wrote:
> > > > > > On Mon, Feb 18, 2019 at 11:52 AM Baolin Wang 
> > > > > >  wrote:
> > > > > > > On Mon, 18 Feb 2019 at 18:31, Arnd Bergmann  wrote:
> > > > > > I did understand the need for a slave-id, I was instead wondering 
> > > > > > about
> > > > > > the channel-id number. On many SoCs, all channels are equal, and you
> > > > > > just have to pick one of those with the right capabilities for a 
> > > > > > particular
> > > > > > slave.
> > > > >
> > > > > Yes, all channels are equal. We just set a unique slave id for the
> > > > > channel for a particular slave. For example, the SPI slave can use
> > > > > channel 10 for tx transfer by setting slave id 11, or it also can use
> > > > > channel 9 for tx transfer by setting same slave id 11.
> > > >
> > > > So the channel selection is software policy, not hardware description, 
> > > > and
> > > > thus doesn't belong in DT?
> > > >
> > > > Can't the DMA engine driver allocate channels dynamically, removing the
> > > > need to specify this in DT?
> > >
> > > In theory we can do as you suggested. But we still want to
> > > manage/assign the DMA channel resources manually for one SoC, we can
> > > make sure some important DMA slaves (such as audio)  can request a DMA
> > > channel at runtime firstly, another benefit is that it is easy to
> > > debug since we can easily know which channel is assigned for this
> > > slave.
> >
> > Are  you suggesting that you have more users than channels available?
>
> Until now we have not met this issue, but we can not make sure if this
> can happen in future. Moreover DMA channel resources are belonging to
> the DMA engine's hardware resources, I think it should be described in
> DT like many other drivers did.

As far as I can tell, most platforms do not describe the assignment
of resources in DT for dma engines, the numbers in there are meant to
describe whatever is fixed, and most platforms should do it that way.

The naming is sometimes a bit confusing, as a dma request line
assignment can be called a slave-id or a channel-id depending whose
documentation you read. The drivers/dma/virt-dma.c implementation
is used in some cases to represent request numbers as virtual
channels, so a dmaengine driver can allow one dma_request_chan()
per slave, and then assign the hardware channels dynamically
while doing a transfer, rather than having a fixed channel assignment
when we first ask for a channel.

   Arnd

RE: [v5 2/2] arm64: dts: lx2160a: add sata node support

[Peng Ma]

Hi Yousaf,

To set sata bit of ecc-addr will affect all sata controllers, The v6 patch has 
been sent will fixed the remap error when two or more sata controllers be 
probed, please review.
Thanks.

Best Regards,
Peng
>-Original Message-
>From: Peng Ma
>Sent: 2019年2月14日 17:19
>To: 'Mian Yousaf Kaukab' 
>Cc: ax...@kernel.dk; shawn...@kernel.org; robh...@kernel.org;
>mark.rutl...@arm.com; Leo Li ;
>linux-...@vger.kernel.org; devicet...@vger.kernel.org;
>linux-kernel@vger.kernel.org; linux-arm-ker...@lists.infradead.org; Andy Tang
>
>Subject: RE: [v5 2/2] arm64: dts: lx2160a: add sata node support
>
>
>
>>-Original Message-
>>From: Mian Yousaf Kaukab 
>>Sent: 2019年2月13日 3:01
>>To: Peng Ma 
>>Cc: ax...@kernel.dk; shawn...@kernel.org; robh...@kernel.org;
>>mark.rutl...@arm.com; Leo Li ;
>>linux-...@vger.kernel.org; devicet...@vger.kernel.org;
>>linux-kernel@vger.kernel.org; linux-arm-ker...@lists.infradead.org;
>>Andy Tang 
>>Subject: Re: [v5 2/2] arm64: dts: lx2160a: add sata node support
>>
>>On Fri, Jan 25, 2019 at 08:10:13AM +, Peng Ma wrote:
>>> Add SATA device nodes for fsl-lx2160a and enable support for QDS and
>>> RDB boards.
>>>
>>> Signed-off-by: Peng Ma 
>>> ---
>>> changed for V5:
>>> - no change
>>>
>>>  arch/arm64/boot/dts/freescale/fsl-lx2160a-qds.dts |   16 +++
>>>  arch/arm64/boot/dts/freescale/fsl-lx2160a-rdb.dts |   16 +++
>>>  arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi|   44
>>+
>>>  3 files changed, 76 insertions(+), 0 deletions(-)
>>>
>>> diff --git a/arch/arm64/boot/dts/freescale/fsl-lx2160a-qds.dts
>>> b/arch/arm64/boot/dts/freescale/fsl-lx2160a-qds.dts
>>> index 99a22ab..1a5acf6 100644
>>> --- a/arch/arm64/boot/dts/freescale/fsl-lx2160a-qds.dts
>>> +++ b/arch/arm64/boot/dts/freescale/fsl-lx2160a-qds.dts
>>> @@ -95,6 +95,22 @@
>>> };
>>>  };
>>>
>>> + {
>>> +   status = "okay";
>>> +};
>>> +
>>> + {
>>> +   status = "okay";
>>> +};
>>> +
>>> + {
>>> +   status = "okay";
>>> +};
>>> +
>>> + {
>>> +   status = "okay";
>>> +};
>>> +
>>>   {
>>> status = "okay";
>>>  };
>>> diff --git a/arch/arm64/boot/dts/freescale/fsl-lx2160a-rdb.dts
>>> b/arch/arm64/boot/dts/freescale/fsl-lx2160a-rdb.dts
>>> index 6481e5f..5b6799e 100644
>>> --- a/arch/arm64/boot/dts/freescale/fsl-lx2160a-rdb.dts
>>> +++ b/arch/arm64/boot/dts/freescale/fsl-lx2160a-rdb.dts
>>> @@ -102,6 +102,22 @@
>>> };
>>>  };
>>>
>>> + {
>>> +   status = "okay";
>>> +};
>>> +
>>> + {
>>> +   status = "okay";
>>> +};
>>> +
>>> + {
>>> +   status = "okay";
>>> +};
>>> +
>>> + {
>>> +   status = "okay";
>>> +};
>>> +
>>>   {
>>> status = "okay";
>>>  };
>>> diff --git a/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi
>>> b/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi
>>> index a79f5c1..592034b 100644
>>> --- a/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi
>>> +++ b/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi
>>> @@ -671,6 +671,50 @@
>>> status = "disabled";
>>> };
>>>
>>> +   sata0: sata@320 {
>>> +   compatible = "fsl,lx2160a-ahci";
>>> +   reg = <0x0 0x320 0x0 0x1>,
>>> + <0x7 0x100520 0x0 0x4>;
>>> +   reg-names = "ahci", "sata-ecc";
>>> +   interrupts = ;
>>> +   clocks = < 4 3>;
>>> +   dma-coherent;
>>> +   status = "disabled";
>>> +   };
>>> +
>>> +   sata1: sata@321 {
>>> +   compatible = "fsl,lx2160a-ahci";
>>> +   reg = <0x0 0x321 0x0 0x1>,
>>> + <0x7 0x100520 0x0 0x4>;
>>> +   reg-names = "ahci", "sata-ecc";
>>> +   interrupts = ;
>>> +   clocks = < 4 3>;
>>> +   dma-coherent;
>>> +   status = "disabled";
>>> +   };
>>> +
>>> +   sata2: sata@322 {
>>> +   compatible = "fsl,lx2160a-ahci";
>>> +   reg = <0x0 0x322 0x0 0x1>,
>>> + <0x7 0x100520 0x0 0x4>;
>>> +   reg-names = "ahci", "sata-ecc";
>>> +   interrupts = ;
>>> +   clocks = < 4 3>;
>>> +   dma-coherent;
>>> +   status = "disabled";
>>> +   };
>>> +
>>> +   sata3: sata@323 {
>>> +   compatible = "fsl,lx2160a-ahci";
>>> +   reg = <0x0 0x323 0x0 0x1>,
>>> + <0x7 0x100520 0x0 0x4>;
>>You are using same reg values for sata-ecc in all sata instances. Does
>>this actually work? No errors when the ahci_qoriq driver do ioremap on
>>it while probing second instance and onward?
>>
> Thanks for you point out the problem. I will fixed it with two or more sata
>enable.
>>fsl-ls208xa.dtsi is the only other file here with multiple sata
>>instances and it doesn’t care about sata-ecc.
>>
>The ls208xa platforms is not 

Re: [PATCH -next] btrfs: Fix type conversion in btrfs_read_root_item

[YueHaibing]

On 2019/2/20 14:10, Dan Carpenter wrote:
> On Wed, Feb 20, 2019 at 08:58:43AM +0300, Dan Carpenter wrote:
>> On Wed, Feb 20, 2019 at 03:08:40AM +, YueHaibing wrote:
>>> btrfs_item_size_nr return value is u32, convert it to int may result
>>> in truncation.Also read_extent_buffer expect a unsigned param, so
>>> min_t should use type u32 to compare.
>>>
>>> Fixes: 8ea05e3a4262 ("Btrfs: introduce subvol uuids and times")
>>> Signed-off-by: YueHaibing 
>>> ---
>>>  fs/btrfs/root-tree.c | 4 ++--
>>>  1 file changed, 2 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/fs/btrfs/root-tree.c b/fs/btrfs/root-tree.c
>>> index 02d1a57af78b..893d12fbfda0 100644
>>> --- a/fs/btrfs/root-tree.c
>>> +++ b/fs/btrfs/root-tree.c
>>> @@ -21,12 +21,12 @@ static void btrfs_read_root_item(struct extent_buffer 
>>> *eb, int slot,
>>> struct btrfs_root_item *item)
>>>  {
>>> uuid_le uuid;
>>> -   int len;
>>> +   u32 len;
>>> int need_reset = 0;
>>>  
>>> len = btrfs_item_size_nr(eb, slot);
>>> read_extent_buffer(eb, item, btrfs_item_ptr_offset(eb, slot),
>>> -   min_t(int, len, (int)sizeof(*item)));
>>   
>> Yeah, min_t() should normally cast to unsigned and the extra cast is
>> silly.
>>
> 
> Btw, I shouldn't have had to dig through the patch to find the *real*
> reason you wrote it.  A better description would have said:
> 
> There is a messy cast here:
> 
>   min_t(int, len, (int)sizeof(*item)));
> 
> min_t() should normally cast to unsigned.  It's not possible for
> "len" to be negative, but if it were then then we definitely
> wouldn't want to pass negatives to read_extent_buffer().  Also there
> is an extra cast.
> 
> This patch shouldn't affect runtime, it's just a clean up.

Yes, This just a cleanup, Thanks!

> 
> regards,
> dan carpenter
> 
> 
> .
> 

Re: linux-next: Tree for Feb 20

[Zhangshaokun]

There is a compiler failure on arm64 platform, as follow:

  AS  arch/arm64/kvm/hyp.o
  CC  kernel/trace/ring_buffer.o
In file included from security/integrity/ima/ima_fs.c:30:0:
security/integrity/ima/ima.h:176:7: error: redeclaration of enumerator ‘NONE’
  hook(NONE)   \
   ^
security/integrity/ima/ima.h:188:34: note: in definition of macro 
‘__ima_hook_enumify’
 #define __ima_hook_enumify(ENUM) ENUM,
  ^
security/integrity/ima/ima.h:191:2: note: in expansion of macro ‘__ima_hooks’
  __ima_hooks(__ima_hook_enumify)
  ^
In file included from ./arch/arm64/include/asm/acpi.h:15:0,
 from ./include/acpi/acpi_io.h:7,
 from ./include/linux/acpi.h:47,
 from ./include/linux/tpm.h:26,
 from security/integrity/ima/ima.h:25,
 from security/integrity/ima/ima_fs.c:30:
./include/linux/efi.h:1716:2: note: previous definition of ‘NONE’ was here
  NONE,
  ^
scripts/Makefile.build:276: recipe for target 'security/integrity/ima/ima_fs.o' 
failed
make[3]: *** [security/integrity/ima/ima_fs.o] Error 1

I dug it and it is the commit 901615cb916d ("tpm: move tpm_chip definition to 
include/linux/tpm.h")

Thanks,
Shaokun

On 2019/2/20 15:43, Stephen Rothwell wrote:
> Hi all,
> 
> Changes since 20190219:
> 
> The asm-generic tree lost its build failure.
> 
> The v4l-dvb tree lost its build failure.
> 
> The net-next tree gained a conflict against the bpf tree.
> 
> The kvm tree still had its build failure so I used a supplied patch.
> 
> The akpm-current tree gained a build failure due to an interaction with
> the drm tree for which I applied a merge fix patch.
> 
> Non-merge commits (relative to Linus' tree): 8846
>  9249 files changed, 416125 insertions(+), 220692 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 296 trees (counting Linus' and 69 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.
> 

Re: [Outreachy kernel] [PATCH] net: dsa: add missing of_node_put

[Himadri Pandya]

On 20/02/19 9:23 AM, Vaishali Thakkar wrote:

On Wed, Feb 20, 2019 at 8:54 AM Himadri Pandya  wrote:
Hi Himadri,

Thanks for the patch!

For the scope of Outreachy, we prefer that you send patches in staging
directory as Greg makes sure to pick them during the application
period. Of course, you're very much encouraged to contribute to other
subsystems as well but there patches are mainly picked up based on
maintainer's cycle which may or may not be picked up for linux-next when
selection of interns happens.

I hope that makes sense.

Understood. Thank you for letting me know that.

Decrement the reference count on port while returning out of the loop.

How did you find out about this issue?
I believe that Julia Lawall has been working on this for a while. After 
doing some cleanup patches, I'm trying to continue the work with her help.

I think it would be good to
give credit to tool in commit log if the issue is identified or produced
by tool. [In this case, I assume it's Coccinelle]


Yes, it was identified by Coccinelle and I should include it in the 
commit message. Thank you for the remark. I'll revise the patch accordingly.


- Himadri



Signed-off-by: Himadri Pandya 
---
  net/dsa/dsa2.c | 14 ++
  1 file changed, 10 insertions(+), 4 deletions(-)

diff --git a/net/dsa/dsa2.c b/net/dsa/dsa2.c
index a1917025e155..396e7433dd8f 100644
--- a/net/dsa/dsa2.c
+++ b/net/dsa/dsa2.c
@@ -624,19 +624,25 @@ static int dsa_switch_parse_ports_of(struct dsa_switch 
*ds,
 for_each_available_child_of_node(ports, port) {
 err = of_property_read_u32(port, "reg", );
 if (err)
-   return err;
+   goto put_port;

-   if (reg >= ds->num_ports)
-   return -EINVAL;
+   if (reg >= ds->num_ports) {
+   err = -EINVAL;
+   goto put_port;
+   }

 dp = >ports[reg];

 err = dsa_port_parse_of(dp, port);
 if (err)
-   return err;
+   goto put_port;
 }

 return 0;
+
+put_port:
+   of_node_put(port);
+   return err;
  }

  static int dsa_switch_parse_member_of(struct dsa_switch *ds,
--
2.17.1

--
You received this message because you are subscribed to the Google Groups 
"outreachy-kernel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to outreachy-kernel+unsubscr...@googlegroups.com.
To post to this group, send email to outreachy-ker...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/outreachy-kernel/20190220032432.2878-1-himadri18.07%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [PATCH v2 09/10] genirq/irqdomain: fall back to default domain when creating hierarchy domain

[Marc Zyngier]

On Tue, 19 Feb 2019 17:48:29 +0100
Thomas Bogendoerfer  wrote:

> On Tue, 19 Feb 2019 16:27:16 +
> Marc Zyngier  wrote:
> 
> > On Tue, 19 Feb 2019 16:57:23 +0100
> > Thomas Bogendoerfer  wrote:
> > 
> > Hi Thomas,
> >   
> > > When creating hierarchy domains use irq_default_domain as parent, if no
> > > parent was given by the caller. This avoids adding helper code for
> > > querying the underlying platform irq domain.
> > > 
> > > Signed-off-by: Thomas Bogendoerfer 
> > > ---
> > >  kernel/irq/irqdomain.c | 5 -
> > >  1 file changed, 4 insertions(+), 1 deletion(-)
> > > 
> > > diff --git a/kernel/irq/irqdomain.c b/kernel/irq/irqdomain.c
> > > index 8b0be4bd6565..617c482d0778 100644
> > > --- a/kernel/irq/irqdomain.c
> > > +++ b/kernel/irq/irqdomain.c
> > > @@ -1021,7 +1021,10 @@ struct irq_domain 
> > > *irq_domain_create_hierarchy(struct irq_domain *parent,
> > >   else
> > >   domain = irq_domain_create_tree(fwnode, ops, host_data);
> > >   if (domain) {
> > > - domain->parent = parent;
> > > + if (parent)
> > > + domain->parent = parent;
> > > + else
> > > + domain->parent = irq_default_domain;
> > >   domain->flags |= flags;
> > >   }
> > >
> > 
> > I'm really not keen on this. The whole "default domain" made sense at a
> > distant point in time (when irqdomains were new and platform code was
> > blissfully ignoring it), but it really looks like a sore spot in the
> > hierarchy code, which assumes that you always know what you're building
> > your hierarchy on top of.
> > 
> > It also create a small issue in the sense that you can create a root
> > domain using irq_domain_create_hierarchy() by passing NULL as the
> > parent. With this patch, the new domain now points to the default one,
> > with unexpected consequences.
> > 
> > So let's come back to first principles: How comes you can't obtain the
> > parent domain at creation time? Because I'd rather give you a way to
> > retrieve it instead if this.  
> 
> the bridge irq domain could be stacked on different underlying irq domains
> for different platforms (HUB is IP27, HEART for IP30 and BEDROCK for IP35).
> And my idea was to set a irq default domain in the IP27/IP30/IP35 platform
> code so that bridge code will pick up the correct underlying irq domain.
> As there is no device tree I haven't found an already implemented other way.

Ah, right. We have ways to solve this kind of problem without DT
(cough... ACPI cough...), but this requires the bridge code to at least
know *something* about the underlying domain (see the use of struct
fwnode in the ACPI IORT code, and the way it uses the routing
informations to build and retrieve fwnodes that are used to match
irq domains).

Do you have such firmware tables that could be used to store sideband
data and allow the bridge code to retrieve the corresponding pointer? I
appreciate this could be quite a lot of work for a platform that has
little future...

> Right now I have two idea to solve my problem without this patch:
> 
> - implement a SGI specific helper for getting the underlying irq domain
> - use a helper function to read irq_default_domain
> 
> What do you prefer ? Or do you see something else ?

Well, short of doing the above, I'd rather have something in the common
code that allows the default domain to be retrieved. How about the
patch below?

Thanks,

M.

>From 3a9e44941c203ef2ed659838f218a0203c963828 Mon Sep 17 00:00:00 2001
From: Marc Zyngier 
Date: Wed, 20 Feb 2019 08:59:23 +
Subject: [PATCH] irqdomain: Allow the default irq domain to be retrieved

The default irq domain allows legacy code to create irqdomain
mappings without having to track the domain it is allocating
from. Setting the default domain is a one shot, fire and forget
operation, and no effort was made to be able to retrieve this
information at a later point in time.

Newer irqdomain APIs (the hierarchical stuff) relies on both
the irqchip code to track the irqdomain it is allocating from,
as well as some form of firmware abstraction to easily identify
which piece of HW maps to which irq domain (DT, ACPI).

For systems without such firmware (or legacy platform that are
getting dragged into the 21st century), things are a bit harder.
For these cases (and these cases only!), let's provide a way
to retrieve the default domain, allowing the use of the v2 API
without having to resort to platform-specific hacks.

Signed-off-by: Marc Zyngier 
---
 include/linux/irqdomain.h |  1 +
 kernel/irq/irqdomain.c| 14 ++
 2 files changed, 15 insertions(+)

diff --git a/include/linux/irqdomain.h b/include/linux/irqdomain.h
index 35965f41d7be..d2130dc7c0e6 100644
--- a/include/linux/irqdomain.h
+++ b/include/linux/irqdomain.h
@@ -265,6 +265,7 @@ extern struct irq_domain *irq_find_matching_fwspec(struct 
irq_fwspec *fwspec,
   enum irq_domain_bus_token 
bus_token);
 extern bool 

Re: [PATCH v6 21/22] iommu/mediatek: Fix iova_to_phys PA start for 4GB mode

[Yong Wu]

On Tue, 2019-02-19 at 15:33 -0800, Evan Green wrote:
> On Sun, Feb 17, 2019 at 1:09 AM Yong Wu  wrote:
> >
> > In the 4GB mode, the physical address is remapped,
> >
> > Here is the detailed remap relationship.
> > CPU PA ->HW PA
> > 0x4000_  0x1_4000_ (Add bit32)
> > 0x8000_  0x1_8000_ ...
> > 0xc000_  0x1_c000_ ...
> > 0x1__0x1__ (No change)
> >
> > Thus, we always add bit32 for PA when entering mtk_iommu_map.
> > But in the iova_to_phys, the CPU don't need this bit32 if the
> > PA is from 0x1_4000_ to 0x1__.
> > This patch discards the bit32 in this iova_to_phys in the 4GB mode.
> >
> > Signed-off-by: Yong Wu 
> > ---
> >  drivers/iommu/mtk_iommu.c | 18 ++
> >  1 file changed, 18 insertions(+)
> >
> > diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
> > index 0277396..076d333 100644
> > --- a/drivers/iommu/mtk_iommu.c
> > +++ b/drivers/iommu/mtk_iommu.c
> > @@ -119,6 +119,19 @@ struct mtk_iommu_domain {
> >
> >  static const struct iommu_ops mtk_iommu_ops;
> >
> > +/*
> > + * In M4U 4GB mode, the physical address is remapped as below:
> > + *  CPU PA ->   M4U HW PA
> > + *  0x4000_ 0x1_4000_ (Add bit32)
> > + *  0x8000_ 0x1_8000_ ...
> > + *  0xc000_ 0x1_c000_ ...
> > + *  0x1__   0x1__ (No change)
> > + *
> > + * Thus, We always add BIT32 in the iommu_map and disable BIT32 if PA is >=
> > + * 0x1_4000_ in the iova_to_phys.
> > + */
> > +#define MTK_IOMMU_4GB_MODE_PA_14000 0x14000UL
> > +
> >  static LIST_HEAD(m4ulist); /* List all the M4U HWs */
> >
> >  #define for_each_m4u(data) list_for_each_entry(data, , list)
> > @@ -415,6 +428,7 @@ static phys_addr_t mtk_iommu_iova_to_phys(struct 
> > iommu_domain *domain,
> >   dma_addr_t iova)
> >  {
> > struct mtk_iommu_domain *dom = to_mtk_domain(domain);
> > +   struct mtk_iommu_data *data = mtk_iommu_get_m4u_data();
> > unsigned long flags;
> > phys_addr_t pa;
> >
> > @@ -422,6 +436,10 @@ static phys_addr_t mtk_iommu_iova_to_phys(struct 
> > iommu_domain *domain,
> > pa = dom->iop->iova_to_phys(dom->iop, iova);
> > spin_unlock_irqrestore(>pgtlock, flags);
> >
> > +   if (data->plat_data->has_4gb_mode && data->dram_is_4gb &&
> > +   pa >= MTK_IOMMU_4GB_MODE_PA_14000)
> > +   pa &= ~BIT_ULL(32);
> > +
> 
> The define doesn't really make it much better, but I guess it doesn't
> make it worse either. As I was reviewing this I was thinking that this
> should be rolled into patch 6 "iommu/io-pgtable-arm-v7s: Extend
> MediaTek 4GB Mode". But I guess this was returning bad PAs since
> before this series, right? So does this need a Fixes tag?

Thanks very much for your reviewing so many patches.

Yes. The issue exist before this series, It was introduced by this
commit:
30e2fccf9512 ("iommu/mediatek: Enlarge the validate PA range for 4GB
mode")

I will send a new version to add this tag.

> -Evan
> 
> ___
> Linux-mediatek mailing list
> linux-media...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-mediatek

Re: [PATCH v1 04/12] arm64: dts: msm8996: thermal: Add temperature sensors near major peripherals

[Amit Kucheria]

On Wed, Feb 20, 2019 at 6:55 AM Eduardo Valentin  wrote:
>
> On Mon, Feb 18, 2019 at 06:05:18PM +0530, Amit Kucheria wrote:
> > msm8996 has a total of 21 temperature sensors. Populate DT with
> > information about them.
> >
> > There are 2 sensors on each of the cpus - one on the top, the other
> > below (we only expose one on the top in DT for now). For the GPU, we
> > expose both, the one on the top and the one below.
> >
> > Depending on the version of the silicon, sensor 2 is either placed near
> > the L3 cache or the venus video decoder. It would've been nice to be
> > able to be version-specific but we don't have DTs that differentiate the
> > two versions of silicon yet.
> >
> > Signed-off-by: Amit Kucheria 
> > ---
> >  arch/arm64/boot/dts/qcom/msm8996.dtsi | 98 +++
> >  1 file changed, 98 insertions(+)
> >
> > diff --git a/arch/arm64/boot/dts/qcom/msm8996.dtsi 
> > b/arch/arm64/boot/dts/qcom/msm8996.dtsi
> > index ae6e9f0778f0..8e36a39e1386 100644
> > --- a/arch/arm64/boot/dts/qcom/msm8996.dtsi
> > +++ b/arch/arm64/boot/dts/qcom/msm8996.dtsi
> > @@ -237,6 +237,104 @@
> >   };
> >   };
> >   };
> > +
> > + gpu-thermal-top {
> > + polling-delay-passive = <250>;
> > + polling-delay = <1000>;
> > +
> > + thermal-sensors = < 6>;
> > +
> > + trips {
> > + gpu1_alert0: trip-point@0 {
> > + temperature = <75000>;
> > + hysteresis = <2000>;
> > + type = "passive";
>
> What is the cooling map for this?

I'm working on it. Will send out an update.

> > + };
> > +
> > + gpu1_crit: gpu_crit {
> > + temperature = <95000>;
> > + hysteresis = <2000>;
> > + type = "critical";
> > + };
> > + };
> > + };
> > +
> > + gpu-thermal-bottom {
> > + polling-delay-passive = <250>;
> > + polling-delay = <1000>;
> > +
> > + thermal-sensors = < 7>;
> > +
> > + trips {
> > + gpu2_alert0: trip-point@0 {
> > + temperature = <75000>;
> > + hysteresis = <2000>;
> > + type = "passive";
> > + };
> > +
> > + gpu2_crit: gpu_crit {
> > + temperature = <95000>;
> > + hysteresis = <2000>;
> > + type = "critical";
> > + };
> > + };
> > + };
> > +
> > + m4m-thermal {
> > + polling-delay-passive = <250>;
> > + polling-delay = <1000>;
> > +
> > + thermal-sensors = < 1>;
> > + };
> > +
> > + l3_or_venus-thermal {
> > + polling-delay-passive = <250>;
> > + polling-delay = <1000>;
> > +
> > + thermal-sensors = < 2>;
> > + };
> > +
> > + cluster0-l2-thermal {
> > + polling-delay-passive = <250>;
> > + polling-delay = <1000>;
> > +
> > + thermal-sensors = < 7>;
> > + };
> > +
> > + cluster1-l2-thermal {
> > + polling-delay-passive = <250>;
> > + polling-delay = <1000>;
> > +
> > + thermal-sensors = < 12>;
> > + };
> > +
> > + camera-thermal {
> > + polling-delay-passive = <250>;
> > + polling-delay = <1000>;
> > +
> > + thermal-sensors = < 1>;
> > + };
> > +
> > + q6-dsp-thermal {
> > + polling-delay-passive = <250>;
> > + polling-delay = <1000>;
> > +
> > + thermal-sensors = < 2>;
> > + };
> > +
> > + mem-thermal {
> > + polling-delay-passive = <250>;
> > + polling-delay = <1000>;
> > +
> > + thermal-sensors = < 3>;
> > + };
> > +
> > + modemtx-thermal {
> > + polling-delay-passive = <250>;
> > + polling-delay = <1000>;
> > +
> > + thermal-sensors = < 4>;
> > + };
> >   };
> >
> >   timer {
> > --
> > 2.17.1
> >

Re: [PATCH] kasan: turn off asan-stack for clang-8 and earlier

[Arnd Bergmann]

On Wed, Feb 20, 2019 at 7:44 AM Dmitry Vyukov  wrote:
>
> On Wed, Feb 20, 2019 at 1:34 AM Kostya Serebryany  wrote:
> >
> > On Tue, Feb 19, 2019 at 2:43 PM Nick Desaulniers
> >  wrote:
> > >
> > > + Evgenii, Kostya for KASAN
> > >
> > > On Tue, Feb 19, 2019 at 2:17 PM Qian Cai  wrote:
> > > >
> > > > On Tue, 2019-02-19 at 22:49 +0100, Arnd Bergmann wrote:
> > > > > Building an arm64 allmodconfig kernel with clang results in over 140 
> > > > > warnings
> > > > > about overly large stack frames, the worst ones being:
> > > > >
> > > > > drivers/gpu/drm/panel/panel-sitronix-st7789v.c:196:12: error: stack 
> > > > > frame size
> > > > > of 20224 bytes in function 'st7789v_prepare'
> > > > > drivers/video/fbdev/omap2/omapfb/displays/panel-tpo-td028ttec1.c:196:12:
> > > > > error: stack frame size of 13120 bytes in function 
> > > > > 'td028ttec1_panel_enable'
> > > > > drivers/usb/host/max3421-hcd.c:1395:1: error: stack frame size of 
> > > > > 10048 bytes
> > > > > in function 'max3421_spi_thread'
> > > > > drivers/net/wan/slic_ds26522.c:209:12: error: stack frame size of 
> > > > > 9664 bytes
> > > > > in function 'slic_ds26522_probe'
> > > > > drivers/crypto/ccp/ccp-ops.c:2434:5: error: stack frame size of 8832 
> > > > > bytes in
> > > > > function 'ccp_run_cmd'
> > > > > drivers/media/dvb-frontends/stv0367.c:1005:12: error: stack frame 
> > > > > size of 7840
> > > > > bytes in function 'stv0367ter_algo'
> > > > >
> > > > > None of these happen with gcc today, and almost all of these are the 
> > > > > result
> > > > > of a single known bug in llvm.  Hopefully it will eventually get 
> > > > > fixed with
> > > > > the
> > > > > clang-9 release.
> >
> > I am not confident we can fix this in clang.
> > The difference between gcc and clang, AFAICT, is not in the asan
> > instrumentation, but in inining.
> > Looking at the reproducer from 
> > https://bugs.llvm.org/show_bug.cgi?id=38809#c4,
> > if I change ltv350qv_write_reg to always inline, gcc also produces a
> > huge 10K stack frame,
> > and making it noinline fixes the stack frame for both gcc and clang.
>
> Does your gcc have fix for https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81715 
> ?
>
> For me gcc rejects to inline it:
>
> gcc version 7.3.0 (Debian 7.3.0-5)
>
> $ gcc /tmp/test.c -Wframe-larger-than=128 -c -fsanitize=kernel-address
> -O2 --param asan-stack=1
> /tmp/test.c:23:13: warning: always_inline function might not be
> inlinable [-Wattributes]

I don't see that warning here

>  static void ltv350qv_write_reg(void) {
>  ^~
> /tmp/test.c: In function ‘ltv350qv_power_on’:
> /tmp/test.c:57:1: warning: the frame size of 416 bytes is larger than
> 128 bytes [-Wframe-larger-than=]
>  }

but I also see the small stack size here: https://godbolt.org/z/Uz5Ruv

gcc definitely inlines the function here but only has one copy of
spi_message and spi_transfer on the stack, while clang inserts
a call to __asan_report_store8_noabort() and has one copy per
inlined call to ltv350qv_write_reg().

  Arnd

Re: [PATCH v1 13/24] drivers: thermal: tsens: Print IP version

[Amit Kucheria]

On Wed, Feb 20, 2019 at 6:47 AM Eduardo Valentin  wrote:
>
> On Thu, Feb 07, 2019 at 04:19:31PM +0530, Amit Kucheria wrote:
> > On some TSENS IP, version is stored. Print that version at init.
> >
> > Signed-off-by: Amit Kucheria 
> > ---
> >  drivers/thermal/qcom/tsens-common.c | 23 ++-
> >  1 file changed, 22 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/thermal/qcom/tsens-common.c 
> > b/drivers/thermal/qcom/tsens-common.c
> > index aae3d71d7eed..39cd5733fd44 100644
> > --- a/drivers/thermal/qcom/tsens-common.c
> > +++ b/drivers/thermal/qcom/tsens-common.c
> > @@ -121,7 +121,7 @@ int __init init_common(struct tsens_priv *priv)
> >   void __iomem *tm_base, *srot_base;
> >   struct device *dev = priv->dev;
> >   struct resource *res;
> > - u32 enabled;
> > + u32 enabled, maj_ver, min_ver;
> >   int ret, i, j;
> >   struct platform_device *op = 
> > of_find_device_by_node(priv->dev->of_node);
> >
> > @@ -155,6 +155,27 @@ int __init init_common(struct tsens_priv *priv)
> >   if (IS_ERR(priv->tm_map))
> >   return PTR_ERR(priv->tm_map);
> >
> > + for (i = 0; i < MAX_REGFIELDS; i++) {
> > + priv->rf[i] = NULL;
> > + }
> > +
> > + /* alloc regmap_fields in srot_map */
> > + if (priv->feat->ver_info) {
> > + for (i = 0, j = VER_MAJOR; i < 2; i++, j++) {
> > + priv->rf[j] = devm_regmap_field_alloc(dev, 
> > priv->srot_map,
> > +   
> > priv->fields[j]);
> > + if (IS_ERR(priv->rf[j]))
> > + return PTR_ERR(priv->rf[j]);
> > + }
> > + ret = regmap_field_read(priv->rf[VER_MAJOR], _ver);
> > + if (ret)
> > + return ret;
> > + ret = regmap_field_read(priv->rf[VER_MINOR], _ver);
> > + if (ret)
> > + return ret;
> > + dev_info(dev, "version: %d.%d\n", maj_ver, min_ver);
>
> Is this really needed? Printing stuff into kernel log during boot can
> just add a lot of info that ends up just slowing down things. Besides,
> if this info is important shouldnt be available somewhere else as the
> kernel log is a circular buffer and eventually that line will get
> wrapped up?

Fair point, I'll remove this statement and dump this into debugfs for
which I'll send a separate series adding debugfs support.

Re: [PATCH v2] USB: serial: cp210x: Fix GPIO in autosuspend

[Johan Hovold]

On Sun, Feb 17, 2019 at 06:59:01PM +0100, Karoly Pados wrote:
> Current GPIO code in cp210x fails to take USB autosuspend into account,
> making it practically impossible to use GPIOs with autosuspend enabled
> without user configuration. Fix this like for ftdi_sio in a previous patch.
> Tested on a CP2102N.
> 
> Signed-off-by: Karoly Pados 
> ---
> Changelog:
> - v2: Restrict new autopm calls to GPIO paths.
>   Always check result of usb_autopm_get.
>   Rebased to current usb_serial upstream.

Thanks for the v2. Now applied after removing the unmotivated white
space change.

I also added a Fixes and CC-stable tag as this seems annoying enough to
warrant a backport even if autosuspend was never actually supported.

Johan

Re: [PATCH] s390/setup: fix early warning messages

[Cornelia Huck]

On Tue, 19 Feb 2019 10:47:38 -0800
Guenter Roeck  wrote:

> Hi Cornelia,
> 
> On 2/18/19 2:30 PM, Cornelia Huck wrote:
> 
> >> What is your qemu command line ?  
> > 
> > Ignoring any additional devices:
> > 
> > s390x-softmmu/qemu-system-s390x -M s390-ccw-virtio,accel=tcg -cpu max  -m 
> > 1024 -nographic -device virtio-scsi-ccw,id=scsi0,devno=fe.0.0001 -drive 
> > file=/home/cohuck/vm-images/vm1.qcow2,format=qcow2,if=none,id=drive-scsi0-0-0-0
> >  -device 
> > scsi-hd,bus=scsi0.0,channel=0,scsi-id=0,lun=0,drive=drive-scsi0-0-0-0,id=scsi0-0-0-0,bootindex=1
> >  -sandbox on -kernel ~/git/linux/arch/s390/boot/bzImage -append 
> > "root=/dev/sda3"
> >   
> 
> Is "accel=tcg" and "-cpu max" expected to make any difference ? CPU 
> consumption
> on my system seems to be identical to the default (no -M or -cpu on command 
> line).
> This is with qemu 3.1.

If you're not running on a s390x, QEMU will pick tcg even if not
specified (as it needs to emulate anyway), so that should not make any
difference. The 'max' cpu model was is not yet available with 3.1
(merged in the current development cycle); it will not make much
difference in practice (a few more cpu features are currently provided
with it over the default 'qemu' cpu model).

As I'm testing various combinations (tcg vs. kvm on an s390x host,
different cpu models) when I'm queuing patches, my command line is not
necessarily exactly the same every time (this was just the one I
happened to be testing the kernel patch with). If you simply want to be
able to boot a test kernel on a non-s390x host, relying on the default
accelerator (tcg) and the default cpu model (qemu) being picked should
be completely fine.

Re: [PATCH v6 9/9] vsprintf: Avoid confusion between invalid address and value

[Petr Mladek]

On Tue 2019-02-19 13:06:17, Andy Shevchenko wrote:
> On Tue, Feb 19, 2019 at 5:07 AM Sergey Senozhatsky
>  wrote:
> 
> > Suppose, in my driver I want to sprintf() IPv4 address. The longest
> > possible address is 3 * 4 (%d%d%d) + 3 bytes (dots) + terminating NULL.
> > E.g. 111.111.111.111
> >
> > forcing sprintf() to write "(invalid address)" to a 16-bytes buffer,
> > but the thing is - strlen("(invalid address)") > 16.

Good catch!

> It would print as many characters as buffer allows. In your case above
> the use of sprintf() is a bit fragile.

Heh, I do not see it used anywhere in the code. Only "%pi6" is used
in a real code and always a safe way.

> But yes, the error messages should not be longer than 8 / 16 bytes
> depending on 32- or 64-bit build we have.

Well, better be on the safe side. I'll move it at the beginning
of the patchset.

Best Regards,
Petr

PS: I am a bit busy with some other things. I'll send v7 later.
I think that it is a material for 5.2. This patchset would deserve
some testing in linux-next and we are already too close to
the 5.1 merge window.

Re: [RFC PATCH] tools/memory-model: Remove (dep ; rfi) from ppo

[Peter Zijlstra]

On Tue, Feb 19, 2019 at 06:01:17PM -0800, Paul E. McKenney wrote:
> On Tue, Feb 19, 2019 at 11:57:37PM +0100, Andrea Parri wrote:
> > Remove this subtle (and, AFAICT, unused) ordering: we can add it back,
> > if necessary, but let us not encourage people to rely on this thing.
> > 
> > For example, the following "exists" clause can be satisfied with this
> > change:
> > 
> > C dep-rfi
> > 
> > { }
> > 
> > P0(int *x, int *y)
> > {
> > WRITE_ONCE(*x, 1);
> > smp_store_release(y, 1);
> > }
> > 
> > P1(int *x, int *y, int *z)
> > {
> > int r0;
> > int r1;
> > int r2;
> > 
> > r0 = READ_ONCE(*y);
> > WRITE_ONCE(*z, r0);
> > r1 = smp_load_acquire(z);
> > r2 = READ_ONCE(*x);
> > }
> > 
> > exists (1:r0=1 /\ 1:r2=0)
> 
> Any objections?  If I don't hear any in a couple days, I will apply this.

IIUC you cannot build hardware that allows the above, so why would we
allow it?

Re: [PATCH v2 1/1] s390: vfio_ap: link the vfio_ap devices to the vfio_ap bus subsystem

[Cornelia Huck]

On Tue, 19 Feb 2019 22:31:17 +0100
Pierre Morel  wrote:

> On 19/02/2019 19:52, Tony Krowiak wrote:
> > On 2/18/19 1:08 PM, Pierre Morel wrote:  
> >> Libudev relies on having a subsystem link for non-root devices. To
> >> avoid libudev (and potentially other userspace tools) choking on the
> >> matrix device let us introduce a vfio_ap bus and with that the vfio_ap
> >> bus subsytem, and make the matrix device reside within it.
> >>
> >> Doing this we need to suppress the forced link from the matrix device to
> >> the vfio_ap driver and we suppress the device_type we do not need
> >> anymore.
> >>
> >> Since the associated matrix driver is not the vfio_ap driver any more,
> >> we have to change the search for the devices on the vfio_ap driver in
> >> the function vfio_ap_verify_queue_reserved.
> >>
> >> Reported-by: Marc Hartmayer 
> >> Reported-by: Christian Borntraeger 
> >> Signed-off-by: Pierre Morel 
> >> ---
> >>   drivers/s390/crypto/vfio_ap_drv.c | 48 
> >> +--
> >>   drivers/s390/crypto/vfio_ap_ops.c |  4 +--
> >>   drivers/s390/crypto/vfio_ap_private.h |  1 +
> >>   3 files changed, 43 insertions(+), 10 deletions(-)
> >>
> >> diff --git a/drivers/s390/crypto/vfio_ap_drv.c 
> >> b/drivers/s390/crypto/vfio_ap_drv.c
> >> index 31c6c84..8e45559 100644
> >> --- a/drivers/s390/crypto/vfio_ap_drv.c
> >> +++ b/drivers/s390/crypto/vfio_ap_drv.c
> >> @@ -24,10 +24,6 @@ MODULE_LICENSE("GPL v2");
> >>   static struct ap_driver vfio_ap_drv;
> >> -static struct device_type vfio_ap_dev_type = {
> >> -    .name = VFIO_AP_DEV_TYPE_NAME,
> >> -};
> >> -
> >>   struct ap_matrix_dev *matrix_dev;
> >>   /* Only type 10 adapters (CEX4 and later) are supported
> >> @@ -62,6 +58,27 @@ static void vfio_ap_matrix_dev_release(struct 
> >> device *dev)
> >>   kfree(matrix_dev);
> >>   }
> >> +static int matrix_bus_match(struct device *dev, struct device_driver 
> >> *drv)
> >> +{
> >> +    return 1;  
> > 
> > I think we should verify the following:
> > 
> > * dev == matrix_dev->device
> > * drv == _driver
> > 
> > The model employed is for the matrix device to be a singleton, so I
> > think we should verify that the matrix device and driver defined herein
> > ought to be the only possible choices for a match. Of course, doing so
> > will require some restructuring of this patch.  
> 
> I think Conny already answered this question.

Not quite :), but I don't think we need any magic in there, as there's
only one device and only one driver on that bus. No need to make this
more complicated.

> 
> >   
> >> +}
> >> +
> >> +static struct bus_type matrix_bus = {
> >> +    .name = "vfio_ap",
> >> +    .match = _bus_match,
> >> +};
> >> +
> >> +static int matrix_probe(struct device *dev)
> >> +{
> >> +    return 0;
> >> +}
> >> +
> >> +static struct device_driver matrix_driver = {
> >> +    .name = "vfio_ap",  
> > 
> > This is the same name used for the original device driver. I think
> > this driver ought to have a different name to avoid confusion.
> > How about vfio_ap_matrix or some other name to differentiate the
> > two.  
> 
> I would like too, but changing this will change the path to the mediated 
> device supported type.

Yes, we don't want to change that.

> 
> 
> >   
> >> +    .bus = _bus,
> >> +    .probe = matrix_probe,  
> > 
> > I would add:
> >  .suppress_bind_attrs = true;
> > 
> > This will remove the sysfs bind/unbind interfaces. Since there is only
> > one matrix device and it's lifecycle is controlled herein, there is no
> > sense in allowing a root user to bind/unbind it.
> >   
> 
> OTOH bind/unbind has no impact.
> If no one else ask for this I will not change what has already been 
> reviewed by Conny and Christian.

As we only have one driver, it does not really make sense anyway.

[PATCH][next] rtlwifi: rtl8192ce: fix typo, "PairwiseENcAlgorithm" -> "PairwiseEncAlgorithm"

[Colin King]

From: Colin Ian King 

There is an uppercase 'N' that should be a lowercase 'n', fix this.

Signed-off-by: Colin Ian King 
---
 drivers/net/wireless/realtek/rtlwifi/rtl8192ce/hw.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8192ce/hw.c 
b/drivers/net/wireless/realtek/rtlwifi/rtl8192ce/hw.c
index 5cf5a85d1376..d8f496e2d68b 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8192ce/hw.c
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8192ce/hw.c
@@ -876,7 +876,7 @@ void rtl92ce_enable_hw_security_config(struct ieee80211_hw 
*hw)
u8 sec_reg_value;
 
RT_TRACE(rtlpriv, COMP_INIT, DBG_LOUD,
-"PairwiseENcAlgorithm = %d GroupEncAlgorithm = %d\n",
+"PairwiseEncAlgorithm = %d GroupEncAlgorithm = %d\n",
 rtlpriv->sec.pairwise_enc_algorithm,
 rtlpriv->sec.group_enc_algorithm);
 
-- 
2.20.1

Re: [PATCH v3 9/9] ARM: configs: Add Milbeaut M10V defconfig

[Arnd Bergmann]

On Wed, Feb 20, 2019 at 8:44 AM Sugaya Taichi
 wrote:

> diff --git a/arch/arm/configs/milbeaut_m10v_defconfig 
> b/arch/arm/configs/milbeaut_m10v_defconfig
> new file mode 100644
> index 000..a263211
> --- /dev/null
> +++ b/arch/arm/configs/milbeaut_m10v_defconfig
> @@ -0,0 +1,175 @@

I no longer see anything here that should be turned off, but you
might want to run 'make savedefconfig' and use the output of that,
to make it easier to keep it up to date.

> diff --git a/arch/arm/configs/multi_v7_defconfig 
> b/arch/arm/configs/multi_v7_defconfig
> index 5bee34a..6753805 100644
> --- a/arch/arm/configs/multi_v7_defconfig
> +++ b/arch/arm/configs/multi_v7_defconfig
> @@ -54,6 +54,8 @@ CONFIG_SOC_VF610=y
>  CONFIG_ARCH_KEYSTONE=y
>  CONFIG_ARCH_MEDIATEK=y
>  CONFIG_ARCH_MESON=y
> +CONFIG_ARCH_MILBEAUT=y
> +CONFIG_ARCH_MILBEAUT_M10V=y
>  CONFIG_ARCH_MVEBU=y
>  CONFIG_MACH_ARMADA_370=y
>  CONFIG_MACH_ARMADA_375=y

I'm surprised that you don't need to enable any drivers. Does this actually
boot on your hardware?

  Arnd

Re: 4.20.7: pl2303 not working (post-4.19 regression) (limited info so far, not yet bisected)

[Johan Hovold]

On Mon, Feb 18, 2019 at 10:32:57AM +, Nix wrote:
> On 18 Feb 2019, Johan Hovold stated:
> 
> > On Sun, Feb 17, 2019 at 07:13:52PM +, Nix wrote:
> >> I'm still fairly sure this is a regression -- my machines are often up
> >> for a lot longer than that and I've never seen this before I upgraded to
> >> 4.20.x -- but I don't think I'm going to identify it by mindless
> >> bisection. I might have to actually *think* about it.
> >
> > I doubt it's a regression in usb-serial as essentially nothing changed
> > with respect to pl2303 or core since 4.19.
> 
> Yeah, I came to that conclusion as well.
> 
> > The -ENOSPC you're seeing is returned by the host controller to
> > indicate:
> >
> > This request would overcommit the usb bandwidth reserved for
> > periodic transfers (interrupt, isochronous).
> 
> Side note: probably not related to *this* -ENOSPC, which I've been
> seeing for a few releases now and which appears to break Chromium's U2F
> negotiation when the USB bus has sufficiently weird devices on it (like,
> uh, my wireless mouse):
> 
> 
> 
> (I say "probably not related" because it's much older and long predates
> the pl2303 trouble.)

Yeah, hard to tell from a quick look.

> > but if you're saying you can reproduce this on "every box" it may not be
> > related to any particular host-controller driver (or USB topology).
> 
> They are all xhci, at least. The pl2303 is USB 2. One machine, a
> two-year-old Broadwell server, says:

> So the quirks are all totally different, and the controllers are quite
> different as well...

Yeah, but they are all xhci as you point out so theoretically it could
be an xhci driver regression.

Johan

RE: [alsa-devel] [PATCH] ASoC: AMD: Configure master codec on all playback/capture cases

[Adam Thomson]

On 8 February 2019 18:18, Mark Brown wrote:

> On Fri, Feb 15, 2019 at 07:06:15AM +, Agrawal, Akshu wrote:
> 
> > +static static int cz_da7219_hw_params(struct snd_pcm_substream
> *substream,
> > +   struct snd_pcm_hw_params *params) {
> > +   /* da7219 Codec is clock master so setup as per the needs */
> > +   if (codec_dai->driver->ops->hw_params)
> > +   return codec_dai->driver->ops->hw_params(substream, params,
> > +codec_dai);
> > +   return 0;
> > +}
> 
> No, this is a bad idea - you shouldn't be callings ops in drivers outside of 
> the
> framework, something is going to break on you there.
> Either the drivers or the frameworks are going to get surprised by things 
> getting
> called out of sequence, for example I'd not rely on the fact that the CODEC 
> would
> be outputing a clock without active audio.
> This probably means that you're going to have to extend the framework in some
> way, or refactor things so that the BCLK is exported as a clock by the CODEC 
> and
> reflect the relationships via the clock API.  I need to think a bit more but 
> I think
> the clock API is going to be the the best solution.
> 
> I also suspect that some work is needed to propagate constraints between the
> various DAIs in the system.

So this was a suggestion from my side to avoid the scenario where the system
starts, the DA7219 codec hasn't yet been used (hw_params() not been called), and
one of the other audio devices is needed for playback/capture. The codec will be
at a default DAI configuration rather than the configuration that's required. If
the DA7219 codec had been used first then of course there's no problem and the
system runs as expected from then on.

This AMD platform limits all DAIs to 48KHz, 2 channel so the configuration is
fixed, as I understand it. DA7219 will output DAI clocks without data so there's
no problem there. I initially suggested using 'soc_dai_hw_params()' but the
function isn't a global symbol, probably intentionally, so for this more unusual
config I felt the above approach might be an option. Absolutely understand your
concerns though.

I considered the CCF approach but I'm not 100% confident that the clocking
mechanism of the codec will fit ideally into that framework. There's already
a clock gate for the DAI clocks, in the driver, but nothing more. The problem
here is that the BCLK rate is intrinsically linked to the WCLK rate, as well as
the word length, so changing the desired BCLK rate would affect the WCLK rate,
and vice versa. I will take a look again, but if you have any suggestions then
they'd be greatly received.

Re: [PATCH] usb: xhci: add Immediate Data Transfer support

[Felipe Balbi]

Nicolas Saenz Julienne  writes:

> Immediate data transfers (IDT) allow the HCD to copy small chunks of
> data (up to 8bytes) directly into its output transfer TRBs. This avoids
> the somewhat expensive DMA mappings that are performed by default on
> most URBs submissions.
>
> In the case an URB was suitable for IDT. The data is directly copied
> into the "Data Buffer Pointer" region of the TRB and the IDT flag is
> set. Instead of triggering memory accesses the HC will use the data
> directly.
>
> The implementation could cover all kind of output endpoints. Yet
> Isochronous endpoints are bypassed as I was unable to find one that
> matched IDT's constraints. As we try to bypass the default DMA mappings
> on URB buffers we'd need to find a Isochronous device with an
> urb->transfer_buffer_length <= 8 bytes.
>
> The implementation takes into account that the 8 byte buffers provided
> by the URB will never cross a 64KB boundary.
>
> Signed-off-by: Nicolas Saenz Julienne 

This looks good to my eyes.

Reviewed-by: Felipe Balbi 

-- 
balbi


signature.asc
Description: PGP signature

Re: [PATCH v3] drivers: base: add support to skip power management in device/driver model

[Rafael J. Wysocki]

On Thursday, February 14, 2019 7:29:10 PM CET Sudeep Holla wrote:
> All device objects in the driver model contain fields that control the
> handling of various power management activities. However, it's not
> always useful. There are few instances where pseudo devices are added
> to the model just to take advantage of many other features like
> kobjects, udev events, and so on. One such example is cpu devices and
> their caches.
> 
> The sysfs for the cpu caches are managed by adding devices with cpu
> as the parent in cpu_device_create() when secondary cpu is brought
> online. Generally when the secondary CPUs are hotplugged back in as part
> of resume from suspend-to-ram, we call cpu_device_create() from the cpu
> hotplug state machine while the cpu device associated with that CPU is
> not yet ready to be resumed as the device_resume() call happens bit
> later. It's not really needed to set the flag is_prepared for cpu
> devices as they are mostly pseudo device and hotplug framework deals
> with state machine and not managed through the cpu device.
> 
> This often results in annoying warning when resuming:
> Enabling non-boot CPUs ...
> CPU1: Booted secondary processor
>  cache: parent cpu1 should not be sleeping
> CPU1 is up
> CPU2: Booted secondary processor
>  cache: parent cpu2 should not be sleeping
> CPU2 is up
>  and so on.
> 
> So in order to fix these kind of errors, we could just completely avoid
> doing any power management related initialisations and operations if
> they are not used by these devices.
> 
> Lets add no_pm_required flags to indicate that the device doesn't
> require any sort of pm activities and all of them can be completely
> skipped. We can use the same flag to also avoid adding not used *power*
> sysfs entries for these devices. For now, lets use this for cpu cache
> devices.
> 
> Cc: Greg Kroah-Hartman 
> Cc: "Rafael J. Wysocki" 
> Reviewed-by: Ulf Hansson 
> Signed-off-by: Sudeep Holla 
> ---
>  drivers/base/cpu.c |  1 +
>  drivers/base/power/main.c  |  7 +++
>  drivers/base/power/sysfs.c |  6 ++
>  include/linux/device.h | 10 ++
>  include/linux/pm.h |  1 +
>  5 files changed, 25 insertions(+)
> 
> v2->v3:
>   - renamed no_pm_required to no_pm
>   - fixed the wrong comment in device_pm_add
>   - add missing check in dpm_sysfs_remove reported by Eugeniu
>   - added Ulf's reviewed-by tag
> 
> v1->v2:
>   - dropped setting the flag for cpu devices, for now just cpu caches
> will make use of this new flag.
> 
> RFC->v1:
>   - dropped the idea of adding cpu hotplug callback to deal just
> with cpu devices, instead add a new flag in the device pm_info
> structure
> 
> [RFC] : https://marc.info/?l=linux-pm=154842896407904=2
> [v1] : https://marc.info/?l=linux-pm=154946578717730=2
> [v2] : https://marc.info/?l=linux-pm=155005931507485=2
> 
> diff --git a/drivers/base/cpu.c b/drivers/base/cpu.c
> index eb9443d5bae1..6ce93a52bf3f 100644
> --- a/drivers/base/cpu.c
> +++ b/drivers/base/cpu.c
> @@ -427,6 +427,7 @@ __cpu_device_create(struct device *parent, void *drvdata,
>   dev->parent = parent;
>   dev->groups = groups;
>   dev->release = device_create_release;
> + device_set_pm_not_required(dev);
>   dev_set_drvdata(dev, drvdata);
> 
>   retval = kobject_set_name_vargs(>kobj, fmt, args);
> diff --git a/drivers/base/power/main.c b/drivers/base/power/main.c
> index 0992e67e862b..6a473004abe6 100644
> --- a/drivers/base/power/main.c
> +++ b/drivers/base/power/main.c
> @@ -124,6 +124,10 @@ void device_pm_unlock(void)
>   */
>  void device_pm_add(struct device *dev)
>  {
> + /* Skip pm setup/initialisation */
> + if (device_pm_not_required(dev))
> + return;
> +
>   pr_debug("PM: Adding info for %s:%s\n",
>dev->bus ? dev->bus->name : "No Bus", dev_name(dev));
>   device_pm_check_callbacks(dev);
> @@ -142,6 +146,9 @@ void device_pm_add(struct device *dev)
>   */
>  void device_pm_remove(struct device *dev)
>  {
> + if (device_pm_not_required(dev))
> + return;
> +
>   pr_debug("PM: Removing info for %s:%s\n",
>dev->bus ? dev->bus->name : "No Bus", dev_name(dev));
>   complete_all(>power.completion);
> diff --git a/drivers/base/power/sysfs.c b/drivers/base/power/sysfs.c
> index d713738ce796..5e8d4867c4da 100644
> --- a/drivers/base/power/sysfs.c
> +++ b/drivers/base/power/sysfs.c
> @@ -648,6 +648,10 @@ int dpm_sysfs_add(struct device *dev)
>  {
>   int rc;
> 
> + /* No need to create pm sysfs if explicitly disabled */
> + if (device_pm_not_required(dev))
> + return 0;
> +
>   rc = sysfs_create_group(>kobj, _attr_group);
>   if (rc)
>   return rc;
> @@ -727,6 +731,8 @@ void rpm_sysfs_remove(struct device *dev)
> 
>  void dpm_sysfs_remove(struct device *dev)
>  {
> + if (device_pm_not_required(dev))
> + return;
>   

BUG: assuming atomic context at kernel/seccomp.c:LINE

[syzbot]

Hello,

syzbot found the following crash on:

HEAD commit:abf446c90405 Add linux-next specific files for 20190220
git tree:   linux-next
console output: https://syzkaller.appspot.com/x/log.txt?x=17f250d8c0
kernel config:  https://syzkaller.appspot.com/x/.config?x=463cb576ac40e350
dashboard link: https://syzkaller.appspot.com/bug?extid=8bf19ee2aa580de7a2a7
compiler:   gcc (GCC) 9.0.0 20181231 (experimental)

Unfortunately, I don't have any reproducer for this crash yet.

IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+8bf19ee2aa580de7a...@syzkaller.appspotmail.com

BUG: assuming atomic context at kernel/seccomp.c:271
in_atomic(): 0, irqs_disabled(): 0, pid: 12803, name: syz-executor.5
no locks held by syz-executor.5/12803.
CPU: 1 PID: 12803 Comm: syz-executor.5 Not tainted 5.0.0-rc7-next-20190220  
#39
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS  
Google 01/01/2011

Call Trace:
 __dump_stack lib/dump_stack.c:77 [inline]
 dump_stack+0x172/0x1f0 lib/dump_stack.c:113
 __cant_sleep kernel/sched/core.c:6218 [inline]
 __cant_sleep.cold+0xa3/0xbb kernel/sched/core.c:6195
 seccomp_run_filters kernel/seccomp.c:271 [inline]
 __seccomp_filter+0x12b/0x12b0 kernel/seccomp.c:801
 __secure_computing+0x101/0x360 kernel/seccomp.c:932
 syscall_trace_enter+0x5bf/0xe10 arch/x86/entry/common.c:120
 do_syscall_64+0x479/0x610 arch/x86/entry/common.c:280
 entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x45ac8a
Code: 25 18 00 00 00 00 74 01 f0 48 0f b1 3d df ba 5f 00 48 39 c2 75 da f3  
c3 0f 1f 84 00 00 00 00 00 48 63 ff b8 e4 00 00 00 0f 05 <48> 3d 00 f0 ff  
ff 77 06 f3 c3 0f 1f 40 00 48 c7 c2 d4 ff ff ff f7

RSP: 002b:7f92ed7b2c58 EFLAGS: 0246 ORIG_RAX: 00e4
RAX: ffda RBX:  RCX: 0045ac8a
RDX: 00017230 RSI: 7f92ed7b2c60 RDI: 0001
RBP: 0073bf00 R08:  R09: 
R10:  R11: 0246 R12: 
R13: 004c4cd5 R14: 004d8890 R15: 


---
This bug is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkal...@googlegroups.com.

syzbot will keep track of this bug report. See:
https://goo.gl/tpsmEJ#bug-status-tracking for how to communicate with  
syzbot.

Re: [PATCH v2 0/2] Fix crash in cper_estatus_check()

[Rafael J. Wysocki]

On Tuesday, February 19, 2019 2:50:04 PM CET Borislav Petkov wrote:
> On Tue, Feb 19, 2019 at 11:00:49AM +0100, Rafael J. Wysocki wrote:
> > Boris, any comments here?
> 
> For both:
> 
> Acked-by: Borislav Petkov 

Both applied, thanks!

Re: [PATCH 1/2] x86: gpio: AMD G-Series pch gpio platform driver

[Linus Walleij]

On Thu, Feb 14, 2019 at 10:56 AM Enrico Weigelt, metux IT consult
 wrote:
> On 08.02.19 15:25, Linus Walleij wrote:
>
> >> +config GPIO_AMD_FCH
> >> +   tristate "GPIO support for AMD Fusion Controller Hub (G-series 
> >> SOCs)"
> >> +   select GPIO_GENERIC
> >
> > You are selecting GPIO_GENERIC, is this necessary? I thought
> > X86 was already selecting this.
>
> Doesn't look so - at least haven't found anything where it's
> automatically selected on x86. OTOH, that wouldn't make much
> sense to me  - I somewhat doubt that x86 can't run w/o that.

Sorry my bad. You should select this if you use it, but are you
using the GPIO MMIO abstractions?
The hallmark of those implementations are that they
call bgpio_init() and this driver does not, and it seems
with the funny layout of the registers it can't even use
it anyway.

> IMHO, dependencies should always be direct - indirect ones could
> suddenly change in subtle ways.

Agreed.

> >> +   priv->gc.owner  = THIS_MODULE;
> >> +   priv->gc.parent = >dev;
> >> +   priv->gc.label  = dev_name(>dev);
> >> +   priv->gc.base   = priv->pdata->gpio_base;
> >
> > No please, use priv->gc.base = -1;
>
> Could I also leave that field untouched (IOW: =0) ?

No unfortunately not, because 0 is a valid GPIO base.

Yours,
Linus Walleij

Re: [PATCH v4] irqchip: gicv3-its: Use NUMA aware memory allocation for ITS tables

[Marc Zyngier]

On Tue, 19 Feb 2019 11:05:38 +,
Shameerali Kolothum Thodi  wrote:
> 
> Hi Marc,
> 
> A gentle reminder on this one...

Thanks for that. Now applied to irqchip-next.

   M.

-- 
Jazz is not dead, it just smell funny.

Re: [PATCH] iwlwifi: mvm: Use div64_s64 instead of do_div in iwl_mvm_debug_range_resp

[Luca Coelho]

On Tue, 2019-02-19 at 11:05 -0800, Nick Desaulniers wrote:
> On Tue, Feb 19, 2019 at 10:21 AM Nathan Chancellor
>  wrote:
> > Clang warns:
> > 
> > drivers/net/wireless/intel/iwlwifi/mvm/ftm-initiator.c:465:2:
> > warning:
> > comparison of distinct pointer types ('typeof ((rtt_avg)) *' (aka
> > 'long
> > long *') and 'uint64_t *' (aka 'unsigned long long *'))
> > [-Wcompare-distinct-pointer-types]
> > do_div(rtt_avg, );
> > ^
> > include/asm-generic/div64.h:222:28: note: expanded from macro
> > 'do_div'
> > (void)(((typeof((n)) *)0) == ((uint64_t *)0));  \
> >~~ ^  ~~~
> > 1 warning generated.
> > 
> > do_div expects an unsigned dividend. Use div64_s64, which expects a
> > signed dividend.
> 
> Eh, IIRC, signed vs unsigned division has implications for rounding
> towards zero or not, but I doubt that the round trip time average
> (RTT
> avg) should ever be negative.  General rule of thumb for C is to keep
> arithmetic signed (even when working with non zero values), so rather
> than make the literal () a unsigned long, I agree with your
> change
> to keep the division signed as well.  Thanks for the fix.
> Reviewed-by: Nick Desaulniers 

Thanks for the patch and for the review.  I've applied this to our
internal tree and it will be sent upstreaming following our normal
upstreaming process.

--
Cheers,
Luca.

Re: [PATCH v1 00/12] qcom: dts: thermal cleanups

[Amit Kucheria]

On Wed, Feb 20, 2019 at 6:56 AM Eduardo Valentin  wrote:
>
> Hey
> On Mon, Feb 18, 2019 at 06:05:14PM +0530, Amit Kucheria wrote:
> > - Expose all temperature sensors on msm8916, msm996, msm8998, sdm845
> > - split up the register address map for msm8998
> > - standardize names of the various thermal-zones across boards to make it
> >   easy for test scripts to parse
> >
>
> I am generally fine with the effort but please fix the following
> (applies for the whole series) wrt to required properties for DT
> thermal:
> a. Trip points for your zones

Thanks for the review.

In some cases, the temperatures are just exposed so something in
userspace might read it and do something with it. We don't expect
kernel trips for them.

Adding trip points also requires me to add cooling-maps (your point b. below).

I guess I'm looking for an example of how to just expose sensor
temperatures w/o any associated trips and cooling maps.

> b. Cooling Mappings for zones that have passive trips.
>

>From what I can see currently only CPUs and GPUs (among the major heat
sources) can passively reduce heat by reducing frequencies.

Things like cameras, display, video might have a more ON/OFF approach
to throttling that might be controlled from userspace. And we don't
have a way to tell in DT that these zones are managed in userspace
(https://patchwork.kernel.org/patch/10259487/)

Re: [PATCH v1 23/24] arm64: dts: qcom: qcs404: Add thermal zones for each sensor

[Amit Kucheria]

On Wed, Feb 20, 2019 at 6:39 AM Eduardo Valentin  wrote:
>
> On Thu, Feb 07, 2019 at 04:19:41PM +0530, Amit Kucheria wrote:
> > qcs404 has 10 sensors connected to the single TSENS IP. Define a thermal
> > zone for each of those sensors to expose the temperature of each zone.
> >
> > Signed-off-by: Amit Kucheria 
> > ---
> >  arch/arm64/boot/dts/qcom/qcs404.dtsi | 243 +++
> >  1 file changed, 243 insertions(+)
> >
> > diff --git a/arch/arm64/boot/dts/qcom/qcs404.dtsi 
> > b/arch/arm64/boot/dts/qcom/qcs404.dtsi
> > index 57d14d8f0c90..ca99c45864df 100644
> > --- a/arch/arm64/boot/dts/qcom/qcs404.dtsi
> > +++ b/arch/arm64/boot/dts/qcom/qcs404.dtsi
> > @@ -3,6 +3,7 @@
> >
> >  #include 
> >  #include 
> > +#include 
> >
> >  / {
> >   interrupt-parent = <>;
> > @@ -30,6 +31,7 @@
> >   reg = <0x100>;
> >   enable-method = "psci";
> >   next-level-cache = <_0>;
> > + #cooling-cells= <2>;
> >   };
> >
> >   CPU1: cpu@101 {
> > @@ -38,6 +40,7 @@
> >   reg = <0x101>;
> >   enable-method = "psci";
> >   next-level-cache = <_0>;
> > + #cooling-cells= <2>;
> >   };
> >
> >   CPU2: cpu@102 {
> > @@ -46,6 +49,7 @@
> >   reg = <0x102>;
> >   enable-method = "psci";
> >   next-level-cache = <_0>;
> > + #cooling-cells= <2>;
> >   };
> >
> >   CPU3: cpu@103 {
> > @@ -54,6 +58,7 @@
> >   reg = <0x103>;
> >   enable-method = "psci";
> >   next-level-cache = <_0>;
> > + #cooling-cells= <2>;
> >   };
> >
> >   L2_0: l2-cache {
> > @@ -507,4 +512,242 @@
> >   #interrupt-cells = <2>;
> >   };
> >   };
> > +
> > + thermal-zones {
>
> There are several zones with passive trips and no cooling maps.

Indeed. The policy bits are still a WIP and in some cases the
throttling is handled by someone in userspace. But I'd like to expose
at least the temperatures at each of the sensors to make it easier for
others to use this information. See my reply to the cover letter.

Regards,
Amit




> > + aoss-thermal {
> > + polling-delay-passive = <250>;
> > + polling-delay = <1000>;
> > +
> > + thermal-sensors = < 0>;
> > +
> > + trips {
> > + aoss_alert0: trip-point@0 {
> > + temperature = <95000>;
> > + hysteresis = <2000>;
> > + type = "passive";
> > + };
> > + aoss_crit: aoss_crit {
> > + temperature = <11>;
> > + hysteresis = <2000>;
> > + type = "critical";
> > + };
> > + };
> > + };
> > +
> > + dsp-thermal {
> > + polling-delay-passive = <250>;
> > + polling-delay = <1000>;
> > +
> > + thermal-sensors = < 1>;
> > +
> > + trips {
> > + dsp_alert0: trip-point@0 {
> > + temperature = <95000>;
> > + hysteresis = <2000>;
> > + type = "passive";
> > + };
> > + dsp_crit: dsp_crit {
> > + temperature = <11>;
> > + hysteresis = <2000>;
> > + type = "critical";
> > + };
> > + };
> > + };
> > +
> > + lpass-thermal {
> > + polling-delay-passive = <250>;
> > + polling-delay = <1000>;
> > +
> > + thermal-sensors = < 2>;
> > +
> > + trips {
> > + lpass_alert0: trip-point@0 {
> > + temperature = <95000>;
> > + hysteresis = <2000>;
> > + type = "passive";
> > + };
> > + lpass_crit: lpass_crit {
> > + temperature = <11>;
> > + hysteresis = <2000>;
> > + type = "critical";
> > + };
> > + };
> > + };
> > +
> > + wlan-thermal {
> > 

Re: [PATCHv7] x86/kdump: bugfix, make the behavior of crashkernel=X consistent with kaslr

[Dave Young]

On 02/20/19 at 09:32am, Borislav Petkov wrote:
> On Mon, Feb 18, 2019 at 09:48:20AM +0800, Dave Young wrote:
> > It is ideal if kernel can do it automatically, but I'm not sure if
> > kernel can predict the swiotlb reserved size automatically.
> 
> Do you see how even more absurd this gets?
> 
> If the kernel cannot know the swiotlb reserved size automatically, how
> is the normal user even supposed to know?!
> 
> I see swiotlb_size_or_default() so we have a sane default which we fall
> back to. Now where's the problem with that?

Good question, I expect some answer from people who know more about the
background.  It would be good to have some actual test results, Pingfan
is trying to do some tests.

Previously Joerg posted below patch, maybe he has some idea. Joerg?

commit 94fb9334182284e8e7e4bcb9125c25dc33af19d4
Author: Joerg Roedel 
Date:   Wed Jun 10 17:49:42 2015 +0200

x86/crash: Allocate enough low memory when crashkernel=high

Thanks
Dave

Re: [PATCH 0/5] iio:potentiostat:lmp91000: Adjust codestyle, and minor cleanup changes

[Jonathan Cameron]

On Mon, 18 Feb 2019 14:22:31 -0300
Lucas Oshiro  wrote:

> Hi,
> 
> We solved some checkpath.el CHECKs and WARNINGs. We also inverted the arms of
> an if statement, in order to make the code smaller as the else statement was
> supressed. We added a missing '\n' on a dev_err message.

Please try to identify the original author.  Matt is still definitely
about, and he is obviously likely to be able to provide the most detailed
review of changes to this driver.

Thanks,

Jonathan

> 
> Lucas Oshiro (5):
>   iio:potentiostat:lmp91000: remove unnecessary parentheses
>   iio:potentiostat:lmp91000: insert braces around if arms
>   iio:potentiostat:lmp91000: reduce line width and remove blank line
>   iio:potentiostat:lmp91000: invert if statement
>   iio:potentiostat:lmp91000: add '\n' on dev_err
> 
>  drivers/iio/potentiostat/lmp91000.c | 14 ++
>  1 file changed, 6 insertions(+), 8 deletions(-)
> 

Re: [PATCH 0/2] pinctrl STM32 updates

[Linus Walleij]

On Thu, Feb 14, 2019 at 5:54 PM Alexandre Torgue
 wrote:

> Please find 2 updates for STM32 pinctrl driver:
>
>  -Fix a memory leak issue present since the beginning of the driver.
>  -Handle error case when a hwspinlock can't get locked.

Patches applied for v5.1.

Yours,
Linus Walleij

Re: [RFC][PATCH 00/16] sched: Core scheduling

[Peter Zijlstra]

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

On Tue, Feb 19, 2019 at 02:07:01PM -0800, Greg Kerr wrote:
> Thanks for posting this patchset Peter. Based on the patch titled, "sched: A
> quick and dirty cgroup tagging interface," I believe cgroups are used to
> define co-scheduling groups in this implementation.
> 
> Chrome OS engineers (kerr...@google.com, mpden...@google.com, and
> pal...@google.com) are considering an interface that is usable by unprivileged
> userspace apps. cgroups are a global resource that require privileged access.
> Have you considered an interface that is akin to namespaces? Consider the
> following strawperson API proposal (I understand prctl() is generally
> used for process
> specific actions, so we aren't married to using prctl()):

I don't think we're anywhere near the point where I care about
interfaces with this stuff.

Interfaces are a trivial but tedious matter once the rest works to
satisfaction.

As it happens; there is actually a bug in that very cgroup patch that
can cause undesired scheduling. Try spotting and fixing that.

Another question is if we want to be L1TF complete (and how strict) or
not, and if so, build the missing pieces (for instance we currently
don't kick siblings on IRQ/trap/exception entry -- and yes that's nasty
and horrible code and missing for that reason).

So first; does this provide what we need? If that's sorted we can
bike-shed on uapi/abi.

Re: [PATCH v3 1/2] gpio: AMD G-Series PCH gpio driver

[Linus Walleij]

On Thu, Feb 14, 2019 at 11:05 PM Enrico Weigelt, metux IT consult
 wrote:

> GPIO platform driver for the AMD G-series PCH (eg. on GX-412TC)
>
> This driver doesn't registers itself automatically, as it needs to
> be provided with platform specific configuration, provided by some
> board driver setup code.
>
> Didn't implement oftree probing yet, as it's rarely found on x86.
>
> Cc: linux-g...@vger.kernel.org
> Cc: linus.wall...@linaro.org
> Cc: bgolaszew...@baylibre.com
> Cc: dvh...@infradead.org
> Cc: a...@infradead.org
> Cc: platform-driver-...@vger.kernel.org
>
> Signed-off-by: Enrico Weigelt, metux IT consult 

(...)
> +config GPIO_AMD_FCH
> +   tristate "GPIO support for AMD Fusion Controller Hub (G-series SOCs)"
> +   select GPIO_GENERIC

Now I see that you do this

> +   spin_lock_irqsave(>gc.bgpio_lock, flags);
(...)
> +   spin_unlock_irqrestore(>gc.bgpio_lock, flags);

Only to get that spinlock.

That's not what GPIO_GENERIC is for, just put a spinlock in your
local state container struct amd_fch_gpio_priv instead.

Yours,
Linus Walleij

Re: [PATCH] nvme: Enable acceleration feature of A64FX processor

[Takao Indoh]

On Thu, Feb 14, 2019 at 08:44:48PM +, Elliott, Robert (Persistent Memory) 
wrote:
> 
> 
> > -Original Message-
> > From: Linux-nvme [mailto:linux-nvme-boun...@lists.infradead.org] On Behalf 
> > Of Keith Busch
> > Sent: Tuesday, February 5, 2019 8:39 AM
> > To: Takao Indoh 
> > Cc: Takao Indoh ; s...@grimberg.me; 
> > linux-kernel@vger.kernel.org; linux-
> > n...@lists.infradead.org; ax...@fb.com; h...@lst.de
> > Subject: Re: [PATCH] nvme: Enable acceleration feature of A64FX processor
> > 
> > On Tue, Feb 05, 2019 at 09:56:05PM +0900, Takao Indoh wrote:
> > > On Fri, Feb 01, 2019 at 07:54:14AM -0700, Keith Busch wrote:
> > > > On Fri, Feb 01, 2019 at 09:46:15PM +0900, Takao Indoh wrote:
> > > > > From: Takao Indoh 
> > > > >
> > > > > Fujitsu A64FX processor has a feature to accelerate data transfer of
> > > > > internal bus by relaxed ordering. It is enabled when the bit 56 of dma
> > > > > address is set to 1.
> > > >
> > > > Wait, what? RO is a standard PCIe TLP attribute. Why would we need this?
> > >
> > > I should have explained this patch more carefully.
> > >
> > > Standard PCIe devices can use Relaxed Ordering (RO) by setting Attr
> > > field in the TLP header, however, this mechanism cannot be utilized if
> > > the device does not support RO feature. Fujitsu A64FX processor has an
> > > alternate feature to enable RO in its Root Port by setting the bit 56 of
> > > DMA address. This mechanism enables to utilize RO feature even if the
> > > device does not support standard PCIe RO.
> > 
> > I think you're better of just purchasing devices that support the
> > capability per spec rather than with a non-standard work around.
> > 
> 
> The PCIe and NVMe specifications dosn't standardize a way to tell the device
> when to use RO, which leads to system workarounds like this.
> 
> The Enable Relaxed Ordering bit defined by PCIe tells the device when it
> cannot use RO, but doesn't advise when it should or shall use RO.
> 
> For SCSI Express (SOP+PQI), we were going to allow specifying these
> on a per-command basis:
> * TLP attributes (No Snoop, Relaxed Ordering, ID-based Ordering)
> * TLP processing hints (Processing Hints and Steering Tags)
> 
> to be used by the data transfers for the command. In some systems, one
> setting per queue or per device might suffice. Transactions to the
> queues and doorbells require stronger ordering.
> 
> For this workaround:
> * making an extra pass through the SGL to set the address bit is 
> inefficient; it should be done as the SGL is created.

Thanks for your comment, do you mean this should be done in
nvme_pci_setup_sgls()/nvme_pci_setup_prps()?

> * why doesn't it support PRP Lists?

This patch does not support PRP because PRP is used for small data and
we cannot get enough performance improvement by this feature. But I can
support PRP to improve performance of the device which is compliant with
NVMe Spec 1.0 or does not support SGL.

> * how does this interact with an iommu, if there is one? Must the 
> address with bit 56 also be granted permission, or is that
> stripped off before any iommu comparisons?

The latter. A bit 56 is cleared in Root Port before pass it to iommu.

Thanks,
Takao Indoh

Re: ext4 corruption on alpha with 4.20.0-09062-gd8372ba8ce28

[Jan Kara]

On Wed 20-02-19 08:31:05, Meelis Roos wrote:
> > Could
> > https://lore.kernel.org/linux-mm/20190219123212.29838-1-lar...@axis.com/T/#u
> > be relevant?
> 
> Tried it, still broken.

OK, I didn't put too much hope into this patch as you see filesystem
metadata corruption so icache/dcache coherency issues seemed unlikely.
Still good that you've tried so that we are sure.

> I wrote:
> 
> > But my kernel config had memory compaction (that turned on page migration) 
> > and
> > bounce buffers. I do not remember why I found them necessary but I will try
> > without them.
> 
> First, I found out that both the problematic alphas had memory compaction and
> page migration and bounce buffers turned on, and working alphas had them off.
> 
> Next, turing off these options makes the problematic alphas work.

OK, thanks for testing! Can you narrow down whether the problem is due to
CONFIG_BOUNCE or CONFIG_MIGRATION + CONFIG_COMPACTION? These are two
completely different things so knowing where to look will help. Thanks!

Honza
-- 
Jan Kara 
SUSE Labs, CR

Re: [PATCH v3 1/7] dump_stack: Support adding to the dump stack arch description

[Michael Ellerman]

Andrea Parri  writes:
> On Mon, Feb 11, 2019 at 03:38:59PM +0100, Petr Mladek wrote:
>> On Mon 2019-02-11 13:50:35, Andrea Parri wrote:
>> > On Thu, Feb 07, 2019 at 11:46:29PM +1100, Michael Ellerman wrote:
>> > > Arch code can set a "dump stack arch description string" which is
>> > > displayed with oops output to describe the hardware platform.
>> > > 
>> > > It is useful to initialise this as early as possible, so that an early
>> > > oops will have the hardware description.
>> > > 
>> > > However in practice we discover the hardware platform in stages, so it
>> > > would be useful to be able to incrementally fill in the hardware
>> > > description as we discover it.
>> > > 
>> > > This patch adds that ability, by creating dump_stack_add_arch_desc().
>> > > 
>> > > If there is no existing string it behaves exactly like
>> > > dump_stack_set_arch_desc(). However if there is an existing string it
>> > > appends to it, with a leading space.
>> > > 
>> > > This makes it easy to call it multiple times from different parts of the
>> > > code and get a reasonable looking result.
>> > > 
>> > > Signed-off-by: Michael Ellerman 
>> > > ---
>> > >  include/linux/printk.h |  5 
>> > >  lib/dump_stack.c   | 58 ++
>> > >  2 files changed, 63 insertions(+)
>> > > 
>> > > v3: No change, just widened Cc list.
>> > > 
>> > > v2: Add a smp_wmb() and comment.
>> > > 
>> > > v1 is here for reference 
>> > > https://lore.kernel.org/lkml/1430824337-15339-1-git-send-email-...@ellerman.id.au/
>> > > 
>> > > I'll take this series via the powerpc tree if no one minds?
>> > > 
>> > > 
>> > > diff --git a/include/linux/printk.h b/include/linux/printk.h
>> > > index 77740a506ebb..d5fb4f960271 100644
>> > > --- a/include/linux/printk.h
>> > > +++ b/include/linux/printk.h
>> > > @@ -198,6 +198,7 @@ u32 log_buf_len_get(void);
>> > >  void log_buf_vmcoreinfo_setup(void);
>> > >  void __init setup_log_buf(int early);
>> > >  __printf(1, 2) void dump_stack_set_arch_desc(const char *fmt, ...);
>> > > +__printf(1, 2) void dump_stack_add_arch_desc(const char *fmt, ...);
>> > >  void dump_stack_print_info(const char *log_lvl);
>> > >  void show_regs_print_info(const char *log_lvl);
>> > >  extern asmlinkage void dump_stack(void) __cold;
>> > > @@ -256,6 +257,10 @@ static inline __printf(1, 2) void 
>> > > dump_stack_set_arch_desc(const char *fmt, ...)
>> > >  {
>> > >  }
>> > >  
>> > > +static inline __printf(1, 2) void dump_stack_add_arch_desc(const char 
>> > > *fmt, ...)
>> > > +{
>> > > +}
>> > > +
>> > >  static inline void dump_stack_print_info(const char *log_lvl)
>> > >  {
>> > >  }
>> > > diff --git a/lib/dump_stack.c b/lib/dump_stack.c
>> > > index 5cff72f18c4a..69b710ff92b5 100644
>> > > --- a/lib/dump_stack.c
>> > > +++ b/lib/dump_stack.c
>> > > @@ -35,6 +35,64 @@ void __init dump_stack_set_arch_desc(const char *fmt, 
>> > > ...)
>> > >  va_end(args);
>> > >  }
>> > >  
>> > > +/**
>> > > + * dump_stack_add_arch_desc - add arch-specific info to show with task 
>> > > dumps
>> > > + * @fmt: printf-style format string
>> > > + * @...: arguments for the format string
>> > > + *
>> > > + * See dump_stack_set_arch_desc() for why you'd want to use this.
>> > > + *
>> > > + * This version adds to any existing string already created with either
>> > > + * dump_stack_set_arch_desc() or dump_stack_add_arch_desc(). If there 
>> > > is an
>> > > + * existing string a space will be prepended to the passed string.
>> > > + */
>> > > +void __init dump_stack_add_arch_desc(const char *fmt, ...)
>> > > +{
>> > > +va_list args;
>> > > +int pos, len;
>> > > +char *p;
>> > > +
>> > > +/*
>> > > + * If there's an existing string we snprintf() past the end of 
>> > > it, and
>> > > + * then turn the terminating NULL of the existing string into a 
>> > > space
>> > > + * to create one string separated by a space.
>> > > + *
>> > > + * If there's no existing string we just snprintf() to the 
>> > > buffer, like
>> > > + * dump_stack_set_arch_desc(), but without calling it because 
>> > > we'd need
>> > > + * a varargs version.
>> > > + */
>> > > +len = strnlen(dump_stack_arch_desc_str, 
>> > > sizeof(dump_stack_arch_desc_str));
>> > > +pos = len;
>> > > +
>> > > +if (len)
>> > > +pos++;
>> > > +
>> > > +if (pos >= sizeof(dump_stack_arch_desc_str))
>> > > +return; /* Ran out of space */
>> > > +
>> > > +p = _stack_arch_desc_str[pos];
>> > > +
>> > > +va_start(args, fmt);
>> > > +vsnprintf(p, sizeof(dump_stack_arch_desc_str) - pos, fmt, args);
>> > > +va_end(args);
>> > > +
>> > > +if (len) {
>> > > +/*
>> > > + * Order the stores above in vsnprintf() vs the store 
>> > > of the
>> > > + * space below which joins the two strings. Note this 
>> > > doesn't

Re: [PATCH 5/5] iio:potentiostat:lmp91000: add '\n' on dev_err

[Jonathan Cameron]

On Mon, 18 Feb 2019 13:01:23 -0800
Joe Perches  wrote:

> On Mon, 2019-02-18 at 14:22 -0300, Lucas Oshiro wrote:
> > Add missing '\n' at the end of dev_err message on line 215.  
> []
> > diff --git a/drivers/iio/potentiostat/lmp91000.c 
> > b/drivers/iio/potentiostat/lmp91000.c  
> []
> > @@ -212,7 +212,7 @@ static int lmp91000_read_config(struct lmp91000_data 
> > *data)
> > ret = of_property_read_u32(np, "ti,tia-gain-ohm", );
> > if (ret) {
> > if (!of_property_read_bool(np, "ti,external-tia-resistor")) {
> > -   dev_err(dev, "no ti,tia-gain-ohm defined");
> > +   dev_err(dev, "no ti,tia-gain-ohm defined\n");  
> 
> Perhaps a copy/paste error as the test is for
> external-tia-resistor and not tia-gain-ohm
> 
It is an odd construct, but I think this is correct.  What it is actually
saying is that, given that we don't have an external resistor, we care
that the tia-gain-ohm isn't set (otherwise it wouldn't matter).

From the docs
  - ti,external-tia-resistor: if the property ti,tia-gain-ohm is not defined 
this
needs to be set to signal that an external resistor value is being used.

So, it might be ideal to say that tia-gain-ohm is not defined and we do
not have an external resistor specified.

So not wrong, but could be more informative!  So perhaps a follow up patch
to tidy that up would be good.

Jonathan
> 

Re: [PATCH 7/8] drm/i915/gvt: vGPU device config data save/restore interface

[Zhenyu Wang]

On 2019.02.19 02:46:32 -0500, Yan Zhao wrote:
> The patch implments the gvt interface intel_gvt_save_restore to
> save/restore vGPU's device config data for live migration.
> 
> vGPU device config data includes vreg, vggtt, vcfg space, workloads, ppgtt,
> execlist.
> It does not include dirty pages in system memory produced by vGPU.
> 
> Signed-off-by: Yulei Zhang 
> Signed-off-by: Xiao Zheng 
> Signed-off-by: Zhenyu Wang 
> Signed-off-by: Yan Zhao 

...

> +
> +#ifndef __GVT_MIGRATE_H__
> +#define __GVT_MIGRATE_H__
> +
> +#define MIGRATION_DIRTY_BITMAP_SIZE (16*1024UL)
> +
> +/* Assume 9MB is enough to descript VM kernel state */
> +#define MIGRATION_IMG_MAX_SIZE (9*1024UL*1024UL)
> +#define GVT_MMIO_SIZE (2*1024UL*1024UL)
> +#define GVT_MIGRATION_VERSION0
> +
> +enum gvt_migration_type_t {
> + GVT_MIGRATION_NONE,
> + GVT_MIGRATION_HEAD,
> + GVT_MIGRATION_CFG_SPACE,
> + GVT_MIGRATION_VREG,
> + GVT_MIGRATION_SREG,
> + GVT_MIGRATION_GTT,
> + GVT_MIGRATION_PPGTT,
> + GVT_MIGRATION_WORKLOAD,
> + GVT_MIGRATION_EXECLIST,
> +};
> +
> +struct gvt_ppgtt_entry_t {
> + int page_table_level;
> + u64 pdp[4];
> +};
> +
> +struct gvt_pending_workload_t {
> + int ring_id;
> + bool emulate_schedule_in;
> + struct execlist_ctx_descriptor_format ctx_desc;
> + struct intel_vgpu_elsp_dwords elsp_dwords;
> +};
> +
> +struct gvt_region_t {
> + enum gvt_migration_type_t type;
> + u32 size;   /* obj size of bytes to read/write */
> +};
> +
> +struct gvt_migration_obj_t {
> + void *img;
> + void *vgpu;
> + u32 offset;
> + struct gvt_region_t region;
> + /* operation func defines how data save-restore */
> + struct gvt_migration_operation_t *ops;
> + char *name;
> +};
> +
> +struct gvt_migration_operation_t {
> + /* called during pre-copy stage, VM is still alive */
> + int (*pre_copy)(const struct gvt_migration_obj_t *obj);
> + /* called before when VM was paused,
> +  * return bytes transferred
> +  */
> + int (*pre_save)(const struct gvt_migration_obj_t *obj);
> + /* called before load the state of device */
> + int (*pre_load)(const struct gvt_migration_obj_t *obj, u32 size);
> + /* called after load the state of device, VM already alive */
> + int (*post_load)(const struct gvt_migration_obj_t *obj, u32 size);
> +};
> +
> +struct gvt_image_header_t {
> + int version;
> + int data_size;
> + u64 crc_check;
> + u64 global_data[64];
> +};

I think this misses device info that should ship with the image,
currently what I can think is that each platform should have seperate
type, e.g BDW, SKL, KBL, etc. We won't allow to restore onto different
platform than the source.

> +
> +#endif
> diff --git a/drivers/gpu/drm/i915/gvt/mmio.c b/drivers/gpu/drm/i915/gvt/mmio.c
> index 43f65848ecd6..6221d2f274fc 100644
> --- a/drivers/gpu/drm/i915/gvt/mmio.c
> +++ b/drivers/gpu/drm/i915/gvt/mmio.c
> @@ -50,6 +50,19 @@ int intel_vgpu_gpa_to_mmio_offset(struct intel_vgpu *vgpu, 
> u64 gpa)
>   return gpa - gttmmio_gpa;
>  }
>  
> +/**
> + * intel_vgpu_mmio_offset_to_GPA - translate a MMIO offset to GPA
> + * @vgpu: a vGPU
> + *
> + * Returns:
> + * Zero on success, negative error code if failed
> + */
> +int intel_vgpu_mmio_offset_to_gpa(struct intel_vgpu *vgpu, u64 offset)
> +{
> + return offset + ((*(u64 *)(vgpu_cfg_space(vgpu) + PCI_BASE_ADDRESS_0)) &
> + ~GENMASK(3, 0));
> +}
> +
>  #define reg_is_mmio(gvt, reg)  \
>   (reg >= 0 && reg < gvt->device_info.mmio_size)
>  
> diff --git a/drivers/gpu/drm/i915/gvt/mmio.h b/drivers/gpu/drm/i915/gvt/mmio.h
> index 1ffc69eba30e..a2bddb0257cf 100644
> --- a/drivers/gpu/drm/i915/gvt/mmio.h
> +++ b/drivers/gpu/drm/i915/gvt/mmio.h
> @@ -82,6 +82,7 @@ void intel_vgpu_reset_mmio(struct intel_vgpu *vgpu, bool 
> dmlr);
>  void intel_vgpu_clean_mmio(struct intel_vgpu *vgpu);
>  
>  int intel_vgpu_gpa_to_mmio_offset(struct intel_vgpu *vgpu, u64 gpa);
> +int intel_vgpu_mmio_offset_to_gpa(struct intel_vgpu *vgpu, u64 offset);
>  
>  int intel_vgpu_emulate_mmio_read(struct intel_vgpu *vgpu, u64 pa,
>   void *p_data, unsigned int bytes);
> diff --git a/drivers/gpu/drm/i915/gvt/vgpu.c b/drivers/gpu/drm/i915/gvt/vgpu.c
> index fcccda35a456..7676dcfdca09 100644
> --- a/drivers/gpu/drm/i915/gvt/vgpu.c
> +++ b/drivers/gpu/drm/i915/gvt/vgpu.c
> @@ -213,6 +213,7 @@ void intel_gvt_activate_vgpu(struct intel_vgpu *vgpu)
>  {
>   mutex_lock(>gvt->lock);
>   vgpu->active = true;
> + intel_vgpu_start_schedule(vgpu);
>   mutex_unlock(>gvt->lock);
>  }
>  
> -- 
> 2.17.1
> 
> ___
> intel-gvt-dev mailing list
> intel-gvt-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gvt-dev

-- 
Open Source Technology Center, Intel ltd.

$gpg --keyserver wwwkeys.pgp.net --recv-keys 4D781827


signature.asc
Description: PGP signature

RE: [PATCH] dt-bindings: imx: update scu resource id headfile

[Aisheng Dong]

> From: Marco Felsch [mailto:m.fel...@pengutronix.de]
> Sent: Wednesday, February 20, 2019 4:17 PM
> On 19-02-20 03:38, Aisheng Dong wrote:
> > [...]
> >
> > > > I don't like droping some ID's (e.g. IMX_SC_R_DC_0_CAPTURE0) by
> > > > mark them as unused or even worse give them a other meaning. IMHO
> > > > the scu-api should be stable since day 1 and the ID's should only be
> extended.
> > > > Marking ID's as deprecated is much better than moving them around.
> > >
> > > I agree the SCU APIs should be stable since day 1 and the ID should
> > > ONLY be extended, but that is the best cases, the reality is, there
> > > are different SoCs/Revision, some revisions may remove the resources
> > > ID defined in pre-coded SCU firmware, like the
> > > IMX_SC_R_DC_0_CAPTURE0 etc., so SCU APIs removes them after real
> > > silicon arrived, now latest SCU firmware marks them as UNUSED, they
> > > could be replaced by some other new resources in later new SoC, I am
> > > NOT sure, but if it happens, this resource ID table should be
> > > updated anyway, leaving the out-of-date resource ID table there will have
> issues, since it is NOT sync with SCU firmware.
> > >
> > > So how to resolve such issue? We hope the SCU firmware should be
> > > stable since day 1, but the truth is NOT, could be still some
> > > updates but NOT very often. And I believe the updates will NOT break old
> kernel version.
> 
> Hi Anson,
> 
> Please don't mix the dt-bindings and the kernel related stuff.
> Unfortunately the bindings are within the kernel repo which in fact is great 
> for
> us kernel developer but the bindings are also used in other projects such as
> barebox or other kernels (don't know the BSD guys). So you can't ensure that
> your change will break something. Please keep that in mind.
> 
> IMHO solving that issue should be done by the scu firmware. I tought the scu 
> is
> a cortex-m4 with a bunch of embedded flash and ram (I don't know that much
> about the scu since it is closed/black-boxed). Why do you don't use a
> translation table within the scu? As I said earlier I don't like the 
> redefinition of
> ID's since they are now part of the dt-bindings.
> The bindings can store up to 32bit values which is a large number ;) IMHO
> wasting some ID's in favour of stability is a better solution.
> 

As far as I know, those remove resource IDs are pre-defined and has never been 
used
and won't be used anymore by SC firmware. (Anson can double check it)
So I think it's safe to remove them or mark them as deprecated.

Personally I may prefer to remove them as they never worked to avoid confusing,
especially at this early stage for mx8.

Regards
Dong Aisheng

Re: [PATCH][udf-next] udf: don't call mark_buffer_dirty on a null bh pointer

[Jan Kara]

On Tue 19-02-19 08:17:09, Steve Magnani wrote:
> On 2/19/19 8:02 AM, Jan Kara wrote:
> > On Tue 19-02-19 11:44:03, Colin King wrote:
> > > From: Colin Ian King 
> > > 
> > > There is a null check on the pointer bh to avoid a null pointer 
> > > dereference
> > > on bh->b_data however later bh is passed to mark_buffer_dirty that can 
> > > also
> > > cause a null pointer dereference on bh.  Avoid this potential null pointer
> > > dereference by moving the call to mark_buffer_dirty inside the null 
> > > checked
> > > block.
> > > 
> > > Fixes: e8b4274735e4 ("udf: finalize integrity descriptor before 
> > > writeback")
> > > Signed-off-by: Colin Ian King 
> > Thanks for the patch! In fact it is the 'if (bh)' check that's
> > unnecessarily defensive (we cannot have sbi->s_lvid_dirty and
> > !sbi->s_lvid_bh). So I'll just drop that check (attached patch).
> > 
> > Honza
> > 
> > > ---
> > >   fs/udf/super.c | 12 ++--
> > >   1 file changed, 6 insertions(+), 6 deletions(-)
> > > 
> > > diff --git a/fs/udf/super.c b/fs/udf/super.c
> > > index a6940d90bedd..b7e9a83d39db 100644
> > > --- a/fs/udf/super.c
> > > +++ b/fs/udf/super.c
> > > @@ -2336,13 +2336,13 @@ static int udf_sync_fs(struct super_block *sb, 
> > > int wait)
> > >   lvid = (struct logicalVolIntegrityDesc 
> > > *)bh->b_data;
> > >   udf_finalize_lvid(lvid);
> > > - }
> > > - /*
> > > -  * Blockdevice will be synced later so we don't have to submit
> > > -  * the buffer for IO
> > > -  */
> > > - mark_buffer_dirty(bh);
> > > + /*
> > > +  * Blockdevice will be synced later so we don't have
> > > +  * to submit the buffer for IO
> > > +  */
> > > + mark_buffer_dirty(bh);
> > > + }
> > >   sbi->s_lvid_dirty = 0;
> > >   }
> > >   mutex_unlock(>s_alloc_mutex);
> > > -- 
> > > 2.20.1
> > > 
> Reviewed-by: Steven J. Magnani 

Is this Reviewed-by for my fixup or the Colin's? Because I've decided to
rather remove the 'if (bh)' check completely since it is pointless...

Honza
-- 
Jan Kara 
SUSE Labs, CR

Re: [PATCH] platform: set of_node in platform_device_register_full()

[Rafael J. Wysocki]

On Mon, Feb 18, 2019 at 12:10 PM Måns Rullgård  wrote:
>
> "Rafael J. Wysocki"  writes:
>
> > On Sat, Feb 16, 2019 at 5:50 PM Mans Rullgard  wrote:
> >>
> >> If the provided fwnode is an OF node, set dev.of_node as well.
> >>
> >> Signed-off-by: Mans Rullgard 
> >> ---
> >>  drivers/base/platform.c | 1 +
> >>  1 file changed, 1 insertion(+)
> >>
> >> diff --git a/drivers/base/platform.c b/drivers/base/platform.c
> >> index dff82a3c2caa..853a1d0e5845 100644
> >> --- a/drivers/base/platform.c
> >> +++ b/drivers/base/platform.c
> >> @@ -512,6 +512,7 @@ struct platform_device *platform_device_register_full(
> >>
> >> pdev->dev.parent = pdevinfo->parent;
> >> pdev->dev.fwnode = pdevinfo->fwnode;
> >> +   pdev->dev.of_node = of_node_get(to_of_node(pdev->dev.fwnode));
> >
> > of_node_get() generally does a kobject_get() on the node's kobject, so
> > when is that reference dropped?  Or if it doesn't need to be dropped
> > at all, why is this the case?
>
> platform_device_release() calls of_device_node_put().

Yes, it does, but this is the reference that's already acquired for
devices added while parsing DT, isn't it?

Your change adds an extra reference AFAICS.

Also, why is this patch needed?

Re: [PATCH v2 01/14] dt-bindings: remoteproc: Add TI PRUSS bindings

[Linus Walleij]

On Fri, Feb 15, 2019 at 2:00 AM Suman Anna  wrote:

> Mark, Linus,
>
> So, I hope it is clear from Roger's responses that above assertions do
> not hold true to this INTC, and so want to confirm that we are good with
> the current non-hierarchical design.

IIUC the 64 lines are latched onto 8 lines, but all 64 lines have
individual masking and ACKing bits and can all be used at the same
time, so yes that is cascading and then you should indeed use
the chained (or nested) IRQ handler.

Yours,
Linus Walleij

Re: [PATCH 4/5] iio:potentiostat:lmp91000: invert if statement

[Jonathan Cameron]

On Mon, 18 Feb 2019 14:22:35 -0300
Lucas Oshiro  wrote:

> Invert if statement arms in line 214, in order to make the code cleaner
> 
> Signed-off-by: Lucas Oshiro 
> Signed-off-by: Anderson Reis 

Given this undoes one of the earlier changes, please merge them.

Jonathan

> ---
>  drivers/iio/potentiostat/lmp91000.c | 5 ++---
>  1 file changed, 2 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/iio/potentiostat/lmp91000.c 
> b/drivers/iio/potentiostat/lmp91000.c
> index 6dba26121a62..7229ef59590a 100644
> --- a/drivers/iio/potentiostat/lmp91000.c
> +++ b/drivers/iio/potentiostat/lmp91000.c
> @@ -211,12 +211,11 @@ static int lmp91000_read_config(struct lmp91000_data 
> *data)
>  
>   ret = of_property_read_u32(np, "ti,tia-gain-ohm", );
>   if (ret) {
> - if (of_property_read_bool(np, "ti,external-tia-resistor")) {
> - val = 0;
> - } else {
> + if (!of_property_read_bool(np, "ti,external-tia-resistor")) {
>   dev_err(dev, "no ti,tia-gain-ohm defined");
>   return ret;
>   }
> + val = 0;
>   }
>  
>   ret = -EINVAL;

Re: [PATCH] pinctrl: nomadik: fix possible object reference leak

[Linus Walleij]

On Fri, Feb 15, 2019 at 9:01 AM WangBo  wrote:

> The of_find_device_by_node takes a reference to the struct device
> when find the match device ,we should release it when fail.
>
> Signed-off-by: WangBo 

Patch applied!

Yours,
Linus Walleij

Re: linux-next: Tree for Feb 20

[Jarkko Sakkinen]

On Wed, Feb 20, 2019 at 05:11:15PM +0800, Zhangshaokun wrote:
> There is a compiler failure on arm64 platform, as follow:
> 
>   AS  arch/arm64/kvm/hyp.o
>   CC  kernel/trace/ring_buffer.o
> In file included from security/integrity/ima/ima_fs.c:30:0:
> security/integrity/ima/ima.h:176:7: error: redeclaration of enumerator ‘NONE’
>   hook(NONE)   \
>^
> security/integrity/ima/ima.h:188:34: note: in definition of macro 
> ‘__ima_hook_enumify’
>  #define __ima_hook_enumify(ENUM) ENUM,
>   ^
> security/integrity/ima/ima.h:191:2: note: in expansion of macro ‘__ima_hooks’
>   __ima_hooks(__ima_hook_enumify)
>   ^
> In file included from ./arch/arm64/include/asm/acpi.h:15:0,
>  from ./include/acpi/acpi_io.h:7,
>  from ./include/linux/acpi.h:47,
>  from ./include/linux/tpm.h:26,
>  from security/integrity/ima/ima.h:25,
>  from security/integrity/ima/ima_fs.c:30:
> ./include/linux/efi.h:1716:2: note: previous definition of ‘NONE’ was here
>   NONE,
>   ^
> scripts/Makefile.build:276: recipe for target 
> 'security/integrity/ima/ima_fs.o' failed
> make[3]: *** [security/integrity/ima/ima_fs.o] Error 1
> 
> I dug it and it is the commit 901615cb916d ("tpm: move tpm_chip definition to 
> include/linux/tpm.h")

This results from a new include in tpm.h:

  #include 

Must be fixed either in include/linux/efi.h or security/integrity/ima.h as
those files have a name collision. Makes me wonder why neither has taken
care of prefixing the constants properly.

/Jarkko

Re: Linux 3.18.135

[Greg KH]

diff --git a/Makefile b/Makefile
index b82f7c3383ec..8cec2faf5d40 100644
--- a/Makefile
+++ b/Makefile
@@ -1,6 +1,6 @@
 VERSION = 3
 PATCHLEVEL = 18
-SUBLEVEL = 134
+SUBLEVEL = 135
 EXTRAVERSION =
 NAME = Diseased Newt
 
diff --git a/arch/alpha/include/asm/irq.h b/arch/alpha/include/asm/irq.h
index 06377400dc09..469642801a68 100644
--- a/arch/alpha/include/asm/irq.h
+++ b/arch/alpha/include/asm/irq.h
@@ -55,15 +55,15 @@
 
 #elif defined(CONFIG_ALPHA_DP264) || \
   defined(CONFIG_ALPHA_LYNX)  || \
-  defined(CONFIG_ALPHA_SHARK) || \
-  defined(CONFIG_ALPHA_EIGER)
+  defined(CONFIG_ALPHA_SHARK)
 # define NR_IRQS   64
 
 #elif defined(CONFIG_ALPHA_TITAN)
 #define NR_IRQS80
 
 #elif defined(CONFIG_ALPHA_RAWHIDE) || \
-   defined(CONFIG_ALPHA_TAKARA)
+  defined(CONFIG_ALPHA_TAKARA) || \
+  defined(CONFIG_ALPHA_EIGER)
 # define NR_IRQS   128
 
 #elif defined(CONFIG_ALPHA_WILDFIRE)
diff --git a/arch/alpha/mm/fault.c b/arch/alpha/mm/fault.c
index 9d0ac091a52a..174d3cbf8a7a 100644
--- a/arch/alpha/mm/fault.c
+++ b/arch/alpha/mm/fault.c
@@ -78,7 +78,7 @@ __load_new_mm_context(struct mm_struct *next_mm)
 /* Macro for exception fixup code to access integer registers.  */
 #define dpf_reg(r) \
(((unsigned long *)regs)[(r) <= 8 ? (r) : (r) <= 15 ? (r)-16 :  \
-(r) <= 18 ? (r)+8 : (r)-10])
+(r) <= 18 ? (r)+10 : (r)-10])
 
 asmlinkage void
 do_page_fault(unsigned long address, unsigned long mmcsr,
diff --git a/arch/arm/boot/dts/da850-evm.dts b/arch/arm/boot/dts/da850-evm.dts
index 4f935ad9f27b..505ea30c9cb2 100644
--- a/arch/arm/boot/dts/da850-evm.dts
+++ b/arch/arm/boot/dts/da850-evm.dts
@@ -146,7 +146,7 @@
 
sound {
compatible = "simple-audio-card";
-   simple-audio-card,name = "DA850/OMAP-L138 EVM";
+   simple-audio-card,name = "DA850-OMAPL138 EVM";
simple-audio-card,widgets =
"Line", "Line In",
"Line", "Line Out";
diff --git a/arch/arm/boot/dts/kirkwood-dnskw.dtsi 
b/arch/arm/boot/dts/kirkwood-dnskw.dtsi
index 113dcf056dcf..1b2dacfa6132 100644
--- a/arch/arm/boot/dts/kirkwood-dnskw.dtsi
+++ b/arch/arm/boot/dts/kirkwood-dnskw.dtsi
@@ -35,8 +35,8 @@
compatible = "gpio-fan";
pinctrl-0 = <_fan_high_speed _fan_low_speed>;
pinctrl-names = "default";
-   gpios = < 14 GPIO_ACTIVE_LOW
- 13 GPIO_ACTIVE_LOW>;
+   gpios = < 14 GPIO_ACTIVE_HIGH
+ 13 GPIO_ACTIVE_HIGH>;
gpio-fan,speed-map = <00
  3000 1
  6000 2>;
diff --git a/arch/arm/boot/dts/omap4-sdp.dts b/arch/arm/boot/dts/omap4-sdp.dts
index 3e1da43068f6..4669854614c3 100644
--- a/arch/arm/boot/dts/omap4-sdp.dts
+++ b/arch/arm/boot/dts/omap4-sdp.dts
@@ -33,6 +33,7 @@
gpio = < 16 0>;  /* gpio line 48 */
enable-active-high;
regulator-boot-on;
+   startup-delay-us = <25000>;
};
 
vbat: fixedregulator-vbat {
diff --git a/arch/arm/kernel/smp.c b/arch/arm/kernel/smp.c
index a8e32aaf0383..bae65844ff03 100644
--- a/arch/arm/kernel/smp.c
+++ b/arch/arm/kernel/smp.c
@@ -658,6 +658,21 @@ void smp_send_stop(void)
pr_warn("SMP: failed to stop secondary CPUs\n");
 }
 
+/* In case panic() and panic() called at the same time on CPU1 and CPU2,
+ * and CPU 1 calls panic_smp_self_stop() before crash_smp_send_stop()
+ * CPU1 can't receive the ipi irqs from CPU2, CPU1 will be always online,
+ * kdump fails. So split out the panic_smp_self_stop() and add
+ * set_cpu_online(smp_processor_id(), false).
+ */
+void panic_smp_self_stop(void)
+{
+   pr_debug("CPU %u will stop doing anything useful since another CPU has 
paniced\n",
+smp_processor_id());
+   set_cpu_online(smp_processor_id(), false);
+   while (1)
+   cpu_relax();
+}
+
 /*
  * not supported here
  */
diff --git a/arch/arm/kvm/mmio.c b/arch/arm/kvm/mmio.c
index 4cb5a93182e9..c215bb4423ac 100644
--- a/arch/arm/kvm/mmio.c
+++ b/arch/arm/kvm/mmio.c
@@ -118,6 +118,12 @@ int kvm_handle_mmio_return(struct kvm_vcpu *vcpu, struct 
kvm_run *run)
*vcpu_reg(vcpu, vcpu->arch.mmio_decode.rt) = data;
}
 
+   /*
+* The MMIO instruction is emulated and should not be re-executed
+* in the guest.
+*/
+   kvm_skip_instr(vcpu, kvm_vcpu_trap_il_is32bit(vcpu));
+
return 0;
 }
 
@@ -154,11 +160,6 @@ static int decode_hsr(struct kvm_vcpu *vcpu, phys_addr_t 
fault_ipa,
vcpu->arch.mmio_decode.sign_extend = sign_extend;
vcpu->arch.mmio_decode.rt = rt;
 
-   /*
-* The MMIO instruction is emulated and should not be re-executed
-* in the guest.
- 

Linux 3.18.135

[Greg KH]

I'm announcing the release of the 3.18.135 kernel.

All users of the 3.18 kernel series must upgrade.

The updated 3.18.y git tree can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git 
linux-3.18.y
and can be browsed at the normal kernel.org git web browser:

http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary

thanks,

greg k-h



 Makefile|2 
 arch/alpha/include/asm/irq.h|6 
 arch/alpha/mm/fault.c   |2 
 arch/arm/boot/dts/da850-evm.dts |2 
 arch/arm/boot/dts/kirkwood-dnskw.dtsi   |4 
 arch/arm/boot/dts/omap4-sdp.dts |1 
 arch/arm/kernel/smp.c   |   15 ++
 arch/arm/kvm/mmio.c |   11 -
 arch/arm/mach-imx/clk-imx6sl.c  |6 
 arch/arm/mach-integrator/impd1.c|6 
 arch/arm/mach-iop32x/n2100.c|3 
 arch/arm/mach-omap2/omap_hwmod.c|6 
 arch/arm/mach-pxa/cm-x300.c |2 
 arch/arm/mach-pxa/littleton.c   |2 
 arch/arm/mach-pxa/zeus.c|2 
 arch/arm64/kernel/entry-ftrace.S|1 
 arch/mips/include/uapi/asm/inst.h   |2 
 arch/mips/pci/pci-octeon.c  |   10 -
 arch/powerpc/include/asm/uaccess.h  |2 
 arch/powerpc/platforms/pseries/dlpar.c  |2 
 arch/um/include/asm/pgtable.h   |9 +
 arch/x86/ia32/ia32_aout.c   |6 
 arch/x86/kernel/cpu/perf_event_intel_uncore_snbep.c |4 
 arch/x86/kvm/vmx.c  |1 
 arch/x86/kvm/x86.c  |7 +
 arch/x86/pci/broadcom_bus.c |4 
 drivers/ata/sata_rcar.c |4 
 drivers/block/drbd/drbd_nl.c|   15 +-
 drivers/block/drbd/drbd_receiver.c  |   13 +-
 drivers/block/swim3.c   |6 
 drivers/cdrom/gdrom.c   |1 
 drivers/cpuidle/cpuidle-big_little.c|7 -
 drivers/crypto/ux500/cryp/cryp_core.c   |4 
 drivers/crypto/ux500/hash/hash_core.c   |2 
 drivers/dma/imx-dma.c   |8 -
 drivers/gpu/drm/drm_modes.c |2 
 drivers/gpu/drm/vmwgfx/vmwgfx_drv.c |9 -
 drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c |2 
 drivers/hid/hid-debug.c |  121 +++-
 drivers/hwmon/lm80.c|   26 +++-
 drivers/input/misc/bma150.c |9 -
 drivers/input/mouse/elantech.c  |9 +
 drivers/isdn/hisax/hfc_pci.c|2 
 drivers/media/platform/davinci/vpbe.c   |7 -
 drivers/memstick/core/memstick.c|3 
 drivers/misc/vexpress-syscfg.c  |2 
 drivers/mtd/nand/gpmi-nand/gpmi-lib.c   |   15 +-
 drivers/net/ethernet/broadcom/bcmsysport.c  |   25 +---
 drivers/net/ethernet/broadcom/bcmsysport.h  |2 
 drivers/net/ethernet/cisco/enic/enic_main.c |2 
 drivers/net/ethernet/intel/igb/igb_main.c   |8 -
 drivers/net/ethernet/marvell/skge.c |6 
 drivers/net/ethernet/sun/niu.c  |   10 +
 drivers/net/usb/kaweth.c|   18 --
 drivers/net/usb/smsc95xx.c  |   12 -
 drivers/pinctrl/qcom/pinctrl-msm.c  |   23 ++-
 drivers/soc/tegra/common.c  |6 
 drivers/staging/iio/adc/ad7280a.c   |   17 ++
 drivers/staging/iio/adc/ad7780.c|6 
 drivers/staging/iio/resolver/ad2s90.c   |7 -
 drivers/thermal/thermal_hwmon.h |4 
 drivers/tty/serial/fsl_lpuart.c |4 
 drivers/usb/core/hub.c  |   10 +
 drivers/usb/dwc2/hcd.c  |1 
 drivers/usb/gadget/udc/net2272.c|2 
 drivers/usb/host/ehci-msm.c |6 
 drivers/usb/phy/phy-am335x.c|5 
 drivers/video/console/fbcon.c   |2 
 drivers/video/fbdev/clps711x-fb.c   |5 
 drivers/video/fbdev/core/fbmem.c|8 -
 fs/cifs/file.c  |8 +
 fs/cifs/readdir.c   |9 +
 fs/cifs/smb2file.c  |4 
 fs/debugfs/inode.c  |7 +
 

Re: Linux 4.4.175

[Greg KH]

diff --git a/Documentation/networking/ip-sysctl.txt 
b/Documentation/networking/ip-sysctl.txt
index 7c229f59016f..2fb35658d151 100644
--- a/Documentation/networking/ip-sysctl.txt
+++ b/Documentation/networking/ip-sysctl.txt
@@ -116,7 +116,7 @@ ipfrag_high_thresh - LONG INTEGER
Maximum memory used to reassemble IP fragments.
 
 ipfrag_low_thresh - LONG INTEGER
-   (Obsolete since linux-4.17)
+   (Obsolete since linux-4.4.174, backported from linux-4.17)
Maximum memory used to reassemble IP fragments before the kernel
begins to remove incomplete fragment queues to free up resources.
The kernel still accepts new fragments for defragmentation.
diff --git a/Makefile b/Makefile
index 1fa281069379..5f0bdef2af99 100644
--- a/Makefile
+++ b/Makefile
@@ -1,6 +1,6 @@
 VERSION = 4
 PATCHLEVEL = 4
-SUBLEVEL = 174
+SUBLEVEL = 175
 EXTRAVERSION =
 NAME = Blurry Fish Butt
 
diff --git a/arch/alpha/include/asm/irq.h b/arch/alpha/include/asm/irq.h
index 06377400dc09..469642801a68 100644
--- a/arch/alpha/include/asm/irq.h
+++ b/arch/alpha/include/asm/irq.h
@@ -55,15 +55,15 @@
 
 #elif defined(CONFIG_ALPHA_DP264) || \
   defined(CONFIG_ALPHA_LYNX)  || \
-  defined(CONFIG_ALPHA_SHARK) || \
-  defined(CONFIG_ALPHA_EIGER)
+  defined(CONFIG_ALPHA_SHARK)
 # define NR_IRQS   64
 
 #elif defined(CONFIG_ALPHA_TITAN)
 #define NR_IRQS80
 
 #elif defined(CONFIG_ALPHA_RAWHIDE) || \
-   defined(CONFIG_ALPHA_TAKARA)
+  defined(CONFIG_ALPHA_TAKARA) || \
+  defined(CONFIG_ALPHA_EIGER)
 # define NR_IRQS   128
 
 #elif defined(CONFIG_ALPHA_WILDFIRE)
diff --git a/arch/alpha/mm/fault.c b/arch/alpha/mm/fault.c
index 4a905bd667e2..0f68f0de9b5e 100644
--- a/arch/alpha/mm/fault.c
+++ b/arch/alpha/mm/fault.c
@@ -77,7 +77,7 @@ __load_new_mm_context(struct mm_struct *next_mm)
 /* Macro for exception fixup code to access integer registers.  */
 #define dpf_reg(r) \
(((unsigned long *)regs)[(r) <= 8 ? (r) : (r) <= 15 ? (r)-16 :  \
-(r) <= 18 ? (r)+8 : (r)-10])
+(r) <= 18 ? (r)+10 : (r)-10])
 
 asmlinkage void
 do_page_fault(unsigned long address, unsigned long mmcsr,
diff --git a/arch/arm/boot/dts/da850-evm.dts b/arch/arm/boot/dts/da850-evm.dts
index 6881757b03e8..67369f284b91 100644
--- a/arch/arm/boot/dts/da850-evm.dts
+++ b/arch/arm/boot/dts/da850-evm.dts
@@ -147,7 +147,7 @@
 
sound {
compatible = "simple-audio-card";
-   simple-audio-card,name = "DA850/OMAP-L138 EVM";
+   simple-audio-card,name = "DA850-OMAPL138 EVM";
simple-audio-card,widgets =
"Line", "Line In",
"Line", "Line Out";
diff --git a/arch/arm/boot/dts/kirkwood-dnskw.dtsi 
b/arch/arm/boot/dts/kirkwood-dnskw.dtsi
index 113dcf056dcf..1b2dacfa6132 100644
--- a/arch/arm/boot/dts/kirkwood-dnskw.dtsi
+++ b/arch/arm/boot/dts/kirkwood-dnskw.dtsi
@@ -35,8 +35,8 @@
compatible = "gpio-fan";
pinctrl-0 = <_fan_high_speed _fan_low_speed>;
pinctrl-names = "default";
-   gpios = < 14 GPIO_ACTIVE_LOW
- 13 GPIO_ACTIVE_LOW>;
+   gpios = < 14 GPIO_ACTIVE_HIGH
+ 13 GPIO_ACTIVE_HIGH>;
gpio-fan,speed-map = <00
  3000 1
  6000 2>;
diff --git a/arch/arm/boot/dts/mmp2.dtsi b/arch/arm/boot/dts/mmp2.dtsi
index 766bbb8495b6..47e5b63339d1 100644
--- a/arch/arm/boot/dts/mmp2.dtsi
+++ b/arch/arm/boot/dts/mmp2.dtsi
@@ -220,12 +220,15 @@
status = "disabled";
};
 
-   twsi2: i2c@d4025000 {
+   twsi2: i2c@d4031000 {
compatible = "mrvl,mmp-twsi";
-   reg = <0xd4025000 0x1000>;
-   interrupts = <58>;
+   reg = <0xd4031000 0x1000>;
+   interrupt-parent = <>;
+   interrupts = <0>;
clocks = <_clocks MMP2_CLK_TWSI1>;
resets = <_clocks MMP2_CLK_TWSI1>;
+   #address-cells = <1>;
+   #size-cells = <0>;
status = "disabled";
};
 
diff --git a/arch/arm/boot/dts/omap4-sdp.dts b/arch/arm/boot/dts/omap4-sdp.dts
index f0bdc41f8eff..235d1493f8aa 100644
--- a/arch/arm/boot/dts/omap4-sdp.dts
+++ b/arch/arm/boot/dts/omap4-sdp.dts
@@ -33,6 +33,7 @@
gpio = < 16 GPIO_ACTIVE_HIGH>;  /* gpio line 48 */
enable-active-high;
regulator-boot-on;
+   startup-delay-us = <25000>;
};
 
vbat: fixedregulator-vbat {