[PATCH resend] arm: dts: ls1021a: add reboot node to .dtsi

[Rasmus Villemoes]

The LS1021A can be reset via the dcfg regmap in the same way as the
arm64 layerscape SoCs, so add the corresponding DT node.

Signed-off-by: Rasmus Villemoes 
---
 arch/arm/boot/dts/ls1021a.dtsi | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/arch/arm/boot/dts/ls1021a.dtsi b/arch/arm/boot/dts/ls1021a.dtsi
index 9319e1f0f1d8..3ff2b8a9f01a 100644
--- a/arch/arm/boot/dts/ls1021a.dtsi
+++ b/arch/arm/boot/dts/ls1021a.dtsi
@@ -108,6 +108,13 @@
 ;
};
 
+   reboot {
+   compatible = "syscon-reboot";
+   regmap = <>;
+   offset = <0xb0>;
+   mask = <0x02>;
+   };
+
soc {
compatible = "simple-bus";
#address-cells = <2>;
-- 
2.7.4

Re: [PATCH] scsi: csiostor: fix spelling mistake: "Couldnt" -> "Couldn't"

[Martin K. Petersen]

Colin,

> Trivial fix to spelling mistake in error message text.

Applied to 4.16/scsi-queue.

-- 
Martin K. Petersen  Oracle Linux Engineering

Re: BUG: KASAN: slab-out-of-bounds in perf_callchain_user+0x494/0x530

[Namhyung Kim]

Hello,

On Thu, Nov 30, 2017 at 04:37:12PM -0300, Arnaldo Carvalho de Melo wrote:
> Em Thu, Nov 30, 2017 at 09:20:26AM +0100, Peter Zijlstra escreveu:
> > On Thu, Nov 30, 2017 at 10:32:19AM +0800, Fengguang Wu wrote:
> > > Hello,
> > > 
> > > FYI this happens in mainline kernel 4.15.0-rc1.
> > > It looks like a new regression and hard to bisect.
> > > 
> > > It occurs in 1 out of 57 boots.
> > > 
> > > [   10.009610] chown (367) used greatest stack depth: 26944 bytes left
> > > Kernel tests: Boot OK!
> > > [   30.357729] trinity-main uses obsolete (PF_INET,SOCK_PACKET)
> > > [   31.301433] sock: process `trinity-main' is using obsolete setsockopt 
> > > SO_BSDCOMPAT
> > > [   31.310289] 
> > > ==
> > > [   31.311490] BUG: KASAN: slab-out-of-bounds in 
> > > perf_callchain_user+0x494/0x530:
> > >   perf_callchain_store at 
> > > include/linux/perf_event.h:1128
> > >(inlined by) 
> > > perf_callchain_user at arch/x86/events/core.c:2485
> > 
> > I don't think we recently changed anything here...
> > 
> > But I do have vague memories of something being off here; I never quite
> > could penetrate the max_stack / contexts_maxed stuff, and istr acme was
> > going to have a peek.
>  
> Sure, but I saw some backward ring buffer stuff in there as well, no?
> IIRC that came after the max-stack code, Adding Wang to the CC list.

I think it's because of per-event max-stack not being checked for the
first event.  Please see the patch below..

Also I'm not sure that the allocation failure check would work
correctly since it decrements nr_callchain_events when it fails.

Thanks,
Namhyung



>From c12126c4ff9835f0899619db3ee7b4a3151ff2bb Mon Sep 17 00:00:00 2001
From: Namhyung Kim 
Date: Tue, 5 Dec 2017 16:54:50 +0900
Subject: [PATCH] perf/core: Fix overflow on perf_callchain_entry

The commit 97c79a38cd45 add a check whether per-event max stack is
greater than the global max.  But it missed to do it for the first
event.  So if the event had a stack depth greater than the global max,
it could overflow the callchain entry list.

Reported-by: Fengguang Wu 
Fixes: 97c79a38cd45 ("perf core: Per event callchain limit")
Signed-off-by: Namhyung Kim 
---
 kernel/events/callchain.c | 21 -
 1 file changed, 12 insertions(+), 9 deletions(-)

diff --git a/kernel/events/callchain.c b/kernel/events/callchain.c
index 1b2be63c8528..e449e23802eb 100644
--- a/kernel/events/callchain.c
+++ b/kernel/events/callchain.c
@@ -119,19 +119,22 @@ int get_callchain_buffers(int event_max_stack)
goto exit;
}
 
+   /*
+* If requesting per event more than the global cap,
+* return a different error to help userspace figure this out.
+*
+* And also do it here so that we have _mutex held.
+*/
+   if (event_max_stack > sysctl_perf_event_max_stack) {
+   err = -EOVERFLOW;
+   goto exit;
+   }
+
if (count > 1) {
/* If the allocation failed, give up */
if (!callchain_cpus_entries)
err = -ENOMEM;
-   /*
-* If requesting per event more than the global cap,
-* return a different error to help userspace figure
-* this out.
-*
-* And also do it here so that we have _mutex held.
-*/
-   if (event_max_stack > sysctl_perf_event_max_stack)
-   err = -EOVERFLOW;
+
goto exit;
}
 
-- 
2.15.0

[PATCH resend] arm: dts: ls1021a: Specify interrupt-affinity for pmu node

[Rasmus Villemoes]

From: Esben Haabendal 

From: Esben Haabendal 

This avoids the warning

  hw perfevents: no interrupt-affinity property for /pmu, guessing.

Signed-off-by: Esben Haabendal 
[RV: adapt commit log to the warning emitted in current mainline]
Signed-off-by: Rasmus Villemoes 
---
 arch/arm/boot/dts/ls1021a.dtsi | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/boot/dts/ls1021a.dtsi b/arch/arm/boot/dts/ls1021a.dtsi
index 02a266faec9b..96dc1a29fc64 100644
--- a/arch/arm/boot/dts/ls1021a.dtsi
+++ b/arch/arm/boot/dts/ls1021a.dtsi
@@ -106,6 +106,7 @@
compatible = "arm,cortex-a7-pmu";
interrupts = ,
 ;
+   interrupt-affinity = <>, <>;
};
 
reboot {
-- 
2.7.4

Re: [PATCH v2 2/2] arm64: allwinner: a64-sopine: Fix to use dcdc1 regulator instead of vcc3v3

[Maxime Ripard]

On Mon, Dec 04, 2017 at 10:23:07AM +0530, Jagan Teki wrote:
> Since current tree support AXP803 regulators,
> replace fixed regulator vcc3v3 with AXP803 dcdc1 regulator where ever
> it need to replace.
> 
> Tested mmc0 on sopine baseboard.
> 
> Signed-off-by: Jagan Teki 

Queued as a fix, thanks

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com


signature.asc
Description: PGP signature

Re: [PATCH v2 1/2] arm64: dts: a64-olinuxino: Enable RTL8723BS WiFi

[Maxime Ripard]

On Mon, Dec 04, 2017 at 10:23:06AM +0530, Jagan Teki wrote:
> Enable RTL8723BS WiFi chip on a64-olinuxino board:
> - WiFi SDIO interface is connected to MMC1
> - WiFi REG_ON pin connected to gpio PL2: attach to mmc-pwrseq
> - WiFi HOST_WAKE pin connected to gpio PL3
> 
> Signed-off-by: Jagan Teki 
> Acked-by: Maxime Ripard 

Applied, thanks!
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com


signature.asc
Description: PGP signature

[PATCH v2 3/3] mtd: nand: squash struct nand_buffers into struct nand_chip

[Masahiro Yamada]

struct nand_buffers is malloc'ed in nand_scan_tail() just for
containing three pointers.  Squash this struct into nand_chip.

Move and rename as follows:

  chip->buffers->ecccalc   ->  chip->ecc.calc_buf
  chip->buffers->ecccode   ->  chip->ecc.code_buf
  chip->buffers->databuf   ->  chip->data_buf

Signed-off-by: Masahiro Yamada 
---

Changes in v2:
  - Rename as Boris suggested
  - Based on cafe_nand rework

 drivers/mtd/nand/brcmnand/brcmnand.c   |  2 +-
 drivers/mtd/nand/denali.c  |  2 +-
 drivers/mtd/nand/fsmc_nand.c   |  4 +-
 drivers/mtd/nand/gpmi-nand/gpmi-nand.c |  4 +-
 drivers/mtd/nand/nand_base.c   | 91 ++
 drivers/mtd/nand/nand_bbt.c|  2 +-
 drivers/mtd/nand/omap2.c   | 10 ++--
 drivers/mtd/nand/sunxi_nand.c  |  6 +--
 include/linux/mtd/rawnand.h| 23 +++--
 9 files changed, 59 insertions(+), 85 deletions(-)

diff --git a/drivers/mtd/nand/brcmnand/brcmnand.c 
b/drivers/mtd/nand/brcmnand/brcmnand.c
index e0eb51d..cc13c88 100644
--- a/drivers/mtd/nand/brcmnand/brcmnand.c
+++ b/drivers/mtd/nand/brcmnand/brcmnand.c
@@ -1681,7 +1681,7 @@ static int brcmstb_nand_verify_erased_page(struct 
mtd_info *mtd,
int ret;
 
if (!buf) {
-   buf = chip->buffers->databuf;
+   buf = chip->data_buf;
/* Invalidate page cache */
chip->pagebuf = -1;
}
diff --git a/drivers/mtd/nand/denali.c b/drivers/mtd/nand/denali.c
index 2fc964b..3e61ac4 100644
--- a/drivers/mtd/nand/denali.c
+++ b/drivers/mtd/nand/denali.c
@@ -328,7 +328,7 @@ static int denali_check_erased_page(struct mtd_info *mtd,
unsigned long uncor_ecc_flags,
unsigned int max_bitflips)
 {
-   uint8_t *ecc_code = chip->buffers->ecccode;
+   uint8_t *ecc_code = chip->ecc.code_buf;
int ecc_steps = chip->ecc.steps;
int ecc_size = chip->ecc.size;
int ecc_bytes = chip->ecc.bytes;
diff --git a/drivers/mtd/nand/fsmc_nand.c b/drivers/mtd/nand/fsmc_nand.c
index eac15d9..574b043 100644
--- a/drivers/mtd/nand/fsmc_nand.c
+++ b/drivers/mtd/nand/fsmc_nand.c
@@ -684,8 +684,8 @@ static int fsmc_read_page_hwecc(struct mtd_info *mtd, 
struct nand_chip *chip,
int eccbytes = chip->ecc.bytes;
int eccsteps = chip->ecc.steps;
uint8_t *p = buf;
-   uint8_t *ecc_calc = chip->buffers->ecccalc;
-   uint8_t *ecc_code = chip->buffers->ecccode;
+   uint8_t *ecc_calc = chip->ecc.calc_buf;
+   uint8_t *ecc_code = chip->ecc.code_buf;
int off, len, group = 0;
/*
 * ecc_oob is intentionally taken as uint16_t. In 16bit devices, we
diff --git a/drivers/mtd/nand/gpmi-nand/gpmi-nand.c 
b/drivers/mtd/nand/gpmi-nand/gpmi-nand.c
index 50f8d4a..a760ae7 100644
--- a/drivers/mtd/nand/gpmi-nand/gpmi-nand.c
+++ b/drivers/mtd/nand/gpmi-nand/gpmi-nand.c
@@ -1712,7 +1712,7 @@ static int mx23_check_transcription_stamp(struct 
gpmi_nand_data *this)
unsigned int search_area_size_in_strides;
unsigned int stride;
unsigned int page;
-   uint8_t *buffer = chip->buffers->databuf;
+   uint8_t *buffer = chip->data_buf;
int saved_chip_number;
int found_an_ncb_fingerprint = false;
 
@@ -1771,7 +1771,7 @@ static int mx23_write_transcription_stamp(struct 
gpmi_nand_data *this)
unsigned int block;
unsigned int stride;
unsigned int page;
-   uint8_t  *buffer = chip->buffers->databuf;
+   uint8_t  *buffer = chip->data_buf;
int saved_chip_number;
int status;
 
diff --git a/drivers/mtd/nand/nand_base.c b/drivers/mtd/nand/nand_base.c
index 0cc61b1..fe583e4 100644
--- a/drivers/mtd/nand/nand_base.c
+++ b/drivers/mtd/nand/nand_base.c
@@ -1456,8 +1456,8 @@ static int nand_read_page_swecc(struct mtd_info *mtd, 
struct nand_chip *chip,
int eccbytes = chip->ecc.bytes;
int eccsteps = chip->ecc.steps;
uint8_t *p = buf;
-   uint8_t *ecc_calc = chip->buffers->ecccalc;
-   uint8_t *ecc_code = chip->buffers->ecccode;
+   uint8_t *ecc_calc = chip->ecc.calc_buf;
+   uint8_t *ecc_code = chip->ecc.code_buf;
unsigned int max_bitflips = 0;
 
chip->ecc.read_page_raw(mtd, chip, buf, 1, page);
@@ -1529,7 +1529,7 @@ static int nand_read_subpage(struct mtd_info *mtd, struct 
nand_chip *chip,
 
/* Calculate ECC */
for (i = 0; i < eccfrag_len ; i += chip->ecc.bytes, p += chip->ecc.size)
-   chip->ecc.calculate(mtd, p, >buffers->ecccalc[i]);
+   chip->ecc.calculate(mtd, p, >ecc.calc_buf[i]);
 
/*
 * The performance is faster if we position offsets according to
@@ -1563,7 +1563,7 @@ static int nand_read_subpage(struct mtd_info *mtd, struct 
nand_chip *chip,
chip->read_buf(mtd, >oob_poi[aligned_pos], aligned_len);
}
 
-   ret = 

Re: [PATCH] power: ltc2941-battery-gauge: Disable continuous monitoring on shutdown

[Ladislav Michl]

On Tue, Dec 05, 2017 at 08:10:27AM +0100, Mike Looijmans wrote:
> On 01-12-17 16:42, Sebastian Reichel wrote:
> > Hi,
> > 
> > On Thu, Nov 23, 2017 at 03:41:05PM +0100, Mike Looijmans wrote:
> > > The driver sets the fuel gauge to continuous monitoring on startup, for
> > > the models that support this. When the board shuts down, the chip remains
> > > in that mode, causing a few mA drain on the battery every 2 or 10 seconds.
> > > 
> > > This patch registers a shutdown handler that turns off the monitoring to
> > > prevent this battery drain.
> > > 
> > > Signed-off-by: Mike Looijmans 
> > > ---
> > 
> > Thanks, queued. I wonder if you need a second patch to also disable
> > the monitoring for suspend (and re-enable on resume)?
> 
> For now, yes, that would probably make sense.
> 
> The gauge also has "alert" functionality, once that is enabled in the
> driver, the monitoring shouldn't be disabled and the device would even be
> able to wake the system. But that's no concern yet, so just stopping it on
> suspend would be better for now.

That should be probably somehow configurable. DT property? As some boards
might continue to drain power in suspended state and disabling gas gauge
might cause inaccuracy in battery charge after some time. The same will
happen when charging device in suspended (or even disabled) state.

Best regards,
ladis

> > -- Sebastian
> > 
> > >   drivers/power/supply/ltc2941-battery-gauge.c | 25 
> > > +
> > >   1 file changed, 25 insertions(+)
> > > 
> > > diff --git a/drivers/power/supply/ltc2941-battery-gauge.c 
> > > b/drivers/power/supply/ltc2941-battery-gauge.c
> > > index 08e4fd9..4cfa3f0 100644
> > > --- a/drivers/power/supply/ltc2941-battery-gauge.c
> > > +++ b/drivers/power/supply/ltc2941-battery-gauge.c
> > > @@ -60,6 +60,7 @@ enum ltc294x_id {
> > >   #define LTC294X_REG_CONTROL_PRESCALER_SET(x) \
> > >   ((x << 3) & LTC294X_REG_CONTROL_PRESCALER_MASK)
> > >   #define LTC294X_REG_CONTROL_ALCC_CONFIG_DISABLED0
> > > +#define LTC294X_REG_CONTROL_ADC_DISABLE(x)   ((x) & ~(BIT(7) | 
> > > BIT(6)))
> > >   struct ltc294x_info {
> > >   struct i2c_client *client;  /* I2C Client pointer */
> > > @@ -523,6 +524,29 @@ static int ltc294x_i2c_probe(struct i2c_client 
> > > *client,
> > >   return 0;
> > >   }
> > > +static void ltc294x_i2c_shutdown(struct i2c_client *client)
> > > +{
> > > + struct ltc294x_info *info = i2c_get_clientdata(client);
> > > + int ret;
> > > + u8 value;
> > > + u8 control;
> > > +
> > > + /* The LTC2941 does not need any special handling */
> > > + if (info->id == LTC2941_ID)
> > > + return;
> > > +
> > > + /* Read control register */
> > > + ret = ltc294x_read_regs(info->client, LTC294X_REG_CONTROL, , 1);
> > > + if (ret < 0)
> > > + return;
> > > +
> > > + /* Disable continuous ADC conversion as this drains the battery */
> > > + control = LTC294X_REG_CONTROL_ADC_DISABLE(value);
> > > + if (control != value)
> > > + ltc294x_write_regs(info->client, LTC294X_REG_CONTROL,
> > > + , 1);
> > > +}
> > > +
> > >   #ifdef CONFIG_PM_SLEEP
> > >   static int ltc294x_suspend(struct device *dev)
> > > @@ -589,6 +613,7 @@ static int ltc294x_resume(struct device *dev)
> > >   },
> > >   .probe  = ltc294x_i2c_probe,
> > >   .remove = ltc294x_i2c_remove,
> > > + .shutdown   = ltc294x_i2c_shutdown,
> > >   .id_table   = ltc294x_i2c_id,
> > >   };
> > >   module_i2c_driver(ltc294x_driver);
> > > -- 
> > > 1.9.1
> > > 
> 
> 
> -- 
> Mike Looijmans
> 
> 
> Kind regards,
> 
> Mike Looijmans
> System Expert
> 
> TOPIC Products
> Materiaalweg 4, NL-5681 RJ Best
> Postbus 440, NL-5680 AK Best
> Telefoon: +31 (0) 499 33 69 79
> E-mail: mike.looijm...@topicproducts.com
> Website: www.topicproducts.com
> 
> Please consider the environment before printing this e-mail
> 
> 

Re: Regression in e1000e since Kernel 4.14.3

[Gabriel C]

On 05.12.2017 09:53, Greg KH wrote:

On Tue, Dec 05, 2017 at 09:20:33AM +0100, Gabriel C wrote:

On 05.12.2017 07:19, Greg KH wrote:

On Tue, Dec 05, 2017 at 07:18:34AM +0100, Greg KH wrote:

On Tue, Dec 05, 2017 at 12:47:10AM +0100, Gabriel C wrote:

On 04.12.2017 23:10, rwar...@gmx.de wrote:


Hallo

someone and I got an regression with e1000e since kernel 4.14.3 and it seems 
there is 4.14.4 on the way without a fix.


bug report is here:

https://bugzilla.kernel.org/show_bug.cgi?id=198047


( added stable and netdev to CC )

Yes I have a box with e1000e and it seems something at least breaks NM after 
4.14.3.


Again, can people try 4.14.5-rc1?  It should be resolved there.


Oops, that would be 4.14.4-rc1.  Any why do you say above that is on the
way without a fix, did you test it?


I didn't tested 4.14.4-rc1 but somone from the bug report tested it and told is 
not resolved.

I'll fire up an build in a bit and let you know.


Great, and maybe cc: the developers and mailing list for this driver at
the same time?  :)



Greg,

last time I reported something about e100* someone told me to just CC netdev =)

However the issue still remains with 4.14.4-rc1 and NM , and is still fine with 
connman.

I don't even think is something about the driver itself because I've quick 
compiled the out-of-tree-e1000e
and breaks with NM in the same way. ( which should not be possible ? )

Even when 4.14.3 was biggiSH :) after a quick scan and assuming the e1000e 
patches are fine , remaining candidates
should be the IRQ* and x86/* ones ?


NM seems to go in a loop setup link , kill link , setup link etc like this :

Dez 05 09:51:45 zwerg NetworkManager[807]:   [1512463905.5925] policy: 
auto-activating connection 'enp6s0_1'
Dez 05 09:51:45 zwerg NetworkManager[807]:   [1512463905.5940] device 
(enp6s0): Activation: starting connection 'enp6s0_1' 
(8a825b19-b086-3413-901c-508ee26b4138)
Dez 05 09:51:45 zwerg NetworkManager[807]:   [1512463905.5943] device 
(enp6s0): state change: disconnected -> prepare (reason 'none', sys-iface-state: 
'managed')
Dez 05 09:51:45 zwerg NetworkManager[807]:   [1512463905.5945] manager: 
NetworkManager state is now CONNECTING
Dez 05 09:51:45 zwerg NetworkManager[807]:   [1512463905.5950] device 
(enp6s0): state change: prepare -> config (reason 'none', sys-iface-state: 'managed')
Dez 05 09:51:45 zwerg NetworkManager[807]:   [1512463905.5958] device 
(enp6s0): state change: config -> ip-config (reason 'none', sys-iface-state: 
'managed')
Dez 05 09:51:45 zwerg NetworkManager[807]:   [1512463905.5962] dhcp4 
(enp6s0): activation: beginning transaction (timeout in 45 seconds)
Dez 05 09:51:45 zwerg NetworkManager[807]:   [1512463905.5980] dhcp4 
(enp6s0): dhclient started with pid 1180
Dez 05 09:51:45 zwerg dhclient[1180]: DHCPREQUEST on enp6s0 to 255.255.255.255 
port 67
Dez 05 09:51:45 zwerg dhclient[1180]: DHCPACK from 192.168.178.1
Dez 05 09:51:45 zwerg NetworkManager[807]:   [1512463905.6268] dhcp4 
(enp6s0):   address 192.168.178.21
Dez 05 09:51:45 zwerg NetworkManager[807]:   [1512463905.6268] dhcp4 
(enp6s0):   plen 24 (255.255.255.0)
Dez 05 09:51:45 zwerg NetworkManager[807]:   [1512463905.6269] dhcp4 
(enp6s0):   gateway 192.168.178.1
Dez 05 09:51:45 zwerg NetworkManager[807]:   [1512463905.6269] dhcp4 
(enp6s0):   lease time 864000
Dez 05 09:51:45 zwerg NetworkManager[807]:   [1512463905.6269] dhcp4 
(enp6s0):   nameserver '192.168.178.1'
Dez 05 09:51:45 zwerg NetworkManager[807]:   [1512463905.6270] dhcp4 
(enp6s0):   domain name 'fritz.box'
Dez 05 09:51:45 zwerg NetworkManager[807]:   [1512463905.6270] dhcp4 
(enp6s0): state changed unknown -> bound

and then :

Dez 05 09:52:17 zwerg NetworkManager[807]:   [1512463937.5788] device 
(enp6s0): state change: ip-config -> failed (reason 'ip-config-unavailable', 
sys-iface-state: 'managed')
Dez 05 09:52:17 zwerg NetworkManager[807]:   [1512463937.5792] manager: 
NetworkManager state is now DISCONNECTED
Dez 05 09:52:17 zwerg NetworkManager[807]:   [1512463937.5794] policy: 
disabling autoconnect for connection 'enp6s0_1'.
Dez 05 09:52:17 zwerg NetworkManager[807]:   [1512463937.5798] device 
(enp6s0): Activation: failed for connection 'enp6s0_1'
Dez 05 09:52:17 zwerg NetworkManager[807]:   [1512463937.5807] device 
(enp6s0): state change: failed -> disconnected (reason 'none', sys-iface-state: 
'managed')
Dez 05 09:52:17 zwerg NetworkManager[807]:   [1512463937.5899] dhcp4 
(enp6s0): canceled DHCP transaction, DHCP client pid 1180
Dez 05 09:52:17 zwerg NetworkManager[807]:   [1512463937.5899] dhcp4 
(enp6s0): state changed bound -> done

...

With connman all is fine and the connection is stable so the driver itself 
seems fine..

Re: [PATCH 5/5] PCI: cadence: add EndPoint Controller driver for Cadence PCIe controller

[Kishon Vijay Abraham I]

Hi,

On Friday 01 December 2017 05:50 PM, Lorenzo Pieralisi wrote:
> On Thu, Nov 23, 2017 at 04:01:50PM +0100, Cyrille Pitchen wrote:
>> This patch adds support to the Cadence PCIe controller in endpoint mode.
> 
> Please add a brief description to the log to describe the most salient
> features.
> 
>> Signed-off-by: Cyrille Pitchen 
>> ---
>>  drivers/pci/cadence/Kconfig   |   9 +
>>  drivers/pci/cadence/Makefile  |   1 +
>>  drivers/pci/cadence/pcie-cadence-ep.c | 553 
>> ++
>>  3 files changed, 563 insertions(+)
>>  create mode 100644 drivers/pci/cadence/pcie-cadence-ep.c
>>
>> diff --git a/drivers/pci/cadence/Kconfig b/drivers/pci/cadence/Kconfig
>> index 120306cae2aa..b2e6af71f39e 100644
>> --- a/drivers/pci/cadence/Kconfig
>> +++ b/drivers/pci/cadence/Kconfig
>> @@ -21,4 +21,13 @@ config PCIE_CADENCE_HOST
>>mode. This PCIe controller may be embedded into many different vendors
>>SoCs.
>>  
>> +config PCIE_CADENCE_EP
>> +bool "Cadence PCIe endpoint controller"
>> +depends on PCI_ENDPOINT
>> +select PCIE_CADENCE
>> +help
>> +  Say Y here if you want to support the Cadence PCIe  controller in
>> +  endpoint mode. This PCIe controller may be embedded into many
>> +  different vendors SoCs.
>> +
>>  endif # PCI_CADENCE
>> diff --git a/drivers/pci/cadence/Makefile b/drivers/pci/cadence/Makefile
>> index d57d192d2595..61e9c8d6839d 100644
>> --- a/drivers/pci/cadence/Makefile
>> +++ b/drivers/pci/cadence/Makefile
>> @@ -1,2 +1,3 @@
>>  obj-$(CONFIG_PCIE_CADENCE) += pcie-cadence.o
>>  obj-$(CONFIG_PCIE_CADENCE_HOST) += pcie-cadence-host.o
>> +obj-$(CONFIG_PCIE_CADENCE_EP) += pcie-cadence-ep.o
>> diff --git a/drivers/pci/cadence/pcie-cadence-ep.c 
>> b/drivers/pci/cadence/pcie-cadence-ep.c
>> new file mode 100644
>> index ..a1d761101a9c
>> --- /dev/null
>> +++ b/drivers/pci/cadence/pcie-cadence-ep.c
>> @@ -0,0 +1,553 @@
>> +/*
>> + * Cadence PCIe host controller driver.
> 
> You should update this comment.
> 
>> + *
>> + * Copyright (c) 2017 Cadence
>> + *
>> + * Author: Cyrille Pitchen 
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License version 2 as
>> + * published by the Free Software Foundation.
>> + *
>> + * This program is distributed in the hope that it will be useful,
>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
>> + * GNU General Public License for more details.
>> + *
>> + * You should have received a copy of the GNU General Public License along 
>> with
>> + * this program.  If not, see .
>> + */
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
> 
> Nit: alphabetical order.
> 
>> +#include "pcie-cadence.h"
>> +
>> +#define CDNS_PCIE_EP_MIN_APERTURE   128 /* 128 bytes */
>> +#define CDNS_PCIE_EP_IRQ_PCI_ADDR_NONE  0x1
>> +#define CDNS_PCIE_EP_IRQ_PCI_ADDR_LEGACY0x3
>> +
>> +/**
>> + * struct cdns_pcie_ep_data - hardware specific data
>> + * @max_regions: maximum nmuber of regions supported by hardware
> 
> s/nmuber/number
> 
>> + */
>> +struct cdns_pcie_ep_data {
>> +size_t  max_regions;
>> +};
>> +
>> +/**
>> + * struct cdns_pcie_ep - private data for this PCIe endpoint controller 
>> driver
>> + * @pcie: Cadence PCIe controller
>> + * @data: pointer to a 'struct cdns_pcie_data'
>> + */
>> +struct cdns_pcie_ep {
>> +struct cdns_pciepcie;
>> +const struct cdns_pcie_ep_data  *data;
>> +struct pci_epc  *epc;
>> +unsigned long   ob_region_map;
>> +phys_addr_t *ob_addr;
>> +phys_addr_t irq_phys_addr;
>> +void __iomem*irq_cpu_addr;
>> +u64 irq_pci_addr;
>> +u8  irq_pending;
>> +};
>> +
>> +static int cdns_pcie_ep_write_header(struct pci_epc *epc,
>> + struct pci_epf_header *hdr)
>> +{
>> +struct cdns_pcie_ep *ep = epc_get_drvdata(epc);
>> +struct cdns_pcie *pcie = >pcie;
>> +u8 fn = 0;
>> +
>> +if (fn == 0) {
> 
> I think there is some code to retrieve fn missing here.

hmm.. the endpoint core has to send the function number which right now it's
not doing though it has the function number info in pci_epf.
> 
>> +u32 id = CDNS_PCIE_LM_ID_VENDOR(hdr->vendorid) |
>> + CDNS_PCIE_LM_ID_SUBSYS(hdr->subsys_vendor_id);
>> +cdns_pcie_writel(pcie, CDNS_PCIE_LM_ID, id);
>> +}
>> +cdns_pcie_ep_fn_writew(pcie, fn, PCI_DEVICE_ID, hdr->deviceid);
>> +cdns_pcie_ep_fn_writeb(pcie, fn, PCI_REVISION_ID, hdr->revid);
>> +

[PATCH] ARM: multi_v7_defconfig: Add configs for peripherals on Keystone2 SoCs

[Vignesh R]

Enable Cadence QSPI present on 66AK2G SoC and Keystone USB PHY driver
for K2E.

Signed-off-by: Vignesh R 
---
 arch/arm/configs/multi_v7_defconfig | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/configs/multi_v7_defconfig 
b/arch/arm/configs/multi_v7_defconfig
index 992a8a5da065..c4f4f6682ea5 100644
--- a/arch/arm/configs/multi_v7_defconfig
+++ b/arch/arm/configs/multi_v7_defconfig
@@ -185,6 +185,7 @@ CONFIG_MTD_NAND_BRCMNAND=y
 CONFIG_MTD_NAND_VF610_NFC=y
 CONFIG_MTD_NAND_DAVINCI=y
 CONFIG_MTD_SPI_NOR=y
+CONFIG_SPI_CADENCE_QUADSPI=m
 CONFIG_SPI_FSL_QUADSPI=m
 CONFIG_MTD_UBI=y
 CONFIG_BLK_DEV_LOOP=y
@@ -675,6 +676,7 @@ CONFIG_USB_CHIPIDEA_HOST=y
 CONFIG_USB_ISP1760=y
 CONFIG_USB_HSIC_USB3503=y
 CONFIG_AB8500_USB=y
+CONFIG_KEYSTONE_USB_PHY=m
 CONFIG_NOP_USB_XCEIV=m
 CONFIG_USB_GPIO_VBUS=y
 CONFIG_USB_ISP1301=y
-- 
2.15.1

b1cbacc866 ("x86/smpboot: Do not use smp_num_siblings in .."): divide error: 0000 [#1] SMP DEBUG_PAGEALLOC

[kernel test robot]

7ec8323 --
git bisect  bad 60f97903c07c2f9dec16f3434fa6bc8374553c75  # 07:54  B  0 
1   15   0  Merge 'krzk/for-next' into devel-catchup-201712050639
git bisect  bad c5ae250423192c95979baa9e26553078c6fbdb12  # 09:33  B  0     
5   19   0  Merge 
'linux-review/yuan-linyu/netlink-optimize-err-assignment/20171205-051606' into 
devel-catchup-201712050639
git bisect  bad d45ca31b78f444ff0f7c6dbd56df9c75991b1748  # 10:16  B  0 
6   20   0  Merge 'jcmvbkbc-xtensa/xtensa-ssp-kasan' into 
devel-catchup-201712050639
git bisect good 9b490c677dc4246f6f2adad29d94a71a25f492a8  # 10:49  G 10 
00   1  Merge 'abelloni/at91-dt-fixes' into devel-catchup-201712050639
git bisect good fcfab2f4b076cdd0c000c2e1a30404e4007c2c06  # 11:13  G 11 
00   0  Merge 'abelloni/at91-dt' into devel-catchup-201712050639
git bisect  bad b9115db1d525e5a59a515ec6ffc53e5163b53f9b  # 11:52  B  0
10   24   0  Merge 'tip/x86/urgent' into devel-catchup-201712050639
git bisect good 2b67799bdf25d19690710a88c2bce9127cf3ba6f  # 12:16  G 10 
00   0  x86: Make X86_BUG_FXSAVE_LEAK detectable in CPUID on AMD
git bisect good 866a79a1c98c5004a410122b06f808152f2fe53c  # 12:53  G 11 
00   0  x86/microcode/AMD: Add support for fam17h microcode loading
git bisect  bad 2ee90363a838cf41ebf1ad24bad274762e467d8d  # 13:15  B  0 
3   17   0  x86 / PCI: Make broadcom_postcore_init() check acpi_disabled
git bisect  bad b1cbacc8663a4dce62e4ae501e859c82f4aeb1ca  # 13:39  B  0 
1   15   0  x86/smpboot: Do not use smp_num_siblings in __max_logical_packages 
calculation
# first bad commit: [b1cbacc8663a4dce62e4ae501e859c82f4aeb1ca] x86/smpboot: Do 
not use smp_num_siblings in __max_logical_packages calculation
git bisect good 866a79a1c98c5004a410122b06f808152f2fe53c  # 13:55  G 31 
00   0  x86/microcode/AMD: Add support for fam17h microcode loading
# extra tests with debug options
git bisect  bad b1cbacc8663a4dce62e4ae501e859c82f4aeb1ca  # 14:22  B  0
11   25   0  x86/smpboot: Do not use smp_num_siblings in __max_logical_packages 
calculation
# extra tests on HEAD of linux-devel/devel-catchup-201712050639
git bisect  bad a2b385361ab06450408875fe58a45445ed300a40  # 14:22  B  0
21   38   0  0day head guard for 'devel-catchup-201712050639'
# extra tests on tree/branch tip/x86/urgent
git bisect  bad cdf577209aad4cdbe3455d3efa6cf631f838c55d  # 14:37  B  0 
1   15   0  x86/power: Fix some ordering bugs in __restore_processor_context()
# extra tests with first bad commit reverted
git bisect good 886fa2f68001f51d63c3934943f4a844faaa5e8f  # 15:15  G 11 
00   0  Revert "x86/smpboot: Do not use smp_num_siblings in 
__max_logical_packages calculation"
# extra tests on tree/branch tip/master
git bisect good 5b33501b13ab807284ae73492938d162e0f8629e  # 15:59  G 10 
00   0  Merge branch 'WIP.x86/mm'

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


dmesg-yocto-lkp-nhm-dp1-10:20171205133919:x86_64-randconfig-s0-12050632:4.14.0-01223-gb1cbacc:1.gz
Description: application/gzip
#!/bin/bash

kernel=$1

kvm=(
qemu-system-x86_64
-enable-kvm
-kernel $kernel
-m 512
-smp 1
-device e1000,netdev=net0
-netdev user,id=net0
-boot order=nc
-no-reboot
-watchdog i6300esb
-watchdog-action debug
-rtc base=localtime
-serial stdio
-display none
-monitor null
)

append=(
root=/dev/ram0
hung_task_panic=1
debug
apic=debug
sysrq_always_enabled
rcupdate.rcu_cpu_stall_timeout=100
net.ifnames=0
printk.devkmsg=on
panic=-1
softlockup_panic=1
nmi_watchdog=panic
oops=panic
load_ramdisk=2
prompt_ramdisk=0
drbd.minor_count=8
systemd.log_level=err
ignore_loglevel
console=tty0
earlyprintk=ttyS0,115200
console=ttyS0,115200
vga=normal
rw
drbd.minor_count=8
)

"${kvm[@]}" -append "${append[*]}"
#
# Automatically generated file; DO NOT EDIT.
# Linux/x86_64 4.14.0 Kernel Configuration
#
CONFIG_64BIT=y
CONFIG_X86_64=y
CONFIG_X86=y
CONFIG_INSTRUCTION_DECODER=y
CONFIG_OUTPUT_FORMAT="elf64-x86-64"
CONFIG_ARCH_DEFCONFIG="arch/x86/configs/x86_64_defconfig"
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_MMU=y
CONFIG_ARCH_MMAP_RND_BITS_MIN=28
CONFIG_ARCH_MMAP_RND_BITS_MAX=32
CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MIN=8
CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MAX=16
CONFIG_NEED_DMA_MAP_STATE=y
CONFIG_NEED_SG_DMA_LENGTH=y
CONFIG_GENERIC_BUG=y
CONFIG_GENERIC_BUG_RELATIVE_POINTERS=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_ARCH_HAS_CPU_RELAX=y
CONFIG_ARCH_HAS_

Re: [PATCH v2] sunxi-rsb: Include OF based modalias in device uevent

[Maxime Ripard]

On Tue, Dec 05, 2017 at 03:28:25PM +0800, Chen-Yu Tsai wrote:
> Hi,
> 
> On Tue, Nov 28, 2017 at 11:47 PM, Maxime Ripard
>  wrote:
> > On Mon, Nov 27, 2017 at 08:05:34PM +0100, Stefan Brüns wrote:
> >> Include the OF-based modalias in the uevent sent when registering devices
> >> on the sunxi RSB bus, so that user space has a chance to autoload the
> >> kernel module for the device.
> >>
> >> Fixes a regression caused by commit 3f241bfa60bd ("arm64: allwinner: a64:
> >> pine64: Use dcdc1 regulator for mmc0"). When the axp20x-rsb module for
> >> the AXP803 PMIC is built as a module, it is not loaded and the system
> >> ends up with an disfunctional MMC controller.
> >>
> 
> Tags should be:
> 
> Fixes: d787dcdb9c8f ("bus: sunxi-rsb: Add driver for Allwinner Reduced
> Serial Bus")
> Cc: stable  # 4.4.x 7a3b7cd332db of: device:
> Export of_device_{get_modalias, uvent_modalias} to modules
> 
> >> Cc: stable 
> >> Signed-off-by: Stefan Brüns 
> >
> > Acked-by: Maxime Ripard 
> 
> Acked-by: Chen-Yu Tsai 
> 
> Maxime, could you merge this as a fix to get it in fast?

Applied, thanks!

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com


signature.asc
Description: PGP signature

Re: [PATCH] ARM: dts: sunxi: Convert to CCU index macros for HDMI controller

[Maxime Ripard]

Hi,

On Mon, Dec 04, 2017 at 04:44:01PM +0800, Chen-Yu Tsai wrote:
> When the HDMI controller device node was added, the needed PLL clock
> macros were not exported. A separate patch addresses that, but it is
> merged through a different tree.
> 
> Now that both patches are in mainline proper, we can convert the raw
> numbers to proper macros.
> 
> Signed-off-by: Chen-Yu Tsai 

Applied, thanks!
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com


signature.asc
Description: PGP signature

[PATCH v3 0/4] kaslr: add new parameter immovable_mem=nn[KMG]@ss[KMG] to make memory hotplug work well with kaslr

[Chao Fan]

Here is a problem:
Here is a machine with several NUMA nodes and some of them are
hot-pluggable. It's not good for kernel to be extracted in the memory
region of movable node. But in current code, I print the address chosen by
kaslr and found it may be placed in movable node sometimes.
To solve this problem, it's better to limit the memory region chosen by
kaslr to immovable node in kaslr.c. But the memory information about if
it's hot-pluggable is stored in ACPI SRAT table, which is parsed after
kernel is extracted. So we can't get the detail memory information
before extracting kernel.

So add the new parameter immovable_mem=nn@ss, in which nn means
the size of memory in *immovable* node, and ss means the start position of
this memory region. Then limit kaslr choose memory in these regions.

There are two policies:
1. Specify the memory region in *movable* node to avoid:
   Then we can use the existing mem_avoid to handle. But if the memory
   on movable node was separated by memory hole or different movable nodes
   are discontinuous, we don't know how many regions need to avoid.
   OTOH, we must avoid all of the movable memory, otherwise, kaslr may
   choose the wrong place.
2. Specify the memory region in *immovable* node to select:
   Only support 4 regions in this parameter. Then user can use two nodes
   at least for kaslr to choose, it's enough for the kernel to extract.
   At the same time, because we need only 4 new mem_vector, the usage
   of memory here is not too big. So I think this way is better, and this 
   patchset is based on this policy.

PATCH 1/4 parse the new parameter immovable_mem=nn[KMG]@ss[KMG], then
  store the memory regions.
PATCH 2/4 select the memory region in immovable node when process
  memmap.
PATCH 3/4 skip mirror feature if movable_node or immovable_mem specified.
PATCH 4/4 add document.

v1->v2:
Follow Dou Liyang's suggestion:
 - Add the parse for movable_node=nn[KMG] without @ss[KMG]
 - Fix the bug for more than one "movable_node=" specified
 - Drop useless variables and use mem_vector region directely
 - Add more comments.

v2->v3:
Follow Baoquan He's suggestion:
 - Change names of several functions.
 - Add a new parameter "immovable_mem" instead of extending mvoable_node
 - Use the clamp to calculate the memory intersecting, which makes
   logical more clear.
 - Disable memory mirror if movable_node specified


Chao Fan (4):
  kaslr: add immovable_mem=nn[KMG]@ss[KMG] to specify extracting memory
  kaslr: calculate the memory region in immovable node
  kaslr: disable memory mirror feature when movable_node specified
  document: change the document for immovable_mem

 Documentation/admin-guide/kernel-parameters.txt |   9 ++
 arch/x86/boot/compressed/kaslr.c| 154 +---
 2 files changed, 147 insertions(+), 16 deletions(-)

-- 
2.14.3

[PATCH] mtd: nand: cafe: clean up DMA address setup

[Masahiro Yamada]

Use macros from  to make the code readable.
The compiler warning will be kept suppressed.

Signed-off-by: Masahiro Yamada 
---

 drivers/mtd/nand/cafe_nand.c | 8 ++--
 1 file changed, 2 insertions(+), 6 deletions(-)

diff --git a/drivers/mtd/nand/cafe_nand.c b/drivers/mtd/nand/cafe_nand.c
index add4613..2af5e35 100644
--- a/drivers/mtd/nand/cafe_nand.c
+++ b/drivers/mtd/nand/cafe_nand.c
@@ -737,12 +737,8 @@ static int cafe_nand_probe(struct pci_dev *pdev,
}
 
/* Set up DMA address */
-   cafe_writel(cafe, cafe->dmaaddr & 0x, NAND_DMA_ADDR0);
-   if (sizeof(cafe->dmaaddr) > 4)
-   /* Shift in two parts to shut the compiler up */
-   cafe_writel(cafe, (cafe->dmaaddr >> 16) >> 16, NAND_DMA_ADDR1);
-   else
-   cafe_writel(cafe, 0, NAND_DMA_ADDR1);
+   cafe_writel(cafe, lower_32_bits(cafe->dmaaddr), NAND_DMA_ADDR0);
+   cafe_writel(cafe, upper_32_bits(cafe->dmaaddr), NAND_DMA_ADDR1);
 
cafe_dev_dbg(>pdev->dev, "Set DMA address to %x (virt %p)\n",
cafe_readl(cafe, NAND_DMA_ADDR0), cafe->dmabuf);
-- 
2.7.4

Re: [GIT PULL] hash addresses printed with %p

[Greg Kroah-Hartman]

On Tue, Dec 05, 2017 at 04:45:37PM +0800, Dave Young wrote:
> On 12/05/17 at 09:09am, Greg Kroah-Hartman wrote:
> > On Tue, Dec 05, 2017 at 01:14:34PM +0800, Dave Young wrote:
> > > On 12/04/17 at 03:00pm, Greg Kroah-Hartman wrote:
> > > > On Mon, Dec 04, 2017 at 12:51:13PM +, David Laight wrote:
> > > > > From: Ard Biesheuvel
> > > > > > Sent: 04 December 2017 10:03
> > > > > ...
> > > > > > and uses __ATTR_RO() to emit initializers for it. __ATTR() 
> > > > > > initializes
> > > > > > the .store member as well, which does not exists, and so it cannot 
> > > > > > be
> > > > > > used directly.
> > > > > > 
> > > > > > So we should either add a .store member that is always NULL, or we
> > > > > > should add our own
> > > > > > 
> > > > > > #define __ATTR_0400(_name) { \
> > > > > > .attr = { .name = __stringify(_name), .mode = 0400 }, \
> > > > > > .show = _name##_show, \
> > > > > > }
> > > > > 
> > > > > What about an __ATTR_RO_MODE(name, mode) that doesn't set the .store 
> > > > > member.
> > > > > Even if the mode allowed write, writes wouldn't happen.
> > > > 
> > > > Ah, that might work, could you convert the other users of __ATTR() in
> > > > the efi code to use it as well?
> > > 
> > > $ grep __ATTR * -RI
> > > efi.c:__ATTR(systab, 0400, systab_show, NULL);
> > > efi.c:static struct kobj_attribute efi_attr_fw_vendor = 
> > > __ATTR_RO(fw_vendor);
> > > efi.c:static struct kobj_attribute efi_attr_runtime = __ATTR_RO(runtime);
> > > efi.c:static struct kobj_attribute efi_attr_config_table = 
> > > __ATTR_RO(config_table);
> > > efi.c:__ATTR_RO(fw_platform_size);
> > > esrt.c:static struct esre_attribute esre_fw_class = __ATTR(fw_class, 0400,
> > > esrt.c:static struct esre_attribute esre_##name = __ATTR(name, 0400, \
> > > esrt.c:static struct kobj_attribute esrt_##name = __ATTR(name, 0400, \
> > > runtime-map.c:static struct map_attribute map_type_attr = __ATTR_RO(type);
> > > runtime-map.c:static struct map_attribute map_phys_addr_attr   = 
> > > __ATTR_RO(phys_addr);
> > > runtime-map.c:static struct map_attribute map_virt_addr_attr  = 
> > > __ATTR_RO(virt_addr);
> > > runtime-map.c:static struct map_attribute map_num_pages_attr  = 
> > > __ATTR_RO(num_pages);
> > > runtime-map.c:static struct map_attribute map_attribute_attr  = 
> > > __ATTR_RO(attribute);
> > > 
> > > Above is all the __ATTR users for drivers/firmware/efi/*, it makes sense
> > > to update all __ATTR_RO to __ATTR_RO_MODE, so efi.c, runtime-map.c, and
> > > drivers/firmware/dmi-sysfs.c can be updated.  But esrt.c __ATTR seems
> > > not necessary.
> > > 
> > > And if so __ATTR_RO_MODE(name, mode) still needs go to sysfs.h.
> > > 
> > > I can do it but need confirm, Is this what you prefer?
> > 
> > Yes, how about the patch below, it builds for me, haven't done anything
> > other than that to test it :)
> 
> Thanks! Let me do a kexec test and a boot test for esrt.
> 
> > 
> > Also, what's with the multi-line sysfs file systab?  That's really not
> > allowed, can you please remove it?  Also the first check for !kobj and
> > !buf is funny, that can never happen.
> 
> I thought to do that, but later worried about it will break things:
> http://lists.infradead.org/pipermail/kexec/2013-December/010759.html

Heh, I guess I complained about this in the past :)

So what userspace tool uses it?

Are these values all exported through sysfs already?  If not, do that
first.

> I also thought to add code comment to avoid future expanding of this
> file. Maybe we can do this now.

Please do, but it should be a separate patch.

thanks,

greg k-h

[PATCH v3 4/4] document: change the document for immovable_mem

[Chao Fan]

Add the document for the change of new parameter
immovable_mem=nn[KMG]@ss[KMG].

Cc: linux-...@vger.kernel.org
Cc: Jonathan Corbet 
Signed-off-by: Chao Fan 
---
 Documentation/admin-guide/kernel-parameters.txt | 9 +
 1 file changed, 9 insertions(+)

diff --git a/Documentation/admin-guide/kernel-parameters.txt 
b/Documentation/admin-guide/kernel-parameters.txt
index b74e13312fdc..eea755af697f 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -2355,6 +2355,15 @@
allocations which rules out almost all kernel
allocations. Use with caution!
 
+   immovable_mem=nn[KMG]@ss[KMG]
+   [KNL] Force usage of a specific region of memory.
+   Make memory hotplug  work well with KASLR.
+   Region of memory in immovable node is from ss to ss+nn.
+   Multiple regions can be specified, comma delimited.
+   Notice: we support 4 regions at most now.
+   Example:
+   immovable_mem=1G,500M@2G,1G@4G
+
MTD_Partition=  [MTD]
Format: ,,,
 
-- 
2.14.3

Re: [PATCH 0/3] pwm: meson-axg: add pwm controller driver

[Thierry Reding]

On Mon, Dec 04, 2017 at 02:00:15PM +0800, Yixun Lan wrote:
> This patch series try to add PWM controller driver for the 
> Amlogic's Meson-AXG SoC. Update the Clock sources, pin DT.
> 
> Jian Hu (3):
>   dt-bindings: pwm: update bindings for the Meson-AXG
>   pwm: meson: add clock source configuratin for Meson-AXG

Applied both of these, thanks.

Thierry


signature.asc
Description: PGP signature

Re: [PATCH v2] mmap.2: MAP_FIXED updated documentation

[Michal Hocko]

On Mon 04-12-17 23:42:00, John Hubbard wrote:
> On 12/04/2017 11:05 PM, Michal Hocko wrote:
> > On Mon 04-12-17 18:14:18, John Hubbard wrote:
> >> On 12/04/2017 02:55 AM, Cyril Hrubis wrote:
> >>> Hi!
> >>> I know that we are not touching the rest of the existing description for
> >>> MAP_FIXED however the second sentence in the manual page says that "addr
> >>> must be a multiple of the page size." Which however is misleading as
> >>> this is not enough on some architectures. Code in the wild seems to
> >>> (mis)use SHMLBA for aligment purposes but I'm not sure that we should
> >>> advise something like that in the manpages.
> >>>
> >>> So what about something as:
> >>>
> >>> "addr must be suitably aligned, for most architectures multiple of page
> >>> size is sufficient, however some may impose additional restrictions for
> >>> page mapping addresses."
> >>>
> >>
> >> Hi Cyril,
> >>
> >> Right, so I've been looking into this today, and I think we can go a bit
> >> further than that, even. The kernel, as far back as the *original* git
> >> commit in 2005, implements mmap on ARM by requiring that the address is
> >> aligned to SHMLBA:
> >>
> >> arch/arm/mm/mmap.c:50:
> >>
> >>if (flags & MAP_FIXED) {
> >>if (aliasing && flags & MAP_SHARED &&
> >>(addr - (pgoff << PAGE_SHIFT)) & (SHMLBA - 1))
> >>return -EINVAL;
> >>return addr;
> >>}
> >>
> >> So, given that this has been the implementation for the last 12+ years (and
> >> probably the whole time, in fact), I think we can be bold enough to use 
> >> this
> >> wording for the second sentence of MAP_FIXED:
> >>
> >> "addr must be a multiple of SHMLBA (), which in turn is either
> >> the system page size (on many architectures) or a multiple of the system
> >> page size (on some architectures)."
> >>
> >> What do you think?
> > 
> > I am not sure this is a good idea. This is pulling way too many
> > implementation details into the man page IMHO. Note that your wording is
> > even incorrect because this applies only to shared mappings and on some
> > architectures it even requires special memory regions. We do not want
> > all that in the man page...
> > 
> 
> Hi Michal,
> 
> OK, so it sounds like Cyril's original wording would be just about right,
> after all, like this?
> 
> "addr must be suitably aligned. For most architectures multiple of page
> size is sufficient; however, some may impose additional restrictions."
> 
> (It does seem unfortunate that the man page cannot help the programmer
> actually write correct code here. He or she is forced to read the kernel
> implementation, in order to figure out the true alignment rules. I was
> hoping we could avoid that.)

I strongly suspect that this is more the architecture than the kernel
implementation imposed restriction.
-- 
Michal Hocko
SUSE Labs

Re: [PATCH v4 02/10] pinctrl: axp209: add pinctrl features

[Maxime Ripard]

Hi,

On Mon, Dec 04, 2017 at 09:07:52AM +0100, Quentin Schulz wrote:
> >> +static int axp20x_pmx_set_mux(struct pinctrl_dev *pctldev,
> >> +unsigned int function, unsigned int group)
> >> +{
> >> +  struct axp20x_gpio *gpio = pinctrl_dev_get_drvdata(pctldev);
> >> +  unsigned int mask;
> >> +
> >> +  /* Every pin supports GPIO_OUT and GPIO_IN functions */
> >> +  if (function <= AXP20X_FUNC_GPIO_IN)
> >> +  return axp20x_pmx_set(pctldev, group,
> >> +gpio->funcs[function].muxval);
> >> +
> >> +  if (function == AXP20X_FUNC_LDO)
> >> +  mask = gpio->desc->ldo_mask;
> >> +  else
> >> +  mask = gpio->desc->adc_mask;
> > 
> > What is the point of this test...
> > 
> >> +  if (!(BIT(group) & mask))
> >> +  return -EINVAL;
> >> +
> >> +  /*
> >> +   * We let the regulator framework handle the LDO muxing as muxing bits
> >> +   * are basically also regulators on/off bits. It's better not to enforce
> >> +   * any state of the regulator when selecting LDO mux so that we don't
> >> +   * interfere with the regulator driver.
> >> +   */
> >> +  if (function == AXP20X_FUNC_LDO)
> >> +  return 0;
> > 
> > ... if you know that you're not going to do anything with one of the
> > outcomes. It would be better to just move that part above, instead of
> > doing the same test twice.
> > 
> 
> Return value is different. In one case, it is an error to request "ldo"
> for a pin that does not support it. In the other case, the ldo request
> is valid but nothing's done on driver side.
> 
> Both cases are handled differently by the core:
> http://elixir.free-electrons.com/linux/latest/source/drivers/pinctrl/pinmux.c#L439
> 
> I think that's the behavior we're expecting from this driver.

Ah, right.

> Or maybe you're asking to do:
> 
> + if (function == AXP20X_FUNC_LDO) {
> + if (!(BIT(group) & gpio->desc->ldo_mask))
> + return -EINVAL;
> + return 0;
> + } else if (!(BIT(group) & gpio->desc->adc_mask)) {
> + return -EINVAL;
> + }
> 
> ?

No, it's definitely better the way you did it.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com


signature.asc
Description: PGP signature

[PATCH v3 1/4] kaslr: add immovable_mem=nn[KMG]@ss[KMG] to specify extracting memory

[Chao Fan]

In current code, kaslr may choose the memory region in movable
nodes to extract kernel, which will make the nodes can't be hot-removed.
To solve it, we can specify the memory region in immovable node.
Create immovable_mem to store the regions in immovable_mem, where should
be chosen by kaslr.

Multiple regions can be specified, comma delimited.
Considering the usage of memory, only support for 4 regions.
4 regions contains 2 nodes at least, enough for kernel to extract.

Also change the "handle_mem_memmap" to "handle_mem_filter", since
it will not only handle memmap parameter now.

Signed-off-by: Chao Fan 
---
 arch/x86/boot/compressed/kaslr.c | 80 ++--
 1 file changed, 77 insertions(+), 3 deletions(-)

diff --git a/arch/x86/boot/compressed/kaslr.c b/arch/x86/boot/compressed/kaslr.c
index a63fbc25ce84..0bbbaf5f6370 100644
--- a/arch/x86/boot/compressed/kaslr.c
+++ b/arch/x86/boot/compressed/kaslr.c
@@ -108,6 +108,15 @@ enum mem_avoid_index {
 
 static struct mem_vector mem_avoid[MEM_AVOID_MAX];
 
+/* Only supporting at most 4 immovable memory regions with kaslr */
+#define MAX_IMMOVABLE_MEM  4
+
+/* Store the memory regions in immovable node */
+static struct mem_vector immovable_mem[MAX_IMMOVABLE_MEM];
+
+/* The immovable regions user specify, not more than 4 */
+static int num_immovable_region;
+
 static bool mem_overlaps(struct mem_vector *one, struct mem_vector *two)
 {
/* Item one is entirely before item two. */
@@ -168,6 +177,38 @@ parse_memmap(char *p, unsigned long long *start, unsigned 
long long *size)
return -EINVAL;
 }
 
+static int parse_immovable_mem(char *p,
+  unsigned long long *start,
+  unsigned long long *size)
+{
+   char *oldp;
+
+   if (!p)
+   return -EINVAL;
+
+   oldp = p;
+   *size = memparse(p, );
+   if (p == oldp)
+   return -EINVAL;
+
+   /* We support nn[KMG]@ss[KMG] and nn[KMG]. */
+   switch (*p) {
+   case '@':
+   *start = memparse(p + 1, );
+   return 0;
+   default:
+   /*
+* If w/o offset, only size specified, immovable_mem=nn[KMG]
+* has the same behaviour as immovable_mem=nn[KMG]@0. It means
+* the region starts from 0.
+*/
+   *start = 0;
+   return 0;
+   }
+
+   return -EINVAL;
+}
+
 static void mem_avoid_memmap(char *str)
 {
static int i;
@@ -207,7 +248,37 @@ static void mem_avoid_memmap(char *str)
memmap_too_large = true;
 }
 
-static int handle_mem_memmap(void)
+#ifdef CONFIG_MEMORY_HOTPLUG
+static void parse_immovable_mem_regions(char *str)
+{
+   static int i;
+
+   while (str && (i < MAX_IMMOVABLE_MEM)) {
+   int rc;
+   unsigned long long start, size;
+   char *k = strchr(str, ',');
+
+   if (k)
+   *k++ = 0;
+
+   rc = parse_immovable_mem(str, , );
+   if (rc < 0)
+   break;
+   str = k;
+
+   immovable_mem[i].start = start;
+   immovable_mem[i].size = size;
+   i++;
+   }
+   num_immovable_region = i;
+}
+#else
+static inline void parse_immovable_mem_regions(char *str)
+{
+}
+#endif
+
+static int handle_mem_filter(void)
 {
char *args = (char *)get_cmd_line_ptr();
size_t len = strlen((char *)args);
@@ -215,7 +286,8 @@ static int handle_mem_memmap(void)
char *param, *val;
u64 mem_size;
 
-   if (!strstr(args, "memmap=") && !strstr(args, "mem="))
+   if (!strstr(args, "memmap=") && !strstr(args, "mem=") &&
+   !strstr(args, "immovable_mem="))
return 0;
 
tmp_cmdline = malloc(len + 1);
@@ -240,6 +312,8 @@ static int handle_mem_memmap(void)
 
if (!strcmp(param, "memmap")) {
mem_avoid_memmap(val);
+   } else if (!strcmp(param, "immovable_mem")) {
+   parse_immovable_mem_regions(val);
} else if (!strcmp(param, "mem")) {
char *p = val;
 
@@ -379,7 +453,7 @@ static void mem_avoid_init(unsigned long input, unsigned 
long input_size,
/* We don't need to set a mapping for setup_data. */
 
/* Mark the memmap regions we need to avoid */
-   handle_mem_memmap();
+   handle_mem_filter();
 
 #ifdef CONFIG_X86_VERBOSE_BOOTUP
/* Make sure video RAM can be used. */
-- 
2.14.3

Re: [PATCH 0/3] thunderbolt fixes for v4.15-rc2

[Greg Kroah-Hartman]

On Tue, Dec 05, 2017 at 10:49:13AM +0200, Mika Westerberg wrote:
> On Fri, Dec 01, 2017 at 03:08:02PM +0300, Mika Westerberg wrote:
> > Hi Greg,
> > 
> > Here are two Thunderbolt fixes and one related MAINTAINERS update for the
> > next -rc:
> > 
> > - Use shorter path for force_power attribute in thunderbolt.rst
> > - Ring interrupts were not masked properly when Rx polling starts
> > - Add thunderbolt.rst to the Thunderbolt driver MAINTAINERS entry
> > 
> > Thanks!
> 
> Hi Greg,
> 
> I wonder if I missed something in this series? These are fixes I picked
> up to my tree and then forwarded to you to be included in your char-misc
> repository for -rc.

I was traveling all last week, please give me a chance to catch up on
patches :)

thanks,

greg k-h

[PATCH v3 2/4] kaslr: calculate the memory region in immovable node

[Chao Fan]

If there is no immovable memory region specified, go on the old code.
There are several conditons:
1. CONFIG_MEMORY_HOTPLUG is not specified to y.
2. immovable_mem= is not specified.

Otherwise, calculate the intersecting between memmap entry and
immovable memory.

Signed-off-by: Chao Fan 
---
 arch/x86/boot/compressed/kaslr.c | 59 ++--
 1 file changed, 51 insertions(+), 8 deletions(-)

diff --git a/arch/x86/boot/compressed/kaslr.c b/arch/x86/boot/compressed/kaslr.c
index 0bbbaf5f6370..e3a3b6132da0 100644
--- a/arch/x86/boot/compressed/kaslr.c
+++ b/arch/x86/boot/compressed/kaslr.c
@@ -635,6 +635,39 @@ static void process_mem_region(struct mem_vector *entry,
}
 }
 
+static bool process_immovable_mem(struct mem_vector region,
+ unsigned long long minimum,
+ unsigned long long image_size)
+{
+   int i;
+
+   /*
+* Walk all immovable regions, and filter the intersection
+* to process_mem_region.
+*/
+   for (i = 0; i < num_immovable_region; i++) {
+   struct mem_vector entry;
+   unsigned long long start, end, entry_end;
+
+   start = immovable_mem[i].start;
+   end = start + immovable_mem[i].size;
+
+   entry.start = clamp(region.start, start, end);
+   entry_end = clamp(region.start + region.size, start, end);
+
+   if (entry.start < entry_end) {
+   entry.size = entry_end - entry.start;
+   process_mem_region(, minimum, image_size);
+   }
+
+   if (slot_area_index == MAX_SLOT_AREA) {
+   debug_putstr("Aborted memmap scan (slot_areas 
full)!\n");
+   return 1;
+   }
+   }
+   return 0;
+}
+
 #ifdef CONFIG_EFI
 /*
  * Returns true if mirror region found (and must have been processed
@@ -700,11 +733,16 @@ process_efi_entries(unsigned long minimum, unsigned long 
image_size)
 
region.start = md->phys_addr;
region.size = md->num_pages << EFI_PAGE_SHIFT;
-   process_mem_region(, minimum, image_size);
-   if (slot_area_index == MAX_SLOT_AREA) {
-   debug_putstr("Aborted EFI scan (slot_areas full)!\n");
+
+   /* If no immovable_mem stored, use region directly */
+   if (num_immovable_region == 0) {
+   process_mem_region(, minimum, image_size);
+   if (slot_area_index == MAX_SLOT_AREA) {
+   debug_putstr("Aborted memmap scan (slot_areas 
full)!\n");
+   break;
+   }
+   } else if (process_immovable_mem(region, minimum, image_size))
break;
-   }
}
return true;
 }
@@ -731,11 +769,16 @@ static void process_e820_entries(unsigned long minimum,
continue;
region.start = entry->addr;
region.size = entry->size;
-   process_mem_region(, minimum, image_size);
-   if (slot_area_index == MAX_SLOT_AREA) {
-   debug_putstr("Aborted e820 scan (slot_areas full)!\n");
+
+   /* If no immovable_mem stored, use region directly */
+   if (num_immovable_region == 0) {
+   process_mem_region(, minimum, image_size);
+   if (slot_area_index == MAX_SLOT_AREA) {
+   debug_putstr("Aborted memmap scan (slot_areas 
full)!\n");
+   break;
+   }
+   } else if (process_immovable_mem(region, minimum, image_size))
break;
-   }
}
 }
 
-- 
2.14.3

[PATCH v3 3/4] kaslr: disable memory mirror feature when movable_node specified

[Chao Fan]

In kernel code, if movable_node specified, it will skip the mirror
feature. So we should also skip mirror feature in kaslr.

Signed-off-by: Chao Fan 
---
 arch/x86/boot/compressed/kaslr.c | 15 ++-
 1 file changed, 10 insertions(+), 5 deletions(-)

diff --git a/arch/x86/boot/compressed/kaslr.c b/arch/x86/boot/compressed/kaslr.c
index e3a3b6132da0..fc798d6d608d 100644
--- a/arch/x86/boot/compressed/kaslr.c
+++ b/arch/x86/boot/compressed/kaslr.c
@@ -677,6 +677,7 @@ static bool
 process_efi_entries(unsigned long minimum, unsigned long image_size)
 {
struct efi_info *e = _params->efi_info;
+   char *args = (char *)get_cmd_line_ptr();
bool efi_mirror_found = false;
struct mem_vector region;
efi_memory_desc_t *md;
@@ -702,11 +703,15 @@ process_efi_entries(unsigned long minimum, unsigned long 
image_size)
 #endif
 
nr_desc = e->efi_memmap_size / e->efi_memdesc_size;
-   for (i = 0; i < nr_desc; i++) {
-   md = efi_early_memdesc_ptr(pmap, e->efi_memdesc_size, i);
-   if (md->attribute & EFI_MEMORY_MORE_RELIABLE) {
-   efi_mirror_found = true;
-   break;
+
+   /* Skip memory mirror if movabale_node or immovable_mem specified */
+   if (!strstr(args, "movable_node") && !strstr(args, "immovable_mem")) {
+   for (i = 0; i < nr_desc; i++) {
+   md = efi_early_memdesc_ptr(pmap, e->efi_memdesc_size, 
i);
+   if (md->attribute & EFI_MEMORY_MORE_RELIABLE) {
+   efi_mirror_found = true;
+   break;
+   }
}
}
 
-- 
2.14.3

Re: [PATCH 0/3] eeprom: at25: Add DT support for 25lc040

[Geert Uytterhoeven]

Hi Rob,

On Mon, Dec 4, 2017 at 10:22 PM, Rob Herring  wrote:
> On Thu, Nov 30, 2017 at 02:29:43PM +0100, Geert Uytterhoeven wrote:
>> Some "atmel,at25" compatible SPI EEPROMs (e.g. Microchip 25lc040) use an
>> odd number of address bits.  This patch series adds support for
>> instantiating such devices from DT.
>>
>> Do EEPROMs using 17 or 25 address bits, as mentioned in
>> include/linux/spi/eeprom.h, really exist?
>> Or should we just limit it to a single odd value (9 bits)?
>>
>> This has been tested with a bunch of 25lc040 EEPROMs.
>>
>> Thanks!
>>
>> Geert Uytterhoeven (3):
>>   eeprom: at25: Add DT support for EEPROMs with odd address bits
>>   dt-bindings: eeprom: at25: Grammar s/are can/can/
>>   dt-bindings: eeprom: at25: Document device-specific compatible values
>
> 2 and 3 are fixes and I'll apply for 4.15 if you don't mind.

Thanks, I don't mind.

Gr{oetje,eeting}s,

Geert

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

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

Re: Regression in e1000e since Kernel 4.14.3

[Greg KH]

On Tue, Dec 05, 2017 at 09:20:33AM +0100, Gabriel C wrote:
> On 05.12.2017 07:19, Greg KH wrote:
> > On Tue, Dec 05, 2017 at 07:18:34AM +0100, Greg KH wrote:
> > > On Tue, Dec 05, 2017 at 12:47:10AM +0100, Gabriel C wrote:
> > > > On 04.12.2017 23:10, rwar...@gmx.de wrote:
> > > > 
> > > > > Hallo
> > > > > 
> > > > > someone and I got an regression with e1000e since kernel 4.14.3 and 
> > > > > it seems there is 4.14.4 on the way without a fix.
> > > > > 
> > > > > 
> > > > > bug report is here:
> > > > > 
> > > > > https://bugzilla.kernel.org/show_bug.cgi?id=198047
> > > > 
> > > > ( added stable and netdev to CC )
> > > > 
> > > > Yes I have a box with e1000e and it seems something at least breaks NM 
> > > > after 4.14.3.
> > > 
> > > Again, can people try 4.14.5-rc1?  It should be resolved there.
> > 
> > Oops, that would be 4.14.4-rc1.  Any why do you say above that is on the
> > way without a fix, did you test it?
> 
> I didn't tested 4.14.4-rc1 but somone from the bug report tested it and told 
> is not resolved.
> 
> I'll fire up an build in a bit and let you know.

Great, and maybe cc: the developers and mailing list for this driver at
the same time?  :)

Re: [PATCH v4 1/3] drm/bridge/synopsys: dsi: stop clobbering drvdata

[Nickey Yang]

Hi Philippe,


On 2017年12月01日 18:07, Philippe CORNU wrote:

Hi Nickey,

On 12/01/2017 10:11 AM, Nickey Yang wrote:

Hi Philippe,


On 2017年12月01日 16:32, Philippe CORNU wrote:

Dear Nickey,

Many thanks for your patch.

I am sorry to say that but you can not add my "Acked-by" to this patch
because this code is different from the "original" one from Brian (which
got my "Acked-by").

I'm sorry I didn't think much about it, Thank you for correcting me.

Sometimes it is not an issue because differences are not important but
in this particular case, the code is really different: you have remove
platform_set_drvdata() & platform_get_drvdata() in the stm part.

Could you please go back to the original code or propose me an updated
version of this code.

Could you help update new version of this code(stm part) and then test on
stm platform?

I think you can simply goes back to the original version from Brian (see
the discussion thread in https://patchwork.kernel.org/patch/10078493/)
unless you have specific/good reasons for modifying the code as you did.

mmm,I'm sorry, I feel a little puzzled. Do you means we should abandon
Brian's patch (https://patchwork.kernel.org/patch/10078493/)?
I think we need to adjust stm part because  dw_mipi_dsi_stm.c calls
bridge's drivers if we want merge Brian's patch.


Thanks

Many thanks,
Philippe :)


Thanks,
Nickey.

Many thanks,

Philippe :-)


On 12/01/2017 04:58 AM, Nickey Yang wrote:

From: Brian Norris

Bridge drivers/helpers shouldn't be clobbering the drvdata, since a
parent driver might need to own this. Instead, let's return our
'dw_mipi_dsi' object and have callers pass that back to us for removal.

Signed-off-by: Brian Norris
Signed-off-by: Nickey Yang
Reviewed-by: Matthias Kaehlcke
Reviewed-by: Archit Taneja
Acked-by: Philippe Cornu
Link:https://patchwork.kernel.org/patch/10078493/

---
Changes in v4:
- Add From tag,update subject line
- keep patch "drm/stm: dsi: Adjust dw_mipi_dsi_probe and remove"
 in this piece together.

drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c | 36 
++-
drivers/gpu/drm/stm/dw_mipi_dsi-stm.c |  8 +++---
include/drm/bridge/dw_mipi_dsi.h  | 17 -
3 files changed, 29 insertions(+), 32 deletions(-)

diff --git a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c 
b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
index d9cca4f..c39c7dc 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
@@ -922,8 +922,6 @@ static int dw_mipi_dsi_bridge_attach(struct drm_bridge 
*bridge)
dsi->bridge.of_node = pdev->dev.of_node;
#endif

-	dev_set_drvdata(dev, dsi);

-
return dsi;
}

@@ -935,23 +933,16 @@ static void __dw_mipi_dsi_remove(struct dw_mipi_dsi *dsi)

/*
 * Probe/remove API, used from platforms based on the DRM bridge API.
 */
-int dw_mipi_dsi_probe(struct platform_device *pdev,
- const struct dw_mipi_dsi_plat_data *plat_data)
+struct dw_mipi_dsi *
+dw_mipi_dsi_probe(struct platform_device *pdev,
+ const struct dw_mipi_dsi_plat_data *plat_data)
{
-   struct dw_mipi_dsi *dsi;
-
-   dsi = __dw_mipi_dsi_probe(pdev, plat_data);
-   if (IS_ERR(dsi))
-   return PTR_ERR(dsi);
-
-   return 0;
+   return __dw_mipi_dsi_probe(pdev, plat_data);
}
EXPORT_SYMBOL_GPL(dw_mipi_dsi_probe);

-void dw_mipi_dsi_remove(struct platform_device *pdev)

+void dw_mipi_dsi_remove(struct dw_mipi_dsi *dsi)
{
-   struct dw_mipi_dsi *dsi = platform_get_drvdata(pdev);
-
mipi_dsi_host_unregister(>dsi_host);

	__dw_mipi_dsi_remove(dsi);

@@ -961,31 +952,30 @@ void dw_mipi_dsi_remove(struct platform_device *pdev)
/*
 * Bind/unbind API, used from platforms based on the component framework.
 */
-int dw_mipi_dsi_bind(struct platform_device *pdev, struct drm_encoder *encoder,
-const struct dw_mipi_dsi_plat_data *plat_data)
+struct dw_mipi_dsi *
+dw_mipi_dsi_bind(struct platform_device *pdev, struct drm_encoder *encoder,
+const struct dw_mipi_dsi_plat_data *plat_data)
{
struct dw_mipi_dsi *dsi;
int ret;

	dsi = __dw_mipi_dsi_probe(pdev, plat_data);

if (IS_ERR(dsi))
-   return PTR_ERR(dsi);
+   return dsi;

	ret = drm_bridge_attach(encoder, >bridge, NULL);

if (ret) {
-   dw_mipi_dsi_remove(pdev);
+   dw_mipi_dsi_remove(dsi);
DRM_ERROR("Failed to initialize bridge with drm\n");
-   return ret;
+   return ERR_PTR(ret);
}

-	return 0;

+   return dsi;
}
EXPORT_SYMBOL_GPL(dw_mipi_dsi_bind);

-void dw_mipi_dsi_unbind(struct device *dev)

+void 

Re: [GIT PULL] hash addresses printed with %p

[Dave Young]

On 12/05/17 at 04:45pm, Dave Young wrote:
> On 12/05/17 at 09:09am, Greg Kroah-Hartman wrote:
> > On Tue, Dec 05, 2017 at 01:14:34PM +0800, Dave Young wrote:
> > > On 12/04/17 at 03:00pm, Greg Kroah-Hartman wrote:
> > > > On Mon, Dec 04, 2017 at 12:51:13PM +, David Laight wrote:
> > > > > From: Ard Biesheuvel
> > > > > > Sent: 04 December 2017 10:03
> > > > > ...
> > > > > > and uses __ATTR_RO() to emit initializers for it. __ATTR() 
> > > > > > initializes
> > > > > > the .store member as well, which does not exists, and so it cannot 
> > > > > > be
> > > > > > used directly.
> > > > > > 
> > > > > > So we should either add a .store member that is always NULL, or we
> > > > > > should add our own
> > > > > > 
> > > > > > #define __ATTR_0400(_name) { \
> > > > > > .attr = { .name = __stringify(_name), .mode = 0400 }, \
> > > > > > .show = _name##_show, \
> > > > > > }
> > > > > 
> > > > > What about an __ATTR_RO_MODE(name, mode) that doesn't set the .store 
> > > > > member.
> > > > > Even if the mode allowed write, writes wouldn't happen.
> > > > 
> > > > Ah, that might work, could you convert the other users of __ATTR() in
> > > > the efi code to use it as well?
> > > 
> > > $ grep __ATTR * -RI
> > > efi.c:__ATTR(systab, 0400, systab_show, NULL);
> > > efi.c:static struct kobj_attribute efi_attr_fw_vendor = 
> > > __ATTR_RO(fw_vendor);
> > > efi.c:static struct kobj_attribute efi_attr_runtime = __ATTR_RO(runtime);
> > > efi.c:static struct kobj_attribute efi_attr_config_table = 
> > > __ATTR_RO(config_table);
> > > efi.c:__ATTR_RO(fw_platform_size);
> > > esrt.c:static struct esre_attribute esre_fw_class = __ATTR(fw_class, 0400,
> > > esrt.c:static struct esre_attribute esre_##name = __ATTR(name, 0400, \
> > > esrt.c:static struct kobj_attribute esrt_##name = __ATTR(name, 0400, \
> > > runtime-map.c:static struct map_attribute map_type_attr = __ATTR_RO(type);
> > > runtime-map.c:static struct map_attribute map_phys_addr_attr   = 
> > > __ATTR_RO(phys_addr);
> > > runtime-map.c:static struct map_attribute map_virt_addr_attr  = 
> > > __ATTR_RO(virt_addr);
> > > runtime-map.c:static struct map_attribute map_num_pages_attr  = 
> > > __ATTR_RO(num_pages);
> > > runtime-map.c:static struct map_attribute map_attribute_attr  = 
> > > __ATTR_RO(attribute);
> > > 
> > > Above is all the __ATTR users for drivers/firmware/efi/*, it makes sense
> > > to update all __ATTR_RO to __ATTR_RO_MODE, so efi.c, runtime-map.c, and
> > > drivers/firmware/dmi-sysfs.c can be updated.  But esrt.c __ATTR seems
> > > not necessary.
> > > 
> > > And if so __ATTR_RO_MODE(name, mode) still needs go to sysfs.h.
> > > 
> > > I can do it but need confirm, Is this what you prefer?
> > 
> > Yes, how about the patch below, it builds for me, haven't done anything
> > other than that to test it :)
> 
> Thanks! Let me do a kexec test and a boot test for esrt.

It works for me. esrt part only did a boot test and cat/ls.

> 
> > 
> > Also, what's with the multi-line sysfs file systab?  That's really not
> > allowed, can you please remove it?  Also the first check for !kobj and
> > !buf is funny, that can never happen.
> 
> I thought to do that, but later worried about it will break things:
> http://lists.infradead.org/pipermail/kexec/2013-December/010759.html
> 
> I also thought to add code comment to avoid future expanding of this
> file. Maybe we can do this now.
> 
> > 
> > Please turn all of those different values into different sysfs files.
> > 
> > thanks,
> > 
> > greg k-h
> > 
> > 
> > diff --git a/drivers/firmware/efi/efi.c b/drivers/firmware/efi/efi.c
> > index f70febf680c3..c3eefa126e3b 100644
> > --- a/drivers/firmware/efi/efi.c
> > +++ b/drivers/firmware/efi/efi.c
> > @@ -143,8 +143,7 @@ static ssize_t systab_show(struct kobject *kobj,
> > return str - buf;
> >  }
> >  
> > -static struct kobj_attribute efi_attr_systab =
> > -   __ATTR(systab, 0400, systab_show, NULL);
> > +static struct kobj_attribute efi_attr_systab = __ATTR_RO_MODE(systab, 
> > 0400);
> >  
> >  #define EFI_FIELD(var) efi.var
> >  
> > diff --git a/drivers/firmware/efi/esrt.c b/drivers/firmware/efi/esrt.c
> > index bd7ed3c1148a..7aae2483fcb9 100644
> > --- a/drivers/firmware/efi/esrt.c
> > +++ b/drivers/firmware/efi/esrt.c
> > @@ -106,7 +106,7 @@ static const struct sysfs_ops esre_attr_ops = {
> >  };
> >  
> >  /* Generic ESRT Entry ("ESRE") support. */
> > -static ssize_t esre_fw_class_show(struct esre_entry *entry, char *buf)
> > +static ssize_t fw_class_show(struct esre_entry *entry, char *buf)
> >  {
> > char *str = buf;
> >  
> > @@ -117,18 +117,16 @@ static ssize_t esre_fw_class_show(struct esre_entry 
> > *entry, char *buf)
> > return str - buf;
> >  }
> >  
> > -static struct esre_attribute esre_fw_class = __ATTR(fw_class, 0400,
> > -   esre_fw_class_show, NULL);
> > +static struct esre_attribute esre_fw_class = __ATTR_RO_MODE(fw_class, 
> > 0400);
> >  
> >  #define esre_attr_decl(name, size, fmt) 

Re: Regression in e1000e since Kernel 4.14.3

[Greg KH]

On Tue, Dec 05, 2017 at 10:16:03AM +0100, Gabriel C wrote:
> On 05.12.2017 09:53, Greg KH wrote:
> > On Tue, Dec 05, 2017 at 09:20:33AM +0100, Gabriel C wrote:
> > > On 05.12.2017 07:19, Greg KH wrote:
> > > > On Tue, Dec 05, 2017 at 07:18:34AM +0100, Greg KH wrote:
> > > > > On Tue, Dec 05, 2017 at 12:47:10AM +0100, Gabriel C wrote:
> > > > > > On 04.12.2017 23:10, rwar...@gmx.de wrote:
> > > > > > 
> > > > > > > Hallo
> > > > > > > 
> > > > > > > someone and I got an regression with e1000e since kernel 4.14.3 
> > > > > > > and it seems there is 4.14.4 on the way without a fix.
> > > > > > > 
> > > > > > > 
> > > > > > > bug report is here:
> > > > > > > 
> > > > > > > https://bugzilla.kernel.org/show_bug.cgi?id=198047
> > > > > > 
> > > > > > ( added stable and netdev to CC )
> > > > > > 
> > > > > > Yes I have a box with e1000e and it seems something at least breaks 
> > > > > > NM after 4.14.3.
> > > > > 
> > > > > Again, can people try 4.14.5-rc1?  It should be resolved there.
> > > > 
> > > > Oops, that would be 4.14.4-rc1.  Any why do you say above that is on the
> > > > way without a fix, did you test it?
> > > 
> > > I didn't tested 4.14.4-rc1 but somone from the bug report tested it and 
> > > told is not resolved.
> > > 
> > > I'll fire up an build in a bit and let you know.
> > 
> > Great, and maybe cc: the developers and mailing list for this driver at
> > the same time?  :)
> > 
> 
> Greg,
> 
> last time I reported something about e100* someone told me to just CC netdev 
> =)
> 
> However the issue still remains with 4.14.4-rc1 and NM , and is still fine 
> with connman.
> 
> I don't even think is something about the driver itself because I've quick 
> compiled the out-of-tree-e1000e
> and breaks with NM in the same way. ( which should not be possible ? )
> 
> Even when 4.14.3 was biggiSH :) after a quick scan and assuming the e1000e 
> patches are fine , remaining candidates
> should be the IRQ* and x86/* ones ?

I am not assuming the e1000e patches are all fine :)

Any chance you can do a 'git bisect' between 4.14.2 and 4.14.3 to find
the offending patch?

thanks,

greg k-h

Re: [PATCH v3 3/9] drm: Add Content Protection property

[Hans Verkuil]

On 12/05/2017 06:15 AM, Sean Paul wrote:
> This patch adds a new optional connector property to allow userspace to enable
> protection over the content it is displaying. This will typically be 
> implemented
> by the driver using HDCP.
> 
> The property is a tri-state with the following values:
> - OFF: Self explanatory, no content protection
> - DESIRED: Userspace requests that the driver enable protection
> - ENABLED: Once the driver has authenticated the link, it sets this value
> 
> The driver is responsible for downgrading ENABLED to DESIRED if the link 
> becomes
> unprotected. The driver should also maintain the desiredness of protection
> across hotplug/dpms/suspend.
> 
> If this looks familiar, I posted [1] this 3 years ago. We have been using this
> in ChromeOS across exynos, mediatek, and rockchip over that time.
> 
> Changes in v2:
>  - Pimp kerneldoc for content_protection_property (Daniel)
>  - Drop sysfs attribute
> Changes in v3:
>  - None
> 
> Cc: Daniel Vetter 
> Signed-off-by: Sean Paul 
> 
> [1] https://lists.freedesktop.org/archives/dri-devel/2014-December/073336.html
> ---
>  drivers/gpu/drm/drm_atomic.c|  8 +
>  drivers/gpu/drm/drm_connector.c | 71 
> +
>  drivers/gpu/drm/drm_sysfs.c |  1 +
>  include/drm/drm_connector.h | 16 ++
>  include/uapi/drm/drm_mode.h |  4 +++
>  5 files changed, 100 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index c2da5585e201..676025d755b2 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -1196,6 +1196,12 @@ static int drm_atomic_connector_set_property(struct 
> drm_connector *connector,
>   state->picture_aspect_ratio = val;
>   } else if (property == connector->scaling_mode_property) {
>   state->scaling_mode = val;
> + } else if (property == connector->content_protection_property) {
> + if (val == DRM_MODE_CONTENT_PROTECTION_ENABLED) {
> + DRM_DEBUG_KMS("only drivers can set CP Enabled\n");
> + return -EINVAL;
> + }
> + state->content_protection = val;
>   } else if (connector->funcs->atomic_set_property) {
>   return connector->funcs->atomic_set_property(connector,
>   state, property, val);
> @@ -1275,6 +1281,8 @@ drm_atomic_connector_get_property(struct drm_connector 
> *connector,
>   *val = state->picture_aspect_ratio;
>   } else if (property == connector->scaling_mode_property) {
>   *val = state->scaling_mode;
> + } else if (property == connector->content_protection_property) {
> + *val = state->content_protection;
>   } else if (connector->funcs->atomic_get_property) {
>   return connector->funcs->atomic_get_property(connector,
>   state, property, val);
> diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
> index f14b48e6e839..8626aa8f485e 100644
> --- a/drivers/gpu/drm/drm_connector.c
> +++ b/drivers/gpu/drm/drm_connector.c
> @@ -698,6 +698,13 @@ static const struct drm_prop_enum_list 
> drm_tv_subconnector_enum_list[] = {
>  DRM_ENUM_NAME_FN(drm_get_tv_subconnector_name,
>drm_tv_subconnector_enum_list)
>  
> +static struct drm_prop_enum_list drm_cp_enum_list[] = {
> +{ DRM_MODE_CONTENT_PROTECTION_OFF, "Off" },
> +{ DRM_MODE_CONTENT_PROTECTION_DESIRED, "Desired" },
> +{ DRM_MODE_CONTENT_PROTECTION_ENABLED, "Enabled" },
> +};
> +DRM_ENUM_NAME_FN(drm_get_content_protection_name, drm_cp_enum_list)
> +
>  /**
>   * DOC: standard connector properties
>   *
> @@ -764,6 +771,34 @@ DRM_ENUM_NAME_FN(drm_get_tv_subconnector_name,
>   *  after modeset, the kernel driver may set this to "BAD" and issue a
>   *  hotplug uevent. Drivers should update this value using
>   *  drm_mode_connector_set_link_status_property().
> + * Content Protection:
> + *   This property is used by userspace to request the kernel protect future
> + *   content communicated over the link. When requested, kernel will apply
> + *   the appropriate means of protection (most often HDCP), and use the
> + *   property to tell userspace the protection is active.
> + *
> + *   The value of this property can be one of the following:
> + *
> + *   - DRM_MODE_CONTENT_PROTECTION_OFF = 0
> + *   The link is not protected, content is transmitted in the clear.
> + *   - DRM_MODE_CONTENT_PROTECTION_DESIRED = 1
> + *   Userspace has requested content protection, but the link is not
> + *   currently protected. When in this state, kernel should enable
> + *   Content Protection as soon as possible.
> + *   - DRM_MODE_CONTENT_PROTECTION_ENABLED = 2
> + *   Userspace has requested content protection, and the link is
> + *   protected. 

Re: [PATCH] cpufreq: longhaul: Set transition_delay_us to 20 ms

[Meelis Roos]

> The commit e948bc8fbee0 ("cpufreq: Cap the default transition delay
> value to 10 ms") caused a regression on EPIA-M min-ITX computer where
> shutdown or reboot hangs occasionally with a print message like:
> 
> longhaul: Warning: Timeout while waiting for idle PCI bus
> cpufreq: __target_index: Failed to change cpu frequency: -16
> 
> This probably happens because the cpufreq governor tries to change the
> frequency of the CPU faster than allowed by the hardware.
> 
> With the above commit, the default transition delay comes to 10 ms for a
> transition_latency of 200 us. Set the default transition delay to 20 ms
> directly to fix this regression.
> 
> Fixes: e948bc8fbee0 ("cpufreq: Cap the default transition delay value to 10 
> ms")
> Cc: 4.14+  # 4.14+
> Reported-by: Meelis Roos 
> Suggested-by: Rafael J. Wysocki 
> Signed-off-by: Viresh Kumar 
> ---
>  drivers/cpufreq/longhaul.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/cpufreq/longhaul.c b/drivers/cpufreq/longhaul.c
> index c46a12df40dd..56eafcb07859 100644
> --- a/drivers/cpufreq/longhaul.c
> +++ b/drivers/cpufreq/longhaul.c
> @@ -894,7 +894,7 @@ static int longhaul_cpu_init(struct cpufreq_policy 
> *policy)
>   if ((longhaul_version != TYPE_LONGHAUL_V1) && (scale_voltage != 0))
>   longhaul_setup_voltagescaling();
>  
> - policy->cpuinfo.transition_latency = 20;/* nsec */
> + policy->transition_delay_us = 2;/* usec */
>  
>   return cpufreq_table_validate_and_show(policy, longhaul_table);
>  }

This patch also works on my EPIA-M board - tested 10+ times.

Sorry it took so long to test, it was a remote computer.

-- 
Meelis Roos (mr...@linux.ee)

[PATCH resend] arm: dts: ls1021a: Add label to USB controllers

[Rasmus Villemoes]

From: Esben Haabendal 

Add usb2 and usb3 labels to USB2 and USB3 controller device tree nodes,
for easier modification in board dts files.

Signed-off-by: Esben Haabendal 
Signed-off-by: Rasmus Villemoes 
---
 arch/arm/boot/dts/ls1021a.dtsi | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/ls1021a.dtsi b/arch/arm/boot/dts/ls1021a.dtsi
index 3ff2b8a9f01a..02a266faec9b 100644
--- a/arch/arm/boot/dts/ls1021a.dtsi
+++ b/arch/arm/boot/dts/ls1021a.dtsi
@@ -675,7 +675,7 @@
};
};
 
-   usb@860 {
+   usb2: usb@860 {
compatible = "fsl-usb2-dr-v2.5", "fsl-usb2-dr";
reg = <0x0 0x860 0x0 0x1000>;
interrupts = ;
@@ -683,7 +683,7 @@
phy_type = "ulpi";
};
 
-   usb3@310 {
+   usb3: usb3@310 {
compatible = "snps,dwc3";
reg = <0x0 0x310 0x0 0x1>;
interrupts = ;
-- 
2.7.4

Re: [PATCH 6/8] mfd: axp20x: add battery power supply cell for AXP813

[Lee Jones]

On Mon, 04 Dec 2017, Quentin Schulz wrote:

> As axp20x-battery-power-supply now supports AXP813, add a cell for it.
> 
> Signed-off-by: Quentin Schulz 
> ---
>  drivers/mfd/axp20x.c | 3 +++
>  1 file changed, 3 insertions(+)

For my own reference:
  Acked-for-MFD-by: Lee Jones 

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

RE: [PATCH] Support TrackStick of Thinkpad L570

[Masaki Ota]

Hi, Pali,

OK, I got it.
So, the problem of structure will be solved next chance.

Best Regards,
Masaki Ota
-Original Message-
From: Pali Rohár [mailto:pali.ro...@gmail.com] 
Sent: Monday, December 04, 2017 6:51 PM
To: 太田 真喜 Masaki Ota 
Cc: Masaki Ota <012ne...@gmail.com>; dmitry.torok...@gmail.com; 
benjamin.tissoi...@redhat.com; aaron...@canonical.com; j...@ristioja.ee; 
linux-in...@vger.kernel.org; linux-kernel@vger.kernel.org
Subject: Re: [PATCH] Support TrackStick of Thinkpad L570

On Monday 04 December 2017 09:40:04 Masaki Ota wrote:
> Hi, Pali,
> 
> It does not work in my test result.

Hm.. that is strange, we have dangling pointers in struct alps_data?
Otherwise I have no idea why does not work.

> BTW, other some functions also use both of "struct psmouse" and "struct 
> alps_data" argument.

It does not make sense to pass one structure (via pointers) two times.
And if this "pattern" is already used in code and reason is that one pointer 
"does not work" because it is dangling, then it is really wrong.

I know it is irrelevant to your patch, but this problem with dangling pointer 
should be fixed, e.g. in next patches (not in this one).

Problems (with memory allocation/pointers) should not be camouflaged.
Memory corruption in kernel can lead to fatal problems.

> I just followed it.

Blindly following bad code is a bad idea. When we see something like this, we 
should at least stop and ask question "why is this code pattern used?".

> Best Regards,
> Masaki Ota
> -Original Message-
> From: Pali Rohár [mailto:pali.ro...@gmail.com]
> Sent: Monday, December 04, 2017 6:12 PM
> To: 太田 真喜 Masaki Ota 
> Cc: Masaki Ota <012ne...@gmail.com>; dmitry.torok...@gmail.com; 
> benjamin.tissoi...@redhat.com; aaron...@canonical.com; 
> j...@ristioja.ee; linux-in...@vger.kernel.org; 
> linux-kernel@vger.kernel.org
> Subject: Re: [PATCH] Support TrackStick of Thinkpad L570
> 
> On Monday 04 December 2017 04:48:43 Masaki Ota wrote:
> > Hi, Pali,
> > 
> > I don't get your point.
> > Please modify the code if you have an idea.
> 
> See below
> 
> > Best Regards,
> > Masaki Ota
> > -Original Message-
> > From: Pali Rohár [mailto:pali.ro...@gmail.com]
> > Sent: Saturday, December 02, 2017 6:08 AM
> > To: Masaki Ota <012ne...@gmail.com>
> > Cc: dmitry.torok...@gmail.com; benjamin.tissoi...@redhat.com; 
> > aaron...@canonical.com; j...@ristioja.ee; 太田 真喜 Masaki Ota 
> > ; linux-in...@vger.kernel.org; 
> > linux-kernel@vger.kernel.org
> > Subject: Re: [PATCH] Support TrackStick of Thinkpad L570
> > 
> > On Wednesday 29 November 2017 17:33:58 Masaki Ota wrote:
> > > From: Masaki Ota 
> > > - The issue is that Thinkpad L570 TrackStick does not work. Because the 
> > > main interface of Thinkpad L570 device is SMBus, so ALPS overlooked PS2 
> > > interface Firmware setting of TrackStick. The detail is that TrackStick 
> > > otp bit is disabled.
> > > - Add the code that checks 0xD7 address value. This value is device 
> > > number information, so we can identify the device by checking this value.
> > > - If we check 0xD7 value, we need to enable Command mode and after check 
> > > the value we need to disable Command mode, then we have to enable the 
> > > device(0xF4 command).
> > > - Thinkpad L570 device number is 0x0C or 0x1D. If it is TRUE, enable 
> > > ALPS_DUALPOINT flag.
> > > 
> > > Signed-off-by: Masaki Ota 
> > > ---
> > >  drivers/input/mouse/alps.c | 24 +---
> > >  1 file changed, 21 insertions(+), 3 deletions(-)
> > > 
> > > diff --git a/drivers/input/mouse/alps.c 
> > > b/drivers/input/mouse/alps.c index 850b00e3ad8e..6f092bdd9fc5 
> > > 100644
> > > --- a/drivers/input/mouse/alps.c
> > > +++ b/drivers/input/mouse/alps.c
> > > @@ -2541,13 +2541,31 @@ static int 
> > > alps_update_btn_info_ss4_v2(unsigned char otp[][4],  }
> > >  
> > >  static int alps_update_dual_info_ss4_v2(unsigned char otp[][4],
> > > -struct alps_data *priv)
> > > +struct alps_data *priv,
> > > + struct psmouse *psmouse)
> > >  {
> 
> You can access psmouse from the priv structure as:
> 
>   struct psmouse *psmouse = priv->psmouse;
> 
> Therefore you do not have to extend function parameters with psmouse pointer 
> as that is already present int alps_data.
> 
> struct alps_data is defined as:
> 
> struct alps_data {
>   struct psmouse *psmouse;
>   ...
> }
> 
> > >   bool is_dual = false;
> > > + int reg_val = 0;
> > > + struct ps2dev *ps2dev = >ps2dev;
> > >  
> > > - if (IS_SS4PLUS_DEV(priv->dev_id))
> > > + if (IS_SS4PLUS_DEV(priv->dev_id)) {
> > >   is_dual = (otp[0][0] >> 4) & 0x01;
> > >  
> > > + if (!is_dual) {
> > > + /* For support TrackStick of Thinkpad L/E series */
> > > + if (alps_exit_command_mode(psmouse) == 0 &&

Re: [PATCH] cpufreq: longhaul: Set transition_delay_us to 20 ms

[Meelis Roos]

> > The commit e948bc8fbee0 ("cpufreq: Cap the default transition delay
> > value to 10 ms") caused a regression on EPIA-M min-ITX computer where
> > shutdown or reboot hangs occasionally with a print message like:
> > 
> > longhaul: Warning: Timeout while waiting for idle PCI bus
> > cpufreq: __target_index: Failed to change cpu frequency: -16
> > 
> > This probably happens because the cpufreq governor tries to change the
> > frequency of the CPU faster than allowed by the hardware.
> > 
> > With the above commit, the default transition delay comes to 10 ms for a
> > transition_latency of 200 us. Set the default transition delay to 20 ms
> > directly to fix this regression.
> > 
> > Fixes: e948bc8fbee0 ("cpufreq: Cap the default transition delay value to 10 
> > ms")
> > Cc: 4.14+  # 4.14+
> > Reported-by: Meelis Roos 
> > Suggested-by: Rafael J. Wysocki 
> > Signed-off-by: Viresh Kumar 
> > ---
> >  drivers/cpufreq/longhaul.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/drivers/cpufreq/longhaul.c b/drivers/cpufreq/longhaul.c
> > index c46a12df40dd..56eafcb07859 100644
> > --- a/drivers/cpufreq/longhaul.c
> > +++ b/drivers/cpufreq/longhaul.c
> > @@ -894,7 +894,7 @@ static int longhaul_cpu_init(struct cpufreq_policy 
> > *policy)
> > if ((longhaul_version != TYPE_LONGHAUL_V1) && (scale_voltage != 0))
> > longhaul_setup_voltagescaling();
> >  
> > -   policy->cpuinfo.transition_latency = 20;/* nsec */
> > +   policy->transition_delay_us = 2;/* usec */
> >  
> > return cpufreq_table_validate_and_show(policy, longhaul_table);
> >  }
> 
> This patch also works on my EPIA-M board - tested 10+ times.

An on the last try just after sending the mail, it hung again in the 
same way as before - so maybe 20 is on the edge of being good.


-- 
Meelis Roos (mr...@ut.ee)  http://www.cs.ut.ee/~mroos/

Re: [PATCH v2 0/4] lockdep/crossrelease: Apply crossrelease to page locks

[Michal Hocko]

On Mon 04-12-17 23:45:17, Matthew Wilcox wrote:
> On Tue, Dec 05, 2017 at 03:19:46PM +0900, Byungchul Park wrote:
> > On 12/5/2017 2:46 PM, Byungchul Park wrote:
> > > On 12/5/2017 2:30 PM, Matthew Wilcox wrote:
> > > > On Mon, Dec 04, 2017 at 02:16:19PM +0900, Byungchul Park wrote:
> > > > > For now, wait_for_completion() / complete() works with lockdep, add
> > > > > lock_page() / unlock_page() and its family to lockdep support.
> > > > > 
> > > > > Changes from v1
> > > > >   - Move lockdep_map_cross outside of page_ext to make it flexible
> > > > >   - Prevent allocating lockdep_map per page by default
> > > > >   - Add a boot parameter allowing the allocation for debugging
> > > > > 
> > > > > Byungchul Park (4):
> > > > >    lockdep: Apply crossrelease to PG_locked locks
> > > > >    lockdep: Apply lock_acquire(release) on __Set(__Clear)PageLocked
> > > > >    lockdep: Move data of CONFIG_LOCKDEP_PAGELOCK from page to page_ext
> > > > >    lockdep: Add a boot parameter enabling to track page locks using
> > > > >  lockdep and disable it by default
> > > > 
> > > > I don't like the way you've structured this patch series; first adding
> > > > the lockdep map to struct page, then moving it to page_ext.
> > > 
> > > Hello,
> > > 
> > > I will make them into one patch.
> > 
> > I've thought it more.
> > 
> > Actually I did it because I thought I'd better make it into two
> > patches since it makes reviewers easier to review. It doesn't matter
> > which one I choose, but I prefer to split it.
> 
> I don't know whether it's better to make it all one patch or split it
> into multiple patches.  But it makes no sense to introduce it in struct
> page, then move it to struct page_ext.

I would tend to agree. It is not like anybody would like to apply only
the first part alone. Adding the necessary infrastructure to page_ext is
not such a big deal.

-- 
Michal Hocko
SUSE Labs

Re: [PATCH 1/3] eeprom: at25: Add DT support for EEPROMs with odd address bits

[Geert Uytterhoeven]

Hi Ivo,

On Mon, Dec 4, 2017 at 11:00 PM, Ivo Sieben  wrote:
> 2017-12-04 10:17 GMT+01:00 Geert Uytterhoeven :
>>> EEPROMs using 9 address bits are common (e.g. M95040, 25AA040/25LC040).
>>> Do EEPROMs using 17 or 25 address bits, as mentioned in
>>> include/linux/spi/eeprom.h, really exist?
>>> Or should we just limit it to a single odd value (9 bits)?
>>
>> At least for the real Atmel parts, only the AT25040 part uses odd (8 +
>> 1 bit) addressing.
>> AT25M01 uses 3-byte addressing (it needs 17 bits).
>>
>> So I tend to believe EEPROMs using 16 + 1  or 24 + 1 address bits (with the
>> extra bit in the instruction byte) do not exist?
>>
>
> I think you are right. Most likely this extra address bit option is
> only used for 9 bit addressable chips.
> I'm not an expert, but I know only the M95040 chip for which I
> originally wrote the patch.
> By then I decided to make it a bit broader (so also to be used as
> address 17 & 25 bit addressing) but that might
> not make any sense indeed.
>
>>> @@ -6,7 +6,9 @@ Required properties:
>>>  - spi-max-frequency : max spi frequency to use
>>>  - pagesize : size of the eeprom page
>>>  - size : total eeprom size in bytes
>>> -- address-width : number of address bits (one of 8, 16, or 24)
>>> +- address-width : number of address bits (one of 8, 9, 16, 17, 24, or 25).
>>> +  For odd values, the MSB of the address is sent as bit 3 of the 
>>> instruction
>>> +  byte, before the address byte(s).
>>
>> Alternatively, we can drop the binding change, i.e. keep on using
>> address-width = <8> for 512-byte '040...
>>
>
> As you also stated before: maybe it is more clear to leave only the
> "9" value option documented
> here, that looks to me the only valid use case for it.

OK.

>
>>> +   if (val & 1) {
>>> +   chip->flags |= EE_INSTR_BIT3_IS_ADDR;
>>> +   val -= 1;
>>> +   }
>>
>> ... and handle it here like:
>>
>> if (chip->byte_len == 2U << val)
>> chip->flags |= EE_INSTR_BIT3_IS_ADDR;
>>
>> However, that would IMHO be a bit confusing, as the "address-width"
>> property is no longer the real address width, but indicates how many bits
>> are specified in address bytes sent after the read/write command.
>> So "address-bytes" = 1, 2, or 3 would be more correct ;-)
>>
>> Or deprecate this whole "specify parameters using DT properties" business,
>> and derive them from the compatible value. But that would mean adding a
>> large and ever growing table to an old driver...
>>
>> Thoughts?
>
> I'm not a DT expert but to me your first proposal makes the most sense
> to me and feels the most intuitive:
> I would go for the address-with value 9 option here.

OK.

> Since we only expect value 9 to be a valid option, maybe you could
> rewrite it a bit to explicitly check for value 9:
>
> if (val == 9) {
> chip->flags |= EE_INSTR_BIT3_IS_ADDR;
> val -= 1;
> }
>
> I think this is slightly more readable.

Sure.

> Hope this helps,

Thanks!

Gr{oetje,eeting}s,

Geert

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

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

Re: [PATCH] irqchip/gic-v3: Fix the driver probe() fail due to disabled GICC entry

[Marc Zyngier]

On 04/12/17 14:04, Shanker Donthineni wrote:
> Hi Thanks,
> 
> On 12/04/2017 04:28 AM, Marc Zyngier wrote:
>> On 03/12/17 23:21, Shanker Donthineni wrote:
>>> As per MADT specification, it's perfectly valid firmware can pass
>>> MADT table to OS with disabled GICC entries. ARM64-SMP code skips
>>> those cpu cores to bring online. However the current GICv3 driver
>>> probe bails out in this case on systems where redistributor regions
>>> are not in the always-on power domain.
>>>
>>> This patch does the two things to fix the panic.
>>>   - Don't return an error in gic_acpi_match_gicc() for disabled GICC.
>>>   - No need to keep GICR region information for disabled GICC.
>>>
>>> Kernel crash traces:
>>>   Kernel panic - not syncing: No interrupt controller found.
>>>   CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.13.5 #26
>>>   [] dump_backtrace+0x0/0x218
>>>   [] show_stack+0x14/0x20
>>>   [] dump_stack+0x98/0xb8
>>>   [] panic+0x118/0x26c
>>>   [] init_IRQ+0x24/0x2c
>>>   [] start_kernel+0x230/0x394
>>>   [] __primary_switched+0x64/0x6c
>>>   ---[ end Kernel panic - not syncing: No interrupt controller found.
>>>
>>> Disabled GICC subtable example:
>>>Subtable Type : 0B [Generic Interrupt Controller]
>>>   Length : 50
>>> Reserved : 
>>> CPU Interface Number : 003D
>>>Processor UID : 003D
>>>Flags (decoded below) : 
>>>Processor Enabled : 0
>>>  Performance Interrupt Trig Mode : 0
>>>  Virtual GIC Interrupt Trig Mode : 0
>>> Parking Protocol Version : 
>>>Performance Interrupt : 0017
>>>   Parked Address : 
>>> Base Address : 
>>> Virtual GIC Base Address : 
>>>  Hypervisor GIC Base Address : 
>>>Virtual GIC Interrupt : 0019
>>>   Redistributor Base Address : 88F4
>>>ARM MPIDR : 000D
>>> Efficiency Class : 00
>>> Reserved : 00
>>>
>>> Signed-off-by: Shanker Donthineni 
>>> ---
>>>  drivers/irqchip/irq-gic-v3.c | 14 +-
>>>  1 file changed, 9 insertions(+), 5 deletions(-)
>>>
>>> diff --git a/drivers/irqchip/irq-gic-v3.c b/drivers/irqchip/irq-gic-v3.c
>>> index b56c3e2..a30fbac 100644
>>> --- a/drivers/irqchip/irq-gic-v3.c
>>> +++ b/drivers/irqchip/irq-gic-v3.c
>>> @@ -1331,6 +1331,10 @@ static int __init gic_of_init(struct device_node 
>>> *node, struct device_node *pare
>>> u32 size = reg == GIC_PIDR2_ARCH_GICv4 ? SZ_64K * 4 : SZ_64K * 2;
>>> void __iomem *redist_base;
>>>  
>>> +   /* GICC entry which has !ACPI_MADT_ENABLED is not unusable so skip */
>>> +   if (!(gicc->flags & ACPI_MADT_ENABLED))
>>> +   return 0;
>>> +
>>> redist_base = ioremap(gicc->gicr_base_address, size);
>>> if (!redist_base)
>>> return -ENOMEM;
>>> @@ -1374,13 +1378,13 @@ static int __init gic_acpi_match_gicc(struct 
>>> acpi_subtable_header *header,
>>> (struct acpi_madt_generic_interrupt *)header;
>>>  
>>> /*
>>> -* If GICC is enabled and has valid gicr base address, then it means
>>> -* GICR base is presented via GICC
>>> +* If GICC is enabled and has not valid gicr base address, then it means
>>> +* GICR base is not presented via GICC
>>>  */
>>> -   if ((gicc->flags & ACPI_MADT_ENABLED) && gicc->gicr_base_address)
>>> -   return 0;
>>> +   if ((gicc->flags & ACPI_MADT_ENABLED) && (!gicc->gicr_base_address))
>>> +   return -ENODEV;
>>
>> This doesn't feel quite right. It would mean that having the ENABLED
>> flag cleared and potentially no address would make it valid? It looks to
>> me that the original code is "less wrong".
>>
>> What am I missing?
>>
> 
> Original definition of the function gic_acpi_match_gicc().
>  {
>   if ((gicc->flags & ACPI_MADT_ENABLED) && gicc->gicr_base_address)
> return 0;
> 
>   return -ENODEV;
>  }
> 
> Above code triggers the driver probe fail for the two reasons.
>   1) GICC with ACPI_MADT_ENABLED=0, it's a bug according to ACPI spec.
>   2) GICC with ACPI_MADT_ENABLED=1 and invalid GICR address, expected.
> 
> 
> This patch fix the first failed case and keep the second case intact.
>   if ((gicc->flags & ACPI_MADT_ENABLED) && (!gicc->gicr_base_address))
> return -ENODEV;
> 
>   return 0;
If (1) is a firmware bug, then why is it handled in the SMP code? You're
even saying that this is the right thing to do?

As for (2), you seem to imply that only the address matter. So why isn't
it just:

if (gicc->gicr_base_address)
return 0;

?

Thanks,

M.
-- 
Jazz is not dead. It just smells funny...

Re: [PATCH] riscv/ftrace: Add basic support

[Alan Kao]

On Mon, Dec 04, 2017 at 03:05:09AM -0500, Steven Rostedt wrote:
> On Mon, 4 Dec 2017 13:52:30 +0800
> Alan Kao  wrote:
> 
> > > > Note that the functions in both ftrace.c and setup.c should not be
> > > > hooked with the compiler's -pg option: to prevent infinite self-
> > > > referencing for the former, and to ignore early setup stuff for the 
> > > > latter.  
> > > 
> > > I'm curious to what is in setup.c that ftrace uses.  
> > 
> > In the scenario for some embedded systems, the __init prefix does not give 
> > us the notrace feature without the MODULE config.  Therefore, all functions 
> > would have been hooked with the _mcount trampoline if the -pg flag was not 
> > specifically disabled.
> 
> But is there functions you may want to trace. There's an effort going
> on to allow function tracing to start in early boot up.
> 

Fair enough, but no. Those (in setup.c) are very early stage functions. 
Unless Palmer has different opinion on this, making all of them notrace
should be ok.

> > 
> > And a terrible result would have happened after function setup_vm called
> > _mcount.  As _mcount compared the value of ftrace_trace_function and 
> > the position of ftrace_stub, it crashed the kernel because one of them 
> > was a physical address while the other was a virtual address but
> > actually they pointed to the same.
> > 
> > Adding notrace to setup_vm can solve the described issue, but it might be 
> > redundant once the MODULE config becomes stable and default on most 
> > platforms. To be honest, nobody really needs those init procedures to be
> > ftrace-able.
> 
> Um no, because MODULE init code can now be traced. It use to be that we
> didn't trace any __init, but I worked on having both inits be traced.
> The module code was a little bit trickier because it can be loaded
> multiple times and we needed to figure out the best way to handle init
> functions in the buffer that went stale and is replaced by other module
> init functions.
> 

Thanks for the explanation. But sorry for being unclear, I didn't mean
all the init procedures, but only those in setup.c.

>  
> > > > +config TRACE_IRQFLAGS_SUPPORT
> > > > +   def_bool y
> > > > +
> > > > +config LOCKDEP_SUPPORT
> > > > +   def_bool y  
> > > 
> > > Hmm, not sure the above is needed for function tracing.
> > >  
> > 
> > FTRACE depends on TRACING_SUPPORT, and TRACING_SUPPORT depends on
> > TRACE_IRQFLAGS_SUPPORT. But LOCKDEP_SUPPORT is not actually needed
> > for any of the ftrace features implemented in this patch.
> 
> Hmm, I think that's stale. Thanks for bringing that to my attention,
> and don't believe that dependency still exists.
> 
> > 
> > The LOCKDEP_SUPPORT will be removed in the next version.
> >
> 
> I should have also asked, is lockdep really supported on this arch, and
> is IRQSFLAGS really supported too? I vaguely remember making ftrace
> depend on IRQFLAGS because we wanted archs to support TRACE_IRQFLAGS
> before they supported ftrace. Maybe I'll keep that dependency.

We do have the implementation of IRQFLAGS in
arch/riscv/include/asm/irqflags.  But I'm not sure about LOCKDEP.
 
> > > > +ENTRY(_mcount)
> > > > +   la  t4, ftrace_stub
> > > > +#ifdef CONFIG_FUNCTION_GRAPH_TRACER
> > > > +   la  t0, ftrace_graph_return
> > > > +   ld  t1, 0(t0)
> > > > +   bne t1, t4, do_ftrace_graph_caller  
> > > 
> > > If function graph is enabled, you jump straight to the graph tracer,
> > > but never return back to here?
> > >  
> > 
> > Because prepare_ftrace_return function can return to the caller of
> > _mcount directly without messing up the stack.
> 
> Yes, is that required?
>

I don't get your point here. Are you suggesting that a call is better than 
a jump here, for future extension towards dynamic tracing support? 

> > 
> > > > +
> > > > +   la  t3, ftrace_graph_entry
> > > > +   ld  t2, 0(t3)
> > > > +   la  t6, ftrace_graph_entry_stub
> > > > +   bne t2, t6, do_ftrace_graph_caller
> > > > +#endif
> > > > +   la  t3, ftrace_trace_function
> > > > +   ld  t5, 0(t3)
> > > > +   bne t5, t4, do_trace
> > > > +   ret
> > > > +
> > > > +#ifdef CONFIG_FUNCTION_GRAPH_TRACER
> > > > +/*
> > > > + * A pseudo representation for the function graph tracer:
> > > > + * prepare_to_return(_to_caller_of_caller, ra_to_caller)
> > > > + */
> > > > +do_ftrace_graph_caller:
> > > > +   addia0, s0, -8
> > > > +   mv  a1, ra
> > > > +#ifdef HAVE_FUNCTION_GRAPH_FP_TEST
> > > > +   ld  a2, -16(s0)
> > > > +#endif
> > > > +   SAVE_ABI_STATE
> > > > +   la  t0, prepare_ftrace_return
> > > > +   jalrt0
> > > > +   STORE_ABI_STATE  
> > > 
> > > I'm guessing you don't support function tracer and function graph
> > > tracer running at the same time?
> > > 
> > > -- Steve
> > >   
> > 
> > This code section implements similar logic as those for arm, arm64,
> > blackfin, and others.  Also, 

Re: [PATCH v4 10/10] ARM: dtsi: axp81x: set pinmux for GPIO0/1 when used as LDOs

[Chen-Yu Tsai]

On Fri, Dec 1, 2017 at 11:58 PM, Maxime Ripard
 wrote:
> On Fri, Dec 01, 2017 at 02:44:51PM +0100, Quentin Schulz wrote:
>> On AXP813/818, GPIO0 and GPIO1 can be used as LDO as (respectively)
>> ldo_io0 and ldo_io1.
>>
>> Let's add the pinctrl properties to the said regulators.
>>
>> Signed-off-by: Quentin Schulz 
>
> Acked-by: Maxime Ripard 

Acked-by: Chen-Yu Tsai 

Re: [linux-sunxi] [PATCH v4 09/10] ARM: dtsi: axp81x: add GPIO DT node

[Chen-Yu Tsai]

On Fri, Dec 1, 2017 at 9:44 PM, Quentin Schulz
 wrote:
> This adds DT node for the GPIO/pinctrl part present in AXP813/AXP818.
>
> Signed-off-by: Quentin Schulz 
> ---
>  arch/arm/boot/dts/axp81x.dtsi | 6 ++
>  1 file changed, 6 insertions(+)
>
> diff --git a/arch/arm/boot/dts/axp81x.dtsi b/arch/arm/boot/dts/axp81x.dtsi
> index 73b761f..0ef959d 100644
> --- a/arch/arm/boot/dts/axp81x.dtsi
> +++ b/arch/arm/boot/dts/axp81x.dtsi
> @@ -48,6 +48,12 @@
> interrupt-controller;
> #interrupt-cells = <1>;
>
> +   axp_gpio: axp-gpio {
> +   compatible = "x-powers,axp813-gpio";
> +   gpio-controller;
> +   #gpio-cells = <2>;

What about interrupt-controller for directly referenced interrupts from
the GPIO pins?

Otherwise,

Acked-by: Chen-Yu Tsai 

> +   };
> +
> regulators {
> /* Default work frequency for buck regulators */
> x-powers,dcdc-freq = <3000>;
> --
> git-series 0.9.1
>
> --
> You received this message because you are subscribed to the Google Groups 
> "linux-sunxi" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to linux-sunxi+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

Re: [GIT PULL] hash addresses printed with %p

[Ard Biesheuvel]

On 5 December 2017 at 08:52, Greg Kroah-Hartman
 wrote:
> On Tue, Dec 05, 2017 at 04:45:37PM +0800, Dave Young wrote:
>> On 12/05/17 at 09:09am, Greg Kroah-Hartman wrote:
>> > On Tue, Dec 05, 2017 at 01:14:34PM +0800, Dave Young wrote:
>> > > On 12/04/17 at 03:00pm, Greg Kroah-Hartman wrote:
>> > > > On Mon, Dec 04, 2017 at 12:51:13PM +, David Laight wrote:
>> > > > > From: Ard Biesheuvel
>> > > > > > Sent: 04 December 2017 10:03
>> > > > > ...
>> > > > > > and uses __ATTR_RO() to emit initializers for it. __ATTR() 
>> > > > > > initializes
>> > > > > > the .store member as well, which does not exists, and so it cannot 
>> > > > > > be
>> > > > > > used directly.
>> > > > > >
>> > > > > > So we should either add a .store member that is always NULL, or we
>> > > > > > should add our own
>> > > > > >
>> > > > > > #define __ATTR_0400(_name) { \
>> > > > > > .attr = { .name = __stringify(_name), .mode = 0400 }, \
>> > > > > > .show = _name##_show, \
>> > > > > > }
>> > > > >
>> > > > > What about an __ATTR_RO_MODE(name, mode) that doesn't set the .store 
>> > > > > member.
>> > > > > Even if the mode allowed write, writes wouldn't happen.
>> > > >
>> > > > Ah, that might work, could you convert the other users of __ATTR() in
>> > > > the efi code to use it as well?
>> > >
>> > > $ grep __ATTR * -RI
>> > > efi.c:__ATTR(systab, 0400, systab_show, NULL);
>> > > efi.c:static struct kobj_attribute efi_attr_fw_vendor = 
>> > > __ATTR_RO(fw_vendor);
>> > > efi.c:static struct kobj_attribute efi_attr_runtime = __ATTR_RO(runtime);
>> > > efi.c:static struct kobj_attribute efi_attr_config_table = 
>> > > __ATTR_RO(config_table);
>> > > efi.c:__ATTR_RO(fw_platform_size);
>> > > esrt.c:static struct esre_attribute esre_fw_class = __ATTR(fw_class, 
>> > > 0400,
>> > > esrt.c:static struct esre_attribute esre_##name = __ATTR(name, 0400, \
>> > > esrt.c:static struct kobj_attribute esrt_##name = __ATTR(name, 0400, \
>> > > runtime-map.c:static struct map_attribute map_type_attr = 
>> > > __ATTR_RO(type);
>> > > runtime-map.c:static struct map_attribute map_phys_addr_attr   = 
>> > > __ATTR_RO(phys_addr);
>> > > runtime-map.c:static struct map_attribute map_virt_addr_attr  = 
>> > > __ATTR_RO(virt_addr);
>> > > runtime-map.c:static struct map_attribute map_num_pages_attr  = 
>> > > __ATTR_RO(num_pages);
>> > > runtime-map.c:static struct map_attribute map_attribute_attr  = 
>> > > __ATTR_RO(attribute);
>> > >
>> > > Above is all the __ATTR users for drivers/firmware/efi/*, it makes sense
>> > > to update all __ATTR_RO to __ATTR_RO_MODE, so efi.c, runtime-map.c, and
>> > > drivers/firmware/dmi-sysfs.c can be updated.  But esrt.c __ATTR seems
>> > > not necessary.
>> > >
>> > > And if so __ATTR_RO_MODE(name, mode) still needs go to sysfs.h.
>> > >
>> > > I can do it but need confirm, Is this what you prefer?
>> >
>> > Yes, how about the patch below, it builds for me, haven't done anything
>> > other than that to test it :)
>>
>> Thanks! Let me do a kexec test and a boot test for esrt.
>>
>> >
>> > Also, what's with the multi-line sysfs file systab?  That's really not
>> > allowed, can you please remove it?  Also the first check for !kobj and
>> > !buf is funny, that can never happen.
>>
>> I thought to do that, but later worried about it will break things:
>> http://lists.infradead.org/pipermail/kexec/2013-December/010759.html
>
> Heh, I guess I complained about this in the past :)
>
> So what userspace tool uses it?
>

On x86, it is mostly tools that read DMI tables via /dev/mem, and use
/sys/firmware/efi/systab to locate them. dmidecode, lscpu, etc

That does mean we could investigate which entries are actually used,
and at least start removing the ones we don't need.

> Are these values all exported through sysfs already?  If not, do that
> first.
>
>> I also thought to add code comment to avoid future expanding of this
>> file. Maybe we can do this now.
>
> Please do, but it should be a separate patch.
>
> thanks,
>
> greg k-h

Re: [PATCH v2 1/2] of: overlay: Fix memory leak in of_overlay_apply() error path

[Geert Uytterhoeven]

Hi Frank,

On Tue, Dec 5, 2017 at 3:07 AM, Frank Rowand  wrote:
> On 12/04/17 10:47, Geert Uytterhoeven wrote:
>> If of_resolve_phandles() fails, free_overlay_changeset() is called in
>> the error path.  However, that function returns early if the list hasn't
>> been initialized yet, before freeing the object.
>>
>> Explicitly calling kfree() instead would solve that issue. However, that
>> complicates matter, by having to consider which of two different methods
>> to use to dispose of the same object.
>>
>> Hence make free_overlay_changeset() consider initialization state of the
>> different parts of the object, making it always safe to call (once!) to
>> dispose of a (partially) initialized overlay_changeset:
>>   - Only destroy the changeset if the list was initialized,
>>   - Ignore uninitialized IDs (zero).
>>
>> Reported-by: Colin King 
>> Fixes: f948d6d8b792bb90 ("of: overlay: avoid race condition between applying 
>> multiple overlays")
>> Signed-off-by: Geert Uytterhoeven 
>> ---
>>  drivers/of/overlay.c | 7 +++
>>  1 file changed, 3 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/of/overlay.c b/drivers/of/overlay.c
>> index 3b7a3980ff50d6bf..312cd658bec0083b 100644
>> --- a/drivers/of/overlay.c
>> +++ b/drivers/of/overlay.c
>> @@ -630,11 +630,10 @@ static void free_overlay_changeset(struct 
>> overlay_changeset *ovcs)
>>  {
>>   int i;
>>
>> - if (!ovcs->cset.entries.next)
>> - return;
>> - of_changeset_destroy(>cset);
>> + if (ovcs->cset.entries.next)
>> + of_changeset_destroy(>cset);
>>
>
> OK
>
>> - if (ovcs->id)
>> + if (ovcs->id > 0)
>
> Instead of this change, could you please make a change in 
> init_overlay_changeset()?
>
> Current init_overlay_changeset():
>
> ovcs->id = idr_alloc(_idr, ovcs, 1, 0, GFP_KERNEL);
> if (ovcs->id <= 0)
> return ovcs->id;
>
> My proposed version:
>
> ret = idr_alloc(_idr, ovcs, 1, 0, GFP_KERNEL);
> if (ret <= 0)
> return ret;
> ovcs->id = ret;

Sure.

>>   idr_remove(_idr, ovcs->id);
>>
>>   for (i = 0; i < ovcs->count; i++) {
>>
>
> Also, the previous version of the patch, and the discussion around the 
> resulting
> bug make me think that I should not have moved 'kfree(ovcs)' into
> free_overlay_changeset(), because that kfree is then not very visible in the
> error path of of_overlay_apply().  Could you remove 'kfree(ovcs)' from
> free_overlay_changeset(), and instead call it immediately after each call
> to free_overlay_changeset()?

Actually I like that free_overlay_changeset() takes care of the deallocation,
especially in light of the kojectification op top from bbb-overlays, which
means you cannot just call kfree(ovcs) anymore (I know this won't go upstream
anytime soon, but I need overlay configfs for my development and testing).

Perhaps the allocation of ovcs should be moved into free_overlay_changeset(),
and the latter being renamed to alloc_overlay_changeset()?
That way allocation and freeing become symmetrical.
It would move the allocation under the mutexes, though.

What do you think?

Thanks!

Gr{oetje,eeting}s,

Geert

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

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

Re: [GIT PULL] hash addresses printed with %p

[Greg Kroah-Hartman]

On Tue, Dec 05, 2017 at 01:14:34PM +0800, Dave Young wrote:
> On 12/04/17 at 03:00pm, Greg Kroah-Hartman wrote:
> > On Mon, Dec 04, 2017 at 12:51:13PM +, David Laight wrote:
> > > From: Ard Biesheuvel
> > > > Sent: 04 December 2017 10:03
> > > ...
> > > > and uses __ATTR_RO() to emit initializers for it. __ATTR() initializes
> > > > the .store member as well, which does not exists, and so it cannot be
> > > > used directly.
> > > > 
> > > > So we should either add a .store member that is always NULL, or we
> > > > should add our own
> > > > 
> > > > #define __ATTR_0400(_name) { \
> > > > .attr = { .name = __stringify(_name), .mode = 0400 }, \
> > > > .show = _name##_show, \
> > > > }
> > > 
> > > What about an __ATTR_RO_MODE(name, mode) that doesn't set the .store 
> > > member.
> > > Even if the mode allowed write, writes wouldn't happen.
> > 
> > Ah, that might work, could you convert the other users of __ATTR() in
> > the efi code to use it as well?
> 
> $ grep __ATTR * -RI
> efi.c:__ATTR(systab, 0400, systab_show, NULL);
> efi.c:static struct kobj_attribute efi_attr_fw_vendor = __ATTR_RO(fw_vendor);
> efi.c:static struct kobj_attribute efi_attr_runtime = __ATTR_RO(runtime);
> efi.c:static struct kobj_attribute efi_attr_config_table = 
> __ATTR_RO(config_table);
> efi.c:__ATTR_RO(fw_platform_size);
> esrt.c:static struct esre_attribute esre_fw_class = __ATTR(fw_class, 0400,
> esrt.c:static struct esre_attribute esre_##name = __ATTR(name, 0400, \
> esrt.c:static struct kobj_attribute esrt_##name = __ATTR(name, 0400, \
> runtime-map.c:static struct map_attribute map_type_attr = __ATTR_RO(type);
> runtime-map.c:static struct map_attribute map_phys_addr_attr   = 
> __ATTR_RO(phys_addr);
> runtime-map.c:static struct map_attribute map_virt_addr_attr  = 
> __ATTR_RO(virt_addr);
> runtime-map.c:static struct map_attribute map_num_pages_attr  = 
> __ATTR_RO(num_pages);
> runtime-map.c:static struct map_attribute map_attribute_attr  = 
> __ATTR_RO(attribute);
> 
> Above is all the __ATTR users for drivers/firmware/efi/*, it makes sense
> to update all __ATTR_RO to __ATTR_RO_MODE, so efi.c, runtime-map.c, and
> drivers/firmware/dmi-sysfs.c can be updated.  But esrt.c __ATTR seems
> not necessary.
> 
> And if so __ATTR_RO_MODE(name, mode) still needs go to sysfs.h.
> 
> I can do it but need confirm, Is this what you prefer?

Yes, how about the patch below, it builds for me, haven't done anything
other than that to test it :)

Also, what's with the multi-line sysfs file systab?  That's really not
allowed, can you please remove it?  Also the first check for !kobj and
!buf is funny, that can never happen.

Please turn all of those different values into different sysfs files.

thanks,

greg k-h


diff --git a/drivers/firmware/efi/efi.c b/drivers/firmware/efi/efi.c
index f70febf680c3..c3eefa126e3b 100644
--- a/drivers/firmware/efi/efi.c
+++ b/drivers/firmware/efi/efi.c
@@ -143,8 +143,7 @@ static ssize_t systab_show(struct kobject *kobj,
return str - buf;
 }
 
-static struct kobj_attribute efi_attr_systab =
-   __ATTR(systab, 0400, systab_show, NULL);
+static struct kobj_attribute efi_attr_systab = __ATTR_RO_MODE(systab, 0400);
 
 #define EFI_FIELD(var) efi.var
 
diff --git a/drivers/firmware/efi/esrt.c b/drivers/firmware/efi/esrt.c
index bd7ed3c1148a..7aae2483fcb9 100644
--- a/drivers/firmware/efi/esrt.c
+++ b/drivers/firmware/efi/esrt.c
@@ -106,7 +106,7 @@ static const struct sysfs_ops esre_attr_ops = {
 };
 
 /* Generic ESRT Entry ("ESRE") support. */
-static ssize_t esre_fw_class_show(struct esre_entry *entry, char *buf)
+static ssize_t fw_class_show(struct esre_entry *entry, char *buf)
 {
char *str = buf;
 
@@ -117,18 +117,16 @@ static ssize_t esre_fw_class_show(struct esre_entry 
*entry, char *buf)
return str - buf;
 }
 
-static struct esre_attribute esre_fw_class = __ATTR(fw_class, 0400,
-   esre_fw_class_show, NULL);
+static struct esre_attribute esre_fw_class = __ATTR_RO_MODE(fw_class, 0400);
 
 #define esre_attr_decl(name, size, fmt) \
-static ssize_t esre_##name##_show(struct esre_entry *entry, char *buf) \
+static ssize_t name##_show(struct esre_entry *entry, char *buf) \
 { \
return sprintf(buf, fmt "\n", \
   le##size##_to_cpu(entry->esre.esre1->name)); \
 } \
 \
-static struct esre_attribute esre_##name = __ATTR(name, 0400, \
-   esre_##name##_show, NULL)
+static struct esre_attribute esre_##name = __ATTR_RO_MODE(name, 0400)
 
 esre_attr_decl(fw_type, 32, "%u");
 esre_attr_decl(fw_version, 32, "%u");
@@ -193,14 +191,13 @@ static int esre_create_sysfs_entry(void *esre, int 
entry_num)
 
 /* support for displaying ESRT fields at the top level */
 #define esrt_attr_decl(name, size, fmt) \
-static ssize_t esrt_##name##_show(struct kobject *kobj, \
+static ssize_t name##_show(struct kobject *kobj, \
  struct kobj_attribute *attr, char *buf)\
 { \
return 

Re: [PATCH v3 1/1] at24: support eeproms that do not auto-rollover reads.

[Bartosz Golaszewski]

2017-12-05 8:44 GMT+01:00 Sakari Ailus :
> On Mon, Dec 04, 2017 at 05:24:33PM -0500, Sven Van Asbroeck wrote:
>> > If this is truly specific to at24, then vendor prefix would be appropriate,
>> > plus it'd go to an at24 specific binding file. However if it isn't I'd just
>> > remove the above sentence. I guess the latter?
>>
>> Yes, no-read-rollover is truly specific to at24.c, because it applies only
>> to i2c multi-address chips. The at25 is spi based so cannot have multiple
>> addresses.
>>
>> So yes, "at24,no-read-rollover" would perhaps be a better name.
>>
>> Regarding an at24 specific binding file. You're saying I should create
>> Documentation/devicetree/bindings/eeprom/at24.txt ? Should I indicate
>> that at24.txt "inherits from" eeprom.txt? Note that at25.txt does not
>> currently do this.
>
> Hmm. I actually missed we didn't have one to begin with. at25.txt exists
> and it documents a number of properties specific to at25, so if at24 will
> have an at24-specific property, then I think it should go to a separate
> file.

The eeprom.txt file in the bindings directory actually describes the
bindings for at24. There's a patch[1] from Wolfram waiting for Rob's
ack that renames it to at24.txt. I hope that clears any confusion.

@Sven: please split the patch into two: one for bindings and one for code.

As for the name: I would change it to at24,no-read-rollover and remove
the fragment saying it's only supported in at24 - as I said: this file
only concerns at24 and will be renamed.

>
> Aren't there really other chips which need this? It'd be (a little bit)
> easier to just remove the sentence. :-)
>
> --
> Regards,
>
> Sakari Ailus
> sakari.ai...@linux.intel.com

Thanks,
Bartosz

[1] http://patchwork.ozlabs.org/patch/842500/

Re: [PATCH 08/45] drivers: input: remove duplicate includes

[Benjamin Tissoires]

Hi,

[adding Jiri, the HID maintainer in CC]

On Tue, Dec 5, 2017 at 3:01 AM, Pravin Shedge
 wrote:
> These duplicate includes have been found with scripts/checkincludes.pl but
> they have been removed manually to avoid removing false positives.
>
> Signed-off-by: Pravin Shedge 
> ---

Acked-by: Benjamin Tissoires 

Cheers,
Benjamin

>  drivers/input/rmi4/rmi_f34.c | 1 -
>  1 file changed, 1 deletion(-)
>
> diff --git a/drivers/input/rmi4/rmi_f34.c b/drivers/input/rmi4/rmi_f34.c
> index 4cfe970..f1f5ac5 100644
> --- a/drivers/input/rmi4/rmi_f34.c
> +++ b/drivers/input/rmi4/rmi_f34.c
> @@ -11,7 +11,6 @@
>  #include 
>  #include 
>  #include 
> -#include 
>  #include 
>
>  #include "rmi_driver.h"
> --
> 2.7.4
>

Re: [PATCH v3 14/14] nubus: Add support for the driver model

[Greg Kroah-Hartman]

On Tue, Dec 05, 2017 at 01:20:02AM -0500, Finn Thain wrote:
> This patch brings basic support for the Linux Driver Model to the
> NuBus subsystem.
> 
> For flexibility, the matching of boards with drivers is left up to the
> drivers. This is also the approach taken by NetBSD. A board may have
> many functions, and drivers may have to consider many functional
> resources and board resources in order to match a device.
> 
> This implementation does not bind drivers to resources (nor does it bind
> many drivers to the same board). Apple's NuBus declaration ROM design
> is flexible enough to allow that, but I don't see a need to support it
> as we don't use the "slot zero" resources (in the main logic board ROM).
> 
> Eliminate the global nubus_boards linked list by rewriting the procfs
> board iterator around bus_for_each_dev(). Hence the nubus device refcount
> can be used to determine the lifespan of board objects.
> 
> Cc: Greg Kroah-Hartman 
> Tested-by: Stan Johnson 
> Signed-off-by: Finn Thain 

Nice job:

Reviewed-by: Greg Kroah-Hartman 

Re: [GIT PULL] hash addresses printed with %p

[Dave Young]

On 12/05/17 at 09:09am, Greg Kroah-Hartman wrote:
> On Tue, Dec 05, 2017 at 01:14:34PM +0800, Dave Young wrote:
> > On 12/04/17 at 03:00pm, Greg Kroah-Hartman wrote:
> > > On Mon, Dec 04, 2017 at 12:51:13PM +, David Laight wrote:
> > > > From: Ard Biesheuvel
> > > > > Sent: 04 December 2017 10:03
> > > > ...
> > > > > and uses __ATTR_RO() to emit initializers for it. __ATTR() initializes
> > > > > the .store member as well, which does not exists, and so it cannot be
> > > > > used directly.
> > > > > 
> > > > > So we should either add a .store member that is always NULL, or we
> > > > > should add our own
> > > > > 
> > > > > #define __ATTR_0400(_name) { \
> > > > > .attr = { .name = __stringify(_name), .mode = 0400 }, \
> > > > > .show = _name##_show, \
> > > > > }
> > > > 
> > > > What about an __ATTR_RO_MODE(name, mode) that doesn't set the .store 
> > > > member.
> > > > Even if the mode allowed write, writes wouldn't happen.
> > > 
> > > Ah, that might work, could you convert the other users of __ATTR() in
> > > the efi code to use it as well?
> > 
> > $ grep __ATTR * -RI
> > efi.c:  __ATTR(systab, 0400, systab_show, NULL);
> > efi.c:static struct kobj_attribute efi_attr_fw_vendor = 
> > __ATTR_RO(fw_vendor);
> > efi.c:static struct kobj_attribute efi_attr_runtime = __ATTR_RO(runtime);
> > efi.c:static struct kobj_attribute efi_attr_config_table = 
> > __ATTR_RO(config_table);
> > efi.c:  __ATTR_RO(fw_platform_size);
> > esrt.c:static struct esre_attribute esre_fw_class = __ATTR(fw_class, 0400,
> > esrt.c:static struct esre_attribute esre_##name = __ATTR(name, 0400, \
> > esrt.c:static struct kobj_attribute esrt_##name = __ATTR(name, 0400, \
> > runtime-map.c:static struct map_attribute map_type_attr = __ATTR_RO(type);
> > runtime-map.c:static struct map_attribute map_phys_addr_attr   = 
> > __ATTR_RO(phys_addr);
> > runtime-map.c:static struct map_attribute map_virt_addr_attr  = 
> > __ATTR_RO(virt_addr);
> > runtime-map.c:static struct map_attribute map_num_pages_attr  = 
> > __ATTR_RO(num_pages);
> > runtime-map.c:static struct map_attribute map_attribute_attr  = 
> > __ATTR_RO(attribute);
> > 
> > Above is all the __ATTR users for drivers/firmware/efi/*, it makes sense
> > to update all __ATTR_RO to __ATTR_RO_MODE, so efi.c, runtime-map.c, and
> > drivers/firmware/dmi-sysfs.c can be updated.  But esrt.c __ATTR seems
> > not necessary.
> > 
> > And if so __ATTR_RO_MODE(name, mode) still needs go to sysfs.h.
> > 
> > I can do it but need confirm, Is this what you prefer?
> 
> Yes, how about the patch below, it builds for me, haven't done anything
> other than that to test it :)

Thanks! Let me do a kexec test and a boot test for esrt.

> 
> Also, what's with the multi-line sysfs file systab?  That's really not
> allowed, can you please remove it?  Also the first check for !kobj and
> !buf is funny, that can never happen.

I thought to do that, but later worried about it will break things:
http://lists.infradead.org/pipermail/kexec/2013-December/010759.html

I also thought to add code comment to avoid future expanding of this
file. Maybe we can do this now.

> 
> Please turn all of those different values into different sysfs files.
> 
> thanks,
> 
> greg k-h
> 
> 
> diff --git a/drivers/firmware/efi/efi.c b/drivers/firmware/efi/efi.c
> index f70febf680c3..c3eefa126e3b 100644
> --- a/drivers/firmware/efi/efi.c
> +++ b/drivers/firmware/efi/efi.c
> @@ -143,8 +143,7 @@ static ssize_t systab_show(struct kobject *kobj,
>   return str - buf;
>  }
>  
> -static struct kobj_attribute efi_attr_systab =
> - __ATTR(systab, 0400, systab_show, NULL);
> +static struct kobj_attribute efi_attr_systab = __ATTR_RO_MODE(systab, 0400);
>  
>  #define EFI_FIELD(var) efi.var
>  
> diff --git a/drivers/firmware/efi/esrt.c b/drivers/firmware/efi/esrt.c
> index bd7ed3c1148a..7aae2483fcb9 100644
> --- a/drivers/firmware/efi/esrt.c
> +++ b/drivers/firmware/efi/esrt.c
> @@ -106,7 +106,7 @@ static const struct sysfs_ops esre_attr_ops = {
>  };
>  
>  /* Generic ESRT Entry ("ESRE") support. */
> -static ssize_t esre_fw_class_show(struct esre_entry *entry, char *buf)
> +static ssize_t fw_class_show(struct esre_entry *entry, char *buf)
>  {
>   char *str = buf;
>  
> @@ -117,18 +117,16 @@ static ssize_t esre_fw_class_show(struct esre_entry 
> *entry, char *buf)
>   return str - buf;
>  }
>  
> -static struct esre_attribute esre_fw_class = __ATTR(fw_class, 0400,
> - esre_fw_class_show, NULL);
> +static struct esre_attribute esre_fw_class = __ATTR_RO_MODE(fw_class, 0400);
>  
>  #define esre_attr_decl(name, size, fmt) \
> -static ssize_t esre_##name##_show(struct esre_entry *entry, char *buf) \
> +static ssize_t name##_show(struct esre_entry *entry, char *buf) \
>  { \
>   return sprintf(buf, fmt "\n", \
>  le##size##_to_cpu(entry->esre.esre1->name)); \
>  } \
>  \
> -static struct esre_attribute esre_##name = __ATTR(name, 0400, \
> - 

Re: [PATCH 0/3] thunderbolt fixes for v4.15-rc2

[Mika Westerberg]

On Fri, Dec 01, 2017 at 03:08:02PM +0300, Mika Westerberg wrote:
> Hi Greg,
> 
> Here are two Thunderbolt fixes and one related MAINTAINERS update for the
> next -rc:
> 
> - Use shorter path for force_power attribute in thunderbolt.rst
> - Ring interrupts were not masked properly when Rx polling starts
> - Add thunderbolt.rst to the Thunderbolt driver MAINTAINERS entry
> 
> Thanks!

Hi Greg,

I wonder if I missed something in this series? These are fixes I picked
up to my tree and then forwarded to you to be included in your char-misc
repository for -rc.

Thanks!

[PATCH v2 1/3] mtd: nand: cafe: remove use of NAND_OWN_BUFFERS

[Masahiro Yamada]

This driver is the last/only user of NAND_OWN_BUFFERS.  Boris suggested
to remove this flag.

Taking a closer look at this driver, it calls dma_alloc_coherent() for
the concatenated area for the DMA bounce buffer + struct nand_buffers,
but the latter does not need to be DMA-coherent; cafe_{write,read}_buf
simply do memcpy() between buffers when usedma==1.

Let's do dma_alloc_coherent() for the DMA bounce buffer in the front,
and leave the nand_buffers allocation to nand_scan_tail(), then rip off
NAND_OWN_BUFFERS.

The magic number, 2112, is still mysterious (hard-coded writesize +
oobsize ?), but this is not our main interest.  I am keeping it.

Suggested-by: Boris Brezillon 
Signed-off-by: Masahiro Yamada 
---

Changes in v2:
  - Newly added

 drivers/mtd/nand/cafe_nand.c | 24 
 1 file changed, 4 insertions(+), 20 deletions(-)

diff --git a/drivers/mtd/nand/cafe_nand.c b/drivers/mtd/nand/cafe_nand.c
index bc558c4..add4613 100644
--- a/drivers/mtd/nand/cafe_nand.c
+++ b/drivers/mtd/nand/cafe_nand.c
@@ -613,7 +613,6 @@ static int cafe_nand_probe(struct pci_dev *pdev,
uint32_t ctrl;
int err = 0;
int old_dma;
-   struct nand_buffers *nbuf;
 
/* Very old versions shared the same PCI ident for all three
   functions on the chip. Verify the class too... */
@@ -661,7 +660,6 @@ static int cafe_nand_probe(struct pci_dev *pdev,
 
/* Enable the following for a flash based bad block table */
cafe->nand.bbt_options = NAND_BBT_USE_FLASH;
-   cafe->nand.options = NAND_OWN_BUFFERS;
 
if (skipbbt) {
cafe->nand.options |= NAND_SKIP_BBTSCAN;
@@ -731,15 +729,12 @@ static int cafe_nand_probe(struct pci_dev *pdev,
if (err)
goto out_irq;
 
-   cafe->dmabuf = dma_alloc_coherent(>pdev->dev,
-   2112 + sizeof(struct nand_buffers) +
-   mtd->writesize + mtd->oobsize,
-   >dmaaddr, GFP_KERNEL);
+   cafe->dmabuf = dma_alloc_coherent(>pdev->dev, 2112,
+ >dmaaddr, GFP_KERNEL);
if (!cafe->dmabuf) {
err = -ENOMEM;
goto out_irq;
}
-   cafe->nand.buffers = nbuf = (void *)cafe->dmabuf + 2112;
 
/* Set up DMA address */
cafe_writel(cafe, cafe->dmaaddr & 0x, NAND_DMA_ADDR0);
@@ -752,11 +747,6 @@ static int cafe_nand_probe(struct pci_dev *pdev,
cafe_dev_dbg(>pdev->dev, "Set DMA address to %x (virt %p)\n",
cafe_readl(cafe, NAND_DMA_ADDR0), cafe->dmabuf);
 
-   /* this driver does not need the @ecccalc and @ecccode */
-   nbuf->ecccalc = NULL;
-   nbuf->ecccode = NULL;
-   nbuf->databuf = (uint8_t *)(nbuf + 1);
-
/* Restore the DMA flag */
usedma = old_dma;
 
@@ -801,10 +791,7 @@ static int cafe_nand_probe(struct pci_dev *pdev,
goto out;
 
  out_free_dma:
-   dma_free_coherent(>pdev->dev,
-   2112 + sizeof(struct nand_buffers) +
-   mtd->writesize + mtd->oobsize,
-   cafe->dmabuf, cafe->dmaaddr);
+   dma_free_coherent(>pdev->dev, 2112, cafe->dmabuf, cafe->dmaaddr);
  out_irq:
/* Disable NAND IRQ in global IRQ mask register */
cafe_writel(cafe, ~1 & cafe_readl(cafe, GLOBAL_IRQ_MASK), 
GLOBAL_IRQ_MASK);
@@ -829,10 +816,7 @@ static void cafe_nand_remove(struct pci_dev *pdev)
nand_release(mtd);
free_rs(cafe->rs);
pci_iounmap(pdev, cafe->mmio);
-   dma_free_coherent(>pdev->dev,
-   2112 + sizeof(struct nand_buffers) +
-   mtd->writesize + mtd->oobsize,
-   cafe->dmabuf, cafe->dmaaddr);
+   dma_free_coherent(>pdev->dev, 2112, cafe->dmabuf, cafe->dmaaddr);
kfree(cafe);
 }
 
-- 
2.7.4

[PATCH v2 2/3] mtd: nand: remove unused NAND_OWN_BUFFERS flag

[Masahiro Yamada]

The last/only user of NAND_OWN_BUFFERS (cafe_nand.c) has been reworked.
This flag is no longer needed.

Suggested-by: Boris Brezillon 
Signed-off-by: Masahiro Yamada 
---

Changes in v2:
  - Newly added

 drivers/mtd/nand/nand_base.c | 45 
 include/linux/mtd/rawnand.h  |  5 -
 2 files changed, 20 insertions(+), 30 deletions(-)

diff --git a/drivers/mtd/nand/nand_base.c b/drivers/mtd/nand/nand_base.c
index 6135d00..0cc61b1 100644
--- a/drivers/mtd/nand/nand_base.c
+++ b/drivers/mtd/nand/nand_base.c
@@ -4646,35 +4646,30 @@ int nand_scan_tail(struct mtd_info *mtd)
return -EINVAL;
}
 
-   if (!(chip->options & NAND_OWN_BUFFERS)) {
-   nbuf = kzalloc(sizeof(*nbuf), GFP_KERNEL);
-   if (!nbuf)
-   return -ENOMEM;
-
-   nbuf->ecccalc = kmalloc(mtd->oobsize, GFP_KERNEL);
-   if (!nbuf->ecccalc) {
-   ret = -ENOMEM;
-   goto err_free_nbuf;
-   }
+   nbuf = kzalloc(sizeof(*nbuf), GFP_KERNEL);
+   if (!nbuf)
+   return -ENOMEM;
 
-   nbuf->ecccode = kmalloc(mtd->oobsize, GFP_KERNEL);
-   if (!nbuf->ecccode) {
-   ret = -ENOMEM;
-   goto err_free_nbuf;
-   }
+   nbuf->ecccalc = kmalloc(mtd->oobsize, GFP_KERNEL);
+   if (!nbuf->ecccalc) {
+   ret = -ENOMEM;
+   goto err_free_nbuf;
+   }
 
-   nbuf->databuf = kmalloc(mtd->writesize + mtd->oobsize,
-   GFP_KERNEL);
-   if (!nbuf->databuf) {
-   ret = -ENOMEM;
-   goto err_free_nbuf;
-   }
+   nbuf->ecccode = kmalloc(mtd->oobsize, GFP_KERNEL);
+   if (!nbuf->ecccode) {
+   ret = -ENOMEM;
+   goto err_free_nbuf;
+   }
 
-   chip->buffers = nbuf;
-   } else if (!chip->buffers) {
-   return -ENOMEM;
+   nbuf->databuf = kmalloc(mtd->writesize + mtd->oobsize, GFP_KERNEL);
+   if (!nbuf->databuf) {
+   ret = -ENOMEM;
+   goto err_free_nbuf;
}
 
+   chip->buffers = nbuf;
+
/*
 * FIXME: some NAND manufacturer drivers expect the first die to be
 * selected when manufacturer->init() is called. They should be fixed
@@ -5032,7 +5027,7 @@ void nand_cleanup(struct nand_chip *chip)
 
/* Free bad block table memory */
kfree(chip->bbt);
-   if (!(chip->options & NAND_OWN_BUFFERS) && chip->buffers) {
+   if (chip->buffers) {
kfree(chip->buffers->databuf);
kfree(chip->buffers->ecccode);
kfree(chip->buffers->ecccalc);
diff --git a/include/linux/mtd/rawnand.h b/include/linux/mtd/rawnand.h
index 749bb08..5b24a8e 100644
--- a/include/linux/mtd/rawnand.h
+++ b/include/linux/mtd/rawnand.h
@@ -191,11 +191,6 @@ enum nand_ecc_algo {
 /* Non chip related options */
 /* This option skips the bbt scan during initialization. */
 #define NAND_SKIP_BBTSCAN  0x0001
-/*
- * This option is defined if the board driver allocates its own buffers
- * (e.g. because it needs them DMA-coherent).
- */
-#define NAND_OWN_BUFFERS   0x0002
 /* Chip may not exist, so silence any errors in scan */
 #define NAND_SCAN_SILENT_NODEV 0x0004
 /*
-- 
2.7.4

Re: [PATCH v4 00/10] add pinmuxing support for pins in AXP209 and AXP813 PMICs

[Maxime Ripard]

On Sat, Dec 02, 2017 at 05:00:03PM +0100, Linus Walleij wrote:
> On Fri, Dec 1, 2017 at 2:44 PM, Quentin Schulz
>  wrote:
> 
> > The AXP209 and AXP813 PMICs have several pins (respectively 3 and 2) that 
> > can
> > be used either as GPIOs or for other purposes (ADC or LDO here).
> >
> > We already have a GPIO driver for the GPIO use of those pins on the AXP209.
> > Let's "upgrade" this driver to support all the functions these pins can 
> > have.
> >
> > Then we add support to this driver for the AXP813 which is slighlty 
> > different
> > (basically a different offset in two registers and one less pin).
> >
> > I suggest patches 1 to 8 go through Linus's tree and 9 and 10 via Maxime or
> > Chen-Yu's tree.
> >
> > v4:
> 
> Looks overall good. As soon as Maxime is happy with everything I will
> happily apply 1-8 to the pinctrl tree and then pull it to GPIO as well to
> avoid clashes.
> 
> I think there were some minor comments but it seems almost finished.

You can apply everything with my
Acked-by: Maxime Ripard 

The only comment left is the checkpatch warning, but there's multiple
occurences of that issue in the driver, so it can definitely be done
in a separate patch.

(But please do it Quentin ;))

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com


signature.asc
Description: PGP signature

[PATCH v2 4/5] x86/stacktrace: do not fail for ORC with regs on stack

[Jiri Slaby]

save_stack_trace_reliable now returns "non reliable" when there are
kernel pt_regs on stack. This means an interrupt or exception happened
somewhere down the route. It is a problem for frame pointer unwinder,
because the frame might not have been set up yet when the irq happened,
so the unwinder might fail to unwind from the interrupted function.

With ORC, this is not a problem, as ORC has out-of-band data. We can
find ORC data even for the IP in the interrupted function and always
unwind one level up reliably.

So lift the check to apply only when CONFIG_FRAME_POINTER is enabled.

[v2]
- rewrite the code in favor of Josh's suggestions

Signed-off-by: Jiri Slaby 
Cc: Thomas Gleixner 
Cc: Ingo Molnar 
Cc: "H. Peter Anvin" 
Cc: x...@kernel.org
Cc: Josh Poimboeuf 
---
 arch/x86/kernel/stacktrace.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/x86/kernel/stacktrace.c b/arch/x86/kernel/stacktrace.c
index 9da8af2922b6..45915bd01692 100644
--- a/arch/x86/kernel/stacktrace.c
+++ b/arch/x86/kernel/stacktrace.c
@@ -113,7 +113,8 @@ __save_stack_trace_reliable(struct stack_trace *trace,
 * or a page fault), which can make frame pointers
 * unreliable.
 */
-   return -EINVAL;
+   if (IS_ENABLED(CONFIG_FRAME_POINTER))
+   return -EINVAL;
}
 
addr = unwind_get_return_address();
-- 
2.15.1

[PATCH v2 1/5] x86/stacktrace: do now unwind after user regs

[Jiri Slaby]

Josh pointed out, that there is no way a frame can be after user regs.
So remove the last unwind and the check.

Signed-off-by: Jiri Slaby 
Cc: Thomas Gleixner 
Cc: Ingo Molnar 
Cc: "H. Peter Anvin" 
Cc: x...@kernel.org
Cc: Josh Poimboeuf 
---
 arch/x86/kernel/stacktrace.c | 9 -
 1 file changed, 9 deletions(-)

diff --git a/arch/x86/kernel/stacktrace.c b/arch/x86/kernel/stacktrace.c
index 77835bc021c7..b088d4f9e43e 100644
--- a/arch/x86/kernel/stacktrace.c
+++ b/arch/x86/kernel/stacktrace.c
@@ -113,15 +113,6 @@ __save_stack_trace_reliable(struct stack_trace *trace,
if (!user_mode(regs))
return -EINVAL;
 
-   /*
-* The last frame contains the user mode syscall
-* pt_regs.  Skip it and finish the unwind.
-*/
-   unwind_next_frame();
-   if (!unwind_done()) {
-   STACKTRACE_DUMP_ONCE(task);
-   return -EINVAL;
-   }
break;
}
 
-- 
2.15.1

[PATCH v2 3/5] x86/stacktrace: remove STACKTRACE_DUMP_ONCE from __save_stack_trace_reliable

[Jiri Slaby]

The stack unwinding can sometimes fail yet. Especially with the
generated debug info. So do not yell at users -- live patching (the only
user of this interface) will inform the user about the failure
gracefully.

Signed-off-by: Jiri Slaby 
Cc: Thomas Gleixner 
Cc: Ingo Molnar 
Cc: "H. Peter Anvin" 
Cc: x...@kernel.org
Cc: Josh Poimboeuf 
---
 arch/x86/kernel/stacktrace.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/arch/x86/kernel/stacktrace.c b/arch/x86/kernel/stacktrace.c
index 9193607e3ead..9da8af2922b6 100644
--- a/arch/x86/kernel/stacktrace.c
+++ b/arch/x86/kernel/stacktrace.c
@@ -123,10 +123,8 @@ __save_stack_trace_reliable(struct stack_trace *trace,
 * generated code which __kernel_text_address() doesn't know
 * about.
 */
-   if (!addr) {
-   STACKTRACE_DUMP_ONCE(task);
+   if (!addr)
return -EINVAL;
-   }
 
if (save_stack_address(trace, addr, false))
return -EINVAL;
-- 
2.15.1

[PATCH v2 2/5] x86/stacktrace: remove unwind_state->error

[Jiri Slaby]

Reorganize the unwinding in __save_stack_trace_reliable, so that we
don't need to set another variable -- unwind_state->error. In case,
unwinding fails, we fail after the for loop too. The only way to escape
the loop successfully is via the 'if (user_mode(regs))' check now.

Signed-off-by: Jiri Slaby 
Cc: Thomas Gleixner 
Cc: Ingo Molnar 
Cc: "H. Peter Anvin" 
Cc: x...@kernel.org
Cc: Josh Poimboeuf 
---
 arch/x86/include/asm/unwind.h  |  6 --
 arch/x86/kernel/stacktrace.c   | 15 ++-
 arch/x86/kernel/unwind_frame.c |  2 --
 3 files changed, 6 insertions(+), 17 deletions(-)

diff --git a/arch/x86/include/asm/unwind.h b/arch/x86/include/asm/unwind.h
index 5be2fb23825a..6f90295e6547 100644
--- a/arch/x86/include/asm/unwind.h
+++ b/arch/x86/include/asm/unwind.h
@@ -15,7 +15,6 @@ struct unwind_state {
unsigned long stack_mask;
struct task_struct *task;
int graph_idx;
-   bool error;
 #if defined(CONFIG_UNWINDER_ORC)
bool signal, full_regs;
unsigned long sp, bp, ip;
@@ -40,11 +39,6 @@ static inline bool unwind_done(struct unwind_state *state)
return state->stack_info.type == STACK_TYPE_UNKNOWN;
 }
 
-static inline bool unwind_error(struct unwind_state *state)
-{
-   return state->error;
-}
-
 static inline
 void unwind_start(struct unwind_state *state, struct task_struct *task,
  struct pt_regs *regs, unsigned long *first_frame)
diff --git a/arch/x86/kernel/stacktrace.c b/arch/x86/kernel/stacktrace.c
index b088d4f9e43e..9193607e3ead 100644
--- a/arch/x86/kernel/stacktrace.c
+++ b/arch/x86/kernel/stacktrace.c
@@ -104,16 +104,16 @@ __save_stack_trace_reliable(struct stack_trace *trace,
 
regs = unwind_get_entry_regs();
if (regs) {
+   if (user_mode(regs))
+   goto success;
+
/*
 * Kernel mode registers on the stack indicate an
 * in-kernel interrupt or exception (e.g., preemption
 * or a page fault), which can make frame pointers
 * unreliable.
 */
-   if (!user_mode(regs))
-   return -EINVAL;
-
-   break;
+   return -EINVAL;
}
 
addr = unwind_get_return_address();
@@ -132,12 +132,9 @@ __save_stack_trace_reliable(struct stack_trace *trace,
return -EINVAL;
}
 
-   /* Check for stack corruption */
-   if (unwind_error()) {
-   STACKTRACE_DUMP_ONCE(task);
-   return -EINVAL;
-   }
+   return -EINVAL;
 
+success:
if (trace->nr_entries < trace->max_entries)
trace->entries[trace->nr_entries++] = ULONG_MAX;
 
diff --git a/arch/x86/kernel/unwind_frame.c b/arch/x86/kernel/unwind_frame.c
index 3dc26f95d46e..0c08a56adabe 100644
--- a/arch/x86/kernel/unwind_frame.c
+++ b/arch/x86/kernel/unwind_frame.c
@@ -332,8 +332,6 @@ bool unwind_next_frame(struct unwind_state *state)
return true;
 
 bad_address:
-   state->error = true;
-
/*
 * When unwinding a non-current task, the task might actually be
 * running on another CPU, in which case it could be modifying its
-- 
2.15.1

Re: [REGRESSION][v4.13.y][v4.14.y] scsi: libsas: allow async aborts

[Fabian Grünbichler]

On Fri, Nov 17, 2017 at 03:09:37PM +0100, Hannes Reinecke wrote:
> On 11/16/2017 11:08 PM, Joseph Salisbury wrote:
> > Hi Christoph,
> > 
> > A kernel bug report was opened against Ubuntu [0].  After a kernel
> > bisect, it was found that reverting the following commit resolved this bug:
> > 
> > 909657615d9b ("scsi: libsas: allow async aborts")
> > 
> >  
> > The regression was introduced as of v4.12-rc1, and it still exists in
> > 4.14 mainline.
> > 
> > I was hoping to get your feedback, since you are the patch author.  Do
> > you think gathering any additional data will help diagnose this issue,
> > or would it be best to submit a revert request?
> > 
> I'll be checking what's going on there.
> 
> Cheers,
> 
> Hannes

Any news about this regression? Any traces / data affected users can
provide?

Thanks!

[PATCH v2 5/5] x86/stacktrace: orc, mark it as reliable

[Jiri Slaby]

In SUSE, we need a reliable stack unwinder for kernel live patching, but
we do not want to enable frame pointers for performance reasons. So
after the previous patches to make the ORC reliable, mark ORC as a
reliable stack unwinder on x86.

Signed-off-by: Jiri Slaby 
Cc: Josh Poimboeuf 
Cc: Thomas Gleixner 
Cc: Ingo Molnar 
Cc: "H. Peter Anvin" 
Cc: x...@kernel.org
---
 arch/x86/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index bb757400869e..54d4f67ad4bf 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -172,7 +172,7 @@ config X86
select HAVE_PERF_USER_STACK_DUMP
select HAVE_RCU_TABLE_FREE
select HAVE_REGS_AND_STACK_ACCESS_API
-   select HAVE_RELIABLE_STACKTRACE if X86_64 && 
UNWINDER_FRAME_POINTER && STACK_VALIDATION
+   select HAVE_RELIABLE_STACKTRACE if X86_64 && 
(UNWINDER_FRAME_POINTER || UNWINDER_ORC) && STACK_VALIDATION
select HAVE_STACK_VALIDATIONif X86_64
select HAVE_SYSCALL_TRACEPOINTS
select HAVE_UNSTABLE_SCHED_CLOCK
-- 
2.15.1

Re: [PATCH v3 5/9] drm/i915: Add HDCP framework + base implementation

[Ramalingam C]

On Tuesday 05 December 2017 10:45 AM, Sean Paul wrote:

This patch adds the framework required to add HDCP support to intel
connectors. It implements Aksv loading from fuse, and parts 1/2/3
of the HDCP authentication scheme.

Note that without shim implementations, this does not actually implement
HDCP. That will come in subsequent patches.

Changes in v2:
- Don't open code wait_fors (Chris)
- drm_hdcp.c under MIT license (Daniel)
- Move intel_hdcp_disable() call above ddi_disable (Ram)
- Fix // comments (I wore a cone of shame for 12 hours to atone) (Daniel)
- Justify intel_hdcp_shim with comments (Daniel)
- Fixed async locking issues by adding hdcp_mutex (Daniel)
- Don't alter connector_state in enable/disable (Daniel)
Changes in v3:
- Added hdcp_mutex/hdcp_value to make async reasonable
- Added hdcp_prop_work to separate link checking & property setting
- Added new helper for atomic_check state tracking (Daniel)
- Moved enable/disable into atomic_commit with matching helpers
- Moved intel_hdcp_check_link out of all locks when called from dp
- Bumped up ksv_fifo timeout (noticed failure on one of my dongles)

Cc: Chris Wilson 
Cc: Daniel Vetter 
Cc: Ramalingam C 
Signed-off-by: Sean Paul 
---
  drivers/gpu/drm/i915/Makefile|   1 +
  drivers/gpu/drm/i915/i915_reg.h  |  83 
  drivers/gpu/drm/i915/intel_atomic.c  |   2 +
  drivers/gpu/drm/i915/intel_display.c |  14 +
  drivers/gpu/drm/i915/intel_drv.h |  88 +
  drivers/gpu/drm/i915/intel_hdcp.c| 731 +++
  6 files changed, 919 insertions(+)
  create mode 100644 drivers/gpu/drm/i915/intel_hdcp.c

diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 42bc8bd4ff06..3facea4eefdb 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -107,6 +107,7 @@ i915-y += intel_audio.o \
  intel_fbc.o \
  intel_fifo_underrun.o \
  intel_frontbuffer.o \
+ intel_hdcp.o \
  intel_hotplug.o \
  intel_modes.o \
  intel_overlay.o \
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 09bf043c1c2e..2bd2cc8441d4 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -8034,6 +8034,7 @@ enum {
  #define GEN9_MEM_LATENCY_LEVEL_1_5_SHIFT  8
  #define GEN9_MEM_LATENCY_LEVEL_2_6_SHIFT  16
  #define GEN9_MEM_LATENCY_LEVEL_3_7_SHIFT  24
+#define   SKL_PCODE_LOAD_HDCP_KEYS 0x5
  #define   SKL_PCODE_CDCLK_CONTROL 0x7
  #define SKL_CDCLK_PREPARE_FOR_CHANGE  0x3
  #define SKL_CDCLK_READY_FOR_CHANGE0x1
@@ -8335,6 +8336,88 @@ enum skl_power_gate {
  #define  SKL_PW_TO_PG(pw) ((pw) - SKL_DISP_PW_1 + SKL_PG1)
  #define  SKL_FUSE_PG_DIST_STATUS(pg)  (1 << (27 - (pg)))
  
+

+/* HDCP Key Registers */
+#define SKL_HDCP_KEY_CONF  _MMIO(0x66c00)
+#define SKL_HDCP_AKSV_SEND_TRIGGER BIT(31)
+#define  SKL_HDCP_CLEAR_KEYS_TRIGGER   BIT(30)
+#define SKL_HDCP_KEY_STATUS_MMIO(0x66c04)
+#define  SKL_HDCP_FUSE_IN_PROGRESS BIT(7)
+#define  SKL_HDCP_FUSE_ERROR   BIT(6)
+#define  SKL_HDCP_FUSE_DONEBIT(5)
+#define  SKL_HDCP_KEY_LOAD_STATUS  BIT(1)
+#define  SKL_HDCP_KEY_LOAD_DONEBIT(0)
+#define SKL_HDCP_AKSV_LO   _MMIO(0x66c10)
+#define SKL_HDCP_AKSV_HI   _MMIO(0x66c14)
+
+/* HDCP Repeater Registers */
+#define SKL_HDCP_REP_CTL   _MMIO(0x66d00)
+#define  SKL_HDCP_DDIB_REP_PRESENT BIT(30)
+#define  SKL_HDCP_DDIA_REP_PRESENT BIT(29)
+#define  SKL_HDCP_DDIC_REP_PRESENT BIT(28)
+#define  SKL_HDCP_DDID_REP_PRESENT BIT(27)
+#define  SKL_HDCP_DDIF_REP_PRESENT BIT(26)
+#define  SKL_HDCP_DDIE_REP_PRESENT BIT(25)
+#define  SKL_HDCP_DDIB_SHA1_M0 (1 << 20)
+#define  SKL_HDCP_DDIA_SHA1_M0 (2 << 20)
+#define  SKL_HDCP_DDIC_SHA1_M0 (3 << 20)
+#define  SKL_HDCP_DDID_SHA1_M0 (4 << 20)
+#define  SKL_HDCP_DDIF_SHA1_M0 (5 << 20)
+#define  SKL_HDCP_DDIE_SHA1_M0 (6 << 20) /* Bspec says 5? */
+#define  SKL_HDCP_SHA1_BUSYBIT(16)
+#define  SKL_HDCP_SHA1_READY   BIT(17)
+#define  SKL_HDCP_SHA1_COMPLETEBIT(18)
+#define  SKL_HDCP_SHA1_V_MATCH BIT(19)
+#define  SKL_HDCP_SHA1_TEXT_32 (1 << 1)
+#define  SKL_HDCP_SHA1_COMPLETE_HASH   (2 << 1)
+#define  SKL_HDCP_SHA1_TEXT_24 (4 << 1)
+#define  SKL_HDCP_SHA1_TEXT_16 (5 << 1)
+#define  SKL_HDCP_SHA1_TEXT_8  (6 << 1)
+#define  SKL_HDCP_SHA1_TEXT_0  (7 << 1)
+#define SKL_HDCP_SHA_V_PRIME_H0_MMIO(0x66d04)
+#define SKL_HDCP_SHA_V_PRIME_H1_MMIO(0x66d08)
+#define SKL_HDCP_SHA_V_PRIME_H2_MMIO(0x66d0C)
+#define SKL_HDCP_SHA_V_PRIME_H3_MMIO(0x66d10)
+#define 

Re: [PATCH 1/3] eeprom: at25: Add DT support for EEPROMs with odd address bits

[Geert Uytterhoeven]

Hi Rob,

On Tue, Dec 5, 2017 at 9:57 AM, Geert Uytterhoeven  wrote:
> On Mon, Dec 4, 2017 at 10:17 PM, Rob Herring  wrote:
>> On Mon, Dec 04, 2017 at 10:17:47AM +0100, Geert Uytterhoeven wrote:
>>> On Thu, Nov 30, 2017 at 2:29 PM, Geert Uytterhoeven
>>>  wrote:
>>> > Certain EEPROMS have a size that is larger than the number of address
>>> > bytes would allow, and store the MSB of the address in bit 3 of the
>>> > instruction byte.
>>> >
>>> > This can be described in platform data using EE_INSTR_BIT3_IS_ADDR, or
>>> > in DT using the obsolete legacy "at25,addr-mode" property.
>>> > But currently there exists no non-deprecated way to describe this in DT.
>>> >
>>> > Hence extend the existing "address-width" DT property to allow
>>> > specifying 9, 17, or 25 address bits, and enable support for that in the
>>> > driver.
>>> >
>>> > Signed-off-by: Geert Uytterhoeven 
>>> > ---
>>> > EEPROMs using 9 address bits are common (e.g. M95040, 25AA040/25LC040).
>>> > Do EEPROMs using 17 or 25 address bits, as mentioned in
>>> > include/linux/spi/eeprom.h, really exist?
>>> > Or should we just limit it to a single odd value (9 bits)?
>>>
>>> At least for the real Atmel parts, only the AT25040 part uses odd (8 +
>>> 1 bit) addressing.
>>
>> Seems like we should have a specific compatible for it.
>
> Possibly. But currently all configuration is done through DT properties, not
> through matching on compatible values.

Adding compatible values for all known/used parts could quickly become a
large table.
E.g. Atmel/Microchip has 3 variants of 512-byte EEPROMs: AT25040B,
25LC040A, and 25AA040A. The former uses an 8-byte pagesize, while the
latter parts use 16-byte pagesizes.
Not to mention "compatible" parts from other manufacturers, and all other
supported size.

Currently all of this is configured through the "pagesize", "size", and
"address-width" DT properties, with matching on generic "atmel,at25".

Gr{oetje,eeting}s,

Geert

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

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

[PATCH 0/17] scsi: arcmsr: add some driver options and support new adapter ARC-1884

[Ching Huang]

From: Ching Huang 

Hi Martin,

Due to 4.16/scsi-queue conflict with 4.15-rc1, so I resubmit these patches 
again.
The following patches apply to Linus' 4.15-rc1 tree.

Patch 1: redefine ACB_ADAPTER_TYPE_A, _B, _C, _D and subsequent changes.

Patch 2: simplify arcmsr_iop_init function.

Patch 3: add codes for ACB_ADAPTER_TYPE_E to support new adapter ARC-1884

Patch 4. update ARCMSR_MAX_OUTSTANDING_CMD and ARCMSR_MAX_FREECCB_NUM to 1024

Patch 5: replace constant ARCMSR_MAX_FREECCB_NUM by variable acb->maxFreeCCB 
that was got from firmware.

Patch 6: add driver option host_can_queue to set host->can_queue value by user. 
It's value expands
 up to 1024.

Patch 7: replace constant ARCMSR_MAX_OUTSTANDING_CMD by variable 
acb->maxOutstanding that was determined by user.

Patch 8: add driver option cmd_per_lun to set host->cmd_per_lun value by user.

Patch 9: add ACB_F_MSG_GET_CONFIG to acb->acb_flags for for message interrupt 
checking before schedule work for
 get device map.

Patch 10: add a function arcmsr_set_iop_datetime and driver option 
set_date_time to set date and time to firmware.

Patch 11: fix clear doorbell queue on ACB_ADAPTER_TYPE_B controller.

Patch 12: spin off duplicate code of timer init for message isr BH in 
arcmsr_probe and arcmsr_resume as a function
  arcmsr_init_get_devmap_timer

Patch 13: adjust some tab or white-space to make text alignment.

Patch 14: fix grammar error.

Patch 15: Add module parameter msi_enable to has a chance to disable msi 
interrupt if it does not work properly.

Patch 16: Add module parameter msix_enable to has a chance to disable msix 
interrupt if it does not work properly.

Patch 17: update driver version to v1.40.00.04-20171130
---

Re: [PATCH] powerpc/xive: store server for masked interrupt in kvmppc_xive_set_xive()

[Laurent Vivier]

On 05/12/2017 04:05, Paul Mackerras wrote:
> On Fri, Nov 24, 2017 at 07:38:13AM +1100, Benjamin Herrenschmidt wrote:
>> On Thu, 2017-11-23 at 10:06 +0100, Laurent Vivier wrote:
>>> This is needed to map kvmppc_xive_set_xive() behavior
>>> to kvmppc_xics_set_xive().
>>>
>>> As we store the server, kvmppc_xive_get_xive() can return
>>> the good value and we can also allow kvmppc_xive_int_on().
>>>
>>> Signed-off-by: Laurent Vivier 
>>> ---
>>>  arch/powerpc/kvm/book3s_xive.c | 20 
>>>  1 file changed, 8 insertions(+), 12 deletions(-)
>>>
>>> diff --git a/arch/powerpc/kvm/book3s_xive.c b/arch/powerpc/kvm/book3s_xive.c
>>> index bf457843e032..2781b8733038 100644
>>> --- a/arch/powerpc/kvm/book3s_xive.c
>>> +++ b/arch/powerpc/kvm/book3s_xive.c
>>> @@ -584,10 +584,14 @@ int kvmppc_xive_set_xive(struct kvm *kvm, u32 irq, 
>>> u32 server,
>>>  *   we could initialize interrupts with valid default
>>>  */
>>>  
>>> -   if (new_act_prio != MASKED &&
>>> -   (state->act_server != server ||
>>> -state->act_priority != new_act_prio))
>>> -   rc = xive_target_interrupt(kvm, state, server, new_act_prio);
>>> +   if (state->act_server != server ||
>>> +   state->act_priority != new_act_prio) {
>>> +   if (new_act_prio != MASKED)
>>> +   rc = xive_target_interrupt(kvm, state, server,
>>> +  new_act_prio);
>>> +   if (!rc)
>>> +   state->act_server = server;
>>> +   }
>>
>> That leads to another problem with this code. My current implementation
>> is such that is a target queue is full, it will pick another target.
>> But here, we still update act_server to the passed-in server and
>> not the actual target...
> 
> So does that amount to a NAK?
> 
>>> /*
>>>  * Perform the final unmasking of the interrupt source
>>> @@ -646,14 +650,6 @@ int kvmppc_xive_int_on(struct kvm *kvm, u32 irq)
>>>  
>>> pr_devel("int_on(irq=0x%x)\n", irq);
>>>  
>>> -   /*
>>> -* Check if interrupt was not targetted
>>> -*/
>>> -   if (state->act_priority == MASKED) {
>>> -   pr_devel("int_on on untargetted interrupt\n");
>>> -   return -EINVAL;
>>> -   }
>>> -
>>
>> So my thinking here was that act_priority was never going to be MASKED
>> except if the interrupt had never been targetted anywhere at machine
>> startup time. Thus if act_priority is masked, the act_server field
>> cannot be trusted.
>>
>>> /* If saved_priority is 0xff, do nothing */
>>> if (state->saved_priority == MASKED)
>>> return 0;
> 
> How do you think this should be fixed?
> 
> Laurent, are you reworking the patch at the moment?

Not for the moment.

The easy way is to forbid to set interrupt value to the MASKED one with
xive_set_xive. I think it's allowed by the specs.

I've got another bug in the XICS emulation: when we migrate a guest
under stress, the pending interrupt is lost and the guest hangs on the
destination side. I'm trying to understand why.

Thanks,
Laurent

Re: [PATCH 3/8] mfd: axp20x: probe axp20x_adc driver for AXP813

[Maxime Ripard]

On Mon, Dec 04, 2017 at 03:12:49PM +0100, Quentin Schulz wrote:
> This makes the axp20x_adc driver probe with platform device id
> "axp813-adc".
> 
> Signed-off-by: Quentin Schulz 
> ---
>  drivers/mfd/axp20x.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/mfd/axp20x.c b/drivers/mfd/axp20x.c
> index 2468b43..42e54d1 100644
> --- a/drivers/mfd/axp20x.c
> +++ b/drivers/mfd/axp20x.c
> @@ -878,7 +878,9 @@ static struct mfd_cell axp813_cells[] = {
>   .resources  = axp803_pek_resources,
>   }, {
>   .name   = "axp20x-regulator",
> - }
> + }, {
> + .name   = "axp813-adc",
> + },

Any particular reason you're not adding it to the DT?

Thanks!
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com


signature.asc
Description: PGP signature

Re: Regression in e1000e since Kernel 4.14.3

[Gabriel C]

On 05.12.2017 07:19, Greg KH wrote:

On Tue, Dec 05, 2017 at 07:18:34AM +0100, Greg KH wrote:

On Tue, Dec 05, 2017 at 12:47:10AM +0100, Gabriel C wrote:

On 04.12.2017 23:10, rwar...@gmx.de wrote:


Hallo

someone and I got an regression with e1000e since kernel 4.14.3 and it seems 
there is 4.14.4 on the way without a fix.


bug report is here:

https://bugzilla.kernel.org/show_bug.cgi?id=198047


( added stable and netdev to CC )

Yes I have a box with e1000e and it seems something at least breaks NM after 
4.14.3.


Again, can people try 4.14.5-rc1?  It should be resolved there.


Oops, that would be 4.14.4-rc1.  Any why do you say above that is on the
way without a fix, did you test it?


I didn't tested 4.14.4-rc1 but somone from the bug report tested it and told is 
not resolved.

I'll fire up an build in a bit and let you know.

Re: [PATCH][next] misc: rtsx: rts5260: make several functions static

[Lee Jones]

On Mon, 04 Dec 2017, Colin King wrote:

> From: Colin Ian King 
> 
> Several functios are local to the source and do not need to be in global
> scope, so make them static.
> 
> Cleans up sparse warnings:
> symbol 'rts5260_get_ocpstat' was not declared. Should it be static?
> symbol 'rts5260_get_ocpstat2' was not declared. Should it be static?
> symbol 'rts5260_clear_ocpstat' was not declared. Should it be static?
> symbol 'rts5260_process_ocp' was not declared. Should it be static?
> symbol 'rts5260_init_hw' was not declared. Should it be static?
> symbol 'rts5260_set_aspm' was not declared. Should it be static?
> 
> Signed-off-by: Colin Ian King 
> ---
>  drivers/misc/cardreader/rts5260.c | 12 ++--
>  1 file changed, 6 insertions(+), 6 deletions(-)

Acked-by: Lee Jones 

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

Re: [PATCH] misc: rtsx: make several functions static

[Lee Jones]

On Mon, 04 Dec 2017, Colin King wrote:

> From: Colin Ian King 
> 
> Several functions are local to the source and do not need to be in global
> scope, so make them static.
> 
> Cleans up sparse warnings:
> symbol 'rtsx_pm_power_saving' was not declared. Should it be static?
> symbol 'rtsx_set_l1off_sub_cfg_d0' was not declared. Should it be static?
> symbol 'rtsx_pm_full_on' was not declared. Should it be static?
> symbol 'rtsx_comm_set_ltr_latency' was not declared. Should it be static?
> symbol 'rtsx_pci_process_ocp' was not declared. Should it be static?
> symbol 'rtsx_pci_process_ocp_interrupt' was not declared. Should it be
> static?
> 
> Signed-off-by: Colin Ian King 
> ---
>  drivers/misc/cardreader/rtsx_pcr.c | 12 ++--
>  1 file changed, 6 insertions(+), 6 deletions(-)

Acked-by: Lee Jones 

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

[f2fs-dev] [PATCH] f2fs: use unlikely for release case

[LiFan]

Since the variable release is only nonzero when another unlikely
case occurs, use unlikely() on it seems logical.

Signed-off-by: Fan li 
---
 fs/f2fs/f2fs.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
index 71fbba96..0f01af0 100644
--- a/fs/f2fs/f2fs.h
+++ b/fs/f2fs/f2fs.h
@@ -1594,7 +1594,7 @@ static inline int inc_valid_block_count(struct 
f2fs_sb_info *sbi,
}
spin_unlock(>stat_lock);
 
-   if (release)
+   if (unlikely(release))
dquot_release_reservation_block(inode, release);
f2fs_i_blocks_write(inode, *count, true, true);
return 0;
-- 
2.7.4

Re: [PATCH 1/3] eeprom: at25: Add DT support for EEPROMs with odd address bits

[Geert Uytterhoeven]

Hi Rob,

On Mon, Dec 4, 2017 at 10:17 PM, Rob Herring  wrote:
> On Mon, Dec 04, 2017 at 10:17:47AM +0100, Geert Uytterhoeven wrote:
>> On Thu, Nov 30, 2017 at 2:29 PM, Geert Uytterhoeven
>>  wrote:
>> > Certain EEPROMS have a size that is larger than the number of address
>> > bytes would allow, and store the MSB of the address in bit 3 of the
>> > instruction byte.
>> >
>> > This can be described in platform data using EE_INSTR_BIT3_IS_ADDR, or
>> > in DT using the obsolete legacy "at25,addr-mode" property.
>> > But currently there exists no non-deprecated way to describe this in DT.
>> >
>> > Hence extend the existing "address-width" DT property to allow
>> > specifying 9, 17, or 25 address bits, and enable support for that in the
>> > driver.
>> >
>> > Signed-off-by: Geert Uytterhoeven 
>> > ---
>> > EEPROMs using 9 address bits are common (e.g. M95040, 25AA040/25LC040).
>> > Do EEPROMs using 17 or 25 address bits, as mentioned in
>> > include/linux/spi/eeprom.h, really exist?
>> > Or should we just limit it to a single odd value (9 bits)?
>>
>> At least for the real Atmel parts, only the AT25040 part uses odd (8 +
>> 1 bit) addressing.
>
> Seems like we should have a specific compatible for it.

Possibly. But currently all configuration is done through DT properties, not
through matching on compatible values.

>> AT25M01 uses 3-byte addressing (it needs 17 bits).
>
> Do you need to know it is 17-bit vs. 24-bits? I'm guessing not as the
> unused bits are probably don't care.

The 17 bits can be derived from the EEPROM size in bytes (1 Mb = 128 KiB).
What is important to know is how to pass addresses to the device:
  1. 3 address bytes, OR
  2. 2 address bytes, and the odd MSB bit in the command byte.

But apparently the second scheme is not used for 17-bit addressing.

Gr{oetje,eeting}s,

Geert

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

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

Re: [PATCH] ARM: dts: sun8i: h3: enable USB OTG for NanoPi Neo board

[Maxime Ripard]

Hi,

On Fri, Dec 01, 2017 at 11:49:42PM +0100, Krzysztof Adamski wrote:
> Similarly to Orange Pi Zero, NanoPi Neo board has an USB OTG port with
> an ID pin but with unpowered VBUS. This patch enables this port in
> forced peripheral mode.
> 
> Signed-off-by: Krzysztof Adamski 
> ---
> arch/arm/boot/dts/sun8i-h3-nanopi-neo.dts | 17 +
> 1 file changed, 17 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/sun8i-h3-nanopi-neo.dts 
> b/arch/arm/boot/dts/sun8i-h3-nanopi-neo.dts
> index 78f6c24952dd..14c3f137dbd3 100644
> --- a/arch/arm/boot/dts/sun8i-h3-nanopi-neo.dts
> +++ b/arch/arm/boot/dts/sun8i-h3-nanopi-neo.dts
> @@ -53,3 +53,20 @@
>   allwinner,leds-active-low;
>   status = "okay";
> };
> +
> +_otg {
> + status = "okay";
> + dr_mode = "peripheral";
> +};
> +
> + {
> + usb0_id_det-gpios = < 6 12 GPIO_ACTIVE_HIGH>; /* PG12 */
> +};
> +
> + {
> + status = "okay";
> +};
> +
> + {
> + status = "okay";
> +};

Please sort the nodes in alphabetical order.

Also, does it make sense to add the OHCI and EHCI controller for a
peripheral-only device?

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com


signature.asc
Description: PGP signature

Re: [PATCH] drivers: pwm: pwm-atmel: implement suspend/resume functions

[Thierry Reding]

On Tue, Apr 11, 2017 at 11:53:11AM +0200, Boris Brezillon wrote:
> On Tue, 11 Apr 2017 12:41:59 +0300
> m18063  wrote:
> 
> > On 11.04.2017 11:56, Boris Brezillon wrote:
> > > On Tue, 11 Apr 2017 11:22:39 +0300
> > > m18063  wrote:
> > >   
> > >> Hi Boris,
> > >>
> > >> On 10.04.2017 17:35, Boris Brezillon wrote:  
> > >>> On Mon, 10 Apr 2017 17:20:20 +0300
> > >>> Claudiu Beznea  wrote:
> > >>> 
> >  Implement suspend and resume power management specific
> >  function to allow PWM controller to correctly suspend
> >  and resume.
> > 
> >  Signed-off-by: Claudiu Beznea 
> >  ---
> >   drivers/pwm/pwm-atmel.c | 81 
> >  +
> >   1 file changed, 81 insertions(+)
> > 
> >  diff --git a/drivers/pwm/pwm-atmel.c b/drivers/pwm/pwm-atmel.c
> >  index 530d7dc..75177c6 100644
> >  --- a/drivers/pwm/pwm-atmel.c
> >  +++ b/drivers/pwm/pwm-atmel.c
> >  @@ -58,6 +58,8 @@
> >   #define PWM_MAX_PRD   0x
> >   #define PRD_MAX_PRES  10
> >   
> >  +#define PWM_MAX_CH_NUM(4)
> >  +
> >   struct atmel_pwm_registers {
> > u8 period;
> > u8 period_upd;
> >  @@ -65,11 +67,18 @@ struct atmel_pwm_registers {
> > u8 duty_upd;
> >   };
> >   
> >  +struct atmel_pwm_pm_ctx {
> >  +  u32 cmr;
> >  +  u32 cdty;
> >  +  u32 cprd;
> >  +};
> >  +
> >   struct atmel_pwm_chip {
> > struct pwm_chip chip;
> > struct clk *clk;
> > void __iomem *base;
> > const struct atmel_pwm_registers *regs;
> >  +  struct atmel_pwm_pm_ctx ctx[PWM_MAX_CH_NUM];
> > >>>
> > >>> Hm, I'm pretty sure you can rely on the current PWM state and call
> > >>> atmel_pwm_apply() at resume time instead of doing that. See what I did
> > >>> here [1].
> > >>
> > >> I agree with the approach you propose but the thing is the 
> > >> atmel_pwm_apply()
> > >> take care of both, current PWM state and the new state received as 
> > >> argument
> > >> in order to change only duty factor without disabling the PWM channel (if
> > >> channel is enabled) and then returns. Changing PWM duty and period and 
> > >> polarity
> > >> in the same step without disabling + enabling the PWM channel (with 
> > >> atomic
> > >> approach) may lead to intermediary unwanted output waveforms (the IP 
> > >> doesn't
> > >> support this for ordinary PWM channels). To take advantage of 
> > >> atmel_pwm_apply()
> > >> (in the formit is today) in resume() hook might need to first call it to 
> > >> disable
> > >> channel and then to enable it. Or atmel_pwm_apply() should be changed to 
> > >> also
> > >> disable + enable the channel when user changes the duty factor at 
> > >> runtime.  
> > > 
> > > Nope. Just save the state at suspend time, implement ->get_state() and
> > > use it to retrieve the real PWM state when resuming before restoring
> > > the state you saved during suspend.  
> > Ok.
> > > But anyway, as Thierry explained, I'm not sure we should take the
> > > 're-apply PWM state' action here. It's probably better to leave this
> > > decision to the PWM user.   
> > Do you thinks we should proceed with restoring the registers behind
> > the re-apply as other drivers does at this moment?
> 
> Nope. IMO we'd better start patching PWM users to restore the states
> rather than supporting suspend/resume in all PWM drivers.
> 
> Thierry, what's your opinion?

I just noticed this thread while cleaning up patchwork. I think I had
already mentioned in an earlier reply that in my opinion we should leave
PWM suspend/resume to users.

I'm totally fine if we add helpers to the PWM core to help with that
task. Maybe something like this would work:

void pwm_suspend(struct pwm_device *pwm)
{
pwm_get_state(pwm, >suspend);
pwm_disable(pwm);
}

void pwm_resume(struct pwm_device *pwm)
{
pwm_apply_state(pwm, >suspend);
}

Though, quite frankly, this is so trivial that drivers could just do
that themselves. Also, the helpers above aren't flexible at all with
respect to any special sequences the PWM might need to go through on
suspend. I suspect that this doesn't matter at all in most cases but
given how trivial they are we might as well just make drivers do it.
Also we don't burden users that don't care about suspend/resume with
the extra suspend state in struct pwm_device.

Thierry


signature.asc
Description: PGP signature

[PATCH] perf evsel: Enable ignore_missing_thread for pid option

[Mengting Zhang]

While monitoring a multithread process with pid option, perf sometimes
may return sys_perf_event_open failure with 3(No such process) if any
of the process's threads die before we open the event. However, we want
perf continue monitoring the remaining threads and do not exit with error.

Here, the patch enables perf_evsel::ignore_missing_thread for -p option
to ignore complete failure if any of threads die before we open the event.
But it may still return sys_perf_event_open failure with 22(Invalid) if we
monitors several event groups.

sys_perf_event_open: pid 28960  cpu 40  group_fd 118202  flags 0x8
sys_perf_event_open: pid 28961  cpu 40  group_fd 118203  flags 0x8
WARNING: Ignored open failure for pid 28962
sys_perf_event_open: pid 28962  cpu 40  group_fd [118203]  flags 0x8
sys_perf_event_open failed, error -22

That is because when we ignore a missing thread, we change the thread_idx
without dealing with its fds, FD(evsel, cpu, thread). Then get_group_fd()
may return a wrong group_fd for the next thread and sys_perf_event_open()
return with 22.

sys_perf_event_open(){
   ...
   if (group_fd != -1)
   perf_fget_light()//to get corresponding group_leader by group_fd
   ...
   if (group_leader)
  if (group_leader->ctx->task != ctx->task)//should on the same task
   goto err_context
   ...
}

This patch also fixes this bug by introducing group_fd__remove() to allow
removing fds for the missing thread.

Signed-off-by: Mengting Zhang 
Signed-off-by: Cheng Jian 
---
 tools/perf/builtin-record.c |  4 ++--
 tools/perf/util/evsel.c | 42 --
 2 files changed, 42 insertions(+), 4 deletions(-)

diff --git a/tools/perf/builtin-record.c b/tools/perf/builtin-record.c
index 3d7f33e..86b2e03 100644
--- a/tools/perf/builtin-record.c
+++ b/tools/perf/builtin-record.c
@@ -1763,8 +1763,8 @@ int cmd_record(int argc, const char **argv)
goto out;
}
 
-   /* Enable ignoring missing threads when -u option is defined. */
-   rec->opts.ignore_missing_thread = rec->opts.target.uid != UINT_MAX;
+   /* Enable ignoring missing threads when -u/-p option is defined. */
+   rec->opts.ignore_missing_thread = rec->opts.target.uid != UINT_MAX || 
rec->opts.target.pid;
 
err = -ENOMEM;
if (perf_evlist__create_maps(rec->evlist, >opts.target) < 0)
diff --git a/tools/perf/util/evsel.c b/tools/perf/util/evsel.c
index f894893..5ca335d 100644
--- a/tools/perf/util/evsel.c
+++ b/tools/perf/util/evsel.c
@@ -1592,10 +1592,42 @@ static int __open_attr__fprintf(FILE *fp, const char 
*name, const char *val,
return fprintf(fp, "  %-32s %s\n", name, val);
 }
 
+static int group_fd__remove(struct perf_evsel *evsel,
+   int nr_cpus, int cpu_idx,
+   int nr_threads, int thread_idx)
+{
+   struct perf_evsel *pos;
+   struct perf_evlist *evlist = evsel->evlist;
+
+   if (nr_cpus < 1 || nr_threads < 1)
+   return -EINVAL;
+
+   if (cpu_idx >= nr_cpus || thread_idx >= nr_threads)
+   return -EINVAL;
+
+   evlist__for_each_entry(evlist, pos) {
+   if (pos != evsel) {
+   for (int cpu = 0; cpu < nr_cpus; cpu++)
+   for (int thread = thread_idx; thread < 
nr_threads; thread++)
+   FD(pos, cpu, thread) = FD(pos, cpu, 
thread + 1);
+   }
+   else {
+   for (int cpu = 0; cpu < cpu_idx; cpu++)
+   for (int thread = thread_idx; thread < 
nr_threads; thread++)
+   FD(pos, cpu, thread) = FD(pos, cpu, 
thread + 1);
+   break;
+   }
+   }
+   return 0;
+}
+
 static bool ignore_missing_thread(struct perf_evsel *evsel,
+ int nr_cpus, int cpu,
  struct thread_map *threads,
  int thread, int err)
 {
+   pid_t ignore_pid = thread_map__pid(threads, thread);
+
if (!evsel->ignore_missing_thread)
return false;
 
@@ -1611,11 +1643,17 @@ static bool ignore_missing_thread(struct perf_evsel 
*evsel,
if (threads->nr == 1)
return false;
 
+   /* We should remove group_fd for missing_thread first
+* because thread_map__remove() will decrease threads->nr.
+*/
+   if (group_fd__remove(evsel, nr_cpus, cpu, threads->nr, thread))
+   return false;
+
if (thread_map__remove(threads, thread))
return false;
 
pr_warning("WARNING: Ignored open failure for pid %d\n",
-  thread_map__pid(threads, thread));
+  ignore_pid);
return 

Re: possible deadlock in generic_file_write_iter (2)

[Dmitry Vyukov]

On Tue, Dec 5, 2017 at 5:58 AM, Byungchul Park  wrote:
> On 12/4/2017 5:33 PM, Jan Kara wrote:
>>
>> Hello,
>>
>> adding Peter and Byungchul to CC since the lockdep report just looks
>> strange and cross-release seems to be involved. Guys, how did #5 get into
>> the lock chain and what does put_ucounts() have to do with sb_writers
>> there? Thanks!
>
>
> Hello Jan,
>
> In order to get full stack of #5, we have to pass a boot param,
> "crossrelease_fullstack", to the kernel. Now that it only informs
> put_ucounts() in the call trace, it's hard to find out what exactly
> happened at that time, but I can tell #5 shows:
>
> When acquire(sb_writers) in put_ucounts(), it was on the way to
> complete((completion)) of wait_for_completion() in
> devtmpfs_create_node().
>
> If acquire(sb_writers) in put_ucounts() is stuck, then
> wait_for_completion() in devtmpfs_create_node() would be also
> stuck, since complete() being in the context of acquire(sb_writers)
> cannot be called.
>
> This is why cross-release added the lock chain.

Hi,

What is cross-release? Is it something new? Should we always enable
crossrelease_fullstack during testing?

Thanks

[PATCH 1/17] scsi: arcmsr: redefine ACB_ADAPTER_TYPE_A, _B, _C, _D and subsequent changes.

[Ching Huang]

From: Ching Huang 

redefine ACB_ADAPTER_TYPE_A, _B, _C, _D and subsequent changes.

Signed-off-by: Ching Huang 
---

diff -uprN a/drivers/scsi/arcmsr/arcmsr.h b/drivers/scsi/arcmsr/arcmsr.h
--- a/drivers/scsi/arcmsr/arcmsr.h  2017-12-05 10:45:50.0 +0800
+++ b/drivers/scsi/arcmsr/arcmsr.h  2017-08-03 18:54:46.0 +0800
@@ -621,10 +621,10 @@ struct MessageUnit_D {
 struct AdapterControlBlock
 {
uint32_t  adapter_type;/* adapter A,B. */
-   #define ACB_ADAPTER_TYPE_A0x0001/* hba I IOP */
-   #define ACB_ADAPTER_TYPE_B0x0002/* hbb M IOP */
-   #define ACB_ADAPTER_TYPE_C0x0004/* hbc P IOP */
-   #define ACB_ADAPTER_TYPE_D0x0008/* hbd A IOP */
+   #define ACB_ADAPTER_TYPE_A  0x  /* hba I IOP */
+   #define ACB_ADAPTER_TYPE_B  0x0001  /* hbb M IOP */
+   #define ACB_ADAPTER_TYPE_C  0x0002  /* hbc L IOP */
+   #define ACB_ADAPTER_TYPE_D  0x0003  /* hbd M IOP */
u32 roundup_ccbsize;
struct pci_dev *pdev;
struct Scsi_Host *  host;
diff -uprN a/drivers/scsi/arcmsr/arcmsr_hba.c b/drivers/scsi/arcmsr/arcmsr_hba.c
--- a/drivers/scsi/arcmsr/arcmsr_hba.c  2017-12-05 10:45:30.0 +0800
+++ b/drivers/scsi/arcmsr/arcmsr_hba.c  2017-12-05 11:47:40.0 +0800
@@ -1785,7 +1785,7 @@ arcmsr_Read_iop_rqbuffer_data(struct Ada
uint8_t __iomem *iop_data;
uint32_t iop_len;
 
-   if (acb->adapter_type & (ACB_ADAPTER_TYPE_C | ACB_ADAPTER_TYPE_D))
+   if (acb->adapter_type > ACB_ADAPTER_TYPE_B)
return arcmsr_Read_iop_rqbuffer_in_DWORD(acb, prbuffer);
iop_data = (uint8_t __iomem *)prbuffer->data;
iop_len = readl(>data_len);
@@ -1871,7 +1871,7 @@ arcmsr_write_ioctldata2iop(struct Adapte
uint8_t __iomem *iop_data;
int32_t allxfer_len = 0;
 
-   if (acb->adapter_type & (ACB_ADAPTER_TYPE_C | ACB_ADAPTER_TYPE_D)) {
+   if (acb->adapter_type > ACB_ADAPTER_TYPE_B) {
arcmsr_write_ioctldata2iop_in_DWORD(acb);
return;
}

Re: linux-next: Signed-off-by missing for commits in the drm tree

[Laurent Pinchart]

Hi Stephen,

On Tuesday, 5 December 2017 04:45:50 EET Stephen Rothwell wrote:
> Hi all,
> 
> Commits
> 
>   36a46da90212 ("drm: rcar-du: Add R8A7743 support")
>   cdd907001572 ("drm: rcar-du: Add R8A7745 support")
>   7912dee7775e ("drm: rcar-du: Implement system suspend/resume support")
>   cf05f74ef40e ("drm: rcar-du: Remove unused CRTC suspend/resume functions")
> 
> are missing a Signed-off-by from their committer.

I've sent lots of pull requests to maintainers in the past where I have picked 
patches signed off by the original author without any further modification and 
only added my Acked-by or Reviewed-by line. I thought this was an accepted 
practice as nobody ever complained, but I'll make sure to always include my 
SoB for any patch that goes through my tree in the future. I'm sorry about 
this, it's all my fault.

-- 
Regards,

Laurent Pinchart

Re: [linux-sunxi] [PATCH v4 09/10] ARM: dtsi: axp81x: add GPIO DT node

[Maxime Ripard]

Hi,

On Tue, Dec 05, 2017 at 05:24:47PM +0800, Chen-Yu Tsai wrote:
> On Fri, Dec 1, 2017 at 9:44 PM, Quentin Schulz
>  wrote:
> > This adds DT node for the GPIO/pinctrl part present in AXP813/AXP818.
> >
> > Signed-off-by: Quentin Schulz 
> > ---
> >  arch/arm/boot/dts/axp81x.dtsi | 6 ++
> >  1 file changed, 6 insertions(+)
> >
> > diff --git a/arch/arm/boot/dts/axp81x.dtsi b/arch/arm/boot/dts/axp81x.dtsi
> > index 73b761f..0ef959d 100644
> > --- a/arch/arm/boot/dts/axp81x.dtsi
> > +++ b/arch/arm/boot/dts/axp81x.dtsi
> > @@ -48,6 +48,12 @@
> > interrupt-controller;
> > #interrupt-cells = <1>;
> >
> > +   axp_gpio: axp-gpio {
> > +   compatible = "x-powers,axp813-gpio";
> > +   gpio-controller;
> > +   #gpio-cells = <2>;
> 
> What about interrupt-controller for directly referenced interrupts from
> the GPIO pins?

There's a bit more to it to enable interrupts. You would probably need
to set up a chained interrupt controller in the GPIO driver, and in
the DTS with a interrupt-parent and interrupts properties pointing to
the AXP device itself.

> Otherwise,
> 
> Acked-by: Chen-Yu Tsai 

Applied 9 and 10, thanks!
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com


signature.asc
Description: PGP signature

Re: [PATCH v2 1/3] mtd: nand: cafe: remove use of NAND_OWN_BUFFERS

[Boris Brezillon]

On Tue,  5 Dec 2017 17:47:14 +0900
Masahiro Yamada  wrote:

> This driver is the last/only user of NAND_OWN_BUFFERS.  Boris suggested
> to remove this flag.
> 
> Taking a closer look at this driver, it calls dma_alloc_coherent() for
> the concatenated area for the DMA bounce buffer + struct nand_buffers,
> but the latter does not need to be DMA-coherent; cafe_{write,read}_buf
> simply do memcpy() between buffers when usedma==1.
> 
> Let's do dma_alloc_coherent() for the DMA bounce buffer in the front,
> and leave the nand_buffers allocation to nand_scan_tail(), then rip off
> NAND_OWN_BUFFERS.
> 
> The magic number, 2112, is still mysterious (hard-coded writesize +
> oobsize ?),

Yep, 2k pages usually have 64b of OOB, hence the 2112 magic number
(2048 + 64).

> but this is not our main interest.  I am keeping it.

Agreed.

> 
> Suggested-by: Boris Brezillon 
> Signed-off-by: Masahiro Yamada 
> ---
> 
> Changes in v2:
>   - Newly added
> 
>  drivers/mtd/nand/cafe_nand.c | 24 
>  1 file changed, 4 insertions(+), 20 deletions(-)
> 
> diff --git a/drivers/mtd/nand/cafe_nand.c b/drivers/mtd/nand/cafe_nand.c
> index bc558c4..add4613 100644
> --- a/drivers/mtd/nand/cafe_nand.c
> +++ b/drivers/mtd/nand/cafe_nand.c
> @@ -613,7 +613,6 @@ static int cafe_nand_probe(struct pci_dev *pdev,
>   uint32_t ctrl;
>   int err = 0;
>   int old_dma;
> - struct nand_buffers *nbuf;
>  
>   /* Very old versions shared the same PCI ident for all three
>  functions on the chip. Verify the class too... */
> @@ -661,7 +660,6 @@ static int cafe_nand_probe(struct pci_dev *pdev,
>  
>   /* Enable the following for a flash based bad block table */
>   cafe->nand.bbt_options = NAND_BBT_USE_FLASH;
> - cafe->nand.options = NAND_OWN_BUFFERS;
>  
>   if (skipbbt) {
>   cafe->nand.options |= NAND_SKIP_BBTSCAN;
> @@ -731,15 +729,12 @@ static int cafe_nand_probe(struct pci_dev *pdev,
>   if (err)
>   goto out_irq;
>  
> - cafe->dmabuf = dma_alloc_coherent(>pdev->dev,
> - 2112 + sizeof(struct nand_buffers) +
> - mtd->writesize + mtd->oobsize,
> - >dmaaddr, GFP_KERNEL);
> + cafe->dmabuf = dma_alloc_coherent(>pdev->dev, 2112,
> +   >dmaaddr, GFP_KERNEL);
>   if (!cafe->dmabuf) {
>   err = -ENOMEM;
>   goto out_irq;
>   }
> - cafe->nand.buffers = nbuf = (void *)cafe->dmabuf + 2112;
>  
>   /* Set up DMA address */
>   cafe_writel(cafe, cafe->dmaaddr & 0x, NAND_DMA_ADDR0);
> @@ -752,11 +747,6 @@ static int cafe_nand_probe(struct pci_dev *pdev,
>   cafe_dev_dbg(>pdev->dev, "Set DMA address to %x (virt %p)\n",
>   cafe_readl(cafe, NAND_DMA_ADDR0), cafe->dmabuf);
>  
> - /* this driver does not need the @ecccalc and @ecccode */
> - nbuf->ecccalc = NULL;
> - nbuf->ecccode = NULL;
> - nbuf->databuf = (uint8_t *)(nbuf + 1);
> -
>   /* Restore the DMA flag */
>   usedma = old_dma;
>  
> @@ -801,10 +791,7 @@ static int cafe_nand_probe(struct pci_dev *pdev,
>   goto out;
>  
>   out_free_dma:
> - dma_free_coherent(>pdev->dev,
> - 2112 + sizeof(struct nand_buffers) +
> - mtd->writesize + mtd->oobsize,
> - cafe->dmabuf, cafe->dmaaddr);
> + dma_free_coherent(>pdev->dev, 2112, cafe->dmabuf, cafe->dmaaddr);
>   out_irq:
>   /* Disable NAND IRQ in global IRQ mask register */
>   cafe_writel(cafe, ~1 & cafe_readl(cafe, GLOBAL_IRQ_MASK), 
> GLOBAL_IRQ_MASK);
> @@ -829,10 +816,7 @@ static void cafe_nand_remove(struct pci_dev *pdev)
>   nand_release(mtd);
>   free_rs(cafe->rs);
>   pci_iounmap(pdev, cafe->mmio);
> - dma_free_coherent(>pdev->dev,
> - 2112 + sizeof(struct nand_buffers) +
> - mtd->writesize + mtd->oobsize,
> - cafe->dmabuf, cafe->dmaaddr);
> + dma_free_coherent(>pdev->dev, 2112, cafe->dmabuf, cafe->dmaaddr);
>   kfree(cafe);
>  }
>  

[PATCH 5/17] scsi: arcmsr: replace constant ARCMSR_MAX_FREECCB_NUM by variable

[Ching Huang]

From: Ching Huang 

replace constant ARCMSR_MAX_FREECCB_NUM by variable acb->maxFreeCCB that was 
got from firmware

Signed-off-by: Ching Huang 
---

diff -uprN a/drivers/scsi/arcmsr/arcmsr.h b/drivers/scsi/arcmsr/arcmsr.h
--- a/drivers/scsi/arcmsr/arcmsr.h  2017-12-05 15:24:16.0 +0800
+++ b/drivers/scsi/arcmsr/arcmsr.h  2017-12-05 15:25:06.0 +0800
@@ -831,6 +831,7 @@ struct AdapterControlBlock
atomic_tante_token_value;
uint32_tmaxOutstanding;
int vector_count;
+   uint32_tmaxFreeCCB;
uint32_tdoneq_index;
uint32_tccbsize;
uint32_tin_doorbell;
diff -uprN a/drivers/scsi/arcmsr/arcmsr_hba.c b/drivers/scsi/arcmsr/arcmsr_hba.c
--- a/drivers/scsi/arcmsr/arcmsr_hba.c  2017-12-05 11:47:16.0 +0800
+++ b/drivers/scsi/arcmsr/arcmsr_hba.c  2017-12-05 11:47:04.0 +0800
@@ -688,7 +688,7 @@ static int arcmsr_alloc_ccb_pool(struct 
acb->host->max_sectors = max_xfer_len/512;
acb->host->sg_tablesize = max_sg_entrys;
roundup_ccbsize = roundup(sizeof(struct CommandControlBlock) + 
(max_sg_entrys - 1) * sizeof(struct SG64ENTRY), 32);
-   acb->uncache_size = roundup_ccbsize * ARCMSR_MAX_FREECCB_NUM;
+   acb->uncache_size = roundup_ccbsize * acb->maxFreeCCB;
dma_coherent = dma_alloc_coherent(>dev, acb->uncache_size, 
_coherent_handle, GFP_KERNEL);
if(!dma_coherent){
printk(KERN_NOTICE "arcmsr%d: dma_alloc_coherent got error\n", 
acb->host->host_no);
@@ -700,7 +700,7 @@ static int arcmsr_alloc_ccb_pool(struct 
acb->ccbsize = roundup_ccbsize;
ccb_tmp = dma_coherent;
acb->vir2phy_offset = (unsigned long)dma_coherent - (unsigned 
long)dma_coherent_handle;
-   for(i = 0; i < ARCMSR_MAX_FREECCB_NUM; i++){
+   for(i = 0; i < acb->maxFreeCCB; i++){
cdb_phyaddr = dma_coherent_handle + offsetof(struct 
CommandControlBlock, arcmsr_cdb);
switch (acb->adapter_type) {
case ACB_ADAPTER_TYPE_A:
@@ -1427,7 +1427,7 @@ static void arcmsr_remove(struct pci_dev
 
arcmsr_abort_allcmd(acb);
arcmsr_done4abort_postqueue(acb);
-   for (i = 0; i < ARCMSR_MAX_FREECCB_NUM; i++) {
+   for (i = 0; i < acb->maxFreeCCB; i++) {
struct CommandControlBlock *ccb = acb->pccb_pool[i];
if (ccb->startdone == ARCMSR_CCB_START) {
ccb->startdone = ARCMSR_CCB_ABORTED;
@@ -3239,6 +3239,9 @@ static bool arcmsr_get_firmware_spec(str
else
acb->maxOutstanding = acb->firm_numbers_queue - 1;
acb->host->can_queue = acb->maxOutstanding;
+   acb->maxFreeCCB = acb->host->can_queue;
+   if (acb->maxFreeCCB < ARCMSR_MAX_FREECCB_NUM)
+   acb->maxFreeCCB += 64;
return rtn;
 }
 
@@ -4261,7 +4264,7 @@ static uint8_t arcmsr_iop_reset(struct A
rtnval = arcmsr_abort_allcmd(acb);
/* clear all outbound posted Q */
arcmsr_done4abort_postqueue(acb);
-   for (i = 0; i < ARCMSR_MAX_FREECCB_NUM; i++) {
+   for (i = 0; i < acb->maxFreeCCB; i++) {
ccb = acb->pccb_pool[i];
if (ccb->startdone == ARCMSR_CCB_START) {
scsi_dma_unmap(ccb->pcmd);
@@ -4369,7 +4372,7 @@ static int arcmsr_abort(struct scsi_cmnd
}
 
intmask_org = arcmsr_disable_outbound_ints(acb);
-   for (i = 0; i < ARCMSR_MAX_FREECCB_NUM; i++) {
+   for (i = 0; i < acb->maxFreeCCB; i++) {
struct CommandControlBlock *ccb = acb->pccb_pool[i];
if (ccb->startdone == ARCMSR_CCB_START && ccb->pcmd == cmd) {
ccb->startdone = ARCMSR_CCB_ABORTED;

Re: [PATCH] checkpatch: warn for use of %px

[Tobin C. Harding]

On Mon, Dec 04, 2017 at 11:24:24PM -0800, Joe Perches wrote:
> On Tue, 2017-12-05 at 08:17 +1100, Tobin C. Harding wrote:
> > Usage of the new %px specifier potentially leaks sensitive
> > inforamtion. Printing kernel addresses exposes the kernel layout in
> 
> information

I don't understand this comment? Do you mean the wording is wrong? I'll
re-word as suggested below.

> > memory, this is potentially exploitable. We have tools in the kernel to
> > help us do the right thing. We can have checkpatch warn developers of
> > potential dangers of using %px.
> > 
> > Have checkpatch emit a warning for usage of specifier %px.
> > 
> > Suggested-by: Andrew Morton 
> > Signed-off-by: Tobin C. Harding 
> > Co-Developed-by: Joe Perches 
> > 
> > ---
> > 
> > Joe,
> > 
> > Are you happy with this tagging? Needs your signed-off-by still.
> 
> Maybe with a few corrections (below)

thanks for the tips.

> > Andrew,
> > 
> > Is it okay to add your Suggested-by tag here?
> > 
> > I'm not entirely sure when one is supposed to add someones signed-off-by
> > tag since the docs state that it should not be added without
> > permission. I am also unsure where/when is the best time to request this
> > permission.
> []
> > diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
> []
> > @@ -1612,6 +1612,17 @@ sub raw_line {
> > return $line;
> >  }
> >  
> > +sub stat_real {
> > +   my ($linenr, $lc) = @_;
> > +
> > +   my $stat_real = raw_line($linenr, 0);
> > +   for (my $count = $linenr + 1; $count <= $lc; $count++) {
> > +   $stat_real = $stat_real . "\n" . raw_line($count, 0);
> > +   }
> > +
> > +   return $stat_real;
> > +}
> 
> If you are going to make a subroutine of this
> there are some other places it could be used too.

Ok, I'm not super happy with sub routine name. Have you a better suggestion?

> > +
> >  sub cat_vet {
> > my ($vet) = @_;
> > my ($res, $coded);
> > @@ -5747,24 +5758,35 @@ sub process {
> > defined $stat &&
> > $stat =~ /^\+(?![^\{]*\{\s*).*\b(\w+)\s*\(.*$String\s*,/s &&
> > $1 !~ /^_*volatile_*$/) {
> > -   my $bad_extension = "";
> > +   my ($specifier, $extension, $stat_real);
> 
> My preference is not to define multiple variables on a single line.
> I'd rather have:
>   my $specifier;
>   my $extension;
>   my $stat_real;

No problem, is this a kernel wide thing or just a checkpatch thing (so I
can follow your lead if need be in leaking_addresses.pl). Or is it the
same as we do in C, in which case $extension and $specifier could be on
a single line but not $stat_real?

> > +   my $bad_specifier = "";
> > my $lc = $stat =~ tr@\n@@;
> > $lc = $lc + $linenr;
> > for (my $count = $linenr; $count <= $lc; $count++) {
> > my $fmt = get_quoted_string($lines[$count - 1], 
> > raw_line($count, 0));
> > $fmt =~ s/%%//g;
> > -   if ($fmt =~ 
> > /(\%[\*\d\.]*p(?![\WFfSsBKRraEhMmIiUDdgVCbGNOx]).)/) {
> > -   $bad_extension = $1;
> > -   last;
> > +
> > +   while ($fmt =~ /(\%[\*\d\.]*p(\w))/g) {
> > +   $specifier = $1;
> > +   $extension = $2;
> > +   if ($extension !~ 
> > /[FfSsBKRraEhMmIiUDdgVCbGNOx]/) {
> > +   $bad_specifier = $specifier;
> > +   last;
> > +   }
> > +   if ($extension eq "x" && 
> > !defined($stat_real)) {
> > +   if (!defined($stat_real)) {
> > +   $stat_real = 
> > stat_real($linenr, $lc);
> > +   }
> > +   WARN("VSPRINTF_SPECIFIER_PX",
> > +"Using vsprintf specifier 
> > '\%px' potentially exposes the kernel layout in memory, if you don't 
> > _realy_ need the address please consider using '\%p'.\n" . 
> > "$here\n$stat_real\n");  
> 
> "kernel memory layout" not "kernel layout in memory"
> "really" not "_realy_"

Got it.

thanks,
Tobin.

[PATCH 9/17] scsi: arcmsr: add ACB_F_MSG_GET_CONFIG to acb->acb_flags for for message interrupt checking before schedule work for get device map

[Ching Huang]

From: Ching Huang 

add ACB_F_MSG_GET_CONFIG to acb->acb_flags for for message interrupt checking 
before schedule work for get device map

Signed-off-by: Ching Huang 
---

diff -uprN a/drivers/scsi/arcmsr/arcmsr.h b/drivers/scsi/arcmsr/arcmsr.h
--- a/drivers/scsi/arcmsr/arcmsr.h  2017-12-05 15:26:32.0 +0800
+++ b/drivers/scsi/arcmsr/arcmsr.h  2017-12-05 15:27:04.0 +0800
@@ -782,6 +782,7 @@ struct AdapterControlBlock
/* iop init */
#define ACB_F_ABORT 0x0200
#define ACB_F_FIRMWARE_TRAP 0x0400
+   #define ACB_F_MSG_GET_CONFIG0x1000
struct CommandControlBlock *
pccb_pool[ARCMSR_MAX_FREECCB_NUM];
/* used for memory free */
struct list_headccb_free_list;
diff -uprN a/drivers/scsi/arcmsr/arcmsr_hba.c b/drivers/scsi/arcmsr/arcmsr_hba.c
--- a/drivers/scsi/arcmsr/arcmsr_hba.c  2017-12-05 11:46:18.0 +0800
+++ b/drivers/scsi/arcmsr/arcmsr_hba.c  2017-12-05 11:46:06.0 +0800
@@ -743,6 +743,7 @@ static void arcmsr_message_isr_bh_fn(str
struct scsi_device *psdev;
char diff, temp;
 
+   acb->acb_flags &= ~ACB_F_MSG_GET_CONFIG;
switch (acb->adapter_type) {
case ACB_ADAPTER_TYPE_A: {
struct MessageUnit_A __iomem *reg  = acb->pmuA;
@@ -2328,7 +2329,8 @@ static void arcmsr_hbaA_message_isr(stru
struct MessageUnit_A __iomem *reg  = acb->pmuA;
/*clear interrupt and message state*/
writel(ARCMSR_MU_OUTBOUND_MESSAGE0_INT, >outbound_intstatus);
-   schedule_work(>arcmsr_do_message_isr_bh);
+   if (acb->acb_flags & ACB_F_MSG_GET_CONFIG)
+   schedule_work(>arcmsr_do_message_isr_bh);
 }
 static void arcmsr_hbaB_message_isr(struct AdapterControlBlock *acb)
 {
@@ -2336,7 +2338,8 @@ static void arcmsr_hbaB_message_isr(stru
 
/*clear interrupt and message state*/
writel(ARCMSR_MESSAGE_INT_CLEAR_PATTERN, reg->iop2drv_doorbell);
-   schedule_work(>arcmsr_do_message_isr_bh);
+   if (acb->acb_flags & ACB_F_MSG_GET_CONFIG)
+   schedule_work(>arcmsr_do_message_isr_bh);
 }
 /*
 
**
@@ -2352,7 +2355,8 @@ static void arcmsr_hbaC_message_isr(stru
struct MessageUnit_C __iomem *reg  = acb->pmuC;
/*clear interrupt and message state*/
writel(ARCMSR_HBCMU_IOP2DRV_MESSAGE_CMD_DONE_DOORBELL_CLEAR, 
>outbound_doorbell_clear);
-   schedule_work(>arcmsr_do_message_isr_bh);
+   if (acb->acb_flags & ACB_F_MSG_GET_CONFIG)
+   schedule_work(>arcmsr_do_message_isr_bh);
 }
 
 static void arcmsr_hbaD_message_isr(struct AdapterControlBlock *acb)
@@ -2361,7 +2365,8 @@ static void arcmsr_hbaD_message_isr(stru
 
writel(ARCMSR_ARC1214_IOP2DRV_MESSAGE_CMD_DONE, reg->outbound_doorbell);
readl(reg->outbound_doorbell);
-   schedule_work(>arcmsr_do_message_isr_bh);
+   if (acb->acb_flags & ACB_F_MSG_GET_CONFIG)
+   schedule_work(>arcmsr_do_message_isr_bh);
 }
 
 static void arcmsr_hbaE_message_isr(struct AdapterControlBlock *acb)
@@ -2369,7 +2374,8 @@ static void arcmsr_hbaE_message_isr(stru
struct MessageUnit_E __iomem *reg  = acb->pmuE;
 
writel(0, >host_int_status);
-   schedule_work(>arcmsr_do_message_isr_bh);
+   if (acb->acb_flags & ACB_F_MSG_GET_CONFIG)
+   schedule_work(>arcmsr_do_message_isr_bh);
 }
 
 static int arcmsr_hbaA_handle_isr(struct AdapterControlBlock *acb)
@@ -3826,6 +3832,7 @@ static void arcmsr_hbaA_request_device_m
return;
}
writel(ARCMSR_INBOUND_MESG0_GET_CONFIG, >inbound_msgaddr0);
+   acb->acb_flags |= ACB_F_MSG_GET_CONFIG;
mod_timer(>eternal_timer, jiffies + msecs_to_jiffies(6 * 
HZ));
}
return;
@@ -3848,6 +3855,7 @@ static void arcmsr_hbaB_request_device_m
return;
}
writel(ARCMSR_MESSAGE_GET_CONFIG, reg->drv2iop_doorbell);
+   acb->acb_flags |= ACB_F_MSG_GET_CONFIG;
mod_timer(>eternal_timer, jiffies + msecs_to_jiffies(6 * 
HZ));
}
return;
@@ -3871,6 +3879,7 @@ static void arcmsr_hbaC_request_device_m
}
writel(ARCMSR_INBOUND_MESG0_GET_CONFIG, >inbound_msgaddr0);
writel(ARCMSR_HBCMU_DRV2IOP_MESSAGE_CMD_DONE, 
>inbound_doorbell);
+   acb->acb_flags |= ACB_F_MSG_GET_CONFIG;
mod_timer(>eternal_timer, jiffies + msecs_to_jiffies(6 * 
HZ));
}
return;
@@ -3900,6 +3909,7 @@ static void arcmsr_hbaD_request_device_m
}
writel(ARCMSR_INBOUND_MESG0_GET_CONFIG,
reg->inbound_msgaddr0);
+   acb->acb_flags |= ACB_F_MSG_GET_CONFIG;

Re: [PATCH 0/7 v2] net: Fix platform_get_irq's error checking

[Sergei Shtylyov]

On 12/5/2017 12:54 PM, Sergei Shtylyov wrote:


The platform_get_irq() function returns negative number if an error
occurs, Zero if No irq is found and positive number if irq gets successful.


    No, returning 0 is not a failure indication anymore! It used to be but not 
any longer...


   And I fixed this function exactly to avoid overly complex error checks 
(which you're trying to propose here).



platform_get_irq() error checking for only zero is not correct.


[...]


MBR, Sergei

Re: [PATCH] power: ltc2941-battery-gauge: Disable continuous monitoring on shutdown

[Mike Looijmans]

On 01-12-17 16:42, Sebastian Reichel wrote:

Hi,

On Thu, Nov 23, 2017 at 03:41:05PM +0100, Mike Looijmans wrote:

The driver sets the fuel gauge to continuous monitoring on startup, for
the models that support this. When the board shuts down, the chip remains
in that mode, causing a few mA drain on the battery every 2 or 10 seconds.

This patch registers a shutdown handler that turns off the monitoring to
prevent this battery drain.

Signed-off-by: Mike Looijmans 
---


Thanks, queued. I wonder if you need a second patch to also disable
the monitoring for suspend (and re-enable on resume)?


For now, yes, that would probably make sense.

The gauge also has "alert" functionality, once that is enabled in the 
driver, the monitoring shouldn't be disabled and the device would even 
be able to wake the system. But that's no concern yet, so just stopping 
it on suspend would be better for now.





-- Sebastian


  drivers/power/supply/ltc2941-battery-gauge.c | 25 +
  1 file changed, 25 insertions(+)

diff --git a/drivers/power/supply/ltc2941-battery-gauge.c 
b/drivers/power/supply/ltc2941-battery-gauge.c
index 08e4fd9..4cfa3f0 100644
--- a/drivers/power/supply/ltc2941-battery-gauge.c
+++ b/drivers/power/supply/ltc2941-battery-gauge.c
@@ -60,6 +60,7 @@ enum ltc294x_id {
  #define LTC294X_REG_CONTROL_PRESCALER_SET(x) \
((x << 3) & LTC294X_REG_CONTROL_PRESCALER_MASK)
  #define LTC294X_REG_CONTROL_ALCC_CONFIG_DISABLED  0
+#define LTC294X_REG_CONTROL_ADC_DISABLE(x) ((x) & ~(BIT(7) | BIT(6)))
  
  struct ltc294x_info {

struct i2c_client *client;  /* I2C Client pointer */
@@ -523,6 +524,29 @@ static int ltc294x_i2c_probe(struct i2c_client *client,
return 0;
  }
  
+static void ltc294x_i2c_shutdown(struct i2c_client *client)

+{
+   struct ltc294x_info *info = i2c_get_clientdata(client);
+   int ret;
+   u8 value;
+   u8 control;
+
+   /* The LTC2941 does not need any special handling */
+   if (info->id == LTC2941_ID)
+   return;
+
+   /* Read control register */
+   ret = ltc294x_read_regs(info->client, LTC294X_REG_CONTROL, , 1);
+   if (ret < 0)
+   return;
+
+   /* Disable continuous ADC conversion as this drains the battery */
+   control = LTC294X_REG_CONTROL_ADC_DISABLE(value);
+   if (control != value)
+   ltc294x_write_regs(info->client, LTC294X_REG_CONTROL,
+   , 1);
+}
+
  #ifdef CONFIG_PM_SLEEP
  
  static int ltc294x_suspend(struct device *dev)

@@ -589,6 +613,7 @@ static int ltc294x_resume(struct device *dev)
},
.probe  = ltc294x_i2c_probe,
.remove = ltc294x_i2c_remove,
+   .shutdown   = ltc294x_i2c_shutdown,
.id_table   = ltc294x_i2c_id,
  };
  module_i2c_driver(ltc294x_driver);
--
1.9.1




--
Mike Looijmans


Kind regards,

Mike Looijmans
System Expert

TOPIC Products
Materiaalweg 4, NL-5681 RJ Best
Postbus 440, NL-5680 AK Best
Telefoon: +31 (0) 499 33 69 79
E-mail: mike.looijm...@topicproducts.com
Website: www.topicproducts.com

Please consider the environment before printing this e-mail

Re: net/wireless/shipped-certs.c:2:1: error: expected expression at end of input

[Johannes Berg]

On Tue, 2017-12-05 at 11:01 +0100, Paul Menzel wrote:
> 
> 
> ```
> $ git describe
> v4.15-rc2-79-gfd6d2e506ce6
> $ git log --oneline -1
> fd6d2e506ce6 Merge tag 'docs-4.15-fixes' of git://git.lwn.net/linux
> $ time ARCH=i386 make deb-pkg -j50
> […]
> net/wireless/shipped-certs.c:2:1: error: expected expression at end of input
>   const u8 shipped_regdb_certs[] = {
>   ^
> […]
> $ more net/wireless/shipped-certs.c
> #include "reg.h"
> const u8 shipped_regdb_certs[] = {
> ```

Ah, here we go - you probably don't have "hexdump" installed on this
system?

I thought about doing hexdump in posix shell/awk/sed/whatever
instead... maybe I should do that.

johannes

Re: [PATCH] mtd: nand: squash struct nand_buffers into struct nand_chip

[Masahiro Yamada]

Hi Boris,

2017-12-04 18:10 GMT+09:00 Boris Brezillon :

>>   }
>>
>>   if (!(chip->options & NAND_OWN_BUFFERS)) {
>> - nbuf = kzalloc(sizeof(*nbuf), GFP_KERNEL);
>> - if (!nbuf)
>> + chip->ecccalc = kmalloc(mtd->oobsize, GFP_KERNEL);
>> + if (!chip->ecccalc)
>>   return -ENOMEM;
>>
>> - nbuf->ecccalc = kmalloc(mtd->oobsize, GFP_KERNEL);
>> - if (!nbuf->ecccalc) {
>> + chip->ecccode = kmalloc(mtd->oobsize, GFP_KERNEL);
>> + if (!chip->ecccode) {
>>   ret = -ENOMEM;
>>   goto err_free_nbuf;
>>   }
>
> Hm, again not directly related to this patch, but I wonder if we
> couldn't allocate those buffers only when they are really needed. For
> example, most NAND controllers do the ECC calculation/correct in HW and
> simply don't need those buffers.


The only idea I came up with is to add a new flag,
but I am not sure if you are happy with it
because we are removing NAND_OWN_BUFFERS.





-- 
Best Regards
Masahiro Yamada

[PATCH 11/17] scsi: arcmsr: fix clear doorbell queue on ACB_ADAPTER_TYPE_B controller

[Ching Huang]

From: Ching Huang 

fix clear doorbell queue on ACB_ADAPTER_TYPE_B controller

Signed-off-by: Ching Huang 
---

diff -uprN a/drivers/scsi/arcmsr/arcmsr_hba.c b/drivers/scsi/arcmsr/arcmsr_hba.c
--- a/drivers/scsi/arcmsr/arcmsr_hba.c  2017-12-05 11:45:52.0 +0800
+++ b/drivers/scsi/arcmsr/arcmsr_hba.c  2017-12-05 11:45:34.0 +0800
@@ -4196,10 +4196,19 @@ static void arcmsr_clear_doorbell_queue_
 
case ACB_ADAPTER_TYPE_B: {
struct MessageUnit_B *reg = acb->pmuB;
-   /*clear interrupt and message state*/
-   writel(ARCMSR_MESSAGE_INT_CLEAR_PATTERN, reg->iop2drv_doorbell);
+   uint32_t outbound_doorbell, i;
+   writel(ARCMSR_DOORBELL_INT_CLEAR_PATTERN, 
reg->iop2drv_doorbell);
writel(ARCMSR_DRV2IOP_DATA_READ_OK, reg->drv2iop_doorbell);
/* let IOP know data has been read */
+   for(i=0; i < 200; i++) {
+   msleep(20);
+   outbound_doorbell = readl(reg->iop2drv_doorbell);
+   if( outbound_doorbell & ARCMSR_IOP2DRV_DATA_WRITE_OK) {
+   writel(ARCMSR_DOORBELL_INT_CLEAR_PATTERN, 
reg->iop2drv_doorbell);
+   writel(ARCMSR_DRV2IOP_DATA_READ_OK, 
reg->drv2iop_doorbell);
+   } else
+   break;
+   }
}
break;
case ACB_ADAPTER_TYPE_C: {

[RFC v3 PATCH 0/2] Introduce Security Version to EFI Stub

[Gary Lin]

The series of patches introduce Security Version to EFI stub.

Security Version is a monotonically increasing number and designed to
prevent the user from loading an insecure kernel accidentally. The
bootloader maintains a list of security versions corresponding to
different distributions. After fixing a critical vulnerability, the
distribution kernel maintainer bumps the "version", and the bootloader
updates the list automatically. When the user tries to load a kernel
with a lower security version, the bootloader shows a warning prompt
to notify the user the potential risk.

For more details: https://github.com/lcp/shim/wiki/Security-Version

The original idea is to add a new PE/COFF section to store the data.
However, there are some restrictions.

1. For x86, the size limit of the EFI header is 0x200, and a section entry
   in the section table takes 40 bytes. Currently, the EFI header already
   occupies the first 0x1da bytes, so there is no room for a new section
   entry.

2. The MemoryAttributes table sets the attributes of memory pages according
   to the section flags. For ARM64, the minimal granularity is 4KB, but
   Security Version only needs a few bytes, and it's pointless to allocate
   4KB for it.

Fortunately, there is a special section defined in PE/COFF: resource
section. The only known user of the resource section in UEFI is the HII
protocol which fetches data from "HII" directory. For Security Version, a
new directory called "LinuxSV" is created and it contains the file offset
to the struct of Security Version. The bootloader just follows the
resource table to fetch the "version" from the image file.

v3:
- Move everything to the resource section to be compatible with both
  x86 and ARM64
v2:
- Decrease the size of secdata_offset to 2 bytes since the setup header
  is limited to around 32KB.
- Restructure the secdata section. The signer is now a null-terminated
  string. The type of distro_version changes to u32 in case the distro
  uses a long version.
- Modify the Kconfig names and add help.
- Remove the signer name hack in build.c.

Cc: "H. Peter Anvin" 
Cc: Thomas Gleixner 
Cc: Ard Biesheuvel 
Cc: Ingo Molnar 
Cc: Matt Fleming 
Cc: Catalin Marinas 
Cc: Will Deacon 
Cc: Joey Lee 
Signed-off-by: Gary Lin 

Gary Lin (2):
  x86/efi: Introduce Security Version to x86
  arm64/efi: Introduce Security Version to ARM64

 arch/arm64/kernel/efi-header.S | 57 ++
 arch/x86/boot/header.S | 55 
 drivers/firmware/efi/Kconfig   | 40 +
 3 files changed, 152 insertions(+)

-- 
2.15.0

Re: [RFC 0/3] Safe, dynamically (un)loadable LSMs

[Sargun Dhillon]

On Wed, Nov 29, 2017 at 6:28 PM, Casey Schaufler  wrote:
> On 11/26/2017 2:15 PM, Sargun Dhillon wrote:
>> This patchset introduces safe dynamic LSM support. It does this via
>> SRCU-protected security hooks. It also EXPORT_SYMBOL_GPLs the symbols
>> required to perform runtime loading, and unloading. The patchset is
>> meant to introduce as little overhead as possible when not used.
>> Additionally, the functionality is disabled by default.
>
> Can you explain the value in being able to unload a security module?
> I can see having a throttle on an active module, but what do you gain
> by being able to unload it? Can it possibly be worth the inevitable
> memory leaks and almost certain dangling pointers? The restrictions on
> a security module that can work safely in this environment are significant.
> I don't see any point in unloading a module that could work with those
> restrictions. The overhead of making it unloadable is likely to exceed
> the overhead of running it.
>
There are three things here:
1) I wanted to replicate what in-kernel security hooks could do.
security_delete_hooks exists today, and although I'm not sure how it
can safely be used, even though it called as list_del_rcu, I'm not
sure if there is any way to ensure safety around ensuring there are no
more remaining references. I didn't dig into this too deeply.
2) In the future, I want to extend this patch and add the idea of
"immutable hooks" i.e. hooks which can only be loaded, but not
unloaded. If we combine this with the sealable memory allocator, it
provides some interesting security guarantees, especially if we
incorporate some of the other patches around the sealable memory
allocator.
3) My personal reason for wanting this is actually tied to my use
case. I have certain policies which are far easier to express by
writing some C-code (a module), as opposed to writing a generic
loader. Often times these modules are a few lines of code, and the
rulesets are changed on the fly. Although this could be implemented be
adding lots of hooks, the overhead starts to become unreasonable,
especially when newer hooks obsolete older hooks. -- Think nftables or
systemtap -- sometimes, the environment changes, and you need to
reconfigure your system.

I started going down the route of benchmarking these things, but
unfortunately, with the machines I have access to, I can't see the
performance counters, so I'm unable to see differences in performance
other than wall-clock time. I can dig in a little bit more, but we can
always gate module unloading behind a config flag if you think that's
best. If it's disabled, there's no reason to do this whole SRCU thing
at all.

>>
>> The SRCU was made safe to call from an interrupt context in the patch
>> "srcu: Allow use of Classic SRCU from both process and interrupt context"
>> (1123a6041654e8f889014659593bad4168e542c2) by Paolo Bonzini. Therefore
>> this mechanism is safe to use for traversal of the callback list,
>> even when a hook is called from the interrupt context.
>>
>> Currently, this maintains an entirely seperate mechanism to attach hooks
>> because the hooks are behind managed static_keys to prevent overhead.
>> This is also done so sealable memory support could be added at a later
>> point. The callbacks currently include a percpu_counter, but that could
>> sit outside of the struct itself. This may also have a benefit that these
>> counters, could have __cacheline_aligned_in_smp. Although, in my testing
>> I was unable to find much performance delta with percpu_counters that
>> were not aligned.
>>
>> It includes an example LSM that prevents specific time travel.
>
> Time based controls (e.g. you can't execute files in /usr/games between
> 8:00 and 17:00) would be cool. I suggested them in the 1980's, but
> no one has gotten around to implementing them. :)
>
>>
>> Sargun Dhillon (3):
>>   security: Add safe, dynamic (runtime-loadable) hook support
>>   LSM: Add statistics about the invocation of dynamic hooks
>>   LSM: Add an example sample dynamic LSM
>>
>>  include/linux/lsm_hooks.h | 254 +
>>  samples/Kconfig   |   6 +
>>  samples/Makefile  |   2 +-
>>  samples/lsm/Makefile  |   4 +
>>  samples/lsm/lsm_example.c |  46 +++
>>  security/Kconfig  |  16 +++
>>  security/Makefile |   2 +
>>  security/dynamic.c| 316 
>> ++
>>  security/dynamic.h|  33 +
>>  security/dynamicfs.c  | 118 +
>>  security/inode.c  |   2 +
>>  security/security.c   |  66 +-
>>  12 files changed, 863 insertions(+), 2 deletions(-)
>>  create mode 100644 samples/lsm/Makefile
>>  create mode 100644 samples/lsm/lsm_example.c
>>  create mode 100644 security/dynamic.c
>>  create mode 100644 security/dynamic.h
>>  create mode 100644 security/dynamicfs.c
>>
>

[PATCH] efi: move some sysfs files to be read-only by root

[Greg Kroah-Hartman]

Thanks to the scripts/leaking_addresses.pl script, it was found that
some EFI values should not be readable by non-root users.

So make them root-only, and to do that, add a __ATTR_RO_MODE() macro to
make this easier, and use it in other places at the same time.

Reported-by: Linus Torvalds 
Tested-by: Dave Young 
Cc: Matt Fleming 
Cc: Ard Biesheuvel 
Cc: stable 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/firmware/efi/efi.c |3 +--
 drivers/firmware/efi/esrt.c|   15 ++-
 drivers/firmware/efi/runtime-map.c |   10 +-
 include/linux/sysfs.h  |5 +
 4 files changed, 17 insertions(+), 16 deletions(-)

--- a/drivers/firmware/efi/efi.c
+++ b/drivers/firmware/efi/efi.c
@@ -143,8 +143,7 @@ static ssize_t systab_show(struct kobjec
return str - buf;
 }
 
-static struct kobj_attribute efi_attr_systab =
-   __ATTR(systab, 0400, systab_show, NULL);
+static struct kobj_attribute efi_attr_systab = __ATTR_RO_MODE(systab, 0400);
 
 #define EFI_FIELD(var) efi.var
 
--- a/drivers/firmware/efi/esrt.c
+++ b/drivers/firmware/efi/esrt.c
@@ -106,7 +106,7 @@ static const struct sysfs_ops esre_attr_
 };
 
 /* Generic ESRT Entry ("ESRE") support. */
-static ssize_t esre_fw_class_show(struct esre_entry *entry, char *buf)
+static ssize_t fw_class_show(struct esre_entry *entry, char *buf)
 {
char *str = buf;
 
@@ -117,18 +117,16 @@ static ssize_t esre_fw_class_show(struct
return str - buf;
 }
 
-static struct esre_attribute esre_fw_class = __ATTR(fw_class, 0400,
-   esre_fw_class_show, NULL);
+static struct esre_attribute esre_fw_class = __ATTR_RO_MODE(fw_class, 0400);
 
 #define esre_attr_decl(name, size, fmt) \
-static ssize_t esre_##name##_show(struct esre_entry *entry, char *buf) \
+static ssize_t name##_show(struct esre_entry *entry, char *buf) \
 { \
return sprintf(buf, fmt "\n", \
   le##size##_to_cpu(entry->esre.esre1->name)); \
 } \
 \
-static struct esre_attribute esre_##name = __ATTR(name, 0400, \
-   esre_##name##_show, NULL)
+static struct esre_attribute esre_##name = __ATTR_RO_MODE(name, 0400)
 
 esre_attr_decl(fw_type, 32, "%u");
 esre_attr_decl(fw_version, 32, "%u");
@@ -193,14 +191,13 @@ static int esre_create_sysfs_entry(void
 
 /* support for displaying ESRT fields at the top level */
 #define esrt_attr_decl(name, size, fmt) \
-static ssize_t esrt_##name##_show(struct kobject *kobj, \
+static ssize_t name##_show(struct kobject *kobj, \
  struct kobj_attribute *attr, char *buf)\
 { \
return sprintf(buf, fmt "\n", le##size##_to_cpu(esrt->name)); \
 } \
 \
-static struct kobj_attribute esrt_##name = __ATTR(name, 0400, \
-   esrt_##name##_show, NULL)
+static struct kobj_attribute esrt_##name = __ATTR_RO_MODE(name, 0400)
 
 esrt_attr_decl(fw_resource_count, 32, "%u");
 esrt_attr_decl(fw_resource_count_max, 32, "%u");
--- a/drivers/firmware/efi/runtime-map.c
+++ b/drivers/firmware/efi/runtime-map.c
@@ -63,11 +63,11 @@ static ssize_t map_attr_show(struct kobj
return map_attr->show(entry, buf);
 }
 
-static struct map_attribute map_type_attr = __ATTR_RO(type);
-static struct map_attribute map_phys_addr_attr   = __ATTR_RO(phys_addr);
-static struct map_attribute map_virt_addr_attr  = __ATTR_RO(virt_addr);
-static struct map_attribute map_num_pages_attr  = __ATTR_RO(num_pages);
-static struct map_attribute map_attribute_attr  = __ATTR_RO(attribute);
+static struct map_attribute map_type_attr = __ATTR_RO_MODE(type, 0400);
+static struct map_attribute map_phys_addr_attr = __ATTR_RO_MODE(phys_addr, 
0400);
+static struct map_attribute map_virt_addr_attr = __ATTR_RO_MODE(virt_addr, 
0400);
+static struct map_attribute map_num_pages_attr = __ATTR_RO_MODE(num_pages, 
0400);
+static struct map_attribute map_attribute_attr = __ATTR_RO_MODE(attribute, 
0400);
 
 /*
  * These are default attributes that are added for every memmap entry.
--- a/include/linux/sysfs.h
+++ b/include/linux/sysfs.h
@@ -117,6 +117,11 @@ struct attribute_group {
.show   = _name##_show, \
 }
 
+#define __ATTR_RO_MODE(_name, _mode) { \
+   .attr   = { .name = __stringify(_name), .mode = _mode },\
+   .show   = _name##_show, \
+}
+
 #define __ATTR_WO(_name) { \
.attr   = { .name = __stringify(_name), .mode = S_IWUSR },  \
.store  = _name##_store,\

Re: [GIT PULL] hash addresses printed with %p

[Greg Kroah-Hartman]

On Tue, Dec 05, 2017 at 05:24:10PM +0800, Dave Young wrote:
> On 12/05/17 at 04:45pm, Dave Young wrote:
> > On 12/05/17 at 09:09am, Greg Kroah-Hartman wrote:
> > > On Tue, Dec 05, 2017 at 01:14:34PM +0800, Dave Young wrote:
> > > > On 12/04/17 at 03:00pm, Greg Kroah-Hartman wrote:
> > > > > On Mon, Dec 04, 2017 at 12:51:13PM +, David Laight wrote:
> > > > > > From: Ard Biesheuvel
> > > > > > > Sent: 04 December 2017 10:03
> > > > > > ...
> > > > > > > and uses __ATTR_RO() to emit initializers for it. __ATTR() 
> > > > > > > initializes
> > > > > > > the .store member as well, which does not exists, and so it 
> > > > > > > cannot be
> > > > > > > used directly.
> > > > > > > 
> > > > > > > So we should either add a .store member that is always NULL, or we
> > > > > > > should add our own
> > > > > > > 
> > > > > > > #define __ATTR_0400(_name) { \
> > > > > > > .attr = { .name = __stringify(_name), .mode = 0400 }, \
> > > > > > > .show = _name##_show, \
> > > > > > > }
> > > > > > 
> > > > > > What about an __ATTR_RO_MODE(name, mode) that doesn't set the 
> > > > > > .store member.
> > > > > > Even if the mode allowed write, writes wouldn't happen.
> > > > > 
> > > > > Ah, that might work, could you convert the other users of __ATTR() in
> > > > > the efi code to use it as well?
> > > > 
> > > > $ grep __ATTR * -RI
> > > > efi.c:  __ATTR(systab, 0400, systab_show, NULL);
> > > > efi.c:static struct kobj_attribute efi_attr_fw_vendor = 
> > > > __ATTR_RO(fw_vendor);
> > > > efi.c:static struct kobj_attribute efi_attr_runtime = 
> > > > __ATTR_RO(runtime);
> > > > efi.c:static struct kobj_attribute efi_attr_config_table = 
> > > > __ATTR_RO(config_table);
> > > > efi.c:  __ATTR_RO(fw_platform_size);
> > > > esrt.c:static struct esre_attribute esre_fw_class = __ATTR(fw_class, 
> > > > 0400,
> > > > esrt.c:static struct esre_attribute esre_##name = __ATTR(name, 0400, \
> > > > esrt.c:static struct kobj_attribute esrt_##name = __ATTR(name, 0400, \
> > > > runtime-map.c:static struct map_attribute map_type_attr = 
> > > > __ATTR_RO(type);
> > > > runtime-map.c:static struct map_attribute map_phys_addr_attr   = 
> > > > __ATTR_RO(phys_addr);
> > > > runtime-map.c:static struct map_attribute map_virt_addr_attr  = 
> > > > __ATTR_RO(virt_addr);
> > > > runtime-map.c:static struct map_attribute map_num_pages_attr  = 
> > > > __ATTR_RO(num_pages);
> > > > runtime-map.c:static struct map_attribute map_attribute_attr  = 
> > > > __ATTR_RO(attribute);
> > > > 
> > > > Above is all the __ATTR users for drivers/firmware/efi/*, it makes sense
> > > > to update all __ATTR_RO to __ATTR_RO_MODE, so efi.c, runtime-map.c, and
> > > > drivers/firmware/dmi-sysfs.c can be updated.  But esrt.c __ATTR seems
> > > > not necessary.
> > > > 
> > > > And if so __ATTR_RO_MODE(name, mode) still needs go to sysfs.h.
> > > > 
> > > > I can do it but need confirm, Is this what you prefer?
> > > 
> > > Yes, how about the patch below, it builds for me, haven't done anything
> > > other than that to test it :)
> > 
> > Thanks! Let me do a kexec test and a boot test for esrt.
> 
> It works for me. esrt part only did a boot test and cat/ls.

Great, thanks for testing, I've sent it off now as a "real" patch.

greg k-h

Re: net/wireless/shipped-certs.c:2:1: error: expected expression at end of input

[Paul Menzel]

Dear Johannes,


On 12/05/17 11:03, Johannes Berg wrote:

On Tue, 2017-12-05 at 11:01 +0100, Paul Menzel wrote:


```
$ git describe
v4.15-rc2-79-gfd6d2e506ce6
$ git log --oneline -1
fd6d2e506ce6 Merge tag 'docs-4.15-fixes' of git://git.lwn.net/linux
$ time ARCH=i386 make deb-pkg -j50
[…]
net/wireless/shipped-certs.c:2:1: error: expected expression at end of input
   const u8 shipped_regdb_certs[] = {
   ^
[…]
$ more net/wireless/shipped-certs.c
#include "reg.h"
const u8 shipped_regdb_certs[] = {
```


Ah, here we go - you probably don't have "hexdump" installed on this
system?


Well, I didn’t, but got the error, that hexdump couldn’t be found. After 
installing it, I got the error above, and sent the message.


Removing the file `net/wireless/shipped-certs.c`, and building again, 
fixed the problem. So I guess, the clean-up task(?) in the build script 
has a problem.



I thought about doing hexdump in posix shell/awk/sed/whatever
instead... maybe I should do that.


I do not think, it’s necessary, as I got an error, that the executable 
is not there. No idea, if it is documented somewhere though.



Kind regards,

Paul



smime.p7s
Description: S/MIME Cryptographic Signature

[PATCH] ARC: [plat-hsdk] Switch DisplayLink driver from fbdev to DRM

[Alexey Brodkin]

Currently there're 2 different implementations of the driver for
DisplayLink USB2.0-to-HDMI/DVI adapters: older FBDEV and modern true
DRM.

We initially decided to use FBDEV version just because with it
/dev/fbX is usable from user-space while in DRM version
with DRM_FBDEV_EMULATION user-space cannot draw anything on a real
screen, for more info read [1].

But today /dev/fbX is not that important as more and more software
projects switch to use of DRI (/dev/dri/cardX).

But what's even more important DRM driver allows building of complicated
graphics processing chains. The most important for us is rendering of
3D on a dedicated GPU while outputting video through a simpler
bitstreamer like DisplayLink. So let's use much more future-proof
driver from now on.

[1] https://lists.freedesktop.org/archives/dri-devel/2017-December/159519.html

Signed-off-by: Alexey Brodkin 
---
 arch/arc/configs/hsdk_defconfig | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/arch/arc/configs/hsdk_defconfig b/arch/arc/configs/hsdk_defconfig
index 7b8f8faf8a24..ac6b0ed8341e 100644
--- a/arch/arc/configs/hsdk_defconfig
+++ b/arch/arc/configs/hsdk_defconfig
@@ -49,10 +49,11 @@ CONFIG_SERIAL_8250_DW=y
 CONFIG_SERIAL_OF_PLATFORM=y
 # CONFIG_HW_RANDOM is not set
 # CONFIG_HWMON is not set
+CONFIG_DRM=y
+# CONFIG_DRM_FBDEV_EMULATION is not set
+CONFIG_DRM_UDL=y
 CONFIG_FB=y
-CONFIG_FB_UDL=y
 CONFIG_FRAMEBUFFER_CONSOLE=y
-CONFIG_USB=y
 CONFIG_USB_EHCI_HCD=y
 CONFIG_USB_EHCI_HCD_PLATFORM=y
 CONFIG_USB_OHCI_HCD=y
-- 
2.7.5

[PATCH] ARC: Force disable IOC if ioc_enable=0

[Alexey Brodkin]

U-Boot enables and uses IOC so if we don't want to use it in the kernel
we need to _disable_ it for real. This is in comparison to what we do
today based on "ioc_enable" flag - if it is set to 0 we just
_dont_enable_ IOC which effectively keeps IOC alive and kicking.

Signed-off-by: Alexey Brodkin 
---
 arch/arc/mm/cache.c | 47 +++
 1 file changed, 27 insertions(+), 20 deletions(-)

diff --git a/arch/arc/mm/cache.c b/arch/arc/mm/cache.c
index eee924dfffa6..b763c34aa6bc 100644
--- a/arch/arc/mm/cache.c
+++ b/arch/arc/mm/cache.c
@@ -1149,6 +1149,10 @@ noinline void __init arc_ioc_setup(void)
 {
unsigned int ioc_base, mem_sz;
 
+   /* Force disable IOC if it exists but we don't want to use it */
+   if (ioc_exists && !ioc_enable)
+   write_aux_reg(ARC_REG_IO_COH_ENABLE, 0);
+
/* Flush + invalidate + disable L1 dcache */
__dc_disable();
 
@@ -1156,31 +1160,34 @@ noinline void __init arc_ioc_setup(void)
if (read_aux_reg(ARC_REG_SLC_BCR))
slc_entire_op(OP_FLUSH_N_INV);
 
-   /*
-* currently IOC Aperture covers entire DDR
-* TBD: fix for PGU + 1GB of low mem
-* TBD: fix for PAE
-*/
-   mem_sz = arc_get_mem_sz();
+   /* Only setup IOC if we really want to use it */
+   if (ioc_exists && ioc_enable) {
+   /*
+* currently IOC Aperture covers entire DDR
+* TBD: fix for PGU + 1GB of low mem
+* TBD: fix for PAE
+*/
+   mem_sz = arc_get_mem_sz();
 
-   if (!is_power_of_2(mem_sz) || mem_sz < 4096)
-   panic("IOC Aperture size must be power of 2 larger than 4KB");
+   if (!is_power_of_2(mem_sz) || mem_sz < 4096)
+   panic("IOC Aperture size must be power of 2 larger than 
4KB");
 
-   /*
-* IOC Aperture size decoded as 2 ^ (SIZE + 2) KB,
-* so setting 0x11 implies 512MB, 0x12 implies 1GB...
-*/
-   write_aux_reg(ARC_REG_IO_COH_AP0_SIZE, order_base_2(mem_sz >> 10) - 2);
+   /*
+* IOC Aperture size decoded as 2 ^ (SIZE + 2) KB,
+* so setting 0x11 implies 512MB, 0x12 implies 1GB...
+*/
+   write_aux_reg(ARC_REG_IO_COH_AP0_SIZE, order_base_2(mem_sz >> 
10) - 2);
 
-   /* for now assume kernel base is start of IOC aperture */
-   ioc_base = CONFIG_LINUX_RAM_BASE;
+   /* for now assume kernel base is start of IOC aperture */
+   ioc_base = CONFIG_LINUX_RAM_BASE;
 
-   if (ioc_base % mem_sz != 0)
-   panic("IOC Aperture start must be aligned to the size of the 
aperture");
+   if (ioc_base % mem_sz != 0)
+   panic("IOC Aperture start must be aligned to the size 
of the aperture");
 
-   write_aux_reg(ARC_REG_IO_COH_AP0_BASE, ioc_base >> 12);
-   write_aux_reg(ARC_REG_IO_COH_PARTIAL, 1);
-   write_aux_reg(ARC_REG_IO_COH_ENABLE, 1);
+   write_aux_reg(ARC_REG_IO_COH_AP0_BASE, ioc_base >> 12);
+   write_aux_reg(ARC_REG_IO_COH_PARTIAL, 1);
+   write_aux_reg(ARC_REG_IO_COH_ENABLE, 1);
+   }
 
/* Re-enable L1 dcache */
__dc_enable();
-- 
2.7.5

[PATCH 14/17] scsi: arcmsr: fix grammar error

[Ching Huang]

From: Ching Huang 

fix grammar error.

Signed-off-by: Ching Huang 
---

diff -uprN a/drivers/scsi/arcmsr/arcmsr_hba.c b/drivers/scsi/arcmsr/arcmsr_hba.c
--- a/drivers/scsi/arcmsr/arcmsr_hba.c  2017-12-05 11:44:52.0 +0800
+++ b/drivers/scsi/arcmsr/arcmsr_hba.c  2017-12-05 11:44:36.0 +0800
@@ -4453,7 +4453,7 @@ static int arcmsr_bus_reset(struct scsi_
 
if (acb->acb_flags & ACB_F_BUS_RESET) {
long timeout;
-   pr_notice("arcmsr: there is an bus reset eh proceeding...\n");
+   pr_notice("arcmsr: there is a bus reset eh proceeding...\n");
timeout = wait_event_timeout(wait_q, (acb->acb_flags
& ACB_F_BUS_RESET) == 0, 220 * HZ);
if (timeout)

[RFC PATCH] net: stmmac: enable EEE in MII, GMII or RGMII only

[Jerome Brunet]

Note in the databook - Section 4.4 - EEE :
" The EEE feature is not supported when the MAC is configured to use the
TBI, RTBI, SMII, RMII or SGMII single PHY interface. Even if the MAC
supports multiple PHY interfaces, you should activate the EEE mode only
when the MAC is operating with GMII, MII, or RGMII interface."

Applying this restriction solves a stability issue observed on Amlogic
gxl platforms operating with RMII interface and the internal PHY.

Fixes: 83bf79b6bb64 ("stmmac: disable at run-time the EEE if not supported")
Signed-off-by: Jerome Brunet 
---

Hi Peppe, Alexandre,

As quickly explained in the log above, we are having some stability issue on
Amlogic gxl platform: synopsys MAC + internal PHY over RMII. We found out that
these issues are caused by EEE. Forcefully disabling this feature solves our
problem. We are now looking for the more appropriate way to address the
problem.

I only had access to a snip of databook. I have no idea if the restriction
explained above applies to all the revision of Synopsys MAC controller ?
Or maybe the restriction is more generic and we should check for the
interface type in phy_init_eee() instead ?

Could you please share your opinion on this matter ?

Thanks
Jerome

 drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 9 +
 1 file changed, 9 insertions(+)

diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c 
b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index f63c2ddced3c..8e8add8c6ed3 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -364,9 +364,18 @@ static void stmmac_eee_ctrl_timer(struct timer_list *t)
 bool stmmac_eee_init(struct stmmac_priv *priv)
 {
struct net_device *ndev = priv->dev;
+   int interface = priv->plat->interface;
unsigned long flags;
bool ret = false;
 
+   if ((interface != PHY_INTERFACE_MODE_MII) &&
+   (interface != PHY_INTERFACE_MODE_GMII) &&
+   (interface != PHY_INTERFACE_MODE_RGMII) &&
+   (interface != PHY_INTERFACE_MODE_RGMII_ID) &&
+   (interface != PHY_INTERFACE_MODE_RGMII_TXID) &&
+   (interface != PHY_INTERFACE_MODE_RGMII_RXID))
+   goto out;
+
/* Using PCS we cannot dial with the phy registers at this stage
 * so we do not support extra feature like EEE.
 */
-- 
2.14.3

Re: [RFC PATCH 1/6] drm: Add Content Protection property

[Pavel Machek]

On Wed 2017-11-29 22:08:56, Sean Paul wrote:
> This patch adds a new optional connector property to allow userspace to enable
> protection over the content it is displaying. This will typically be 
> implemented
> by the driver using HDCP.
> 
> The property is a tri-state with the following values:
> - OFF: Self explanatory, no content protection
> - DESIRED: Userspace requests that the driver enable protection
> - ENABLED: Once the driver has authenticated the link, it sets this value
> 
> The driver is responsible for downgrading ENABLED to DESIRED if the link 
> becomes
> unprotected. The driver should also maintain the desiredness of protection
> across hotplug/dpms/suspend.

Why would user of the machine want this to be something else than
'OFF'?

If kernel implements this, will it mean hardware vendors will have to
prevent user from updating kernel on machines they own?

If this is merged, does it open kernel developers to DMCA threats if
they try to change it?

Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature

Re: 4.15.0-rc1-next-20171201: WARNING: .... at net/mac80211/agg-tx.c:315

[Kalle Valo]

Pavel Machek  writes:

> This is quite annoying: repeated
>
> [ 4169.591529] ---[ end trace e65d97cf1d20b84d ]---
> [ 4169.591565] WARNING: CPU: 0 PID: 5472 at net/mac80211/agg-tx.c:315
> ___ieee80211_stop_tx_\
> ba_session+0x158/0x1f0
>
> Hardware is thinkpad x60. Git blame says cfcdbde35 introduced the
> test.

To save time for others, the driver is iwl3945:

> [0.970687] iwl3945: Intel(R) PRO/Wireless 3945ABG/BG Network Connection 
> driver for Linux, in-tree:ds
> [0.970690] iwl3945: Copyright(c) 2003-2011 Intel Corporation
> [0.970692] iwl3945: hw_scan is disabled
> [0.971082] iwl3945 :03:00.0: can't disable ASPM; OS doesn't have ASPM 
> control
> [1.026281] iwl3945 :03:00.0: Tunable channels: 11 802.11bg, 13 
> 802.11a channels
> [1.026287] iwl3945 :03:00.0: Detected Intel Wireless WiFi Link 3945ABG
> [1.027866] ieee80211 phy0: Selected rate control algorithm 'iwl-3945-rs'

-- 
Kalle Valo

Re: [PATCH] efi: move some sysfs files to be read-only by root

[Greg Kroah-Hartman]

On Tue, Dec 05, 2017 at 10:16:56AM +, Ard Biesheuvel wrote:
> On 5 December 2017 at 10:13, Greg Kroah-Hartman
>  wrote:
> > Thanks to the scripts/leaking_addresses.pl script, it was found that
> > some EFI values should not be readable by non-root users.
> >
> > So make them root-only, and to do that, add a __ATTR_RO_MODE() macro to
> > make this easier, and use it in other places at the same time.
> >
> > Reported-by: Linus Torvalds 
> > Tested-by: Dave Young 
> > Cc: Matt Fleming 
> > Cc: Ard Biesheuvel 
> > Cc: stable 
> > Signed-off-by: Greg Kroah-Hartman 
> >
> > ---
> >  drivers/firmware/efi/efi.c |3 +--
> >  drivers/firmware/efi/esrt.c|   15 ++-
> >  drivers/firmware/efi/runtime-map.c |   10 +-
> >  include/linux/sysfs.h  |5 +
> >  4 files changed, 17 insertions(+), 16 deletions(-)
> >
> > --- a/drivers/firmware/efi/efi.c
> > +++ b/drivers/firmware/efi/efi.c
> > @@ -143,8 +143,7 @@ static ssize_t systab_show(struct kobjec
> > return str - buf;
> >  }
> >
> > -static struct kobj_attribute efi_attr_systab =
> > -   __ATTR(systab, 0400, systab_show, NULL);
> > +static struct kobj_attribute efi_attr_systab = __ATTR_RO_MODE(systab, 
> > 0400);
> >
> >  #define EFI_FIELD(var) efi.var
> >
> > --- a/drivers/firmware/efi/esrt.c
> > +++ b/drivers/firmware/efi/esrt.c
> > @@ -106,7 +106,7 @@ static const struct sysfs_ops esre_attr_
> >  };
> >
> >  /* Generic ESRT Entry ("ESRE") support. */
> > -static ssize_t esre_fw_class_show(struct esre_entry *entry, char *buf)
> > +static ssize_t fw_class_show(struct esre_entry *entry, char *buf)
> >  {
> > char *str = buf;
> >
> > @@ -117,18 +117,16 @@ static ssize_t esre_fw_class_show(struct
> > return str - buf;
> >  }
> >
> > -static struct esre_attribute esre_fw_class = __ATTR(fw_class, 0400,
> > -   esre_fw_class_show, NULL);
> > +static struct esre_attribute esre_fw_class = __ATTR_RO_MODE(fw_class, 
> > 0400);
> >
> >  #define esre_attr_decl(name, size, fmt) \
> > -static ssize_t esre_##name##_show(struct esre_entry *entry, char *buf) \
> > +static ssize_t name##_show(struct esre_entry *entry, char *buf) \
> >  { \
> > return sprintf(buf, fmt "\n", \
> >le##size##_to_cpu(entry->esre.esre1->name)); \
> >  } \
> >  \
> > -static struct esre_attribute esre_##name = __ATTR(name, 0400, \
> > -   esre_##name##_show, NULL)
> > +static struct esre_attribute esre_##name = __ATTR_RO_MODE(name, 0400)
> >
> >  esre_attr_decl(fw_type, 32, "%u");
> >  esre_attr_decl(fw_version, 32, "%u");
> > @@ -193,14 +191,13 @@ static int esre_create_sysfs_entry(void
> >
> >  /* support for displaying ESRT fields at the top level */
> >  #define esrt_attr_decl(name, size, fmt) \
> > -static ssize_t esrt_##name##_show(struct kobject *kobj, \
> > +static ssize_t name##_show(struct kobject *kobj, \
> >   struct kobj_attribute *attr, char *buf)\
> >  { \
> > return sprintf(buf, fmt "\n", le##size##_to_cpu(esrt->name)); \
> >  } \
> >  \
> > -static struct kobj_attribute esrt_##name = __ATTR(name, 0400, \
> > -   esrt_##name##_show, NULL)
> > +static struct kobj_attribute esrt_##name = __ATTR_RO_MODE(name, 0400)
> >
> >  esrt_attr_decl(fw_resource_count, 32, "%u");
> >  esrt_attr_decl(fw_resource_count_max, 32, "%u");
> > --- a/drivers/firmware/efi/runtime-map.c
> > +++ b/drivers/firmware/efi/runtime-map.c
> > @@ -63,11 +63,11 @@ static ssize_t map_attr_show(struct kobj
> > return map_attr->show(entry, buf);
> >  }
> >
> > -static struct map_attribute map_type_attr = __ATTR_RO(type);
> > -static struct map_attribute map_phys_addr_attr   = __ATTR_RO(phys_addr);
> > -static struct map_attribute map_virt_addr_attr  = __ATTR_RO(virt_addr);
> > -static struct map_attribute map_num_pages_attr  = __ATTR_RO(num_pages);
> > -static struct map_attribute map_attribute_attr  = __ATTR_RO(attribute);
> > +static struct map_attribute map_type_attr = __ATTR_RO_MODE(type, 0400);
> > +static struct map_attribute map_phys_addr_attr = __ATTR_RO_MODE(phys_addr, 
> > 0400);
> > +static struct map_attribute map_virt_addr_attr = __ATTR_RO_MODE(virt_addr, 
> > 0400);
> > +static struct map_attribute map_num_pages_attr = __ATTR_RO_MODE(num_pages, 
> > 0400);
> > +static struct map_attribute map_attribute_attr = __ATTR_RO_MODE(attribute, 
> > 0400);
> >
> >  /*
> >   * These are default attributes that are added for every memmap entry.
> > --- a/include/linux/sysfs.h
> > +++ b/include/linux/sysfs.h
> > @@ -117,6 +117,11 @@ struct attribute_group {
> > .show   = _name##_show, \
> >  }
> >
> > +#define __ATTR_RO_MODE(_name, _mode) { \
> > +   .attr   = { .name = 

[PATCH v2] efi: move some sysfs files to be read-only by root

[Greg Kroah-Hartman]

Thanks to the scripts/leaking_addresses.pl script, it was found that
some EFI values should not be readable by non-root users.

So make them root-only, and to do that, add a __ATTR_RO_MODE() macro to
make this easier, and use it in other places at the same time.

Reported-by: Linus Torvalds 
Tested-by: Dave Young 
Cc: Matt Fleming 
Cc: Ard Biesheuvel 
Cc: stable 
Signed-off-by: Greg Kroah-Hartman 

---
v2: add VERIFY_OCTAL_PERMISSIONS to __ATTR_RO_MODE() as pointed out by
Ard.

 drivers/firmware/efi/efi.c |3 +--
 drivers/firmware/efi/esrt.c|   15 ++-
 drivers/firmware/efi/runtime-map.c |   10 +-
 include/linux/sysfs.h  |6 ++
 4 files changed, 18 insertions(+), 16 deletions(-)

--- a/drivers/firmware/efi/efi.c
+++ b/drivers/firmware/efi/efi.c
@@ -143,8 +143,7 @@ static ssize_t systab_show(struct kobjec
return str - buf;
 }
 
-static struct kobj_attribute efi_attr_systab =
-   __ATTR(systab, 0400, systab_show, NULL);
+static struct kobj_attribute efi_attr_systab = __ATTR_RO_MODE(systab, 0400);
 
 #define EFI_FIELD(var) efi.var
 
--- a/drivers/firmware/efi/esrt.c
+++ b/drivers/firmware/efi/esrt.c
@@ -106,7 +106,7 @@ static const struct sysfs_ops esre_attr_
 };
 
 /* Generic ESRT Entry ("ESRE") support. */
-static ssize_t esre_fw_class_show(struct esre_entry *entry, char *buf)
+static ssize_t fw_class_show(struct esre_entry *entry, char *buf)
 {
char *str = buf;
 
@@ -117,18 +117,16 @@ static ssize_t esre_fw_class_show(struct
return str - buf;
 }
 
-static struct esre_attribute esre_fw_class = __ATTR(fw_class, 0400,
-   esre_fw_class_show, NULL);
+static struct esre_attribute esre_fw_class = __ATTR_RO_MODE(fw_class, 0400);
 
 #define esre_attr_decl(name, size, fmt) \
-static ssize_t esre_##name##_show(struct esre_entry *entry, char *buf) \
+static ssize_t name##_show(struct esre_entry *entry, char *buf) \
 { \
return sprintf(buf, fmt "\n", \
   le##size##_to_cpu(entry->esre.esre1->name)); \
 } \
 \
-static struct esre_attribute esre_##name = __ATTR(name, 0400, \
-   esre_##name##_show, NULL)
+static struct esre_attribute esre_##name = __ATTR_RO_MODE(name, 0400)
 
 esre_attr_decl(fw_type, 32, "%u");
 esre_attr_decl(fw_version, 32, "%u");
@@ -193,14 +191,13 @@ static int esre_create_sysfs_entry(void
 
 /* support for displaying ESRT fields at the top level */
 #define esrt_attr_decl(name, size, fmt) \
-static ssize_t esrt_##name##_show(struct kobject *kobj, \
+static ssize_t name##_show(struct kobject *kobj, \
  struct kobj_attribute *attr, char *buf)\
 { \
return sprintf(buf, fmt "\n", le##size##_to_cpu(esrt->name)); \
 } \
 \
-static struct kobj_attribute esrt_##name = __ATTR(name, 0400, \
-   esrt_##name##_show, NULL)
+static struct kobj_attribute esrt_##name = __ATTR_RO_MODE(name, 0400)
 
 esrt_attr_decl(fw_resource_count, 32, "%u");
 esrt_attr_decl(fw_resource_count_max, 32, "%u");
--- a/drivers/firmware/efi/runtime-map.c
+++ b/drivers/firmware/efi/runtime-map.c
@@ -63,11 +63,11 @@ static ssize_t map_attr_show(struct kobj
return map_attr->show(entry, buf);
 }
 
-static struct map_attribute map_type_attr = __ATTR_RO(type);
-static struct map_attribute map_phys_addr_attr   = __ATTR_RO(phys_addr);
-static struct map_attribute map_virt_addr_attr  = __ATTR_RO(virt_addr);
-static struct map_attribute map_num_pages_attr  = __ATTR_RO(num_pages);
-static struct map_attribute map_attribute_attr  = __ATTR_RO(attribute);
+static struct map_attribute map_type_attr = __ATTR_RO_MODE(type, 0400);
+static struct map_attribute map_phys_addr_attr = __ATTR_RO_MODE(phys_addr, 
0400);
+static struct map_attribute map_virt_addr_attr = __ATTR_RO_MODE(virt_addr, 
0400);
+static struct map_attribute map_num_pages_attr = __ATTR_RO_MODE(num_pages, 
0400);
+static struct map_attribute map_attribute_attr = __ATTR_RO_MODE(attribute, 
0400);
 
 /*
  * These are default attributes that are added for every memmap entry.
--- a/include/linux/sysfs.h
+++ b/include/linux/sysfs.h
@@ -117,6 +117,12 @@ struct attribute_group {
.show   = _name##_show, \
 }
 
+#define __ATTR_RO_MODE(_name, _mode) { \
+   .attr   = { .name = __stringify(_name), \
+   .mode = VERIFY_OCTAL_PERMISSIONS(_mode) },  \
+   .show   = _name##_show, \
+}
+
 #define __ATTR_WO(_name) { \
.attr   = { .name = __stringify(_name), .mode = S_IWUSR },  \
.store  = _name##_store,\

Re: [PATCH] ASoC: atmel-classd: select correct Kconfig symbol

[Arnd Bergmann]

On Tue, Dec 5, 2017 at 11:57 AM, Alexandre Belloni
 wrote:
> On 05/12/2017 at 11:09:38 +0100, Arnd Bergmann wrote:
>> Commit 061981ff8cc8 ("ASoC: atmel: properly select dma driver state")
>> changed the way that the dependencies are handled, but then the
>> Class D amplifier support got merged, which used the old method.
>>
>> This seems to have triggered a very rare randconfig condition for me
>> now, leading to a link error:
>>
>> sound/soc/atmel/atmel_ssc_dai.o: In function `atmel_ssc_set_audio':
>> atmel_ssc_dai.c:(.text+0x79c): undefined reference to 
>> `atmel_pcm_dma_platform_register'
>> atmel_ssc_dai.c:(.text+0x79c): relocation truncated to fit: R_AARCH64_CALL26 
>> against undefined symbol `atmel_pcm_dma_platform_register'
>> sound/soc/atmel/atmel_ssc_dai.o: In function `atmel_ssc_put_audio':
>> atmel_ssc_dai.c:(.text+0xf24): undefined reference to 
>> `atmel_pcm_dma_platform_unregister'
>> atmel_ssc_dai.c:(.text+0xf24): relocation truncated to fit: R_AARCH64_CALL26 
>> against undefined symbol `atmel_pcm_dma_platform_unregister'
>>
>> Changing it to select SND_ATMEL_SOC_SSC_DMA as intended rather than
>> SND_ATMEL_SOC_DMA directly makes it work again.
>>
>> Fixes: e0a25b6d1862 ("ASoC: atmel-classd: add the Audio Class D Amplifier")
>> Signed-off-by: Arnd Bergmann 
> Acked-by: Alexandre Belloni 

Unfortunately, my testing just found a new problem with this patch
applied, I had
not run enough randconfig tests on top of it:

sound/soc/atmel/atmel_ssc_dai.o: In function `atmel_ssc_set_audio':
atmel_ssc_dai.c:(.text+0x73c): undefined reference to `ssc_request'
sound/soc/atmel/atmel_ssc_dai.o: In function `atmel_ssc_put_audio':
atmel_ssc_dai.c:(.text+0x7be): undefined reference to `ssc_free'

This is for a configuration with SND_ATMEL_SOC_CLASSD=y
and CONFIG_ATMEL_SSC=n. Could you tell me whether that is a
sensible configuration that should work, or whether we need a dependency
on ATMEL_SSC in SND_ATMEL_SOC_CLASSD? I can't really tell
from the source code, but you probably know the answer.

   Arnd

[PATCH/RFC v2] leds: trigger: Introduce a NETDEV trigger

[Ben Whitten]

From: Ben Whitten 

This commit introduces a NETDEV trigger for named device
activity. Available triggers are link, rx, and tx.

Signed-off-by: Ben Whitten 

---
Changes in v2:
Sort includes and redate documentation
Correct licence
Remove macro and replace with generic function using enums
Convert blink logic in stats work to use led_blink_oneshot
Uses configured brightness instead of FULL
---
 .../ABI/testing/sysfs-class-led-trigger-netdev |  45 ++
 drivers/leds/trigger/Kconfig   |   7 +
 drivers/leds/trigger/Makefile  |   1 +
 drivers/leds/trigger/ledtrig-netdev.c  | 507 +
 4 files changed, 560 insertions(+)
 create mode 100644 Documentation/ABI/testing/sysfs-class-led-trigger-netdev
 create mode 100644 drivers/leds/trigger/ledtrig-netdev.c

diff --git a/Documentation/ABI/testing/sysfs-class-led-trigger-netdev 
b/Documentation/ABI/testing/sysfs-class-led-trigger-netdev
new file mode 100644
index 000..451af6d
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-class-led-trigger-netdev
@@ -0,0 +1,45 @@
+What:  /sys/class/leds//device_name
+Date:  Dec 2017
+KernelVersion: 4.16
+Contact:   linux-l...@vger.kernel.org
+Description:
+   Specifies the network device name to monitor.
+
+What:  /sys/class/leds//interval
+Date:  Dec 2017
+KernelVersion: 4.16
+Contact:   linux-l...@vger.kernel.org
+Description:
+   Specifies the duration of the LED blink in milliseconds.
+   Defaults to 50 ms.
+
+What:  /sys/class/leds//link
+Date:  Dec 2017
+KernelVersion: 4.16
+Contact:   linux-l...@vger.kernel.org
+Description:
+   Signal the link state of the named network device.
+   If set to 0 (default), the LED's normal state is off.
+   If set to 1, the LED's normal state reflects the link state
+   of the named network device.
+   Setting this value also immediately changes the LED state.
+
+What:  /sys/class/leds//tx
+Date:  Dec 2017
+KernelVersion: 4.16
+Contact:   linux-l...@vger.kernel.org
+Description:
+   Signal transmission of data on the named network device.
+   If set to 0 (default), the LED will not blink on transmission.
+   If set to 1, the LED will blink for the milliseconds specified
+   in interval to signal transmission.
+
+What:  /sys/class/leds//rx
+Date:  Dec 2017
+KernelVersion: 4.16
+Contact:   linux-l...@vger.kernel.org
+Description:
+   Signal reception of data on the named network device.
+   If set to 0 (default), the LED will not blink on reception.
+   If set to 1, the LED will blink for the milliseconds specified
+   in interval to signal reception.
diff --git a/drivers/leds/trigger/Kconfig b/drivers/leds/trigger/Kconfig
index 3f9ddb9..4ec1853 100644
--- a/drivers/leds/trigger/Kconfig
+++ b/drivers/leds/trigger/Kconfig
@@ -126,4 +126,11 @@ config LEDS_TRIGGER_PANIC
  a different trigger.
  If unsure, say Y.
 
+config LEDS_TRIGGER_NETDEV
+   tristate "LED Netdev Trigger"
+   depends on NET && LEDS_TRIGGERS
+   help
+ This allows LEDs to be controlled by network device activity.
+ If unsure, say Y.
+
 endif # LEDS_TRIGGERS
diff --git a/drivers/leds/trigger/Makefile b/drivers/leds/trigger/Makefile
index 9f2e868..59e163d 100644
--- a/drivers/leds/trigger/Makefile
+++ b/drivers/leds/trigger/Makefile
@@ -11,3 +11,4 @@ obj-$(CONFIG_LEDS_TRIGGER_DEFAULT_ON) += ledtrig-default-on.o
 obj-$(CONFIG_LEDS_TRIGGER_TRANSIENT)   += ledtrig-transient.o
 obj-$(CONFIG_LEDS_TRIGGER_CAMERA)  += ledtrig-camera.o
 obj-$(CONFIG_LEDS_TRIGGER_PANIC)   += ledtrig-panic.o
+obj-$(CONFIG_LEDS_TRIGGER_NETDEV)  += ledtrig-netdev.o
diff --git a/drivers/leds/trigger/ledtrig-netdev.c 
b/drivers/leds/trigger/ledtrig-netdev.c
new file mode 100644
index 000..3b6075d
--- /dev/null
+++ b/drivers/leds/trigger/ledtrig-netdev.c
@@ -0,0 +1,507 @@
+/*
+ * LED Kernel Netdev Trigger
+ *
+ * Toggles the LED to reflect the link and traffic state of a named net device
+ *
+ * Copyright 2017 Ben Whitten 
+ *
+ * Copyright 2007 Oliver Jowett 
+ *
+ * Derived from ledtrig-timer.c which is:
+ *  Copyright 2005-2006 Openedhand Ltd.
+ *  Author: Richard Purdie 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/*
+ * Configurable sysfs attributes:
+ *
+ * device_name - network device name to monitor
+ * interval - duration of