Re: [PATCH 5/5] arm64: dts: spi bus dts support multiple devices

[Sascha Hauer]

On Wed, Oct 14, 2015 at 11:23:35AM +0800, Leilk Liu wrote:
> This patch support multiple devices for MT8173.

The subject of this patch and also the above sentence should contain the
board name this patch is changing so that the reader knows this is about
a single board, and not arm64 in general.

Sascha

> 
> Signed-off-by: Leilk Liu 
> ---
>  arch/arm64/boot/dts/mediatek/mt8173-evb.dts | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/arm64/boot/dts/mediatek/mt8173-evb.dts 
> b/arch/arm64/boot/dts/mediatek/mt8173-evb.dts
> index 04b38ed..1c8c407 100644
> --- a/arch/arm64/boot/dts/mediatek/mt8173-evb.dts
> +++ b/arch/arm64/boot/dts/mediatek/mt8173-evb.dts
> @@ -194,7 +194,7 @@
>   pinmux = ,
>   ,
>   ,
> - ;
> + ;
>   };
>   };
>  };
> @@ -399,6 +399,7 @@
>   {
>   pinctrl-names = "default";
>   pinctrl-0 = <_pins_a>;
> + cs-gpios = < 72 0>;
>   mediatek,pad-select = <0>;
>   status = "okay";
>  };
> -- 
> 1.8.1.1.dirty
> 
> 

-- 
Pengutronix e.K.   | |
Industrial Linux Solutions | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [BUG] broken mixer after second resume from mem

[Krzysztof Kozlowski]

On 13.10.2015 19:25, Tomeu Vizoso wrote:
> Hi,
> 
> have been hunting down a bug on exynos5250-snow which caused both HDMI
> and LVDS output to be broken after the second resume (with suspend to
> mem, but not to idle).
> 
> What I have found is that when powering down the DISP1 power domain
> while suspending for the second time, the contents of the SRC_TOP3
> register change from 0x1110550 to 0x1110500. IIUIC, this means that
> ACLK_200_DISP1 is reparented to XXTI.
> 
> When the CPU comes up again, that register contains 0x1110550 again, but
> it's set to 0x1110500 by the code that restores clk registers when resuming:
> 
> First suspend:
> 
> exynos_pd_power: SRC_TOP3 1110550 disp1-power-domain@100440A0 - before
> exynos_pd_power: SRC_TOP3 1110550 disp1-power-domain@100440A0 - after
> exynos5250_clk_suspend: SRC_TOP3 1110550
> exynos5250_clk_resume: SRC_TOP3 1110550 - before
> exynos5250_clk_resume: SRC_TOP3 1110550 - after
> exynos_pd_power: SRC_TOP3 1110550 disp1-power-domain@100440A0 - before
> exynos_pd_power: SRC_TOP3 1110550 disp1-power-domain@100440A0 - after
> 
> 
> Second suspend:
> 
> exynos_pd_power: SRC_TOP3 1110550 disp1-power-domain@100440A0 - before
> exynos_pd_power: SRC_TOP3 1110500 disp1-power-domain@100440A0 - after
> exynos5250_clk_suspend: SRC_TOP3 1110500
> exynos5250_clk_resume: SRC_TOP3 1110550 - before
> exynos5250_clk_resume: SRC_TOP3 1110500 - after
> exynos_pd_power: SRC_TOP3 1110500 disp1-power-domain@100440A0 - before
> exynos_pd_power: SRC_TOP3 1110500 disp1-power-domain@100440A0 - after
> 

I am assuming you are talking about current linux-next. The actual
reparent happens in exynos_pd_power which would indicate the exynos pd
clock reparenting code. However the domains for Exynos5250 don't have
any clocks set up for reparenting... which actually might be the issue.
These clocks should be probably reparented - as it is done for other
platforms - look at 5420 example (they are glitch-free on both of SoCs).

I've seen a such issues before. The problem is that after some time I
tend to forget the needed workaround and solution. :)

Try with reparenting necessary clocks. On other platform for some kind
of similar issue the reset was required for the IP block - DECON
(actually the mux could not stabilize there which can be observed in one
of STATUS registers for mux).

Let me know if explanation above is not detailed enough.

> I have no idea of why it happens on the second suspend, and also don't
> know why it doesn't happen when suspending to idle.

As for the idle - domains are probably not gated so the problems just
does not exist.

BTW as this is display, you can CC some Samsung guys from DRM... they
know a lot on these stuff. :)

Best regards,
Krzysztof

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] ACPICA: Tables: Fix FADT dependency regression

[Lv Zheng]

Some logics actually relying on the existence of FADT, currently relies on
the number of loaded tables. This false dependency can easily trigger
regressions. The reported regression can be seen on the following commit:
  Commit: 8ec3f459073e67e5c6d78507dec693064b3040a2
  Subject: ACPICA: Tables: Fix global table list issues by removing fixed table
The commit changing the fixed table indexes results in the change of FADT
table index, originally, it was 3 (thus the installed table count should be
greater than 4), while currently it is 0 (and the installed table count may
be 3).

This patch fixes this regression by cleaning up the code. Lv Zheng.

Reference: https://bugzilla.kernel.org/show_bug.cgi?id=105351
Reported-and-tested-by: Meelis Roos 
Signed-off-by: Lv Zheng 
---
 drivers/acpi/acpica/acglobal.h |1 +
 drivers/acpi/acpica/actables.h |4 +---
 drivers/acpi/acpica/evxfevnt.c |2 +-
 drivers/acpi/acpica/tbfadt.c   |   10 +-
 drivers/acpi/acpica/tbutils.c  |   26 ++
 5 files changed, 10 insertions(+), 33 deletions(-)

diff --git a/drivers/acpi/acpica/acglobal.h b/drivers/acpi/acpica/acglobal.h
index 09f37b5..4dde37c 100644
--- a/drivers/acpi/acpica/acglobal.h
+++ b/drivers/acpi/acpica/acglobal.h
@@ -61,6 +61,7 @@ ACPI_GLOBAL(struct acpi_table_header, 
acpi_gbl_original_dsdt_header);
 ACPI_INIT_GLOBAL(u32, acpi_gbl_dsdt_index, ACPI_INVALID_TABLE_INDEX);
 ACPI_INIT_GLOBAL(u32, acpi_gbl_facs_index, ACPI_INVALID_TABLE_INDEX);
 ACPI_INIT_GLOBAL(u32, acpi_gbl_xfacs_index, ACPI_INVALID_TABLE_INDEX);
+ACPI_INIT_GLOBAL(u32, acpi_gbl_fadt_index, ACPI_INVALID_TABLE_INDEX);
 
 #if (!ACPI_REDUCED_HARDWARE)
 ACPI_GLOBAL(struct acpi_table_facs *, acpi_gbl_FACS);
diff --git a/drivers/acpi/acpica/actables.h b/drivers/acpi/acpica/actables.h
index f7731f2..591ea95 100644
--- a/drivers/acpi/acpica/actables.h
+++ b/drivers/acpi/acpica/actables.h
@@ -85,7 +85,7 @@ void acpi_tb_set_table_loaded_flag(u32 table_index, u8 
is_loaded);
 /*
  * tbfadt - FADT parse/convert/validate
  */
-void acpi_tb_parse_fadt(u32 table_index);
+void acpi_tb_parse_fadt(void);
 
 void acpi_tb_create_local_fadt(struct acpi_table_header *table, u32 length);
 
@@ -138,8 +138,6 @@ acpi_status acpi_tb_get_owner_id(u32 table_index, 
acpi_owner_id *owner_id);
  */
 acpi_status acpi_tb_initialize_facs(void);
 
-u8 acpi_tb_tables_loaded(void);
-
 void
 acpi_tb_print_table_header(acpi_physical_address address,
   struct acpi_table_header *header);
diff --git a/drivers/acpi/acpica/evxfevnt.c b/drivers/acpi/acpica/evxfevnt.c
index faad911..10ce48e 100644
--- a/drivers/acpi/acpica/evxfevnt.c
+++ b/drivers/acpi/acpica/evxfevnt.c
@@ -71,7 +71,7 @@ acpi_status acpi_enable(void)
 
/* ACPI tables must be present */
 
-   if (!acpi_tb_tables_loaded()) {
+   if (acpi_gbl_fadt_index == ACPI_INVALID_TABLE_INDEX) {
return_ACPI_STATUS(AE_NO_ACPI_TABLES);
}
 
diff --git a/drivers/acpi/acpica/tbfadt.c b/drivers/acpi/acpica/tbfadt.c
index 455a070..a6454f4 100644
--- a/drivers/acpi/acpica/tbfadt.c
+++ b/drivers/acpi/acpica/tbfadt.c
@@ -298,7 +298,7 @@ acpi_tb_select_address(char *register_name, u32 address32, 
u64 address64)
  *
  * FUNCTION:acpi_tb_parse_fadt
  *
- * PARAMETERS:  table_index - Index for the FADT
+ * PARAMETERS:  None
  *
  * RETURN:  None
  *
@@ -307,7 +307,7 @@ acpi_tb_select_address(char *register_name, u32 address32, 
u64 address64)
  *
  
**/
 
-void acpi_tb_parse_fadt(u32 table_index)
+void acpi_tb_parse_fadt(void)
 {
u32 length;
struct acpi_table_header *table;
@@ -319,11 +319,11 @@ void acpi_tb_parse_fadt(u32 table_index)
 * Get a local copy of the FADT and convert it to a common format
 * Map entire FADT, assumed to be smaller than one page.
 */
-   length = acpi_gbl_root_table_list.tables[table_index].length;
+   length = acpi_gbl_root_table_list.tables[acpi_gbl_fadt_index].length;
 
table =
-   acpi_os_map_memory(acpi_gbl_root_table_list.tables[table_index].
-  address, length);
+   acpi_os_map_memory(acpi_gbl_root_table_list.
+  tables[acpi_gbl_fadt_index].address, length);
if (!table) {
return;
}
diff --git a/drivers/acpi/acpica/tbutils.c b/drivers/acpi/acpica/tbutils.c
index 4337990..d8ddef3 100644
--- a/drivers/acpi/acpica/tbutils.c
+++ b/drivers/acpi/acpica/tbutils.c
@@ -99,29 +99,6 @@ acpi_status acpi_tb_initialize_facs(void)
 
 
/***
  *
- * FUNCTION:acpi_tb_tables_loaded
- *
- * PARAMETERS:  None
- *
- * RETURN:  TRUE if required ACPI tables are loaded
- *
- * DESCRIPTION: Determine if the minimum required ACPI tables are present
- *  (FADT, FACS, DSDT)
- *
- 

[PATCH] Input: pixcir_i2c_ts: remove wakeirq related code from pixcir driver

[Vignesh R]

With commit 3fffd1283927 ("i2c: allow specifying separate wakeup
interrupt in device tree") wakeirq is managed by i2c-core, so remove
wakeirq related code from pixcir_i2c_ts driver.

Signed-off-by: Vignesh R 
---
 drivers/input/touchscreen/pixcir_i2c_ts.c | 12 
 1 file changed, 12 deletions(-)

diff --git a/drivers/input/touchscreen/pixcir_i2c_ts.c 
b/drivers/input/touchscreen/pixcir_i2c_ts.c
index 91621725bfb5..4b961ad9f0b5 100644
--- a/drivers/input/touchscreen/pixcir_i2c_ts.c
+++ b/drivers/input/touchscreen/pixcir_i2c_ts.c
@@ -377,8 +377,6 @@ static int __maybe_unused pixcir_i2c_ts_suspend(struct 
device *dev)
goto unlock;
}
}
-
-   enable_irq_wake(client->irq);
} else if (input->users) {
ret = pixcir_stop(ts);
}
@@ -399,7 +397,6 @@ static int __maybe_unused pixcir_i2c_ts_resume(struct 
device *dev)
mutex_lock(>mutex);
 
if (device_may_wakeup(>dev)) {
-   disable_irq_wake(client->irq);
 
if (!input->users) {
ret = pixcir_stop(ts);
@@ -564,14 +561,6 @@ static int pixcir_i2c_ts_probe(struct i2c_client *client,
return error;
 
i2c_set_clientdata(client, tsdata);
-   device_init_wakeup(>dev, 1);
-
-   return 0;
-}
-
-static int pixcir_i2c_ts_remove(struct i2c_client *client)
-{
-   device_init_wakeup(>dev, 0);
 
return 0;
 }
@@ -609,7 +598,6 @@ static struct i2c_driver pixcir_i2c_ts_driver = {
.of_match_table = of_match_ptr(pixcir_of_match),
},
.probe  = pixcir_i2c_ts_probe,
-   .remove = pixcir_i2c_ts_remove,
.id_table   = pixcir_i2c_ts_id,
 };
 
-- 
2.6.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] ARM: dts: am437x-gp-evm: Add wakeup interrupt source for pixcir_i2c_ts

[Vignesh R]

On am437x-gp-evm, pixcir_i2c_ts can wakeup the system from lower power
state via pinctrl and IO daisy chain using generic wakeirq framework.
With commit 3fffd1283927 ("i2c: allow specifying separate wakeup
interrupt in device tree") i2c core allows optional wakeirq to be
specified via device tree. Add wakeup irq entry to enable pixcir_i2c_ts
to wake the system from low power state.

Signed-off-by: Vignesh R 
---
 arch/arm/boot/dts/am437x-gp-evm.dts | 5 +
 1 file changed, 5 insertions(+)

diff --git a/arch/arm/boot/dts/am437x-gp-evm.dts 
b/arch/arm/boot/dts/am437x-gp-evm.dts
index 22038f21f228..69e93af7df0d 100644
--- a/arch/arm/boot/dts/am437x-gp-evm.dts
+++ b/arch/arm/boot/dts/am437x-gp-evm.dts
@@ -581,8 +581,13 @@
 
attb-gpio = < 22 GPIO_ACTIVE_HIGH>;
 
+   interrupts-extended = < 22 GPIO_ACTIVE_HIGH>,
+ <_pinmux 0x264>;
+   interrupt-names = "tsc", "wakeup";
+
touchscreen-size-x = <1024>;
touchscreen-size-y = <600>;
+   wakeup-source;
};
 
ov2659@30 {
-- 
2.6.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: bisected: Re: 4.3.0-rc3-00042: ACPI Warning: AcpiEnable failed

[Zheng, Lv]

Hi,

> From: Rafael J. Wysocki [mailto:r...@rjwysocki.net]
> Sent: Tuesday, October 13, 2015 3:19 AM
> 
> On Monday, October 12, 2015 07:48:12 AM Zheng, Lv wrote:
> > Hi, Rafael
> 
> Hi,
> 
> > The bug has been fixed.
> > The root cause is the previous commit doesn't cover a hidden logic:
> >  acpi_enable() should rely on the existence of FADT while currently it 
> > relies on the number of loaded tables.
> > The fix that removes the hidden logic is an ACPICA commit.
> > Shall we wait until it is merged via an ACPICA release cycle or make it a 
> > bit faster by merging Linuxized version first?
> 
> Please send the Linuxized version of it ASAP, we need it for 4.3.

I'll send the fix to this thread.

Thanks and best regards
-Lv

> 
> Thanks,
> Rafael
> 
> 
> > > From: mr...@math.ut.ee [mailto:mr...@math.ut.ee] On Behalf Of Meelis Roos
> > > Sent: Friday, October 02, 2015 2:14 PM
> > >
> > > > > > 4.2.0 worked fine, 4.3.0-rc3-00042-g3225031 was the next one tested
> > > > > > after that and with this kernel, ACPI enabling fails. This is 
> > > > > > Pentium
> > > > > > III, 1 GHz, Intel 815 chipset, DMI tells something about "Packard 
> > > > > > Bell
> > > > > > NEC" as the mainboard type.
> > > > > >
> > > > > > Full dmesg and config are below. What additional information can I
> > > > > > provide besides bisecting (will take time)?
> > > > >
> > > > > Bisecting done, here is the culprit:
> > > > >
> > > > > 8ec3f459073e67e5c6d78507dec693064b3040a2 is the first bad commit
> > > > > commit 8ec3f459073e67e5c6d78507dec693064b3040a2
> > > > > Author: Lv Zheng 
> > > > > Date:   Tue Aug 25 10:29:01 2015 +0800
> > > > >
> > > > > ACPICA: Tables: Fix global table list issues by removing fixed 
> > > > > table indexes
> > > > >
> > > > > ACPICA commit c0b38b4c3982c2336ee92a2a14716107248bd941
> > > >
> > > > Thanks a lot for bisecting this!
> > > >
> > > > It will help if you file a bug entry at bugzilla.kernel.org agaist ACPI 
> > > > for
> > > > this issue (please mark it as a regression) and attach the output of 
> > > > acpidump
> > > > from the affected system to it.
> > >
> > > Done, https://bugzilla.kernel.org/show_bug.cgi?id=105351
> > >
> > > --
> > > Meelis Roos (mr...@linux.ee)
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> > the body of a message to majord...@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> > Please read the FAQ at  http://www.tux.org/lkml/
> 
> --
> I speak only for myself.
> Rafael J. Wysocki, Intel Open Source Technology Center.

Re: [PATCH] i2c: at91: fix write transfers by clearing pending interrupt first

[Ludovic Desroches]

On Tue, Oct 13, 2015 at 08:01:34PM +0200, Peter Rosin wrote:
> On 2015-10-13 18:47, Cyrille Pitchen wrote:
> > Le 13/10/2015 17:19, Peter Rosin a écrit :
> >> On 2015-10-13 16:21, Ludovic Desroches wrote:
> >>> From: Cyrille Pitchen 
> >>>
> >>> In some cases a NACK interrupt may be pending in the Status Register (SR)
> >>> as a result of a previous transfer. However at91_do_twi_transfer() did not
> >>> read the SR to clear pending interruptions before starting a new transfer.
> >>> Hence a NACK interrupt rose as soon as it was enabled again at the I2C
> >>> controller level, resulting in a wrong sequence of operations and strange
> >>> patterns of behaviour on the I2C bus, such as a clock stretch followed by
> >>> a restart of the transfer.
> >>>
> >>> This first issue occurred with both DMA and PIO write transfers.
> >>>
> >>> Also when a NACK error was detected during a PIO write transfer, the
> >>> interrupt handler used to wrongly start a new transfer by writing into the
> >>> Transmit Holding Register (THR). Then the I2C slave was likely to reply
> >>> with a second NACK.
> >>>
> >>> This second issue is fixed in atmel_twi_interrupt() by handling the TXRDY
> >>> status bit only if both the TXCOMP and NACK status bits are cleared.
> >>>
> >>> Tested with a at24 eeprom on sama5d36ek board running a linux-4.1-at91
> >>> kernel image. Adapted to linux-next.
> >>>
> >>> Signed-off-by: Cyrille Pitchen 
> >>> Fixes: 93563a6a71bb ("i2c: at91: fix a race condition when using the DMA 
> >>> controller")
> >>> Reported-by: Peter Rosin 
> >>> Signed-off-by: Ludovic Desroches 
> >>> Cc: sta...@vger.kernel.org #4.1
> >>
> >> The regression is gone with this patch (vanilla 4.2), thank you!
> >>
> >> However, looking at the bus, there are two NACKs after each
> >> successful chunk of memory written by the eeprom driver.
> >>
> >> Looking at the eeprom driver, I expect this on the bus:
> >>
> >> S 0x50 0x00 "hello there guys" P
> >> S 0x50 NACK P
> >> delay for at least 1 ms (since the eeprom driver has a msleep(1) call).
> >> S 0x50 NACK P
> >> delay for at least 1 ms
> >> ...
> >> ...
> >> S 0x50 NACK P
> >> delay for at least 1 ms
> >> S 0x50 0x10 "and girls\n" P
> >>
> >> This is not what I observe on the bus, most of the time there is a
> >> second NACK immediately following the first. I suspect that it is
> >> the i2c bus driver that somehow confuses itself and reissues the
> >> command for some reason?
> >>
> >> But this behavior has been there since the beginning, so it's probably
> >> orthogonal, and killing the data corrupting regression is much more
> >> important to me than fussing over a surplus failed transfer. Hence
> >>
> >> Tested-by: Peter Rosin 
> >>
> >> Cheers,
> >> Peter
> >>
> > 
> > Hi Peter,
> > 
> > sama5d3x and sama5d4x don't support the so called "Alternative Command mode"
> > whereas sama5d2x do. The Alternative Command mode comes with a new hardware
> > mechanism inside the I2C controller which locks the transmission of data on
> > the I2C bus when a NACK is detected. It means that even if a data is written
> > into the THR, the I2C controller doesn't push this data on the I2C bus but
> > retains the data in the THR (and its associated FIFO for sama5d2x and future
> > SoCs) until the driver unlocks the transmitter by writing the LOCKCLR (Lock
> > Clear) bit in the Control Register. Then and only then, the transmitter 
> > outputs
> > pending data again.
> > This new mechanism was introduced to cope with an unwanted DMA write into 
> > the
> > THR after a NACK. Indeed, as I've tried to explain in my patch, when a first
> > NACK is detected, the I2C controller sets the TXCOMP, NACK and TXRDY bits
> > alltogether in the Status Register. However setting the TXRDY bit also 
> > triggers
> > the DMA controller to write the next data into the THR. Pitifully, WITHOUT 
> > the
> > new lock mechanism, writing into the THR starts a new I2C frame. Since the
> > eeprom is likely not to be ready yet, it replies by a second NACK. So you
> > see on the scope two consecutive NACKs.
> > 
> > On sama5d3x and sama5d4x, which do not support this lock mechanism, you are
> > likely to see a successful write transfer followed by two NACKs then a delay
> > and finally a new successful write transfer. This is the case 2b:
> > 
> > 1 - A successfull write transfer is completed.
> > 2 - The at24 driver immediately tries to perform the next write transfer...
> > 3 - ... but the eeprom is not ready yet and replies with a first NACK.
> > 4 - The I2C controller detects this NACK and sets the NACK, TXCOMP and TXRDY
> > bits in its Status Register (and interrupts the CPU).
> > 5 - The DMA controller is triggered by the TXRDY bit to write the next data
> > into the THR.
> > 6 - WITHTOUT the lock mechanism, the I2C controller starts a new frame 
> > because
> >of the write into the THR by the DMA controller...
> > 7 - ... but the eeprom is still not ready and replies with a second NACK.
> > 
> > 8 - starting 

[PATCH] gfp: GFP_RECLAIM_MASK should include __GFP_NO_KSWAPD

[Pan Xinhui]

From: Pan Xinhui 

GFP_RECLAIM_MASK was introduced in commit 6cb062296f73 ("Categorize GFP
flags"). In slub subsystem, this macro controls slub's allocation
behavior. In particular, some flags which are not in GFP_RECLAIM_MASK
will be cleared. So when slub pass this new gfp_flag into page
allocator, we might lost some very important flags.

There are some mistakes when we introduce __GFP_NO_KSWAPD. This flag is
used to avoid any scheduler-related codes recursive.  But it seems like
patch author forgot to add it into GFP_RECLAIM_MASK. So lets add it now.

Signed-off-by: Pan Xinhui 
---
 include/linux/gfp.h | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/include/linux/gfp.h b/include/linux/gfp.h
index f92cbd2..9ebad4d 100644
--- a/include/linux/gfp.h
+++ b/include/linux/gfp.h
@@ -130,7 +130,8 @@ struct vm_area_struct;
 /* Control page allocator reclaim behavior */
 #define GFP_RECLAIM_MASK (__GFP_WAIT|__GFP_HIGH|__GFP_IO|__GFP_FS|\
__GFP_NOWARN|__GFP_REPEAT|__GFP_NOFAIL|\
-   __GFP_NORETRY|__GFP_MEMALLOC|__GFP_NOMEMALLOC)
+   __GFP_NORETRY|__GFP_MEMALLOC|__GFP_NOMEMALLOC|\
+   __GFP_NO_KSWAPD)
 
 /* Control slab gfp mask during early boot */
 #define GFP_BOOT_MASK (__GFP_BITS_MASK & ~(__GFP_WAIT|__GFP_IO|__GFP_FS))
-- 
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 5/6] e1000 driver remove checkpatch errors, warnings and checks.

[Jeff Kirsher]

On Tue, 2015-10-13 at 15:23 -0700, Alexander Duyck wrote:
> On 10/13/2015 02:39 PM, Janusz Wolak wrote:
> > From: Janusz Wolak 
> >
> > Signed-off-by: Janusz Wolak 
> > ---
> >   drivers/net/ethernet/intel/e1000/e1000_param.c | 114
> ++---
> >   1 file changed, 82 insertions(+), 32 deletions(-)
> >
> > diff --git a/drivers/net/ethernet/intel/e1000/e1000_param.c
> b/drivers/net/ethernet/intel/e1000/e1000_param.c
> > index c9cde35..9ec730e 100644
> > --- a/drivers/net/ethernet/intel/e1000/e1000_param.c
> > +++ b/drivers/net/ethernet/intel/e1000/e1000_param.c
> > @@ -1,5 +1,5 @@
> >  
> /
> ***
> > -
> > +*
> > Intel PRO/1000 Linux driver
> > Copyright(c) 1999 - 2006 Intel Corporation.
> >   
> > @@ -45,10 +45,10 @@
> >   
> >   #define E1000_PARAM_INIT { [0 ... E1000_MAX_NIC] = OPTION_UNSET }
> >   #define E1000_PARAM(X, desc) \
> > - static int X[E1000_MAX_NIC+1] = E1000_PARAM_INIT; \
> > + static int X[E1000_MAX_NIC + 1] = E1000_PARAM_INIT; \
> >   static unsigned int num_##X; \
> >   module_param_array_named(X, X, int, _##X, 0); \
> > - MODULE_PARM_DESC(X, desc);
> > + MODULE_PARM_DESC(X, desc)
> >   
> >   /* Transmit Descriptor Count
> >*
> > @@ -200,6 +200,7 @@ struct e1000_option {
> >   } r;
> >   struct { /* list_option info */
> >   int nr;
> > +
> >   const struct e1000_opt_list { int i; char
> *str; } *p;
> >   } l;
> >   } arg;
> 
> How is adding a space here adding any value?  Please don't just
> blindly 
> follow checkpatch as it can give out erroneous information.
> 
> Looking over most of this patch series it seems like it is taking 
> readability in the wrong direction and reducing the ability to
> maintain 
> the driver since this code has been "maintenance only" for some time 
> now.  If somebody comes up with a legitimate fix for an issue at some
> point in the future they will need to work around these patches in
> order 
> to back-port it into a stable release and that just hurts
> maintainability.
> 
> I'd say this whole series should be rejected on the grounds that this
> driver is mostly stable and should only really be modified for bug
> fixes 
> at this point.  If we really need to go through and do a checkpatch 
> sweep we should probably just focus on serious errors only instead of
> going astray and chasing down things that are false hits or minor
> issues 
> that are mostly a matter of preference.

In addition to all what Alex has said, I am not pleased about a 6 patch
series, with every patch in the series with the exact same frickin
title.

Consider this patch series rejected and dropped.

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

[PATCH] arm: dts: ls1021a: Add quirk for Erratum A009116

[Rajesh Bhagat]

Add "snps,quirk-frame-length-adjustment" property to
USB3 node for erratum A009116. This property provides
value of GFLADJ_30MHZ for post silicon frame length
adjustment.

Signed-off-by: Nikhil Badola 
Signed-off-by: Rajesh Bhagat 
---
This patch was intiallly part of below patchset(other patches accepted), 
but patch can go independently through arm-soc tree. 
Refer: https://lkml.org/lkml/2015/10/8/46

 arch/arm/boot/dts/ls1021a.dtsi |1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/arch/arm/boot/dts/ls1021a.dtsi b/arch/arm/boot/dts/ls1021a.dtsi
index c70bb27..50ac0d4 100644
--- a/arch/arm/boot/dts/ls1021a.dtsi
+++ b/arch/arm/boot/dts/ls1021a.dtsi
@@ -404,6 +404,7 @@
reg = <0x0 0x310 0x0 0x1>;
interrupts = ;
dr_mode = "host";
+   snps,quirk-frame-length-adjustment = <0x20>;
};
};
 };
-- 
1.7.7.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 1/2] dax: dax_pfn_mkwrite() truncate race check

[Dave Chinner]

On Tue, Oct 13, 2015 at 04:25:36PM -0600, Ross Zwisler wrote:
> Update dax_pfn_mkwrite() so that it validates i_size before returning.
> This is necessary to ensure that the page fault has not raced with truncate
> and is now pointing to a region beyond the end of the current file.
> 
> This change is based on a similar outstanding patch for XFS from Dave
> Chinner entitled "xfs: add ->pfn_mkwrite support for DAX".
> 
> Signed-off-by: Ross Zwisler 
> Cc: Dave Chinner 
> ---
>  fs/dax.c | 13 +++--
>  1 file changed, 11 insertions(+), 2 deletions(-)
> 
> diff --git a/fs/dax.c b/fs/dax.c
> index 131fd35a..82be6e4 100644
> --- a/fs/dax.c
> +++ b/fs/dax.c
> @@ -693,12 +693,21 @@ EXPORT_SYMBOL_GPL(dax_pmd_fault);
>   */
>  int dax_pfn_mkwrite(struct vm_area_struct *vma, struct vm_fault *vmf)
>  {
> - struct super_block *sb = file_inode(vma->vm_file)->i_sb;
> + struct inode *inode = file_inode(vma->vm_file);
> + struct super_block *sb = inode->i_sb;
> + int ret = VM_FAULT_NOPAGE;
> + loff_t size;
>  
>   sb_start_pagefault(sb);
>   file_update_time(vma->vm_file);
> +
> + /* check that the faulting page hasn't raced with truncate */
> + size = (i_size_read(inode) + PAGE_SIZE - 1) >> PAGE_SHIFT;
> + if (vmf->pgoff >= size)
> + ret = VM_FAULT_SIGBUS;
> +
>   sb_end_pagefault(sb);
> - return VM_FAULT_NOPAGE;
> + return ret;

This is still racy, as the read of the inode size is not serialised
against or ordered by any locks held by truncate. The check in XFS
is serialised against truncate by the XFS_MMAPLOCK and the generic
DAX code does not have such a mechanism to rely on. Hence I'd
suggest that the correct thing to do here is remove
dax_pfn_mkwrite() and force filesystems to implement their own
truncate-safe variants of ->pfn_mkwrite.

And on further thought, I'm not sure that what I did with XFS is
at all correct when considering hole punching. That is, to get a PFN
based fault, we've already had to guarantee the file offset has
blocks allocated and mapped them. Then:

process 1   process 2
pfn_mkwrite @ X punch hole @ X
 xfs_filemap_pfn_mkwriteXFS_MMAPLOCK_EXCL
  XFS_MMAPLOCK_SHARED

invalidate mapping @ X
remove blocks @ X

unlock XFS_MMAPLOCK_EXCL
   checks file size
  unlock XFS_MMAPLOCK_SHARED
  return VM_FAULT_NOPAGE

And so process 1 continues with an invalid page mapping over the
hole process 2 just punched in the file. That's a data
exposure/corruption problem the underlying blocks get reallocated
to some other file.

Unless I'm missing something here, this gets ugly real fast.

If we treat ->pfn_mkwrite like ->page_mkwrite() and allocate blocks
under the pfn that was invalidated and punched out by the hole punch
operation, then *the physical pfn that maps to the file offset that
the page fault occurred for changes*.

So, we can't allocate new blocks during ->pfn_mkwrite. All we can
do is check the pfn mapping is still valid when we have serialised
against hole punch/truncate, and if it isn't we need to return
VM_FAULT_RETRY so that the page fault is restarted to find the new
mapping which can then have ->page_mkwrite/->pfn_mkwrite called
on it.

The biggest problem here is that VM_FAULT_RETRY will only allow one
retry of the page fault - if the page fault races twice in a row
with a hole punch (need 3 processes, two doing write faults at the
same offset, and the other repeatedly hole punching the same offset)
then we'll SIGBUS the process on the second VM_FAULT_RETRY in a row
from ->pfn_mkwrite

And because I don't have all day to work out all the twisty paths of
the page fault code, where is a pfn-based read fault validated
against racing truncate/holepunch operations freeing the
underlying storage?

Cheers,

Dave.
-- 
Dave Chinner
da...@fromorbit.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC PATCH 2/2] bpf: Implement bpf_perf_event_sample_enable/disable() helpers

[Alexei Starovoitov]

On 10/13/15 3:54 AM, He Kuang wrote:

If we want perf to reflect as soon as our sample event be generated,
--no-buffering should be used, but this option has a greater
impact on performance.


no_buffering doesn't have to be applied to all events obviously.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v3 1/7] arm64: ftrace: adjust callsite addresses examined by stack tracer

[AKASHI Takahiro]

On 10/14/2015 12:37 AM, Steven Rostedt wrote:

On Thu,  8 Oct 2015 19:01:38 +0900
AKASHI Takahiro  wrote:


  extern int stack_tracer_enabled;
  int
  stack_trace_sysctl(struct ctl_table *table, int write,
diff --git a/kernel/trace/trace_stack.c b/kernel/trace/trace_stack.c
index b746399..30521ea 100644
--- a/kernel/trace/trace_stack.c
+++ b/kernel/trace/trace_stack.c
@@ -105,7 +105,7 @@ check_stack(unsigned long ip, unsigned long *stack)

/* Skip over the overhead of the stack tracer itself */
for (i = 0; i < max_stack_trace.nr_entries; i++) {
-   if (stack_dump_trace[i] == ip)
+   if ((stack_dump_trace[i] + FTRACE_STACK_FRAME_OFFSET) == ip)
break;
}

@@ -133,7 +133,8 @@ check_stack(unsigned long ip, unsigned long *stack)
for (; p < top && i < max_stack_trace.nr_entries; p++) {
if (stack_dump_trace[i] == ULONG_MAX)
break;
-   if (*p == stack_dump_trace[i]) {
+   if (*p == (stack_dump_trace[i]
+   + FTRACE_STACK_FRAME_OFFSET)) {


I'm fine with the patch, but this is one of those cases that I think
the 80 column max limit produces uglier code than just going a little
over.

Or, we can add a helper variable in both locations:

addr = stack_dump_trace[i] + FTRACE_STACK_FRAME_OFFSET;
if (*p == addr) {

gcc should be smart enough to optimize out the addr variable.


Thanks, I will take this.
(please note that this patch won't be necessary if my patch5,6 and 7 are
accepted.)

-Takahiro AKASHI


-- Steve


stack_dump_trace[x] = stack_dump_trace[i++];
this_size = stack_dump_index[x++] =
(top - p) * sizeof(unsigned long);



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] blk-mq: fix use-after-free in blk_mq_free_tag_set()

[Junichi Nomura]

tags is freed in blk_mq_free_rq_map() and should not be used after that.
The problem doesn't manifest if CONFIG_CPUMASK_OFFSTACK is false because
free_cpumask_var() is nop.

tags->cpumask is allocated in blk_mq_init_tags() so it's natural to
free cpumask in its counter part, blk_mq_free_tags().

Fixes: f26cdc8536ad ("blk-mq: Shared tag enhancements")
Signed-off-by: Jun'ichi Nomura 
Cc: Keith Busch 
Cc: Jens Axboe 
---
 block/blk-mq-tag.c | 1 +
 block/blk-mq.c | 4 +---
 2 files changed, 2 insertions(+), 3 deletions(-)

diff --git a/block/blk-mq-tag.c b/block/blk-mq-tag.c
index ed96474..ec2d119 100644
--- a/block/blk-mq-tag.c
+++ b/block/blk-mq-tag.c
@@ -641,6 +641,7 @@ void blk_mq_free_tags(struct blk_mq_tags *tags)
 {
bt_free(>bitmap_tags);
bt_free(>breserved_tags);
+   free_cpumask_var(tags->cpumask);
kfree(tags);
 }
 
diff --git a/block/blk-mq.c b/block/blk-mq.c
index 7785ae9..85f0143 100644
--- a/block/blk-mq.c
+++ b/block/blk-mq.c
@@ -2296,10 +2296,8 @@ void blk_mq_free_tag_set(struct blk_mq_tag_set *set)
int i;
 
for (i = 0; i < set->nr_hw_queues; i++) {
-   if (set->tags[i]) {
+   if (set->tags[i])
blk_mq_free_rq_map(set, set->tags[i], i);
-   free_cpumask_var(set->tags[i]->cpumask);
-   }
}
 
kfree(set->tags);
-- 
2.1.0--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v3 3/7] arm64: ftrace: fix a stack tracer's output under function graph tracer

[AKASHI Takahiro]

On 10/14/2015 12:24 AM, Jungseok Lee wrote:

On Oct 8, 2015, at 7:01 PM, AKASHI Takahiro wrote:

Hi Akashi,


Function graph tracer modifies a return address (LR) in a stack frame
to hook a function return. This will result in many useless entries
(return_to_handler) showing up in a stack tracer's output.

This patch replaces such entries with originals values preserved in
current->ret_stack[].

Signed-off-by: AKASHI Takahiro 


The following diff should be folded into this patch, not [7/7] one, to
address build breakage.


Thanks.
I fixed all the build errors reported by kbuild test robot.

-Takahiro AKASHI


8<
diff --git a/arch/arm64/kernel/stacktrace.c b/arch/arm64/kernel/stacktrace.c
index 407991b..7126d4d 100644
--- a/arch/arm64/kernel/stacktrace.c
+++ b/arch/arm64/kernel/stacktrace.c
@@ -17,6 +17,7 @@
   */
  #include 
  #include 
+#include 
  #include 
  #include 
8<

Best Regards
Jungseok Lee


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] drm/nouveau: fix memory leak

[Sudip Mukherjee]

On Thu, Oct 08, 2015 at 03:22:20PM +0100, Emil Velikov wrote:
> On 8 October 2015 at 14:00, Sudip Mukherjee  
> wrote:
> > On Thu, Oct 01, 2015 at 04:40:59PM +1000, Ben Skeggs wrote:
> >> On 09/25/2015 01:59 AM, Sudip Mukherjee wrote:
> >> > On Fri, Sep 11, 2015 at 03:00:56PM +0530, Sudip Mukherjee wrote:
> >> >> If pm_runtime_get_sync() we were going to "out" but we missed
> >> >> freeing vma.
> >> >>
> >> >> Signed-off-by: Sudip Mukherjee  ---
> >> > Hi Ben, Another gentle ping for another patch.
> >> Both patches are in my tree.
> >
> > Hi Ben,
> > I am not seeing these in linux-next.
> >
> The nouveau tree does not merge into linux-next I'm afraid. Perhaps we
> should as Ben gets the chance/time.

Can I be of any help in that? Maybe I can learn few things about drm in
the proces.

regards
sudip
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 0/3] drivers/misc/sgi-gru: unapplied patches and a new one

[Sudip Mukherjee]

On Mon, Oct 05, 2015 at 10:18:32AM -0500, Dimitri Sivanich wrote:
> On Mon, Oct 05, 2015 at 08:43:07PM +0530, Sudip Mukherjee wrote:
> > On Thu, Sep 24, 2015 at 12:31:01PM +0530, Sudip Mukherjee wrote:
> > > On Wed, Sep 23, 2015 at 12:48:25PM -0500, Dimitri Sivanich wrote:
> > > > Sudip,
> > > > 
> > > > I can take a look at the Jack Steiner patches.  Was there anything in 
> > > > the set
> > > > of 3 patches that you sent that still needs a review?
> > > Yes. The 3/3 patch please. That one is new. I found that problem while
> > > checking another old patch.
> > > If Jack Steiner patches looks ok then you can send the series to Greg or
> > > if you want me to send please do let me know.
> > 
> > Hi Dimitri,
> > Greg has picked up this series. Did you have a chance to look at the
> > series of Jack Steiner or shall i repost for your review?
> >
> I haven't had a chance to fully review those yet.

Hi Dimitri,
will it help if I repost them as patch? I understand it will be
difficult to review patches in webpage from where you can not apply and
test. Please do let me know if i can be of any help.

regards
sudip
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] MAINTAINERS: fix entry of char/misc

[Sudip Mukherjee]

On Tue, Oct 13, 2015 at 10:39:47AM -0700, Greg Kroah-Hartman wrote:
> On Tue, Oct 13, 2015 at 10:49:24PM +0530, Sudip Mukherjee wrote:
> > On Tue, Oct 13, 2015 at 07:48:05AM -0700, Joe Perches wrote:
> > > On Tue, 2015-10-13 at 15:34 +0530, Sudip Mukherjee wrote:
> > > > Greg and Arnd are supporter of char and misc drivers. While using
> > > > getmaintainer.pl on any patch or any file in these directories their
> > > > names were never displayed.
> > > []
> > > > diff --git a/MAINTAINERS b/MAINTAINERS
> > > []
> > > >  M: Greg Kroah-Hartman 
> > > >  T: git 
> > > > git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc.git
> > > >  S: Supported
> > > > -F: drivers/char/*
> > > > -F: drivers/misc/*
> > > > +F: drivers/char/
> > > > +F: drivers/misc/
> > > >  F: include/linux/miscdevice.h
> > > 
> > > Do Greg and Arnd really want to be supporting all
> > > subsystems below drivers/char like agp and xillybus?
> > 
> > I don't know that. Maybe Greg and Arnd can say.
> > But wasn't that the intention when char/* and misc/* was mentioned here?
> 
> Kind of, I'm here to pick up the portions of this tree that do not have
> a maintainer already (random.c is one example.)

Then what about the ones that has a maintainer? I had specifically
sgi-gru in mind when I made this patch. I hope you remember the issue
that I pointed out when i sent some patches for that.

regards
sudip
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] debugfs: update commits of debugfs_remove

[Tan Xiaojun]

Please ignore this patch, I make a spelling mistake.

On 2015/10/14 10:53, Tan Xiaojun wrote:
> This function debugfs_remove can't remove a directory if it is not
> empty. The commits make misunderstood and cause misuse easily, so
> update it.
> 
> Signed-off-by: Tan Xiaojun 
> ---
>  fs/debugfs/inode.c | 6 +-
>  1 file changed, 5 insertions(+), 1 deletion(-)
> 
> diff --git a/fs/debugfs/inode.c b/fs/debugfs/inode.c
> index c711be8..350754e 100644
> --- a/fs/debugfs/inode.c
> +++ b/fs/debugfs/inode.c
> @@ -531,7 +531,8 @@ static int __debugfs_remove(struct dentry *dentry, struct 
> dentry *parent)
>  }
>  
>  /**
> - * debugfs_remove - removes a file or directory from the debugfs filesystem
> + * debugfs_remove - removes a file or an empty directory from the debugfs
> + *   filesystem
>   * @dentry: a pointer to a the dentry of the file or directory to be
>   *  removed.
>   *
> @@ -542,6 +543,9 @@ static int __debugfs_remove(struct dentry *dentry, struct 
> dentry *parent)
>   * This function is required to be called in order for the file to be
>   * removed, no automatic cleanup of files will happen when a module is
>   * removed, you are responsible here.
> + *
> + * For removing directory, if you are not sure it is empty or not, use
> + * debugfs_remove_recursive instead.
>   */
>  void debugfs_remove(struct dentry *dentry)
>  {
> 


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] rtc: pcf8563: disable CLKOUT

[Heiko Schocher]

Hello Alexandre,

Am 13.10.2015 um 22:17 schrieb Alexandre Belloni:

Hi,

On 13/10/2015 at 07:08:58 +0200, Heiko Schocher wrote :

Disable the CLKOUT of the RTC after power-up.
After power-up/reset of the RTC, CLKOUT is enabled by default,
with CLKOUT enabled the RTC chip has 2-3 times higher power
consumption. If you do not need CLKOUT, you can disable the
CLKOUT with setting "disable-clkout" property.



I think you can simply unconditionally disable clkout. My preferred way
of doing what you suggest is probably to register a clock in the CCF. If
the clock is not used, it will be automatically disabled.
It will also provide a generic way of setting the clkout frequency (some
RTC are able to output 32kHZ, 1kHz and 1Hz).


Does disabling it ot break some boards?

I take a look into CCF, good idea.

bye,
Heiko
--
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 3/3] ARM: dts: exynos5422-odroidxu3: Added UHS-I bus speed support

[Krzysztof Kozlowski]

On 14.10.2015 12:58, Anand Moon wrote:
> hi Krzysztof,
> 
> On 14 October 2015 at 05:29, Krzysztof Kozlowski
>  wrote:
>> On 14.10.2015 01:27, Anand Moon wrote:
>>> Hi Krzysztof,
>>>
>>> On 13 October 2015 at 09:13, Krzysztof Kozlowski
>>>  wrote:

 On 13.10.2015 12:08, Anand Moon wrote:
> Hi Krzysztof,
>
> On 13 October 2015 at 05:44, Krzysztof Kozlowski
>  wrote:
>> On 13.10.2015 00:32, Anand Moon wrote:
>>> Hi Krzysztof,
>>>
>>> On 12 October 2015 at 11:14, Krzysztof Kozlowski
>>>  wrote:
 On 12.10.2015 00:46, Anand Moon wrote:
> Added support for UHS-I bus speed 50MB/s (SDR50, DDR50) 104MB/s 
> (SDR104)

 This description is not entirely correct. The MMC driver already
 supports these UHS speeds (you did not any code) so you rather enabled
 it (description of bindings says "is supported").

 You mentioned DDR50 but I don't see respective property below.

 How do you know that these modes are really supported? I don't know. 
 Can
 you convince me?
>>>
>>> Setting this DDR50 capability give me this error. That's the reason to
>>> drop this capability.
>>
>> But you mentioned it in commit message! "Added support for UHS-I ...
>> (DDR50)"
>>
>> In the same time dropping DDR50 is not an sufficient proof that "SDR50
>> and SDR104 are really supported".
>>
>
> These changes are related to the microSD card capabilities.
> So SDR50 have better frequency over DDR50. On the same Sandisk card.
>
> When the card select the capability for DDR50
> ---
> [4.001477] mmc_host mmc1: Bus speed (slot 0) = 5000Hz (slot
> req 5000Hz, actual 5000HZ div = 0)
> [4.001604] mmc1: new ultra high speed DDR50 SDHC card at address 
> [4.004505] mmcblk0: mmc1: SL32G 29.7 GiB
> [4.009179] mmcblk0: error -110 sending status command, retrying
> [4.009271] mmcblk0: error -115 sending stop command, original cmd
> response 0x900, card status 0x900
> [4.009275] mmcblk0: error -84 transferring data, sector 0, nr 8,
> cmd response 0x900, card status 0x0
> [4.025563] mmc_host mmc1: Bus speed (slot 0) = 5000Hz (slot
> req 40Hz, actual 396825HZ div = 63)
> [4.067770] Console: switching to colour frame buffer device 274x77
> [4.098782] mmc_host mmc1: Bus speed (slot 0) = 5000Hz (slot
> req 5000Hz, actual 5000HZ div = 0)
> [4.099692] mmc1: tried to reset card
> [4.101332]  mmcblk0: p1 p2
>
>
> When the card select the capability for SDR50
> -
> [ 2.439806] mmc_host mmc1: Bus speed (slot 0) = 1Hz (slot req
> 1Hz, actual 1HZ div = 0)
> [ 2.449729] mmc1: new ultra high speed SDR50 SDHC card at address 
> [ 2.455984] mmcblk0: mmc1: SL32G 29.7 GiB
> [ 2.461743] mmcblk0: p1 p2
>
> Which will relate to better read/write speed.

 Which is not an answer to my question. To none of my previous questions.

>>>
>>> Basically UHS-I capability  (sd-uhs-sdr12, sd-uhs-sdr25, sd-uhs-sdr50,
>>> sd-uhs-sdr104) help tune speed supported for mmc
>>>
>>> I have tired to compare the speed on high speed UHS-I vs ultra high
>>> speed UHS-I using izone utility.
>>>
>>> [2.572469] mmc_host mmc1: Bus speed (slot 0) = 5000Hz (slot
>>> req 5000Hz, actual 5000HZ div = 0)
>>> [2.572609] mmc1: new high speed SDHC card at address 
>>>
>>>   Command line used: ./iozone -L64 -S32 -azecwI -+n -r4k -r64k
>>> -r128k -s10M -i0 -i1 -i2 -f datafile -Rb out.xls
>>> Output is in kBytes/sec
>>> Time Resolution = 0.01 seconds.
>>> Processor cache size set to 32 kBytes.
>>> Processor cache line size set to 64 bytes.
>>> File stride size set to 17 * record size.
>>>   random
>>>  random bkwdrecordstride
>>>   kB  reclenwrite  rewritereadrereadread
>>>   write read   rewrite  read   fwrite frewritefread
>>> freread
>>>10240   4 16310 65560 5538  
>>> 982
>>>10240  64 8828018897017994  
>>> 303
>>>10240 128 6269020670020128 
>>> 1096
>>> -
>>> [2.613761] mmc_host mmc1: Bus speed (slot 0) = 1Hz (slot
>>> req 1Hz, actual 1HZ div = 0)
>>> [2.623573] mmc1: new ultra high speed SDR50 SDHC card at address 
>>>
>>> Command line used: ./iozone -L64 -S32 -azecwI -+n -r4k 

Re: [PATCH] net: phy: smsc: disable energy detect mode

[Heiko Schocher]

Hello Florian,

Am 13.10.2015 um 21:26 schrieb Florian Fainelli:

On 12/10/15 22:13, Heiko Schocher wrote:

On some boards the energy enable detect mode leads in
trouble with some switches, so make the enabling of
this mode configurable through DT.

Signed-off-by: Heiko Schocher 
---

  .../devicetree/bindings/net/smsc-lan87xx.txt   | 19 +
  drivers/net/phy/smsc.c | 24 +-
  2 files changed, 38 insertions(+), 5 deletions(-)
  create mode 100644 Documentation/devicetree/bindings/net/smsc-lan87xx.txt

diff --git a/Documentation/devicetree/bindings/net/smsc-lan87xx.txt 
b/Documentation/devicetree/bindings/net/smsc-lan87xx.txt
new file mode 100644
index 000..39aa1dc
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/smsc-lan87xx.txt
@@ -0,0 +1,19 @@
+SMSC LAN87xx Ethernet PHY
+
+Some boards require special tuning values. Configure them
+through an Ethernet OF device node.
+
+Optional properties:
+
+- disable-energy-detect:
+  If set, do not enable energy detect mode for the SMSC phy.
+  default: enable energy detect mode


Although energy detection is something that is implemented by many PHYs,
I am not sure a generic property is suitable here, I would prefix that
with the SMSC vendor prefix here to make it clear this only applies to
this PHY.


Hmm... but all PHYs should be able to enable, disable it in some way, or?


Would not you want to make it a reverse property here though, something
like this:

smsc,energy-detect: boolean, when present indicates the PHY reliably
supports energy detection


Yes, that was also my first thought, but currently, on this PHYs
energy detect mode is on ... and if I introduce such a property,
it will disable it for all existing boards, because property is
missing ... so, maybe I break boards ...


+
+Examples:
+
+   /* Attach to an Ethernet device with autodetected PHY */
+   _emac0 {
+   phy_id = <_mdio>, <0>;
+   phy-mode = "mii";
+   disable-energy-detect;
+   };
diff --git a/drivers/net/phy/smsc.c b/drivers/net/phy/smsc.c
index 70b0895..f90fbf3 100644
--- a/drivers/net/phy/smsc.c
+++ b/drivers/net/phy/smsc.c
@@ -43,16 +43,30 @@ static int smsc_phy_ack_interrupt(struct phy_device *phydev)

  static int smsc_phy_config_init(struct phy_device *phydev)
  {
+#ifdef CONFIG_OF
+   int len;
+   struct device *dev = >dev;
+   struct device_node *of_node = dev->of_node;


That does not need to be ifdefd out, at best annontate with __maybe_unused?


Yes, I try it.


+#endif
int rc = phy_read(phydev, MII_LAN83C185_CTRL_STATUS);
+   int enable_energy = 1;

if (rc < 0)
return rc;

-   /* Enable energy detect mode for this SMSC Transceivers */
-   rc = phy_write(phydev, MII_LAN83C185_CTRL_STATUS,
-  rc | MII_LAN83C185_EDPWRDOWN);
-   if (rc < 0)
-   return rc;
+#ifdef CONFIG_OF
+   if (!of_node && dev->parent->of_node)
+   of_node = dev->parent->of_node;


That looks strange, why would the property be placed at the parent level
when this is a PHY device tree node property?


Hmm.. I recheck this.


+   if (of_find_property(of_node, "disable-energy-detect", ))
+   enable_energy = 0;
+#endif
+   if (enable_energy) {
+   /* Enable energy detect mode for this SMSC Transceivers */
+   rc = phy_write(phydev, MII_LAN83C185_CTRL_STATUS,
+  rc | MII_LAN83C185_EDPWRDOWN);
+   if (rc < 0)
+   return rc;
+   }

return smsc_phy_ack_interrupt(phydev);
  }



Thanks for your review.

bye,
Heiko

--
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] mm: skip if required_kernelcore is larger than totalpages

[Tang Chen]

On 10/14/2015 11:28 AM, Xishi Qiu wrote:

On 2015/10/14 10:50, Tang Chen wrote:


Hi, Qiu

The patch seems OK to me. Only one little concern below.

On 10/12/2015 09:37 AM, Xishi Qiu wrote:

On 2015/10/9 23:41, Yasuaki Ishimatsu wrote:


On Thu, 8 Oct 2015 10:21:05 +0800
Xishi Qiu  wrote:


If kernelcore was not specified, or the kernelcore size is zero
(required_movablecore >= totalpages), or the kernelcore size is larger

Why does required_movablecore become larger than totalpages, when the
kernelcore size is zero? I read the code but I could not find that you
mention.


If user only set boot option movablecore, and the value is larger than
totalpages, the calculation of kernelcore is zero, but we can't fill
the zone only with kernelcore, so skip it.

I have send a patch before this patch.
"fix overflow in find_zone_movable_pfns_for_nodes()"
 ...
   required_movablecore =
   roundup(required_movablecore, MAX_ORDER_NR_PAGES);
+required_movablecore = min(totalpages, required_movablecore);
   corepages = totalpages - required_movablecore;
 ...


So if required_movablecore >= totalpages, there won't be any ZONE_MOVABLE.
How about add a warning or debug info to tell the user he has specified a
too large movablecore, and it is ignored ?

Thanks.

Yes, but I don't think is is necessary, user should know the total memory
before he set the boot option.


Well, I'm just thinking if I set a too large movablecore, but I didn't 
realize it.

And when the system boots up, there is no ZONE_MOVABLE. It may confuse me.

Thanks.



Thanks,
Xishi Qiu

.



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: powerpc/mpc5xxx: Use of_get_next_parent to simplify code

[Michael Ellerman]

On Sun, 2015-11-10 at 20:27:40 UTC, Christophe Jaillet wrote:
> of_get_next_parent can be used to simplify the while() loop and
> avoid the need of a temp variable.
> 
> Signed-off-by: Christophe JAILLET 
> ---
>  arch/powerpc/sysdev/mpc5xxx_clocks.c | 5 +
>  1 file changed, 1 insertion(+), 4 deletions(-)
> 
> diff --git a/arch/powerpc/sysdev/mpc5xxx_clocks.c 
> b/arch/powerpc/sysdev/mpc5xxx_clocks.c
> index f4f0301..5732926 100644
> --- a/arch/powerpc/sysdev/mpc5xxx_clocks.c
> +++ b/arch/powerpc/sysdev/mpc5xxx_clocks.c
> @@ -13,7 +13,6 @@
>  
>  unsigned long mpc5xxx_get_bus_frequency(struct device_node *node)
>  {
> - struct device_node *np;
>   const unsigned int *p_bus_freq = NULL;
>  
>   of_node_get(node);
> @@ -22,9 +21,7 @@ unsigned long mpc5xxx_get_bus_frequency(struct device_node 
> *node)
>   if (p_bus_freq)
>   break;
>  
> - np = of_get_parent(node);
> - of_node_put(node);
> - node = np;
> + node = of_get_next_parent(node);
>   }
>   of_node_put(node);


This conversion is OK, but the logic in the function is still wrong.

It uses of_get_property() inside the loop, but then drops the reference to the
node before dereferencing the p_bus_freq pointer, which could by then point to
junk if the node has been freed.

Instead it should use of_property_read_u32() to actually read the property
value before dropping the reference.

cheers
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 3/3] ARM: dts: exynos5422-odroidxu3: Added UHS-I bus speed support

[Anand Moon]

hi Krzysztof,

On 14 October 2015 at 05:29, Krzysztof Kozlowski
 wrote:
> On 14.10.2015 01:27, Anand Moon wrote:
>> Hi Krzysztof,
>>
>> On 13 October 2015 at 09:13, Krzysztof Kozlowski
>>  wrote:
>>>
>>> On 13.10.2015 12:08, Anand Moon wrote:
 Hi Krzysztof,

 On 13 October 2015 at 05:44, Krzysztof Kozlowski
  wrote:
> On 13.10.2015 00:32, Anand Moon wrote:
>> Hi Krzysztof,
>>
>> On 12 October 2015 at 11:14, Krzysztof Kozlowski
>>  wrote:
>>> On 12.10.2015 00:46, Anand Moon wrote:
 Added support for UHS-I bus speed 50MB/s (SDR50, DDR50) 104MB/s 
 (SDR104)
>>>
>>> This description is not entirely correct. The MMC driver already
>>> supports these UHS speeds (you did not any code) so you rather enabled
>>> it (description of bindings says "is supported").
>>>
>>> You mentioned DDR50 but I don't see respective property below.
>>>
>>> How do you know that these modes are really supported? I don't know. Can
>>> you convince me?
>>
>> Setting this DDR50 capability give me this error. That's the reason to
>> drop this capability.
>
> But you mentioned it in commit message! "Added support for UHS-I ...
> (DDR50)"
>
> In the same time dropping DDR50 is not an sufficient proof that "SDR50
> and SDR104 are really supported".
>

 These changes are related to the microSD card capabilities.
 So SDR50 have better frequency over DDR50. On the same Sandisk card.

 When the card select the capability for DDR50
 ---
 [4.001477] mmc_host mmc1: Bus speed (slot 0) = 5000Hz (slot
 req 5000Hz, actual 5000HZ div = 0)
 [4.001604] mmc1: new ultra high speed DDR50 SDHC card at address 
 [4.004505] mmcblk0: mmc1: SL32G 29.7 GiB
 [4.009179] mmcblk0: error -110 sending status command, retrying
 [4.009271] mmcblk0: error -115 sending stop command, original cmd
 response 0x900, card status 0x900
 [4.009275] mmcblk0: error -84 transferring data, sector 0, nr 8,
 cmd response 0x900, card status 0x0
 [4.025563] mmc_host mmc1: Bus speed (slot 0) = 5000Hz (slot
 req 40Hz, actual 396825HZ div = 63)
 [4.067770] Console: switching to colour frame buffer device 274x77
 [4.098782] mmc_host mmc1: Bus speed (slot 0) = 5000Hz (slot
 req 5000Hz, actual 5000HZ div = 0)
 [4.099692] mmc1: tried to reset card
 [4.101332]  mmcblk0: p1 p2


 When the card select the capability for SDR50
 -
 [ 2.439806] mmc_host mmc1: Bus speed (slot 0) = 1Hz (slot req
 1Hz, actual 1HZ div = 0)
 [ 2.449729] mmc1: new ultra high speed SDR50 SDHC card at address 
 [ 2.455984] mmcblk0: mmc1: SL32G 29.7 GiB
 [ 2.461743] mmcblk0: p1 p2

 Which will relate to better read/write speed.
>>>
>>> Which is not an answer to my question. To none of my previous questions.
>>>
>>
>> Basically UHS-I capability  (sd-uhs-sdr12, sd-uhs-sdr25, sd-uhs-sdr50,
>> sd-uhs-sdr104) help tune speed supported for mmc
>>
>> I have tired to compare the speed on high speed UHS-I vs ultra high
>> speed UHS-I using izone utility.
>>
>> [2.572469] mmc_host mmc1: Bus speed (slot 0) = 5000Hz (slot
>> req 5000Hz, actual 5000HZ div = 0)
>> [2.572609] mmc1: new high speed SDHC card at address 
>>
>>   Command line used: ./iozone -L64 -S32 -azecwI -+n -r4k -r64k
>> -r128k -s10M -i0 -i1 -i2 -f datafile -Rb out.xls
>> Output is in kBytes/sec
>> Time Resolution = 0.01 seconds.
>> Processor cache size set to 32 kBytes.
>> Processor cache line size set to 64 bytes.
>> File stride size set to 17 * record size.
>>   random
>>  random bkwdrecordstride
>>   kB  reclenwrite  rewritereadrereadread
>>   write read   rewrite  read   fwrite frewritefread
>> freread
>>10240   4 16310 65560 5538  
>> 982
>>10240  64 8828018897017994  
>> 303
>>10240 128 6269020670020128 
>> 1096
>> -
>> [2.613761] mmc_host mmc1: Bus speed (slot 0) = 1Hz (slot
>> req 1Hz, actual 1HZ div = 0)
>> [2.623573] mmc1: new ultra high speed SDR50 SDHC card at address 
>>
>> Command line used: ./iozone -L64 -S32 -azecwI -+n -r4k -r64k
>> -r128k -s10M -i0 -i1 -i2 -f datafile -Rb out.xls
>> Output is in kBytes/sec
>> Time Resolution = 0.01 seconds.
>> Processor cache 

Re: [PATCH v2] sunrpc: fix waitqueue_active without memory barrier in sunrpc

[Kosuke Tatsukawa]

J. Bruce Fields wrote:
> On Mon, Oct 12, 2015 at 10:41:06AM +, Kosuke Tatsukawa wrote:
>> J. Bruce Fields wrote:
>> > On Fri, Oct 09, 2015 at 06:29:44AM +, Kosuke Tatsukawa wrote:
>> >> Neil Brown wrote:
>> >> > Kosuke Tatsukawa  writes:
>> >> > 
>> >> >> There are several places in net/sunrpc/svcsock.c which calls
>> >> >> waitqueue_active() without calling a memory barrier.  Add a memory
>> >> >> barrier just as in wq_has_sleeper().
>> >> >>
>> >> >> I found this issue when I was looking through the linux source code
>> >> >> for places calling waitqueue_active() before wake_up*(), but without
>> >> >> preceding memory barriers, after sending a patch to fix a similar
>> >> >> issue in drivers/tty/n_tty.c  (Details about the original issue can be
>> >> >> found here: https://lkml.org/lkml/2015/9/28/849).
>> >> > 
>> >> > hi,
>> >> > this feels like the wrong approach to the problem.  It requires extra
>> >> > 'smb_mb's to be spread around which are hard to understand as easy to
>> >> > forget.
>> >> > 
>> >> > A quick look seems to suggest that (nearly) every waitqueue_active()
>> >> > will need an smb_mb.  Could we just put the smb_mb() inside
>> >> > waitqueue_active()??
>> >> 
>> >> 
>> >> There are around 200 occurrences of waitqueue_active() in the kernel
>> >> source, and most of the places which use it before wake_up are either
>> >> protected by some spin lock, or already has a memory barrier or some
>> >> kind of atomic operation before it.
>> >> 
>> >> Simply adding smp_mb() to waitqueue_active() would incur extra cost in
>> >> many cases and won't be a good idea.
>> >> 
>> >> Another way to solve this problem is to remove the waitqueue_active(),
>> >> making the code look like this;
>> >>   if (wq)
>> >>   wake_up_interruptible(wq);
>> >> This also fixes the problem because the spinlock in the wake_up*() acts
>> >> as a memory barrier and prevents the code from being reordered by the
>> >> CPU (and it also makes the resulting code is much simpler).
>> > 
>> > I might not care which we did, except I don't have the means to test
>> > this quickly, and I guess this is some of our most frequently called
>> > code.
>> > 
>> > I suppose your patch is the most conservative approach, as the
>> > alternative is a spinlock/unlock in wake_up_interruptible, which I
>> > assume is necessarily more expensive than an smp_mb().
>> > 
>> > As far as I can tell it's been this way since forever.  (Well, since a
>> > 2002 patch "NFSD: TCP: rationalise locking in RPC server routines" which
>> > removed some spinlocks from the data_ready routines.)
>> > 
>> > I don't understand what the actual race is yet (which code exactly is
>> > missing the wakeup in this case?  nfsd threads seem to instead get
>> > woken up by the wake_up_process() in svc_xprt_do_enqueue().)
>> 
>> Thank you for the reply.  I tried looking into this.
>> 
>> The callbacks in net/sunrpc/svcsock.c are set up in svc_tcp_init() and
>> svc_udp_init(), which are both called from svc_setup_socket().
>> svc_setup_socket() is called (indirectly) from lockd, nfsd, and nfsv4
>> callback port related code.
>> 
>> Maybe I'm wrong, but there might not be any kernel code that is using
>> the socket's wait queue in this case.
> 
> As Trond points out there are probably waiters internal to the
> networking code.

Trond and Bruce, thank you for the comment.  I was able to find the call
to the wait function that was called from nfsd.

sk_stream_wait_connect() and sk_stream_wait_memory() were called from
either do_tcp_sendpages() or tcp_sendmsg() called from within
svc_send().  sk_stream_wait_connect() shouldn't be called at this point,
because the socket has already been used to receive the rpc request.

On the wake_up side, sk_write_space() is called from the following
locations.  The relevant ones seems to be preceded by atomic_sub or a
memory barrier.
+ ksocknal_write_space 
[drivers/staging/lustre/lnet/klnds/socklnd/socklnd_lib.c:633]
+ atm_pop_raw [net/atm/raw.c:40]
+ sock_setsockopt [net/core/sock.c:740]
+ sock_wfree [net/core/sock.c:1630]
  Preceded by atomic_sub in sock_wfree()
+ ccid3_hc_tx_packet_recv [net/dccp/ccids/ccid3.c:442]
+ do_tcp_sendpages [net/ipv4/tcp.c:1008]
+ tcp_sendmsg [net/ipv4/tcp.c:1300]
+ do_tcp_setsockopt [net/ipv4/tcp.c:2597]
+ tcp_new_space [net/ipv4/tcp_input.c:4885]
  Preceded by smp_mb__after_atomic in tcp_check_space()
+ llc_conn_state_process [net/llc/llc_conn.c:148]
+ pipe_rcv_status [net/phonet/pep.c:312]
+ pipe_do_rcv [net/phonet/pep.c:440]
+ pipe_start_flow_control [net/phonet/pep.c:554]
+ svc_sock_setbufsize [net/sunrpc/svcsock.c:45]

sk_state_change() calls related to TCP/IP were called from the following
places.
+ inet_shutdown [net/ipv4/af_inet.c:825]
  This shouldn't be called when waiting
+ tcp_done [net/ipv4/tcp.c:3078]
  spin_lock*/spin_unlock* is called in lock_timer_base
+ tcp_fin [net/ipv4/tcp_input.c:4031]
  atomic_long_sub is called from sk_memory_allocated_sub called within
  sk_mem_reclaim
+ 

Re: [PATCH v2 1/3] unix: fix use-after-free in unix_dgram_poll()

[Jason Baron]

On 10/12/2015 04:41 PM, Rainer Weikusat wrote:
> Jason Baron  writes:
>> On 10/05/2015 12:31 PM, Rainer Weikusat wrote:
> 
> [...]
> 
>>> Here's a more simple idea which _might_ work. The underlying problem
>>> seems to be that the second sock_poll_wait introduces a covert reference
>>> to the peer socket which isn't accounted for. The basic idea behind this
>>> is to execute an additional sock_hold for the peer whenever the
>>> sock_poll_wait is called for it and store it (the struct sock *) in a
>>> new struct unix_sock member.
> 
> [...]
> 
>> Interesting - will this work for the test case you supplied where we are in
>> epoll_wait() and another thread does a connect() to a new target? In that
>> case, even if we issue a wakeup to the epoll thread, its not going to have
>> a non-NULL poll_table, so it wouldn't be added to the new target. IE
>> the first test case here:
>>
>> https://lkml.org/lkml/2015/10/4/154
> 
> "Indeed it would not." I've also meanwhile found the time to check what
> is and isn't locked here and found that Eric's "this looks racy" was
> also justified. In theory, a clean solution could be based on modifying
> the various polling implementations to keep a piece of data for a polled
> something and provided that again on each subsequent poll call. This
> could then be used to keep the peer socket alive for as long as
> necessary were it possible to change the set of wait queues with every
> poll call. Since this also isn't the case, the idea to increment the
> reference count of the peer socket won't fly.
> 
> OTOH, something I seriously dislike about your relaying implementation
> is the unconditional add_wait_queue upon connect as this builds up a
> possibly large wait queue of entities entirely uninterested in the
> event which will need to be traversed even if peer_wait wakeups will
> only happen if at least someone actually wants to be notified. This
> could be changed such that the struct unix_sock member is only put onto
> the peer's wait queue in poll and only if it hasn't already been put
> onto it. The connection could then be severed if some kind of
> 'disconnect' occurs.
> 
> The code below (again based on 3.2.54) is what I'm currently running and
> it has survived testing during the day (without trying the exercise in
> hexadecimal as that doesn't cause failure for me, anyway). The wakeup
> relaying function checks that a socket wait queue actually still exists
> because I used to get null pointers oopses without every now and then
> (I've also tested this with an additional printk printing 'no q' in case
> the pointer was actually null to verify that this really occurs here).
> 

Hi,

What about the following race?

1) thread A does poll() on f, finds the wakeup condition low, and adds
itself to the remote peer_wait queue.

2) thread B sets the wake up condition in dgram_recvmsg(), but does not
execute the wakeup of threads yet.

3) thread C also does a poll() on f, finds now that the wakeup condition
is set, and hence removes f from the remote peer_wait queue.

Then, thread A misses the POLLOUT, and hangs.

I understand your concern about POLLIN only waiters-I think we
could add the 'relay callback' in dgram_poll() only for those who are
looking for POLLOUT, and simply avoid the de-registration, as in practice
I think its unlikely we are going to have a socket switching from
POLLOUT to *only* POLLIN. I suspect that will cover most of the cases
that concern you?

Thanks,

-Jason

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/1] perf:Adding --list-opts to usage string

[Namhyung Kim]

Hi Arnaldo,

On Wed, Oct 14, 2015 at 12:10 PM, Arnaldo Carvalho de Melo
 wrote:
> Em Wed, Oct 14, 2015 at 10:29:05AM +0800, Yunlong Song escreveu:
>> On 2015/10/13 23:24, Ramkumar Ramachandra wrote:
>> > Arnaldo Carvalho de Melo wrote:
>> >> Em Thu, Oct 08, 2015 at 10:59:50AM +0530, Sriram Raghunathan escreveu:
>> >>> Minor change, adding --list-opts to usage string. So that it is
>> >>> visible to the user on running perf --help. or just perf
>> >>> from command line.
>> >>
>> >> Ramkumar, Yunlong, are you ok with this?
>
>> > Not sure I understand the motivation, but I suppose it can't hurt to
>> > show this detail?
>
>> Agree with Ramkumar, --list-opts is redundant due to the existing [OPTIONS] 
>> in
>> the perf_usage_string[].

AFAIK the --list-cmds and --list-opts options are just for completion
scripts, not for human.  I don't think we need to expose them to
normal users.

>
> I see, thinking about it now, it seems that this is because 'perf -h'
> behaves differently from other tools, i.e.:
>
> $ perf -h
>
>  usage: perf [--version] [--help] [OPTIONS] COMMAND [ARGS]
>
>  The most commonly used perf commands are:

One nit, these are not commonly used commands, but all commands. :)
Anyway it'd be better to add option descriptions here for consistency.

>annotateRead perf.data (created by perf record) and display 
> annotated code
>archive Create archive with object files with build-ids found in 
> perf.data file
>bench   General framework for benchmark suites
>buildid-cache   Manage build-id cache.
>buildid-listList the buildids in a perf.data file
> 
>testRuns sanity tests.
>timechart   Tool to visualize total system behavior during a workload
>top System profiling tool.
>trace   strace inspired tool
>probe   Define new dynamic tracepoints
>
>  See 'perf help COMMAND' for more information on a specific command.
>
> --
>
> While:
>
> $ perf stat -h
>
>  usage: perf stat [] []
>
> -T, --transaction hardware transaction statistics
> -e, --eventevent selector. use 'perf list' to list available 
> events
> --filter 
>   event filter
> -i, --no-inherit  child tasks do not inherit counters
> -p, --pidstat events on existing process id
> -t, --tidstat events on existing thread id
> -a, --all-cpussystem-wide collection from all CPUs
> 
> -I, --interval-print 
>   print counts at regular interval in ms (>= 10)
> --per-socket  aggregate counts per processor socket
> --per-coreaggregate counts per physical processor core
> --per-thread  aggregate counts per thread
> -D, --delayms to wait before starting measurement after 
> program start
>
> --
>
> One doesn't show what options can be used, the other does, so there is
> an inconsistency, this and the fact that 'perf -h' outputs to stdout,
> 'perf stat -h' and the other builtins output to stderr. I think all
> should output to stdout, just like 'ls --help', what do you think?

I'm ok with changing to stdout.

Thanks,
Namhyung
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [V4 PATCH 4/4] x86/apic: Introduce noextnmi boot option

[河合英宏 / KAWAI，HIDEHIRO]

> On Fri, 25 Sep 2015, Hidehiro Kawai wrote:
> 
> > This patch introduces new boot option "noextnmi" which disables
> > external NMI.  This option is useful for the dump capture kernel
> > so that an HA application or administrator wouldn't mistakenly
> > shoot down the kernel by NMI.
> >
> > Currently, only x86 supports this option.
> 
> You might add that is can be used for debugging purposes as
> well. External NMIs can be their own source of trouble. :)

Thanks for your comments!  I'll do that.

By the way, I have a pending patch which expands this option like
this:

apic_extnmi={ bsp | all | none }

If apic_extnmi=all is specified, external NMIs are broadcast to
all CPUs.  This raises the successful rate of kernel panic in the case
where an external NMI to CPU 0 is swallowed by other NMI handlers or
blocked due to hang-up in NMI context.  The patch works without any
problems, but I'm going to drop the feature if it will cause long
discussion.  I'd like to settle this patch set down once.  At least,
I'm going to change this option to apic_extnmi={bsp|none} style for
the future expansion.

How do you think about this?

> > Signed-off-by: Hidehiro Kawai 
> > Cc: Thomas Gleixner 
> > Cc: Ingo Molnar 
> > Cc: "H. Peter Anvin" 
> > Cc: Jonathan Corbet 
> > ---
> >  Documentation/kernel-parameters.txt |4 
> >  arch/x86/kernel/apic/apic.c |   17 -
> >  2 files changed, 20 insertions(+), 1 deletion(-)
> >
> > diff --git a/Documentation/kernel-parameters.txt 
> > b/Documentation/kernel-parameters.txt
> > index 22a4b68..8bcaccd 100644
> > --- a/Documentation/kernel-parameters.txt
> > +++ b/Documentation/kernel-parameters.txt
> > @@ -2379,6 +2379,10 @@ bytes respectively. Such letter suffixes can also be 
> > entirely omitted.
> > noexec=on: enable non-executable mappings (default)
> > noexec=off: disable non-executable mappings
> >
> > +   noextnmi[X86]
> > +   Mask external NMI.  This option is useful for a
> > +   dump capture kernel to be shot down by NMI.
> 
> That should read: "...not to be shot down", right?

Yes, you are right.  I'll fix it.

> Other than that.
> 
> Acked-by: Thomas Gleixner 

Regards,

Hidehiro Kawai
Hitachi, Ltd. Research & Development Group

Re: [PATCH] mm: skip if required_kernelcore is larger than totalpages

[Xishi Qiu]

On 2015/10/14 10:50, Tang Chen wrote:

> Hi, Qiu
> 
> The patch seems OK to me. Only one little concern below.
> 
> On 10/12/2015 09:37 AM, Xishi Qiu wrote:
>> On 2015/10/9 23:41, Yasuaki Ishimatsu wrote:
>>
>>> On Thu, 8 Oct 2015 10:21:05 +0800
>>> Xishi Qiu  wrote:
>>>
 If kernelcore was not specified, or the kernelcore size is zero
 (required_movablecore >= totalpages), or the kernelcore size is larger
>>> Why does required_movablecore become larger than totalpages, when the
>>> kernelcore size is zero? I read the code but I could not find that you
>>> mention.
>>>
>> If user only set boot option movablecore, and the value is larger than
>> totalpages, the calculation of kernelcore is zero, but we can't fill
>> the zone only with kernelcore, so skip it.
>>
>> I have send a patch before this patch.
>> "fix overflow in find_zone_movable_pfns_for_nodes()"
>> ...
>>   required_movablecore =
>>   roundup(required_movablecore, MAX_ORDER_NR_PAGES);
>> +required_movablecore = min(totalpages, required_movablecore);
>>   corepages = totalpages - required_movablecore;
>> ...
> 
> 
> So if required_movablecore >= totalpages, there won't be any ZONE_MOVABLE.
> How about add a warning or debug info to tell the user he has specified a
> too large movablecore, and it is ignored ?
> 
> Thanks.

Yes, but I don't think is is necessary, user should know the total memory
before he set the boot option.

Thanks,
Xishi Qiu

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 3/4] blk-mq: check bio_mergeable() early before merging

[Ming Lei]

It isn't necessary to try to merge the bio which is marked
as NOMERGE.

Signed-off-by: Ming Lei 
---
 block/blk-mq.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/block/blk-mq.c b/block/blk-mq.c
index 546b3b8..deb5f4c 100644
--- a/block/blk-mq.c
+++ b/block/blk-mq.c
@@ -671,6 +671,9 @@ static bool blk_mq_attempt_merge(struct request_queue *q,
struct request *rq;
int checked = 8;
 
+   if (!bio_mergeable(bio))
+   return false;
+
list_for_each_entry_reverse(rq, >rq_list, queuelist) {
int el_ret;
 
@@ -1140,7 +1143,7 @@ static inline bool blk_mq_merge_queue_io(struct 
blk_mq_hw_ctx *hctx,
 struct blk_mq_ctx *ctx,
 struct request *rq, struct bio *bio)
 {
-   if (!hctx_allow_merges(hctx)) {
+   if (!hctx_allow_merges(hctx) || !bio_mergeable(bio)) {
blk_mq_bio_to_request(rq, bio);
spin_lock(>lock);
 insert_rq:
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 1/4] block: setup bi_phys_segments after splitting

[Ming Lei]

The number of bio->bi_phys_segments is always obtained
during bio splitting, so it is natural to setup it
just after bio splitting, then we can avoid to compute
nr_segment again during merge.

Signed-off-by: Ming Lei 
---
 block/blk-merge.c | 29 ++---
 1 file changed, 22 insertions(+), 7 deletions(-)

diff --git a/block/blk-merge.c b/block/blk-merge.c
index c4e9c37..22293fd 100644
--- a/block/blk-merge.c
+++ b/block/blk-merge.c
@@ -11,13 +11,16 @@
 
 static struct bio *blk_bio_discard_split(struct request_queue *q,
 struct bio *bio,
-struct bio_set *bs)
+struct bio_set *bs,
+unsigned *nsegs)
 {
unsigned int max_discard_sectors, granularity;
int alignment;
sector_t tmp;
unsigned split_sectors;
 
+   *nsegs = 1;
+
/* Zero-sector (unknown) and one-sector granularities are the same.  */
granularity = max(q->limits.discard_granularity >> 9, 1U);
 
@@ -51,8 +54,11 @@ static struct bio *blk_bio_discard_split(struct 
request_queue *q,
 
 static struct bio *blk_bio_write_same_split(struct request_queue *q,
struct bio *bio,
-   struct bio_set *bs)
+   struct bio_set *bs,
+   unsigned *nsegs)
 {
+   *nsegs = 1;
+
if (!q->limits.max_write_same_sectors)
return NULL;
 
@@ -64,7 +70,8 @@ static struct bio *blk_bio_write_same_split(struct 
request_queue *q,
 
 static struct bio *blk_bio_segment_split(struct request_queue *q,
 struct bio *bio,
-struct bio_set *bs)
+struct bio_set *bs,
+unsigned *segs)
 {
struct bio_vec bv, bvprv, *bvprvp = NULL;
struct bvec_iter iter;
@@ -106,22 +113,30 @@ new_segment:
sectors += bv.bv_len >> 9;
}
 
+   *segs = nsegs;
return NULL;
 split:
+   *segs = nsegs;
return bio_split(bio, sectors, GFP_NOIO, bs);
 }
 
 void blk_queue_split(struct request_queue *q, struct bio **bio,
 struct bio_set *bs)
 {
-   struct bio *split;
+   struct bio *split, *res;
+   unsigned nsegs;
 
if ((*bio)->bi_rw & REQ_DISCARD)
-   split = blk_bio_discard_split(q, *bio, bs);
+   split = blk_bio_discard_split(q, *bio, bs, );
else if ((*bio)->bi_rw & REQ_WRITE_SAME)
-   split = blk_bio_write_same_split(q, *bio, bs);
+   split = blk_bio_write_same_split(q, *bio, bs, );
else
-   split = blk_bio_segment_split(q, *bio, q->bio_split);
+   split = blk_bio_segment_split(q, *bio, q->bio_split, );
+
+   /* physical segments can be figured out during splitting */
+   res = split ? split : *bio;
+   res->bi_phys_segments = nsegs;
+   bio_set_flag(res, BIO_SEG_VALID);
 
if (split) {
bio_chain(split, *bio);
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 2/4] block: avoid to merge splitted bio

[Ming Lei]

The splitted bio has been already too fat to merge, so mark it
as NOMERGE.

Signed-off-by: Ming Lei 
---
 block/blk-merge.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/block/blk-merge.c b/block/blk-merge.c
index 22293fd..de5716d8 100644
--- a/block/blk-merge.c
+++ b/block/blk-merge.c
@@ -139,6 +139,9 @@ void blk_queue_split(struct request_queue *q, struct bio 
**bio,
bio_set_flag(res, BIO_SEG_VALID);
 
if (split) {
+   /* there isn't chance to merge the splitted bio */
+   split->bi_rw |= REQ_NOMERGE;
+
bio_chain(split, *bio);
generic_make_request(*bio);
*bio = split;
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 4/4] blk-mq: mark ctx as pending at batch in flush plug path

[Ming Lei]

Most of times, flush plug should be the hottest I/O path,
so mark ctx as pending after all requests in the list are
inserted.

Signed-off-by: Ming Lei 
---
 block/blk-mq.c | 18 +-
 1 file changed, 13 insertions(+), 5 deletions(-)

diff --git a/block/blk-mq.c b/block/blk-mq.c
index deb5f4c..1c943b9 100644
--- a/block/blk-mq.c
+++ b/block/blk-mq.c
@@ -993,18 +993,25 @@ void blk_mq_delay_queue(struct blk_mq_hw_ctx *hctx, 
unsigned long msecs)
 }
 EXPORT_SYMBOL(blk_mq_delay_queue);
 
-static void __blk_mq_insert_request(struct blk_mq_hw_ctx *hctx,
-   struct request *rq, bool at_head)
+static inline void __blk_mq_insert_req_list(struct blk_mq_hw_ctx *hctx,
+   struct blk_mq_ctx *ctx,
+   struct request *rq,
+   bool at_head)
 {
-   struct blk_mq_ctx *ctx = rq->mq_ctx;
-
trace_block_rq_insert(hctx->queue, rq);
 
if (at_head)
list_add(>queuelist, >rq_list);
else
list_add_tail(>queuelist, >rq_list);
+}
+
+static void __blk_mq_insert_request(struct blk_mq_hw_ctx *hctx,
+   struct request *rq, bool at_head)
+{
+   struct blk_mq_ctx *ctx = rq->mq_ctx;
 
+   __blk_mq_insert_req_list(hctx, ctx, rq, at_head);
blk_mq_hctx_mark_pending(hctx, ctx);
 }
 
@@ -1060,8 +1067,9 @@ static void blk_mq_insert_requests(struct request_queue 
*q,
rq = list_first_entry(list, struct request, queuelist);
list_del_init(>queuelist);
rq->mq_ctx = ctx;
-   __blk_mq_insert_request(hctx, rq, false);
+   __blk_mq_insert_req_list(hctx, ctx, rq, false);
}
+   blk_mq_hctx_mark_pending(hctx, ctx);
spin_unlock(>lock);
 
blk_mq_run_hw_queue(hctx, from_schedule);
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 0/4] block: some misc changes

[Ming Lei]

Hi,

The 1st three patches are optimizations related with bio splitting.

The 4th patch is to mark ctx as pending at batch in flush plug path.

Thanks,

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [patch 2/2] misc: mic/scif: fix wrap around tests

[Sudeep Dutt]

On Fri, 2015-10-09 at 09:40 +0300, Dan Carpenter wrote:
> Signed integer overflow is undefined.  Also I added a check for
> "(offset < 0)" in scif_unregister() because that makes it match the
> other conditions and because I didn't want to subtract a negative.
> 
> Fixes: ba612aa8b487 ('misc: mic: SCIF memory registration and unregistration')
> Signed-off-by: Dan Carpenter 
> ---
> 
> Imagine you are on 64 bit and len is larger than INT_MAX << 12, it means
> that we truncate it because scif_get_window_offset() takes an integer
> argument.  I don't know if this is an issue.  Maybe I should use
> INT_MAX instead of LONG_MAX?  I am working on a static checker warning
> for these types of issues:
> drivers/misc/mic/scif/scif_rma.c:1631 scif_register() warn: truncating user 
> data 'len >> 12' '0-4503599627370495'
> drivers/misc/mic/scif/scif_rma.c:1643 scif_register() warn: truncating user 
> data 'len >> 12' '0-4503599627370495'
> 
> The other static warnings here are:
> 
> drivers/misc/mic/scif/scif_rma.c:745 scif_unregister_window() warn: 
> inconsistent returns 'mutex:>rma_info.rma_lock'.
>   Locked on:   line 745
>   Unlocked on: line 687
> drivers/misc/mic/scif/scif_rma.c:1463 scif_unpin_pages() warn: passing 
> __func__ while the format string already contains the name of the function 
> 'scif_unpin_pages'
> 
> diff --git a/drivers/misc/mic/scif/scif_rma.c 
> b/drivers/misc/mic/scif/scif_rma.c
> index bc2dccb..fea7d2c 100644
> --- a/drivers/misc/mic/scif/scif_rma.c
> +++ b/drivers/misc/mic/scif/scif_rma.c
> @@ -1510,7 +1510,7 @@ off_t scif_register_pinned_pages(scif_epd_t epd,
>   if ((map_flags & SCIF_MAP_FIXED) &&
>   ((ALIGN(offset, PAGE_SIZE) != offset) ||
>   (offset < 0) ||
> - (offset + (off_t)len < offset)))
> + (len > LONG_MAX - offset)))
>   return -EINVAL;
>  
>   might_sleep();
> @@ -1613,7 +1613,7 @@ off_t scif_register(scif_epd_t epd, void *addr, size_t 
> len, off_t offset,
>   if ((map_flags & SCIF_MAP_FIXED) &&
>   ((ALIGN(offset, PAGE_SIZE) != offset) ||
>   (offset < 0) ||
> - (offset + (off_t)len < offset)))
> + (len < LONG_MAX - offset)))

Hi Dan,
Should this be > instead of < like the others?
Thanks,
Sudeep Dutt

>   return -EINVAL;
>  
>   /* Unsupported protection requested */
> @@ -1731,7 +1731,8 @@ scif_unregister(scif_epd_t epd, off_t offset, size_t 
> len)
>  
>   /* Offset is not page aligned or offset+len wraps around */
>   if ((ALIGN(offset, PAGE_SIZE) != offset) ||
> - (offset + (off_t)len < offset))
> + (offset < 0) ||
> + (len > LONG_MAX - offset))
>   return -EINVAL;
>  
>   err = scif_verify_epd(ep);


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 2/5] spi: mediatek: remove mtk_spi_config

[Leilk Liu]

mtk_spi_config() and mtk_spi_prepare_message() both initialize
spi register, so remove mtk_spi_config() and init all register
in mtk_spi_prepare_message().

Signed-off-by: Leilk Liu 
---
 drivers/spi/spi-mt65xx.c | 59 +---
 1 file changed, 26 insertions(+), 33 deletions(-)

diff --git a/drivers/spi/spi-mt65xx.c b/drivers/spi/spi-mt65xx.c
index ecb6c58..7bd84c8 100755
--- a/drivers/spi/spi-mt65xx.c
+++ b/drivers/spi/spi-mt65xx.c
@@ -131,10 +131,34 @@ static void mtk_spi_reset(struct mtk_spi *mdata)
writel(reg_val, mdata->base + SPI_CMD_REG);
 }
 
-static void mtk_spi_config(struct mtk_spi *mdata,
-  struct mtk_chip_config *chip_config)
+static int mtk_spi_prepare_message(struct spi_master *master,
+  struct spi_message *msg)
 {
+   u16 cpha, cpol;
u32 reg_val;
+   struct mtk_chip_config *chip_config;
+   struct spi_device *spi = msg->spi;
+   struct mtk_spi *mdata = spi_master_get_devdata(master);
+
+   cpha = spi->mode & SPI_CPHA ? 1 : 0;
+   cpol = spi->mode & SPI_CPOL ? 1 : 0;
+
+   chip_config = spi->controller_data;
+   if (!chip_config) {
+   chip_config = (void *)_default_chip_info;
+   spi->controller_data = chip_config;
+   }
+
+   reg_val = readl(mdata->base + SPI_CMD_REG);
+   if (cpha)
+   reg_val |= SPI_CMD_CPHA;
+   else
+   reg_val &= ~SPI_CMD_CPHA;
+   if (cpol)
+   reg_val |= SPI_CMD_CPOL;
+   else
+   reg_val &= ~SPI_CMD_CPOL;
+   writel(reg_val, mdata->base + SPI_CMD_REG);
 
reg_val = readl(mdata->base + SPI_CMD_REG);
 
@@ -171,37 +195,6 @@ static void mtk_spi_config(struct mtk_spi *mdata,
/* pad select */
if (mdata->dev_comp->need_pad_sel)
writel(mdata->pad_sel, mdata->base + SPI_PAD_SEL_REG);
-}
-
-static int mtk_spi_prepare_message(struct spi_master *master,
-  struct spi_message *msg)
-{
-   u32 reg_val;
-   u8 cpha, cpol;
-   struct mtk_chip_config *chip_config;
-   struct spi_device *spi = msg->spi;
-   struct mtk_spi *mdata = spi_master_get_devdata(master);
-
-   cpha = spi->mode & SPI_CPHA ? 1 : 0;
-   cpol = spi->mode & SPI_CPOL ? 1 : 0;
-
-   reg_val = readl(mdata->base + SPI_CMD_REG);
-   if (cpha)
-   reg_val |= SPI_CMD_CPHA;
-   else
-   reg_val &= ~SPI_CMD_CPHA;
-   if (cpol)
-   reg_val |= SPI_CMD_CPOL;
-   else
-   reg_val &= ~SPI_CMD_CPOL;
-   writel(reg_val, mdata->base + SPI_CMD_REG);
-
-   chip_config = spi->controller_data;
-   if (!chip_config) {
-   chip_config = (void *)_default_chip_info;
-   spi->controller_data = chip_config;
-   }
-   mtk_spi_config(mdata, chip_config);
 
return 0;
 }
-- 
1.8.1.1.dirty

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 3/5] spi: mediatek: handle controller_data in mtk_spi_setup

[Leilk Liu]

controller_data is related with device, so move to master->setup
function.

Signed-off-by: Leilk Liu 
---
 drivers/spi/spi-mt65xx.c | 19 ---
 1 file changed, 12 insertions(+), 7 deletions(-)

diff --git a/drivers/spi/spi-mt65xx.c b/drivers/spi/spi-mt65xx.c
index 7bd84c8..406695a 100755
--- a/drivers/spi/spi-mt65xx.c
+++ b/drivers/spi/spi-mt65xx.c
@@ -136,19 +136,13 @@ static int mtk_spi_prepare_message(struct spi_master 
*master,
 {
u16 cpha, cpol;
u32 reg_val;
-   struct mtk_chip_config *chip_config;
struct spi_device *spi = msg->spi;
+   struct mtk_chip_config *chip_config = spi->controller_data;
struct mtk_spi *mdata = spi_master_get_devdata(master);
 
cpha = spi->mode & SPI_CPHA ? 1 : 0;
cpol = spi->mode & SPI_CPOL ? 1 : 0;
 
-   chip_config = spi->controller_data;
-   if (!chip_config) {
-   chip_config = (void *)_default_chip_info;
-   spi->controller_data = chip_config;
-   }
-
reg_val = readl(mdata->base + SPI_CMD_REG);
if (cpha)
reg_val |= SPI_CMD_CPHA;
@@ -406,6 +400,16 @@ static bool mtk_spi_can_dma(struct spi_master *master,
return xfer->len > MTK_SPI_MAX_FIFO_SIZE;
 }
 
+static int mtk_spi_setup(struct spi_device *spi)
+{
+   struct mtk_spi *mdata = spi_master_get_devdata(spi->master);
+
+   if (!spi->controller_data)
+   spi->controller_data = (void *)_default_chip_info;
+
+   return 0;
+}
+
 static irqreturn_t mtk_spi_interrupt(int irq, void *dev_id)
 {
u32 cmd, reg_val, cnt;
@@ -493,6 +497,7 @@ static int mtk_spi_probe(struct platform_device *pdev)
master->prepare_message = mtk_spi_prepare_message;
master->transfer_one = mtk_spi_transfer_one;
master->can_dma = mtk_spi_can_dma;
+   master->setup = mtk_spi_setup;
 
of_id = of_match_node(mtk_spi_of_match, pdev->dev.of_node);
if (!of_id) {
-- 
1.8.1.1.dirty

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 5/5] arm64: dts: spi bus dts support multiple devices

[Leilk Liu]

This patch support multiple devices for MT8173.

Signed-off-by: Leilk Liu 
---
 arch/arm64/boot/dts/mediatek/mt8173-evb.dts | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/mediatek/mt8173-evb.dts 
b/arch/arm64/boot/dts/mediatek/mt8173-evb.dts
index 04b38ed..1c8c407 100644
--- a/arch/arm64/boot/dts/mediatek/mt8173-evb.dts
+++ b/arch/arm64/boot/dts/mediatek/mt8173-evb.dts
@@ -194,7 +194,7 @@
pinmux = ,
,
,
-   ;
+   ;
};
};
 };
@@ -399,6 +399,7 @@
  {
pinctrl-names = "default";
pinctrl-0 = <_pins_a>;
+   cs-gpios = < 72 0>;
mediatek,pad-select = <0>;
status = "okay";
 };
-- 
1.8.1.1.dirty

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 0/5] mt8173 spi multiple devices support

[Leilk Liu]

This series are based on 4.3-rc1 and provide 5 patches to support
mt8173 spi multiple devices.

Change in this series:
1. update document to add cs-gpio;
2. remove mtk_spi_config function;
3. move controller_data to master->setup;
4. add mt8173 spi multiple devices support;
5. update dts to add cs-gpio and modify cs pin to gpio function.

Leilk Liu (5):
  dt-binding: spi: Mediatek: Update document devicetree bindings to
support multiple devices
  spi: mediatek: remove mtk_spi_config
  spi: mediatek: handle controller_data in mtk_spi_setup
  spi: mediatek: mt8173 spi multiple devices support
  arm64: dts: spi bus dts support multiple devices

 .../devicetree/bindings/spi/spi-mt65xx.txt |   8 +-
 arch/arm64/boot/dts/mediatek/mt8173-evb.dts|   3 +-
 drivers/spi/spi-mt65xx.c   | 129 +
 3 files changed, 91 insertions(+), 49 deletions(-)
 mode change 100755 => 100644 drivers/spi/spi-mt65xx.c

--
1.8.1.1.dirty

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 1/5] dt-binding: spi: Mediatek: Update document devicetree bindings to support multiple devices

[Leilk Liu]

This patch update document devicetree bindings to
support multiple devices.

Signed-off-by: Leilk Liu 
---
 Documentation/devicetree/bindings/spi/spi-mt65xx.txt | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/spi/spi-mt65xx.txt 
b/Documentation/devicetree/bindings/spi/spi-mt65xx.txt
index dcefc43..8391193 100644
--- a/Documentation/devicetree/bindings/spi/spi-mt65xx.txt
+++ b/Documentation/devicetree/bindings/spi/spi-mt65xx.txt
@@ -28,8 +28,11 @@ Required properties:
   "parent-clk" for the parent clock.
 
 Optional properties:
+-cs-gpios: see spi-bus.txt, only required for MT8173.
+
 - mediatek,pad-select: specify which pins group(ck/mi/mo/cs) spi
-  controller used, this value should be 0~3, only required for MT8173.
+  controller used. This is a array, the element value should be 0~3,
+  only required for MT8173.
 0: specify GPIO69,70,71,72 for spi pins.
 1: specify GPIO102,103,104,105 for spi pins.
 2: specify GPIO128,129,130,131 for spi pins.
@@ -46,6 +49,7 @@ spi: spi@1100a000 {
interrupts = ;
clocks = < CLK_TOP_SPI_SEL>, < CLK_TOP_SYSPLL3_D2>;
clock-names = "spi-clk", "parent-clk";
-   mediatek,pad-select = <0>;
+   cs-gpios = < 105 GPIO_ACTIVE_LOW>, < 72 GPIO_ACTIVE_LOW>;
+   mediatek,pad-select = <1>, <0>;
status = "disabled";
 };
-- 
1.8.1.1.dirty

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 4/5] spi: mediatek: mt8173 spi multiple devices support

[Leilk Liu]

mt8173 IC spi HW has 4 gpio group, it's possible to support
max <= 4 slave devices, even mtk spi HW is not congruent to spi core.
1. When a device do a spi_message transfer, spi HW should know
   which pad-group this device is on, and then writes pad-select
   register.
2. Mtk pad-select register just selects which MISO pin HW will
   receive data. For example, pad-select=1(select spi1 pins), HW just
   receives data from spi1 MISO, but it still send waveform to all 4
   group cs/clk/mosi. If cs pin in other groups is still spi mode,
   after spi1 is selected(by active cs pin), devices on other group
   will also be selected.

Signed-off-by: Leilk Liu 
---
 drivers/spi/spi-mt65xx.c | 65 ++--
 1 file changed, 52 insertions(+), 13 deletions(-)
 mode change 100755 => 100644 drivers/spi/spi-mt65xx.c

diff --git a/drivers/spi/spi-mt65xx.c b/drivers/spi/spi-mt65xx.c
old mode 100755
new mode 100644
index 406695a..563954a
--- a/drivers/spi/spi-mt65xx.c
+++ b/drivers/spi/spi-mt65xx.c
@@ -20,6 +20,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -84,7 +85,8 @@ struct mtk_spi_compatible {
 struct mtk_spi {
void __iomem *base;
u32 state;
-   u32 pad_sel;
+   int pad_num;
+   u32 *pad_sel;
struct clk *parent_clk, *sel_clk, *spi_clk;
struct spi_transfer *cur_transfer;
u32 xfer_len;
@@ -188,7 +190,8 @@ static int mtk_spi_prepare_message(struct spi_master 
*master,
 
/* pad select */
if (mdata->dev_comp->need_pad_sel)
-   writel(mdata->pad_sel, mdata->base + SPI_PAD_SEL_REG);
+   writel(mdata->pad_sel[spi->chip_select],
+  mdata->base + SPI_PAD_SEL_REG);
 
return 0;
 }
@@ -407,6 +410,9 @@ static int mtk_spi_setup(struct spi_device *spi)
if (!spi->controller_data)
spi->controller_data = (void *)_default_chip_info;
 
+   if (mdata->dev_comp->need_pad_sel)
+   gpio_direction_output(spi->cs_gpio, !(spi->mode & SPI_CS_HIGH));
+
return 0;
 }
 
@@ -481,7 +487,7 @@ static int mtk_spi_probe(struct platform_device *pdev)
struct mtk_spi *mdata;
const struct of_device_id *of_id;
struct resource *res;
-   int irq, ret;
+   int i, irq, ret;
 
master = spi_alloc_master(>dev, sizeof(*mdata));
if (!master) {
@@ -512,21 +518,34 @@ static int mtk_spi_probe(struct platform_device *pdev)
master->flags = SPI_MASTER_MUST_TX;
 
if (mdata->dev_comp->need_pad_sel) {
-   ret = of_property_read_u32(pdev->dev.of_node,
-  "mediatek,pad-select",
-  >pad_sel);
-   if (ret) {
-   dev_err(>dev, "failed to read pad select: %d\n",
-   ret);
+   mdata->pad_num = of_property_count_u32_elems(
+   pdev->dev.of_node,
+   "mediatek,pad-select");
+   if (mdata->pad_num < 0) {
+   dev_err(>dev,
+   "No 'mediatek,pad-select' property\n");
+   ret = -EINVAL;
goto err_put_master;
}
 
-   if (mdata->pad_sel > MT8173_SPI_MAX_PAD_SEL) {
-   dev_err(>dev, "wrong pad-select: %u\n",
-   mdata->pad_sel);
-   ret = -EINVAL;
+   mdata->pad_sel = devm_kmalloc_array(>dev, mdata->pad_num,
+   sizeof(u32), GFP_KERNEL);
+   if (!mdata->pad_sel) {
+   ret = -ENOMEM;
goto err_put_master;
}
+
+   for (i = 0; i < mdata->pad_num; i++) {
+   of_property_read_u32_index(pdev->dev.of_node,
+  "mediatek,pad-select",
+  i, >pad_sel[i]);
+   if (mdata->pad_sel[i] > MT8173_SPI_MAX_PAD_SEL) {
+   dev_err(>dev, "wrong pad-sel[%d]: %u\n",
+   i, mdata->pad_sel[i]);
+   ret = -EINVAL;
+   goto err_put_master;
+   }
+   }
}
 
platform_set_drvdata(pdev, master);
@@ -604,6 +623,26 @@ static int mtk_spi_probe(struct platform_device *pdev)
goto err_put_master;
}
 
+   if (mdata->dev_comp->need_pad_sel) {
+   if (mdata->pad_num != master->num_chipselect) {
+   dev_err(>dev,
+   "pad_num does not match num_chipselect(%d != 
%d)\n",
+   mdata->pad_num, master->num_chipselect);
+   ret = -EINVAL;
+   

RE: v4.3-rc4: i915: ThinkPad Yoga 12: *ERROR* The master control interrupt lied (SDE)! [regression]

[Miramontes Caton, Jairo Daniel]

Created bug in fdo bugzilla to keep track of this regression: 
https://bugs.freedesktop.org/show_bug.cgi?id=92454
Regards

-Original Message-
From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel Vetter
Sent: Monday, October 12, 2015 2:06 AM
To: Darren Hart
Cc: Linux Kernel Mailing List; Vetter, Daniel; Daniel Vetter; Jani Nikula; 
David Airlie; intel-...@lists.freedesktop.org; dri-de...@lists.freedesktop.org; 
Miramontes Caton, Jairo Daniel
Subject: Re: v4.3-rc4: i915: ThinkPad Yoga 12: *ERROR* The master control 
interrupt lied (SDE)! [regression]

Another regression for Jairo to track.
-Daniel

On Sat, Oct 10, 2015 at 12:08:43PM -0700, Darren Hart wrote:
> The Debian 3.16.0 kernel does not emit the error, but I have not 
> attempted a bisection.
> 
> The warning was added by:
> 38cc46d drm/i915/bdw: Ack interrupts before handling them (GEN8)
>  2014-06-18 (1 year, 4 months ago), Oscar Mateo 
> 
> 
> Follows: v3.15-rc8
> Preceedes: 3.17-rc1
> 
> This is not present in v3.16, so perhaps not present in the Debian 
> kernel and this is not a regression, but just reporting the condition as 
> intended.
> 
> Linux Version: v4.3-rc4
> Platform: Lenovo ThinkPad Yoga 12
> OS: Debian 8.2
> 
> $ dmesg | grep -i drm
> [   10.918367] [drm] Initialized drm 1.1.0 20060810
> [   11.235005] [drm] Memory usable by graphics device = 4096M
> [   11.235009] fb: switching to inteldrmfb from simple
> [   11.235093] [drm] Replacing VGA console driver
> [   11.241160] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
> [   11.241162] [drm] Driver supports precise vblank timestamp query.
> [   11.256249] [drm:drm_calc_timestamping_constants [drm]] *ERROR* crtc 21: 
> Can't calculate constants, dotclock = 0!
> [   11.326946] [drm] GMBUS [i915 gmbus dpb] timed out, falling back to bit 
> banging on pin 5
> [   11.344097] [drm] Initialized i915 1.6.0 20150731 for :00:02.0 on 
> minor 0
> [   11.344913] fbcon: inteldrmfb (fb0) is primary device
> [   12.462509] [drm:gen8_irq_handler [i915]] *ERROR* The master control 
> interrupt lied (SDE)!
> [   12.466498] i915 :00:02.0: fb0: inteldrmfb frame buffer device
> [   12.794359] [drm:gen8_irq_handler [i915]] *ERROR* The master control 
> interrupt lied (SDE)!
> [   13.869733] [drm:gen8_irq_handler [i915]] *ERROR* The master control 
> interrupt lied (SDE)!
> [   13.869894] [drm:gen8_irq_handler [i915]] *ERROR* The master control 
> interrupt lied (SDE)!
> [   13.870058] [drm:gen8_irq_handler [i915]] *ERROR* The master control 
> interrupt lied (SDE)!
> [   22.656986] [drm:gen8_irq_handler [i915]] *ERROR* The master control 
> interrupt lied (SDE)!
> [  257.506246] [drm:gen8_irq_handler [i915]] *ERROR* The master control 
> interrupt lied (SDE)!
> [  257.506415] [drm:gen8_irq_handler [i915]] *ERROR* The master control 
> interrupt lied (SDE)!
> [  257.506584] [drm:gen8_irq_handler [i915]] *ERROR* The master control 
> interrupt lied (SDE)!
> [  257.506746] [drm:gen8_irq_handler [i915]] *ERROR* The master control 
> interrupt lied (SDE)!
> [  278.722570] [drm:gen8_irq_handler [i915]] *ERROR* The master control 
> interrupt lied (SDE)!
> [  278.722744] [drm:gen8_irq_handler [i915]] *ERROR* The master control 
> interrupt lied (SDE)!
> [  278.722908] [drm:gen8_irq_handler [i915]] *ERROR* The master control 
> interrupt lied (SDE)!
> [ 1857.776390] [drm:gen8_irq_handler [i915]] *ERROR* The master control 
> interrupt lied (SDE)!
> [ 1857.776549] [drm:gen8_irq_handler [i915]] *ERROR* The master control 
> interrupt lied (SDE)!
> [ 1857.776710] [drm:gen8_irq_handler [i915]] *ERROR* The master control 
> interrupt lied (SDE)!
> [ 4057.592685] [drm:gen8_irq_handler [i915]] *ERROR* The master control 
> interrupt lied (SDE)!
> 
> --
> Darren Hart
> Intel Open Source Technology Center

--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/1] perf:Adding --list-opts to usage string

[Arnaldo Carvalho de Melo]

Em Wed, Oct 14, 2015 at 10:29:05AM +0800, Yunlong Song escreveu:
> On 2015/10/13 23:24, Ramkumar Ramachandra wrote:
> > Arnaldo Carvalho de Melo wrote:
> >> Em Thu, Oct 08, 2015 at 10:59:50AM +0530, Sriram Raghunathan escreveu:
> >>> Minor change, adding --list-opts to usage string. So that it is
> >>> visible to the user on running perf --help. or just perf
> >>> from command line.
> >>
> >> Ramkumar, Yunlong, are you ok with this?

> > Not sure I understand the motivation, but I suppose it can't hurt to
> > show this detail?

> Agree with Ramkumar, --list-opts is redundant due to the existing [OPTIONS] in
> the perf_usage_string[].

I see, thinking about it now, it seems that this is because 'perf -h'
behaves differently from other tools, i.e.:

$ perf -h

 usage: perf [--version] [--help] [OPTIONS] COMMAND [ARGS]

 The most commonly used perf commands are:
   annotateRead perf.data (created by perf record) and display 
annotated code
   archive Create archive with object files with build-ids found in 
perf.data file
   bench   General framework for benchmark suites
   buildid-cache   Manage build-id cache.
   buildid-listList the buildids in a perf.data file

   testRuns sanity tests.
   timechart   Tool to visualize total system behavior during a workload
   top System profiling tool.
   trace   strace inspired tool
   probe   Define new dynamic tracepoints

 See 'perf help COMMAND' for more information on a specific command.

--

While:

$ perf stat -h

 usage: perf stat [] []

-T, --transaction hardware transaction statistics
-e, --eventevent selector. use 'perf list' to list available 
events
--filter 
  event filter
-i, --no-inherit  child tasks do not inherit counters
-p, --pidstat events on existing process id
-t, --tidstat events on existing thread id
-a, --all-cpussystem-wide collection from all CPUs

-I, --interval-print 
  print counts at regular interval in ms (>= 10)
--per-socket  aggregate counts per processor socket
--per-coreaggregate counts per physical processor core
--per-thread  aggregate counts per thread
-D, --delayms to wait before starting measurement after program 
start

--

One doesn't show what options can be used, the other does, so there is
an inconsistency, this and the fact that 'perf -h' outputs to stdout,
'perf stat -h' and the other builtins output to stderr. I think all
should output to stdout, just like 'ls --help', what do you think?

- Arnaldo
 
> >>>
> >>>  const char perf_usage_string[] =
> >>> - "perf [--version] [--help] [OPTIONS] COMMAND [ARGS]";
> >>> + "perf [--version] [--help] [--list-opts] [OPTIONS] COMMAND [ARGS]";
> 
> -- 
> Thanks,
> Yunlong Song
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RESEND PATCH 1/1] mm: vmstat: Add OOM victims count in vmstat counter

[David Rientjes]

On Mon, 12 Oct 2015, Pintu Kumar wrote:

> This patch maintains the number of oom victims kill count in
> /proc/vmstat.
> Currently, we are dependent upon kernel logs when the kernel OOM occurs.
> But kernel OOM can went passed unnoticed by the developer as it can
> silently kill some background applications/services.
> In some small embedded system, it might be possible that OOM is captured
> in the logs but it was over-written due to ring-buffer.
> Thus this interface can quickly help the user in analyzing, whether there
> were any OOM kill happened in the past, or whether the system have ever
> entered the oom kill stage till date.
> 
> Thus, it can be beneficial under following cases:
> 1. User can monitor kernel oom kill scenario without looking into the
>kernel logs.

I'm not sure how helpful that would be since we don't know anything about 
the oom kill itself, only that at some point during the uptime there were 
oom kills.

> 2. It can help in tuning the watermark level in the system.

I disagree with this one, because we can encounter oom kills due to 
fragmentation rather than low memory conditions for high-order 
allocations.  The amount of free memory may be substantially higher than 
all zone watermarks.

> 3. It can help in tuning the low memory killer behavior in user space.

Same reason as above.

> 4. It can be helpful on a logless system or if klogd logging
>(/var/log/messages) are disabled.
> 

This would be similar to point (1) above, and I question how helpful it 
would be.  I notice that all oom kills (system, cpuset, mempolicy, and 
memcg) are treated equally in this case and there's no way to 
differentiate them.  That would lead me to believe that you are targeting 
this change for systems that don't use mempolicies or cgroups.  That's 
fine, but I doubt it will be helpful for anybody else.

> A snapshot of the result of 3 days of over night test is shown below:
> System: ARM Cortex A7, 1GB RAM, 8GB EMMC
> Linux: 3.10.xx
> Category: reference smart phone device
> Loglevel: 7
> Conditions: Fully loaded, BT/WiFi/GPS ON
> Tests: auto launching of ~30+ apps using test scripts, in a loop for
> 3 days.
> At the end of tests, check:
> $ cat /proc/vmstat
> nr_oom_victims 6
> 
> As we noticed, there were around 6 oom kill victims.
> 
> The OOM is bad for any system. So, this counter can help in quickly
> tuning the OOM behavior of the system, without depending on the logs.
> 

NACK to the patch since it isn't justified.

We've long had a desire to have a better oom reporting mechanism rather 
than just the kernel log.  It seems like you're feeling the same pain.  I 
think it would be better to have an eventfd notifier for system oom 
conditions so we can track kernel oom kills (and conditions) in 
userspace.  I have a patch for that, and it works quite well when 
userspace is mlocked with a buffer in memory.

If you are only interested in a strict count of system oom kills, this 
could then easily be implemented without adding vmstat counters.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] ARM: dts: at91: sama5d2_xplained: add regulator nodes

[Wenyou Yang]

Add regulator nodes of PMIC ACT8945A chip on the board.

Signed-off-by: Wenyou Yang 
---

 arch/arm/boot/dts/at91-sama5d2_xplained.dts |   57 +++
 1 file changed, 57 insertions(+)

diff --git a/arch/arm/boot/dts/at91-sama5d2_xplained.dts 
b/arch/arm/boot/dts/at91-sama5d2_xplained.dts
index dc23979..e07c2b2 100644
--- a/arch/arm/boot/dts/at91-sama5d2_xplained.dts
+++ b/arch/arm/boot/dts/at91-sama5d2_xplained.dts
@@ -122,6 +122,63 @@
pinctrl-names = "default";
pinctrl-0 = <_i2c0_default>;
status = "okay";
+
+   pmic: act8865@5b {
+   compatible = "active-semi,act8865";
+   reg = <0x5b>;
+   active-semi,vsel-high;
+   status = "okay";
+
+   regulators {
+   vdd_1v35_reg: DCDC_REG1 {
+   regulator-name = 
"VDD_1V35";
+   regulator-min-microvolt 
= <135>;
+   regulator-max-microvolt 
= <135>;
+   regulator-always-on;
+   };
+
+   vdd_1v2_reg: DCDC_REG2 {
+   regulator-name = 
"VDD_1V2";
+   regulator-min-microvolt 
= <110>;
+   regulator-max-microvolt 
= <130>;
+   regulator-always-on;
+   };
+
+   vdd_3v3_reg: DCDC_REG3 {
+   regulator-name = 
"VDD_3V3";
+   regulator-min-microvolt 
= <330>;
+   regulator-max-microvolt 
= <330>;
+   regulator-always-on;
+   };
+
+   vdd_fuse_reg: LDO_REG1 {
+   regulator-name = 
"VDD_FUSE";
+   regulator-min-microvolt 
= <250>;
+   regulator-max-microvolt 
= <250>;
+   regulator-always-on;
+   };
+
+   vdd_3v3_lp_reg: LDO_REG2 {
+   regulator-name = 
"VDD_3V3_LP";
+   regulator-min-microvolt 
= <330>;
+   regulator-max-microvolt 
= <330>;
+   regulator-always-on;
+   };
+
+   vdd_led_reg: LDO_REG3 {
+   regulator-name = 
"VDD_LED";
+   regulator-min-microvolt 
= <330>;
+   regulator-max-microvolt 
= <330>;
+   regulator-always-on;
+   };
+
+   vdd_sdhc_1v8_reg: LDO_REG4 {
+   regulator-name = 
"VDD_SDHC_1V8";
+   regulator-min-microvolt 
= <180>;
+   regulator-max-microvolt 
= <180>;
+   };
+   };
+   };
};
 
uart3: serial@fc008000 {
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v9 5/6] Documentation: dt-bindings: pci: altera pcie device tree binding

[Ley Foon Tan]

This patch adds the bindings for Altera PCIe host controller driver and
Altera PCIe MSI driver.

Signed-off-by: Ley Foon Tan 
---
 .../devicetree/bindings/pci/altera-pcie-msi.txt| 28 +
 .../devicetree/bindings/pci/altera-pcie.txt| 49 ++
 2 files changed, 77 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/pci/altera-pcie-msi.txt
 create mode 100644 Documentation/devicetree/bindings/pci/altera-pcie.txt

diff --git a/Documentation/devicetree/bindings/pci/altera-pcie-msi.txt 
b/Documentation/devicetree/bindings/pci/altera-pcie-msi.txt
new file mode 100644
index 000..09cd3bc
--- /dev/null
+++ b/Documentation/devicetree/bindings/pci/altera-pcie-msi.txt
@@ -0,0 +1,28 @@
+* Altera PCIe MSI controller
+
+Required properties:
+- compatible:  should contain "altr,msi-1.0"
+- reg: specifies the physical base address of the controller and
+   the length of the memory mapped region.
+- reg-names:   must include the following entries:
+   "csr": CSR registers
+   "vector_slave": vectors slave port region
+- interrupt-parent:interrupt source phandle.
+- interrupts:  specifies the interrupt source of the parent interrupt
+   controller. The format of the interrupt specifier depends on the
+   parent interrupt controller.
+- num-vectors: number of vectors, range 1 to 32.
+- msi-controller:  indicates that this is MSI controller node
+
+
+Example
+msi0: msi@0xFF20 {
+   compatible = "altr,msi-1.0";
+   reg = <0xFF20 0x0010
+   0xFF200010 0x0080>;
+   reg-names = "csr", "vector_slave";
+   interrupt-parent = <_0_arm_gic_0>;
+   interrupts = <0 42 4>;
+   msi-controller;
+   num-vectors = <32>;
+};
diff --git a/Documentation/devicetree/bindings/pci/altera-pcie.txt 
b/Documentation/devicetree/bindings/pci/altera-pcie.txt
new file mode 100644
index 000..2951a6a
--- /dev/null
+++ b/Documentation/devicetree/bindings/pci/altera-pcie.txt
@@ -0,0 +1,49 @@
+* Altera PCIe controller
+
+Required properties:
+- compatible : should contain "altr,pcie-root-port-1.0"
+- reg: a list of physical base address and length for TXS and CRA.
+- reg-names:   must include the following entries:
+   "Txs": TX slave port region
+   "Cra": Control register access region
+- interrupt-parent:interrupt source phandle.
+- interrupts:  specifies the interrupt source of the parent interrupt 
controller.
+   The format of the interrupt specifier depends on the parent 
interrupt
+   controller.
+- device_type: must be "pci"
+- #address-cells:  set to <3>
+- #size-cells: set to <2>
+- #interrupt-cells:set to <1>
+- ranges:  describes the translation of addresses for root ports 
and standard
+   PCI regions.
+- interrupt-map-mask and interrupt-map: standard PCI properties to define the
+   mapping of the PCIe interface to interrupt numbers.
+
+Optional properties:
+- msi-parent:  Link to the hardware entity that serves as the MSI controller 
for this PCIe
+   controller.
+- bus-range:   PCI bus numbers covered
+
+Example
+   pcie_0: pcie@0xc {
+   compatible = "altr,pcie-root-port-1.0";
+   reg = <0xc000 0x2000>,
+   <0xff22 0x4000>;
+   reg-names = "Txs", "Cra";
+   interrupt-parent = <_0_arm_gic_0>;
+   interrupts = <0 40 4>;
+   interrupt-controller;
+   #interrupt-cells = <1>;
+   bus-range = <0x0 0xFF>;
+   device_type = "pci";
+   msi-parent = <_to_gic_gen_0>;
+   #address-cells = <3>;
+   #size-cells = <2>;
+   interrupt-map-mask = <0 0 0 7>;
+   interrupt-map = <0 0 0 1 _0 1>,
+   <0 0 0 2 _0 2>,
+   <0 0 0 3 _0 3>,
+   <0 0 0 4 _0 4>;
+   ranges = <0x8200 0x 0x 0xc000 
0x 0x1000
+   0x8200 0x 0x1000 0xd000 
0x 0x1000>;
+   };
-- 
1.8.2.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v9 1/6] arm: add msi.h to Kbuild

[Ley Foon Tan]

Include asm-generic/msi.h to support CONFIG_GENERIC_MSI_IRQ_DOMAIN.
This to fix compilation error:
"include/linux/msi.h:123:21: fatal error: asm/msi.h:
No such file or directory"

Signed-off-by: Ley Foon Tan 
---
 arch/arm/include/asm/Kbuild | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/include/asm/Kbuild b/arch/arm/include/asm/Kbuild
index be648eb..bd42530 100644
--- a/arch/arm/include/asm/Kbuild
+++ b/arch/arm/include/asm/Kbuild
@@ -14,6 +14,7 @@ generic-y += local.h
 generic-y += local64.h
 generic-y += mm-arch-hooks.h
 generic-y += msgbuf.h
+generic-y += msi.h
 generic-y += param.h
 generic-y += parport.h
 generic-y += poll.h
-- 
1.8.2.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] mm: skip if required_kernelcore is larger than totalpages

[Tang Chen]

Hi, Qiu

The patch seems OK to me. Only one little concern below.

On 10/12/2015 09:37 AM, Xishi Qiu wrote:

On 2015/10/9 23:41, Yasuaki Ishimatsu wrote:


On Thu, 8 Oct 2015 10:21:05 +0800
Xishi Qiu  wrote:


If kernelcore was not specified, or the kernelcore size is zero
(required_movablecore >= totalpages), or the kernelcore size is larger

Why does required_movablecore become larger than totalpages, when the
kernelcore size is zero? I read the code but I could not find that you
mention.


If user only set boot option movablecore, and the value is larger than
totalpages, the calculation of kernelcore is zero, but we can't fill
the zone only with kernelcore, so skip it.

I have send a patch before this patch.
"fix overflow in find_zone_movable_pfns_for_nodes()"
...
required_movablecore =
roundup(required_movablecore, MAX_ORDER_NR_PAGES);
+   required_movablecore = min(totalpages, required_movablecore);
corepages = totalpages - required_movablecore;
...



So if required_movablecore >= totalpages, there won't be any ZONE_MOVABLE.
How about add a warning or debug info to tell the user he has specified a
too large movablecore, and it is ignored ?

Thanks.




Thanks,
Xishi Qiu


Thanks,
Yasuaki Ishimatsu


than totalpages, there is no ZONE_MOVABLE. We should fill the zone
with both kernel memory and movable memory.

Signed-off-by: Xishi Qiu 
---
  mm/page_alloc.c | 7 +--
  1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index af3c9bd..6a6da0d 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -5674,8 +5674,11 @@ static void __init find_zone_movable_pfns_for_nodes(void)
required_kernelcore = max(required_kernelcore, corepages);
}
  
-	/* If kernelcore was not specified, there is no ZONE_MOVABLE */

-   if (!required_kernelcore)
+   /*
+* If kernelcore was not specified or kernelcore size is larger
+* than totalpages, there is no ZONE_MOVABLE.
+*/
+   if (!required_kernelcore || required_kernelcore >= totalpages)
goto out;
  
  	/* usable_startpfn is the lowest possible pfn ZONE_MOVABLE can be at */

--
2.0.0


--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majord...@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: mailto:"d...@kvack.org;> em...@kvack.org 

.




.



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2/3] dts: Updated devicetree bindings for Zynq 7000 platform

[Moritz Fischer]

Hi Michal,

On Mon, Oct 12, 2015 at 2:32 AM, Michal Simek  wrote:
> On 10/09/2015 12:45 AM, Moritz Fischer wrote:
>> Added addtional bindings required for FPGA Manager operation
>> of the Xilinx Zynq Devc configuration interface.
>>
>> Signed-off-by: Moritz Fischer 
>> ---
>>  arch/arm/boot/dts/zynq-7000.dtsi | 5 +
>>  1 file changed, 5 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/zynq-7000.dtsi 
>> b/arch/arm/boot/dts/zynq-7000.dtsi
>> index dc0457e..1a5220e 100644
>> --- a/arch/arm/boot/dts/zynq-7000.dtsi
>> +++ b/arch/arm/boot/dts/zynq-7000.dtsi
>> @@ -294,6 +294,11 @@
>>   devcfg: devcfg@f8007000 {
>>   compatible = "xlnx,zynq-devcfg-1.0";
>>   reg = <0xf8007000 0x100>;
>> + interrupt-parent = <>;
>> + interrupts = <0 8 4>;
>> + clocks = < 12>;
>> + clock-names = "ref_clk";
>> + syscon = <>;
>>   };
>>
>>   global_timer: timer@f8f00200 {
>>
>
> This patch should go via arm-soc tree. That's why please remove it from
> this patchset.

Just to clarify, you want this as a separate patch?

>
> Thanks,
> Michal

Cheers,

Moritz
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] ARM: SWP emulation: Restore original *data when failed

[Shengjiu Wang]

__user_swpX_asm maybe failed in first STREX operation, emulate_swpX
will try again, but the *data has been changed in first time. which
cause the result is wrong. So need to recover the *data when failed.

Signed-off-by: Shengjiu Wang 
---
 arch/arm/kernel/swp_emulate.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/kernel/swp_emulate.c b/arch/arm/kernel/swp_emulate.c
index 5b26e7e..c61fbf92 100644
--- a/arch/arm/kernel/swp_emulate.c
+++ b/arch/arm/kernel/swp_emulate.c
@@ -41,6 +41,7 @@
"1: strex"B"%0, %2, [%3]\n" \
"   cmp %0, #0\n"   \
"   movne   %0, %4\n"   \
+   "   movne   %1, %2\n"   \
"2:\n"  \
"   .section .text.fixup,\"ax\"\n"  \
"   .align  2\n"\
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] pstore: add a helper function pstore_register_kmsg

[Geliang Tang]

Add a new wraper function pstore_register_kmsg to keep the
consistency with the other similar pstore_register_* functions.

Signed-off-by: Geliang Tang 
---
 fs/pstore/platform.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/fs/pstore/platform.c b/fs/pstore/platform.c
index 791743d..1b11249 100644
--- a/fs/pstore/platform.c
+++ b/fs/pstore/platform.c
@@ -353,6 +353,11 @@ static struct kmsg_dumper pstore_dumper = {
.dump = pstore_dump,
 };
 
+static void pstore_register_kmsg(void)
+{
+   kmsg_dump_register(_dumper);
+}
+
 #ifdef CONFIG_PSTORE_CONSOLE
 static void pstore_console_write(struct console *con, const char *s, unsigned 
c)
 {
@@ -442,7 +447,7 @@ int pstore_register(struct pstore_info *psi)
if (pstore_is_mounted())
pstore_get_records(0);
 
-   kmsg_dump_register(_dumper);
+   pstore_register_kmsg();
 
if ((psi->flags & PSTORE_FLAGS_FRAGILE) == 0) {
pstore_register_console();
-- 
1.9.1


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] debugfs: update commits of debugfs_remove

[Tan Xiaojun]

This function debugfs_remove can't remove a directory if it is not
empty. The commits make misunderstood and cause misuse easily, so
update it.

Signed-off-by: Tan Xiaojun 
---
 fs/debugfs/inode.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/fs/debugfs/inode.c b/fs/debugfs/inode.c
index c711be8..350754e 100644
--- a/fs/debugfs/inode.c
+++ b/fs/debugfs/inode.c
@@ -531,7 +531,8 @@ static int __debugfs_remove(struct dentry *dentry, struct 
dentry *parent)
 }
 
 /**
- * debugfs_remove - removes a file or directory from the debugfs filesystem
+ * debugfs_remove - removes a file or an empty directory from the debugfs
+ * filesystem
  * @dentry: a pointer to a the dentry of the file or directory to be
  *  removed.
  *
@@ -542,6 +543,9 @@ static int __debugfs_remove(struct dentry *dentry, struct 
dentry *parent)
  * This function is required to be called in order for the file to be
  * removed, no automatic cleanup of files will happen when a module is
  * removed, you are responsible here.
+ *
+ * For removing directory, if you are not sure it is empty or not, use
+ * debugfs_remove_recursive instead.
  */
 void debugfs_remove(struct dentry *dentry)
 {
-- 
2.5.3

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v9 6/6] MAINTAINERS: Add Altera PCIe and MSI drivers maintainer

[Ley Foon Tan]

Signed-off-by: Ley Foon Tan 
---
 MAINTAINERS | 16 
 1 file changed, 16 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 5f46784..0f55f38 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -7943,6 +7943,14 @@ F:   include/linux/pci*
 F: arch/x86/pci/
 F: arch/x86/kernel/quirks.c
 
+PCI DRIVER FOR ALTERA PCIE IP
+M: Ley Foon Tan 
+L: r...@lists.rocketboards.org (moderated for non-subscribers)
+L: linux-...@vger.kernel.org
+S: Supported
+F: Documentation/devicetree/bindings/pci/altera-pcie.txt
+F: drivers/pci/host/pcie-altera.c
+
 PCI DRIVER FOR ARM VERSATILE PLATFORM
 M: Rob Herring 
 L: linux-...@vger.kernel.org
@@ -8044,6 +8052,14 @@ L:   linux-...@vger.kernel.org
 S: Maintained
 F: drivers/pci/host/*spear*
 
+PCI MSI DRIVER FOR ALTERA MSI IP
+M: Ley Foon Tan 
+L: r...@lists.rocketboards.org (moderated for non-subscribers)
+L: linux-...@vger.kernel.org
+S: Supported
+F: Documentation/devicetree/bindings/pci/altera-pcie-msi.txt
+F: drivers/pci/host/pcie-altera-msi.c
+
 PCI MSI DRIVER FOR APPLIEDMICRO XGENE
 M: Duc Dang 
 L: linux-...@vger.kernel.org
-- 
1.8.2.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v9 3/6] pci:host: Add Altera PCIe host controller driver

[Ley Foon Tan]

This patch adds the Altera PCIe host controller driver.

Signed-off-by: Ley Foon Tan 
Reviewed-by: Marc Zyngier 
---
 drivers/pci/host/Kconfig   |   7 +
 drivers/pci/host/Makefile  |   1 +
 drivers/pci/host/pcie-altera.c | 592 +
 3 files changed, 600 insertions(+)
 create mode 100644 drivers/pci/host/pcie-altera.c

diff --git a/drivers/pci/host/Kconfig b/drivers/pci/host/Kconfig
index d5e58ba..f956206 100644
--- a/drivers/pci/host/Kconfig
+++ b/drivers/pci/host/Kconfig
@@ -145,4 +145,11 @@ config PCIE_IPROC_BCMA
  Say Y here if you want to use the Broadcom iProc PCIe controller
  through the BCMA bus interface
 
+config PCIE_ALTERA
+   bool "Altera PCIe controller"
+   select PCI_DOMAINS
+   help
+Say Y here if you want to enable PCIe controller support on Altera
+FPGA.
+
 endmenu
diff --git a/drivers/pci/host/Makefile b/drivers/pci/host/Makefile
index 140d66f..6954f76 100644
--- a/drivers/pci/host/Makefile
+++ b/drivers/pci/host/Makefile
@@ -17,3 +17,4 @@ obj-$(CONFIG_PCI_VERSATILE) += pci-versatile.o
 obj-$(CONFIG_PCIE_IPROC) += pcie-iproc.o
 obj-$(CONFIG_PCIE_IPROC_PLATFORM) += pcie-iproc-platform.o
 obj-$(CONFIG_PCIE_IPROC_BCMA) += pcie-iproc-bcma.o
+obj-$(CONFIG_PCIE_ALTERA) += pcie-altera.o
diff --git a/drivers/pci/host/pcie-altera.c b/drivers/pci/host/pcie-altera.c
new file mode 100644
index 000..e714e95
--- /dev/null
+++ b/drivers/pci/host/pcie-altera.c
@@ -0,0 +1,592 @@
+/*
+ * Copyright Altera Corporation (C) 2013-2015. All rights reserved
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope 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 
+#include 
+#include 
+#include 
+
+#define A2P_ADDR_MAP_LO0   0x1000
+#define A2P_ADDR_MAP_HI0   0x1004
+#define RP_TX_REG0 0x2000
+#define RP_TX_REG1 0x2004
+#define RP_TX_CNTRL0x2008
+#define RP_TX_EOP  0x2
+#define RP_TX_SOP  0x1
+#define RP_RXCPL_STATUS0x2010
+#define RP_RXCPL_EOP   0x2
+#define RP_RXCPL_SOP   0x1
+#define RP_RXCPL_REG0  0x2014
+#define RP_RXCPL_REG1  0x2018
+#define P2A_INT_STATUS 0x3060
+#define P2A_INT_STS_ALL0xF
+#define P2A_INT_ENABLE 0x3070
+#define P2A_INT_ENA_ALL0xF
+#define RP_LTSSM   0x3C64
+#define LTSSM_L0   0xF
+
+/* TLP configuration type 0 and 1 */
+#define TLP_FMTTYPE_CFGRD0 0x04/* Configuration Read Type 0 */
+#define TLP_FMTTYPE_CFGWR0 0x44/* Configuration Write Type 0 */
+#define TLP_FMTTYPE_CFGRD1 0x05/* Configuration Read Type 1 */
+#define TLP_FMTTYPE_CFGWR1 0x45/* Configuration Write Type 1 */
+#define TLP_PAYLOAD_SIZE   0x01
+#define TLP_READ_TAG   0x1D
+#define TLP_WRITE_TAG  0x10
+#define TLP_CFG_DW0(fmttype)   (((fmttype) << 24) | TLP_PAYLOAD_SIZE)
+#define TLP_CFG_DW1(reqid, tag, be)(((reqid) << 16) | (tag << 8) | (be))
+#define TLP_CFG_DW2(bus, devfn, offset)\
+   (((bus) << 24) | ((devfn) << 16) | (offset))
+#define TLP_REQ_ID(bus, devfn) (((bus) << 8) | (devfn))
+#define TLP_COMPL_STATUS(hdr)  (((hdr) & 0xE0) >> 13)
+#define TLP_HDR_SIZE   3
+#define TLP_LOOP   500
+
+#define INTX_NUM   4
+
+#define DWORD_MASK 3
+
+struct altera_pcie {
+   struct platform_device  *pdev;
+   void __iomem*cra_base;
+   int irq;
+   u8  root_bus_nr;
+   struct irq_domain   *irq_domain;
+   struct resource bus_range;
+   struct list_headresources;
+};
+
+struct tlp_rp_regpair_t {
+   u32 ctrl;
+   u32 reg0;
+   u32 reg1;
+};
+
+static void altera_pcie_retrain(struct pci_dev *dev)
+{
+   u16 linkcap, linkstat;
+
+   /*
+* Set the retrain bit if the PCIe rootport support > 2.5GB/s, but
+* current speed is 2.5 GB/s.
+*/
+   pcie_capability_read_word(dev, PCI_EXP_LNKCAP, );
+
+   if ((linkcap & PCI_EXP_LNKCAP_SLS) <= PCI_EXP_LNKCAP_SLS_2_5GB)
+ 

[PATCH v9 4/6] pci: altera: Add Altera PCIe MSI driver

[Ley Foon Tan]

This patch adds Altera PCIe MSI driver. This soft IP supports configurable
number of vectors, which is a dts parameter.

Signed-off-by: Ley Foon Tan 
Reviewed-by: Marc Zyngier 
---
 drivers/pci/host/Kconfig   |   8 +
 drivers/pci/host/Makefile  |   1 +
 drivers/pci/host/pcie-altera-msi.c | 313 +
 3 files changed, 322 insertions(+)
 create mode 100644 drivers/pci/host/pcie-altera-msi.c

diff --git a/drivers/pci/host/Kconfig b/drivers/pci/host/Kconfig
index f956206..56daa1e 100644
--- a/drivers/pci/host/Kconfig
+++ b/drivers/pci/host/Kconfig
@@ -152,4 +152,12 @@ config PCIE_ALTERA
 Say Y here if you want to enable PCIe controller support on Altera
 FPGA.
 
+config PCIE_ALTERA_MSI
+   bool "Altera PCIe MSI feature"
+   depends on PCI_MSI
+   select PCI_MSI_IRQ_DOMAIN
+   help
+ Say Y here if you want PCIe MSI support for the Altera FPGA.
+ This MSI driver supports Altera MSI to GIC controller IP.
+
 endmenu
diff --git a/drivers/pci/host/Makefile b/drivers/pci/host/Makefile
index 6954f76..6c4913d 100644
--- a/drivers/pci/host/Makefile
+++ b/drivers/pci/host/Makefile
@@ -18,3 +18,4 @@ obj-$(CONFIG_PCIE_IPROC) += pcie-iproc.o
 obj-$(CONFIG_PCIE_IPROC_PLATFORM) += pcie-iproc-platform.o
 obj-$(CONFIG_PCIE_IPROC_BCMA) += pcie-iproc-bcma.o
 obj-$(CONFIG_PCIE_ALTERA) += pcie-altera.o
+obj-$(CONFIG_PCIE_ALTERA_MSI) += pcie-altera-msi.o
diff --git a/drivers/pci/host/pcie-altera-msi.c 
b/drivers/pci/host/pcie-altera-msi.c
new file mode 100644
index 000..1d8a1b6
--- /dev/null
+++ b/drivers/pci/host/pcie-altera-msi.c
@@ -0,0 +1,313 @@
+/*
+ * Copyright Altera Corporation (C) 2013-2015. All rights reserved
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope 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 
+#include 
+#include 
+#include 
+
+#define MSI_STATUS 0x0
+#define MSI_ERROR  0x4
+#define MSI_INTMASK0x8
+
+#define MAX_MSI_VECTORS32
+struct altera_msi {
+   DECLARE_BITMAP(used, MAX_MSI_VECTORS);
+   struct mutexlock;   /* proctect used variable */
+   struct platform_device  *pdev;
+   struct irq_domain   *msi_domain;
+   struct irq_domain   *inner_domain;
+   void __iomem*csr_base;
+   void __iomem*vector_base;
+   phys_addr_t vector_phy;
+   u32 num_of_vectors;
+   int irq;
+};
+
+static inline void msi_writel(struct altera_msi *msi, const u32 value,
+ const u32 reg)
+{
+   writel_relaxed(value, msi->csr_base + reg);
+}
+
+static inline u32 msi_readl(struct altera_msi *msi, const u32 reg)
+{
+   return readl_relaxed(msi->csr_base + reg);
+}
+
+static void altera_msi_isr(struct irq_desc *desc)
+{
+   struct irq_chip *chip = irq_desc_get_chip(desc);
+   struct altera_msi *msi;
+   unsigned long status;
+   u32 num_of_vectors;
+   u32 bit;
+   u32 virq;
+
+   chained_irq_enter(chip, desc);
+   msi = irq_desc_get_handler_data(desc);
+   num_of_vectors = msi->num_of_vectors;
+
+   while ((status = msi_readl(msi, MSI_STATUS)) != 0) {
+   for_each_set_bit(bit, , msi->num_of_vectors) {
+   /* Dummy read from vector to clear the interrupt */
+   readl_relaxed(msi->vector_base + (bit * sizeof(u32)));
+
+   virq = irq_find_mapping(msi->inner_domain, bit);
+   if (virq)
+   generic_handle_irq(virq);
+   else
+   dev_err(>pdev->dev, "unexpected MSI\n");
+   }
+   }
+
+   chained_irq_exit(chip, desc);
+}
+
+static struct irq_chip altera_msi_irq_chip = {
+   .name = "Altera PCIe MSI",
+   .irq_mask = pci_msi_mask_irq,
+   .irq_unmask = pci_msi_unmask_irq,
+};
+
+static struct msi_domain_info altera_msi_domain_info = {
+   .flags  = (MSI_FLAG_USE_DEF_DOM_OPS | MSI_FLAG_USE_DEF_CHIP_OPS |
+MSI_FLAG_PCI_MSIX),
+   .chip   = _msi_irq_chip,
+};
+
+static void altera_compose_msi_msg(struct irq_data *data, struct msi_msg *msg)
+{
+   struct altera_msi *msi = irq_data_get_irq_chip_data(data);
+   phys_addr_t addr = msi->vector_phy + (data->hwirq * 

[PATCH v9 2/6] pci: add Altera PCI vendor ID

[Ley Foon Tan]

Signed-off-by: Ley Foon Tan 
---
 include/linux/pci_ids.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/include/linux/pci_ids.h b/include/linux/pci_ids.h
index d9ba49c..08e4462 100644
--- a/include/linux/pci_ids.h
+++ b/include/linux/pci_ids.h
@@ -1550,6 +1550,8 @@
 #define PCI_DEVICE_ID_SERVERWORKS_CSB6LPC 0x0227
 #define PCI_DEVICE_ID_SERVERWORKS_HT1100LD 0x0408
 
+#define PCI_VENDOR_ID_ALTERA   0x1172
+
 #define PCI_VENDOR_ID_SBE  0x1176
 #define PCI_DEVICE_ID_SBE_WANXL100 0x0301
 #define PCI_DEVICE_ID_SBE_WANXL200 0x0302
-- 
1.8.2.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v9 0/6] Altera PCIe host controller driver with MSI support

[Ley Foon Tan]

This is the 9th version of patch set to add support for Altera PCIe host
controller with MSI feature on Altera FPGA device families. This patchset
mainly update the config read and write functions to support read/write
specific bytes to avoid read-modify-write and minor fixes.

This patchset is based on v4.3-rc5.

v8->v9 changes:
- altera-pcie-msi: fix missing mutex_unlock when error return
- altera-pcie: update config read and write functions to support read/write
   specific bytes

History:
---
[v1]: https://lkml.org/lkml/2015/7/28/395
[v2]: https://lkml.org/lkml/2015/7/31/267
[v3]: http://www.kernelhub.org/?msg=811940=2
[v4]: https://lkml.org/lkml/2015/8/17/141
[v5]: https://lkml.org/lkml/2015/8/25/238
[v6]: https://lkml.org/lkml/2015/9/1/177
[v7]: https://lkml.org/lkml/2015/9/20/193
[v8]: http://www.kernelhub.org/?msg=853553=2

Ley Foon Tan (6):
  arm: add msi.h to Kbuild
  pci: add Altera PCI vendor ID
  pci:host: Add Altera PCIe host controller driver
  pci: altera: Add Altera PCIe MSI driver
  Documentation: dt-bindings: pci: altera pcie device tree binding
  MAINTAINERS: Add Altera PCIe and MSI drivers maintainer

 .../devicetree/bindings/pci/altera-pcie-msi.txt|  28 +
 .../devicetree/bindings/pci/altera-pcie.txt|  49 ++
 MAINTAINERS|  16 +
 arch/arm/include/asm/Kbuild|   1 +
 drivers/pci/host/Kconfig   |  15 +
 drivers/pci/host/Makefile  |   2 +
 drivers/pci/host/pcie-altera-msi.c | 313 +++
 drivers/pci/host/pcie-altera.c | 592 +
 include/linux/pci_ids.h|   2 +
 9 files changed, 1018 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/pci/altera-pcie-msi.txt
 create mode 100644 Documentation/devicetree/bindings/pci/altera-pcie.txt
 create mode 100644 drivers/pci/host/pcie-altera-msi.c
 create mode 100644 drivers/pci/host/pcie-altera.c

-- 
1.8.2.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC] arm64: ioremap: add ioremap_cache macro

[yalin wang]

> On Oct 13, 2015, at 23:20, Catalin Marinas  wrote:
> 
> On Tue, Oct 13, 2015 at 03:23:27PM +0100, Will Deacon wrote:
>> On Tue, Oct 13, 2015 at 03:10:55PM +0100, Catalin Marinas wrote:
>>> On Mon, Oct 12, 2015 at 10:28:18AM +0800, yalin wang wrote:
 Add ioremap_cache macro, because some code will test if this macro
 is defined or not, and will generate a generric version if not defined,
 for example, memremap.c do like this.
 
 Signed-off-by: yalin wang 
 ---
 arch/arm64/include/asm/io.h | 1 +
 1 file changed, 1 insertion(+)
 
 diff --git a/arch/arm64/include/asm/io.h b/arch/arm64/include/asm/io.h
 index 44be1e0..d6b620c 100644
 --- a/arch/arm64/include/asm/io.h
 +++ b/arch/arm64/include/asm/io.h
 @@ -172,6 +172,7 @@ extern void __iomem *ioremap_cache(phys_addr_t 
 phys_addr, size_t size);
 #define ioremap_wc(addr, size) __ioremap((addr), (size), 
 __pgprot(PROT_NORMAL_NC))
 #define ioremap_wt(addr, size) __ioremap((addr), (size), 
 __pgprot(PROT_DEVICE_nGnRE))
 #define iounmap__iounmap
 +#define ioremap_cache  ioremap_cache
>>> 
>>> Applied. Thanks.
>> 
>> I'm not sure we want this. See:
>> 
>>  https://lkml.org/lkml/2015/10/9/699
> 
> Thanks Will and Arnd, I missed this. Patch reverted.
> 
i don’t understand why conflict with Dan Williams’ patch.
Dan Williams ’s patch also define ioremap_cache  for arch ia64  & arch sh & 
arch xtensa ,
i see this :
# git show   92281dee825f
am i miss something?

Thanks






--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Crypto Fixes for 4.3

[Herbert Xu]

On Tue, Oct 13, 2015 at 07:00:20PM -0700, Linus Torvalds wrote:
>
> You might try to start using signed tags for your pull requests. That
> lessens this kind of issue, because now only will you write the tag
> message and then your signing key pass phrase etc, the tag would
> specify one very particular commit at the time of the tagging rather
> than just have it be the default branch of your public repository.

Right.  I'll start using branches for the next push.

Thanks,
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/3] slab_common: rename cache create/destroy helpers

[David Rientjes]

On Thu, 8 Oct 2015, Vladimir Davydov wrote:

> do_kmem_cache_create, do_kmem_cache_shutdown, and do_kmem_cache_release
> sound awkward for static helper functions that are not supposed to be
> used outside slab_common.c. Rename them to create_cache, shutdown_cache,
> and release_caches, respectively. This patch is a pure cleanup and does
> not introduce any functional changes.
> 
> Signed-off-by: Vladimir Davydov 

Acked-by: David Rientjes 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH V2] mm, page_alloc: reserve pageblocks for high-order atomic allocations on demand -fix

[David Rientjes]

On Tue, 13 Oct 2015, yalin wang wrote:

> There is a redundant check and a memory leak introduced by a patch in
> mmotm. This patch removes an unlikely(order) check as we are sure order
> is not zero at the time. It also checks if a page is already allocated
> to avoid a memory leak.
> 
> This is a fix to the mmotm patch
> mm-page_alloc-reserve-pageblocks-for-high-order-atomic-allocations-on-demand.patch
> 
> Signed-off-by: yalin wang 
> Acked-by: Mel Gorman 

Acked-by: David Rientjes 

Cool find!
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] mm: skip if required_kernelcore is larger than totalpages

[David Rientjes]

On Thu, 8 Oct 2015, Xishi Qiu wrote:

> If kernelcore was not specified, or the kernelcore size is zero
> (required_movablecore >= totalpages), or the kernelcore size is larger
> than totalpages, there is no ZONE_MOVABLE. We should fill the zone
> with both kernel memory and movable memory.
> 
> Signed-off-by: Xishi Qiu 

Acked-by: David Rientjes 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/1] perf:Adding --list-opts to usage string

[Yunlong Song]

On 2015/10/13 23:24, Ramkumar Ramachandra wrote:
> Arnaldo Carvalho de Melo wrote:
>> Em Thu, Oct 08, 2015 at 10:59:50AM +0530, Sriram Raghunathan escreveu:
>>> Minor change, adding --list-opts to usage string. So that it is
>>> visible to the user on running perf --help. or just perf
>>> from command line.
>>
>>
>> Ramkumar, Yunlong, are you ok with this?
> 
> Not sure I understand the motivation, but I suppose it can't hurt to
> show this detail?
> 
> Ram

Agree with Ramkumar, --list-opts is redundant due to the existing [OPTIONS] in
the perf_usage_string[].

>>>
>>>  const char perf_usage_string[] =
>>> - "perf [--version] [--help] [OPTIONS] COMMAND [ARGS]";
>>> + "perf [--version] [--help] [--list-opts] [OPTIONS] COMMAND [ARGS]";

-- 
Thanks,
Yunlong Song

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 0/2] irqchip: make non-modular code explicitly non-modular

[Paul Gortmaker]

[Re: [PATCH 0/2] irqchip: make non-modular code explicitly non-modular] On 
12/10/2015 (Mon 09:04) Geert Uytterhoeven wrote:

> Hi Paul,
> 
> On Mon, Oct 12, 2015 at 1:05 AM, Paul Gortmaker
>  wrote:

[...]

> > Paul Gortmaker (2):
> >   drivers/irqchip: make irq-renesas-intc-irqpin.c explicitly non-modular
> >   drivers/irqchip: make irq-renesas-irqc.c explicitly non-modular
> >
> >  drivers/irqchip/irq-renesas-intc-irqpin.c | 24 +---
> >  drivers/irqchip/irq-renesas-irqc.c| 30 
> > +-
> >  2 files changed, 2 insertions(+), 52 deletions(-)
> 
> Both of these are "external interrupt controllers", meaning that on some 
> boards
> they are used to handle only interrupts from external devices (e.g. Ethernet),
> which is optional.
> 
> Hence IMHO the bool should be changed to tristate instead.

So, at the risk of repeating myself -- changing to tristate widens the
scope on build coverage and everything else.  When I did this for a
staging driver, I got caught in symbols that were not exported.  Not
critically complex, but it does show that allowing a new config option
can make things break.  Hence keeping the support matrix the same is
table stakes to allow me to make this tree wide update in a way that
scales.

As the changes I propose do not change the runtime, I think that the
verification of the extension of functionality lies on those who think
moving these drivers from bool to tristate is a genuine value add.

If for no other reason, it at least does keep a bisect honest in showing
where existing functionality broke vs. added functionality brought in
new breakage.

Paul.
--

> 
> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 3/3] ARM: dts: exynos5422-odroidxu3: Added UHS-I bus speed support

[Alim Akhtar]

On Wed, Oct 14, 2015 at 7:50 AM, Krzysztof Kozlowski
 wrote:
> On 14.10.2015 11:13, Alim Akhtar wrote:
>> On Wed, Oct 14, 2015 at 6:45 AM, Krzysztof Kozlowski
>>  wrote:
>>> On 14.10.2015 10:06, Alim Akhtar wrote:
 +Doug
 Hello,
 AFAIR, dw_mmc host controller does support UHS-I [1], specially SDR50
 and SDR104 modes.

 [1]: http://www.spinics.net/lists/linux-mmc/msg28186.html

 What I remember is, one need to set "broken-cd" property also in order
 to make it work because of the vqmmc and vmmc connection on board. I
 didn't find the link right now, but you can search on the web, there
 was a long discussion about handling this.
 Have not checked it recently, so not sure if this got broken somehow.

>>>
>>> Please, don't top post.
>>>
>> I am sorry, but I didn't get this, what is the guide line here???
>
> I mean reply inline, under the other person's quote, not above it.
>
> And some old, really old joke:
> A: Because it messes up the order in which people normally read text.
> Q: Why is top-posting such a bad thing?
> A: Top-posting.
> Q: What is the most annoying thing in e-mail?
>
> :)
>
I see..got it..thanks for clarification.

> Best regards,
> Krzysztof
>



-- 
Regards,
Alim
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] genirq/msi: Do not use pci_msi_[un]mask_irq as default methods

[Jiang Liu]

On 2015/10/14 2:14, Marc Zyngier wrote:
> When we create a generic MSI domain, that MSI_FLAG_USE_DEF_CHIP_OPS
> is set, and that any of .mask or .unmask are NULL in the irq_chip
> structure, we set them to pci_msi_[un]mask_irq.
> 
> This is a bad idea for at least two reasons:
> - PCI_MSI might not be selected, kernel fails to build (yes, this is
>   legitimate, at least on arm64!)
> - This may not be a PCI/MSI domain at all (platform MSI, for example)
> 
> Either way, this looks wrong. Move the overriding of mask/unmask to
> the PCI counterpart, and panic is any of these two methods is not
> set in the core code (they really should be present).
Hi Marc,
Thanks for fixing this,
Reviewed-by: Jiang Liu 
Thanks,
Gerry


> 
> Signed-off-by: Marc Zyngier 
> ---
>  drivers/pci/msi.c | 4 
>  kernel/irq/msi.c  | 6 +-
>  2 files changed, 5 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/pci/msi.c b/drivers/pci/msi.c
> index d449714..4a7da3c 100644
> --- a/drivers/pci/msi.c
> +++ b/drivers/pci/msi.c
> @@ -1243,6 +1243,10 @@ static void pci_msi_domain_update_chip_ops(struct 
> msi_domain_info *info)
>   BUG_ON(!chip);
>   if (!chip->irq_write_msi_msg)
>   chip->irq_write_msi_msg = pci_msi_domain_write_msg;
> + if (!chip->irq_mask)
> + chip->irq_mask = pci_msi_mask_irq;
> + if (!chip->irq_unmask)
> + chip->irq_unmask = pci_msi_unmask_irq;
>  }
>  
>  /**
> diff --git a/kernel/irq/msi.c b/kernel/irq/msi.c
> index 7e6512b..be9149f 100644
> --- a/kernel/irq/msi.c
> +++ b/kernel/irq/msi.c
> @@ -228,11 +228,7 @@ static void msi_domain_update_chip_ops(struct 
> msi_domain_info *info)
>  {
>   struct irq_chip *chip = info->chip;
>  
> - BUG_ON(!chip);
> - if (!chip->irq_mask)
> - chip->irq_mask = pci_msi_mask_irq;
> - if (!chip->irq_unmask)
> - chip->irq_unmask = pci_msi_unmask_irq;
> + BUG_ON(!chip || !chip->irq_mask || !chip->irq_unmask);
>   if (!chip->irq_set_affinity)
>   chip->irq_set_affinity = msi_domain_set_affinity;
>  }
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 3/3] ARM: dts: exynos5422-odroidxu3: Added UHS-I bus speed support

[Krzysztof Kozlowski]

On 14.10.2015 11:13, Alim Akhtar wrote:
> On Wed, Oct 14, 2015 at 6:45 AM, Krzysztof Kozlowski
>  wrote:
>> On 14.10.2015 10:06, Alim Akhtar wrote:
>>> +Doug
>>> Hello,
>>> AFAIR, dw_mmc host controller does support UHS-I [1], specially SDR50
>>> and SDR104 modes.
>>>
>>> [1]: http://www.spinics.net/lists/linux-mmc/msg28186.html
>>>
>>> What I remember is, one need to set "broken-cd" property also in order
>>> to make it work because of the vqmmc and vmmc connection on board. I
>>> didn't find the link right now, but you can search on the web, there
>>> was a long discussion about handling this.
>>> Have not checked it recently, so not sure if this got broken somehow.
>>>
>>
>> Please, don't top post.
>>
> I am sorry, but I didn't get this, what is the guide line here???

I mean reply inline, under the other person's quote, not above it.

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

:)

Best regards,
Krzysztof

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Updated scalable urandom patchkit

[Andi Kleen]

> Off hand, do you know how large a read each operation is?  I want to
> reduce mixback from once per 10 bytes to once per read, and the size
> ratio will give me some idea of how large an improvement to expect.

My test reads 64 bytes using the syscall.

-Andi

-- 
a...@linux.intel.com -- Speaking for myself only.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] soc: qcom: smd-rpm: Correct the active vs sleep state flagging

[Andy Gross]

On Tue, Oct 13, 2015 at 01:57:43PM -0700, Bjorn Andersson wrote:
> The BIT() was incorrectly inherited from family A and should not be used
> on family B where the state is denoted by an enum.
> 
> Reported-by: Georgi Djakov 
> Signed-off-by: Bjorn Andersson 
> ---
>  drivers/soc/qcom/smd-rpm.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/soc/qcom/smd-rpm.c b/drivers/soc/qcom/smd-rpm.c
> index b5feb58dbd9f..2969321e1b09 100644
> --- a/drivers/soc/qcom/smd-rpm.c
> +++ b/drivers/soc/qcom/smd-rpm.c
> @@ -126,7 +126,7 @@ int qcom_rpm_smd_write(struct qcom_smd_rpm *rpm,
>   pkt->hdr.length = cpu_to_le32(sizeof(struct qcom_rpm_request) + count);
>  
>   pkt->req.msg_id = cpu_to_le32(msg_id++);
> - pkt->req.flags = cpu_to_le32(BIT(state));
> + pkt->req.flags = cpu_to_le32(state);

Right, nice catch.  I'll queue it up.


-- 
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 3/3] ARM: dts: exynos5422-odroidxu3: Added UHS-I bus speed support

[Alim Akhtar]

On Wed, Oct 14, 2015 at 6:45 AM, Krzysztof Kozlowski
 wrote:
> On 14.10.2015 10:06, Alim Akhtar wrote:
>> +Doug
>> Hello,
>> AFAIR, dw_mmc host controller does support UHS-I [1], specially SDR50
>> and SDR104 modes.
>>
>> [1]: http://www.spinics.net/lists/linux-mmc/msg28186.html
>>
>> What I remember is, one need to set "broken-cd" property also in order
>> to make it work because of the vqmmc and vmmc connection on board. I
>> didn't find the link right now, but you can search on the web, there
>> was a long discussion about handling this.
>> Have not checked it recently, so not sure if this got broken somehow.
>>
>
> Please, don't top post.
>
I am sorry, but I didn't get this, what is the guide line here???

> I am not a SD/MMC specialist (I do not feel enough confident in its
> internals) but the datasheet for 5422 does not mention UHS. However it
> mentions "High Speed DDR Mode with 200 MHz clock rate (HS400)". This
> does not look like UHS...
> https://www.sdcard.org/developers/overview/bus_speed/
> This of course is not a definite proof that 5422 does not support UHS. I
> am just saying that I couldn't find any information that *it does*.
>
> Best regards,
> Krzysztof
>



-- 
Regards,
Alim
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] ARM64: dts: vexpress: Use a symlink to vexpress-v2m-rs1.dtsi from arch=arm

[Masahiro Yamada]

Hello Ian, Rob, Olof,


2015-10-13 0:37 GMT+09:00 Mark Rutland :
> On Mon, Oct 05, 2015 at 12:53:52PM +0100, Ian Campbell wrote:
>> Commit 9ccd608070b6 "arm64: dts: add device tree for ARM SMM-A53x2 on
>> LogicTile Express 20MG" added a new dts file to arch/arm64 which
>> included "../../../../arm/boot/dts/vexpress-v2m-rs1.dtsi", i.e. a
>> .dtsi supplied by arch/arm.
>>
>> Unfortunately this causes some issues for the split device tree
>> repository[0], since things get moved around there. In that context
>> the new .dts ends up at src/arm64/arm/vexpress-v2f-1xv7-ca53x2.dts
>> while the include is at src/arm/vexpress-v2m-rs1.dtsi.
>>
>> The sharing of the .dtsi is legitimate since the baseboard is the same
>> for various vexpress systems whatever processor they use.
>>
>> Previously I attempted to resolve this by creating a shared location
>> for such things but we have been unable to come to a consensus on
>> where that should be.
>>
>> Instead this patch simply replaces the use of ../../ in the dts
>> /include/ with a symlink in arch/arm64/boot/dts/arm pointing to the
>> file arch/arm/boot/dts.
>>
>> Since the split device tree repo will shortly be required to flatten
>> symlinks for other reasons this will cause the dtsi file to appear in
>> both src/arm and src/arm64 in the split repo, which is an improvement
>> on not building for arm64 now.
>>
>> [0] 
>> https://git.kernel.org/cgit/linux/kernel/git/devicetree/devicetree-rebasing.git/
>>
>> Signed-off-by: Ian Campbell 
>> Cc: Rob Herring 
>> Cc: Pawel Moll 
>> Cc: Mark Rutland 
>> Cc: Kumar Gala 
>> Cc: Liviu Dudau 
>> Cc: Sudeep Holla 
>> Cc: Lorenzo Pieralisi 
>> Cc: Russell King 
>> Cc: Catalin Marinas 
>> Cc: Will Deacon 
>> Cc: Kristina Martsenko 
>> Cc: Kevin Hilman 
>> Cc: Frank Rowand 
>> Cc: Olof Johansson 
>> Cc: devicet...@vger.kernel.org
>> Cc: linux-kernel@vger.kernel.org
>> Cc: linux-arm-ker...@lists.infradead.org
>> Cc: a...@kernel.org
>> Cc: linux-kbu...@vger.kernel.org


I have a similar issue to vexpress, so I want to consult experts.

I am trying to support a new ARM64 SoC and
want to share some DTSI files between arch/arm/boot/dts and arch/arm64/boot/dts.


I think Ian's "dtb: Create a common home for cross-architecture dtsi files"
is under way (or rejected?).

I can live with the symbolic link.
Is it OK (at least for now)?



-- 
Best Regards
Masahiro Yamada
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH net-next] net: hisilicon net: fix a bug about led

[yankejian]

From: lipeng 

this patch fixes a bug in hns driver. the link led is on at the beginning,
but at this time the ethernet port is on down status. it needs to reset
the led status on init sequence.

Signed-off-by: lipeng 
Signed-off-by: yankejian 
---
 drivers/net/ethernet/hisilicon/hns/hns_dsaf_mac.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_mac.c 
b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_mac.c
index 95bf42a..f8f7347 100644
--- a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_mac.c
+++ b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_mac.c
@@ -744,9 +744,11 @@ int hns_mac_get_cfg(struct dsaf_device *dsaf_dev, int 
mac_idx)
mac_cb->serdes_vaddr = dsaf_dev->sds_base;
 
if (dsaf_dev->cpld_base &&
-   mac_idx < DSAF_SERVICE_PORT_NUM_PER_DSAF)
+   mac_idx < DSAF_SERVICE_PORT_NUM_PER_DSAF) {
mac_cb->cpld_vaddr = dsaf_dev->cpld_base +
mac_cb->mac_id * CPLD_ADDR_PORT_OFFSET;
+   cpld_led_reset(mac_cb);
+   }
mac_cb->sfp_prsnt = 0;
mac_cb->txpkt_for_led = 0;
mac_cb->rxpkt_for_led = 0;
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 3/3] ARM: dts: exynos5422-odroidxu3: Added UHS-I bus speed support

[Alim Akhtar]

On Wed, Oct 14, 2015 at 7:22 AM, Krzysztof Kozlowski
 wrote:
> On 14.10.2015 10:40, Jaehoon Chung wrote:
>> On 10/14/2015 10:15 AM, Krzysztof Kozlowski wrote:
>>> On 14.10.2015 10:06, Alim Akhtar wrote:
 +Doug
 Hello,
 AFAIR, dw_mmc host controller does support UHS-I [1], specially SDR50
 and SDR104 modes.

 [1]: http://www.spinics.net/lists/linux-mmc/msg28186.html

 What I remember is, one need to set "broken-cd" property also in order
 to make it work because of the vqmmc and vmmc connection on board. I
 didn't find the link right now, but you can search on the web, there
 was a long discussion about handling this.
 Have not checked it recently, so not sure if this got broken somehow.

>>>
>>> Please, don't top post.
>>>
>>> I am not a SD/MMC specialist (I do not feel enough confident in its
>>> internals) but the datasheet for 5422 does not mention UHS. However it
>>> mentions "High Speed DDR Mode with 200 MHz clock rate (HS400)". This
>>> does not look like UHS...
>>
>> You're right. It's not UHS mode. it mentions eMMC's HS400 mode.
>> UHS and HS400 are difference mode.
>>
>> eMMC mode are supported
>>
>>> https://www.sdcard.org/developers/overview/bus_speed/
>>> This of course is not a definite proof that 5422 does not support UHS. I
>>> am just saying that I couldn't find any information that *it does*.
>>
>> Well, I think you want to know whether it supported or not.
>> Then you can find the information at User manual.
>> In mobile storage part of User manual, it described the overview.
>> Mobile storage host supports these specification:
>> - Secure Digital memory (SD memory version 3.0)
>> - Secure Digital I/O SDIO (SDIO version 3.0)
>> - etc...
>>
>> SD3.0 is supported UHS-I mode.
>> If user manual of exynos5422 is mentioned this specification, it should be 
>> supported UHS-I mode.
>
> Thanks! Indeed datasheet mentions that supported SD and SDIO is version
> 3.0 (not 3.01... which seems irrelevant because 3.0 introduced UHS-I,
> right?).
>
Yes, your understanding is right. SD3.0 does includes UHS-I.

> Best regards,
> Krzysztof



-- 
Regards,
Alim
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2] vfs: remove unused wrapper block_page_mkwrite()

[Ryusuke Konishi]

On Tue, 13 Oct 2015 16:51:02 -0600, Ross Zwisler wrote:
> The function currently called "__block_page_mkwrite()" used to be called
> "block_page_mkwrite()" until a wrapper for this function was added by:
> 
> commit 24da4fab5a61 ("vfs: Create __block_page_mkwrite() helper passing
>   error values back")
> 
> This wrapper, the current "block_page_mkwrite()", is currently unused.
> __block_page_mkwrite() is used directly by ext4, nilfs2 and xfs.
> 
> Remove the unused wrapper, rename __block_page_mkwrite() back to
> block_page_mkwrite() and update the comment above block_page_mkwrite().
> 
> Signed-off-by: Ross Zwisler 
> Reviewed-by: Jan Kara 
> Cc: Jan Kara 
> Cc: Christoph Hellwig 
> Cc: Al Viro 

Acked-by: Ryusuke Konishi 

Thanks,
Ryusuke Konishi

> ---
>  fs/buffer.c | 24 ++--
>  fs/ext4/inode.c |  4 ++--
>  fs/nilfs2/file.c|  2 +-
>  fs/xfs/xfs_file.c   |  2 +-
>  include/linux/buffer_head.h |  2 --
>  5 files changed, 6 insertions(+), 28 deletions(-)
> 
> diff --git a/fs/buffer.c b/fs/buffer.c
> index 82283ab..e46c916 100644
> --- a/fs/buffer.c
> +++ b/fs/buffer.c
> @@ -2420,9 +2420,9 @@ EXPORT_SYMBOL(block_commit_write);
>   * unlock the page.
>   *
>   * Direct callers of this function should protect against filesystem freezing
> - * using sb_start_write() - sb_end_write() functions.
> + * using sb_start_pagefault() - sb_end_pagefault() functions.
>   */
> -int __block_page_mkwrite(struct vm_area_struct *vma, struct vm_fault *vmf,
> +int block_page_mkwrite(struct vm_area_struct *vma, struct vm_fault *vmf,
>get_block_t get_block)
>  {
>   struct page *page = vmf->page;
> @@ -2459,26 +2459,6 @@ out_unlock:
>   unlock_page(page);
>   return ret;
>  }
> -EXPORT_SYMBOL(__block_page_mkwrite);
> -
> -int block_page_mkwrite(struct vm_area_struct *vma, struct vm_fault *vmf,
> -get_block_t get_block)
> -{
> - int ret;
> - struct super_block *sb = file_inode(vma->vm_file)->i_sb;
> -
> - sb_start_pagefault(sb);
> -
> - /*
> -  * Update file times before taking page lock. We may end up failing the
> -  * fault so this update may be superfluous but who really cares...
> -  */
> - file_update_time(vma->vm_file);
> -
> - ret = __block_page_mkwrite(vma, vmf, get_block);
> - sb_end_pagefault(sb);
> - return block_page_mkwrite_return(ret);
> -}
>  EXPORT_SYMBOL(block_page_mkwrite);
>  
>  /*
> diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c
> index 612fbcf..2d1ecd2 100644
> --- a/fs/ext4/inode.c
> +++ b/fs/ext4/inode.c
> @@ -5244,7 +5244,7 @@ int ext4_page_mkwrite(struct vm_area_struct *vma, 
> struct vm_fault *vmf)
>   !ext4_should_journal_data(inode) &&
>   !ext4_nonda_switch(inode->i_sb)) {
>   do {
> - ret = __block_page_mkwrite(vma, vmf,
> + ret = block_page_mkwrite(vma, vmf,
>  ext4_da_get_block_prep);
>   } while (ret == -ENOSPC &&
>  ext4_should_retry_alloc(inode->i_sb, ));
> @@ -5291,7 +5291,7 @@ retry_alloc:
>   ret = VM_FAULT_SIGBUS;
>   goto out;
>   }
> - ret = __block_page_mkwrite(vma, vmf, get_block);
> + ret = block_page_mkwrite(vma, vmf, get_block);
>   if (!ret && ext4_should_journal_data(inode)) {
>   if (ext4_walk_page_buffers(handle, page_buffers(page), 0,
> PAGE_CACHE_SIZE, NULL, do_journal_get_write_access)) {
> diff --git a/fs/nilfs2/file.c b/fs/nilfs2/file.c
> index 54575e3..088ba00 100644
> --- a/fs/nilfs2/file.c
> +++ b/fs/nilfs2/file.c
> @@ -109,7 +109,7 @@ static int nilfs_page_mkwrite(struct vm_area_struct *vma, 
> struct vm_fault *vmf)
>   goto out;
>  
>   file_update_time(vma->vm_file);
> - ret = __block_page_mkwrite(vma, vmf, nilfs_get_block);
> + ret = block_page_mkwrite(vma, vmf, nilfs_get_block);
>   if (ret) {
>   nilfs_transaction_abort(inode->i_sb);
>   goto out;
> diff --git a/fs/xfs/xfs_file.c b/fs/xfs/xfs_file.c
> index e78feb4..f80e90f 100644
> --- a/fs/xfs/xfs_file.c
> +++ b/fs/xfs/xfs_file.c
> @@ -1506,7 +1506,7 @@ xfs_filemap_page_mkwrite(
>   ret = __dax_mkwrite(vma, vmf, xfs_get_blocks_direct,
>   xfs_end_io_dax_write);
>   } else {
> - ret = __block_page_mkwrite(vma, vmf, xfs_get_blocks);
> + ret = block_page_mkwrite(vma, vmf, xfs_get_blocks);
>   ret = block_page_mkwrite_return(ret);
>   }
>  
> diff --git a/include/linux/buffer_head.h b/include/linux/buffer_head.h
> index e6797de..89d9aa9 100644
> --- a/include/linux/buffer_head.h
> +++ b/include/linux/buffer_head.h
> @@ -227,8 +227,6 @@ int cont_write_begin(struct file *, struct address_space 
> *, loff_t,
>   get_block_t *, loff_t *);
>  int 

Re: Crypto Fixes for 4.3

[Linus Torvalds]

On Tue, Oct 13, 2015 at 6:03 PM, Herbert Xu  wrote:
>
> Oops, I should've waited for you to pull the previous one before
> pushing this one out.

You might try to start using signed tags for your pull requests. That
lessens this kind of issue, because now only will you write the tag
message and then your signing key pass phrase etc, the tag would
specify one very particular commit at the time of the tagging rather
than just have it be the default branch of your public repository.

Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] zsmalloc: don't test shrinker_enabled in zs_shrinker_count()

[Sergey Senozhatsky]

We don't let user to disable shrinker in zsmalloc (once
it's been enabled), so no need to check ->shrinker_enabled
in zs_shrinker_count(), at the moment at least.

Signed-off-by: Sergey Senozhatsky 
---
 mm/zsmalloc.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/mm/zsmalloc.c b/mm/zsmalloc.c
index 7ad5e54..8ba247d 100644
--- a/mm/zsmalloc.c
+++ b/mm/zsmalloc.c
@@ -1822,9 +1822,6 @@ static unsigned long zs_shrinker_count(struct shrinker 
*shrinker,
struct zs_pool *pool = container_of(shrinker, struct zs_pool,
shrinker);
 
-   if (!pool->shrinker_enabled)
-   return 0;
-
for (i = zs_size_classes - 1; i >= 0; i--) {
class = pool->size_class[i];
if (!class)
-- 
2.6.1.134.g4b1fd35

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 3/3] ARM: dts: exynos5422-odroidxu3: Added UHS-I bus speed support

[Krzysztof Kozlowski]

On 14.10.2015 10:40, Jaehoon Chung wrote:
> On 10/14/2015 10:15 AM, Krzysztof Kozlowski wrote:
>> On 14.10.2015 10:06, Alim Akhtar wrote:
>>> +Doug
>>> Hello,
>>> AFAIR, dw_mmc host controller does support UHS-I [1], specially SDR50
>>> and SDR104 modes.
>>>
>>> [1]: http://www.spinics.net/lists/linux-mmc/msg28186.html
>>>
>>> What I remember is, one need to set "broken-cd" property also in order
>>> to make it work because of the vqmmc and vmmc connection on board. I
>>> didn't find the link right now, but you can search on the web, there
>>> was a long discussion about handling this.
>>> Have not checked it recently, so not sure if this got broken somehow.
>>>
>>
>> Please, don't top post.
>>
>> I am not a SD/MMC specialist (I do not feel enough confident in its
>> internals) but the datasheet for 5422 does not mention UHS. However it
>> mentions "High Speed DDR Mode with 200 MHz clock rate (HS400)". This
>> does not look like UHS...
> 
> You're right. It's not UHS mode. it mentions eMMC's HS400 mode.
> UHS and HS400 are difference mode.
> 
> eMMC mode are supported 
> 
>> https://www.sdcard.org/developers/overview/bus_speed/
>> This of course is not a definite proof that 5422 does not support UHS. I
>> am just saying that I couldn't find any information that *it does*.
> 
> Well, I think you want to know whether it supported or not.
> Then you can find the information at User manual.
> In mobile storage part of User manual, it described the overview.
> Mobile storage host supports these specification:
> - Secure Digital memory (SD memory version 3.0)
> - Secure Digital I/O SDIO (SDIO version 3.0)
> - etc...
> 
> SD3.0 is supported UHS-I mode. 
> If user manual of exynos5422 is mentioned this specification, it should be 
> supported UHS-I mode.

Thanks! Indeed datasheet mentions that supported SD and SDIO is version
3.0 (not 3.01... which seems irrelevant because 3.0 introduced UHS-I,
right?).

Best regards,
Krzysztof
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

LUCRATIVE BUSINESS PROPOSAL!!

Compliment,
Our company urgently needs a local supply agent from India for the supply of 
raw materials for production. 
 If you think you can handle this supply deal kindly reverts back to me for the 
terms and conditions. 
All contact should be addressed to Dr.Chris Harrison via 
email:(dr.chrisharriso...@gmail.com)

Best Regards,
Dr.Chris.Harrison.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [lkp] [sched/fair] 98d8fd8126: -20.8% hackbench.throughput

[Huang, Ying]

Dietmar Eggemann  writes:

> Hi Ying,
>
> On 24/09/15 03:00, kernel test robot wrote:
>> FYI, we noticed the below changes on
>> 
>> https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git sched/core
>> commit 98d8fd8126676f7ba6e133e65b2ca4b17989d32c ("sched/fair: Initialize 
>> task load and utilization before placing task on rq")
>> 
>> 
>> =
>> tbox_group/testcase/rootfs/kconfig/compiler/nr_threads/mode/ipc:
>>   
>> lkp-ws02/hackbench/debian-x86_64-2015-02-07.cgz/x86_64-rhel/gcc-4.9/1600%/process/pipe
>> 
>> commit: 
>>   231678b768da07d19ab5683a39eeb0c250631d02
>>   98d8fd8126676f7ba6e133e65b2ca4b17989d32c
>> 
>> 231678b768da07d1 98d8fd8126676f7ba6e133e65b 
>>  -- 
>>  %stddev %change %stddev
>>  \  |\  
>> 188818 ±  1% -20.8% 149585 ±  1%  hackbench.throughput
>
> [...]
>
>> 
>> lkp-ws02: Westmere-EP
>> Memory: 16G
>> 
>> 
>> 
>> 
>>   hackbench.time.involuntary_context_switches
>> 
>> 3e+08 ++O---+
>>   O  O O   O O  |
>>   2.5e+08 ++ OO  O   O  O
>>   | O   O O  O  |
>>   |   O   O O   O   |
>> 2e+08 ++   O|
>>   |O|
>>   1.5e+08 ++|
>>   | |
>> 1e+08 ++|
>>   |  .*...*..*..*...*..*|
>>   *..*...*..*..*...*..  .*..  ..*..*.   |
>> 5e+07 ++  *.*.  |
>>   | |
>> 0 +++
>> 
>>   vmstat.system.in
>> 
>>   30 ++-+
>>  |O O   O   |
>>  OO  O   O   O  |
>>   25 ++ O   O O O
>>  | O|
>>  | O  O  O   O  O  O|
>>   20 ++O   O|
>>  |  |
>>   15 ++ |
>>  |  |
>>  |  |
>>   10 ++ |
>>  |   .*...   .*..*...*..*..*...*|
>>  *..*...*..*. *..  .*...  .*...*.   |
>>5 ++--*--*---+
>> 
>>  [*] bisect-good sample
>>  [O] bisect-bad  sample
>> 
>> To reproduce:
>> 
>> git clone 
>> git://git.kernel.org/pub/scm/linux/kernel/git/wfg/lkp-tests.git
>> cd lkp-tests
>> bin/lkp install job.yaml  # job file is attached in this email
>> bin/lkp run job.yaml
>
> I try to recreate this on one of my Intel machines (Xeon CPU E5-2650 v2
> @ 2.60GHz) w/ 16 logical cpus. We haven't seen anything near a 20%
> performance degradation for hackbench when we were running our hackbench
> tests on 5/6 core arm machines as well as on a IVB-EP (2*10*2) Intel
> machine.
>
> So I cloned the repo:
>
> # git clone git://git.kernel.org/pub/scm/linux/kernel/git/wfg
> /lkp-tests.git lkp-tests
>
> and ran the hackbench example:
>
> root # lkp install $LKP_SRC/jobs/hackbench.yaml
>
> root # lkp split-job $LKP_SRC/jobs/hackbench.yaml
>
> root # lkp run ./hackbench-50%-threads-socket.yaml
>
> 2015-10-12 19:27:20 /usr/bin/hackbench -g 8 --threads -l 6
> Running in threaded mode with 8 groups using 40 file descriptors each
> (== 320 tasks)
> Each sender will pass 6 messages of 100 bytes
> ...
> wait for background monitors: perf-profile uptime proc-vmstat proc-stat
> meminfo slabinfo interrupts softirqs diskstats cpuidle turbostat sched_debug
>
> root # lkp result hackbench
>
> 

Re: [PATCH v3 6/6] powerpc: atomic: Implement cmpxchg{,64}_* and atomic{,64}_cmpxchg_* variants

[Boqun Feng]

On Tue, Oct 13, 2015 at 04:04:27PM +0100, Will Deacon wrote:
> On Tue, Oct 13, 2015 at 10:58:30PM +0800, Boqun Feng wrote:
> > On Tue, Oct 13, 2015 at 03:43:33PM +0100, Will Deacon wrote:
> > > Putting a barrier in the middle of that critical section is probably a
> > > terrible idea, and that's why I thought you were avoiding it (hence my
> > 
> > The fact is that I haven't thought of that way to implement
> > cmpxchg_release before you ask that question ;-) And I'm not going to do
> > that for now and probably not in the future.
> > 
> > > original question). Perhaps just add a comment to that effect, since I
> > 
> > Are you suggesting if I put a barrier in the middle I'd better to add a
> > comment, right? So if I don't do that, it's OK to let this patch as it.
> 
> No, I mean put a comment in your file to explain the reason why you
> override _relaxed and _acquire, but not _release (because overriding

You mean overriding _acquire and fully order version, right?

> _release would introduce this weird barrier in the middle of the critical
> section, which would likely cause the conditional store to fail).
> 
> Will


signature.asc
Description: PGP signature

[PATCH v2 for-next] EDAC: use edac_debugfs_remove_recursive instead of debugfs_remove

[Tan Xiaojun]

debugfs_remove is used to remove a file or an empty directory from
the debugfs filesystem, but mci->debugfs is not empty.

This is not easily discovered, because debugfs_remove return nothing
when failed. It can be test like below:

1)open EDAC config and open CONFIG_EDAC_DEBUG
2)insmod a edac_mc module (like i3000_edac or others in drivers/edac/)
3)rmmod this module
4)we can also see files under /sys/kernel/debug/edac/ like
  "fake_inject"

Reported-by: Yun Wu (Abel) 
Signed-off-by: Tan Xiaojun 
---
 drivers/edac/debugfs.c   | 2 +-
 drivers/edac/edac_mc_sysfs.c | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/edac/debugfs.c b/drivers/edac/debugfs.c
index 4864703..54d2f66 100644
--- a/drivers/edac/debugfs.c
+++ b/drivers/edac/debugfs.c
@@ -98,7 +98,7 @@ int edac_create_debugfs_nodes(struct mem_ctl_info *mci)
mci->debugfs = parent;
return 0;
 nomem:
-   debugfs_remove(mci->debugfs);
+   edac_debugfs_remove_recursive(mci->debugfs);
return -ENOMEM;
 }
 
diff --git a/drivers/edac/edac_mc_sysfs.c b/drivers/edac/edac_mc_sysfs.c
index 3929391..a75acea 100644
--- a/drivers/edac/edac_mc_sysfs.c
+++ b/drivers/edac/edac_mc_sysfs.c
@@ -976,7 +976,7 @@ void edac_remove_sysfs_mci_device(struct mem_ctl_info *mci)
edac_dbg(0, "\n");
 
 #ifdef CONFIG_EDAC_DEBUG
-   debugfs_remove(mci->debugfs);
+   edac_debugfs_remove_recursive(mci->debugfs);
 #endif
 #ifdef CONFIG_EDAC_LEGACY_SYSFS
edac_delete_csrow_objects(mci);
-- 
2.5.3

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 3/3] ARM: dts: exynos5422-odroidxu3: Added UHS-I bus speed support

[Jaehoon Chung]

On 10/14/2015 10:15 AM, Krzysztof Kozlowski wrote:
> On 14.10.2015 10:06, Alim Akhtar wrote:
>> +Doug
>> Hello,
>> AFAIR, dw_mmc host controller does support UHS-I [1], specially SDR50
>> and SDR104 modes.
>>
>> [1]: http://www.spinics.net/lists/linux-mmc/msg28186.html
>>
>> What I remember is, one need to set "broken-cd" property also in order
>> to make it work because of the vqmmc and vmmc connection on board. I
>> didn't find the link right now, but you can search on the web, there
>> was a long discussion about handling this.
>> Have not checked it recently, so not sure if this got broken somehow.
>>
> 
> Please, don't top post.
> 
> I am not a SD/MMC specialist (I do not feel enough confident in its
> internals) but the datasheet for 5422 does not mention UHS. However it
> mentions "High Speed DDR Mode with 200 MHz clock rate (HS400)". This
> does not look like UHS...

You're right. It's not UHS mode. it mentions eMMC's HS400 mode.
UHS and HS400 are difference mode.

eMMC mode are supported 

> https://www.sdcard.org/developers/overview/bus_speed/
> This of course is not a definite proof that 5422 does not support UHS. I
> am just saying that I couldn't find any information that *it does*.

Well, I think you want to know whether it supported or not.
Then you can find the information at User manual.
In mobile storage part of User manual, it described the overview.
Mobile storage host supports these specification:
- Secure Digital memory (SD memory version 3.0)
- Secure Digital I/O SDIO (SDIO version 3.0)
- etc...

SD3.0 is supported UHS-I mode. 
If user manual of exynos5422 is mentioned this specification, it should be 
supported UHS-I mode.

If my understanding is wrong, let me know, plz.

Best Regards,
Jaehoon Chung

> 
> Best regards,
> Krzysztof
> 
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2/4] mmc: dt-bindings: update Mediatek MMC bindings

[Chaotian Jing]

On Tue, 2015-10-13 at 11:38 +0100, Mark Rutland wrote:
> On Tue, Oct 13, 2015 at 05:37:56PM +0800, Chaotian Jing wrote:
> > Add 400Mhz clock source for HS400 mode
> > 
> > Signed-off-by: Chaotian Jing 
> > ---
> >  Documentation/devicetree/bindings/mmc/mtk-sd.txt | 12 ++--
> >  1 file changed, 10 insertions(+), 2 deletions(-)
> > 
> > diff --git a/Documentation/devicetree/bindings/mmc/mtk-sd.txt 
> > b/Documentation/devicetree/bindings/mmc/mtk-sd.txt
> > index a1adfa4..745bee2 100644
> > --- a/Documentation/devicetree/bindings/mmc/mtk-sd.txt
> > +++ b/Documentation/devicetree/bindings/mmc/mtk-sd.txt
> > @@ -17,6 +17,11 @@ Required properties:
> >  - vmmc-supply: power to the Core
> >  - vqmmc-supply: power to the IO
> >  
> > +Optional properties:
> > +- clocks: 400mhz clock source for HS400
> > +- clock-names: "400mhz"
> 
> Is that really what the input line is called?
> 
> > +- hs400-ds-delay: HS400 DS delay setting
> 
> What is the format of this? Where can I derive the correct value?
> 
> Mark.
> 
This is the value of register PAD_DS_TUNE(0x188), in general, this value
is the default value of register PAD_DS_TUNE(different platform has
different value, 0x14015 is the default value of MT8173). And, this
register is used to tune data in HS400 mode, but as you know, HS400 mode
do not support CMD21, so we need find a "best" value to cover HS400
mode, if default value does not work, we have an off-line calibration
program to find the best value.
> > +
> >  Examples:
> >  mmc0: mmc@1123 {
> > compatible = "mediatek,mt8173-mmc", "mediatek,mt8135-mmc";
> > @@ -24,9 +29,12 @@ mmc0: mmc@1123 {
> > interrupts = ;
> > vmmc-supply = <_vemc_3v3_reg>;
> > vqmmc-supply = <_vio18_reg>;
> > -   clocks = < CLK_PERI_MSDC30_0>, < 
> > CLK_TOP_MSDC50_0_H_SEL>;
> > -   clock-names = "source", "hclk";
> > +   clocks = < CLK_PERI_MSDC30_0>,
> > +< CLK_TOP_MSDC50_0_H_SEL>,
> > +< CLK_TOP_MSDCPLL_D2> ;
> > +   clock-names = "source", "hclk", "400mhz";
> > pinctrl-names = "default", "state_uhs";
> > pinctrl-0 = <_pins_default>;
> > pinctrl-1 = <_pins_uhs>;
> > +   hs400-ds-delay = <0x14015>;
> >  };
> > -- 
> > 1.8.1.1.dirty
> > 
> > 
> > ___
> > linux-arm-kernel mailing list
> > linux-arm-ker...@lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> > 


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCHv2 0/3] align zpool/zbud/zsmalloc on the api

[Sergey Senozhatsky]

Sorry for long reply.

On (10/09/15 08:36), Dan Streetman wrote:
[..]
> Specifically regarding the determinism of each; obviously compaction
> will have an impact, since it takes cpu cycles to do the compaction.
> I don't know how much impact, but I think at minimum it would make
> sense to add a module param to zsmalloc to allow disabling compaction.

Well, this was on my list of things TODO; and, BTW, this was *ONE OF*
the reason I added bool flag `->shrinker_enabled'.

static unsigned long zs_shrinker_count(struct shrinker *shrinker,
struct shrink_control *sc)
{
...
if (!pool->shrinker_enabled)
return 0;
...
}

So, technically, it's easy. I'm not sure, though, that I want to export
this low level knob. It sort of makes sense, but at the same time a bit
tricky.

> But even without compaction, there is an important difference between
> zbud and zsmalloc; zbud will never alloc more than 1 page when it
> needs more storage, while zsmalloc will alloc between 1 and
> ZS_MAX_PAGES_PER_ZSPAGE (currently 4) pages when it needs more
> storage.  So in the worst case (if memory is tight and alloc_page()
> takes a while), zsmalloc could take up to 4 times as long as zbud to
> store a page.
>

hm... zsmalloc release zspage once it becomes empty, which happens:
a) when zspage receives 'final' zs_free() (no more objects in use)
   and turns into a ZS_EMPTY zspage
b) when compaction moves all of its object to other zspages and, thus,
   the zspage becomes ZS_EMPTY

And, basically, this `allocate ZS_MAX_PAGES_PER_ZSPAGE pages' penalty
hits (to some degree) us even if we are not so tight on memory.


So... *May be* it makes some sense to guarantee (well, via a special
knob) that each class has no less than N unused objects (hot-cache),
which may be (but not necessarily is) an equivalent of keeping M
ZS_EMPTY zspage(-s) in the class. IOW, avoid free_zspage() if that will
result in K alloc_page() shortly, simply because we end up having just
1 or 2 unused objects in the class.

I can understand that some workloads care less about memory efficiency.


Looks like I finally have more time this week so I'll try to take a
look why zsmalloc makes Vitaly so unhappy.

-ss

> Now, that should average out, where zsmalloc doesn't
> need to alloc as many times as zbud (since it allocs more at once),
> but on the small scale there will be less consistency of page storage
> times with zsmalloc than zbud; at least, theoretically ;-)
> 
> I suggest you work with Minchan to find out what comparison data he
> wants to see, to prove zbud is more stable/consistent under a certain
> workload (and/or across kernel versions).
> 
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majord...@kvack.org.  For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Don't email: mailto:"d...@kvack.org;> em...@kvack.org 
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [patch 0/3] irqchip/mxs: Add support for ASM9260 interrupt controller

[Shawn Guo]

On Tue, Oct 13, 2015 at 05:58:53PM -, Thomas Gleixner wrote:
> I'm reposting this series from Oleksij before I apply it to give Shawn
> and Sascha an opportunity to review and test it on imx.

I tested the series on imx28-evk board with v4.3-rc5, and it works fine.

Tested-by: Shawn Guo 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [PATCH][RFC] mm: Introduce kernelcore=reliable option

[Izumi, Taku]

> > I remember Kame has already suggested this idea. In my opinion,
> > I still think it's better to add a new migratetype or a new zone,
> > so both user and kernel could use mirrored memory.
> 
> A new zone would be more flexible ... and probably the right long
> term solution.  But this looks like a very clever was to try out the
> feature with a minimally invasive patch.

 Yes. I agree creating a new zone is the right solution for long term.
 I believe this approach using MOVABLE_ZONE is good and reasonable 
 for short-term solution.

Sincerely,
Taku Izumi
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [alsa-devel] [RFC PATCH] ASoC: Modify check condition of multiple bindings of components

[Koro Chen]

On Tue, 2015-10-13 at 16:42 +0200, Lars-Peter Clausen wrote:
> On 10/13/2015 04:18 PM, Koro Chen wrote:
> > On Tue, 2015-10-13 at 15:44 +0200, Lars-Peter Clausen wrote:
> >> On 10/13/2015 03:37 PM, Koro Chen wrote:
> >>> The patch "ASoC: Prevent components from being bound to multiple cards"
> >>> adds check to prevent multiple cards from using the same component.
> >>> However, snd_soc_register_platform() or snd_soc_register_codec() will
> >>> also create components, and sharing the same platform by multiple cards
> >>> is then refused. This happens with a platform having multiple
> >>> independent DAIs that share the same DMA controller.
> >>>
> >>> Relax the condition by checking component->registered_as_component,
> >>> which is only true in case of snd_soc_register_component() and
> >>> will be false for components created by snd_soc_register_platform()
> >>> or snd_soc_register_codec().
> >>
> >> Binding a component to multiple cards results in internal data structure
> >> corruption, regardless of whether it is a raw component, CODEC or platform,
> >> which is why the check was added. So the proposed change wont work.
> >>
> > Thanks for your comment. Is it possible to share an example of how the
> > data structure will be corrupted? So I can study into this further.
> 
> Just look at soc_probe_component() and think about what happens if that runs
> twice for two different cards. Multiple calls to list_add() on the same
> list, controls are added multiple times, DAPM widgets are created multiple
> times, the card field will only point to the last card.
> 
When multiple binding happens, soc_probe_component() just returns zero
without doing anything after this patch (actually it also returned zero
before the patch "ASoC: Prevent components from being bound to multiple
cards"). So the component still binds to the first card. For this case I
think it should be fine?

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


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 5/6] e1000 driver remove checkpatch errors, warnings and checks.

[Joe Perches]

On Tue, 2015-10-13 at 15:23 -0700, Alexander Duyck wrote:
> Please don't just blindly 
> follow checkpatch as it can give out erroneous information.
> 
> Looking over most of this patch series it seems like it is taking 
> readability in the wrong direction and reducing the ability to maintain 
> the driver since this code has been "maintenance only" for some time 
> now.  If somebody comes up with a legitimate fix for an issue at some 
> point in the future they will need to work around these patches in order 
> to back-port it into a stable release and that just hurts maintainability.
> 
> I'd say this whole series should be rejected on the grounds that this 
> driver is mostly stable and should only really be modified for bug fixes 
> at this point.  If we really need to go through and do a checkpatch 
> sweep we should probably just focus on serious errors only instead of 
> going astray and chasing down things that are false hits or minor issues 
> that are mostly a matter of preference.

Excellent advice.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/1] Bumps limit of maximum core ID from 32 to 128.

[Guenter Roeck]

On 10/12/2015 04:53 AM, Lukasz Odzioba wrote:

A new limit selected arbitrarily as power of two greater than
required minimum for Xeon Phi processor.

Currently driver is not able to handle cores with core ID greater than 32.
Such attempt ends up with the following error in dmesg:
coretemp coretemp.0: Adding Core XXX failed

Signed-off-by: Lukasz Odzioba 


Applied, after fixing up the subject and listing the current required limit
of 72 cores for Xeon Phi (per published information).

Guenter


---
  drivers/hwmon/coretemp.c |2 +-
  1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/hwmon/coretemp.c b/drivers/hwmon/coretemp.c
index 3e03379..6a27eb2 100644
--- a/drivers/hwmon/coretemp.c
+++ b/drivers/hwmon/coretemp.c
@@ -52,7 +52,7 @@ module_param_named(tjmax, force_tjmax, int, 0444);
  MODULE_PARM_DESC(tjmax, "TjMax value in degrees Celsius");

  #define BASE_SYSFS_ATTR_NO2   /* Sysfs Base attr no for coretemp */
-#define NUM_REAL_CORES 32  /* Number of Real cores per cpu */
+#define NUM_REAL_CORES 128 /* Number of Real cores per cpu */
  #define CORETEMP_NAME_LENGTH  19  /* String Length of attrs */
  #define MAX_CORE_ATTRS4   /* Maximum no of basic attrs */
  #define TOTAL_ATTRS   (MAX_CORE_ATTRS + 1)



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 3/3] ARM: dts: exynos5422-odroidxu3: Added UHS-I bus speed support

[Krzysztof Kozlowski]

On 14.10.2015 10:06, Alim Akhtar wrote:
> +Doug
> Hello,
> AFAIR, dw_mmc host controller does support UHS-I [1], specially SDR50
> and SDR104 modes.
> 
> [1]: http://www.spinics.net/lists/linux-mmc/msg28186.html
> 
> What I remember is, one need to set "broken-cd" property also in order
> to make it work because of the vqmmc and vmmc connection on board. I
> didn't find the link right now, but you can search on the web, there
> was a long discussion about handling this.
> Have not checked it recently, so not sure if this got broken somehow.
> 

Please, don't top post.

I am not a SD/MMC specialist (I do not feel enough confident in its
internals) but the datasheet for 5422 does not mention UHS. However it
mentions "High Speed DDR Mode with 200 MHz clock rate (HS400)". This
does not look like UHS...
https://www.sdcard.org/developers/overview/bus_speed/
This of course is not a definite proof that 5422 does not support UHS. I
am just saying that I couldn't find any information that *it does*.

Best regards,
Krzysztof

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2] mISDN: use kstrdup() in dsp_pipeline_build

[David Miller]

From: Geliang Tang 
Date: Mon, 12 Oct 2015 01:19:07 -0700

> Use kstrdup instead of strlen-kmalloc-strcpy. Remove unneeded NULL
> test, it will be tested inside kstrdup. Remove 0 length string test,
> it has been tested in the caller of dsp_pipeline_build.
> 
> Signed-off-by: Geliang Tang 
> ---
> Changes in v2:
>   - Remove unneeded NULL test.

Applied, thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v4 3/3] arm64: dts: mt8173: Add nor flash node

[Daniel Kurtz]

Sergei,

On Tue, Oct 13, 2015 at 10:33 PM, Sergei Shtylyov
 wrote:
> Hello.
>
> On 10/13/2015 12:39 PM, Bayi Cheng wrote:
>
>> Add Mediatek nor flash node
>>
>> Signed-off-by: Bayi Cheng 
>> ---
>>   arch/arm64/boot/dts/mediatek/mt8173.dtsi | 15 +++
>>   1 file changed, 15 insertions(+)
>>
>> diff --git a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
>> b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
>> index d18ee42..385c2e4 100644
>> --- a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
>> +++ b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
>> @@ -365,6 +365,21 @@
>> status = "disabled";
>> };
>>
>> +   nor_flash: spi@1100d000 {
>
>
>I don't think this is a good label name for a SPI controller.

You think "spi" is not a good name for SPI controller?
Or you mean the label "nor_flash"?

Would you prefer:

  spi_nor_flash: spi@1100d000


>
>> +   compatible = "mediatek,mt8173-nor";
>> +   reg = <0 0x1100d000 0 0xe0>;
>> +   clocks = < CLK_PERI_SPI>,
>> +< CLK_TOP_SPINFI_IFR_SEL>;
>> +   clock-names = "spi", "sf";
>> +   #address-cells = <1>;
>> +   #size-cells = <0>;
>> +
>> +   flash@0 {
>> +   compatible = "jedec,spi-nor";
>> +   reg = <0>;
>> +   };
>> +   };
>> +
>> i2c3: i2c3@1101 {
>
>
>Grr, the name should be "i2c@1101".

Don't worry.  This is already fixed in Matthias' tree:
  
https://github.com/mbgg/linux-mediatek/commit/1ee35c05d9c67771d649f687e6f76e61e76eb779

-Dan

>
> [...]
>
> MBR, Sergei
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 3/3] ARM: dts: exynos5422-odroidxu3: Added UHS-I bus speed support

[Alim Akhtar]

+Doug
Hello,
AFAIR, dw_mmc host controller does support UHS-I [1], specially SDR50
and SDR104 modes.

[1]: http://www.spinics.net/lists/linux-mmc/msg28186.html

What I remember is, one need to set "broken-cd" property also in order
to make it work because of the vqmmc and vmmc connection on board. I
didn't find the link right now, but you can search on the web, there
was a long discussion about handling this.
Have not checked it recently, so not sure if this got broken somehow.


Regards,
Alim


On Wed, Oct 14, 2015 at 5:29 AM, Krzysztof Kozlowski
 wrote:
> On 14.10.2015 01:27, Anand Moon wrote:
>> Hi Krzysztof,
>>
>> On 13 October 2015 at 09:13, Krzysztof Kozlowski
>>  wrote:
>>>
>>> On 13.10.2015 12:08, Anand Moon wrote:
 Hi Krzysztof,

 On 13 October 2015 at 05:44, Krzysztof Kozlowski
  wrote:
> On 13.10.2015 00:32, Anand Moon wrote:
>> Hi Krzysztof,
>>
>> On 12 October 2015 at 11:14, Krzysztof Kozlowski
>>  wrote:
>>> On 12.10.2015 00:46, Anand Moon wrote:
 Added support for UHS-I bus speed 50MB/s (SDR50, DDR50) 104MB/s 
 (SDR104)
>>>
>>> This description is not entirely correct. The MMC driver already
>>> supports these UHS speeds (you did not any code) so you rather enabled
>>> it (description of bindings says "is supported").
>>>
>>> You mentioned DDR50 but I don't see respective property below.
>>>
>>> How do you know that these modes are really supported? I don't know. Can
>>> you convince me?
>>
>> Setting this DDR50 capability give me this error. That's the reason to
>> drop this capability.
>
> But you mentioned it in commit message! "Added support for UHS-I ...
> (DDR50)"
>
> In the same time dropping DDR50 is not an sufficient proof that "SDR50
> and SDR104 are really supported".
>

 These changes are related to the microSD card capabilities.
 So SDR50 have better frequency over DDR50. On the same Sandisk card.

 When the card select the capability for DDR50
 ---
 [4.001477] mmc_host mmc1: Bus speed (slot 0) = 5000Hz (slot
 req 5000Hz, actual 5000HZ div = 0)
 [4.001604] mmc1: new ultra high speed DDR50 SDHC card at address 
 [4.004505] mmcblk0: mmc1: SL32G 29.7 GiB
 [4.009179] mmcblk0: error -110 sending status command, retrying
 [4.009271] mmcblk0: error -115 sending stop command, original cmd
 response 0x900, card status 0x900
 [4.009275] mmcblk0: error -84 transferring data, sector 0, nr 8,
 cmd response 0x900, card status 0x0
 [4.025563] mmc_host mmc1: Bus speed (slot 0) = 5000Hz (slot
 req 40Hz, actual 396825HZ div = 63)
 [4.067770] Console: switching to colour frame buffer device 274x77
 [4.098782] mmc_host mmc1: Bus speed (slot 0) = 5000Hz (slot
 req 5000Hz, actual 5000HZ div = 0)
 [4.099692] mmc1: tried to reset card
 [4.101332]  mmcblk0: p1 p2


 When the card select the capability for SDR50
 -
 [ 2.439806] mmc_host mmc1: Bus speed (slot 0) = 1Hz (slot req
 1Hz, actual 1HZ div = 0)
 [ 2.449729] mmc1: new ultra high speed SDR50 SDHC card at address 
 [ 2.455984] mmcblk0: mmc1: SL32G 29.7 GiB
 [ 2.461743] mmcblk0: p1 p2

 Which will relate to better read/write speed.
>>>
>>> Which is not an answer to my question. To none of my previous questions.
>>>
>>
>> Basically UHS-I capability  (sd-uhs-sdr12, sd-uhs-sdr25, sd-uhs-sdr50,
>> sd-uhs-sdr104) help tune speed supported for mmc
>>
>> I have tired to compare the speed on high speed UHS-I vs ultra high
>> speed UHS-I using izone utility.
>>
>> [2.572469] mmc_host mmc1: Bus speed (slot 0) = 5000Hz (slot
>> req 5000Hz, actual 5000HZ div = 0)
>> [2.572609] mmc1: new high speed SDHC card at address 
>>
>>   Command line used: ./iozone -L64 -S32 -azecwI -+n -r4k -r64k
>> -r128k -s10M -i0 -i1 -i2 -f datafile -Rb out.xls
>> Output is in kBytes/sec
>> Time Resolution = 0.01 seconds.
>> Processor cache size set to 32 kBytes.
>> Processor cache line size set to 64 bytes.
>> File stride size set to 17 * record size.
>>   random
>>  random bkwdrecordstride
>>   kB  reclenwrite  rewritereadrereadread
>>   write read   rewrite  read   fwrite frewritefread
>> freread
>>10240   4 16310 65560 5538  
>> 982
>>10240  64 8828018897017994  
>> 303
>>10240 128 6269020670020128 
>> 1096
>> 

Re: Crypto Fixes for 4.3

[Herbert Xu]

On Tue, Oct 13, 2015 at 10:23:39AM -0700, Linus Torvalds wrote:
>
> Hmm. It looks like you also quietly added a ahash fix this morning.
> 
> I took it despite it not being described or in the diffstat. But
> please send new pull requests when you update a branch you asked me to
> pull.

Oops, I should've waited for you to pull the previous one before
pushing this one out.

Anyway, this one is meant to fix a potential crash that can be
triggered by user-space but only if you have the relevant hardware,
in particular, Marvell CESA on ARM.

Thanks,
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v3 4/6] powerpc: atomic: Implement atomic{,64}_*_return_* variants

[Boqun Feng]

On Tue, Oct 13, 2015 at 09:35:54PM +0800, Boqun Feng wrote:
> On Tue, Oct 13, 2015 at 02:21:32PM +0100, Will Deacon wrote:
> > On Mon, Oct 12, 2015 at 10:14:04PM +0800, Boqun Feng wrote:
> [snip]
> > > +/*
> > > + * Since {add,sub}_return_relaxed and xchg_relaxed are implemented with
> > > + * a "bne-" instruction at the end, so an isync is enough as a acquire 
> > > barrier
> > > + * on the platform without lwsync.
> > > + */
> > > +#ifdef CONFIG_SMP
> > > +#define smp_acquire_barrier__after_atomic() \
> > > + __asm__ __volatile__(PPC_ACQUIRE_BARRIER : : : "memory")
> > 
> > I'm not keen on this barrier, as it sounds like it's part of the kernel
> > memory model, as opposed to an implementation detail on PowerPC (and
> > we've already got enough of that in the generic code ;).
> > 
> 
> Indeed, but we still have smp_lwsync() ;-)
> 
> > Can you name it something different please (and maybe #undef it when
> > you're done)?
> > 
> 
> I've considered #undef it after used, but now I think open code this
> into __atomic_op_acquire() of PPC is a better idea?
> 
> 
> #define __atomic_op_acquire(op, args...)  \
> ({\
>   typeof(op##_relaxed(args)) __ret  = op##_relaxed(args); \
>   __asm__ __volatile__(PPC_ACQUIRE_BARRIER : : : "memory");   \

Should be:
__asm__ __volatile__(PPC_ACQUIRE_BARRIER "" : : : "memory");

>   __ret;  \
> })
> 
> PPC_ACQUIRE_BARRIER will be empty if !SMP, so that will become a pure
> compiler barrier and just what we need.
> 
> Regards,
> Boqun


signature.asc
Description: PGP signature

Re: [PATCH 1/5] ftrace: remove redundant strsep in mod_callback

[Steven Rostedt]

On Tue, 29 Sep 2015 19:46:12 +0300
Dmitry Safonov <0x7f454...@gmail.com> wrote:
  
> - ret = ftrace_match_module_records(hash, func, mod);
> - if (!ret)
> - ret = -EINVAL;
> + ret = ftrace_match_module_records(hash, func, param);
> + if (ret == 0)

Small nit, personally, I prefer the if (!ret) version.

For me "== 0" is for counters and strcmp. I may change this to be
consistent with the rest of the code.

-- Steve

> + return -EINVAL;
>   if (ret < 0)
>   return ret;
>  

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH RESEND v3 1/6] powerpc: atomic: Make *xchg and *cmpxchg a full barrier

[Boqun Feng]

On Wed, Oct 14, 2015 at 11:10:00AM +1100, Michael Ellerman wrote:
> On Mon, 2015-10-12 at 22:30 +0800, Boqun Feng wrote:
> > According to memory-barriers.txt, xchg, cmpxchg and their atomic{,64}_
> > versions all need to imply a full barrier, however they are now just
> > RELEASE+ACQUIRE, which is not a full barrier.
> > 
> > So replace PPC_RELEASE_BARRIER and PPC_ACQUIRE_BARRIER with
> > PPC_ATOMIC_ENTRY_BARRIER and PPC_ATOMIC_EXIT_BARRIER in
> > __{cmp,}xchg_{u32,u64} respectively to guarantee a full barrier
> > semantics of atomic{,64}_{cmp,}xchg() and {cmp,}xchg().
> > 
> > This patch is a complement of commit b97021f85517 ("powerpc: Fix
> > atomic_xxx_return barrier semantics").
> > 
> > Cc:  # 3.4.y-
> > Signed-off-by: Boqun Feng 
> > ---
> >  arch/powerpc/include/asm/cmpxchg.h | 16 
> >  1 file changed, 8 insertions(+), 8 deletions(-)
> 
> Hi Boqun,
> 

Hello, Michael

> Thanks for fixing this. In future you should send a patch like this as a
> separate patch. I've not been paying attention to it because I assumed it was

Got it. However, here is the thing, in previous version, this fix
depends on some of other patches in this patchset. So to make this fix
applied cleanly, I reorder my patchset to put this patch first, and the
result is that some of other patches in this patchset depends on
this(they need to remove code modified by this patch).

So I guess I'd better to stop Cc stable for this one, and wait until
this patchset merged and send a separate patch for -stable tree. Does
that work for you? I think this is what Peter want to suggests me to do
when he asked me about this, right, Peter?

> part of your full series and was still under discussion like the other 
> patches.
> 
> I don't think we've seen any crashes caused by this have we? So I guess I'll

No, we haven't seen any.

> put it in next to let it get some wider testing rather than sending it 
> straight
> to Linus.
> 

Good idea, thank you ;-)

> To be clear you're doing:
> 
> > -   PPC_RELEASE_BARRIER
> > +   PPC_ATOMIC_ENTRY_BARRIER
> 
> Which is correct but doesn't actually change anything at the moment, because
> both macros turn into LWSYNC.
> 
> On the other hand:
> 
> > -   PPC_ACQUIRE_BARRIER
> > +   PPC_ATOMIC_EXIT_BARRIER
> 
> Is changing an isync (which is then patched to lwsync on some cpus), with a 
> sync.
> 

These macros are introduced by commit b97021f85517 ("powerpc: Fix
atomic_xxx_return barrier semantics") to fix a similar problem, so I use
them to keep code similar.

> 
> Also I'm not clear what your stable line means:
> 
> > Cc:  # 3.4.y-
> 
> Do you mean 3.4 and anything after? I usually write that as 3.4+, but I'm not
> sure if that's the correct syntax either.
> 

Quote from Documentation/stable_kernel_rules.txt:

"""
Also, some patches may have kernel version prerequisites.  This can be
specified in the following format in the sign-off area:

 Cc:   # 3.3.x-

   The tag has the meaning of:
 git cherry-pick 

   For each "-stable" tree starting with the specified version.
"""

But yes, I have seen several people use like "3.4+", I'm not sure either

Regards,
Boqun


signature.asc
Description: PGP signature

Re: 4.3-rc3 BAR allocation problems on multiple machines

[Yinghai Lu]

On Tue, Oct 13, 2015 at 1:39 PM, Meelis Roos  wrote:
>
> 0001:00:07.0 ISA bridge: ULi Electronics Inc. M1533/M1535/M1543 PCI to ISA 
> Bridge [Aladdin IV/V/V+]
> Control: I/O+ Mem+ BusMaster+ SpecCycle+ MemWINV- VGASnoop- ParErr- 
> Stepping- SERR- FastB2B- DisINTx-
> Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- 
> SERR-  Latency: 0
> Region 0: [virtual] I/O ports at  [size=64K]
> Region 1: Memory at  (32-bit, non-prefetchable) [size=1M]
> Region 2: Memory at  (32-bit, non-prefetchable) [size=1M]
> Region 3: [virtual] Memory at f801 (32-bit, 
> non-prefetchable)
> Region 4: [virtual] Memory at f801 (32-bit, 
> non-prefetchable)
> Region 5: [virtual] Memory at f801 (32-bit, 
> non-prefetchable)
> [virtual] Expansion ROM at f801 [disabled]
> Capabilities: [a0] Power Management version 1
> Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA 
> PME(D0-,D1-,D2-,D3hot-,D3cold-)
> Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
> 00: b9 10 33 15 0f 00 10 02 00 00 01 06 00 00 00 00
> 10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 30: 00 00 00 00 a0 00 00 00 00 00 00 00 00 00 00 00
> 40: 03 13 4b 80 83 09 00 47 00 00 06 00 00 00 eb 31
> 50: 00 00 00 20 90 02 20 03 66 03 00 00 00 00 00 08
> 60: 40 00 00 00 00 00 00 00 00 00 00 00 80 20 00 00
> 70: 00 00 0a 00 47 00 00 db 04 02 00 04 00 80 01 90
> 80: a5 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> a0: 01 00 01 00 00 00 00 00 00 00 00 00 00 00 00 00
> b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

Please check attached patch.

Thanks

Yinghai
Subject: [PATCH] PCI: Ignore BAR for ALi M1533 PCI-ISA bridge

Meelis reported strange conflicts on sparc v210:
pci 0001:00:07.0: can't claim BAR 2 [mem 0x7ff-0x7ff000f]: address conflict with 0001:00:07.0 [mem 0x7ff-0x7ff000f]
pci 0001:00:06.0: can't claim BAR 0 [io 0x7fe0100-0x7fe010f]: address conflict with 0001:00:07.0 [io 0x7fe0100-0x7fe0100]
pci 0001:00:0d.0: can't claim BAR 0 [io 0x7fe01000900-0x7fe01000907]: address conflict with 0001:00:07.0 [io 0x7fe0100-0x7fe0100]
pci 0001:00:0d.0: can't claim BAR 1 [io 0x7fe01000918-0x7fe0100091f]: address conflict with 0001:00:07.0 [io 0x7fe0100-0x7fe0100]
pci 0001:00:0d.0: can't claim BAR 2 [io 0x7fe01000910-0x7fe01000917]: address conflict with 0001:00:07.0 [io 0x7fe0100-0x7fe0100]
pci 0001:00:0d.0: can't claim BAR 3 [io 0x7fe01000908-0x7fe0100090f]: address conflict with 0001:00:07.0 [io 0x7fe0100-0x7fe0100]
pci 0001:00:0d.0: can't claim BAR 4 [io 0x7fe01000920-0x7fe0100092f]: address conflict with 0001:00:07.0 [io 0x7fe0100-0x7fe0100]
PCI: /pci@1e,60 can't claim Video RAM area [mem 0x7ff000a-0x7ff000b]: address conflict with 0001:00:07.0 [mem 0x7ff-0x7ff000f]
PCI: /pci@1e,60 can't claim System ROM [mem 0x7ff000f-0x7ff000f]: address conflict with 0001:00:07.0 [mem 0x7ff-0x7ff000f]
PCI: /pci@1e,60 can't claim Video ROM [mem 0x7ff000c-0x7ff000c7fff]: address conflict with 0001:00:07.0 [mem 0x7ff-0x7ff000f]

we have
pci_bus 0001:00: root bus resource [io  0x7fe0100-0x7fe01ff] (bus address [0x-0xff])
pci_bus 0001:00: root bus resource [mem 0x7ff-0x7ff] (bus address [0x-0x])

so pci bus address in the bars for 0001:00:07.0 has all 0s.

0001:00:07.0 ISA bridge: ULi Electronics Inc. M1533/M1535/M1543 PCI to ISA Bridge [Aladdin IV/V/V+]
Region 0: [virtual] I/O ports at  [size=64K]
Region 1: Memory at  (32-bit, non-prefetchable) [size=1M]
Region 2: Memory at  (32-bit, non-prefetchable) [size=1M]
00: b9 10 33 15 0f 00 10 02 00 00 01 06 00 00 00 00
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
30: 00 00 00 00 a0 00 00 00 00 00 00 00 00 00 00 00

According to http://www.versalogic.com/Support/Downloads/pdf/ali1543.pdf
page 28: The indices before 40h are read-only.
and we have all 0 from 0x10-0x2f, according to lspci.

So clean flags, and ignore them all the way include
claim and sizing and alloc etc.

Reported-by: Meelis Roos 
Signed-off-by: Yinghai Lu 

---
 drivers/pci/quirks.c |   15 +++
 1 file changed, 15 insertions(+)

Index: linux-2.6/drivers/pci/quirks.c
===
--- linux-2.6.orig/drivers/pci/quirks.c
+++ linux-2.6/drivers/pci/quirks.c
@@ -470,6 +470,21 @@ static void quirk_amd_nl_class(struct pc
 

Re: [PATCH 2/4] perf/x86: add support for PERF_SAMPLE_BRANCH_CALL

[Stephane Eranian]

On Tue, Oct 13, 2015 at 6:40 AM, Ingo Molnar  wrote:
>
>
> * Stephane Eranian  wrote:
>
> > This patch enables the suport for the PERF_SAMPLE_BRANCH_CALL
> > for Intel x86 processors. When the processor support LBR filtering
> > this the selection is done in hardware. Otherwise, the filter is
> > applied by software. Note that we chose to include zero length calls
> > because they also represent calls.
> >
> > Signed-off-by: Stephane Eranian 
> > ---
> >  arch/x86/kernel/cpu/perf_event_intel_lbr.c | 4 
> >  1 file changed, 4 insertions(+)
> >
> > diff --git a/arch/x86/kernel/cpu/perf_event_intel_lbr.c 
> > b/arch/x86/kernel/cpu/perf_event_intel_lbr.c
> > index ad0b8b0..bfd0b71 100644
> > --- a/arch/x86/kernel/cpu/perf_event_intel_lbr.c
> > +++ b/arch/x86/kernel/cpu/perf_event_intel_lbr.c
> > @@ -555,6 +555,8 @@ static int intel_pmu_setup_sw_lbr_filter(struct 
> > perf_event *event)
> >   if (br_type & PERF_SAMPLE_BRANCH_IND_JUMP)
> >   mask |= X86_BR_IND_JMP;
> >
> > + if (br_type & PERF_SAMPLE_BRANCH_CALL)
> > + mask |= X86_BR_CALL | X86_BR_ZERO_CALL;
>
> I'm wondering how frequent zero-length calls are. If they still occur in 
> typical
> user-space, would it make sense to also have a separate branch sampling type 
> for
> zero length calls?
>
We could add that. It would rely on the sw filter to catch only the
zero calls as Andi
mentioned. But I am wondering about the data quality because we would catch zero
calls without being able to determine how many we sampled vs. how many have
occurred. There is no PMU event counting zero call branches.

> Intel documents zero length calls as ones that (ab-)use the call instruction 
> to
> push the current IP on the stack:
>
> call next_addr
> next_addr:
> pop %reg
>
> which can take over 10 cycles on certain microarchitectures (and it unbalances
> whatever call stack tracking/caching the CPU does as well).
>
> So it might make sense to analyze them separately. I guess that's the reason 
> why
> Intel added a separate flag for them in the PMU.
>
> Thanks,
>
> Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/