Re: [PATCH] char: tmp: fix potential null pointer dereference

[Gustavo A. R. Silva]

Hi Jarkko,

Please, see my comments below

Quoting Jarkko Sakkinen :


On Tue, May 30, 2017 at 04:51:23PM -0500, Gustavo A. R. Silva wrote:

NULL check at line 147: if (chip) {, implies chip might be NULL.
Function dev_get_drvdata() dereference pointer chip.
Move pointer priv assignment inside the IF block that checks
pointer chip.

Addresses-Coverity-ID: 1397646
Signed-off-by: Gustavo A. R. Silva 


It cannot be.



I got it.


/Jarkko


---
 drivers/char/tpm/tpm_atmel.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/char/tpm/tpm_atmel.c b/drivers/char/tpm/tpm_atmel.c
index 0d322ab..0826efd 100644
--- a/drivers/char/tpm/tpm_atmel.c
+++ b/drivers/char/tpm/tpm_atmel.c
@@ -142,9 +142,10 @@ static struct platform_device *pdev;
 static void atml_plat_remove(void)
 {
struct tpm_chip *chip = dev_get_drvdata(>dev);
-   struct tpm_atmel_priv *priv = dev_get_drvdata(>dev);
+   struct tpm_atmel_priv *priv;

if (chip) {


So, this NULL check could be removed?


+   priv = dev_get_drvdata(>dev);
tpm_chip_unregister(chip);
if (priv->have_region)
atmel_release_region(priv->base, priv->region_size);
--
2.5.0



Thank you
--
Gustavo A. R. Silva

[PATCH 2/2] Support perf script -F brstackoff,dso

[Mark Santaniello]

The idea here is to make AutoFDO easier in cloud environment with ASLR.
It's easiest to show how this is useful by example. I built a small test
akin to "while(1) { do_nothing(); }" where the do_nothing function is
loaded from a dso.  I sampled the execution with perf record -b.

Using the existing "brstack,dso", we get absolute addresses that are
affected by ASLR, and could be different on different hosts. The address
does not uniquely identify a branch/target in the binary:
$ ./perf script -F brstack,dso | sed 's/\/0 /\/0\n/g' \
> | grep burncpu | grep dso.so | head -n 1
0x7f967139b6aa(/tmp/burncpu/dso.so)/0x4006b1(/tmp/burncpu/exe)/P/-/-/0

Using the existing "brstacksym,dso" is a little better, because the
symbol plus offset and dso name *does* uniquely identify a branch/target
in the binary.  Ultimately, however, AutoFDO wants a simple offset into
the binary, so we'd have to undo all the work perf did to symbolize in
the first place:
$ ./perf script -F brstacksym,dso | sed 's/\/0 /\/0\n/g' \
> | grep burncpu | grep dso.so | head -n 1
do_nothing+0x5(/tmp/burncpu/dso.so)/main+0x44(/tmp/burncpu/exe)/P/-/-/0

With the new "brstackoff,dso" we get what we need: a simple offset into a
specific dso/binary that uniquely identifies a branch/target:
$ ./perf script -F brstackoff,dso | sed 's/\/0 /\/0\n/g' \
> | grep burncpu | grep dso.so | head -n 1
0x6aa(/tmp/burncpu/dso.so)/0x4006b1(/tmp/burncpu/exe)/P/-/-/0

Note this patch depends on commit 9d0ec0748cd9.

Signed-off-by: Mark Santaniello 
---
 tools/perf/builtin-script.c | 56 +
 1 file changed, 52 insertions(+), 4 deletions(-)

diff --git a/tools/perf/builtin-script.c b/tools/perf/builtin-script.c
index 6a7033b..1effc64 100644
--- a/tools/perf/builtin-script.c
+++ b/tools/perf/builtin-script.c
@@ -85,6 +85,7 @@ enum perf_output_field {
PERF_OUTPUT_INSN= 1U << 21,
PERF_OUTPUT_INSNLEN = 1U << 22,
PERF_OUTPUT_BRSTACKINSN = 1U << 23,
+   PERF_OUTPUT_BRSTACKOFF  = 1U << 24,
 };
 
 struct output_option {
@@ -115,6 +116,7 @@ struct output_option {
{.str = "insn", .field = PERF_OUTPUT_INSN},
{.str = "insnlen", .field = PERF_OUTPUT_INSNLEN},
{.str = "brstackinsn", .field = PERF_OUTPUT_BRSTACKINSN},
+   {.str = "brstackoff", .field = PERF_OUTPUT_BRSTACKOFF},
 };
 
 /* default set to maintain compatibility with current format */
@@ -299,10 +301,9 @@ static int perf_evsel__check_attr(struct perf_evsel *evsel,
return -EINVAL;
}
if (PRINT_FIELD(DSO) && !PRINT_FIELD(IP) && !PRINT_FIELD(ADDR) &&
-   !PRINT_FIELD(BRSTACK) && !PRINT_FIELD(BRSTACKSYM)) {
-   pr_err("Display of DSO requested but none of sample IP, sample 
address, "
-  "brstack\nor brstacksym are selected. Hence, no 
addresses to "
-  "convert to DSO.\n");
+   !PRINT_FIELD(BRSTACK) && !PRINT_FIELD(BRSTACKSYM) && 
!PRINT_FIELD(BRSTACKOFF)) {
+   pr_err("Display of DSO requested but no address to convert.  
Select\n"
+  "sample IP, sample address, brstack, brstacksym, or 
brstackoff.\n");
return -EINVAL;
}
if (PRINT_FIELD(SRCLINE) && !PRINT_FIELD(IP)) {
@@ -606,6 +607,51 @@ static void print_sample_brstacksym(struct perf_sample 
*sample,
}
 }
 
+static void print_sample_brstackoff(struct perf_sample *sample,
+   struct thread *thread,
+   struct perf_event_attr *attr)
+{
+   struct branch_stack *br = sample->branch_stack;
+   struct addr_location alf, alt;
+   u64 i, from, to;
+
+   if (!(br && br->nr))
+   return;
+
+   for (i = 0; i < br->nr; i++) {
+
+   memset(, 0, sizeof(alf));
+   memset(, 0, sizeof(alt));
+   from = br->entries[i].from;
+   to   = br->entries[i].to;
+
+   thread__find_addr_map(thread, sample->cpumode, MAP__FUNCTION, 
from, );
+   if (alf.map && !alf.map->dso->adjust_symbols)
+   from = map__map_ip(alf.map, from);
+
+   thread__find_addr_map(thread, sample->cpumode, MAP__FUNCTION, 
to, );
+   if (alt.map && !alt.map->dso->adjust_symbols)
+   to = map__map_ip(alt.map, to);
+
+   printf("0x%"PRIx64, from);
+   if (PRINT_FIELD(DSO)) {
+   printf("(");
+   map__fprintf_dsoname(alf.map, stdout);
+   printf(")");
+   }
+   printf("/0x%"PRIx64, to);
+   if (PRINT_FIELD(DSO)) {
+   printf("(");
+   map__fprintf_dsoname(alt.map, stdout);
+   printf(")");
+   }
+   printf("/%c/%c/%c/%d ",
+   mispred_str(br->entries + i),
+   

Re: [PATCH v2 2/2] tcp: md5: extend the tcp_md5sig struct to specify a key address prefix

[Ivan Delalande]

On Sat, Jun 10, 2017 at 06:58:11PM -0400, David Miller wrote:
> From: Ivan Delalande 
> Date: Fri,  9 Jun 2017 19:14:49 -0700
> 
> > Add a flag field and address prefix length at the end of the tcp_md5sig
> > structure so users can configure an address prefix length along with a
> > key. Make sure shorter option values are still accepted in
> > tcp_v4_parse_md5_keys and tcp_v6_parse_md5_keys to maintain backward
> > compatibility.
> > 
> > Signed-off-by: Bob Gilligan 
> > Signed-off-by: Eric Mowat 
> > Signed-off-by: Ivan Delalande 
> 
> As I believe was previously stated, the problem with this approach is
> that if a new tool requests the prefix length and is run on an older
> kernel, the kernel will return success even though the prefix length
> was not taken into account.
> 
> We do not want to get a success back when the operation requested was
> not performed.

Ah yeah that's right, sorry, definitely not great.

So I guess our only other option is to add a new socket option, like
TCP_MD5SIG_EXT which would use the extended version of struct tcp_md5sig
from this patch. Is it justified for this feature, or do you see any
other way to achieve this?

Thanks,
-- 
Ivan Delalande
Arista Networks

Re: [PATCH v2 2/2] tcp: md5: extend the tcp_md5sig struct to specify a key address prefix

[Ivan Delalande]

On Sat, Jun 10, 2017 at 06:58:11PM -0400, David Miller wrote:
> From: Ivan Delalande 
> Date: Fri,  9 Jun 2017 19:14:49 -0700
> 
> > Add a flag field and address prefix length at the end of the tcp_md5sig
> > structure so users can configure an address prefix length along with a
> > key. Make sure shorter option values are still accepted in
> > tcp_v4_parse_md5_keys and tcp_v6_parse_md5_keys to maintain backward
> > compatibility.
> > 
> > Signed-off-by: Bob Gilligan 
> > Signed-off-by: Eric Mowat 
> > Signed-off-by: Ivan Delalande 
> 
> As I believe was previously stated, the problem with this approach is
> that if a new tool requests the prefix length and is run on an older
> kernel, the kernel will return success even though the prefix length
> was not taken into account.
> 
> We do not want to get a success back when the operation requested was
> not performed.

Ah yeah that's right, sorry, definitely not great.

So I guess our only other option is to add a new socket option, like
TCP_MD5SIG_EXT which would use the extended version of struct tcp_md5sig
from this patch. Is it justified for this feature, or do you see any
other way to achieve this?

Thanks,
-- 
Ivan Delalande
Arista Networks

Re: [PATCH v2] arm: eBPF JIT compiler

[David Miller]

From: Alexander Alemayhu 
Date: Tue, 13 Jun 2017 00:45:45 +0200

> On Mon, Jun 12, 2017 at 09:10:07PM +0530, Shubham Bansal wrote:
>> 
>> Nope. It looks like a latest addition to testing. Can you please tell
>> me how to test with it?
>>
> cd tools/testing/selftests/bpf/
> make
> sudo ./test_progs

Also, you might need to do a "make headers_install" at the top level
before doing this.

Re: [PATCH v2] arm: eBPF JIT compiler

[David Miller]

From: Alexander Alemayhu 
Date: Tue, 13 Jun 2017 00:45:45 +0200

> On Mon, Jun 12, 2017 at 09:10:07PM +0530, Shubham Bansal wrote:
>> 
>> Nope. It looks like a latest addition to testing. Can you please tell
>> me how to test with it?
>>
> cd tools/testing/selftests/bpf/
> make
> sudo ./test_progs

Also, you might need to do a "make headers_install" at the top level
before doing this.

Re: [PATCH v2] arm: eBPF JIT compiler

[Alexander Alemayhu]

On Mon, Jun 12, 2017 at 09:10:07PM +0530, Shubham Bansal wrote:
> 
> Nope. It looks like a latest addition to testing. Can you please tell
> me how to test with it?
>
cd tools/testing/selftests/bpf/
make
sudo ./test_progs

-- 
Mit freundlichen Grüßen

Alexander Alemayhu

Re: [PATCH v2] arm: eBPF JIT compiler

[Alexander Alemayhu]

On Mon, Jun 12, 2017 at 09:10:07PM +0530, Shubham Bansal wrote:
> 
> Nope. It looks like a latest addition to testing. Can you please tell
> me how to test with it?
>
cd tools/testing/selftests/bpf/
make
sudo ./test_progs

-- 
Mit freundlichen Grüßen

Alexander Alemayhu

[tip:irq/urgent] genirq: Release resources in __setup_irq() error path

[tip-bot for Heiner Kallweit]

Commit-ID:  fa07ab72cbb0d843429e61bf179308aed6cbe0dd
Gitweb: http://git.kernel.org/tip/fa07ab72cbb0d843429e61bf179308aed6cbe0dd
Author: Heiner Kallweit 
AuthorDate: Sun, 11 Jun 2017 00:38:36 +0200
Committer:  Thomas Gleixner 
CommitDate: Tue, 13 Jun 2017 00:40:39 +0200

genirq: Release resources in __setup_irq() error path

In case __irq_set_trigger() fails the resources requested via
irq_request_resources() are not released.

Add the missing release call into the error handling path.

Fixes: c1bacbae8192 ("genirq: Provide irq_request/release_resources chip 
callbacks")
Signed-off-by: Heiner Kallweit 
Signed-off-by: Thomas Gleixner 
Cc: sta...@vger.kernel.org
Link: http://lkml.kernel.org/r/655538f5-cb20-a892-ff15-fbd2dd1fa...@gmail.com

---
 kernel/irq/manage.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/kernel/irq/manage.c b/kernel/irq/manage.c
index 070be98..425170d 100644
--- a/kernel/irq/manage.c
+++ b/kernel/irq/manage.c
@@ -1312,8 +1312,10 @@ __setup_irq(unsigned int irq, struct irq_desc *desc, 
struct irqaction *new)
ret = __irq_set_trigger(desc,
new->flags & IRQF_TRIGGER_MASK);
 
-   if (ret)
+   if (ret) {
+   irq_release_resources(desc);
goto out_mask;
+   }
}
 
desc->istate &= ~(IRQS_AUTODETECT | IRQS_SPURIOUS_DISABLED | \

[tip:irq/urgent] genirq: Release resources in __setup_irq() error path

[tip-bot for Heiner Kallweit]

Commit-ID:  fa07ab72cbb0d843429e61bf179308aed6cbe0dd
Gitweb: http://git.kernel.org/tip/fa07ab72cbb0d843429e61bf179308aed6cbe0dd
Author: Heiner Kallweit 
AuthorDate: Sun, 11 Jun 2017 00:38:36 +0200
Committer:  Thomas Gleixner 
CommitDate: Tue, 13 Jun 2017 00:40:39 +0200

genirq: Release resources in __setup_irq() error path

In case __irq_set_trigger() fails the resources requested via
irq_request_resources() are not released.

Add the missing release call into the error handling path.

Fixes: c1bacbae8192 ("genirq: Provide irq_request/release_resources chip 
callbacks")
Signed-off-by: Heiner Kallweit 
Signed-off-by: Thomas Gleixner 
Cc: sta...@vger.kernel.org
Link: http://lkml.kernel.org/r/655538f5-cb20-a892-ff15-fbd2dd1fa...@gmail.com

---
 kernel/irq/manage.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/kernel/irq/manage.c b/kernel/irq/manage.c
index 070be98..425170d 100644
--- a/kernel/irq/manage.c
+++ b/kernel/irq/manage.c
@@ -1312,8 +1312,10 @@ __setup_irq(unsigned int irq, struct irq_desc *desc, 
struct irqaction *new)
ret = __irq_set_trigger(desc,
new->flags & IRQF_TRIGGER_MASK);
 
-   if (ret)
+   if (ret) {
+   irq_release_resources(desc);
goto out_mask;
+   }
}
 
desc->istate &= ~(IRQS_AUTODETECT | IRQS_SPURIOUS_DISABLED | \

Re: [PATCH v9 07/10] powerpc/perf: PMU functions for Core IMC and hotplugging

[Thomas Gleixner]

On Wed, 7 Jun 2017, Anju T Sudhakar wrote:
> On Tuesday 06 June 2017 03:39 PM, Thomas Gleixner wrote:
> > On Mon, 5 Jun 2017, Anju T Sudhakar wrote:
> > > +static void cleanup_all_core_imc_memory(struct imc_pmu *pmu_ptr)
> > > +{
> > > + struct imc_mem_info *ptr = pmu_ptr->mem_info;
> > > +
> > > + if (!ptr)
> > > + return;
> > That's pointless.
> 
> No, it is not.  We may end up here from imc_mem_init() when the memory
> allocation for pmu_ptr->mem_info fails. So in that case we can just
> return from here, and kfree wont be called with a NULL pointer.

What's the problem with that. kfree() CAN be called with a NULL pointer. It
has a check already.

Thanks,

tglx

Re: [PATCH v9 07/10] powerpc/perf: PMU functions for Core IMC and hotplugging

[Thomas Gleixner]

On Wed, 7 Jun 2017, Anju T Sudhakar wrote:
> On Tuesday 06 June 2017 03:39 PM, Thomas Gleixner wrote:
> > On Mon, 5 Jun 2017, Anju T Sudhakar wrote:
> > > +static void cleanup_all_core_imc_memory(struct imc_pmu *pmu_ptr)
> > > +{
> > > + struct imc_mem_info *ptr = pmu_ptr->mem_info;
> > > +
> > > + if (!ptr)
> > > + return;
> > That's pointless.
> 
> No, it is not.  We may end up here from imc_mem_init() when the memory
> allocation for pmu_ptr->mem_info fails. So in that case we can just
> return from here, and kfree wont be called with a NULL pointer.

What's the problem with that. kfree() CAN be called with a NULL pointer. It
has a check already.

Thanks,

tglx

Re: [PATCH 3/4] mfd: tps65217: remove duplicated interrupt resources.

[Grygorii Strashko]

On 06/12/2017 04:24 PM, Enric Balletbo i Serra wrote:
> I don't think it makes sense to have the interrupt resources for charger
> and power button in two different places, the driver and the DT binding.
> That's confusing so remove the ones from the mfd driver in favour of
> having the interrupt resources only described in the DT. Having the
> resources in DT may help if there is or will be a similar pmic with
> different resource allocation.

Wouldn't this break DT compatibility? Old DTs do not contain IRQ resources
and so they work only because of IRQ definitions in code.

> 
> Signed-off-by: Enric Balletbo i Serra 
> ---
>   drivers/mfd/tps65217.c | 22 +-
>   1 file changed, 1 insertion(+), 21 deletions(-)
> 
> diff --git a/drivers/mfd/tps65217.c b/drivers/mfd/tps65217.c
> index f769c7d..fd83bae 100644
> --- a/drivers/mfd/tps65217.c
> +++ b/drivers/mfd/tps65217.c
> @@ -33,15 +33,6 @@
>   #include 
>   #include 
>   
> -static struct resource charger_resources[] = {
> - DEFINE_RES_IRQ_NAMED(TPS65217_IRQ_AC, "AC"),
> - DEFINE_RES_IRQ_NAMED(TPS65217_IRQ_USB, "USB"),
> -};
> -
> -static struct resource pb_resources[] = {
> - DEFINE_RES_IRQ_NAMED(TPS65217_IRQ_PB, "PB"),
> -};
> -
>   static void tps65217_irq_lock(struct irq_data *data)
>   {
>   struct tps65217 *tps = irq_data_get_irq_chip_data(data);
> @@ -97,14 +88,10 @@ static struct mfd_cell tps65217s[] = {
>   },
>   {
>   .name = "tps65217-charger",
> - .num_resources = ARRAY_SIZE(charger_resources),
> - .resources = charger_resources,
>   .of_compatible = "ti,tps65217-charger",
>   },
>   {
>   .name = "tps65217-pwrbutton",
> - .num_resources = ARRAY_SIZE(pb_resources),
> - .resources = pb_resources,
>   .of_compatible = "ti,tps65217-pwrbutton",
>   },
>   };
> @@ -359,15 +346,8 @@ static int tps65217_probe(struct i2c_client *client,
>   return ret;
>   }
>   
> - if (client->irq) {
> + if (client->irq)
>   tps65217_irq_init(tps, client->irq);
> - } else {
> - int i;
> -
> - /* Don't tell children about IRQ resources which won't fire */
> - for (i = 0; i < ARRAY_SIZE(tps65217s); i++)
> - tps65217s[i].num_resources = 0;
> - }
>   
>   ret = devm_mfd_add_devices(tps->dev, -1, tps65217s,
>  ARRAY_SIZE(tps65217s), NULL, 0,
> 

-- 
regards,
-grygorii

Re: [PATCH 3/4] mfd: tps65217: remove duplicated interrupt resources.

[Grygorii Strashko]

On 06/12/2017 04:24 PM, Enric Balletbo i Serra wrote:
> I don't think it makes sense to have the interrupt resources for charger
> and power button in two different places, the driver and the DT binding.
> That's confusing so remove the ones from the mfd driver in favour of
> having the interrupt resources only described in the DT. Having the
> resources in DT may help if there is or will be a similar pmic with
> different resource allocation.

Wouldn't this break DT compatibility? Old DTs do not contain IRQ resources
and so they work only because of IRQ definitions in code.

> 
> Signed-off-by: Enric Balletbo i Serra 
> ---
>   drivers/mfd/tps65217.c | 22 +-
>   1 file changed, 1 insertion(+), 21 deletions(-)
> 
> diff --git a/drivers/mfd/tps65217.c b/drivers/mfd/tps65217.c
> index f769c7d..fd83bae 100644
> --- a/drivers/mfd/tps65217.c
> +++ b/drivers/mfd/tps65217.c
> @@ -33,15 +33,6 @@
>   #include 
>   #include 
>   
> -static struct resource charger_resources[] = {
> - DEFINE_RES_IRQ_NAMED(TPS65217_IRQ_AC, "AC"),
> - DEFINE_RES_IRQ_NAMED(TPS65217_IRQ_USB, "USB"),
> -};
> -
> -static struct resource pb_resources[] = {
> - DEFINE_RES_IRQ_NAMED(TPS65217_IRQ_PB, "PB"),
> -};
> -
>   static void tps65217_irq_lock(struct irq_data *data)
>   {
>   struct tps65217 *tps = irq_data_get_irq_chip_data(data);
> @@ -97,14 +88,10 @@ static struct mfd_cell tps65217s[] = {
>   },
>   {
>   .name = "tps65217-charger",
> - .num_resources = ARRAY_SIZE(charger_resources),
> - .resources = charger_resources,
>   .of_compatible = "ti,tps65217-charger",
>   },
>   {
>   .name = "tps65217-pwrbutton",
> - .num_resources = ARRAY_SIZE(pb_resources),
> - .resources = pb_resources,
>   .of_compatible = "ti,tps65217-pwrbutton",
>   },
>   };
> @@ -359,15 +346,8 @@ static int tps65217_probe(struct i2c_client *client,
>   return ret;
>   }
>   
> - if (client->irq) {
> + if (client->irq)
>   tps65217_irq_init(tps, client->irq);
> - } else {
> - int i;
> -
> - /* Don't tell children about IRQ resources which won't fire */
> - for (i = 0; i < ARRAY_SIZE(tps65217s); i++)
> - tps65217s[i].num_resources = 0;
> - }
>   
>   ret = devm_mfd_add_devices(tps->dev, -1, tps65217s,
>  ARRAY_SIZE(tps65217s), NULL, 0,
> 

-- 
regards,
-grygorii

Re: [4.4.70 REGRESSION] Nouveau hangs up at boot

[Ben Skeggs]

On 06/10/2017 06:25 AM, Takashi Iwai wrote:
> Hi,
> 
> we've received a bug report about 4.4.70 kernel showing the hang up at
> boot.  And, this turned out to be a regression in nouveau driver:
>   https://bugzilla.suse.com/show_bug.cgi?id=1043467
> 
> I provided a test kernel reverting the last five commits about
> nouveau below, and it was confirmed to work.  But still not figured
> out which one actually breaks.
> 
> e4add1cf6b4154804350c3385c6d447cff3570de
> drm/nouveau/tmr: handle races with hw when updating the next alarm time
> commit 1b0f84380b10ee97f7d2dd191294de9017e94d1d upstream.
> 
> 9d78e40f5f41ad1db1849f8d15acbda99d0871b4
> drm/nouveau/tmr: avoid processing completed alarms when adding a new one
> commit 330bdf62fe6a6c5b99a647f7bf7157107c9348b3 upstream.
> 
> 5e07724c28f4e06fe42dd5b58bb6f9dd56510567
> drm/nouveau/tmr: fix corruption of the pending list when rescheduling an 
> alarm
> commit 9fc64667ee48c9a25e7dca1a6bcb6906fec5bcc5 upstream.
> 
> 27f82df2f02688c51d2c1d9f624cc0c5b8a62661
> drm/nouveau/tmr: ack interrupt before processing alarms
> commit 3733bd8b407211739e72d051e5f30ad82a52c4bc upstream.
> 
> 3819271d8a5f4c6e0c8f71c339e44e2efbe40710
> drm/nouveau/therm: remove ineffective workarounds for alarm bugs
> commit e4311ee51d1e2676001b2d8fcefd92bdd79aad85 upstream.
> 
> 
> Ben, is this a known problem?  Or is there any fixup?
> The kernel back trace found in the bugzilla report shows the issue in
> nvkm_timer_alarm_trigger(), at least.
> 
A fix (b4e382ca7586a63b6c1e5221ce0863ff867c2df6) has been submitted already.

Sorry for the trouble!
Ben.

> 
> thanks,
> 
> Takashi
> 



signature.asc
Description: OpenPGP digital signature

Re: [4.4.70 REGRESSION] Nouveau hangs up at boot

[Ben Skeggs]

On 06/10/2017 06:25 AM, Takashi Iwai wrote:
> Hi,
> 
> we've received a bug report about 4.4.70 kernel showing the hang up at
> boot.  And, this turned out to be a regression in nouveau driver:
>   https://bugzilla.suse.com/show_bug.cgi?id=1043467
> 
> I provided a test kernel reverting the last five commits about
> nouveau below, and it was confirmed to work.  But still not figured
> out which one actually breaks.
> 
> e4add1cf6b4154804350c3385c6d447cff3570de
> drm/nouveau/tmr: handle races with hw when updating the next alarm time
> commit 1b0f84380b10ee97f7d2dd191294de9017e94d1d upstream.
> 
> 9d78e40f5f41ad1db1849f8d15acbda99d0871b4
> drm/nouveau/tmr: avoid processing completed alarms when adding a new one
> commit 330bdf62fe6a6c5b99a647f7bf7157107c9348b3 upstream.
> 
> 5e07724c28f4e06fe42dd5b58bb6f9dd56510567
> drm/nouveau/tmr: fix corruption of the pending list when rescheduling an 
> alarm
> commit 9fc64667ee48c9a25e7dca1a6bcb6906fec5bcc5 upstream.
> 
> 27f82df2f02688c51d2c1d9f624cc0c5b8a62661
> drm/nouveau/tmr: ack interrupt before processing alarms
> commit 3733bd8b407211739e72d051e5f30ad82a52c4bc upstream.
> 
> 3819271d8a5f4c6e0c8f71c339e44e2efbe40710
> drm/nouveau/therm: remove ineffective workarounds for alarm bugs
> commit e4311ee51d1e2676001b2d8fcefd92bdd79aad85 upstream.
> 
> 
> Ben, is this a known problem?  Or is there any fixup?
> The kernel back trace found in the bugzilla report shows the issue in
> nvkm_timer_alarm_trigger(), at least.
> 
A fix (b4e382ca7586a63b6c1e5221ce0863ff867c2df6) has been submitted already.

Sorry for the trouble!
Ben.

> 
> thanks,
> 
> Takashi
> 



signature.asc
Description: OpenPGP digital signature

[PATCH v2] libnvdimm, pmem: Add sysfs notifications to badblocks

[Toshi Kani]

Sysfs "badblocks" information may be updated during run-time that:
 - MCE, SCI, and sysfs "scrub" may add new bad blocks
 - Writes and ioctl() may clear bad blocks

Add support to send sysfs notifications to sysfs "badblocks" file
under region and pmem directories when their badblocks information
is re-evaluated (but is not necessarily changed) during run-time.

Signed-off-by: Toshi Kani 
Cc: Dan Williams 
Cc: Vishal Verma 
Cc: Linda Knippers 
---
v2: Send notifications for the clearing case
---
 drivers/nvdimm/bus.c|3 +++
 drivers/nvdimm/nd.h |1 +
 drivers/nvdimm/pmem.c   |   14 ++
 drivers/nvdimm/pmem.h   |1 +
 drivers/nvdimm/region.c |   12 ++--
 5 files changed, 29 insertions(+), 2 deletions(-)

diff --git a/drivers/nvdimm/bus.c b/drivers/nvdimm/bus.c
index e9361bf..63ce50d 100644
--- a/drivers/nvdimm/bus.c
+++ b/drivers/nvdimm/bus.c
@@ -198,6 +198,9 @@ static int nvdimm_clear_badblocks_region(struct device 
*dev, void *data)
sector = (ctx->phys - nd_region->ndr_start) / 512;
badblocks_clear(_region->bb, sector, ctx->cleared / 512);
 
+   if (nd_region->bb_state)
+   sysfs_notify_dirent(nd_region->bb_state);
+
return 0;
 }
 
diff --git a/drivers/nvdimm/nd.h b/drivers/nvdimm/nd.h
index 03852d7..4bb57ff 100644
--- a/drivers/nvdimm/nd.h
+++ b/drivers/nvdimm/nd.h
@@ -155,6 +155,7 @@ struct nd_region {
u64 ndr_start;
int id, num_lanes, ro, numa_node;
void *provider_data;
+   struct kernfs_node *bb_state;
struct badblocks bb;
struct nd_interleave_set *nd_set;
struct nd_percpu_lane __percpu *lane;
diff --git a/drivers/nvdimm/pmem.c b/drivers/nvdimm/pmem.c
index c544d46..6c14c72 100644
--- a/drivers/nvdimm/pmem.c
+++ b/drivers/nvdimm/pmem.c
@@ -68,6 +68,8 @@ static int pmem_clear_poison(struct pmem_device *pmem, 
phys_addr_t offset,
(unsigned long long) sector, cleared,
cleared > 1 ? "s" : "");
badblocks_clear(>bb, sector, cleared);
+   if (pmem->bb_state)
+   sysfs_notify_dirent(pmem->bb_state);
}
 
invalidate_pmem(pmem->virt_addr + offset, len);
@@ -377,6 +379,13 @@ static int pmem_attach_disk(struct device *dev,
 
revalidate_disk(disk);
 
+   pmem->bb_state = sysfs_get_dirent(disk_to_dev(disk)->kobj.sd,
+ "badblocks");
+   if (pmem->bb_state)
+   sysfs_put(pmem->bb_state);
+   else
+   dev_warn(dev, "sysfs_get_dirent 'badblocks' failed\n");
+
return 0;
 }
 
@@ -428,6 +437,7 @@ static void nd_pmem_notify(struct device *dev, enum 
nvdimm_event event)
struct nd_namespace_io *nsio;
struct resource res;
struct badblocks *bb;
+   struct kernfs_node *bb_state;
 
if (event != NVDIMM_REVALIDATE_POISON)
return;
@@ -439,11 +449,13 @@ static void nd_pmem_notify(struct device *dev, enum 
nvdimm_event event)
nd_region = to_nd_region(ndns->dev.parent);
nsio = to_nd_namespace_io(>dev);
bb = >bb;
+   bb_state = NULL;
} else {
struct pmem_device *pmem = dev_get_drvdata(dev);
 
nd_region = to_region(pmem);
bb = >bb;
+   bb_state = pmem->bb_state;
 
if (is_nd_pfn(dev)) {
struct nd_pfn *nd_pfn = to_nd_pfn(dev);
@@ -463,6 +475,8 @@ static void nd_pmem_notify(struct device *dev, enum 
nvdimm_event event)
res.start = nsio->res.start + offset;
res.end = nsio->res.end - end_trunc;
nvdimm_badblocks_populate(nd_region, bb, );
+   if (bb_state)
+   sysfs_notify_dirent(bb_state);
 }
 
 MODULE_ALIAS("pmem");
diff --git a/drivers/nvdimm/pmem.h b/drivers/nvdimm/pmem.h
index 7f4dbd7..c5917f0 100644
--- a/drivers/nvdimm/pmem.h
+++ b/drivers/nvdimm/pmem.h
@@ -17,6 +17,7 @@ struct pmem_device {
size_t  size;
/* trim size when namespace capacity has been section aligned */
u32 pfn_pad;
+   struct kernfs_node  *bb_state;
struct badblocksbb;
struct dax_device   *dax_dev;
struct gendisk  *disk;
diff --git a/drivers/nvdimm/region.c b/drivers/nvdimm/region.c
index 869a886..ca94029 100644
--- a/drivers/nvdimm/region.c
+++ b/drivers/nvdimm/region.c
@@ -58,10 +58,16 @@ static int nd_region_probe(struct device *dev)
 
if (devm_init_badblocks(dev, _region->bb))
return -ENODEV;
+   nd_region->bb_state = sysfs_get_dirent(nd_region->dev.kobj.sd,
+  "badblocks");
+   if (nd_region->bb_state)
+   

[PATCH v2] libnvdimm, pmem: Add sysfs notifications to badblocks

[Toshi Kani]

Sysfs "badblocks" information may be updated during run-time that:
 - MCE, SCI, and sysfs "scrub" may add new bad blocks
 - Writes and ioctl() may clear bad blocks

Add support to send sysfs notifications to sysfs "badblocks" file
under region and pmem directories when their badblocks information
is re-evaluated (but is not necessarily changed) during run-time.

Signed-off-by: Toshi Kani 
Cc: Dan Williams 
Cc: Vishal Verma 
Cc: Linda Knippers 
---
v2: Send notifications for the clearing case
---
 drivers/nvdimm/bus.c|3 +++
 drivers/nvdimm/nd.h |1 +
 drivers/nvdimm/pmem.c   |   14 ++
 drivers/nvdimm/pmem.h   |1 +
 drivers/nvdimm/region.c |   12 ++--
 5 files changed, 29 insertions(+), 2 deletions(-)

diff --git a/drivers/nvdimm/bus.c b/drivers/nvdimm/bus.c
index e9361bf..63ce50d 100644
--- a/drivers/nvdimm/bus.c
+++ b/drivers/nvdimm/bus.c
@@ -198,6 +198,9 @@ static int nvdimm_clear_badblocks_region(struct device 
*dev, void *data)
sector = (ctx->phys - nd_region->ndr_start) / 512;
badblocks_clear(_region->bb, sector, ctx->cleared / 512);
 
+   if (nd_region->bb_state)
+   sysfs_notify_dirent(nd_region->bb_state);
+
return 0;
 }
 
diff --git a/drivers/nvdimm/nd.h b/drivers/nvdimm/nd.h
index 03852d7..4bb57ff 100644
--- a/drivers/nvdimm/nd.h
+++ b/drivers/nvdimm/nd.h
@@ -155,6 +155,7 @@ struct nd_region {
u64 ndr_start;
int id, num_lanes, ro, numa_node;
void *provider_data;
+   struct kernfs_node *bb_state;
struct badblocks bb;
struct nd_interleave_set *nd_set;
struct nd_percpu_lane __percpu *lane;
diff --git a/drivers/nvdimm/pmem.c b/drivers/nvdimm/pmem.c
index c544d46..6c14c72 100644
--- a/drivers/nvdimm/pmem.c
+++ b/drivers/nvdimm/pmem.c
@@ -68,6 +68,8 @@ static int pmem_clear_poison(struct pmem_device *pmem, 
phys_addr_t offset,
(unsigned long long) sector, cleared,
cleared > 1 ? "s" : "");
badblocks_clear(>bb, sector, cleared);
+   if (pmem->bb_state)
+   sysfs_notify_dirent(pmem->bb_state);
}
 
invalidate_pmem(pmem->virt_addr + offset, len);
@@ -377,6 +379,13 @@ static int pmem_attach_disk(struct device *dev,
 
revalidate_disk(disk);
 
+   pmem->bb_state = sysfs_get_dirent(disk_to_dev(disk)->kobj.sd,
+ "badblocks");
+   if (pmem->bb_state)
+   sysfs_put(pmem->bb_state);
+   else
+   dev_warn(dev, "sysfs_get_dirent 'badblocks' failed\n");
+
return 0;
 }
 
@@ -428,6 +437,7 @@ static void nd_pmem_notify(struct device *dev, enum 
nvdimm_event event)
struct nd_namespace_io *nsio;
struct resource res;
struct badblocks *bb;
+   struct kernfs_node *bb_state;
 
if (event != NVDIMM_REVALIDATE_POISON)
return;
@@ -439,11 +449,13 @@ static void nd_pmem_notify(struct device *dev, enum 
nvdimm_event event)
nd_region = to_nd_region(ndns->dev.parent);
nsio = to_nd_namespace_io(>dev);
bb = >bb;
+   bb_state = NULL;
} else {
struct pmem_device *pmem = dev_get_drvdata(dev);
 
nd_region = to_region(pmem);
bb = >bb;
+   bb_state = pmem->bb_state;
 
if (is_nd_pfn(dev)) {
struct nd_pfn *nd_pfn = to_nd_pfn(dev);
@@ -463,6 +475,8 @@ static void nd_pmem_notify(struct device *dev, enum 
nvdimm_event event)
res.start = nsio->res.start + offset;
res.end = nsio->res.end - end_trunc;
nvdimm_badblocks_populate(nd_region, bb, );
+   if (bb_state)
+   sysfs_notify_dirent(bb_state);
 }
 
 MODULE_ALIAS("pmem");
diff --git a/drivers/nvdimm/pmem.h b/drivers/nvdimm/pmem.h
index 7f4dbd7..c5917f0 100644
--- a/drivers/nvdimm/pmem.h
+++ b/drivers/nvdimm/pmem.h
@@ -17,6 +17,7 @@ struct pmem_device {
size_t  size;
/* trim size when namespace capacity has been section aligned */
u32 pfn_pad;
+   struct kernfs_node  *bb_state;
struct badblocksbb;
struct dax_device   *dax_dev;
struct gendisk  *disk;
diff --git a/drivers/nvdimm/region.c b/drivers/nvdimm/region.c
index 869a886..ca94029 100644
--- a/drivers/nvdimm/region.c
+++ b/drivers/nvdimm/region.c
@@ -58,10 +58,16 @@ static int nd_region_probe(struct device *dev)
 
if (devm_init_badblocks(dev, _region->bb))
return -ENODEV;
+   nd_region->bb_state = sysfs_get_dirent(nd_region->dev.kobj.sd,
+  "badblocks");
+   if (nd_region->bb_state)
+   sysfs_put(nd_region->bb_state);
+   else
+   dev_warn(_region->dev,
+

Re: [PATCH v3] mmc: dw_mmc-k3: add sd support for hi3660

[Jaehoon Chung]

Hi,

On 06/12/2017 11:27 PM, Jaehoon Chung wrote:
> Hi Li,
> 
> On 2017년 06월 12일 16:46, liwei wrote:
>> Add sd card support for hi3660 soc
>>
>> Major changes in v3:
>>  - solve review comments from Heiner Kallweit.
>>*use the GENMASK and FIELD_PREP macros replace the bit shift operation.
>>*use usleep_range() replace udelay() and mdelay().
> 
> I had added the some comments about your previous patch.
> Refer to below...
> 
> https://patchwork.kernel.org/patch/9747495/

Before sending patch, run checkpatch...I will not apply this patch.

Best Regards,
Jaehoon Chung

> 
>>
>> Signed-off-by: Li Wei 
>> Signed-off-by: Chen Jun 
>> ---
> 
> Locate changelog at here.
> 
> Best Regards,
> Jaehoon Chung
> 
>>  drivers/mmc/host/dw_mmc-k3.c | 314 
>> +++
>>  1 file changed, 314 insertions(+)
>>
>> diff --git a/drivers/mmc/host/dw_mmc-k3.c b/drivers/mmc/host/dw_mmc-k3.c
>> index e38fb0020bb1..a6e13bd83b9f 100644
>> --- a/drivers/mmc/host/dw_mmc-k3.c
>> +++ b/drivers/mmc/host/dw_mmc-k3.c
>> @@ -8,6 +8,8 @@
>>   * (at your option) any later version.
>>   */
>>  
>> +#include 
>> +#include 
>>  #include 
>>  #include 
>>  #include 
>> @@ -28,7 +30,40 @@
>>  #define AO_SCTRL_SEL18  BIT(10)
>>  #define AO_SCTRL_CTRL3  0x40C
>>  
>> +#define DWMMC_SD_ID   1
>> +#define DWMMC_SDIO_ID 2
>> +
>> +#define SOC_SCTRL_SCPERCTRL5(0x314)
>> +#define SDCARD_IO_SEL18 BIT(2)
>> +
>> +#define GENCLK_DIV (7)
>> +
>> +#define GPIO_CLK_ENABLE   BIT(16)
>> +#define GPIO_CLK_DIV_MASK GENMASK(11, 8)
>> +#define GPIO_USE_SAMPLE_DLY_MASK  GENMASK(13, 13)
>> +#define UHS_REG_EXT_SAMPLE_PHASE_MASK GENMASK(20, 16)
>> +#define UHS_REG_EXT_SAMPLE_DRVPHASE_MASK  GENMASK(25, 21)
>> +#define UHS_REG_EXT_SAMPLE_DLY_MASK   GENMASK(30, 26)
>> +
>> +#define SDMMC_UHS_REG_EXT   0x108
>> +#define SDMMC_ENABLE_SHIFT  0x110
>> +
>> +#define TIMING_MODE 3
>> +#define TIMING_CFG_NUM 10
>> +
>> +#define PULL_DOWN BIT(1)
>> +#define PULL_UP   BIT(0)
>> +
>> +#define NUM_PHASES (40)
>> +
>> +#define ENABLE_SHIFT_MIN_SMPL (4)
>> +#define ENABLE_SHIFT_MAX_SMPL (12)
>> +#define USE_DLY_MIN_SMPL (11)
>> +#define USE_DLY_MAX_SMPL (14)
>> +
>>  struct k3_priv {
>> +u8 ctrl_id;
>> +u32 cur_speed;
>>  struct regmap   *reg;
>>  };
>>  
>> @@ -38,6 +73,41 @@ static unsigned long dw_mci_hi6220_caps[] = {
>>  0
>>  };
>>  
>> +struct hs_timing {
>> +int drv_phase;
>> +int sam_dly;
>> +int sam_phase_max;
>> +int sam_phase_min;
>> +};
>> +
>> +struct hs_timing hs_timing_cfg[TIMING_MODE][TIMING_CFG_NUM] = {
>> +{ /* reserved */ },
>> +{ /* SD */
>> +{7, 0, 15, 15,},  /* 0: LEGACY 400k */
>> +{6, 0,  4,  4,},  /* 1: MMC_HS */
>> +{6, 0,  3,  3,},  /* 2: SD_HS */
>> +{6, 0, 15, 15,},  /* 3: SDR12 */
>> +{6, 0,  2,  2,},  /* 4: SDR25 */
>> +{4, 0, 11,  0,},  /* 5: SDR50 */
>> +{6, 4, 15,  0,},  /* 6: SDR104 */
>> +{0},  /* 7: DDR50 */
>> +{0},  /* 8: DDR52 */
>> +{0},  /* 9: HS200 */
>> +},
>> +{ /* SDIO */
>> +{7, 0, 15, 15,},  /* 0: LEGACY 400k */
>> +{0},  /* 1: MMC_HS */
>> +{6, 0, 15, 15,},  /* 2: SD_HS */
>> +{6, 0, 15, 15,},  /* 3: SDR12 */
>> +{6, 0,  0,  0,},  /* 4: SDR25 */
>> +{4, 0, 12,  0,},  /* 5: SDR50 */
>> +{5, 4, 15,  0,},  /* 6: SDR104 */
>> +{0},  /* 7: DDR50 */
>> +{0},  /* 8: DDR52 */
>> +{0},  /* 9: HS200 */
>> +}
>> +};
>> +
>>  static void dw_mci_k3_set_ios(struct dw_mci *host, struct mmc_ios *ios)
>>  {
>>  int ret;
>> @@ -66,6 +136,10 @@ static int dw_mci_hi6220_parse_dt(struct dw_mci *host)
>>  if (IS_ERR(priv->reg))
>>  priv->reg = NULL;
>>  
>> +priv->ctrl_id = of_alias_get_id(host->dev->of_node, "mshc");
>> +if (priv->ctrl_id < 0)
>> +priv->ctrl_id = 0;
>> +
>>  host->priv = priv;
>>  return 0;
>>  }
>> @@ -144,7 +218,242 @@ static const struct dw_mci_drv_data hi6220_data = {
>>  .execute_tuning = dw_mci_hi6220_execute_tuning,
>>  };
>>  
>> +static void dw_mci_hs_set_timing(struct dw_mci *host, int timing, int 
>> sam_phase)
>> +{
>> +int drv_phase;
>> +int sam_dly;
>> +int ctrl_id;
>> +int use_sam_dly = 0;
>> +int enable_shift = 0;
>> +int reg_value;
>> +struct k3_priv *priv;
>> +
>> +priv = host->priv;
>> +ctrl_id = priv->ctrl_id;
>> +
>> +drv_phase = hs_timing_cfg[ctrl_id][timing].drv_phase;
>> +sam_dly   = hs_timing_cfg[ctrl_id][timing].sam_dly;
>> +if (sam_phase == -1)
>> +sam_phase = (hs_timing_cfg[ctrl_id][timing].sam_phase_max +
>> + 

Re: [PATCH v3] mmc: dw_mmc-k3: add sd support for hi3660

[Jaehoon Chung]

Hi,

On 06/12/2017 11:27 PM, Jaehoon Chung wrote:
> Hi Li,
> 
> On 2017년 06월 12일 16:46, liwei wrote:
>> Add sd card support for hi3660 soc
>>
>> Major changes in v3:
>>  - solve review comments from Heiner Kallweit.
>>*use the GENMASK and FIELD_PREP macros replace the bit shift operation.
>>*use usleep_range() replace udelay() and mdelay().
> 
> I had added the some comments about your previous patch.
> Refer to below...
> 
> https://patchwork.kernel.org/patch/9747495/

Before sending patch, run checkpatch...I will not apply this patch.

Best Regards,
Jaehoon Chung

> 
>>
>> Signed-off-by: Li Wei 
>> Signed-off-by: Chen Jun 
>> ---
> 
> Locate changelog at here.
> 
> Best Regards,
> Jaehoon Chung
> 
>>  drivers/mmc/host/dw_mmc-k3.c | 314 
>> +++
>>  1 file changed, 314 insertions(+)
>>
>> diff --git a/drivers/mmc/host/dw_mmc-k3.c b/drivers/mmc/host/dw_mmc-k3.c
>> index e38fb0020bb1..a6e13bd83b9f 100644
>> --- a/drivers/mmc/host/dw_mmc-k3.c
>> +++ b/drivers/mmc/host/dw_mmc-k3.c
>> @@ -8,6 +8,8 @@
>>   * (at your option) any later version.
>>   */
>>  
>> +#include 
>> +#include 
>>  #include 
>>  #include 
>>  #include 
>> @@ -28,7 +30,40 @@
>>  #define AO_SCTRL_SEL18  BIT(10)
>>  #define AO_SCTRL_CTRL3  0x40C
>>  
>> +#define DWMMC_SD_ID   1
>> +#define DWMMC_SDIO_ID 2
>> +
>> +#define SOC_SCTRL_SCPERCTRL5(0x314)
>> +#define SDCARD_IO_SEL18 BIT(2)
>> +
>> +#define GENCLK_DIV (7)
>> +
>> +#define GPIO_CLK_ENABLE   BIT(16)
>> +#define GPIO_CLK_DIV_MASK GENMASK(11, 8)
>> +#define GPIO_USE_SAMPLE_DLY_MASK  GENMASK(13, 13)
>> +#define UHS_REG_EXT_SAMPLE_PHASE_MASK GENMASK(20, 16)
>> +#define UHS_REG_EXT_SAMPLE_DRVPHASE_MASK  GENMASK(25, 21)
>> +#define UHS_REG_EXT_SAMPLE_DLY_MASK   GENMASK(30, 26)
>> +
>> +#define SDMMC_UHS_REG_EXT   0x108
>> +#define SDMMC_ENABLE_SHIFT  0x110
>> +
>> +#define TIMING_MODE 3
>> +#define TIMING_CFG_NUM 10
>> +
>> +#define PULL_DOWN BIT(1)
>> +#define PULL_UP   BIT(0)
>> +
>> +#define NUM_PHASES (40)
>> +
>> +#define ENABLE_SHIFT_MIN_SMPL (4)
>> +#define ENABLE_SHIFT_MAX_SMPL (12)
>> +#define USE_DLY_MIN_SMPL (11)
>> +#define USE_DLY_MAX_SMPL (14)
>> +
>>  struct k3_priv {
>> +u8 ctrl_id;
>> +u32 cur_speed;
>>  struct regmap   *reg;
>>  };
>>  
>> @@ -38,6 +73,41 @@ static unsigned long dw_mci_hi6220_caps[] = {
>>  0
>>  };
>>  
>> +struct hs_timing {
>> +int drv_phase;
>> +int sam_dly;
>> +int sam_phase_max;
>> +int sam_phase_min;
>> +};
>> +
>> +struct hs_timing hs_timing_cfg[TIMING_MODE][TIMING_CFG_NUM] = {
>> +{ /* reserved */ },
>> +{ /* SD */
>> +{7, 0, 15, 15,},  /* 0: LEGACY 400k */
>> +{6, 0,  4,  4,},  /* 1: MMC_HS */
>> +{6, 0,  3,  3,},  /* 2: SD_HS */
>> +{6, 0, 15, 15,},  /* 3: SDR12 */
>> +{6, 0,  2,  2,},  /* 4: SDR25 */
>> +{4, 0, 11,  0,},  /* 5: SDR50 */
>> +{6, 4, 15,  0,},  /* 6: SDR104 */
>> +{0},  /* 7: DDR50 */
>> +{0},  /* 8: DDR52 */
>> +{0},  /* 9: HS200 */
>> +},
>> +{ /* SDIO */
>> +{7, 0, 15, 15,},  /* 0: LEGACY 400k */
>> +{0},  /* 1: MMC_HS */
>> +{6, 0, 15, 15,},  /* 2: SD_HS */
>> +{6, 0, 15, 15,},  /* 3: SDR12 */
>> +{6, 0,  0,  0,},  /* 4: SDR25 */
>> +{4, 0, 12,  0,},  /* 5: SDR50 */
>> +{5, 4, 15,  0,},  /* 6: SDR104 */
>> +{0},  /* 7: DDR50 */
>> +{0},  /* 8: DDR52 */
>> +{0},  /* 9: HS200 */
>> +}
>> +};
>> +
>>  static void dw_mci_k3_set_ios(struct dw_mci *host, struct mmc_ios *ios)
>>  {
>>  int ret;
>> @@ -66,6 +136,10 @@ static int dw_mci_hi6220_parse_dt(struct dw_mci *host)
>>  if (IS_ERR(priv->reg))
>>  priv->reg = NULL;
>>  
>> +priv->ctrl_id = of_alias_get_id(host->dev->of_node, "mshc");
>> +if (priv->ctrl_id < 0)
>> +priv->ctrl_id = 0;
>> +
>>  host->priv = priv;
>>  return 0;
>>  }
>> @@ -144,7 +218,242 @@ static const struct dw_mci_drv_data hi6220_data = {
>>  .execute_tuning = dw_mci_hi6220_execute_tuning,
>>  };
>>  
>> +static void dw_mci_hs_set_timing(struct dw_mci *host, int timing, int 
>> sam_phase)
>> +{
>> +int drv_phase;
>> +int sam_dly;
>> +int ctrl_id;
>> +int use_sam_dly = 0;
>> +int enable_shift = 0;
>> +int reg_value;
>> +struct k3_priv *priv;
>> +
>> +priv = host->priv;
>> +ctrl_id = priv->ctrl_id;
>> +
>> +drv_phase = hs_timing_cfg[ctrl_id][timing].drv_phase;
>> +sam_dly   = hs_timing_cfg[ctrl_id][timing].sam_dly;
>> +if (sam_phase == -1)
>> +sam_phase = (hs_timing_cfg[ctrl_id][timing].sam_phase_max +
>> + hs_timing_cfg[ctrl_id][timing].sam_phase_min) / 2;
>> +
>> +

Re: nfc: nci: fix potential NULL pointer dereference

[Guenter Roeck]

On Mon, Jun 12, 2017 at 05:02:23PM -0500, Gustavo A. R. Silva wrote:
> NULL check at line 76: if (conn_info) {, implies that pointer conn_info
> might be NULL, but this pointer is being previously dereferenced,
> which might cause a NULL pointer dereference.
> 
> Add NULL check before dereferencing pointer conn_info in order to
> avoid a potential NULL pointer dereference.
> 
> Addresses-Coverity-ID: 1362349
> Signed-off-by: Gustavo A. R. Silva 
> ---
>  net/nfc/nci/core.c | 11 +--
>  1 file changed, 5 insertions(+), 6 deletions(-)
> 
> diff --git a/net/nfc/nci/core.c b/net/nfc/nci/core.c
> index 61fff42..d2198ce 100644
> --- a/net/nfc/nci/core.c
> +++ b/net/nfc/nci/core.c
> @@ -70,14 +70,13 @@ int nci_get_conn_info_by_dest_type_params(struct nci_dev 
> *ndev, u8 dest_type,
>   struct nci_conn_info *conn_info;
>  
>   list_for_each_entry(conn_info, >conn_info_list, list) {

conn_info is set in list_for_each_entry() using container_of(),
which is never NULL. Plus, it is dereferenced there as well.
The check is unnecessary.

Guenter

> - if (conn_info->dest_type == dest_type) {
> + if (conn_info && conn_info->dest_type == dest_type) {
>   if (!params)
>   return conn_info->conn_id;
> - if (conn_info) {
> - if (params->id == conn_info->dest_params->id &&
> - params->protocol == 
> conn_info->dest_params->protocol)
> - return conn_info->conn_id;
> - }
> +
> + if (params->id == conn_info->dest_params->id &&
> + params->protocol == 
> conn_info->dest_params->protocol)
> + return conn_info->conn_id;
>   }
>   }
>  

Re: nfc: nci: fix potential NULL pointer dereference

[Guenter Roeck]

On Mon, Jun 12, 2017 at 05:02:23PM -0500, Gustavo A. R. Silva wrote:
> NULL check at line 76: if (conn_info) {, implies that pointer conn_info
> might be NULL, but this pointer is being previously dereferenced,
> which might cause a NULL pointer dereference.
> 
> Add NULL check before dereferencing pointer conn_info in order to
> avoid a potential NULL pointer dereference.
> 
> Addresses-Coverity-ID: 1362349
> Signed-off-by: Gustavo A. R. Silva 
> ---
>  net/nfc/nci/core.c | 11 +--
>  1 file changed, 5 insertions(+), 6 deletions(-)
> 
> diff --git a/net/nfc/nci/core.c b/net/nfc/nci/core.c
> index 61fff42..d2198ce 100644
> --- a/net/nfc/nci/core.c
> +++ b/net/nfc/nci/core.c
> @@ -70,14 +70,13 @@ int nci_get_conn_info_by_dest_type_params(struct nci_dev 
> *ndev, u8 dest_type,
>   struct nci_conn_info *conn_info;
>  
>   list_for_each_entry(conn_info, >conn_info_list, list) {

conn_info is set in list_for_each_entry() using container_of(),
which is never NULL. Plus, it is dereferenced there as well.
The check is unnecessary.

Guenter

> - if (conn_info->dest_type == dest_type) {
> + if (conn_info && conn_info->dest_type == dest_type) {
>   if (!params)
>   return conn_info->conn_id;
> - if (conn_info) {
> - if (params->id == conn_info->dest_params->id &&
> - params->protocol == 
> conn_info->dest_params->protocol)
> - return conn_info->conn_id;
> - }
> +
> + if (params->id == conn_info->dest_params->id &&
> + params->protocol == 
> conn_info->dest_params->protocol)
> + return conn_info->conn_id;
>   }
>   }
>  

Re: [RFC PATCH 1/7 v1]powerpc: Free up four PTE bits to accommodate memory keys

[Ram Pai]

On Mon, Jun 12, 2017 at 12:27:44PM +0530, Aneesh Kumar K.V wrote:
> Ram Pai  writes:
> 
> > Rearrange  PTE   bits to  free  up  bits 3, 4, 5  and  6  for
> > memory keys. Bit 3, 4, 5, 6 and 57  shall  be used for memory
> > keys.
> >
> > The patch does the following change to the 64K PTE format
> >
> > H_PAGE_BUSY moves from bit 3 to bit 7
> > H_PAGE_F_SECOND which occupied bit 4 moves to the second part
> > of the pte.
> > H_PAGE_F_GIX which  occupied bit 5, 6 and 7 also moves to the
> > second part of the pte.
> >
> > The second part of the PTE will hold
> >a (H_PAGE_F_SECOND|H_PAGE_F_GIX)  for  64K page backed pte,
> >and sixteen (H_PAGE_F_SECOND|H_PAGE_F_GIX)  for 4k  backed
> > pte.
> >
> > the four  bits((H_PAGE_F_SECOND|H_PAGE_F_GIX) that represent a slot
> > is initialized to 0xF indicating a invalid slot. if a hashpage does
> > get  allocated  to  the  0xF  slot, it is released and not used. In
> > other words, even  though  0xF  is  a valid slot we discard it  and
> > consider it as invalid slot(HPTE_SOFT_INVALID). This  gives  us  an
> > opportunity to  not  depend on a bit in the primary PTE in order to
> > determine the validity of a slot.
> 
> Do we need to do this for 64K hptes ? H_PAGE_HASHPTE indicates whether a
> slot is valid or not. For 4K hptes, we do need this right ? ie, only
> when H_PAGE_COMBO is set we need to consider 0xf as an invalid slot

for 64k hptes; you are right, we do not use 0xF to
track the validity of a slot. We just depend on H_PAGE_HASHPTE flag.

for 4k hptes, we need to depend on both H_PAGE_HASHPTE as well as the
value of the slot.  H_PAGE_HASHPTE tells if there exists any valid
4k HPTEs, and the 4-bit values in the second-part-of-the-pte tells
us if they are valid values.

However in either case we do not need H_PAGE_COMBO. That flag is not
used for ptes.  But we continue to use that flag for pmd to track
hugepages, which is why I have not entirely divorced H_PAGE_COMBO from
the 64K pagesize case.

> 
> 
> >
> > When  we  release  a  0xF slot we also release a legitimate primary
> > slot  and  unmap  that  entry. This  is  to  ensure  that we do get
> > a legimate non-0xF slot the next time we retry for a slot.
> 
> Can you explain this more ? what is a primary slot here ?

I may not be using the right terminology here. But when I say slot, i
mean the four bits that tell the position of the hpte in the hash
buckets. Bit 0, indicates if it the primary or secondary hash bucket.
and bit 1,2,3 indicates the entry in the hash bucket.

So when i say primary slot, I mean a entry in the primary hash bucket.

The idea is, when hpte_insert returns a hpte which is cached in the 7slot
of the secondary bucket i.e 0xF, we discard it, and also release a
random entry from the primary bucket, so that on retry we can get that
entry.


> 
> >
> > Though treating 0xF slot as invalid reduces the number of available
> > slots and make have a effect on the performance, the probabilty
> > of hitting a 0xF is extermely low.
> >
> > Compared  to the current scheme, the above described scheme reduces
> > the number of false hash table updates  significantly  and  has the
> > added  advantage  of  releasing  four  valuable  PTE bits for other
> > purpose.
> >
> > This idea was jointly developed by Paul Mackerras, Aneesh, Michael
> > Ellermen and myself.
> >
> > 4K PTE format remain unchanged currently.
> >
> > Signed-off-by: Ram Pai 
> > ---
> >  arch/powerpc/include/asm/book3s/64/hash-4k.h  | 12 +
> >  arch/powerpc/include/asm/book3s/64/hash-64k.h | 38 ++
> >  arch/powerpc/include/asm/book3s/64/hash.h |  8 ++-
> >  arch/powerpc/include/asm/book3s/64/mmu-hash.h |  5 ++
> >  arch/powerpc/mm/dump_linuxpagetables.c|  3 +-
> >  arch/powerpc/mm/hash64_4k.c   | 12 ++---
> >  arch/powerpc/mm/hash64_64k.c  | 73 
> > +--
> >  arch/powerpc/mm/hash_utils_64.c   | 38 +-
> >  arch/powerpc/mm/hugetlbpage-hash64.c  | 16 +++---
> >  9 files changed, 107 insertions(+), 98 deletions(-)
> >
> > diff --git a/arch/powerpc/include/asm/book3s/64/hash-4k.h 
> > b/arch/powerpc/include/asm/book3s/64/hash-4k.h
> > index b4b5e6b..223d318 100644
> > --- a/arch/powerpc/include/asm/book3s/64/hash-4k.h
> > +++ b/arch/powerpc/include/asm/book3s/64/hash-4k.h
> > @@ -16,6 +16,18 @@
> >  #define H_PUD_TABLE_SIZE   (sizeof(pud_t) << H_PUD_INDEX_SIZE)
> >  #define H_PGD_TABLE_SIZE   (sizeof(pgd_t) << H_PGD_INDEX_SIZE)
> >
> > +
> > +/*
> > + * Only supported by 4k linux page size
> 
> that comment is confusing, you can drop that, it is part of hash-4k.h
> which means these defines are local to 4k linux page size config.
> 
> > + */

right. ok.

> > +#define H_PAGE_F_SECOND_RPAGE_RSV2 /* HPTE is in 2ndary HPTEG 
> > */
> > +#define H_PAGE_F_GIX   (_RPAGE_RSV3 | _RPAGE_RSV4 | _RPAGE_RPN44)
> > +#define H_PAGE_F_GIX_SHIFT 56
> > +

Re: [RFC PATCH 1/7 v1]powerpc: Free up four PTE bits to accommodate memory keys

[Ram Pai]

On Mon, Jun 12, 2017 at 12:27:44PM +0530, Aneesh Kumar K.V wrote:
> Ram Pai  writes:
> 
> > Rearrange  PTE   bits to  free  up  bits 3, 4, 5  and  6  for
> > memory keys. Bit 3, 4, 5, 6 and 57  shall  be used for memory
> > keys.
> >
> > The patch does the following change to the 64K PTE format
> >
> > H_PAGE_BUSY moves from bit 3 to bit 7
> > H_PAGE_F_SECOND which occupied bit 4 moves to the second part
> > of the pte.
> > H_PAGE_F_GIX which  occupied bit 5, 6 and 7 also moves to the
> > second part of the pte.
> >
> > The second part of the PTE will hold
> >a (H_PAGE_F_SECOND|H_PAGE_F_GIX)  for  64K page backed pte,
> >and sixteen (H_PAGE_F_SECOND|H_PAGE_F_GIX)  for 4k  backed
> > pte.
> >
> > the four  bits((H_PAGE_F_SECOND|H_PAGE_F_GIX) that represent a slot
> > is initialized to 0xF indicating a invalid slot. if a hashpage does
> > get  allocated  to  the  0xF  slot, it is released and not used. In
> > other words, even  though  0xF  is  a valid slot we discard it  and
> > consider it as invalid slot(HPTE_SOFT_INVALID). This  gives  us  an
> > opportunity to  not  depend on a bit in the primary PTE in order to
> > determine the validity of a slot.
> 
> Do we need to do this for 64K hptes ? H_PAGE_HASHPTE indicates whether a
> slot is valid or not. For 4K hptes, we do need this right ? ie, only
> when H_PAGE_COMBO is set we need to consider 0xf as an invalid slot

for 64k hptes; you are right, we do not use 0xF to
track the validity of a slot. We just depend on H_PAGE_HASHPTE flag.

for 4k hptes, we need to depend on both H_PAGE_HASHPTE as well as the
value of the slot.  H_PAGE_HASHPTE tells if there exists any valid
4k HPTEs, and the 4-bit values in the second-part-of-the-pte tells
us if they are valid values.

However in either case we do not need H_PAGE_COMBO. That flag is not
used for ptes.  But we continue to use that flag for pmd to track
hugepages, which is why I have not entirely divorced H_PAGE_COMBO from
the 64K pagesize case.

> 
> 
> >
> > When  we  release  a  0xF slot we also release a legitimate primary
> > slot  and  unmap  that  entry. This  is  to  ensure  that we do get
> > a legimate non-0xF slot the next time we retry for a slot.
> 
> Can you explain this more ? what is a primary slot here ?

I may not be using the right terminology here. But when I say slot, i
mean the four bits that tell the position of the hpte in the hash
buckets. Bit 0, indicates if it the primary or secondary hash bucket.
and bit 1,2,3 indicates the entry in the hash bucket.

So when i say primary slot, I mean a entry in the primary hash bucket.

The idea is, when hpte_insert returns a hpte which is cached in the 7slot
of the secondary bucket i.e 0xF, we discard it, and also release a
random entry from the primary bucket, so that on retry we can get that
entry.


> 
> >
> > Though treating 0xF slot as invalid reduces the number of available
> > slots and make have a effect on the performance, the probabilty
> > of hitting a 0xF is extermely low.
> >
> > Compared  to the current scheme, the above described scheme reduces
> > the number of false hash table updates  significantly  and  has the
> > added  advantage  of  releasing  four  valuable  PTE bits for other
> > purpose.
> >
> > This idea was jointly developed by Paul Mackerras, Aneesh, Michael
> > Ellermen and myself.
> >
> > 4K PTE format remain unchanged currently.
> >
> > Signed-off-by: Ram Pai 
> > ---
> >  arch/powerpc/include/asm/book3s/64/hash-4k.h  | 12 +
> >  arch/powerpc/include/asm/book3s/64/hash-64k.h | 38 ++
> >  arch/powerpc/include/asm/book3s/64/hash.h |  8 ++-
> >  arch/powerpc/include/asm/book3s/64/mmu-hash.h |  5 ++
> >  arch/powerpc/mm/dump_linuxpagetables.c|  3 +-
> >  arch/powerpc/mm/hash64_4k.c   | 12 ++---
> >  arch/powerpc/mm/hash64_64k.c  | 73 
> > +--
> >  arch/powerpc/mm/hash_utils_64.c   | 38 +-
> >  arch/powerpc/mm/hugetlbpage-hash64.c  | 16 +++---
> >  9 files changed, 107 insertions(+), 98 deletions(-)
> >
> > diff --git a/arch/powerpc/include/asm/book3s/64/hash-4k.h 
> > b/arch/powerpc/include/asm/book3s/64/hash-4k.h
> > index b4b5e6b..223d318 100644
> > --- a/arch/powerpc/include/asm/book3s/64/hash-4k.h
> > +++ b/arch/powerpc/include/asm/book3s/64/hash-4k.h
> > @@ -16,6 +16,18 @@
> >  #define H_PUD_TABLE_SIZE   (sizeof(pud_t) << H_PUD_INDEX_SIZE)
> >  #define H_PGD_TABLE_SIZE   (sizeof(pgd_t) << H_PGD_INDEX_SIZE)
> >
> > +
> > +/*
> > + * Only supported by 4k linux page size
> 
> that comment is confusing, you can drop that, it is part of hash-4k.h
> which means these defines are local to 4k linux page size config.
> 
> > + */

right. ok.

> > +#define H_PAGE_F_SECOND_RPAGE_RSV2 /* HPTE is in 2ndary HPTEG 
> > */
> > +#define H_PAGE_F_GIX   (_RPAGE_RSV3 | _RPAGE_RSV4 | _RPAGE_RPN44)
> > +#define H_PAGE_F_GIX_SHIFT 56
> > +
> > +#define H_PAGE_BUSY

Re: [PATCH v2 5/8] PM / sleep: Print timing information if debug is enabled

[Joe Perches]

On Mon, 2017-06-12 at 22:51 +0200, Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki 
> 
> Avoid printing the device suspend/resume timing information if
> CONFIG_PM_DEBUG is not set to reduce the log noise level.
> 
> Signed-off-by: Rafael J. Wysocki 
> ---
>  drivers/base/power/main.c |4 
>  1 file changed, 4 insertions(+)
> 
> Index: linux-pm/drivers/base/power/main.c
> ===
> --- linux-pm.orig/drivers/base/power/main.c
> +++ linux-pm/drivers/base/power/main.c
> @@ -417,6 +417,7 @@ static void pm_dev_err(struct device *de
>   dev_name(dev), pm_verb(state.event), info, error);
>  }
>  
> +#ifdef CONFIG_PM_DEBUG
>  static void dpm_show_time(ktime_t starttime, pm_message_t state, char *info)
>  {
>   ktime_t calltime;
> @@ -433,6 +434,9 @@ static void dpm_show_time(ktime_t startt
>   info ?: "", info ? " " : "", pm_verb(state.event),
>   usecs / USEC_PER_MSEC, usecs % USEC_PER_MSEC);
>  }
> +#else
> +static inline void dpm_show_time(ktime_t starttime, pm_message_t state, char 
> *info) {}
> +#endif /* CONFIG_PM_DEBUG */
>  
>  static int dpm_run_callback(pm_callback_t cb, struct device *dev,
>   pm_message_t state, char *info)
> 

trivia:

This style of code can be reduced a few lines of code
using a single definition.

static type func(args...)
{
#ifdef CONFIG_
[code ...]
#endif
}

and compilers will generate the same code for the
!defined CONFIG_ case.

This style can help avoid defects of updating one
function definition and not the other and only
compile testing the updated version.

Re: [PATCH v2 5/8] PM / sleep: Print timing information if debug is enabled

[Joe Perches]

On Mon, 2017-06-12 at 22:51 +0200, Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki 
> 
> Avoid printing the device suspend/resume timing information if
> CONFIG_PM_DEBUG is not set to reduce the log noise level.
> 
> Signed-off-by: Rafael J. Wysocki 
> ---
>  drivers/base/power/main.c |4 
>  1 file changed, 4 insertions(+)
> 
> Index: linux-pm/drivers/base/power/main.c
> ===
> --- linux-pm.orig/drivers/base/power/main.c
> +++ linux-pm/drivers/base/power/main.c
> @@ -417,6 +417,7 @@ static void pm_dev_err(struct device *de
>   dev_name(dev), pm_verb(state.event), info, error);
>  }
>  
> +#ifdef CONFIG_PM_DEBUG
>  static void dpm_show_time(ktime_t starttime, pm_message_t state, char *info)
>  {
>   ktime_t calltime;
> @@ -433,6 +434,9 @@ static void dpm_show_time(ktime_t startt
>   info ?: "", info ? " " : "", pm_verb(state.event),
>   usecs / USEC_PER_MSEC, usecs % USEC_PER_MSEC);
>  }
> +#else
> +static inline void dpm_show_time(ktime_t starttime, pm_message_t state, char 
> *info) {}
> +#endif /* CONFIG_PM_DEBUG */
>  
>  static int dpm_run_callback(pm_callback_t cb, struct device *dev,
>   pm_message_t state, char *info)
> 

trivia:

This style of code can be reduced a few lines of code
using a single definition.

static type func(args...)
{
#ifdef CONFIG_
[code ...]
#endif
}

and compilers will generate the same code for the
!defined CONFIG_ case.

This style can help avoid defects of updating one
function definition and not the other and only
compile testing the updated version.

Re: WMI and Kernel:User interface

[Pali Rohár]

On Monday 12 June 2017 19:02:49 Darren Hart wrote:
> On Sat, Jun 10, 2017 at 12:36:40PM +0200, Pali Rohár wrote:
> > On Saturday 10 June 2017 02:46:41 Darren Hart wrote:
> > > On Fri, Jun 09, 2017 at 08:41:51AM +0200, Greg Kroah-Hartman
> > > wrote:
> > > > On Sat, Jun 03, 2017 at 12:50:58PM -0700, Darren Hart wrote:
> > > > > On Wed, May 10, 2017 at 07:13:41AM +0200, Greg Kroah-Hartman
> > > > > 
> > > > > wrote:
> > > > > > On Tue, May 09, 2017 at 04:16:39PM -0700, Darren Hart wrote:
> > > > > > > Linus and Greg,
> > > > > > > 
> > > > > > > We are in the process of redesigning the Windows
> > > > > > > Management Instrumentation (WMI) [1] system in the
> > > > > > > kernel. WMI is the Microsoft implementation of Web-Based
> > > > > > > Enterprise Management (WBEM). We are looking to provide
> > > > > > > WMI access to userspace, while allowing the kernel to
> > > > > > > filter requests that conflict with its own usage. We'd
> > > > > > > like your take on how this approach relates to our
> > > > > > > commitment to not break userspace.
> > > > > > > 
> > > > > > > For this discussion, we are specifically referring to
> > > > > > > ACPI PNP0C14 WMI devices, consisting of a GUID and a set
> > > > > > > of methods and events, as well as a precompiled
> > > > > > > intermediate description of the methods and arguments
> > > > > > > (MOF). Exposed to userspace, these methods provide for
> > > > > > > BIOS interaction and are used for system management as
> > > > > > > well as LEDs, hot keys, radio switches, etc. There is
> > > > > > > vendor interest in achieving feature parity with Windows
> > > > > > > by exposing WMI methods to userspace for system
> > > > > > > management.
> > > > > > > 
> > > > > > > While it appears WMI intended to be accessed from
> > > > > > > userspace, we have made use of it in the kernel to
> > > > > > > support various laptop features by connecting the WMI
> > > > > > > methods to other subsystems, notably input, leds, and
> > > > > > > rfkill [2]. The challenge is continuing to use WMI for
> > > > > > > these platform features, while allowing userspace to use
> > > > > > > it for system management tasks. Unfortunately, the WMI
> > > > > > > methods are not guaranteed to be split up along granular
> > > > > > > functional lines, and we will certainly face situations
> > > > > > > where the same GUID::METHOD_ID will be needed for a
> > > > > > > kernel feature (say LED support) as well as a system
> > > > > > > management task.
> > > > > > > 
> > > > > > > To address this, I have proposed [3] that exporting WMI
> > > > > > > be opt-in, only done at the request of and in
> > > > > > > collaboration with a vendor, with the kernel platform
> > > > > > > driver given the opportunity to filter requests. This
> > > > > > > filtering would need to be at the method and argument
> > > > > > > inspection level, such as checking for specific bits in
> > > > > > > the input buffer, and rejecting the request if they
> > > > > > > conflict with an in kernel usage (that's worst case, in
> > > > > > > some cases just GUID or method ID could be sufficient).
> > > > > > > 
> > > > > > > Because the kernel and the platform drivers are under
> > > > > > > continual development, and new systems appear regularly,
> > > > > > > we will encounter necessary changes to the platform
> > > > > > > driver WMI request filters. These changes could be
> > > > > > > considered a change to the kernel provided WMI interface
> > > > > > > to userspace. For example, we could regularly accept a
> > > > > > > call to
> > > > > > > $GUID::$METHOD_ID with bit 4 of the buffer set, and later
> > > > > > > deny the call when we determine it interferes with kernel
> > > > > > > usage.
> > > > > > > 
> > > > > > > In your view, is it acceptable to provide a chardev
> > > > > > > interface, for example, exposing WMI methods to
> > > > > > > userspace, with the understanding that the kernel may
> > > > > > > choose to filter certain requests which conflict with
> > > > > > > its own use? And that this filtering may change as new
> > > > > > > features are added to the platform drivers?
> > > > > > 
> > > > > > So, for example, if a new driver for a "brightness key"
> > > > > > were added to the kernel, all of a sudden the "raw" access
> > > > > > to the wmi data through the chardev would filtered away by
> > > > > > the kernel and not seen by userspace?
> > > > > > 
> > > > > > Why would you want to do that?  What's wrong with providing
> > > > > > "raw" access through a chardev, and the current in-kernel
> > > > > > access as well at the same time?
> > > > > > 
> > > > > > I don't really understand what would "break" over time
> > > > > > here.
> > > > > 
> > > > > Just a bump now that we're out of the merge window in case
> > > > > either Greg or Linus care to follow up with the responses to
> > > > > this.
> > > > > 
> > > > > To Greg's last point - any kernel state that is built up in
> > > > > conjunction with the WMI 

Re: [PATCH] audit: style fix

[Paul Moore]

On Sun, Jun 11, 2017 at 10:33 PM, Derek Robson  wrote:
> Fixed checkpatch.pl warnings of "function definition argument FOO
>  should also have an identifier name"
>
> Signed-off-by: Derek Robson 
> ---
>  kernel/audit.h | 28 ++--
>  1 file changed, 14 insertions(+), 14 deletions(-)

I'm going to go ahead and merge this, but I generally dislike
accepting standalone style/formatting patches from people who don't
regularly contribute to the subsystem.  Honestly, I tend to dislike
seeing patches like this from regular contributors as well, I'm just
slightly less annoyed in those cases.

If you are interested in contributing to the audit subsystem, but
aren't sure where to start, I would encourage you to take a look at
some of the outstanding issues on GitHub; patches for any of those
issues would be much more helpful than a style/formatting fix.

* https://github.com/linux-audit/audit-kernel/issues
* https://github.com/linux-audit/audit-testsuite/issues

If you have any questions about those issues, feel free to comment on
the issue, or send an email to the audit mailing list, and we'll do
our best to help you get started.

> diff --git a/kernel/audit.h b/kernel/audit.h
> index ddfce2ea4891..90b891eea204 100644
> --- a/kernel/audit.h
> +++ b/kernel/audit.h
> @@ -247,13 +247,13 @@ struct audit_netlink_list {
> struct sk_buff_head q;
>  };
>
> -int audit_send_list(void *);
> +int audit_send_list(void *_dest);
>
>  extern int selinux_audit_rule_update(void);
>
>  extern struct mutex audit_filter_mutex;
> -extern int audit_del_rule(struct audit_entry *);
> -extern void audit_free_rule_rcu(struct rcu_head *);
> +extern int audit_del_rule(struct audit_entry *entry);
> +extern void audit_free_rule_rcu(struct rcu_head *head);
>  extern struct list_head audit_filter_list[];
>
>  extern struct audit_entry *audit_dupe_rule(struct audit_krule *old);
> @@ -301,17 +301,17 @@ extern int audit_exe_compare(struct task_struct *tsk, 
> struct audit_fsnotify_mark
>  #endif /* CONFIG_AUDIT_WATCH */
>
>  #ifdef CONFIG_AUDIT_TREE
> -extern struct audit_chunk *audit_tree_lookup(const struct inode *);
> -extern void audit_put_chunk(struct audit_chunk *);
> -extern bool audit_tree_match(struct audit_chunk *, struct audit_tree *);
> -extern int audit_make_tree(struct audit_krule *, char *, u32);
> -extern int audit_add_tree_rule(struct audit_krule *);
> -extern int audit_remove_tree_rule(struct audit_krule *);
> +extern struct audit_chunk *audit_tree_lookup(const struct inode *inode);
> +extern void audit_put_chunk(struct audit_chunk *chunk);
> +extern bool audit_tree_match(struct audit_chunk *chunk, struct audit_tree 
> *tree);
> +extern int audit_make_tree(struct audit_krule *rule, char *pathname, u32 op);
> +extern int audit_add_tree_rule(struct audit_krule *rule);
> +extern int audit_remove_tree_rule(struct audit_krule *rule);
>  extern void audit_trim_trees(void);
>  extern int audit_tag_tree(char *old, char *new);
> -extern const char *audit_tree_path(struct audit_tree *);
> -extern void audit_put_tree(struct audit_tree *);
> -extern void audit_kill_trees(struct list_head *);
> +extern const char *audit_tree_path(struct audit_tree *tree);
> +extern void audit_put_tree(struct audit_tree *tree);
> +extern void audit_kill_trees(struct list_head *list);
>  #else
>  #define audit_remove_tree_rule(rule) BUG()
>  #define audit_add_tree_rule(rule) -EINVAL
> @@ -323,7 +323,7 @@ extern void audit_kill_trees(struct list_head *);
>  #define audit_kill_trees(list) BUG()
>  #endif
>
> -extern char *audit_unpack_string(void **, size_t *, size_t);
> +extern char *audit_unpack_string(void **bufp, size_t *remain, size_t len);
>
>  extern pid_t audit_sig_pid;
>  extern kuid_t audit_sig_uid;
> @@ -333,7 +333,7 @@ extern int audit_filter(int msgtype, unsigned int 
> listtype);
>
>  #ifdef CONFIG_AUDITSYSCALL
>  extern int audit_signal_info(int sig, struct task_struct *t);
> -extern void audit_filter_inodes(struct task_struct *, struct audit_context 
> *);
> +extern void audit_filter_inodes(struct task_struct *tsk, struct 
> audit_context *ctx);
>  extern struct list_head *audit_killed_trees(void);
>  #else
>  #define audit_signal_info(s,t) AUDIT_DISABLED
> --
> 2.13.0
>



-- 
paul moore
www.paul-moore.com

Re: WMI and Kernel:User interface

[Pali Rohár]

On Monday 12 June 2017 19:02:49 Darren Hart wrote:
> On Sat, Jun 10, 2017 at 12:36:40PM +0200, Pali Rohár wrote:
> > On Saturday 10 June 2017 02:46:41 Darren Hart wrote:
> > > On Fri, Jun 09, 2017 at 08:41:51AM +0200, Greg Kroah-Hartman
> > > wrote:
> > > > On Sat, Jun 03, 2017 at 12:50:58PM -0700, Darren Hart wrote:
> > > > > On Wed, May 10, 2017 at 07:13:41AM +0200, Greg Kroah-Hartman
> > > > > 
> > > > > wrote:
> > > > > > On Tue, May 09, 2017 at 04:16:39PM -0700, Darren Hart wrote:
> > > > > > > Linus and Greg,
> > > > > > > 
> > > > > > > We are in the process of redesigning the Windows
> > > > > > > Management Instrumentation (WMI) [1] system in the
> > > > > > > kernel. WMI is the Microsoft implementation of Web-Based
> > > > > > > Enterprise Management (WBEM). We are looking to provide
> > > > > > > WMI access to userspace, while allowing the kernel to
> > > > > > > filter requests that conflict with its own usage. We'd
> > > > > > > like your take on how this approach relates to our
> > > > > > > commitment to not break userspace.
> > > > > > > 
> > > > > > > For this discussion, we are specifically referring to
> > > > > > > ACPI PNP0C14 WMI devices, consisting of a GUID and a set
> > > > > > > of methods and events, as well as a precompiled
> > > > > > > intermediate description of the methods and arguments
> > > > > > > (MOF). Exposed to userspace, these methods provide for
> > > > > > > BIOS interaction and are used for system management as
> > > > > > > well as LEDs, hot keys, radio switches, etc. There is
> > > > > > > vendor interest in achieving feature parity with Windows
> > > > > > > by exposing WMI methods to userspace for system
> > > > > > > management.
> > > > > > > 
> > > > > > > While it appears WMI intended to be accessed from
> > > > > > > userspace, we have made use of it in the kernel to
> > > > > > > support various laptop features by connecting the WMI
> > > > > > > methods to other subsystems, notably input, leds, and
> > > > > > > rfkill [2]. The challenge is continuing to use WMI for
> > > > > > > these platform features, while allowing userspace to use
> > > > > > > it for system management tasks. Unfortunately, the WMI
> > > > > > > methods are not guaranteed to be split up along granular
> > > > > > > functional lines, and we will certainly face situations
> > > > > > > where the same GUID::METHOD_ID will be needed for a
> > > > > > > kernel feature (say LED support) as well as a system
> > > > > > > management task.
> > > > > > > 
> > > > > > > To address this, I have proposed [3] that exporting WMI
> > > > > > > be opt-in, only done at the request of and in
> > > > > > > collaboration with a vendor, with the kernel platform
> > > > > > > driver given the opportunity to filter requests. This
> > > > > > > filtering would need to be at the method and argument
> > > > > > > inspection level, such as checking for specific bits in
> > > > > > > the input buffer, and rejecting the request if they
> > > > > > > conflict with an in kernel usage (that's worst case, in
> > > > > > > some cases just GUID or method ID could be sufficient).
> > > > > > > 
> > > > > > > Because the kernel and the platform drivers are under
> > > > > > > continual development, and new systems appear regularly,
> > > > > > > we will encounter necessary changes to the platform
> > > > > > > driver WMI request filters. These changes could be
> > > > > > > considered a change to the kernel provided WMI interface
> > > > > > > to userspace. For example, we could regularly accept a
> > > > > > > call to
> > > > > > > $GUID::$METHOD_ID with bit 4 of the buffer set, and later
> > > > > > > deny the call when we determine it interferes with kernel
> > > > > > > usage.
> > > > > > > 
> > > > > > > In your view, is it acceptable to provide a chardev
> > > > > > > interface, for example, exposing WMI methods to
> > > > > > > userspace, with the understanding that the kernel may
> > > > > > > choose to filter certain requests which conflict with
> > > > > > > its own use? And that this filtering may change as new
> > > > > > > features are added to the platform drivers?
> > > > > > 
> > > > > > So, for example, if a new driver for a "brightness key"
> > > > > > were added to the kernel, all of a sudden the "raw" access
> > > > > > to the wmi data through the chardev would filtered away by
> > > > > > the kernel and not seen by userspace?
> > > > > > 
> > > > > > Why would you want to do that?  What's wrong with providing
> > > > > > "raw" access through a chardev, and the current in-kernel
> > > > > > access as well at the same time?
> > > > > > 
> > > > > > I don't really understand what would "break" over time
> > > > > > here.
> > > > > 
> > > > > Just a bump now that we're out of the merge window in case
> > > > > either Greg or Linus care to follow up with the responses to
> > > > > this.
> > > > > 
> > > > > To Greg's last point - any kernel state that is built up in
> > > > > conjunction with the WMI 

Re: [PATCH] audit: style fix

[Paul Moore]

On Sun, Jun 11, 2017 at 10:33 PM, Derek Robson  wrote:
> Fixed checkpatch.pl warnings of "function definition argument FOO
>  should also have an identifier name"
>
> Signed-off-by: Derek Robson 
> ---
>  kernel/audit.h | 28 ++--
>  1 file changed, 14 insertions(+), 14 deletions(-)

I'm going to go ahead and merge this, but I generally dislike
accepting standalone style/formatting patches from people who don't
regularly contribute to the subsystem.  Honestly, I tend to dislike
seeing patches like this from regular contributors as well, I'm just
slightly less annoyed in those cases.

If you are interested in contributing to the audit subsystem, but
aren't sure where to start, I would encourage you to take a look at
some of the outstanding issues on GitHub; patches for any of those
issues would be much more helpful than a style/formatting fix.

* https://github.com/linux-audit/audit-kernel/issues
* https://github.com/linux-audit/audit-testsuite/issues

If you have any questions about those issues, feel free to comment on
the issue, or send an email to the audit mailing list, and we'll do
our best to help you get started.

> diff --git a/kernel/audit.h b/kernel/audit.h
> index ddfce2ea4891..90b891eea204 100644
> --- a/kernel/audit.h
> +++ b/kernel/audit.h
> @@ -247,13 +247,13 @@ struct audit_netlink_list {
> struct sk_buff_head q;
>  };
>
> -int audit_send_list(void *);
> +int audit_send_list(void *_dest);
>
>  extern int selinux_audit_rule_update(void);
>
>  extern struct mutex audit_filter_mutex;
> -extern int audit_del_rule(struct audit_entry *);
> -extern void audit_free_rule_rcu(struct rcu_head *);
> +extern int audit_del_rule(struct audit_entry *entry);
> +extern void audit_free_rule_rcu(struct rcu_head *head);
>  extern struct list_head audit_filter_list[];
>
>  extern struct audit_entry *audit_dupe_rule(struct audit_krule *old);
> @@ -301,17 +301,17 @@ extern int audit_exe_compare(struct task_struct *tsk, 
> struct audit_fsnotify_mark
>  #endif /* CONFIG_AUDIT_WATCH */
>
>  #ifdef CONFIG_AUDIT_TREE
> -extern struct audit_chunk *audit_tree_lookup(const struct inode *);
> -extern void audit_put_chunk(struct audit_chunk *);
> -extern bool audit_tree_match(struct audit_chunk *, struct audit_tree *);
> -extern int audit_make_tree(struct audit_krule *, char *, u32);
> -extern int audit_add_tree_rule(struct audit_krule *);
> -extern int audit_remove_tree_rule(struct audit_krule *);
> +extern struct audit_chunk *audit_tree_lookup(const struct inode *inode);
> +extern void audit_put_chunk(struct audit_chunk *chunk);
> +extern bool audit_tree_match(struct audit_chunk *chunk, struct audit_tree 
> *tree);
> +extern int audit_make_tree(struct audit_krule *rule, char *pathname, u32 op);
> +extern int audit_add_tree_rule(struct audit_krule *rule);
> +extern int audit_remove_tree_rule(struct audit_krule *rule);
>  extern void audit_trim_trees(void);
>  extern int audit_tag_tree(char *old, char *new);
> -extern const char *audit_tree_path(struct audit_tree *);
> -extern void audit_put_tree(struct audit_tree *);
> -extern void audit_kill_trees(struct list_head *);
> +extern const char *audit_tree_path(struct audit_tree *tree);
> +extern void audit_put_tree(struct audit_tree *tree);
> +extern void audit_kill_trees(struct list_head *list);
>  #else
>  #define audit_remove_tree_rule(rule) BUG()
>  #define audit_add_tree_rule(rule) -EINVAL
> @@ -323,7 +323,7 @@ extern void audit_kill_trees(struct list_head *);
>  #define audit_kill_trees(list) BUG()
>  #endif
>
> -extern char *audit_unpack_string(void **, size_t *, size_t);
> +extern char *audit_unpack_string(void **bufp, size_t *remain, size_t len);
>
>  extern pid_t audit_sig_pid;
>  extern kuid_t audit_sig_uid;
> @@ -333,7 +333,7 @@ extern int audit_filter(int msgtype, unsigned int 
> listtype);
>
>  #ifdef CONFIG_AUDITSYSCALL
>  extern int audit_signal_info(int sig, struct task_struct *t);
> -extern void audit_filter_inodes(struct task_struct *, struct audit_context 
> *);
> +extern void audit_filter_inodes(struct task_struct *tsk, struct 
> audit_context *ctx);
>  extern struct list_head *audit_killed_trees(void);
>  #else
>  #define audit_signal_info(s,t) AUDIT_DISABLED
> --
> 2.13.0
>



-- 
paul moore
www.paul-moore.com

Re: [tip:timers/core] posix-timers: Zero out oldval itimerspec

[Andrei Vagin]

On Tue, Jun 13, 2017 at 12:01:17AM +0200, Thomas Gleixner wrote:
> On Mon, 12 Jun 2017, Andrei Vagin wrote:
> > > diff --git a/kernel/time/posix-timers.c b/kernel/time/posix-timers.c
> > > index b53a0b5..88517dc 100644
> > > --- a/kernel/time/posix-timers.c
> > > +++ b/kernel/time/posix-timers.c
> > > @@ -828,6 +828,8 @@ SYSCALL_DEFINE4(timer_settime, timer_t, timer_id, 
> > > int, flags,
> > >   if (!timespec64_valid(_spec64.it_interval) ||
> > >   !timespec64_valid(_spec64.it_value))
> > >   return -EINVAL;
> > > + if (rtn)
> > > + memset(rtn, 0, sizeof(*rtn));
> > 
> > Maybe we need to call memset after "retry:"?
> 
> That would be counter productive.
> 
> > common_timer_get() is called at the begining of common_timer_set(), then
> > common_timer_set() can return TIMER_RETRY. common_timer_get() will be
> > called again and some fields of rtn which have been touched first time
> > will not be touched.
> > 
> > At the end, rtn will contain data from two executions of
> > common_timer_get().
> 
> No. See the full code sequence:
> 
> retry:
> timr = lock_timer(timer_id, );
> if (!timr)
> return -EINVAL;
> 
> kc = clockid_to_kclock(timr->it_clock);
>   if (WARN_ON_ONCE(!kc || !kc->timer_set))
> error = -EINVAL;
> else
> error = kc->timer_set(timr, flags, _spec64, rtn);
> 
> unlock_timer(timr, flag);
> if (error == TIMER_RETRY) {
> rtn = NULL; // We already got the old time...
> goto retry;
> }
> 
> If you clear it after retry, you'll get all zeros in the retry case. Not
> what you really want.

Yes, you are right. Sorry for the noise.
> 
> Thanks,
> 
>   tglx

Re: [tip:timers/core] posix-timers: Zero out oldval itimerspec

[Andrei Vagin]

On Tue, Jun 13, 2017 at 12:01:17AM +0200, Thomas Gleixner wrote:
> On Mon, 12 Jun 2017, Andrei Vagin wrote:
> > > diff --git a/kernel/time/posix-timers.c b/kernel/time/posix-timers.c
> > > index b53a0b5..88517dc 100644
> > > --- a/kernel/time/posix-timers.c
> > > +++ b/kernel/time/posix-timers.c
> > > @@ -828,6 +828,8 @@ SYSCALL_DEFINE4(timer_settime, timer_t, timer_id, 
> > > int, flags,
> > >   if (!timespec64_valid(_spec64.it_interval) ||
> > >   !timespec64_valid(_spec64.it_value))
> > >   return -EINVAL;
> > > + if (rtn)
> > > + memset(rtn, 0, sizeof(*rtn));
> > 
> > Maybe we need to call memset after "retry:"?
> 
> That would be counter productive.
> 
> > common_timer_get() is called at the begining of common_timer_set(), then
> > common_timer_set() can return TIMER_RETRY. common_timer_get() will be
> > called again and some fields of rtn which have been touched first time
> > will not be touched.
> > 
> > At the end, rtn will contain data from two executions of
> > common_timer_get().
> 
> No. See the full code sequence:
> 
> retry:
> timr = lock_timer(timer_id, );
> if (!timr)
> return -EINVAL;
> 
> kc = clockid_to_kclock(timr->it_clock);
>   if (WARN_ON_ONCE(!kc || !kc->timer_set))
> error = -EINVAL;
> else
> error = kc->timer_set(timr, flags, _spec64, rtn);
> 
> unlock_timer(timr, flag);
> if (error == TIMER_RETRY) {
> rtn = NULL; // We already got the old time...
> goto retry;
> }
> 
> If you clear it after retry, you'll get all zeros in the retry case. Not
> what you really want.

Yes, you are right. Sorry for the noise.
> 
> Thanks,
> 
>   tglx

[PATCH v3 1/3] arch: Define CPU_BIG_ENDIAN for all fixed big endian archs

[Babu Moger]

While working on enabling queued rwlock on SPARC, found
this following code in include/asm-generic/qrwlock.h
which uses CONFIG_CPU_BIG_ENDIAN to clear a byte.

static inline u8 *__qrwlock_write_byte(struct qrwlock *lock)
 {
return (u8 *)lock + 3 * IS_BUILTIN(CONFIG_CPU_BIG_ENDIAN);
 }

Problem is many of the fixed big endian architectures don't define
CPU_BIG_ENDIAN and clears the wrong byte.

Define CPU_BIG_ENDIAN for all the fixed big endian architecture to fix it.

Also found few more references of this config parameter in
drivers/of/base.c
drivers/of/fdt.c
drivers/tty/serial/earlycon.c
drivers/tty/serial/serial_core.c
Be aware that this may cause regressions if someone has worked-around
problems in the above code already. Remove the work-around.

Here is our original discussion
https://lkml.org/lkml/2017/5/24/620

Signed-off-by: Babu Moger 
Suggested-by: Arnd Bergmann 
Acked-by: Geert Uytterhoeven 
Acked-by: David S. Miller 
Acked-by: Stafford Horne 
---
 arch/frv/Kconfig  |3 +++
 arch/h8300/Kconfig|3 +++
 arch/m68k/Kconfig |3 +++
 arch/openrisc/Kconfig |3 +++
 arch/parisc/Kconfig   |3 +++
 arch/sparc/Kconfig|3 +++
 6 files changed, 18 insertions(+), 0 deletions(-)

diff --git a/arch/frv/Kconfig b/arch/frv/Kconfig
index eefd9a4..1cce824 100644
--- a/arch/frv/Kconfig
+++ b/arch/frv/Kconfig
@@ -17,6 +17,9 @@ config FRV
select HAVE_DEBUG_STACKOVERFLOW
select ARCH_NO_COHERENT_DMA_MMAP
 
+config CPU_BIG_ENDIAN
+   def_bool y
+
 config ZONE_DMA
bool
default y
diff --git a/arch/h8300/Kconfig b/arch/h8300/Kconfig
index 3ae8525..5380ac8 100644
--- a/arch/h8300/Kconfig
+++ b/arch/h8300/Kconfig
@@ -23,6 +23,9 @@ config H8300
select HAVE_ARCH_HASH
select CPU_NO_EFFICIENT_FFS
 
+config CPU_BIG_ENDIAN
+   def_bool y
+
 config RWSEM_GENERIC_SPINLOCK
def_bool y
 
diff --git a/arch/m68k/Kconfig b/arch/m68k/Kconfig
index d140206..029a58b 100644
--- a/arch/m68k/Kconfig
+++ b/arch/m68k/Kconfig
@@ -23,6 +23,9 @@ config M68K
select OLD_SIGSUSPEND3
select OLD_SIGACTION
 
+config CPU_BIG_ENDIAN
+   def_bool y
+
 config RWSEM_GENERIC_SPINLOCK
bool
default y
diff --git a/arch/openrisc/Kconfig b/arch/openrisc/Kconfig
index 1e95920..a0f2e4a 100644
--- a/arch/openrisc/Kconfig
+++ b/arch/openrisc/Kconfig
@@ -29,6 +29,9 @@ config OPENRISC
select CPU_NO_EFFICIENT_FFS if !OPENRISC_HAVE_INST_FF1
select NO_BOOTMEM
 
+config CPU_BIG_ENDIAN
+   def_bool y
+
 config MMU
def_bool y
 
diff --git a/arch/parisc/Kconfig b/arch/parisc/Kconfig
index 531da9e..dda1f55 100644
--- a/arch/parisc/Kconfig
+++ b/arch/parisc/Kconfig
@@ -47,6 +47,9 @@ config PARISC
  and later HP3000 series).  The PA-RISC Linux project home page is
  at .
 
+config CPU_BIG_ENDIAN
+   def_bool y
+
 config MMU
def_bool y
 
diff --git a/arch/sparc/Kconfig b/arch/sparc/Kconfig
index 908f019..0d9dc49 100644
--- a/arch/sparc/Kconfig
+++ b/arch/sparc/Kconfig
@@ -92,6 +92,9 @@ config ARCH_DEFCONFIG
 config ARCH_PROC_KCORE_TEXT
def_bool y
 
+config CPU_BIG_ENDIAN
+   def_bool y
+
 config ARCH_ATU
bool
default y if SPARC64
-- 
1.7.1

[PATCH v3 1/3] arch: Define CPU_BIG_ENDIAN for all fixed big endian archs

[Babu Moger]

While working on enabling queued rwlock on SPARC, found
this following code in include/asm-generic/qrwlock.h
which uses CONFIG_CPU_BIG_ENDIAN to clear a byte.

static inline u8 *__qrwlock_write_byte(struct qrwlock *lock)
 {
return (u8 *)lock + 3 * IS_BUILTIN(CONFIG_CPU_BIG_ENDIAN);
 }

Problem is many of the fixed big endian architectures don't define
CPU_BIG_ENDIAN and clears the wrong byte.

Define CPU_BIG_ENDIAN for all the fixed big endian architecture to fix it.

Also found few more references of this config parameter in
drivers/of/base.c
drivers/of/fdt.c
drivers/tty/serial/earlycon.c
drivers/tty/serial/serial_core.c
Be aware that this may cause regressions if someone has worked-around
problems in the above code already. Remove the work-around.

Here is our original discussion
https://lkml.org/lkml/2017/5/24/620

Signed-off-by: Babu Moger 
Suggested-by: Arnd Bergmann 
Acked-by: Geert Uytterhoeven 
Acked-by: David S. Miller 
Acked-by: Stafford Horne 
---
 arch/frv/Kconfig  |3 +++
 arch/h8300/Kconfig|3 +++
 arch/m68k/Kconfig |3 +++
 arch/openrisc/Kconfig |3 +++
 arch/parisc/Kconfig   |3 +++
 arch/sparc/Kconfig|3 +++
 6 files changed, 18 insertions(+), 0 deletions(-)

diff --git a/arch/frv/Kconfig b/arch/frv/Kconfig
index eefd9a4..1cce824 100644
--- a/arch/frv/Kconfig
+++ b/arch/frv/Kconfig
@@ -17,6 +17,9 @@ config FRV
select HAVE_DEBUG_STACKOVERFLOW
select ARCH_NO_COHERENT_DMA_MMAP
 
+config CPU_BIG_ENDIAN
+   def_bool y
+
 config ZONE_DMA
bool
default y
diff --git a/arch/h8300/Kconfig b/arch/h8300/Kconfig
index 3ae8525..5380ac8 100644
--- a/arch/h8300/Kconfig
+++ b/arch/h8300/Kconfig
@@ -23,6 +23,9 @@ config H8300
select HAVE_ARCH_HASH
select CPU_NO_EFFICIENT_FFS
 
+config CPU_BIG_ENDIAN
+   def_bool y
+
 config RWSEM_GENERIC_SPINLOCK
def_bool y
 
diff --git a/arch/m68k/Kconfig b/arch/m68k/Kconfig
index d140206..029a58b 100644
--- a/arch/m68k/Kconfig
+++ b/arch/m68k/Kconfig
@@ -23,6 +23,9 @@ config M68K
select OLD_SIGSUSPEND3
select OLD_SIGACTION
 
+config CPU_BIG_ENDIAN
+   def_bool y
+
 config RWSEM_GENERIC_SPINLOCK
bool
default y
diff --git a/arch/openrisc/Kconfig b/arch/openrisc/Kconfig
index 1e95920..a0f2e4a 100644
--- a/arch/openrisc/Kconfig
+++ b/arch/openrisc/Kconfig
@@ -29,6 +29,9 @@ config OPENRISC
select CPU_NO_EFFICIENT_FFS if !OPENRISC_HAVE_INST_FF1
select NO_BOOTMEM
 
+config CPU_BIG_ENDIAN
+   def_bool y
+
 config MMU
def_bool y
 
diff --git a/arch/parisc/Kconfig b/arch/parisc/Kconfig
index 531da9e..dda1f55 100644
--- a/arch/parisc/Kconfig
+++ b/arch/parisc/Kconfig
@@ -47,6 +47,9 @@ config PARISC
  and later HP3000 series).  The PA-RISC Linux project home page is
  at .
 
+config CPU_BIG_ENDIAN
+   def_bool y
+
 config MMU
def_bool y
 
diff --git a/arch/sparc/Kconfig b/arch/sparc/Kconfig
index 908f019..0d9dc49 100644
--- a/arch/sparc/Kconfig
+++ b/arch/sparc/Kconfig
@@ -92,6 +92,9 @@ config ARCH_DEFCONFIG
 config ARCH_PROC_KCORE_TEXT
def_bool y
 
+config CPU_BIG_ENDIAN
+   def_bool y
+
 config ARCH_ATU
bool
default y if SPARC64
-- 
1.7.1

[PATCH v3 0/3] Define CPU_BIG_ENDIAN or warn for inconsistencies

[Babu Moger]

Found this problem while enabling queued rwlock on SPARC.
The parameter CONFIG_CPU_BIG_ENDIAN is used to clear the
specific byte in qrwlock structure. Without this parameter,
we clear the wrong byte.
Here is the code in include/asm-generic/qrwlock.h

static inline u8 *__qrwlock_write_byte(struct qrwlock *lock)
  {
 return (u8 *)lock + 3 * IS_BUILTIN(CONFIG_CPU_BIG_ENDIAN);
  }

Also found few more references of this parameter in
drivers/of/base.c
drivers/of/fdt.c
drivers/tty/serial/earlycon.c
drivers/tty/serial/serial_core.c

Here is our previous discussion.
https://lkml.org/lkml/2017/5/24/620

Based on the discussion, it was decided to add CONFIG_CPU_BIG_ENDIAN
for all the fixed big endian architecture(frv, h8300, m68k, openrisc,
parisc and sparc). And warn if there are inconsistencies in this definition.

v2 -> v3:
 Added the choice statement for endianness selection for microblaze.
 Updated the Makefile for microblaze(Suggested by Arnd Bergmann) to
 properly compile for the correct format.
 Updated acks.

v1 -> v2:
 Updated the commit messages and acks.

Babu Moger (3):
  arch: Define CPU_BIG_ENDIAN for all fixed big endian archs
  arch/microblaze: Add choice for endianness and update Makefile
  include: warn for inconsistent endian config definition

 arch/frv/Kconfig|3 +++
 arch/h8300/Kconfig  |3 +++
 arch/m68k/Kconfig   |3 +++
 arch/microblaze/Kconfig |   16 
 arch/microblaze/Makefile|2 ++
 arch/openrisc/Kconfig   |3 +++
 arch/parisc/Kconfig |3 +++
 arch/sparc/Kconfig  |3 +++
 include/linux/byteorder/big_endian.h|4 
 include/linux/byteorder/little_endian.h |4 
 10 files changed, 44 insertions(+), 0 deletions(-)

[PATCH v3 2/3] arch/microblaze: Add choice for endianness and update Makefile

[Babu Moger]

microblaze architectures can be configured for either little or
big endian formats. Add a choice option for the user to select the
correct endian format(default to big endian).

Also update the Makefile so toolchain can compile for the format
it is configured for.

Signed-off-by: Babu Moger 
Signed-off-by: Arnd Bergmann 
---
 arch/microblaze/Kconfig  |   16 
 arch/microblaze/Makefile |2 ++
 2 files changed, 18 insertions(+), 0 deletions(-)

diff --git a/arch/microblaze/Kconfig b/arch/microblaze/Kconfig
index 85885a5..74aa5de 100644
--- a/arch/microblaze/Kconfig
+++ b/arch/microblaze/Kconfig
@@ -35,6 +35,22 @@ config MICROBLAZE
select VIRT_TO_BUS
select CPU_NO_EFFICIENT_FFS
 
+# Endianness selection
+choice
+   prompt "Endianness selection"
+   default CPU_BIG_ENDIAN
+   help
+ microblaze architectures can be configured for either little or
+ big endian formats. Be sure to select the appropriate mode.
+
+config CPU_BIG_ENDIAN
+   bool "Big endian"
+
+config CPU_LITTLE_ENDIAN
+   bool "Little endian"
+
+endchoice
+
 config SWAP
def_bool n
 
diff --git a/arch/microblaze/Makefile b/arch/microblaze/Makefile
index 740f2b8..1f6c486 100644
--- a/arch/microblaze/Makefile
+++ b/arch/microblaze/Makefile
@@ -35,6 +35,8 @@ endif
 CPUFLAGS-$(CONFIG_XILINX_MICROBLAZE0_USE_DIV) += -mno-xl-soft-div
 CPUFLAGS-$(CONFIG_XILINX_MICROBLAZE0_USE_BARREL) += -mxl-barrel-shift
 CPUFLAGS-$(CONFIG_XILINX_MICROBLAZE0_USE_PCMP_INSTR) += -mxl-pattern-compare
+CPUFLAGS-$(CONFIG_BIG_ENDIAN) += -mbig-endian
+CPUFLAGS-$(CONFIG_LITTLE_ENDIAN) += -mlittle-endian
 
 CPUFLAGS-1 += $(call cc-option,-mcpu=v$(CPU_VER))
 
-- 
1.7.1

[PATCH v3 3/3] include: warn for inconsistent endian config definition

[Babu Moger]

We have seen some generic code use config parameter CONFIG_CPU_BIG_ENDIAN
to decide the endianness.

Here are the few examples.
include/asm-generic/qrwlock.h
drivers/of/base.c
drivers/of/fdt.c
drivers/tty/serial/earlycon.c
drivers/tty/serial/serial_core.c

Display warning if CPU_BIG_ENDIAN is not defined on big endian
architecture and also warn if it defined on little endian architectures.

Here is our original discussion
https://lkml.org/lkml/2017/5/24/620

Signed-off-by: Babu Moger 
Suggested-by: Arnd Bergmann 
Acked-by: Geert Uytterhoeven 
---
 include/linux/byteorder/big_endian.h|4 
 include/linux/byteorder/little_endian.h |4 
 2 files changed, 8 insertions(+), 0 deletions(-)

diff --git a/include/linux/byteorder/big_endian.h 
b/include/linux/byteorder/big_endian.h
index 3920414..ffd2159 100644
--- a/include/linux/byteorder/big_endian.h
+++ b/include/linux/byteorder/big_endian.h
@@ -3,5 +3,9 @@
 
 #include 
 
+#ifndef CONFIG_CPU_BIG_ENDIAN
+#warning inconsistent configuration, needs CONFIG_CPU_BIG_ENDIAN
+#endif
+
 #include 
 #endif /* _LINUX_BYTEORDER_BIG_ENDIAN_H */
diff --git a/include/linux/byteorder/little_endian.h 
b/include/linux/byteorder/little_endian.h
index 0805737..ba910bb 100644
--- a/include/linux/byteorder/little_endian.h
+++ b/include/linux/byteorder/little_endian.h
@@ -3,5 +3,9 @@
 
 #include 
 
+#ifdef CONFIG_CPU_BIG_ENDIAN
+#warning inconsistent configuration, CONFIG_CPU_BIG_ENDIAN is set
+#endif
+
 #include 
 #endif /* _LINUX_BYTEORDER_LITTLE_ENDIAN_H */
-- 
1.7.1

[PATCH v3 0/3] Define CPU_BIG_ENDIAN or warn for inconsistencies

[Babu Moger]

Found this problem while enabling queued rwlock on SPARC.
The parameter CONFIG_CPU_BIG_ENDIAN is used to clear the
specific byte in qrwlock structure. Without this parameter,
we clear the wrong byte.
Here is the code in include/asm-generic/qrwlock.h

static inline u8 *__qrwlock_write_byte(struct qrwlock *lock)
  {
 return (u8 *)lock + 3 * IS_BUILTIN(CONFIG_CPU_BIG_ENDIAN);
  }

Also found few more references of this parameter in
drivers/of/base.c
drivers/of/fdt.c
drivers/tty/serial/earlycon.c
drivers/tty/serial/serial_core.c

Here is our previous discussion.
https://lkml.org/lkml/2017/5/24/620

Based on the discussion, it was decided to add CONFIG_CPU_BIG_ENDIAN
for all the fixed big endian architecture(frv, h8300, m68k, openrisc,
parisc and sparc). And warn if there are inconsistencies in this definition.

v2 -> v3:
 Added the choice statement for endianness selection for microblaze.
 Updated the Makefile for microblaze(Suggested by Arnd Bergmann) to
 properly compile for the correct format.
 Updated acks.

v1 -> v2:
 Updated the commit messages and acks.

Babu Moger (3):
  arch: Define CPU_BIG_ENDIAN for all fixed big endian archs
  arch/microblaze: Add choice for endianness and update Makefile
  include: warn for inconsistent endian config definition

 arch/frv/Kconfig|3 +++
 arch/h8300/Kconfig  |3 +++
 arch/m68k/Kconfig   |3 +++
 arch/microblaze/Kconfig |   16 
 arch/microblaze/Makefile|2 ++
 arch/openrisc/Kconfig   |3 +++
 arch/parisc/Kconfig |3 +++
 arch/sparc/Kconfig  |3 +++
 include/linux/byteorder/big_endian.h|4 
 include/linux/byteorder/little_endian.h |4 
 10 files changed, 44 insertions(+), 0 deletions(-)

[PATCH v3 2/3] arch/microblaze: Add choice for endianness and update Makefile

[Babu Moger]

microblaze architectures can be configured for either little or
big endian formats. Add a choice option for the user to select the
correct endian format(default to big endian).

Also update the Makefile so toolchain can compile for the format
it is configured for.

Signed-off-by: Babu Moger 
Signed-off-by: Arnd Bergmann 
---
 arch/microblaze/Kconfig  |   16 
 arch/microblaze/Makefile |2 ++
 2 files changed, 18 insertions(+), 0 deletions(-)

diff --git a/arch/microblaze/Kconfig b/arch/microblaze/Kconfig
index 85885a5..74aa5de 100644
--- a/arch/microblaze/Kconfig
+++ b/arch/microblaze/Kconfig
@@ -35,6 +35,22 @@ config MICROBLAZE
select VIRT_TO_BUS
select CPU_NO_EFFICIENT_FFS
 
+# Endianness selection
+choice
+   prompt "Endianness selection"
+   default CPU_BIG_ENDIAN
+   help
+ microblaze architectures can be configured for either little or
+ big endian formats. Be sure to select the appropriate mode.
+
+config CPU_BIG_ENDIAN
+   bool "Big endian"
+
+config CPU_LITTLE_ENDIAN
+   bool "Little endian"
+
+endchoice
+
 config SWAP
def_bool n
 
diff --git a/arch/microblaze/Makefile b/arch/microblaze/Makefile
index 740f2b8..1f6c486 100644
--- a/arch/microblaze/Makefile
+++ b/arch/microblaze/Makefile
@@ -35,6 +35,8 @@ endif
 CPUFLAGS-$(CONFIG_XILINX_MICROBLAZE0_USE_DIV) += -mno-xl-soft-div
 CPUFLAGS-$(CONFIG_XILINX_MICROBLAZE0_USE_BARREL) += -mxl-barrel-shift
 CPUFLAGS-$(CONFIG_XILINX_MICROBLAZE0_USE_PCMP_INSTR) += -mxl-pattern-compare
+CPUFLAGS-$(CONFIG_BIG_ENDIAN) += -mbig-endian
+CPUFLAGS-$(CONFIG_LITTLE_ENDIAN) += -mlittle-endian
 
 CPUFLAGS-1 += $(call cc-option,-mcpu=v$(CPU_VER))
 
-- 
1.7.1

[PATCH v3 3/3] include: warn for inconsistent endian config definition

[Babu Moger]

We have seen some generic code use config parameter CONFIG_CPU_BIG_ENDIAN
to decide the endianness.

Here are the few examples.
include/asm-generic/qrwlock.h
drivers/of/base.c
drivers/of/fdt.c
drivers/tty/serial/earlycon.c
drivers/tty/serial/serial_core.c

Display warning if CPU_BIG_ENDIAN is not defined on big endian
architecture and also warn if it defined on little endian architectures.

Here is our original discussion
https://lkml.org/lkml/2017/5/24/620

Signed-off-by: Babu Moger 
Suggested-by: Arnd Bergmann 
Acked-by: Geert Uytterhoeven 
---
 include/linux/byteorder/big_endian.h|4 
 include/linux/byteorder/little_endian.h |4 
 2 files changed, 8 insertions(+), 0 deletions(-)

diff --git a/include/linux/byteorder/big_endian.h 
b/include/linux/byteorder/big_endian.h
index 3920414..ffd2159 100644
--- a/include/linux/byteorder/big_endian.h
+++ b/include/linux/byteorder/big_endian.h
@@ -3,5 +3,9 @@
 
 #include 
 
+#ifndef CONFIG_CPU_BIG_ENDIAN
+#warning inconsistent configuration, needs CONFIG_CPU_BIG_ENDIAN
+#endif
+
 #include 
 #endif /* _LINUX_BYTEORDER_BIG_ENDIAN_H */
diff --git a/include/linux/byteorder/little_endian.h 
b/include/linux/byteorder/little_endian.h
index 0805737..ba910bb 100644
--- a/include/linux/byteorder/little_endian.h
+++ b/include/linux/byteorder/little_endian.h
@@ -3,5 +3,9 @@
 
 #include 
 
+#ifdef CONFIG_CPU_BIG_ENDIAN
+#warning inconsistent configuration, CONFIG_CPU_BIG_ENDIAN is set
+#endif
+
 #include 
 #endif /* _LINUX_BYTEORDER_LITTLE_ENDIAN_H */
-- 
1.7.1

Re: [RESEND x3][PATCH v4] arm64: dts: hi6220: Add k3-dma and i2s/hdmi audio support

[Mark Brown]

On Mon, Jun 12, 2017 at 01:52:46PM -0700, John Stultz wrote:

> + sound {
> + compatible = "simple-audio-card";
> + simple-audio-card,name = "hikey-hdmi";

Now the graph card has been merged it's probably a good idea to be using
that, it's generally a better idea for pretty much all use cases.


signature.asc
Description: PGP signature

Re: [RESEND x3][PATCH v4] arm64: dts: hi6220: Add k3-dma and i2s/hdmi audio support

[Mark Brown]

On Mon, Jun 12, 2017 at 01:52:46PM -0700, John Stultz wrote:

> + sound {
> + compatible = "simple-audio-card";
> + simple-audio-card,name = "hikey-hdmi";

Now the graph card has been merged it's probably a good idea to be using
that, it's generally a better idea for pretty much all use cases.


signature.asc
Description: PGP signature

[RELEASE] LTTng modules 2.10.0-rc2, 2.9.3, 2.8.6

[Mathieu Desnoyers]

The LTTng modules provide Linux kernel tracing capability to the LTTng
tracer toolset.

Those versions are bugfixes in the currently maintained stable
branches of lttng-modules. They mainly contain:

- Fix for the "PID tracker" feature, which should track pgid, which
  corresponds to the notion of process ID in user-space. It is now
  in sync with the feature in the UST tracing domain (application
  tracing),
- Adding a "flush empty" ioctl for snapshots fixes cases where the
  Babeltrace lttng-live reader has issues keeping up with a steady
  stream of useless empty packets. This "flush empty" ioctl is
  introduced in backwards and forwards compatible ways, to ensure
  smooth upgrade within the stable versions of lttng-tools and
  lttng-modules.

Those releases also add support for 4.12 release candidate kernels.

Enjoy!

Mathieu

Project website: http://lttng.org
Documentation: http://lttng.org/docs
Download link: http://lttng.org/download

Detailed change logs:

2017-06-12 (National Peanut Butter Cookie Day) LTTng modules 2.10.0-rc2
* Fix: pid tracker should track "pgid"
* Fix: Build ftrace probe on kernels prior to 4.12
* Fix: update ftrace probe for kernel 4.12
* Fix: update block instrumentation for kernel 4.12
* Fix: Add support for 4.9.27-rt18 kernel
* Fix: update btrfs instrumentation for kernel 4.12
* Fix: update ringbuffer for kernel 4.12
* Fix: update sched instrumentation for kernel 4.12
* Fix: ext3 was completely removed from the kernel in v4.3
* Fix: NULL pointer dereference of THIS_MODULE with built-in modules
* Fix: add "flush empty" ioctl for stream intersection
* Revert "Fix: flush empty packets on snapshot channel"
* Revert "Fix: don't perform extra flush on metadata channel"

2017-06-12 (National Peanut Butter Cookie Day) LTTng modules 2.9.3
* Fix: pid tracker should track "pgid"
* Fix: Build ftrace probe on kernels prior to 4.12
* Fix: update ftrace probe for kernel 4.12
* Fix: update block instrumentation for kernel 4.12
* Fix: Add support for 4.9.27-rt18 kernel
* Fix: update btrfs instrumentation for kernel 4.12
* Fix: update ringbuffer for kernel 4.12
* Fix: update sched instrumentation for kernel 4.12
* Fix: ext3 was completely removed from the kernel in v4.3
* Fix: NULL pointer dereference of THIS_MODULE with built-in modules
* Fix: add "flush empty" ioctl for stream intersection
* Revert "Fix: flush empty packets on snapshot channel"
* Revert "Fix: don't perform extra flush on metadata channel"
* Fix: remove CONFIG_KALLSYMS_ALL warning on clean

2017-06-12 (National Peanut Butter Cookie Day) LTTng modules 2.8.6
* Fix: pid tracker should track "pgid"
* Fix: Build ftrace probe on kernels prior to 4.12
* Fix: update ftrace probe for kernel 4.12
* Fix: update block instrumentation for kernel 4.12
* Fix: Add support for 4.9.27-rt18 kernel
* Fix: update btrfs instrumentation for kernel 4.12
* Fix: update ringbuffer for kernel 4.12
* Fix: update sched instrumentation for kernel 4.12
* Fix: ext3 was completely removed from the kernel in v4.3
* Fix: NULL pointer dereference of THIS_MODULE with built-in modules
* Fix: add "flush empty" ioctl for stream intersection
* Revert "Fix: flush empty packets on snapshot channel"
* Revert "Fix: don't perform extra flush on metadata channel"
* Fix: remove CONFIG_KALLSYMS_ALL warning on clean

-- 
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com

[RELEASE] LTTng modules 2.10.0-rc2, 2.9.3, 2.8.6

[Mathieu Desnoyers]

The LTTng modules provide Linux kernel tracing capability to the LTTng
tracer toolset.

Those versions are bugfixes in the currently maintained stable
branches of lttng-modules. They mainly contain:

- Fix for the "PID tracker" feature, which should track pgid, which
  corresponds to the notion of process ID in user-space. It is now
  in sync with the feature in the UST tracing domain (application
  tracing),
- Adding a "flush empty" ioctl for snapshots fixes cases where the
  Babeltrace lttng-live reader has issues keeping up with a steady
  stream of useless empty packets. This "flush empty" ioctl is
  introduced in backwards and forwards compatible ways, to ensure
  smooth upgrade within the stable versions of lttng-tools and
  lttng-modules.

Those releases also add support for 4.12 release candidate kernels.

Enjoy!

Mathieu

Project website: http://lttng.org
Documentation: http://lttng.org/docs
Download link: http://lttng.org/download

Detailed change logs:

2017-06-12 (National Peanut Butter Cookie Day) LTTng modules 2.10.0-rc2
* Fix: pid tracker should track "pgid"
* Fix: Build ftrace probe on kernels prior to 4.12
* Fix: update ftrace probe for kernel 4.12
* Fix: update block instrumentation for kernel 4.12
* Fix: Add support for 4.9.27-rt18 kernel
* Fix: update btrfs instrumentation for kernel 4.12
* Fix: update ringbuffer for kernel 4.12
* Fix: update sched instrumentation for kernel 4.12
* Fix: ext3 was completely removed from the kernel in v4.3
* Fix: NULL pointer dereference of THIS_MODULE with built-in modules
* Fix: add "flush empty" ioctl for stream intersection
* Revert "Fix: flush empty packets on snapshot channel"
* Revert "Fix: don't perform extra flush on metadata channel"

2017-06-12 (National Peanut Butter Cookie Day) LTTng modules 2.9.3
* Fix: pid tracker should track "pgid"
* Fix: Build ftrace probe on kernels prior to 4.12
* Fix: update ftrace probe for kernel 4.12
* Fix: update block instrumentation for kernel 4.12
* Fix: Add support for 4.9.27-rt18 kernel
* Fix: update btrfs instrumentation for kernel 4.12
* Fix: update ringbuffer for kernel 4.12
* Fix: update sched instrumentation for kernel 4.12
* Fix: ext3 was completely removed from the kernel in v4.3
* Fix: NULL pointer dereference of THIS_MODULE with built-in modules
* Fix: add "flush empty" ioctl for stream intersection
* Revert "Fix: flush empty packets on snapshot channel"
* Revert "Fix: don't perform extra flush on metadata channel"
* Fix: remove CONFIG_KALLSYMS_ALL warning on clean

2017-06-12 (National Peanut Butter Cookie Day) LTTng modules 2.8.6
* Fix: pid tracker should track "pgid"
* Fix: Build ftrace probe on kernels prior to 4.12
* Fix: update ftrace probe for kernel 4.12
* Fix: update block instrumentation for kernel 4.12
* Fix: Add support for 4.9.27-rt18 kernel
* Fix: update btrfs instrumentation for kernel 4.12
* Fix: update ringbuffer for kernel 4.12
* Fix: update sched instrumentation for kernel 4.12
* Fix: ext3 was completely removed from the kernel in v4.3
* Fix: NULL pointer dereference of THIS_MODULE with built-in modules
* Fix: add "flush empty" ioctl for stream intersection
* Revert "Fix: flush empty packets on snapshot channel"
* Revert "Fix: don't perform extra flush on metadata channel"
* Fix: remove CONFIG_KALLSYMS_ALL warning on clean

-- 
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com

Re: [PATCH v3 06/18] xen/pvcalls: handle commands from the frontend

[Boris Ostrovsky]

> +
>  static void pvcalls_back_work(struct work_struct *work)
>  {
> + struct pvcalls_fedata *priv = container_of(work,
> + struct pvcalls_fedata, register_work);
> + int notify, notify_all = 0, more = 1;
> + struct xen_pvcalls_request req;
> + struct xenbus_device *dev = priv->dev;
> +
> + while (more) {
> + while (RING_HAS_UNCONSUMED_REQUESTS(>ring)) {
> + RING_COPY_REQUEST(>ring,
> +   priv->ring.req_cons++,
> +   );
> +
> + if (!pvcalls_back_handle_cmd(dev, )) {
> + RING_PUSH_RESPONSES_AND_CHECK_NOTIFY(
> + >ring, notify);
> + notify_all += notify;
> + }
> + }
> +
> + if (notify_all)
> + notify_remote_via_irq(priv->irq);
> +
> + RING_FINAL_CHECK_FOR_REQUESTS(>ring, more);
> + }
>  }
>  
>  static irqreturn_t pvcalls_back_event(int irq, void *dev_id)
>  {
> + struct xenbus_device *dev = dev_id;
> + struct pvcalls_fedata *priv = NULL;
> +
> + if (dev == NULL)
> + return IRQ_HANDLED;
> +
> + priv = dev_get_drvdata(>dev);
> + if (priv == NULL)
> + return IRQ_HANDLED;
> +
> + /*
> +  * TODO: a small theoretical race exists if we try to queue work
> +  * after pvcalls_back_work checked for final requests and before
> +  * it returns. The queuing will fail, and pvcalls_back_work
> +  * won't do the work because it is about to return. In that
> +  * case, we lose the notification.
> +  */
> + queue_work(priv->wq, >register_work);

Would queuing delayed work (if queue_work() failed) help? And canceling
it on next invocation of pvcalls_back_event()?

-boris

Re: [PATCH 4.11 000/150] 4.11.5-stable review

[Guenter Roeck]

On Mon, Jun 12, 2017 at 05:23:27PM +0200, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.11.5 release.
> There are 150 patches in this series, all will be posted as a response
> to this one.  If anyone has any issues with these being applied, please
> let me know.
> 
> Responses should be made by Wed Jun 14 15:24:44 UTC 2017.
> Anything received after that time might be too late.
> 

Build results:
total: 145 pass: 145 fail: 0
Qemu test results:
total: 122 pass: 113 fail: 9
Failed tests:
mips:malta_defconfig:nosmp
mips:malta_defconfig:smp
mips64:malta_defconfig:nosmp
mips64:malta_defconfig:smp
mipsel:24Kf:malta_defconfig:nosmp
mipsel:24Kf:malta_defconfig:smp
mipsel64:malta_defconfig:nosmp
mipsel64:malta_defconfig:smp
mipsel64:fuloong2e_defconfig:fulong2e

All mips builds hang during boot. Bisect points to commit 9b99d86800f ("kthread:
Fix use-after-free if kthread fork fails"). The problem was also seen upstream,
and has been fixed with commit b0f5a8f32e ("kthread: fix boot hang (regression)
on MIPS/OpenRISC"). The problem is gone after this patch is applied.

Guenter

Re: [PATCH v3 06/18] xen/pvcalls: handle commands from the frontend

[Boris Ostrovsky]

> +
>  static void pvcalls_back_work(struct work_struct *work)
>  {
> + struct pvcalls_fedata *priv = container_of(work,
> + struct pvcalls_fedata, register_work);
> + int notify, notify_all = 0, more = 1;
> + struct xen_pvcalls_request req;
> + struct xenbus_device *dev = priv->dev;
> +
> + while (more) {
> + while (RING_HAS_UNCONSUMED_REQUESTS(>ring)) {
> + RING_COPY_REQUEST(>ring,
> +   priv->ring.req_cons++,
> +   );
> +
> + if (!pvcalls_back_handle_cmd(dev, )) {
> + RING_PUSH_RESPONSES_AND_CHECK_NOTIFY(
> + >ring, notify);
> + notify_all += notify;
> + }
> + }
> +
> + if (notify_all)
> + notify_remote_via_irq(priv->irq);
> +
> + RING_FINAL_CHECK_FOR_REQUESTS(>ring, more);
> + }
>  }
>  
>  static irqreturn_t pvcalls_back_event(int irq, void *dev_id)
>  {
> + struct xenbus_device *dev = dev_id;
> + struct pvcalls_fedata *priv = NULL;
> +
> + if (dev == NULL)
> + return IRQ_HANDLED;
> +
> + priv = dev_get_drvdata(>dev);
> + if (priv == NULL)
> + return IRQ_HANDLED;
> +
> + /*
> +  * TODO: a small theoretical race exists if we try to queue work
> +  * after pvcalls_back_work checked for final requests and before
> +  * it returns. The queuing will fail, and pvcalls_back_work
> +  * won't do the work because it is about to return. In that
> +  * case, we lose the notification.
> +  */
> + queue_work(priv->wq, >register_work);

Would queuing delayed work (if queue_work() failed) help? And canceling
it on next invocation of pvcalls_back_event()?

-boris

Re: [PATCH 4.11 000/150] 4.11.5-stable review

[Guenter Roeck]

On Mon, Jun 12, 2017 at 05:23:27PM +0200, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.11.5 release.
> There are 150 patches in this series, all will be posted as a response
> to this one.  If anyone has any issues with these being applied, please
> let me know.
> 
> Responses should be made by Wed Jun 14 15:24:44 UTC 2017.
> Anything received after that time might be too late.
> 

Build results:
total: 145 pass: 145 fail: 0
Qemu test results:
total: 122 pass: 113 fail: 9
Failed tests:
mips:malta_defconfig:nosmp
mips:malta_defconfig:smp
mips64:malta_defconfig:nosmp
mips64:malta_defconfig:smp
mipsel:24Kf:malta_defconfig:nosmp
mipsel:24Kf:malta_defconfig:smp
mipsel64:malta_defconfig:nosmp
mipsel64:malta_defconfig:smp
mipsel64:fuloong2e_defconfig:fulong2e

All mips builds hang during boot. Bisect points to commit 9b99d86800f ("kthread:
Fix use-after-free if kthread fork fails"). The problem was also seen upstream,
and has been fixed with commit b0f5a8f32e ("kthread: fix boot hang (regression)
on MIPS/OpenRISC"). The problem is gone after this patch is applied.

Guenter

[PATCH] nfc: nci: fix potential NULL pointer dereference

[Gustavo A. R. Silva]

NULL check at line 76: if (conn_info) {, implies that pointer conn_info
might be NULL, but this pointer is being previously dereferenced,
which might cause a NULL pointer dereference.

Add NULL check before dereferencing pointer conn_info in order to
avoid a potential NULL pointer dereference.

Addresses-Coverity-ID: 1362349
Signed-off-by: Gustavo A. R. Silva 
---
 net/nfc/nci/core.c | 11 +--
 1 file changed, 5 insertions(+), 6 deletions(-)

diff --git a/net/nfc/nci/core.c b/net/nfc/nci/core.c
index 61fff42..d2198ce 100644
--- a/net/nfc/nci/core.c
+++ b/net/nfc/nci/core.c
@@ -70,14 +70,13 @@ int nci_get_conn_info_by_dest_type_params(struct nci_dev 
*ndev, u8 dest_type,
struct nci_conn_info *conn_info;
 
list_for_each_entry(conn_info, >conn_info_list, list) {
-   if (conn_info->dest_type == dest_type) {
+   if (conn_info && conn_info->dest_type == dest_type) {
if (!params)
return conn_info->conn_id;
-   if (conn_info) {
-   if (params->id == conn_info->dest_params->id &&
-   params->protocol == 
conn_info->dest_params->protocol)
-   return conn_info->conn_id;
-   }
+
+   if (params->id == conn_info->dest_params->id &&
+   params->protocol == 
conn_info->dest_params->protocol)
+   return conn_info->conn_id;
}
}
 
-- 
2.5.0

[PATCH] nfc: nci: fix potential NULL pointer dereference

[Gustavo A. R. Silva]

NULL check at line 76: if (conn_info) {, implies that pointer conn_info
might be NULL, but this pointer is being previously dereferenced,
which might cause a NULL pointer dereference.

Add NULL check before dereferencing pointer conn_info in order to
avoid a potential NULL pointer dereference.

Addresses-Coverity-ID: 1362349
Signed-off-by: Gustavo A. R. Silva 
---
 net/nfc/nci/core.c | 11 +--
 1 file changed, 5 insertions(+), 6 deletions(-)

diff --git a/net/nfc/nci/core.c b/net/nfc/nci/core.c
index 61fff42..d2198ce 100644
--- a/net/nfc/nci/core.c
+++ b/net/nfc/nci/core.c
@@ -70,14 +70,13 @@ int nci_get_conn_info_by_dest_type_params(struct nci_dev 
*ndev, u8 dest_type,
struct nci_conn_info *conn_info;
 
list_for_each_entry(conn_info, >conn_info_list, list) {
-   if (conn_info->dest_type == dest_type) {
+   if (conn_info && conn_info->dest_type == dest_type) {
if (!params)
return conn_info->conn_id;
-   if (conn_info) {
-   if (params->id == conn_info->dest_params->id &&
-   params->protocol == 
conn_info->dest_params->protocol)
-   return conn_info->conn_id;
-   }
+
+   if (params->id == conn_info->dest_params->id &&
+   params->protocol == 
conn_info->dest_params->protocol)
+   return conn_info->conn_id;
}
}
 
-- 
2.5.0

Re: [tip:timers/core] posix-timers: Zero out oldval itimerspec

[Thomas Gleixner]

On Mon, 12 Jun 2017, Andrei Vagin wrote:
> > diff --git a/kernel/time/posix-timers.c b/kernel/time/posix-timers.c
> > index b53a0b5..88517dc 100644
> > --- a/kernel/time/posix-timers.c
> > +++ b/kernel/time/posix-timers.c
> > @@ -828,6 +828,8 @@ SYSCALL_DEFINE4(timer_settime, timer_t, timer_id, int, 
> > flags,
> > if (!timespec64_valid(_spec64.it_interval) ||
> > !timespec64_valid(_spec64.it_value))
> > return -EINVAL;
> > +   if (rtn)
> > +   memset(rtn, 0, sizeof(*rtn));
> 
> Maybe we need to call memset after "retry:"?

That would be counter productive.

> common_timer_get() is called at the begining of common_timer_set(), then
> common_timer_set() can return TIMER_RETRY. common_timer_get() will be
> called again and some fields of rtn which have been touched first time
> will not be touched.
> 
> At the end, rtn will contain data from two executions of
> common_timer_get().

No. See the full code sequence:

retry:
timr = lock_timer(timer_id, );
if (!timr)
return -EINVAL;

kc = clockid_to_kclock(timr->it_clock);
if (WARN_ON_ONCE(!kc || !kc->timer_set))
error = -EINVAL;
else
error = kc->timer_set(timr, flags, _spec64, rtn);

unlock_timer(timr, flag);
if (error == TIMER_RETRY) {
rtn = NULL; // We already got the old time...
goto retry;
}

If you clear it after retry, you'll get all zeros in the retry case. Not
what you really want.

Thanks,

tglx

Re: [tip:timers/core] posix-timers: Zero out oldval itimerspec

[Thomas Gleixner]

On Mon, 12 Jun 2017, Andrei Vagin wrote:
> > diff --git a/kernel/time/posix-timers.c b/kernel/time/posix-timers.c
> > index b53a0b5..88517dc 100644
> > --- a/kernel/time/posix-timers.c
> > +++ b/kernel/time/posix-timers.c
> > @@ -828,6 +828,8 @@ SYSCALL_DEFINE4(timer_settime, timer_t, timer_id, int, 
> > flags,
> > if (!timespec64_valid(_spec64.it_interval) ||
> > !timespec64_valid(_spec64.it_value))
> > return -EINVAL;
> > +   if (rtn)
> > +   memset(rtn, 0, sizeof(*rtn));
> 
> Maybe we need to call memset after "retry:"?

That would be counter productive.

> common_timer_get() is called at the begining of common_timer_set(), then
> common_timer_set() can return TIMER_RETRY. common_timer_get() will be
> called again and some fields of rtn which have been touched first time
> will not be touched.
> 
> At the end, rtn will contain data from two executions of
> common_timer_get().

No. See the full code sequence:

retry:
timr = lock_timer(timer_id, );
if (!timr)
return -EINVAL;

kc = clockid_to_kclock(timr->it_clock);
if (WARN_ON_ONCE(!kc || !kc->timer_set))
error = -EINVAL;
else
error = kc->timer_set(timr, flags, _spec64, rtn);

unlock_timer(timr, flag);
if (error == TIMER_RETRY) {
rtn = NULL; // We already got the old time...
goto retry;
}

If you clear it after retry, you'll get all zeros in the retry case. Not
what you really want.

Thanks,

tglx

Re: [PATCH] PCI: Add Intel XXV710 to broken INTx masking quirk

[Bjorn Helgaas]

On Wed, Jun 07, 2017 at 01:00:48PM -0600, Alex Williamson wrote:
> Just like the other XL710 and X710 variants, the XXV710 device IDs
> appear to have the same hardware bug, the status register doesn't
> report pending interrupts resulting in "irq xx: nobody cared..."
> errors from the spurious interrupt handler when we try to use it
> with device assignment.
> 
> Reported-by: Stefan Assmann 
> Signed-off-by: Alex Williamson 
> Cc: Jesse Brandeburg 

Applied with Jesse's ack to pci/virtualization for v4.13, thanks!

> ---
>  drivers/pci/quirks.c |4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
> index 16e6cd86ad71..aa1c9e65f562 100644
> --- a/drivers/pci/quirks.c
> +++ b/drivers/pci/quirks.c
> @@ -3236,6 +3236,10 @@ static void quirk_broken_intx_masking(struct pci_dev 
> *dev)
>   quirk_broken_intx_masking);
>  DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, 0x1589,
>   quirk_broken_intx_masking);
> +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, 0x158a,
> + quirk_broken_intx_masking);
> +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, 0x158b,
> + quirk_broken_intx_masking);
>  DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, 0x37d0,
>   quirk_broken_intx_masking);
>  DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, 0x37d1,
> 

Re: [PATCH] PCI: Add Intel XXV710 to broken INTx masking quirk

[Bjorn Helgaas]

On Wed, Jun 07, 2017 at 01:00:48PM -0600, Alex Williamson wrote:
> Just like the other XL710 and X710 variants, the XXV710 device IDs
> appear to have the same hardware bug, the status register doesn't
> report pending interrupts resulting in "irq xx: nobody cared..."
> errors from the spurious interrupt handler when we try to use it
> with device assignment.
> 
> Reported-by: Stefan Assmann 
> Signed-off-by: Alex Williamson 
> Cc: Jesse Brandeburg 

Applied with Jesse's ack to pci/virtualization for v4.13, thanks!

> ---
>  drivers/pci/quirks.c |4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
> index 16e6cd86ad71..aa1c9e65f562 100644
> --- a/drivers/pci/quirks.c
> +++ b/drivers/pci/quirks.c
> @@ -3236,6 +3236,10 @@ static void quirk_broken_intx_masking(struct pci_dev 
> *dev)
>   quirk_broken_intx_masking);
>  DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, 0x1589,
>   quirk_broken_intx_masking);
> +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, 0x158a,
> + quirk_broken_intx_masking);
> +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, 0x158b,
> + quirk_broken_intx_masking);
>  DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, 0x37d0,
>   quirk_broken_intx_masking);
>  DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, 0x37d1,
> 

Re: [PATCH tip/core/rcu 07/13] rcu: Add smp_mb__after_atomic() to sync_exp_work_done()

[Paul E. McKenney]

On Mon, Jun 12, 2017 at 04:51:43PM +0200, Dmitry Vyukov wrote:
> On Sat, Jun 10, 2017 at 12:56 AM, Paul E. McKenney
>  wrote:
> >> > > > +/**
> >> > > > + * spin_is_locked - Conditionally interpose after prior critical 
> >> > > > sections
> >> > > > + * @lock: the spinlock whose critical sections are to be interposed.
> >> > > > + *
> >> > > > + * Semantically this is equivalent to a spin_trylock(), and, if
> >> > > > + * the spin_trylock() succeeds, immediately followed by a (mythical)
> >> > > > + * spin_unlock_relaxed().  The return value from spin_trylock() is 
> >> > > > returned
> >> > > > + * by spin_is_locked().  Note that all current architectures have 
> >> > > > extremely
> >> > > > + * efficient implementations in which the spin_is_locked() does not 
> >> > > > even
> >> > > > + * write to the lock variable.
> >> > > > + *
> >> > > > + * A successful spin_is_locked() primitive in some sense "takes its 
> >> > > > place"
> >> > > > + * after some critical section for the lock in question.  Any 
> >> > > > accesses
> >> > > > + * following a successful spin_is_locked() call will therefore 
> >> > > > happen
> >> > > > + * after any accesses by any of the preceding critical section for 
> >> > > > that
> >> > > > + * same lock.  Note however, that spin_is_locked() provides 
> >> > > > absolutely no
> >> > > > + * ordering guarantees for code preceding the call to that 
> >> > > > spin_is_locked().
> >> > > > + */
> >> > > >  static __always_inline int spin_is_locked(spinlock_t *lock)
> >> > > >  {
> >> > > > return raw_spin_is_locked(>rlock);
> >> > >
> >> > > I'm current confused on this one. The case listed in the qspinlock code
> >> > > doesn't appear to exist in the kernel anymore (or at least, I'm having
> >> > > trouble finding it).
> >> > >
> >> > > That said, I'm also not sure spin_is_locked() provides an acquire, as
> >> > > that comment has an explicit smp_acquire__after_ctrl_dep();
> >> >
> >> > OK, I have dropped this portion of the patch for the moment.
> >> >
> >> > Going forward, exactly what semantics do you believe spin_is_locked()
> >> > provides?
> >> >
> >> > Do any of the current implementations need to change to provide the
> >> > semantics expected by the various use cases?
> >>
> >> I don't have anything other than the comment I wrote back then. I would
> >> have to go audit all spin_is_locked() implementations and users (again).
> >
> > And Andrea (CCed) and I did a review of the v4.11 uses of
> > spin_is_locked(), and none of the current uses requires any particular
> > ordering.
> >
> > There is one very strange use of spin_is_locked() in 
> > __fnic_set_state_flags()
> > in drivers/scsi/fnic/fnic_scsi.c.  This code checks spin_is_locked(),
> > and then acquires the lock only if it wasn't held.  I am having a very
> > hard time imagining a situation where this would do something useful.
> > My guess is that the author thought that spin_is_locked() meant that
> > the current CPU holds the lock, when it instead means that some CPU
> > (possibly the current one, possibly not) holds the lock.
> >
> > Adding the FNIC guys on CC so that they can enlighten me.

And if my guess is correct, the usual fix is to use a variable to track
which CPU is holding the lock, with -1 indicating that no one holds it.
Then the spin_is_locked() check becomes a test to see if the value of
this variable is equal to the ID of the current CPU, but with preemption
disabled across the test.  If this makes no sense, let me know, and I
can supply a prototype patch.

> > Ignoring the FNIC use case for the moment, anyone believe that
> > spin_is_locked() needs to provide any ordering guarantees?
> 
> Not providing any ordering guarantees for spin_is_locked() sounds good to me.
> Restricting all types of mutexes/locks to the simple canonical use
> case (protecting a critical section of code) makes it easier to reason
> about code, enables a bunch of possible static/dynamic correctness
> checking and reliefs lock/unlock function from providing unnecessary
> ordering (i.e. acquire in spin_is_locked() pairing with release in
> spin_lock()).
> Tricky uses of is_locked and try_lock can resort to atomic operations
> (or maybe be removed).

One vote in favor of dropping ordering guarantees.  Any objections?

Thanx, Paul

Re: [PATCH tip/core/rcu 07/13] rcu: Add smp_mb__after_atomic() to sync_exp_work_done()

[Paul E. McKenney]

On Mon, Jun 12, 2017 at 04:51:43PM +0200, Dmitry Vyukov wrote:
> On Sat, Jun 10, 2017 at 12:56 AM, Paul E. McKenney
>  wrote:
> >> > > > +/**
> >> > > > + * spin_is_locked - Conditionally interpose after prior critical 
> >> > > > sections
> >> > > > + * @lock: the spinlock whose critical sections are to be interposed.
> >> > > > + *
> >> > > > + * Semantically this is equivalent to a spin_trylock(), and, if
> >> > > > + * the spin_trylock() succeeds, immediately followed by a (mythical)
> >> > > > + * spin_unlock_relaxed().  The return value from spin_trylock() is 
> >> > > > returned
> >> > > > + * by spin_is_locked().  Note that all current architectures have 
> >> > > > extremely
> >> > > > + * efficient implementations in which the spin_is_locked() does not 
> >> > > > even
> >> > > > + * write to the lock variable.
> >> > > > + *
> >> > > > + * A successful spin_is_locked() primitive in some sense "takes its 
> >> > > > place"
> >> > > > + * after some critical section for the lock in question.  Any 
> >> > > > accesses
> >> > > > + * following a successful spin_is_locked() call will therefore 
> >> > > > happen
> >> > > > + * after any accesses by any of the preceding critical section for 
> >> > > > that
> >> > > > + * same lock.  Note however, that spin_is_locked() provides 
> >> > > > absolutely no
> >> > > > + * ordering guarantees for code preceding the call to that 
> >> > > > spin_is_locked().
> >> > > > + */
> >> > > >  static __always_inline int spin_is_locked(spinlock_t *lock)
> >> > > >  {
> >> > > > return raw_spin_is_locked(>rlock);
> >> > >
> >> > > I'm current confused on this one. The case listed in the qspinlock code
> >> > > doesn't appear to exist in the kernel anymore (or at least, I'm having
> >> > > trouble finding it).
> >> > >
> >> > > That said, I'm also not sure spin_is_locked() provides an acquire, as
> >> > > that comment has an explicit smp_acquire__after_ctrl_dep();
> >> >
> >> > OK, I have dropped this portion of the patch for the moment.
> >> >
> >> > Going forward, exactly what semantics do you believe spin_is_locked()
> >> > provides?
> >> >
> >> > Do any of the current implementations need to change to provide the
> >> > semantics expected by the various use cases?
> >>
> >> I don't have anything other than the comment I wrote back then. I would
> >> have to go audit all spin_is_locked() implementations and users (again).
> >
> > And Andrea (CCed) and I did a review of the v4.11 uses of
> > spin_is_locked(), and none of the current uses requires any particular
> > ordering.
> >
> > There is one very strange use of spin_is_locked() in 
> > __fnic_set_state_flags()
> > in drivers/scsi/fnic/fnic_scsi.c.  This code checks spin_is_locked(),
> > and then acquires the lock only if it wasn't held.  I am having a very
> > hard time imagining a situation where this would do something useful.
> > My guess is that the author thought that spin_is_locked() meant that
> > the current CPU holds the lock, when it instead means that some CPU
> > (possibly the current one, possibly not) holds the lock.
> >
> > Adding the FNIC guys on CC so that they can enlighten me.

And if my guess is correct, the usual fix is to use a variable to track
which CPU is holding the lock, with -1 indicating that no one holds it.
Then the spin_is_locked() check becomes a test to see if the value of
this variable is equal to the ID of the current CPU, but with preemption
disabled across the test.  If this makes no sense, let me know, and I
can supply a prototype patch.

> > Ignoring the FNIC use case for the moment, anyone believe that
> > spin_is_locked() needs to provide any ordering guarantees?
> 
> Not providing any ordering guarantees for spin_is_locked() sounds good to me.
> Restricting all types of mutexes/locks to the simple canonical use
> case (protecting a critical section of code) makes it easier to reason
> about code, enables a bunch of possible static/dynamic correctness
> checking and reliefs lock/unlock function from providing unnecessary
> ordering (i.e. acquire in spin_is_locked() pairing with release in
> spin_lock()).
> Tricky uses of is_locked and try_lock can resort to atomic operations
> (or maybe be removed).

One vote in favor of dropping ordering guarantees.  Any objections?

Thanx, Paul

Re: [PATCH 4.9 000/119] 4.9.32-stable review

[Guenter Roeck]

On Mon, Jun 12, 2017 at 05:24:22PM +0200, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.9.32 release.
> There are 119 patches in this series, all will be posted as a response
> to this one.  If anyone has any issues with these being applied, please
> let me know.
> 
> Responses should be made by Wed Jun 14 15:25:24 UTC 2017.
> Anything received after that time might be too late.
> 

Build results:
total: 145 pass: 145 fail: 0
Qemu test results:
total: 122 pass: 122 fail: 0

Details are available at http://kerneltests.org/builders.

Guenter

Re: [PATCH 4.9 000/119] 4.9.32-stable review

[Guenter Roeck]

On Mon, Jun 12, 2017 at 05:24:22PM +0200, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.9.32 release.
> There are 119 patches in this series, all will be posted as a response
> to this one.  If anyone has any issues with these being applied, please
> let me know.
> 
> Responses should be made by Wed Jun 14 15:25:24 UTC 2017.
> Anything received after that time might be too late.
> 

Build results:
total: 145 pass: 145 fail: 0
Qemu test results:
total: 122 pass: 122 fail: 0

Details are available at http://kerneltests.org/builders.

Guenter

Re: [PATCH 4.4 00/90] 4.4.72-stable review

[Guenter Roeck]

On Mon, Jun 12, 2017 at 05:25:06PM +0200, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.4.72 release.
> There are 90 patches in this series, all will be posted as a response
> to this one.  If anyone has any issues with these being applied, please
> let me know.
> 
> Responses should be made by Wed Jun 14 15:25:30 UTC 2017.
> Anything received after that time might be too late.
> 

Build results:
total: 145 pass: 145 fail: 0
Qemu test results:
total: 115 pass: 115 fail: 0

Details are available at http://kerneltests.org/builders.

Guenter

Re: [PATCH 4.4 00/90] 4.4.72-stable review

[Guenter Roeck]

On Mon, Jun 12, 2017 at 05:25:06PM +0200, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.4.72 release.
> There are 90 patches in this series, all will be posted as a response
> to this one.  If anyone has any issues with these being applied, please
> let me know.
> 
> Responses should be made by Wed Jun 14 15:25:30 UTC 2017.
> Anything received after that time might be too late.
> 

Build results:
total: 145 pass: 145 fail: 0
Qemu test results:
total: 115 pass: 115 fail: 0

Details are available at http://kerneltests.org/builders.

Guenter

Re: [PATCH 3.18 00/45] 3.18.57-stable review

[Guenter Roeck]

On Mon, Jun 12, 2017 at 05:26:10PM +0200, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 3.18.57 release.
> There are 45 patches in this series, all will be posted as a response
> to this one.  If anyone has any issues with these being applied, please
> let me know.
> 
> Responses should be made by Wed Jun 14 15:25:35 UTC 2017.
> Anything received after that time might be too late.
> 

Build results:
total: 136 pass: 136 fail: 0
Qemu test results:
total: 111 pass: 111 fail: 0

Details are available at http://kerneltests.org/builders.

Guenter

Re: [PATCH 3.18 00/45] 3.18.57-stable review

[Guenter Roeck]

On Mon, Jun 12, 2017 at 05:26:10PM +0200, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 3.18.57 release.
> There are 45 patches in this series, all will be posted as a response
> to this one.  If anyone has any issues with these being applied, please
> let me know.
> 
> Responses should be made by Wed Jun 14 15:25:35 UTC 2017.
> Anything received after that time might be too late.
> 

Build results:
total: 136 pass: 136 fail: 0
Qemu test results:
total: 111 pass: 111 fail: 0

Details are available at http://kerneltests.org/builders.

Guenter

Re: [RFC PATCH] fs: ext4: don't trap kswapd and allocating tasks on ext4 inode IO

[Johannes Weiner]

On Mon, Jun 12, 2017 at 05:19:34PM +0200, Jan Kara wrote:
> On Mon 12-06-17 10:37:27, Johannes Weiner wrote:
> > However, with or without a reproducer, it seems to make sense to not
> > serialize evict() on commits when we don't have to from a correctness
> > point of view. Would you be opposed to just merging the patch anyway?
> 
> No, I guess the patch makes sense even without a reproducer. I'll send it
> to Ted for inclusion.

Thank you, I appreciate it!

Re: [RFC PATCH] fs: ext4: don't trap kswapd and allocating tasks on ext4 inode IO

[Johannes Weiner]

On Mon, Jun 12, 2017 at 05:19:34PM +0200, Jan Kara wrote:
> On Mon 12-06-17 10:37:27, Johannes Weiner wrote:
> > However, with or without a reproducer, it seems to make sense to not
> > serialize evict() on commits when we don't have to from a correctness
> > point of view. Would you be opposed to just merging the patch anyway?
> 
> No, I guess the patch makes sense even without a reproducer. I'll send it
> to Ted for inclusion.

Thank you, I appreciate it!

Re: [PATCH v3] PCI: Workaround wrong flags completions for IDT switch

[Bjorn Helgaas]

On Fri, Jun 09, 2017 at 04:16:17PM -0700, Yinghai Lu wrote:
> From: James Puthukattukaran 
> 
> The IDT switch incorrectly flags an ACS source violation on a read config
> request to an end point device on the completion (IDT 89H32H8G3-YC,
> errata #36) even though the PCI Express spec states that completions are
> never affected by ACS source violation (PCI Spec 3.1, Section 6.12.1.1).

Can you include a URL where this erratum is published?  If not, can
you include the actual erratum text here?

Have you considered ways to make this patch apply only to the affected
IDT switches?  Currently it applies to *all* devices.

The purpose of the pci_bus_read_dev_vendor_id() path is to support the
Configuration Request Retry Status feature (see PCIe r3.1, sec 2.3.2),
which works by special handling of config reads of the Vendor ID after
a reset.  Normally, that Vendor ID read would be the first access to
a device when we enumerate it.

This patch adds config reads and writes of the ACS capability *before*
the Vendor ID read.  At that point we don't even know whether the
device exists.  If it doesn't exist, pci_find_ext_capability() would
read 0x data, and it probably fails reasonably gracefully.

But if the device *does* exist, I think this patch breaks the CRS
Software Visibility feature.  Without this patch, we try to read
Vendor ID, and the device may return a CRS Completion Status.  If CRS
visibility is enabled, the root complex may complete the request by
returning 0x0001 for the Vendor ID, in which case we sleep and try
again later.

With this patch, we first try to read the ACS capability.  If the
device returns a CRS Completion Status, the root complex is required
to reissue the config request.  This is the required behavior
regardless of whether CRS Software Visibility is enabled, so I think
this effectively disables that feature.

> The suggested workaround by IDT is to issue a configuration write to the
> downstream device before issuing the first config read. This allows the
> downstream device to capture its bus number, thus avoiding the ACS
> violation on the completion.
> 
> The patch does the following -
> 
> 1. Disable ACS source violation if enabled
> 2. Wait for config space access to become available by reading vendor id
> 3. Do a config write to the end point (errata workaround)
> 4. Enable ACS source validation (if it was enabled to begin with)
> 
> -v2: move workaround to pci_bus_read_dev_vendor_id() from pci_bus_check_dev()
>  and move enable_acs_sv to drivers/pci/pci.c -- by Yinghai
> -v3: add bus->self check for root bus and virtual bus for sriov vfs.
> 
> Signed-off-by: James Puthukattukaran 
> Signed-off-by: Yinghai Lu 
> 
> --
> 
>  drivers/pci/pci.c   |   33 +
>  drivers/pci/pci.h   |1 +
>  drivers/pci/probe.c |   38 --
>  3 files changed, 70 insertions(+), 2 deletions(-)
> 
> Index: linux-2.6/drivers/pci/probe.c
> ===
> --- linux-2.6.orig/drivers/pci/probe.c
> +++ linux-2.6/drivers/pci/probe.c
> @@ -1763,8 +1763,8 @@ struct pci_dev *pci_alloc_dev(struct pci
>  }
>  EXPORT_SYMBOL(pci_alloc_dev);
>  
> -bool pci_bus_read_dev_vendor_id(struct pci_bus *bus, int devfn, u32 *l,
> - int crs_timeout)
> +static bool __pci_bus_read_dev_vendor_id(struct pci_bus *bus, int devfn,
> +  u32 *l, int crs_timeout)
>  {
>   int delay = 1;
>  
> @@ -1801,6 +1801,40 @@ bool pci_bus_read_dev_vendor_id(struct p
>  
>   return true;
>  }
> +
> +bool pci_bus_read_dev_vendor_id(struct pci_bus *bus, int devfn, u32 *l,
> + int crs_timeout)
> +{
> + int found;
> + int enable = -1;
> +
> + /*
> +  * Some IDT switches flag an ACS violation for config reads
> +  * even though the PCI spec allows for it (PCIe 3.1, 6.1.12.1)
> +  * It flags it because the bus number is not properly set in the
> +  * completion. The workaround is to do a dummy write to properly
> +  * latch number once the device is ready for config operations
> +  */
> +
> + if (bus->self)
> + enable = pci_std_enable_acs_sv(bus->self, false);
> +
> + found = __pci_bus_read_dev_vendor_id(bus, devfn, l, crs_timeout);
> +
> + /*
> +  * The fact that we can read the vendor id indicates that the device
> +  * is ready for config operations. Do the write as part of the errata
> +  * workaround.
> +  */
> + if (bus->self) {
> + if (found)
> + pci_bus_write_config_word(bus, devfn, PCI_VENDOR_ID, 0);
> + if (enable > 0)
> + pci_std_enable_acs_sv(bus->self, enable);
> + }
> +
> + return found;
> +}
>  EXPORT_SYMBOL(pci_bus_read_dev_vendor_id);
>  
>  /*
> Index: 

Re: [PATCH v3] PCI: Workaround wrong flags completions for IDT switch

[Bjorn Helgaas]

On Fri, Jun 09, 2017 at 04:16:17PM -0700, Yinghai Lu wrote:
> From: James Puthukattukaran 
> 
> The IDT switch incorrectly flags an ACS source violation on a read config
> request to an end point device on the completion (IDT 89H32H8G3-YC,
> errata #36) even though the PCI Express spec states that completions are
> never affected by ACS source violation (PCI Spec 3.1, Section 6.12.1.1).

Can you include a URL where this erratum is published?  If not, can
you include the actual erratum text here?

Have you considered ways to make this patch apply only to the affected
IDT switches?  Currently it applies to *all* devices.

The purpose of the pci_bus_read_dev_vendor_id() path is to support the
Configuration Request Retry Status feature (see PCIe r3.1, sec 2.3.2),
which works by special handling of config reads of the Vendor ID after
a reset.  Normally, that Vendor ID read would be the first access to
a device when we enumerate it.

This patch adds config reads and writes of the ACS capability *before*
the Vendor ID read.  At that point we don't even know whether the
device exists.  If it doesn't exist, pci_find_ext_capability() would
read 0x data, and it probably fails reasonably gracefully.

But if the device *does* exist, I think this patch breaks the CRS
Software Visibility feature.  Without this patch, we try to read
Vendor ID, and the device may return a CRS Completion Status.  If CRS
visibility is enabled, the root complex may complete the request by
returning 0x0001 for the Vendor ID, in which case we sleep and try
again later.

With this patch, we first try to read the ACS capability.  If the
device returns a CRS Completion Status, the root complex is required
to reissue the config request.  This is the required behavior
regardless of whether CRS Software Visibility is enabled, so I think
this effectively disables that feature.

> The suggested workaround by IDT is to issue a configuration write to the
> downstream device before issuing the first config read. This allows the
> downstream device to capture its bus number, thus avoiding the ACS
> violation on the completion.
> 
> The patch does the following -
> 
> 1. Disable ACS source violation if enabled
> 2. Wait for config space access to become available by reading vendor id
> 3. Do a config write to the end point (errata workaround)
> 4. Enable ACS source validation (if it was enabled to begin with)
> 
> -v2: move workaround to pci_bus_read_dev_vendor_id() from pci_bus_check_dev()
>  and move enable_acs_sv to drivers/pci/pci.c -- by Yinghai
> -v3: add bus->self check for root bus and virtual bus for sriov vfs.
> 
> Signed-off-by: James Puthukattukaran 
> Signed-off-by: Yinghai Lu 
> 
> --
> 
>  drivers/pci/pci.c   |   33 +
>  drivers/pci/pci.h   |1 +
>  drivers/pci/probe.c |   38 --
>  3 files changed, 70 insertions(+), 2 deletions(-)
> 
> Index: linux-2.6/drivers/pci/probe.c
> ===
> --- linux-2.6.orig/drivers/pci/probe.c
> +++ linux-2.6/drivers/pci/probe.c
> @@ -1763,8 +1763,8 @@ struct pci_dev *pci_alloc_dev(struct pci
>  }
>  EXPORT_SYMBOL(pci_alloc_dev);
>  
> -bool pci_bus_read_dev_vendor_id(struct pci_bus *bus, int devfn, u32 *l,
> - int crs_timeout)
> +static bool __pci_bus_read_dev_vendor_id(struct pci_bus *bus, int devfn,
> +  u32 *l, int crs_timeout)
>  {
>   int delay = 1;
>  
> @@ -1801,6 +1801,40 @@ bool pci_bus_read_dev_vendor_id(struct p
>  
>   return true;
>  }
> +
> +bool pci_bus_read_dev_vendor_id(struct pci_bus *bus, int devfn, u32 *l,
> + int crs_timeout)
> +{
> + int found;
> + int enable = -1;
> +
> + /*
> +  * Some IDT switches flag an ACS violation for config reads
> +  * even though the PCI spec allows for it (PCIe 3.1, 6.1.12.1)
> +  * It flags it because the bus number is not properly set in the
> +  * completion. The workaround is to do a dummy write to properly
> +  * latch number once the device is ready for config operations
> +  */
> +
> + if (bus->self)
> + enable = pci_std_enable_acs_sv(bus->self, false);
> +
> + found = __pci_bus_read_dev_vendor_id(bus, devfn, l, crs_timeout);
> +
> + /*
> +  * The fact that we can read the vendor id indicates that the device
> +  * is ready for config operations. Do the write as part of the errata
> +  * workaround.
> +  */
> + if (bus->self) {
> + if (found)
> + pci_bus_write_config_word(bus, devfn, PCI_VENDOR_ID, 0);
> + if (enable > 0)
> + pci_std_enable_acs_sv(bus->self, enable);
> + }
> +
> + return found;
> +}
>  EXPORT_SYMBOL(pci_bus_read_dev_vendor_id);
>  
>  /*
> Index: linux-2.6/drivers/pci/pci.c
> ===
> --- 

[GIT PULL rcu/next] RCU commits for 4.13

[Paul E. McKenney]

Hello, Ingo,

This pull request is unusual in being a single linear set of commits,
as opposed to my usual topic branches.  This is due to the many
large-footprint changes, which means that reasonable topic branches
result in large numbers of merge conflicts.  In addition, some commits
depend on other commits that should be on different topic branches.
I will return to the topic-branch style next time.

The largest feature of this series is shrinking and simplification,
with the following diffstat summary:

 79 files changed, 1496 insertions(+), 4211 deletions(-)

In other words, this series represents a net reduction of more than 2700
lines of code.

These commits were posted to LKML:

http://lkml.kernel.org/r/20170525215934.ga11...@linux.vnet.ibm.com

Two of these commits (46/88 and 48/88) have been deferred, most likely
to v4.14.  All of the remaining commits have been subjected to the 0day
Test Robot and -next testing, and are availiable in teh git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git for-mingo

for you to fetch changes up to 6d48152eafde1f0d0a4a9e0584fa7d9ff4fbfdac:

  rcu: Remove RCU CPU stall warnings from Tiny RCU (2017-06-08 18:52:45 -0700)


Arnd Bergmann (1):
  bcm47xx: Fix build regression

Paul E. McKenney (83):
  rcutorture: Add lockdep to one of the SRCU scenarios
  rcutorture: Add three-level tree test for Tree SRCU
  rcutorture: Fix bug in reporting Kconfig mis-settings
  rcutorture: Add a scenario for Tiny SRCU
  rcutorture: Add a scenario for Classic SRCU
  rcu: Prevent rcu_barrier() from starting needless grace periods
  rcutorture: Correctly handle CONFIG_RCU_TORTURE_TEST_* options
  rcutorture: Update test scenarios based on new Kconfig dependencies
  srcu: Eliminate possibility of destructive counter overflow
  rcu: Complain if blocking in preemptible RCU read-side critical section
  rcuperf: Defer expedited/normal check to end of test
  rcuperf: Remove conflicting Kconfig options
  rcu: Remove obsolete reference to synchronize_kernel()
  rcuperf: Add ability to performance-test call_rcu() and friends
  rcuperf: Add a Kconfig-fragment file for Classic SRCU
  rcu: Make sync_rcu_preempt_exp_done() return bool
  checkpatch: Remove checks for expedited grace periods
  rcuperf: Add test for dynamically initialized srcu_struct
  doc/atomic_ops: Clarify smp_mb__{before,after}_atomic()
  atomics: Add header comment so spin_unlock_wait()
  rcuperf: Add the ability to test tiny RCU flavors
  srcu: Make Classic and Tree SRCU announce themselves at bootup
  rcutorture: Reduce CPUs dedicated to testing Classic SRCU
  srcu: Shrink Tiny SRCU a bit more
  rcuperf: Set more user-friendly defaults
  rcuperf: Add writer_holdoff boot parameter
  rcutorture: Add "git diff" output to testid.txt file
  srcu: Document auto-expediting requirement
  doc: Take tail recursion into account in RCU requirements
  rcu: Add preemptibility checks in rcu_sched_qs() and rcu_bh_qs()
  rcu: Print out rcupdate.c non-default boot-time settings
  rcu: Update rcu_bootup_announce_oddness()
  srcu: Make exp_holdoff module parameter be static
  srcu: Print non-default exp_holdoff values at boot time
  rcu: Add lockdep_assert_held() teeth to tree.c
  rcu: Add lockdep_assert_held() teeth to tree_plugin.h
  srcu: Make SRCU be once again optional
  srcu: Shrink Tiny SRCU a bit
  srcu: Add DEBUG_OBJECTS_RCU_HEAD functionality
  rcu: Make synchronize_rcu_mult() check for duplicates
  sched: Rely on synchronize_rcu_mult() de-duplication
  rcu: Use RCU_NOCB_WAKE rather than RCU_NOGP_WAKE
  rcu: Add memory barriers for NOCB leader wakeup
  rcu: Flag need for rcu_node_tree.h and rcu_segcblist.h visibility
  rcu: Move docbook comments out of rcupdate.h
  rcu: Move rcu_expedited and rcu_normal externs from rcupdate.h
  rcu: Move expediting-related access/control out of rcupdate.h
  rcu: Move torture-related definitions from rcupdate.h to rcu.h
  rcu: Remove UINT_CMP_GE() and UINT_CMP_LT()
  rcu: Move rcupdate.h to new empty-function style
  rcu: Eliminate the unused __rcu_is_watching() function
  rcu: Move the RCU_SCHEDULER_ definitions from rcupdate.h
  rcu: Remove linux/debugobjects.h from rcupdate.h
  rcu: Improve __call_rcu() debug-objects error message
  rcu: Move rcu_is_nocb_cpu() from rcupdate.h to rcu.h
  rcu: Move rcu_ftrace_dump() from rcupdate.h to rcu.h
  rcu: move rcupdate.h to the new true/false-function style
  rcu: Move torture-related functions out of rcutiny.h and rcutree.h
  rcu: Move rcu_request_urgent_qs_task() out of rcutiny.h and rcutree.h
  rcu: Move rcutiny.h to new empty/true/false-function style
  srcu: Prevent sdp->srcu_gp_seq_needed counter wrap
   

[GIT PULL rcu/next] RCU commits for 4.13

[Paul E. McKenney]

Hello, Ingo,

This pull request is unusual in being a single linear set of commits,
as opposed to my usual topic branches.  This is due to the many
large-footprint changes, which means that reasonable topic branches
result in large numbers of merge conflicts.  In addition, some commits
depend on other commits that should be on different topic branches.
I will return to the topic-branch style next time.

The largest feature of this series is shrinking and simplification,
with the following diffstat summary:

 79 files changed, 1496 insertions(+), 4211 deletions(-)

In other words, this series represents a net reduction of more than 2700
lines of code.

These commits were posted to LKML:

http://lkml.kernel.org/r/20170525215934.ga11...@linux.vnet.ibm.com

Two of these commits (46/88 and 48/88) have been deferred, most likely
to v4.14.  All of the remaining commits have been subjected to the 0day
Test Robot and -next testing, and are availiable in teh git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git for-mingo

for you to fetch changes up to 6d48152eafde1f0d0a4a9e0584fa7d9ff4fbfdac:

  rcu: Remove RCU CPU stall warnings from Tiny RCU (2017-06-08 18:52:45 -0700)


Arnd Bergmann (1):
  bcm47xx: Fix build regression

Paul E. McKenney (83):
  rcutorture: Add lockdep to one of the SRCU scenarios
  rcutorture: Add three-level tree test for Tree SRCU
  rcutorture: Fix bug in reporting Kconfig mis-settings
  rcutorture: Add a scenario for Tiny SRCU
  rcutorture: Add a scenario for Classic SRCU
  rcu: Prevent rcu_barrier() from starting needless grace periods
  rcutorture: Correctly handle CONFIG_RCU_TORTURE_TEST_* options
  rcutorture: Update test scenarios based on new Kconfig dependencies
  srcu: Eliminate possibility of destructive counter overflow
  rcu: Complain if blocking in preemptible RCU read-side critical section
  rcuperf: Defer expedited/normal check to end of test
  rcuperf: Remove conflicting Kconfig options
  rcu: Remove obsolete reference to synchronize_kernel()
  rcuperf: Add ability to performance-test call_rcu() and friends
  rcuperf: Add a Kconfig-fragment file for Classic SRCU
  rcu: Make sync_rcu_preempt_exp_done() return bool
  checkpatch: Remove checks for expedited grace periods
  rcuperf: Add test for dynamically initialized srcu_struct
  doc/atomic_ops: Clarify smp_mb__{before,after}_atomic()
  atomics: Add header comment so spin_unlock_wait()
  rcuperf: Add the ability to test tiny RCU flavors
  srcu: Make Classic and Tree SRCU announce themselves at bootup
  rcutorture: Reduce CPUs dedicated to testing Classic SRCU
  srcu: Shrink Tiny SRCU a bit more
  rcuperf: Set more user-friendly defaults
  rcuperf: Add writer_holdoff boot parameter
  rcutorture: Add "git diff" output to testid.txt file
  srcu: Document auto-expediting requirement
  doc: Take tail recursion into account in RCU requirements
  rcu: Add preemptibility checks in rcu_sched_qs() and rcu_bh_qs()
  rcu: Print out rcupdate.c non-default boot-time settings
  rcu: Update rcu_bootup_announce_oddness()
  srcu: Make exp_holdoff module parameter be static
  srcu: Print non-default exp_holdoff values at boot time
  rcu: Add lockdep_assert_held() teeth to tree.c
  rcu: Add lockdep_assert_held() teeth to tree_plugin.h
  srcu: Make SRCU be once again optional
  srcu: Shrink Tiny SRCU a bit
  srcu: Add DEBUG_OBJECTS_RCU_HEAD functionality
  rcu: Make synchronize_rcu_mult() check for duplicates
  sched: Rely on synchronize_rcu_mult() de-duplication
  rcu: Use RCU_NOCB_WAKE rather than RCU_NOGP_WAKE
  rcu: Add memory barriers for NOCB leader wakeup
  rcu: Flag need for rcu_node_tree.h and rcu_segcblist.h visibility
  rcu: Move docbook comments out of rcupdate.h
  rcu: Move rcu_expedited and rcu_normal externs from rcupdate.h
  rcu: Move expediting-related access/control out of rcupdate.h
  rcu: Move torture-related definitions from rcupdate.h to rcu.h
  rcu: Remove UINT_CMP_GE() and UINT_CMP_LT()
  rcu: Move rcupdate.h to new empty-function style
  rcu: Eliminate the unused __rcu_is_watching() function
  rcu: Move the RCU_SCHEDULER_ definitions from rcupdate.h
  rcu: Remove linux/debugobjects.h from rcupdate.h
  rcu: Improve __call_rcu() debug-objects error message
  rcu: Move rcu_is_nocb_cpu() from rcupdate.h to rcu.h
  rcu: Move rcu_ftrace_dump() from rcupdate.h to rcu.h
  rcu: move rcupdate.h to the new true/false-function style
  rcu: Move torture-related functions out of rcutiny.h and rcutree.h
  rcu: Move rcu_request_urgent_qs_task() out of rcutiny.h and rcutree.h
  rcu: Move rcutiny.h to new empty/true/false-function style
  srcu: Prevent sdp->srcu_gp_seq_needed counter wrap
   

[PATCH 0/4] Xtensa fixes for v4.12-rc6

[Max Filippov]

Hi Linus,

please pull the following batch of fixes and cleanups for the Xtensa
architecture.

The following changes since commit a351e9b9fc24e982ec2f0e76379a49826036da12:

  Linux 4.11 (2017-04-30 19:47:48 -0700)

are available in the git repository at:

  git://github.com/jcmvbkbc/linux-xtensa.git tags/xtensa-20170612

for you to fetch changes up to e5c86679d5e864947a52fb31e45a425dea3e7fa9:

  xtensa: don't use linux IRQ #0 (2017-06-05 16:53:10 -0700)


Xtensa fixes for v4.12-rc6

- don't use linux IRQ #0 in legacy irq domains: fixes timer interrupt
  assignment when it's hardware IRQ # is 0 and the kernel is built w/o
  device tree support;
- reduce reservation size for double exception vector literals from 48
  to 20 bytes: fixes build on cores with small user exception vector;
- cleanups: use kmalloc_array instead of kmalloc in simdisk_init and
  seq_puts instead of seq_printf in c_show.


Markus Elfring (2):
  xtensa: Use seq_puts() in c_show()
  xtensa: ISS: Use kmalloc_array() in simdisk_init()

Max Filippov (2):
  xtensa: reduce double exception literal reservation
  xtensa: don't use linux IRQ #0

 arch/xtensa/include/asm/irq.h|  3 ++-
 arch/xtensa/kernel/irq.c |  5 -
 arch/xtensa/kernel/setup.c   |  3 +--
 arch/xtensa/kernel/vmlinux.lds.S |  6 +++---
 arch/xtensa/platforms/iss/simdisk.c  |  3 +--
 arch/xtensa/platforms/xtfpga/include/platform/hardware.h |  6 --
 arch/xtensa/platforms/xtfpga/setup.c | 10 +-
 drivers/irqchip/irq-xtensa-mx.c  |  2 +-
 drivers/irqchip/irq-xtensa-pic.c |  2 +-
 9 files changed, 18 insertions(+), 22 deletions(-)

-- 
Thanks.
-- Max

[PATCH 0/4] Xtensa fixes for v4.12-rc6

[Max Filippov]

Hi Linus,

please pull the following batch of fixes and cleanups for the Xtensa
architecture.

The following changes since commit a351e9b9fc24e982ec2f0e76379a49826036da12:

  Linux 4.11 (2017-04-30 19:47:48 -0700)

are available in the git repository at:

  git://github.com/jcmvbkbc/linux-xtensa.git tags/xtensa-20170612

for you to fetch changes up to e5c86679d5e864947a52fb31e45a425dea3e7fa9:

  xtensa: don't use linux IRQ #0 (2017-06-05 16:53:10 -0700)


Xtensa fixes for v4.12-rc6

- don't use linux IRQ #0 in legacy irq domains: fixes timer interrupt
  assignment when it's hardware IRQ # is 0 and the kernel is built w/o
  device tree support;
- reduce reservation size for double exception vector literals from 48
  to 20 bytes: fixes build on cores with small user exception vector;
- cleanups: use kmalloc_array instead of kmalloc in simdisk_init and
  seq_puts instead of seq_printf in c_show.


Markus Elfring (2):
  xtensa: Use seq_puts() in c_show()
  xtensa: ISS: Use kmalloc_array() in simdisk_init()

Max Filippov (2):
  xtensa: reduce double exception literal reservation
  xtensa: don't use linux IRQ #0

 arch/xtensa/include/asm/irq.h|  3 ++-
 arch/xtensa/kernel/irq.c |  5 -
 arch/xtensa/kernel/setup.c   |  3 +--
 arch/xtensa/kernel/vmlinux.lds.S |  6 +++---
 arch/xtensa/platforms/iss/simdisk.c  |  3 +--
 arch/xtensa/platforms/xtfpga/include/platform/hardware.h |  6 --
 arch/xtensa/platforms/xtfpga/setup.c | 10 +-
 drivers/irqchip/irq-xtensa-mx.c  |  2 +-
 drivers/irqchip/irq-xtensa-pic.c |  2 +-
 9 files changed, 18 insertions(+), 22 deletions(-)

-- 
Thanks.
-- Max

Re: [PATCH v4 3/3] net/cxgb4: Use new PCI_DEV_FLAGS_NO_RELAXED_ORDERING flag

[Alexander Duyck]

On Mon, Jun 12, 2017 at 4:05 AM, Ding Tianhong  wrote:
> From: Casey Leedom 
>
> cxgb4 Ethernet driver now queries PCIe configuration space to determine
> if it can send TLPs to it with the Relaxed Ordering Attribute set.
>
> Signed-off-by: Casey Leedom 
> Signed-off-by: Ding Tianhong 

Casey, does this patch work for you? I just want to make sure Ding
didn't miss anything. The effect of this is that the relaxed ordering
bits being set from your original patch are now dependent on them
being set in the PCIe configuration space of the device. I recall you
mentioning something about peer to peer and this currently disables
that for the case where the root complex or any PCIe bridges in
between cannot support relaxed ordering. Does that work for you or
will you need additional changes for this driver to enable peer to
peer in the that case?

> ---
>  drivers/net/ethernet/chelsio/cxgb4/cxgb4.h  |  1 +
>  drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c | 17 +
>  drivers/net/ethernet/chelsio/cxgb4/sge.c|  5 +++--
>  3 files changed, 21 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/ethernet/chelsio/cxgb4/cxgb4.h 
> b/drivers/net/ethernet/chelsio/cxgb4/cxgb4.h
> index e88c180..478f25a 100644
> --- a/drivers/net/ethernet/chelsio/cxgb4/cxgb4.h
> +++ b/drivers/net/ethernet/chelsio/cxgb4/cxgb4.h
> @@ -521,6 +521,7 @@ enum { /* adapter flags */
> USING_SOFT_PARAMS  = (1 << 6),
> MASTER_PF  = (1 << 7),
> FW_OFLD_CONN   = (1 << 9),
> +   ROOT_NO_RELAXED_ORDERING = (1 << 10),
>  };
>
>  enum {
> diff --git a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c 
> b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c
> index 38a5c67..1dd093d 100644
> --- a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c
> +++ b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c
> @@ -4726,6 +4726,23 @@ static int init_one(struct pci_dev *pdev, const struct 
> pci_device_id *ent)
> adapter->msg_enable = DFLT_MSG_ENABLE;
> memset(adapter->chan_map, 0xff, sizeof(adapter->chan_map));
>
> +   /* If possible, we use PCIe Relaxed Ordering Attribute to deliver
> +* Ingress Packet Data to Free List Buffers in order to allow for
> +* chipset performance optimizations between the Root Complex and
> +* Memory Controllers.  (Messages to the associated Ingress Queue
> +* notifying new Packet Placement in the Free Lists Buffers will be
> +* send without the Relaxed Ordering Attribute thus guaranteeing that
> +* all preceding PCIe Transaction Layer Packets will be processed
> +* first.)  But some Root Complexes have various issues with Upstream
> +* Transaction Layer Packets with the Relaxed Ordering Attribute set.
> +* The PCIe devices which under the Root Complexes will be cleared the
> +* Relaxed Ordering bit in the configuration space, So we check our
> +* PCIe configuration space to see if it's flagged with advice against
> +* using Relaxed Ordering.
> +*/
> +   if (pcie_relaxed_ordering_supported(pdev))
> +   adapter->flags |= ROOT_NO_RELAXED_ORDERING;
> +
> spin_lock_init(>stats_lock);
> spin_lock_init(>tid_release_lock);
> spin_lock_init(>win0_lock);
> diff --git a/drivers/net/ethernet/chelsio/cxgb4/sge.c 
> b/drivers/net/ethernet/chelsio/cxgb4/sge.c
> index f05f0d4..ac229a3 100644
> --- a/drivers/net/ethernet/chelsio/cxgb4/sge.c
> +++ b/drivers/net/ethernet/chelsio/cxgb4/sge.c
> @@ -2571,6 +2571,7 @@ int t4_sge_alloc_rxq(struct adapter *adap, struct 
> sge_rspq *iq, bool fwevtq,
> struct fw_iq_cmd c;
> struct sge *s = >sge;
> struct port_info *pi = netdev_priv(dev);
> +   int relaxed = !(adap->flags & ROOT_NO_RELAXED_ORDERING);
>
> /* Size needs to be multiple of 16, including status entry. */
> iq->size = roundup(iq->size, 16);
> @@ -2624,8 +2625,8 @@ int t4_sge_alloc_rxq(struct adapter *adap, struct 
> sge_rspq *iq, bool fwevtq,
>
> flsz = fl->size / 8 + s->stat_len / sizeof(struct tx_desc);
> c.iqns_to_fl0congen |= htonl(FW_IQ_CMD_FL0PACKEN_F |
> -FW_IQ_CMD_FL0FETCHRO_F |
> -FW_IQ_CMD_FL0DATARO_F |
> +FW_IQ_CMD_FL0FETCHRO_V(relaxed) |
> +FW_IQ_CMD_FL0DATARO_V(relaxed) |
>  FW_IQ_CMD_FL0PADEN_F);
> if (cong >= 0)
> c.iqns_to_fl0congen |=
> --
> 1.9.0
>
>

Re: [PATCH v4 3/3] net/cxgb4: Use new PCI_DEV_FLAGS_NO_RELAXED_ORDERING flag

[Alexander Duyck]

On Mon, Jun 12, 2017 at 4:05 AM, Ding Tianhong  wrote:
> From: Casey Leedom 
>
> cxgb4 Ethernet driver now queries PCIe configuration space to determine
> if it can send TLPs to it with the Relaxed Ordering Attribute set.
>
> Signed-off-by: Casey Leedom 
> Signed-off-by: Ding Tianhong 

Casey, does this patch work for you? I just want to make sure Ding
didn't miss anything. The effect of this is that the relaxed ordering
bits being set from your original patch are now dependent on them
being set in the PCIe configuration space of the device. I recall you
mentioning something about peer to peer and this currently disables
that for the case where the root complex or any PCIe bridges in
between cannot support relaxed ordering. Does that work for you or
will you need additional changes for this driver to enable peer to
peer in the that case?

> ---
>  drivers/net/ethernet/chelsio/cxgb4/cxgb4.h  |  1 +
>  drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c | 17 +
>  drivers/net/ethernet/chelsio/cxgb4/sge.c|  5 +++--
>  3 files changed, 21 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/ethernet/chelsio/cxgb4/cxgb4.h 
> b/drivers/net/ethernet/chelsio/cxgb4/cxgb4.h
> index e88c180..478f25a 100644
> --- a/drivers/net/ethernet/chelsio/cxgb4/cxgb4.h
> +++ b/drivers/net/ethernet/chelsio/cxgb4/cxgb4.h
> @@ -521,6 +521,7 @@ enum { /* adapter flags */
> USING_SOFT_PARAMS  = (1 << 6),
> MASTER_PF  = (1 << 7),
> FW_OFLD_CONN   = (1 << 9),
> +   ROOT_NO_RELAXED_ORDERING = (1 << 10),
>  };
>
>  enum {
> diff --git a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c 
> b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c
> index 38a5c67..1dd093d 100644
> --- a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c
> +++ b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c
> @@ -4726,6 +4726,23 @@ static int init_one(struct pci_dev *pdev, const struct 
> pci_device_id *ent)
> adapter->msg_enable = DFLT_MSG_ENABLE;
> memset(adapter->chan_map, 0xff, sizeof(adapter->chan_map));
>
> +   /* If possible, we use PCIe Relaxed Ordering Attribute to deliver
> +* Ingress Packet Data to Free List Buffers in order to allow for
> +* chipset performance optimizations between the Root Complex and
> +* Memory Controllers.  (Messages to the associated Ingress Queue
> +* notifying new Packet Placement in the Free Lists Buffers will be
> +* send without the Relaxed Ordering Attribute thus guaranteeing that
> +* all preceding PCIe Transaction Layer Packets will be processed
> +* first.)  But some Root Complexes have various issues with Upstream
> +* Transaction Layer Packets with the Relaxed Ordering Attribute set.
> +* The PCIe devices which under the Root Complexes will be cleared the
> +* Relaxed Ordering bit in the configuration space, So we check our
> +* PCIe configuration space to see if it's flagged with advice against
> +* using Relaxed Ordering.
> +*/
> +   if (pcie_relaxed_ordering_supported(pdev))
> +   adapter->flags |= ROOT_NO_RELAXED_ORDERING;
> +
> spin_lock_init(>stats_lock);
> spin_lock_init(>tid_release_lock);
> spin_lock_init(>win0_lock);
> diff --git a/drivers/net/ethernet/chelsio/cxgb4/sge.c 
> b/drivers/net/ethernet/chelsio/cxgb4/sge.c
> index f05f0d4..ac229a3 100644
> --- a/drivers/net/ethernet/chelsio/cxgb4/sge.c
> +++ b/drivers/net/ethernet/chelsio/cxgb4/sge.c
> @@ -2571,6 +2571,7 @@ int t4_sge_alloc_rxq(struct adapter *adap, struct 
> sge_rspq *iq, bool fwevtq,
> struct fw_iq_cmd c;
> struct sge *s = >sge;
> struct port_info *pi = netdev_priv(dev);
> +   int relaxed = !(adap->flags & ROOT_NO_RELAXED_ORDERING);
>
> /* Size needs to be multiple of 16, including status entry. */
> iq->size = roundup(iq->size, 16);
> @@ -2624,8 +2625,8 @@ int t4_sge_alloc_rxq(struct adapter *adap, struct 
> sge_rspq *iq, bool fwevtq,
>
> flsz = fl->size / 8 + s->stat_len / sizeof(struct tx_desc);
> c.iqns_to_fl0congen |= htonl(FW_IQ_CMD_FL0PACKEN_F |
> -FW_IQ_CMD_FL0FETCHRO_F |
> -FW_IQ_CMD_FL0DATARO_F |
> +FW_IQ_CMD_FL0FETCHRO_V(relaxed) |
> +FW_IQ_CMD_FL0DATARO_V(relaxed) |
>  FW_IQ_CMD_FL0PADEN_F);
> if (cong >= 0)
> c.iqns_to_fl0congen |=
> --
> 1.9.0
>
>

Re: [PATCH 2/2] include: warn for inconsistent endian config definition

[Babu Moger]

On 6/12/2017 3:58 PM, Max Filippov wrote:

On Mon, Jun 12, 2017 at 1:51 PM, Arnd Bergmann  wrote:

That way, we don't have to guess what the toolchain does, but rather
tell it to do whatever is configured, like we do for most other architectures.

Unfortunately we can't do the same thing on xtensa, as that no longer
supports the -mbig-endian/-mbig-endian flags in any recent gcc version
(a long time ago it had them, but they were removed along with many other
options).

For xtensa we probably need to generate Kconfig fragment that would go
in with the variant subdirectory. That will solve this, and clean up other
options that we currently have for manual selection for xtensa, but there's
actually no choice, i.e. the option has to be selected correctly, there's only
one correct choice and otherwise the kernel either won't build or won't work.
I'll look into it.

Max. Thanks. Please update us when you are done.

Re: [PATCH 2/2] include: warn for inconsistent endian config definition

[Babu Moger]

On 6/12/2017 3:58 PM, Max Filippov wrote:

On Mon, Jun 12, 2017 at 1:51 PM, Arnd Bergmann  wrote:

That way, we don't have to guess what the toolchain does, but rather
tell it to do whatever is configured, like we do for most other architectures.

Unfortunately we can't do the same thing on xtensa, as that no longer
supports the -mbig-endian/-mbig-endian flags in any recent gcc version
(a long time ago it had them, but they were removed along with many other
options).

For xtensa we probably need to generate Kconfig fragment that would go
in with the variant subdirectory. That will solve this, and clean up other
options that we currently have for manual selection for xtensa, but there's
actually no choice, i.e. the option has to be selected correctly, there's only
one correct choice and otherwise the kernel either won't build or won't work.
I'll look into it.

Max. Thanks. Please update us when you are done.

Re: [PATCH 03/11] Creation of "usb_device_auth" LSM hook

[Casey Schaufler]

On 6/12/2017 9:56 AM, Salvatore Mesoraca wrote:
> Creation of a new LSM hook that can be used to authorize or deauthorize
> new USB devices via the usb authorization interface.
> The same hook can also prevent the authorization of a USB device via
> "/sys/bus/usb/devices/DEVICE/authorized".
> Using this hook an LSM could provide an higher level of granularity
> than the current authorization interface.
>
> Signed-off-by: Salvatore Mesoraca 
> Cc: linux-...@vger.kernel.org
> Cc: Greg Kroah-Hartman 
> ---
>  drivers/usb/core/hub.c| 4 
>  drivers/usb/core/sysfs.c  | 6 +-
>  include/linux/lsm_hooks.h | 6 ++
>  include/linux/security.h  | 7 +++
>  security/security.c   | 5 +
>  5 files changed, 27 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
> index b8bb20d..58be4f0 100644
> --- a/drivers/usb/core/hub.c
> +++ b/drivers/usb/core/hub.c
> @@ -28,6 +28,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #include 
>  #include 
> @@ -4831,6 +4832,9 @@ static void hub_port_connect(struct usb_hub *hub, int 
> port1, u16 portstatus,
>   if (udev->quirks & USB_QUIRK_DELAY_INIT)
>   msleep(1000);
>  
> + if (security_usb_device_auth(udev))
> + usb_deauthorize_device(udev);
> +
>   /* consecutive bus-powered hubs aren't reliable; they can
>* violate the voltage drop budget.  if the new child has
>* a "powered" LED, users should notice we didn't enable it
> diff --git a/drivers/usb/core/sysfs.c b/drivers/usb/core/sysfs.c
> index dfc68ed..fce9d39 100644
> --- a/drivers/usb/core/sysfs.c
> +++ b/drivers/usb/core/sysfs.c
> @@ -17,6 +17,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include "usb.h"
>  
>  /* Active configuration fields */
> @@ -742,8 +743,11 @@ static ssize_t authorized_store(struct device *dev,
>   result = -EINVAL;
>   else if (val == 0)
>   result = usb_deauthorize_device(usb_dev);
> - else
> + else {
> + if (security_usb_device_auth(usb_dev))
> + return -EPERM;

Return the error reported by the hook rather than -EPERM.

>   result = usb_authorize_device(usb_dev);
> + }
>   return result < 0 ? result : size;
>  }
>  static DEVICE_ATTR_IGNORE_LOCKDEP(authorized, S_IRUGO | S_IWUSR,
> diff --git a/include/linux/lsm_hooks.h b/include/linux/lsm_hooks.h
> index bd274db..cc0937e 100644
> --- a/include/linux/lsm_hooks.h
> +++ b/include/linux/lsm_hooks.h
> @@ -1189,6 +1189,10 @@
>   *   to the @parent process for tracing.
>   *   @parent contains the task_struct structure for debugger process.
>   *   Return 0 if permission is granted.
> + * @usb_device_auth:
> + *   Check if @udev device should be authorized or not.
> + *   @udev contains the usb_device structure for the USB device.
> + *   Return 0 if the device is allowed.
>   * @capget:
>   *   Get the @effective, @inheritable, and @permitted capability sets for
>   *   the @target process.  The hook may also perform permission checking to
> @@ -1352,6 +1356,7 @@
>   int (*ptrace_access_check)(struct task_struct *child,
>   unsigned int mode);
>   int (*ptrace_traceme)(struct task_struct *parent);
> + int (*usb_device_auth)(const struct usb_device *udev);
>   int (*capget)(struct task_struct *target, kernel_cap_t *effective,
>   kernel_cap_t *inheritable, kernel_cap_t *permitted);
>   int (*capset)(struct cred *new, const struct cred *old,
> @@ -1670,6 +1675,7 @@ struct security_hook_heads {
>   struct list_head binder_transfer_file;
>   struct list_head ptrace_access_check;
>   struct list_head ptrace_traceme;
> + struct list_head usb_device_auth;
>   struct list_head capget;
>   struct list_head capset;
>   struct list_head capable;
> diff --git a/include/linux/security.h b/include/linux/security.h
> index af675b5..19bc364 100644
> --- a/include/linux/security.h
> +++ b/include/linux/security.h
> @@ -30,6 +30,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  struct linux_binprm;
>  struct cred;
> @@ -196,6 +197,7 @@ int security_binder_transfer_file(struct task_struct 
> *from,
> struct task_struct *to, struct file *file);
>  int security_ptrace_access_check(struct task_struct *child, unsigned int 
> mode);
>  int security_ptrace_traceme(struct task_struct *parent);
> +int security_usb_device_auth(const struct usb_device *udev);
>  int security_capget(struct task_struct *target,
>   kernel_cap_t *effective,
>   kernel_cap_t *inheritable,
> @@ -434,6 +436,11 @@ static inline int security_ptrace_traceme(struct 
> task_struct *parent)
>   return cap_ptrace_traceme(parent);
>  }
>  
> +static inline int security_usb_device_auth(const 

Re: [PATCH 03/11] Creation of "usb_device_auth" LSM hook

[Casey Schaufler]

On 6/12/2017 9:56 AM, Salvatore Mesoraca wrote:
> Creation of a new LSM hook that can be used to authorize or deauthorize
> new USB devices via the usb authorization interface.
> The same hook can also prevent the authorization of a USB device via
> "/sys/bus/usb/devices/DEVICE/authorized".
> Using this hook an LSM could provide an higher level of granularity
> than the current authorization interface.
>
> Signed-off-by: Salvatore Mesoraca 
> Cc: linux-...@vger.kernel.org
> Cc: Greg Kroah-Hartman 
> ---
>  drivers/usb/core/hub.c| 4 
>  drivers/usb/core/sysfs.c  | 6 +-
>  include/linux/lsm_hooks.h | 6 ++
>  include/linux/security.h  | 7 +++
>  security/security.c   | 5 +
>  5 files changed, 27 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
> index b8bb20d..58be4f0 100644
> --- a/drivers/usb/core/hub.c
> +++ b/drivers/usb/core/hub.c
> @@ -28,6 +28,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #include 
>  #include 
> @@ -4831,6 +4832,9 @@ static void hub_port_connect(struct usb_hub *hub, int 
> port1, u16 portstatus,
>   if (udev->quirks & USB_QUIRK_DELAY_INIT)
>   msleep(1000);
>  
> + if (security_usb_device_auth(udev))
> + usb_deauthorize_device(udev);
> +
>   /* consecutive bus-powered hubs aren't reliable; they can
>* violate the voltage drop budget.  if the new child has
>* a "powered" LED, users should notice we didn't enable it
> diff --git a/drivers/usb/core/sysfs.c b/drivers/usb/core/sysfs.c
> index dfc68ed..fce9d39 100644
> --- a/drivers/usb/core/sysfs.c
> +++ b/drivers/usb/core/sysfs.c
> @@ -17,6 +17,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include "usb.h"
>  
>  /* Active configuration fields */
> @@ -742,8 +743,11 @@ static ssize_t authorized_store(struct device *dev,
>   result = -EINVAL;
>   else if (val == 0)
>   result = usb_deauthorize_device(usb_dev);
> - else
> + else {
> + if (security_usb_device_auth(usb_dev))
> + return -EPERM;

Return the error reported by the hook rather than -EPERM.

>   result = usb_authorize_device(usb_dev);
> + }
>   return result < 0 ? result : size;
>  }
>  static DEVICE_ATTR_IGNORE_LOCKDEP(authorized, S_IRUGO | S_IWUSR,
> diff --git a/include/linux/lsm_hooks.h b/include/linux/lsm_hooks.h
> index bd274db..cc0937e 100644
> --- a/include/linux/lsm_hooks.h
> +++ b/include/linux/lsm_hooks.h
> @@ -1189,6 +1189,10 @@
>   *   to the @parent process for tracing.
>   *   @parent contains the task_struct structure for debugger process.
>   *   Return 0 if permission is granted.
> + * @usb_device_auth:
> + *   Check if @udev device should be authorized or not.
> + *   @udev contains the usb_device structure for the USB device.
> + *   Return 0 if the device is allowed.
>   * @capget:
>   *   Get the @effective, @inheritable, and @permitted capability sets for
>   *   the @target process.  The hook may also perform permission checking to
> @@ -1352,6 +1356,7 @@
>   int (*ptrace_access_check)(struct task_struct *child,
>   unsigned int mode);
>   int (*ptrace_traceme)(struct task_struct *parent);
> + int (*usb_device_auth)(const struct usb_device *udev);
>   int (*capget)(struct task_struct *target, kernel_cap_t *effective,
>   kernel_cap_t *inheritable, kernel_cap_t *permitted);
>   int (*capset)(struct cred *new, const struct cred *old,
> @@ -1670,6 +1675,7 @@ struct security_hook_heads {
>   struct list_head binder_transfer_file;
>   struct list_head ptrace_access_check;
>   struct list_head ptrace_traceme;
> + struct list_head usb_device_auth;
>   struct list_head capget;
>   struct list_head capset;
>   struct list_head capable;
> diff --git a/include/linux/security.h b/include/linux/security.h
> index af675b5..19bc364 100644
> --- a/include/linux/security.h
> +++ b/include/linux/security.h
> @@ -30,6 +30,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  struct linux_binprm;
>  struct cred;
> @@ -196,6 +197,7 @@ int security_binder_transfer_file(struct task_struct 
> *from,
> struct task_struct *to, struct file *file);
>  int security_ptrace_access_check(struct task_struct *child, unsigned int 
> mode);
>  int security_ptrace_traceme(struct task_struct *parent);
> +int security_usb_device_auth(const struct usb_device *udev);
>  int security_capget(struct task_struct *target,
>   kernel_cap_t *effective,
>   kernel_cap_t *inheritable,
> @@ -434,6 +436,11 @@ static inline int security_ptrace_traceme(struct 
> task_struct *parent)
>   return cap_ptrace_traceme(parent);
>  }
>  
> +static inline int security_usb_device_auth(const struct usb_device *udev)
> +{
> + return 0;
> +}
> +

Re: [PATCH 05/11] Creation of "check_vmflags" LSM hook

[Casey Schaufler]

On 6/12/2017 9:56 AM, Salvatore Mesoraca wrote:
> Creation of a new LSM hook to check if a given configuration of vmflags,
> for a new memory allocation request, should be allowed or not.
> It's placed in "do_mmap", "do_brk_flags" and "__install_special_mapping".
>
> Signed-off-by: Salvatore Mesoraca 
> Cc: linux...@kvack.org
> ---
>  include/linux/lsm_hooks.h | 6 ++
>  include/linux/security.h  | 6 ++
>  mm/mmap.c | 9 +
>  security/security.c   | 5 +
>  4 files changed, 26 insertions(+)
>
> diff --git a/include/linux/lsm_hooks.h b/include/linux/lsm_hooks.h
> index cc0937e..6934cc5 100644
> --- a/include/linux/lsm_hooks.h
> +++ b/include/linux/lsm_hooks.h
> @@ -483,6 +483,10 @@
>   *   @reqprot contains the protection requested by the application.
>   *   @prot contains the protection that will be applied by the kernel.
>   *   Return 0 if permission is granted.
> + * @check_vmflags:
> + *   Check if the requested @vmflags are allowed.
> + *   @vmflags contains requested the vmflags.
> + *   Return 0 if the operation is allowed to continue.
>   * @file_lock:
>   *   Check permission before performing file locking operations.
>   *   Note: this hook mediates both flock and fcntl style locks.
> @@ -1482,6 +1486,7 @@
>   unsigned long prot, unsigned long flags);
>   int (*file_mprotect)(struct vm_area_struct *vma, unsigned long reqprot,
>   unsigned long prot);
> + int (*check_vmflags)(vm_flags_t vmflags);
>   int (*file_lock)(struct file *file, unsigned int cmd);
>   int (*file_fcntl)(struct file *file, unsigned int cmd,
>   unsigned long arg);
> @@ -1753,6 +1758,7 @@ struct security_hook_heads {
>   struct list_head mmap_addr;
>   struct list_head mmap_file;
>   struct list_head file_mprotect;
> + struct list_head check_vmflags;
>   struct list_head file_lock;
>   struct list_head file_fcntl;
>   struct list_head file_set_fowner;
> diff --git a/include/linux/security.h b/include/linux/security.h
> index 19bc364..67e33b6 100644
> --- a/include/linux/security.h
> +++ b/include/linux/security.h
> @@ -302,6 +302,7 @@ int security_mmap_file(struct file *file, unsigned long 
> prot,
>  int security_mmap_addr(unsigned long addr);
>  int security_file_mprotect(struct vm_area_struct *vma, unsigned long reqprot,
>  unsigned long prot);
> +int security_check_vmflags(vm_flags_t vmflags);
>  int security_file_lock(struct file *file, unsigned int cmd);
>  int security_file_fcntl(struct file *file, unsigned int cmd, unsigned long 
> arg);
>  void security_file_set_fowner(struct file *file);
> @@ -830,6 +831,11 @@ static inline int security_file_mprotect(struct 
> vm_area_struct *vma,
>   return 0;
>  }
>  
> +static inline int security_check_vmflags(vm_flags_t vmflags)
> +{
> + return 0;
> +}
> +
>  static inline int security_file_lock(struct file *file, unsigned int cmd)
>  {
>   return 0;
> diff --git a/mm/mmap.c b/mm/mmap.c
> index f82741e..e19f04e 100644
> --- a/mm/mmap.c
> +++ b/mm/mmap.c
> @@ -1363,6 +1363,9 @@ unsigned long do_mmap(struct file *file, unsigned long 
> addr,
>   vm_flags |= calc_vm_prot_bits(prot, pkey) | calc_vm_flag_bits(flags) |
>   mm->def_flags | VM_MAYREAD | VM_MAYWRITE | VM_MAYEXEC;
>  
> + if (security_check_vmflags(vm_flags))
> + return -EPERM;
> +

Have the hook return a value and return that rather
than -EPERM. That way a security module can choose an
error that it determines is appropriate. It is possible
that a module might want to deny the access for a reason
other than lack of privilege. 

>   if (flags & MAP_LOCKED)
>   if (!can_do_mlock())
>   return -EPERM;
> @@ -2833,6 +2836,9 @@ static int do_brk_flags(unsigned long addr, unsigned 
> long request, unsigned long
>   return -EINVAL;
>   flags |= VM_DATA_DEFAULT_FLAGS | VM_ACCOUNT | mm->def_flags;
>  
> + if (security_check_vmflags(flags))
> + return -EPERM;
> +

Same here

>   error = get_unmapped_area(NULL, addr, len, 0, MAP_FIXED);
>   if (offset_in_page(error))
>   return error;
> @@ -3208,6 +3214,9 @@ static struct vm_area_struct *__install_special_mapping(
>   int ret;
>   struct vm_area_struct *vma;
>  
> + if (security_check_vmflags(vm_flags))
> + return ERR_PTR(-EPERM);
> +

And here.

>   vma = kmem_cache_zalloc(vm_area_cachep, GFP_KERNEL);
>   if (unlikely(vma == NULL))
>   return ERR_PTR(-ENOMEM);
> diff --git a/security/security.c b/security/security.c
> index e390f99..25d58f0 100644
> --- a/security/security.c
> +++ b/security/security.c
> @@ -905,6 +905,11 @@ int security_file_mprotect(struct vm_area_struct *vma, 
> unsigned long reqprot,
>   return call_int_hook(file_mprotect, 0, vma, reqprot, prot);
>  }
>  
> +int 

Re: [PATCH 05/11] Creation of "check_vmflags" LSM hook

[Casey Schaufler]

On 6/12/2017 9:56 AM, Salvatore Mesoraca wrote:
> Creation of a new LSM hook to check if a given configuration of vmflags,
> for a new memory allocation request, should be allowed or not.
> It's placed in "do_mmap", "do_brk_flags" and "__install_special_mapping".
>
> Signed-off-by: Salvatore Mesoraca 
> Cc: linux...@kvack.org
> ---
>  include/linux/lsm_hooks.h | 6 ++
>  include/linux/security.h  | 6 ++
>  mm/mmap.c | 9 +
>  security/security.c   | 5 +
>  4 files changed, 26 insertions(+)
>
> diff --git a/include/linux/lsm_hooks.h b/include/linux/lsm_hooks.h
> index cc0937e..6934cc5 100644
> --- a/include/linux/lsm_hooks.h
> +++ b/include/linux/lsm_hooks.h
> @@ -483,6 +483,10 @@
>   *   @reqprot contains the protection requested by the application.
>   *   @prot contains the protection that will be applied by the kernel.
>   *   Return 0 if permission is granted.
> + * @check_vmflags:
> + *   Check if the requested @vmflags are allowed.
> + *   @vmflags contains requested the vmflags.
> + *   Return 0 if the operation is allowed to continue.
>   * @file_lock:
>   *   Check permission before performing file locking operations.
>   *   Note: this hook mediates both flock and fcntl style locks.
> @@ -1482,6 +1486,7 @@
>   unsigned long prot, unsigned long flags);
>   int (*file_mprotect)(struct vm_area_struct *vma, unsigned long reqprot,
>   unsigned long prot);
> + int (*check_vmflags)(vm_flags_t vmflags);
>   int (*file_lock)(struct file *file, unsigned int cmd);
>   int (*file_fcntl)(struct file *file, unsigned int cmd,
>   unsigned long arg);
> @@ -1753,6 +1758,7 @@ struct security_hook_heads {
>   struct list_head mmap_addr;
>   struct list_head mmap_file;
>   struct list_head file_mprotect;
> + struct list_head check_vmflags;
>   struct list_head file_lock;
>   struct list_head file_fcntl;
>   struct list_head file_set_fowner;
> diff --git a/include/linux/security.h b/include/linux/security.h
> index 19bc364..67e33b6 100644
> --- a/include/linux/security.h
> +++ b/include/linux/security.h
> @@ -302,6 +302,7 @@ int security_mmap_file(struct file *file, unsigned long 
> prot,
>  int security_mmap_addr(unsigned long addr);
>  int security_file_mprotect(struct vm_area_struct *vma, unsigned long reqprot,
>  unsigned long prot);
> +int security_check_vmflags(vm_flags_t vmflags);
>  int security_file_lock(struct file *file, unsigned int cmd);
>  int security_file_fcntl(struct file *file, unsigned int cmd, unsigned long 
> arg);
>  void security_file_set_fowner(struct file *file);
> @@ -830,6 +831,11 @@ static inline int security_file_mprotect(struct 
> vm_area_struct *vma,
>   return 0;
>  }
>  
> +static inline int security_check_vmflags(vm_flags_t vmflags)
> +{
> + return 0;
> +}
> +
>  static inline int security_file_lock(struct file *file, unsigned int cmd)
>  {
>   return 0;
> diff --git a/mm/mmap.c b/mm/mmap.c
> index f82741e..e19f04e 100644
> --- a/mm/mmap.c
> +++ b/mm/mmap.c
> @@ -1363,6 +1363,9 @@ unsigned long do_mmap(struct file *file, unsigned long 
> addr,
>   vm_flags |= calc_vm_prot_bits(prot, pkey) | calc_vm_flag_bits(flags) |
>   mm->def_flags | VM_MAYREAD | VM_MAYWRITE | VM_MAYEXEC;
>  
> + if (security_check_vmflags(vm_flags))
> + return -EPERM;
> +

Have the hook return a value and return that rather
than -EPERM. That way a security module can choose an
error that it determines is appropriate. It is possible
that a module might want to deny the access for a reason
other than lack of privilege. 

>   if (flags & MAP_LOCKED)
>   if (!can_do_mlock())
>   return -EPERM;
> @@ -2833,6 +2836,9 @@ static int do_brk_flags(unsigned long addr, unsigned 
> long request, unsigned long
>   return -EINVAL;
>   flags |= VM_DATA_DEFAULT_FLAGS | VM_ACCOUNT | mm->def_flags;
>  
> + if (security_check_vmflags(flags))
> + return -EPERM;
> +

Same here

>   error = get_unmapped_area(NULL, addr, len, 0, MAP_FIXED);
>   if (offset_in_page(error))
>   return error;
> @@ -3208,6 +3214,9 @@ static struct vm_area_struct *__install_special_mapping(
>   int ret;
>   struct vm_area_struct *vma;
>  
> + if (security_check_vmflags(vm_flags))
> + return ERR_PTR(-EPERM);
> +

And here.

>   vma = kmem_cache_zalloc(vm_area_cachep, GFP_KERNEL);
>   if (unlikely(vma == NULL))
>   return ERR_PTR(-ENOMEM);
> diff --git a/security/security.c b/security/security.c
> index e390f99..25d58f0 100644
> --- a/security/security.c
> +++ b/security/security.c
> @@ -905,6 +905,11 @@ int security_file_mprotect(struct vm_area_struct *vma, 
> unsigned long reqprot,
>   return call_int_hook(file_mprotect, 0, vma, reqprot, prot);
>  }
>  
> +int 

Re: [PATCH v3 05/18] xen/pvcalls: connect to a frontend

[Boris Ostrovsky]

On 06/02/2017 03:31 PM, Stefano Stabellini wrote:
> Introduce a per-frontend data structure named pvcalls_fedata. It
> contains pointers to the command ring, its event channel, a list of
> active sockets and a tree of passive sockets (passing sockets need to be
> looked up from the id on listen, accept and poll commands, while active
> sockets only on release).
>
> It also has an unbound workqueue to schedule the work of parsing and
> executing commands on the command ring. socket_lock protects the two
> lists. In pvcalls_back_global, keep a list of connected frontends.
>
> Signed-off-by: Stefano Stabellini 
> CC: boris.ostrov...@oracle.com
> CC: jgr...@suse.com

Reviewed-by: Boris Ostrovsky 

Re: [PATCH v3 05/18] xen/pvcalls: connect to a frontend

[Boris Ostrovsky]

On 06/02/2017 03:31 PM, Stefano Stabellini wrote:
> Introduce a per-frontend data structure named pvcalls_fedata. It
> contains pointers to the command ring, its event channel, a list of
> active sockets and a tree of passive sockets (passing sockets need to be
> looked up from the id on listen, accept and poll commands, while active
> sockets only on release).
>
> It also has an unbound workqueue to schedule the work of parsing and
> executing commands on the command ring. socket_lock protects the two
> lists. In pvcalls_back_global, keep a list of connected frontends.
>
> Signed-off-by: Stefano Stabellini 
> CC: boris.ostrov...@oracle.com
> CC: jgr...@suse.com

Reviewed-by: Boris Ostrovsky 

Re: [PATCH v4 2/3] PCI: Enable PCIe Relaxed Ordering if supported

[Alexander Duyck]

On Mon, Jun 12, 2017 at 4:05 AM, Ding Tianhong  wrote:
> The PCIe Device Control Register use the bit 4 to indicate that
> whether the device is permitted to enable relaxed ordering or not.
> But relaxed ordering is not safe for some platform which could only
> use strong write ordering, so devices are allowed (but not required)
> to enable relaxed ordering bit by default.
>
> If a PCIe device didn't enable the relaxed ordering attribute default,
> we should not do anything in the PCIe configuration, otherwise we
> should check if any of the devices above us do not support relaxed
> ordering by the PCI_DEV_FLAGS_NO_RELAXED_ORDERING flag, then base on
> the result if we get a return that indicate that the relaxed ordering
> is not supported we should update our device to disable relaxed ordering
> in configuration space. If the device above us doesn't exist or isn't
> the PCIe device, we shouldn't do anything and skip updating relaxed ordering
> because we are probably running in a guest machine.
>
> Signed-off-by: Ding Tianhong 
> ---
>  drivers/pci/pci.c   | 32 
>  drivers/pci/probe.c | 41 +
>  include/linux/pci.h |  2 ++
>  3 files changed, 75 insertions(+)
>
> diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
> index b01bd5b..b44f34c 100644
> --- a/drivers/pci/pci.c
> +++ b/drivers/pci/pci.c
> @@ -4878,6 +4878,38 @@ int pcie_set_mps(struct pci_dev *dev, int mps)
>  EXPORT_SYMBOL(pcie_set_mps);
>
>  /**
> + * pcie_clear_relaxed_ordering - clear PCI Express relaxed ordering bit
> + * @dev: PCI device to query
> + *
> + * If possible clear relaxed ordering
> + */
> +int pcie_clear_relaxed_ordering(struct pci_dev *dev)
> +{
> +   return pcie_capability_clear_word(dev, PCI_EXP_DEVCTL,
> + PCI_EXP_DEVCTL_RELAX_EN);
> +}
> +EXPORT_SYMBOL(pcie_clear_relaxed_ordering);
> +
> +/**
> + * pcie_relaxed_ordering_supported - Probe for PCIe relexed ordering support
> + * @dev: PCI device to query
> + *
> + * Returns true if the device support relaxed ordering attribute.
> + */
> +bool pcie_relaxed_ordering_supported(struct pci_dev *dev)
> +{
> +   bool ro_supported = false;
> +   u16 v;
> +
> +   pcie_capability_read_word(dev, PCI_EXP_DEVCTL, );
> +   if ((v & PCI_EXP_DEVCTL_RELAX_EN) >> 4)
> +   ro_supported = true;

Instead of "return ro_supported" why not just "return !!(v &
PCIE_EXP_DEVCTL_RELAX_EN)"? You can cut out the extra steps and save
yourself some extra steps this way since the shift by 4 shouldn't even
really be needed since you are just testing for a bit anyway.

> +
> +   return ro_supported;
> +}
> +EXPORT_SYMBOL(pcie_relaxed_ordering_supported);
> +
> +/**
>   * pcie_get_minimum_link - determine minimum link settings of a PCI device
>   * @dev: PCI device to query
>   * @speed: storage for minimum speed
> diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
> index 19c8950..ed1f717 100644
> --- a/drivers/pci/probe.c
> +++ b/drivers/pci/probe.c
> @@ -1701,6 +1701,46 @@ static void pci_configure_extended_tags(struct pci_dev 
> *dev)
>  PCI_EXP_DEVCTL_EXT_TAG);
>  }
>
> +/**
> + * pci_dev_should_disable_relaxed_ordering - check if the PCI device
> + * should disable the relaxed ordering attribute.
> + * @dev: PCI device
> + *
> + * Return true if any of the PCI devices above us do not support
> + * relaxed ordering.
> + */
> +static bool pci_dev_should_disable_relaxed_ordering(struct pci_dev *dev)
> +{
> +   bool ro_disabled = false;
> +
> +   while (dev) {
> +   if (dev->dev_flags & PCI_DEV_FLAGS_NO_RELAXED_ORDERING) {
> +   ro_disabled = true;
> +   break;
> +   }
> +   dev = dev->bus->self;
> +   }
> +
> +   return ro_disabled;

Same thing here. I would suggest just returning either true or false,
and drop the ro_disabled value. It will return the lines of code and
make things a bit bit more direct.

> +}
> +
> +static void pci_configure_relaxed_ordering(struct pci_dev *dev)
> +{
> +   struct pci_dev *bridge = pci_upstream_bridge(dev);
> +
> +   if (!pci_is_pcie(dev) || !bridge || !pci_is_pcie(bridge))
> +   return;

The pci_is_pcie check is actually redundant based on the
pcie_relaxed_ordering_supported check using pcie_capability_read_word.

Also I am not sure what the point is of the pci_upstream_bridge()
check is, it seems like you should be able to catch all the same stuff
in your pci_dev_should_disable_relaxed_ordering() call. Though it did
give me a thought. I don't think we can alter this for a VF, so you
might want to add a check for dev->is_virtfn to the list of checks and
if it is a virtual function just return since I don't think there are
any VFs that would let you alter this bit anyway.

> +   /* If the releaxed ordering enable bit is 

Re: [PATCH v4 2/3] PCI: Enable PCIe Relaxed Ordering if supported

[Alexander Duyck]

On Mon, Jun 12, 2017 at 4:05 AM, Ding Tianhong  wrote:
> The PCIe Device Control Register use the bit 4 to indicate that
> whether the device is permitted to enable relaxed ordering or not.
> But relaxed ordering is not safe for some platform which could only
> use strong write ordering, so devices are allowed (but not required)
> to enable relaxed ordering bit by default.
>
> If a PCIe device didn't enable the relaxed ordering attribute default,
> we should not do anything in the PCIe configuration, otherwise we
> should check if any of the devices above us do not support relaxed
> ordering by the PCI_DEV_FLAGS_NO_RELAXED_ORDERING flag, then base on
> the result if we get a return that indicate that the relaxed ordering
> is not supported we should update our device to disable relaxed ordering
> in configuration space. If the device above us doesn't exist or isn't
> the PCIe device, we shouldn't do anything and skip updating relaxed ordering
> because we are probably running in a guest machine.
>
> Signed-off-by: Ding Tianhong 
> ---
>  drivers/pci/pci.c   | 32 
>  drivers/pci/probe.c | 41 +
>  include/linux/pci.h |  2 ++
>  3 files changed, 75 insertions(+)
>
> diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
> index b01bd5b..b44f34c 100644
> --- a/drivers/pci/pci.c
> +++ b/drivers/pci/pci.c
> @@ -4878,6 +4878,38 @@ int pcie_set_mps(struct pci_dev *dev, int mps)
>  EXPORT_SYMBOL(pcie_set_mps);
>
>  /**
> + * pcie_clear_relaxed_ordering - clear PCI Express relaxed ordering bit
> + * @dev: PCI device to query
> + *
> + * If possible clear relaxed ordering
> + */
> +int pcie_clear_relaxed_ordering(struct pci_dev *dev)
> +{
> +   return pcie_capability_clear_word(dev, PCI_EXP_DEVCTL,
> + PCI_EXP_DEVCTL_RELAX_EN);
> +}
> +EXPORT_SYMBOL(pcie_clear_relaxed_ordering);
> +
> +/**
> + * pcie_relaxed_ordering_supported - Probe for PCIe relexed ordering support
> + * @dev: PCI device to query
> + *
> + * Returns true if the device support relaxed ordering attribute.
> + */
> +bool pcie_relaxed_ordering_supported(struct pci_dev *dev)
> +{
> +   bool ro_supported = false;
> +   u16 v;
> +
> +   pcie_capability_read_word(dev, PCI_EXP_DEVCTL, );
> +   if ((v & PCI_EXP_DEVCTL_RELAX_EN) >> 4)
> +   ro_supported = true;

Instead of "return ro_supported" why not just "return !!(v &
PCIE_EXP_DEVCTL_RELAX_EN)"? You can cut out the extra steps and save
yourself some extra steps this way since the shift by 4 shouldn't even
really be needed since you are just testing for a bit anyway.

> +
> +   return ro_supported;
> +}
> +EXPORT_SYMBOL(pcie_relaxed_ordering_supported);
> +
> +/**
>   * pcie_get_minimum_link - determine minimum link settings of a PCI device
>   * @dev: PCI device to query
>   * @speed: storage for minimum speed
> diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
> index 19c8950..ed1f717 100644
> --- a/drivers/pci/probe.c
> +++ b/drivers/pci/probe.c
> @@ -1701,6 +1701,46 @@ static void pci_configure_extended_tags(struct pci_dev 
> *dev)
>  PCI_EXP_DEVCTL_EXT_TAG);
>  }
>
> +/**
> + * pci_dev_should_disable_relaxed_ordering - check if the PCI device
> + * should disable the relaxed ordering attribute.
> + * @dev: PCI device
> + *
> + * Return true if any of the PCI devices above us do not support
> + * relaxed ordering.
> + */
> +static bool pci_dev_should_disable_relaxed_ordering(struct pci_dev *dev)
> +{
> +   bool ro_disabled = false;
> +
> +   while (dev) {
> +   if (dev->dev_flags & PCI_DEV_FLAGS_NO_RELAXED_ORDERING) {
> +   ro_disabled = true;
> +   break;
> +   }
> +   dev = dev->bus->self;
> +   }
> +
> +   return ro_disabled;

Same thing here. I would suggest just returning either true or false,
and drop the ro_disabled value. It will return the lines of code and
make things a bit bit more direct.

> +}
> +
> +static void pci_configure_relaxed_ordering(struct pci_dev *dev)
> +{
> +   struct pci_dev *bridge = pci_upstream_bridge(dev);
> +
> +   if (!pci_is_pcie(dev) || !bridge || !pci_is_pcie(bridge))
> +   return;

The pci_is_pcie check is actually redundant based on the
pcie_relaxed_ordering_supported check using pcie_capability_read_word.

Also I am not sure what the point is of the pci_upstream_bridge()
check is, it seems like you should be able to catch all the same stuff
in your pci_dev_should_disable_relaxed_ordering() call. Though it did
give me a thought. I don't think we can alter this for a VF, so you
might want to add a check for dev->is_virtfn to the list of checks and
if it is a virtual function just return since I don't think there are
any VFs that would let you alter this bit anyway.

> +   /* If the releaxed ordering enable bit is not set, do nothing. */
> +   if 

Re: [PATCHSET for-4.13] cgroup: implement cgroup2 thread mode, v2

[Tejun Heo]

Hello, Peter.

On Mon, Jun 12, 2017 at 02:31:50PM +0200, Peter Zijlstra wrote:
> Please don't rush this; also, I might not be around much the coming
> weeks due to taking some leave 'soon' (kid #3 is imminent).

Congrats.  As for this going forward, how can we possibly be slower?

> And I really need more time to look at this (and re-read the old
> discussions, because I've forgot most everything again).

Can we at least unblock the cpu controller part?  We can hash the
details of thread support as long as necessary but I'm not sure it's
reasonable to keep blocking the whole cpu controller at this point.

> > * Root cgroup can enable thread mode anytime and a first level child
> >   can opt-in to that thread subtree anchored at root by writing "join"
> >   to "cgroup.threads" files, start its own thread subtree or just be a
> >   normal cgroup.
> 
> Yuck... this again is a consequence of tagging the 'wrong' thing. Again,
> the primary construct is the resource domain.
> 
> If you use that as a tag, you don't need this weird join crap. Because
> as soon as you clear the 'resource domain' flag on a group, it instantly
> becomes a thread group and 'obviously' connects to the first parent that
> is a resource domain.

It has nothing to do with whether we mark domain or threaded subtrees.
It is solely from whether you wanna express cases where a thread root
is right below another thread root.  Tn's are member cgroup of thread
subtrees where the same number means the same threaded subtree, D's
are of domain cgroups.

The following is straight forward.

T0
   /  \
  T0   D

The following is too.

T0
   /  \
  T0   D
\
 T1

The question is whether to allow something like the following.

T0
   /  \
  T0  T1

That's where the "join" thing comes from because we wanna be able to
tell apart whether a cgroup is gonna be a part of the existing thread
subtree or starting its own thread subtree.  There sure are multiple
ways to express that but one way or the other, if you wanna support
topologies like the last one, you have to distinguish the two.

The previous iteration actually was that way, so the only thread mode
operation was setting whether to enable thread or not as before and if
the parent is already thread mode, it'd always join the existing
threaded subtree.  If you like that better, I can post that version
right away.

> And, as per the last time, this threaded marker isn't uniquely
> identifying things, so it hard prohibits from ever extending the model
> to allow resource domains nested in a thread subtree. Now I understand
> why you don't implement that now -- you were struggling with the views
> API, but that is no excuse to create an API that permanently disables
> that feature.

Hmmm?  We can just allow disabling thread mode if we ever get to that.
We can't make arbitrary graphs out of these nodes.  Whatever mode we
put them in, they have to fall in with the overall tree structure, so
I don't think the interface is unnecessarily restricting in that
direction.

> I cannot at this time remember if there was a strong use-case for that
> scenario -- like said, I really need to re-read the email threads, but I
> might not have enough time to do so now.
> 
> Again, please don't rush this.

Well, I don't have a way to do that.

> So I really regret the 'shares' interface; we really should have done a
> nice thing.
> 
>   
> https://lkml.kernel.org/r/20170410073622.2y6tnpcd2ssuo...@hirez.programming.kicks-ass.net
> 
> So I would like to change to that instead of the weird 100 thing.

Is it?  Relative weights are pretty fundamental and clearly defined in
expressing work-conserving resource distribution.  Do you have more
details on what you have on mind?

> As for the RT thing, the runtime/period thing is not a MAX but a MIN
> limit (conceptually -- in practise its both).

Yeah, it's a hard allocation.

> Also, we need cpuset to be a thread controller.

Yeah, absolutely.

Thanks.

-- 
tejun

Re: [PATCHSET for-4.13] cgroup: implement cgroup2 thread mode, v2

[Tejun Heo]

Hello, Peter.

On Mon, Jun 12, 2017 at 02:31:50PM +0200, Peter Zijlstra wrote:
> Please don't rush this; also, I might not be around much the coming
> weeks due to taking some leave 'soon' (kid #3 is imminent).

Congrats.  As for this going forward, how can we possibly be slower?

> And I really need more time to look at this (and re-read the old
> discussions, because I've forgot most everything again).

Can we at least unblock the cpu controller part?  We can hash the
details of thread support as long as necessary but I'm not sure it's
reasonable to keep blocking the whole cpu controller at this point.

> > * Root cgroup can enable thread mode anytime and a first level child
> >   can opt-in to that thread subtree anchored at root by writing "join"
> >   to "cgroup.threads" files, start its own thread subtree or just be a
> >   normal cgroup.
> 
> Yuck... this again is a consequence of tagging the 'wrong' thing. Again,
> the primary construct is the resource domain.
> 
> If you use that as a tag, you don't need this weird join crap. Because
> as soon as you clear the 'resource domain' flag on a group, it instantly
> becomes a thread group and 'obviously' connects to the first parent that
> is a resource domain.

It has nothing to do with whether we mark domain or threaded subtrees.
It is solely from whether you wanna express cases where a thread root
is right below another thread root.  Tn's are member cgroup of thread
subtrees where the same number means the same threaded subtree, D's
are of domain cgroups.

The following is straight forward.

T0
   /  \
  T0   D

The following is too.

T0
   /  \
  T0   D
\
 T1

The question is whether to allow something like the following.

T0
   /  \
  T0  T1

That's where the "join" thing comes from because we wanna be able to
tell apart whether a cgroup is gonna be a part of the existing thread
subtree or starting its own thread subtree.  There sure are multiple
ways to express that but one way or the other, if you wanna support
topologies like the last one, you have to distinguish the two.

The previous iteration actually was that way, so the only thread mode
operation was setting whether to enable thread or not as before and if
the parent is already thread mode, it'd always join the existing
threaded subtree.  If you like that better, I can post that version
right away.

> And, as per the last time, this threaded marker isn't uniquely
> identifying things, so it hard prohibits from ever extending the model
> to allow resource domains nested in a thread subtree. Now I understand
> why you don't implement that now -- you were struggling with the views
> API, but that is no excuse to create an API that permanently disables
> that feature.

Hmmm?  We can just allow disabling thread mode if we ever get to that.
We can't make arbitrary graphs out of these nodes.  Whatever mode we
put them in, they have to fall in with the overall tree structure, so
I don't think the interface is unnecessarily restricting in that
direction.

> I cannot at this time remember if there was a strong use-case for that
> scenario -- like said, I really need to re-read the email threads, but I
> might not have enough time to do so now.
> 
> Again, please don't rush this.

Well, I don't have a way to do that.

> So I really regret the 'shares' interface; we really should have done a
> nice thing.
> 
>   
> https://lkml.kernel.org/r/20170410073622.2y6tnpcd2ssuo...@hirez.programming.kicks-ass.net
> 
> So I would like to change to that instead of the weird 100 thing.

Is it?  Relative weights are pretty fundamental and clearly defined in
expressing work-conserving resource distribution.  Do you have more
details on what you have on mind?

> As for the RT thing, the runtime/period thing is not a MAX but a MIN
> limit (conceptually -- in practise its both).

Yeah, it's a hard allocation.

> Also, we need cpuset to be a thread controller.

Yeah, absolutely.

Thanks.

-- 
tejun

Re: [PATCH 2/2] include: warn for inconsistent endian config definition

[Babu Moger]

On 6/12/2017 3:51 PM, Arnd Bergmann wrote:

On Mon, Jun 12, 2017 at 10:30 PM, Babu Moger  wrote:

Looks like microblaze can be configured to either little or big endian
formats.  How about
adding a choice statement to address this.
Here is my proposed patch.

Hi Babu,

This part looks fine, but I think we also need this one:

diff --git a/arch/microblaze/Makefile b/arch/microblaze/Makefile
index 740f2b82a182..1f6c486826a0 100644
--- a/arch/microblaze/Makefile
+++ b/arch/microblaze/Makefile
@@ -35,6 +35,8 @@ endif
  CPUFLAGS-$(CONFIG_XILINX_MICROBLAZE0_USE_DIV) += -mno-xl-soft-div
  CPUFLAGS-$(CONFIG_XILINX_MICROBLAZE0_USE_BARREL) += -mxl-barrel-shift
  CPUFLAGS-$(CONFIG_XILINX_MICROBLAZE0_USE_PCMP_INSTR) += -mxl-pattern-compare
+CPUFLAGS-$(CONFIG_BIG_ENDIAN) += -mbig-endian
+CPUFLAGS-$(CONFIG_LITTLE_ENDIAN) += -mlittle-endian

  CPUFLAGS-1 += $(call cc-option,-mcpu=v$(CPU_VER))


That way, we don't have to guess what the toolchain does, but rather
tell it to do whatever is configured, like we do for most other architectures.


Ok. Thanks. Arnd. Will update and resend the series.



Unfortunately we can't do the same thing on xtensa, as that no longer
supports the -mbig-endian/-mbig-endian flags in any recent gcc version
(a long time ago it had them, but they were removed along with many other
options).

 Arnd

Re: [PATCH 2/2] include: warn for inconsistent endian config definition

[Babu Moger]

On 6/12/2017 3:51 PM, Arnd Bergmann wrote:

On Mon, Jun 12, 2017 at 10:30 PM, Babu Moger  wrote:

Looks like microblaze can be configured to either little or big endian
formats.  How about
adding a choice statement to address this.
Here is my proposed patch.

Hi Babu,

This part looks fine, but I think we also need this one:

diff --git a/arch/microblaze/Makefile b/arch/microblaze/Makefile
index 740f2b82a182..1f6c486826a0 100644
--- a/arch/microblaze/Makefile
+++ b/arch/microblaze/Makefile
@@ -35,6 +35,8 @@ endif
  CPUFLAGS-$(CONFIG_XILINX_MICROBLAZE0_USE_DIV) += -mno-xl-soft-div
  CPUFLAGS-$(CONFIG_XILINX_MICROBLAZE0_USE_BARREL) += -mxl-barrel-shift
  CPUFLAGS-$(CONFIG_XILINX_MICROBLAZE0_USE_PCMP_INSTR) += -mxl-pattern-compare
+CPUFLAGS-$(CONFIG_BIG_ENDIAN) += -mbig-endian
+CPUFLAGS-$(CONFIG_LITTLE_ENDIAN) += -mlittle-endian

  CPUFLAGS-1 += $(call cc-option,-mcpu=v$(CPU_VER))


That way, we don't have to guess what the toolchain does, but rather
tell it to do whatever is configured, like we do for most other architectures.


Ok. Thanks. Arnd. Will update and resend the series.



Unfortunately we can't do the same thing on xtensa, as that no longer
supports the -mbig-endian/-mbig-endian flags in any recent gcc version
(a long time ago it had them, but they were removed along with many other
options).

 Arnd

Re: PC speaker

[Randy Dunlap]

On 06/12/17 12:13, R.F. Burns wrote:
> Is it possible to write a kernel module which, when loaded, will blow
> the PC speaker?
> 

deja vu all over again.  Same author.

http://marc.info/?l=linux-kernel=118165248822375=2

are you a bot?

-- 
~Randy

Re: PC speaker

[Randy Dunlap]

On 06/12/17 12:13, R.F. Burns wrote:
> Is it possible to write a kernel module which, when loaded, will blow
> the PC speaker?
> 

deja vu all over again.  Same author.

http://marc.info/?l=linux-kernel=118165248822375=2

are you a bot?

-- 
~Randy

[PATCH 3/4] mfd: tps65217: remove duplicated interrupt resources.

[Enric Balletbo i Serra]

I don't think it makes sense to have the interrupt resources for charger
and power button in two different places, the driver and the DT binding.
That's confusing so remove the ones from the mfd driver in favour of
having the interrupt resources only described in the DT. Having the
resources in DT may help if there is or will be a similar pmic with
different resource allocation.

Signed-off-by: Enric Balletbo i Serra 
---
 drivers/mfd/tps65217.c | 22 +-
 1 file changed, 1 insertion(+), 21 deletions(-)

diff --git a/drivers/mfd/tps65217.c b/drivers/mfd/tps65217.c
index f769c7d..fd83bae 100644
--- a/drivers/mfd/tps65217.c
+++ b/drivers/mfd/tps65217.c
@@ -33,15 +33,6 @@
 #include 
 #include 
 
-static struct resource charger_resources[] = {
-   DEFINE_RES_IRQ_NAMED(TPS65217_IRQ_AC, "AC"),
-   DEFINE_RES_IRQ_NAMED(TPS65217_IRQ_USB, "USB"),
-};
-
-static struct resource pb_resources[] = {
-   DEFINE_RES_IRQ_NAMED(TPS65217_IRQ_PB, "PB"),
-};
-
 static void tps65217_irq_lock(struct irq_data *data)
 {
struct tps65217 *tps = irq_data_get_irq_chip_data(data);
@@ -97,14 +88,10 @@ static struct mfd_cell tps65217s[] = {
},
{
.name = "tps65217-charger",
-   .num_resources = ARRAY_SIZE(charger_resources),
-   .resources = charger_resources,
.of_compatible = "ti,tps65217-charger",
},
{
.name = "tps65217-pwrbutton",
-   .num_resources = ARRAY_SIZE(pb_resources),
-   .resources = pb_resources,
.of_compatible = "ti,tps65217-pwrbutton",
},
 };
@@ -359,15 +346,8 @@ static int tps65217_probe(struct i2c_client *client,
return ret;
}
 
-   if (client->irq) {
+   if (client->irq)
tps65217_irq_init(tps, client->irq);
-   } else {
-   int i;
-
-   /* Don't tell children about IRQ resources which won't fire */
-   for (i = 0; i < ARRAY_SIZE(tps65217s); i++)
-   tps65217s[i].num_resources = 0;
-   }
 
ret = devm_mfd_add_devices(tps->dev, -1, tps65217s,
   ARRAY_SIZE(tps65217s), NULL, 0,
-- 
2.9.3

[PATCH 3/4] mfd: tps65217: remove duplicated interrupt resources.

[Enric Balletbo i Serra]

I don't think it makes sense to have the interrupt resources for charger
and power button in two different places, the driver and the DT binding.
That's confusing so remove the ones from the mfd driver in favour of
having the interrupt resources only described in the DT. Having the
resources in DT may help if there is or will be a similar pmic with
different resource allocation.

Signed-off-by: Enric Balletbo i Serra 
---
 drivers/mfd/tps65217.c | 22 +-
 1 file changed, 1 insertion(+), 21 deletions(-)

diff --git a/drivers/mfd/tps65217.c b/drivers/mfd/tps65217.c
index f769c7d..fd83bae 100644
--- a/drivers/mfd/tps65217.c
+++ b/drivers/mfd/tps65217.c
@@ -33,15 +33,6 @@
 #include 
 #include 
 
-static struct resource charger_resources[] = {
-   DEFINE_RES_IRQ_NAMED(TPS65217_IRQ_AC, "AC"),
-   DEFINE_RES_IRQ_NAMED(TPS65217_IRQ_USB, "USB"),
-};
-
-static struct resource pb_resources[] = {
-   DEFINE_RES_IRQ_NAMED(TPS65217_IRQ_PB, "PB"),
-};
-
 static void tps65217_irq_lock(struct irq_data *data)
 {
struct tps65217 *tps = irq_data_get_irq_chip_data(data);
@@ -97,14 +88,10 @@ static struct mfd_cell tps65217s[] = {
},
{
.name = "tps65217-charger",
-   .num_resources = ARRAY_SIZE(charger_resources),
-   .resources = charger_resources,
.of_compatible = "ti,tps65217-charger",
},
{
.name = "tps65217-pwrbutton",
-   .num_resources = ARRAY_SIZE(pb_resources),
-   .resources = pb_resources,
.of_compatible = "ti,tps65217-pwrbutton",
},
 };
@@ -359,15 +346,8 @@ static int tps65217_probe(struct i2c_client *client,
return ret;
}
 
-   if (client->irq) {
+   if (client->irq)
tps65217_irq_init(tps, client->irq);
-   } else {
-   int i;
-
-   /* Don't tell children about IRQ resources which won't fire */
-   for (i = 0; i < ARRAY_SIZE(tps65217s); i++)
-   tps65217s[i].num_resources = 0;
-   }
 
ret = devm_mfd_add_devices(tps->dev, -1, tps65217s,
   ARRAY_SIZE(tps65217s), NULL, 0,
-- 
2.9.3

[PATCH 1/4] ARM: dts: tps65217: Add charger interrupts to the common tps65217.dtsi file

[Enric Balletbo i Serra]

The interrupt specifiers for USB and AC charger input are static data that
comes from the datasheet, there is no reason to need to define these values
on every board so seem reasonable put this information into the common
tps65217 file.

Signed-off-by: Enric Balletbo i Serra 
---
 arch/arm/boot/dts/am335x-bone-common.dtsi | 2 --
 arch/arm/boot/dts/am335x-chiliboard.dts   | 2 --
 arch/arm/boot/dts/tps65217.dtsi   | 2 ++
 3 files changed, 2 insertions(+), 4 deletions(-)

diff --git a/arch/arm/boot/dts/am335x-bone-common.dtsi 
b/arch/arm/boot/dts/am335x-bone-common.dtsi
index bf6b26a..bfa4258 100644
--- a/arch/arm/boot/dts/am335x-bone-common.dtsi
+++ b/arch/arm/boot/dts/am335x-bone-common.dtsi
@@ -319,8 +319,6 @@
ti,pmic-shutdown-controller;
 
charger {
-   interrupts = <0>, <1>;
-   interrupt-names = "USB", "AC";
status = "okay";
};
 
diff --git a/arch/arm/boot/dts/am335x-chiliboard.dts 
b/arch/arm/boot/dts/am335x-chiliboard.dts
index d876979..5c25f3a 100644
--- a/arch/arm/boot/dts/am335x-chiliboard.dts
+++ b/arch/arm/boot/dts/am335x-chiliboard.dts
@@ -191,8 +191,6 @@
interrupts = <7>; /* NNMI */
 
charger {
-   interrupts = <0>, <1>;
-   interrupt-names = "USB", "AC";
status = "okay";
};
 
diff --git a/arch/arm/boot/dts/tps65217.dtsi b/arch/arm/boot/dts/tps65217.dtsi
index 02de56b..1973159 100644
--- a/arch/arm/boot/dts/tps65217.dtsi
+++ b/arch/arm/boot/dts/tps65217.dtsi
@@ -18,6 +18,8 @@
 
charger {
compatible = "ti,tps65217-charger";
+   interrupts = <0>, <1>;
+   interrupt-names = "USB", "AC";
status = "disabled";
};
 
-- 
2.9.3

[PATCH 1/4] ARM: dts: tps65217: Add charger interrupts to the common tps65217.dtsi file

[Enric Balletbo i Serra]

The interrupt specifiers for USB and AC charger input are static data that
comes from the datasheet, there is no reason to need to define these values
on every board so seem reasonable put this information into the common
tps65217 file.

Signed-off-by: Enric Balletbo i Serra 
---
 arch/arm/boot/dts/am335x-bone-common.dtsi | 2 --
 arch/arm/boot/dts/am335x-chiliboard.dts   | 2 --
 arch/arm/boot/dts/tps65217.dtsi   | 2 ++
 3 files changed, 2 insertions(+), 4 deletions(-)

diff --git a/arch/arm/boot/dts/am335x-bone-common.dtsi 
b/arch/arm/boot/dts/am335x-bone-common.dtsi
index bf6b26a..bfa4258 100644
--- a/arch/arm/boot/dts/am335x-bone-common.dtsi
+++ b/arch/arm/boot/dts/am335x-bone-common.dtsi
@@ -319,8 +319,6 @@
ti,pmic-shutdown-controller;
 
charger {
-   interrupts = <0>, <1>;
-   interrupt-names = "USB", "AC";
status = "okay";
};
 
diff --git a/arch/arm/boot/dts/am335x-chiliboard.dts 
b/arch/arm/boot/dts/am335x-chiliboard.dts
index d876979..5c25f3a 100644
--- a/arch/arm/boot/dts/am335x-chiliboard.dts
+++ b/arch/arm/boot/dts/am335x-chiliboard.dts
@@ -191,8 +191,6 @@
interrupts = <7>; /* NNMI */
 
charger {
-   interrupts = <0>, <1>;
-   interrupt-names = "USB", "AC";
status = "okay";
};
 
diff --git a/arch/arm/boot/dts/tps65217.dtsi b/arch/arm/boot/dts/tps65217.dtsi
index 02de56b..1973159 100644
--- a/arch/arm/boot/dts/tps65217.dtsi
+++ b/arch/arm/boot/dts/tps65217.dtsi
@@ -18,6 +18,8 @@
 
charger {
compatible = "ti,tps65217-charger";
+   interrupts = <0>, <1>;
+   interrupt-names = "USB", "AC";
status = "disabled";
};
 
-- 
2.9.3

Re: [PATCH] DocBook: w1: Update W1 file locations and names in DocBook

[kbuild test robot]

Hi Andrew,

[auto build test ERROR on linus/master]
[also build test ERROR on v4.12-rc5]
[cannot apply to next-20170609]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Andrew-F-Davis/DocBook-w1-Update-W1-file-locations-and-names-in-DocBook/20170613-035424
reproduce: make htmldocs

All errors (new ones prefixed by >>):

>> docproc: include/linux/w1.h: No such file or directory

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip

Re: [PATCH] DocBook: w1: Update W1 file locations and names in DocBook

[kbuild test robot]

Hi Andrew,

[auto build test ERROR on linus/master]
[also build test ERROR on v4.12-rc5]
[cannot apply to next-20170609]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Andrew-F-Davis/DocBook-w1-Update-W1-file-locations-and-names-in-DocBook/20170613-035424
reproduce: make htmldocs

All errors (new ones prefixed by >>):

>> docproc: include/linux/w1.h: No such file or directory

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip

[PATCH 4/4] power: supply: tps65217: able to disable the charger block.

[Enric Balletbo i Serra]

The TPS65217 charger is enabled by default, but by default the DT binding
sets the charger as disabled, so currently all the devices that include
the tps65217 binding have the charger enabled. This patch adds a check in
the probe function of the tps65217 charger and disables it if the device
status is disabled.

Signed-off-by: Enric Balletbo i Serra 
---
 drivers/power/supply/tps65217_charger.c | 17 +
 1 file changed, 17 insertions(+)

diff --git a/drivers/power/supply/tps65217_charger.c 
b/drivers/power/supply/tps65217_charger.c
index 1f52340..55308f4 100644
--- a/drivers/power/supply/tps65217_charger.c
+++ b/drivers/power/supply/tps65217_charger.c
@@ -203,6 +203,23 @@ static int tps65217_charger_probe(struct platform_device 
*pdev)
int ret;
int i;
 
+   /*
+* By default the charger is enabled but if device is disabled stop
+* the charger accordingly to the configuration.
+*/
+   if (!of_device_is_available(pdev->dev.of_node)) {
+   dev_dbg(>dev, "charger disabled\n");
+   ret = tps65217_clear_bits(tps, TPS65217_REG_CHGCONFIG1,
+ TPS65217_CHGCONFIG1_CHG_EN,
+ TPS65217_PROTECT_NONE);
+   if (ret) {
+   dev_err(>dev, "Error writing in reg 0x%x: %d\n",
+   TPS65217_REG_CHGCONFIG1, ret);
+   return ret;
+   }
+   return -ENODEV;
+   }
+
charger = devm_kzalloc(>dev, sizeof(*charger), GFP_KERNEL);
if (!charger)
return -ENOMEM;
-- 
2.9.3

[PATCH 4/4] power: supply: tps65217: able to disable the charger block.

[Enric Balletbo i Serra]

The TPS65217 charger is enabled by default, but by default the DT binding
sets the charger as disabled, so currently all the devices that include
the tps65217 binding have the charger enabled. This patch adds a check in
the probe function of the tps65217 charger and disables it if the device
status is disabled.

Signed-off-by: Enric Balletbo i Serra 
---
 drivers/power/supply/tps65217_charger.c | 17 +
 1 file changed, 17 insertions(+)

diff --git a/drivers/power/supply/tps65217_charger.c 
b/drivers/power/supply/tps65217_charger.c
index 1f52340..55308f4 100644
--- a/drivers/power/supply/tps65217_charger.c
+++ b/drivers/power/supply/tps65217_charger.c
@@ -203,6 +203,23 @@ static int tps65217_charger_probe(struct platform_device 
*pdev)
int ret;
int i;
 
+   /*
+* By default the charger is enabled but if device is disabled stop
+* the charger accordingly to the configuration.
+*/
+   if (!of_device_is_available(pdev->dev.of_node)) {
+   dev_dbg(>dev, "charger disabled\n");
+   ret = tps65217_clear_bits(tps, TPS65217_REG_CHGCONFIG1,
+ TPS65217_CHGCONFIG1_CHG_EN,
+ TPS65217_PROTECT_NONE);
+   if (ret) {
+   dev_err(>dev, "Error writing in reg 0x%x: %d\n",
+   TPS65217_REG_CHGCONFIG1, ret);
+   return ret;
+   }
+   return -ENODEV;
+   }
+
charger = devm_kzalloc(>dev, sizeof(*charger), GFP_KERNEL);
if (!charger)
return -ENOMEM;
-- 
2.9.3

[PATCH 2/4] ARM: dts: tps65217: Add power button interrupt to the common tps65217.dtsi file

[Enric Balletbo i Serra]

The interrupt for power button is static data that comes from the
datasheet, there is no reason to need to define this value on every
board so seams reasonable put this information into the common tps65217
file.

Signed-off-by: Enric Balletbo i Serra 
---
 arch/arm/boot/dts/am335x-bone-common.dtsi | 1 -
 arch/arm/boot/dts/am335x-chiliboard.dts   | 1 -
 arch/arm/boot/dts/tps65217.dtsi   | 1 +
 3 files changed, 1 insertion(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/am335x-bone-common.dtsi 
b/arch/arm/boot/dts/am335x-bone-common.dtsi
index bfa4258..89daaeb 100644
--- a/arch/arm/boot/dts/am335x-bone-common.dtsi
+++ b/arch/arm/boot/dts/am335x-bone-common.dtsi
@@ -323,7 +323,6 @@
};
 
pwrbutton {
-   interrupts = <2>;
status = "okay";
};
 
diff --git a/arch/arm/boot/dts/am335x-chiliboard.dts 
b/arch/arm/boot/dts/am335x-chiliboard.dts
index 5c25f3a..59431b2 100644
--- a/arch/arm/boot/dts/am335x-chiliboard.dts
+++ b/arch/arm/boot/dts/am335x-chiliboard.dts
@@ -195,7 +195,6 @@
};
 
pwrbutton {
-   interrupts = <2>;
status = "okay";
};
 };
diff --git a/arch/arm/boot/dts/tps65217.dtsi b/arch/arm/boot/dts/tps65217.dtsi
index 1973159..399baaa 100644
--- a/arch/arm/boot/dts/tps65217.dtsi
+++ b/arch/arm/boot/dts/tps65217.dtsi
@@ -25,6 +25,7 @@
 
pwrbutton {
compatible = "ti,tps65217-pwrbutton";
+   interrupts = <2>;
status = "disabled";
};
 
-- 
2.9.3

[PATCH 2/4] ARM: dts: tps65217: Add power button interrupt to the common tps65217.dtsi file

[Enric Balletbo i Serra]

The interrupt for power button is static data that comes from the
datasheet, there is no reason to need to define this value on every
board so seams reasonable put this information into the common tps65217
file.

Signed-off-by: Enric Balletbo i Serra 
---
 arch/arm/boot/dts/am335x-bone-common.dtsi | 1 -
 arch/arm/boot/dts/am335x-chiliboard.dts   | 1 -
 arch/arm/boot/dts/tps65217.dtsi   | 1 +
 3 files changed, 1 insertion(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/am335x-bone-common.dtsi 
b/arch/arm/boot/dts/am335x-bone-common.dtsi
index bfa4258..89daaeb 100644
--- a/arch/arm/boot/dts/am335x-bone-common.dtsi
+++ b/arch/arm/boot/dts/am335x-bone-common.dtsi
@@ -323,7 +323,6 @@
};
 
pwrbutton {
-   interrupts = <2>;
status = "okay";
};
 
diff --git a/arch/arm/boot/dts/am335x-chiliboard.dts 
b/arch/arm/boot/dts/am335x-chiliboard.dts
index 5c25f3a..59431b2 100644
--- a/arch/arm/boot/dts/am335x-chiliboard.dts
+++ b/arch/arm/boot/dts/am335x-chiliboard.dts
@@ -195,7 +195,6 @@
};
 
pwrbutton {
-   interrupts = <2>;
status = "okay";
};
 };
diff --git a/arch/arm/boot/dts/tps65217.dtsi b/arch/arm/boot/dts/tps65217.dtsi
index 1973159..399baaa 100644
--- a/arch/arm/boot/dts/tps65217.dtsi
+++ b/arch/arm/boot/dts/tps65217.dtsi
@@ -25,6 +25,7 @@
 
pwrbutton {
compatible = "ti,tps65217-pwrbutton";
+   interrupts = <2>;
status = "disabled";
};
 
-- 
2.9.3

Re: [PATCH v3 04/18] xen/pvcalls: xenbus state handling

[Boris Ostrovsky]

On 06/02/2017 03:31 PM, Stefano Stabellini wrote:
> Introduce the code to handle xenbus state changes.
>
> Implement the probe function for the pvcalls backend. Write the
> supported versions, max-page-order and function-calls nodes to xenstore,
> as required by the protocol.
>
> Introduce stub functions for disconnecting/connecting to a frontend.
>
> Signed-off-by: Stefano Stabellini 
> CC: boris.ostrov...@oracle.com
> CC: jgr...@suse.com


Reviewed-by: Boris Ostrovsky 

Re: [PATCH v3 04/18] xen/pvcalls: xenbus state handling

[Boris Ostrovsky]

On 06/02/2017 03:31 PM, Stefano Stabellini wrote:
> Introduce the code to handle xenbus state changes.
>
> Implement the probe function for the pvcalls backend. Write the
> supported versions, max-page-order and function-calls nodes to xenstore,
> as required by the protocol.
>
> Introduce stub functions for disconnecting/connecting to a frontend.
>
> Signed-off-by: Stefano Stabellini 
> CC: boris.ostrov...@oracle.com
> CC: jgr...@suse.com


Reviewed-by: Boris Ostrovsky