I need your assistance to invest!!!

[Miss Margaret Carnegie]

Dear Sir,

I need your support to relocate and invest in your country. I ask your 
assistance because I don’t have knowledge about 
business and the rules that guide your country for safe investment.
Will you promise to be sincere with me?

Please contact me for more information details!

With best regards,
Miss Margaret Carnegie.

I need your assistance to invest!!!

[Miss Margaret Carnegie]

Dear Sir,

I need your support to relocate and invest in your country. I ask your 
assistance because I don’t have knowledge about 
business and the rules that guide your country for safe investment.
Will you promise to be sincere with me?

Please contact me for more information details!

With best regards,
Miss Margaret Carnegie.

Re: [PATCH] orinoco: Use shash instead of ahash for MIC calculations

[Eric Biggers]

On Mon, Dec 12, 2016 at 12:55:55PM -0800, Andy Lutomirski wrote:
> +int orinoco_mic(struct crypto_shash *tfm_michael, u8 *key,
>   u8 *da, u8 *sa, u8 priority,
>   u8 *data, size_t data_len, u8 *mic)
>  {
> - AHASH_REQUEST_ON_STACK(req, tfm_michael);
> - struct scatterlist sg[2];
> + SHASH_DESC_ON_STACK(desc, tfm_michael);
>   u8 hdr[ETH_HLEN + 2]; /* size of header + padding */
>   int err;
>  
> @@ -67,18 +66,27 @@ int orinoco_mic(struct crypto_ahash *tfm_michael, u8 *key,
>   hdr[ETH_ALEN * 2 + 2] = 0;
>   hdr[ETH_ALEN * 2 + 3] = 0;
>  
> - /* Use scatter gather to MIC header and data in one go */
> - sg_init_table(sg, 2);
> - sg_set_buf([0], hdr, sizeof(hdr));
> - sg_set_buf([1], data, data_len);
> + desc->tfm = tfm_michael;
> + desc->flags = 0;
>  
> - if (crypto_ahash_setkey(tfm_michael, key, MIC_KEYLEN))
> - return -1;
> + err = crypto_shash_setkey(tfm_michael, key, MIC_KEYLEN);
> + if (err)
> + return err;
> +
> + err = crypto_shash_init(desc);
> + if (err)
> + return err;
> +
> + err = crypto_shash_update(desc, hdr, sizeof(hdr));
> + if (err)
> + return err;
> +
> + err = crypto_shash_update(desc, data, data_len);
> + if (err)
> + return err;
> +
> + err = crypto_shash_final(desc, mic);
> + shash_desc_zero(desc);
>  
> - ahash_request_set_tfm(req, tfm_michael);
> - ahash_request_set_callback(req, 0, NULL, NULL);
> - ahash_request_set_crypt(req, sg, mic, data_len + sizeof(hdr));
> - err = crypto_ahash_digest(req);
> - ahash_request_zero(req);
>   return err;

It's probably a good idea to always do shash_desc_zero(), even when something
above it fails.  Otherwise this looks fine.  Thanks for sending these patches!

Eric

Re: [PATCH] orinoco: Use shash instead of ahash for MIC calculations

[Eric Biggers]

On Mon, Dec 12, 2016 at 12:55:55PM -0800, Andy Lutomirski wrote:
> +int orinoco_mic(struct crypto_shash *tfm_michael, u8 *key,
>   u8 *da, u8 *sa, u8 priority,
>   u8 *data, size_t data_len, u8 *mic)
>  {
> - AHASH_REQUEST_ON_STACK(req, tfm_michael);
> - struct scatterlist sg[2];
> + SHASH_DESC_ON_STACK(desc, tfm_michael);
>   u8 hdr[ETH_HLEN + 2]; /* size of header + padding */
>   int err;
>  
> @@ -67,18 +66,27 @@ int orinoco_mic(struct crypto_ahash *tfm_michael, u8 *key,
>   hdr[ETH_ALEN * 2 + 2] = 0;
>   hdr[ETH_ALEN * 2 + 3] = 0;
>  
> - /* Use scatter gather to MIC header and data in one go */
> - sg_init_table(sg, 2);
> - sg_set_buf([0], hdr, sizeof(hdr));
> - sg_set_buf([1], data, data_len);
> + desc->tfm = tfm_michael;
> + desc->flags = 0;
>  
> - if (crypto_ahash_setkey(tfm_michael, key, MIC_KEYLEN))
> - return -1;
> + err = crypto_shash_setkey(tfm_michael, key, MIC_KEYLEN);
> + if (err)
> + return err;
> +
> + err = crypto_shash_init(desc);
> + if (err)
> + return err;
> +
> + err = crypto_shash_update(desc, hdr, sizeof(hdr));
> + if (err)
> + return err;
> +
> + err = crypto_shash_update(desc, data, data_len);
> + if (err)
> + return err;
> +
> + err = crypto_shash_final(desc, mic);
> + shash_desc_zero(desc);
>  
> - ahash_request_set_tfm(req, tfm_michael);
> - ahash_request_set_callback(req, 0, NULL, NULL);
> - ahash_request_set_crypt(req, sg, mic, data_len + sizeof(hdr));
> - err = crypto_ahash_digest(req);
> - ahash_request_zero(req);
>   return err;

It's probably a good idea to always do shash_desc_zero(), even when something
above it fails.  Otherwise this looks fine.  Thanks for sending these patches!

Eric

Re: [PATCH v5 2/2] mmc: sdhci-cadence: add Cadence SD4HC support

[Ulf Hansson]

[...]

>>> +
>>> +Optional properties:
>>> +For eMMC configuration, supported speed modes are not indicated by the 
>>> SDHCI
>>> +Capabilities Register.  Instead, the following properties should be 
>>> specified
>>> +if supported.  See mmc.txt for details.
>>> +- mmc-ddr-1_8v
>>> +- mmc-ddr-1_2v
>>> +- mmc-hs200-1_8v
>>> +- mmc-hs200-1_2v
>>> +- mmc-hs400-1_8v
>>> +- mmc-hs400-1_2v
>>
>> There's now a property to override SDHCI capabilities register. Maybe
>> you should use that instead? I'll defer to Ulf.
>>
>
> I did not know this new property.
>
> So, now we have two ways to specify MMC speed mode capabilities
> by only touching DT.

Let me clarify a bit.

The point with the new bindings is to be able to override *broken*
SDHCI caps bits. So, not only related to the speed modes.

>
> [1] Add MMC mode flags directly, like I did.
> [2] Use "sdhci-caps-mask" and "sdhci-caps"
>
>
> The problem for [2] is that eMMC capabilities
> do not perfectly correspond to the SDHCI capabilities register.
>
>
>>> +- mmc-hs400-1_8v
>>> +- mmc-hs400-1_2v
>
> If the driver sets SDHCI_QUIRK2_CAPS_BIT63_FOR_HS400,
> we can use the bit63 of caps for specifying HS400.
>
> But, this is not defined in the SDHCI standard.
> #define  SDHCI_SUPPORT_HS400 0x8000 /* Non-standard */
>
>
>
>>> +- mmc-ddr-1_8v
>
> For High Speed DDR, perhaps we can imply MMC_CAP_1_8V_DDR
> from MMC_CAP_UHS_DDR50  (bit34 of caps)
>
> This is not supported in the current code, but
> if this is a good idea, I can send a patch.
>
>
>>> +- mmc-ddr-1_2v
>
> This does not have the corresponding bit, but
> 1.2V is not commonly used, so this is not a fatal problem.
>
>
>
> What I can do at most now, is to delete the
> Optional properties section entirely
> so users can choose [1] or [2] as they like.
>

I think a better approach is to use the new sdhci-caps* bindings to
mask those caps that can't be trusted. And then use the generic mmc
bindings for speed modes instead.

That should be a safer approach, right!?

Kind regards
Uffe

Re: [PATCH v5 2/2] mmc: sdhci-cadence: add Cadence SD4HC support

[Ulf Hansson]

[...]

>>> +
>>> +Optional properties:
>>> +For eMMC configuration, supported speed modes are not indicated by the 
>>> SDHCI
>>> +Capabilities Register.  Instead, the following properties should be 
>>> specified
>>> +if supported.  See mmc.txt for details.
>>> +- mmc-ddr-1_8v
>>> +- mmc-ddr-1_2v
>>> +- mmc-hs200-1_8v
>>> +- mmc-hs200-1_2v
>>> +- mmc-hs400-1_8v
>>> +- mmc-hs400-1_2v
>>
>> There's now a property to override SDHCI capabilities register. Maybe
>> you should use that instead? I'll defer to Ulf.
>>
>
> I did not know this new property.
>
> So, now we have two ways to specify MMC speed mode capabilities
> by only touching DT.

Let me clarify a bit.

The point with the new bindings is to be able to override *broken*
SDHCI caps bits. So, not only related to the speed modes.

>
> [1] Add MMC mode flags directly, like I did.
> [2] Use "sdhci-caps-mask" and "sdhci-caps"
>
>
> The problem for [2] is that eMMC capabilities
> do not perfectly correspond to the SDHCI capabilities register.
>
>
>>> +- mmc-hs400-1_8v
>>> +- mmc-hs400-1_2v
>
> If the driver sets SDHCI_QUIRK2_CAPS_BIT63_FOR_HS400,
> we can use the bit63 of caps for specifying HS400.
>
> But, this is not defined in the SDHCI standard.
> #define  SDHCI_SUPPORT_HS400 0x8000 /* Non-standard */
>
>
>
>>> +- mmc-ddr-1_8v
>
> For High Speed DDR, perhaps we can imply MMC_CAP_1_8V_DDR
> from MMC_CAP_UHS_DDR50  (bit34 of caps)
>
> This is not supported in the current code, but
> if this is a good idea, I can send a patch.
>
>
>>> +- mmc-ddr-1_2v
>
> This does not have the corresponding bit, but
> 1.2V is not commonly used, so this is not a fatal problem.
>
>
>
> What I can do at most now, is to delete the
> Optional properties section entirely
> so users can choose [1] or [2] as they like.
>

I think a better approach is to use the new sdhci-caps* bindings to
mask those caps that can't be trusted. And then use the generic mmc
bindings for speed modes instead.

That should be a safer approach, right!?

Kind regards
Uffe

Re: [PATCH] clk: imx: pllv3: support fractional multiplier on vf610 PLL1/PLL2

[Nikita Yushchenko]

>> diff --git a/drivers/clk/imx/clk-pllv3.c b/drivers/clk/imx/clk-pllv3.c
>> index 19f9b622981a..24a9e914e0d5 100644
>> --- a/drivers/clk/imx/clk-pllv3.c
>> +++ b/drivers/clk/imx/clk-pllv3.c
>> @@ -288,6 +291,87 @@ static const struct clk_ops clk_pllv3_av_ops = {
>>  .set_rate   = clk_pllv3_av_set_rate,
>>  };
>>  
>> +static unsigned long clk_pllv3_vf610_recalc_rate(struct clk_hw *hw,
>> +  unsigned long parent_rate)
>> +{
>> +struct clk_pllv3 *pll = to_clk_pllv3(hw);
>> +u32 mfn = readl_relaxed(pll->base + PLL_VF610_NUM_OFFSET);
>> +u32 mfd = readl_relaxed(pll->base + PLL_VF610_DENOM_OFFSET);
>> +u32 div = (readl_relaxed(pll->base) & pll->div_mask) ? 22 : 20;

Should be not 'div' but 'mfi' to be consistent with datasheet and with
other routines in the same patch. Will fix.

Re: [PATCH] clk: imx: pllv3: support fractional multiplier on vf610 PLL1/PLL2

[Nikita Yushchenko]

>> diff --git a/drivers/clk/imx/clk-pllv3.c b/drivers/clk/imx/clk-pllv3.c
>> index 19f9b622981a..24a9e914e0d5 100644
>> --- a/drivers/clk/imx/clk-pllv3.c
>> +++ b/drivers/clk/imx/clk-pllv3.c
>> @@ -288,6 +291,87 @@ static const struct clk_ops clk_pllv3_av_ops = {
>>  .set_rate   = clk_pllv3_av_set_rate,
>>  };
>>  
>> +static unsigned long clk_pllv3_vf610_recalc_rate(struct clk_hw *hw,
>> +  unsigned long parent_rate)
>> +{
>> +struct clk_pllv3 *pll = to_clk_pllv3(hw);
>> +u32 mfn = readl_relaxed(pll->base + PLL_VF610_NUM_OFFSET);
>> +u32 mfd = readl_relaxed(pll->base + PLL_VF610_DENOM_OFFSET);
>> +u32 div = (readl_relaxed(pll->base) & pll->div_mask) ? 22 : 20;

Should be not 'div' but 'mfi' to be consistent with datasheet and with
other routines in the same patch. Will fix.

Re: netlink: GPF in sock_sndtimeo

[Richard Guy Briggs]

On 2016-12-09 23:40, Cong Wang wrote:
> On Fri, Dec 9, 2016 at 8:13 PM, Cong Wang  wrote:
> > On Fri, Dec 9, 2016 at 3:01 AM, Richard Guy Briggs  wrote:
> >> On 2016-12-08 22:57, Cong Wang wrote:
> >>> On Thu, Dec 8, 2016 at 10:02 PM, Richard Guy Briggs  
> >>> wrote:
> >>> > I also tried to extend Cong Wang's idea to attempt to proactively 
> >>> > respond to a
> >>> > NETLINK_URELEASE on the audit_sock and reset it, but ran into a locking 
> >>> > error
> >>> > stack dump using mutex_lock(_cmd_mutex) in the notifier callback.
> >>> > Eliminating the lock since the sock is dead anways eliminates the error.
> >>> >
> >>> > Is it safe?  I'll resubmit if this looks remotely sane.  Meanwhile I'll 
> >>> > try to
> >>> > get the test case to compile.
> >>>
> >>> It doesn't look safe, because 'audit_sock', 'audit_nlk_portid' and 
> >>> 'audit_pid'
> >>> are updated as a whole and race between audit_receive_msg() and
> >>> NETLINK_URELEASE.
> >>
> >> This is what I expected and why I originally added the mutex lock in the
> >> callback...  The dumps I got were bare with no wrapper identifying the
> >> process context or specific error, so I'm at a bit of a loss how to
> >> solve this (without thinking more about it) other than instinctively
> >> removing the mutex.
> >
> > Netlink notifier can safely be converted to blocking one, I will send
> > a patch.
> >
> > But I seriously doubt you really need NETLINK_URELEASE here,
> > it adds nothing but overhead, b/c the netlink notifier is called on
> > every netlink socket in the system, but for net exit path, that is
> > relatively a slow path.
> >
> > Also, kauditd_send_skb() needs audit_cmd_mutex too.
> 
> Please let me know what you think about the attached patch?
> 
> Thanks!

> commit a12b43ee814625933ff155c20dc863c59cfcf240
> Author: Cong Wang 
> Date:   Fri Dec 9 17:56:42 2016 -0800
> 
> audit: close a race condition on audit_sock
> 
> Signed-off-by: Cong Wang 
> 
> diff --git a/kernel/audit.c b/kernel/audit.c
> index f1ca116..ab947d8 100644
> --- a/kernel/audit.c
> +++ b/kernel/audit.c
> @@ -423,6 +423,8 @@ static void kauditd_send_skb(struct sk_buff *skb)
>   snprintf(s, sizeof(s), "audit_pid=%d reset", 
> audit_pid);
>   audit_log_lost(s);
>   audit_pid = 0;
> + audit_nlk_portid = 0;
> + sock_put(audit_sock);
>   audit_sock = NULL;
>   } else {
>   pr_warn("re-scheduling(#%d) write to 
> audit_pid=%d\n",
> @@ -899,6 +901,9 @@ static int audit_receive_msg(struct sk_buff *skb, struct 
> nlmsghdr *nlh)
>   audit_log_config_change("audit_pid", new_pid, 
> audit_pid, 1);
>   audit_pid = new_pid;
>   audit_nlk_portid = NETLINK_CB(skb).portid;
> + sock_hold(skb->sk);
> + if (audit_sock)
> + sock_put(audit_sock);
>   audit_sock = skb->sk;
>   }
>   if (s.mask & AUDIT_STATUS_RATE_LIMIT) {
> @@ -1167,10 +1172,6 @@ static void __net_exit audit_net_exit(struct net *net)
>  {
>   struct audit_net *aunet = net_generic(net, audit_net_id);
>   struct sock *sock = aunet->nlsk;
> - if (sock == audit_sock) {
> - audit_pid = 0;
> - audit_sock = NULL;
> - }

So how does this not leak memory leaving the sock refcount incremented
by the registered audit daemon when that daemon shuts down normally?


- RGB

--
Richard Guy Briggs 
Kernel Security Engineering, Base Operating Systems, Red Hat
Remote, Ottawa, Canada
Voice: +1.647.777.2635, Internal: (81) 32635

Re: netlink: GPF in sock_sndtimeo

[Richard Guy Briggs]

On 2016-12-09 23:40, Cong Wang wrote:
> On Fri, Dec 9, 2016 at 8:13 PM, Cong Wang  wrote:
> > On Fri, Dec 9, 2016 at 3:01 AM, Richard Guy Briggs  wrote:
> >> On 2016-12-08 22:57, Cong Wang wrote:
> >>> On Thu, Dec 8, 2016 at 10:02 PM, Richard Guy Briggs  
> >>> wrote:
> >>> > I also tried to extend Cong Wang's idea to attempt to proactively 
> >>> > respond to a
> >>> > NETLINK_URELEASE on the audit_sock and reset it, but ran into a locking 
> >>> > error
> >>> > stack dump using mutex_lock(_cmd_mutex) in the notifier callback.
> >>> > Eliminating the lock since the sock is dead anways eliminates the error.
> >>> >
> >>> > Is it safe?  I'll resubmit if this looks remotely sane.  Meanwhile I'll 
> >>> > try to
> >>> > get the test case to compile.
> >>>
> >>> It doesn't look safe, because 'audit_sock', 'audit_nlk_portid' and 
> >>> 'audit_pid'
> >>> are updated as a whole and race between audit_receive_msg() and
> >>> NETLINK_URELEASE.
> >>
> >> This is what I expected and why I originally added the mutex lock in the
> >> callback...  The dumps I got were bare with no wrapper identifying the
> >> process context or specific error, so I'm at a bit of a loss how to
> >> solve this (without thinking more about it) other than instinctively
> >> removing the mutex.
> >
> > Netlink notifier can safely be converted to blocking one, I will send
> > a patch.
> >
> > But I seriously doubt you really need NETLINK_URELEASE here,
> > it adds nothing but overhead, b/c the netlink notifier is called on
> > every netlink socket in the system, but for net exit path, that is
> > relatively a slow path.
> >
> > Also, kauditd_send_skb() needs audit_cmd_mutex too.
> 
> Please let me know what you think about the attached patch?
> 
> Thanks!

> commit a12b43ee814625933ff155c20dc863c59cfcf240
> Author: Cong Wang 
> Date:   Fri Dec 9 17:56:42 2016 -0800
> 
> audit: close a race condition on audit_sock
> 
> Signed-off-by: Cong Wang 
> 
> diff --git a/kernel/audit.c b/kernel/audit.c
> index f1ca116..ab947d8 100644
> --- a/kernel/audit.c
> +++ b/kernel/audit.c
> @@ -423,6 +423,8 @@ static void kauditd_send_skb(struct sk_buff *skb)
>   snprintf(s, sizeof(s), "audit_pid=%d reset", 
> audit_pid);
>   audit_log_lost(s);
>   audit_pid = 0;
> + audit_nlk_portid = 0;
> + sock_put(audit_sock);
>   audit_sock = NULL;
>   } else {
>   pr_warn("re-scheduling(#%d) write to 
> audit_pid=%d\n",
> @@ -899,6 +901,9 @@ static int audit_receive_msg(struct sk_buff *skb, struct 
> nlmsghdr *nlh)
>   audit_log_config_change("audit_pid", new_pid, 
> audit_pid, 1);
>   audit_pid = new_pid;
>   audit_nlk_portid = NETLINK_CB(skb).portid;
> + sock_hold(skb->sk);
> + if (audit_sock)
> + sock_put(audit_sock);
>   audit_sock = skb->sk;
>   }
>   if (s.mask & AUDIT_STATUS_RATE_LIMIT) {
> @@ -1167,10 +1172,6 @@ static void __net_exit audit_net_exit(struct net *net)
>  {
>   struct audit_net *aunet = net_generic(net, audit_net_id);
>   struct sock *sock = aunet->nlsk;
> - if (sock == audit_sock) {
> - audit_pid = 0;
> - audit_sock = NULL;
> - }

So how does this not leak memory leaving the sock refcount incremented
by the registered audit daemon when that daemon shuts down normally?


- RGB

--
Richard Guy Briggs 
Kernel Security Engineering, Base Operating Systems, Red Hat
Remote, Ottawa, Canada
Voice: +1.647.777.2635, Internal: (81) 32635

Re: [PATCH] clk: imx: pllv3: support fractional multiplier on vf610 PLL1/PLL2

[Nikita Yushchenko]

>> diff --git a/drivers/clk/imx/clk-pllv3.c b/drivers/clk/imx/clk-pllv3.c
>> index 19f9b622981a..24a9e914e0d5 100644
>> --- a/drivers/clk/imx/clk-pllv3.c
>> +++ b/drivers/clk/imx/clk-pllv3.c
>> @@ -288,6 +291,87 @@ static const struct clk_ops clk_pllv3_av_ops = {
>>  .set_rate   = clk_pllv3_av_set_rate,
>>  };
>>  
>> +static unsigned long clk_pllv3_vf610_recalc_rate(struct clk_hw *hw,
>> +  unsigned long parent_rate)
>> +{
>> +struct clk_pllv3 *pll = to_clk_pllv3(hw);
>> +u32 mfn = readl_relaxed(pll->base + PLL_VF610_NUM_OFFSET);
>> +u32 mfd = readl_relaxed(pll->base + PLL_VF610_DENOM_OFFSET);
>> +u32 div = (readl_relaxed(pll->base) & pll->div_mask) ? 22 : 20;
>> +u64 temp64 = (u64)parent_rate;
> 
> Useless cast, please remove.

Ok

>> +
>> +temp64 *= mfn;
>> +do_div(temp64, mfd);
>> +
>> +return (parent_rate * div) + (u32)temp64;
>> +}
>> +
>> +static long clk_pllv3_vf610_round_rate(struct clk_hw *hw, unsigned long 
>> rate,
>> +unsigned long *prate)
>> +{
>> +unsigned long parent_rate = *prate;
>> +unsigned int mfi = (rate >= 22 * parent_rate) ? 22 : 20;
> 
> What is the importance of 22 and 20? Hint, at the least it needs
> a comment.

These come directly from datasheet:

Frequency multipler selection (MFI).
0: Fout = Fref * 20
1: Fout = Fref * 22

These numbers (20 / 22) are common among flavours of pllv3 hardware.
In similar places in the same file (e.g. in clk_pllv3_recalc_rate(), in
clk_pllv3_set_rate() ,etc) there are no comments explaining them.

Are you sure this place is special and comment is needed here?

>> +u32 mfn, mfd = 0x3fff;
>> +u64 temp64;
>> +
>> +if (rate <= parent_rate * mfi)
>> +mfn = 0;
>> +else if (rate >= parent_rate * (mfi + 1))
>> +mfn = mfd - 1;
>> +else {
>> +/* rate = parent_rate * (mfi + mfn/mfd) */
>> +temp64 = rate - parent_rate * mfi;
>> +temp64 *= mfd;
>> +do_div(temp64, parent_rate);
>> +mfn = temp64;
>> +}
>> +
>> +temp64 = ((u64)mfd * mfi + mfn) * parent_rate;
>> +do_div(temp64, mfd);
>> +return (u32)temp64;
> 
> Do we need the cast here for some reason?

Just for readability, can remove if it hurts.

>> +}
>> +
>> +static int clk_pllv3_vf610_set_rate(struct clk_hw *hw, unsigned long rate,
>> +unsigned long parent_rate)
>> +{
>> +struct clk_pllv3 *pll = to_clk_pllv3(hw);
>> +unsigned int mfi = (rate >= 22 * parent_rate) ? 22 : 20;
>> +u32 val, mfn, mfd = 0x3fff;
>> +u64 temp64;
>> +
>> +if (rate <= parent_rate * mfi)
>> +mfn = 0;
>> +else if (rate >= parent_rate * (mfi + 1))
>> +mfn = mfd - 1;
>> +else {
>> +/* rate = parent_rate * (mfi + mfn/mfd) */
>> +temp64 = rate - parent_rate * mfi;
>> +temp64 *= mfd;
>> +do_div(temp64, parent_rate);
>> +mfn = temp64;
>> +}
>> +
>> +val = readl_relaxed(pll->base);
>> +if (mfi == 20)
> 
> Presumably this is another place 20 and 22 are special.

See my reply above. Same applies here.

Nikita

Re: [PATCH] clk: imx: pllv3: support fractional multiplier on vf610 PLL1/PLL2

[Nikita Yushchenko]

>> diff --git a/drivers/clk/imx/clk-pllv3.c b/drivers/clk/imx/clk-pllv3.c
>> index 19f9b622981a..24a9e914e0d5 100644
>> --- a/drivers/clk/imx/clk-pllv3.c
>> +++ b/drivers/clk/imx/clk-pllv3.c
>> @@ -288,6 +291,87 @@ static const struct clk_ops clk_pllv3_av_ops = {
>>  .set_rate   = clk_pllv3_av_set_rate,
>>  };
>>  
>> +static unsigned long clk_pllv3_vf610_recalc_rate(struct clk_hw *hw,
>> +  unsigned long parent_rate)
>> +{
>> +struct clk_pllv3 *pll = to_clk_pllv3(hw);
>> +u32 mfn = readl_relaxed(pll->base + PLL_VF610_NUM_OFFSET);
>> +u32 mfd = readl_relaxed(pll->base + PLL_VF610_DENOM_OFFSET);
>> +u32 div = (readl_relaxed(pll->base) & pll->div_mask) ? 22 : 20;
>> +u64 temp64 = (u64)parent_rate;
> 
> Useless cast, please remove.

Ok

>> +
>> +temp64 *= mfn;
>> +do_div(temp64, mfd);
>> +
>> +return (parent_rate * div) + (u32)temp64;
>> +}
>> +
>> +static long clk_pllv3_vf610_round_rate(struct clk_hw *hw, unsigned long 
>> rate,
>> +unsigned long *prate)
>> +{
>> +unsigned long parent_rate = *prate;
>> +unsigned int mfi = (rate >= 22 * parent_rate) ? 22 : 20;
> 
> What is the importance of 22 and 20? Hint, at the least it needs
> a comment.

These come directly from datasheet:

Frequency multipler selection (MFI).
0: Fout = Fref * 20
1: Fout = Fref * 22

These numbers (20 / 22) are common among flavours of pllv3 hardware.
In similar places in the same file (e.g. in clk_pllv3_recalc_rate(), in
clk_pllv3_set_rate() ,etc) there are no comments explaining them.

Are you sure this place is special and comment is needed here?

>> +u32 mfn, mfd = 0x3fff;
>> +u64 temp64;
>> +
>> +if (rate <= parent_rate * mfi)
>> +mfn = 0;
>> +else if (rate >= parent_rate * (mfi + 1))
>> +mfn = mfd - 1;
>> +else {
>> +/* rate = parent_rate * (mfi + mfn/mfd) */
>> +temp64 = rate - parent_rate * mfi;
>> +temp64 *= mfd;
>> +do_div(temp64, parent_rate);
>> +mfn = temp64;
>> +}
>> +
>> +temp64 = ((u64)mfd * mfi + mfn) * parent_rate;
>> +do_div(temp64, mfd);
>> +return (u32)temp64;
> 
> Do we need the cast here for some reason?

Just for readability, can remove if it hurts.

>> +}
>> +
>> +static int clk_pllv3_vf610_set_rate(struct clk_hw *hw, unsigned long rate,
>> +unsigned long parent_rate)
>> +{
>> +struct clk_pllv3 *pll = to_clk_pllv3(hw);
>> +unsigned int mfi = (rate >= 22 * parent_rate) ? 22 : 20;
>> +u32 val, mfn, mfd = 0x3fff;
>> +u64 temp64;
>> +
>> +if (rate <= parent_rate * mfi)
>> +mfn = 0;
>> +else if (rate >= parent_rate * (mfi + 1))
>> +mfn = mfd - 1;
>> +else {
>> +/* rate = parent_rate * (mfi + mfn/mfd) */
>> +temp64 = rate - parent_rate * mfi;
>> +temp64 *= mfd;
>> +do_div(temp64, parent_rate);
>> +mfn = temp64;
>> +}
>> +
>> +val = readl_relaxed(pll->base);
>> +if (mfi == 20)
> 
> Presumably this is another place 20 and 22 are special.

See my reply above. Same applies here.

Nikita

[PATCH v5 1/2] usb: host: plat: Enable xhci plat runtime PM

[Baolin Wang]

Enable the xhci plat runtime PM for parent device to suspend/resume xhci.
Also call pm_runtime_get_noresume() in probe() function in case the parent
device doesn't call suspend/resume callback by runtime PM now.

Signed-off-by: Baolin Wang 
---
Changes since v4:
 - No updates.

Changes since v3:
 - Fix kbuild error.

Changes since v2:
 - Add pm_runtime_get_noresume() in probe() function.
 - Add pm_runtime_set_suspended()/pm_runtime_put_noidle() in remove() function.

Changes since v1:
 - No updates.
---
 drivers/usb/host/xhci-plat.c |   41 -
 1 file changed, 36 insertions(+), 5 deletions(-)

diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c
index ed56bf9..5805c6a 100644
--- a/drivers/usb/host/xhci-plat.c
+++ b/drivers/usb/host/xhci-plat.c
@@ -246,6 +246,10 @@ static int xhci_plat_probe(struct platform_device *pdev)
if (ret)
goto dealloc_usb2_hcd;
 
+   pm_runtime_get_noresume(>dev);
+   pm_runtime_set_active(>dev);
+   pm_runtime_enable(>dev);
+
return 0;
 
 
@@ -274,6 +278,10 @@ static int xhci_plat_remove(struct platform_device *dev)
struct xhci_hcd *xhci = hcd_to_xhci(hcd);
struct clk *clk = xhci->clk;
 
+   pm_runtime_set_suspended(>dev);
+   pm_runtime_put_noidle(>dev);
+   pm_runtime_disable(>dev);
+
usb_remove_hcd(xhci->shared_hcd);
usb_phy_shutdown(hcd->usb_phy);
 
@@ -311,14 +319,37 @@ static int xhci_plat_resume(struct device *dev)
 
return xhci_resume(xhci, 0);
 }
+#endif /* CONFIG_PM_SLEEP */
+
+#ifdef CONFIG_PM
+static int xhci_plat_runtime_suspend(struct device *dev)
+{
+   struct usb_hcd  *hcd = dev_get_drvdata(dev);
+   struct xhci_hcd *xhci = hcd_to_xhci(hcd);
+
+   return xhci_suspend(xhci, device_may_wakeup(dev));
+}
+
+static int xhci_plat_runtime_resume(struct device *dev)
+{
+   struct usb_hcd  *hcd = dev_get_drvdata(dev);
+   struct xhci_hcd *xhci = hcd_to_xhci(hcd);
+
+   return xhci_resume(xhci, 0);
+}
+
+static int xhci_plat_runtime_idle(struct device *dev)
+{
+   return 0;
+}
+#endif /* CONFIG_PM */
 
 static const struct dev_pm_ops xhci_plat_pm_ops = {
SET_SYSTEM_SLEEP_PM_OPS(xhci_plat_suspend, xhci_plat_resume)
+
+   SET_RUNTIME_PM_OPS(xhci_plat_runtime_suspend, xhci_plat_runtime_resume,
+  xhci_plat_runtime_idle)
 };
-#define DEV_PM_OPS (_plat_pm_ops)
-#else
-#define DEV_PM_OPS NULL
-#endif /* CONFIG_PM */
 
 static const struct acpi_device_id usb_xhci_acpi_match[] = {
/* XHCI-compliant USB Controller */
@@ -332,7 +363,7 @@ static int xhci_plat_resume(struct device *dev)
.remove = xhci_plat_remove,
.driver = {
.name = "xhci-hcd",
-   .pm = DEV_PM_OPS,
+   .pm = _plat_pm_ops,
.of_match_table = of_match_ptr(usb_xhci_of_match),
.acpi_match_table = ACPI_PTR(usb_xhci_acpi_match),
},
-- 
1.7.9.5

[PATCH v5 2/2] usb: dwc3: core: Support the dwc3 host suspend/resume

[Baolin Wang]

For some mobile devices with strict power management, we also want to suspend
the host when the slave is detached for power saving. Thus we add the host
suspend/resume functions to support this requirement.

Signed-off-by: Baolin Wang 
---
Changes since v4:
 - Remove Kconfig and just enable host suspend/resume.
 - Simplify the dwc3_host_suspend/resume() function.

Changes since v3:
 - No updates.

Changes since v2:
 - Remove pm_children_suspended() and other unused macros.

Changes since v1:
 - Add pm_runtime.h head file to avoid kbuild error.
---
 drivers/usb/dwc3/core.c |   26 +-
 drivers/usb/dwc3/core.h |7 +++
 drivers/usb/dwc3/host.c |   21 +
 3 files changed, 53 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index 9a4a5e4..7ad4bc3 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -1091,6 +1091,7 @@ static int dwc3_probe(struct platform_device *pdev)
pm_runtime_use_autosuspend(dev);
pm_runtime_set_autosuspend_delay(dev, DWC3_DEFAULT_AUTOSUSPEND_DELAY);
pm_runtime_enable(dev);
+   pm_suspend_ignore_children(dev, true);
ret = pm_runtime_get_sync(dev);
if (ret < 0)
goto err1;
@@ -1215,15 +1216,27 @@ static int dwc3_remove(struct platform_device *pdev)
 static int dwc3_suspend_common(struct dwc3 *dwc)
 {
unsigned long   flags;
+   int ret;
 
switch (dwc->dr_mode) {
case USB_DR_MODE_PERIPHERAL:
+   spin_lock_irqsave(>lock, flags);
+   dwc3_gadget_suspend(dwc);
+   spin_unlock_irqrestore(>lock, flags);
+   break;
case USB_DR_MODE_OTG:
+   ret = dwc3_host_suspend(dwc);
+   if (ret)
+   return ret;
+
spin_lock_irqsave(>lock, flags);
dwc3_gadget_suspend(dwc);
spin_unlock_irqrestore(>lock, flags);
break;
case USB_DR_MODE_HOST:
+   ret = dwc3_host_suspend(dwc);
+   if (ret)
+   return ret;
default:
/* do nothing */
break;
@@ -1245,12 +1258,23 @@ static int dwc3_resume_common(struct dwc3 *dwc)
 
switch (dwc->dr_mode) {
case USB_DR_MODE_PERIPHERAL:
+   spin_lock_irqsave(>lock, flags);
+   dwc3_gadget_resume(dwc);
+   spin_unlock_irqrestore(>lock, flags);
+   break;
case USB_DR_MODE_OTG:
+   ret = dwc3_host_resume(dwc);
+   if (ret)
+   return ret;
+
spin_lock_irqsave(>lock, flags);
dwc3_gadget_resume(dwc);
spin_unlock_irqrestore(>lock, flags);
-   /* FALLTHROUGH */
+   break;
case USB_DR_MODE_HOST:
+   ret = dwc3_host_resume(dwc);
+   if (ret)
+   return ret;
default:
/* do nothing */
break;
diff --git a/drivers/usb/dwc3/core.h b/drivers/usb/dwc3/core.h
index b585a30..1099168 100644
--- a/drivers/usb/dwc3/core.h
+++ b/drivers/usb/dwc3/core.h
@@ -1158,11 +1158,18 @@ static inline bool dwc3_is_usb31(struct dwc3 *dwc)
 #if IS_ENABLED(CONFIG_USB_DWC3_HOST) || IS_ENABLED(CONFIG_USB_DWC3_DUAL_ROLE)
 int dwc3_host_init(struct dwc3 *dwc);
 void dwc3_host_exit(struct dwc3 *dwc);
+int dwc3_host_suspend(struct dwc3 *dwc);
+int dwc3_host_resume(struct dwc3 *dwc);
 #else
 static inline int dwc3_host_init(struct dwc3 *dwc)
 { return 0; }
 static inline void dwc3_host_exit(struct dwc3 *dwc)
 { }
+
+static inline int dwc3_host_suspend(struct dwc3 *dwc)
+{ return 0; }
+static inline int dwc3_host_resume(struct dwc3 *dwc)
+{ return 0; }
 #endif
 
 #if IS_ENABLED(CONFIG_USB_DWC3_GADGET) || IS_ENABLED(CONFIG_USB_DWC3_DUAL_ROLE)
diff --git a/drivers/usb/dwc3/host.c b/drivers/usb/dwc3/host.c
index ed82464..7959ef0 100644
--- a/drivers/usb/dwc3/host.c
+++ b/drivers/usb/dwc3/host.c
@@ -16,6 +16,7 @@
  */
 
 #include 
+#include 
 
 #include "core.h"
 
@@ -130,3 +131,23 @@ void dwc3_host_exit(struct dwc3 *dwc)
  dev_name(>xhci->dev));
platform_device_unregister(dwc->xhci);
 }
+
+int dwc3_host_suspend(struct dwc3 *dwc)
+{
+   struct device *xhci = >xhci->dev;
+
+   /*
+* Note: if we get the -EBUSY, which means the xHCI children devices are
+* not in suspend state yet, the glue layer need to wait for a while and
+* try to suspend xHCI device again.
+*/
+   return pm_runtime_put_sync(xhci);
+}
+
+int dwc3_host_resume(struct dwc3 *dwc)
+{
+   struct device *xhci = >xhci->dev;
+
+   /* Resume the xHCI device synchronously. */
+   return pm_runtime_get_sync(xhci);
+}
-- 
1.7.9.5

[PATCH v5 2/2] usb: dwc3: core: Support the dwc3 host suspend/resume

[Baolin Wang]

For some mobile devices with strict power management, we also want to suspend
the host when the slave is detached for power saving. Thus we add the host
suspend/resume functions to support this requirement.

Signed-off-by: Baolin Wang 
---
Changes since v4:
 - Remove Kconfig and just enable host suspend/resume.
 - Simplify the dwc3_host_suspend/resume() function.

Changes since v3:
 - No updates.

Changes since v2:
 - Remove pm_children_suspended() and other unused macros.

Changes since v1:
 - Add pm_runtime.h head file to avoid kbuild error.
---
 drivers/usb/dwc3/core.c |   26 +-
 drivers/usb/dwc3/core.h |7 +++
 drivers/usb/dwc3/host.c |   21 +
 3 files changed, 53 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index 9a4a5e4..7ad4bc3 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -1091,6 +1091,7 @@ static int dwc3_probe(struct platform_device *pdev)
pm_runtime_use_autosuspend(dev);
pm_runtime_set_autosuspend_delay(dev, DWC3_DEFAULT_AUTOSUSPEND_DELAY);
pm_runtime_enable(dev);
+   pm_suspend_ignore_children(dev, true);
ret = pm_runtime_get_sync(dev);
if (ret < 0)
goto err1;
@@ -1215,15 +1216,27 @@ static int dwc3_remove(struct platform_device *pdev)
 static int dwc3_suspend_common(struct dwc3 *dwc)
 {
unsigned long   flags;
+   int ret;
 
switch (dwc->dr_mode) {
case USB_DR_MODE_PERIPHERAL:
+   spin_lock_irqsave(>lock, flags);
+   dwc3_gadget_suspend(dwc);
+   spin_unlock_irqrestore(>lock, flags);
+   break;
case USB_DR_MODE_OTG:
+   ret = dwc3_host_suspend(dwc);
+   if (ret)
+   return ret;
+
spin_lock_irqsave(>lock, flags);
dwc3_gadget_suspend(dwc);
spin_unlock_irqrestore(>lock, flags);
break;
case USB_DR_MODE_HOST:
+   ret = dwc3_host_suspend(dwc);
+   if (ret)
+   return ret;
default:
/* do nothing */
break;
@@ -1245,12 +1258,23 @@ static int dwc3_resume_common(struct dwc3 *dwc)
 
switch (dwc->dr_mode) {
case USB_DR_MODE_PERIPHERAL:
+   spin_lock_irqsave(>lock, flags);
+   dwc3_gadget_resume(dwc);
+   spin_unlock_irqrestore(>lock, flags);
+   break;
case USB_DR_MODE_OTG:
+   ret = dwc3_host_resume(dwc);
+   if (ret)
+   return ret;
+
spin_lock_irqsave(>lock, flags);
dwc3_gadget_resume(dwc);
spin_unlock_irqrestore(>lock, flags);
-   /* FALLTHROUGH */
+   break;
case USB_DR_MODE_HOST:
+   ret = dwc3_host_resume(dwc);
+   if (ret)
+   return ret;
default:
/* do nothing */
break;
diff --git a/drivers/usb/dwc3/core.h b/drivers/usb/dwc3/core.h
index b585a30..1099168 100644
--- a/drivers/usb/dwc3/core.h
+++ b/drivers/usb/dwc3/core.h
@@ -1158,11 +1158,18 @@ static inline bool dwc3_is_usb31(struct dwc3 *dwc)
 #if IS_ENABLED(CONFIG_USB_DWC3_HOST) || IS_ENABLED(CONFIG_USB_DWC3_DUAL_ROLE)
 int dwc3_host_init(struct dwc3 *dwc);
 void dwc3_host_exit(struct dwc3 *dwc);
+int dwc3_host_suspend(struct dwc3 *dwc);
+int dwc3_host_resume(struct dwc3 *dwc);
 #else
 static inline int dwc3_host_init(struct dwc3 *dwc)
 { return 0; }
 static inline void dwc3_host_exit(struct dwc3 *dwc)
 { }
+
+static inline int dwc3_host_suspend(struct dwc3 *dwc)
+{ return 0; }
+static inline int dwc3_host_resume(struct dwc3 *dwc)
+{ return 0; }
 #endif
 
 #if IS_ENABLED(CONFIG_USB_DWC3_GADGET) || IS_ENABLED(CONFIG_USB_DWC3_DUAL_ROLE)
diff --git a/drivers/usb/dwc3/host.c b/drivers/usb/dwc3/host.c
index ed82464..7959ef0 100644
--- a/drivers/usb/dwc3/host.c
+++ b/drivers/usb/dwc3/host.c
@@ -16,6 +16,7 @@
  */
 
 #include 
+#include 
 
 #include "core.h"
 
@@ -130,3 +131,23 @@ void dwc3_host_exit(struct dwc3 *dwc)
  dev_name(>xhci->dev));
platform_device_unregister(dwc->xhci);
 }
+
+int dwc3_host_suspend(struct dwc3 *dwc)
+{
+   struct device *xhci = >xhci->dev;
+
+   /*
+* Note: if we get the -EBUSY, which means the xHCI children devices are
+* not in suspend state yet, the glue layer need to wait for a while and
+* try to suspend xHCI device again.
+*/
+   return pm_runtime_put_sync(xhci);
+}
+
+int dwc3_host_resume(struct dwc3 *dwc)
+{
+   struct device *xhci = >xhci->dev;
+
+   /* Resume the xHCI device synchronously. */
+   return pm_runtime_get_sync(xhci);
+}
-- 
1.7.9.5

[PATCH v5 1/2] usb: host: plat: Enable xhci plat runtime PM

[Baolin Wang]

Enable the xhci plat runtime PM for parent device to suspend/resume xhci.
Also call pm_runtime_get_noresume() in probe() function in case the parent
device doesn't call suspend/resume callback by runtime PM now.

Signed-off-by: Baolin Wang 
---
Changes since v4:
 - No updates.

Changes since v3:
 - Fix kbuild error.

Changes since v2:
 - Add pm_runtime_get_noresume() in probe() function.
 - Add pm_runtime_set_suspended()/pm_runtime_put_noidle() in remove() function.

Changes since v1:
 - No updates.
---
 drivers/usb/host/xhci-plat.c |   41 -
 1 file changed, 36 insertions(+), 5 deletions(-)

diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c
index ed56bf9..5805c6a 100644
--- a/drivers/usb/host/xhci-plat.c
+++ b/drivers/usb/host/xhci-plat.c
@@ -246,6 +246,10 @@ static int xhci_plat_probe(struct platform_device *pdev)
if (ret)
goto dealloc_usb2_hcd;
 
+   pm_runtime_get_noresume(>dev);
+   pm_runtime_set_active(>dev);
+   pm_runtime_enable(>dev);
+
return 0;
 
 
@@ -274,6 +278,10 @@ static int xhci_plat_remove(struct platform_device *dev)
struct xhci_hcd *xhci = hcd_to_xhci(hcd);
struct clk *clk = xhci->clk;
 
+   pm_runtime_set_suspended(>dev);
+   pm_runtime_put_noidle(>dev);
+   pm_runtime_disable(>dev);
+
usb_remove_hcd(xhci->shared_hcd);
usb_phy_shutdown(hcd->usb_phy);
 
@@ -311,14 +319,37 @@ static int xhci_plat_resume(struct device *dev)
 
return xhci_resume(xhci, 0);
 }
+#endif /* CONFIG_PM_SLEEP */
+
+#ifdef CONFIG_PM
+static int xhci_plat_runtime_suspend(struct device *dev)
+{
+   struct usb_hcd  *hcd = dev_get_drvdata(dev);
+   struct xhci_hcd *xhci = hcd_to_xhci(hcd);
+
+   return xhci_suspend(xhci, device_may_wakeup(dev));
+}
+
+static int xhci_plat_runtime_resume(struct device *dev)
+{
+   struct usb_hcd  *hcd = dev_get_drvdata(dev);
+   struct xhci_hcd *xhci = hcd_to_xhci(hcd);
+
+   return xhci_resume(xhci, 0);
+}
+
+static int xhci_plat_runtime_idle(struct device *dev)
+{
+   return 0;
+}
+#endif /* CONFIG_PM */
 
 static const struct dev_pm_ops xhci_plat_pm_ops = {
SET_SYSTEM_SLEEP_PM_OPS(xhci_plat_suspend, xhci_plat_resume)
+
+   SET_RUNTIME_PM_OPS(xhci_plat_runtime_suspend, xhci_plat_runtime_resume,
+  xhci_plat_runtime_idle)
 };
-#define DEV_PM_OPS (_plat_pm_ops)
-#else
-#define DEV_PM_OPS NULL
-#endif /* CONFIG_PM */
 
 static const struct acpi_device_id usb_xhci_acpi_match[] = {
/* XHCI-compliant USB Controller */
@@ -332,7 +363,7 @@ static int xhci_plat_resume(struct device *dev)
.remove = xhci_plat_remove,
.driver = {
.name = "xhci-hcd",
-   .pm = DEV_PM_OPS,
+   .pm = _plat_pm_ops,
.of_match_table = of_match_ptr(usb_xhci_of_match),
.acpi_match_table = ACPI_PTR(usb_xhci_acpi_match),
},
-- 
1.7.9.5

Re: epoll_wait inaccurate timeout

[Dmitry Banschikov]

On Mon, Dec 12, 2016 at 2:34 PM, Eric Wong  wrote:
> +Cc folks who may know about timer stuff on epoll.
>
> Dmitry Banschikov  wrote:
>> Hi!
>>
>> I have a problem caused by inaccurate timeouts in epoll_wait(2).
>> Here are some parts of strace -tt output:
>
> Which kernel version are you using?

I was able to reproduce this problem in 4.4.0(Ubuntu 16.04) and
3.10.0(CentOS 7.2.1511) on
two different x86_64 machines.

>
>> 22578 09:33:46.959791 epoll_wait(5,  
>> 22578 09:33:50.010794 <... epoll_wait resumed> [], 128, 1498) = 0
>> ...
>> 22034 09:35:07.686896 epoll_wait(5,  
>> 22034 09:35:09.482526 <... epoll_wait resumed> [{EPOLLIN,
>> {u32=151458248, u64=151458248}}], 128, 362) = 1
>> ...
>> 22036 09:35:41.433241 epoll_wait(5,  
>> 22036 09:35:43.176881 <... epoll_wait resumed> [], 128, 97) = 0
>>
>> In each example epoll_wait is blocked for too longer then asked in timeout.
>>
>> Is it normal?
>
> I don't think so, unless you have a huge /proc//timerslack_ns
> set.  But I mainly use -1 or 0 as the timeout value.

/proc//timerslack_ns interface was added in 4.6.
For sure I can try to reproduce problem on fresh kernel if it can help
debugging.

I observe such epoll_wait behavior quite rarely - usually
one/two/three times per
hours of attempts to reproduce. And from strace output I can see that
system is not in state of resource starvation - because other threads
do some work
between call and return to/from epoll_wait.

Such timeout values for epoll_wait are generated by Boost ASIO library.
Internally it uses priority queue for storing timer events and use timeout to
nearest event from queue in epoll_wait.

What information can help to debug this issue?


>
>> Please CC me.
>
> That's standard procedure, here :)



-- 

Dmitry Banschikov

Re: epoll_wait inaccurate timeout

[Dmitry Banschikov]

On Mon, Dec 12, 2016 at 2:34 PM, Eric Wong  wrote:
> +Cc folks who may know about timer stuff on epoll.
>
> Dmitry Banschikov  wrote:
>> Hi!
>>
>> I have a problem caused by inaccurate timeouts in epoll_wait(2).
>> Here are some parts of strace -tt output:
>
> Which kernel version are you using?

I was able to reproduce this problem in 4.4.0(Ubuntu 16.04) and
3.10.0(CentOS 7.2.1511) on
two different x86_64 machines.

>
>> 22578 09:33:46.959791 epoll_wait(5,  
>> 22578 09:33:50.010794 <... epoll_wait resumed> [], 128, 1498) = 0
>> ...
>> 22034 09:35:07.686896 epoll_wait(5,  
>> 22034 09:35:09.482526 <... epoll_wait resumed> [{EPOLLIN,
>> {u32=151458248, u64=151458248}}], 128, 362) = 1
>> ...
>> 22036 09:35:41.433241 epoll_wait(5,  
>> 22036 09:35:43.176881 <... epoll_wait resumed> [], 128, 97) = 0
>>
>> In each example epoll_wait is blocked for too longer then asked in timeout.
>>
>> Is it normal?
>
> I don't think so, unless you have a huge /proc//timerslack_ns
> set.  But I mainly use -1 or 0 as the timeout value.

/proc//timerslack_ns interface was added in 4.6.
For sure I can try to reproduce problem on fresh kernel if it can help
debugging.

I observe such epoll_wait behavior quite rarely - usually
one/two/three times per
hours of attempts to reproduce. And from strace output I can see that
system is not in state of resource starvation - because other threads
do some work
between call and return to/from epoll_wait.

Such timeout values for epoll_wait are generated by Boost ASIO library.
Internally it uses priority queue for storing timer events and use timeout to
nearest event from queue in epoll_wait.

What information can help to debug this issue?


>
>> Please CC me.
>
> That's standard procedure, here :)



-- 

Dmitry Banschikov

[PATCHv2 4/5] perf tools: Allow to ignore missing pid

[Jiri Olsa]

On Tue, Dec 13, 2016 at 01:58:25AM +0900, Namhyung Kim wrote:

SNIP

> >  }
> >  
> > +static bool ignore_missing_thread(struct perf_evsel *evsel,
> > + struct thread_map *threads,
> > + int thread, int err)
> > +{
> > +   if (!evsel->ignore_missing_thread)
> > +   return false;
> > +
> > +   /* The system wide setup does not work with threads. */
> > +   if (!evsel->system_wide)
> > +   return false;
> 
> I'm bit confused with this.  Shouldn't the condition be positive?
> 

ugh, right.. that was last minute change, I had this condition
below together with ignore_missing_thread call and moved it up :-\

thanks for spotting this, attaching v2

jirka


---
Adding perf_evsel::ignore_missing_cpu_thread bool.

When set true, it allows perf to ignore error of missing
pid of perf event syscall.

We remove missing thread id from the thread_map, so the
rest of the processing like ioctl and mmap won't get
disturbed with -1 fd.

The reason for supporting this is to ease up monitoring
group of pids, that 'disappear' before perf opens their
event. This currently leads perf to report error and exit
and makes perf record's -u option unusable under certain
setup.

With this change we will allow this race and ignore such
failure with following warning:

  WARNING: Ignored open failure for pid 8605

Signed-off-by: Jiri Olsa 
Cc: David Ahern 
Cc: Namhyung Kim 
Cc: Peter Zijlstra 
Link: http://lkml.kernel.org/n/tip-atmzsjyhrt1j6xjwwmb84...@git.kernel.org
---
 tools/perf/perf.h   |  1 +
 tools/perf/util/evsel.c | 44 
 tools/perf/util/evsel.h |  1 +
 3 files changed, 46 insertions(+)

diff --git a/tools/perf/perf.h b/tools/perf/perf.h
index 9a0236a4cf95..1c27d947c2fe 100644
--- a/tools/perf/perf.h
+++ b/tools/perf/perf.h
@@ -55,6 +55,7 @@ struct record_opts {
bool all_user;
bool tail_synthesize;
bool overwrite;
+   bool ignore_missing_thread;
unsigned int freq;
unsigned int mmap_pages;
unsigned int auxtrace_mmap_pages;
diff --git a/tools/perf/util/evsel.c b/tools/perf/util/evsel.c
index fd61ebd77c26..04e536ae4d88 100644
--- a/tools/perf/util/evsel.c
+++ b/tools/perf/util/evsel.c
@@ -990,6 +990,8 @@ void perf_evsel__config(struct perf_evsel *evsel, struct 
record_opts *opts,
 * it overloads any global configuration.
 */
apply_config_terms(evsel, opts);
+
+   evsel->ignore_missing_thread = opts->ignore_missing_thread;
 }
 
 static int perf_evsel__alloc_fd(struct perf_evsel *evsel, int ncpus, int 
nthreads)
@@ -1419,6 +1421,33 @@ static int __open_attr__fprintf(FILE *fp, const char 
*name, const char *val,
return fprintf(fp, "  %-32s %s\n", name, val);
 }
 
+static bool ignore_missing_thread(struct perf_evsel *evsel,
+ struct thread_map *threads,
+ int thread, int err)
+{
+   if (!evsel->ignore_missing_thread)
+   return false;
+
+   /* The system wide setup does not work with threads. */
+   if (evsel->system_wide)
+   return false;
+
+   /* The -ESRCH is perf event syscall errno for pid's not found. */
+   if (err != -ESRCH)
+   return false;
+
+   /* If there's only one thread, let it fail. */
+   if (threads->nr == 1)
+   return false;
+
+   if (thread_map__remove(threads, thread))
+   return false;
+
+   pr_warning("WARNING: Ignored open failure for pid %d\n",
+  thread_map__pid(threads, thread));
+   return true;
+}
+
 static int __perf_evsel__open(struct perf_evsel *evsel, struct cpu_map *cpus,
  struct thread_map *threads)
 {
@@ -1491,6 +1520,21 @@ static int __perf_evsel__open(struct perf_evsel *evsel, 
struct cpu_map *cpus,
 
if (fd < 0) {
err = -errno;
+
+   if (ignore_missing_thread(evsel, threads, 
thread, err)) {
+   /*
+* We just removed 1 thread, so take a 
step
+* back on thread index and lower the 
upper
+* nthreads limit.
+*/
+   nthreads--;
+   thread--;
+
+   /* ... and pretend like nothing have 
happened. */
+   err = 0;
+   continue;
+   }
+
pr_debug2("\nsys_perf_event_open failed, error 
%d\n",
  err);

[PATCHv2 4/5] perf tools: Allow to ignore missing pid

[Jiri Olsa]

On Tue, Dec 13, 2016 at 01:58:25AM +0900, Namhyung Kim wrote:

SNIP

> >  }
> >  
> > +static bool ignore_missing_thread(struct perf_evsel *evsel,
> > + struct thread_map *threads,
> > + int thread, int err)
> > +{
> > +   if (!evsel->ignore_missing_thread)
> > +   return false;
> > +
> > +   /* The system wide setup does not work with threads. */
> > +   if (!evsel->system_wide)
> > +   return false;
> 
> I'm bit confused with this.  Shouldn't the condition be positive?
> 

ugh, right.. that was last minute change, I had this condition
below together with ignore_missing_thread call and moved it up :-\

thanks for spotting this, attaching v2

jirka


---
Adding perf_evsel::ignore_missing_cpu_thread bool.

When set true, it allows perf to ignore error of missing
pid of perf event syscall.

We remove missing thread id from the thread_map, so the
rest of the processing like ioctl and mmap won't get
disturbed with -1 fd.

The reason for supporting this is to ease up monitoring
group of pids, that 'disappear' before perf opens their
event. This currently leads perf to report error and exit
and makes perf record's -u option unusable under certain
setup.

With this change we will allow this race and ignore such
failure with following warning:

  WARNING: Ignored open failure for pid 8605

Signed-off-by: Jiri Olsa 
Cc: David Ahern 
Cc: Namhyung Kim 
Cc: Peter Zijlstra 
Link: http://lkml.kernel.org/n/tip-atmzsjyhrt1j6xjwwmb84...@git.kernel.org
---
 tools/perf/perf.h   |  1 +
 tools/perf/util/evsel.c | 44 
 tools/perf/util/evsel.h |  1 +
 3 files changed, 46 insertions(+)

diff --git a/tools/perf/perf.h b/tools/perf/perf.h
index 9a0236a4cf95..1c27d947c2fe 100644
--- a/tools/perf/perf.h
+++ b/tools/perf/perf.h
@@ -55,6 +55,7 @@ struct record_opts {
bool all_user;
bool tail_synthesize;
bool overwrite;
+   bool ignore_missing_thread;
unsigned int freq;
unsigned int mmap_pages;
unsigned int auxtrace_mmap_pages;
diff --git a/tools/perf/util/evsel.c b/tools/perf/util/evsel.c
index fd61ebd77c26..04e536ae4d88 100644
--- a/tools/perf/util/evsel.c
+++ b/tools/perf/util/evsel.c
@@ -990,6 +990,8 @@ void perf_evsel__config(struct perf_evsel *evsel, struct 
record_opts *opts,
 * it overloads any global configuration.
 */
apply_config_terms(evsel, opts);
+
+   evsel->ignore_missing_thread = opts->ignore_missing_thread;
 }
 
 static int perf_evsel__alloc_fd(struct perf_evsel *evsel, int ncpus, int 
nthreads)
@@ -1419,6 +1421,33 @@ static int __open_attr__fprintf(FILE *fp, const char 
*name, const char *val,
return fprintf(fp, "  %-32s %s\n", name, val);
 }
 
+static bool ignore_missing_thread(struct perf_evsel *evsel,
+ struct thread_map *threads,
+ int thread, int err)
+{
+   if (!evsel->ignore_missing_thread)
+   return false;
+
+   /* The system wide setup does not work with threads. */
+   if (evsel->system_wide)
+   return false;
+
+   /* The -ESRCH is perf event syscall errno for pid's not found. */
+   if (err != -ESRCH)
+   return false;
+
+   /* If there's only one thread, let it fail. */
+   if (threads->nr == 1)
+   return false;
+
+   if (thread_map__remove(threads, thread))
+   return false;
+
+   pr_warning("WARNING: Ignored open failure for pid %d\n",
+  thread_map__pid(threads, thread));
+   return true;
+}
+
 static int __perf_evsel__open(struct perf_evsel *evsel, struct cpu_map *cpus,
  struct thread_map *threads)
 {
@@ -1491,6 +1520,21 @@ static int __perf_evsel__open(struct perf_evsel *evsel, 
struct cpu_map *cpus,
 
if (fd < 0) {
err = -errno;
+
+   if (ignore_missing_thread(evsel, threads, 
thread, err)) {
+   /*
+* We just removed 1 thread, so take a 
step
+* back on thread index and lower the 
upper
+* nthreads limit.
+*/
+   nthreads--;
+   thread--;
+
+   /* ... and pretend like nothing have 
happened. */
+   err = 0;
+   continue;
+   }
+
pr_debug2("\nsys_perf_event_open failed, error 
%d\n",
  err);
goto try_fallback;
diff --git a/tools/perf/util/evsel.h b/tools/perf/util/evsel.h

Re: [PATCH] Input: ar1021-i2c - fix too long name in driver's device table

[Christian Gmeiner]

2016-12-13 0:57 GMT+01:00 Dmitry Torokhov :
> The name field in structure i2c_device_id is 20 characters, and we
> expect it to be NULL-terminated, however we are trying to stuff it with
> 21 bytes and thus NULL-terminator is lost. This causes issues when one
> creates device with name "MICROCHIP_AR1021_I2C" as i2c core cuts off the
> last "C", and automatic module loading by alias does not work as result.
>
> The -I2C suffix in the device name is superfluous, we know what bus we
> are dealing with, so let's drop it.
>
> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=116211
> Signed-off-by: Dmitry Torokhov 
> ---
>  drivers/input/touchscreen/ar1021_i2c.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/input/touchscreen/ar1021_i2c.c 
> b/drivers/input/touchscreen/ar1021_i2c.c
> index 71b5a63..89f9587 100644
> --- a/drivers/input/touchscreen/ar1021_i2c.c
> +++ b/drivers/input/touchscreen/ar1021_i2c.c
> @@ -152,7 +152,7 @@ static int __maybe_unused ar1021_i2c_resume(struct device 
> *dev)
>  static SIMPLE_DEV_PM_OPS(ar1021_i2c_pm, ar1021_i2c_suspend, 
> ar1021_i2c_resume);
>
>  static const struct i2c_device_id ar1021_i2c_id[] = {
> -   { "MICROCHIP_AR1021_I2C", 0 },
> +   { "MICROCHIP_AR1021", 0 },
> { },
>  };
>  MODULE_DEVICE_TABLE(i2c, ar1021_i2c_id);
> --
> 2.8.0.rc3.226.g39d4020
>

Reviewed-By: Christian Gmeiner 

Re: [PATCH] Input: ar1021-i2c - fix too long name in driver's device table

[Christian Gmeiner]

2016-12-13 0:57 GMT+01:00 Dmitry Torokhov :
> The name field in structure i2c_device_id is 20 characters, and we
> expect it to be NULL-terminated, however we are trying to stuff it with
> 21 bytes and thus NULL-terminator is lost. This causes issues when one
> creates device with name "MICROCHIP_AR1021_I2C" as i2c core cuts off the
> last "C", and automatic module loading by alias does not work as result.
>
> The -I2C suffix in the device name is superfluous, we know what bus we
> are dealing with, so let's drop it.
>
> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=116211
> Signed-off-by: Dmitry Torokhov 
> ---
>  drivers/input/touchscreen/ar1021_i2c.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/input/touchscreen/ar1021_i2c.c 
> b/drivers/input/touchscreen/ar1021_i2c.c
> index 71b5a63..89f9587 100644
> --- a/drivers/input/touchscreen/ar1021_i2c.c
> +++ b/drivers/input/touchscreen/ar1021_i2c.c
> @@ -152,7 +152,7 @@ static int __maybe_unused ar1021_i2c_resume(struct device 
> *dev)
>  static SIMPLE_DEV_PM_OPS(ar1021_i2c_pm, ar1021_i2c_suspend, 
> ar1021_i2c_resume);
>
>  static const struct i2c_device_id ar1021_i2c_id[] = {
> -   { "MICROCHIP_AR1021_I2C", 0 },
> +   { "MICROCHIP_AR1021", 0 },
> { },
>  };
>  MODULE_DEVICE_TABLE(i2c, ar1021_i2c_id);
> --
> 2.8.0.rc3.226.g39d4020
>

Reviewed-By: Christian Gmeiner 

Re: [PATCH] clk: imx: pllv3: support fractional multiplier on vf610 PLL1/PLL2

[Stephen Boyd]

On 12/09, Nikita Yushchenko wrote:
> diff --git a/drivers/clk/imx/clk-pllv3.c b/drivers/clk/imx/clk-pllv3.c
> index 19f9b622981a..24a9e914e0d5 100644
> --- a/drivers/clk/imx/clk-pllv3.c
> +++ b/drivers/clk/imx/clk-pllv3.c
> @@ -288,6 +291,87 @@ static const struct clk_ops clk_pllv3_av_ops = {
>   .set_rate   = clk_pllv3_av_set_rate,
>  };
>  
> +static unsigned long clk_pllv3_vf610_recalc_rate(struct clk_hw *hw,
> +   unsigned long parent_rate)
> +{
> + struct clk_pllv3 *pll = to_clk_pllv3(hw);
> + u32 mfn = readl_relaxed(pll->base + PLL_VF610_NUM_OFFSET);
> + u32 mfd = readl_relaxed(pll->base + PLL_VF610_DENOM_OFFSET);
> + u32 div = (readl_relaxed(pll->base) & pll->div_mask) ? 22 : 20;
> + u64 temp64 = (u64)parent_rate;

Useless cast, please remove.

> +
> + temp64 *= mfn;
> + do_div(temp64, mfd);
> +
> + return (parent_rate * div) + (u32)temp64;
> +}
> +
> +static long clk_pllv3_vf610_round_rate(struct clk_hw *hw, unsigned long rate,
> + unsigned long *prate)
> +{
> + unsigned long parent_rate = *prate;
> + unsigned int mfi = (rate >= 22 * parent_rate) ? 22 : 20;

What is the importance of 22 and 20? Hint, at the least it needs
a comment.

> + u32 mfn, mfd = 0x3fff;
> + u64 temp64;
> +
> + if (rate <= parent_rate * mfi)
> + mfn = 0;
> + else if (rate >= parent_rate * (mfi + 1))
> + mfn = mfd - 1;
> + else {
> + /* rate = parent_rate * (mfi + mfn/mfd) */
> + temp64 = rate - parent_rate * mfi;
> + temp64 *= mfd;
> + do_div(temp64, parent_rate);
> + mfn = temp64;
> + }
> +
> + temp64 = ((u64)mfd * mfi + mfn) * parent_rate;
> + do_div(temp64, mfd);
> + return (u32)temp64;

Do we need the cast here for some reason?

> +}
> +
> +static int clk_pllv3_vf610_set_rate(struct clk_hw *hw, unsigned long rate,
> + unsigned long parent_rate)
> +{
> + struct clk_pllv3 *pll = to_clk_pllv3(hw);
> + unsigned int mfi = (rate >= 22 * parent_rate) ? 22 : 20;
> + u32 val, mfn, mfd = 0x3fff;
> + u64 temp64;
> +
> + if (rate <= parent_rate * mfi)
> + mfn = 0;
> + else if (rate >= parent_rate * (mfi + 1))
> + mfn = mfd - 1;
> + else {
> + /* rate = parent_rate * (mfi + mfn/mfd) */
> + temp64 = rate - parent_rate * mfi;
> + temp64 *= mfd;
> + do_div(temp64, parent_rate);
> + mfn = temp64;
> + }
> +
> + val = readl_relaxed(pll->base);
> + if (mfi == 20)

Presumably this is another place 20 and 22 are special.

> + val &= ~pll->div_mask;
> + else
> + val |= pll->div_mask;
-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH] clk: imx: pllv3: support fractional multiplier on vf610 PLL1/PLL2

[Stephen Boyd]

On 12/09, Nikita Yushchenko wrote:
> diff --git a/drivers/clk/imx/clk-pllv3.c b/drivers/clk/imx/clk-pllv3.c
> index 19f9b622981a..24a9e914e0d5 100644
> --- a/drivers/clk/imx/clk-pllv3.c
> +++ b/drivers/clk/imx/clk-pllv3.c
> @@ -288,6 +291,87 @@ static const struct clk_ops clk_pllv3_av_ops = {
>   .set_rate   = clk_pllv3_av_set_rate,
>  };
>  
> +static unsigned long clk_pllv3_vf610_recalc_rate(struct clk_hw *hw,
> +   unsigned long parent_rate)
> +{
> + struct clk_pllv3 *pll = to_clk_pllv3(hw);
> + u32 mfn = readl_relaxed(pll->base + PLL_VF610_NUM_OFFSET);
> + u32 mfd = readl_relaxed(pll->base + PLL_VF610_DENOM_OFFSET);
> + u32 div = (readl_relaxed(pll->base) & pll->div_mask) ? 22 : 20;
> + u64 temp64 = (u64)parent_rate;

Useless cast, please remove.

> +
> + temp64 *= mfn;
> + do_div(temp64, mfd);
> +
> + return (parent_rate * div) + (u32)temp64;
> +}
> +
> +static long clk_pllv3_vf610_round_rate(struct clk_hw *hw, unsigned long rate,
> + unsigned long *prate)
> +{
> + unsigned long parent_rate = *prate;
> + unsigned int mfi = (rate >= 22 * parent_rate) ? 22 : 20;

What is the importance of 22 and 20? Hint, at the least it needs
a comment.

> + u32 mfn, mfd = 0x3fff;
> + u64 temp64;
> +
> + if (rate <= parent_rate * mfi)
> + mfn = 0;
> + else if (rate >= parent_rate * (mfi + 1))
> + mfn = mfd - 1;
> + else {
> + /* rate = parent_rate * (mfi + mfn/mfd) */
> + temp64 = rate - parent_rate * mfi;
> + temp64 *= mfd;
> + do_div(temp64, parent_rate);
> + mfn = temp64;
> + }
> +
> + temp64 = ((u64)mfd * mfi + mfn) * parent_rate;
> + do_div(temp64, mfd);
> + return (u32)temp64;

Do we need the cast here for some reason?

> +}
> +
> +static int clk_pllv3_vf610_set_rate(struct clk_hw *hw, unsigned long rate,
> + unsigned long parent_rate)
> +{
> + struct clk_pllv3 *pll = to_clk_pllv3(hw);
> + unsigned int mfi = (rate >= 22 * parent_rate) ? 22 : 20;
> + u32 val, mfn, mfd = 0x3fff;
> + u64 temp64;
> +
> + if (rate <= parent_rate * mfi)
> + mfn = 0;
> + else if (rate >= parent_rate * (mfi + 1))
> + mfn = mfd - 1;
> + else {
> + /* rate = parent_rate * (mfi + mfn/mfd) */
> + temp64 = rate - parent_rate * mfi;
> + temp64 *= mfd;
> + do_div(temp64, parent_rate);
> + mfn = temp64;
> + }
> +
> + val = readl_relaxed(pll->base);
> + if (mfi == 20)

Presumably this is another place 20 and 22 are special.

> + val &= ~pll->div_mask;
> + else
> + val |= pll->div_mask;
-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH 3/5] firmware: revamp firmware documentation

[Rafał Miłecki]

On 12/13/2016 04:08 AM, Luis R. Rodriguez wrote:

Understanding this code is getting out of control without any
notes. Give the firmware_class driver a much needed documentation love,
and while at it convert it to the new sphinx documentation format.


It does help to understand the class/API, thank you!



+Even if you have these needs there are a few reasons why you may not be
+able to make use of built-in firmware:
+
+* Legalese - firmware is non-GPL compatible
+* Some firmware may be optional
+* Firmware upgrades are possible, therefore a new firmware would implicate
+  a complete firmware rebuild.


Could it be you meant "kernel rebuild" or "vmlinux rebuild" here?



diff --git a/Documentation/driver-api/firmware/fallback-mechanisms.rst 
b/Documentation/driver-api/firmware/fallback-mechanisms.rst
new file mode 100644
index ..edce1d76ce29
--- /dev/null
+++ b/Documentation/driver-api/firmware/fallback-mechanisms.rst
@@ -0,0 +1,195 @@
+===
+Fallback mechanisms
+===
+
+A fallback mechanism is supported to allow to overcome failures to do a direct
+filesystem lookup on the root filesystem or when the firmware simply cannot be
+installed for practical reasons on the root filesystem. The kernel
+configuration options related to supporting the firmware fallback mechanism 
are:
+
+  * CONFIG_FW_LOADER_USER_HELPER: enables building the firmware fallback
+mechanism. Most distributions enable this option today. If enabled but
+CONFIG_FW_LOADER_USER_HELPER_FALLBACK is disabled, only the custom fallback
+mechanism is available and for the request_firmware_nowait() call.
+  * CONFIG_FW_LOADER_USER_HELPER_FALLBACK: force enables each request to
+enable the kobject uevent fallback mechanism on all firmare API calls
+except request_firmware_direct(). Most distributions disable this option
+today. The call request_firmware_nowait() allows for one alternative
+fallback mechanism: if this kconfig option is enabled and your second
+argument to request_firmware_nowait(), uevent, is set to false you are
+informing the kernel that you have a custom fallback mechanism and it will
+manually load the firmware. Read below for more details.


Yeah, it really asks for API simplification ;)

Re: [PATCH 3/5] firmware: revamp firmware documentation

[Rafał Miłecki]

On 12/13/2016 04:08 AM, Luis R. Rodriguez wrote:

Understanding this code is getting out of control without any
notes. Give the firmware_class driver a much needed documentation love,
and while at it convert it to the new sphinx documentation format.


It does help to understand the class/API, thank you!



+Even if you have these needs there are a few reasons why you may not be
+able to make use of built-in firmware:
+
+* Legalese - firmware is non-GPL compatible
+* Some firmware may be optional
+* Firmware upgrades are possible, therefore a new firmware would implicate
+  a complete firmware rebuild.


Could it be you meant "kernel rebuild" or "vmlinux rebuild" here?



diff --git a/Documentation/driver-api/firmware/fallback-mechanisms.rst 
b/Documentation/driver-api/firmware/fallback-mechanisms.rst
new file mode 100644
index ..edce1d76ce29
--- /dev/null
+++ b/Documentation/driver-api/firmware/fallback-mechanisms.rst
@@ -0,0 +1,195 @@
+===
+Fallback mechanisms
+===
+
+A fallback mechanism is supported to allow to overcome failures to do a direct
+filesystem lookup on the root filesystem or when the firmware simply cannot be
+installed for practical reasons on the root filesystem. The kernel
+configuration options related to supporting the firmware fallback mechanism 
are:
+
+  * CONFIG_FW_LOADER_USER_HELPER: enables building the firmware fallback
+mechanism. Most distributions enable this option today. If enabled but
+CONFIG_FW_LOADER_USER_HELPER_FALLBACK is disabled, only the custom fallback
+mechanism is available and for the request_firmware_nowait() call.
+  * CONFIG_FW_LOADER_USER_HELPER_FALLBACK: force enables each request to
+enable the kobject uevent fallback mechanism on all firmare API calls
+except request_firmware_direct(). Most distributions disable this option
+today. The call request_firmware_nowait() allows for one alternative
+fallback mechanism: if this kconfig option is enabled and your second
+argument to request_firmware_nowait(), uevent, is set to false you are
+informing the kernel that you have a custom fallback mechanism and it will
+manually load the firmware. Read below for more details.


Yeah, it really asks for API simplification ;)

Re: [PATCH] x86/kbuild: enable modversions for symbols exported from asm

[Nicholas Piggin]

On Mon, 12 Dec 2016 10:48:47 +0100
Stanislav Kozina  wrote:

>  A runtime check is still done, with per-module vermagic which distros
>  can change when they bump the ABI version. Is it really necessary to
>  have more than that (i.e., per-symbol versioning)?  
> >>>   From my point of view, it is. We need to allow changing ABI for some
> >>> modules while maintaining it for others.
> >>> In fact I think that there should be version not only for every exported
> >>> symbol (in the EXPORT_SYMBOL() sense), but also for every public type
> >>> (in the sense of eg. structure defined in the public header file).  
> >> Well the distro can just append _v2, _v3 to the name of the function
> >> or type if it has to break compat for some reason. Would that be enough?  
> > There are other ways that distros can work around when upstream "breaks"
> > the ABI, sometimes they can rename functions, and others they can
> > "preload" structures with padding in anticipation for when/if fields get
> > added to them.  But that's all up to the distros, no need for us to
> > worry about that at all :)  
> 
> Currently, the ABI version (checksum) is stored outside of the actual 
> code in the __ksymtab section. That means that the distributions can 
> still apply upstream patches cleanly and only update the version 
> checksum if these break ABI.
> 
> With the _v2, _v3 suffixes (or similar solutions) we'd be effectively 
> storing the ABI versions directly in the code and that would cause 
> conflicts when pulling further patches from upstream.
> 
> My view is that it would be than easier to maintain out-of-tree 
> modversions (or similar tool) rather than to solve all these conflicts.

That kind of name clash should hardly be an issue, in comparison with the
care it requires to merge fixes on top of a backport which has already
changed ABI. It tends to be trivially fixable just by search/replace
in the patchfile before applying, if nothing else. But you probably *want*
to be flagged on those things and merge by hand anyway.

Backporting alone I don't think can justify symbol versioning, but I'd
like to hear from distro maintainers if any disagree.

Thanks,
Nick

Re: [PATCH] x86/kbuild: enable modversions for symbols exported from asm

[Nicholas Piggin]

On Mon, 12 Dec 2016 10:48:47 +0100
Stanislav Kozina  wrote:

>  A runtime check is still done, with per-module vermagic which distros
>  can change when they bump the ABI version. Is it really necessary to
>  have more than that (i.e., per-symbol versioning)?  
> >>>   From my point of view, it is. We need to allow changing ABI for some
> >>> modules while maintaining it for others.
> >>> In fact I think that there should be version not only for every exported
> >>> symbol (in the EXPORT_SYMBOL() sense), but also for every public type
> >>> (in the sense of eg. structure defined in the public header file).  
> >> Well the distro can just append _v2, _v3 to the name of the function
> >> or type if it has to break compat for some reason. Would that be enough?  
> > There are other ways that distros can work around when upstream "breaks"
> > the ABI, sometimes they can rename functions, and others they can
> > "preload" structures with padding in anticipation for when/if fields get
> > added to them.  But that's all up to the distros, no need for us to
> > worry about that at all :)  
> 
> Currently, the ABI version (checksum) is stored outside of the actual 
> code in the __ksymtab section. That means that the distributions can 
> still apply upstream patches cleanly and only update the version 
> checksum if these break ABI.
> 
> With the _v2, _v3 suffixes (or similar solutions) we'd be effectively 
> storing the ABI versions directly in the code and that would cause 
> conflicts when pulling further patches from upstream.
> 
> My view is that it would be than easier to maintain out-of-tree 
> modversions (or similar tool) rather than to solve all these conflicts.

That kind of name clash should hardly be an issue, in comparison with the
care it requires to merge fixes on top of a backport which has already
changed ABI. It tends to be trivially fixable just by search/replace
in the patchfile before applying, if nothing else. But you probably *want*
to be flagged on those things and merge by hand anyway.

Backporting alone I don't think can justify symbol versioning, but I'd
like to hear from distro maintainers if any disagree.

Thanks,
Nick

Issue with DRM and "reimplement IDR and IDA using the radix tree"

[Alexandre Courbot]

Hi Matthew,

Trying the latest -next on the Jetson TK1 board (with two different DRM
devices and display and render), I noticed that the GPU device probe
always failed with error -ENOSPC. After investigating I figured out that
this was due to the minor device allocation failing when a second DRM
device is added.

More precisely, when drm_minor_alloc() is called with DRM_MINOR_PRIMARY
(0) as argument for a second time, the call to idr_alloc() (which has a
requested range of 0..64) fails instead of returning 1 as expected. Note
that the first call is successful.

Reverting "reimplement IDR and IDA using the radix tree" on 20161213's
next fixes the issue for me, suggesting a bug may have slipped in there.

Not sure how this could be fixed, so reporting the issue for now in case
it is not known yet.

Cheers,
Alex.

Issue with DRM and "reimplement IDR and IDA using the radix tree"

[Alexandre Courbot]

Hi Matthew,

Trying the latest -next on the Jetson TK1 board (with two different DRM
devices and display and render), I noticed that the GPU device probe
always failed with error -ENOSPC. After investigating I figured out that
this was due to the minor device allocation failing when a second DRM
device is added.

More precisely, when drm_minor_alloc() is called with DRM_MINOR_PRIMARY
(0) as argument for a second time, the call to idr_alloc() (which has a
requested range of 0..64) fails instead of returning 1 as expected. Note
that the first call is successful.

Reverting "reimplement IDR and IDA using the radix tree" on 20161213's
next fixes the issue for me, suggesting a bug may have slipped in there.

Not sure how this could be fixed, so reporting the issue for now in case
it is not known yet.

Cheers,
Alex.

Re: [RFC PATCH 0/3] staging: remove fbdev drivers

[Michel Dänzer]

On 10/12/16 05:27 AM, Benjamin Herrenschmidt wrote:
> On Fri, 2016-12-09 at 14:35 +0100, Daniel Vetter wrote:
>>> As for multi userspace client, well, swapping an mmap between HW and
>>> memory backing store is a somewhat solved problem already.
>>
>> Hm, I didn't know that, but then all existing drm drivers have fairly
>> simplistic fbdev mmap implementations.
> 
> Hrm, I though the TTM did it ... I remember talking with Thomas
> Hellstrom about that back in the day... you use unmap_mapping_range
> to unmap the existing mappings basically so you can take new faults
> and route them to a different page, but I can't see a call in there
> so maybe he ended up not doing it.

I think he did, it was working fine for userspace mappings when I tried
making radeon use a non-pinned BO for fbdev years ago (the problem was
fbcon potentially trying to access the framebuffer at the most
inconvenient times). There's still ttm_fbdev_mmap, but I'm not sure
everything to make this fully work for userspace fbdev mappings is still
there.


-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast | Mesa and X developer

Re: [RFC PATCH 0/3] staging: remove fbdev drivers

[Michel Dänzer]

On 10/12/16 05:27 AM, Benjamin Herrenschmidt wrote:
> On Fri, 2016-12-09 at 14:35 +0100, Daniel Vetter wrote:
>>> As for multi userspace client, well, swapping an mmap between HW and
>>> memory backing store is a somewhat solved problem already.
>>
>> Hm, I didn't know that, but then all existing drm drivers have fairly
>> simplistic fbdev mmap implementations.
> 
> Hrm, I though the TTM did it ... I remember talking with Thomas
> Hellstrom about that back in the day... you use unmap_mapping_range
> to unmap the existing mappings basically so you can take new faults
> and route them to a different page, but I can't see a call in there
> so maybe he ended up not doing it.

I think he did, it was working fine for userspace mappings when I tried
making radeon use a non-pinned BO for fbdev years ago (the problem was
fbcon potentially trying to access the framebuffer at the most
inconvenient times). There's still ttm_fbdev_mmap, but I'm not sure
everything to make this fully work for userspace fbdev mappings is still
there.


-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast | Mesa and X developer

[RFC][PATCH 1/5] usb: dwc2: Avoid sleeping while holding hsotg->lock

[John Stultz]

Basically when plugging in various cables in different orders, I'm
occasionally seeing the following BUG splat:

[   86.215403] BUG: scheduling while atomic: kworker/u16:2/53/0x0002
[   86.219164] usb 1-1: USB disconnect, device number 9
[   86.226845] Preemption disabled at:[   86.230218]
[] dwc2_conn_id_status_change+0x120/0x250
[   86.236894] CPU: 0 PID: 53 Comm: kworker/u16:2 Tainted: GW
 4.9.0-rc8-00051-gd5a7979-dirty #1702
[   86.246836] Hardware name: HiKey Development Board (DT)
[   86.252100] Workqueue: dwc2 dwc2_conn_id_status_change
[   86.257279] Call trace:
[   86.259771] [] dump_backtrace+0x0/0x1a0
[   86.265210] [] show_stack+0x14/0x20
[   86.270308] [] dump_stack+0x90/0xb0
[   86.275401] [] __schedule_bug+0x6c/0xb8
[   86.280841] [] __schedule+0x4f8/0x5b0
[   86.286099] [] schedule+0x38/0xa0
[   86.291017] [] schedule_hrtimeout_range_clock+0x8c/0xf0
[   86.297846] [] schedule_hrtimeout_range+0x10/0x18
[   86.304150] [] usleep_range+0x50/0x58
[   86.309418] [] dwc2_wait_for_mode.isra.4+0x54/0xd0
[   86.315815] [] dwc2_core_reset+0xe0/0x168
[   86.321431] [] dwc2_hsotg_core_init_disconnected+0x2c/0x310
[   86.328602] [] dwc2_conn_id_status_change+0x130/0x250
[   86.335254] [] process_one_work+0x118/0x370
[   86.341035] [] worker_thread+0x48/0x498
[   86.346473] [] kthread+0xd0/0xe8
[   86.351299] [] ret_from_fork+0x10/0x50

This seems to be caused by the dwc2_wait_for_mode() calling
usleep_range() while the hstog->lock spinlock is held, since
we take that before calling dwc2_hsotg_core_init_disconnected().

This patch avoids the issue by adding an extra argument to
dwc2_core_reset(), as suggested by John Youn, which allows us to
skip the waiting, which should be unnecessary when calling from
dwc2_hsotg_core_init_disconnected().

Cc: Wei Xu 
Cc: Guodong Xu 
Cc: Amit Pundir 
Cc: Rob Herring 
Cc: John Youn 
Cc: Douglas Anderson 
Cc: Chen Yu 
Cc: Kishon Vijay Abraham I 
Cc: Felipe Balbi 
Cc: Greg Kroah-Hartman 
Cc: linux-...@vger.kernel.org
Signed-off-by: John Stultz 
---
 drivers/usb/dwc2/core.c   | 6 +++---
 drivers/usb/dwc2/core.h   | 2 +-
 drivers/usb/dwc2/gadget.c | 2 +-
 3 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/usb/dwc2/core.c b/drivers/usb/dwc2/core.c
index 4c0fa0b..2e83545 100644
--- a/drivers/usb/dwc2/core.c
+++ b/drivers/usb/dwc2/core.c
@@ -313,7 +313,7 @@ static bool dwc2_iddig_filter_enabled(struct dwc2_hsotg 
*hsotg)
  * Do core a soft reset of the core.  Be careful with this because it
  * resets all the internal state machines of the core.
  */
-int dwc2_core_reset(struct dwc2_hsotg *hsotg)
+int dwc2_core_reset(struct dwc2_hsotg *hsotg, bool skip_wait)
 {
u32 greset;
int count = 0;
@@ -369,7 +369,7 @@ int dwc2_core_reset(struct dwc2_hsotg *hsotg)
}
} while (!(greset & GRSTCTL_AHBIDLE));
 
-   if (wait_for_host_mode)
+   if (wait_for_host_mode && !skip_wait)
dwc2_wait_for_mode(hsotg, true);
 
return 0;
@@ -500,7 +500,7 @@ int dwc2_core_reset_and_force_dr_mode(struct dwc2_hsotg 
*hsotg)
 {
int retval;
 
-   retval = dwc2_core_reset(hsotg);
+   retval = dwc2_core_reset(hsotg, false);
if (retval)
return retval;
 
diff --git a/drivers/usb/dwc2/core.h b/drivers/usb/dwc2/core.h
index 2a21a04..963ea1b 100644
--- a/drivers/usb/dwc2/core.h
+++ b/drivers/usb/dwc2/core.h
@@ -1020,7 +1020,7 @@ enum dwc2_halt_status {
  * The following functions support initialization of the core driver component
  * and the DWC_otg controller
  */
-extern int dwc2_core_reset(struct dwc2_hsotg *hsotg);
+extern int dwc2_core_reset(struct dwc2_hsotg *hsotg, bool skip_wait);
 extern int dwc2_core_reset_and_force_dr_mode(struct dwc2_hsotg *hsotg);
 extern int dwc2_enter_hibernation(struct dwc2_hsotg *hsotg);
 extern int dwc2_exit_hibernation(struct dwc2_hsotg *hsotg, bool restore);
diff --git a/drivers/usb/dwc2/gadget.c b/drivers/usb/dwc2/gadget.c
index 24fbebc..0bda799 100644
--- a/drivers/usb/dwc2/gadget.c
+++ b/drivers/usb/dwc2/gadget.c
@@ -2521,7 +2521,7 @@ void dwc2_hsotg_core_init_disconnected(struct dwc2_hsotg 
*hsotg,
kill_all_requests(hsotg, hsotg->eps_out[0], -ECONNRESET);
 
if (!is_usb_reset)
-   if (dwc2_core_reset(hsotg))
+   if (dwc2_core_reset(hsotg, true))
return;
 
/*
-- 
2.7.4

[RFC][PATCH 4/5] usb: dwc2: Avoid suspending if we're in gadget mode

[John Stultz]

I've found when booting HiKey with the usb gadget cable attached
if I then try to connect via adb, I get an infinite spew of:

dwc2 f72c.usb: dwc2_hsotg_ep_sethalt(ep ffc0790ecb18 ep1out, 0)
dwc2 f72c.usb: dwc2_hsotg_ep_sethalt(ep ffc0790eca18 ep1in, 0)

It seems that the usb autosuspend is suspending the bus shortly
after bootup when the gadget cable is attached. So when adbd
then tries to use the device, it doesn't work and it then tries
to restart it over and over via the ep_sethalt calls (via
FUNCTIONFS_CLEAR_HALT ioctl).

Chen Yu suggested this patch to avoid suspending if we're
in device mode, and it avoids the problem.

This doesn't remove the need for the previous patch, to resume
the port when we switch to gadget mode from host mode. But it
does seem to resolve the issue.

Cc: Wei Xu 
Cc: Guodong Xu 
Cc: Amit Pundir 
Cc: Rob Herring 
Cc: John Youn 
Cc: Douglas Anderson 
Cc: Chen Yu 
Cc: Kishon Vijay Abraham I 
Cc: Felipe Balbi 
Cc: Greg Kroah-Hartman 
Cc: linux-...@vger.kernel.org
Suggested-by: Chen Yu 
Signed-off-by: John Stultz 
---
 drivers/usb/dwc2/hcd.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/usb/dwc2/hcd.c b/drivers/usb/dwc2/hcd.c
index 24db997..008f5bc 100644
--- a/drivers/usb/dwc2/hcd.c
+++ b/drivers/usb/dwc2/hcd.c
@@ -4375,6 +4375,9 @@ static int _dwc2_hcd_suspend(struct usb_hcd *hcd)
if (!HCD_HW_ACCESSIBLE(hcd))
goto unlock;
 
+   if (hsotg->op_state == OTG_STATE_B_PERIPHERAL)
+   goto unlock;
+
if (!hsotg->core_params->hibernation)
goto skip_power_saving;
 
-- 
2.7.4

[RFC][PATCH 1/5] usb: dwc2: Avoid sleeping while holding hsotg->lock

[John Stultz]

Basically when plugging in various cables in different orders, I'm
occasionally seeing the following BUG splat:

[   86.215403] BUG: scheduling while atomic: kworker/u16:2/53/0x0002
[   86.219164] usb 1-1: USB disconnect, device number 9
[   86.226845] Preemption disabled at:[   86.230218]
[] dwc2_conn_id_status_change+0x120/0x250
[   86.236894] CPU: 0 PID: 53 Comm: kworker/u16:2 Tainted: GW
 4.9.0-rc8-00051-gd5a7979-dirty #1702
[   86.246836] Hardware name: HiKey Development Board (DT)
[   86.252100] Workqueue: dwc2 dwc2_conn_id_status_change
[   86.257279] Call trace:
[   86.259771] [] dump_backtrace+0x0/0x1a0
[   86.265210] [] show_stack+0x14/0x20
[   86.270308] [] dump_stack+0x90/0xb0
[   86.275401] [] __schedule_bug+0x6c/0xb8
[   86.280841] [] __schedule+0x4f8/0x5b0
[   86.286099] [] schedule+0x38/0xa0
[   86.291017] [] schedule_hrtimeout_range_clock+0x8c/0xf0
[   86.297846] [] schedule_hrtimeout_range+0x10/0x18
[   86.304150] [] usleep_range+0x50/0x58
[   86.309418] [] dwc2_wait_for_mode.isra.4+0x54/0xd0
[   86.315815] [] dwc2_core_reset+0xe0/0x168
[   86.321431] [] dwc2_hsotg_core_init_disconnected+0x2c/0x310
[   86.328602] [] dwc2_conn_id_status_change+0x130/0x250
[   86.335254] [] process_one_work+0x118/0x370
[   86.341035] [] worker_thread+0x48/0x498
[   86.346473] [] kthread+0xd0/0xe8
[   86.351299] [] ret_from_fork+0x10/0x50

This seems to be caused by the dwc2_wait_for_mode() calling
usleep_range() while the hstog->lock spinlock is held, since
we take that before calling dwc2_hsotg_core_init_disconnected().

This patch avoids the issue by adding an extra argument to
dwc2_core_reset(), as suggested by John Youn, which allows us to
skip the waiting, which should be unnecessary when calling from
dwc2_hsotg_core_init_disconnected().

Cc: Wei Xu 
Cc: Guodong Xu 
Cc: Amit Pundir 
Cc: Rob Herring 
Cc: John Youn 
Cc: Douglas Anderson 
Cc: Chen Yu 
Cc: Kishon Vijay Abraham I 
Cc: Felipe Balbi 
Cc: Greg Kroah-Hartman 
Cc: linux-...@vger.kernel.org
Signed-off-by: John Stultz 
---
 drivers/usb/dwc2/core.c   | 6 +++---
 drivers/usb/dwc2/core.h   | 2 +-
 drivers/usb/dwc2/gadget.c | 2 +-
 3 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/usb/dwc2/core.c b/drivers/usb/dwc2/core.c
index 4c0fa0b..2e83545 100644
--- a/drivers/usb/dwc2/core.c
+++ b/drivers/usb/dwc2/core.c
@@ -313,7 +313,7 @@ static bool dwc2_iddig_filter_enabled(struct dwc2_hsotg 
*hsotg)
  * Do core a soft reset of the core.  Be careful with this because it
  * resets all the internal state machines of the core.
  */
-int dwc2_core_reset(struct dwc2_hsotg *hsotg)
+int dwc2_core_reset(struct dwc2_hsotg *hsotg, bool skip_wait)
 {
u32 greset;
int count = 0;
@@ -369,7 +369,7 @@ int dwc2_core_reset(struct dwc2_hsotg *hsotg)
}
} while (!(greset & GRSTCTL_AHBIDLE));
 
-   if (wait_for_host_mode)
+   if (wait_for_host_mode && !skip_wait)
dwc2_wait_for_mode(hsotg, true);
 
return 0;
@@ -500,7 +500,7 @@ int dwc2_core_reset_and_force_dr_mode(struct dwc2_hsotg 
*hsotg)
 {
int retval;
 
-   retval = dwc2_core_reset(hsotg);
+   retval = dwc2_core_reset(hsotg, false);
if (retval)
return retval;
 
diff --git a/drivers/usb/dwc2/core.h b/drivers/usb/dwc2/core.h
index 2a21a04..963ea1b 100644
--- a/drivers/usb/dwc2/core.h
+++ b/drivers/usb/dwc2/core.h
@@ -1020,7 +1020,7 @@ enum dwc2_halt_status {
  * The following functions support initialization of the core driver component
  * and the DWC_otg controller
  */
-extern int dwc2_core_reset(struct dwc2_hsotg *hsotg);
+extern int dwc2_core_reset(struct dwc2_hsotg *hsotg, bool skip_wait);
 extern int dwc2_core_reset_and_force_dr_mode(struct dwc2_hsotg *hsotg);
 extern int dwc2_enter_hibernation(struct dwc2_hsotg *hsotg);
 extern int dwc2_exit_hibernation(struct dwc2_hsotg *hsotg, bool restore);
diff --git a/drivers/usb/dwc2/gadget.c b/drivers/usb/dwc2/gadget.c
index 24fbebc..0bda799 100644
--- a/drivers/usb/dwc2/gadget.c
+++ b/drivers/usb/dwc2/gadget.c
@@ -2521,7 +2521,7 @@ void dwc2_hsotg_core_init_disconnected(struct dwc2_hsotg 
*hsotg,
kill_all_requests(hsotg, hsotg->eps_out[0], -ECONNRESET);
 
if (!is_usb_reset)
-   if (dwc2_core_reset(hsotg))
+   if (dwc2_core_reset(hsotg, true))
return;
 
/*
-- 
2.7.4

[RFC][PATCH 4/5] usb: dwc2: Avoid suspending if we're in gadget mode

[John Stultz]

I've found when booting HiKey with the usb gadget cable attached
if I then try to connect via adb, I get an infinite spew of:

dwc2 f72c.usb: dwc2_hsotg_ep_sethalt(ep ffc0790ecb18 ep1out, 0)
dwc2 f72c.usb: dwc2_hsotg_ep_sethalt(ep ffc0790eca18 ep1in, 0)

It seems that the usb autosuspend is suspending the bus shortly
after bootup when the gadget cable is attached. So when adbd
then tries to use the device, it doesn't work and it then tries
to restart it over and over via the ep_sethalt calls (via
FUNCTIONFS_CLEAR_HALT ioctl).

Chen Yu suggested this patch to avoid suspending if we're
in device mode, and it avoids the problem.

This doesn't remove the need for the previous patch, to resume
the port when we switch to gadget mode from host mode. But it
does seem to resolve the issue.

Cc: Wei Xu 
Cc: Guodong Xu 
Cc: Amit Pundir 
Cc: Rob Herring 
Cc: John Youn 
Cc: Douglas Anderson 
Cc: Chen Yu 
Cc: Kishon Vijay Abraham I 
Cc: Felipe Balbi 
Cc: Greg Kroah-Hartman 
Cc: linux-...@vger.kernel.org
Suggested-by: Chen Yu 
Signed-off-by: John Stultz 
---
 drivers/usb/dwc2/hcd.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/usb/dwc2/hcd.c b/drivers/usb/dwc2/hcd.c
index 24db997..008f5bc 100644
--- a/drivers/usb/dwc2/hcd.c
+++ b/drivers/usb/dwc2/hcd.c
@@ -4375,6 +4375,9 @@ static int _dwc2_hcd_suspend(struct usb_hcd *hcd)
if (!HCD_HW_ACCESSIBLE(hcd))
goto unlock;
 
+   if (hsotg->op_state == OTG_STATE_B_PERIPHERAL)
+   goto unlock;
+
if (!hsotg->core_params->hibernation)
goto skip_power_saving;
 
-- 
2.7.4

[RFC][PATCH 2/5] usb: dwc2: Workaround case where GOTGCTL state is wrong

[John Stultz]

When removing a USB-A to USB-otg adapter cable, we get a change
status irq, and then in dwc2_conn_id_status_change, we
erroniously see the GOTGCTL_CONID_B flag set. This causes us to
get  stuck in the "while (!dwc2_is_device_mode(hsotg))" loop,
spitting out "Waiting for Peripheral Mode, Mode=Host" warnings
until it fails out many seconds later.

This patch works around the issue by re-reading the GOTGCTL
state to check if the GOTGCTL_CONID_B is still set and if not
restarting the change status logic.

I suspect this isn't the best solution, but it seems to work
well for me.

Feedback would be greatly appreciated!

Cc: Wei Xu 
Cc: Guodong Xu 
Cc: Amit Pundir 
Cc: Rob Herring 
Cc: John Youn 
Cc: Douglas Anderson 
Cc: Chen Yu 
Cc: Kishon Vijay Abraham I 
Cc: Felipe Balbi 
Cc: Greg Kroah-Hartman 
Cc: linux-...@vger.kernel.org
Acked-by: John Youn 
Signed-off-by: John Stultz 
---
 drivers/usb/dwc2/hcd.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/dwc2/hcd.c b/drivers/usb/dwc2/hcd.c
index df5a065..a3f34dd 100644
--- a/drivers/usb/dwc2/hcd.c
+++ b/drivers/usb/dwc2/hcd.c
@@ -3199,7 +3199,7 @@ static void dwc2_conn_id_status_change(struct work_struct 
*work)
dev_dbg(hsotg->dev, "gotgctl=%0x\n", gotgctl);
dev_dbg(hsotg->dev, "gotgctl.b.conidsts=%d\n",
!!(gotgctl & GOTGCTL_CONID_B));
-
+again:
/* B-Device connector (Device Mode) */
if (gotgctl & GOTGCTL_CONID_B) {
/* Wait for switch to device mode */
@@ -3210,6 +3210,9 @@ static void dwc2_conn_id_status_change(struct work_struct 
*work)
 dwc2_is_host_mode(hsotg) ? "Host" :
 "Peripheral");
usleep_range(2, 4);
+   gotgctl = dwc2_readl(hsotg->regs + GOTGCTL);
+   if (!(gotgctl & GOTGCTL_CONID_B))
+   goto again;
if (++count > 250)
break;
}
-- 
2.7.4

[RFC][PATCH 2/5] usb: dwc2: Workaround case where GOTGCTL state is wrong

[John Stultz]

When removing a USB-A to USB-otg adapter cable, we get a change
status irq, and then in dwc2_conn_id_status_change, we
erroniously see the GOTGCTL_CONID_B flag set. This causes us to
get  stuck in the "while (!dwc2_is_device_mode(hsotg))" loop,
spitting out "Waiting for Peripheral Mode, Mode=Host" warnings
until it fails out many seconds later.

This patch works around the issue by re-reading the GOTGCTL
state to check if the GOTGCTL_CONID_B is still set and if not
restarting the change status logic.

I suspect this isn't the best solution, but it seems to work
well for me.

Feedback would be greatly appreciated!

Cc: Wei Xu 
Cc: Guodong Xu 
Cc: Amit Pundir 
Cc: Rob Herring 
Cc: John Youn 
Cc: Douglas Anderson 
Cc: Chen Yu 
Cc: Kishon Vijay Abraham I 
Cc: Felipe Balbi 
Cc: Greg Kroah-Hartman 
Cc: linux-...@vger.kernel.org
Acked-by: John Youn 
Signed-off-by: John Stultz 
---
 drivers/usb/dwc2/hcd.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/dwc2/hcd.c b/drivers/usb/dwc2/hcd.c
index df5a065..a3f34dd 100644
--- a/drivers/usb/dwc2/hcd.c
+++ b/drivers/usb/dwc2/hcd.c
@@ -3199,7 +3199,7 @@ static void dwc2_conn_id_status_change(struct work_struct 
*work)
dev_dbg(hsotg->dev, "gotgctl=%0x\n", gotgctl);
dev_dbg(hsotg->dev, "gotgctl.b.conidsts=%d\n",
!!(gotgctl & GOTGCTL_CONID_B));
-
+again:
/* B-Device connector (Device Mode) */
if (gotgctl & GOTGCTL_CONID_B) {
/* Wait for switch to device mode */
@@ -3210,6 +3210,9 @@ static void dwc2_conn_id_status_change(struct work_struct 
*work)
 dwc2_is_host_mode(hsotg) ? "Host" :
 "Peripheral");
usleep_range(2, 4);
+   gotgctl = dwc2_readl(hsotg->regs + GOTGCTL);
+   if (!(gotgctl & GOTGCTL_CONID_B))
+   goto again;
if (++count > 250)
break;
}
-- 
2.7.4

[RFC][PATCH 0/5] Fixes and workarounds for dwc2 on HiKey board

[John Stultz]

I just wanted to send out my current queue of patches for dwc2
controller on the HiKey board.

This does exclude my patchset[1] to add extcon support to dwc2,
which John Youn suspects a pending rework of the dwc2 fifo init
logic might make unnecssary.

So in the meantime, I wanted to send out the other patches I
have to use, so that they can get feedback and be consdiered
for the next (4.11) merge window.

Feedback would be greatly appreciated!

thanks
-john

[1] https://lkml.org/lkml/2016/12/6/69

Cc: Wei Xu 
Cc: Guodong Xu 
Cc: Amit Pundir 
Cc: Rob Herring 
Cc: John Youn 
Cc: Douglas Anderson 
Cc: Chen Yu 
Cc: Kishon Vijay Abraham I 
Cc: Felipe Balbi 
Cc: Greg Kroah-Hartman 
Cc: linux-...@vger.kernel.org

Chen Yu (2):
  usb: dwc2: Force port resume on switching to device mode
  usb: dwc2: Add a quirk to allow speed negotiation for Hisilicon Hi6220

John Stultz (3):
  usb: dwc2: Avoid sleeping while holding hsotg->lock
  usb: dwc2: Workaround case where GOTGCTL state is wrong
  usb: dwc2: Avoid suspending if we're in gadget mode

 drivers/usb/dwc2/core.c |  6 ++--
 drivers/usb/dwc2/core.h |  8 -
 drivers/usb/dwc2/gadget.c   |  2 +-
 drivers/usb/dwc2/hcd.c  | 75 -
 drivers/usb/dwc2/platform.c |  1 +
 5 files changed, 86 insertions(+), 6 deletions(-)

-- 
2.7.4

[RFC][PATCH 0/5] Fixes and workarounds for dwc2 on HiKey board

[John Stultz]

I just wanted to send out my current queue of patches for dwc2
controller on the HiKey board.

This does exclude my patchset[1] to add extcon support to dwc2,
which John Youn suspects a pending rework of the dwc2 fifo init
logic might make unnecssary.

So in the meantime, I wanted to send out the other patches I
have to use, so that they can get feedback and be consdiered
for the next (4.11) merge window.

Feedback would be greatly appreciated!

thanks
-john

[1] https://lkml.org/lkml/2016/12/6/69

Cc: Wei Xu 
Cc: Guodong Xu 
Cc: Amit Pundir 
Cc: Rob Herring 
Cc: John Youn 
Cc: Douglas Anderson 
Cc: Chen Yu 
Cc: Kishon Vijay Abraham I 
Cc: Felipe Balbi 
Cc: Greg Kroah-Hartman 
Cc: linux-...@vger.kernel.org

Chen Yu (2):
  usb: dwc2: Force port resume on switching to device mode
  usb: dwc2: Add a quirk to allow speed negotiation for Hisilicon Hi6220

John Stultz (3):
  usb: dwc2: Avoid sleeping while holding hsotg->lock
  usb: dwc2: Workaround case where GOTGCTL state is wrong
  usb: dwc2: Avoid suspending if we're in gadget mode

 drivers/usb/dwc2/core.c |  6 ++--
 drivers/usb/dwc2/core.h |  8 -
 drivers/usb/dwc2/gadget.c   |  2 +-
 drivers/usb/dwc2/hcd.c  | 75 -
 drivers/usb/dwc2/platform.c |  1 +
 5 files changed, 86 insertions(+), 6 deletions(-)

-- 
2.7.4

[RFC][PATCH 5/5] usb: dwc2: Add a quirk to allow speed negotiation for Hisilicon Hi6220

[John Stultz]

From: Chen Yu 

The Hi6220's usb controller is limited in that it does not
support "Split Transactions", so it does not support communicating
with low-speed and full-speed devices behind a high-speed hub.

Thus it requires a quirk so that we can manually drop the usb
speed when low/full-speed are attached, and bump back to high
speed when they are removed.

Cc: Wei Xu 
Cc: Guodong Xu 
Cc: Amit Pundir 
Cc: Rob Herring 
Cc: John Youn 
Cc: Douglas Anderson 
Cc: Chen Yu 
Cc: Kishon Vijay Abraham I 
Cc: Felipe Balbi 
Cc: Greg Kroah-Hartman 
Cc: linux-...@vger.kernel.org
Signed-off-by: Chen Yu 
[jstultz: Reworked to simplify the patch, and made
 commit log to be more specific about the issue]
Signed-off-by: John Stultz 
---
v2:
* Fix build issue reported by kbuildbot
* Rework to avoid using new dts entry suggested by RobH
* Further tweaks from Chen Yu to try to address comments from
  John Youn
* Further simplified logic
---
 drivers/usb/dwc2/core.h |  6 +
 drivers/usb/dwc2/hcd.c  | 60 +
 drivers/usb/dwc2/platform.c |  1 +
 3 files changed, 67 insertions(+)

diff --git a/drivers/usb/dwc2/core.h b/drivers/usb/dwc2/core.h
index 963ea1b..de1fa0c 100644
--- a/drivers/usb/dwc2/core.h
+++ b/drivers/usb/dwc2/core.h
@@ -417,6 +417,11 @@ enum dwc2_ep0_state {
  * needed.
  * 0 - No (default)
  * 1 - Yes
+ * @change_speed_quirk: Change speed configuration to DWC2_SPEED_PARAM_FULL
+ *  while full speed device connect. And change speed
+ *  back to DWC2_SPEED_PARAM_HIGH while device is gone.
+ * 0 - No (default)
+ * 1 - Yes
  *
  * The following parameters may be specified when starting the module. These
  * parameters define how the DWC_otg controller should be configured. A
@@ -457,6 +462,7 @@ struct dwc2_core_params {
int uframe_sched;
int external_id_pin_ctl;
int hibernation;
+   int change_speed_quirk;
 };
 
 /**
diff --git a/drivers/usb/dwc2/hcd.c b/drivers/usb/dwc2/hcd.c
index 008f5bc..7cf8d8e 100644
--- a/drivers/usb/dwc2/hcd.c
+++ b/drivers/usb/dwc2/hcd.c
@@ -4873,6 +4873,61 @@ static void _dwc2_hcd_clear_tt_buffer_complete(struct 
usb_hcd *hcd,
spin_unlock_irqrestore(>lock, flags);
 }
 
+/*
+ * HPRT0_SPD_HIGH_SPEED: high speed
+ * HPRT0_SPD_FULL_SPEED: full speed
+ */
+static void dwc2_change_bus_speed(struct usb_hcd *hcd, int speed)
+{
+   struct dwc2_hsotg *hsotg = dwc2_hcd_to_hsotg(hcd);
+
+   if (hsotg->core_params->speed == speed)
+   return;
+
+   hsotg->core_params->speed = speed;
+   queue_work(hsotg->wq_otg, >wf_otg);
+}
+
+static void dwc2_free_dev(struct usb_hcd *hcd, struct usb_device *udev)
+{
+   struct dwc2_hsotg *hsotg = dwc2_hcd_to_hsotg(hcd);
+
+   if (!hsotg->core_params->change_speed_quirk)
+   return;
+
+   /*
+* On removal, set speed to default high-speed.
+*/
+   if (udev->parent && udev->parent->speed > USB_SPEED_UNKNOWN &&
+   udev->parent->speed < USB_SPEED_HIGH) {
+   dev_info(hsotg->dev, "Set speed to default high-speed\n");
+   dwc2_change_bus_speed(hcd, HPRT0_SPD_HIGH_SPEED);
+   }
+}
+
+static int dwc2_reset_device(struct usb_hcd *hcd, struct usb_device *udev)
+{
+   struct dwc2_hsotg *hsotg = dwc2_hcd_to_hsotg(hcd);
+
+   if (!hsotg->core_params->change_speed_quirk)
+   return 0;
+
+   if (udev->speed == USB_SPEED_HIGH) {
+   dev_info(hsotg->dev, "Set speed to high-speed\n");
+   dwc2_change_bus_speed(hcd, HPRT0_SPD_HIGH_SPEED);
+   } else if ((udev->speed == USB_SPEED_FULL ||
+   udev->speed == USB_SPEED_LOW)) {
+   /*
+* Change speed setting to full-speed if there's
+* a full-speed or low-speed device plugged in.
+*/
+   dev_info(hsotg->dev, "Set speed to full-speed\n");
+   dwc2_change_bus_speed(hcd, HPRT0_SPD_FULL_SPEED);
+   }
+
+   return 0;
+}
+
 static struct hc_driver dwc2_hc_driver = {
.description = "dwc2_hsotg",
.product_desc = "DWC OTG Controller",
@@ -5028,6 +5083,11 @@ int dwc2_hcd_init(struct dwc2_hsotg *hsotg, int irq)
dev_warn(hsotg->dev, "can't set coherent DMA mask\n");
}
 
+   if (hsotg->core_params->change_speed_quirk) {
+   dwc2_hc_driver.free_dev = dwc2_free_dev;
+   dwc2_hc_driver.reset_device = dwc2_reset_device;
+   }
+
hcd = usb_create_hcd(_hc_driver, hsotg->dev, 

[RFC][PATCH 3/5] usb: dwc2: Force port resume on switching to device mode

[John Stultz]

From: Chen Yu 

We've seen failures when switching between host and gadget mode,
which was diagnosed as being caused due to the bus being
auto-suspended when we switched.

So this patch forces a port resume when switching to device
mode if the bus is suspended.

Cc: Wei Xu 
Cc: Guodong Xu 
Cc: Amit Pundir 
Cc: Rob Herring 
Cc: John Youn 
Cc: Douglas Anderson 
Cc: Chen Yu 
Cc: Felipe Balbi 
Cc: Greg Kroah-Hartman 
Cc: linux-...@vger.kernel.org
Signed-off-by: Chen Yu 
Signed-off-by: John Stultz 
---
 drivers/usb/dwc2/hcd.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/drivers/usb/dwc2/hcd.c b/drivers/usb/dwc2/hcd.c
index a3f34dd..24db997 100644
--- a/drivers/usb/dwc2/hcd.c
+++ b/drivers/usb/dwc2/hcd.c
@@ -54,6 +54,8 @@
 #include "core.h"
 #include "hcd.h"
 
+static void dwc2_port_resume(struct dwc2_hsotg *hsotg);
+
 /*
  * =
  *  Host Core Layer Functions
@@ -3204,6 +3206,11 @@ static void dwc2_conn_id_status_change(struct 
work_struct *work)
if (gotgctl & GOTGCTL_CONID_B) {
/* Wait for switch to device mode */
dev_dbg(hsotg->dev, "connId B\n");
+   if (hsotg->bus_suspended) {
+   dev_info(hsotg->dev,
+"Do port resume before switching to device 
mode\n");
+   dwc2_port_resume(hsotg);
+   }
while (!dwc2_is_device_mode(hsotg)) {
dev_info(hsotg->dev,
 "Waiting for Peripheral Mode, Mode=%s\n",
-- 
2.7.4

[RFC][PATCH 5/5] usb: dwc2: Add a quirk to allow speed negotiation for Hisilicon Hi6220

[John Stultz]

From: Chen Yu 

The Hi6220's usb controller is limited in that it does not
support "Split Transactions", so it does not support communicating
with low-speed and full-speed devices behind a high-speed hub.

Thus it requires a quirk so that we can manually drop the usb
speed when low/full-speed are attached, and bump back to high
speed when they are removed.

Cc: Wei Xu 
Cc: Guodong Xu 
Cc: Amit Pundir 
Cc: Rob Herring 
Cc: John Youn 
Cc: Douglas Anderson 
Cc: Chen Yu 
Cc: Kishon Vijay Abraham I 
Cc: Felipe Balbi 
Cc: Greg Kroah-Hartman 
Cc: linux-...@vger.kernel.org
Signed-off-by: Chen Yu 
[jstultz: Reworked to simplify the patch, and made
 commit log to be more specific about the issue]
Signed-off-by: John Stultz 
---
v2:
* Fix build issue reported by kbuildbot
* Rework to avoid using new dts entry suggested by RobH
* Further tweaks from Chen Yu to try to address comments from
  John Youn
* Further simplified logic
---
 drivers/usb/dwc2/core.h |  6 +
 drivers/usb/dwc2/hcd.c  | 60 +
 drivers/usb/dwc2/platform.c |  1 +
 3 files changed, 67 insertions(+)

diff --git a/drivers/usb/dwc2/core.h b/drivers/usb/dwc2/core.h
index 963ea1b..de1fa0c 100644
--- a/drivers/usb/dwc2/core.h
+++ b/drivers/usb/dwc2/core.h
@@ -417,6 +417,11 @@ enum dwc2_ep0_state {
  * needed.
  * 0 - No (default)
  * 1 - Yes
+ * @change_speed_quirk: Change speed configuration to DWC2_SPEED_PARAM_FULL
+ *  while full speed device connect. And change speed
+ *  back to DWC2_SPEED_PARAM_HIGH while device is gone.
+ * 0 - No (default)
+ * 1 - Yes
  *
  * The following parameters may be specified when starting the module. These
  * parameters define how the DWC_otg controller should be configured. A
@@ -457,6 +462,7 @@ struct dwc2_core_params {
int uframe_sched;
int external_id_pin_ctl;
int hibernation;
+   int change_speed_quirk;
 };
 
 /**
diff --git a/drivers/usb/dwc2/hcd.c b/drivers/usb/dwc2/hcd.c
index 008f5bc..7cf8d8e 100644
--- a/drivers/usb/dwc2/hcd.c
+++ b/drivers/usb/dwc2/hcd.c
@@ -4873,6 +4873,61 @@ static void _dwc2_hcd_clear_tt_buffer_complete(struct 
usb_hcd *hcd,
spin_unlock_irqrestore(>lock, flags);
 }
 
+/*
+ * HPRT0_SPD_HIGH_SPEED: high speed
+ * HPRT0_SPD_FULL_SPEED: full speed
+ */
+static void dwc2_change_bus_speed(struct usb_hcd *hcd, int speed)
+{
+   struct dwc2_hsotg *hsotg = dwc2_hcd_to_hsotg(hcd);
+
+   if (hsotg->core_params->speed == speed)
+   return;
+
+   hsotg->core_params->speed = speed;
+   queue_work(hsotg->wq_otg, >wf_otg);
+}
+
+static void dwc2_free_dev(struct usb_hcd *hcd, struct usb_device *udev)
+{
+   struct dwc2_hsotg *hsotg = dwc2_hcd_to_hsotg(hcd);
+
+   if (!hsotg->core_params->change_speed_quirk)
+   return;
+
+   /*
+* On removal, set speed to default high-speed.
+*/
+   if (udev->parent && udev->parent->speed > USB_SPEED_UNKNOWN &&
+   udev->parent->speed < USB_SPEED_HIGH) {
+   dev_info(hsotg->dev, "Set speed to default high-speed\n");
+   dwc2_change_bus_speed(hcd, HPRT0_SPD_HIGH_SPEED);
+   }
+}
+
+static int dwc2_reset_device(struct usb_hcd *hcd, struct usb_device *udev)
+{
+   struct dwc2_hsotg *hsotg = dwc2_hcd_to_hsotg(hcd);
+
+   if (!hsotg->core_params->change_speed_quirk)
+   return 0;
+
+   if (udev->speed == USB_SPEED_HIGH) {
+   dev_info(hsotg->dev, "Set speed to high-speed\n");
+   dwc2_change_bus_speed(hcd, HPRT0_SPD_HIGH_SPEED);
+   } else if ((udev->speed == USB_SPEED_FULL ||
+   udev->speed == USB_SPEED_LOW)) {
+   /*
+* Change speed setting to full-speed if there's
+* a full-speed or low-speed device plugged in.
+*/
+   dev_info(hsotg->dev, "Set speed to full-speed\n");
+   dwc2_change_bus_speed(hcd, HPRT0_SPD_FULL_SPEED);
+   }
+
+   return 0;
+}
+
 static struct hc_driver dwc2_hc_driver = {
.description = "dwc2_hsotg",
.product_desc = "DWC OTG Controller",
@@ -5028,6 +5083,11 @@ int dwc2_hcd_init(struct dwc2_hsotg *hsotg, int irq)
dev_warn(hsotg->dev, "can't set coherent DMA mask\n");
}
 
+   if (hsotg->core_params->change_speed_quirk) {
+   dwc2_hc_driver.free_dev = dwc2_free_dev;
+   dwc2_hc_driver.reset_device = dwc2_reset_device;
+   }
+
hcd = usb_create_hcd(_hc_driver, hsotg->dev, dev_name(hsotg->dev));
if (!hcd)
goto error1;
diff --git a/drivers/usb/dwc2/platform.c b/drivers/usb/dwc2/platform.c
index 8e1728b..17eb5fd 100644
--- a/drivers/usb/dwc2/platform.c
+++ b/drivers/usb/dwc2/platform.c
@@ -85,6 +85,7 @@ static const struct dwc2_core_params params_hi6220 

[RFC][PATCH 3/5] usb: dwc2: Force port resume on switching to device mode

[John Stultz]

From: Chen Yu 

We've seen failures when switching between host and gadget mode,
which was diagnosed as being caused due to the bus being
auto-suspended when we switched.

So this patch forces a port resume when switching to device
mode if the bus is suspended.

Cc: Wei Xu 
Cc: Guodong Xu 
Cc: Amit Pundir 
Cc: Rob Herring 
Cc: John Youn 
Cc: Douglas Anderson 
Cc: Chen Yu 
Cc: Felipe Balbi 
Cc: Greg Kroah-Hartman 
Cc: linux-...@vger.kernel.org
Signed-off-by: Chen Yu 
Signed-off-by: John Stultz 
---
 drivers/usb/dwc2/hcd.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/drivers/usb/dwc2/hcd.c b/drivers/usb/dwc2/hcd.c
index a3f34dd..24db997 100644
--- a/drivers/usb/dwc2/hcd.c
+++ b/drivers/usb/dwc2/hcd.c
@@ -54,6 +54,8 @@
 #include "core.h"
 #include "hcd.h"
 
+static void dwc2_port_resume(struct dwc2_hsotg *hsotg);
+
 /*
  * =
  *  Host Core Layer Functions
@@ -3204,6 +3206,11 @@ static void dwc2_conn_id_status_change(struct 
work_struct *work)
if (gotgctl & GOTGCTL_CONID_B) {
/* Wait for switch to device mode */
dev_dbg(hsotg->dev, "connId B\n");
+   if (hsotg->bus_suspended) {
+   dev_info(hsotg->dev,
+"Do port resume before switching to device 
mode\n");
+   dwc2_port_resume(hsotg);
+   }
while (!dwc2_is_device_mode(hsotg)) {
dev_info(hsotg->dev,
 "Waiting for Peripheral Mode, Mode=%s\n",
-- 
2.7.4

[GIT PULL] s390 patches for 4.10 merge window #1

[Martin Schwidefsky]

Hi Linus,

please pull from the 'for-linus' branch of

git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux.git for-linus

to receive the following updates:

The main bulk of the s390 patches for the 4.10 merge window:

* Add support for the contiguous memory allocator.

* The recovery for I/O errors in the dasd device driver is improved, the
  driver will now remove channel paths that are not working properly.

* Additional fields are added to /proc/sysinfo, the extended partition name
  and the partition UUID.

* New naming for PCI devices with system defined UIDs.

* The last few remaining alloc_bootmem calls are converted to memblock.

* The thread_info structure is stripped down and moved to the task_struct.
  The only field left in thread_info is the flags field.

* Rework of the arch topology code to fix a fake numa issue.

* Refactoring of the atomic primitives and add a new preempt_count
  implementation.

* Clocksource steering for the STP sync check offsets.

* The s390 specific headers are changed to make them usable with CLANG.

* Bug fixes and cleanup.

The shortlog:

Christian Borntraeger (1):
  s390/cpumf: Use configuration level indication for sampling data

Dan Carpenter (1):
  s390/crypto: unlock on error in prng_tdes_read()

Dong Jia Shi (1):
  s390/cio: clean up DEV_STATE_SENSE_PGID

Gerald Schaefer (1):
  s390/vmlogrdr: fix IUCV buffer allocation

Harald Freudenberger (1):
  MAINTAINERS: update for maintainer of s390/zcrypt

Heiko Carstens (24):
  s390: move thread_info into task_struct
  s390/uaccess: make setfs macro return void
  s390/thread_info: get rid of THREAD_ORDER define
  s390/cpumf: simplify psw generation
  s390: add cma support
  s390: update defconfig
  s390: convert remaining bootmem allocations to memblock
  s390: use generic asm-offsets.h
  s390/hypfs: add hypfs header file to uapi header export list
  s390/uapi: sort header export list
  s390/kexec: use node 0 when re-adding crash kernel memory
  s390/setup: fix memblock usage
  s390/numa: always use logical cpu and core ids
  s390/smp: use smp_get_base_cpu() helper function
  s390/topology: always use s390 specific sched_domain_topology_level
  s390/smp: initialize cpu_present_mask in setup_arch
  s390/topology: use cpu_topology array instead of per cpu variable
  s390/numa: establish cpu to node mapping early
  s390/numa: pin all possible cpus to nodes early
  s390: remove unused labels from entry.S
  s390: exclude early C code from gcov profiling
  s390: fix initrd corruptions with gcov/kcov instrumented kernels
  s390: cleanup arch/s390/kernel Makefile
  s390: provide memmove implementation

Jan Höppner (7):
  s390/dasd: Make setting queue_max_segments more explicit
  s390/dasd: Define often used variable
  s390/dasd: Replace simple_strtoul with kstrtouint
  s390/dasd: Make use of dasd_set_feature() more often
  s390/dasd: Eliminate race condition in dasd_generic_set_offline()
  s390/dasd: Fix locking issue when changing EER attribute
  s390/dasd: Fix locking issue when changing RO attribute

Lars-Peter Clausen (1):
  s390/zcrypt: Convert to PM ops

Martin Schwidefsky (12):
  s390/time: refactor clock sync
  s390/time: adjust last_update_clock at clock synchronization
  s390/time: steer clocksource on STP sync events
  s390/atomic: refactor atomic primitives
  s390/bitops: use atomic primitives for bitops
  s390/preempt: move preempt_count to the lowcore
  s390: move system_call field from thread_info to thread_struct
  s390: move cputime accounting fields from thread_info to thread_struct
  s390: move sys_call_table and last_break from thread_info to thread_struct
  s390/time: fix clocksource steering for negative clock offsets
  s390: fix kernel oops for CONFIG_MARCH_Z900=y builds
  s390: fix machine check panic stack switch

Masahiro Yamada (3):
  s390: delete unneeded #include  from facilities_src.h
  s390: squash facilities_src.h into gen_facilities.c
  s390: remove unneeded dependency for gen_facilities

Michael Holzheu (2):
  zcore: Improve startup-message text
  s390: Remove VLAIS in ptff() and clear_table()

Paul Gortmaker (9):
  s390: cio: make it explicitly non-modular
  s390: char: make zcore explicitly non-modular
  s390: char: make con3215 explicitly non-modular
  s390: char: make sclp_tty explicitly non-modular
  s390: char: make slcp_quiesce explicitly non-modular
  s390: hypfs: make inode explicitly non-modular
  s390: kernel: make lgr explicitly non-modular
  s390: hotplug: make pci_hpc explicitly non-modular
  s390: virtio: make ccw explicitly non-modular

Sebastian Ott (4):
  s390/pci: fix dma address calculation in map_sg
  s390/pci_dma: make lazy flush independent from the tlb_refresh bit
  s390/pci_dma: remove memset 

[GIT PULL] s390 patches for 4.10 merge window #1

[Martin Schwidefsky]

Hi Linus,

please pull from the 'for-linus' branch of

git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux.git for-linus

to receive the following updates:

The main bulk of the s390 patches for the 4.10 merge window:

* Add support for the contiguous memory allocator.

* The recovery for I/O errors in the dasd device driver is improved, the
  driver will now remove channel paths that are not working properly.

* Additional fields are added to /proc/sysinfo, the extended partition name
  and the partition UUID.

* New naming for PCI devices with system defined UIDs.

* The last few remaining alloc_bootmem calls are converted to memblock.

* The thread_info structure is stripped down and moved to the task_struct.
  The only field left in thread_info is the flags field.

* Rework of the arch topology code to fix a fake numa issue.

* Refactoring of the atomic primitives and add a new preempt_count
  implementation.

* Clocksource steering for the STP sync check offsets.

* The s390 specific headers are changed to make them usable with CLANG.

* Bug fixes and cleanup.

The shortlog:

Christian Borntraeger (1):
  s390/cpumf: Use configuration level indication for sampling data

Dan Carpenter (1):
  s390/crypto: unlock on error in prng_tdes_read()

Dong Jia Shi (1):
  s390/cio: clean up DEV_STATE_SENSE_PGID

Gerald Schaefer (1):
  s390/vmlogrdr: fix IUCV buffer allocation

Harald Freudenberger (1):
  MAINTAINERS: update for maintainer of s390/zcrypt

Heiko Carstens (24):
  s390: move thread_info into task_struct
  s390/uaccess: make setfs macro return void
  s390/thread_info: get rid of THREAD_ORDER define
  s390/cpumf: simplify psw generation
  s390: add cma support
  s390: update defconfig
  s390: convert remaining bootmem allocations to memblock
  s390: use generic asm-offsets.h
  s390/hypfs: add hypfs header file to uapi header export list
  s390/uapi: sort header export list
  s390/kexec: use node 0 when re-adding crash kernel memory
  s390/setup: fix memblock usage
  s390/numa: always use logical cpu and core ids
  s390/smp: use smp_get_base_cpu() helper function
  s390/topology: always use s390 specific sched_domain_topology_level
  s390/smp: initialize cpu_present_mask in setup_arch
  s390/topology: use cpu_topology array instead of per cpu variable
  s390/numa: establish cpu to node mapping early
  s390/numa: pin all possible cpus to nodes early
  s390: remove unused labels from entry.S
  s390: exclude early C code from gcov profiling
  s390: fix initrd corruptions with gcov/kcov instrumented kernels
  s390: cleanup arch/s390/kernel Makefile
  s390: provide memmove implementation

Jan Höppner (7):
  s390/dasd: Make setting queue_max_segments more explicit
  s390/dasd: Define often used variable
  s390/dasd: Replace simple_strtoul with kstrtouint
  s390/dasd: Make use of dasd_set_feature() more often
  s390/dasd: Eliminate race condition in dasd_generic_set_offline()
  s390/dasd: Fix locking issue when changing EER attribute
  s390/dasd: Fix locking issue when changing RO attribute

Lars-Peter Clausen (1):
  s390/zcrypt: Convert to PM ops

Martin Schwidefsky (12):
  s390/time: refactor clock sync
  s390/time: adjust last_update_clock at clock synchronization
  s390/time: steer clocksource on STP sync events
  s390/atomic: refactor atomic primitives
  s390/bitops: use atomic primitives for bitops
  s390/preempt: move preempt_count to the lowcore
  s390: move system_call field from thread_info to thread_struct
  s390: move cputime accounting fields from thread_info to thread_struct
  s390: move sys_call_table and last_break from thread_info to thread_struct
  s390/time: fix clocksource steering for negative clock offsets
  s390: fix kernel oops for CONFIG_MARCH_Z900=y builds
  s390: fix machine check panic stack switch

Masahiro Yamada (3):
  s390: delete unneeded #include  from facilities_src.h
  s390: squash facilities_src.h into gen_facilities.c
  s390: remove unneeded dependency for gen_facilities

Michael Holzheu (2):
  zcore: Improve startup-message text
  s390: Remove VLAIS in ptff() and clear_table()

Paul Gortmaker (9):
  s390: cio: make it explicitly non-modular
  s390: char: make zcore explicitly non-modular
  s390: char: make con3215 explicitly non-modular
  s390: char: make sclp_tty explicitly non-modular
  s390: char: make slcp_quiesce explicitly non-modular
  s390: hypfs: make inode explicitly non-modular
  s390: kernel: make lgr explicitly non-modular
  s390: hotplug: make pci_hpc explicitly non-modular
  s390: virtio: make ccw explicitly non-modular

Sebastian Ott (4):
  s390/pci: fix dma address calculation in map_sg
  s390/pci_dma: make lazy flush independent from the tlb_refresh bit
  s390/pci_dma: remove memset 

[GIT PULL] xen: features and fixes for 4.10 rc0

[Juergen Gross]

Linus,

Please git pull the following tag:

 git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git
for-linus-4.10-rc0-tag

xen: features and fixes for 4.10 rc0

These are some fixes, a move of some arm related headers to share them
between arm and arm64 and a series introducing a helper to make code
more readable.

The most notable change is David stepping down as maintainer of the Xen
hypervisor interface. This results in me sending you the pull requests
for Xen related code from now on.

Thanks.

Juergen

 MAINTAINERS|   1 -
 arch/arm/include/asm/xen/hypercall.h   |  88 +
 arch/arm/include/asm/xen/hypervisor.h  |  40 +-
 arch/arm/include/asm/xen/interface.h   |  86 +
 arch/arm/include/asm/xen/page-coherent.h   |  99 +--
 arch/arm/include/asm/xen/page.h| 123 +-
 arch/arm/xen/enlighten.c   |   3 +-
 arch/arm64/include/asm/xen/hypercall.h |   2 +-
 arch/arm64/include/asm/xen/hypervisor.h|   2 +-
 arch/arm64/include/asm/xen/interface.h |   2 +-
 arch/arm64/include/asm/xen/page-coherent.h |   2 +-
 arch/arm64/include/asm/xen/page.h  |   2 +-
 arch/x86/include/asm/e820.h|  12 +-
 arch/x86/pci/xen.c |   4 +-
 arch/x86/xen/setup.c   |   6 +-
 drivers/block/xen-blkback/xenbus.c |  36 +++---
 drivers/block/xen-blkfront.c   |  81 
 drivers/char/tpm/xen-tpmfront.c|   8 +-
 drivers/input/misc/xen-kbdfront.c  |  13 +-
 drivers/net/xen-netback/xenbus.c   |  52 +++-
 drivers/net/xen-netfront.c |  67 +++---
 drivers/pci/xen-pcifront.c |   6 +-
 drivers/scsi/xen-scsifront.c   | 195
+
 drivers/video/fbdev/xen-fbfront.c  |  13 +-
 drivers/xen/balloon.c  |   6 +-
 drivers/xen/events/events_base.c   |   2 +-
 drivers/xen/gntalloc.c |   9 +-
 drivers/xen/gntdev.c   |   2 +-
 drivers/xen/platform-pci.c |   6 +-
 drivers/xen/xen-pciback/xenbus.c   |   8 +-
 drivers/xen/xenbus/xenbus_dev_frontend.c   |   2 +
 drivers/xen/xenbus/xenbus_probe.c  |   4 +-
 drivers/xen/xenbus/xenbus_probe_backend.c  |   8 +-
 drivers/xen/xenbus/xenbus_xs.c |  22 +++-
 fs/proc/generic.c  |   1 +
 fs/proc/internal.h |   1 -
 include/linux/proc_fs.h|   2 +
 include/xen/arm/hypercall.h|  87 +
 include/xen/arm/hypervisor.h   |  39 ++
 include/xen/arm/interface.h|  85 +
 include/xen/arm/page-coherent.h|  98 +++
 include/xen/arm/page.h | 122 ++
 include/xen/xenbus.h   |   4 +
 43 files changed, 670 insertions(+), 781 deletions(-)

Alex Thorlton (2):
  x86: Make E820_X_MAX unconditionally larger than E820MAX
  xen/x86: Increase xen_e820_map to E820_X_MAX possible entries

Arnd Bergmann (1):
  xen-netback: fix error handling output

Boris Ostrovsky (1):
  xen/gntdev: Use VM_MIXEDMAP instead of VM_IO to avoid NUMA balancing

David Vrabel (2):
  MAINTAINERS: update XEN HYPERVISOR INTERFACE
  xenbus: fix deadlock on writes to /proc/xen/xenbus

Geliang Tang (1):
  xen-platform: use builtin_pci_driver

Juergen Gross (13):
  xen: introduce xenbus_read_unsigned()
  xen: make use of xenbus_read_unsigned() in xen-blkback
  xen: make use of xenbus_read_unsigned() in xen-blkfront
  xen: make use of xenbus_read_unsigned() in xen-tpmfront
  xen: make use of xenbus_read_unsigned() in xen-kbdfront
  xen: make use of xenbus_read_unsigned() in xen-netback
  xen: make use of xenbus_read_unsigned() in xen-netfront
  xen: make use of xenbus_read_unsigned() in xen-pcifront
  xen: make use of xenbus_read_unsigned() in xen-scsifront
  xen: make use of xenbus_read_unsigned() in xen-fbfront
  xen: make use of xenbus_read_unsigned() in xen-pciback
  xen: make use of xenbus_read_unsigned() in xenbus
  xen/scsifront: don't request a slot on the ring until request is ready

Julien Grall (1):
  arm/xen: Use alloc_percpu rather than __alloc_percpu

Konrad Rzeszutek Wilk (1):
  xen/pci: Bubble up error and fix description.

Marc Zyngier (1):
  arm/arm64: xen: Move shared architecture headers to include/xen/arm

Pan Bian (2):
  xen: set error code on failures
  xen: xenbus: set error code on failure

Quentin Lambert (1):
  xen-scsifront: Add a missing call to kfree

Ross Lagerwall (1):
  xen/balloon: Only mark a page as managed when it is released

Seth Forshee (1):
  xenfs: Use proc_create_mount_point() to create /proc/xen

Vitaly Kuznetsov (1):
  xen/events: use xen_vcpu_id mapping for 

[GIT PULL] xen: features and fixes for 4.10 rc0

[Juergen Gross]

Linus,

Please git pull the following tag:

 git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git
for-linus-4.10-rc0-tag

xen: features and fixes for 4.10 rc0

These are some fixes, a move of some arm related headers to share them
between arm and arm64 and a series introducing a helper to make code
more readable.

The most notable change is David stepping down as maintainer of the Xen
hypervisor interface. This results in me sending you the pull requests
for Xen related code from now on.

Thanks.

Juergen

 MAINTAINERS|   1 -
 arch/arm/include/asm/xen/hypercall.h   |  88 +
 arch/arm/include/asm/xen/hypervisor.h  |  40 +-
 arch/arm/include/asm/xen/interface.h   |  86 +
 arch/arm/include/asm/xen/page-coherent.h   |  99 +--
 arch/arm/include/asm/xen/page.h| 123 +-
 arch/arm/xen/enlighten.c   |   3 +-
 arch/arm64/include/asm/xen/hypercall.h |   2 +-
 arch/arm64/include/asm/xen/hypervisor.h|   2 +-
 arch/arm64/include/asm/xen/interface.h |   2 +-
 arch/arm64/include/asm/xen/page-coherent.h |   2 +-
 arch/arm64/include/asm/xen/page.h  |   2 +-
 arch/x86/include/asm/e820.h|  12 +-
 arch/x86/pci/xen.c |   4 +-
 arch/x86/xen/setup.c   |   6 +-
 drivers/block/xen-blkback/xenbus.c |  36 +++---
 drivers/block/xen-blkfront.c   |  81 
 drivers/char/tpm/xen-tpmfront.c|   8 +-
 drivers/input/misc/xen-kbdfront.c  |  13 +-
 drivers/net/xen-netback/xenbus.c   |  52 +++-
 drivers/net/xen-netfront.c |  67 +++---
 drivers/pci/xen-pcifront.c |   6 +-
 drivers/scsi/xen-scsifront.c   | 195
+
 drivers/video/fbdev/xen-fbfront.c  |  13 +-
 drivers/xen/balloon.c  |   6 +-
 drivers/xen/events/events_base.c   |   2 +-
 drivers/xen/gntalloc.c |   9 +-
 drivers/xen/gntdev.c   |   2 +-
 drivers/xen/platform-pci.c |   6 +-
 drivers/xen/xen-pciback/xenbus.c   |   8 +-
 drivers/xen/xenbus/xenbus_dev_frontend.c   |   2 +
 drivers/xen/xenbus/xenbus_probe.c  |   4 +-
 drivers/xen/xenbus/xenbus_probe_backend.c  |   8 +-
 drivers/xen/xenbus/xenbus_xs.c |  22 +++-
 fs/proc/generic.c  |   1 +
 fs/proc/internal.h |   1 -
 include/linux/proc_fs.h|   2 +
 include/xen/arm/hypercall.h|  87 +
 include/xen/arm/hypervisor.h   |  39 ++
 include/xen/arm/interface.h|  85 +
 include/xen/arm/page-coherent.h|  98 +++
 include/xen/arm/page.h | 122 ++
 include/xen/xenbus.h   |   4 +
 43 files changed, 670 insertions(+), 781 deletions(-)

Alex Thorlton (2):
  x86: Make E820_X_MAX unconditionally larger than E820MAX
  xen/x86: Increase xen_e820_map to E820_X_MAX possible entries

Arnd Bergmann (1):
  xen-netback: fix error handling output

Boris Ostrovsky (1):
  xen/gntdev: Use VM_MIXEDMAP instead of VM_IO to avoid NUMA balancing

David Vrabel (2):
  MAINTAINERS: update XEN HYPERVISOR INTERFACE
  xenbus: fix deadlock on writes to /proc/xen/xenbus

Geliang Tang (1):
  xen-platform: use builtin_pci_driver

Juergen Gross (13):
  xen: introduce xenbus_read_unsigned()
  xen: make use of xenbus_read_unsigned() in xen-blkback
  xen: make use of xenbus_read_unsigned() in xen-blkfront
  xen: make use of xenbus_read_unsigned() in xen-tpmfront
  xen: make use of xenbus_read_unsigned() in xen-kbdfront
  xen: make use of xenbus_read_unsigned() in xen-netback
  xen: make use of xenbus_read_unsigned() in xen-netfront
  xen: make use of xenbus_read_unsigned() in xen-pcifront
  xen: make use of xenbus_read_unsigned() in xen-scsifront
  xen: make use of xenbus_read_unsigned() in xen-fbfront
  xen: make use of xenbus_read_unsigned() in xen-pciback
  xen: make use of xenbus_read_unsigned() in xenbus
  xen/scsifront: don't request a slot on the ring until request is ready

Julien Grall (1):
  arm/xen: Use alloc_percpu rather than __alloc_percpu

Konrad Rzeszutek Wilk (1):
  xen/pci: Bubble up error and fix description.

Marc Zyngier (1):
  arm/arm64: xen: Move shared architecture headers to include/xen/arm

Pan Bian (2):
  xen: set error code on failures
  xen: xenbus: set error code on failure

Quentin Lambert (1):
  xen-scsifront: Add a missing call to kfree

Ross Lagerwall (1):
  xen/balloon: Only mark a page as managed when it is released

Seth Forshee (1):
  xenfs: Use proc_create_mount_point() to create /proc/xen

Vitaly Kuznetsov (1):
  xen/events: use xen_vcpu_id mapping for 

Re: [PATCH 0/4] UEFI: EFI_MEMORY_ATTRIBUTES_TABLE support for x86

[joeyli]

Hi Sai,

On Wed, Dec 07, 2016 at 12:13:28PM -0800, Sai Praneeth Prakhya wrote:
> On Wed, 2016-12-07 at 20:04 +, Matt Fleming wrote:
> > On Wed, 07 Dec, at 11:01:06AM, Sai Praneeth Prakhya wrote:
> > > 
> > > Thanks Matt!
> > > 
> > > Would you like to see a new version of these patch series addressing
> > > your comments? Like
> > > 1. Dropping of patch #4
> > > 2. Adding Reviewed-by tag of Joey (Sorry for that)
> > > 3. This time with correct version number
> > 
> > No need, they're already in the 'next' branch of the EFI tree.
> 
> Great! Just saw the patches in 'next' branch.
> Thanks again Matt.
> 
> Regards,
> Sai
> 
>

Thanks for your patches to enable this function for x86.

Joey Lee 

Re: [PATCH 0/4] UEFI: EFI_MEMORY_ATTRIBUTES_TABLE support for x86

[joeyli]

Hi Sai,

On Wed, Dec 07, 2016 at 12:13:28PM -0800, Sai Praneeth Prakhya wrote:
> On Wed, 2016-12-07 at 20:04 +, Matt Fleming wrote:
> > On Wed, 07 Dec, at 11:01:06AM, Sai Praneeth Prakhya wrote:
> > > 
> > > Thanks Matt!
> > > 
> > > Would you like to see a new version of these patch series addressing
> > > your comments? Like
> > > 1. Dropping of patch #4
> > > 2. Adding Reviewed-by tag of Joey (Sorry for that)
> > > 3. This time with correct version number
> > 
> > No need, they're already in the 'next' branch of the EFI tree.
> 
> Great! Just saw the patches in 'next' branch.
> Thanks again Matt.
> 
> Regards,
> Sai
> 
>

Thanks for your patches to enable this function for x86.

Joey Lee 

Re: CVE-2016-7097 causes acl leak

[Cong Wang]

On Mon, Dec 12, 2016 at 4:26 PM, Mark Salyzyn  wrote:
>
> The leaks were introduced in 9p, gfs2, jfs and xfs drivers only.


Only the 9p case is obvious to me:

diff --git a/fs/9p/acl.c b/fs/9p/acl.c
index b3c2cc7..082d227 100644
--- a/fs/9p/acl.c
+++ b/fs/9p/acl.c
@@ -277,6 +277,7 @@ static int v9fs_xattr_set_acl(const struct
xattr_handler *handler,
case ACL_TYPE_ACCESS:
if (acl) {
struct iattr iattr;
+   struct posix_acl *old_acl = acl;

retval = posix_acl_update_mode(inode,
_mode, );
if (retval)
@@ -287,6 +288,7 @@ static int v9fs_xattr_set_acl(const struct
xattr_handler *handler,
 * by the mode bits. So don't
 * update ACL.
 */
+   posix_acl_release(old_acl);
value = NULL;
size = 0;
}


The rest are anti-pattern (modifying parameters on stack via address)
but look correct.

Re: CVE-2016-7097 causes acl leak

[Cong Wang]

On Mon, Dec 12, 2016 at 4:26 PM, Mark Salyzyn  wrote:
>
> The leaks were introduced in 9p, gfs2, jfs and xfs drivers only.


Only the 9p case is obvious to me:

diff --git a/fs/9p/acl.c b/fs/9p/acl.c
index b3c2cc7..082d227 100644
--- a/fs/9p/acl.c
+++ b/fs/9p/acl.c
@@ -277,6 +277,7 @@ static int v9fs_xattr_set_acl(const struct
xattr_handler *handler,
case ACL_TYPE_ACCESS:
if (acl) {
struct iattr iattr;
+   struct posix_acl *old_acl = acl;

retval = posix_acl_update_mode(inode,
_mode, );
if (retval)
@@ -287,6 +288,7 @@ static int v9fs_xattr_set_acl(const struct
xattr_handler *handler,
 * by the mode bits. So don't
 * update ACL.
 */
+   posix_acl_release(old_acl);
value = NULL;
size = 0;
}


The rest are anti-pattern (modifying parameters on stack via address)
but look correct.

Re: [PATCH] SPCR: check bit width for the 16550 UART

[Jon Masters]

On 12/07/2016 10:23 AM, Mark Salter wrote:
> On Tue, 2016-12-06 at 01:34 -0500, Jon Masters wrote:
>> On 12/05/2016 10:55 PM, Duc Dang wrote:

>>> On Mon, Dec 5, 2016 at 6:27 PM, Jon Masters  wrote:

 HOWEVER while the console does come up, the use of "earlycon" on the
 command line (with no parameters) doesn't result in the early SPCR
 console coming up correctly. I see some garbled characters that
 suggest the baud (or register access width) is off somewhere.
>>> My bad that I did not catch this in the morning. Yes, earlycon does
>>> not seems to work as expected. I can see that earlycon parameters
>>> seems to be correct, but the bootconsole message does not come out
>>> (the following is from 'dmesg')
>>>
>>> [0.00] ACPI: SPCR: console: uart,mmio32,0x1c02,115200
>>> [0.00] earlycon: uart0 at MMIO32 0x1c02 (options 
>>> '115200')
>>> [0.00] bootconsole [uart0] enabled
>> The difference appears to be in the baud rate. When I explicitly specify
>> "earlycon=uart8250,mmio32,0x1c021000" no baud is set. When booting with
>> the SPCR, the baud is set to 9600 in my case or 115200 in yours. But we
>> both know that the base clock on the X-Gene UART is weird. Maybe
>> somehow we can explain this through the lack of setting a baud.
> 
> BTW, this behavior is same with devicetree.

At least it's consistent :)

> If you specify a baudrate with earlycon=, the driver tries to set that
> baudrate and if you have an 8250 with some non-standard baud clock, then
> it will fail. Perhaps SPCR shouldn't pass baud option to setup_earlycon().

Yet they seem to explicitly want to do this...in my conversations with some
others we agree that, in many cases, you really want to say "leave the baud
whatever the firmware set it", which would work in this case, but might
break some others. Then again, nobody on x86 Linux is really using the
SPCR today due to it not having been something they used until now and
due to the location of the COM ports being fairly well known ;)

So who knows what folks will prefer, but we should at least get the spec
to cover both situations by explicitly calling out Applied as special.

> Then again, setup_earlycon() has this comment:
> 
>  *setup_earlycon - match and register earlycon console
>  *@buf:   earlycon param string
>  *
>  *Registers the earlycon console matching the earlycon specified
>  *in the param string @buf. Acceptable param strings are of the form
>  *   ,io|mmio|mmio32|mmio32be,,
>  *   ,0x,
>  *   ,
>  *   
>  *
>  *Only for the third form does the earlycon setup() method receive the
>  * string in the 'options' parameter; all other forms set
>  *the parameter to NULL.
> 
> That part about the 3rd form doesn't seem to be true. I don't see where
> options gets set to NULL for forms other than the third.

I saw that also, and agree that it appears totally bogus. We'll want to get
the documentation fixed as part of this cleanup.

So I've been discussing some changes to the SPCR and the current proposal
is that we have two new subtypes - one for 16550s that are non-standard
register width/stride but use the typical base clock, and a specific
additional type for SBSA level 0 compatible 16550 UARTs (Applied). I
will followup when the specification document has been revised.

Jon.

P.S. I had a lot of fun over my birthday reading the original 8250 spec
and learning about how the DLAB stuff works (I think those brain cells had
died). Which - on a total tangent - finally helps with a long standing issue
we have had. We (a small cabal) have wanted to sneak in an instruction into
the ARM ISA or specs referring to DLAB (the initials of a certain person
who owns the ARM ARM) and now we will get to do this into the SBBR ;)

-- 
Computer Architect | Sent from my Fedora powered laptop

Re: [PATCH] SPCR: check bit width for the 16550 UART

[Jon Masters]

On 12/07/2016 10:23 AM, Mark Salter wrote:
> On Tue, 2016-12-06 at 01:34 -0500, Jon Masters wrote:
>> On 12/05/2016 10:55 PM, Duc Dang wrote:

>>> On Mon, Dec 5, 2016 at 6:27 PM, Jon Masters  wrote:

 HOWEVER while the console does come up, the use of "earlycon" on the
 command line (with no parameters) doesn't result in the early SPCR
 console coming up correctly. I see some garbled characters that
 suggest the baud (or register access width) is off somewhere.
>>> My bad that I did not catch this in the morning. Yes, earlycon does
>>> not seems to work as expected. I can see that earlycon parameters
>>> seems to be correct, but the bootconsole message does not come out
>>> (the following is from 'dmesg')
>>>
>>> [0.00] ACPI: SPCR: console: uart,mmio32,0x1c02,115200
>>> [0.00] earlycon: uart0 at MMIO32 0x1c02 (options 
>>> '115200')
>>> [0.00] bootconsole [uart0] enabled
>> The difference appears to be in the baud rate. When I explicitly specify
>> "earlycon=uart8250,mmio32,0x1c021000" no baud is set. When booting with
>> the SPCR, the baud is set to 9600 in my case or 115200 in yours. But we
>> both know that the base clock on the X-Gene UART is weird. Maybe
>> somehow we can explain this through the lack of setting a baud.
> 
> BTW, this behavior is same with devicetree.

At least it's consistent :)

> If you specify a baudrate with earlycon=, the driver tries to set that
> baudrate and if you have an 8250 with some non-standard baud clock, then
> it will fail. Perhaps SPCR shouldn't pass baud option to setup_earlycon().

Yet they seem to explicitly want to do this...in my conversations with some
others we agree that, in many cases, you really want to say "leave the baud
whatever the firmware set it", which would work in this case, but might
break some others. Then again, nobody on x86 Linux is really using the
SPCR today due to it not having been something they used until now and
due to the location of the COM ports being fairly well known ;)

So who knows what folks will prefer, but we should at least get the spec
to cover both situations by explicitly calling out Applied as special.

> Then again, setup_earlycon() has this comment:
> 
>  *setup_earlycon - match and register earlycon console
>  *@buf:   earlycon param string
>  *
>  *Registers the earlycon console matching the earlycon specified
>  *in the param string @buf. Acceptable param strings are of the form
>  *   ,io|mmio|mmio32|mmio32be,,
>  *   ,0x,
>  *   ,
>  *   
>  *
>  *Only for the third form does the earlycon setup() method receive the
>  * string in the 'options' parameter; all other forms set
>  *the parameter to NULL.
> 
> That part about the 3rd form doesn't seem to be true. I don't see where
> options gets set to NULL for forms other than the third.

I saw that also, and agree that it appears totally bogus. We'll want to get
the documentation fixed as part of this cleanup.

So I've been discussing some changes to the SPCR and the current proposal
is that we have two new subtypes - one for 16550s that are non-standard
register width/stride but use the typical base clock, and a specific
additional type for SBSA level 0 compatible 16550 UARTs (Applied). I
will followup when the specification document has been revised.

Jon.

P.S. I had a lot of fun over my birthday reading the original 8250 spec
and learning about how the DLAB stuff works (I think those brain cells had
died). Which - on a total tangent - finally helps with a long standing issue
we have had. We (a small cabal) have wanted to sneak in an instruction into
the ARM ISA or specs referring to DLAB (the initials of a certain person
who owns the ARM ARM) and now we will get to do this into the SBBR ;)

-- 
Computer Architect | Sent from my Fedora powered laptop

Re: [PATCH 4/5] firmware: add SmPL report for custom fallback mechanism

[Julia Lawall]

On Mon, 12 Dec 2016, Luis R. Rodriguez wrote:

> Even though most distributions today disable the fallback mechanism
> by default we've determined that we cannot remove them from the kernel.
> This is not well understood so document the reason and logic behind that.
>
> Recent discussions suggest some future userspace development prospects which
> may enable fallback mechanisms to become more useful while avoiding some
> historical issues. These discussions have made it clear though that there
> is less value to the custom fallback mechanism and an alternative can be
> provided in the future. Its also clear that some old users of the custom
> fallback mechanism were using it as a copy and paste error. Because of
> all this add a Coccinelle SmPL patch to help maintainers police for new
> incorrect users of the custom fallback mechanism.
>
> Best we can do for now then is police for new users of the custom
> fallback mechanism and and fix incorrect users when they are spotted.
> Drivers can only be transitioned out of the custom fallback mechanism
> once we know old userspace cannot be not be broken by a kernel change.
>
> The current SmPL patch reports:
>
> $ export COCCI=scripts/coccinelle/api/request_firmware-custom-fallback.cocci
> $ make coccicheck MODE=report
>
> drivers/leds/leds-lp55xx-common.c:227:8-31: WARNING: please check if driver 
> really needs a custom fallback mechanism
> drivers/firmware/dell_rbu.c:622:17-40: WARNING: please check if driver really 
> needs a custom fallback mechanism
>
> Cc: Richard Purdie 
> Cc: Jacek Anaszewski 
> Cc: linux-l...@vger.kernel.org
> Cc: Abhay Salunke 
> Signed-off-by: Luis R. Rodriguez 

Acked-by: julia.law...@lip6.fr


> ---
>  .../driver-api/firmware/fallback-mechanisms.rst| 17 ++
>  .../api/request_firmware-custom-fallback.cocci | 37 
> ++
>  2 files changed, 54 insertions(+)
>  create mode 100644 
> scripts/coccinelle/api/request_firmware-custom-fallback.cocci
>
> diff --git a/Documentation/driver-api/firmware/fallback-mechanisms.rst 
> b/Documentation/driver-api/firmware/fallback-mechanisms.rst
> index edce1d76ce29..955c11d6ff9d 100644
> --- a/Documentation/driver-api/firmware/fallback-mechanisms.rst
> +++ b/Documentation/driver-api/firmware/fallback-mechanisms.rst
> @@ -28,6 +28,12 @@ CONFIG_FW_LOADER_USER_HELPER_FALLBACK=n
>  the kobject uevent fallback mechanism will never take effect even
>  for request_firmware_nowait() when uevent is set to true.
>
> +Although the fallback mechanisms are not used widely today they cannot be
> +removed from the kernel since some old userspace may exist which could
> +entirely depend on the fallback mechanism enabled with the kernel config 
> option
> +CONFIG_FW_LOADER_USER_HELPER_FALLBACK. In the future though drivers may opt
> +to embrace a different API which provides alternative fallback mechanisms.
> +
>  Justifying the firmware fallback mechanism
>  ==
>
> @@ -176,6 +182,17 @@ but you want to suppress kobject uevents, as you have a 
> custom solution which
>  will monitor for your device addition into the device hierarchy somehow and
>  load firmware for you through a custom path.
>
> +The custom fallback mechanism can often be enabled by mistake. We currently
> +have only 2 users of it, and little justification to enable it for other 
> users.
> +Since it is a common driver developer mistake to enable it, help police for
> +new users of the custom fallback mechanism with::
> +
> +$ export 
> COCCI=scripts/coccinelle/api/request_firmware-avoid-init-probe-init.cocci
> +$ make coccicheck MODE=report
> +
> +Drivers can only be transitioned out of the custom fallback mechanism
> +once we know old userspace cannot be not be broken by a kernel change.
> +
>  Firmware fallback timeout
>  =
>
> diff --git a/scripts/coccinelle/api/request_firmware-custom-fallback.cocci 
> b/scripts/coccinelle/api/request_firmware-custom-fallback.cocci
> new file mode 100644
> index ..c7598cfc4780
> --- /dev/null
> +++ b/scripts/coccinelle/api/request_firmware-custom-fallback.cocci
> @@ -0,0 +1,37 @@
> +// Avoid the firmware custom fallback mechanism at all costs
> +//
> +// request_firmware_nowait() API enables explicit request for use of the 
> custom
> +// fallback mechanism if firmware is not found. Chances are high its use is
> +// just a copy and paste bug. Before you fix the driver be sure to *verify* 
> no
> +// custom firmware loading tool exists that would otherwise break if we 
> replace
> +// the driver to use the uevent fallback mechanism.
> +//
> +// Confidence: High
> +//
> +// Reason for low confidence:
> +//
> +// Copyright: (C) 2016 Luis R. Rodriguez  GPLv2.
> +//
> +// Options: --include-headers
> +
> +virtual report
> +virtual context
> +
> +@ r1 depends on report || context @
> 

Re: [PATCH 4/5] firmware: add SmPL report for custom fallback mechanism

[Julia Lawall]

On Mon, 12 Dec 2016, Luis R. Rodriguez wrote:

> Even though most distributions today disable the fallback mechanism
> by default we've determined that we cannot remove them from the kernel.
> This is not well understood so document the reason and logic behind that.
>
> Recent discussions suggest some future userspace development prospects which
> may enable fallback mechanisms to become more useful while avoiding some
> historical issues. These discussions have made it clear though that there
> is less value to the custom fallback mechanism and an alternative can be
> provided in the future. Its also clear that some old users of the custom
> fallback mechanism were using it as a copy and paste error. Because of
> all this add a Coccinelle SmPL patch to help maintainers police for new
> incorrect users of the custom fallback mechanism.
>
> Best we can do for now then is police for new users of the custom
> fallback mechanism and and fix incorrect users when they are spotted.
> Drivers can only be transitioned out of the custom fallback mechanism
> once we know old userspace cannot be not be broken by a kernel change.
>
> The current SmPL patch reports:
>
> $ export COCCI=scripts/coccinelle/api/request_firmware-custom-fallback.cocci
> $ make coccicheck MODE=report
>
> drivers/leds/leds-lp55xx-common.c:227:8-31: WARNING: please check if driver 
> really needs a custom fallback mechanism
> drivers/firmware/dell_rbu.c:622:17-40: WARNING: please check if driver really 
> needs a custom fallback mechanism
>
> Cc: Richard Purdie 
> Cc: Jacek Anaszewski 
> Cc: linux-l...@vger.kernel.org
> Cc: Abhay Salunke 
> Signed-off-by: Luis R. Rodriguez 

Acked-by: julia.law...@lip6.fr


> ---
>  .../driver-api/firmware/fallback-mechanisms.rst| 17 ++
>  .../api/request_firmware-custom-fallback.cocci | 37 
> ++
>  2 files changed, 54 insertions(+)
>  create mode 100644 
> scripts/coccinelle/api/request_firmware-custom-fallback.cocci
>
> diff --git a/Documentation/driver-api/firmware/fallback-mechanisms.rst 
> b/Documentation/driver-api/firmware/fallback-mechanisms.rst
> index edce1d76ce29..955c11d6ff9d 100644
> --- a/Documentation/driver-api/firmware/fallback-mechanisms.rst
> +++ b/Documentation/driver-api/firmware/fallback-mechanisms.rst
> @@ -28,6 +28,12 @@ CONFIG_FW_LOADER_USER_HELPER_FALLBACK=n
>  the kobject uevent fallback mechanism will never take effect even
>  for request_firmware_nowait() when uevent is set to true.
>
> +Although the fallback mechanisms are not used widely today they cannot be
> +removed from the kernel since some old userspace may exist which could
> +entirely depend on the fallback mechanism enabled with the kernel config 
> option
> +CONFIG_FW_LOADER_USER_HELPER_FALLBACK. In the future though drivers may opt
> +to embrace a different API which provides alternative fallback mechanisms.
> +
>  Justifying the firmware fallback mechanism
>  ==
>
> @@ -176,6 +182,17 @@ but you want to suppress kobject uevents, as you have a 
> custom solution which
>  will monitor for your device addition into the device hierarchy somehow and
>  load firmware for you through a custom path.
>
> +The custom fallback mechanism can often be enabled by mistake. We currently
> +have only 2 users of it, and little justification to enable it for other 
> users.
> +Since it is a common driver developer mistake to enable it, help police for
> +new users of the custom fallback mechanism with::
> +
> +$ export 
> COCCI=scripts/coccinelle/api/request_firmware-avoid-init-probe-init.cocci
> +$ make coccicheck MODE=report
> +
> +Drivers can only be transitioned out of the custom fallback mechanism
> +once we know old userspace cannot be not be broken by a kernel change.
> +
>  Firmware fallback timeout
>  =
>
> diff --git a/scripts/coccinelle/api/request_firmware-custom-fallback.cocci 
> b/scripts/coccinelle/api/request_firmware-custom-fallback.cocci
> new file mode 100644
> index ..c7598cfc4780
> --- /dev/null
> +++ b/scripts/coccinelle/api/request_firmware-custom-fallback.cocci
> @@ -0,0 +1,37 @@
> +// Avoid the firmware custom fallback mechanism at all costs
> +//
> +// request_firmware_nowait() API enables explicit request for use of the 
> custom
> +// fallback mechanism if firmware is not found. Chances are high its use is
> +// just a copy and paste bug. Before you fix the driver be sure to *verify* 
> no
> +// custom firmware loading tool exists that would otherwise break if we 
> replace
> +// the driver to use the uevent fallback mechanism.
> +//
> +// Confidence: High
> +//
> +// Reason for low confidence:
> +//
> +// Copyright: (C) 2016 Luis R. Rodriguez  GPLv2.
> +//
> +// Options: --include-headers
> +
> +virtual report
> +virtual context
> +
> +@ r1 depends on report || context @
> +expression mod, name, dev, gfp, drv, cb;
> +position p;
> +@@
> +
> +(
> +*request_firmware_nowait@p(mod, 

Re: [PATCH v3 1/4] pinctrl: aspeed: Read and write bits in LPC and GFX controllers

[Andrew Jeffery]

On Mon, 2016-12-12 at 10:27 -0600, Rob Herring wrote:
> On Tue, Dec 06, 2016 at 02:11:49PM +1100, Andrew Jeffery wrote:
> > The System Control Unit IP block in the Aspeed SoCs is typically where
> > the pinmux configuration is found, but not always. A number of pins
> > depend on state in one of LPC Host Control (LHC) or SoC Display
> > Controller (GFX) IP blocks, so the Aspeed pinmux drivers should have the
> > means to adjust these as necessary.
> > 
> > We use syscon to cast a regmap over the GFX and LPC blocks, which is
> > used as an arbitration layer between the relevant driver and the pinctrl
> > subsystem. The regmaps are then exposed to the SoC-specific pinctrl
> > drivers by phandles in the devicetree, and are selected during a mux
> > request by querying a new 'ip' member in struct aspeed_sig_desc.
> > 
> > > > Signed-off-by: Andrew Jeffery 
> > ---
> >  .../devicetree/bindings/pinctrl/pinctrl-aspeed.txt |  50 ++-
> >  drivers/pinctrl/aspeed/pinctrl-aspeed-g4.c |  18 +--
> >  drivers/pinctrl/aspeed/pinctrl-aspeed-g5.c |  48 --
> >  drivers/pinctrl/aspeed/pinctrl-aspeed.c| 161 
> > +
> >  drivers/pinctrl/aspeed/pinctrl-aspeed.h|  32 ++--
> >  5 files changed, 214 insertions(+), 95 deletions(-)
> > 
> > diff --git a/Documentation/devicetree/bindings/pinctrl/pinctrl-aspeed.txt 
> > b/Documentation/devicetree/bindings/pinctrl/pinctrl-aspeed.txt
> > index 2ad18c4ea55c..115b0cce6c1c 100644
> > --- a/Documentation/devicetree/bindings/pinctrl/pinctrl-aspeed.txt
> > +++ b/Documentation/devicetree/bindings/pinctrl/pinctrl-aspeed.txt
> > @@ -4,12 +4,19 @@ Aspeed Pin Controllers
> >  The Aspeed SoCs vary in functionality inside a generation but have a 
> > common mux
> >  device register layout.
> >  
> > -Required properties:
> > -- compatible : Should be any one of the following:
> > > > -   "aspeed,ast2400-pinctrl"
> > > > -   "aspeed,g4-pinctrl"
> > > > -   "aspeed,ast2500-pinctrl"
> > > > -   "aspeed,g5-pinctrl"
> > +Required properties for g4:
> > > > +- compatible : Should be any one of the 
> > > > following:
> > > > +   "aspeed,ast2400-pinctrl"
> > > > +   "aspeed,g4-pinctrl"
> > +
> > +Required properties for g5:
> > > > +- compatible : Should be any one of the 
> > > > following:
> > > > +   "aspeed,ast2500-pinctrl"
> > > > +   "aspeed,g5-pinctrl"
> > +
> > > > +- aspeed,external-nodes:   A cell of phandles to external 
> > > > controller nodes:
> > > > +   0: compatible with 
> > > > "aspeed,ast2500-gfx", "syscon"
> > > > +   1: compatible with 
> > > > "aspeed,ast2500-lpchc", "syscon"
> >  
> >  The pin controller node should be a child of a syscon node with the 
> > required
> >  property:
> > @@ -47,7 +54,7 @@ RGMII1 RGMII2 RMII1 RMII2 SD1 SPI1 SPI1DEBUG SPI1PASSTHRU 
> > TIMER4 TIMER5 TIMER6
> >  TIMER7 TIMER8 VGABIOSROM
> >  
> >  
> > -Examples:
> > +g4 Example:
> >  
> > > >  syscon: scu@1e6e2000 {
> > > >     compatible = "syscon", "simple-mfd";
> > > > @@ -63,5 +70,34 @@ syscon: scu@1e6e2000 {
> > > >     };
> >  };
> >  
> > +g5 Example:
> > +
> > +apb {
> > > > > > +   gfx: display@1e6e6000 {
> > > > +   compatible = "aspeed,ast2500-gfx", "syscon";
> > > > +   reg = <0x1e6e6000 0x1000>;
> > > > +   };
> > +
> > > > > > +   lpchc: lpchc@1e7890a0 {
> > > > +   compatible = "aspeed,ast2500-lpchc", "syscon";
> > > > +   reg = <0x1e7890a0 0xc4>;
> > > > +   };
> > +
> > > > > > +   syscon: scu@1e6e2000 {
> > +   compatible = "syscon", "simple-mfd";
> 
> I must have missed this the first time, but "syscon" should be used with 
> a specific compatible. Though, the scu binding does define one.

Yes, the example should be fixed.

> 
> > > > +   reg = <0x1e6e2000 0x1a8>;
> > +
> > +   pinctrl: pinctrl {
> 
> Is this the only child? 

No. A incomplete list of other functions in the SCU includes:

* An RNG
* Power management
* PCI configuration
* System reset
* Clock configuration

> 
> > +   compatible = "aspeed,g5-pinctrl";
> 
> There's no register range for pinctrl?

This may be a mistake on my part; when I wrote this I had no experience
with writing devicetree bindings (and still don't have a lot).

The SCU does have register regions for pinctrl but on reflection I feel
neither the mfd nor syscon bindings describe how children's resources
should be treated in general. The example in the mfd bindings is for
hardware that is register-bit-led,compatible, whose bindings use the
'offset' property rather than 'reg', which still describes where, but
not using the reg property. Given my uncertainty with reg in an mfd
child, I wrote the 

Re: [PATCH v3 1/4] pinctrl: aspeed: Read and write bits in LPC and GFX controllers

[Andrew Jeffery]

On Mon, 2016-12-12 at 10:27 -0600, Rob Herring wrote:
> On Tue, Dec 06, 2016 at 02:11:49PM +1100, Andrew Jeffery wrote:
> > The System Control Unit IP block in the Aspeed SoCs is typically where
> > the pinmux configuration is found, but not always. A number of pins
> > depend on state in one of LPC Host Control (LHC) or SoC Display
> > Controller (GFX) IP blocks, so the Aspeed pinmux drivers should have the
> > means to adjust these as necessary.
> > 
> > We use syscon to cast a regmap over the GFX and LPC blocks, which is
> > used as an arbitration layer between the relevant driver and the pinctrl
> > subsystem. The regmaps are then exposed to the SoC-specific pinctrl
> > drivers by phandles in the devicetree, and are selected during a mux
> > request by querying a new 'ip' member in struct aspeed_sig_desc.
> > 
> > > > Signed-off-by: Andrew Jeffery 
> > ---
> >  .../devicetree/bindings/pinctrl/pinctrl-aspeed.txt |  50 ++-
> >  drivers/pinctrl/aspeed/pinctrl-aspeed-g4.c |  18 +--
> >  drivers/pinctrl/aspeed/pinctrl-aspeed-g5.c |  48 --
> >  drivers/pinctrl/aspeed/pinctrl-aspeed.c| 161 
> > +
> >  drivers/pinctrl/aspeed/pinctrl-aspeed.h|  32 ++--
> >  5 files changed, 214 insertions(+), 95 deletions(-)
> > 
> > diff --git a/Documentation/devicetree/bindings/pinctrl/pinctrl-aspeed.txt 
> > b/Documentation/devicetree/bindings/pinctrl/pinctrl-aspeed.txt
> > index 2ad18c4ea55c..115b0cce6c1c 100644
> > --- a/Documentation/devicetree/bindings/pinctrl/pinctrl-aspeed.txt
> > +++ b/Documentation/devicetree/bindings/pinctrl/pinctrl-aspeed.txt
> > @@ -4,12 +4,19 @@ Aspeed Pin Controllers
> >  The Aspeed SoCs vary in functionality inside a generation but have a 
> > common mux
> >  device register layout.
> >  
> > -Required properties:
> > -- compatible : Should be any one of the following:
> > > > -   "aspeed,ast2400-pinctrl"
> > > > -   "aspeed,g4-pinctrl"
> > > > -   "aspeed,ast2500-pinctrl"
> > > > -   "aspeed,g5-pinctrl"
> > +Required properties for g4:
> > > > +- compatible : Should be any one of the 
> > > > following:
> > > > +   "aspeed,ast2400-pinctrl"
> > > > +   "aspeed,g4-pinctrl"
> > +
> > +Required properties for g5:
> > > > +- compatible : Should be any one of the 
> > > > following:
> > > > +   "aspeed,ast2500-pinctrl"
> > > > +   "aspeed,g5-pinctrl"
> > +
> > > > +- aspeed,external-nodes:   A cell of phandles to external 
> > > > controller nodes:
> > > > +   0: compatible with 
> > > > "aspeed,ast2500-gfx", "syscon"
> > > > +   1: compatible with 
> > > > "aspeed,ast2500-lpchc", "syscon"
> >  
> >  The pin controller node should be a child of a syscon node with the 
> > required
> >  property:
> > @@ -47,7 +54,7 @@ RGMII1 RGMII2 RMII1 RMII2 SD1 SPI1 SPI1DEBUG SPI1PASSTHRU 
> > TIMER4 TIMER5 TIMER6
> >  TIMER7 TIMER8 VGABIOSROM
> >  
> >  
> > -Examples:
> > +g4 Example:
> >  
> > > >  syscon: scu@1e6e2000 {
> > > >     compatible = "syscon", "simple-mfd";
> > > > @@ -63,5 +70,34 @@ syscon: scu@1e6e2000 {
> > > >     };
> >  };
> >  
> > +g5 Example:
> > +
> > +apb {
> > > > > > +   gfx: display@1e6e6000 {
> > > > +   compatible = "aspeed,ast2500-gfx", "syscon";
> > > > +   reg = <0x1e6e6000 0x1000>;
> > > > +   };
> > +
> > > > > > +   lpchc: lpchc@1e7890a0 {
> > > > +   compatible = "aspeed,ast2500-lpchc", "syscon";
> > > > +   reg = <0x1e7890a0 0xc4>;
> > > > +   };
> > +
> > > > > > +   syscon: scu@1e6e2000 {
> > +   compatible = "syscon", "simple-mfd";
> 
> I must have missed this the first time, but "syscon" should be used with 
> a specific compatible. Though, the scu binding does define one.

Yes, the example should be fixed.

> 
> > > > +   reg = <0x1e6e2000 0x1a8>;
> > +
> > +   pinctrl: pinctrl {
> 
> Is this the only child? 

No. A incomplete list of other functions in the SCU includes:

* An RNG
* Power management
* PCI configuration
* System reset
* Clock configuration

> 
> > +   compatible = "aspeed,g5-pinctrl";
> 
> There's no register range for pinctrl?

This may be a mistake on my part; when I wrote this I had no experience
with writing devicetree bindings (and still don't have a lot).

The SCU does have register regions for pinctrl but on reflection I feel
neither the mfd nor syscon bindings describe how children's resources
should be treated in general. The example in the mfd bindings is for
hardware that is register-bit-led,compatible, whose bindings use the
'offset' property rather than 'reg', which still describes where, but
not using the reg property. Given my uncertainty with reg in an mfd
child, I wrote the pinctrl/pinmux driver using 

linux-next: Tree for Dec 13

[Stephen Rothwell]

Hi all,

Please do not add any material for v4.11 to your linux-next included
branches until after v4.10-rc1 has been released.

Changes since 20161212:

The hid tree lost its build failure.

The spi tree lost its build failure.

Non-merge commits (relative to Linus' tree): 8829
 7664 files changed, 471419 insertions(+), 200537 deletions(-)



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

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

Below is a summary of the state of the merge.

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

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

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

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

-- 
Cheers,
Stephen Rothwell

$ git checkout master
$ git reset --hard stable
Merging origin/master (df5f0f0a028c Merge branch 'ras-core-for-linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip)
Merging fixes/master (30066ce675d3 Merge branch 'linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6)
Merging kbuild-current/rc-fixes (152b695d7437 builddeb: fix cross-building to 
arm64 producing host-arch debs)
Merging arc-current/for-curr (7badf6fefca8 ARC: axs10x: really enable ARC PGU)
Merging arm-current/fixes (8478132a8784 Revert "arm: move exports to 
definitions")
Merging m68k-current/for-linus (7e251bb21ae0 m68k: Fix ndelay() macro)
Merging metag-fixes/fixes (35d04077ad96 metag: Only define 
atomic_dec_if_positive conditionally)
Merging powerpc-fixes/fixes (dadc4a1bb9f0 powerpc/64: Fix placement of .text to 
be immediately following .head.text)
Merging sparc/master (8fa3b6f9392b Merge tag 'cris-for-4.10' of 
git://git.kernel.org/pub/scm/linux/kernel/git/jesper/cris)
Merging net/master (8fa3b6f9392b Merge tag 'cris-for-4.10' of 
git://git.kernel.org/pub/scm/linux/kernel/git/jesper/cris)
Merging ipsec/master (bc3913a5378c Merge 
git://git.kernel.org/pub/scm/linux/kernel/git/davem/sparc)
Merging netfilter/master (045169816b31 Merge branch 'linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6)
Merging ipvs/master (045169816b31 Merge branch 'linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6)
Merging wireless-drivers/master (fcd2042e8d36 mwifiex: printk() overflow with 
32-byte SSIDs)
Merging mac80211/master (9590112241ba tipc: fix link statistics counter errors)
Merging sound-current/for-linus (995c6a7fd9b9 ALSA: hiface: Fix M2Tech hiFace 
driver sampling rate change)
Merging pci-current/for-linus (e42010d8207f PCI: Set Read Completion Boundary 
to 128 iff Root Port supports it (_HPX))
Merging driver-core.current/driver-core-linus (a25f0944ba9b Linux 4.9-rc5)
Merging tty.current/tty-linus (a909d3e63699 Linux 4.9-rc3)
Merging usb.current/usb-linus (e5517c2a5a49 Linux 4.9-rc7)
Merging usb-gadget-fixes/fixes (05e78c6933d6 usb: gadget: f_fs: fix wrong 
parenthesis in ffs_func_req_match())
Merging usb-serial-fixes/usb-linus (46490c347df4 USB: serial: option: add dlink 
dwm-158)
Merging usb-chipidea-fixes/ci-for-usb-stable (c7fbb09b2ea1 usb: chipidea: move 
the lock initialization to core file)
Merging phy/fixes (4320f9d4c183 phy: sun4i: check PMU presence when poking 
unknown bit of pmu)
Merging staging.current/staging-linus (a25f0944ba9b Linux 4.9-rc5)
Merging char-misc.current/char-misc-linus (a25f0944ba9b Linux 4.9-rc5)
Merging input-current/for-linus (2425f1808123 Input: change KEY_DATA from 0x275 
to 0x277)
Merging crypto-current/master (678b5c6b22fe crypto: algif_aead - fix 
uninitialized variable warning)
Merging ide/master (797cee982eef Merge branch 'stable-4.8' of 
git://git.infradead.org/use

linux-next: Tree for Dec 13

[Stephen Rothwell]

Hi all,

Please do not add any material for v4.11 to your linux-next included
branches until after v4.10-rc1 has been released.

Changes since 20161212:

The hid tree lost its build failure.

The spi tree lost its build failure.

Non-merge commits (relative to Linus' tree): 8829
 7664 files changed, 471419 insertions(+), 200537 deletions(-)



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

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

Below is a summary of the state of the merge.

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

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

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

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

-- 
Cheers,
Stephen Rothwell

$ git checkout master
$ git reset --hard stable
Merging origin/master (df5f0f0a028c Merge branch 'ras-core-for-linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip)
Merging fixes/master (30066ce675d3 Merge branch 'linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6)
Merging kbuild-current/rc-fixes (152b695d7437 builddeb: fix cross-building to 
arm64 producing host-arch debs)
Merging arc-current/for-curr (7badf6fefca8 ARC: axs10x: really enable ARC PGU)
Merging arm-current/fixes (8478132a8784 Revert "arm: move exports to 
definitions")
Merging m68k-current/for-linus (7e251bb21ae0 m68k: Fix ndelay() macro)
Merging metag-fixes/fixes (35d04077ad96 metag: Only define 
atomic_dec_if_positive conditionally)
Merging powerpc-fixes/fixes (dadc4a1bb9f0 powerpc/64: Fix placement of .text to 
be immediately following .head.text)
Merging sparc/master (8fa3b6f9392b Merge tag 'cris-for-4.10' of 
git://git.kernel.org/pub/scm/linux/kernel/git/jesper/cris)
Merging net/master (8fa3b6f9392b Merge tag 'cris-for-4.10' of 
git://git.kernel.org/pub/scm/linux/kernel/git/jesper/cris)
Merging ipsec/master (bc3913a5378c Merge 
git://git.kernel.org/pub/scm/linux/kernel/git/davem/sparc)
Merging netfilter/master (045169816b31 Merge branch 'linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6)
Merging ipvs/master (045169816b31 Merge branch 'linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6)
Merging wireless-drivers/master (fcd2042e8d36 mwifiex: printk() overflow with 
32-byte SSIDs)
Merging mac80211/master (9590112241ba tipc: fix link statistics counter errors)
Merging sound-current/for-linus (995c6a7fd9b9 ALSA: hiface: Fix M2Tech hiFace 
driver sampling rate change)
Merging pci-current/for-linus (e42010d8207f PCI: Set Read Completion Boundary 
to 128 iff Root Port supports it (_HPX))
Merging driver-core.current/driver-core-linus (a25f0944ba9b Linux 4.9-rc5)
Merging tty.current/tty-linus (a909d3e63699 Linux 4.9-rc3)
Merging usb.current/usb-linus (e5517c2a5a49 Linux 4.9-rc7)
Merging usb-gadget-fixes/fixes (05e78c6933d6 usb: gadget: f_fs: fix wrong 
parenthesis in ffs_func_req_match())
Merging usb-serial-fixes/usb-linus (46490c347df4 USB: serial: option: add dlink 
dwm-158)
Merging usb-chipidea-fixes/ci-for-usb-stable (c7fbb09b2ea1 usb: chipidea: move 
the lock initialization to core file)
Merging phy/fixes (4320f9d4c183 phy: sun4i: check PMU presence when poking 
unknown bit of pmu)
Merging staging.current/staging-linus (a25f0944ba9b Linux 4.9-rc5)
Merging char-misc.current/char-misc-linus (a25f0944ba9b Linux 4.9-rc5)
Merging input-current/for-linus (2425f1808123 Input: change KEY_DATA from 0x275 
to 0x277)
Merging crypto-current/master (678b5c6b22fe crypto: algif_aead - fix 
uninitialized variable warning)
Merging ide/master (797cee982eef Merge branch 'stable-4.8' of 
git://git.infradead.org/use

[PATCH v2] btrfs: limit async_work allocation and worker func duration

[Maxim Patlasov]

Problem statement: unprivileged user who has read-write access to more than
one btrfs subvolume may easily consume all kernel memory (eventually
triggering oom-killer).

Reproducer (./mkrmdir below essentially loops over mkdir/rmdir):

[root@kteam1 ~]# cat prep.sh

DEV=/dev/sdb
mkfs.btrfs -f $DEV
mount $DEV /mnt
for i in `seq 1 16`
do
mkdir /mnt/$i
btrfs subvolume create /mnt/SV_$i
ID=`btrfs subvolume list /mnt |grep "SV_$i$" |cut -d ' ' -f 2`
mount -t btrfs -o subvolid=$ID $DEV /mnt/$i
chmod a+rwx /mnt/$i
done

[root@kteam1 ~]# sh prep.sh

[maxim@kteam1 ~]$ for i in `seq 1 16`; do ./mkrmdir /mnt/$i 2000 2000 & done

[root@kteam1 ~]# for i in `seq 1 4`; do grep "kmalloc-128" /proc/slabinfo | 
grep -v dma; sleep 60; done
kmalloc-12810144  10144128   321 : tunables000 : 
slabdata317317  0
kmalloc-128   9992352 9992352128   321 : tunables000 : 
slabdata 312261 312261  0
kmalloc-128   24226752 24226752128   321 : tunables000 
: slabdata 757086 757086  0
kmalloc-128   42754240 42754240128   321 : tunables000 
: slabdata 1336070 1336070  0

The huge numbers above come from insane number of async_work-s allocated
and queued by btrfs_wq_run_delayed_node.

The problem is caused by btrfs_wq_run_delayed_node() queuing more and more
works if the number of delayed items is above BTRFS_DELAYED_BACKGROUND. The
worker func (btrfs_async_run_delayed_root) processes at least
BTRFS_DELAYED_BATCH items (if they are present in the list). So, the machinery
works as expected while the list is almost empty. As soon as it is getting
bigger, worker func starts to process more than one item at a time, it takes
longer, and the chances to have async_works queued more than needed is getting
higher.

The problem above is worsened by another flaw of delayed-inode implementation:
if async_work was queued in a throttling branch (number of items >=
BTRFS_DELAYED_WRITEBACK), corresponding worker func won't quit until
the number of items < BTRFS_DELAYED_BACKGROUND / 2. So, it is possible that
the func occupies CPU infinitely (up to 30sec in my experiments): while the
func is trying to drain the list, the user activity may add more and more
items to the list.

The patch fixes both problems in straightforward way: refuse queuing too
many works in btrfs_wq_run_delayed_node and bail out of worker func if
at least BTRFS_DELAYED_WRITEBACK items are processed.

Changed in v2: remove support of thresh == NO_THRESHOLD.

Signed-off-by: Maxim Patlasov 
---
 fs/btrfs/async-thread.c  |   14 ++
 fs/btrfs/async-thread.h  |1 +
 fs/btrfs/delayed-inode.c |6 --
 3 files changed, 19 insertions(+), 2 deletions(-)

diff --git a/fs/btrfs/async-thread.c b/fs/btrfs/async-thread.c
index e0f071f..63d1977 100644
--- a/fs/btrfs/async-thread.c
+++ b/fs/btrfs/async-thread.c
@@ -86,6 +86,20 @@ btrfs_work_owner(struct btrfs_work *work)
return work->wq->fs_info;
 }
 
+bool btrfs_workqueue_normal_congested(struct btrfs_workqueue *wq)
+{
+   /*
+* We could compare wq->normal->pending with num_online_cpus()
+* to support "thresh == NO_THRESHOLD" case, but it requires
+* moving up atomic_inc/dec in thresh_queue/exec_hook. Let's
+* postpone it until someone needs the support of that case.
+*/
+   if (wq->normal->thresh == NO_THRESHOLD)
+   return false;
+
+   return atomic_read(>normal->pending) > wq->normal->thresh * 2;
+}
+
 BTRFS_WORK_HELPER(worker_helper);
 BTRFS_WORK_HELPER(delalloc_helper);
 BTRFS_WORK_HELPER(flush_delalloc_helper);
diff --git a/fs/btrfs/async-thread.h b/fs/btrfs/async-thread.h
index 8e52484..1f95973 100644
--- a/fs/btrfs/async-thread.h
+++ b/fs/btrfs/async-thread.h
@@ -84,4 +84,5 @@ void btrfs_workqueue_set_max(struct btrfs_workqueue *wq, int 
max);
 void btrfs_set_work_high_priority(struct btrfs_work *work);
 struct btrfs_fs_info *btrfs_work_owner(struct btrfs_work *work);
 struct btrfs_fs_info *btrfs_workqueue_owner(struct __btrfs_workqueue *wq);
+bool btrfs_workqueue_normal_congested(struct btrfs_workqueue *wq);
 #endif
diff --git a/fs/btrfs/delayed-inode.c b/fs/btrfs/delayed-inode.c
index 3eeb9cd..de946dd 100644
--- a/fs/btrfs/delayed-inode.c
+++ b/fs/btrfs/delayed-inode.c
@@ -1356,7 +1356,8 @@ release_path:
total_done++;
 
btrfs_release_prepared_delayed_node(delayed_node);
-   if (async_work->nr == 0 || total_done < async_work->nr)
+   if ((async_work->nr == 0 && total_done < BTRFS_DELAYED_WRITEBACK) ||
+   total_done < async_work->nr)
goto again;
 
 free_path:
@@ -1372,7 +1373,8 @@ static int btrfs_wq_run_delayed_node(struct 
btrfs_delayed_root *delayed_root,
 {
struct btrfs_async_delayed_work *async_work;
 
-   if (atomic_read(_root->items) < BTRFS_DELAYED_BACKGROUND)
+   if (atomic_read(_root->items) < 

[PATCH v2] btrfs: limit async_work allocation and worker func duration

[Maxim Patlasov]

Problem statement: unprivileged user who has read-write access to more than
one btrfs subvolume may easily consume all kernel memory (eventually
triggering oom-killer).

Reproducer (./mkrmdir below essentially loops over mkdir/rmdir):

[root@kteam1 ~]# cat prep.sh

DEV=/dev/sdb
mkfs.btrfs -f $DEV
mount $DEV /mnt
for i in `seq 1 16`
do
mkdir /mnt/$i
btrfs subvolume create /mnt/SV_$i
ID=`btrfs subvolume list /mnt |grep "SV_$i$" |cut -d ' ' -f 2`
mount -t btrfs -o subvolid=$ID $DEV /mnt/$i
chmod a+rwx /mnt/$i
done

[root@kteam1 ~]# sh prep.sh

[maxim@kteam1 ~]$ for i in `seq 1 16`; do ./mkrmdir /mnt/$i 2000 2000 & done

[root@kteam1 ~]# for i in `seq 1 4`; do grep "kmalloc-128" /proc/slabinfo | 
grep -v dma; sleep 60; done
kmalloc-12810144  10144128   321 : tunables000 : 
slabdata317317  0
kmalloc-128   9992352 9992352128   321 : tunables000 : 
slabdata 312261 312261  0
kmalloc-128   24226752 24226752128   321 : tunables000 
: slabdata 757086 757086  0
kmalloc-128   42754240 42754240128   321 : tunables000 
: slabdata 1336070 1336070  0

The huge numbers above come from insane number of async_work-s allocated
and queued by btrfs_wq_run_delayed_node.

The problem is caused by btrfs_wq_run_delayed_node() queuing more and more
works if the number of delayed items is above BTRFS_DELAYED_BACKGROUND. The
worker func (btrfs_async_run_delayed_root) processes at least
BTRFS_DELAYED_BATCH items (if they are present in the list). So, the machinery
works as expected while the list is almost empty. As soon as it is getting
bigger, worker func starts to process more than one item at a time, it takes
longer, and the chances to have async_works queued more than needed is getting
higher.

The problem above is worsened by another flaw of delayed-inode implementation:
if async_work was queued in a throttling branch (number of items >=
BTRFS_DELAYED_WRITEBACK), corresponding worker func won't quit until
the number of items < BTRFS_DELAYED_BACKGROUND / 2. So, it is possible that
the func occupies CPU infinitely (up to 30sec in my experiments): while the
func is trying to drain the list, the user activity may add more and more
items to the list.

The patch fixes both problems in straightforward way: refuse queuing too
many works in btrfs_wq_run_delayed_node and bail out of worker func if
at least BTRFS_DELAYED_WRITEBACK items are processed.

Changed in v2: remove support of thresh == NO_THRESHOLD.

Signed-off-by: Maxim Patlasov 
---
 fs/btrfs/async-thread.c  |   14 ++
 fs/btrfs/async-thread.h  |1 +
 fs/btrfs/delayed-inode.c |6 --
 3 files changed, 19 insertions(+), 2 deletions(-)

diff --git a/fs/btrfs/async-thread.c b/fs/btrfs/async-thread.c
index e0f071f..63d1977 100644
--- a/fs/btrfs/async-thread.c
+++ b/fs/btrfs/async-thread.c
@@ -86,6 +86,20 @@ btrfs_work_owner(struct btrfs_work *work)
return work->wq->fs_info;
 }
 
+bool btrfs_workqueue_normal_congested(struct btrfs_workqueue *wq)
+{
+   /*
+* We could compare wq->normal->pending with num_online_cpus()
+* to support "thresh == NO_THRESHOLD" case, but it requires
+* moving up atomic_inc/dec in thresh_queue/exec_hook. Let's
+* postpone it until someone needs the support of that case.
+*/
+   if (wq->normal->thresh == NO_THRESHOLD)
+   return false;
+
+   return atomic_read(>normal->pending) > wq->normal->thresh * 2;
+}
+
 BTRFS_WORK_HELPER(worker_helper);
 BTRFS_WORK_HELPER(delalloc_helper);
 BTRFS_WORK_HELPER(flush_delalloc_helper);
diff --git a/fs/btrfs/async-thread.h b/fs/btrfs/async-thread.h
index 8e52484..1f95973 100644
--- a/fs/btrfs/async-thread.h
+++ b/fs/btrfs/async-thread.h
@@ -84,4 +84,5 @@ void btrfs_workqueue_set_max(struct btrfs_workqueue *wq, int 
max);
 void btrfs_set_work_high_priority(struct btrfs_work *work);
 struct btrfs_fs_info *btrfs_work_owner(struct btrfs_work *work);
 struct btrfs_fs_info *btrfs_workqueue_owner(struct __btrfs_workqueue *wq);
+bool btrfs_workqueue_normal_congested(struct btrfs_workqueue *wq);
 #endif
diff --git a/fs/btrfs/delayed-inode.c b/fs/btrfs/delayed-inode.c
index 3eeb9cd..de946dd 100644
--- a/fs/btrfs/delayed-inode.c
+++ b/fs/btrfs/delayed-inode.c
@@ -1356,7 +1356,8 @@ release_path:
total_done++;
 
btrfs_release_prepared_delayed_node(delayed_node);
-   if (async_work->nr == 0 || total_done < async_work->nr)
+   if ((async_work->nr == 0 && total_done < BTRFS_DELAYED_WRITEBACK) ||
+   total_done < async_work->nr)
goto again;
 
 free_path:
@@ -1372,7 +1373,8 @@ static int btrfs_wq_run_delayed_node(struct 
btrfs_delayed_root *delayed_root,
 {
struct btrfs_async_delayed_work *async_work;
 
-   if (atomic_read(_root->items) < BTRFS_DELAYED_BACKGROUND)
+   if (atomic_read(_root->items) < BTRFS_DELAYED_BACKGROUND ||
+ 

[PATCH v2] kasan: Support for r/w instrumentation control

[Maninder Singh]

This provide option to control sanity of read and write operations
Both read and write instrumentation increase size of uImage, So using
this option read or write instrumentation can be avoided if not required.
Useful in case of module sanity, using this uImage sanity can be avoided.

Also user space ASAN provides this support for read/write instrumentation
control.

Signed-off-by: Vaneet narang 
Signed-off-by: Maninder Singh 
Reviewed-by: Ajeet Yadav 
---
v1 -> v2: Added Documentation for the same.

 Documentation/dev-tools/kasan.rst | 16 
 lib/Kconfig.kasan | 16 
 scripts/Makefile.kasan|  4 
 3 files changed, 36 insertions(+)

diff --git a/Documentation/dev-tools/kasan.rst 
b/Documentation/dev-tools/kasan.rst
index f7a18f2..b8147df 100644
--- a/Documentation/dev-tools/kasan.rst
+++ b/Documentation/dev-tools/kasan.rst
@@ -40,6 +40,22 @@ similar to the following to the respective kernel Makefile:
 
 KASAN_SANITIZE := n
 
+Control Over Read/Write Instrumentation of kernel::
+
+- To Disable Read Instrumentation of kernel with:
+
+CONFIG_KASAN_READS = n
+
+Because in some cases we need to check only memory write sanitization
+for better performance, read instrumentation can be disabled.
+
+- To Disable Write Instrumentation of kernel with:
+
+CONFIG_KASAN_WRITES = n
+
+In case when to instrument only external modules, not the entire kernel
+for read or write intrumentation or both.
+
 Error reports
 ~
 
diff --git a/lib/Kconfig.kasan b/lib/Kconfig.kasan
index bd38aab..37d1de9 100644
--- a/lib/Kconfig.kasan
+++ b/lib/Kconfig.kasan
@@ -45,6 +45,22 @@ config KASAN_INLINE
 
 endchoice
 
+config KASAN_READS
+   prompt "Read instrumentation"
+   bool
+   default y
+   depends on KASAN
+   help
+ This configuration controls the sanity of memory read.
+
+config KASAN_WRITES
+   prompt "Write instrumentation"
+   bool
+   default y
+   depends on KASAN
+   help
+ This configuration controls the sanity of memory write.
+
 config TEST_KASAN
tristate "Module for testing kasan for bug detection"
depends on m && KASAN
diff --git a/scripts/Makefile.kasan b/scripts/Makefile.kasan
index 37323b0..a61b18e 100644
--- a/scripts/Makefile.kasan
+++ b/scripts/Makefile.kasan
@@ -29,3 +29,7 @@ else
 endif
 endif
 endif
+
+CFLAGS_KASAN += $(call cc-option, \
+   $(if $(CONFIG_KASAN_READS),, --param asan-instrument-reads=0) \
+   $(if $(CONFIG_KASAN_WRITES),, --param asan-instrument-writes=0))
-- 
1.9.1

[PATCH v2] kasan: Support for r/w instrumentation control

[Maninder Singh]

This provide option to control sanity of read and write operations
Both read and write instrumentation increase size of uImage, So using
this option read or write instrumentation can be avoided if not required.
Useful in case of module sanity, using this uImage sanity can be avoided.

Also user space ASAN provides this support for read/write instrumentation
control.

Signed-off-by: Vaneet narang 
Signed-off-by: Maninder Singh 
Reviewed-by: Ajeet Yadav 
---
v1 -> v2: Added Documentation for the same.

 Documentation/dev-tools/kasan.rst | 16 
 lib/Kconfig.kasan | 16 
 scripts/Makefile.kasan|  4 
 3 files changed, 36 insertions(+)

diff --git a/Documentation/dev-tools/kasan.rst 
b/Documentation/dev-tools/kasan.rst
index f7a18f2..b8147df 100644
--- a/Documentation/dev-tools/kasan.rst
+++ b/Documentation/dev-tools/kasan.rst
@@ -40,6 +40,22 @@ similar to the following to the respective kernel Makefile:
 
 KASAN_SANITIZE := n
 
+Control Over Read/Write Instrumentation of kernel::
+
+- To Disable Read Instrumentation of kernel with:
+
+CONFIG_KASAN_READS = n
+
+Because in some cases we need to check only memory write sanitization
+for better performance, read instrumentation can be disabled.
+
+- To Disable Write Instrumentation of kernel with:
+
+CONFIG_KASAN_WRITES = n
+
+In case when to instrument only external modules, not the entire kernel
+for read or write intrumentation or both.
+
 Error reports
 ~
 
diff --git a/lib/Kconfig.kasan b/lib/Kconfig.kasan
index bd38aab..37d1de9 100644
--- a/lib/Kconfig.kasan
+++ b/lib/Kconfig.kasan
@@ -45,6 +45,22 @@ config KASAN_INLINE
 
 endchoice
 
+config KASAN_READS
+   prompt "Read instrumentation"
+   bool
+   default y
+   depends on KASAN
+   help
+ This configuration controls the sanity of memory read.
+
+config KASAN_WRITES
+   prompt "Write instrumentation"
+   bool
+   default y
+   depends on KASAN
+   help
+ This configuration controls the sanity of memory write.
+
 config TEST_KASAN
tristate "Module for testing kasan for bug detection"
depends on m && KASAN
diff --git a/scripts/Makefile.kasan b/scripts/Makefile.kasan
index 37323b0..a61b18e 100644
--- a/scripts/Makefile.kasan
+++ b/scripts/Makefile.kasan
@@ -29,3 +29,7 @@ else
 endif
 endif
 endif
+
+CFLAGS_KASAN += $(call cc-option, \
+   $(if $(CONFIG_KASAN_READS),, --param asan-instrument-reads=0) \
+   $(if $(CONFIG_KASAN_WRITES),, --param asan-instrument-writes=0))
-- 
1.9.1

Re: [PATCH] Input: ar1021-i2c - fix too long name in driver's device table

[Wolfram Sang]

On Mon, Dec 12, 2016 at 03:57:02PM -0800, Dmitry Torokhov wrote:
> The name field in structure i2c_device_id is 20 characters, and we
> expect it to be NULL-terminated, however we are trying to stuff it with
> 21 bytes and thus NULL-terminator is lost. This causes issues when one
> creates device with name "MICROCHIP_AR1021_I2C" as i2c core cuts off the
> last "C", and automatic module loading by alias does not work as result.
> 
> The -I2C suffix in the device name is superfluous, we know what bus we
> are dealing with, so let's drop it.
> 
> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=116211
> Signed-off-by: Dmitry Torokhov 

Acked-by: Wolfram Sang 



signature.asc
Description: PGP signature

Re: [PATCH] Input: ar1021-i2c - fix too long name in driver's device table

[Wolfram Sang]

On Mon, Dec 12, 2016 at 03:57:02PM -0800, Dmitry Torokhov wrote:
> The name field in structure i2c_device_id is 20 characters, and we
> expect it to be NULL-terminated, however we are trying to stuff it with
> 21 bytes and thus NULL-terminator is lost. This causes issues when one
> creates device with name "MICROCHIP_AR1021_I2C" as i2c core cuts off the
> last "C", and automatic module loading by alias does not work as result.
> 
> The -I2C suffix in the device name is superfluous, we know what bus we
> are dealing with, so let's drop it.
> 
> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=116211
> Signed-off-by: Dmitry Torokhov 

Acked-by: Wolfram Sang 



signature.asc
Description: PGP signature

[GIT PULL] Thermal management updates for v4.10-rc1

[Zhang Rui]

Hi, Linus,

Please pull from
  git://git.kernel.org/pub/scm/linux/kernel/git/rzhang/linux.git next

to receive the latest Thermal Management updates for v4.10-rc1 with
top-most commit 0faf7dd5a947006978b549dfe29a01b710becf4a:

  MAINTAINERS: Samsung: Update maintainer for PWM FAN and SAMSUNG
THERMAL (2016-12-13 11:20:23 +0800)

on top of commit 23400ac997062647f2b63c82030d189671b1effe:

  Merge branch 'for-rc' of
git://git.kernel.org/pub/scm/linux/kernel/git/rzhang/linux (2016-11-22
13:53:01 -0800)

Specifics:

- Thermal core code reorganization and cleanup. Two new files are
  created for thermal sysfs I/F code and thermal helper functions.
  From: Eduardo Valentin.

- Sanitize hotplug and locking for x86_pkg_temp driver.
  From: Thomas Gleixner.

- Update MAINTAINER file for pwm-fan driver and Samsung thermal driver.
  From: Lukasz Majewski.

- Fix module auto-load for max77620, tango and db8500 thermal driver.
  From: Javier Martinez Canillas.

- Fix a bug that thermal hwmon sysfs I/F returns wrong critical trip
  point temperature value. From: Krzysztof Kozlowski.

- Add Skylake PCH 100 series support for intel_pch_thermal driver.
  From: OGAWA Hirofumi.

- Small fixes and cleanups for platform thermal drivers.
  From Julia Lawall, Luis Henriques, Leo Yan, Stephen Boyd,
  Shawn Lin, Javi Merino and Lukasz Luba.

thanks,
rui


Eduardo Valentin (49):
  thermal: core: prevent zones with no types to be registered
  thermal: core: group thermal_zone DEVICE_ATTR's declarations
  thermal: core: group device_create_file() calls that are always
created
  thermal: core: use dev.groups to manage always present tz
attributes
  thermal: core: move emul_temp creation to tz->device.groups
  thermal: core: move mode attribute to tz->device.groups
  thermal: core: move passive attr to tz->device.groups
  thermal: core: improve power actor documentation
  thermal: core: move power actor code out of sysfs I/F section
  thermal: core: remove useless empty line
  thermal: core: fix style on remove_trip_attrs()
  thermal: core: move the trip attrs to the tz sysfs I/F section
  thermal: core: create tz->device.groups dynamically
  thermal: core: move trips attributes to tz->device.groups
  thermal: core: remove unnecessary device_remove() calls
  thermal: core: split passive_store
  thermal: core: split policy_store
  thermal: core: split available_policies_show()
  thermal: core: move to_thermal_zone() macro to header file
  thermal: core: treat correctly the return value of *scanf calls
  thermal: core: match parenthesis on code alignment
  thermal: core: move thermal_zone sysfs to thermal_sysfs.c
  thermal: core: move to_cooling_device macro to header file
  thermal: core: move cooling device sysfs to thermal_sysfs.c
  thermal: core: remove a couple of style issues on helpers
  thermal: core: introduce thermal_helpers.c
  thermal: core: group functions related to governor handling
  thermal: core: move idr handling to device management section
  thermal: core: small style fix on __unbind() helper
  thermal: core: move __unbind() helper to where it is used
  thermal: core: move bind_cdev() to where it is used
  thermal: core: move bind_tz() to where it is used
  thermal: core: fix couple of style issues on __bind() helper
  thermal: core: move __bind() to where it is used
  thermal: core: add inline to print_bind_err_msg()
  thermal: core: move notify to the zone update section
  thermal: core: add a comment describing the main update loop
  thermal: core: add a comment describing the power actor section
  thermal: core: add a comment describing the device management
section
  thermal: sysfs: remove symbols of emul_temp when config is
disabled
  thermal: core: remove FSF address in the GPL notice
  thermal: core: small style fix when checking for
__find_governor()
  thermal: core: standardize line breaking alignment
  thermal: core: remove void function return statements
  thermal: core: remove style warnings and checks
  thermal: core: improve kerneldoc entry of
thermal_cooling_device_unregister
  thermal: core: use kzalloc(sizeof(*ptr),...)
  thermal: sysfs: use kcalloc() instead of kzalloc()
  thermal: core: move slop and offset helpers to thermal_helpers.c

Javi Merino (1):
  devfreq_cooling: pass a pointer to devfreq in the power model
callbacks

Javier Martinez Canillas (3):
  thermal: max77620: Fix module autoload
  thermal: tango: Fix module autoload
  thermal: db8500: Fix module autoload

Julia Lawall (2):
  thermal: hwmon: use permission-specific DEVICE_ATTR variants
  thermal: int340x_thermal: use permission-specific DEVICE_ATTR
variants

Krzysztof Kozlowski (1):
  thermal: hwmon: Properly report critical temperature in sysfs

[GIT PULL] Thermal management updates for v4.10-rc1

[Zhang Rui]

Hi, Linus,

Please pull from
  git://git.kernel.org/pub/scm/linux/kernel/git/rzhang/linux.git next

to receive the latest Thermal Management updates for v4.10-rc1 with
top-most commit 0faf7dd5a947006978b549dfe29a01b710becf4a:

  MAINTAINERS: Samsung: Update maintainer for PWM FAN and SAMSUNG
THERMAL (2016-12-13 11:20:23 +0800)

on top of commit 23400ac997062647f2b63c82030d189671b1effe:

  Merge branch 'for-rc' of
git://git.kernel.org/pub/scm/linux/kernel/git/rzhang/linux (2016-11-22
13:53:01 -0800)

Specifics:

- Thermal core code reorganization and cleanup. Two new files are
  created for thermal sysfs I/F code and thermal helper functions.
  From: Eduardo Valentin.

- Sanitize hotplug and locking for x86_pkg_temp driver.
  From: Thomas Gleixner.

- Update MAINTAINER file for pwm-fan driver and Samsung thermal driver.
  From: Lukasz Majewski.

- Fix module auto-load for max77620, tango and db8500 thermal driver.
  From: Javier Martinez Canillas.

- Fix a bug that thermal hwmon sysfs I/F returns wrong critical trip
  point temperature value. From: Krzysztof Kozlowski.

- Add Skylake PCH 100 series support for intel_pch_thermal driver.
  From: OGAWA Hirofumi.

- Small fixes and cleanups for platform thermal drivers.
  From Julia Lawall, Luis Henriques, Leo Yan, Stephen Boyd,
  Shawn Lin, Javi Merino and Lukasz Luba.

thanks,
rui


Eduardo Valentin (49):
  thermal: core: prevent zones with no types to be registered
  thermal: core: group thermal_zone DEVICE_ATTR's declarations
  thermal: core: group device_create_file() calls that are always
created
  thermal: core: use dev.groups to manage always present tz
attributes
  thermal: core: move emul_temp creation to tz->device.groups
  thermal: core: move mode attribute to tz->device.groups
  thermal: core: move passive attr to tz->device.groups
  thermal: core: improve power actor documentation
  thermal: core: move power actor code out of sysfs I/F section
  thermal: core: remove useless empty line
  thermal: core: fix style on remove_trip_attrs()
  thermal: core: move the trip attrs to the tz sysfs I/F section
  thermal: core: create tz->device.groups dynamically
  thermal: core: move trips attributes to tz->device.groups
  thermal: core: remove unnecessary device_remove() calls
  thermal: core: split passive_store
  thermal: core: split policy_store
  thermal: core: split available_policies_show()
  thermal: core: move to_thermal_zone() macro to header file
  thermal: core: treat correctly the return value of *scanf calls
  thermal: core: match parenthesis on code alignment
  thermal: core: move thermal_zone sysfs to thermal_sysfs.c
  thermal: core: move to_cooling_device macro to header file
  thermal: core: move cooling device sysfs to thermal_sysfs.c
  thermal: core: remove a couple of style issues on helpers
  thermal: core: introduce thermal_helpers.c
  thermal: core: group functions related to governor handling
  thermal: core: move idr handling to device management section
  thermal: core: small style fix on __unbind() helper
  thermal: core: move __unbind() helper to where it is used
  thermal: core: move bind_cdev() to where it is used
  thermal: core: move bind_tz() to where it is used
  thermal: core: fix couple of style issues on __bind() helper
  thermal: core: move __bind() to where it is used
  thermal: core: add inline to print_bind_err_msg()
  thermal: core: move notify to the zone update section
  thermal: core: add a comment describing the main update loop
  thermal: core: add a comment describing the power actor section
  thermal: core: add a comment describing the device management
section
  thermal: sysfs: remove symbols of emul_temp when config is
disabled
  thermal: core: remove FSF address in the GPL notice
  thermal: core: small style fix when checking for
__find_governor()
  thermal: core: standardize line breaking alignment
  thermal: core: remove void function return statements
  thermal: core: remove style warnings and checks
  thermal: core: improve kerneldoc entry of
thermal_cooling_device_unregister
  thermal: core: use kzalloc(sizeof(*ptr),...)
  thermal: sysfs: use kcalloc() instead of kzalloc()
  thermal: core: move slop and offset helpers to thermal_helpers.c

Javi Merino (1):
  devfreq_cooling: pass a pointer to devfreq in the power model
callbacks

Javier Martinez Canillas (3):
  thermal: max77620: Fix module autoload
  thermal: tango: Fix module autoload
  thermal: db8500: Fix module autoload

Julia Lawall (2):
  thermal: hwmon: use permission-specific DEVICE_ATTR variants
  thermal: int340x_thermal: use permission-specific DEVICE_ATTR
variants

Krzysztof Kozlowski (1):
  thermal: hwmon: Properly report critical temperature in sysfs

[PATCH RFC] [media] m5mols: add missing dependency on VIDEO_IR_I2C

[Nicholas Mc Guire]

The Depends on: tag in Kconfig for CONFIG_VIDEO_M5MOLS does not list
VIDEO_IR_I2C so Kconfig displays the dependencies needed so the M-5MOLS
driver can not be found. 

Fixes: commit cb7a01ac324b ("[media] move i2c files into drivers/media/i2c")
Signed-off-by: Nicholas Mc Guire <hof...@osadl.org>
---

searching for VIDEO_M5MOLS in menuconfig currently shows the following 
dependencies
 Depends on: MEDIA_SUPPORT [=m] && I2C [=y] && VIDEO_V4L2 [=m] && \
 VIDEO_V4L2_SUBDEV_API [=y] && MEDIA_CAMERA_SUPPORT [=y]  
but as the default settings include MEDIA_SUBDRV_AUTOSELECT=y the
"I2C module for IR" submenu (CONFIG_VIDEO_IR_I2C) is not displayed
adding the VIDEO_IR_I2C to the dependency list makes this clear

Q: should a patch like this carry a Fixes: tag ? 

Patch was tested against: x86_64_defconfig

Patch is against 4.9.0 (localversion-next is next-20161212)

 drivers/media/i2c/m5mols/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/i2c/m5mols/Kconfig b/drivers/media/i2c/m5mols/Kconfig
index dc8c250..6847a1b 100644
--- a/drivers/media/i2c/m5mols/Kconfig
+++ b/drivers/media/i2c/m5mols/Kconfig
@@ -1,6 +1,6 @@
 config VIDEO_M5MOLS
tristate "Fujitsu M-5MOLS 8MP sensor support"
-   depends on I2C && VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API
+   depends on I2C && VIDEO_IR_I2C && VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API
depends on MEDIA_CAMERA_SUPPORT
---help---
  This driver supports Fujitsu M-5MOLS camera sensor with ISP
-- 
2.1.4

[PATCH RFC] [media] m5mols: add missing dependency on VIDEO_IR_I2C

[Nicholas Mc Guire]

The Depends on: tag in Kconfig for CONFIG_VIDEO_M5MOLS does not list
VIDEO_IR_I2C so Kconfig displays the dependencies needed so the M-5MOLS
driver can not be found. 

Fixes: commit cb7a01ac324b ("[media] move i2c files into drivers/media/i2c")
Signed-off-by: Nicholas Mc Guire 
---

searching for VIDEO_M5MOLS in menuconfig currently shows the following 
dependencies
 Depends on: MEDIA_SUPPORT [=m] && I2C [=y] && VIDEO_V4L2 [=m] && \
 VIDEO_V4L2_SUBDEV_API [=y] && MEDIA_CAMERA_SUPPORT [=y]  
but as the default settings include MEDIA_SUBDRV_AUTOSELECT=y the
"I2C module for IR" submenu (CONFIG_VIDEO_IR_I2C) is not displayed
adding the VIDEO_IR_I2C to the dependency list makes this clear

Q: should a patch like this carry a Fixes: tag ? 

Patch was tested against: x86_64_defconfig

Patch is against 4.9.0 (localversion-next is next-20161212)

 drivers/media/i2c/m5mols/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/i2c/m5mols/Kconfig b/drivers/media/i2c/m5mols/Kconfig
index dc8c250..6847a1b 100644
--- a/drivers/media/i2c/m5mols/Kconfig
+++ b/drivers/media/i2c/m5mols/Kconfig
@@ -1,6 +1,6 @@
 config VIDEO_M5MOLS
tristate "Fujitsu M-5MOLS 8MP sensor support"
-   depends on I2C && VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API
+   depends on I2C && VIDEO_IR_I2C && VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API
depends on MEDIA_CAMERA_SUPPORT
---help---
  This driver supports Fujitsu M-5MOLS camera sensor with ISP
-- 
2.1.4

DO YOU NEED A LOAN??

[bancoleite]

Are you in need of a loan? Apply for more details.

DO YOU NEED A LOAN??

[bancoleite]

Are you in need of a loan? Apply for more details.

[PATCH] [media] m5mols: set usleep_range delta greater 0

[Nicholas Mc Guire]

This delay is in non-atomic context and it does not seem to be
time-critical so relax it to allow the timer subsystem to optimize
hrtimers. 

Signed-off-by: Nicholas Mc Guire <hof...@osadl.org>
---
problem was located by coccinelle spatch

The problem is that usleep_range is calculating the delay by
 exp = ktime_add_us(ktime_get(), min)
 delta = (u64)(max - min) * NSEC_PER_USEC
so delta is set to 0
and then calls
  schedule_hrtimeout_range(exp, 0,...)
effectively this means that the clock subsystem has no room to
optimize which makes little sense as this is not atomic context
anyway so there is not guarantee of precision here.

As this is not a critical delay and the jitter of any system is
in the 10s of microseconds range anyway the range is set to 200
to 300 microseconds - this change cold have a negligible impact
on bandwidth (though I doubt this is relevant or even measurable
here) thus it needs a review by someone that knows the details
of the device and preferably would increase that range.

A comment in the second case was added to clarify the intent of
the delay as time between i2c transfers.

Patch was only compile tested against: x86_64_defconfig + CONFIG_MEDIA_SUPPORT=m
MEDIA_CAMERA_SUPPORT=y, VIDEO_V4L2_SUBDEV_API, MEDIA_DIGITAL_TV-_SUPPORT=y
MEDIA_RC_SUPPORT=y, MEDIA_CONTROLLER=y, VIDEO_V4L2_SUBDEV_API=y
MEDIA_SUBDRV_AUTOSELECT=n, CONFIG_VIDEO_M5MOLS=m

Patch is against 4.9.0 (localversion-next is next-20161212)

 drivers/media/i2c/m5mols/m5mols_core.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/media/i2c/m5mols/m5mols_core.c 
b/drivers/media/i2c/m5mols/m5mols_core.c
index acb804b..23e8616 100644
--- a/drivers/media/i2c/m5mols/m5mols_core.c
+++ b/drivers/media/i2c/m5mols/m5mols_core.c
@@ -168,7 +168,7 @@ static int m5mols_read(struct v4l2_subdev *sd, u32 size, 
u32 reg, u32 *val)
msg[1].buf = rbuf;
 
/* minimum stabilization time */
-   usleep_range(200, 200);
+   usleep_range(200, 300);
 
ret = i2c_transfer(client->adapter, msg, 2);
 
@@ -268,7 +268,8 @@ int m5mols_write(struct v4l2_subdev *sd, u32 reg, u32 val)
 
*buf = m5mols_swap_byte((u8 *), size);
 
-   usleep_range(200, 200);
+   /* minimum stabilization time */
+   usleep_range(200, 300);
 
ret = i2c_transfer(client->adapter, msg, 1);
if (ret == 1)
-- 
2.1.4

[PATCH] [media] m5mols: set usleep_range delta greater 0

[Nicholas Mc Guire]

This delay is in non-atomic context and it does not seem to be
time-critical so relax it to allow the timer subsystem to optimize
hrtimers. 

Signed-off-by: Nicholas Mc Guire 
---
problem was located by coccinelle spatch

The problem is that usleep_range is calculating the delay by
 exp = ktime_add_us(ktime_get(), min)
 delta = (u64)(max - min) * NSEC_PER_USEC
so delta is set to 0
and then calls
  schedule_hrtimeout_range(exp, 0,...)
effectively this means that the clock subsystem has no room to
optimize which makes little sense as this is not atomic context
anyway so there is not guarantee of precision here.

As this is not a critical delay and the jitter of any system is
in the 10s of microseconds range anyway the range is set to 200
to 300 microseconds - this change cold have a negligible impact
on bandwidth (though I doubt this is relevant or even measurable
here) thus it needs a review by someone that knows the details
of the device and preferably would increase that range.

A comment in the second case was added to clarify the intent of
the delay as time between i2c transfers.

Patch was only compile tested against: x86_64_defconfig + CONFIG_MEDIA_SUPPORT=m
MEDIA_CAMERA_SUPPORT=y, VIDEO_V4L2_SUBDEV_API, MEDIA_DIGITAL_TV-_SUPPORT=y
MEDIA_RC_SUPPORT=y, MEDIA_CONTROLLER=y, VIDEO_V4L2_SUBDEV_API=y
MEDIA_SUBDRV_AUTOSELECT=n, CONFIG_VIDEO_M5MOLS=m

Patch is against 4.9.0 (localversion-next is next-20161212)

 drivers/media/i2c/m5mols/m5mols_core.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/media/i2c/m5mols/m5mols_core.c 
b/drivers/media/i2c/m5mols/m5mols_core.c
index acb804b..23e8616 100644
--- a/drivers/media/i2c/m5mols/m5mols_core.c
+++ b/drivers/media/i2c/m5mols/m5mols_core.c
@@ -168,7 +168,7 @@ static int m5mols_read(struct v4l2_subdev *sd, u32 size, 
u32 reg, u32 *val)
msg[1].buf = rbuf;
 
/* minimum stabilization time */
-   usleep_range(200, 200);
+   usleep_range(200, 300);
 
ret = i2c_transfer(client->adapter, msg, 2);
 
@@ -268,7 +268,8 @@ int m5mols_write(struct v4l2_subdev *sd, u32 reg, u32 val)
 
*buf = m5mols_swap_byte((u8 *), size);
 
-   usleep_range(200, 200);
+   /* minimum stabilization time */
+   usleep_range(200, 300);
 
ret = i2c_transfer(client->adapter, msg, 1);
if (ret == 1)
-- 
2.1.4

Re: [PATCH v2] audit: use proper refcount locking on audit_sock

[Richard Guy Briggs]

On 2016-12-12 15:18, Paul Moore wrote:
> On Mon, Dec 12, 2016 at 5:03 AM, Richard Guy Briggs  wrote:
> > Resetting audit_sock appears to be racy.
> >
> > audit_sock was being copied and dereferenced without using a refcount on
> > the source sock.
> >
> > Bump the refcount on the underlying sock when we store a refrence in
> > audit_sock and release it when we reset audit_sock.  audit_sock
> > modification needs the audit_cmd_mutex.
> >
> > See: https://lkml.org/lkml/2016/11/26/232
> >
> > Thanks to Eric Dumazet  and Cong Wang
> >  on ideas how to fix it.
> >
> > Signed-off-by: Richard Guy Briggs 
> > ---
> > There has been a lot of change in the audit code that is about to go
> > upstream to address audit queue issues.  This patch is based on the
> > source tree: git://git.infradead.org/users/pcmoore/audit#next
> > ---
> >  kernel/audit.c |   34 --
> >  1 files changed, 28 insertions(+), 6 deletions(-)
> > diff --git a/kernel/audit.c b/kernel/audit.c
> > index f20eee0..439f7f3 100644
> > --- a/kernel/audit.c
> > +++ b/kernel/audit.c
> > @@ -452,7 +452,9 @@ static void auditd_reset(void)
> > struct sk_buff *skb;
> >
> > /* break the connection */
> > +   sock_put(audit_sock);
> > audit_pid = 0;
> > +   audit_nlk_portid = 0;
> > audit_sock = NULL;
> >
> > /* flush all of the retry queue to the hold queue */
> > @@ -478,6 +480,12 @@ static int kauditd_send_unicast_skb(struct sk_buff 
> > *skb)
> > if (rc >= 0) {
> > consume_skb(skb);
> > rc = 0;
> > +   } else {
> > +   if (rc & (-ENOMEM|-EPERM|-ECONNREFUSED)) {
> 
> I dislike the way you wrote this because instead of simply looking at
> this to see if it correct I need to sort out all the bits and find out
> if there are other error codes that could run afoul of this check ...
> make it simple, e.g. (rc == -ENOMEM || rc == -EPERM || ...).
> Actually, since EPERM is 1, -EPERM (-1 in two's compliment is
> 0x) is going to cause this to be true for pretty much any
> value of rc, yes?

Yes, you are correct.  We need there a logical or on the results of each
comparison to the return code rather than bit-wise or-ing the result
codes together first to save a step.

> > +   mutex_lock(_cmd_mutex);
> > +   auditd_reset();
> > +   mutex_unlock(_cmd_mutex);
> > +   }
> 
> The code in audit#next handles netlink_unicast() errors in
> kauditd_thread() and you are adding error handling code here in
> kauditd_send_unicast_skb() ... that's messy.  I don't care too much
> where the auditd_reset() call is made, but let's only do it in one
> function; FWIW, I originally put the error handling code in
> kauditd_thread() because there was other error handling code that
> needed to done in that scope so it resulted in cleaner code.

Hmmm, I seem to remember it not returning the return code and I thought
I had changed it to do so, but I see now that it was already there.
Agreed, I needlessly duplicated that error handling.

> Related, I see you are now considering ENOMEM to be a fatal condition,
> that differs from the AUDITD_BAD macro in kauditd_thread(); this
> difference needs to be reconciled.

Also correct about -EPERM now that I check back to the intent of commit
32a1dbaece7e ("audit: try harder to send to auditd upon netlink
failure")

> Finally, you should update the comment header block for auditd_reset()
> that it needs to be called with the audit_cmd_mutex held.

Yup.

> > @@ -1004,17 +1018,22 @@ static int audit_receive_msg(struct sk_buff *skb, 
> > struct nlmsghdr *nlh)
> > return -EACCES;
> > }
> > if (audit_pid && new_pid &&
> > -   audit_replace(requesting_pid) != -ECONNREFUSED) 
> > {
> > +   (audit_replace(requesting_pid) & 
> > (-ECONNREFUSED|-EPERM|-ENOMEM))) {
> 
> Do we simply want to treat any error here as fatal, and not just
> ECONN/EPERM/ENOMEM?  If not, let's come up with a single macro to
> handle the fatal netlink_unicast() return codes so we have some chance
> to keep things consistent in the future.

I'll work through this before I post another patch...

> paul moore

- RGB

--
Richard Guy Briggs 
Kernel Security Engineering, Base Operating Systems, Red Hat
Remote, Ottawa, Canada
Voice: +1.647.777.2635, Internal: (81) 32635

Re: [PATCH v2] audit: use proper refcount locking on audit_sock

[Richard Guy Briggs]

On 2016-12-12 15:18, Paul Moore wrote:
> On Mon, Dec 12, 2016 at 5:03 AM, Richard Guy Briggs  wrote:
> > Resetting audit_sock appears to be racy.
> >
> > audit_sock was being copied and dereferenced without using a refcount on
> > the source sock.
> >
> > Bump the refcount on the underlying sock when we store a refrence in
> > audit_sock and release it when we reset audit_sock.  audit_sock
> > modification needs the audit_cmd_mutex.
> >
> > See: https://lkml.org/lkml/2016/11/26/232
> >
> > Thanks to Eric Dumazet  and Cong Wang
> >  on ideas how to fix it.
> >
> > Signed-off-by: Richard Guy Briggs 
> > ---
> > There has been a lot of change in the audit code that is about to go
> > upstream to address audit queue issues.  This patch is based on the
> > source tree: git://git.infradead.org/users/pcmoore/audit#next
> > ---
> >  kernel/audit.c |   34 --
> >  1 files changed, 28 insertions(+), 6 deletions(-)
> > diff --git a/kernel/audit.c b/kernel/audit.c
> > index f20eee0..439f7f3 100644
> > --- a/kernel/audit.c
> > +++ b/kernel/audit.c
> > @@ -452,7 +452,9 @@ static void auditd_reset(void)
> > struct sk_buff *skb;
> >
> > /* break the connection */
> > +   sock_put(audit_sock);
> > audit_pid = 0;
> > +   audit_nlk_portid = 0;
> > audit_sock = NULL;
> >
> > /* flush all of the retry queue to the hold queue */
> > @@ -478,6 +480,12 @@ static int kauditd_send_unicast_skb(struct sk_buff 
> > *skb)
> > if (rc >= 0) {
> > consume_skb(skb);
> > rc = 0;
> > +   } else {
> > +   if (rc & (-ENOMEM|-EPERM|-ECONNREFUSED)) {
> 
> I dislike the way you wrote this because instead of simply looking at
> this to see if it correct I need to sort out all the bits and find out
> if there are other error codes that could run afoul of this check ...
> make it simple, e.g. (rc == -ENOMEM || rc == -EPERM || ...).
> Actually, since EPERM is 1, -EPERM (-1 in two's compliment is
> 0x) is going to cause this to be true for pretty much any
> value of rc, yes?

Yes, you are correct.  We need there a logical or on the results of each
comparison to the return code rather than bit-wise or-ing the result
codes together first to save a step.

> > +   mutex_lock(_cmd_mutex);
> > +   auditd_reset();
> > +   mutex_unlock(_cmd_mutex);
> > +   }
> 
> The code in audit#next handles netlink_unicast() errors in
> kauditd_thread() and you are adding error handling code here in
> kauditd_send_unicast_skb() ... that's messy.  I don't care too much
> where the auditd_reset() call is made, but let's only do it in one
> function; FWIW, I originally put the error handling code in
> kauditd_thread() because there was other error handling code that
> needed to done in that scope so it resulted in cleaner code.

Hmmm, I seem to remember it not returning the return code and I thought
I had changed it to do so, but I see now that it was already there.
Agreed, I needlessly duplicated that error handling.

> Related, I see you are now considering ENOMEM to be a fatal condition,
> that differs from the AUDITD_BAD macro in kauditd_thread(); this
> difference needs to be reconciled.

Also correct about -EPERM now that I check back to the intent of commit
32a1dbaece7e ("audit: try harder to send to auditd upon netlink
failure")

> Finally, you should update the comment header block for auditd_reset()
> that it needs to be called with the audit_cmd_mutex held.

Yup.

> > @@ -1004,17 +1018,22 @@ static int audit_receive_msg(struct sk_buff *skb, 
> > struct nlmsghdr *nlh)
> > return -EACCES;
> > }
> > if (audit_pid && new_pid &&
> > -   audit_replace(requesting_pid) != -ECONNREFUSED) 
> > {
> > +   (audit_replace(requesting_pid) & 
> > (-ECONNREFUSED|-EPERM|-ENOMEM))) {
> 
> Do we simply want to treat any error here as fatal, and not just
> ECONN/EPERM/ENOMEM?  If not, let's come up with a single macro to
> handle the fatal netlink_unicast() return codes so we have some chance
> to keep things consistent in the future.

I'll work through this before I post another patch...

> paul moore

- RGB

--
Richard Guy Briggs 
Kernel Security Engineering, Base Operating Systems, Red Hat
Remote, Ottawa, Canada
Voice: +1.647.777.2635, Internal: (81) 32635

Re: [PATCH v3 6/6] mfd: dt: Move syscon bindings to syscon subdirectory

[Andrew Jeffery]

On Mon, 2016-12-12 at 09:39 -0600, Rob Herring wrote:
> On Tue, Dec 06, 2016 at 01:53:21PM +1100, Andrew Jeffery wrote:
> > The use of syscons is growing, lets collate them in their own part of
> > the bindings tree.
> > 
> > > > Signed-off-by: Andrew Jeffery 
> > ---
> >  Documentation/devicetree/bindings/mfd/{ => syscon}/aspeed-scu.txt 
> > | 0
> >  Documentation/devicetree/bindings/mfd/{ => syscon}/atmel-gpbr.txt 
> > | 0
> >  Documentation/devicetree/bindings/mfd/{ => syscon}/atmel-matrix.txt   
> > | 0
> >  Documentation/devicetree/bindings/mfd/{ => syscon}/atmel-smc.txt  
> > | 0
> >  Documentation/devicetree/bindings/mfd/{ => syscon}/qcom,tcsr.txt  
> > | 0
> >  Documentation/devicetree/bindings/mfd/{ => syscon}/syscon.txt 
> > | 0
> >  .../devicetree/bindings/mfd/{ => syscon}/ti-keystone-devctrl.txt  
> > | 0
> >  7 files changed, 0 insertions(+), 0 deletions(-)
> >  rename Documentation/devicetree/bindings/mfd/{ => syscon}/aspeed-scu.txt 
> > (100%)
> >  rename Documentation/devicetree/bindings/mfd/{ => syscon}/atmel-gpbr.txt 
> > (100%)
> >  rename Documentation/devicetree/bindings/mfd/{ => syscon}/atmel-matrix.txt 
> > (100%)
> >  rename Documentation/devicetree/bindings/mfd/{ => syscon}/atmel-smc.txt 
> > (100%)
> >  rename Documentation/devicetree/bindings/mfd/{ => syscon}/qcom,tcsr.txt 
> > (100%)
> >  rename Documentation/devicetree/bindings/mfd/{ => syscon}/syscon.txt (100%)
> >  rename Documentation/devicetree/bindings/mfd/{ => 
> > syscon}/ti-keystone-devctrl.txt (100%)
> 
> I'm not so sure this is the right direction. syscon usage is pretty much 
> spread throughout the tree.

This patch was created based on my interpretation of Lee's feedback
here:

https://lkml.org/lkml/2016/11/18/650

Lee's next email in the chain poked Arnd for an opinion, but Arnd
didn't reply.

I don't mind. I moved these bindings separately so we could just drop
the patch if there was push-back. If we drop the whole idea I'll need
to apply a small fix to patch 5/6 to avoid creating the syscon
subdirectory.

Andrew

> 
> Rob

signature.asc
Description: This is a digitally signed message part

Re: [PATCH v3 6/6] mfd: dt: Move syscon bindings to syscon subdirectory

[Andrew Jeffery]

On Mon, 2016-12-12 at 09:39 -0600, Rob Herring wrote:
> On Tue, Dec 06, 2016 at 01:53:21PM +1100, Andrew Jeffery wrote:
> > The use of syscons is growing, lets collate them in their own part of
> > the bindings tree.
> > 
> > > > Signed-off-by: Andrew Jeffery 
> > ---
> >  Documentation/devicetree/bindings/mfd/{ => syscon}/aspeed-scu.txt 
> > | 0
> >  Documentation/devicetree/bindings/mfd/{ => syscon}/atmel-gpbr.txt 
> > | 0
> >  Documentation/devicetree/bindings/mfd/{ => syscon}/atmel-matrix.txt   
> > | 0
> >  Documentation/devicetree/bindings/mfd/{ => syscon}/atmel-smc.txt  
> > | 0
> >  Documentation/devicetree/bindings/mfd/{ => syscon}/qcom,tcsr.txt  
> > | 0
> >  Documentation/devicetree/bindings/mfd/{ => syscon}/syscon.txt 
> > | 0
> >  .../devicetree/bindings/mfd/{ => syscon}/ti-keystone-devctrl.txt  
> > | 0
> >  7 files changed, 0 insertions(+), 0 deletions(-)
> >  rename Documentation/devicetree/bindings/mfd/{ => syscon}/aspeed-scu.txt 
> > (100%)
> >  rename Documentation/devicetree/bindings/mfd/{ => syscon}/atmel-gpbr.txt 
> > (100%)
> >  rename Documentation/devicetree/bindings/mfd/{ => syscon}/atmel-matrix.txt 
> > (100%)
> >  rename Documentation/devicetree/bindings/mfd/{ => syscon}/atmel-smc.txt 
> > (100%)
> >  rename Documentation/devicetree/bindings/mfd/{ => syscon}/qcom,tcsr.txt 
> > (100%)
> >  rename Documentation/devicetree/bindings/mfd/{ => syscon}/syscon.txt (100%)
> >  rename Documentation/devicetree/bindings/mfd/{ => 
> > syscon}/ti-keystone-devctrl.txt (100%)
> 
> I'm not so sure this is the right direction. syscon usage is pretty much 
> spread throughout the tree.

This patch was created based on my interpretation of Lee's feedback
here:

https://lkml.org/lkml/2016/11/18/650

Lee's next email in the chain poked Arnd for an opinion, but Arnd
didn't reply.

I don't mind. I moved these bindings separately so we could just drop
the patch if there was push-back. If we drop the whole idea I'll need
to apply a small fix to patch 5/6 to avoid creating the syscon
subdirectory.

Andrew

> 
> Rob

signature.asc
Description: This is a digitally signed message part

Re: [PATCH v2] audit: use proper refcount locking on audit_sock

[Richard Guy Briggs]

On 2016-12-12 12:10, Paul Moore wrote:
> On Mon, Dec 12, 2016 at 5:03 AM, Richard Guy Briggs  wrote:
> > Resetting audit_sock appears to be racy.
> >
> > audit_sock was being copied and dereferenced without using a refcount on
> > the source sock.
> >
> > Bump the refcount on the underlying sock when we store a refrence in
> > audit_sock and release it when we reset audit_sock.  audit_sock
> > modification needs the audit_cmd_mutex.
> >
> > See: https://lkml.org/lkml/2016/11/26/232
> >
> > Thanks to Eric Dumazet  and Cong Wang
> >  on ideas how to fix it.
> >
> > Signed-off-by: Richard Guy Briggs 
> > ---
> > There has been a lot of change in the audit code that is about to go
> > upstream to address audit queue issues.  This patch is based on the
> > source tree: git://git.infradead.org/users/pcmoore/audit#next
> > ---
> >  kernel/audit.c |   34 --
> >  1 files changed, 28 insertions(+), 6 deletions(-)
> 
> This is coming in pretty late for the v4.10 merge window, much later
> than I would usually take things, but this is arguably important, and
> (at first glance) relatively low risk - what testing have you done on
> this?

At this point, compile and boot, and I'm able to compile and run the
supplied test code without any issues.

> > diff --git a/kernel/audit.c b/kernel/audit.c
> > index f20eee0..439f7f3 100644
> > --- a/kernel/audit.c
> > +++ b/kernel/audit.c
> > @@ -452,7 +452,9 @@ static void auditd_reset(void)
> > struct sk_buff *skb;
> >
> > /* break the connection */
> > +   sock_put(audit_sock);
> > audit_pid = 0;
> > +   audit_nlk_portid = 0;
> > audit_sock = NULL;
> >
> > /* flush all of the retry queue to the hold queue */
> > @@ -478,6 +480,12 @@ static int kauditd_send_unicast_skb(struct sk_buff 
> > *skb)
> > if (rc >= 0) {
> > consume_skb(skb);
> > rc = 0;
> > +   } else {
> > +   if (rc & (-ENOMEM|-EPERM|-ECONNREFUSED)) {
> > +   mutex_lock(_cmd_mutex);
> > +   auditd_reset();
> > +   mutex_unlock(_cmd_mutex);
> > +   }
> > }
> >
> > return rc;
> > @@ -579,7 +587,9 @@ static int kauditd_thread(void *dummy)
> >
> > auditd = 0;
> > if (AUDITD_BAD(rc, reschedule)) {
> > +   mutex_lock(_cmd_mutex);
> > auditd_reset();
> > +   mutex_unlock(_cmd_mutex);
> > reschedule = 0;
> > }
> > } else
> > @@ -594,7 +604,9 @@ static int kauditd_thread(void *dummy)
> > auditd = 0;
> > if (AUDITD_BAD(rc, reschedule)) {
> > kauditd_hold_skb(skb);
> > +   mutex_lock(_cmd_mutex);
> > auditd_reset();
> > +   mutex_unlock(_cmd_mutex);
> > reschedule = 0;
> > } else
> > /* temporary problem (we hope), 
> > queue
> > @@ -623,7 +635,9 @@ quick_loop:
> > if (rc) {
> > auditd = 0;
> > if (AUDITD_BAD(rc, reschedule)) {
> > +   
> > mutex_lock(_cmd_mutex);
> > auditd_reset();
> > +   
> > mutex_unlock(_cmd_mutex);
> > reschedule = 0;
> > }
> >
> > @@ -1004,17 +1018,22 @@ static int audit_receive_msg(struct sk_buff *skb, 
> > struct nlmsghdr *nlh)
> > return -EACCES;
> > }
> > if (audit_pid && new_pid &&
> > -   audit_replace(requesting_pid) != -ECONNREFUSED) 
> > {
> > +   (audit_replace(requesting_pid) & 
> > (-ECONNREFUSED|-EPERM|-ENOMEM))) {
> > audit_log_config_change("audit_pid", 
> > new_pid, audit_pid, 0);
> > return -EEXIST;
> > }
> > if (audit_enabled != AUDIT_OFF)
> > audit_log_config_change("audit_pid", 
> > new_pid, audit_pid, 1);
> > -   audit_pid = new_pid;
> > -   audit_nlk_portid = NETLINK_CB(skb).portid;
> > -   audit_sock = skb->sk;
> > -   

Re: [PATCH v2] audit: use proper refcount locking on audit_sock

[Richard Guy Briggs]

On 2016-12-12 12:10, Paul Moore wrote:
> On Mon, Dec 12, 2016 at 5:03 AM, Richard Guy Briggs  wrote:
> > Resetting audit_sock appears to be racy.
> >
> > audit_sock was being copied and dereferenced without using a refcount on
> > the source sock.
> >
> > Bump the refcount on the underlying sock when we store a refrence in
> > audit_sock and release it when we reset audit_sock.  audit_sock
> > modification needs the audit_cmd_mutex.
> >
> > See: https://lkml.org/lkml/2016/11/26/232
> >
> > Thanks to Eric Dumazet  and Cong Wang
> >  on ideas how to fix it.
> >
> > Signed-off-by: Richard Guy Briggs 
> > ---
> > There has been a lot of change in the audit code that is about to go
> > upstream to address audit queue issues.  This patch is based on the
> > source tree: git://git.infradead.org/users/pcmoore/audit#next
> > ---
> >  kernel/audit.c |   34 --
> >  1 files changed, 28 insertions(+), 6 deletions(-)
> 
> This is coming in pretty late for the v4.10 merge window, much later
> than I would usually take things, but this is arguably important, and
> (at first glance) relatively low risk - what testing have you done on
> this?

At this point, compile and boot, and I'm able to compile and run the
supplied test code without any issues.

> > diff --git a/kernel/audit.c b/kernel/audit.c
> > index f20eee0..439f7f3 100644
> > --- a/kernel/audit.c
> > +++ b/kernel/audit.c
> > @@ -452,7 +452,9 @@ static void auditd_reset(void)
> > struct sk_buff *skb;
> >
> > /* break the connection */
> > +   sock_put(audit_sock);
> > audit_pid = 0;
> > +   audit_nlk_portid = 0;
> > audit_sock = NULL;
> >
> > /* flush all of the retry queue to the hold queue */
> > @@ -478,6 +480,12 @@ static int kauditd_send_unicast_skb(struct sk_buff 
> > *skb)
> > if (rc >= 0) {
> > consume_skb(skb);
> > rc = 0;
> > +   } else {
> > +   if (rc & (-ENOMEM|-EPERM|-ECONNREFUSED)) {
> > +   mutex_lock(_cmd_mutex);
> > +   auditd_reset();
> > +   mutex_unlock(_cmd_mutex);
> > +   }
> > }
> >
> > return rc;
> > @@ -579,7 +587,9 @@ static int kauditd_thread(void *dummy)
> >
> > auditd = 0;
> > if (AUDITD_BAD(rc, reschedule)) {
> > +   mutex_lock(_cmd_mutex);
> > auditd_reset();
> > +   mutex_unlock(_cmd_mutex);
> > reschedule = 0;
> > }
> > } else
> > @@ -594,7 +604,9 @@ static int kauditd_thread(void *dummy)
> > auditd = 0;
> > if (AUDITD_BAD(rc, reschedule)) {
> > kauditd_hold_skb(skb);
> > +   mutex_lock(_cmd_mutex);
> > auditd_reset();
> > +   mutex_unlock(_cmd_mutex);
> > reschedule = 0;
> > } else
> > /* temporary problem (we hope), 
> > queue
> > @@ -623,7 +635,9 @@ quick_loop:
> > if (rc) {
> > auditd = 0;
> > if (AUDITD_BAD(rc, reschedule)) {
> > +   
> > mutex_lock(_cmd_mutex);
> > auditd_reset();
> > +   
> > mutex_unlock(_cmd_mutex);
> > reschedule = 0;
> > }
> >
> > @@ -1004,17 +1018,22 @@ static int audit_receive_msg(struct sk_buff *skb, 
> > struct nlmsghdr *nlh)
> > return -EACCES;
> > }
> > if (audit_pid && new_pid &&
> > -   audit_replace(requesting_pid) != -ECONNREFUSED) 
> > {
> > +   (audit_replace(requesting_pid) & 
> > (-ECONNREFUSED|-EPERM|-ENOMEM))) {
> > audit_log_config_change("audit_pid", 
> > new_pid, audit_pid, 0);
> > return -EEXIST;
> > }
> > if (audit_enabled != AUDIT_OFF)
> > audit_log_config_change("audit_pid", 
> > new_pid, audit_pid, 1);
> > -   audit_pid = new_pid;
> > -   audit_nlk_portid = NETLINK_CB(skb).portid;
> > -   audit_sock = skb->sk;
> > -   if (!new_pid)
> > +   if (new_pid) {
> > +   

Re: [PATCH v3 4/6] mfd: dt: Add bindings for the Aspeed LPC Host Controller (LHC)

[Andrew Jeffery]

On Mon, 2016-12-12 at 09:30 -0600, Rob Herring wrote:
> On Tue, Dec 06, 2016 at 01:53:19PM +1100, Andrew Jeffery wrote:
> > The LPC bus pinmux configuration on fifth generation Aspeed SoCs depends
> > on bits in both the System Control Unit and the LPC Host Controller.
> > 
> > The Aspeed LPC Host Controller is described as a child node of the
> > LPC host-range syscon device for arbitration of access by the host
> > controller and pinmux drivers.
> > 
> > > > Signed-off-by: Andrew Jeffery 
> > ---
> >  .../devicetree/bindings/mfd/aspeed-lpc.txt | 22 
> > ++
> >  1 file changed, 22 insertions(+)
> > 
> > diff --git a/Documentation/devicetree/bindings/mfd/aspeed-lpc.txt 
> > b/Documentation/devicetree/bindings/mfd/aspeed-lpc.txt
> > index a97131aba446..9de318ef72da 100644
> > --- a/Documentation/devicetree/bindings/mfd/aspeed-lpc.txt
> > +++ b/Documentation/devicetree/bindings/mfd/aspeed-lpc.txt
> > > > @@ -109,3 +109,25 @@ lpc: lpc@1e789000 {
> > > >     };
> >  };
> >  
> > +Host Node Children
> > +==
> > +
> > +LPC Host Controller
> > +---
> > +
> > +The Aspeed LPC Host Controller configures the Low Pin Count (LPC) bus 
> > behaviour
> > +between the host and the baseboard management controller. The registers 
> > exist
> > +in the "host" portion of the Aspeed LPC controller, which must be the 
> > parent of
> > +the LPC host controller node.
> > +
> > +Required properties:
> > > > +- compatible:  "aspeed,ast2500-lhc";
> > > > +- reg: contains offset/length value of the LHC memory
> > +   region.
> 
> How many regions? Looks like 2.

Yes, two. The first region is registers configuring various LPC host
controller properties. The second region is for configuring the LPC
serial IRQ trigger modes.

Would you like me to say as much in the patch? It's not a completely
clear split of functionality as other serial IRQ properties are also
described in the first region. Maybe describing the datasheet's
register names for the regions (LHCR[0-8] for the first, LHCR[A-B] for
the second) would help?

Cheers,

Andrew

> 
> > +
> > +Example:
> > +
> > > > +lhc: lhc@20 {
> > > > +   compatible = "aspeed,ast2500-lhc";
> > > > +   reg = <0x20 0x24 0x48 0x8>;
> > +};
> > -- 
> > 2.9.3
> > 

signature.asc
Description: This is a digitally signed message part

Re: [PATCH v3 4/6] mfd: dt: Add bindings for the Aspeed LPC Host Controller (LHC)

[Andrew Jeffery]

On Mon, 2016-12-12 at 09:30 -0600, Rob Herring wrote:
> On Tue, Dec 06, 2016 at 01:53:19PM +1100, Andrew Jeffery wrote:
> > The LPC bus pinmux configuration on fifth generation Aspeed SoCs depends
> > on bits in both the System Control Unit and the LPC Host Controller.
> > 
> > The Aspeed LPC Host Controller is described as a child node of the
> > LPC host-range syscon device for arbitration of access by the host
> > controller and pinmux drivers.
> > 
> > > > Signed-off-by: Andrew Jeffery 
> > ---
> >  .../devicetree/bindings/mfd/aspeed-lpc.txt | 22 
> > ++
> >  1 file changed, 22 insertions(+)
> > 
> > diff --git a/Documentation/devicetree/bindings/mfd/aspeed-lpc.txt 
> > b/Documentation/devicetree/bindings/mfd/aspeed-lpc.txt
> > index a97131aba446..9de318ef72da 100644
> > --- a/Documentation/devicetree/bindings/mfd/aspeed-lpc.txt
> > +++ b/Documentation/devicetree/bindings/mfd/aspeed-lpc.txt
> > > > @@ -109,3 +109,25 @@ lpc: lpc@1e789000 {
> > > >     };
> >  };
> >  
> > +Host Node Children
> > +==
> > +
> > +LPC Host Controller
> > +---
> > +
> > +The Aspeed LPC Host Controller configures the Low Pin Count (LPC) bus 
> > behaviour
> > +between the host and the baseboard management controller. The registers 
> > exist
> > +in the "host" portion of the Aspeed LPC controller, which must be the 
> > parent of
> > +the LPC host controller node.
> > +
> > +Required properties:
> > > > +- compatible:  "aspeed,ast2500-lhc";
> > > > +- reg: contains offset/length value of the LHC memory
> > +   region.
> 
> How many regions? Looks like 2.

Yes, two. The first region is registers configuring various LPC host
controller properties. The second region is for configuring the LPC
serial IRQ trigger modes.

Would you like me to say as much in the patch? It's not a completely
clear split of functionality as other serial IRQ properties are also
described in the first region. Maybe describing the datasheet's
register names for the regions (LHCR[0-8] for the first, LHCR[A-B] for
the second) would help?

Cheers,

Andrew

> 
> > +
> > +Example:
> > +
> > > > +lhc: lhc@20 {
> > > > +   compatible = "aspeed,ast2500-lhc";
> > > > +   reg = <0x20 0x24 0x48 0x8>;
> > +};
> > -- 
> > 2.9.3
> > 

signature.asc
Description: This is a digitally signed message part

Re: [PATCH v5 2/2] mmc: sdhci-cadence: add Cadence SD4HC support

[Masahiro Yamada]

Hi Rob.

2016-12-13 2:14 GMT+09:00 Rob Herring :
>> diff --git a/Documentation/devicetree/bindings/mmc/sdhci-cadence.txt 
>> b/Documentation/devicetree/bindings/mmc/sdhci-cadence.txt
>> new file mode 100644
>> index 000..750374f
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/mmc/sdhci-cadence.txt
>> @@ -0,0 +1,30 @@
>> +* Cadence SD/SDIO/eMMC Host Controller
>> +
>> +Required properties:
>> +- compatible: should be "cdns,sd4hc".
>
> Needs SoC specific compatible strings too.


I remember you mentioned the vendor prefix
stands for the SoC vendor, not the IP vendor.
The compatible prefixed with the IP vendor is prepared for a fallback.

I will add "socionext,sd4hc".




>> +- reg: offset and length of the register set for the device.
>> +- interrupts: a single interrupt specifier.
>> +- clocks: phandle to the input clock.
>> +
>> +Optional properties:
>> +For eMMC configuration, supported speed modes are not indicated by the SDHCI
>> +Capabilities Register.  Instead, the following properties should be 
>> specified
>> +if supported.  See mmc.txt for details.
>> +- mmc-ddr-1_8v
>> +- mmc-ddr-1_2v
>> +- mmc-hs200-1_8v
>> +- mmc-hs200-1_2v
>> +- mmc-hs400-1_8v
>> +- mmc-hs400-1_2v
>
> There's now a property to override SDHCI capabilities register. Maybe
> you should use that instead? I'll defer to Ulf.
>

I did not know this new property.

So, now we have two ways to specify MMC speed mode capabilities
by only touching DT.

[1] Add MMC mode flags directly, like I did.
[2] Use "sdhci-caps-mask" and "sdhci-caps"


The problem for [2] is that eMMC capabilities
do not perfectly correspond to the SDHCI capabilities register.


>> +- mmc-hs400-1_8v
>> +- mmc-hs400-1_2v

If the driver sets SDHCI_QUIRK2_CAPS_BIT63_FOR_HS400,
we can use the bit63 of caps for specifying HS400.

But, this is not defined in the SDHCI standard.
#define  SDHCI_SUPPORT_HS400 0x8000 /* Non-standard */



>> +- mmc-ddr-1_8v

For High Speed DDR, perhaps we can imply MMC_CAP_1_8V_DDR
from MMC_CAP_UHS_DDR50  (bit34 of caps)

This is not supported in the current code, but
if this is a good idea, I can send a patch.


>> +- mmc-ddr-1_2v

This does not have the corresponding bit, but
1.2V is not commonly used, so this is not a fatal problem.



What I can do at most now, is to delete the
Optional properties section entirely
so users can choose [1] or [2] as they like.



-- 
Best Regards
Masahiro Yamada

Re: [PATCH v5 2/2] mmc: sdhci-cadence: add Cadence SD4HC support

[Masahiro Yamada]

Hi Rob.

2016-12-13 2:14 GMT+09:00 Rob Herring :
>> diff --git a/Documentation/devicetree/bindings/mmc/sdhci-cadence.txt 
>> b/Documentation/devicetree/bindings/mmc/sdhci-cadence.txt
>> new file mode 100644
>> index 000..750374f
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/mmc/sdhci-cadence.txt
>> @@ -0,0 +1,30 @@
>> +* Cadence SD/SDIO/eMMC Host Controller
>> +
>> +Required properties:
>> +- compatible: should be "cdns,sd4hc".
>
> Needs SoC specific compatible strings too.


I remember you mentioned the vendor prefix
stands for the SoC vendor, not the IP vendor.
The compatible prefixed with the IP vendor is prepared for a fallback.

I will add "socionext,sd4hc".




>> +- reg: offset and length of the register set for the device.
>> +- interrupts: a single interrupt specifier.
>> +- clocks: phandle to the input clock.
>> +
>> +Optional properties:
>> +For eMMC configuration, supported speed modes are not indicated by the SDHCI
>> +Capabilities Register.  Instead, the following properties should be 
>> specified
>> +if supported.  See mmc.txt for details.
>> +- mmc-ddr-1_8v
>> +- mmc-ddr-1_2v
>> +- mmc-hs200-1_8v
>> +- mmc-hs200-1_2v
>> +- mmc-hs400-1_8v
>> +- mmc-hs400-1_2v
>
> There's now a property to override SDHCI capabilities register. Maybe
> you should use that instead? I'll defer to Ulf.
>

I did not know this new property.

So, now we have two ways to specify MMC speed mode capabilities
by only touching DT.

[1] Add MMC mode flags directly, like I did.
[2] Use "sdhci-caps-mask" and "sdhci-caps"


The problem for [2] is that eMMC capabilities
do not perfectly correspond to the SDHCI capabilities register.


>> +- mmc-hs400-1_8v
>> +- mmc-hs400-1_2v

If the driver sets SDHCI_QUIRK2_CAPS_BIT63_FOR_HS400,
we can use the bit63 of caps for specifying HS400.

But, this is not defined in the SDHCI standard.
#define  SDHCI_SUPPORT_HS400 0x8000 /* Non-standard */



>> +- mmc-ddr-1_8v

For High Speed DDR, perhaps we can imply MMC_CAP_1_8V_DDR
from MMC_CAP_UHS_DDR50  (bit34 of caps)

This is not supported in the current code, but
if this is a good idea, I can send a patch.


>> +- mmc-ddr-1_2v

This does not have the corresponding bit, but
1.2V is not commonly used, so this is not a fatal problem.



What I can do at most now, is to delete the
Optional properties section entirely
so users can choose [1] or [2] as they like.



-- 
Best Regards
Masahiro Yamada

Re: [PATCH V2 for-next 00/11] Code improvements & fixes for HNS RoCE driver

[Doug Ledford]

On 11/15/2016 1:10 PM, Salil Mehta wrote:
> This patchset introduces some code improvements and fixes
> for the identified problems in the HNS RoCE driver.
> 
> Lijun Ou (4):
>   IB/hns: Add the interface for querying QP1
>   IB/hns: add self loopback for CM
>   IB/hns: Modify the condition of notifying hardware loopback
>   IB/hns: Fix the bug for qp state in hns_roce_v1_m_qp()
> 
> Salil Mehta (1):
>   IB/hns: Fix for Checkpatch.pl comment style errors
> 
> Shaobo Xu (1):
>   IB/hns: Implement the add_gid/del_gid and optimize the GIDs
> management
> 
> Wei Hu (Xavier) (5):
>   IB/hns: Add code for refreshing CQ CI using TPTR
>   IB/hns: Optimize the logic of allocating memory using APIs
>   IB/hns: Modify the macro for the timeout when cmd process
>   IB/hns: Modify query info named port_num when querying RC QP
>   IB/hns: Change qpn allocation to round-robin mode.
> 
>  drivers/infiniband/hw/hns/hns_roce_alloc.c  |   11 +-
>  drivers/infiniband/hw/hns/hns_roce_cmd.c|8 +-
>  drivers/infiniband/hw/hns/hns_roce_cmd.h|7 +-
>  drivers/infiniband/hw/hns/hns_roce_common.h |2 -
>  drivers/infiniband/hw/hns/hns_roce_cq.c |   17 +-
>  drivers/infiniband/hw/hns/hns_roce_device.h |   45 ++--
>  drivers/infiniband/hw/hns/hns_roce_eq.c |6 +-
>  drivers/infiniband/hw/hns/hns_roce_hem.c|6 +-
>  drivers/infiniband/hw/hns/hns_roce_hw_v1.c  |  267 +--
>  drivers/infiniband/hw/hns/hns_roce_hw_v1.h  |   17 +-
>  drivers/infiniband/hw/hns/hns_roce_main.c   |  311 
> +++
>  drivers/infiniband/hw/hns/hns_roce_mr.c |   21 +-
>  drivers/infiniband/hw/hns/hns_roce_pd.c |5 +-
>  drivers/infiniband/hw/hns/hns_roce_qp.c |2 +-
>  14 files changed, 363 insertions(+), 362 deletions(-)
> 

Series applied, thanks.

-- 
Doug Ledford 
GPG Key ID: 0E572FDD



signature.asc
Description: OpenPGP digital signature

Re: [PATCH V2 for-next 00/11] Code improvements & fixes for HNS RoCE driver

[Doug Ledford]

On 11/15/2016 1:10 PM, Salil Mehta wrote:
> This patchset introduces some code improvements and fixes
> for the identified problems in the HNS RoCE driver.
> 
> Lijun Ou (4):
>   IB/hns: Add the interface for querying QP1
>   IB/hns: add self loopback for CM
>   IB/hns: Modify the condition of notifying hardware loopback
>   IB/hns: Fix the bug for qp state in hns_roce_v1_m_qp()
> 
> Salil Mehta (1):
>   IB/hns: Fix for Checkpatch.pl comment style errors
> 
> Shaobo Xu (1):
>   IB/hns: Implement the add_gid/del_gid and optimize the GIDs
> management
> 
> Wei Hu (Xavier) (5):
>   IB/hns: Add code for refreshing CQ CI using TPTR
>   IB/hns: Optimize the logic of allocating memory using APIs
>   IB/hns: Modify the macro for the timeout when cmd process
>   IB/hns: Modify query info named port_num when querying RC QP
>   IB/hns: Change qpn allocation to round-robin mode.
> 
>  drivers/infiniband/hw/hns/hns_roce_alloc.c  |   11 +-
>  drivers/infiniband/hw/hns/hns_roce_cmd.c|8 +-
>  drivers/infiniband/hw/hns/hns_roce_cmd.h|7 +-
>  drivers/infiniband/hw/hns/hns_roce_common.h |2 -
>  drivers/infiniband/hw/hns/hns_roce_cq.c |   17 +-
>  drivers/infiniband/hw/hns/hns_roce_device.h |   45 ++--
>  drivers/infiniband/hw/hns/hns_roce_eq.c |6 +-
>  drivers/infiniband/hw/hns/hns_roce_hem.c|6 +-
>  drivers/infiniband/hw/hns/hns_roce_hw_v1.c  |  267 +--
>  drivers/infiniband/hw/hns/hns_roce_hw_v1.h  |   17 +-
>  drivers/infiniband/hw/hns/hns_roce_main.c   |  311 
> +++
>  drivers/infiniband/hw/hns/hns_roce_mr.c |   21 +-
>  drivers/infiniband/hw/hns/hns_roce_pd.c |5 +-
>  drivers/infiniband/hw/hns/hns_roce_qp.c |2 +-
>  14 files changed, 363 insertions(+), 362 deletions(-)
> 

Series applied, thanks.

-- 
Doug Ledford 
GPG Key ID: 0E572FDD



signature.asc
Description: OpenPGP digital signature

Re: [GIT pull] x86/cache: Updates for 4.10

[Linus Torvalds]

On Mon, Dec 12, 2016 at 1:53 AM, Thomas Gleixner  wrote:
>
> This update provides the support for Intel Cache Allocation Technology, a
> cache partitioning mechanism.

Ugh, this is some funky stuff. And it's entirely x86-specific, with a
rather odd special filesystem interface.

It looks pretty self-contained (good), but it also looks majorly
strange. I will have to think about this. What are the main/expected
users?

Linus

Re: [GIT pull] x86/cache: Updates for 4.10

[Linus Torvalds]

On Mon, Dec 12, 2016 at 1:53 AM, Thomas Gleixner  wrote:
>
> This update provides the support for Intel Cache Allocation Technology, a
> cache partitioning mechanism.

Ugh, this is some funky stuff. And it's entirely x86-specific, with a
rather odd special filesystem interface.

It looks pretty self-contained (good), but it also looks majorly
strange. I will have to think about this. What are the main/expected
users?

Linus

[PATCH v2] ACPI/NUMA: Do not map pxm to node when NUMA is turned off

[Boris Ostrovsky]

Otherwise we may unexpectedly reference a non-zero node via, for example,
acpi_get_node() while other parts of the kernel assume that only node 0
(which is what NUMA_NO_NODE is supposed to be converted to) is
available.

Signed-off-by: Boris Ostrovsky 
---
V2:
* Drop __initdata from x86's numa_off 
* Make numa_off available to drivers/acpi/numa.c for arm64 and IA64 

 arch/arm64/include/asm/numa.h | 2 ++
 arch/arm64/mm/numa.c  | 2 +-
 arch/ia64/include/asm/numa.h  | 2 ++
 arch/x86/mm/numa.c| 2 +-
 drivers/acpi/numa.c   | 2 +-
 5 files changed, 7 insertions(+), 3 deletions(-)

diff --git a/arch/arm64/include/asm/numa.h b/arch/arm64/include/asm/numa.h
index 600887e..bf466d1 100644
--- a/arch/arm64/include/asm/numa.h
+++ b/arch/arm64/include/asm/numa.h
@@ -15,6 +15,8 @@
 
 extern nodemask_t numa_nodes_parsed __initdata;
 
+extern bool numa_off;
+
 /* Mappings between node number and cpus on that node. */
 extern cpumask_var_t node_to_cpumask_map[MAX_NUMNODES];
 void numa_clear_node(unsigned int cpu);
diff --git a/arch/arm64/mm/numa.c b/arch/arm64/mm/numa.c
index 4b32168..b388a99 100644
--- a/arch/arm64/mm/numa.c
+++ b/arch/arm64/mm/numa.c
@@ -35,7 +35,7 @@
 
 static int numa_distance_cnt;
 static u8 *numa_distance;
-static bool numa_off;
+bool numa_off;
 
 static __init int numa_parse_early_param(char *opt)
 {
diff --git a/arch/ia64/include/asm/numa.h b/arch/ia64/include/asm/numa.h
index 2db0a6c..ebef7f4 100644
--- a/arch/ia64/include/asm/numa.h
+++ b/arch/ia64/include/asm/numa.h
@@ -65,6 +65,8 @@ struct node_cpuid_s {
 
 #define local_nodeid (cpu_to_node_map[smp_processor_id()])
 
+#define numa_off 0
+
 extern void map_cpu_to_node(int cpu, int nid);
 extern void unmap_cpu_from_node(int cpu, int nid);
 extern void numa_clear_node(int cpu);
diff --git a/arch/x86/mm/numa.c b/arch/x86/mm/numa.c
index 3f35b48..12dcad7 100644
--- a/arch/x86/mm/numa.c
+++ b/arch/x86/mm/numa.c
@@ -19,7 +19,7 @@
 
 #include "numa_internal.h"
 
-int __initdata numa_off;
+int numa_off;
 nodemask_t numa_nodes_parsed __initdata;
 
 struct pglist_data *node_data[MAX_NUMNODES] __read_mostly;
diff --git a/drivers/acpi/numa.c b/drivers/acpi/numa.c
index ce3a7a1..edb0c79 100644
--- a/drivers/acpi/numa.c
+++ b/drivers/acpi/numa.c
@@ -70,7 +70,7 @@ int acpi_map_pxm_to_node(int pxm)
 {
int node;
 
-   if (pxm < 0 || pxm >= MAX_PXM_DOMAINS)
+   if (pxm < 0 || pxm >= MAX_PXM_DOMAINS || numa_off)
return NUMA_NO_NODE;
 
node = pxm_to_node_map[pxm];
-- 
1.8.3.1

[PATCH v2] ACPI/NUMA: Do not map pxm to node when NUMA is turned off

[Boris Ostrovsky]

Otherwise we may unexpectedly reference a non-zero node via, for example,
acpi_get_node() while other parts of the kernel assume that only node 0
(which is what NUMA_NO_NODE is supposed to be converted to) is
available.

Signed-off-by: Boris Ostrovsky 
---
V2:
* Drop __initdata from x86's numa_off 
* Make numa_off available to drivers/acpi/numa.c for arm64 and IA64 

 arch/arm64/include/asm/numa.h | 2 ++
 arch/arm64/mm/numa.c  | 2 +-
 arch/ia64/include/asm/numa.h  | 2 ++
 arch/x86/mm/numa.c| 2 +-
 drivers/acpi/numa.c   | 2 +-
 5 files changed, 7 insertions(+), 3 deletions(-)

diff --git a/arch/arm64/include/asm/numa.h b/arch/arm64/include/asm/numa.h
index 600887e..bf466d1 100644
--- a/arch/arm64/include/asm/numa.h
+++ b/arch/arm64/include/asm/numa.h
@@ -15,6 +15,8 @@
 
 extern nodemask_t numa_nodes_parsed __initdata;
 
+extern bool numa_off;
+
 /* Mappings between node number and cpus on that node. */
 extern cpumask_var_t node_to_cpumask_map[MAX_NUMNODES];
 void numa_clear_node(unsigned int cpu);
diff --git a/arch/arm64/mm/numa.c b/arch/arm64/mm/numa.c
index 4b32168..b388a99 100644
--- a/arch/arm64/mm/numa.c
+++ b/arch/arm64/mm/numa.c
@@ -35,7 +35,7 @@
 
 static int numa_distance_cnt;
 static u8 *numa_distance;
-static bool numa_off;
+bool numa_off;
 
 static __init int numa_parse_early_param(char *opt)
 {
diff --git a/arch/ia64/include/asm/numa.h b/arch/ia64/include/asm/numa.h
index 2db0a6c..ebef7f4 100644
--- a/arch/ia64/include/asm/numa.h
+++ b/arch/ia64/include/asm/numa.h
@@ -65,6 +65,8 @@ struct node_cpuid_s {
 
 #define local_nodeid (cpu_to_node_map[smp_processor_id()])
 
+#define numa_off 0
+
 extern void map_cpu_to_node(int cpu, int nid);
 extern void unmap_cpu_from_node(int cpu, int nid);
 extern void numa_clear_node(int cpu);
diff --git a/arch/x86/mm/numa.c b/arch/x86/mm/numa.c
index 3f35b48..12dcad7 100644
--- a/arch/x86/mm/numa.c
+++ b/arch/x86/mm/numa.c
@@ -19,7 +19,7 @@
 
 #include "numa_internal.h"
 
-int __initdata numa_off;
+int numa_off;
 nodemask_t numa_nodes_parsed __initdata;
 
 struct pglist_data *node_data[MAX_NUMNODES] __read_mostly;
diff --git a/drivers/acpi/numa.c b/drivers/acpi/numa.c
index ce3a7a1..edb0c79 100644
--- a/drivers/acpi/numa.c
+++ b/drivers/acpi/numa.c
@@ -70,7 +70,7 @@ int acpi_map_pxm_to_node(int pxm)
 {
int node;
 
-   if (pxm < 0 || pxm >= MAX_PXM_DOMAINS)
+   if (pxm < 0 || pxm >= MAX_PXM_DOMAINS || numa_off)
return NUMA_NO_NODE;
 
node = pxm_to_node_map[pxm];
-- 
1.8.3.1

RE: [PATCH v2 9/9] NTB: Add ntb.h comments

[Allen Hubbe]

From: Serge Semin
> 
> Signed-off-by: Serge Semin 
> 
> ---
>  include/linux/ntb.h | 17 +++--
>  1 file changed, 11 insertions(+), 6 deletions(-)
> 
> diff --git a/include/linux/ntb.h b/include/linux/ntb.h
> index fe0437c..c5a369c 100644
> --- a/include/linux/ntb.h
> +++ b/include/linux/ntb.h
> @@ -312,13 +312,18 @@ static inline int ntb_dev_ops_is_valid(const struct 
> ntb_dev_ops
> *ops)
>  {
>   /* commented callbacks are not required: */
>   return
> + /* Port operations are required */

Maybe: are required for multiport devices.

>   ops->port_number&&
>   ops->peer_port_count&&
>   ops->peer_port_number   &&
>   ops->peer_port_idx  &&
> +
> + /* Link operations are requiered */
>   ops->link_is_up &&
>   ops->link_enable&&
>   ops->link_disable   &&

Wasn't the first patch in this series all about making link ops first?

> +
> + /* One or both MW interfaces should be developed */
>   ops->mw_count   &&
>   ops->mw_get_align   &&
>   (ops->mw_set_trans  ||
> @@ -328,12 +333,11 @@ static inline int ntb_dev_ops_is_valid(const struct 
> ntb_dev_ops
> *ops)
>   ops->peer_mw_get_addr   &&
>   /* ops->peer_mw_clear_trans && */
> 
> + /* Doorbell operations are mostly required */
>   /* ops->db_is_unsafe&& */
>   ops->db_valid_mask  &&
> -
>   /* both set, or both unset */
>   (!ops->db_vector_count == !ops->db_vector_mask) &&
> -
>   ops->db_read&&
>   /* ops->db_set  && */
>   ops->db_clear   &&
> @@ -347,6 +351,8 @@ static inline int ntb_dev_ops_is_valid(const struct 
> ntb_dev_ops *ops)
>   /* ops->peer_db_read_mask   && */
>   /* ops->peer_db_set_mask&& */
>   /* ops->peer_db_clear_mask  && */
> +
> + /* Scrachpad interface is optional */
>   /* !ops->spad_is_unsafe == !ops->spad_count && */
>   !ops->spad_read == !ops->spad_count &&
>   !ops->spad_write == !ops->spad_count&&
> @@ -354,6 +360,7 @@ static inline int ntb_dev_ops_is_valid(const struct 
> ntb_dev_ops *ops)
>   /* !ops->peer_spad_read == !ops->spad_count && */
>   !ops->peer_spad_write == !ops->spad_count &&
> 
> + /* Message registers interface is optional */
>   !ops->msg_inbits == !ops->msg_count &&
>   !ops->msg_outbits == !ops->msg_count&&
>   !ops->msg_read_sts == !ops->msg_count   &&
> @@ -374,13 +381,12 @@ struct ntb_client {
>   struct device_driverdrv;
>   const struct ntb_client_ops ops;
>  };
> -
>  #define drv_ntb_client(__drv) container_of((__drv), struct ntb_client, drv)
> 
>  /**
>   * struct ntb_device - ntb device
>   * @dev: Linux device object.
> - * @pdev:Pci device entry of the ntb.
> + * @pdev:PCI device entry of the ntb.
>   * @topo:Detected topology of the ntb.
>   * @ops: See _dev_ops.
>   * @ctx: See _ctx_ops.
> @@ -401,7 +407,6 @@ struct ntb_dev {
>   /* block unregister until device is fully released */
>   struct completion   released;
>  };
> -
>  #define dev_ntb(__dev) container_of((__dev), struct ntb_dev, dev)
> 
>  /**
> @@ -498,7 +503,7 @@ void ntb_link_event(struct ntb_dev *ntb);
>   * multiple interrupt vectors for doorbells, the vector number indicates 
> which
>   * vector received the interrupt.  The vector number is relative to the first
>   * vector used for doorbells, starting at zero, and must be less than
> - ** ntb_db_vector_count().  The driver may call ntb_db_read() to check which
> + * ntb_db_vector_count().  The driver may call ntb_db_read() to check which
>   * doorbell bits need service, and ntb_db_vector_mask() to determine which of
>   * those bits are associated with the vector number.
>   */
> --
> 2.6.6

RE: [PATCH v2 9/9] NTB: Add ntb.h comments

[Allen Hubbe]

From: Serge Semin
> 
> Signed-off-by: Serge Semin 
> 
> ---
>  include/linux/ntb.h | 17 +++--
>  1 file changed, 11 insertions(+), 6 deletions(-)
> 
> diff --git a/include/linux/ntb.h b/include/linux/ntb.h
> index fe0437c..c5a369c 100644
> --- a/include/linux/ntb.h
> +++ b/include/linux/ntb.h
> @@ -312,13 +312,18 @@ static inline int ntb_dev_ops_is_valid(const struct 
> ntb_dev_ops
> *ops)
>  {
>   /* commented callbacks are not required: */
>   return
> + /* Port operations are required */

Maybe: are required for multiport devices.

>   ops->port_number&&
>   ops->peer_port_count&&
>   ops->peer_port_number   &&
>   ops->peer_port_idx  &&
> +
> + /* Link operations are requiered */
>   ops->link_is_up &&
>   ops->link_enable&&
>   ops->link_disable   &&

Wasn't the first patch in this series all about making link ops first?

> +
> + /* One or both MW interfaces should be developed */
>   ops->mw_count   &&
>   ops->mw_get_align   &&
>   (ops->mw_set_trans  ||
> @@ -328,12 +333,11 @@ static inline int ntb_dev_ops_is_valid(const struct 
> ntb_dev_ops
> *ops)
>   ops->peer_mw_get_addr   &&
>   /* ops->peer_mw_clear_trans && */
> 
> + /* Doorbell operations are mostly required */
>   /* ops->db_is_unsafe&& */
>   ops->db_valid_mask  &&
> -
>   /* both set, or both unset */
>   (!ops->db_vector_count == !ops->db_vector_mask) &&
> -
>   ops->db_read&&
>   /* ops->db_set  && */
>   ops->db_clear   &&
> @@ -347,6 +351,8 @@ static inline int ntb_dev_ops_is_valid(const struct 
> ntb_dev_ops *ops)
>   /* ops->peer_db_read_mask   && */
>   /* ops->peer_db_set_mask&& */
>   /* ops->peer_db_clear_mask  && */
> +
> + /* Scrachpad interface is optional */
>   /* !ops->spad_is_unsafe == !ops->spad_count && */
>   !ops->spad_read == !ops->spad_count &&
>   !ops->spad_write == !ops->spad_count&&
> @@ -354,6 +360,7 @@ static inline int ntb_dev_ops_is_valid(const struct 
> ntb_dev_ops *ops)
>   /* !ops->peer_spad_read == !ops->spad_count && */
>   !ops->peer_spad_write == !ops->spad_count &&
> 
> + /* Message registers interface is optional */
>   !ops->msg_inbits == !ops->msg_count &&
>   !ops->msg_outbits == !ops->msg_count&&
>   !ops->msg_read_sts == !ops->msg_count   &&
> @@ -374,13 +381,12 @@ struct ntb_client {
>   struct device_driverdrv;
>   const struct ntb_client_ops ops;
>  };
> -
>  #define drv_ntb_client(__drv) container_of((__drv), struct ntb_client, drv)
> 
>  /**
>   * struct ntb_device - ntb device
>   * @dev: Linux device object.
> - * @pdev:Pci device entry of the ntb.
> + * @pdev:PCI device entry of the ntb.
>   * @topo:Detected topology of the ntb.
>   * @ops: See _dev_ops.
>   * @ctx: See _ctx_ops.
> @@ -401,7 +407,6 @@ struct ntb_dev {
>   /* block unregister until device is fully released */
>   struct completion   released;
>  };
> -
>  #define dev_ntb(__dev) container_of((__dev), struct ntb_dev, dev)
> 
>  /**
> @@ -498,7 +503,7 @@ void ntb_link_event(struct ntb_dev *ntb);
>   * multiple interrupt vectors for doorbells, the vector number indicates 
> which
>   * vector received the interrupt.  The vector number is relative to the first
>   * vector used for doorbells, starting at zero, and must be less than
> - ** ntb_db_vector_count().  The driver may call ntb_db_read() to check which
> + * ntb_db_vector_count().  The driver may call ntb_db_read() to check which
>   * doorbell bits need service, and ntb_db_vector_mask() to determine which of
>   * those bits are associated with the vector number.
>   */
> --
> 2.6.6

RE: [PATCH v2 7/9] NTB: Add new Memory Windows API documentation

[Allen Hubbe]

From: Serge Semin
> Since the new API slightly changes the way a typical NTB client driver
> works, the documentation file needs to be appropriately updated.
> 
> Signed-off-by: Serge Semin 

Acked-by: Allen Hubbe 

> 
> ---
>  Documentation/ntb.txt | 99 
> ++-
>  1 file changed, 91 insertions(+), 8 deletions(-)
> 
> diff --git a/Documentation/ntb.txt b/Documentation/ntb.txt
> index 1d9bbab..d01bb69 100644
> --- a/Documentation/ntb.txt
> +++ b/Documentation/ntb.txt
> @@ -1,14 +1,16 @@
>  # NTB Drivers
> 
>  NTB (Non-Transparent Bridge) is a type of PCI-Express bridge chip that 
> connects
> -the separate memory systems of two computers to the same PCI-Express fabric.
> -Existing NTB hardware supports a common feature set, including scratchpad
> -registers, doorbell registers, and memory translation windows.  Scratchpad
> -registers are read-and-writable registers that are accessible from either 
> side
> -of the device, so that peers can exchange a small amount of information at a
> -fixed address.  Doorbell registers provide a way for peers to send interrupt
> -events.  Memory windows allow translated read and write access to the peer
> -memory.
> +the separate memory systems of two or more computers to the same PCI-Express
> +fabric. Existing NTB hardware supports a common feature set: doorbell
> +registers and memory translation windows, as well as non common features like
> +scratchpad and message registers. Scratchpad registers are read-and-writable
> +registers that are accessible from either side of the device, so that peers 
> can
> +exchange a small amount of information at a fixed address. Message registers 
> can
> +be utialized for the same purpose. Additionally they are provided with with
> +special status bits to make sure the information isn't rewritten by another
> +peer. Doorbell registers provide a way for peers to send interrupt events.
> +Memory windows allow translated read and write access to the peer memory.
> 
>  ## NTB Core Driver (ntb)
> 
> @@ -26,6 +28,87 @@ as ntb hardware, or hardware drivers, are inserted and 
> removed.  The
>  registration uses the Linux Device framework, so it should feel familiar to
>  anyone who has written a pci driver.
> 
> +### NTB Typical client driver implementation
> +
> +Primary purpose of NTB is to share some peace of memory between at least two
> +systems. So the NTB device features like Scratchpad/Message regiesters are
> +mainly used to perform the proper memory window initialization. Typically
> +there are two types of memory window interfaces supported by the NTB API:
> +inbound translation configured on the local ntb port and outbound translation
> +configured by the peer, on the peer ntb port. The first type is
> +depicted on the next figure
> +
> +Inbound translation:
> + Memory:  Local NTB Port:  Peer NTB Port:  Peer MMIO:
> +  
> + | dma-mapped |-ntb_mw_set_trans(addr)  |
> + | memory |_v   |   __
> + | (addr) |<==| MW xlat addr |<| MW base addr |<== memory-mapped 
> IO
> + ||   |--|  |  |--|
> +
> +So typical scenario of the first type memory window initialization looks:
> +1) allocate a memory region, 2) put translated address to NTB config,
> +3) somehow notify a peer device of performed initialization, 4) peer device
> +maps corresponding outbound memory window so to have access to the shared
> +memory region.
> +
> +The second type of interface, that implies the shared windows being
> +initialized by a peer device, is depicted on the figure:
> +
> +Outbound translation:
> + Memory:Local NTB Port:Peer NTB Port:  Peer MMIO:
> +    __
> + | dma-mapped ||   | MW base addr |<== memory-mapped IO
> + | memory ||   |--|
> + | (addr) |<===| MW xlat addr 
> |<-ntb_peer_mw_set_trans(addr)
> + |||   |--|
> +
> +Typical scenario of the second type interface initialization would be:
> +1) allocate a memory region, 2) somehow deliver a translated address to a 
> peer
> +device, 3) peer puts the translated address to NTB config, 4) peer device 
> maps
> +outbound memory window so to have access to the shared memory region.
> +
> +As one can see the described scenarios can be combined in one portable
> +algorithm.
> + Local device:
> +  1) Allocate memory for a shared window
> +  2) Initialize memory window by translated address of the allocated region
> + (it may fail if local memory window initialzation is unsupported)
> +  3) Send the translated address and memory window index to a peer device
> + Peer device:
> +  1) Initialize memory window with retrieved address of the allocated
> + by another device memory region (it may fail if peer memory window
> + 

RE: [PATCH v2 8/9] NTB: Add PCIe Gen4 link speed

[Allen Hubbe]

From: Serge Semin
> 
> Signed-off-by: Serge Semin 

Acked-by: Allen Hubbe 

> 
> ---
>  include/linux/ntb.h | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/include/linux/ntb.h b/include/linux/ntb.h
> index 90746df..fe0437c 100644
> --- a/include/linux/ntb.h
> +++ b/include/linux/ntb.h
> @@ -108,6 +108,7 @@ static inline char *ntb_topo_string(enum ntb_topo topo)
>   * @NTB_SPEED_GEN1:  Link is trained to gen1 speed.
>   * @NTB_SPEED_GEN2:  Link is trained to gen2 speed.
>   * @NTB_SPEED_GEN3:  Link is trained to gen3 speed.
> + * @NTB_SPEED_GEN4:  Link is trained to gen4 speed.
>   */
>  enum ntb_speed {
>   NTB_SPEED_AUTO = -1,
> @@ -115,6 +116,7 @@ enum ntb_speed {
>   NTB_SPEED_GEN1 = 1,
>   NTB_SPEED_GEN2 = 2,
>   NTB_SPEED_GEN3 = 3,
> + NTB_SPEED_GEN4 = 4
>  };
> 
>  /**
> --
> 2.6.6

RE: [PATCH v2 7/9] NTB: Add new Memory Windows API documentation

[Allen Hubbe]

From: Serge Semin
> Since the new API slightly changes the way a typical NTB client driver
> works, the documentation file needs to be appropriately updated.
> 
> Signed-off-by: Serge Semin 

Acked-by: Allen Hubbe 

> 
> ---
>  Documentation/ntb.txt | 99 
> ++-
>  1 file changed, 91 insertions(+), 8 deletions(-)
> 
> diff --git a/Documentation/ntb.txt b/Documentation/ntb.txt
> index 1d9bbab..d01bb69 100644
> --- a/Documentation/ntb.txt
> +++ b/Documentation/ntb.txt
> @@ -1,14 +1,16 @@
>  # NTB Drivers
> 
>  NTB (Non-Transparent Bridge) is a type of PCI-Express bridge chip that 
> connects
> -the separate memory systems of two computers to the same PCI-Express fabric.
> -Existing NTB hardware supports a common feature set, including scratchpad
> -registers, doorbell registers, and memory translation windows.  Scratchpad
> -registers are read-and-writable registers that are accessible from either 
> side
> -of the device, so that peers can exchange a small amount of information at a
> -fixed address.  Doorbell registers provide a way for peers to send interrupt
> -events.  Memory windows allow translated read and write access to the peer
> -memory.
> +the separate memory systems of two or more computers to the same PCI-Express
> +fabric. Existing NTB hardware supports a common feature set: doorbell
> +registers and memory translation windows, as well as non common features like
> +scratchpad and message registers. Scratchpad registers are read-and-writable
> +registers that are accessible from either side of the device, so that peers 
> can
> +exchange a small amount of information at a fixed address. Message registers 
> can
> +be utialized for the same purpose. Additionally they are provided with with
> +special status bits to make sure the information isn't rewritten by another
> +peer. Doorbell registers provide a way for peers to send interrupt events.
> +Memory windows allow translated read and write access to the peer memory.
> 
>  ## NTB Core Driver (ntb)
> 
> @@ -26,6 +28,87 @@ as ntb hardware, or hardware drivers, are inserted and 
> removed.  The
>  registration uses the Linux Device framework, so it should feel familiar to
>  anyone who has written a pci driver.
> 
> +### NTB Typical client driver implementation
> +
> +Primary purpose of NTB is to share some peace of memory between at least two
> +systems. So the NTB device features like Scratchpad/Message regiesters are
> +mainly used to perform the proper memory window initialization. Typically
> +there are two types of memory window interfaces supported by the NTB API:
> +inbound translation configured on the local ntb port and outbound translation
> +configured by the peer, on the peer ntb port. The first type is
> +depicted on the next figure
> +
> +Inbound translation:
> + Memory:  Local NTB Port:  Peer NTB Port:  Peer MMIO:
> +  
> + | dma-mapped |-ntb_mw_set_trans(addr)  |
> + | memory |_v   |   __
> + | (addr) |<==| MW xlat addr |<| MW base addr |<== memory-mapped 
> IO
> + ||   |--|  |  |--|
> +
> +So typical scenario of the first type memory window initialization looks:
> +1) allocate a memory region, 2) put translated address to NTB config,
> +3) somehow notify a peer device of performed initialization, 4) peer device
> +maps corresponding outbound memory window so to have access to the shared
> +memory region.
> +
> +The second type of interface, that implies the shared windows being
> +initialized by a peer device, is depicted on the figure:
> +
> +Outbound translation:
> + Memory:Local NTB Port:Peer NTB Port:  Peer MMIO:
> +    __
> + | dma-mapped ||   | MW base addr |<== memory-mapped IO
> + | memory ||   |--|
> + | (addr) |<===| MW xlat addr 
> |<-ntb_peer_mw_set_trans(addr)
> + |||   |--|
> +
> +Typical scenario of the second type interface initialization would be:
> +1) allocate a memory region, 2) somehow deliver a translated address to a 
> peer
> +device, 3) peer puts the translated address to NTB config, 4) peer device 
> maps
> +outbound memory window so to have access to the shared memory region.
> +
> +As one can see the described scenarios can be combined in one portable
> +algorithm.
> + Local device:
> +  1) Allocate memory for a shared window
> +  2) Initialize memory window by translated address of the allocated region
> + (it may fail if local memory window initialzation is unsupported)
> +  3) Send the translated address and memory window index to a peer device
> + Peer device:
> +  1) Initialize memory window with retrieved address of the allocated
> + by another device memory region (it may fail if peer memory window
> + initialization is unsupported)
> +  2) Map 

RE: [PATCH v2 8/9] NTB: Add PCIe Gen4 link speed

[Allen Hubbe]

From: Serge Semin
> 
> Signed-off-by: Serge Semin 

Acked-by: Allen Hubbe 

> 
> ---
>  include/linux/ntb.h | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/include/linux/ntb.h b/include/linux/ntb.h
> index 90746df..fe0437c 100644
> --- a/include/linux/ntb.h
> +++ b/include/linux/ntb.h
> @@ -108,6 +108,7 @@ static inline char *ntb_topo_string(enum ntb_topo topo)
>   * @NTB_SPEED_GEN1:  Link is trained to gen1 speed.
>   * @NTB_SPEED_GEN2:  Link is trained to gen2 speed.
>   * @NTB_SPEED_GEN3:  Link is trained to gen3 speed.
> + * @NTB_SPEED_GEN4:  Link is trained to gen4 speed.
>   */
>  enum ntb_speed {
>   NTB_SPEED_AUTO = -1,
> @@ -115,6 +116,7 @@ enum ntb_speed {
>   NTB_SPEED_GEN1 = 1,
>   NTB_SPEED_GEN2 = 2,
>   NTB_SPEED_GEN3 = 3,
> + NTB_SPEED_GEN4 = 4
>  };
> 
>  /**
> --
> 2.6.6

RE: [PATCH v2 6/9] NTB: Add Messaging NTB API

[Allen Hubbe]

From: Serge Semin
> Some IDT NTB-capable PCIe-switches have message registers to communicate with
> peer devices. This patch adds new NTB API callback methods, which can be used
> to utilize these registers functionality:
>  ntb_msg_count(); - get number of message registers
>  ntb_msg_inbits(); - get bitfield of inbound message registers status
>  ntb_msg_outbits(); - get bitfield of outbound message registers status
>  ntb_msg_read_sts(); - read the inbound and outbound message registers status
>  ntb_msg_clear_sts(); - clear status bits of message registers
>  ntb_msg_set_mask(); - mask interrupts raised by status bits of message
> registers.
>  ntb_msg_clear_mask(); - clear interrupts mask bits of message registers
>  ntb_msg_read(midx, *pidx); - read message register with specified index,
> additionally getting peer port index which data received from
>  ntb_msg_write(midx, pidx); - write data to the specified message register
> sending it to the passed peer device connected over a pidx port
>  ntb_msg_event(); - notify driver context of a new message event
> 
> Of course there is hadrware which doesn't support Message registers, so

s/hadrware/hardware/

> this API is made optional.
> 
> Signed-off-by: Serge Semin 

Acked-by: Allen Hubbe 

> 
> ---
>  drivers/ntb/ntb.c   |  13 
>  include/linux/ntb.h | 205 
> 
>  2 files changed, 218 insertions(+)
> 
> diff --git a/drivers/ntb/ntb.c b/drivers/ntb/ntb.c
> index f6153af..06574f8 100644
> --- a/drivers/ntb/ntb.c
> +++ b/drivers/ntb/ntb.c
> @@ -193,6 +193,19 @@ void ntb_db_event(struct ntb_dev *ntb, int vector)
>  }
>  EXPORT_SYMBOL(ntb_db_event);
> 
> +void ntb_msg_event(struct ntb_dev *ntb)
> +{
> + unsigned long irqflags;
> +
> + spin_lock_irqsave(>ctx_lock, irqflags);
> + {
> + if (ntb->ctx_ops && ntb->ctx_ops->msg_event)
> + ntb->ctx_ops->msg_event(ntb->ctx);
> + }
> + spin_unlock_irqrestore(>ctx_lock, irqflags);
> +}
> +EXPORT_SYMBOL(ntb_msg_event);
> +
>  static int ntb_probe(struct device *dev)
>  {
>   struct ntb_dev *ntb;
> diff --git a/include/linux/ntb.h b/include/linux/ntb.h
> index a6bf15d..90746df 100644
> --- a/include/linux/ntb.h
> +++ b/include/linux/ntb.h
> @@ -164,10 +164,12 @@ static inline int ntb_client_ops_is_valid(const struct
> ntb_client_ops *ops)
>   * struct ntb_ctx_ops - ntb driver context operations
>   * @link_event:  See ntb_link_event().
>   * @db_event:See ntb_db_event().
> + * @msg_event:   See ntb_msg_event().
>   */
>  struct ntb_ctx_ops {
>   void (*link_event)(void *ctx);
>   void (*db_event)(void *ctx, int db_vector);
> + void (*msg_event)(void *ctx);
>  };
> 
>  static inline int ntb_ctx_ops_is_valid(const struct ntb_ctx_ops *ops)
> @@ -176,6 +178,7 @@ static inline int ntb_ctx_ops_is_valid(const struct 
> ntb_ctx_ops *ops)
>   return
>   /* ops->link_event  && */
>   /* ops->db_event&& */
> + /* ops->msg_event   && */
>   1;
>  }
> 
> @@ -220,6 +223,15 @@ static inline int ntb_ctx_ops_is_valid(const struct 
> ntb_ctx_ops *ops)
>   * @peer_spad_addr:  See ntb_peer_spad_addr().
>   * @peer_spad_read:  See ntb_peer_spad_read().
>   * @peer_spad_write: See ntb_peer_spad_write().
> + * @msg_count:   See ntb_msg_count().
> + * @msg_inbits:  See ntb_msg_inbits().
> + * @msg_outbits: See ntb_msg_outbits().
> + * @msg_read_sts:See ntb_msg_read_sts().
> + * @msg_clear_sts:   See ntb_msg_clear_sts().
> + * @msg_set_mask:See ntb_msg_set_mask().
> + * @msg_clear_mask:  See ntb_msg_clear_mask().
> + * @msg_read:See ntb_msg_read().
> + * @msg_write:   See ntb_msg_write().
>   */
>  struct ntb_dev_ops {
>   int (*port_number)(struct ntb_dev *ntb);
> @@ -282,6 +294,16 @@ struct ntb_dev_ops {
>   u32 (*peer_spad_read)(struct ntb_dev *ntb, int pidx, int sidx);
>   int (*peer_spad_write)(struct ntb_dev *ntb, int pidx, int sidx,
>  u32 val);
> +
> + int (*msg_count)(struct ntb_dev *ntb);
> + u64 (*msg_inbits)(struct ntb_dev *ntb);
> + u64 (*msg_outbits)(struct ntb_dev *ntb);
> + u64 (*msg_read_sts)(struct ntb_dev *ntb);
> + int (*msg_clear_sts)(struct ntb_dev *ntb, u64 sts_bits);
> + int (*msg_set_mask)(struct ntb_dev *ntb, u64 mask_bits);
> + int (*msg_clear_mask)(struct ntb_dev *ntb, u64 mask_bits);
> + int (*msg_read)(struct ntb_dev *ntb, int midx, int *pidx, u32 *msg);
> + int (*msg_write)(struct ntb_dev *ntb, int midx, int pidx, u32 msg);
>  };
> 
>  static inline int ntb_dev_ops_is_valid(const struct ntb_dev_ops *ops)
> @@ -329,6 +351,15 @@ static inline int ntb_dev_ops_is_valid(const struct 
> ntb_dev_ops *ops)
>   /* !ops->peer_spad_addr == !ops->spad_count && */
>  

RE: [PATCH v2 6/9] NTB: Add Messaging NTB API

[Allen Hubbe]

From: Serge Semin
> Some IDT NTB-capable PCIe-switches have message registers to communicate with
> peer devices. This patch adds new NTB API callback methods, which can be used
> to utilize these registers functionality:
>  ntb_msg_count(); - get number of message registers
>  ntb_msg_inbits(); - get bitfield of inbound message registers status
>  ntb_msg_outbits(); - get bitfield of outbound message registers status
>  ntb_msg_read_sts(); - read the inbound and outbound message registers status
>  ntb_msg_clear_sts(); - clear status bits of message registers
>  ntb_msg_set_mask(); - mask interrupts raised by status bits of message
> registers.
>  ntb_msg_clear_mask(); - clear interrupts mask bits of message registers
>  ntb_msg_read(midx, *pidx); - read message register with specified index,
> additionally getting peer port index which data received from
>  ntb_msg_write(midx, pidx); - write data to the specified message register
> sending it to the passed peer device connected over a pidx port
>  ntb_msg_event(); - notify driver context of a new message event
> 
> Of course there is hadrware which doesn't support Message registers, so

s/hadrware/hardware/

> this API is made optional.
> 
> Signed-off-by: Serge Semin 

Acked-by: Allen Hubbe 

> 
> ---
>  drivers/ntb/ntb.c   |  13 
>  include/linux/ntb.h | 205 
> 
>  2 files changed, 218 insertions(+)
> 
> diff --git a/drivers/ntb/ntb.c b/drivers/ntb/ntb.c
> index f6153af..06574f8 100644
> --- a/drivers/ntb/ntb.c
> +++ b/drivers/ntb/ntb.c
> @@ -193,6 +193,19 @@ void ntb_db_event(struct ntb_dev *ntb, int vector)
>  }
>  EXPORT_SYMBOL(ntb_db_event);
> 
> +void ntb_msg_event(struct ntb_dev *ntb)
> +{
> + unsigned long irqflags;
> +
> + spin_lock_irqsave(>ctx_lock, irqflags);
> + {
> + if (ntb->ctx_ops && ntb->ctx_ops->msg_event)
> + ntb->ctx_ops->msg_event(ntb->ctx);
> + }
> + spin_unlock_irqrestore(>ctx_lock, irqflags);
> +}
> +EXPORT_SYMBOL(ntb_msg_event);
> +
>  static int ntb_probe(struct device *dev)
>  {
>   struct ntb_dev *ntb;
> diff --git a/include/linux/ntb.h b/include/linux/ntb.h
> index a6bf15d..90746df 100644
> --- a/include/linux/ntb.h
> +++ b/include/linux/ntb.h
> @@ -164,10 +164,12 @@ static inline int ntb_client_ops_is_valid(const struct
> ntb_client_ops *ops)
>   * struct ntb_ctx_ops - ntb driver context operations
>   * @link_event:  See ntb_link_event().
>   * @db_event:See ntb_db_event().
> + * @msg_event:   See ntb_msg_event().
>   */
>  struct ntb_ctx_ops {
>   void (*link_event)(void *ctx);
>   void (*db_event)(void *ctx, int db_vector);
> + void (*msg_event)(void *ctx);
>  };
> 
>  static inline int ntb_ctx_ops_is_valid(const struct ntb_ctx_ops *ops)
> @@ -176,6 +178,7 @@ static inline int ntb_ctx_ops_is_valid(const struct 
> ntb_ctx_ops *ops)
>   return
>   /* ops->link_event  && */
>   /* ops->db_event&& */
> + /* ops->msg_event   && */
>   1;
>  }
> 
> @@ -220,6 +223,15 @@ static inline int ntb_ctx_ops_is_valid(const struct 
> ntb_ctx_ops *ops)
>   * @peer_spad_addr:  See ntb_peer_spad_addr().
>   * @peer_spad_read:  See ntb_peer_spad_read().
>   * @peer_spad_write: See ntb_peer_spad_write().
> + * @msg_count:   See ntb_msg_count().
> + * @msg_inbits:  See ntb_msg_inbits().
> + * @msg_outbits: See ntb_msg_outbits().
> + * @msg_read_sts:See ntb_msg_read_sts().
> + * @msg_clear_sts:   See ntb_msg_clear_sts().
> + * @msg_set_mask:See ntb_msg_set_mask().
> + * @msg_clear_mask:  See ntb_msg_clear_mask().
> + * @msg_read:See ntb_msg_read().
> + * @msg_write:   See ntb_msg_write().
>   */
>  struct ntb_dev_ops {
>   int (*port_number)(struct ntb_dev *ntb);
> @@ -282,6 +294,16 @@ struct ntb_dev_ops {
>   u32 (*peer_spad_read)(struct ntb_dev *ntb, int pidx, int sidx);
>   int (*peer_spad_write)(struct ntb_dev *ntb, int pidx, int sidx,
>  u32 val);
> +
> + int (*msg_count)(struct ntb_dev *ntb);
> + u64 (*msg_inbits)(struct ntb_dev *ntb);
> + u64 (*msg_outbits)(struct ntb_dev *ntb);
> + u64 (*msg_read_sts)(struct ntb_dev *ntb);
> + int (*msg_clear_sts)(struct ntb_dev *ntb, u64 sts_bits);
> + int (*msg_set_mask)(struct ntb_dev *ntb, u64 mask_bits);
> + int (*msg_clear_mask)(struct ntb_dev *ntb, u64 mask_bits);
> + int (*msg_read)(struct ntb_dev *ntb, int midx, int *pidx, u32 *msg);
> + int (*msg_write)(struct ntb_dev *ntb, int midx, int pidx, u32 msg);
>  };
> 
>  static inline int ntb_dev_ops_is_valid(const struct ntb_dev_ops *ops)
> @@ -329,6 +351,15 @@ static inline int ntb_dev_ops_is_valid(const struct 
> ntb_dev_ops *ops)
>   /* !ops->peer_spad_addr == !ops->spad_count && */
>   /* !ops->peer_spad_read == !ops->spad_count 

RE: [PATCH v2 5/9] NTB: Alter Scratchpads API to support multi-ports devices

[Allen Hubbe]

From: Serge Semin 
> Even though there is no any real NTB hardware, which would have both more
> than two ports and Scratchpad registers, it is logically correct to have
> Scratchpad API accepting a peer port index as well. Intel/AMD drivers utilize
> Primary and Secondary topology to split Scratchpad between connected root
> devices. Since port-index API introduced, Intel/AMD NTB hadrware drivers can

s/hadrware/hardware/

> use device port to determine which Scratchpad registers actually belong to
> local and peer devices. The same approach can be used if some potential
> hardware in future will be multi-port and have some set of Scratchpads.
> Here are the brief of changes in the API:
>  ntb_spad_count() - return number of Scratchpad per each port
>  ntb_peer_spad_addr(pidx, sidx) - address of Scratchpad register of the
> peer device with pidx-index
>  ntb_peer_spad_read(pidx, sidx) - read specified Scratchpad register of the
> peer with pidx-index
>  ntb_peer_spad_write(pidx, sidx) - write data to Scratchpad register of the
> peer with pidx-index
> 
> Since there is hardware which doesn't support Scratchpad registers, the
> corresponding API methods are now made optional.

The api change looks good.  See the comment to simplify ntb_tool.

> Signed-off-by: Serge Semin 
> 
> ---
>  drivers/ntb/hw/amd/ntb_hw_amd.c | 14 +++
>  drivers/ntb/hw/intel/ntb_hw_intel.c | 14 +++
>  drivers/ntb/ntb_transport.c | 17 -
>  drivers/ntb/test/ntb_perf.c |  6 +--
>  drivers/ntb/test/ntb_pingpong.c |  8 +++-
>  drivers/ntb/test/ntb_tool.c | 45 +-
>  include/linux/ntb.h | 76 
> +++--
>  7 files changed, 115 insertions(+), 65 deletions(-)
> 
> diff --git a/drivers/ntb/hw/amd/ntb_hw_amd.c b/drivers/ntb/hw/amd/ntb_hw_amd.c
> index 74fe9b8..a2596ad 100644
> --- a/drivers/ntb/hw/amd/ntb_hw_amd.c
> +++ b/drivers/ntb/hw/amd/ntb_hw_amd.c
> @@ -476,30 +476,30 @@ static int amd_ntb_spad_write(struct ntb_dev *ntb,
>   return 0;
>  }
> 
> -static u32 amd_ntb_peer_spad_read(struct ntb_dev *ntb, int idx)
> +static u32 amd_ntb_peer_spad_read(struct ntb_dev *ntb, int pidx, int sidx)
>  {
>   struct amd_ntb_dev *ndev = ntb_ndev(ntb);
>   void __iomem *mmio = ndev->self_mmio;
>   u32 offset;
> 
> - if (idx < 0 || idx >= ndev->spad_count)
> + if (sidx < 0 || sidx >= ndev->spad_count)
>   return -EINVAL;
> 
> - offset = ndev->peer_spad + (idx << 2);
> + offset = ndev->peer_spad + (sidx << 2);
>   return readl(mmio + AMD_SPAD_OFFSET + offset);
>  }
> 
> -static int amd_ntb_peer_spad_write(struct ntb_dev *ntb,
> -int idx, u32 val)
> +static int amd_ntb_peer_spad_write(struct ntb_dev *ntb, int pidx,
> +int sidx, u32 val)
>  {
>   struct amd_ntb_dev *ndev = ntb_ndev(ntb);
>   void __iomem *mmio = ndev->self_mmio;
>   u32 offset;
> 
> - if (idx < 0 || idx >= ndev->spad_count)
> + if (sidx < 0 || sidx >= ndev->spad_count)
>   return -EINVAL;
> 
> - offset = ndev->peer_spad + (idx << 2);
> + offset = ndev->peer_spad + (sidx << 2);
>   writel(val, mmio + AMD_SPAD_OFFSET + offset);
> 
>   return 0;
> diff --git a/drivers/ntb/hw/intel/ntb_hw_intel.c 
> b/drivers/ntb/hw/intel/ntb_hw_intel.c
> index 5a57d9e..471b0ba 100644
> --- a/drivers/ntb/hw/intel/ntb_hw_intel.c
> +++ b/drivers/ntb/hw/intel/ntb_hw_intel.c
> @@ -1452,30 +1452,30 @@ static int intel_ntb_spad_write(struct ntb_dev *ntb,
>  ndev->self_reg->spad);
>  }
> 
> -static int intel_ntb_peer_spad_addr(struct ntb_dev *ntb, int idx,
> +static int intel_ntb_peer_spad_addr(struct ntb_dev *ntb, int pidx, int sidx,
>   phys_addr_t *spad_addr)
>  {
>   struct intel_ntb_dev *ndev = ntb_ndev(ntb);
> 
> - return ndev_spad_addr(ndev, idx, spad_addr, ndev->peer_addr,
> + return ndev_spad_addr(ndev, sidx, spad_addr, ndev->peer_addr,
> ndev->peer_reg->spad);
>  }
> 
> -static u32 intel_ntb_peer_spad_read(struct ntb_dev *ntb, int idx)
> +static u32 intel_ntb_peer_spad_read(struct ntb_dev *ntb, int pidx, int sidx)
>  {
>   struct intel_ntb_dev *ndev = ntb_ndev(ntb);
> 
> - return ndev_spad_read(ndev, idx,
> + return ndev_spad_read(ndev, sidx,
> ndev->peer_mmio +
> ndev->peer_reg->spad);
>  }
> 
> -static int intel_ntb_peer_spad_write(struct ntb_dev *ntb,
> -  int idx, u32 val)
> +static int intel_ntb_peer_spad_write(struct ntb_dev *ntb, int pidx,
> +  int sidx, u32 val)
>  {
>   struct intel_ntb_dev *ndev = ntb_ndev(ntb);
> 
> - return ndev_spad_write(ndev, idx, val,
> + return ndev_spad_write(ndev, sidx, val,
>  ndev->peer_mmio +
>

RE: [PATCH v2 5/9] NTB: Alter Scratchpads API to support multi-ports devices

[Allen Hubbe]

From: Serge Semin 
> Even though there is no any real NTB hardware, which would have both more
> than two ports and Scratchpad registers, it is logically correct to have
> Scratchpad API accepting a peer port index as well. Intel/AMD drivers utilize
> Primary and Secondary topology to split Scratchpad between connected root
> devices. Since port-index API introduced, Intel/AMD NTB hadrware drivers can

s/hadrware/hardware/

> use device port to determine which Scratchpad registers actually belong to
> local and peer devices. The same approach can be used if some potential
> hardware in future will be multi-port and have some set of Scratchpads.
> Here are the brief of changes in the API:
>  ntb_spad_count() - return number of Scratchpad per each port
>  ntb_peer_spad_addr(pidx, sidx) - address of Scratchpad register of the
> peer device with pidx-index
>  ntb_peer_spad_read(pidx, sidx) - read specified Scratchpad register of the
> peer with pidx-index
>  ntb_peer_spad_write(pidx, sidx) - write data to Scratchpad register of the
> peer with pidx-index
> 
> Since there is hardware which doesn't support Scratchpad registers, the
> corresponding API methods are now made optional.

The api change looks good.  See the comment to simplify ntb_tool.

> Signed-off-by: Serge Semin 
> 
> ---
>  drivers/ntb/hw/amd/ntb_hw_amd.c | 14 +++
>  drivers/ntb/hw/intel/ntb_hw_intel.c | 14 +++
>  drivers/ntb/ntb_transport.c | 17 -
>  drivers/ntb/test/ntb_perf.c |  6 +--
>  drivers/ntb/test/ntb_pingpong.c |  8 +++-
>  drivers/ntb/test/ntb_tool.c | 45 +-
>  include/linux/ntb.h | 76 
> +++--
>  7 files changed, 115 insertions(+), 65 deletions(-)
> 
> diff --git a/drivers/ntb/hw/amd/ntb_hw_amd.c b/drivers/ntb/hw/amd/ntb_hw_amd.c
> index 74fe9b8..a2596ad 100644
> --- a/drivers/ntb/hw/amd/ntb_hw_amd.c
> +++ b/drivers/ntb/hw/amd/ntb_hw_amd.c
> @@ -476,30 +476,30 @@ static int amd_ntb_spad_write(struct ntb_dev *ntb,
>   return 0;
>  }
> 
> -static u32 amd_ntb_peer_spad_read(struct ntb_dev *ntb, int idx)
> +static u32 amd_ntb_peer_spad_read(struct ntb_dev *ntb, int pidx, int sidx)
>  {
>   struct amd_ntb_dev *ndev = ntb_ndev(ntb);
>   void __iomem *mmio = ndev->self_mmio;
>   u32 offset;
> 
> - if (idx < 0 || idx >= ndev->spad_count)
> + if (sidx < 0 || sidx >= ndev->spad_count)
>   return -EINVAL;
> 
> - offset = ndev->peer_spad + (idx << 2);
> + offset = ndev->peer_spad + (sidx << 2);
>   return readl(mmio + AMD_SPAD_OFFSET + offset);
>  }
> 
> -static int amd_ntb_peer_spad_write(struct ntb_dev *ntb,
> -int idx, u32 val)
> +static int amd_ntb_peer_spad_write(struct ntb_dev *ntb, int pidx,
> +int sidx, u32 val)
>  {
>   struct amd_ntb_dev *ndev = ntb_ndev(ntb);
>   void __iomem *mmio = ndev->self_mmio;
>   u32 offset;
> 
> - if (idx < 0 || idx >= ndev->spad_count)
> + if (sidx < 0 || sidx >= ndev->spad_count)
>   return -EINVAL;
> 
> - offset = ndev->peer_spad + (idx << 2);
> + offset = ndev->peer_spad + (sidx << 2);
>   writel(val, mmio + AMD_SPAD_OFFSET + offset);
> 
>   return 0;
> diff --git a/drivers/ntb/hw/intel/ntb_hw_intel.c 
> b/drivers/ntb/hw/intel/ntb_hw_intel.c
> index 5a57d9e..471b0ba 100644
> --- a/drivers/ntb/hw/intel/ntb_hw_intel.c
> +++ b/drivers/ntb/hw/intel/ntb_hw_intel.c
> @@ -1452,30 +1452,30 @@ static int intel_ntb_spad_write(struct ntb_dev *ntb,
>  ndev->self_reg->spad);
>  }
> 
> -static int intel_ntb_peer_spad_addr(struct ntb_dev *ntb, int idx,
> +static int intel_ntb_peer_spad_addr(struct ntb_dev *ntb, int pidx, int sidx,
>   phys_addr_t *spad_addr)
>  {
>   struct intel_ntb_dev *ndev = ntb_ndev(ntb);
> 
> - return ndev_spad_addr(ndev, idx, spad_addr, ndev->peer_addr,
> + return ndev_spad_addr(ndev, sidx, spad_addr, ndev->peer_addr,
> ndev->peer_reg->spad);
>  }
> 
> -static u32 intel_ntb_peer_spad_read(struct ntb_dev *ntb, int idx)
> +static u32 intel_ntb_peer_spad_read(struct ntb_dev *ntb, int pidx, int sidx)
>  {
>   struct intel_ntb_dev *ndev = ntb_ndev(ntb);
> 
> - return ndev_spad_read(ndev, idx,
> + return ndev_spad_read(ndev, sidx,
> ndev->peer_mmio +
> ndev->peer_reg->spad);
>  }
> 
> -static int intel_ntb_peer_spad_write(struct ntb_dev *ntb,
> -  int idx, u32 val)
> +static int intel_ntb_peer_spad_write(struct ntb_dev *ntb, int pidx,
> +  int sidx, u32 val)
>  {
>   struct intel_ntb_dev *ndev = ntb_ndev(ntb);
> 
> - return ndev_spad_write(ndev, idx, val,
> + return ndev_spad_write(ndev, sidx, val,
>  ndev->peer_mmio +
>