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

[Andrea Parri]

On Wed, Feb 20, 2019 at 10:26:04AM +0100, Peter Zijlstra wrote:
> 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?

The change/simplification was mainly intended as precautionary measure
(hence the "we can add it back, ..."): I do agree that it shouldn't be
possible to realize the above state; OTOH, you really don't need to be
too "creative" to imagine possible mis-uses/mis-interpretations of the
(dep ; rfi) term ("forget" ONCEs, trick herd7 with "false dependencies"
or simply wrongly assume that control dependencies are part this "dep",
what else? ...).  So, no, I'm not that fond to this term; why should I
be?  or you are simply suggesting to expand the changelog?

I should probably also remark that "such a simplification" wouldn't be
a first time for the LKMM and, in fact, for the ppo term itself:

  
https://mirrors.edge.kernel.org/pub/linux/kernel/people/paulmck/LWNLinuxMM/WeakModel.html#Preserved%20Program%20Order

  Andrea

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

[Harald Freudenberger]

On 18.02.19 19:08, 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;
> +}
> +
> +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",
> + .bus = _bus,
> + .probe = matrix_probe,
> +};
> +
>  static int vfio_ap_matrix_dev_create(void)
>  {
>   int ret;
> @@ -71,6 +88,10 @@ static int vfio_ap_matrix_dev_create(void)
>   if (IS_ERR(root_device))
>   return PTR_ERR(root_device);
>  
> + ret = bus_register(_bus);
> + if (ret)
> + goto bus_register_err;
> +
>   matrix_dev = kzalloc(sizeof(*matrix_dev), GFP_KERNEL);
>   if (!matrix_dev) {
>   ret = -ENOMEM;
> @@ -87,30 +108,41 @@ static int vfio_ap_matrix_dev_create(void)
>   mutex_init(_dev->lock);
>   INIT_LIST_HEAD(_dev->mdev_list);
>  
> - matrix_dev->device.type = _ap_dev_type;
>   dev_set_name(_dev->device, "%s", VFIO_AP_DEV_NAME);
>   matrix_dev->device.parent = root_device;
> + matrix_dev->device.bus = _bus;
>   matrix_dev->device.release = vfio_ap_matrix_dev_release;
> - matrix_dev->device.driver = _ap_drv.driver;
> + matrix_dev->vfio_ap_drv = _ap_drv;
>  
>   ret = device_register(_dev->device);
>   if (ret)
>   goto matrix_reg_err;
>  
> + ret = driver_register(_driver);
> + if (ret)
> + goto matrix_drv_err;
> +
>   return 0;
>  
> +matrix_drv_err:
> + device_unregister(_dev->device);
>  matrix_reg_err:
>   put_device(_dev->device);
>  matrix_alloc_err:
> + bus_unregister(_bus);
> +bus_register_err:
>   root_device_unregister(root_device);
> -
>   return ret;
>  }
>  
>  static void vfio_ap_matrix_dev_destroy(void)
>  {
> + struct device *root_device = matrix_dev->device.parent;
> +
> + driver_unregister(_driver);
>   device_unregister(_dev->device);
> - root_device_unregister(matrix_dev->device.parent);
> + bus_unregister(_bus);
> + root_device_unregister(root_device);
>  }
>  
>  static int __init vfio_ap_init(void)
> diff --git a/drivers/s390/crypto/vfio_ap_ops.c 
> b/drivers/s390/crypto/vfio_ap_ops.c
> index 272ef42..900b9cf 100644
> --- a/drivers/s390/crypto/vfio_ap_ops.c
> +++ b/drivers/s390/crypto/vfio_ap_ops.c
> @@ -198,8 +198,8 @@ static int vfio_ap_verify_queue_reserved(unsigned long 
> *apid,
>   qres.apqi = apqi;
>   qres.reserved = false;
>  
> - ret = driver_for_each_device(matrix_dev->device.driver, NULL, ,
> -  vfio_ap_has_queue);
> + ret = driver_for_each_device(_dev->vfio_ap_drv->driver, NULL,
> +  , vfio_ap_has_queue);
>   if (ret)
>   return ret;
>  
> diff --git a/drivers/s390/crypto/vfio_ap_private.h 
> b/drivers/s390/crypto/vfio_ap_private.h
> index 5675492..76b7f98 100644
> --- a/drivers/s390/crypto/vfio_ap_private.h
> +++ b/drivers/s390/crypto/vfio_ap_private.h
> @@ -40,6 +40,7 @@ struct ap_matrix_dev {
>   struct ap_config_info info;
>   struct list_head mdev_list;
>   struct mutex lock;
> + struct ap_driver  *vfio_ap_drv;
>  };
>  
>  extern struct ap_matrix_dev *matrix_dev;

You are introducing a new 

Re: [PATCH 4.19 01/24] bridge: do not add port to router list when receives query with source 0.0.0.0

[Nikolay Aleksandrov]

On 20/02/2019 15:09, Nikolay Aleksandrov wrote:
> On 20/02/2019 14:48, Sebastian Gottschall wrote:
>> *reminder*
>>
> [snip]
>>    }
>>    static void br_ip4_multicast_query(struct net_bridge *br,
 Is this also a problem in 4.20?  This patch went into 4.20-rc1, so it
 has been around for a while with no reported issues that I can find.
 Any pointers to the reports?
>>>
>>> i need to check this. i found this patch in 4.9, 4.14 and 4.4
>>> the rest was picked up from the mailinglist. according to the git sources 
>>> of 4.20 and 5.0 the same code is in there as well
>>>
>>> i just got the report from users today and was able to reproduce it with 
>>> iptv streams. just by disabling the code it was working again.
>>>
>>> Sebastian

 thanks,

 greg k-h

>>>
> 
> Could you please include more details about the setup that's broken ?
> Note that we were warned[1] of potential breakage from this change
> after it went in and regardless of the suggestion from the RFC we'll
> probably have to revert this patch.
> 
> Ying Xu as author of the patch, any thoughts ?
> 

My bad, it's Hangbin Liu's patch. It was reported by Ying Xu.

> Also adding Linus Lüssing to the CC as he was the one who warned against it.
> Note that the warning was sent as a reply to my breakage fix, but it was 
> intended
> for the original patch.
> 
> Thanks,
>  Nik
> 
> [1] https://www.mail-archive.com/netdev@vger.kernel.org/msg272944.html
> 

[PATCH v5 2/3] pwm: stm32-lp: Add power management support

[Fabrice Gasnier]

Add suspend/resume PM sleep ops. When going to low power, enforce the PWM
channel isn't active. Let the PWM consumers disable it during their own
suspend sequence. Only perform a check here, and handle the pinctrl states.
See [1].
[1] https://lkml.org/lkml/2019/2/5/770

Signed-off-by: Fabrice Gasnier 
---
Changes in v2:
- Don't disable PWM channel: let the PWM user disable it. Refuse to
  suspend in case it's been left enabled.
- Drop the ifdefs, use __maybe_unused instead.
---
 drivers/pwm/pwm-stm32-lp.c | 25 +
 1 file changed, 25 insertions(+)

diff --git a/drivers/pwm/pwm-stm32-lp.c b/drivers/pwm/pwm-stm32-lp.c
index 0059b24c..2211a64 100644
--- a/drivers/pwm/pwm-stm32-lp.c
+++ b/drivers/pwm/pwm-stm32-lp.c
@@ -13,6 +13,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -223,6 +224,29 @@ static int stm32_pwm_lp_remove(struct platform_device 
*pdev)
return pwmchip_remove(>chip);
 }
 
+static int __maybe_unused stm32_pwm_lp_suspend(struct device *dev)
+{
+   struct stm32_pwm_lp *priv = dev_get_drvdata(dev);
+   struct pwm_state state;
+
+   pwm_get_state(>chip.pwms[0], );
+   if (state.enabled) {
+   dev_err(dev, "The consumer didn't stop us (%s)\n",
+   priv->chip.pwms[0].label);
+   return -EBUSY;
+   }
+
+   return pinctrl_pm_select_sleep_state(dev);
+}
+
+static int __maybe_unused stm32_pwm_lp_resume(struct device *dev)
+{
+   return pinctrl_pm_select_default_state(dev);
+}
+
+static SIMPLE_DEV_PM_OPS(stm32_pwm_lp_pm_ops, stm32_pwm_lp_suspend,
+stm32_pwm_lp_resume);
+
 static const struct of_device_id stm32_pwm_lp_of_match[] = {
{ .compatible = "st,stm32-pwm-lp", },
{},
@@ -235,6 +259,7 @@ static struct platform_driver stm32_pwm_lp_driver = {
.driver = {
.name = "stm32-pwm-lp",
.of_match_table = of_match_ptr(stm32_pwm_lp_of_match),
+   .pm = _pwm_lp_pm_ops,
},
 };
 module_platform_driver(stm32_pwm_lp_driver);
-- 
2.7.4

[PATCH v5 0/3] Add PM support to STM32 LP Timer drivers

[Fabrice Gasnier]

This patch series adds power management support for STM32 LP Timer:
- PWM driver
- Document the pinctrl states for sleep mode

It also adds device link between the PWM consumer and the PWM provider.
This allows proper sequencing for suspend/resume (e.g. user will likely
do a pwm_disable() before the PWM provider suspend executes), see [1].

[1] https://lkml.org/lkml/2019/2/5/770

---
Changes in v5:
- improve a warning message, fix a style issue.

Changes in v4:
- improve error handling when adding the PWM consumer device link.

Changes in v3:
- Move the device_link_add() call to of_pwm_get() as discussed with Uwe.

Changes in v2:
- Don't disable PWM channel in PWM provider: rather refuse to suspend
  and report an error as suggested by Uwe and Thierry.
- Add patch 3/3 to propose device link addition.
- No updates for STM32 LP Timer IIO driver. Patches can be send separately.

Fabrice Gasnier (3):
  dt-bindings: pwm-stm32-lp: document pinctrl sleep state
  pwm: stm32-lp: Add power management support
  pwm: core: add consumer device link

 .../devicetree/bindings/pwm/pwm-stm32-lp.txt   |  9 ++--
 drivers/pwm/core.c | 50 --
 drivers/pwm/pwm-stm32-lp.c | 25 +++
 include/linux/pwm.h|  6 ++-
 4 files changed, 82 insertions(+), 8 deletions(-)

-- 
2.7.4

Re: [PATCH v2 2/2] extcon intel-cht-wc: Enable external charger

[Andy Shevchenko]

On Wed, Feb 20, 2019 at 12:24:41AM +0300, Yauhen Kharuzhy wrote:
> In some configuration external charger "#charge enable" signal is
> connected to PMIC. Enable it at device probing to allow charging.
> 
> Save CHGRCTRL0 and CHGDISCTR registers at driver probing and restore
> them at driver unbind to re-enable hardware charging control if it was
> enabled before.
> 
> Tested at Lenovo Yoga Book (YB1-X91L).

My comments below.
After addressing them,
Reviewed-by: Andy Shevchenko 

> +#define CHT_WC_CHGDISCTRL_OUTPUT BIT(0)

Simple _OUT as per documentation.

> +/* 0 - open drain, 1 - regular output */

Regular means push-pull.

> +#define CHT_WC_CHGDISCTRL_DRV_OD_DIS BIT(4)

_DRV as per documentation.

> +#define CHT_WC_CHGDISCTRL_MODE_HWBIT(6)

_FN as per documentation.

> +static void cht_wc_extcon_enable_charging(struct cht_wc_extcon_data *ext,
> +   bool enable)
> +{
> + unsigned int val;
> + int ret;
> +

> + val = enable ? 0 : CHT_WC_CHGDISCTRL_OUTPUT;

Can be assigned in definition block.

> + ret = regmap_update_bits(ext->regmap, CHT_WC_CHGDISCTRL,
> +  CHT_WC_CHGDISCTRL_OUTPUT, val);
> + if (ret)
> + dev_err(ext->dev, "Error updating CHGDISCTRL reg: %d\n", ret);
> +}

> + val = enable ? 0 : CHT_WC_CHGDISCTRL_MODE_HW;

> + ret = regmap_update_bits(ext->regmap, CHT_WC_CHGDISCTRL,
> + CHT_WC_CHGDISCTRL_MODE_HW, val);

Indentation.

> + if (ret)
> + dev_err(ext->dev,
> + "Error setting sw control for charger enable: %d\n",
> + ret);

> +static int cht_wc_save_initial_state(struct cht_wc_extcon_data *ext)
> +{
> + int ret;
> +
> + /*
> +  * Save the external charger control output state for restoring it at
> +  * driver unbinding

You may move "at" to the next line and add a period at the end.

> +  */
> + ret = regmap_read(ext->regmap, CHT_WC_CHGDISCTRL,
> +   >chgdisctrl_saved);
> + if (ret) {
> + dev_err(ext->dev, "Error reading CHGDISCTRL: %d\n",
> + ret);
> + return ret;
> + }
> +
> + ret = regmap_read(ext->regmap, CHT_WC_CHGRCTRL0,
> +   >chgrctrl0_saved);
> + if (ret) {
> + dev_err(ext->dev, "Error reading CHGRCTRL0: %d\n",
> + ret);
> + return ret;
> + }
> +
> + return 0;
> +}

-- 
With Best Regards,
Andy Shevchenko

[PATCH v5 3/3] pwm: core: add consumer device link

[Fabrice Gasnier]

Add a device link between the PWM consumer and the PWM provider. This
enforces the PWM user to get suspended before the PWM provider. It
allows proper synchronization of suspend/resume sequences: the PWM user
is responsible for properly stopping PWM, before the provider gets
suspended: see [1]. Add the device link in:
- of_pwm_get()
- pwm_get()
- devm_*pwm_get() variants
as it requires a reference to the device for the PWM consumer.

[1] https://lkml.org/lkml/2019/2/5/770

Suggested-by: Thierry Reding 
Signed-off-by: Fabrice Gasnier 
---
Changes in v5:
- fix a style issue
- use dev_warn() instead of pr_warn

Changes in v4:
- rework error handling following Thierry's comments
- turn/split pr_debug() into dev_err()/pr_warn().

Changes in v3:
- add struct device to of_get_pwm() arguments to handle device link from
  there as discussed with Uwe.
---
 drivers/pwm/core.c  | 50 +++---
 include/linux/pwm.h |  6 --
 2 files changed, 51 insertions(+), 5 deletions(-)

diff --git a/drivers/pwm/core.c b/drivers/pwm/core.c
index 1581f6a..03aa1b5 100644
--- a/drivers/pwm/core.c
+++ b/drivers/pwm/core.c
@@ -636,8 +636,35 @@ static struct pwm_chip *of_node_to_pwmchip(struct 
device_node *np)
return ERR_PTR(-EPROBE_DEFER);
 }
 
+static struct device_link *pwm_device_link_add(struct device *dev,
+  struct pwm_device *pwm)
+{
+   struct device_link *dl;
+
+   if (!dev) {
+   /*
+* No device for the PWM consumer has been provided. It may
+* impact the PM sequence ordering: the PWM supplier may get
+* suspended before the consumer.
+*/
+   dev_warn(pwm->chip->dev,
+"No consumer device specified to create a link to\n");
+   return NULL;
+   }
+
+   dl = device_link_add(dev, pwm->chip->dev, DL_FLAG_AUTOREMOVE_CONSUMER);
+   if (!dl) {
+   dev_err(dev, "failed to create device link to %s\n",
+   dev_name(pwm->chip->dev));
+   return ERR_PTR(-EINVAL);
+   }
+
+   return dl;
+}
+
 /**
  * of_pwm_get() - request a PWM via the PWM framework
+ * @dev: device for PWM consumer
  * @np: device node to get the PWM from
  * @con_id: consumer name
  *
@@ -655,10 +682,12 @@ static struct pwm_chip *of_node_to_pwmchip(struct 
device_node *np)
  * Returns: A pointer to the requested PWM device or an ERR_PTR()-encoded
  * error code on failure.
  */
-struct pwm_device *of_pwm_get(struct device_node *np, const char *con_id)
+struct pwm_device *of_pwm_get(struct device *dev, struct device_node *np,
+ const char *con_id)
 {
struct pwm_device *pwm = NULL;
struct of_phandle_args args;
+   struct device_link *dl;
struct pwm_chip *pc;
int index = 0;
int err;
@@ -689,6 +718,14 @@ struct pwm_device *of_pwm_get(struct device_node *np, 
const char *con_id)
if (IS_ERR(pwm))
goto put;
 
+   dl = pwm_device_link_add(dev, pwm);
+   if (IS_ERR(dl)) {
+   /* of_xlate ended up calling pwm_request_from_chip() */
+   pwm_free(pwm);
+   pwm = ERR_CAST(dl);
+   goto put;
+   }
+
/*
 * If a consumer name was not given, try to look it up from the
 * "pwm-names" property if it exists. Otherwise use the name of
@@ -764,6 +801,7 @@ struct pwm_device *pwm_get(struct device *dev, const char 
*con_id)
const char *dev_id = dev ? dev_name(dev) : NULL;
struct pwm_device *pwm;
struct pwm_chip *chip;
+   struct device_link *dl;
unsigned int best = 0;
struct pwm_lookup *p, *chosen = NULL;
unsigned int match;
@@ -771,7 +809,7 @@ struct pwm_device *pwm_get(struct device *dev, const char 
*con_id)
 
/* look up via DT first */
if (IS_ENABLED(CONFIG_OF) && dev && dev->of_node)
-   return of_pwm_get(dev->of_node, con_id);
+   return of_pwm_get(dev, dev->of_node, con_id);
 
/*
 * We look up the provider in the static table typically provided by
@@ -848,6 +886,12 @@ struct pwm_device *pwm_get(struct device *dev, const char 
*con_id)
if (IS_ERR(pwm))
return pwm;
 
+   dl = pwm_device_link_add(dev, pwm);
+   if (IS_ERR(dl)) {
+   pwm_free(pwm);
+   return ERR_CAST(dl);
+   }
+
pwm->args.period = chosen->period;
pwm->args.polarity = chosen->polarity;
 
@@ -939,7 +983,7 @@ struct pwm_device *devm_of_pwm_get(struct device *dev, 
struct device_node *np,
if (!ptr)
return ERR_PTR(-ENOMEM);
 
-   pwm = of_pwm_get(np, con_id);
+   pwm = of_pwm_get(dev, np, con_id);
if (!IS_ERR(pwm)) {
*ptr = pwm;
devres_add(dev, ptr);
diff --git a/include/linux/pwm.h b/include/linux/pwm.h
index 

Re: [PATCH 4.19 01/24] bridge: do not add port to router list when receives query with source 0.0.0.0

[Nikolay Aleksandrov]

On 20/02/2019 14:48, Sebastian Gottschall wrote:
> *reminder*
> 
[snip]
>    }
>    static void br_ip4_multicast_query(struct net_bridge *br,
>>> Is this also a problem in 4.20?  This patch went into 4.20-rc1, so it
>>> has been around for a while with no reported issues that I can find.
>>> Any pointers to the reports?
>>
>> i need to check this. i found this patch in 4.9, 4.14 and 4.4
>> the rest was picked up from the mailinglist. according to the git sources of 
>> 4.20 and 5.0 the same code is in there as well
>>
>> i just got the report from users today and was able to reproduce it with 
>> iptv streams. just by disabling the code it was working again.
>>
>> Sebastian
>>>
>>> thanks,
>>>
>>> greg k-h
>>>
>>

Could you please include more details about the setup that's broken ?
Note that we were warned[1] of potential breakage from this change
after it went in and regardless of the suggestion from the RFC we'll
probably have to revert this patch.

Ying Xu as author of the patch, any thoughts ?

Also adding Linus Lüssing to the CC as he was the one who warned against it.
Note that the warning was sent as a reply to my breakage fix, but it was 
intended
for the original patch.

Thanks,
 Nik

[1] https://www.mail-archive.com/netdev@vger.kernel.org/msg272944.html

[PATCH v5 1/3] dt-bindings: pwm-stm32-lp: document pinctrl sleep state

[Fabrice Gasnier]

Add documentation for pinctrl sleep state on STM32 LPTimer PWM.

Signed-off-by: Fabrice Gasnier 
Reviewed-by: Rob Herring 
---
 Documentation/devicetree/bindings/pwm/pwm-stm32-lp.txt | 9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/Documentation/devicetree/bindings/pwm/pwm-stm32-lp.txt 
b/Documentation/devicetree/bindings/pwm/pwm-stm32-lp.txt
index bd23302..6521bc4 100644
--- a/Documentation/devicetree/bindings/pwm/pwm-stm32-lp.txt
+++ b/Documentation/devicetree/bindings/pwm/pwm-stm32-lp.txt
@@ -11,8 +11,10 @@ Required parameters:
bindings defined in pwm.txt.
 
 Optional properties:
-- pinctrl-names:   Set to "default".
-- pinctrl-0:   Phandle pointing to pin configuration node for PWM.
+- pinctrl-names:   Set to "default". An additional "sleep" state can be
+   defined to set pins in sleep state when in low power.
+- pinctrl-n:   Phandle(s) pointing to pin configuration node for PWM,
+   respectively for "default" and "sleep" states.
 
 Example:
timer@40002400 {
@@ -21,7 +23,8 @@ Example:
pwm {
compatible = "st,stm32-pwm-lp";
#pwm-cells = <3>;
-   pinctrl-names = "default";
+   pinctrl-names = "default", "sleep";
pinctrl-0 = <_pins>;
+   pinctrl-1 = <_sleep_pins>;
};
};
-- 
2.7.4

Re: [PATCH v4 5/6] usb:cdns3 Add Cadence USB3 DRD Driver

[Roger Quadros]

Pawel,

On 14/02/2019 21:45, Pawel Laszczak wrote:
> This patch introduce new Cadence USBSS DRD driver to linux kernel.
> 
> The Cadence USBSS DRD Driver is a highly configurable IP Core whichi
> can be instantiated as Dual-Role Device (DRD), Peripheral Only and
> Host Only (XHCI)configurations.
> 
> The current driver has been validated with FPGA burned. We have support
> for PCIe bus, which is used on FPGA prototyping.
> 
> The host side of USBSS-DRD controller is compliance with XHCI
> specification, so it works with standard XHCI linux driver.
> 
> Signed-off-by: Pawel Laszczak 
> ---
>  drivers/usb/Kconfig|2 +
>  drivers/usb/Makefile   |2 +
>  drivers/usb/cdns3/Kconfig  |   44 +
>  drivers/usb/cdns3/Makefile |   14 +
>  drivers/usb/cdns3/cdns3-pci-wrap.c |  155 +++
>  drivers/usb/cdns3/core.c   |  403 ++
>  drivers/usb/cdns3/core.h   |  116 ++
>  drivers/usb/cdns3/debug.h  |  168 +++
>  drivers/usb/cdns3/debugfs.c|  164 +++
>  drivers/usb/cdns3/drd.c|  365 +
>  drivers/usb/cdns3/drd.h|  162 +++
>  drivers/usb/cdns3/ep0.c|  907 +
>  drivers/usb/cdns3/gadget-export.h  |   28 +
>  drivers/usb/cdns3/gadget.c | 2003 
>  drivers/usb/cdns3/gadget.h | 1207 +
>  drivers/usb/cdns3/host-export.h|   28 +
>  drivers/usb/cdns3/host.c   |   72 +
>  drivers/usb/cdns3/trace.c  |   23 +
>  drivers/usb/cdns3/trace.h  |  404 ++
>  19 files changed, 6267 insertions(+)
>  create mode 100644 drivers/usb/cdns3/Kconfig
>  create mode 100644 drivers/usb/cdns3/Makefile
>  create mode 100644 drivers/usb/cdns3/cdns3-pci-wrap.c
>  create mode 100644 drivers/usb/cdns3/core.c
>  create mode 100644 drivers/usb/cdns3/core.h
>  create mode 100644 drivers/usb/cdns3/debug.h
>  create mode 100644 drivers/usb/cdns3/debugfs.c
>  create mode 100644 drivers/usb/cdns3/drd.c
>  create mode 100644 drivers/usb/cdns3/drd.h
>  create mode 100644 drivers/usb/cdns3/ep0.c
>  create mode 100644 drivers/usb/cdns3/gadget-export.h
>  create mode 100644 drivers/usb/cdns3/gadget.c
>  create mode 100644 drivers/usb/cdns3/gadget.h
>  create mode 100644 drivers/usb/cdns3/host-export.h
>  create mode 100644 drivers/usb/cdns3/host.c
>  create mode 100644 drivers/usb/cdns3/trace.c
>  create mode 100644 drivers/usb/cdns3/trace.h
> 
> diff --git a/drivers/usb/Kconfig b/drivers/usb/Kconfig
> index 987fc5ba6321..5f9334019d04 100644
> --- a/drivers/usb/Kconfig
> +++ b/drivers/usb/Kconfig
> @@ -112,6 +112,8 @@ source "drivers/usb/usbip/Kconfig"
>  
>  endif
>  
> +source "drivers/usb/cdns3/Kconfig"
> +
>  source "drivers/usb/mtu3/Kconfig"
>  
>  source "drivers/usb/musb/Kconfig"
> diff --git a/drivers/usb/Makefile b/drivers/usb/Makefile
> index 7d1b8c82b208..ab125b966cac 100644
> --- a/drivers/usb/Makefile
> +++ b/drivers/usb/Makefile
> @@ -12,6 +12,8 @@ obj-$(CONFIG_USB_DWC3)  += dwc3/
>  obj-$(CONFIG_USB_DWC2)   += dwc2/
>  obj-$(CONFIG_USB_ISP1760)+= isp1760/
>  
> +obj-$(CONFIG_USB_CDNS3)  += cdns3/
> +
>  obj-$(CONFIG_USB_MON)+= mon/
>  obj-$(CONFIG_USB_MTU3)   += mtu3/
>  
> diff --git a/drivers/usb/cdns3/Kconfig b/drivers/usb/cdns3/Kconfig
> new file mode 100644
> index ..27cb3d8dbe3d
> --- /dev/null
> +++ b/drivers/usb/cdns3/Kconfig
> @@ -0,0 +1,44 @@
> +config USB_CDNS3
> + tristate "Cadence USB3 Dual-Role Controller"
> + depends on USB_SUPPORT && (USB || USB_GADGET) && HAS_DMA
> + help
> +   Say Y here if your system has a cadence USB3 dual-role controller.
> +   It supports: dual-role switch, Host-only, and Peripheral-only.
> +
> +   If you choose to build this driver is a dynamically linked
> +   as module, the module will be called cdns3.ko.
> +
> +if USB_CDNS3
> +
> +config USB_CDNS3_GADGET
> +bool "Cadence USB3 device controller"
> +depends on USB_GADGET
> +help
> +  Say Y here to enable device controller functionality of the
> +  cadence USBSS-DEV driver.

"Cadence" ?

> +
> +  This controller supports FF, HS and SS mode. It doesn't support
> +  LS and SSP mode.
> +
> +config USB_CDNS3_HOST
> +bool "Cadence USB3 host controller"
> +depends on USB_XHCI_HCD
> +help
> +  Say Y here to enable host controller functionality of the
> +  cadence driver.
> +
> +  Host controller is compliant with XHCI so it will use
> +  standard XHCI driver.
> +
> +config USB_CDNS3_PCI_WRAP
> + tristate "Cadence USB3 support on PCIe-based platforms"
> + depends on USB_PCI && ACPI
> + default USB_CDNS3
> + help
> +   If you're using the USBSS Core IP with a PCIe, please say
> +   'Y' or 'M' here.
> +
> +   If you choose to build this driver as module it will
> +   be dynamically linked and module will 

[PATCH] iommu: Fix IOMMU debugfs fallout

[Geert Uytterhoeven]

A change made in the final version of IOMMU debugfs support replaced the
public function iommu_debugfs_new_driver_dir() by the public dentry
iommu_debugfs_dir in , but forgot to update both the
implementation in iommu-debugfs.c, and the patch description.

Fix this by exporting iommu_debugfs_dir, and removing the reference to
and implementation of iommu_debugfs_new_driver_dir().

Fixes: bad614b24293ae46 ("iommu: Enable debugfs exposure of IOMMU driver 
internals")
Signed-off-by: Geert Uytterhoeven 
---
 drivers/iommu/iommu-debugfs.c | 23 ---
 1 file changed, 4 insertions(+), 19 deletions(-)

diff --git a/drivers/iommu/iommu-debugfs.c b/drivers/iommu/iommu-debugfs.c
index 3b1bf88fd1b0494a..f0354894209648fd 100644
--- a/drivers/iommu/iommu-debugfs.c
+++ b/drivers/iommu/iommu-debugfs.c
@@ -12,6 +12,7 @@
 #include 
 
 struct dentry *iommu_debugfs_dir;
+EXPORT_SYMBOL_GPL(iommu_debugfs_dir);
 
 /**
  * iommu_debugfs_setup - create the top-level iommu directory in debugfs
@@ -23,9 +24,9 @@ struct dentry *iommu_debugfs_dir;
  * Emit a strong warning at boot time to indicate that this feature is
  * enabled.
  *
- * This function is called from iommu_init; drivers may then call
- * iommu_debugfs_new_driver_dir() to instantiate a vendor-specific
- * directory to be used to expose internal data.
+ * This function is called from iommu_init; drivers may then use
+ * iommu_debugfs_dir to instantiate a vendor-specific directory to be used
+ * to expose internal data.
  */
 void iommu_debugfs_setup(void)
 {
@@ -48,19 +49,3 @@ void iommu_debugfs_setup(void)

pr_warn("*\n");
}
 }
-
-/**
- * iommu_debugfs_new_driver_dir - create a vendor directory under debugfs/iommu
- * @vendor: name of the vendor-specific subdirectory to create
- *
- * This function is called by an IOMMU driver to create the top-level debugfs
- * directory for that driver.
- *
- * Return: upon success, a pointer to the dentry for the new directory.
- * NULL in case of failure.
- */
-struct dentry *iommu_debugfs_new_driver_dir(const char *vendor)
-{
-   return debugfs_create_dir(vendor, iommu_debugfs_dir);
-}
-EXPORT_SYMBOL_GPL(iommu_debugfs_new_driver_dir);
-- 
2.17.1

[PATCH 0/3] iommu: Kerneldoc improvements

[Geert Uytterhoeven]

Hi Jörg,

This series contains a fix for an incorrect kerneldoc parameter, and
adds the missing kerneldoc for two recently added IOMMU methods.

Thanks!

Geert Uytterhoeven (3):
  iommu: Fix kerneldoc for iommu_ops.flush_iotlb_all()
  iommu: Document iommu_ops.iotlb_sync_map()
  iommu: Document iommu_ops.is_attach_deferred()

 include/linux/iommu.h | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

-- 
2.17.1

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 1/8] livepatch: Create and include UAPI headers

[Miroslav Benes]

> diff --git a/include/uapi/linux/livepatch.h b/include/uapi/linux/livepatch.h
> new file mode 100644
> index ..bc35f85fd859
> --- /dev/null
> +++ b/include/uapi/linux/livepatch.h
> @@ -0,0 +1,28 @@
> +/*
> + * livepatch.h - Kernel Live Patching Core
> + *
> + * Copyright (C) 2016 Josh Poimboeuf 
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License
> + * as published by the Free Software Foundation; either version 2
> + * of the License, or (at your option) any later version.
> + *
> + * 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.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program; if not, see .
> + */

People will ask to replace GPL boilerplate with SPDX tag.

> +#ifndef _UAPI_LIVEPATCH_H
> +#define _UAPI_LIVEPATCH_H
> +
> +#include 

#include is not necessary here, I think.

> +#define KLP_RELA_PREFIX  ".klp.rela."
> +#define KLP_SYM_PREFIX   ".klp.sym."
> +
> +#endif /* _UAPI_LIVEPATCH_H */

Miroslav

[PATCH 3/3] iommu: Document iommu_ops.is_attach_deferred()

[Geert Uytterhoeven]

Add missing kerneldoc for iommu_ops.is_attach_deferred().

Fixes: e01d1913b0d08171 ("iommu: Add is_attach_deferred call-back to iommu-ops")
Signed-off-by: Geert Uytterhoeven 
---
 include/linux/iommu.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/include/linux/iommu.h b/include/linux/iommu.h
index 3ed5d372b090af54..ffbbc7e39ceeba3e 100644
--- a/include/linux/iommu.h
+++ b/include/linux/iommu.h
@@ -184,6 +184,8 @@ struct iommu_resv_region {
  * @domain_window_enable: Configure and enable a particular window for a domain
  * @domain_window_disable: Disable a particular window for a domain
  * @of_xlate: add OF master IDs to iommu grouping
+ * @is_attach_deferred: Check if domain attach should be deferred from iommu
+ *  driver init to device driver init (default no)
  * @pgsize_bitmap: bitmap of all possible supported page sizes
  */
 struct iommu_ops {
-- 
2.17.1

Firmware files for QCA BT chip wcn3990

[Balakrishna Godavarthi]

Hi,

The following changes since commit 
710963fe53ee3f227556d36839df3858daf6e232:


  Merge https://github.com/ajaykuee/linux-firmware (2019-02-13 07:42:20 
-0500)


are available in the Git repository at:

  https://github.com/bgodavar/qca_bt_wcn3990_fw.git

for you to fetch changes up to f859d9fda9379205c9bcf2eab11fae68891085ee:

  qca: Add firmware files for BT chip wcn3990. (2019-02-20 18:23:46 
+0530)



Balakrishna Godavarthi (1):
  qca: Add firmware files for BT chip wcn3990.

 WHENCE   |   2 +
 qca/NOTICE.txt   | 334 


 qca/crbtfw21.tlv | Bin 0 -> 177060 bytes
 qca/crnv21.bin   | Bin 0 -> 4587 bytes
 4 files changed, 129 insertions(+), 207 deletions(-)
 create mode 100644 qca/crbtfw21.tlv
 create mode 100644 qca/crnv21.bin


--
Regards
Balakrishna.

[PATCH 1/3] iommu: Fix kerneldoc for iommu_ops.flush_iotlb_all()

[Geert Uytterhoeven]

While the API wrapper is called iommu_flush_tlb_all(), the actual
iommu_ops method is called .flush_iotlb_all(), not .flush_tlb_all().

Fixes: add02cfdc9bc2987 ("iommu: Introduce Interface for IOMMU TLB Flushing")
Signed-off-by: Geert Uytterhoeven 
---
 include/linux/iommu.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/linux/iommu.h b/include/linux/iommu.h
index 477ef47c357c0553..848fb07026b67169 100644
--- a/include/linux/iommu.h
+++ b/include/linux/iommu.h
@@ -167,7 +167,7 @@ struct iommu_resv_region {
  * @detach_dev: detach device from an iommu domain
  * @map: map a physically contiguous memory region to an iommu domain
  * @unmap: unmap a physically contiguous memory region from an iommu domain
- * @flush_tlb_all: Synchronously flush all hardware TLBs for this domain
+ * @flush_iotlb_all: Synchronously flush all hardware TLBs for this domain
  * @iotlb_range_add: Add a given iova range to the flush queue for this domain
  * @iotlb_sync: Flush all queued ranges from the hardware TLBs and empty flush
  *queue
-- 
2.17.1

[PATCH 2/3] iommu: Document iommu_ops.iotlb_sync_map()

[Geert Uytterhoeven]

Add missing kerneldoc for iommu_ops.iotlb_sync_map().

Fixes: 1d7ae53b152dbc5b ("iommu: Introduce iotlb_sync_map callback")
Signed-off-by: Geert Uytterhoeven 
---
 include/linux/iommu.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/include/linux/iommu.h b/include/linux/iommu.h
index 848fb07026b67169..3ed5d372b090af54 100644
--- a/include/linux/iommu.h
+++ b/include/linux/iommu.h
@@ -169,6 +169,7 @@ struct iommu_resv_region {
  * @unmap: unmap a physically contiguous memory region from an iommu domain
  * @flush_iotlb_all: Synchronously flush all hardware TLBs for this domain
  * @iotlb_range_add: Add a given iova range to the flush queue for this domain
+ * @iotlb_sync_map: Sync mappings created recently using @map to the hardware
  * @iotlb_sync: Flush all queued ranges from the hardware TLBs and empty flush
  *queue
  * @iova_to_phys: translate iova to physical address
-- 
2.17.1

Re: [RFC PATCH net-next v3 13/21] ethtool: provide timestamping information in GET_INFO request

[Michal Kubecek]

On Tue, Feb 19, 2019 at 07:00:48PM -0800, Jakub Kicinski wrote:
> On Mon, 18 Feb 2019 19:22:29 +0100 (CET), Michal Kubecek wrote:
> > Add timestamping information as provided by ETHTOOL_GET_TS_INFO ioctl
> > command in GET_INFO reply if ETH_INFO_IM_TSINFO flag is set in the request.
> > 
> > Add constants for counts of HWTSTAMP_TX_* and HWTSTAM_FILTER_* constants
> > and provide symbolic names for timestamping related values so that they can
> > be retrieved in GET_STRSET and GET_INFO requests.
> 
> What's the reason for providing the symbolic names?

One of the the goals I had was to reduce the need to keep the lists of
possible values in sync between kernel and userspace ethtool and other
users of the interface so that when a new value is added, we don't have
to update all userspace tools to be able to use or present it.

This already works in ethtool for some newer commands (e.g. features)
and obviously for those where the list of available options depends on
the device (e.g. private flags or statistics). I would like to extend
the principle also to older commands and new ones which do not work like
this (e.g. device reset).

Michal

[PATCHv2] usb: typec: tps6598x: handle block writes separately with plain-I2C adapters

[Nikolaus Voss]

Commit 1a2f474d328f handles block _reads_ separately with plain-I2C
adapters, but the problem described with regmap-i2c not handling
SMBus block transfers (i.e. read and writes) correctly also exists
with writes.

As workaround, this patch adds a block write function the same way
1a2f474d328f adds a block read function.

Fixes: 1a2f474d328f ("usb: typec: tps6598x: handle block reads separately with 
plain-I2C adapters")
Fixes: 0a4c005bd171 ("usb: typec: driver for TI TPS6598x USB Power Delivery 
controllers")
Signed-off-by: Nikolaus Voss 
---
v2: fix tps6598x_exec_cmd also
---
 drivers/usb/typec/tps6598x.c | 26 --
 1 file changed, 20 insertions(+), 6 deletions(-)

diff --git a/drivers/usb/typec/tps6598x.c b/drivers/usb/typec/tps6598x.c
index c84c8c189e90..c54b73fb2a2f 100644
--- a/drivers/usb/typec/tps6598x.c
+++ b/drivers/usb/typec/tps6598x.c
@@ -110,6 +110,20 @@ tps6598x_block_read(struct tps6598x *tps, u8 reg, void 
*val, size_t len)
return 0;
 }
 
+static int tps6598x_block_write(struct tps6598x *tps, u8 reg,
+   void *val, size_t len)
+{
+   u8 data[len + 1];
+
+   if (!tps->i2c_protocol)
+   return regmap_raw_write(tps->regmap, reg, val, len);
+
+   data[0] = len;
+   memcpy([1], val, len);
+
+   return regmap_raw_write(tps->regmap, reg, data, sizeof(data));
+}
+
 static inline int tps6598x_read16(struct tps6598x *tps, u8 reg, u16 *val)
 {
return tps6598x_block_read(tps, reg, val, sizeof(u16));
@@ -127,23 +141,23 @@ static inline int tps6598x_read64(struct tps6598x *tps, 
u8 reg, u64 *val)
 
 static inline int tps6598x_write16(struct tps6598x *tps, u8 reg, u16 val)
 {
-   return regmap_raw_write(tps->regmap, reg, , sizeof(u16));
+   return tps6598x_block_write(tps, reg, , sizeof(u16));
 }
 
 static inline int tps6598x_write32(struct tps6598x *tps, u8 reg, u32 val)
 {
-   return regmap_raw_write(tps->regmap, reg, , sizeof(u32));
+   return tps6598x_block_write(tps, reg, , sizeof(u32));
 }
 
 static inline int tps6598x_write64(struct tps6598x *tps, u8 reg, u64 val)
 {
-   return regmap_raw_write(tps->regmap, reg, , sizeof(u64));
+   return tps6598x_block_write(tps, reg, , sizeof(u64));
 }
 
 static inline int
 tps6598x_write_4cc(struct tps6598x *tps, u8 reg, const char *val)
 {
-   return regmap_raw_write(tps->regmap, reg, , sizeof(u32));
+   return tps6598x_block_write(tps, reg, , sizeof(u32));
 }
 
 static int tps6598x_read_partner_identity(struct tps6598x *tps)
@@ -229,8 +243,8 @@ static int tps6598x_exec_cmd(struct tps6598x *tps, const 
char *cmd,
return -EBUSY;
 
if (in_len) {
-   ret = regmap_raw_write(tps->regmap, TPS_REG_DATA1,
-  in_data, in_len);
+   ret = tps6598x_block_write(tps, TPS_REG_DATA1,
+  in_data, in_len);
if (ret)
return ret;
}
-- 
2.17.1

Re: [PATCH] usb: typec: tps6598x: handle block writes separately with plain-I2C adapters

[Nikolaus Voss]

Hi,

On Wed, 20 Feb 2019, Heikki Krogerus wrote:

Hi,

On Mon, Sep 10, 2018 at 07:05:01AM +0200, Nikolaus Voss wrote:

Commit 1a2f474d328f handles block _reads_ separately with plain-I2C
adapters, but the problem described with regmap-i2c not handling
SMBus block transfers (i.e. read and writes) correctly also exists
with writes.

As workaround, this patch adds a block write function the same way
1a2f474d328f adds a block read function.

Fixes: 1a2f474d328f ("usb: typec: tps6598x: handle block reads separately with 
plain-I2C adapters")
Fixes: 0a4c005bd171 ("usb: typec: driver for TI TPS6598x USB Power Delivery 
controllers")
Signed-off-by: Nikolaus Voss 
---
 drivers/usb/typec/tps6598x.c | 22 ++
 1 file changed, 18 insertions(+), 4 deletions(-)

diff --git a/drivers/usb/typec/tps6598x.c b/drivers/usb/typec/tps6598x.c
index c84c8c189e90..57a3e6c5c175 100644
--- a/drivers/usb/typec/tps6598x.c
+++ b/drivers/usb/typec/tps6598x.c
@@ -110,6 +110,20 @@ tps6598x_block_read(struct tps6598x *tps, u8 reg, void 
*val, size_t len)
return 0;
 }

+static int tps6598x_block_write(struct tps6598x *tps, u8 reg,
+   void *val, size_t len)
+{
+   u8 data[len + 1];
+
+   if (!tps->i2c_protocol)
+   return regmap_raw_write(tps->regmap, reg, val, len);
+
+   data[0] = len;
+   memcpy([1], val, len);
+
+   return regmap_raw_write(tps->regmap, reg, data, sizeof(data));
+}
+
 static inline int tps6598x_read16(struct tps6598x *tps, u8 reg, u16 *val)
 {
return tps6598x_block_read(tps, reg, val, sizeof(u16));
@@ -127,23 +141,23 @@ static inline int tps6598x_read64(struct tps6598x *tps, 
u8 reg, u64 *val)

 static inline int tps6598x_write16(struct tps6598x *tps, u8 reg, u16 val)
 {
-   return regmap_raw_write(tps->regmap, reg, , sizeof(u16));
+   return tps6598x_block_write(tps, reg, , sizeof(u16));
 }

 static inline int tps6598x_write32(struct tps6598x *tps, u8 reg, u32 val)
 {
-   return regmap_raw_write(tps->regmap, reg, , sizeof(u32));
+   return tps6598x_block_write(tps, reg, , sizeof(u32));
 }

 static inline int tps6598x_write64(struct tps6598x *tps, u8 reg, u64 val)
 {
-   return regmap_raw_write(tps->regmap, reg, , sizeof(u64));
+   return tps6598x_block_write(tps, reg, , sizeof(u64));
 }

 static inline int
 tps6598x_write_4cc(struct tps6598x *tps, u8 reg, const char *val)
 {
-   return regmap_raw_write(tps->regmap, reg, , sizeof(u32));
+   return tps6598x_block_write(tps, reg, , sizeof(u32));
 }

 static int tps6598x_read_partner_identity(struct tps6598x *tps)


You need to fix tps6598x_exec_cmd() as well.


Right, thanks. I will fix that.



Did you really send this last September? If you did, then the mail has
been stuck somewhere for a long time.


It's been stuck with me, I forgot to send it ;-).

Nikolaus

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

[Michal Hocko]

Rong Chen,
coudl you double check this indeed fixes the issue for you please?

On Mon 18-02-19 19:15:44, Michal Hocko wrote:
> From: Michal Hocko 
> 
> Rong Chen has reported the following boot crash
> [   40.305212] PGD 0 P4D 0
> [   40.308255] Oops:  [#1] PREEMPT SMP PTI
> [   40.313055] CPU: 1 PID: 239 Comm: udevd Not tainted 
> 5.0.0-rc4-00149-gefad4e4 #1
> [   40.321348] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
> 1.10.2-1 04/01/2014
> [   40.330813] RIP: 0010:page_mapping+0x12/0x80
> [   40.335709] Code: 5d c3 48 89 df e8 0e ad 02 00 85 c0 75 da 89 e8 5b 5d c3 
> 0f 1f 44 00 00 53 48 89 fb 48 8b 43 08 48 8d 50 ff a8 01 48 0f 45 da <48> 8b 
> 53 08 48 8d 42 ff 83 e2 01 48 0f 44 c3 48 83 38 ff 74 2f 48
> [   40.356704] RSP: 0018:88801fa87cd8 EFLAGS: 00010202
> [   40.362714] RAX:  RBX: fffe RCX: 
> 000a
> [   40.370798] RDX: fffe RSI: 820b9a20 RDI: 
> 88801e5c
> [   40.378830] RBP: 6db6db6db6db6db7 R08: 88801e8bb000 R09: 
> 01b64d13
> [   40.386902] R10: 88801fa87cf8 R11: 0001 R12: 
> 88801e64
> [   40.395033] R13: 820b9a20 R14: 88801f145258 R15: 
> 0001
> [   40.403138] FS:  7fb2079817c0() GS:88801dd0() 
> knlGS:
> [   40.412243] CS:  0010 DS:  ES:  CR0: 80050033
> [   40.418846] CR2: 0006 CR3: 1fa82000 CR4: 
> 06a0
> [   40.426951] Call Trace:
> [   40.429843]  __dump_page+0x14/0x2c0
> [   40.433947]  is_mem_section_removable+0x24c/0x2c0
> [   40.439327]  removable_show+0x87/0xa0
> [   40.443613]  dev_attr_show+0x25/0x60
> [   40.447763]  sysfs_kf_seq_show+0xba/0x110
> [   40.452363]  seq_read+0x196/0x3f0
> [   40.456282]  __vfs_read+0x34/0x180
> [   40.460233]  ? lock_acquire+0xb6/0x1e0
> [   40.464610]  vfs_read+0xa0/0x150
> [   40.468372]  ksys_read+0x44/0xb0
> [   40.472129]  ? do_syscall_64+0x1f/0x4a0
> [   40.476593]  do_syscall_64+0x5e/0x4a0
> [   40.480809]  ? trace_hardirqs_off_thunk+0x1a/0x1c
> [   40.486195]  entry_SYSCALL_64_after_hwframe+0x49/0xbe
> 
> and bisected it down to efad4e475c31 ("mm, memory_hotplug:
> is_mem_section_removable do not pass the end of a zone"). The reason for
> the crash is that the mapping is garbage for poisoned (uninitialized) page.
> This shouldn't happen as all pages in the zone's boundary should be
> initialized. Later debugging revealed that the actual problem is an
> off-by-one when evaluating the end_page. start_pfn + nr_pages resp.
> zone_end_pfn refers to a pfn after the range and as such it might belong
> to a differen memory section. This along with CONFIG_SPARSEMEM then
> makes the loop condition completely bogus because a pointer arithmetic
> doesn't work for pages from two different sections in that memory model.
> 
> Fix the issue by reworking is_pageblock_removable to be pfn based and
> only use struct page where necessary. This makes the code slightly
> easier to follow and we will remove the problematic pointer arithmetic
> completely.
> 
> Fixes: efad4e475c31 ("mm, memory_hotplug: is_mem_section_removable do not 
> pass the end of a zone")
> Reported-by: 
> Signed-off-by: Michal Hocko 
> ---
>  mm/memory_hotplug.c | 27 +++
>  1 file changed, 15 insertions(+), 12 deletions(-)
> 
> diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
> index 124e794867c5..1ad28323fb9f 100644
> --- a/mm/memory_hotplug.c
> +++ b/mm/memory_hotplug.c
> @@ -1188,11 +1188,13 @@ static inline int pageblock_free(struct page *page)
>   return PageBuddy(page) && page_order(page) >= pageblock_order;
>  }
>  
> -/* Return the start of the next active pageblock after a given page */
> -static struct page *next_active_pageblock(struct page *page)
> +/* Return the pfn of the start of the next active pageblock after a given 
> pfn */
> +static unsigned long next_active_pageblock(unsigned long pfn)
>  {
> + struct page *page = pfn_to_page(pfn);
> +
>   /* Ensure the starting page is pageblock-aligned */
> - BUG_ON(page_to_pfn(page) & (pageblock_nr_pages - 1));
> + BUG_ON(pfn & (pageblock_nr_pages - 1));
>  
>   /* If the entire pageblock is free, move to the end of free page */
>   if (pageblock_free(page)) {
> @@ -1200,16 +1202,16 @@ static struct page *next_active_pageblock(struct page 
> *page)
>   /* be careful. we don't have locks, page_order can be changed.*/
>   order = page_order(page);
>   if ((order < MAX_ORDER) && (order >= pageblock_order))
> - return page + (1 << order);
> + return pfn + (1 << order);
>   }
>  
> - return page + pageblock_nr_pages;
> + return pfn + pageblock_nr_pages;
>  }
>  
> -static bool is_pageblock_removable_nolock(struct page *page)
> +static bool is_pageblock_removable_nolock(unsigned long pfn)
>  {
> + struct page *page = pfn_to_page(pfn);
>   struct zone 

Re: [PATCH] slub: fix a crash with SLUB_DEBUG + KASAN_SW_TAGS

[Andrey Konovalov]

On Wed, Feb 20, 2019 at 3:03 AM Qian Cai  wrote:
>
> In process_slab(), "p = get_freepointer()" could return a tagged
> pointer, but "addr = page_address()" always return a native pointer. As
> the result, slab_index() is messed up here,
>
> return (p - addr) / s->size;
>
> All other callers of slab_index() have the same situation where "addr"
> is from page_address(), so just need to untag "p".
>
>  # cat /sys/kernel/slab/hugetlbfs_inode_cache/alloc_calls
>
> [18868.759419] Unable to handle kernel paging request at virtual address 
> 2bff808aa4856d48
> [18868.767341] Mem abort info:
> [18868.770133]   ESR = 0x9607
> [18868.773187]   Exception class = DABT (current EL), IL = 32 bits
> [18868.779103]   SET = 0, FnV = 0
> [18868.782155]   EA = 0, S1PTW = 0
> [18868.785292] Data abort info:
> [18868.788170]   ISV = 0, ISS = 0x0007
> [18868.792003]   CM = 0, WnR = 0
> [18868.794973] swapper pgtable: 64k pages, 48-bit VAs, pgdp = 02498338
> [18868.801932] [2bff808aa4856d48] pgd=0097fcfd0003, pud=0097fcfd0003, 
> pmd=0097fca30003, pte=00e8008b24850712
> [18868.812597] Internal error: Oops: 9607 [#1] SMP
> [18868.835088] CPU: 3 PID: 79210 Comm: read_all Tainted: G L
> 5.0.0-rc7+ #84
> [18868.843087] Hardware name: HPE Apollo 70 /C01_APACHE_MB
>  , BIOS L50_5.13_1.0.6 07/10/2018
> [18868.852915] pstate: 00400089 (nzcv daIf +PAN -UAO)
> [18868.857710] pc : get_map+0x78/0xec
> [18868.861109] lr : get_map+0xa0/0xec
> [18868.864505] sp : aeff808989e3f8e0
> [18868.867816] x29: aeff808989e3f940 x28: 80082620
> [18868.873128] x27: 100012d47000 x26: 97002500
> [18868.878440] x25: 0001 x24: 52ff8008200131f8
> [18868.883753] x23: 52ff8008200130a0 x22: 52ff800820013098
> [18868.889065] x21: 80082620 x20: 100013172ba0
> [18868.894377] x19: 2bff808a8971bc00 x18: 1000148f5538
> [18868.899690] x17: 001b x16: 00ff
> [18868.905002] x15: 1000148f5000 x14: 00d2
> [18868.910314] x13: 0001 x12: 
> [18868.915626] x11: 2002 x10: 2bff808aa4856d48
> [18868.920937] x9 : 0200 x8 : 68ff80082620ebb0
> [18868.926249] x7 :  x6 : 1000105da1dc
> [18868.931561] x5 :  x4 : 
> [18868.936872] x3 : 0010 x2 : 2bff808a8971bc00
> [18868.942184] x1 : 7fe002098800 x0 : 80082620ceb0
> [18868.947499] Process read_all (pid: 79210, stack limit = 0xf65b9361)
> [18868.954454] Call trace:
> [18868.956899]  get_map+0x78/0xec
> [18868.959952]  process_slab+0x7c/0x47c
> [18868.963526]  list_locations+0xb0/0x3c8
> [18868.967273]  alloc_calls_show+0x34/0x40
> [18868.971107]  slab_attr_show+0x34/0x48
> [18868.974768]  sysfs_kf_seq_show+0x2e4/0x570
> [18868.978864]  kernfs_seq_show+0x12c/0x1a0
> [18868.982786]  seq_read+0x48c/0xf84
> [18868.986099]  kernfs_fop_read+0xd4/0x448
> [18868.989935]  __vfs_read+0x94/0x5d4
> [18868.993334]  vfs_read+0xcc/0x194
> [18868.996560]  ksys_read+0x6c/0xe8
> [18868.999786]  __arm64_sys_read+0x68/0xb0
> [18869.003622]  el0_svc_handler+0x230/0x3bc
> [18869.007544]  el0_svc+0x8/0xc
> [18869.010428] Code: d3467d2a 9ac92329 8b0a0e6a f9800151 (c85f7d4b)
> [18869.016742] ---[ end trace a383a9a44ff13176 ]---
> [18869.021356] Kernel panic - not syncing: Fatal exception
> [18869.026705] SMP: stopping secondary CPUs
> [18870.254279] SMP: failed to stop secondary CPUs 1-7,32,40,127
> [18870.259942] Kernel Offset: disabled
> [18870.263434] CPU features: 0x002,2c18
> [18870.267358] Memory Limit: none
> [18870.270725] ---[ end Kernel panic - not syncing: Fatal exception ]---
>
> Signed-off-by: Qian Cai 

Reviewed-by: Andrey Konovalov 

> ---
>  mm/slub.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/mm/slub.c b/mm/slub.c
> index 4a61959e1887..289c22f1b0c4 100644
> --- a/mm/slub.c
> +++ b/mm/slub.c
> @@ -311,7 +311,7 @@ static inline void set_freepointer(struct kmem_cache *s, 
> void *object, void *fp)
>  /* Determine object index from a given position */
>  static inline unsigned int slab_index(void *p, struct kmem_cache *s, void 
> *addr)
>  {
> -   return (p - addr) / s->size;
> +   return (kasan_reset_tag(p) - addr) / s->size;
>  }
>
>  static inline unsigned int order_objects(unsigned int order, unsigned int 
> size)
> --
> 2.17.2 (Apple Git-113)
>

[PATCH] vfs: Make __vfs_write() static

[Geert Uytterhoeven]

__vfs_write() was unexported, and removed from , but
forgotten to be made static.

Fixes: eb031849d52e61d2 ("fs: unexport __vfs_read/__vfs_write")
Signed-off-by: Geert Uytterhoeven 
---
 fs/read_write.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/fs/read_write.c b/fs/read_write.c
index ff3c5e6f87cfaa7c..4b328e45db36682a 100644
--- a/fs/read_write.c
+++ b/fs/read_write.c
@@ -478,8 +478,8 @@ static ssize_t new_sync_write(struct file *filp, const char 
__user *buf, size_t
return ret;
 }
 
-ssize_t __vfs_write(struct file *file, const char __user *p, size_t count,
-   loff_t *pos)
+static ssize_t __vfs_write(struct file *file, const char __user *p,
+  size_t count, loff_t *pos)
 {
if (file->f_op->write)
return file->f_op->write(file, p, count, pos);
-- 
2.17.1

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

[Halil Pasic]

On Wed, 20 Feb 2019 10:27:31 +0100
Cornelia Huck  wrote:

> 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.
> 


I agree, no need to complicate this any further.

> > 
> > >   
> > >> +}
> > >> +
> > >> +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.
> 

Nod.

> > 
> > 
> > >   
> > >> +    .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.
> 

I see this as a reason to suppress_bind_attrs. It is much easier than to
think about what should happen when one unbinds the matrix device from
the vfio_ap driver on the vfio_ap bus. With the code as is it seems to
just keep working as if nothing happened.
And /sys/devices/vfio_ap/matrix/mdev_supported_types/ referencing the
name of the driver that is already gone sounds a bit weird.

Regards,
Halil

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

[Pingfan Liu]

On Wed, Feb 20, 2019 at 5:41 PM Dave Young  wrote:
>
> 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 think swiotlb is bounce-buffer, if we enlarge it, we can get better
performance. Default size should be enough for platform to work. But
in case of reserving low memory for crashkernel, things are different.
The reserve low memory = swiotlb_size_or_default() + DMA32 memory for
devices. And the 2nd item in the right of the equation varies, based
on machine type and dynamic payload

> > 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.
>
Not following the idea, I do not think the following test result can
tell much. (We need various type of machine to get a final result.)
I do a quick test on "HPE ProLiant DL380 Gen10/ProLiant DL380 Gen10",
command line "crashkernel=180M,high crashkernel=64M,low" can work for
the 2nd kernel. Although it complained some memory shortage issue:
[7.655591] fbcon: mgadrmfb (fb0) is primary device
[7.655639] Console: switching to colour frame buffer device 128x48
[7.660609] systemd-udevd: page allocation failure: order:0, mode:0x280d4
[7.660611] CPU: 0 PID: 180 Comm: systemd-udevd Not tainted
3.10.0-957.el7.x86_64 #1
[7.660612] Hardware name: HPE ProLiant DL380 Gen10/ProLiant DL380
Gen10, BIOS U30 06/20/2018
[7.660612] Call Trace:
[7.660621]  [] dump_stack+0x19/0x1b
[7.660625]  [] warn_alloc_failed+0x110/0x180
[7.660628]  [] __alloc_pages_slowpath+0x6b6/0x724
[7.660631]  [] __alloc_pages_nodemask+0x405/0x420
[7.660633]  [] alloc_pages_current+0x98/0x110
[7.660638]  [] ttm_pool_populate+0x3d2/0x4b0 [ttm]
[7.660641]  [] ttm_tt_populate+0x7d/0x90 [ttm]
[7.660644]  [] ttm_bo_kmap+0x124/0x240 [ttm]
[7.660648]  [] ? __wake_up_sync_key+0x4f/0x60
[7.660650]  [] mga_dirty_update+0x25e/0x310 [mgag200]
[7.660653]  [] mga_imageblit+0x2f/0x40 [mgag200]
[7.660657]  [] soft_cursor+0x1ba/0x260
[7.660659]  [] bit_cursor+0x663/0x6a0
[7.660662]  [] ? console_trylock+0x19/0x70
[7.660664]  [] fbcon_cursor+0x13d/0x1c0
[7.660665]  [] ? bit_clear+0x120/0x120
[7.660668]  [] hide_cursor+0x2e/0xa0
[7.660669]  [] redraw_screen+0x188/0x270
[7.660671]  [] do_bind_con_driver+0x316/0x340
[7.660672]  [] do_take_over_console+0x49/0x60
[7.660674]  [] do_fbcon_takeover+0x63/0xd0
[7.660675]  [] fbcon_event_notify+0x61d/0x730
[7.660678]  [] notifier_call_chain+0x4f/0x70
[7.660681]  [] __blocking_notifier_call_chain+0x4d/0x70
[7.660683]  [] blocking_notifier_call_chain+0x16/0x20
[7.660684]  [] fb_notifier_call_chain+0x1b/0x20
[7.660686]  [] register_framebuffer+0x1f6/0x340
[7.660690]  []
__drm_fb_helper_initial_config_and_unlock+0x252/0x3e0 [drm_kms_helper]
[7.660694]  []
drm_fb_helper_initial_config+0x3e/0x50 [drm_kms_helper]
[7.660697]  [] mgag200_fbdev_init+0xe3/0x100 [mgag200]
[7.660699]  [] mgag200_modeset_init+0x154/0x1d0 [mgag200]
[7.660701]  [] mgag200_driver_load+0x41d/0x5b0 [mgag200]
[7.660708]  [] drm_dev_register+0x15f/0x1f0 [drm]
[7.660711]  [] ? pci_enable_device_flags+0xe8/0x140
[7.660718]  [] drm_get_pci_dev+0x8a/0x1a0 [drm]
[7.660720]  [] mga_pci_probe+0x9b/0xc0 [mgag200]
[7.660722]  [] local_pci_probe+0x4a/0xb0
[7.660723]  [] pci_device_probe+0x109/0x160
[7.660726]  [] driver_probe_device+0xc5/0x3e0
[7.660727]  [] __driver_attach+0x93/0xa0
[7.660728]  [] ? __device_attach+0x50/0x50
[7.660730]  [] bus_for_each_dev+0x75/0xc0
[7.660731]  [] driver_attach+0x1e/0x20
[7.660733]  [] bus_add_driver+0x200/0x2d0
[7.660734]  [] driver_register+0x64/0xf0
[7.660735]  [] __pci_register_driver+0xa5/0xc0
[7.660737]  [] ? 0xc012cfff
[7.660739]  [] mgag200_init+0x39/0x1000 [mgag200]
[7.660742]  [] do_one_initcall+0xba/0x240
[7.660745]  [] load_module+0x272c/0x2bc0
[7.660748]  [] ? ddebug_proc_write+0x100/0x100
[7.660750]  [] SyS_init_module+0xef/0x140
[7.660752]  [] system_call_fastpath+0x22/0x27
[7.660753] Mem-Info:
[7.660756] active_anon:3364 inactive_anon:6661 isolated_anon:0
[7.660756]  active_file:0 inactive_file:0 isolated_file:0
[7.660756]  unevictable:0 dirty:0 writeback:0 unstable:0
[7.660756]  slab_reclaimable:1492 slab_unreclaimable:3116
[7.660756]  mapped:1223 shmem:8449 pagetables:179 bounce:0
[7.660756]  

Re: [PATCH 4.19 01/24] bridge: do not add port to router list when receives query with source 0.0.0.0

[Sebastian Gottschall]

*reminder*

Am 18.02.2019 um 11:18 schrieb Sebastian Gottschall:


Am 17.02.2019 um 17:48 schrieb Greg Kroah-Hartman:

On Sun, Feb 17, 2019 at 03:29:22PM +0100, Sebastian Gottschall wrote:
according to user reports this patch will cause a serious 
regression. igmp

snooping is not working anymore with this patch

Am 02.11.2018 um 19:34 schrieb Greg Kroah-Hartman:
4.19-stable review patch.  If anyone has any objections, please let 
me know.


--

From: Hangbin Liu 

[ Upstream commit 5a2de63fd1a59c30c02526d427bc014b98adf508 ]

Based on RFC 4541, 2.1.1.  IGMP Forwarding Rules

    The switch supporting IGMP snooping must maintain a list of
    multicast routers and the ports on which they are attached.  This
    list can be constructed in any combination of the following ways:

    a) This list should be built by the snooping switch sending
   Multicast Router Solicitation messages as described in IGMP
   Multicast Router Discovery [MRDISC].  It may also snoop
   Multicast Router Advertisement messages sent by and to other
   nodes.

    b) The arrival port for IGMP Queries (sent by multicast routers)
   where the source address is not 0.0.0.0.

We should not add the port to router list when receives query with 
source

0.0.0.0.

Reported-by: Ying Xu 
Signed-off-by: Hangbin Liu 
Acked-by: Nikolay Aleksandrov 
Acked-by: Roopa Prabhu 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman 
---
   net/bridge/br_multicast.c |   10 +-
   1 file changed, 9 insertions(+), 1 deletion(-)

--- a/net/bridge/br_multicast.c
+++ b/net/bridge/br_multicast.c
@@ -1420,7 +1420,15 @@ static void br_multicast_query_received(
   return;
   br_multicast_update_query_timer(br, query, max_delay);
-    br_multicast_mark_router(br, port);
+
+    /* Based on RFC4541, section 2.1.1 IGMP Forwarding Rules,
+ * the arrival port for IGMP Queries where the source address
+ * is 0.0.0.0 should not be added to router port list.
+ */
+    if ((saddr->proto == htons(ETH_P_IP) && saddr->u.ip4) ||
+    (saddr->proto == htons(ETH_P_IPV6) &&
+ !ipv6_addr_any(>u.ip6)))
+    br_multicast_mark_router(br, port);
   }
   static void br_ip4_multicast_query(struct net_bridge *br,

Is this also a problem in 4.20?  This patch went into 4.20-rc1, so it
has been around for a while with no reported issues that I can find.
Any pointers to the reports?


i need to check this. i found this patch in 4.9, 4.14 and 4.4
the rest was picked up from the mailinglist. according to the git 
sources of 4.20 and 5.0 the same code is in there as well


i just got the report from users today and was able to reproduce it 
with iptv streams. just by disabling the code it was working again.


Sebastian


thanks,

greg k-h

Re: [PATCH 00/10] perf: Multi-die/package support

[Jiri Olsa]

On Tue, Feb 19, 2019 at 12:00:01PM -0800, kan.li...@linux.intel.com wrote:
> From: Kan Liang 
> 
> Add Linux perf support for multi-die/package. The first product with
> multi-die is Xeon Cascade Lake-AP (CLX-AP).
> The code bases on the top of Len's multi-die/package support.
> https://lkml.org/lkml/2019/2/18/1534
> 
> Patch 1-4: They are generic codes for previous platforms.
> Perf supports miscellaneous modules, e.g cstate, RAPL and uncore.
> Their counters have the same scope of effect (per package).
> But they maintain their own scope information independently.
> It's very useful to abstract several common topology related codes
> for these modules to reduce the code redundancy, especially when
> adding counters with new scope.
> 
> Patch 5-8: Support die scope counters on CLX-AP for uncore, RAPL
> and cstate.
> 
> Patch 9-10: Support per-die aggregation for perf stat and header.
> 
> Kan Liang (10):
>   perf/x86/intel: Introduce a concept "domain" as the scope of counters
>   perf/x86/intel/cstate: Apply "domain" for cstate
>   perf/x86/intel/uncore: Apply "domain" for uncore
>   perf/x86/intel/rapl: Apply "domain" for RAPL
>   perf/x86/intel/domain: Add new domain type for die
>   perf/x86/intel/uncore: Support die scope counters on CLX-AP
>   perf/x86/intel/rapl: Support die scope counters on CLX-AP
>   perf/x86/intel/cstate: Support die scope counters on CLX-AP
>   perf header: Add die information in cpu topology
>   perf stat: Support per-die aggregation

hi,
what is based on? I'm getting conflicts when applying
on tip or Arnaldo's perf/core

thanks,
jirka

> 
>  arch/x86/events/Makefile   |   2 +-
>  arch/x86/events/domain.c   |  81 +
>  arch/x86/events/domain.h   |  26 ++
>  arch/x86/events/intel/cstate.c | 364 
> -
>  arch/x86/events/intel/rapl.c   | 333 ++-
>  arch/x86/events/intel/uncore.c | 247 +-
>  arch/x86/events/intel/uncore.h |   9 +-
>  arch/x86/events/intel/uncore_snbep.c   |   2 +-
>  tools/perf/Documentation/perf-stat.txt |  10 +
>  tools/perf/Documentation/perf.data-file-format.txt |   9 +-
>  tools/perf/builtin-stat.c  |  73 -
>  tools/perf/util/cpumap.c   |  55 +++-
>  tools/perf/util/cpumap.h   |  10 +-
>  tools/perf/util/env.c  |   1 +
>  tools/perf/util/env.h  |   3 +
>  tools/perf/util/header.c   | 185 ++-
>  tools/perf/util/stat-display.c |  24 +-
>  tools/perf/util/stat-shadow.c  |   1 +
>  tools/perf/util/stat.c |   1 +
>  tools/perf/util/stat.h |   1 +
>  20 files changed, 1082 insertions(+), 355 deletions(-)
>  create mode 100644 arch/x86/events/domain.c
>  create mode 100644 arch/x86/events/domain.h
> 
> -- 
> 2.7.4
> 

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

[Maxime Ripard]

Hi,

On Wed, Feb 20, 2019 at 10:59:58AM +, Måns Rullgård wrote:
> Maxime Ripard  writes:
> 
> > 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.
> 
> Should we also add this to existing nodes?

If you want to send an additional patch, then yes sure :)

Maxime

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


signature.asc
Description: PGP signature

[PATCH 1/4] kasan: prevent tracing of tags.c

[Andrey Konovalov]

Similarly to 0d0c8de8 ("kasan: mark file common so ftrace doesn't trace
it") add the -pg flag to mm/kasan/tags.c to prevent conflicts with
tracing.

Reported-by: Qian Cai 
Signed-off-by: Andrey Konovalov 
---
 mm/kasan/Makefile | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/mm/kasan/Makefile b/mm/kasan/Makefile
index e2bb06c1b45e..5d1065efbd47 100644
--- a/mm/kasan/Makefile
+++ b/mm/kasan/Makefile
@@ -7,6 +7,8 @@ KCOV_INSTRUMENT := n
 
 CFLAGS_REMOVE_common.o = -pg
 CFLAGS_REMOVE_generic.o = -pg
+CFLAGS_REMOVE_tags.o = -pg
+
 # Function splitter causes unnecessary splits in __asan_load1/__asan_store1
 # see: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63533
 
-- 
2.21.0.rc0.258.g878e2cd30e-goog

[PATCH 3/4] kasan, slab: make freelist stored without tags

[Andrey Konovalov]

Similarly to 680c37ae ("kasan, slub: move kasan_poison_slab hook before
page_address"), move kasan_poison_slab() before alloc_slabmgmt(), which
calls page_address(), to make page_address() return value to be
non-tagged. This, combined with calling kasan_reset_tag() for off-slab
slab management object, leads to freelist being stored non-tagged.

Signed-off-by: Andrey Konovalov 
---
 mm/slab.c | 11 +--
 1 file changed, 9 insertions(+), 2 deletions(-)

diff --git a/mm/slab.c b/mm/slab.c
index c84458281a88..4ad95fcb1686 100644
--- a/mm/slab.c
+++ b/mm/slab.c
@@ -2359,7 +2359,7 @@ static void *alloc_slabmgmt(struct kmem_cache *cachep,
void *freelist;
void *addr = page_address(page);
 
-   page->s_mem = kasan_reset_tag(addr) + colour_off;
+   page->s_mem = addr + colour_off;
page->active = 0;
 
if (OBJFREELIST_SLAB(cachep))
@@ -2368,6 +2368,7 @@ static void *alloc_slabmgmt(struct kmem_cache *cachep,
/* Slab management obj is off-slab. */
freelist = kmem_cache_alloc_node(cachep->freelist_cache,
  local_flags, nodeid);
+   freelist = kasan_reset_tag(freelist);
if (!freelist)
return NULL;
} else {
@@ -2681,6 +2682,13 @@ static struct page *cache_grow_begin(struct kmem_cache 
*cachep,
 
offset *= cachep->colour_off;
 
+   /*
+* Call kasan_poison_slab() before calling alloc_slabmgmt(), so
+* page_address() in the latter returns a non-tagged pointer,
+* as it should be for slab pages.
+*/
+   kasan_poison_slab(page);
+
/* Get slab management. */
freelist = alloc_slabmgmt(cachep, page, offset,
local_flags & ~GFP_CONSTRAINT_MASK, page_node);
@@ -2689,7 +2697,6 @@ static struct page *cache_grow_begin(struct kmem_cache 
*cachep,
 
slab_map_pages(cachep, page, freelist);
 
-   kasan_poison_slab(page);
cache_init_objs(cachep, page);
 
if (gfpflags_allow_blocking(local_flags))
-- 
2.21.0.rc0.258.g878e2cd30e-goog

[PATCH 4/4] kasan, slab: remove redundant kasan_slab_alloc hooks

[Andrey Konovalov]

kasan_slab_alloc() calls in kmem_cache_alloc() and kmem_cache_alloc_node()
are redundant as they are already called via slab_alloc/slab_alloc_node()->
slab_post_alloc_hook()->kasan_slab_alloc(). Remove them.

Signed-off-by: Andrey Konovalov 
---
 mm/slab.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/mm/slab.c b/mm/slab.c
index 4ad95fcb1686..91c1863df93d 100644
--- a/mm/slab.c
+++ b/mm/slab.c
@@ -3547,7 +3547,6 @@ void *kmem_cache_alloc(struct kmem_cache *cachep, gfp_t 
flags)
 {
void *ret = slab_alloc(cachep, flags, _RET_IP_);
 
-   ret = kasan_slab_alloc(cachep, ret, flags);
trace_kmem_cache_alloc(_RET_IP_, ret,
   cachep->object_size, cachep->size, flags);
 
@@ -3637,7 +3636,6 @@ void *kmem_cache_alloc_node(struct kmem_cache *cachep, 
gfp_t flags, int nodeid)
 {
void *ret = slab_alloc_node(cachep, flags, nodeid, _RET_IP_);
 
-   ret = kasan_slab_alloc(cachep, ret, flags);
trace_kmem_cache_alloc_node(_RET_IP_, ret,
cachep->object_size, cachep->size,
flags, nodeid);
-- 
2.21.0.rc0.258.g878e2cd30e-goog

[PATCH 2/4] kasan, slab: fix conflicts with CONFIG_HARDENED_USERCOPY

[Andrey Konovalov]

Similarly to 96fedce2 ("kasan: make tag based mode work with
CONFIG_HARDENED_USERCOPY"), we need to reset pointer tags in
__check_heap_object() in mm/slab.c before doing any pointer math.

Signed-off-by: Andrey Konovalov 
---
 mm/slab.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/mm/slab.c b/mm/slab.c
index 78eb8c5bf4e4..c84458281a88 100644
--- a/mm/slab.c
+++ b/mm/slab.c
@@ -4408,6 +4408,8 @@ void __check_heap_object(const void *ptr, unsigned long 
n, struct page *page,
unsigned int objnr;
unsigned long offset;
 
+   ptr = kasan_reset_tag(ptr);
+
/* Find and validate object. */
cachep = page->slab_cache;
objnr = obj_to_index(cachep, page, (void *)ptr);
-- 
2.21.0.rc0.258.g878e2cd30e-goog

Re: [PATCH 4/4] drm/panel: Add OSD101T2587-53TS driver

[Sam Ravnborg]

Hi Peter.

Always good to see that feedback input is used.
 
> OK.
> 
> >> +
> >> +  return 0;
> >> +}
> >> +
> >> +static void osd101t2587_panel_shutdown(struct mipi_dsi_device *dsi)
> >> +{
> >> +  struct osd101t2587_panel *osd101t2587 = mipi_dsi_get_drvdata(dsi);
> >> +
> > Maybe call osd101t2587_panel_unprepare() here to turn off power supply?
> 
> Make sense, in this order:
>   osd101t2587_panel_disable(>base);
>   osd101t2587_panel_unprepare(>base);
> 
> But should the osd101t2587_panel_remove() do the same thing? or the
> osd101t2587_panel_disable() is redundant in the osd101t2587_panel_remove()?

I do not know the details to answer this.
In other words - I do not know if we can rely on that panel->disbale is always
called when a driver is removed.
Try to read the descriptions and maybe test it.

Other drivers do as far as I recall use disable in the remove function.

Sam

Re: [PATCH v2 1/2] extcon-intel-cht-wc: Make charger detection co-existed with OTG host mode

[Andy Shevchenko]

On Wed, Feb 20, 2019 at 12:24:40AM +0300, Yauhen Kharuzhy wrote:
> Whiskey Cove Cherry Trail PMIC requires disabling OTG host mode before
> of charger detection procedure. Do this by manipulationg of CHGRCTRL1
> register.
> 
> Source: APCI DSDT code of Lenovo Yoga Book YB1-X91L and open-sourced
> Intel's drivers.

Some minor comments below.

Otherwise,

Reviewed-by: Andy Shevchenko 

> -#define CHT_WC_CHGRCTRL1 0x5e17
> +#define CHT_WC_CHGRCTRL1 0x5e17

Not related change?

> +#define CHT_WC_CHGRCTRL1_DBPEN_MASK  BIT(7)

Drop the _MASK, it's one bit anyway.

> +#define CHT_WC_CHGRCTRL1_OTGMODE BIT(6)
> +#define CHT_WC_CHGRCTRL1_FTEMP_EVENT BIT(5)
> +#define CHT_WC_CHGRCTRL1_FUSB_INLMT_1500 BIT(4)
> +#define CHT_WC_CHGRCTRL1_FUSB_INLMT_900  BIT(3)
> +#define CHT_WC_CHGRCTRL1_FUSB_INLMT_500  BIT(2)
> +#define CHT_WC_CHGRCTRL1_FUSB_INLMT_150  BIT(1)
> +#define CHT_WC_CHGRCTRL1_FUSB_INLMT_100  BIT(0)

I think better to keep ascending order.

> +static void cht_wc_extcon_set_otgmode(struct cht_wc_extcon_data *ext,
> +   bool enable)
> +{
> + unsigned int chgrctrl1;
> + int ret;
> +
> + ret = regmap_read(ext->regmap, CHT_WC_CHGRCTRL1, );
> + if (ret) {
> + dev_err(ext->dev, "Error reading CHGRCTRL1 reg: %d\n", ret);
> + return;
> + }
> +
> + if (enable)
> + chgrctrl1 |= CHT_WC_CHGRCTRL1_OTGMODE;
> + else
> + chgrctrl1 &= ~(CHT_WC_CHGRCTRL1_OTGMODE);

Redundant parens.

> +
> + ret = regmap_write(ext->regmap, CHT_WC_CHGRCTRL1, chgrctrl1);
> + if (ret)
> + dev_err(ext->dev,
> + "Error writing CHGRCTRL1 OTG mode bit: %d\n", ret);
> +}

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH] powerpc: fix 32-bit KVM-PR lockup and panic with MacOS guest

[Michael Ellerman]

Mark Cave-Ayland  writes:
> On 19/02/2019 04:20, Michael Ellerman wrote:
>> Mark Cave-Ayland  writes:
> unexpectedly removed the MSR_FE0 and MSR_FE1 bits from the bitmask used to
> update the MSR of the previous thread in __giveup_fpu() causing a KVM-PR 
> MacOS
> guest to lockup and panic the kernel.
>> 
>> Which kernel is panicking? The guest or the host?
>
> It's the host kernel. As long as you occasionally tap a few keys to keep the 
> screen
> blanking disabled then you can see the panic on the physical console.

Ah crap I assumed you meant the guest kernel.

> I've uploaded a photo I took during the bisection containing the panic when 
> booting
> MacOS X 10.2 under qemu-system-ppc to
> https://www.ilande.co.uk/tmp/qemu/macmini-kvm.jpg in case you find it useful.

OK. That's a host crash, but only because init died (systemd). Though
the reason it died is because we didn't clear FE0/1 properly, so still a
kernel bug.

> Given that it's really easy to recreate, let me know if you want me to do a 
> git
> pull/rebuild and/or if you need any debugging information as it's easy for me 
> to
> reproduce.

I think that's OK. It's reasonably clear what's going on.


>>> 2) Is this the right fix? I'm told that MacOS guests already run without 
>>> this patch
>>> on a G5 under 64-bit KVM-PR which may suggest that this is a workaround for 
>>> another
>>> bug elsewhere in the 32-bit powerpc code.
>> 
>> That's slightly worrying. It's hard to say without more detail on why
>> the guest is crashing.
>> 
>> I think your patch looks OK based just on the fact that it restores the
>> previous behaviour, so I'll pick it up and pass it through my usual
>> testing. If nothing breaks I'll merge it.
>
> That would be great! Does it need a CC to stable too? It would be great if 
> this would
> get picked up in the next set of Debian ports kernels, for example.

I'll add Cc stable.

cheers

Re: [PATCH v2 -next] btrfs: Remove unnecessary casts in btrfs_read_root_item

[Qu Wenruo]

On 2019/2/20 下午8:32, YueHaibing wrote:
> 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 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.
> 
> Suggested-by: Dan Carpenter 
> Signed-off-by: YueHaibing 

Reviewed-by: Qu Wenruo 

The commit message is much better.

Thanks,
Qu

> ---
> v2: modify commit message as Dan suggested 
> ---
>  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)));
> +min_t(u32, len, sizeof(*item)));
>   if (len < sizeof(*item))
>   need_reset = 1;
>   if (!need_reset && btrfs_root_generation(item)
> 
> 
> 



signature.asc
Description: OpenPGP digital signature

Re: [RFC PATCH net-next v3 10/21] ethtool: provide string sets with GET_STRSET request

[Michal Kubecek]

On Tue, Feb 19, 2019 at 06:56:10PM -0800, Jakub Kicinski wrote:
> On Mon, 18 Feb 2019 19:22:14 +0100 (CET), Michal Kubecek wrote:
> > Requests a contents of one or more string sets, i.e. indexed arrays of
> > strings; this information is provided by ETHTOOL_GSSET_INFO and
> > ETHTOOL_GSTRINGS commands of ioctl interface. There are three types of
> > requests:
> > 
> >   - no NLM_F_DUMP, no device: get "global" stringsets
> >   - no NLM_F_DUMP, with device: get string sets related to the device
> >   - NLM_F_DUMP, no device: get device related string sets for all devices
> > 
> > It's possible to request all string sets of given type or only specific
> > sets. With ETHA_STRSET_COUNTS flag, only set sizes (number of strings) are
> > returned.
> 
> > +GET_STRSET
> > +--
> > +
> > +Requests contents of a string set as provided by ioctl commands
> > +ETHTOOL_GSSET_INFO and ETHTOOL_GSTRINGS. String sets are not user 
> > writeable so
> > +that the corresponding SET_STRSET message is only used in kernel replies.
> > +There are two types of string sets: global (independent of a device, e.g.
> > +device feature names) and device specific (e.g. device private flags).
> > +
> > +Request contents:
> > +
> > +ETHA_STRSET_DEV(nested)device identification
> > +ETHA_STRSET_COUNTS (flag)  request only string 
> > counts
> > +ETHA_STRSET_STRINGSET  (nested)string set to request
> > +ETHA_STRINGSET_ID  (u32)   set id
> > +
> > +Kernel response contents:
> > +
> > +ETHA_STRSET_DEV(nested)device identification
> > +ETHA_STRSET_STRINGSET  (nested)string set to request
> 
> Is it common to put the device information outside of the main
> attribute nest?

There may be multiple string sets (ETHA_STRSET_STIRNGSET nests) in one
message but they would be either all global or all related to the same
device. If string sets for multiple devices are sent, it would be in
response to a dump request and there would be one message per device.

> 
> > +ETHA_STRINGSET_ID  (u32)   set id
> > +ETHA_STRINGSET_COUNT   (u32)   number of 
> > strings
> > +ETHA_STRINGSET_STRINGS (nested)array of strings
> > +ETHA_STRING_INDEX  (u32)   string 
> > index
> > +ETHA_STRING_VALUE  (string)string 
> > value
> > +
> > +ETHA_STRSET_DEV, if present, identifies the device to request device 
> > specific
> > +string sets for. Depending on its presence a and NLM_F_DUMP flag, there are
> > +three type of GET_STRSET requests:
> > +
> > + - no NLM_F_DUMP, no device: get "global" stringsets
> > + - no NLM_F_DUMP, with device: get string sets related to the device
> > + - NLM_F_DUMP, no device: get device related string sets for all devices
> > +
> > +If there is no ETHA_STRSET_STRINGSET attribute, all string sets of 
> > requested
> > +type are returned, otherwise only those specified in the request. Flag
> > +ETHA_STRSET_COUNTS tells kernel to only return string counts of the sets, 
> > not
> > +the actual strings.
> > +
> > +
> 
> > +static int get_strset_id(const struct nlattr *nest, u32 *val,
> > +struct genl_info *info)
> > +{
> > +   struct nlattr *tb[ETHA_STRINGSET_MAX + 1];
> > +   int ret;
> > +
> > +   ret = nla_parse_nested(tb, ETHA_STRINGSET_MAX, nest, stringset_policy,
> > +  info ? info->extack : NULL);
> 
> Would it make sense to use strict parsing everywhere from the start?
> You seem to add REJECTS, but won't attributes > max get ignored?

Good point, I forgot about this when the strict checking helpers were
added. I'll change the uses of nlmsg_parse() and nla_parse_nested() to
their strict variants (and add nla_parse_nested_strict()).

Michal

[PATCH v4 3/3] i2c: mediatek: Add i2c support for MediaTek MT8183

[Qii Wang]

Add i2c compatible for MT8183. Compare to MT2712 i2c controller,
MT8183 has different registers, offsets and clock.

Signed-off-by: Qii Wang 
---
 drivers/i2c/busses/i2c-mt65xx.c |   89 ---
 1 file changed, 84 insertions(+), 5 deletions(-)

diff --git a/drivers/i2c/busses/i2c-mt65xx.c b/drivers/i2c/busses/i2c-mt65xx.c
index 428ac99..82eedbd 100644
--- a/drivers/i2c/busses/i2c-mt65xx.c
+++ b/drivers/i2c/busses/i2c-mt65xx.c
@@ -35,6 +35,7 @@
 #include 
 
 #define I2C_RS_TRANSFER(1 << 4)
+#define I2C_ARB_LOST   (1 << 3)
 #define I2C_HS_NACKERR (1 << 2)
 #define I2C_ACKERR (1 << 1)
 #define I2C_TRANSAC_COMP   (1 << 0)
@@ -76,6 +77,8 @@
 #define I2C_CONTROL_DIR_CHANGE  (0x1 << 4)
 #define I2C_CONTROL_ACKERR_DET_EN   (0x1 << 5)
 #define I2C_CONTROL_TRANSFER_LEN_CHANGE (0x1 << 6)
+#define I2C_CONTROL_DMAACK_EN   (0x1 << 8)
+#define I2C_CONTROL_ASYNC_MODE  (0x1 << 9)
 #define I2C_CONTROL_WRAPPER (0x1 << 0)
 
 #define I2C_DRV_NAME   "i2c-mt65xx"
@@ -130,6 +133,8 @@ enum I2C_REGS_OFFSET {
OFFSET_DEBUGCTRL,
OFFSET_TRANSFER_LEN_AUX,
OFFSET_CLOCK_DIV,
+   /* MT8183 only regs */
+   OFFSET_LTIMING,
 };
 
 static const u16 mt_i2c_regs_v1[] = {
@@ -159,6 +164,32 @@ enum I2C_REGS_OFFSET {
[OFFSET_CLOCK_DIV] = 0x70,
 };
 
+static const u16 mt_i2c_regs_v2[] = {
+   [OFFSET_DATA_PORT] = 0x0,
+   [OFFSET_SLAVE_ADDR] = 0x4,
+   [OFFSET_INTR_MASK] = 0x8,
+   [OFFSET_INTR_STAT] = 0xc,
+   [OFFSET_CONTROL] = 0x10,
+   [OFFSET_TRANSFER_LEN] = 0x14,
+   [OFFSET_TRANSAC_LEN] = 0x18,
+   [OFFSET_DELAY_LEN] = 0x1c,
+   [OFFSET_TIMING] = 0x20,
+   [OFFSET_START] = 0x24,
+   [OFFSET_EXT_CONF] = 0x28,
+   [OFFSET_LTIMING] = 0x2c,
+   [OFFSET_HS] = 0x30,
+   [OFFSET_IO_CONFIG] = 0x34,
+   [OFFSET_FIFO_ADDR_CLR] = 0x38,
+   [OFFSET_TRANSFER_LEN_AUX] = 0x44,
+   [OFFSET_CLOCK_DIV] = 0x48,
+   [OFFSET_SOFTRESET] = 0x50,
+   [OFFSET_DEBUGSTAT] = 0xe0,
+   [OFFSET_DEBUGCTRL] = 0xe8,
+   [OFFSET_FIFO_STAT] = 0xf4,
+   [OFFSET_FIFO_THRESH] = 0xf8,
+   [OFFSET_DCM_EN] = 0xf88,
+};
+
 struct mtk_i2c_compatible {
const struct i2c_adapter_quirks *quirks;
const u16 *regs;
@@ -168,6 +199,7 @@ struct mtk_i2c_compatible {
unsigned char aux_len_reg: 1;
unsigned char support_33bits: 1;
unsigned char timing_adjust: 1;
+   unsigned char dma_sync: 1;
 };
 
 struct mtk_i2c {
@@ -181,6 +213,7 @@ struct mtk_i2c {
struct clk *clk_main;   /* main clock for i2c bus */
struct clk *clk_dma;/* DMA clock for i2c via DMA */
struct clk *clk_pmic;   /* PMIC clock for i2c from PMIC */
+   struct clk *clk_arb;/* Arbitrator clock for i2c */
bool have_pmic; /* can use i2c pins from PMIC */
bool use_push_pull; /* IO config push-pull mode */
 
@@ -190,6 +223,7 @@ struct mtk_i2c {
enum mtk_trans_op op;
u16 timing_reg;
u16 high_speed_reg;
+   u16 ltiming_reg;
unsigned char auto_restart;
bool ignore_restart_irq;
const struct mtk_i2c_compatible *dev_comp;
@@ -216,6 +250,7 @@ struct mtk_i2c {
.aux_len_reg = 1,
.support_33bits = 1,
.timing_adjust = 1,
+   .dma_sync = 0,
 };
 
 static const struct mtk_i2c_compatible mt6577_compat = {
@@ -227,6 +262,7 @@ struct mtk_i2c {
.aux_len_reg = 0,
.support_33bits = 0,
.timing_adjust = 0,
+   .dma_sync = 0,
 };
 
 static const struct mtk_i2c_compatible mt6589_compat = {
@@ -238,6 +274,7 @@ struct mtk_i2c {
.aux_len_reg = 0,
.support_33bits = 0,
.timing_adjust = 0,
+   .dma_sync = 0,
 };
 
 static const struct mtk_i2c_compatible mt7622_compat = {
@@ -249,6 +286,7 @@ struct mtk_i2c {
.aux_len_reg = 1,
.support_33bits = 0,
.timing_adjust = 0,
+   .dma_sync = 0,
 };
 
 static const struct mtk_i2c_compatible mt8173_compat = {
@@ -259,6 +297,18 @@ struct mtk_i2c {
.aux_len_reg = 1,
.support_33bits = 1,
.timing_adjust = 0,
+   .dma_sync = 0,
+};
+
+static const struct mtk_i2c_compatible mt8183_compat = {
+   .regs = mt_i2c_regs_v2,
+   .pmic_i2c = 0,
+   .dcm = 0,
+   .auto_restart = 1,
+   .aux_len_reg = 1,
+   .support_33bits = 1,
+   .timing_adjust = 1,
+   .dma_sync = 1,
 };
 
 static const struct of_device_id mtk_i2c_of_match[] = {
@@ -267,6 +317,7 @@ struct mtk_i2c {
{ .compatible = "mediatek,mt6589-i2c", .data = _compat },
{ .compatible = "mediatek,mt7622-i2c", .data = _compat },
{ .compatible = "mediatek,mt8173-i2c", .data = _compat },
+   { .compatible = "mediatek,mt8183-i2c", .data = _compat },
{}
 };
 MODULE_DEVICE_TABLE(of, 

[PATCH v4 0/3] add i2c support for mt8183

[Qii Wang]

This series are based on 5.0-rc1 and provide three patches to support
mt8183 IC.

Main changes compared to v3:
--remove the patches which have been applied to for-next
--remove i2c fallback for i3c controller 

Main changes compared to v2:
--update commit message
--add Reviewed-by from Rob Herring, Nicolas and Sean

Main changes compared to v1:
--remove useless dt-binding for mt7629
--split a patch into two(2/6 3/6)
--muti-user feature was dropped

Qii Wang (3):
  i2c: mediatek: Add offsets array for new i2c registers
  dt-bindings: i2c: Add Mediatek MT8183 i2c binding
  i2c: mediatek: Add i2c support for MediaTek MT8183

 Documentation/devicetree/bindings/i2c/i2c-mtk.txt |5 +-
 drivers/i2c/busses/i2c-mt65xx.c   |  246 -
 2 files changed, 188 insertions(+), 63 deletions(-)

-- 
1.7.9.5

[PATCH v4 1/3] i2c: mediatek: Add offsets array for new i2c registers

[Qii Wang]

New i2c registers would have different offsets, so we use different
offsets array to distinguish different i2c registers version.

Signed-off-by: Qii Wang 
---
 drivers/i2c/busses/i2c-mt65xx.c |  163 +--
 1 file changed, 104 insertions(+), 59 deletions(-)

diff --git a/drivers/i2c/busses/i2c-mt65xx.c b/drivers/i2c/busses/i2c-mt65xx.c
index 660de1e..428ac99 100644
--- a/drivers/i2c/busses/i2c-mt65xx.c
+++ b/drivers/i2c/busses/i2c-mt65xx.c
@@ -106,34 +106,62 @@ enum mtk_trans_op {
 };
 
 enum I2C_REGS_OFFSET {
-   OFFSET_DATA_PORT = 0x0,
-   OFFSET_SLAVE_ADDR = 0x04,
-   OFFSET_INTR_MASK = 0x08,
-   OFFSET_INTR_STAT = 0x0c,
-   OFFSET_CONTROL = 0x10,
-   OFFSET_TRANSFER_LEN = 0x14,
-   OFFSET_TRANSAC_LEN = 0x18,
-   OFFSET_DELAY_LEN = 0x1c,
-   OFFSET_TIMING = 0x20,
-   OFFSET_START = 0x24,
-   OFFSET_EXT_CONF = 0x28,
-   OFFSET_FIFO_STAT = 0x30,
-   OFFSET_FIFO_THRESH = 0x34,
-   OFFSET_FIFO_ADDR_CLR = 0x38,
-   OFFSET_IO_CONFIG = 0x40,
-   OFFSET_RSV_DEBUG = 0x44,
-   OFFSET_HS = 0x48,
-   OFFSET_SOFTRESET = 0x50,
-   OFFSET_DCM_EN = 0x54,
-   OFFSET_PATH_DIR = 0x60,
-   OFFSET_DEBUGSTAT = 0x64,
-   OFFSET_DEBUGCTRL = 0x68,
-   OFFSET_TRANSFER_LEN_AUX = 0x6c,
-   OFFSET_CLOCK_DIV = 0x70,
+   OFFSET_DATA_PORT,
+   OFFSET_SLAVE_ADDR,
+   OFFSET_INTR_MASK,
+   OFFSET_INTR_STAT,
+   OFFSET_CONTROL,
+   OFFSET_TRANSFER_LEN,
+   OFFSET_TRANSAC_LEN,
+   OFFSET_DELAY_LEN,
+   OFFSET_TIMING,
+   OFFSET_START,
+   OFFSET_EXT_CONF,
+   OFFSET_FIFO_STAT,
+   OFFSET_FIFO_THRESH,
+   OFFSET_FIFO_ADDR_CLR,
+   OFFSET_IO_CONFIG,
+   OFFSET_RSV_DEBUG,
+   OFFSET_HS,
+   OFFSET_SOFTRESET,
+   OFFSET_DCM_EN,
+   OFFSET_PATH_DIR,
+   OFFSET_DEBUGSTAT,
+   OFFSET_DEBUGCTRL,
+   OFFSET_TRANSFER_LEN_AUX,
+   OFFSET_CLOCK_DIV,
+};
+
+static const u16 mt_i2c_regs_v1[] = {
+   [OFFSET_DATA_PORT] = 0x0,
+   [OFFSET_SLAVE_ADDR] = 0x4,
+   [OFFSET_INTR_MASK] = 0x8,
+   [OFFSET_INTR_STAT] = 0xc,
+   [OFFSET_CONTROL] = 0x10,
+   [OFFSET_TRANSFER_LEN] = 0x14,
+   [OFFSET_TRANSAC_LEN] = 0x18,
+   [OFFSET_DELAY_LEN] = 0x1c,
+   [OFFSET_TIMING] = 0x20,
+   [OFFSET_START] = 0x24,
+   [OFFSET_EXT_CONF] = 0x28,
+   [OFFSET_FIFO_STAT] = 0x30,
+   [OFFSET_FIFO_THRESH] = 0x34,
+   [OFFSET_FIFO_ADDR_CLR] = 0x38,
+   [OFFSET_IO_CONFIG] = 0x40,
+   [OFFSET_RSV_DEBUG] = 0x44,
+   [OFFSET_HS] = 0x48,
+   [OFFSET_SOFTRESET] = 0x50,
+   [OFFSET_DCM_EN] = 0x54,
+   [OFFSET_PATH_DIR] = 0x60,
+   [OFFSET_DEBUGSTAT] = 0x64,
+   [OFFSET_DEBUGCTRL] = 0x68,
+   [OFFSET_TRANSFER_LEN_AUX] = 0x6c,
+   [OFFSET_CLOCK_DIV] = 0x70,
 };
 
 struct mtk_i2c_compatible {
const struct i2c_adapter_quirks *quirks;
+   const u16 *regs;
unsigned char pmic_i2c: 1;
unsigned char dcm: 1;
unsigned char auto_restart: 1;
@@ -181,6 +209,7 @@ struct mtk_i2c {
 };
 
 static const struct mtk_i2c_compatible mt2712_compat = {
+   .regs = mt_i2c_regs_v1,
.pmic_i2c = 0,
.dcm = 1,
.auto_restart = 1,
@@ -191,6 +220,7 @@ struct mtk_i2c {
 
 static const struct mtk_i2c_compatible mt6577_compat = {
.quirks = _i2c_quirks,
+   .regs = mt_i2c_regs_v1,
.pmic_i2c = 0,
.dcm = 1,
.auto_restart = 0,
@@ -201,6 +231,7 @@ struct mtk_i2c {
 
 static const struct mtk_i2c_compatible mt6589_compat = {
.quirks = _i2c_quirks,
+   .regs = mt_i2c_regs_v1,
.pmic_i2c = 1,
.dcm = 0,
.auto_restart = 0,
@@ -211,6 +242,7 @@ struct mtk_i2c {
 
 static const struct mtk_i2c_compatible mt7622_compat = {
.quirks = _i2c_quirks,
+   .regs = mt_i2c_regs_v1,
.pmic_i2c = 0,
.dcm = 1,
.auto_restart = 1,
@@ -220,6 +252,7 @@ struct mtk_i2c {
 };
 
 static const struct mtk_i2c_compatible mt8173_compat = {
+   .regs = mt_i2c_regs_v1,
.pmic_i2c = 0,
.dcm = 1,
.auto_restart = 1,
@@ -238,6 +271,17 @@ struct mtk_i2c {
 };
 MODULE_DEVICE_TABLE(of, mtk_i2c_of_match);
 
+static u16 mtk_i2c_readw(struct mtk_i2c *i2c, enum I2C_REGS_OFFSET reg)
+{
+   return readw(i2c->base + i2c->dev_comp->regs[reg]);
+}
+
+static void mtk_i2c_writew(struct mtk_i2c *i2c, u16 val,
+  enum I2C_REGS_OFFSET reg)
+{
+   writew(val, i2c->base + i2c->dev_comp->regs[reg]);
+}
+
 static int mtk_i2c_clock_enable(struct mtk_i2c *i2c)
 {
int ret;
@@ -278,31 +322,31 @@ static void mtk_i2c_init_hw(struct mtk_i2c *i2c)
 {
u16 control_reg;
 
-   writew(I2C_SOFT_RST, i2c->base + OFFSET_SOFTRESET);
+   mtk_i2c_writew(i2c, I2C_SOFT_RST, OFFSET_SOFTRESET);
 
/* Set ioconfig */
if (i2c->use_push_pull)
-   writew(I2C_IO_CONFIG_PUSH_PULL, i2c->base + OFFSET_IO_CONFIG);
+   

[PATCH v4 2/3] dt-bindings: i2c: Add Mediatek MT8183 i2c binding

[Qii Wang]

Add MT8183 i2c binding to binding file. Compare to MT2712 i2c
controller, MT8183 has different registers, offsets, and clock.

Signed-off-by: Qii Wang 
---
 Documentation/devicetree/bindings/i2c/i2c-mtk.txt |5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/i2c/i2c-mtk.txt 
b/Documentation/devicetree/bindings/i2c/i2c-mtk.txt
index ee4c324..da2fa60 100644
--- a/Documentation/devicetree/bindings/i2c/i2c-mtk.txt
+++ b/Documentation/devicetree/bindings/i2c/i2c-mtk.txt
@@ -12,14 +12,15 @@ Required properties:
   "mediatek,mt7623-i2c", "mediatek,mt6577-i2c": for MediaTek MT7623
   "mediatek,mt7629-i2c", "mediatek,mt2712-i2c": for MediaTek MT7629
   "mediatek,mt8173-i2c": for MediaTek MT8173
+  "mediatek,mt8183-i2c": for MediaTek MT8183
   - reg: physical base address of the controller and dma base, length of memory
 mapped region.
   - interrupts: interrupt number to the cpu.
   - clock-div: the fixed value for frequency divider of clock source in i2c
 module. Each IC may be different.
   - clocks: clock name from clock manager
-  - clock-names: Must include "main" and "dma", if enable have-pmic need 
include
-"pmic" extra.
+  - clock-names: Must include "main" and "dma", "arb" is optional, if enable
+have-pmic need include "pmic" extra.
 
 Optional properties:
   - clock-frequency: Frequency in Hz of the bus when transfer, the default 
value
-- 
1.7.9.5

Re: [PATCH v2 -next] btrfs: Remove unnecessary casts in btrfs_read_root_item

[Dan Carpenter]

On Wed, Feb 20, 2019 at 12:32:02PM +, YueHaibing wrote:
> 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 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.
> 
> Suggested-by: Dan Carpenter 

It wasn't really suggested by me...  But I do think it's the right
thing.

Reviewed-by: Dan Carpenter 

regards,
dan carpenter

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

[syzbot]

syzbot has found a reproducer for 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=101e7fb0c0
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)
syz repro:  https://syzkaller.appspot.com/x/repro.syz?x=11a52778c0
C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=12a1007cc0

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: 7853, name: syz-executor140
no locks held by syz-executor140/7853.
CPU: 1 PID: 7853 Comm: syz-executor140 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:0x43ec58
Code: 00 00 be 3c 00 00 00 eb 19 66 0f 1f 84 00 00 00 00 00 48 89 d7 89 f0  
0f 05 48 3d 00 f0 ff ff 77 21 f4 48 89 d7 44 89 c0 0f 05 <48> 3d 00 f0 ff  
ff 76 e0 f7 d8 64 41 89 01 eb d8 0f 1f 84 00 00 00

RSP: 002b:7ffc2d0b2f48 EFLAGS: 0246 ORIG_RAX: 00e7
RAX: ffda RBX:  RCX: 0043ec58
RDX:  RSI: 000

[PATCH v2,0/7] Add Mediatek thermal dirver for mt8183

[michael.kao]

This patchset supports for mt8183 chip to mtk_thermal.c.
MT8183 has six temperature sensors and two thermal
controllers. It has different calibration coefficent with
past project, and doesn't need to select bank.
As a result, we add the common architecture for scalability.

change in v2:
1.Add fix tag of commit message to PATCH 1/7.
2.Change memery declaration of controller_base to PATCH 4/7.
3.Add module author to PATCH 7/7.

Michael Kao (7):
  thermal: mediatek: fix register index error
thermal: mediatek: add common index of vts settings.
thermal: mediatek: add calibration item
thermal: mediatek: add thermal controller offset
thermal: mediatek: add flag for bank selection
dt-bindings: thermal: add binding document for mt8183 thermal
  controller
thermal: mediatek: add support for MT8183

   .../bindings/thermal/mediatek-thermal.txt  |   1 +
drivers/thermal/mtk_thermal.c  | 316 
+
 2 files changed, 258 insertions(+), 59 deletions(-)

Re: [PATCH 1/3] iio: light: Add driver for ap3216c

[Jonathan Cameron]

On Mon, 18 Feb 2019 14:35:51 -0500
Sven Van Asbroeck  wrote:

> Hi Jonathan,
> 
> Thanks again for your clear and extensive feedback !
> 
> On Mon, Feb 18, 2019 at 10:16 AM Jonathan Cameron
>  wrote:
> >
> > I suspect that would break lots of devices if it happened, but
> > fair enough that explicit might be good.  One option would be
> > to document clearly in regmap the requirement that bulk read is ordered.
> >  
> 
> Yes, it would be interesting to hear the regmap people's opinion on ordering.
> In the mean time, we can make this explicit.
> Re-reading the thread, I can also see that Peter Meerwald-Stadler was first
> to spot this race condition.
> 
> > What we need to guarantee is:
> >
> > 1) If the sensor reads on an occasion where the threshold is passed, we do 
> > not miss the event
> >The event is the threshold being passed, not the existence of the 
> > reading, or how many
> >readings etc.
> >
> > 2) A data read will result in a value.  There is no guarantee that it will 
> > match with the
> >event.  All manner of delays could result in new data having occurred 
> > before that read.
> >  
> 
> My feedback was based on two incorrect assumptions:
> a. the interrupt fires whenever new PS/ALS values become available (wrong)
> b. there are strict consistency guarantees between the THRESH event, and what
> userspace will read out (also wrong)
> 
> Taking that into account, I am 100% in agreement with your other comments.
> Thank you so much for the explanation!
> 
> There is one exception, though:
> 
> > > +static int ap3216c_write_event_config(struct iio_dev *indio_dev,
> > > +const struct iio_chan_spec *chan,
> > > +enum iio_event_type type,
> > > +enum iio_event_direction dir, int 
> > > state)
> > > +{
> > > +   struct ap3216c_data *data = iio_priv(indio_dev);
> > > +
> > > +   switch (chan->type) {
> > > +   case IIO_LIGHT:
> > > +   data->als_thresh_en = state;
> > > +   return 0;
> > > +
> > > +   case IIO_PROXIMITY:
> > > +   data->prox_thresh_en = state;
> > > +   return 0;
> > > +
> > > +   default:
> > > +   return -EINVAL;
> > > +   }
> > > +static irqreturn_t ap3216c_event_handler(int irq, void *p)
> > > +{
> > > + if ((status & AP3216C_INT_STATUS_PS_MASK) && data->prox_thresh_en)
> > > + iio_push_event(...);
> > > +
> > >
> > > I think this may not work as intended. One thread (userspace) writes
> > > a variable, another thread (threaded irq handler) checks it. but there
> > > is no explicit or implicit memory barrier. So when userspace activates
> > > thresholding, it may take a long time for the handler to 'see' it !  
> >
> > Yes.  But if userspace took a while to get around to writing this value,
> > it would also take longer...  It's not time critical exactly when you
> > enable the event.  One can create cases where someone might
> > care, but they are pretty obscure.
> >  
> 
> Are you sure? I suspect that it's perfectly possible for the threaded irq
> handler not to 'see' the store to (als|prox)_thresh_en for a _very_ long time.

That is a serious - "in theory" circumstance.  The moment we hit any path at
all that results in a memory barrier it will see it.  Here its not critical
so we can wait.  In this case this is triggered by a userspace write.

Looks to me like that happens (I haven't checked that thoroughly) via
kernfs_fops_write which takes a mutex - so we have a barrier.

There are of course cases where multiple concurrent in kernel actions need
to be protected and need a memory barrier, but this doesn't look like one
of those to me.

> 
> AFAIK only a memory barrier will guarantee that the handler 'sees' the store
> right away. A lock will do - it issues an implicit memory barrier.
> 
> Most drivers use a lock to guarantee visibility. There are a few drivers that
> resort to explicit barriers to make a flag visible from one thread to another.

That's misleading. Most drivers use a lock to protect state against concurrent
inconsistent writes.  They don't take a lock because of it's memory barrier.
I have no objection to seeing one here as it's easier to know it is correct,
and the scope of lock can be nice and apparent.

> 
> E.g. search for mb() or wmb() in:
> drivers/input/keyboard/matrix_keypad.c
> drivers/input/misc/cm109.c
> drivers/input/misc/yealink.c

[PATCH v2,3/7] thermal: mediatek: add calibration item

[michael.kao]

From: Michael Kao 

Add calibration item in thermal_data to support
the project with different calibration coefficient.

Signed-off-by: Michael Kao 
---
 drivers/thermal/mtk_thermal.c | 19 ++-
 1 file changed, 18 insertions(+), 1 deletion(-)

diff --git a/drivers/thermal/mtk_thermal.c b/drivers/thermal/mtk_thermal.c
index 07f8ad7..45c6587 100644
--- a/drivers/thermal/mtk_thermal.c
+++ b/drivers/thermal/mtk_thermal.c
@@ -105,6 +105,9 @@
 /* The number of sensing points per bank */
 #define MT8173_NUM_SENSORS_PER_ZONE4
 
+/* The calibration coefficient of sensor  */
+#define MT8173_CALIBRATION 165
+
 /*
  * Layout of the fuses providing the calibration data
  * These macros could be used for MT8173, MT2701, and MT2712.
@@ -147,6 +150,9 @@ enum {
 /* The number of sensing points per bank */
 #define MT2701_NUM_SENSORS_PER_ZONE3
 
+/* The calibration coefficient of sensor  */
+#define MT2701_CALIBRATION 165
+
 /* MT2712 thermal sensors */
 #define MT2712_TS1 0
 #define MT2712_TS2 1
@@ -162,12 +168,18 @@ enum {
 /* The number of sensing points per bank */
 #define MT2712_NUM_SENSORS_PER_ZONE4
 
+/* The calibration coefficient of sensor  */
+#define MT2712_CALIBRATION 165
+
 #define MT7622_TEMP_AUXADC_CHANNEL 11
 #define MT7622_NUM_SENSORS 1
 #define MT7622_NUM_ZONES   1
 #define MT7622_NUM_SENSORS_PER_ZONE1
 #define MT7622_TS1 0
 
+/* The calibration coefficient of sensor  */
+#define MT7622_CALIBRATION 165
+
 struct mtk_thermal;
 
 struct thermal_bank_cfg {
@@ -188,6 +200,7 @@ struct mtk_thermal_data {
const int *sensor_mux_values;
const int *msr;
const int *adcpnp;
+   const int cali_val;
struct thermal_bank_cfg bank_data[];
 };
 
@@ -295,6 +308,7 @@ struct mtk_thermal {
.num_banks = MT8173_NUM_ZONES,
.num_sensors = MT8173_NUM_SENSORS,
.vts_index = mt8173_vts_index,
+   .cali_val = MT8173_CALIBRATION,
.bank_data = {
{
.num_sensors = 2,
@@ -330,6 +344,7 @@ struct mtk_thermal {
.num_banks = 1,
.num_sensors = MT2701_NUM_SENSORS,
.vts_index = mt2701_vts_index,
+   .cali_val = MT2701_CALIBRATION,
.bank_data = {
{
.num_sensors = 3,
@@ -356,6 +371,7 @@ struct mtk_thermal {
.num_banks = 1,
.num_sensors = MT2712_NUM_SENSORS,
.vts_index = mt2712_vts_index,
+   .cali_val = MT2712_CALIBRATION,
.bank_data = {
{
.num_sensors = 4,
@@ -376,6 +392,7 @@ struct mtk_thermal {
.num_banks = MT7622_NUM_ZONES,
.num_sensors = MT7622_NUM_SENSORS,
.vts_index = mt7622_vts_index,
+   .cali_val = MT7622_CALIBRATION,
.bank_data = {
{
.num_sensors = 1,
@@ -402,7 +419,7 @@ static int raw_to_mcelsius(struct mtk_thermal *mt, int 
sensno, s32 raw)
raw &= 0xfff;
 
tmp = 203450520 << 3;
-   tmp /= 165 + mt->o_slope;
+   tmp /= mt->conf->cali_val + mt->o_slope;
tmp /= 1 + mt->adc_ge;
tmp *= raw - mt->vts[sensno] - 3350;
tmp >>= 3;
-- 
1.9.1

[PATCH v2,5/7] thermal: mediatek: add flag for bank selection

[michael.kao]

From: Michael Kao 

For past ic designs, the thermal controller should select banks before
reading the thermal sensor.
And the new ic design architecture removes this mechanism.

Signed-off-by: Michael Kao 
---
 drivers/thermal/mtk_thermal.c | 20 ++--
 1 file changed, 14 insertions(+), 6 deletions(-)

diff --git a/drivers/thermal/mtk_thermal.c b/drivers/thermal/mtk_thermal.c
index c96a746..0a3944e 100644
--- a/drivers/thermal/mtk_thermal.c
+++ b/drivers/thermal/mtk_thermal.c
@@ -213,6 +213,7 @@ struct mtk_thermal_data {
const int cali_val;
const int num_controller;
const int *controller_offset;
+   bool need_switch_bank;
struct thermal_bank_cfg bank_data[];
 };
 
@@ -327,6 +328,7 @@ struct mtk_thermal {
.cali_val = MT8173_CALIBRATION,
.num_controller = MT8173_NUM_CONTROLLER,
.controller_offset = mt8173_tc_offset,
+   .need_switch_bank = true,
.bank_data = {
{
.num_sensors = 2,
@@ -365,6 +367,7 @@ struct mtk_thermal {
.cali_val = MT2701_CALIBRATION,
.num_controller = MT2701_NUM_CONTROLLER,
.controller_offset = mt2701_tc_offset,
+   .need_switch_bank = true,
.bank_data = {
{
.num_sensors = 3,
@@ -394,6 +397,7 @@ struct mtk_thermal {
.cali_val = MT2712_CALIBRATION,
.num_controller = MT2712_NUM_CONTROLLER,
.controller_offset = mt2712_tc_offset,
+   .need_switch_bank = true,
.bank_data = {
{
.num_sensors = 4,
@@ -417,6 +421,7 @@ struct mtk_thermal {
.cali_val = MT7622_CALIBRATION,
.num_controller = MT7622_NUM_CONTROLLER,
.controller_offset = mt7622_tc_offset,
+   .need_switch_bank = true,
.bank_data = {
{
.num_sensors = 1,
@@ -463,12 +468,14 @@ static void mtk_thermal_get_bank(struct mtk_thermal_bank 
*bank)
struct mtk_thermal *mt = bank->mt;
u32 val;
 
-   mutex_lock(>lock);
+   if (mt->conf->need_switch_bank) {
+   mutex_lock(>lock);
 
-   val = readl(mt->thermal_base + PTPCORESEL);
-   val &= ~0xf;
-   val |= bank->id;
-   writel(val, mt->thermal_base + PTPCORESEL);
+   val = readl(mt->thermal_base + PTPCORESEL);
+   val &= ~0xf;
+   val |= bank->id;
+   writel(val, mt->thermal_base + PTPCORESEL);
+   }
 }
 
 /**
@@ -481,7 +488,8 @@ static void mtk_thermal_put_bank(struct mtk_thermal_bank 
*bank)
 {
struct mtk_thermal *mt = bank->mt;
 
-   mutex_unlock(>lock);
+   if (mt->conf->need_switch_bank)
+   mutex_unlock(>lock);
 }
 
 /**
-- 
1.9.1

[PATCH v2,6/7] dt-bindings: thermal: add binding document for mt8183 thermal controller

[michael.kao]

From: Michael Kao 

This patch adds binding document for mt8183 thermal controller.

Signed-off-by: Michael Kao 
---
 Documentation/devicetree/bindings/thermal/mediatek-thermal.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/thermal/mediatek-thermal.txt 
b/Documentation/devicetree/bindings/thermal/mediatek-thermal.txt
index 41d6a44..f8d7831 100644
--- a/Documentation/devicetree/bindings/thermal/mediatek-thermal.txt
+++ b/Documentation/devicetree/bindings/thermal/mediatek-thermal.txt
@@ -13,6 +13,7 @@ Required properties:
   - "mediatek,mt2701-thermal" : For MT2701 family of SoCs
   - "mediatek,mt2712-thermal" : For MT2712 family of SoCs
   - "mediatek,mt7622-thermal" : For MT7622 SoC
+  - "mediatek,mt8183-thermal" : For MT8183 family of SoCs
 - reg: Address range of the thermal controller
 - interrupts: IRQ for the thermal controller
 - clocks, clock-names: Clocks needed for the thermal controller. required
-- 
1.9.1

[PATCH v2,1/7] thermal: mediatek: fix register index error

[michael.kao]

From: Michael Kao 

The index of msr and adcpnp should match the sensor
which belongs to the selected bank in the for loop.

Fixes: b7cf0053738c ("thermal: Add Mediatek thermal driver for mt2701.")

Signed-off-by: Michael Kao 
---
 drivers/thermal/mtk_thermal.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/thermal/mtk_thermal.c b/drivers/thermal/mtk_thermal.c
index 0691f26..f646436 100644
--- a/drivers/thermal/mtk_thermal.c
+++ b/drivers/thermal/mtk_thermal.c
@@ -431,7 +431,8 @@ static int mtk_thermal_bank_temperature(struct 
mtk_thermal_bank *bank)
u32 raw;
 
for (i = 0; i < conf->bank_data[bank->id].num_sensors; i++) {
-   raw = readl(mt->thermal_base + conf->msr[i]);
+   raw = readl(mt->thermal_base +
+   conf->msr[conf->bank_data[bank->id].sensors[i]]);
 
temp = raw_to_mcelsius(mt,
   conf->bank_data[bank->id].sensors[i],
@@ -568,7 +569,8 @@ static void mtk_thermal_init_bank(struct mtk_thermal *mt, 
int num,
 
for (i = 0; i < conf->bank_data[num].num_sensors; i++)
writel(conf->sensor_mux_values[conf->bank_data[num].sensors[i]],
-  mt->thermal_base + conf->adcpnp[i]);
+  mt->thermal_base +
+  conf->adcpnp[conf->bank_data[num].sensors[i]]);
 
writel((1 << conf->bank_data[num].num_sensors) - 1,
   mt->thermal_base + TEMP_MONCTL0);
-- 
1.9.1

[PATCH v2,7/7] thermal: mediatek: add support for MT8183

[michael.kao]

From: Michael Kao 

MT8183 has two built-in thermal controllers with total six thermal
sensors. And it doesn't have bank, so doesn't need to select bank.
This patch adds support for mt8183.

Signed-off-by: Michael Kao 
---
 drivers/thermal/mtk_thermal.c | 99 ++-
 1 file changed, 98 insertions(+), 1 deletion(-)

diff --git a/drivers/thermal/mtk_thermal.c b/drivers/thermal/mtk_thermal.c
index 0a3944e..5c07a61 100644
--- a/drivers/thermal/mtk_thermal.c
+++ b/drivers/thermal/mtk_thermal.c
@@ -71,6 +71,15 @@
 
 #define TEMP_SPARE00x0f0
 
+#define TEMP_ADCPNP0_1  0x148
+#define TEMP_ADCPNP1_1  0x14c
+#define TEMP_ADCPNP2_1  0x150
+#define TEMP_MSR0_1 0x190
+#define TEMP_MSR1_1 0x194
+#define TEMP_MSR2_1 0x198
+#define TEMP_ADCPNP3_1  0x1b4
+#define TEMP_MSR3_1 0x1B8
+
 #define PTPCORESEL 0x400
 
 #define TEMP_MONCTL1_PERIOD_UNIT(x)((x) & 0x3ff)
@@ -113,7 +122,8 @@
 
 /*
  * Layout of the fuses providing the calibration data
- * These macros could be used for MT8173, MT2701, and MT2712.
+ * These macros could be used for MT8183, MT8173, MT2701, and MT2712.
+ * MT8183 has 6 sensors and needs 6 VTS calibration data.
  * MT8173 has 5 sensors and needs 5 VTS calibration data.
  * MT2701 has 3 sensors and needs 3 VTS calibration data.
  * MT2712 has 4 sensors and needs 4 VTS calibration data.
@@ -124,6 +134,7 @@
 #define CALIB_BUF0_VTS_TS2(x)  (((x) >> 8) & 0x1ff)
 #define CALIB_BUF1_VTS_TS3(x)  (((x) >> 0) & 0x1ff)
 #define CALIB_BUF2_VTS_TS4(x)  (((x) >> 23) & 0x1ff)
+#define CALIB_BUF2_VTS_TS5(x)  (((x) >> 5) & 0x1ff)
 #define CALIB_BUF2_VTS_TSABB(x)(((x) >> 14) & 0x1ff)
 #define CALIB_BUF0_DEGC_CALI(x)(((x) >> 1) & 0x3f)
 #define CALIB_BUF0_O_SLOPE(x)  (((x) >> 26) & 0x3f)
@@ -135,6 +146,7 @@ enum {
VTS2,
VTS3,
VTS4,
+   VTS5,
VTSABB,
MAX_NUM_VTS,
 };
@@ -190,6 +202,29 @@ enum {
 /* The calibration coefficient of sensor  */
 #define MT7622_CALIBRATION 165
 
+/* MT8183 thermal sensors */
+#define MT8183_TS1 0
+#define MT8183_TS2 1
+#define MT8183_TS3 2
+#define MT8183_TS4 3
+#define MT8183_TS5 4
+#define MT8183_TSABB   5
+
+/* AUXADC channel  is used for the temperature sensors */
+#define MT8183_TEMP_AUXADC_CHANNEL 11
+
+/* The total number of temperature sensors in the MT8183 */
+#define MT8183_NUM_SENSORS 6
+
+/* The number of sensing points per bank */
+#define MT8183_NUM_SENSORS_PER_ZONE 6
+
+/* The number of controller in the MT8183 */
+#define MT8183_NUM_CONTROLLER  2
+
+/* The calibration coefficient of sensor  */
+#define MT8183_CALIBRATION 153
+
 struct mtk_thermal;
 
 struct thermal_bank_cfg {
@@ -236,6 +271,27 @@ struct mtk_thermal {
struct mtk_thermal_bank banks[];
 };
 
+/* MT8183 thermal sensor data */
+static const int mt8183_bank_data[MT8183_NUM_SENSORS] = {
+   MT8183_TS1, MT8183_TS2, MT8183_TS3, MT8183_TS4, MT8183_TS5, MT8183_TSABB
+};
+
+static const int mt8183_msr[MT8183_NUM_SENSORS_PER_ZONE] = {
+   TEMP_MSR0_1, TEMP_MSR1_1, TEMP_MSR2_1, TEMP_MSR1, TEMP_MSR0, TEMP_MSR3_1
+};
+
+static const int mt8183_adcpnp[MT8183_NUM_SENSORS_PER_ZONE] = {
+   TEMP_ADCPNP0_1, TEMP_ADCPNP1_1, TEMP_ADCPNP2_1,
+   TEMP_ADCPNP1, TEMP_ADCPNP0, TEMP_ADCPNP3_1
+};
+
+static const int mt8183_mux_values[MT8183_NUM_SENSORS] = { 0, 1, 2, 3, 4, 0 };
+static const int mt8183_tc_offset[MT8183_NUM_CONTROLLER] = {0x0, 0x100};
+
+static const int mt8183_vts_index[MT8183_NUM_SENSORS] = {
+   VTS1, VTS2, VTS3, VTS4, VTS5, VTSABB
+};
+
 /* MT8173 thermal sensor data */
 static const int mt8173_bank_data[MT8173_NUM_ZONES][3] = {
{ MT8173_TS2, MT8173_TS3 },
@@ -434,6 +490,39 @@ struct mtk_thermal {
 };
 
 /**
+ * The MT8183 thermal controller has one bank for the current SW framework.
+ * The MT8183 has a total of 6 temperature sensors.
+ * There are two thermal controller to control the six sensor.
+ * The first one bind 2 sensor, and the other bind 4 sensors.
+ * The thermal core only gets the maximum temperature of all sensor, so
+ * the bank concept wouldn't be necessary here. However, the SVS (Smart
+ * Voltage Scaling) unit makes its decisions based on the same bank
+ * data, and this indeed needs the temperatures of the individual banks
+ * for making better decisions.
+ */
+
+static const struct mtk_thermal_data mt8183_thermal_data = {
+   .auxadc_channel = MT8183_TEMP_AUXADC_CHANNEL,
+   .num_banks = MT8183_NUM_SENSORS_PER_ZONE,
+   .num_sensors = MT8183_NUM_SENSORS,
+   .vts_index = mt8183_vts_index,
+   .cali_val = MT8183_CALIBRATION,
+   .num_controller = MT8183_NUM_CONTROLLER,
+   .controller_offset = mt8183_tc_offset,
+   .need_switch_bank = false,
+   .bank_data = {
+   {
+   .num_sensors = 6,
+ 

[PATCH v2,2/7] thermal: mediatek: add common index of vts settings.

[michael.kao]

From: Michael Kao 

Each project has different number of vts settings.
For the MT2701 just have to set three vts, but the
original code flow add five unnecessary vts.
Add common index of vts settings for scalablity,
and reduce the setting of unnecessary vts.

Signed-off-by: Michael Kao 
---
 drivers/thermal/mtk_thermal.c | 93 ---
 1 file changed, 69 insertions(+), 24 deletions(-)

diff --git a/drivers/thermal/mtk_thermal.c b/drivers/thermal/mtk_thermal.c
index f646436..07f8ad7 100644
--- a/drivers/thermal/mtk_thermal.c
+++ b/drivers/thermal/mtk_thermal.c
@@ -112,17 +112,26 @@
  * MT2701 has 3 sensors and needs 3 VTS calibration data.
  * MT2712 has 4 sensors and needs 4 VTS calibration data.
  */
-#define MT8173_CALIB_BUF0_VALIDBIT(0)
-#define MT8173_CALIB_BUF1_ADC_GE(x)(((x) >> 22) & 0x3ff)
-#define MT8173_CALIB_BUF0_VTS_TS1(x)   (((x) >> 17) & 0x1ff)
-#define MT8173_CALIB_BUF0_VTS_TS2(x)   (((x) >> 8) & 0x1ff)
-#define MT8173_CALIB_BUF1_VTS_TS3(x)   (((x) >> 0) & 0x1ff)
-#define MT8173_CALIB_BUF2_VTS_TS4(x)   (((x) >> 23) & 0x1ff)
-#define MT8173_CALIB_BUF2_VTS_TSABB(x) (((x) >> 14) & 0x1ff)
-#define MT8173_CALIB_BUF0_DEGC_CALI(x) (((x) >> 1) & 0x3f)
-#define MT8173_CALIB_BUF0_O_SLOPE(x)   (((x) >> 26) & 0x3f)
-#define MT8173_CALIB_BUF0_O_SLOPE_SIGN(x)  (((x) >> 7) & 0x1)
-#define MT8173_CALIB_BUF1_ID(x)(((x) >> 9) & 0x1)
+#define CALIB_BUF0_VALID   BIT(0)
+#define CALIB_BUF1_ADC_GE(x)   (((x) >> 22) & 0x3ff)
+#define CALIB_BUF0_VTS_TS1(x)  (((x) >> 17) & 0x1ff)
+#define CALIB_BUF0_VTS_TS2(x)  (((x) >> 8) & 0x1ff)
+#define CALIB_BUF1_VTS_TS3(x)  (((x) >> 0) & 0x1ff)
+#define CALIB_BUF2_VTS_TS4(x)  (((x) >> 23) & 0x1ff)
+#define CALIB_BUF2_VTS_TSABB(x)(((x) >> 14) & 0x1ff)
+#define CALIB_BUF0_DEGC_CALI(x)(((x) >> 1) & 0x3f)
+#define CALIB_BUF0_O_SLOPE(x)  (((x) >> 26) & 0x3f)
+#define CALIB_BUF0_O_SLOPE_SIGN(x) (((x) >> 7) & 0x1)
+#define CALIB_BUF1_ID(x)   (((x) >> 9) & 0x1)
+
+enum {
+   VTS1,
+   VTS2,
+   VTS3,
+   VTS4,
+   VTSABB,
+   MAX_NUM_VTS,
+};
 
 /* MT2701 thermal sensors */
 #define MT2701_TS1 0
@@ -175,6 +184,7 @@ struct mtk_thermal_data {
s32 num_banks;
s32 num_sensors;
s32 auxadc_channel;
+   const int *vts_index;
const int *sensor_mux_values;
const int *msr;
const int *adcpnp;
@@ -194,7 +204,7 @@ struct mtk_thermal {
s32 adc_ge;
s32 degc_cali;
s32 o_slope;
-   s32 vts[MT8173_NUM_SENSORS];
+   s32 vts[MAX_NUM_VTS];
 
const struct mtk_thermal_data *conf;
struct mtk_thermal_bank banks[];
@@ -218,6 +228,10 @@ struct mtk_thermal {
 
 static const int mt8173_mux_values[MT8173_NUM_SENSORS] = { 0, 1, 2, 3, 16 };
 
+static const int mt8173_vts_index[MT8173_NUM_SENSORS] = {
+   VTS1, VTS2, VTS3, VTS4, VTSABB
+};
+
 /* MT2701 thermal sensor data */
 static const int mt2701_bank_data[MT2701_NUM_SENSORS] = {
MT2701_TS1, MT2701_TS2, MT2701_TSABB
@@ -233,6 +247,10 @@ struct mtk_thermal {
 
 static const int mt2701_mux_values[MT2701_NUM_SENSORS] = { 0, 1, 16 };
 
+static const int mt2701_vts_index[MT2701_NUM_SENSORS] = {
+   VTS1, VTS2, VTS3
+};
+
 /* MT2712 thermal sensor data */
 static const int mt2712_bank_data[MT2712_NUM_SENSORS] = {
MT2712_TS1, MT2712_TS2, MT2712_TS3, MT2712_TS4
@@ -248,11 +266,16 @@ struct mtk_thermal {
 
 static const int mt2712_mux_values[MT2712_NUM_SENSORS] = { 0, 1, 2, 3 };
 
+static const int mt2712_vts_index[MT2712_NUM_SENSORS] = {
+   VTS1, VTS2, VTS3, VTS4
+};
+
 /* MT7622 thermal sensor data */
 static const int mt7622_bank_data[MT7622_NUM_SENSORS] = { MT7622_TS1, };
 static const int mt7622_msr[MT7622_NUM_SENSORS_PER_ZONE] = { TEMP_MSR0, };
 static const int mt7622_adcpnp[MT7622_NUM_SENSORS_PER_ZONE] = { TEMP_ADCPNP0, 
};
 static const int mt7622_mux_values[MT7622_NUM_SENSORS] = { 0, };
+static const int mt7622_vts_index[MT7622_NUM_SENSORS] = { VTS1 };
 
 /**
  * The MT8173 thermal controller has four banks. Each bank can read up to
@@ -271,6 +294,7 @@ struct mtk_thermal {
.auxadc_channel = MT8173_TEMP_AUXADC_CHANNEL,
.num_banks = MT8173_NUM_ZONES,
.num_sensors = MT8173_NUM_SENSORS,
+   .vts_index = mt8173_vts_index,
.bank_data = {
{
.num_sensors = 2,
@@ -305,6 +329,7 @@ struct mtk_thermal {
.auxadc_channel = MT2701_TEMP_AUXADC_CHANNEL,
.num_banks = 1,
.num_sensors = MT2701_NUM_SENSORS,
+   .vts_index = mt2701_vts_index,
.bank_data = {
{
.num_sensors = 3,
@@ -330,6 +355,7 @@ struct mtk_thermal {
.auxadc_channel = MT2712_TEMP_AUXADC_CHANNEL,
.num_banks = 1,
.num_sensors = MT2712_NUM_SENSORS,
+   .vts_index = mt2712_vts_index,
.bank_data = {
   

[PATCH v2,4/7] thermal: mediatek: add thermal controller offset

[michael.kao]

From: Michael Kao 

One thermal controller can read four sensors at most,
so we need to add controller_offset for the project with
more than four sensors to reuse the same register settings.

Signed-off-by: Michael Kao 
---
 drivers/thermal/mtk_thermal.c | 79 +--
 1 file changed, 54 insertions(+), 25 deletions(-)

diff --git a/drivers/thermal/mtk_thermal.c b/drivers/thermal/mtk_thermal.c
index 45c6587..c96a746 100644
--- a/drivers/thermal/mtk_thermal.c
+++ b/drivers/thermal/mtk_thermal.c
@@ -105,6 +105,9 @@
 /* The number of sensing points per bank */
 #define MT8173_NUM_SENSORS_PER_ZONE4
 
+/* The number of controller in the MT8173 */
+#define MT8173_NUM_CONTROLLER  1
+
 /* The calibration coefficient of sensor  */
 #define MT8173_CALIBRATION 165
 
@@ -150,6 +153,9 @@ enum {
 /* The number of sensing points per bank */
 #define MT2701_NUM_SENSORS_PER_ZONE3
 
+/* The number of controller in the MT2701 */
+#define MT2701_NUM_CONTROLLER  1
+
 /* The calibration coefficient of sensor  */
 #define MT2701_CALIBRATION 165
 
@@ -168,6 +174,9 @@ enum {
 /* The number of sensing points per bank */
 #define MT2712_NUM_SENSORS_PER_ZONE4
 
+/* The number of controller in the MT2712 */
+#define MT2712_NUM_CONTROLLER  1
+
 /* The calibration coefficient of sensor  */
 #define MT2712_CALIBRATION 165
 
@@ -176,6 +185,7 @@ enum {
 #define MT7622_NUM_ZONES   1
 #define MT7622_NUM_SENSORS_PER_ZONE1
 #define MT7622_TS1 0
+#define MT7622_NUM_CONTROLLER  1
 
 /* The calibration coefficient of sensor  */
 #define MT7622_CALIBRATION 165
@@ -201,6 +211,8 @@ struct mtk_thermal_data {
const int *msr;
const int *adcpnp;
const int cali_val;
+   const int num_controller;
+   const int *controller_offset;
struct thermal_bank_cfg bank_data[];
 };
 
@@ -240,6 +252,7 @@ struct mtk_thermal {
 };
 
 static const int mt8173_mux_values[MT8173_NUM_SENSORS] = { 0, 1, 2, 3, 16 };
+static const int mt8173_tc_offset[MT8173_NUM_CONTROLLER] = { 0x0, };
 
 static const int mt8173_vts_index[MT8173_NUM_SENSORS] = {
VTS1, VTS2, VTS3, VTS4, VTSABB
@@ -259,6 +272,7 @@ struct mtk_thermal {
 };
 
 static const int mt2701_mux_values[MT2701_NUM_SENSORS] = { 0, 1, 16 };
+static const int mt2701_tc_offset[MT2701_NUM_CONTROLLER] = { 0x0, };
 
 static const int mt2701_vts_index[MT2701_NUM_SENSORS] = {
VTS1, VTS2, VTS3
@@ -278,6 +292,7 @@ struct mtk_thermal {
 };
 
 static const int mt2712_mux_values[MT2712_NUM_SENSORS] = { 0, 1, 2, 3 };
+static const int mt2712_tc_offset[MT2712_NUM_CONTROLLER] = { 0x0, };
 
 static const int mt2712_vts_index[MT2712_NUM_SENSORS] = {
VTS1, VTS2, VTS3, VTS4
@@ -289,6 +304,7 @@ struct mtk_thermal {
 static const int mt7622_adcpnp[MT7622_NUM_SENSORS_PER_ZONE] = { TEMP_ADCPNP0, 
};
 static const int mt7622_mux_values[MT7622_NUM_SENSORS] = { 0, };
 static const int mt7622_vts_index[MT7622_NUM_SENSORS] = { VTS1 };
+static const int mt7622_tc_offset[MT7622_NUM_CONTROLLER] = { 0x0, };
 
 /**
  * The MT8173 thermal controller has four banks. Each bank can read up to
@@ -309,6 +325,8 @@ struct mtk_thermal {
.num_sensors = MT8173_NUM_SENSORS,
.vts_index = mt8173_vts_index,
.cali_val = MT8173_CALIBRATION,
+   .num_controller = MT8173_NUM_CONTROLLER,
+   .controller_offset = mt8173_tc_offset,
.bank_data = {
{
.num_sensors = 2,
@@ -345,6 +363,8 @@ struct mtk_thermal {
.num_sensors = MT2701_NUM_SENSORS,
.vts_index = mt2701_vts_index,
.cali_val = MT2701_CALIBRATION,
+   .num_controller = MT2701_NUM_CONTROLLER,
+   .controller_offset = mt2701_tc_offset,
.bank_data = {
{
.num_sensors = 3,
@@ -372,6 +392,8 @@ struct mtk_thermal {
.num_sensors = MT2712_NUM_SENSORS,
.vts_index = mt2712_vts_index,
.cali_val = MT2712_CALIBRATION,
+   .num_controller = MT2712_NUM_CONTROLLER,
+   .controller_offset = mt2712_tc_offset,
.bank_data = {
{
.num_sensors = 4,
@@ -393,6 +415,8 @@ struct mtk_thermal {
.num_sensors = MT7622_NUM_SENSORS,
.vts_index = mt7622_vts_index,
.cali_val = MT7622_CALIBRATION,
+   .num_controller = MT7622_NUM_CONTROLLER,
+   .controller_offset = mt7622_tc_offset,
.bank_data = {
{
.num_sensors = 1,
@@ -523,19 +547,23 @@ static int mtk_read_temp(void *data, int *temperature)
 };
 
 static void mtk_thermal_init_bank(struct mtk_thermal *mt, int num,
- u32 apmixed_phys_base, u32 auxadc_phys_base)
+ u32 apmixed_phys_base, u32 auxadc_phys_base,
+ int ctrl_id)
 {
struct mtk_thermal_bank *bank = >banks[num];
const struct mtk_thermal_data *conf = 

Re: [PATCH] cpufreq: kyro: Reduce frame-size of qcom_cpufreq_kryo_probe()

[Arnd Bergmann]

On Wed, Feb 20, 2019 at 12:14 PM Viresh Kumar  wrote:
>
> With the introduction of commit 846a415bf440 ("arm64: default NR_CPUS to
> 256"), we have started getting following compilation warning:
>
> qcom-cpufreq-kryo.c:168:1: warning: the frame size of 2160 bytes is larger 
> than 2048 bytes [-Wframe-larger-than=]
>
> Fix that by dynamically allocating opp_tables and freeing it later.
>
> Compile tested only.
>
> Signed-off-by: Viresh Kumar 

Looks good to me, thanks for the fix!

Reviewed-by: Arnd Bergmann 

[PATCH 5/6] perf tools: Increase debug leve for cpu_map__snprint verbose output

[Jiri Olsa]

So it does not screw up single -v verbose output.

Link: http://lkml.kernel.org/n/tip-4ucm1kfmy1xwp9w8xohdz...@git.kernel.org
Signed-off-by: Jiri Olsa 
---
 tools/perf/util/cpumap.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/perf/util/cpumap.c b/tools/perf/util/cpumap.c
index 0bbc3feb0894..0b599229bc7e 100644
--- a/tools/perf/util/cpumap.c
+++ b/tools/perf/util/cpumap.c
@@ -681,7 +681,7 @@ size_t cpu_map__snprint(struct cpu_map *map, char *buf, 
size_t size)
 
 #undef COMMA
 
-   pr_debug("cpumask list: %s\n", buf);
+   pr_debug2("cpumask list: %s\n", buf);
return ret;
 }
 
-- 
2.17.2

[PATCH 3/6] perf script: Allow +- operator for type specific fields option

[Jiri Olsa]

Adding support to add/remove fields for specific event types
in -F option.  It's now possible to use '+-' after event type,
like:

  # cat > test.c
  #include 

  int main(void)
  {
 printf("Hello world\n");
 while(1) {}
  }
  ^D
  # gcc -g -o test test.c
  # perf probe -x test 'test.c:5'
  # perf record -e '{cpu/cpu-cycles,period=1/,probe_test:main}:S' ./test
  ...

  # perf script -Ftrace:+period,-cpu
test  3859 396291.117343:  10275 cpu/cpu-cycles,period=1/:  
7f..
test  3859 396291.118234:  11041 cpu/cpu-cycles,period=1/:  
ff..
test  3859 396291.118234:  1  probe_test:main:
test  3859 396291.118248:   8668 cpu/cpu-cycles,period=1/:  
ff..
test  3859 396291.118263:  10139 cpu/cpu-cycles,period=1/:  
ff..

Link: http://lkml.kernel.org/n/tip-gpd58vbcgsk4zx041zwl8...@git.kernel.org
Signed-off-by: Jiri Olsa 
---
 tools/perf/Documentation/perf-script.txt | 6 ++
 tools/perf/builtin-script.c  | 8 
 2 files changed, 14 insertions(+)

diff --git a/tools/perf/Documentation/perf-script.txt 
b/tools/perf/Documentation/perf-script.txt
index 9e4def08d569..2e19fd7ffe35 100644
--- a/tools/perf/Documentation/perf-script.txt
+++ b/tools/perf/Documentation/perf-script.txt
@@ -159,6 +159,12 @@ OPTIONS
the override, and the result of the above is that only S/W and H/W
events are displayed with the given fields.
 
+   It's possible tp add/remove fields only for specific event type:
+
+   -Fsw:-cpu,-period
+
+   removes cpu and period from software events.
+
For the 'wildcard' option if a user selected field is invalid for an
event type, a message is displayed to the user that the option is
ignored for that type. For example:
diff --git a/tools/perf/builtin-script.c b/tools/perf/builtin-script.c
index 8d5fe092525c..373ea151dc60 100644
--- a/tools/perf/builtin-script.c
+++ b/tools/perf/builtin-script.c
@@ -2560,6 +2560,10 @@ static int parse_output_fields(const struct option *opt 
__maybe_unused,
pr_warning("Overriding previous field request for %s 
events.\n",
   event_type(type));
 
+   /* Don't override defaults for +- */
+   if (strchr(tok, '+') || strchr(tok, '-'))
+   goto parse;
+
output[type].fields = 0;
output[type].user_set = true;
output[type].wildcard_set = false;
@@ -2644,6 +2648,10 @@ static int parse_output_fields(const struct option *opt 
__maybe_unused,
rc = -EINVAL;
goto out;
}
+   if (change == REMOVE)
+   output[type].fields &= 
~all_output_options[i].field;
+   else
+   output[type].fields |= 
all_output_options[i].field;
output[type].user_set = true;
output[type].wildcard_set = true;
}
-- 
2.17.2

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

[Arnd Bergmann]

On Wed, Feb 20, 2019 at 12:27 PM Sugaya, Taichi
 wrote:
>
> Hi
>
> On 2019/02/20 18:28, Arnd Bergmann wrote:
> > 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.
> >
>
> I got it, I use the output of 'make savedefconfig'.
> One question, is that OK to add some options on it?
>   -Because "CONFIG_ARCH_MILBEAUT" was not listed.

What I'd do here is to apply all the patches you want to get merged in
the next few releases before running 'savedefconfig' and use the output
of that.

If you already know that you will need the options, including
them now means you don't have to update the defconfig file
as much in the future.

> >> 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?
> >
>
> Yes, but not exactly.
> The series has not serial driver, so I add the driver temporarily and
> confirm the boot log through earlycon.
> The timer driver is selected by "CONFIG_ARCH_MILBEAUT_M10V", no need to
> add the the"CONFIG_MILBEAUT_TIMER".
>
> Here one more question.
> Is this OK to submit a core support patch without any serial drivers?

Yes, we are fairly flexible here. Greg also mentioned in the past that he's
fine with having us merge the serial driver through the arm-soc tree after
it has been reviewed, to keep it together with the platform support, same
thing for the clk, pinctrl, clocksource and irqchip drivers.

However, once the platform support is merged, we prefer that you do
any other driver changes (including newly added drivers) through the
subsystem trees.

  Arnd

[PATCH 1/6] perf tools: Don't report zero period samples for slave events

[Jiri Olsa]

There's no reason to deliver sample for zero period.
It means there was no value for slave event since its
last group leader sample.

Link: http://lkml.kernel.org/n/tip-d5he0papol5dhwvfq33es...@git.kernel.org
Signed-off-by: Jiri Olsa 
---
 tools/perf/util/session.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/tools/perf/util/session.c b/tools/perf/util/session.c
index 18fb9c8cbf9c..c764bbc91009 100644
--- a/tools/perf/util/session.c
+++ b/tools/perf/util/session.c
@@ -1202,6 +1202,13 @@ static int deliver_sample_value(struct perf_evlist 
*evlist,
return 0;
}
 
+   /*
+* There's no reason to deliver sample
+* for zero period, bail out.
+*/
+   if (!sample->period)
+   return 0;
+
return tool->sample(tool, event, sample, sid->evsel, machine);
 }
 
-- 
2.17.2

[PATCH 0/6] perf tools: Assorted fixes

[Jiri Olsa]

hi,
sending assorted general fixes that queued
up in my other branches.

Also available in here:
  https://git.kernel.org/pub/scm/linux/kernel/git/jolsa/perf.git
  perf/fixes

thanks,
jirka


---
Jiri Olsa (6):
  perf tools: Don't report zero period samples for slave events
  perf tools: Force sample_type for slave events
  perf script: Allow +- operator for type specific fields option
  perf tools: Add missing new line into pr_debug call
  perf tools: Increase debug leve for cpu_map__snprint verbose output
  perf tools: Make rm_rf to remove single file

 tools/perf/Documentation/perf-script.txt |  6 ++
 tools/perf/builtin-script.c  |  8 
 tools/perf/util/bpf-event.c  |  2 +-
 tools/perf/util/cpumap.c |  2 +-
 tools/perf/util/evsel.c  |  8 
 tools/perf/util/session.c|  7 +++
 tools/perf/util/util.c   | 16 +---
 7 files changed, 44 insertions(+), 5 deletions(-)

[PATCH 6/6] perf tools: Make rm_rf to remove single file

[Jiri Olsa]

Let rm_rf remove file if it's provided by path.

Cc: Alexey Budankov 
Link: http://lkml.kernel.org/n/tip-whhp3ej5795l9dc86xfyy...@git.kernel.org
Signed-off-by: Jiri Olsa 
---
 tools/perf/util/util.c | 16 +---
 1 file changed, 13 insertions(+), 3 deletions(-)

diff --git a/tools/perf/util/util.c b/tools/perf/util/util.c
index 320b0fef249a..3ee410fc047a 100644
--- a/tools/perf/util/util.c
+++ b/tools/perf/util/util.c
@@ -120,16 +120,26 @@ int mkdir_p(char *path, mode_t mode)
 int rm_rf(const char *path)
 {
DIR *dir;
-   int ret = 0;
+   int ret;
struct dirent *d;
char namebuf[PATH_MAX];
+   struct stat statbuf;
 
+   /* Do not fail if there's no file. */
+   ret = lstat(path, );
+   if (ret)
+   return 0;
+
+   /* Try to remove any file we get. */
+   if (!(statbuf.st_mode & S_IFDIR))
+   return unlink(path);
+
+   /* We have directory in path. */
dir = opendir(path);
if (dir == NULL)
-   return 0;
+   return -1;
 
while ((d = readdir(dir)) != NULL && !ret) {
-   struct stat statbuf;
 
if (!strcmp(d->d_name, ".") || !strcmp(d->d_name, ".."))
continue;
-- 
2.17.2

[PATCH 4/6] perf tools: Add missing new line into pr_debug call

[Jiri Olsa]

Adding missing new line into pr_debug call in
perf_event__synthesize_bpf_events function,
so the error message does not screw the verbose
output.

Link: http://lkml.kernel.org/n/tip-z9h6x8v1mef0iqsfx6m28...@git.kernel.org
Signed-off-by: Jiri Olsa 
---
 tools/perf/util/bpf-event.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/perf/util/bpf-event.c b/tools/perf/util/bpf-event.c
index 62dda96b0096..028c8ec1f62a 100644
--- a/tools/perf/util/bpf-event.c
+++ b/tools/perf/util/bpf-event.c
@@ -233,7 +233,7 @@ int perf_event__synthesize_bpf_events(struct perf_tool 
*tool,
err = 0;
break;
}
-   pr_debug("%s: can't get next program: %s%s",
+   pr_debug("%s: can't get next program: %s%s\n",
 __func__, strerror(errno),
 errno == EINVAL ? " -- kernel too old?" : "");
/* don't report error on old kernel or EPERM  */
-- 
2.17.2

[PATCH 2/6] perf tools: Force sample_type for slave events

[Jiri Olsa]

Forcing sample_type setup for slave events in group
leader sessions.

We don't get sample for slave events, we make them
when delivering group leader sample. Set the slave
event to follow the master sample_type to ease up
report.

Link: http://lkml.kernel.org/n/tip-mqhyqhxm0p2jyzqjffwgb...@git.kernel.org
Signed-off-by: Jiri Olsa 
---
 tools/perf/util/evsel.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/tools/perf/util/evsel.c b/tools/perf/util/evsel.c
index 684c893ca6bc..dfe2958e6287 100644
--- a/tools/perf/util/evsel.c
+++ b/tools/perf/util/evsel.c
@@ -956,6 +956,14 @@ void perf_evsel__config(struct perf_evsel *evsel, struct 
record_opts *opts,
attr->sample_freq= 0;
attr->sample_period  = 0;
attr->write_backward = 0;
+
+   /*
+* We don't get sample for slave events, we make them
+* when delivering group leader sample. Set the slave
+* event to follow the master sample_type to ease up
+* report.
+*/
+   attr->sample_type = leader->attr.sample_type;
}
 
if (opts->no_samples)
-- 
2.17.2

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

[Måns Rullgård]

"Rafael J. Wysocki"  writes:

> On Wed, Feb 20, 2019 at 1:12 PM Måns Rullgård  wrote:
>>
>> Johan Hovold  writes:
>>
>> > On Wed, Feb 20, 2019 at 11:35:06AM +, Mans Rullgard wrote:
>> >> If the provided fwnode is an OF node, set dev.of_node as well.
>> >>
>> >> Some drivers are just shims that create extra "glue" devices with the
>> >> DT device as parent and have the real driver bind to these.  In these
>> >> cases, the glue device needs to get a reference to the original DT node
>> >> in order for the main driver to access properties and child nodes.
>> >>
>> >> For example, the sunxi-musb driver creates such a glue device using
>> >> platform_device_register_full().  Consequently, devices attached to
>> >> this USB interface don't get associated with DT nodes, if present,
>> >> the way they do with EHCI.
>> >>
>> >> This change will allow sunxi-musb and similar driver to easily
>> >> propagate the DT node to child devices as required.
>> >
>> > Just a drive-by comment, didn't look to closely at this patch, but this
>> > all sounds familiar.
>> >
>> > Note that if both platform devices are bound to drivers you may end up
>> > with some resources like pinctrl which are handled automatically by
>> > driver core at probe time to be requested twice (and failing the second
>> > time).
>> >
>> > Take a look at 4e75e1d7dac9 ("driver core: add helper to reuse a
>> > device-tree node"), which provides a means to avoid this, and
>> > 49484abd93ab ("USB: musb: dsps: propagate device-tree node").
>>
>> Thanks, and ugh.  So we should be setting the of_node_reused flag when
>> this is the case.  It's easy for the musb-dsps driver since it doesn't
>> use platform_device_register_full() and can do this before the
>> device_add() call.  How can we convey that this flag needs to be set?
>
> Through pdevinfo I guess?

Not without adding another field to it.  The most direct is of course to
simply add an of_node_reused flag there too and copy it over.  Would
that be OK, or is there a better way?

-- 
Måns Rullgård

Re: [PATCH v2 1/3] arm64: mm: use appropriate ctors for page tables

[Matthew Wilcox]

On Wed, Feb 20, 2019 at 03:57:59PM +0530, Anshuman Khandual wrote:
> On 02/20/2019 03:58 AM, Yu Zhao wrote:
> > On Tue, Feb 19, 2019 at 11:47:12AM +0530, Anshuman Khandual wrote:
> >> On 02/19/2019 11:02 AM, Yu Zhao wrote:
> >>> On Tue, Feb 19, 2019 at 09:51:01AM +0530, Anshuman Khandual wrote:
>  On 02/19/2019 04:43 AM, Yu Zhao wrote:
> > For pte page, use pgtable_page_ctor(); for pmd page, use
> > pgtable_pmd_page_ctor() if not folded; and for the rest (pud,
> > p4d and pgd), don't use any.
>  pgtable_page_ctor()/dtor() is not optional for any level page table page
>  as it determines the struct page state and zone statistics.
> >>>
> >>> This is not true. pgtable_page_ctor() is only meant for user pte
> >>> page. The name isn't perfect (we named it this way before we had
> >>> split pmd page table lock, and never bothered to change it).
> >>>
> >>> The commit cccd843f54be ("mm: mark pages in use for page tables")
> >>> clearly states so:
> >>>   Note that only pages currently accounted as NR_PAGETABLES are
> >>>   tracked as PageTable; this does not include pgd/p4d/pud/pmd pages.
> >>
> >> I think the commit is the following one and it does say so. But what is
> >> the rationale of tagging only PTE page as PageTable and updating the zone
> >> stat but not doing so for higher level page table pages ? Are not they
> >> used as page table pages ? Should not they count towards NR_PAGETABLE ?
> >>
> >> 1d40a5ea01d53251c ("mm: mark pages in use for page tables")
> > 
> > Well, I was just trying to clarify how the ctor is meant to be used.
> > The rational behind it is probably another topic.
> > 
> > For starters, the number of pmd/pud/p4d/pgd is at least two orders
> > of magnitude less than the number of pte, which makes them almost
> > negligible. And some archs use kmem for them, so it's infeasible to
> > SetPageTable on or account them in the way the ctor does on those
> > archs.
> 
> I understand the kmem cases which are definitely problematic and should
> be fixed. IIRC there is a mechanism to custom init pages allocated for
> slab cache with a ctor function which in turn can call pgtable_page_ctor().
> But destructor helper support for slab has been dropped I guess.

You can't put a spinlock in the struct page if the page is allocated
through slab.  Slab uses basically all of struct page for its own
purposes.  I tried to make that clear with the new layout of struct
page where everything's in a union discriminated by what the page is
allocated for.

[PATCH 0/3] usb: gadget: atmel: support USB suspend/resume

[Jonas Bonn]

This patch series hooks up proper support for USB suspend and resume to the
Atmel UDC.

Jonas Bonn (3):
  usb: gadget: atmel_usba_udc: simplify setting of interrupt-enabled
mask
  usb: gadget: atmel: support USB suspend
  usb: gadget: atmel: tie wake lock to running clock

 drivers/usb/gadget/udc/atmel_usba_udc.c | 84 -
 drivers/usb/gadget/udc/atmel_usba_udc.h |  1 +
 2 files changed, 71 insertions(+), 14 deletions(-)

-- 
2.19.1

[PATCH 1/3] usb: gadget: atmel_usba_udc: simplify setting of interrupt-enabled mask

[Jonas Bonn]

This patch adds set and clear functions for enabling/disabling
interrupts.  This simplifies the implementation a bit as the masking of
previously set bits doesn't need to be so explicit.

Signed-off-by: Jonas Bonn 
CC: Cristian Birsan 
CC: Felipe Balbi 
CC: Greg Kroah-Hartman 
CC: Nicolas Ferre 
CC: Alexandre Belloni 
CC: Ludovic Desroches 
CC: linux-arm-ker...@lists.infradead.org
CC: linux-...@vger.kernel.org
---
 drivers/usb/gadget/udc/atmel_usba_udc.c | 29 -
 1 file changed, 19 insertions(+), 10 deletions(-)

diff --git a/drivers/usb/gadget/udc/atmel_usba_udc.c 
b/drivers/usb/gadget/udc/atmel_usba_udc.c
index 51a2b9232baa..9d18f9b2 100644
--- a/drivers/usb/gadget/udc/atmel_usba_udc.c
+++ b/drivers/usb/gadget/udc/atmel_usba_udc.c
@@ -358,8 +358,20 @@ static inline u32 usba_int_enb_get(struct usba_udc *udc)
return udc->int_enb_cache;
 }
 
-static inline void usba_int_enb_set(struct usba_udc *udc, u32 val)
+static inline void usba_int_enb_set(struct usba_udc *udc, u32 mask)
 {
+   u32 val;
+
+   val = udc->int_enb_cache | mask;
+   usba_writel(udc, INT_ENB, val);
+   udc->int_enb_cache = val;
+}
+
+static inline void usba_int_enb_clear(struct usba_udc *udc, u32 mask)
+{
+   u32 val;
+
+   val = udc->int_enb_cache & ~mask;
usba_writel(udc, INT_ENB, val);
udc->int_enb_cache = val;
 }
@@ -629,14 +641,12 @@ usba_ep_enable(struct usb_ep *_ep, const struct 
usb_endpoint_descriptor *desc)
if (ep->can_dma) {
u32 ctrl;
 
-   usba_int_enb_set(udc, usba_int_enb_get(udc) |
- USBA_BF(EPT_INT, 1 << ep->index) |
+   usba_int_enb_set(udc, USBA_BF(EPT_INT, 1 << ep->index) |
  USBA_BF(DMA_INT, 1 << ep->index));
ctrl = USBA_AUTO_VALID | USBA_INTDIS_DMA;
usba_ep_writel(ep, CTL_ENB, ctrl);
} else {
-   usba_int_enb_set(udc, usba_int_enb_get(udc) |
- USBA_BF(EPT_INT, 1 << ep->index));
+   usba_int_enb_set(udc, USBA_BF(EPT_INT, 1 << ep->index));
}
 
spin_unlock_irqrestore(>lock, flags);
@@ -680,8 +690,7 @@ static int usba_ep_disable(struct usb_ep *_ep)
usba_dma_readl(ep, STATUS);
}
usba_ep_writel(ep, CTL_DIS, USBA_EPT_ENABLE);
-   usba_int_enb_set(udc, usba_int_enb_get(udc) &
- ~USBA_BF(EPT_INT, 1 << ep->index));
+   usba_int_enb_clear(udc, USBA_BF(EPT_INT, 1 << ep->index));
 
request_complete_list(ep, _list, -ESHUTDOWN);
 
@@ -1713,7 +1722,7 @@ static irqreturn_t usba_udc_irq(int irq, void *devid)
if (status & USBA_DET_SUSPEND) {
toggle_bias(udc, 0);
usba_writel(udc, INT_CLR, USBA_DET_SUSPEND);
-   usba_int_enb_set(udc, int_enb | USBA_WAKE_UP);
+   usba_int_enb_set(udc, USBA_WAKE_UP);
udc->bias_pulse_needed = true;
DBG(DBG_BUS, "Suspend detected\n");
if (udc->gadget.speed != USB_SPEED_UNKNOWN
@@ -1727,7 +1736,7 @@ static irqreturn_t usba_udc_irq(int irq, void *devid)
if (status & USBA_WAKE_UP) {
toggle_bias(udc, 1);
usba_writel(udc, INT_CLR, USBA_WAKE_UP);
-   usba_int_enb_set(udc, int_enb & ~USBA_WAKE_UP);
+   usba_int_enb_clear(udc, USBA_WAKE_UP);
DBG(DBG_BUS, "Wake Up CPU detected\n");
}
 
@@ -1796,7 +1805,7 @@ static irqreturn_t usba_udc_irq(int irq, void *devid)
| USBA_BF(BK_NUMBER, USBA_BK_NUMBER_ONE)));
usba_ep_writel(ep0, CTL_ENB,
USBA_EPT_ENABLE | USBA_RX_SETUP);
-   usba_int_enb_set(udc, int_enb | USBA_BF(EPT_INT, 1) |
+   usba_int_enb_set(udc, USBA_BF(EPT_INT, 1) |
  USBA_DET_SUSPEND | USBA_END_OF_RESUME);
 
/*
-- 
2.19.1

[PATCH 3/3] usb: gadget: atmel: tie wake lock to running clock

[Jonas Bonn]

If the USB device is connected to a host, the CPU cannot be suspended or
else the USB device appears to be disconnected from the host's point of
view.  Only after a "USB suspend" state has been entered (as set by the
host) or the host is disconnected can the system safely be suspended: in
both these states, the clock is stopped.  As such, this patch associates
a "wake lock" with the running clock of the UDC to keep the system awake
as long as the host maintains the USB connection active.

Signed-off-by: Jonas Bonn 
CC: Cristian Birsan 
CC: Felipe Balbi 
CC: Greg Kroah-Hartman 
CC: Nicolas Ferre 
CC: Alexandre Belloni 
CC: Ludovic Desroches 
CC: linux-arm-ker...@lists.infradead.org
CC: linux-...@vger.kernel.org
---
 drivers/usb/gadget/udc/atmel_usba_udc.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/usb/gadget/udc/atmel_usba_udc.c 
b/drivers/usb/gadget/udc/atmel_usba_udc.c
index 740cb9308a86..864d03c3c9db 100644
--- a/drivers/usb/gadget/udc/atmel_usba_udc.c
+++ b/drivers/usb/gadget/udc/atmel_usba_udc.c
@@ -1859,6 +1859,8 @@ static int start_clock(struct usba_udc *udc)
if (udc->clocked)
return 0;
 
+   pm_stay_awake(>pdev->dev);
+
ret = clk_prepare_enable(udc->pclk);
if (ret)
return ret;
@@ -1881,6 +1883,8 @@ static void stop_clock(struct usba_udc *udc)
clk_disable_unprepare(udc->pclk);
 
udc->clocked = false;
+
+   pm_relax(>pdev->dev);
 }
 
 static int usba_start(struct usba_udc *udc)
-- 
2.19.1

[PATCH 2/3] usb: gadget: atmel: support USB suspend

[Jonas Bonn]

This patch adds support for USB suspend to the Atmel UDC.

When suspended, the UDC clock can be stopped, resulting in some power
savings.  The "wake up" interrupt will fire irregardless of whether the
clock is running or not, allowing the UDC clock to be restarted when the
USB master wants to wake the device again.

The IRQ state of this device is somewhat fiddly.  The "wake up" IRQ
seems to actually be a "bus activity" indicator; the IRQ is almost
continuously asserted so enabling this IRQ should only be done after a
suspend when the wake IRQ becomes relevant.  Similarly, the "suspend"
IRQ detects "bus inactivity" and may therefore fire together with a
"wake" if the two types of activity coincide during the period between
two IRQ handler invocations; therefore, it's important to ignore the
"suspend" IRQ while waiting for a wake-up.

This has been tested on a SAMA5D2 board.

Signed-off-by: Jonas Bonn 
CC: Cristian Birsan 
CC: Felipe Balbi 
CC: Greg Kroah-Hartman 
CC: Nicolas Ferre 
CC: Alexandre Belloni 
CC: Ludovic Desroches 
CC: linux-arm-ker...@lists.infradead.org
CC: linux-...@vger.kernel.org
---
 drivers/usb/gadget/udc/atmel_usba_udc.c | 55 ++---
 drivers/usb/gadget/udc/atmel_usba_udc.h |  1 +
 2 files changed, 50 insertions(+), 6 deletions(-)

diff --git a/drivers/usb/gadget/udc/atmel_usba_udc.c 
b/drivers/usb/gadget/udc/atmel_usba_udc.c
index 9d18f9b2..740cb9308a86 100644
--- a/drivers/usb/gadget/udc/atmel_usba_udc.c
+++ b/drivers/usb/gadget/udc/atmel_usba_udc.c
@@ -1703,6 +1703,9 @@ static void usba_dma_irq(struct usba_udc *udc, struct 
usba_ep *ep)
}
 }
 
+static int start_clock(struct usba_udc *udc);
+static void stop_clock(struct usba_udc *udc);
+
 static irqreturn_t usba_udc_irq(int irq, void *devid)
 {
struct usba_udc *udc = devid;
@@ -1720,10 +1723,13 @@ static irqreturn_t usba_udc_irq(int irq, void *devid)
DBG(DBG_INT, "irq, status=%#08x\n", status);
 
if (status & USBA_DET_SUSPEND) {
-   toggle_bias(udc, 0);
-   usba_writel(udc, INT_CLR, USBA_DET_SUSPEND);
+   usba_writel(udc, INT_CLR, USBA_DET_SUSPEND|USBA_WAKE_UP);
usba_int_enb_set(udc, USBA_WAKE_UP);
+   usba_int_enb_clear(udc, USBA_DET_SUSPEND);
+   udc->suspended = true;
+   toggle_bias(udc, 0);
udc->bias_pulse_needed = true;
+   stop_clock(udc);
DBG(DBG_BUS, "Suspend detected\n");
if (udc->gadget.speed != USB_SPEED_UNKNOWN
&& udc->driver && udc->driver->suspend) {
@@ -1734,14 +1740,17 @@ static irqreturn_t usba_udc_irq(int irq, void *devid)
}
 
if (status & USBA_WAKE_UP) {
+   start_clock(udc);
toggle_bias(udc, 1);
usba_writel(udc, INT_CLR, USBA_WAKE_UP);
-   usba_int_enb_clear(udc, USBA_WAKE_UP);
DBG(DBG_BUS, "Wake Up CPU detected\n");
}
 
if (status & USBA_END_OF_RESUME) {
+   udc->suspended = false;
usba_writel(udc, INT_CLR, USBA_END_OF_RESUME);
+   usba_int_enb_clear(udc, USBA_WAKE_UP);
+   usba_int_enb_set(udc, USBA_DET_SUSPEND);
generate_bias_pulse(udc);
DBG(DBG_BUS, "Resume detected\n");
if (udc->gadget.speed != USB_SPEED_UNKNOWN
@@ -1756,6 +1765,8 @@ static irqreturn_t usba_udc_irq(int irq, void *devid)
if (dma_status) {
int i;
 
+   usba_int_enb_set(udc, USBA_DET_SUSPEND);
+
for (i = 1; i <= USBA_NR_DMAS; i++)
if (dma_status & (1 << i))
usba_dma_irq(udc, >usba_ep[i]);
@@ -1765,6 +1776,8 @@ static irqreturn_t usba_udc_irq(int irq, void *devid)
if (ep_status) {
int i;
 
+   usba_int_enb_set(udc, USBA_DET_SUSPEND);
+
for (i = 0; i < udc->num_ep; i++)
if (ep_status & (1 << i)) {
if (ep_is_control(>usba_ep[i]))
@@ -1778,7 +1791,9 @@ static irqreturn_t usba_udc_irq(int irq, void *devid)
struct usba_ep *ep0, *ep;
int i, n;
 
-   usba_writel(udc, INT_CLR, USBA_END_OF_RESET);
+   usba_writel(udc, INT_CLR,
+   USBA_END_OF_RESET|USBA_END_OF_RESUME
+   |USBA_DET_SUSPEND|USBA_WAKE_UP);
generate_bias_pulse(udc);
reset_all_endpoints(udc);
 
@@ -1805,6 +1820,11 @@ static irqreturn_t usba_udc_irq(int irq, void *devid)
| USBA_BF(BK_NUMBER, USBA_BK_NUMBER_ONE)));
usba_ep_writel(ep0, CTL_ENB,
USBA_EPT_ENABLE | USBA_RX_SETUP);
+
+   /* If we get reset while suspended... */
+   udc->suspended = false;
+   usba_int_enb_clear(udc, USBA_WAKE_UP);
+

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

[Rafael J. Wysocki]

On Wed, Feb 20, 2019 at 1:12 PM Måns Rullgård  wrote:
>
> Johan Hovold  writes:
>
> > On Wed, Feb 20, 2019 at 11:35:06AM +, Mans Rullgard wrote:
> >> If the provided fwnode is an OF node, set dev.of_node as well.
> >>
> >> Some drivers are just shims that create extra "glue" devices with the
> >> DT device as parent and have the real driver bind to these.  In these
> >> cases, the glue device needs to get a reference to the original DT node
> >> in order for the main driver to access properties and child nodes.
> >>
> >> For example, the sunxi-musb driver creates such a glue device using
> >> platform_device_register_full().  Consequently, devices attached to
> >> this USB interface don't get associated with DT nodes, if present,
> >> the way they do with EHCI.
> >>
> >> This change will allow sunxi-musb and similar driver to easily
> >> propagate the DT node to child devices as required.
> >
> > Just a drive-by comment, didn't look to closely at this patch, but this
> > all sounds familiar.
> >
> > Note that if both platform devices are bound to drivers you may end up
> > with some resources like pinctrl which are handled automatically by
> > driver core at probe time to be requested twice (and failing the second
> > time).
> >
> > Take a look at 4e75e1d7dac9 ("driver core: add helper to reuse a
> > device-tree node"), which provides a means to avoid this, and
> > 49484abd93ab ("USB: musb: dsps: propagate device-tree node").
>
> Thanks, and ugh.  So we should be setting the of_node_reused flag when
> this is the case.  It's easy for the musb-dsps driver since it doesn't
> use platform_device_register_full() and can do this before the
> device_add() call.  How can we convey that this flag needs to be set?

Through pdevinfo I guess?

Re: [PATCH] printk: Pass caller information to log_store().

[Petr Mladek]

On Sat 2019-02-16 19:59:33, Tetsuo Handa wrote:
> When thread1 called printk() which did not end with '\n', and then thread2
> called printk() which ends with '\n' before thread1 calls pr_cont(), the
> partial content saved into "struct cont" is flushed by thread2 despite the
> partial content was generated by thread1. This leads to confusing output
> as if the partial content was generated by thread2. Fix this problem by
> passing correct caller information to log_store().
> 
> Before:
> 
>   [ T8533] abcdefghijklm
>   [ T8533] ABCDEFGHIJKLMNOPQRSTUVWXYZ
>   [ T8532] nopqrstuvwxyz
>   [ T8532] abcdefghijklmnopqrstuvwxyz
>   [ T8533] abcdefghijklm
>   [ T8533] ABCDEFGHIJKLMNOPQRSTUVWXYZ
>   [ T8532] nopqrstuvwxyz
> 
> After:
> 
>   [ T8507] abcdefghijklm
>   [ T8508] ABCDEFGHIJKLMNOPQRSTUVWXYZ
>   [ T8507] nopqrstuvwxyz
>   [ T8507] abcdefghijklmnopqrstuvwxyz
>   [ T8507] abcdefghijklm
>   [ T8508] ABCDEFGHIJKLMNOPQRSTUVWXYZ
>   [ T8507] nopqrstuvwxyz

Great catch!
 
> Signed-off-by: Tetsuo Handa 

The patch looks fine to me:

Reviewed-by: Petr Mladek 

There are just two cosmetic changes that I might do when pushing
the patch, see below.

> ---
>  kernel/printk/printk.c | 39 ---
>  1 file changed, 24 insertions(+), 15 deletions(-)
> 
> diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
> index 33c0359..6547a88 100644
> --- a/kernel/printk/printk.c
> +++ b/kernel/printk/printk.c
> @@ -1850,13 +1854,16 @@ static bool cont_add(int facility, int level, enum 
> log_flags flags, const char *
>  
>  static size_t log_output(int facility, int level, enum log_flags lflags, 
> const char *dict, size_t dictlen, char *text, size_t text_len)
>  {
> + const u32 caller_id = printk_caller_id();
> +
>   /*
>* If an earlier line was buffered, and we're a continuation
> -  * write from the same process, try to add it to the buffer.
> +  * write from the same context, try to add it to the buffer.
>*/
>   if (cont.len) {
> - if (cont.owner == current && (lflags & LOG_CONT)) {
> - if (cont_add(facility, level, lflags, text, text_len))
> + if (cont.caller_id == caller_id && (lflags & LOG_CONT)) {
> + if (cont_add(caller_id, facility, level, lflags, text,
> +  text_len))

I think that this is the case when it is better to break the 80-character
per-line rule.

>   return text_len;
>   }
>   /* Otherwise, make sure it's flushed */
> @@ -1869,12 +1876,14 @@ static size_t log_output(int facility, int level, 
> enum log_flags lflags, const c
>  
>   /* If it doesn't end in a newline, try to buffer the current line */
>   if (!(lflags & LOG_NEWLINE)) {
> - if (cont_add(facility, level, lflags, text, text_len))
> + if (cont_add(caller_id, facility, level, lflags, text,
> +  text_len))

Same here.

>   return text_len;
>   }
>  

Best Regards,
Petr

[PATCH v2 -next] btrfs: Remove unnecessary casts in btrfs_read_root_item

[YueHaibing]

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 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.

Suggested-by: Dan Carpenter 
Signed-off-by: YueHaibing 
---
v2: modify commit message as Dan suggested 
---
 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)));
+  min_t(u32, len, sizeof(*item)));
if (len < sizeof(*item))
need_reset = 1;
if (!need_reset && btrfs_root_generation(item)

Re: linux-next: Tree for Feb 20

[Mimi Zohar]

> Fixes for this have already been proposed, and should appear in -next shortly
> 
> The EFI one is here
> https://mail.google.com/mail/u/0/#label/linux-efi/FMfcgxwBVgrQRjglPkWRqRqVclGgVDnB
> 
> Not sure about the IMA one, Mimi should be able to comment ...
    
I've already commented on the other patch and was expecting to see a
revised patch.

Mimi

Re: [PATCH] iio: mma8452: mark expected switch fall-through

[Jonathan Cameron]

On Mon, 11 Feb 2019 16:23:18 -0600
"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/iio/accel/mma8452.c: In function ‘mma8452_probe’:
> drivers/iio/accel/mma8452.c:1581:6: warning: this statement may fall through 
> [-Wimplicit-fallthrough=]
>if (ret == data->chip_info->chip_id)
>   ^
> drivers/iio/accel/mma8452.c:1584:2: note: here
>   default:
>   ^~~
> 
> Warning level 3 was used: -Wimplicit-fallthrough=3
> 
> Notice that, in this particular case, the code comment is modified
> in accordance with what GCC is expecting to find.
> 
> This patch is part of the ongoing efforts to enable
> -Wimplicit-fallthrough.
> 
> Signed-off-by: Gustavo A. R. Silva 
I know Peter probably won't like this, as it doesn't
read a as well, with the else dropped, but I'm going to take
it as we have had a lot of bugs caught by this code and this
is generating a false positive.

Applied to the togreg branch of iio.git and pushed out as testing
for the autobuilders to play with it.

Thanks,

Jonathan

> ---
>  drivers/iio/accel/mma8452.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/iio/accel/mma8452.c b/drivers/iio/accel/mma8452.c
> index 302781126bc6..00e100fc845a 100644
> --- a/drivers/iio/accel/mma8452.c
> +++ b/drivers/iio/accel/mma8452.c
> @@ -1580,7 +1580,7 @@ static int mma8452_probe(struct i2c_client *client,
>   case FXLS8471_DEVICE_ID:
>   if (ret == data->chip_info->chip_id)
>   break;
> - /* else: fall through */
> + /* fall through */
>   default:
>   ret = -ENODEV;
>   goto disable_regulators;

Re: [PATCH v2 1/2] drivers: provide devm_platform_ioremap_resource()

[Greg Kroah-Hartman]

On Wed, Feb 20, 2019 at 12:21:26PM +0100, Bartosz Golaszewski wrote:
> śr., 20 lut 2019 o 12:16 Greg Kroah-Hartman
>  napisał(a):
> >
> > On Wed, Feb 20, 2019 at 12:12:39PM +0100, Bartosz Golaszewski wrote:
> > > From: Bartosz Golaszewski 
> > >
> > > There are currently 1200+ instances of using platform_get_resource()
> > > and devm_ioremap_resource() together in the kernel tree.
> > >
> > > This patch wraps these two calls in a single helper. Thanks to that
> > > we don't have to declare a local variable for struct resource * and can
> > > omit the redundant argument for resource type. We also have one
> > > function call less.
> > >
> > > Signed-off-by: Bartosz Golaszewski 
> >
> > Acked-by: Greg Kroah-Hartman 
> >
> 
> Should this go through the driver-core tree?

No need, put it through the tree for patch 2/2.

thanks,

greg k-h

Re: [PATCH] usb: typec: tps6598x: handle block writes separately with plain-I2C adapters

[Heikki Krogerus]

Hi,

On Mon, Sep 10, 2018 at 07:05:01AM +0200, Nikolaus Voss wrote:
> Commit 1a2f474d328f handles block _reads_ separately with plain-I2C
> adapters, but the problem described with regmap-i2c not handling
> SMBus block transfers (i.e. read and writes) correctly also exists
> with writes.
> 
> As workaround, this patch adds a block write function the same way
> 1a2f474d328f adds a block read function.
> 
> Fixes: 1a2f474d328f ("usb: typec: tps6598x: handle block reads separately 
> with plain-I2C adapters")
> Fixes: 0a4c005bd171 ("usb: typec: driver for TI TPS6598x USB Power Delivery 
> controllers")
> Signed-off-by: Nikolaus Voss 
> ---
>  drivers/usb/typec/tps6598x.c | 22 ++
>  1 file changed, 18 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/usb/typec/tps6598x.c b/drivers/usb/typec/tps6598x.c
> index c84c8c189e90..57a3e6c5c175 100644
> --- a/drivers/usb/typec/tps6598x.c
> +++ b/drivers/usb/typec/tps6598x.c
> @@ -110,6 +110,20 @@ tps6598x_block_read(struct tps6598x *tps, u8 reg, void 
> *val, size_t len)
>   return 0;
>  }
>  
> +static int tps6598x_block_write(struct tps6598x *tps, u8 reg,
> + void *val, size_t len)
> +{
> + u8 data[len + 1];
> +
> + if (!tps->i2c_protocol)
> + return regmap_raw_write(tps->regmap, reg, val, len);
> +
> + data[0] = len;
> + memcpy([1], val, len);
> +
> + return regmap_raw_write(tps->regmap, reg, data, sizeof(data));
> +}
> +
>  static inline int tps6598x_read16(struct tps6598x *tps, u8 reg, u16 *val)
>  {
>   return tps6598x_block_read(tps, reg, val, sizeof(u16));
> @@ -127,23 +141,23 @@ static inline int tps6598x_read64(struct tps6598x *tps, 
> u8 reg, u64 *val)
>  
>  static inline int tps6598x_write16(struct tps6598x *tps, u8 reg, u16 val)
>  {
> - return regmap_raw_write(tps->regmap, reg, , sizeof(u16));
> + return tps6598x_block_write(tps, reg, , sizeof(u16));
>  }
>  
>  static inline int tps6598x_write32(struct tps6598x *tps, u8 reg, u32 val)
>  {
> - return regmap_raw_write(tps->regmap, reg, , sizeof(u32));
> + return tps6598x_block_write(tps, reg, , sizeof(u32));
>  }
>  
>  static inline int tps6598x_write64(struct tps6598x *tps, u8 reg, u64 val)
>  {
> - return regmap_raw_write(tps->regmap, reg, , sizeof(u64));
> + return tps6598x_block_write(tps, reg, , sizeof(u64));
>  }
>  
>  static inline int
>  tps6598x_write_4cc(struct tps6598x *tps, u8 reg, const char *val)
>  {
> - return regmap_raw_write(tps->regmap, reg, , sizeof(u32));
> + return tps6598x_block_write(tps, reg, , sizeof(u32));
>  }
>  
>  static int tps6598x_read_partner_identity(struct tps6598x *tps)

You need to fix tps6598x_exec_cmd() as well.

Did you really send this last September? If you did, then the mail has
been stuck somewhere for a long time.


thanks,

-- 
heikki

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

[Måns Rullgård]

Johan Hovold  writes:

> On Wed, Feb 20, 2019 at 11:35:06AM +, Mans Rullgard wrote:
>> If the provided fwnode is an OF node, set dev.of_node as well.
>> 
>> Some drivers are just shims that create extra "glue" devices with the
>> DT device as parent and have the real driver bind to these.  In these
>> cases, the glue device needs to get a reference to the original DT node
>> in order for the main driver to access properties and child nodes.
>> 
>> For example, the sunxi-musb driver creates such a glue device using
>> platform_device_register_full().  Consequently, devices attached to
>> this USB interface don't get associated with DT nodes, if present,
>> the way they do with EHCI.
>> 
>> This change will allow sunxi-musb and similar driver to easily
>> propagate the DT node to child devices as required.
>
> Just a drive-by comment, didn't look to closely at this patch, but this
> all sounds familiar.
>
> Note that if both platform devices are bound to drivers you may end up
> with some resources like pinctrl which are handled automatically by
> driver core at probe time to be requested twice (and failing the second
> time).
>
> Take a look at 4e75e1d7dac9 ("driver core: add helper to reuse a
> device-tree node"), which provides a means to avoid this, and
> 49484abd93ab ("USB: musb: dsps: propagate device-tree node").

Thanks, and ugh.  So we should be setting the of_node_reused flag when
this is the case.  It's easy for the musb-dsps driver since it doesn't
use platform_device_register_full() and can do this before the
device_add() call.  How can we convey that this flag needs to be set?

>> 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));
>>  
>>  if (pdevinfo->dma_mask) {
>>  /*
>
> Johan

-- 
Måns Rullgård

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

[Lucas Stach]

Am Mittwoch, den 20.02.2019, 11:21 + schrieb Aisheng Dong:
> Hi Marco,
> 
> > From: Marco Felsch [mailto:m.fel...@pengutronix.de]
> > Sent: Wednesday, February 20, 2019 6:53 PM
> > 
> > Hi Aisheng,
> > 
> > On 19-02-20 09:49, Aisheng Dong wrote:
> > > > 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.
> > 
> > I think marking them as deprecated by a commentar is better than redefining
> > bits to be unused. As I said the bindings not only linux related they are 
> > used in
> > other projects too.
> > 
> 
> For other projects, the result is same because SC firmware does not support 
> those
> Resource IDs.
> 
> > > Personally I may prefer to remove them as they never worked to avoid
> > > confusing, especially at this early stage for mx8.
> > 
> > So why they are there if they never worked? Wouldn't it a better approach to
> > start with a basic and working ID file and extend this rather than adding 
> > id's
> > because maybe the will work.. 
> 
> Ideally yes, but may be hard in reality.
> 
> SC firmware code usually is developed quite early before silicon comes.
> But the real chip may changes, e.g. removed or added something.
> 
> AFAIK those resource IDs removed have never worked in SC firmware,
> and they're likely to come out of pre-silicon definition. But chip changes
> later.
> 
> > Sorry but this seems wrong to me too.
> > I know the approach from driver development, adding a driver specific 
> > *_reg.h
> > file and later figuring out that those bits won't work as aspected. As I 
> > said this
> > will be driver and only linux related so we can change them as many times as
> > we want. But in your case we are talking about dt-bindings and this approach
> > won't work.
> 
> I would agree with you if those resource IDs have worked before.
> But they never worked.
> Should we keep a thing never worked in device tree just because
> It makes us look like keeping compatibility?
> 
> If that, I'd rather removing them to avoid confusing in the future. Life is 
> long, right?
> I don't want people to bother with those unmeaning things anymore when they
> look at it.

Removing things is totally fine if they have never worked. Re-using the
now "free" IDs is what is 

Re: [PATCH v2] iio/gyro/bmg160: Use millidegrees for temperature scale

[Jonathan Cameron]

On Wed, 13 Feb 2019 08:41:47 +0100
Mike Looijmans  wrote:

> Standard unit for temperature is millidegrees Celcius, whereas this driver
> was reporting in degrees. Fix the scale factor in the driver.
> 
> Signed-off-by: Mike Looijmans 
Applied to the fixes-togreg branch of iio.git and marked for stable.

Thanks,

Jonathan
> ---
> v2: Don't touch val2 when returning IIO_VAL_INT
> Only touch val when returning a value
> 
>  drivers/iio/gyro/bmg160_core.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/iio/gyro/bmg160_core.c b/drivers/iio/gyro/bmg160_core.c
> index 63ca316..92c07ab 100644
> --- a/drivers/iio/gyro/bmg160_core.c
> +++ b/drivers/iio/gyro/bmg160_core.c
> @@ -582,11 +582,10 @@ static int bmg160_read_raw(struct iio_dev *indio_dev,
>   case IIO_CHAN_INFO_LOW_PASS_FILTER_3DB_FREQUENCY:
>   return bmg160_get_filter(data, val);
>   case IIO_CHAN_INFO_SCALE:
> - *val = 0;
>   switch (chan->type) {
>   case IIO_TEMP:
> - *val2 = 50;
> - return IIO_VAL_INT_PLUS_MICRO;
> + *val = 500;
> + return IIO_VAL_INT;
>   case IIO_ANGL_VEL:
>   {
>   int i;
> @@ -594,6 +593,7 @@ static int bmg160_read_raw(struct iio_dev *indio_dev,
>   for (i = 0; i < ARRAY_SIZE(bmg160_scale_table); ++i) {
>   if (bmg160_scale_table[i].dps_range ==
>   data->dps_range) {
> + *val = 0;
>   *val2 = bmg160_scale_table[i].scale;
>   return IIO_VAL_INT_PLUS_MICRO;
>   }

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

[Mans Rullgard]

This adds pinctrl settings for various missing uart options.

Signed-off-by: Mans Rullgard 
---
Changed in v2:
- add /omit-if-no-ref/ tags to new nodes
---
 arch/arm/boot/dts/sun7i-a20.dtsi | 54 
 1 file changed, 54 insertions(+)

diff --git a/arch/arm/boot/dts/sun7i-a20.dtsi b/arch/arm/boot/dts/sun7i-a20.dtsi
index af5b067a5f83..76d0c961f01e 100644
--- a/arch/arm/boot/dts/sun7i-a20.dtsi
+++ b/arch/arm/boot/dts/sun7i-a20.dtsi
@@ -944,6 +944,36 @@
function = "uart0";
};
 
+   /omit-if-no-ref/
+   uart0_pf_pins: uart0-pf-pins {
+   pins = "PF2", "PF4";
+   function = "uart0";
+   };
+
+   /omit-if-no-ref/
+   uart1_pa_pins: uart1-pa-pins {
+   pins = "PA10", "PA11";
+   function = "uart1";
+   };
+
+   /omit-if-no-ref/
+   uart1_cts_rts_pa_pins: uart1-cts-rts-pa-pins {
+   pins = "PA12", "PIA13";
+   function = "uart2";
+   };
+
+   /omit-if-no-ref/
+   uart2_pa_pins: uart2-pa-pins {
+   pins = "PIA2", "PIA3";
+   function = "uart2";
+   };
+
+   /omit-if-no-ref/
+   uart2_cts_rts_pa_pins: uart2-cts-rts-pa-pins {
+   pins = "PA0", "PIA1";
+   function = "uart2";
+   };
+
uart2_pi_pins: uart2-pi-pins {
pins = "PI18", "PI19";
function = "uart2";
@@ -969,6 +999,12 @@
function = "uart3";
};
 
+   /omit-if-no-ref/
+   uart3_cts_rts_ph_pins: uart3-cts-rts-ph-pins {
+   pins = "PH2", "PH3";
+   function = "uart3";
+   };
+
uart4_pg_pins: uart4-pg-pins {
pins = "PG10", "PG11";
function = "uart4";
@@ -979,16 +1015,34 @@
function = "uart4";
};
 
+   /omit-if-no-ref/
+   uart5_ph_pins: uart5-ph-pins {
+   pins = "PH6", "PH7";
+   function = "uart5";
+   };
+
uart5_pi_pins: uart5-pi-pins {
pins = "PI10", "PI11";
function = "uart5";
};
 
+   /omit-if-no-ref/
+   uart6_pa_pins: uart6-pa-pins {
+   pins = "PA12", "PA13";
+   function = "uart6";
+   };
+
uart6_pi_pins: uart6-pi-pins {
pins = "PI12", "PI13";
function = "uart6";
};
 
+   /omit-if-no-ref/
+   uart7_pa_pins: uart7-pa-pins {
+   pins = "PA14", "PA15";
+   function = "uart7";
+   };
+
uart7_pi_pins: uart7-pi-pins {
pins = "PI20", "PI21";
function = "uart7";
-- 
2.20.1

Re: [PATCH 4/4] drm/panel: Add OSD101T2587-53TS driver

[Peter Ujfalusi]

Hi Sam,

On 20/02/2019 13.52, Sam Ravnborg wrote:
> Hi Peter.
> 
> On Wed, Feb 20, 2019 at 12:39:11PM +0200, Peter Ujfalusi wrote:
>> Hi Sam,
>>
>> On 15/02/2019 20.07, Sam Ravnborg wrote:
 +#include 
 +#include 
 +#include 
 +#include 
 +
 +#include 
>>> Please do not use drmP.h in new drivers - we try to get rid of this file.
>>
>> ...
>>
 +static int osd101t2587_panel_get_modes(struct drm_panel *panel)
 +{
 +  struct osd101t2587_panel *osd101t2587 = to_osd101t2587_panel(panel);
 +  struct drm_display_mode *mode;
 +
 +  mode = drm_mode_duplicate(panel->drm, osd101t2587->default_mode);
 +  if (!mode) {
 +  dev_err(panel->drm->dev, "failed to add mode %ux%ux@%u\n",
>>
>> drm/drmP.h is needed for this dev_err.
> drmP.h is only a set of include files and forwards today.
> So you need to figure out what to replace it with.
> 
> Often removing drmP.h requires you to add more than one extra include file.

Replacing it with
#include 

works perfectly.

Thanks,
- Péter

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

Re: [PATCH v2 0/2] drivers: new helper for ioremapping memory resources

[Andy Shevchenko]

On Wed, Feb 20, 2019 at 12:12:38PM +0100, Bartosz Golaszewski wrote:
> From: Bartosz Golaszewski 
> 
> There are currently 1200+ instances of using platform_get_resource()
> and devm_ioremap_resource() together in the kernel tree. It's a minor
> redundancy, but consolidation is always good.
> 
> The first patch in this series adds a wrapper for these two calls and
> the second uses it in a driver I could test.
> 
> If accepted I'll prepare a coccinelle script that'll make it easier
> to convert all users.
> 

Reviewed-by: Andy Shevchenko 

> v1 -> v2:
> - EXPORT_SYMBOL() -> EXPORT_SYMBOL_GPL()
> 
> Bartosz Golaszewski (2):
>   drivers: provide devm_platform_ioremap_resource()
>   gpio: davinci: use devm_platform_ioremap_resource()
> 
>  drivers/base/platform.c | 18 ++
>  drivers/gpio/gpio-davinci.c |  4 +---
>  include/linux/platform_device.h |  3 +++
>  3 files changed, 22 insertions(+), 3 deletions(-)
> 
> -- 
> 2.20.1
> 

-- 
With Best Regards,
Andy Shevchenko

[PATCH] staging: octeon-usb: fix misspelled "re-enable"

[Sumit Pundir]

Fixes misspelled "re-enable" in comment. Reported by checkpatch.pl

Signed-off-by: Sumit Pundir 
---
 drivers/staging/octeon-usb/octeon-hcd.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/octeon-usb/octeon-hcd.h 
b/drivers/staging/octeon-usb/octeon-hcd.h
index 769c36cf6614..ae7ae50071ae 100644
--- a/drivers/staging/octeon-usb/octeon-hcd.h
+++ b/drivers/staging/octeon-usb/octeon-hcd.h
@@ -1797,7 +1797,7 @@ union cvmx_usbnx_usbp_ctl_status {
 *  This is a test signal. When the USB Core is
 *  powered up (not in Susned Mode), an automatic
 *  tester can use this to disable phy_clock and
-*  free_clk, then re-eanable them with an aligned
+*  free_clk, then re-enable them with an aligned
 *  phase.
 *  '1': The phy_clk and free_clk outputs are
 *  disabled. "0": The phy_clock and free_clk outputs
-- 
2.17.1

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

[Anson Huang]

Update i.MX SCU resource ID table according to latest
system controller firmware.

Latest system controller firmware removes below resources
which are never be used:
IMX_SC_R_DC_0_CAPTURE0
IMX_SC_R_DC_0_CAPTURE1
IMX_SC_R_DC_0_INTEGRAL0
IMX_SC_R_DC_0_INTEGRAL1
IMX_SC_R_DC_0_FRAC1
IMX_SC_R_DC_1_CAPTURE0
IMX_SC_R_DC_1_CAPTURE1
IMX_SC_R_DC_1_INTEGRAL0
IMX_SC_R_DC_1_INTEGRAL1
IMX_SC_R_DC_1_FRAC1
IMX_SC_R_GPU_3_PID0
IMX_SC_R_M4_0_SIM
IMX_SC_R_M4_0_WDOG
IMX_SC_R_M4_1_SIM
IMX_SC_R_M4_1_WDOG

and also add below resources to support new features:
IMX_SC_R_PERF
IMX_SC_R_OCRAM
IMX_SC_R_DMA_5_CH0
IMX_SC_R_DMA_5_CH1
IMX_SC_R_DMA_5_CH2
IMX_SC_R_DMA_5_CH3
IMX_SC_R_ATTESTATION

Signed-off-by: Anson Huang 
---
No changes since V1, just update the commit message to provide more detail info.
---
 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
 #define IMX_SC_R_DC_1_VIDEO1   46
 #define IMX_SC_R_DC_1_FRAC047
-#define IMX_SC_R_DC_1_FRAC148
+#define IMX_SC_R_UNUSED13  48
 #define IMX_SC_R_DC_1  49
-#define IMX_SC_R_GPU_3_PID050
+#define IMX_SC_R_UNUSED14  50
 #define IMX_SC_R_DC_1_PLL_051
 #define IMX_SC_R_DC_1_PLL_152
 #define IMX_SC_R_SPI_0 53
@@ -303,8 +303,8 @@
 #define IMX_SC_R_M4_0_UART 287
 #define IMX_SC_R_M4_0_I2C  288
 #define IMX_SC_R_M4_0_INTMUX   289
-#define IMX_SC_R_M4_0_SIM  290
-#define IMX_SC_R_M4_0_WDOG 291
+#define IMX_SC_R_UNUSED15  290
+#define IMX_SC_R_UNUSED16  291
 #define IMX_SC_R_M4_0_MU_0B292
 #define IMX_SC_R_M4_0_MU_0A0   293
 #define IMX_SC_R_M4_0_MU_0A1   294
@@ -323,8 +323,8 @@
 #define IMX_SC_R_M4_1_UART 307
 #define IMX_SC_R_M4_1_I2C  308
 #define IMX_SC_R_M4_1_INTMUX   309
-#define IMX_SC_R_M4_1_SIM  310
-#define IMX_SC_R_M4_1_WDOG 311
+#define IMX_SC_R_UNUSED17  310
+#define IMX_SC_R_UNUSED18  311
 #define IMX_SC_R_M4_1_MU_0B312
 #define IMX_SC_R_M4_1_MU_0A0   313
 #define IMX_SC_R_M4_1_MU_0A1   314
@@ -337,7 +337,7 @@
 #define IMX_SC_R_IRQSTR_SCU2   321
 #define IMX_SC_R_IRQSTR_DSP322
 #define IMX_SC_R_ELCDIF_PLL323
-#define IMX_SC_R_UNUSED6   324
+#define IMX_SC_R_OCRAM 324
 #define IMX_SC_R_AUDIO_PLL_0   325
 #define IMX_SC_R_PI_0  326
 #define IMX_SC_R_PI_0_PWM_0327
@@ -554,6 +554,11 @@
 #define IMX_SC_R_VPU_MU_3  538
 #define IMX_SC_R_VPU_ENC_1 539
 #define IMX_SC_R_VPU   540
-#define IMX_SC_R_LAST  541
+#define IMX_SC_R_DMA_5_CH0 541
+#define IMX_SC_R_DMA_5_CH1 542
+#define IMX_SC_R_DMA_5_CH2 543
+#define IMX_SC_R_DMA_5_CH3 544
+#define IMX_SC_R_ATTESTATION   545
+#define IMX_SC_R_LAST  546
 
 #endif 

Re: [PATCH v3] iio: adc: ti-ads7950: add GPIO support

[Jonathan Cameron]

On Wed, 13 Feb 2019 09:10:53 +0100
David Lechner  wrote:

> On 2/12/19 9:57 PM, justinpo...@gmail.com wrote:
> > From: Justin Chen 
> > 
> > The ADS79XX has GPIO pins that can be used. Add support for the GPIO
> > pins using the GPIO chip framework.
> > 
> > Signed-off-by: Justin Chen 
> > ---  
> 
> It will be better to split this up into two patches[1]. One to replace 
> all uses of indio_dev->mlock with the new local lock and then another to 
> add GPIO support.
> 
> How are you using/testing this patch? Do we need device tree bindings?
> 
> It will also help reviewers if you add a note about what you changed in 
> each revision of the patch when you resubmit. The usual way to do this 
> is something like:
> 
>  v3 changes:
> 
>  - Fixed unlocking mutex too many times in ti_ads7950_init_gpio()
> 
> It also is nice to wait a few days at least before submitting the next 
> revision to give people some time to respond.

Agreed with all comments except the endian one.
SPI doesn't define an endianness of data on the wire, so we may need
to convert to match whatever ordering the ti chip expects.
I would expect things to be thoroughly broken if we remove those
conversions - particularly as I doubt this is being tested with a
big endian host!

Jonathan
> 
> 
> 
> [1]: 
> https://www.kernel.org/doc/html/latest/process/submitting-patches.html#split-changes
> 
> >   drivers/iio/adc/ti-ads7950.c | 169 
> > ++-
> >   1 file changed, 166 insertions(+), 3 deletions(-)
> > 
> > diff --git a/drivers/iio/adc/ti-ads7950.c b/drivers/iio/adc/ti-ads7950.c
> > index 0ad6359..9723d66 100644
> > --- a/drivers/iio/adc/ti-ads7950.c
> > +++ b/drivers/iio/adc/ti-ads7950.c
> > @@ -17,6 +17,7 @@
> >   #include 
> >   #include 
> >   #include 
> > +#include 
> >   #include 
> >   #include 
> >   #include 
> > @@ -36,10 +37,14 @@
> >*/
> >   #define TI_ADS7950_VA_MV_ACPI_DEFAULT 5000
> >   
> > +#define TI_ADS7950_CR_GPIO BIT(14)
> >   #define TI_ADS7950_CR_MANUAL  BIT(12)
> >   #define TI_ADS7950_CR_WRITE   BIT(11)
> >   #define TI_ADS7950_CR_CHAN(ch)((ch) << 7)
> >   #define TI_ADS7950_CR_RANGE_5VBIT(6)
> > +#define TI_ADS7950_CR_GPIO_DATABIT(5)
> > +#define TI_ADS7950_NUM_GPIOS   4
> > +#define TI_ADS7950_GPIO_MASK   GENMASK(TI_ADS7950_NUM_GPIOS - 1, 0)
> >   
> >   #define TI_ADS7950_MAX_CHAN   16
> >   
> > @@ -56,11 +61,17 @@ struct ti_ads7950_state {
> > struct spi_message  ring_msg;
> > struct spi_message  scan_single_msg;
> >   
> > +   struct gpio_chipchip;
> > +   struct mutexslock;  
> 
> A comment stating what slock is protecting (i.e. the spi xfers and 
> buffers) would be helpful.
> 
> > +
> > struct regulator*reg;
> > unsigned intvref_mv;
> >   
> > unsigned intsettings;
> >   
> > +   unsigned intgpio_direction_bitmask;
> > +   unsigned intgpio_signal_bitmask;
> > +
> > /*
> >  * DMA (thus cache coherency maintenance) requires the
> >  * transfer buffers to live in their own cache lines.
> > @@ -248,7 +259,8 @@ static int ti_ads7950_update_scan_mode(struct iio_dev 
> > *indio_dev,
> >   
> > len = 0;
> > for_each_set_bit(i, active_scan_mask, indio_dev->num_channels) {
> > -   cmd = TI_ADS7950_CR_WRITE | TI_ADS7950_CR_CHAN(i) | 
> > st->settings;
> > +   cmd = TI_ADS7950_CR_WRITE | TI_ADS7950_CR_CHAN(i) | st->settings
> > + | (st->gpio_signal_bitmask & TI_ADS7950_GPIO_MASK);
> > st->tx_buf[len++] = cmd;
> > }
> >   
> > @@ -287,8 +299,9 @@ static int ti_ads7950_scan_direct(struct iio_dev 
> > *indio_dev, unsigned int ch)
> > int ret, cmd;
> >   
> > mutex_lock(_dev->mlock);  
> 
> The use of mlock should be removed here since we are replacing it with 
> slock. Also, ti_ads7950_trigger_handler() will need to be changed to use 
> slock when the use of mlock is removed. (When 
> ti_ads7950_trigger_handler() is called, mlock is already held by the 
> calling function.)
> 
> > -
> > -   cmd = TI_ADS7950_CR_WRITE | TI_ADS7950_CR_CHAN(ch) | st->settings;
> > +   mutex_lock(>slock);
> > +   cmd = TI_ADS7950_CR_WRITE | TI_ADS7950_CR_CHAN(ch) | st->settings
> > + | (st->gpio_signal_bitmask & TI_ADS7950_GPIO_MASK);
> > st->single_tx = cmd;
> >   
> > ret = spi_sync(st->spi, >scan_single_msg);
> > @@ -298,6 +311,7 @@ static int ti_ads7950_scan_direct(struct iio_dev 
> > *indio_dev, unsigned int ch)
> > ret = st->single_rx;
> >   
> >   out:
> > +   mutex_unlock(>slock);
> > mutex_unlock(_dev->mlock);
> >   
> > return ret;
> > @@ -362,6 +376,145 @@ static const struct iio_info ti_ads7950_info = {
> > .update_scan_mode   = ti_ads7950_update_scan_mode,
> >   };
> >   
> > +static void ti_ads7950_set(struct gpio_chip *chip, unsigned int offset,
> > +  int value)
> > +{
> > +   struct ti_ads7950_state *st = 

Re: [PATCH v3 7/9] s390: ap: implement PAPQ AQIC interception in kernel

[Halil Pasic]

On Thu, 14 Feb 2019 14:51:07 +0100
Pierre Morel  wrote:

> We register the AP PQAP instruction hook during the open
> of the mediated device. And unregister it on release.
> 
> In the AP PQAP instruction hook, if we receive a demand to
> enable IRQs,
> - we retrieve the vfio_ap_queue based on the APQN we receive
>   in REG1,
> - we retrieve the page of the guest address, (NIB), from
>   register REG2
> - we the mediated device to use the VFIO pinning infratrsucture
>   to pin the page of the guest address,
> - we retrieve the pointer to KVM to register the guest ISC
>   and retrieve the host ISC
> - finaly we activate GISA
> 
> If we receive a demand to disable IRQs,
> - we deactivate GISA
> - unregister from the GIB
> - unping the NIB
> 
> Signed-off-by: Pierre Morel 
> ---

[..]

> +static int handle_pqap(struct kvm_vcpu *vcpu)
> +{
> + uint64_t status;
> + uint16_t apqn;
> + struct vfio_ap_queue *q;
> + struct ap_queue_status qstatus = {};
> + struct ap_matrix_mdev *matrix_mdev;
> +
> + /* If we do not use the AIV facility just go to userland */
> + if (!(vcpu->arch.sie_block->eca & ECA_AIV))
> + return -EOPNOTSUPP;
> +
> + apqn = vcpu->run->s.regs.gprs[0] & 0x;
> + q = vfio_ap_get_queue(apqn);
> + if (!q) {
> + qstatus.response_code = AP_RESPONSE_Q_NOT_AVAIL;
> + goto out;
> + }
> +
> + /* Check if the queue is associated with a guest matrix */
> + matrix_mdev = q->matrix;
> + if (!matrix_mdev || !matrix_mdev->kvm) {
> + qstatus.response_code = AP_RESPONSE_DECONFIGURED;
> + goto out;
> + }
> +
> + status = vcpu->run->s.regs.gprs[1];
> +
> + /* If IR bit(16) is set we enable the interrupt */
> + if ((status >> (63 - 16)) & 0x01) {
> + q->isc = status & 0x07;
> + q->nib = vcpu->run->s.regs.gprs[2];

Careful! You may already have q->nib set (may or may not be a 0x07
scenario). You should unpin the old nib if set interruption controls
works out, if we get 0x07 response then you unpin the new one.


> + qstatus = vfio_ap_setirq(q);
> + if (qstatus.response_code) {
> + q->nib = 0;
> + q->isc = 0;
> + }
> + } else
> + qstatus = vfio_ap_clrirq(q);
> +
> +out:
> + memcpy(>run->s.regs.gprs[1], , sizeof(qstatus));
> + vfio_ap_put_queue(q);
> + return 0;
> +}

[..]

>  
> @@ -877,11 +1052,15 @@ static int vfio_ap_mdev_reset_queue(unsigned int apid, 
> unsigned int apqi,
>   unsigned int retry)
>  {
>   struct ap_queue_status status;
> + struct vfio_ap_queue *q;
> +
> + q = vfio_ap_get_queue(AP_MKQID(apid, apqi));
>  
>   do {
>   status = ap_zapq(AP_MKQID(apid, apqi));
>   switch (status.response_code) {
>   case AP_RESPONSE_NORMAL:

You could do the get queue here

> + vfio_ap_free_irq(q);

And the put here.


Regards,
Halil

>   return 0;
>   case AP_RESPONSE_RESET_IN_PROGRESS:
>   case AP_RESPONSE_BUSY:
> @@ -999,6 +1178,11 @@ static int vfio_ap_mdev_open(struct mdev_device *mdev)
>   if (ret)
>   goto err_group;
>  
> + if (!matrix_mdev->kvm) {
> + ret = -ENODEV;
> + goto err_iommu;
> + }
> +
>   matrix_mdev->iommu_notifier.notifier_call = vfio_ap_mdev_iommu_notifier;
>   events = VFIO_IOMMU_NOTIFY_DMA_UNMAP;
>  

[..]

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

[Måns Rullgård]

Mans Rullgard  writes:

> If the provided fwnode is an OF node, set dev.of_node as well.
>
> Some drivers are just shims that create extra "glue" devices with the
> DT device as parent and have the real driver bind to these.  In these
> cases, the glue device needs to get a reference to the original DT node
> in order for the main driver to access properties and child nodes.
>
> For example, the sunxi-musb driver creates such a glue device using
> platform_device_register_full().  Consequently, devices attached to
> this USB interface don't get associated with DT nodes, if present,
> the way they do with EHCI.
>
> This change will allow sunxi-musb and similar driver to easily
> propagate the DT node to child devices as required.
>
> 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));
>
>   if (pdevinfo->dma_mask) {
>   /*
> -- 

Sorry, I forgot to add a v2 to this.  Anyway, the only change is the
commit message.

-- 
Måns Rullgård

Re: [PATCH v2 2/2] staging: iio: frequency: ad9834: Move phase and scale to standard iio attribute

[Jonathan Cameron]

On Thu, 14 Feb 2019 18:41:30 +0200
Beniamin Bia  wrote:

> The custom phase and scale attributes were moved to standard iio types.
> 
> Signed-off-by: Beniamin Bia 
Hi, 

This hits the same fundamental questions of ABI as the FSK
elements in the previous patch, just now for Phase Shift Keying.

Unfortunately this ABI element is a strong part of the reason
these DDS chips have languished in staging a long time.
It is not easy to generalize.  On that note, we also want to
take into account any other chips that will want to share ABI with
this one as we define it.

Jonathan

> ---
> Changes in v2:
>   -the personal email address was replaced by the work email
>   -separate define for every phase channel
>   -enum used for write_phase functions
>   -phase variables were replaced by an array
> 
>  drivers/staging/iio/frequency/ad9834.c | 53 --
>  1 file changed, 32 insertions(+), 21 deletions(-)
> 
> diff --git a/drivers/staging/iio/frequency/ad9834.c 
> b/drivers/staging/iio/frequency/ad9834.c
> index 561617046c20..4366b6121154 100644
> --- a/drivers/staging/iio/frequency/ad9834.c
> +++ b/drivers/staging/iio/frequency/ad9834.c
> @@ -82,6 +82,7 @@ struct ad9834_state {
>   struct mutexlock;   /* protect sensor state */
>  
>   unsigned long   frequency[2];
> + unsigned long   phase[2];
>  
>   /*
>* DMA (thus cache coherency maintenance) requires the
> @@ -113,6 +114,8 @@ enum ad9834_supported_device_ids {
>   .output = 1,\
>   .channel = (chan),  \
>   .info_mask_separate = BIT(IIO_CHAN_INFO_FREQUENCY)  \
> + | BIT(IIO_CHAN_INFO_PHASE),\
> + .info_mask_shared_by_type = BIT(IIO_CHAN_INFO_SCALE),   \
>  }
>  
>  static const struct iio_chan_spec ad9833_channels[] = {
> @@ -172,13 +175,26 @@ static int ad9834_write_frequency(struct ad9834_state 
> *st,
>  }
>  
>  static int ad9834_write_phase(struct ad9834_state *st,
> -   unsigned long addr, unsigned long phase)
> +   enum ad9834_ch_addr addr,
> +   unsigned long phase)
>  {
> + int ret;
> +
>   if (phase > BIT(AD9834_PHASE_BITS))
>   return -EINVAL;
> - st->data = cpu_to_be16(addr | phase);
>  
> - return spi_sync(st->spi, >msg);
> + if (addr == AD9834_CHANNEL_ADDRESS0)
> + st->data = cpu_to_be16(AD9834_REG_PHASE0 | phase);
> + else
> + st->data = cpu_to_be16(AD9834_REG_PHASE1 | phase);
> +
> + ret = spi_sync(st->spi, >msg);
> + if (ret)
> + return ret;
> +
> + st->phase[(int)addr] = phase;
> +
> + return 0;
>  }
>  
>  static int ad9834_read_raw(struct iio_dev *indio_dev,
> @@ -191,6 +207,13 @@ static int ad9834_read_raw(struct iio_dev *indio_dev,
>   case IIO_CHAN_INFO_FREQUENCY:
>   *val = st->frequency[chan->channel];
>   return IIO_VAL_INT;
> + case IIO_CHAN_INFO_PHASE:
> + *val = st->phase[chan->channel];
> + return IIO_VAL_INT;
> + case IIO_CHAN_INFO_SCALE:
> + /*1 hz */
> + *val = 1;
> + return IIO_VAL_INT;
>   }
>  
>   return -EINVAL;
> @@ -207,6 +230,10 @@ static int ad9834_write_raw(struct iio_dev *indio_dev,
>   return ad9834_write_frequency(st,
> (enum 
> ad9834_ch_addr)chan->channel,
> val);
> + case IIO_CHAN_INFO_PHASE:
> + return ad9834_write_phase(st,
> +   (enum ad9834_ch_addr)chan->channel,
> +   val);
>   default:
>   return  -EINVAL;
>   }
> @@ -231,10 +258,6 @@ static ssize_t ad9834_write(struct device *dev,
>  
>   mutex_lock(>lock);
>   switch ((u32)this_attr->address) {
> - case AD9834_REG_PHASE0:
> - case AD9834_REG_PHASE1:
> - ret = ad9834_write_phase(st, this_attr->address, val);
> - break;
>   case AD9834_OPBITEN:
>   if (st->control & AD9834_MODE) {
>   ret = -EINVAL;  /* AD9843 reserved mode */
> @@ -394,12 +417,8 @@ static 
> IIO_DEVICE_ATTR(out_altvoltage0_out1_wavetype_available, 0444,
>   */
>  
>  static IIO_DEV_ATTR_FREQSYMBOL(0, 0200, NULL, ad9834_write, AD9834_FSEL);
> -static IIO_CONST_ATTR_FREQ_SCALE(0, "1"); /* 1Hz */
>  
> -static IIO_DEV_ATTR_PHASE(0, 0, 0200, NULL, ad9834_write, AD9834_REG_PHASE0);
> -static IIO_DEV_ATTR_PHASE(0, 1, 0200, NULL, ad9834_write, AD9834_REG_PHASE1);
>  static IIO_DEV_ATTR_PHASESYMBOL(0, 0200, NULL, ad9834_write, AD9834_PSEL);
> -static IIO_CONST_ATTR_PHASE_SCALE(0, "0.0015339808"); /* 2PI/2^12 rad*/
>  
>  static IIO_DEV_ATTR_PINCONTROL_EN(0, 0200, NULL,
>   

Re: [PATCH 4/4] drm/panel: Add OSD101T2587-53TS driver

[Sam Ravnborg]

Hi Peter.

On Wed, Feb 20, 2019 at 12:39:11PM +0200, Peter Ujfalusi wrote:
> Hi Sam,
> 
> On 15/02/2019 20.07, Sam Ravnborg wrote:
> >> +#include 
> >> +#include 
> >> +#include 
> >> +#include 
> >> +
> >> +#include 
> > Please do not use drmP.h in new drivers - we try to get rid of this file.
> 
> ...
> 
> >> +static int osd101t2587_panel_get_modes(struct drm_panel *panel)
> >> +{
> >> +  struct osd101t2587_panel *osd101t2587 = to_osd101t2587_panel(panel);
> >> +  struct drm_display_mode *mode;
> >> +
> >> +  mode = drm_mode_duplicate(panel->drm, osd101t2587->default_mode);
> >> +  if (!mode) {
> >> +  dev_err(panel->drm->dev, "failed to add mode %ux%ux@%u\n",
> 
> drm/drmP.h is needed for this dev_err.
drmP.h is only a set of include files and forwards today.
So you need to figure out what to replace it with.

Often removing drmP.h requires you to add more than one extra include file.

Sam

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

[Johan Hovold]

On Wed, Feb 20, 2019 at 11:35:06AM +, Mans Rullgard wrote:
> If the provided fwnode is an OF node, set dev.of_node as well.
> 
> Some drivers are just shims that create extra "glue" devices with the
> DT device as parent and have the real driver bind to these.  In these
> cases, the glue device needs to get a reference to the original DT node
> in order for the main driver to access properties and child nodes.
> 
> For example, the sunxi-musb driver creates such a glue device using
> platform_device_register_full().  Consequently, devices attached to
> this USB interface don't get associated with DT nodes, if present,
> the way they do with EHCI.
> 
> This change will allow sunxi-musb and similar driver to easily
> propagate the DT node to child devices as required.

Just a drive-by comment, didn't look to closely at this patch, but this
all sounds familiar.

Note that if both platform devices are bound to drivers you may end up
with some resources like pinctrl which are handled automatically by
driver core at probe time to be requested twice (and failing the second
time).

Take a look at 4e75e1d7dac9 ("driver core: add helper to reuse a
device-tree node"), which provides a means to avoid this, and
49484abd93ab ("USB: musb: dsps: propagate device-tree node").

> 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));
>  
>   if (pdevinfo->dma_mask) {
>   /*

Johan

Re: [PATCH v2 1/2] staging: iio: frequency: ad9834: Move frequency to standard iio types

[Jonathan Cameron]

On Thu, 14 Feb 2019 18:41:29 +0200
Beniamin Bia  wrote:

> Frequency attribute is added with a standard type from iio framework
> instead of custom attribute. This is a small step towards removing any
> unnecessary custom attribute. Ad9834 will diverge from ad9833 in the
> future, that is why we have two identical arrays for ad9834 and 9833.
> 
> Signed-off-by: Beniamin Bia 
Hi Beniamin

When you make a change like this, please explain in detail how the ABI
changes.  Here I'm not sure we can actually map it to channels like this.
We are controlling the two frequencies of FSK not independent channels.

The ABI around this needs very careful thinking out.  I would document
your proposed ABI first and share that.  Once we reach agreement on the
ABI, the actual code should be more straight forward!

Thanks,

Jonathan

> ---
> Changes in v2:
>   -the personal email address was replaced by the work email
>   -separate define for frequency channel
>   -address field from channel specification was removed
>   -frequency variables were replaced by an array
>   -specified in comment why we have differente chan_spec for ad9834 and 
> ad9833
>   -enum used for write_frequency function
> 
>  drivers/staging/iio/frequency/ad9834.c | 110 -
>  1 file changed, 91 insertions(+), 19 deletions(-)
> 
> diff --git a/drivers/staging/iio/frequency/ad9834.c 
> b/drivers/staging/iio/frequency/ad9834.c
> index f036f75d1f22..561617046c20 100644
> --- a/drivers/staging/iio/frequency/ad9834.c
> +++ b/drivers/staging/iio/frequency/ad9834.c
> @@ -81,6 +81,8 @@ struct ad9834_state {
>   struct spi_message  freq_msg;
>   struct mutexlock;   /* protect sensor state */
>  
> + unsigned long   frequency[2];
> +
>   /*
>* DMA (thus cache coherency maintenance) requires the
>* transfer buffers to live in their own cache lines.
> @@ -89,6 +91,11 @@ struct ad9834_state {
>   __be16  freq_data[2];
>  };
>  
> +enum ad9834_ch_addr {
> + AD9834_CHANNEL_ADDRESS0,
> + AD9834_CHANNEL_ADDRESS1,
> +};
> +
>  /**
>   * ad9834_supported_device_ids:
>   */
> @@ -100,6 +107,24 @@ enum ad9834_supported_device_ids {
>   ID_AD9838,
>  };
>  
> +#define AD9833_CHANNEL(chan) {   
> \
> + .type = IIO_ALTVOLTAGE, \
> + .indexed = 1,   \
> + .output = 1,\
> + .channel = (chan),  \
> + .info_mask_separate = BIT(IIO_CHAN_INFO_FREQUENCY)  \
> +}
> +
> +static const struct iio_chan_spec ad9833_channels[] = {
> + AD9833_CHANNEL(0),
> + AD9833_CHANNEL(1),
> +};
> +
> +static const struct iio_chan_spec ad9834_channels[] = {
> + AD9833_CHANNEL(0),
> + AD9833_CHANNEL(1),
> +};
> +
>  static unsigned int ad9834_calc_freqreg(unsigned long mclk, unsigned long 
> fout)
>  {
>   unsigned long long freqreg = (u64)fout * (u64)BIT(AD9834_FREQ_BITS);
> @@ -109,10 +134,12 @@ static unsigned int ad9834_calc_freqreg(unsigned long 
> mclk, unsigned long fout)
>  }
>  
>  static int ad9834_write_frequency(struct ad9834_state *st,
> -   unsigned long addr, unsigned long fout)
> +   enum ad9834_ch_addr addr,
> +   unsigned long fout)
>  {
>   unsigned long clk_freq;
>   unsigned long regval;
> + int ret;
>  
>   clk_freq = clk_get_rate(st->mclk);
>  
> @@ -121,13 +148,27 @@ static int ad9834_write_frequency(struct ad9834_state 
> *st,
>  
>   regval = ad9834_calc_freqreg(clk_freq, fout);
>  
> - st->freq_data[0] = cpu_to_be16(addr | (regval &
> -RES_MASK(AD9834_FREQ_BITS / 2)));
> - st->freq_data[1] = cpu_to_be16(addr | ((regval >>
> -(AD9834_FREQ_BITS / 2)) &
> -RES_MASK(AD9834_FREQ_BITS / 2)));
> + if (addr == AD9834_CHANNEL_ADDRESS0) {

So this if statement picks between the two addresses with no other differences?
That's fine, but use a local variable for the register address to simplify
the code.

> + st->freq_data[0] = cpu_to_be16(AD9834_REG_FREQ0 | (regval &
> +RES_MASK(AD9834_FREQ_BITS / 2)));
> + st->freq_data[1] = cpu_to_be16(AD9834_REG_FREQ0 | ((regval >>
> +(AD9834_FREQ_BITS / 2)) &
> +RES_MASK(AD9834_FREQ_BITS / 2)));
> + } else {
> + st->freq_data[0] = cpu_to_be16(AD9834_REG_FREQ1 | (regval &
> +RES_MASK(AD9834_FREQ_BITS / 2)));
> + st->freq_data[1] = cpu_to_be16(AD9834_REG_FREQ1 | ((regval >>

[PATCH 1/7] clk: at91: allow configuring peripheral PCR layout

[Alexandre Belloni]

The PCR register actually changed layout for each SoC. By chance, this
didn't have impact on sama5d[2-4] support but since sama5d3, PID is seven
bits wide and sama5d4 and sama5d2 don't have DIV.

For the DT backward compatibility, keep the layout as is.

Signed-off-by: Alexandre Belloni 
---
 drivers/clk/at91/at91sam9x5.c |  9 ++
 drivers/clk/at91/clk-peripheral.c | 46 ---
 drivers/clk/at91/dt-compat.c  |  9 ++
 drivers/clk/at91/pmc.h| 12 
 drivers/clk/at91/sama5d2.c|  9 ++
 drivers/clk/at91/sama5d4.c|  8 ++
 include/linux/clk/at91_pmc.h  |  3 --
 7 files changed, 71 insertions(+), 25 deletions(-)

diff --git a/drivers/clk/at91/at91sam9x5.c b/drivers/clk/at91/at91sam9x5.c
index 3487e03d4bc6..f5cfcbd85f10 100644
--- a/drivers/clk/at91/at91sam9x5.c
+++ b/drivers/clk/at91/at91sam9x5.c
@@ -49,6 +49,13 @@ static const struct {
{ .n = "pck1",  .p = "prog1",.id = 9 },
 };
 
+static const struct clk_pcr_layout at91sam9x5_pcr_layout = {
+   .offset = 0x10c,
+   .cmd = BIT(12),
+   .pid_mask = GENMASK(5, 0),
+   .div_mask = GENMASK(17, 16),
+};
+
 struct pck {
char *n;
u8 id;
@@ -242,6 +249,7 @@ static void __init at91sam9x5_pmc_setup(struct device_node 
*np,
 
for (i = 0; i < ARRAY_SIZE(at91sam9x5_periphck); i++) {
hw = at91_clk_register_sam9x5_peripheral(regmap, _pcr_lock,
+_pcr_layout,
 
at91sam9x5_periphck[i].n,
 "masterck",
 
at91sam9x5_periphck[i].id,
@@ -254,6 +262,7 @@ static void __init at91sam9x5_pmc_setup(struct device_node 
*np,
 
for (i = 0; extra_pcks[i].id; i++) {
hw = at91_clk_register_sam9x5_peripheral(regmap, _pcr_lock,
+_pcr_layout,
 extra_pcks[i].n,
 "masterck",
 extra_pcks[i].id,
diff --git a/drivers/clk/at91/clk-peripheral.c 
b/drivers/clk/at91/clk-peripheral.c
index 65c1defa78e4..6b7748b9588a 100644
--- a/drivers/clk/at91/clk-peripheral.c
+++ b/drivers/clk/at91/clk-peripheral.c
@@ -8,6 +8,7 @@
  *
  */
 
+#include 
 #include 
 #include 
 #include 
@@ -23,9 +24,6 @@ DEFINE_SPINLOCK(pmc_pcr_lock);
 #define PERIPHERAL_ID_MAX  31
 #define PERIPHERAL_MASK(id)(1 << ((id) & PERIPHERAL_ID_MAX))
 
-#define PERIPHERAL_RSHIFT_MASK 0x3
-#define PERIPHERAL_RSHIFT(val) (((val) >> 16) & PERIPHERAL_RSHIFT_MASK)
-
 #define PERIPHERAL_MAX_SHIFT   3
 
 struct clk_peripheral {
@@ -43,6 +41,7 @@ struct clk_sam9x5_peripheral {
spinlock_t *lock;
u32 id;
u32 div;
+   const struct clk_pcr_layout *layout;
bool auto_div;
 };
 
@@ -169,13 +168,13 @@ static int clk_sam9x5_peripheral_enable(struct clk_hw *hw)
return 0;
 
spin_lock_irqsave(periph->lock, flags);
-   regmap_write(periph->regmap, AT91_PMC_PCR,
-(periph->id & AT91_PMC_PCR_PID_MASK));
-   regmap_update_bits(periph->regmap, AT91_PMC_PCR,
-  AT91_PMC_PCR_DIV_MASK | AT91_PMC_PCR_CMD |
+   regmap_write(periph->regmap, periph->layout->offset,
+(periph->id & periph->layout->pid_mask));
+   regmap_update_bits(periph->regmap, periph->layout->offset,
+  periph->layout->div_mask | periph->layout->cmd |
   AT91_PMC_PCR_EN,
-  AT91_PMC_PCR_DIV(periph->div) |
-  AT91_PMC_PCR_CMD |
+  field_prep(periph->layout->div_mask, periph->div) |
+  periph->layout->cmd |
   AT91_PMC_PCR_EN);
spin_unlock_irqrestore(periph->lock, flags);
 
@@ -191,11 +190,11 @@ static void clk_sam9x5_peripheral_disable(struct clk_hw 
*hw)
return;
 
spin_lock_irqsave(periph->lock, flags);
-   regmap_write(periph->regmap, AT91_PMC_PCR,
-(periph->id & AT91_PMC_PCR_PID_MASK));
-   regmap_update_bits(periph->regmap, AT91_PMC_PCR,
-  AT91_PMC_PCR_EN | AT91_PMC_PCR_CMD,
-  AT91_PMC_PCR_CMD);
+   regmap_write(periph->regmap, periph->layout->offset,
+(periph->id & periph->layout->pid_mask));
+   regmap_update_bits(periph->regmap, periph->layout->offset,
+  AT91_PMC_PCR_EN | periph->layout->cmd,
+  periph->layout->cmd);
spin_unlock_irqrestore(periph->lock, flags);
 }
 
@@ -209,9 +208,9 @@ static int clk_sam9x5_peripheral_is_enabled(struct clk_hw 
*hw)
return 1;
 

Re: [PATCH v2 04/26] mm: allow VM_FAULT_RETRY for multiple times

[Peter Xu]

On Wed, Feb 13, 2019 at 11:34:44AM +0800, Peter Xu wrote:
> On Tue, Feb 12, 2019 at 10:56:10AM +0800, Peter Xu wrote:
> 
> [...]
> 
> > @@ -1351,7 +1351,7 @@ EXPORT_SYMBOL_GPL(__lock_page_killable);
> >  int __lock_page_or_retry(struct page *page, struct mm_struct *mm,
> >  unsigned int flags)
> >  {
> > -   if (flags & FAULT_FLAG_ALLOW_RETRY) {
> > +   if (!flags & FAULT_FLAG_TRIED) {
> 
> Sorry, this should be:
> 
> if (!(flags & FAULT_FLAG_TRIED))

Ok this is problematic too...  Because we for sure allow the page
fault flags to be both !ALLOW_RETRY and !TRIED (e.g., when doing GUP
and when __get_user_pages() is with locked==NULL and !FOLL_NOWAIT).
So current code will fall through the if condition and call
up_read(mmap_sem) even if above condition happened (while we shouldn't
because the GUP caller would assume the mmap_sem should be still
held).  So the correct check should be:

  if ((flags & FAULT_FLAG_ALLOW_RETRY) && !(flags & FAULT_FLAG_TRIED))

To make things easier, I'll just repost this single patch later.
Sorry for the noise.

Regards,

-- 
Peter Xu

[PATCH 5/7] clk: at91: add sam9x60 PLL driver

[Alexandre Belloni]

The PLLs on the sam9x60 (PLLA and USB PLL) use a different register set and
programming model than the previous SoCs.

Signed-off-by: Alexandre Belloni 
---
 drivers/clk/at91/Makefile  |   1 +
 drivers/clk/at91/clk-sam9x60-pll.c | 329 +
 drivers/clk/at91/pmc.h |   6 +
 3 files changed, 336 insertions(+)
 create mode 100644 drivers/clk/at91/clk-sam9x60-pll.c

diff --git a/drivers/clk/at91/Makefile b/drivers/clk/at91/Makefile
index c75df1cad60e..0a30fc8dfcb0 100644
--- a/drivers/clk/at91/Makefile
+++ b/drivers/clk/at91/Makefile
@@ -14,6 +14,7 @@ obj-$(CONFIG_HAVE_AT91_SMD)   += clk-smd.o
 obj-$(CONFIG_HAVE_AT91_H32MX)  += clk-h32mx.o
 obj-$(CONFIG_HAVE_AT91_GENERATED_CLK)  += clk-generated.o
 obj-$(CONFIG_HAVE_AT91_I2S_MUX_CLK)+= clk-i2s-mux.o
+obj-$(CONFIG_HAVE_AT91_SAM9X60_PLL)+= clk-sam9x60-pll.o
 obj-$(CONFIG_SOC_AT91SAM9) += at91sam9260.o at91sam9rl.o at91sam9x5.o
 obj-$(CONFIG_SOC_SAMA5D4) += sama5d4.o
 obj-$(CONFIG_SOC_SAMA5D2) += sama5d2.o
diff --git a/drivers/clk/at91/clk-sam9x60-pll.c 
b/drivers/clk/at91/clk-sam9x60-pll.c
new file mode 100644
index ..a3d5c729e8b6
--- /dev/null
+++ b/drivers/clk/at91/clk-sam9x60-pll.c
@@ -0,0 +1,329 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ *  Copyright (C) 2019 Microchip Technology Inc.
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "pmc.h"
+
+#define PMC_PLL_CTRL0  0xc
+#definePMC_PLL_CTRL0_DIV_MSK   GENMASK(7, 0)
+#definePMC_PLL_CTRL0_ENPLL BIT(28)
+#definePMC_PLL_CTRL0_ENPLLCK   BIT(29)
+#definePMC_PLL_CTRL0_ENLOCKBIT(31)
+
+#define PMC_PLL_CTRL1  0x10
+#definePMC_PLL_CTRL1_FRACR_MSK GENMASK(21, 0)
+#definePMC_PLL_CTRL1_MUL_MSK   GENMASK(30, 24)
+
+#define PMC_PLL_ACR0x18
+#definePMC_PLL_ACR_UTMIVR  BIT(12)
+#definePMC_PLL_ACR_UTMIBG  BIT(13)
+#definePMC_PLL_ACR_LOOP_FILTER_MSK GENMASK(31, 24)
+
+#define PMC_PLL_UPDT   0x1c
+#definePMC_PLL_UPDT_UPDATE BIT(8)
+
+#define PMC_PLL_ISR0   0xec
+
+#define PLL_DIV_MAX(FIELD_GET(PMC_PLL_CTRL0_DIV_MSK, UINT_MAX) + 1)
+#define UPLL_DIV   2
+#define PLL_MUL_MAX(FIELD_GET(PMC_PLL_CTRL1_MUL_MSK, UINT_MAX) + 1)
+
+#define PLL_MAX_ID 1
+
+struct sam9x60_pll {
+   struct clk_hw hw;
+   struct regmap *regmap;
+   spinlock_t *lock;
+   const struct clk_pll_characteristics *characteristics;
+   u32 frac;
+   u8 id;
+   u8 div;
+   u16 mul;
+};
+
+#define to_sam9x60_pll(hw) container_of(hw, struct sam9x60_pll, hw)
+
+static inline bool sam9x60_pll_ready(struct regmap *regmap, int id)
+{
+   unsigned int status;
+
+   regmap_read(regmap, PMC_PLL_ISR0, );
+
+   return !!(status & BIT(id));
+}
+
+static int sam9x60_pll_prepare(struct clk_hw *hw)
+{
+   struct sam9x60_pll *pll = to_sam9x60_pll(hw);
+   struct regmap *regmap = pll->regmap;
+   unsigned long flags;
+   u8 div;
+   u16 mul;
+   u32 val;
+
+   spin_lock_irqsave(pll->lock, flags);
+   regmap_write(regmap, PMC_PLL_UPDT, pll->id);
+
+   regmap_read(regmap, PMC_PLL_CTRL0, );
+   div = FIELD_GET(PMC_PLL_CTRL0_DIV_MSK, val);
+
+   regmap_read(regmap, PMC_PLL_CTRL1, );
+   mul = FIELD_GET(PMC_PLL_CTRL1_MUL_MSK, val);
+
+   if (sam9x60_pll_ready(regmap, pll->id) &&
+   (div == pll->div && mul == pll->mul)) {
+   spin_unlock_irqrestore(pll->lock, flags);
+   return 0;
+   }
+
+   /* Recommended value for PMC_PLL_ACR.LOOP_FILTER is 0x9 */
+   regmap_update_bits(regmap, PMC_PLL_ACR,
+  PMC_PLL_ACR_LOOP_FILTER_MSK, 0x9);
+
+   regmap_write(regmap, PMC_PLL_CTRL1,
+FIELD_PREP(PMC_PLL_CTRL1_MUL_MSK, pll->mul));
+
+   if (pll->characteristics->upll) {
+   /* Enable the UTMI internal bandgap */
+   regmap_update_bits(regmap, PMC_PLL_ACR,
+  PMC_PLL_ACR_UTMIBG, PMC_PLL_ACR_UTMIBG);
+
+   udelay(10);
+
+   /* Enable the UTMI internal regulator */
+   regmap_update_bits(regmap, PMC_PLL_ACR,
+  PMC_PLL_ACR_UTMIVR, PMC_PLL_ACR_UTMIVR);
+
+   udelay(10);
+   }
+
+   regmap_update_bits(regmap, PMC_PLL_UPDT,
+  PMC_PLL_UPDT_UPDATE, PMC_PLL_UPDT_UPDATE);
+
+   regmap_write(regmap, PMC_PLL_CTRL0,
+PMC_PLL_CTRL0_ENLOCK | PMC_PLL_CTRL0_ENPLL |
+PMC_PLL_CTRL0_ENPLLCK | pll->div);
+
+   regmap_update_bits(regmap, PMC_PLL_UPDT,
+  PMC_PLL_UPDT_UPDATE, PMC_PLL_UPDT_UPDATE);
+
+   while (!sam9x60_pll_ready(regmap, pll->id))
+

[PATCH 4/7] clk: at91: master: Add sam9x60 support

[Alexandre Belloni]

The sam9x60 cpu clock is located at a different offset but is otherwise
similar to the master clock.

Signed-off-by: Alexandre Belloni 
---
 drivers/clk/at91/clk-master.c | 8 +---
 drivers/clk/at91/pmc.h| 1 +
 include/linux/clk/at91_pmc.h  | 2 ++
 3 files changed, 8 insertions(+), 3 deletions(-)

diff --git a/drivers/clk/at91/clk-master.c b/drivers/clk/at91/clk-master.c
index eb53b4a8fab6..12b5bf4cc7bb 100644
--- a/drivers/clk/at91/clk-master.c
+++ b/drivers/clk/at91/clk-master.c
@@ -29,6 +29,7 @@ struct clk_master {
struct regmap *regmap;
const struct clk_master_layout *layout;
const struct clk_master_characteristics *characteristics;
+   u32 mckr;
 };
 
 static inline bool clk_master_ready(struct regmap *regmap)
@@ -69,7 +70,7 @@ static unsigned long clk_master_recalc_rate(struct clk_hw *hw,
master->characteristics;
unsigned int mckr;
 
-   regmap_read(master->regmap, AT91_PMC_MCKR, );
+   regmap_read(master->regmap, master->layout->offset, );
mckr &= layout->mask;
 
pres = (mckr >> layout->pres_shift) & MASTER_PRES_MASK;
@@ -95,7 +96,7 @@ static u8 clk_master_get_parent(struct clk_hw *hw)
struct clk_master *master = to_clk_master(hw);
unsigned int mckr;
 
-   regmap_read(master->regmap, AT91_PMC_MCKR, );
+   regmap_read(master->regmap, master->layout->offset, );
 
return mckr & AT91_PMC_CSS;
 }
@@ -147,13 +148,14 @@ at91_clk_register_master(struct regmap *regmap,
return hw;
 }
 
-
 const struct clk_master_layout at91rm9200_master_layout = {
.mask = 0x31F,
.pres_shift = 2,
+   .offset = AT91_PMC_MCKR,
 };
 
 const struct clk_master_layout at91sam9x5_master_layout = {
.mask = 0x373,
.pres_shift = 4,
+   .offset = AT91_PMC_MCKR,
 };
diff --git a/drivers/clk/at91/pmc.h b/drivers/clk/at91/pmc.h
index 44345e4ab1c9..4a30c20f17f1 100644
--- a/drivers/clk/at91/pmc.h
+++ b/drivers/clk/at91/pmc.h
@@ -38,6 +38,7 @@ struct clk_range {
 #define CLK_RANGE(MIN, MAX) {.min = MIN, .max = MAX,}
 
 struct clk_master_layout {
+   u32 offset;
u32 mask;
u8 pres_shift;
 };
diff --git a/include/linux/clk/at91_pmc.h b/include/linux/clk/at91_pmc.h
index 31f00ebf1315..0c53f26ae3d3 100644
--- a/include/linux/clk/at91_pmc.h
+++ b/include/linux/clk/at91_pmc.h
@@ -74,6 +74,8 @@
 #defineAT91_PMC_USBDIV_4   (2 << 28)
 #defineAT91_PMC_USB96M (1 << 28)   /* 
Divider by 2 Enable (PLLB only) */
 
+#define AT91_PMC_CPU_CKR   0x28/* CPU Clock Register */
+
 #defineAT91_PMC_MCKR   0x30/* Master Clock 
Register */
 #defineAT91_PMC_CSS(3 <<  0)   /* 
Master Clock Selection */
 #defineAT91_PMC_CSS_SLOW   (0 << 0)
-- 
2.20.1

[PATCH 6/7] dt-bindings: clk: at91: add bindings for SAM9X60 pmc

[Alexandre Belloni]

Add SAM9X60 PMC compatible string.

Cc: Rob Herring 
Signed-off-by: Alexandre Belloni 
---
 Documentation/devicetree/bindings/clock/at91-clock.txt | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/clock/at91-clock.txt 
b/Documentation/devicetree/bindings/clock/at91-clock.txt
index ce1d21102428..e0e4fa67716f 100644
--- a/Documentation/devicetree/bindings/clock/at91-clock.txt
+++ b/Documentation/devicetree/bindings/clock/at91-clock.txt
@@ -37,7 +37,8 @@ For example:
 Power Management Controller (PMC):
 
 Required properties:
-- compatible : shall be "atmel,-pmc", "syscon":
+- compatible : shall be "atmel,-pmc", "syscon" or
+   "microchip,sam9x60-pmc"
 can be: at91rm9200, at91sam9260, at91sam9261,
at91sam9263, at91sam9g45, at91sam9n12, at91sam9rl, at91sam9g15,
at91sam9g25, at91sam9g35, at91sam9x25, at91sam9x35, at91sam9x5,
-- 
2.20.1

[PATCH V4 4/4] irq: imx: irqsteer: add multi output interrupts support

[Aisheng Dong]

One irqsteer channel can support up to 8 output interrupts.

Cc: Marc Zyngier 
Cc: Lucas Stach 
Cc: Shawn Guo 
Reviewed-by: Lucas Stach 
Signed-off-by: Dong Aisheng 
---
ChangeLog:
v3->v4:
 * no changes
v2->v3:
 * add error check for imx_irqsteer_get_hwirq_base
 * use DIV_ROUND_UP
 * merge 'hwirq +=32' into for loop
 * common error path in probe to avoid replicating clk_disable_unprepare
v1->v2:
 * calculate irq_count by fsl,num-irqs instead of parsing interrupts
   property from devicetree to match the input interrupts and outputs
 * improve output interrupt handler by searching only two registers
   withint the same group
---
 drivers/irqchip/irq-imx-irqsteer.c | 88 +-
 1 file changed, 68 insertions(+), 20 deletions(-)

diff --git a/drivers/irqchip/irq-imx-irqsteer.c 
b/drivers/irqchip/irq-imx-irqsteer.c
index 67ed862..d1098f4 100644
--- a/drivers/irqchip/irq-imx-irqsteer.c
+++ b/drivers/irqchip/irq-imx-irqsteer.c
@@ -10,6 +10,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -21,10 +22,13 @@
 #define CHAN_MINTDIS(t)(CTRL_STRIDE_OFF(t, 3) + 0x4)
 #define CHAN_MASTRSTAT(t)  (CTRL_STRIDE_OFF(t, 3) + 0x8)
 
+#define CHAN_MAX_OUTPUT_INT0x8
+
 struct irqsteer_data {
void __iomem*regs;
struct clk  *ipg_clk;
-   int irq;
+   int irq[CHAN_MAX_OUTPUT_INT];
+   int irq_count;
raw_spinlock_t  lock;
int reg_num;
int channel;
@@ -87,23 +91,47 @@ static const struct irq_domain_ops imx_irqsteer_domain_ops 
= {
.xlate  = irq_domain_xlate_onecell,
 };
 
+static int imx_irqsteer_get_hwirq_base(struct irqsteer_data *data, u32 irq)
+{
+   int i;
+
+   for (i = 0; i < data->irq_count; i++) {
+   if (data->irq[i] == irq)
+   return i * 64;
+   }
+
+   return -EINVAL;
+}
+
 static void imx_irqsteer_irq_handler(struct irq_desc *desc)
 {
struct irqsteer_data *data = irq_desc_get_handler_data(desc);
-   int i;
+   int hwirq;
+   int irq, i;
 
chained_irq_enter(irq_desc_get_chip(desc), desc);
 
-   for (i = 0; i < data->reg_num * 32; i += 32) {
-   int idx = imx_irqsteer_get_reg_index(data, i);
+   irq = irq_desc_get_irq(desc);
+   hwirq = imx_irqsteer_get_hwirq_base(data, irq);
+   if (hwirq < 0) {
+   pr_warn("%s: unable to get hwirq base for irq %d\n",
+   __func__, irq);
+   return;
+   }
+
+   for (i = 0; i < 2; i++, hwirq += 32) {
+   int idx = imx_irqsteer_get_reg_index(data, hwirq);
unsigned long irqmap;
int pos, virq;
 
+   if (hwirq >= data->reg_num * 32)
+   break;
+
irqmap = readl_relaxed(data->regs +
   CHANSTATUS(idx, data->reg_num));
 
for_each_set_bit(pos, , 32) {
-   virq = irq_find_mapping(data->domain, pos + i);
+   virq = irq_find_mapping(data->domain, pos + hwirq);
if (virq)
generic_handle_irq(virq);
}
@@ -117,7 +145,8 @@ static int imx_irqsteer_probe(struct platform_device *pdev)
struct device_node *np = pdev->dev.of_node;
struct irqsteer_data *data;
struct resource *res;
-   int ret;
+   u32 irqs_num;
+   int i, ret;
 
data = devm_kzalloc(>dev, sizeof(*data), GFP_KERNEL);
if (!data)
@@ -130,12 +159,6 @@ static int imx_irqsteer_probe(struct platform_device *pdev)
return PTR_ERR(data->regs);
}
 
-   data->irq = platform_get_irq(pdev, 0);
-   if (data->irq <= 0) {
-   dev_err(>dev, "failed to get irq\n");
-   return -ENODEV;
-   }
-
data->ipg_clk = devm_clk_get(>dev, "ipg");
if (IS_ERR(data->ipg_clk)) {
ret = PTR_ERR(data->ipg_clk);
@@ -146,11 +169,15 @@ static int imx_irqsteer_probe(struct platform_device 
*pdev)
 
raw_spin_lock_init(>lock);
 
-   of_property_read_u32(np, "fsl,num-irqs", >reg_num);
+   of_property_read_u32(np, "fsl,num-irqs", _num);
of_property_read_u32(np, "fsl,channel", >channel);
 
-   /* one register bit map represents 32 input interrupts */
-   data->reg_num /= 32;
+   /*
+* There is one output irq for each group of 64 inputs.
+* One register bit map can represent 32 input interrupts.
+*/
+   data->irq_count = DIV_ROUND_UP(irqs_num, 64);
+   data->reg_num = irqs_num / 32;
 
if (IS_ENABLED(CONFIG_PM_SLEEP)) {
data->saved_reg = devm_kzalloc(>dev,
@@ -173,23 +200,44 @@ static int imx_irqsteer_probe(struct platform_device 
*pdev)
 

[PATCH V4 1/4] dt-binding: irq: imx-irqsteer: use irq number instead of group number

[Aisheng Dong]

Not all 64 interrupts may be used in one group. e.g. most irqsteer in
imx8qxp and imx8qm subsystems supports only 32 interrupts.

As the IP integration parameters are Channel number and interrupts number,
let's use fsl,irqs-num to represents how many interrupts supported
by this irqsteer channel.

Note this will break the compatibility of old binding. As the original
fsl,irq-groups was born out of a misunderstanding of the HW config
options and we are not aware of any users of the current binding.
And the old binding was just published in recent months, so it's
worth to change now to avoid confusing in the future.

Cc: Marc Zyngier 
Cc: Rob Herring 
Cc: Shawn Guo 
Cc: devicet...@vger.kernel.org
Reviewed-by: Lucas Stach 
Signed-off-by: Dong Aisheng 
---
ChangeLog:
v3->v4:
 * add more commit messages to describe the compatibility break
v2->v3:
 * no changes
v1->v2:
 * change property name fsl,irqs-per-chan to fsl,num-irqs.
---
 .../devicetree/bindings/interrupt-controller/fsl,irqsteer.txt   | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git 
a/Documentation/devicetree/bindings/interrupt-controller/fsl,irqsteer.txt 
b/Documentation/devicetree/bindings/interrupt-controller/fsl,irqsteer.txt
index 45790ce..6d0a41b 100644
--- a/Documentation/devicetree/bindings/interrupt-controller/fsl,irqsteer.txt
+++ b/Documentation/devicetree/bindings/interrupt-controller/fsl,irqsteer.txt
@@ -16,8 +16,8 @@ Required properties:
 - #interrupt-cells: Specifies the number of cells needed to encode an
   interrupt source. The value must be 1.
 - fsl,channel: The output channel that all input IRQs should be steered into.
-- fsl,irq-groups: Number of IRQ groups managed by this controller instance.
-  Each group manages 64 input interrupts.
+- fsl,num-irqs: Number of input interrupts of this channel.
+  Should be multiple of 32 input interrupts and up to 512 interrupts.
 
 Example:
 
@@ -28,7 +28,7 @@ Example:
clocks = < IMX8MQ_CLK_DISP_APB_ROOT>;
clock-names = "ipg";
fsl,channel = <0>;
-   fsl,irq-groups = <1>;
+   fsl,num-irqs = <64>;
interrupt-controller;
#interrupt-cells = <1>;
};
-- 
2.7.4

[PATCH V4 2/4] dt-bindings: irq: imx-irqsteer: add multi output interrupts support

[Aisheng Dong]

One irqsteer channel can support up to 8 output interrupts.

Cc: Marc Zyngier 
Cc: Rob Herring 
Cc: Shawn Guo 
Cc: devicet...@vger.kernel.org
Reviewed-by: Lucas Stach 
Signed-off-by: Dong Aisheng 
---
ChangeLog:
v3->v4:
 * no changes
v2->v3:
 * fix a typo
v1->v2:
 * remove one unnecessary note.
---
 .../devicetree/bindings/interrupt-controller/fsl,irqsteer.txt| 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git 
a/Documentation/devicetree/bindings/interrupt-controller/fsl,irqsteer.txt 
b/Documentation/devicetree/bindings/interrupt-controller/fsl,irqsteer.txt
index 6d0a41b..582991c 100644
--- a/Documentation/devicetree/bindings/interrupt-controller/fsl,irqsteer.txt
+++ b/Documentation/devicetree/bindings/interrupt-controller/fsl,irqsteer.txt
@@ -6,8 +6,9 @@ Required properties:
- "fsl,imx8m-irqsteer"
- "fsl,imx-irqsteer"
 - reg: Physical base address and size of registers.
-- interrupts: Should contain the parent interrupt line used to multiplex the
-  input interrupts.
+- interrupts: Should contain the up to 8 parent interrupt lines used to
+  multiplex the input interrupts. They should be specified sequentially
+  from output 0 to 7.
 - clocks: Should contain one clock for entry in clock-names
   see Documentation/devicetree/bindings/clock/clock-bindings.txt
 - clock-names:
-- 
2.7.4

[PATCH V4 0/4] irq: imx-irqsteer: add 32 interrupts chan and multi outputs support

[Aisheng Dong]

Not all 64 interrupts may be used in one group. e.g. most irqsteer in
imx8qxp and imx8qm subsystems supports only 32 interrupts.
And one irqsteer channel can support up to 8 output interrupts.

This patch series aims to support 32 interrupts chan and multi output
interrupts.

Tested on:
iMX8QXP MEK with MIPI CSI capture and DC Display
iMX8MQ EVK with MIPI DSI Display

Change Log:
v3->v4:
 * no code changes except adding more commit message for Patch 1

Dong Aisheng (4):
  dt-binding: irq: imx-irqsteer: use irq number instead of group number
  dt-bindings: irq: imx-irqsteer: add multi output interrupts support
  irq: imx-irqsteer: change to use reg_num instead of irq_group
  irq: imx: irqsteer: add multi output interrupts support

 .../bindings/interrupt-controller/fsl,irqsteer.txt |  11 +-
 drivers/irqchip/irq-imx-irqsteer.c | 115 +++--
 2 files changed, 89 insertions(+), 37 deletions(-)

-- 
2.7.4

[PATCH V4 3/4] irq: imx-irqsteer: change to use reg_num instead of irq_group

[Aisheng Dong]

One group can manage 64 interrupts by using two registers (e.g. STATUS/SET).
However, the integrated irqsteer may support only 32 interrupts which
needs only one register in a group. But the current driver assume there's
a mininum of two registers in a group which result in a wrong register map
for 32 interrupts per channel irqsteer. Let's use the reg_num caculated by
interrupts per channel instead of irq_group to cover this case.

Cc: Marc Zyngier 
Cc: Rob Herring 
Cc: Shawn Guo 
Reviewed-by: Lucas Stach 
Signed-off-by: Dong Aisheng 
---
v2->v4:
 * no changes
v1->v2:
 * The using of property name updated accordingly
---
 drivers/irqchip/irq-imx-irqsteer.c | 35 +++
 1 file changed, 19 insertions(+), 16 deletions(-)

diff --git a/drivers/irqchip/irq-imx-irqsteer.c 
b/drivers/irqchip/irq-imx-irqsteer.c
index 5b3f1d7..67ed862 100644
--- a/drivers/irqchip/irq-imx-irqsteer.c
+++ b/drivers/irqchip/irq-imx-irqsteer.c
@@ -13,7 +13,7 @@
 #include 
 #include 
 
-#define CTRL_STRIDE_OFF(_t, _r)(_t * 8 * _r)
+#define CTRL_STRIDE_OFF(_t, _r)(_t * 4 * _r)
 #define CHANCTRL   0x0
 #define CHANMASK(n, t) (CTRL_STRIDE_OFF(t, 0) + 0x4 * (n) + 0x4)
 #define CHANSET(n, t)  (CTRL_STRIDE_OFF(t, 1) + 0x4 * (n) + 0x4)
@@ -26,7 +26,7 @@ struct irqsteer_data {
struct clk  *ipg_clk;
int irq;
raw_spinlock_t  lock;
-   int irq_groups;
+   int reg_num;
int channel;
struct irq_domain   *domain;
u32 *saved_reg;
@@ -35,7 +35,7 @@ struct irqsteer_data {
 static int imx_irqsteer_get_reg_index(struct irqsteer_data *data,
  unsigned long irqnum)
 {
-   return (data->irq_groups * 2 - irqnum / 32 - 1);
+   return (data->reg_num - irqnum / 32 - 1);
 }
 
 static void imx_irqsteer_irq_unmask(struct irq_data *d)
@@ -46,9 +46,9 @@ static void imx_irqsteer_irq_unmask(struct irq_data *d)
u32 val;
 
raw_spin_lock_irqsave(>lock, flags);
-   val = readl_relaxed(data->regs + CHANMASK(idx, data->irq_groups));
+   val = readl_relaxed(data->regs + CHANMASK(idx, data->reg_num));
val |= BIT(d->hwirq % 32);
-   writel_relaxed(val, data->regs + CHANMASK(idx, data->irq_groups));
+   writel_relaxed(val, data->regs + CHANMASK(idx, data->reg_num));
raw_spin_unlock_irqrestore(>lock, flags);
 }
 
@@ -60,9 +60,9 @@ static void imx_irqsteer_irq_mask(struct irq_data *d)
u32 val;
 
raw_spin_lock_irqsave(>lock, flags);
-   val = readl_relaxed(data->regs + CHANMASK(idx, data->irq_groups));
+   val = readl_relaxed(data->regs + CHANMASK(idx, data->reg_num));
val &= ~BIT(d->hwirq % 32);
-   writel_relaxed(val, data->regs + CHANMASK(idx, data->irq_groups));
+   writel_relaxed(val, data->regs + CHANMASK(idx, data->reg_num));
raw_spin_unlock_irqrestore(>lock, flags);
 }
 
@@ -94,13 +94,13 @@ static void imx_irqsteer_irq_handler(struct irq_desc *desc)
 
chained_irq_enter(irq_desc_get_chip(desc), desc);
 
-   for (i = 0; i < data->irq_groups * 64; i += 32) {
+   for (i = 0; i < data->reg_num * 32; i += 32) {
int idx = imx_irqsteer_get_reg_index(data, i);
unsigned long irqmap;
int pos, virq;
 
irqmap = readl_relaxed(data->regs +
-  CHANSTATUS(idx, data->irq_groups));
+  CHANSTATUS(idx, data->reg_num));
 
for_each_set_bit(pos, , 32) {
virq = irq_find_mapping(data->domain, pos + i);
@@ -146,12 +146,15 @@ static int imx_irqsteer_probe(struct platform_device 
*pdev)
 
raw_spin_lock_init(>lock);
 
-   of_property_read_u32(np, "fsl,irq-groups", >irq_groups);
+   of_property_read_u32(np, "fsl,num-irqs", >reg_num);
of_property_read_u32(np, "fsl,channel", >channel);
 
+   /* one register bit map represents 32 input interrupts */
+   data->reg_num /= 32;
+
if (IS_ENABLED(CONFIG_PM_SLEEP)) {
data->saved_reg = devm_kzalloc(>dev,
-   sizeof(u32) * data->irq_groups * 2,
+   sizeof(u32) * data->reg_num,
GFP_KERNEL);
if (!data->saved_reg)
return -ENOMEM;
@@ -166,7 +169,7 @@ static int imx_irqsteer_probe(struct platform_device *pdev)
/* steer all IRQs into configured channel */
writel_relaxed(BIT(data->channel), data->regs + CHANCTRL);
 
-   data->domain = irq_domain_add_linear(np, data->irq_groups * 64,
+   data->domain = irq_domain_add_linear(np, data->reg_num * 32,
 _irqsteer_domain_ops, data);
if (!data->domain) {

Re: [PATCH 06/13] mm: pagewalk: Add 'depth' parameter to pte_hole

[William Kucharski]

> On Feb 15, 2019, at 10:02 AM, Steven Price  wrote:
> 
> The pte_hole() callback is called at multiple levels of the page tables.
> Code dumping the kernel page tables needs to know what at what depth
> the missing entry is. Add this is an extra parameter to pte_hole().
> When the depth isn't know (e.g. processing a vma) then -1 is passed.
> 
> Note that depth starts at 0 for a PGD so that PUD/PMD/PTE retain their
> natural numbers as levels 2/3/4.

Nit: Could you add a comment noting this for anyone wondering how to
calculate the level numbers in the future?

Thanks!