* [U-Boot] [UBOOT PATCH v2] net: zynq_gem: convert to use livetree
From: Michal Simek @ 2018-07-24 8:58 UTC (permalink / raw)
To: u-boot
In-Reply-To: <BN1PR02MB101A8BE4AAE6B40F4106905D9560@BN1PR02MB101.namprd02.prod.outlook.com>
Hi,
On 23.7.2018 07:48, Siva Durga Prasad Paladugu wrote:
> Hi Joe/Michal,
>
> Can you please take it up if it is fine.
joe: Can you please take it via your tree?
There are some patches before this.
Thanks,
Michal
^ permalink raw reply
* [U-Boot] [PATCH v3 5/5] sandbox: led: use new function to configure default state
From: Patrick Delaunay @ 2018-07-24 8:58 UTC (permalink / raw)
To: u-boot
In-Reply-To: <1532422712-15107-1-git-send-email-patrick.delaunay@st.com>
Initialize the led with the default state defined in device tree
in board_init and solve issue with test for led default state.
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>
---
Led default-state is correctly handle in Sandbox, tested with:
./u-boot -d ./arch/sandbox/dts/test.dtb
=> led list
sandbox:red <inactive>
sandbox:green <inactive>
sandbox:default_on on
sandbox:default_off off
This patch solve "make tests" issue introduced by
http://patchwork.ozlabs.org/patch/943651/
Changes in v3: None
Changes in v2:
- add sandbox impact and test update
board/sandbox/sandbox.c | 9 +++++++++
common/board_r.c | 3 ++-
test/dm/led.c | 3 +++
3 files changed, 14 insertions(+), 1 deletion(-)
diff --git a/board/sandbox/sandbox.c b/board/sandbox/sandbox.c
index 195f620..66b5f24 100644
--- a/board/sandbox/sandbox.c
+++ b/board/sandbox/sandbox.c
@@ -6,6 +6,7 @@
#include <common.h>
#include <cros_ec.h>
#include <dm.h>
+#include <led.h>
#include <os.h>
#include <asm/test.h>
#include <asm/u-boot-sandbox.h>
@@ -47,6 +48,14 @@ int dram_init(void)
return 0;
}
+int board_init(void)
+{
+#ifdef CONFIG_LED
+ led_default_state();
+#endif /* CONFIG_LED */
+ return 0;
+}
+
#ifdef CONFIG_BOARD_LATE_INIT
int board_late_init(void)
{
diff --git a/common/board_r.c b/common/board_r.c
index 64f2574..9402c0e 100644
--- a/common/board_r.c
+++ b/common/board_r.c
@@ -690,7 +690,8 @@ static init_fnc_t init_sequence_r[] = {
#ifdef CONFIG_DM
initr_dm,
#endif
-#if defined(CONFIG_ARM) || defined(CONFIG_NDS32) || defined(CONFIG_RISCV)
+#if defined(CONFIG_ARM) || defined(CONFIG_NDS32) || defined(CONFIG_RISCV) || \
+ defined(CONFIG_SANDBOX)
board_init, /* Setup chipselects */
#endif
/*
diff --git a/test/dm/led.c b/test/dm/led.c
index 0071f21..00de7b3 100644
--- a/test/dm/led.c
+++ b/test/dm/led.c
@@ -32,6 +32,9 @@ static int dm_test_led_default_state(struct unit_test_state *uts)
{
struct udevice *dev;
+ /* configure the default state (auto-probe) */
+ led_default_state();
+
/* Check that we handle the default-state property correctly. */
ut_assertok(led_get_by_label("sandbox:default_on", &dev));
ut_asserteq(LEDST_ON, led_get_state(dev));
--
2.7.4
^ permalink raw reply related
* [U-Boot] [PATCH v3 4/5] stm32mp1: use new function led default state
From: Patrick Delaunay @ 2018-07-24 8:58 UTC (permalink / raw)
To: u-boot
In-Reply-To: <1532422712-15107-1-git-send-email-patrick.delaunay@st.com>
Initialize the led with the default state defined in device tree.
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>
---
Changes in v3:
- minor update after Simon review
- include led.h to avoid compilation warning on stm32mp1 board
Changes in v2: None
board/st/stm32mp1/stm32mp1.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/board/st/stm32mp1/stm32mp1.c b/board/st/stm32mp1/stm32mp1.c
index cc39fa6..bfc8ab6 100644
--- a/board/st/stm32mp1/stm32mp1.c
+++ b/board/st/stm32mp1/stm32mp1.c
@@ -4,6 +4,7 @@
*/
#include <config.h>
#include <common.h>
+#include <led.h>
#include <asm/arch/stm32.h>
/*
@@ -22,5 +23,8 @@ int board_init(void)
/* address of boot parameters */
gd->bd->bi_boot_params = STM32_DDR_BASE + 0x100;
+ if (IS_ENABLED(CONFIG_LED))
+ led_default_state();
+
return 0;
}
--
2.7.4
^ permalink raw reply related
* [U-Boot] [PATCH v3 3/5] dm: led: move default state support in led uclass
From: Patrick Delaunay @ 2018-07-24 8:58 UTC (permalink / raw)
To: u-boot
In-Reply-To: <1532422712-15107-1-git-send-email-patrick.delaunay@st.com>
This patch save common LED property "default-state" value
in post bind of LED uclass.
The configuration for this default state is only performed when
led_default_state() is called;
It can be called in your board_init()
or it could added in init_sequence_r[] in future.
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>
---
Changes in v3: None
Changes in v2: None
drivers/led/led-uclass.c | 54 ++++++++++++++++++++++++++++++++++++++++++++++++
drivers/led/led_gpio.c | 8 -------
include/led.h | 23 +++++++++++++++++++++
3 files changed, 77 insertions(+), 8 deletions(-)
diff --git a/drivers/led/led-uclass.c b/drivers/led/led-uclass.c
index 2f4d69e..141401d 100644
--- a/drivers/led/led-uclass.c
+++ b/drivers/led/led-uclass.c
@@ -8,6 +8,7 @@
#include <dm.h>
#include <errno.h>
#include <led.h>
+#include <dm/device-internal.h>
#include <dm/root.h>
#include <dm/uclass-internal.h>
@@ -63,8 +64,61 @@ int led_set_period(struct udevice *dev, int period_ms)
}
#endif
+static int led_post_bind(struct udevice *dev)
+{
+ struct led_uc_plat *uc_pdata;
+ const char *default_state;
+
+ uc_pdata = dev_get_uclass_platdata(dev);
+
+ /* common optional properties */
+ uc_pdata->default_state = LED_DEF_NO;
+ default_state = dev_read_string(dev, "default-state");
+ if (default_state) {
+ if (!strncmp(default_state, "on", 2))
+ uc_pdata->default_state = LED_DEF_ON;
+ else if (!strncmp(default_state, "off", 3))
+ uc_pdata->default_state = LED_DEF_OFF;
+ else if (!strncmp(default_state, "keep", 4))
+ uc_pdata->default_state = LED_DEF_KEEP;
+ }
+
+ return 0;
+}
+
+int led_default_state(void)
+{
+ struct udevice *dev;
+ struct uclass *uc;
+ struct led_uc_plat *uc_pdata;
+ int ret;
+
+ ret = uclass_get(UCLASS_LED, &uc);
+ if (ret)
+ return ret;
+ for (uclass_find_first_device(UCLASS_LED, &dev);
+ dev;
+ uclass_find_next_device(&dev)) {
+ uc_pdata = dev_get_uclass_platdata(dev);
+ if (!uc_pdata || uc_pdata->default_state == LED_DEF_NO)
+ continue;
+ ret = device_probe(dev);
+ if (ret)
+ return ret;
+ if (uc_pdata->default_state == LED_DEF_ON)
+ led_set_state(dev, LEDST_ON);
+ else if (uc_pdata->default_state == LED_DEF_OFF)
+ led_set_state(dev, LEDST_OFF);
+ printf("%s: default_state=%d\n",
+ uc_pdata->label, uc_pdata->default_state);
+ }
+
+ return ret;
+}
+
UCLASS_DRIVER(led) = {
.id = UCLASS_LED,
.name = "led",
+ .post_bind = led_post_bind,
.per_device_platdata_auto_alloc_size = sizeof(struct led_uc_plat),
};
diff --git a/drivers/led/led_gpio.c b/drivers/led/led_gpio.c
index 533587d..93f6b91 100644
--- a/drivers/led/led_gpio.c
+++ b/drivers/led/led_gpio.c
@@ -57,7 +57,6 @@ static int led_gpio_probe(struct udevice *dev)
{
struct led_uc_plat *uc_plat = dev_get_uclass_platdata(dev);
struct led_gpio_priv *priv = dev_get_priv(dev);
- const char *default_state;
int ret;
/* Ignore the top-level LED node */
@@ -68,13 +67,6 @@ static int led_gpio_probe(struct udevice *dev)
if (ret)
return ret;
- default_state = dev_read_string(dev, "default-state");
- if (default_state) {
- if (!strncmp(default_state, "on", 2))
- gpio_led_set_state(dev, LEDST_ON);
- else if (!strncmp(default_state, "off", 3))
- gpio_led_set_state(dev, LEDST_OFF);
- }
return 0;
}
diff --git a/include/led.h b/include/led.h
index 940b97f..ff45f03 100644
--- a/include/led.h
+++ b/include/led.h
@@ -8,12 +8,27 @@
#define __LED_H
/**
+ * enum led_default_state - The initial state of the LED.
+ * see Documentation/devicetree/bindings/leds/common.txt
+ */
+enum led_def_state_t {
+ LED_DEF_NO,
+ LED_DEF_ON,
+ LED_DEF_OFF,
+ LED_DEF_KEEP
+};
+
+/**
* struct led_uc_plat - Platform data the uclass stores about each device
*
* @label: LED label
+ * @default_state* - The initial state of the LED.
+ see Documentation/devicetree/bindings/leds/common.txt
+ * * - set automatically on device bind by the uclass's '.post_bind' method.
*/
struct led_uc_plat {
const char *label;
+ enum led_def_state_t default_state;
};
/**
@@ -106,4 +121,12 @@ enum led_state_t led_get_state(struct udevice *dev);
*/
int led_set_period(struct udevice *dev, int period_ms);
+/**
+ * led_default_state() - set the default state for all the LED
+ *
+ * This enables all leds which have default state.
+ *
+ */
+int led_default_state(void);
+
#endif
--
2.7.4
^ permalink raw reply related
* [U-Boot] [PATCH v3 2/5] Revert "dm: led: auto probe() LEDs with "default-state""
From: Patrick Delaunay @ 2018-07-24 8:58 UTC (permalink / raw)
To: u-boot
In-Reply-To: <1532422712-15107-1-git-send-email-patrick.delaunay@st.com>
This reverts commit bc882f5d5c7b4d6ed5e927bf838863af43c786e7.
because this patch adds the probe of LED driver during the
binding phasis. It is not allowed in driver model because
the drivers (clock, pincontrol) needed by the LED driver can
be also probed before the binding of all the device and
it is a source of problems.
Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>
---
Changes in v3:
- add motivation in revert commit
Changes in v2: None
drivers/led/led_gpio.c | 9 ---------
1 file changed, 9 deletions(-)
diff --git a/drivers/led/led_gpio.c b/drivers/led/led_gpio.c
index a36942b..533587d 100644
--- a/drivers/led/led_gpio.c
+++ b/drivers/led/led_gpio.c
@@ -10,7 +10,6 @@
#include <led.h>
#include <asm/gpio.h>
#include <dm/lists.h>
-#include <dm/uclass-internal.h>
struct led_gpio_priv {
struct gpio_desc gpio;
@@ -118,14 +117,6 @@ static int led_gpio_bind(struct udevice *parent)
return ret;
uc_plat = dev_get_uclass_platdata(dev);
uc_plat->label = label;
-
- if (ofnode_read_bool(node, "default-state")) {
- struct udevice *devp;
-
- ret = uclass_get_device_tail(dev, 0, &devp);
- if (ret)
- return ret;
- }
}
return 0;
--
2.7.4
^ permalink raw reply related
* Re: [PATCH 4.17 00/63] 4.17.10-stable review
From: Greg Kroah-Hartman @ 2018-07-24 8:58 UTC (permalink / raw)
To: Naresh Kamboju
Cc: open list, Linus Torvalds, Andrew Morton, Guenter Roeck,
Shuah Khan, patches, Ben Hutchings, lkft-triage, linux- stable
In-Reply-To: <CA+G9fYurRz+s2hD4-=2L2z2Z7VGHV2sgktxvnO=vkN4N8CafxQ@mail.gmail.com>
On Tue, Jul 24, 2018 at 01:08:12PM +0530, Naresh Kamboju wrote:
> On 23 July 2018 at 17:54, Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote:
> > This is the start of the stable review cycle for the 4.17.10 release.
> > There are 63 patches in this series, all will be posted as a response
> > to this one. If anyone has any issues with these being applied, please
> > let me know.
> >
> > Responses should be made by Wed Jul 25 12:24:28 UTC 2018.
> > Anything received after that time might be too late.
> >
> > The whole patch series can be found in one patch at:
> > https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.17.10-rc1.gz
> > or in the git tree and branch at:
> > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.17.y
> > and the diffstat can be found below.
> >
> > thanks,
> >
> > greg k-h
>
> Results from Linaro’s test farm.
> No regressions on arm64, arm and x86_64.
Thanks for testing all of these and letting me know.
greg k-h
^ permalink raw reply
* [U-Boot] [PATCH v3 1/5] stm32mp1: add gpio led support
From: Patrick Delaunay @ 2018-07-24 8:58 UTC (permalink / raw)
To: u-boot
In-Reply-To: <1532422712-15107-1-git-send-email-patrick.delaunay@st.com>
This patch add the 4 LED available on the ED1 board and activated
gpio led driver.
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>
---
Changes in v3: None
Changes in v2: None
arch/arm/dts/stm32mp157c-ed1-u-boot.dtsi | 24 ++++++++++++++++++++++++
configs/stm32mp15_basic_defconfig | 2 ++
2 files changed, 26 insertions(+)
diff --git a/arch/arm/dts/stm32mp157c-ed1-u-boot.dtsi b/arch/arm/dts/stm32mp157c-ed1-u-boot.dtsi
index 39a0ebc..4898483 100644
--- a/arch/arm/dts/stm32mp157c-ed1-u-boot.dtsi
+++ b/arch/arm/dts/stm32mp157c-ed1-u-boot.dtsi
@@ -13,6 +13,30 @@
mmc1 = &sdmmc2;
i2c3 = &i2c4;
};
+
+ led {
+ compatible = "gpio-leds";
+
+ red {
+ label = "stm32mp:red:status";
+ gpios = <&gpioa 13 GPIO_ACTIVE_LOW>;
+ default-state = "off";
+ };
+ green {
+ label = "stm32mp:green:user";
+ gpios = <&gpioa 14 GPIO_ACTIVE_LOW>;
+ default-state = "on";
+ };
+ orange {
+ label = "stm32mp:orange:status";
+ gpios = <&gpioh 7 GPIO_ACTIVE_HIGH>;
+ default-state = "off";
+ };
+ blue {
+ label = "stm32mp:blue:user";
+ gpios = <&gpiod 11 GPIO_ACTIVE_HIGH>;
+ };
+ };
};
&uart4_pins_a {
diff --git a/configs/stm32mp15_basic_defconfig b/configs/stm32mp15_basic_defconfig
index c72a440..2cac114 100644
--- a/configs/stm32mp15_basic_defconfig
+++ b/configs/stm32mp15_basic_defconfig
@@ -29,6 +29,8 @@ CONFIG_CMD_EXT4_WRITE=y
# CONFIG_SPL_DOS_PARTITION is not set
CONFIG_DM_I2C=y
CONFIG_SYS_I2C_STM32F7=y
+CONFIG_LED=y
+CONFIG_LED_GPIO=y
CONFIG_DM_MMC=y
CONFIG_STM32_SDMMC2=y
# CONFIG_PINCTRL_FULL is not set
--
2.7.4
^ permalink raw reply related
* [U-Boot] [PATCH v3 0/5] dm: led: remove auto probe in binding function
From: Patrick Delaunay @ 2018-07-24 8:58 UTC (permalink / raw)
To: u-boot
Hi,
The commit bc882f5d5c7b4d6ed5e927bf838863af43c786e7
introduce auto probe of LED in binding function
but that cause issue on my board.
This first patch of this patchset activateis the LED on my board
to explain the issue, the second patch revert this commit and
the third one propose an other solution.
For me, this commit is a error because in README of doc/driver-model/
it is indicated:
The device's bind() method is permitted to perform simple actions, but
should not scan the device tree node, not initialise hardware, nor set up
structures or allocate memory. All of these tasks should be left for
the probe() method.
And in the patch the LED driver is probed during the binding scan.
When I activated the LED in my ARM target with the patch
"stm32mp1: add gpio led support", I have the sequence:
dm_init_and_scan() :
1/ dm_scan_fdt_node()
=> loop on all the node
2/ scan for LED node
=> probe of LED driver is forced by "default-state" detection
LED1 - "red"
=> probe of father of "red" node
A - led
B - soc
C - root
=> probe of node needed by GPIO
1 - pin-controller
2 - gpio at 50002000
3 - rcc-clk at 50000000
4 - rcc at 50000000
=> probe forced by default state for other led
LED2 - green
LED3 - orange
=> probe of node needed by GPIO (other bank)
5 - gpio at 50009000
3/ dm_extended_scan_fdt scan continue...
scan node "fixed-clock" under "/clocks"
clk-hse
clk-hsi
clk-lse
clk-lsi
clk-csi
4/ probe of all the used devices.... after dm_extended_scan_fdt()
So many driver are probed before the end of the scan binding loop !
And that cause issue in my board (boot failed) because the rcc-clk clock
driver found the input frequency with these fixed-clock, which are binded
only after the stm32mp1 clock driver probe.
For me probe in forbidden in binding function and
thus uclass_get_device_tail() is not allowed in the commit
bc882f5d5c7b4d6ed5e927bf838863af43c786e7 which need to be reverted.
In the third patch I proposed an other solution based
on the existing solution in u-class regulator used to enable
regulator with "boot on" property (see regulators_enable_boot_on function).
I think that adding a function is the better solution in the driver model
to force probe for some node according binding information
(after dm_init_and_scan call).
This new function should be called in board_init function for each board
but it could be also added in init_sequence_r[] in future.
Changes in v3:
- add motivation in revert commit
- minor update after Simon review
- include led.h to avoid compilation warning on stm32mp1 board
Changes in v2:
- add sandbox impact and test update
Patrick Delaunay (5):
stm32mp1: add gpio led support
Revert "dm: led: auto probe() LEDs with "default-state""
dm: led: move default state support in led uclass
stm32mp1: use new function led default state
sandbox: led: use new function to configure default state
arch/arm/dts/stm32mp157c-ed1-u-boot.dtsi | 24 ++++++++++++++
board/sandbox/sandbox.c | 9 ++++++
board/st/stm32mp1/stm32mp1.c | 4 +++
common/board_r.c | 3 +-
configs/stm32mp15_basic_defconfig | 2 ++
drivers/led/led-uclass.c | 54 ++++++++++++++++++++++++++++++++
drivers/led/led_gpio.c | 17 ----------
include/led.h | 23 ++++++++++++++
test/dm/led.c | 3 ++
9 files changed, 121 insertions(+), 18 deletions(-)
--
2.7.4
^ permalink raw reply
* Re: [PATCH 2/3] arm64: allwinner: dts: h6: add pinmux for MMC1
From: Icenowy Zheng @ 2018-07-24 8:57 UTC (permalink / raw)
To: Maxime Ripard
Cc: Chen-Yu Tsai, linux-arm-kernel, devicetree, linux-kernel,
linux-sunxi
In-Reply-To: <20180724085639.2cebno52qfxrzmdw@flea>
于 2018年7月24日 GMT+08:00 下午4:56:39, Maxime Ripard <maxime.ripard@bootlin.com> 写到:
>On Tue, Jul 24, 2018 at 09:15:50AM +0800, Icenowy Zheng wrote:
>> The MMC1 controller on H6, in the reference design and most third
>party
>> design, is used to connect SDIO Wi-Fi.
>>
>> Add pinmux for it.
>>
>> Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
>> ---
>> arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi | 8 ++++++++
>> 1 file changed, 8 insertions(+)
>>
>> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi
>b/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi
>> index cfa5fffcf62b..ba1a3a3e2149 100644
>> --- a/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi
>> +++ b/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi
>> @@ -134,6 +134,14 @@
>> bias-pull-up;
>> };
>>
>> + mmc1_pins: mmc1-pins {
>> + pins = "PG0", "PG1", "PG2", "PG3",
>> + "PG4", "PG5";
>> + function = "mmc1";
>> + drive-strength = <30>;
>> + bias-pull-up;
>> + };
>> +
>
>Is that the sole muxing option for MMC1? If so, it should be added to
>the mmc1 node.
Oh... yes, it is.
Will do in v2.
>
>Maxime
^ permalink raw reply
* [U-Boot] [PATCH V3 1/2] mmc: add HS400 support
From: Faiz Abbas @ 2018-07-24 8:57 UTC (permalink / raw)
To: u-boot
In-Reply-To: <AM0PR04MB44813EF0C18A49FD4963A4B688550@AM0PR04MB4481.eurprd04.prod.outlook.com>
Hi Peng,
On Tuesday 24 July 2018 02:14 PM, Peng Fan wrote:
> Hi Faiz,
>
> It's 2 months since this patchset out (:
Has it already been accepted?
> drivers/mmc/Kconfig
>>
>> On Saturday 19 May 2018 06:24 PM, Peng Fan wrote:
>>> Add HS400 support.
>>> Selecting HS400 needs first select HS199 according to spec, so use a
>>> dedicated function for HS400.
>>> Add HS400 related macros.
>>> Remove the restriction of only using the low 6 bits of
>>> EXT_CSD_CARD_TYPE, using all the 8 bits.
>>>
>>> Signed-off-by: Peng Fan <peng.fan@nxp.com>
>>> Cc: Jaehoon Chung <jh80.chung@samsung.com>
>>> Cc: Jean-Jacques Hiblot <jjhiblot@ti.com>
>>> Cc: Stefano Babic <sbabic@denx.de>
>>> Cc: Simon Glass <sjg@chromium.org>
>>> Cc: Kishon Vijay Abraham I <kishon@ti.com>
>>> Cc: Bin Meng <bmeng.cn@gmail.com>
>>> ---
>>>
>>> V3:
>>> Simplify code
>>> add error msg
>>>
>>> V2:
>>> remove 4bits support from HS400, as HS400 does not support 4bits per spec.
>>>
>>> drivers/mmc/Kconfig | 7 +++
>>> drivers/mmc/mmc.c | 137
>> +++++++++++++++++++++++++++++++++++++++++-----------
>>> include/mmc.h | 11 +++++
>>> 3 files changed, 128 insertions(+), 27 deletions(-)
>>>
>>> diff --git a/drivers/mmc/Kconfig b/drivers/mmc/Kconfig index
>>> 3f15f85efd..a535a87a8e 100644
>>> --- a/drivers/mmc/Kconfig
>>> +++ b/drivers/mmc/Kconfig
>>> @@ -104,6 +104,13 @@ config SPL_MMC_UHS_SUPPORT
>>> cards. The IO voltage must be switchable from 3.3v to 1.8v. The bus
>>> frequency can go up to 208MHz (SDR104)
>>>
>>> +config MMC_HS400_SUPPORT
>>> + bool "enable HS400 support"
>>> + select MMC_HS200_SUPPORT
>>> + help
>>> + The HS400 mode is support by some eMMC. The bus frequency is up to
>>> + 200MHz. This mode requires tuning the IO.
>>> +
>>
>> Please add SPL_MMC_HS400_SUPPORT also.
>
> What issue do you see? I did not test SPL MMC with HS400 support. You mean only add a Kconfig
> entry SPL_MMC_HS400_SUPPORT?
Yes only a Kconfig. It helps people who want to include/exclude it from
SPL. You are implicitly checking for the config in
CONFIG_IS_ENABLED(MMC_HS400_SUPPORT) below.
I was just using your patch for some out of tree development and figured
it would be useful to have the CONFIG.
Thanks,
Faiz
^ permalink raw reply
* Re: [PATCH 2/3] arm64: allwinner: dts: h6: add pinmux for MMC1
From: Icenowy Zheng @ 2018-07-24 8:57 UTC (permalink / raw)
To: Maxime Ripard
Cc: Chen-Yu Tsai, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw
In-Reply-To: <20180724085639.2cebno52qfxrzmdw@flea>
于 2018年7月24日 GMT+08:00 下午4:56:39, Maxime Ripard <maxime.ripard-LDxbnhwyfcJBDgjK7y7TUQ@public.gmane.org> 写到:
>On Tue, Jul 24, 2018 at 09:15:50AM +0800, Icenowy Zheng wrote:
>> The MMC1 controller on H6, in the reference design and most third
>party
>> design, is used to connect SDIO Wi-Fi.
>>
>> Add pinmux for it.
>>
>> Signed-off-by: Icenowy Zheng <icenowy-h8G6r0blFSE@public.gmane.org>
>> ---
>> arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi | 8 ++++++++
>> 1 file changed, 8 insertions(+)
>>
>> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi
>b/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi
>> index cfa5fffcf62b..ba1a3a3e2149 100644
>> --- a/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi
>> +++ b/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi
>> @@ -134,6 +134,14 @@
>> bias-pull-up;
>> };
>>
>> + mmc1_pins: mmc1-pins {
>> + pins = "PG0", "PG1", "PG2", "PG3",
>> + "PG4", "PG5";
>> + function = "mmc1";
>> + drive-strength = <30>;
>> + bias-pull-up;
>> + };
>> +
>
>Is that the sole muxing option for MMC1? If so, it should be added to
>the mmc1 node.
Oh... yes, it is.
Will do in v2.
>
>Maxime
--
You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit https://groups.google.com/d/optout.
^ permalink raw reply
* [PATCH 2/3] arm64: allwinner: dts: h6: add pinmux for MMC1
From: Icenowy Zheng @ 2018-07-24 8:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180724085639.2cebno52qfxrzmdw@flea>
? 2018?7?24? GMT+08:00 ??4:56:39, Maxime Ripard <maxime.ripard@bootlin.com> ??:
>On Tue, Jul 24, 2018 at 09:15:50AM +0800, Icenowy Zheng wrote:
>> The MMC1 controller on H6, in the reference design and most third
>party
>> design, is used to connect SDIO Wi-Fi.
>>
>> Add pinmux for it.
>>
>> Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
>> ---
>> arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi | 8 ++++++++
>> 1 file changed, 8 insertions(+)
>>
>> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi
>b/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi
>> index cfa5fffcf62b..ba1a3a3e2149 100644
>> --- a/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi
>> +++ b/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi
>> @@ -134,6 +134,14 @@
>> bias-pull-up;
>> };
>>
>> + mmc1_pins: mmc1-pins {
>> + pins = "PG0", "PG1", "PG2", "PG3",
>> + "PG4", "PG5";
>> + function = "mmc1";
>> + drive-strength = <30>;
>> + bias-pull-up;
>> + };
>> +
>
>Is that the sole muxing option for MMC1? If so, it should be added to
>the mmc1 node.
Oh... yes, it is.
Will do in v2.
>
>Maxime
^ permalink raw reply
* Re: CCREE performance on R-Car H3 + crash
From: Geert Uytterhoeven @ 2018-07-24 7:51 UTC (permalink / raw)
To: Gilad Ben-Yossef; +Cc: Linux-Renesas, Linux Crypto Mailing List
In-Reply-To: <CAOtvUMcZBG-uw8r06=rBRkd+SL_9Pz1WV6zxRbcDj2DXC9Oa1Q@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3671 bytes --]
Hi Gilad,
On Tue, Jul 24, 2018 at 9:32 AM Gilad Ben-Yossef <gilad@benyossef.com> wrote:
> On Mon, Jul 23, 2018 at 5:35 PM, Geert Uytterhoeven
> <geert@linux-m68k.org> wrote:
> > On Mon, Jul 23, 2018 at 4:25 PM Gilad Ben-Yossef <gilad@benyossef.com> wrote:
> >> On Mon, Jul 23, 2018 at 1:31 PM, Gilad Ben-Yossef <gilad@benyossef.com> wrote:
> >> > On Mon, Jul 23, 2018 at 12:55 PM, Geert Uytterhoeven
> >> > <geert@linux-m68k.org> wrote:
> >> >> CC linux-crypto for the crash log.
> >> >>
> >> >> On Sun, Jul 22, 2018 at 7:28 AM Gilad Ben-Yossef <gilad@benyossef.com> wrote:
> >> >>> On Thu, Jul 19, 2018 at 3:43 PM, Geert Uytterhoeven
> >> >>> <geert@linux-m68k.org> wrote:
> >> >>> > I've noticed CCREE is used with a LUKS-formatted disk, so I did some small
> >> > ...
> >> >>
> >> >> $ cryptsetup benchmark
> >> >> # Tests are approximate using memory only (no storage IO).
> >> >> PBKDF2-sha1 478364 iterations per second for 256-bit key
> >> >> PBKDF2-sha256 927943 iterations per second for 256-bit key
> >> >> PBKDF2-sha512 360583 iterations per second for 256-bit key
> >> >> PBKDF2-ripemd160 266677 iterations per second for 256-bit key
> >> >> PBKDF2-whirlpool 115787 iterations per second for 256-bit key
> >> >> # Algorithm | Key | Encryption | Decryption
> >> >> aes-cbc 128b 46.0 MiB/s 46.7 MiB/s
> >> >> serpent-cbc 128b N/A N/A
> >> >> twofish-cbc 128b N/A N/A
> >> >> aes-cbc 256b 46.5 MiB/s 46.4 MiB/s
> >> >> serpent-cbc 256b N/A N/A
> >> >> twofish-cbc 256b N/A N/A
> >> >> Segmentation fault
> >> >>
> >> >> Oops.
> >> >>
> >> >> ccree e6601000.crypto: Unsupported data size 65536.
> >> >> Unable to handle kernel paging request at virtual address ffffffbf5c3c3c20
> >> >
> >> > Oy. Thank you for reporting this. I'll take a look at what is going on ASAP.
> >>
> >> hmm... well, the plot thickens.
> >>
> >> I was able to recreate the "Unsupported data size 65536" message and
> >> now trying to understand
> >> why the check that causes it is there but - I wasn't able to get a
> >> crash, nor do I understand why
> >> this condition would result in a crash (it ends up returning -EINVAL)... :-(
> >>
> >> I am surely using a different tree though - I'm based on the
> >> cryptodev/master tree with cherry picking of just R-Car ccree clocks
> >> and enabling.
> >>
> >> I was thinking maybe it's a fix that is already in upstream cryptodev
> >> tree but not in your tree but didn't manage to identify any obvious
> >> suspects
> >>
> >> What tree are you based off?
> >
> > My tree is based on renesas-drivers-2018-07-17-v4.18-rc5 from
> > https://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git/
> >
> > Do you want me to try something different?
>
> I've tried booting your tree and see the same behavior - "Unsupported
> data size" error message but no crash.
>
> I'm running on an Savator-X R-Car H3 ES1.0 board.
>
> Not really sure how to proceed.
>
> Maybe you can send me your exact .config file?
I cannot reproduce the crash using renesas_defconfig + CONFIG_CRYPTO_DEV_CCREE=y
+ CONFIG_CRYPTO_USER_API_SKCIPHER=y.
I can reproduce it on Salvator-X with R-Car H3 ES1.0 and Salvator-XS with
R-Car H3 ES2.0 using the attached config.
Thanks!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@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
[-- Attachment #2: config-salvator-x.gz --]
[-- Type: application/gzip, Size: 25351 bytes --]
^ permalink raw reply
* Re: [Qemu-devel] [PATCH v3 for 3.0 00/18] docker fixes (and one tcg test tweak)
From: Alex Bennée @ 2018-07-24 8:56 UTC (permalink / raw)
To: Fam Zheng
Cc: cota, Daniel P. Berrange, Philippe Mathieu-Daudé,
Richard Henderson, balrogg, aurelien, Alexander Graf,
QEMU Developers
In-Reply-To: <CAK1Eb9=_s=9U+0SXhDEcNaN_RAkN5+sBTo4OtfnqcJYJv=4q-w@mail.gmail.com>
Fam Zheng <famz@redhat.com> writes:
> On Mon, Jul 23, 2018 at 6:03 PM Alex Bennée <alex.bennee@linaro.org> wrote:
>>
>>
>> Alex Bennée <alex.bennee@linaro.org> writes:
>>
>> > Hi,
>> >
>> > I've missed the boat for today's rc1 but I'd like to get this merged
>> > before rc2. The new docker.py change is technically new functionality
>> > but I'm counting it as a usability bug fix as it replaces a random
>> > back trace failure with a preemptive failure and message mentioning
>> > binfmt_misc configuration. This would have saved Richard a lot of head
>> > scratching as he tried to setup a powerpc-user setup to test his
>> > setcontext fix (he had a custom binfmt_misc pointing to his src tree).
>> >
>> > Finally we also drop the runcom test. It was cute that it got
>> > resurrected but it is ultimately a pointless test for something I'm
>> > sure no one actually uses.
>> >
>> > There will be a follow-up RFC series after this that cleans-up some of
>> > the rough edges when your host is not an x86_64 box but that series
>> > won't be targeting the 3.0 release.
>> >
>> > : The following patches need review
>> > : patch docker/disable debian powerpc user cross.patch
>> > : patch docker/drop QEMU_TARGET check fallback in EXECUTABLE.patch
>> > : patch docker/Update debootstrap script after Debian migrat.patch
>> > : patch docker/ignore distro versioning of debootstrap.patch
>> > : patch docker/perform basic binfmt_misc validation in docke.patch
>> > : patch tests/tcg remove runcom test.patch
>>
>> Ping?
>
> I had questions about patch 13 and 17. Otherwise looks good.
> Maybe you can drop them for now (including patch 9) and send the PULL for
> the rest.
I can drop/replace 13 - but 17 was there for a better reporting of a
failure case Peter found. We can certainly expand it and be smarter in
future iterations.
> I don't know if we can catch up -rc2 but I guess the testing fixes are
> fairly safe to sneak in. :)
>
> (My development machine is affected by
> an
> office power outage, and I was
> also
> busy with upgrading patchew.org. Sorry for the
>
> late reply
> !)
>
> Fam
--
Alex Bennée
^ permalink raw reply
* Re: [PATCH 2/3] arm64: allwinner: dts: h6: add pinmux for MMC1
From: Maxime Ripard @ 2018-07-24 8:56 UTC (permalink / raw)
To: Icenowy Zheng
Cc: Chen-Yu Tsai, linux-arm-kernel, devicetree, linux-kernel,
linux-sunxi
In-Reply-To: <20180724011551.49603-3-icenowy@aosc.io>
[-- Attachment #1: Type: text/plain, Size: 1103 bytes --]
On Tue, Jul 24, 2018 at 09:15:50AM +0800, Icenowy Zheng wrote:
> The MMC1 controller on H6, in the reference design and most third party
> design, is used to connect SDIO Wi-Fi.
>
> Add pinmux for it.
>
> Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
> ---
> arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi | 8 ++++++++
> 1 file changed, 8 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi b/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi
> index cfa5fffcf62b..ba1a3a3e2149 100644
> --- a/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi
> +++ b/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi
> @@ -134,6 +134,14 @@
> bias-pull-up;
> };
>
> + mmc1_pins: mmc1-pins {
> + pins = "PG0", "PG1", "PG2", "PG3",
> + "PG4", "PG5";
> + function = "mmc1";
> + drive-strength = <30>;
> + bias-pull-up;
> + };
> +
Is that the sole muxing option for MMC1? If so, it should be added to
the mmc1 node.
Maxime
--
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH 2/3] arm64: allwinner: dts: h6: add pinmux for MMC1
From: Maxime Ripard @ 2018-07-24 8:56 UTC (permalink / raw)
To: Icenowy Zheng
Cc: Chen-Yu Tsai, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw
In-Reply-To: <20180724011551.49603-3-icenowy-h8G6r0blFSE@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 1086 bytes --]
On Tue, Jul 24, 2018 at 09:15:50AM +0800, Icenowy Zheng wrote:
> The MMC1 controller on H6, in the reference design and most third party
> design, is used to connect SDIO Wi-Fi.
>
> Add pinmux for it.
>
> Signed-off-by: Icenowy Zheng <icenowy-h8G6r0blFSE@public.gmane.org>
> ---
> arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi | 8 ++++++++
> 1 file changed, 8 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi b/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi
> index cfa5fffcf62b..ba1a3a3e2149 100644
> --- a/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi
> +++ b/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi
> @@ -134,6 +134,14 @@
> bias-pull-up;
> };
>
> + mmc1_pins: mmc1-pins {
> + pins = "PG0", "PG1", "PG2", "PG3",
> + "PG4", "PG5";
> + function = "mmc1";
> + drive-strength = <30>;
> + bias-pull-up;
> + };
> +
Is that the sole muxing option for MMC1? If so, it should be added to
the mmc1 node.
Maxime
--
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* [PATCH 2/3] arm64: allwinner: dts: h6: add pinmux for MMC1
From: Maxime Ripard @ 2018-07-24 8:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180724011551.49603-3-icenowy@aosc.io>
On Tue, Jul 24, 2018 at 09:15:50AM +0800, Icenowy Zheng wrote:
> The MMC1 controller on H6, in the reference design and most third party
> design, is used to connect SDIO Wi-Fi.
>
> Add pinmux for it.
>
> Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
> ---
> arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi | 8 ++++++++
> 1 file changed, 8 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi b/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi
> index cfa5fffcf62b..ba1a3a3e2149 100644
> --- a/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi
> +++ b/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi
> @@ -134,6 +134,14 @@
> bias-pull-up;
> };
>
> + mmc1_pins: mmc1-pins {
> + pins = "PG0", "PG1", "PG2", "PG3",
> + "PG4", "PG5";
> + function = "mmc1";
> + drive-strength = <30>;
> + bias-pull-up;
> + };
> +
Is that the sole muxing option for MMC1? If so, it should be added to
the mmc1 node.
Maxime
--
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180724/75b96958/attachment.sig>
^ permalink raw reply
* Re: [PATCH v4] x86/mm: Add mem access rights to NPT
From: Jan Beulich @ 2018-07-24 8:55 UTC (permalink / raw)
To: aisaila; +Cc: George Dunlap, Andrew Cooper, tamas, Razvan Cojocaru, xen-devel
In-Reply-To: <1532353689-2242-1-git-send-email-aisaila@bitdefender.com>
>>> On 23.07.18 at 15:48, <aisaila@bitdefender.com> wrote:
> --- a/xen/arch/x86/mm/mem_access.c
> +++ b/xen/arch/x86/mm/mem_access.c
> @@ -221,12 +221,12 @@ bool p2m_mem_access_check(paddr_t gpa, unsigned long gla,
> {
> req->u.mem_access.flags |= MEM_ACCESS_GLA_VALID;
> req->u.mem_access.gla = gla;
> -
> - if ( npfec.kind == npfec_kind_with_gla )
> - req->u.mem_access.flags |= MEM_ACCESS_FAULT_WITH_GLA;
> - else if ( npfec.kind == npfec_kind_in_gpt )
> - req->u.mem_access.flags |= MEM_ACCESS_FAULT_IN_GPT;
> }
> +
> + if ( npfec.kind == npfec_kind_with_gla )
> + req->u.mem_access.flags |= MEM_ACCESS_FAULT_WITH_GLA;
> + else if ( npfec.kind == npfec_kind_in_gpt )
> + req->u.mem_access.flags |= MEM_ACCESS_FAULT_IN_GPT;
Without explanation in the commit message and without comment
this change is a no-go imo: I consider it at least questionable to
have npfec_kind_with_gla without .gla_valid set to true. Perhaps
it's just a naming issue, but that would then still require half a
sentence to explain.
> @@ -366,8 +366,11 @@ long p2m_set_mem_access(struct domain *d, gfn_t gfn, uint32_t nr,
> /* If request to set default access. */
> if ( gfn_eq(gfn, INVALID_GFN) )
> {
> - p2m->default_access = a;
> - return 0;
> + if ( (rc = p2m->check_access(a)) == 0 )
> + {
> + p2m->default_access = a;
> + return 0;
> + }
> }
This latching into rc makes subsequent code yield inconsistent
behavior.
> --- a/xen/arch/x86/mm/p2m-ept.c
> +++ b/xen/arch/x86/mm/p2m-ept.c
> @@ -667,6 +667,12 @@ bool_t ept_handle_misconfig(uint64_t gpa)
> return spurious ? (rc >= 0) : (rc > 0);
> }
>
> +int ept_check_access(p2m_access_t p2ma)
> +{
> + /* All access is permitted */
> + return 0;
> +}
With this I'd rather see the hook omitted here, to avoid the indirect
call. Perhaps you'll want a wrapper around the indirect call, abstracting
away the NULL check for callers.
> +static void p2m_set_access(struct p2m_domain *p2m, unsigned long gfn,
> + p2m_access_t a)
> +{
> + int rc;
> +
> + if ( !p2m->mem_access_settings )
> + return;
No error indication?
> + if ( p2m_access_rwx == a )
> + {
> + radix_tree_delete(p2m->mem_access_settings, gfn);
> + return;
> + }
Is it really p2m_access_rwx that you want to special case here, rather
than ->default_access?
> @@ -31,6 +34,18 @@ int arch_monitor_init_domain(struct domain *d)
> if ( !d->arch.monitor.msr_bitmap )
> return -ENOMEM;
>
> + if ( cpu_has_svm && !p2m->mem_access_settings )
> + {
> + p2m->mem_access_settings = xmalloc(struct radix_tree_root);
> +
> + if( !p2m->mem_access_settings )
Style.
> + {
> + xfree(d->arch.monitor.msr_bitmap);
> + return -ENOMEM;
> + }
> + radix_tree_init(p2m->mem_access_settings);
> + }
What's the SVM connection here? Please don't forget that p2m-pt.c
also serves the shadow case. Perhaps struct p2m_domain should
contain a boolean indicator whether this auxiliary data structure is
needed?
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply
* Re: [Qemu-devel] [PATCH v3 for 3.0 17/18] docker: perform basic binfmt_misc validation in docker.py
From: Alex Bennée @ 2018-07-24 8:55 UTC (permalink / raw)
To: Fam Zheng
Cc: cota, Daniel P. Berrange, Philippe Mathieu-Daudé,
Richard Henderson, balrogg, aurelien, Alexander Graf,
QEMU Developers
In-Reply-To: <CAK1Eb9kWAni0uWVtxvx-4FpND2iQ2DG22ARjQQwRcKnSzc+_LA@mail.gmail.com>
Fam Zheng <famz@redhat.com> writes:
> On Wed, Jul 18, 2018 at 4:02 AM Alex Bennée <alex.bennee@linaro.org> wrote:
>>
>> Setting up binfmt_misc is outside of the scope of the docker.py script
>> but we can at least validate it with any given executable so we have a
>> more useful error message than the sed line of deboostrap failing
>> cryptically.
>>
>> Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
>> Reported-by: Richard Henderson <richard.henderson@linaro.org>
>> ---
>> tests/docker/docker.py | 30 ++++++++++++++++++++++++++++++
>> 1 file changed, 30 insertions(+)
>>
>> diff --git a/tests/docker/docker.py b/tests/docker/docker.py
>> index 523f4b95a2..a3f5b0c1b0 100755
>> --- a/tests/docker/docker.py
>> +++ b/tests/docker/docker.py
>> @@ -112,6 +112,31 @@ def _copy_binary_with_libs(src, dest_dir):
>> so_path = os.path.dirname(l)
>> _copy_with_mkdir(l , dest_dir, so_path)
>>
>> +
>> +def _check_binfmt_misc(executable):
>> + """Check binfmt_misc has entry for executable in the right place.
>> +
>> + The details of setting up binfmt_misc are outside the scope of
>> + this script but we should at least fail early with a useful
>> + message if it won't work."""
>> +
>> + binary = os.path.basename(executable)
>> + binfmt_entry = "/proc/sys/fs/binfmt_misc/%s" % (binary)
>> +
>> + if not os.path.exists(binfmt_entry):
>> + print ("No binfmt_misc entry for %s" % (binary))
>> + return False
>> +
>> + with open(binfmt_entry) as x: entry = x.read()
>> +
>> + qpath = "/usr/bin/%s" % (binary)
>
> Is it intended to hardcode this to /usr/bin? I thought we were more
> flexible than that..
That's where we currently copy it. However we are certainly capable of
being more flexible. For example as long at there is an entry visible to
the host file-system with the "F" flag we can actually create and run
docker images without copying QEMU inside the container.
However if we don't we certainly need to copy it to the same place in
the container than it is used outside the container.
>
> Fam
>
>> + if not re.search("interpreter %s\n" % (qpath), entry):
>> + print ("binfmt_misc for %s does not point to %s" % (binary, qpath))
>> + return False
>> +
>> + return True
>> +
>> +
>> def _read_qemu_dockerfile(img_name):
>> # special case for Debian linux-user images
>> if img_name.startswith("debian") and img_name.endswith("user"):
>> @@ -315,6 +340,11 @@ class BuildCommand(SubCommand):
>> # Create a docker context directory for the build
>> docker_dir = tempfile.mkdtemp(prefix="docker_build")
>>
>> + # Validate binfmt_misc will work
>> + if args.include_executable:
>> + if not _check_binfmt_misc(args.include_executable):
>> + return 1
>> +
>> # Is there a .pre file to run in the build context?
>> docker_pre = os.path.splitext(args.dockerfile)[0]+".pre"
>> if os.path.exists(docker_pre):
>> --
>> 2.17.1
>>
--
Alex Bennée
^ permalink raw reply
* [PATCH] net/mlx5: fix linkage error for glue lib
From: Shahaf Shuler @ 2018-07-24 8:54 UTC (permalink / raw)
To: yskoh; +Cc: dev, Yaroslav Brustinov, stable, nelio.laranjeiro,
adrien.mazarguil
From: Yaroslav Brustinov <ybrustin@cisco.com>
Compiling with gcc 4.7.2 introduced the linkage error
"bin/ld: Warning: alignment 8 of symbol `mlx5_glue' in
src/dpdk/drivers/net/mlx5/mlx5_glue.c.21.o is smaller than 16 in
src/dpdk/drivers/net/mlx5/mlx5_rxq.c.21.o"
Fix it be forcing the alignment of the glue lib.
Fixes: 0e83b8e536c1 ("net/mlx5: move rdma-core calls to separate file")
Cc: stable@dpdk.org
Cc: nelio.laranjeiro@6wind.com
Cc: adrien.mazarguil@6wind.com
Signed-off-by: Yaroslav Brustinov <ybrustin@cisco.com>
Signed-off-by: Shahaf Shuler <shahafs@mellanox.com>
---
drivers/net/mlx5/mlx5_glue.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/net/mlx5/mlx5_glue.c b/drivers/net/mlx5/mlx5_glue.c
index c7965e51fe..c56c69bb13 100644
--- a/drivers/net/mlx5/mlx5_glue.c
+++ b/drivers/net/mlx5/mlx5_glue.c
@@ -343,7 +343,9 @@ mlx5_glue_dv_create_qp(struct ibv_context *context,
#endif
}
-const struct mlx5_glue *mlx5_glue = &(const struct mlx5_glue){
+const struct mlx5_glue *mlx5_glue __attribute__((__aligned__(64))) =
+ &(const struct mlx5_glue)
+{
.version = MLX5_GLUE_VERSION,
.fork_init = mlx5_glue_fork_init,
.alloc_pd = mlx5_glue_alloc_pd,
--
2.12.0
^ permalink raw reply related
* [Buildroot] [PATCH 1/1] check-package: fix Python3 support
From: Arnout Vandecappelle @ 2018-07-24 8:54 UTC (permalink / raw)
To: buildroot
In-Reply-To: <20180723004107.20985-1-ricardo.martincoski@gmail.com>
On 23-07-18 02:41, Ricardo Martincoski wrote:
> This script currently uses "/usr/bin/env python" as shebang but it does
> not really support Python3. Instead of limiting the script to Python2,
> fix it to support both versions.
>
> Do this by first using an automated tool:
> $ python -m modernize -w -p <files>
In general (if it doesn't break things), I prefer to do the automatic stuff in
a separate patch from the manual stuff. That makes review easier (because for
the automatic stuff, you mainly review the automation itself rather than the
result).
> and then manually fixing what remains:
> - keep the imports in alphabetical order;
> - fix handling of files that cannot be decoded by 'utf-8' codec, such
> as package/urg/0002-urg-gcc6-fix-narrowing-conversion.patch .
>
> In order to avoid errors when decoding files, use
> errors="surrogateescape" when opening files, the docs for open() states:
> "This is useful for processing files in an unknown encoding.".
> This argument is not compatible with Python2 open() so import 'six' to
> use it only when running in Python3.
I would prefer to open files with "rb" instead. However, that's a much bigger
change because all checks should then use bytes objects instead of strings.
> As a consequence the file handler becomes explicit, so use it to close()
> the file after it got processed.
>
> Signed-off-by: Ricardo Martincoski <ricardo.martincoski@gmail.com>
> ---
> Using the default docker (debian) image which uses Python2:
> before this patch:
> https://gitlab.com/buildroot.org/buildroot/-/jobs/83454639
> after this patch:
> https://gitlab.com/RicardoMartincoski/buildroot/-/jobs/83542815
>
> Using an arch docker image which uses Python3:
> before this patch:
> https://gitlab.com/RicardoMartincoski/buildroot/-/jobs/81892607
> after this patch:
> https://gitlab.com/RicardoMartincoski/buildroot/-/jobs/83543363
> The arch image for docker was generated using:
> http://patchwork.ozlabs.org/patch/943301/
> ---
> utils/check-package | 9 ++++++++-
> utils/checkpackagelib/lib.py | 3 ++-
> utils/checkpackagelib/lib_config.py | 13 +++++++------
> utils/checkpackagelib/lib_hash.py | 13 +++++++------
> utils/checkpackagelib/lib_mk.py | 11 ++++++-----
> utils/checkpackagelib/lib_patch.py | 5 +++--
> 6 files changed, 33 insertions(+), 21 deletions(-)
>
> diff --git a/utils/check-package b/utils/check-package
> index 3dbc28b0a2..a8f5ce6157 100755
> --- a/utils/check-package
> +++ b/utils/check-package
> @@ -1,11 +1,13 @@
> #!/usr/bin/env python
> # See utils/checkpackagelib/readme.txt before editing this file.
>
> +from __future__ import absolute_import
This doesn't make sense in a top-level script, does it?
> from __future__ import print_function
> import argparse
> import inspect
> import os
> import re
> +import six
> import sys
>
> import checkpackagelib.lib_config
> @@ -127,10 +129,15 @@ def check_file_using_lib(fname):
>
> for cf in objects:
> nwarnings += print_warnings(cf.before())
> - for lineno, text in enumerate(open(fname, "r").readlines()):
> + if six.PY3:
> + f = open(fname, "r", errors="surrogateescape")
> + else:
> + f = open(fname, "r")
> + for lineno, text in enumerate(f.readlines()):
> nlines += 1
> for cf in objects:
> nwarnings += print_warnings(cf.check_line(lineno + 1, text))
> + f.close()
> for cf in objects:
> nwarnings += print_warnings(cf.after())
>
> diff --git a/utils/checkpackagelib/lib.py b/utils/checkpackagelib/lib.py
> index 91f4ad49b7..61fa46125d 100644
> --- a/utils/checkpackagelib/lib.py
> +++ b/utils/checkpackagelib/lib.py
> @@ -1,6 +1,7 @@
> # See utils/checkpackagelib/readme.txt before editing this file.
>
> -from base import _CheckFunction
> +from __future__ import absolute_import
> +from .base import _CheckFunction
Why is this changed? Will Python3 look for base anywhere else than in the
checkpackagelib directory?
Same below.
>
>
> class ConsecutiveEmptyLines(_CheckFunction):
> diff --git a/utils/checkpackagelib/lib_config.py b/utils/checkpackagelib/lib_config.py
> index 1d273f1c5f..5f316a6d5b 100644
> --- a/utils/checkpackagelib/lib_config.py
> +++ b/utils/checkpackagelib/lib_config.py
> @@ -3,13 +3,14 @@
> # "bool", so below check functions don't need to check for things already
> # checked by running "make menuconfig".
>
> +from __future__ import absolute_import
> import re
>
> -from base import _CheckFunction
> -from lib import ConsecutiveEmptyLines # noqa: F401
> -from lib import EmptyLastLine # noqa: F401
> -from lib import NewlineAtEof # noqa: F401
> -from lib import TrailingSpace # noqa: F401
> +from .base import _CheckFunction
> +from .lib import ConsecutiveEmptyLines # noqa: F401
> +from .lib import EmptyLastLine # noqa: F401
> +from .lib import NewlineAtEof # noqa: F401
> +from .lib import TrailingSpace # noqa: F401
>
>
> def _empty_or_comment(text):
> @@ -45,7 +46,7 @@ class AttributesOrder(_CheckFunction):
> if attribute in entries_that_should_not_be_indented:
> self.state = 0
> return
> - if attribute not in self.attributes_order_convention.keys():
> + if attribute not in list(self.attributes_order_convention.keys()):
Why is this needed? 'not in' works on an iterator, doesn't it?
Same below.
Bottom line: I don't think modernize does anything useful.
Regards,
Arnout
> return
> new_state = self.attributes_order_convention[attribute]
> wrong_order = self.state > new_state
> diff --git a/utils/checkpackagelib/lib_hash.py b/utils/checkpackagelib/lib_hash.py
> index 6d4cc9fd62..8ca92a5a90 100644
> --- a/utils/checkpackagelib/lib_hash.py
> +++ b/utils/checkpackagelib/lib_hash.py
> @@ -3,13 +3,14 @@
> # functions don't need to check for things already checked by running
> # "make package-dirclean package-source".
>
> +from __future__ import absolute_import
> import re
>
> -from base import _CheckFunction
> -from lib import ConsecutiveEmptyLines # noqa: F401
> -from lib import EmptyLastLine # noqa: F401
> -from lib import NewlineAtEof # noqa: F401
> -from lib import TrailingSpace # noqa: F401
> +from .base import _CheckFunction
> +from .lib import ConsecutiveEmptyLines # noqa: F401
> +from .lib import EmptyLastLine # noqa: F401
> +from .lib import NewlineAtEof # noqa: F401
> +from .lib import TrailingSpace # noqa: F401
>
>
> def _empty_line_or_comment(text):
> @@ -43,7 +44,7 @@ class HashType(_CheckFunction):
> htype, hexa = fields[:2]
> if htype == "none":
> return
> - if htype not in self.len_of_hash.keys():
> + if htype not in list(self.len_of_hash.keys()):
> return ["{}:{}: unexpected type of hash ({}#adding-packages-hash)"
> .format(self.filename, lineno, self.url_to_manual),
> text]
> diff --git a/utils/checkpackagelib/lib_mk.py b/utils/checkpackagelib/lib_mk.py
> index 86e9aa2d97..9c17a3cfd2 100644
> --- a/utils/checkpackagelib/lib_mk.py
> +++ b/utils/checkpackagelib/lib_mk.py
> @@ -4,13 +4,14 @@
> # menu options using "make menuconfig" and by running "make" with appropriate
> # packages enabled.
>
> +from __future__ import absolute_import
> import re
>
> -from base import _CheckFunction
> -from lib import ConsecutiveEmptyLines # noqa: F401
> -from lib import EmptyLastLine # noqa: F401
> -from lib import NewlineAtEof # noqa: F401
> -from lib import TrailingSpace # noqa: F401
> +from .base import _CheckFunction
> +from .lib import ConsecutiveEmptyLines # noqa: F401
> +from .lib import EmptyLastLine # noqa: F401
> +from .lib import NewlineAtEof # noqa: F401
> +from .lib import TrailingSpace # noqa: F401
>
>
> class Indent(_CheckFunction):
> diff --git a/utils/checkpackagelib/lib_patch.py b/utils/checkpackagelib/lib_patch.py
> index 555621afa1..4b0d32268f 100644
> --- a/utils/checkpackagelib/lib_patch.py
> +++ b/utils/checkpackagelib/lib_patch.py
> @@ -3,10 +3,11 @@
> # functions don't need to check for things already checked by running
> # "make package-dirclean package-patch".
>
> +from __future__ import absolute_import
> import re
>
> -from base import _CheckFunction
> -from lib import NewlineAtEof # noqa: F401
> +from .base import _CheckFunction
> +from .lib import NewlineAtEof # noqa: F401
>
>
> class ApplyOrder(_CheckFunction):
>
--
Arnout Vandecappelle arnout at mind be
Senior Embedded Software Architect +32-16-286500
Essensium/Mind http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint: 7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF
^ permalink raw reply
* [PATCH v2 10/10] NFC: st95hf: add of match table
From: Daniel Mack @ 2018-07-24 8:54 UTC (permalink / raw)
To: sameo-VuQAYsv1563Yd54FQh9/CA
Cc: linux-wireless-u79uwXL29TY76Z2rM5mHXA,
colin.king-Z7WLFzj8eWMS+FvcfC7Uqw, shikha.singh-qxv4g6HH51o,
Daniel Mack, devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20180724085426.23999-1-daniel-cYrQPVfZoowdnm+yROfE0A@public.gmane.org>
Add a match table for device tree compatible strings. Interestingly, a
document describing the bindings already exists since a while, but users
currently rely on the implicit matching in the drivers core. Let's be
explicit and add a real match table.
Signed-off-by: Daniel Mack <daniel-cYrQPVfZoowdnm+yROfE0A@public.gmane.org>
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
---
drivers/nfc/st95hf/core.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/drivers/nfc/st95hf/core.c b/drivers/nfc/st95hf/core.c
index 4db3c020921c..5a01b454fbc4 100644
--- a/drivers/nfc/st95hf/core.c
+++ b/drivers/nfc/st95hf/core.c
@@ -1012,6 +1012,12 @@ static const struct spi_device_id st95hf_id[] = {
};
MODULE_DEVICE_TABLE(spi, st95hf_id);
+static const struct of_device_id st95hf_of_match[] = {
+ { .compatible = "st,st95hf", },
+ {}
+};
+MODULE_DEVICE_TABLE(of, st95hf_of_match);
+
static int st95hf_probe(struct spi_device *nfc_spi_dev)
{
int ret;
@@ -1189,6 +1195,7 @@ static struct spi_driver st95hf_driver = {
.driver = {
.name = "st95hf",
.owner = THIS_MODULE,
+ .of_match_table = st95hf_of_match,
},
.id_table = st95hf_id,
.probe = st95hf_probe,
--
2.17.1
^ permalink raw reply related
* Re: [PATCH v1 0/2] mm/kdump: exclude reserved pages in dumps
From: Michal Hocko @ 2018-07-24 8:53 UTC (permalink / raw)
To: David Hildenbrand
Cc: Vlastimil Babka, linux-mm, linux-kernel, Andrew Morton,
Baoquan He, Dave Young, Greg Kroah-Hartman, Hari Bathini,
Huang Ying, Kirill A. Shutemov, Marc-André Lureau,
Matthew Wilcox, Miles Chen, Pavel Tatashin, Petr Tesarik
In-Reply-To: <d4528eb7-9d8b-4073-afad-d8dd1390aa91@redhat.com>
On Tue 24-07-18 10:46:20, David Hildenbrand wrote:
> On 24.07.2018 09:25, Michal Hocko wrote:
> > On Mon 23-07-18 19:20:43, David Hildenbrand wrote:
> >> On 23.07.2018 14:30, Michal Hocko wrote:
> >>> On Mon 23-07-18 13:45:18, Vlastimil Babka wrote:
> >>>> On 07/20/2018 02:34 PM, David Hildenbrand wrote:
> >>>>> Dumping tools (like makedumpfile) right now don't exclude reserved pages.
> >>>>> So reserved pages might be access by dump tools although nobody except
> >>>>> the owner should touch them.
> >>>>
> >>>> Are you sure about that? Or maybe I understand wrong. Maybe it changed
> >>>> recently, but IIRC pages that are backing memmap (struct pages) are also
> >>>> PG_reserved. And you definitely do want those in the dump.
> >>>
> >>> You are right. reserve_bootmem_region will make all early bootmem
> >>> allocations (including those backing memmaps) PageReserved. I have asked
> >>> several times but I haven't seen a satisfactory answer yet. Why do we
> >>> even care for kdump about those. If they are reserved the nobody should
> >>> really look at those specific struct pages and manipulate them. Kdump
> >>> tools are using a kernel interface to read the content. If the specific
> >>> content is backed by a non-existing memory then they should simply not
> >>> return anything.
> >>>
> >>
> >> "new kernel" provides an interface to read memory from "old kernel".
> >>
> >> The new kernel has no idea about
> >> - which memory was added/online in the old kernel
> >> - where struct pages of the old kernel are and what their content is
> >> - which memory is save to touch and which not
> >>
> >> Dump tools figure all that out by interpreting the VMCORE. They e.g.
> >> identify "struct pages" and see if they should be dumped. The "new
> >> kernel" only allows to read that memory. It cannot hinder to crash the
> >> system (e.g. if a dump tool would try to read a hwpoison page).
> >>
> >> So how should the "new kernel" know if a page can be touched or not?
> >
> > I am sorry I am not familiar with kdump much. But from what I remember
> > it reads from /proc/vmcore and implementation of this interface should
> > simply return EINVAL or alike when you try to dump inaccessible memory
> > range.
>
> I assume the main problem with this approach is that we would always
> have to fallback to reading old memory from vmcore page by page. e.g.
> makedumpfile will always try to read bigger bunches. I also assume the
> reason HWPOISON is handled in dump tools instead of in the kernel using
> the mechanism you describe is the case.
Is falling back to page-by-page for some ranges a real problem? I mean
most of pages will simply be there so you can go in larger chunks. Once
you get EINVAL, you just fall back to page-by-page for that particular
range.
--
Michal Hocko
SUSE Labs
^ permalink raw reply
* Re: [PATCH 3/5] s390, dcssblk: Allow a NULL-kaddr to ->direct_access()
From: Christian Borntraeger @ 2018-07-24 8:53 UTC (permalink / raw)
To: Huaisheng Ye, linux-nvdimm, dan.j.williams
Cc: axboe, linux-s390, chengnt, linux-fsdevel, heiko.carstens,
linux-kernel, willy, bart.vanassche, viro, gregkh, schwidefsky,
jack
In-Reply-To: <20180724084510.6104-4-yehs2007@zoho.com>
On 07/24/2018 10:45 AM, Huaisheng Ye wrote:
> From: Huaisheng Ye <yehs1@lenovo.com>
>
> dcssblk_direct_access() needs to check the validity of second rank
> pointer kaddr for NULL assignment. If kaddr equals to NULL, it
> doesn't need to calculate the value.
>
> Signed-off-by: Huaisheng Ye <yehs1@lenovo.com>
> ---
> drivers/s390/block/dcssblk.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/s390/block/dcssblk.c b/drivers/s390/block/dcssblk.c
> index 0a312e4..9c13dc5 100644
> --- a/drivers/s390/block/dcssblk.c
> +++ b/drivers/s390/block/dcssblk.c
> @@ -915,7 +915,8 @@ static DEVICE_ATTR(save, S_IWUSR | S_IRUSR, dcssblk_save_show,
> unsigned long dev_sz;
>
> dev_sz = dev_info->end - dev_info->start + 1;
> - *kaddr = (void *) dev_info->start + offset;
> + if (kaddr)
> + *kaddr = (void *) dev_info->start + offset;
So you are trading of a load + add (dev_info->start should be cache hot) against a
compare+branch . Not sure that this is always a win.
> *pfn = __pfn_to_pfn_t(PFN_DOWN(dev_info->start + offset),
> PFN_DEV|PFN_SPECIAL);
>
>
_______________________________________________
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm
^ permalink raw reply
* Re: [PATCH 3/5] s390, dcssblk: Allow a NULL-kaddr to ->direct_access()
From: Christian Borntraeger @ 2018-07-24 8:53 UTC (permalink / raw)
To: Huaisheng Ye, linux-nvdimm, dan.j.williams
Cc: ross.zwisler, willy, vishal.l.verma, dave.jiang, schwidefsky,
heiko.carstens, viro, martin.petersen, axboe, gregkh,
bart.vanassche, jack, linux-kernel, linux-s390, linux-fsdevel,
chengnt, Huaisheng Ye
In-Reply-To: <20180724084510.6104-4-yehs2007@zoho.com>
On 07/24/2018 10:45 AM, Huaisheng Ye wrote:
> From: Huaisheng Ye <yehs1@lenovo.com>
>
> dcssblk_direct_access() needs to check the validity of second rank
> pointer kaddr for NULL assignment. If kaddr equals to NULL, it
> doesn't need to calculate the value.
>
> Signed-off-by: Huaisheng Ye <yehs1@lenovo.com>
> ---
> drivers/s390/block/dcssblk.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/s390/block/dcssblk.c b/drivers/s390/block/dcssblk.c
> index 0a312e4..9c13dc5 100644
> --- a/drivers/s390/block/dcssblk.c
> +++ b/drivers/s390/block/dcssblk.c
> @@ -915,7 +915,8 @@ static DEVICE_ATTR(save, S_IWUSR | S_IRUSR, dcssblk_save_show,
> unsigned long dev_sz;
>
> dev_sz = dev_info->end - dev_info->start + 1;
> - *kaddr = (void *) dev_info->start + offset;
> + if (kaddr)
> + *kaddr = (void *) dev_info->start + offset;
So you are trading of a load + add (dev_info->start should be cache hot) against a
compare+branch . Not sure that this is always a win.
> *pfn = __pfn_to_pfn_t(PFN_DOWN(dev_info->start + offset),
> PFN_DEV|PFN_SPECIAL);
>
>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.