* [PATCH 2/2] tty: serial: samsung_tty: remove SERIAL_SAMSUNG_DEBUG
From: Greg Kroah-Hartman @ 2020-02-20 10:26 UTC (permalink / raw)
To: linux-serial
Cc: Greg Kroah-Hartman, Kukjin Kim, Donghoon Yu, Hyunki Koo,
HYUN-KI KOO, Shinbeom Choi, Krzysztof Kozlowski, Jiri Slaby,
linux-arm-kernel, linux-samsung-soc, linux-kernel
In-Reply-To: <20200220102628.3371996-1-gregkh@linuxfoundation.org>
Since a05025d0ce72 ("tty: serial: samsung_tty: use standard debugging
macros") this configuration option is not used at all, so remove it from
the Kconfig file.
Cc: Kukjin Kim <kgene@kernel.org>
Cc: Donghoon Yu <hoony.yu@samsung.com>
Cc: Hyunki Koo <kkoos00@naver.com>
Cc: HYUN-KI KOO <hyunki00.koo@samsung.com>
Cc: Shinbeom Choi <sbeom.choi@samsung.com>
Cc: Krzysztof Kozlowski <krzk@kernel.org>
Cc: Jiri Slaby <jslaby@suse.com>
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-samsung-soc@vger.kernel.org
Cc: linux-serial@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/tty/serial/Kconfig | 9 ---------
1 file changed, 9 deletions(-)
diff --git a/drivers/tty/serial/Kconfig b/drivers/tty/serial/Kconfig
index a310bd22f1e2..fa4380b0b869 100644
--- a/drivers/tty/serial/Kconfig
+++ b/drivers/tty/serial/Kconfig
@@ -259,15 +259,6 @@ config SERIAL_SAMSUNG_UARTS
help
Select the number of available UART ports for the Samsung S3C
serial driver
-
-config SERIAL_SAMSUNG_DEBUG
- bool "Samsung SoC serial debug"
- depends on SERIAL_SAMSUNG && DEBUG_LL
- help
- Add support for debugging the serial driver. Since this is
- generally being used as a console, we use our own output
- routines that go via the low-level debug printascii()
- function.
config SERIAL_SAMSUNG_CONSOLE
bool "Support for console on Samsung SoC serial port"
--
2.25.1
^ permalink raw reply related
* Re: [PATCH V3 3/7] devicetree-binding: Add pmc gpio node
From: Bartosz Golaszewski @ 2020-02-20 10:26 UTC (permalink / raw)
To: Srinivas Neeli
Cc: Linus Walleij, Michal Simek, shubhrajyoti.datta, linux-gpio,
arm-soc, LKML, git
In-Reply-To: <1581942793-19468-4-git-send-email-srinivas.neeli@xilinx.com>
pon., 17 lut 2020 o 13:33 Srinivas Neeli <srinivas.neeli@xilinx.com> napisał(a):
>
> From: Shubhrajyoti Datta <shubhrajyoti.datta@xilinx.com>
>
> Add the pmc gpio node to the device tree.
>
Same here: I don't know what pmc gpio node is nor do I need to. Please
make your commit messages more verbose.
Bartosz
^ permalink raw reply
* Re: [PATCH v3] backlight: corgi: Convert to use GPIO descriptors
From: Daniel Thompson @ 2020-02-20 10:26 UTC (permalink / raw)
To: Linus Walleij
Cc: Andrea Adami, Jingoo Han, Robert Jarzmik, Lee Jones, dri-devel
In-Reply-To: <20200220090032.6635-1-linus.walleij@linaro.org>
On Thu, Feb 20, 2020 at 10:00:32AM +0100, Linus Walleij wrote:
> The code in the Corgi backlight driver can be considerably
> simplified by moving to GPIO descriptors and lookup tables
> from the board files instead of passing GPIO numbers using
> the old API.
>
> Make sure to encode inversion semantics for the Akita and
> Spitz platforms inside the GPIO lookup table and drop the
> custom inversion semantics from the driver.
>
> All in-tree users are converted in this patch.
>
> Cc: Andrea Adami <andrea.adami@gmail.com>
> Acked-by: Robert Jarzmik <robert.jarzmik@free.fr>
> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
So... I'm still not 100% sure about the bus names. The code is
confusing and made more so by what I think is probably a misleading
comment! So test reports welcome but nevertheless this is...
Reviewed-by: Daniel Thompson <daniel.thompson@linaro.org>
Daniel.
> ---
> ChangeLog v2->v3:
> - Switch the SPI bus name to "spi1.1" rather than "spi0.1" for
> Corgi and "spi2.1" rather than "spi0.1" for Spitz, as
> pxa2xx_set_spi_info() sets the bus number to 1 and 2
> respectively.
> ChangeLog v1->v2:
> - Collect Robert's ACK.
> ---
> arch/arm/mach-pxa/corgi.c | 12 ++++-
> arch/arm/mach-pxa/spitz.c | 34 +++++++++++----
> drivers/video/backlight/corgi_lcd.c | 68 ++++++++---------------------
> include/linux/spi/corgi_lcd.h | 3 --
> 4 files changed, 54 insertions(+), 63 deletions(-)
>
> diff --git a/arch/arm/mach-pxa/corgi.c b/arch/arm/mach-pxa/corgi.c
> index f2d73289230f..593c7f793da5 100644
> --- a/arch/arm/mach-pxa/corgi.c
> +++ b/arch/arm/mach-pxa/corgi.c
> @@ -563,13 +563,20 @@ static void corgi_bl_kick_battery(void)
> }
> }
>
> +static struct gpiod_lookup_table corgi_lcdcon_gpio_table = {
> + .dev_id = "spi1.1",
> + .table = {
> + GPIO_LOOKUP("gpio-pxa", CORGI_GPIO_BACKLIGHT_CONT,
> + "BL_CONT", GPIO_ACTIVE_HIGH),
> + { },
> + },
> +};
> +
> static struct corgi_lcd_platform_data corgi_lcdcon_info = {
> .init_mode = CORGI_LCD_MODE_VGA,
> .max_intensity = 0x2f,
> .default_intensity = 0x1f,
> .limit_mask = 0x0b,
> - .gpio_backlight_cont = CORGI_GPIO_BACKLIGHT_CONT,
> - .gpio_backlight_on = -1,
> .kick_battery = corgi_bl_kick_battery,
> };
>
> @@ -609,6 +616,7 @@ static struct spi_board_info corgi_spi_devices[] = {
> static void __init corgi_init_spi(void)
> {
> pxa2xx_set_spi_info(1, &corgi_spi_info);
> + gpiod_add_lookup_table(&corgi_lcdcon_gpio_table);
> spi_register_board_info(ARRAY_AND_SIZE(corgi_spi_devices));
> }
> #else
> diff --git a/arch/arm/mach-pxa/spitz.c b/arch/arm/mach-pxa/spitz.c
> index a4fdc399d152..371008e9bb02 100644
> --- a/arch/arm/mach-pxa/spitz.c
> +++ b/arch/arm/mach-pxa/spitz.c
> @@ -525,13 +525,33 @@ static void spitz_bl_kick_battery(void)
> }
> }
>
> +static struct gpiod_lookup_table spitz_lcdcon_gpio_table = {
> + .dev_id = "spi2.1",
> + .table = {
> + GPIO_LOOKUP("gpio-pxa", SPITZ_GPIO_BACKLIGHT_CONT,
> + "BL_CONT", GPIO_ACTIVE_LOW),
> + GPIO_LOOKUP("gpio-pxa", SPITZ_GPIO_BACKLIGHT_ON,
> + "BL_ON", GPIO_ACTIVE_HIGH),
> + { },
> + },
> +};
> +
> +static struct gpiod_lookup_table akita_lcdcon_gpio_table = {
> + .dev_id = "spi2.1",
> + .table = {
> + GPIO_LOOKUP("gpio-pxa", AKITA_GPIO_BACKLIGHT_CONT,
> + "BL_CONT", GPIO_ACTIVE_LOW),
> + GPIO_LOOKUP("gpio-pxa", AKITA_GPIO_BACKLIGHT_ON,
> + "BL_ON", GPIO_ACTIVE_HIGH),
> + { },
> + },
> +};
> +
> static struct corgi_lcd_platform_data spitz_lcdcon_info = {
> .init_mode = CORGI_LCD_MODE_VGA,
> .max_intensity = 0x2f,
> .default_intensity = 0x1f,
> .limit_mask = 0x0b,
> - .gpio_backlight_cont = SPITZ_GPIO_BACKLIGHT_CONT,
> - .gpio_backlight_on = SPITZ_GPIO_BACKLIGHT_ON,
> .kick_battery = spitz_bl_kick_battery,
> };
>
> @@ -574,12 +594,10 @@ static struct pxa2xx_spi_controller spitz_spi_info = {
>
> static void __init spitz_spi_init(void)
> {
> - struct corgi_lcd_platform_data *lcd_data = &spitz_lcdcon_info;
> -
> - if (machine_is_akita()) {
> - lcd_data->gpio_backlight_cont = AKITA_GPIO_BACKLIGHT_CONT;
> - lcd_data->gpio_backlight_on = AKITA_GPIO_BACKLIGHT_ON;
> - }
> + if (machine_is_akita())
> + gpiod_add_lookup_table(&akita_lcdcon_gpio_table);
> + else
> + gpiod_add_lookup_table(&spitz_lcdcon_gpio_table);
>
> pxa2xx_set_spi_info(2, &spitz_spi_info);
> spi_register_board_info(ARRAY_AND_SIZE(spitz_spi_devices));
> diff --git a/drivers/video/backlight/corgi_lcd.c b/drivers/video/backlight/corgi_lcd.c
> index 68f7592c5060..25ef0cbd7583 100644
> --- a/drivers/video/backlight/corgi_lcd.c
> +++ b/drivers/video/backlight/corgi_lcd.c
> @@ -15,7 +15,7 @@
> #include <linux/kernel.h>
> #include <linux/init.h>
> #include <linux/delay.h>
> -#include <linux/gpio.h>
> +#include <linux/gpio/consumer.h>
> #include <linux/fb.h>
> #include <linux/lcd.h>
> #include <linux/spi/spi.h>
> @@ -90,9 +90,8 @@ struct corgi_lcd {
> int mode;
> char buf[2];
>
> - int gpio_backlight_on;
> - int gpio_backlight_cont;
> - int gpio_backlight_cont_inverted;
> + struct gpio_desc *backlight_on;
> + struct gpio_desc *backlight_cont;
>
> void (*kick_battery)(void);
> };
> @@ -403,13 +402,13 @@ static int corgi_bl_set_intensity(struct corgi_lcd *lcd, int intensity)
> corgi_ssp_lcdtg_send(lcd, DUTYCTRL_ADRS, intensity);
>
> /* Bit 5 via GPIO_BACKLIGHT_CONT */
> - cont = !!(intensity & 0x20) ^ lcd->gpio_backlight_cont_inverted;
> + cont = !!(intensity & 0x20);
>
> - if (gpio_is_valid(lcd->gpio_backlight_cont))
> - gpio_set_value_cansleep(lcd->gpio_backlight_cont, cont);
> + if (lcd->backlight_cont)
> + gpiod_set_value_cansleep(lcd->backlight_cont, cont);
>
> - if (gpio_is_valid(lcd->gpio_backlight_on))
> - gpio_set_value_cansleep(lcd->gpio_backlight_on, intensity);
> + if (lcd->backlight_on)
> + gpiod_set_value_cansleep(lcd->backlight_on, intensity);
>
> if (lcd->kick_battery)
> lcd->kick_battery();
> @@ -482,48 +481,17 @@ static int setup_gpio_backlight(struct corgi_lcd *lcd,
> struct corgi_lcd_platform_data *pdata)
> {
> struct spi_device *spi = lcd->spi_dev;
> - int err;
> -
> - lcd->gpio_backlight_on = -1;
> - lcd->gpio_backlight_cont = -1;
> -
> - if (gpio_is_valid(pdata->gpio_backlight_on)) {
> - err = devm_gpio_request(&spi->dev, pdata->gpio_backlight_on,
> - "BL_ON");
> - if (err) {
> - dev_err(&spi->dev,
> - "failed to request GPIO%d for backlight_on\n",
> - pdata->gpio_backlight_on);
> - return err;
> - }
> -
> - lcd->gpio_backlight_on = pdata->gpio_backlight_on;
> - gpio_direction_output(lcd->gpio_backlight_on, 0);
> - }
>
> - if (gpio_is_valid(pdata->gpio_backlight_cont)) {
> - err = devm_gpio_request(&spi->dev, pdata->gpio_backlight_cont,
> - "BL_CONT");
> - if (err) {
> - dev_err(&spi->dev,
> - "failed to request GPIO%d for backlight_cont\n",
> - pdata->gpio_backlight_cont);
> - return err;
> - }
> -
> - lcd->gpio_backlight_cont = pdata->gpio_backlight_cont;
> -
> - /* spitz and akita use both GPIOs for backlight, and
> - * have inverted polarity of GPIO_BACKLIGHT_CONT
> - */
> - if (gpio_is_valid(lcd->gpio_backlight_on)) {
> - lcd->gpio_backlight_cont_inverted = 1;
> - gpio_direction_output(lcd->gpio_backlight_cont, 1);
> - } else {
> - lcd->gpio_backlight_cont_inverted = 0;
> - gpio_direction_output(lcd->gpio_backlight_cont, 0);
> - }
> - }
> + lcd->backlight_on = devm_gpiod_get_optional(&spi->dev,
> + "BL_ON", GPIOD_OUT_LOW);
> + if (IS_ERR(lcd->backlight_on))
> + return PTR_ERR(lcd->backlight_on);
> +
> + lcd->backlight_cont = devm_gpiod_get_optional(&spi->dev, "BL_CONT",
> + GPIOD_OUT_LOW);
> + if (IS_ERR(lcd->backlight_cont))
> + return PTR_ERR(lcd->backlight_cont);
> +
> return 0;
> }
>
> diff --git a/include/linux/spi/corgi_lcd.h b/include/linux/spi/corgi_lcd.h
> index edf4beccdadb..0b857616919c 100644
> --- a/include/linux/spi/corgi_lcd.h
> +++ b/include/linux/spi/corgi_lcd.h
> @@ -11,9 +11,6 @@ struct corgi_lcd_platform_data {
> int default_intensity;
> int limit_mask;
>
> - int gpio_backlight_on; /* -1 if n/a */
> - int gpio_backlight_cont; /* -1 if n/a */
> -
> void (*notify)(int intensity);
> void (*kick_battery)(void);
> };
> --
> 2.24.1
>
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* [PATCH 2/2] tty: serial: samsung_tty: remove SERIAL_SAMSUNG_DEBUG
From: Greg Kroah-Hartman @ 2020-02-20 10:26 UTC (permalink / raw)
To: linux-serial
Cc: Donghoon Yu, linux-samsung-soc, Greg Kroah-Hartman, linux-kernel,
Krzysztof Kozlowski, Shinbeom Choi, Hyunki Koo, Kukjin Kim,
linux-arm-kernel, Jiri Slaby, HYUN-KI KOO
In-Reply-To: <20200220102628.3371996-1-gregkh@linuxfoundation.org>
Since a05025d0ce72 ("tty: serial: samsung_tty: use standard debugging
macros") this configuration option is not used at all, so remove it from
the Kconfig file.
Cc: Kukjin Kim <kgene@kernel.org>
Cc: Donghoon Yu <hoony.yu@samsung.com>
Cc: Hyunki Koo <kkoos00@naver.com>
Cc: HYUN-KI KOO <hyunki00.koo@samsung.com>
Cc: Shinbeom Choi <sbeom.choi@samsung.com>
Cc: Krzysztof Kozlowski <krzk@kernel.org>
Cc: Jiri Slaby <jslaby@suse.com>
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-samsung-soc@vger.kernel.org
Cc: linux-serial@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/tty/serial/Kconfig | 9 ---------
1 file changed, 9 deletions(-)
diff --git a/drivers/tty/serial/Kconfig b/drivers/tty/serial/Kconfig
index a310bd22f1e2..fa4380b0b869 100644
--- a/drivers/tty/serial/Kconfig
+++ b/drivers/tty/serial/Kconfig
@@ -259,15 +259,6 @@ config SERIAL_SAMSUNG_UARTS
help
Select the number of available UART ports for the Samsung S3C
serial driver
-
-config SERIAL_SAMSUNG_DEBUG
- bool "Samsung SoC serial debug"
- depends on SERIAL_SAMSUNG && DEBUG_LL
- help
- Add support for debugging the serial driver. Since this is
- generally being used as a console, we use our own output
- routines that go via the low-level debug printascii()
- function.
config SERIAL_SAMSUNG_CONSOLE
bool "Support for console on Samsung SoC serial port"
--
2.25.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH V3 3/7] devicetree-binding: Add pmc gpio node
From: Bartosz Golaszewski @ 2020-02-20 10:26 UTC (permalink / raw)
To: Srinivas Neeli
Cc: Linus Walleij, shubhrajyoti.datta, Michal Simek, LKML, linux-gpio,
git, arm-soc
In-Reply-To: <1581942793-19468-4-git-send-email-srinivas.neeli@xilinx.com>
pon., 17 lut 2020 o 13:33 Srinivas Neeli <srinivas.neeli@xilinx.com> napisał(a):
>
> From: Shubhrajyoti Datta <shubhrajyoti.datta@xilinx.com>
>
> Add the pmc gpio node to the device tree.
>
Same here: I don't know what pmc gpio node is nor do I need to. Please
make your commit messages more verbose.
Bartosz
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [meta-oe][master][PATCH] strongswan: avoid charon crash
From: Saloni Jain @ 2020-02-20 10:26 UTC (permalink / raw)
To: openembedded-core@lists.openembedded.org, Khem Raj
Cc: Nisha Parrakat, Rahul Taya, Aditya Tayade, Anuj Chougule
[-- Attachment #1: Type: text/plain, Size: 6611 bytes --]
From: Anuj Chougule <Anuj.Chougule@kpit.com>
This is a possible fix to charon that crashed early due to invalid
memory access.
Important frames from Backtraces :
8 0x00007f607246e160 in memcpy (__len=1704, __src=<optimized out>, __dest=<optimized out>)
at /usr/include/bits/string_fortified.h:34
No locals.
9 memcpy_noop (n=1704, src=<optimized out>, dst=<optimized out>)
at /usr/src/debug/strongswan/5.7.2-r0/strongswan-5.7.2/src/libstrongswan/utils/utils/memory.h:47
n = 1704
src = <optimized out>
dst = <optimized out>
10 chunk_create_clone (ptr=<optimized out>, chunk=...)
at /usr/src/debug/strongswan/5.7.2-r0/strongswan-5.7.2/src/libstrongswan/utils/chunk.c:48
clone = <optimized out>
11 0x00007f606ebae810 in load_from_blob (blob=..., type=type@entry=CRED_PRIVATE_KEY, subtype=subtype@entry=1,
subject=subject@entry=0x0, flags=flags@entry=X509_NONE)
at /usr/src/debug/strongswan/5.7.2-r0/strongswan-5.7.2/src/libstrongswan/plugins/pem/pem_builder.c:399
x = <optimized out>
cred = 0x0
---Type <return> to continue, or q <return> to quit---
pgp = false
12 0x00007f606ebaf0e4 in load_from_file (flags=X509_NONE, subject=0x0, subtype=1, type=CRED_PRIVATE_KEY,
file=0x7f6069d21a20 "/var/opt/public/sps/sps_necema/data/public/IPsec/secureboot_on/IPsec-internal_key.pem")
at /usr/src/debug/strongswan/5.7.2-r0/strongswan-5.7.2/src/libstrongswan/plugins/pem/pem_builder.c:452
cred = <optimized out>
chunk = 0x7f6054005430
13 pem_load (type=CRED_PRIVATE_KEY, subtype=1, args=<optimized out>)
at /usr/src/debug/strongswan/5.7.2-r0/strongswan-5.7.2/src/libstrongswan/plugins/pem/pem_builder.c:498
file = 0x7f6069d21a20 "/var/opt/public/sps/sps_necema/data/public/IPsec/secureboot_on/IPsec-internal_key.pem"
pem = <optimized out>
subject = 0x0
flags = 0
Problem lies in frame 12 & 11.
(gdb) f 12
12 0x00007f606ebaf0e4 in load_from_file (flags=X509_NONE, subject=0x0, subtype=1, type=CRED_PRIVATE_KEY,
file=0x7f6069d21a20 "/var/opt/public/sps/sps_necema/data/public/IPsec/secureboot_on/IPsec-internal_key.pem")
at /usr/src/debug/strongswan/5.7.2-r0/strongswan-5.7.2/src/libstrongswan/plugins/pem/pem_builder.c:452
452 in /usr/src/debug/strongswan/5.7.2-r0/strongswan-5.7.2/src/libstrongswan/plugins/pem/pem_builder.c
(gdb) info locals
cred = <optimized out>
chunk = 0x7f6054005430
(gdb) print *chunk
$21 = {ptr = 0x7f60728b7000 <error: Cannot access memory at address 0x7f60728b7000>, len = 1704}
(gdb) f 11
11 0x00007f606ebae810 in load_from_blob (blob=..., type=type@entry=CRED_PRIVATE_KEY, subtype=subtype@entry=1, subject=subject@entry=0x0,
flags=flags@entry=X509_NONE) at /usr/src/debug/strongswan/5.7.2-r0/strongswan-5.7.2/src/libstrongswan/plugins/pem/pem_builder.c:399
399 in /usr/src/debug/strongswan/5.7.2-r0/strongswan-5.7.2/src/libstrongswan/plugins/pem/pem_builder.c
(gdb) info args
blob = {ptr = 0x7f60728b7000 <error: Cannot access memory at address 0x7f60728b7000>, len = 140052215328768}
type = CRED_PRIVATE_KEY
subtype = 1
subject = 0x0
flags = X509_NONE
(gdb) print blob
$22 = {ptr = 0x7f60728b7000 <error: Cannot access memory at address 0x7f60728b7000>, len = 140052215328768}
Source code snippet :
static void *load_from_file(char *file, credential_type_t type, int subtype,
identification_t *subject, x509_flag_t flags)
{
void *cred;
chunk_t *chunk;
chunk = chunk_map(file, FALSE);
if (!chunk)
{
DBG1(DBG_LIB, " opening '%s' failed: %s", file, strerror(errno));
return NULL;
}
cred = load_from_blob(*chunk, type, subtype, subject, flags);
chunk_unmap(chunk);
return cred;
}
Local variable chunk is an uninitialised pointer in load_from_file()
(frame 12 above) which is expected to get initialised through
chunk_map() & then passed to load_from_blob() as a parameter.
But somehow, the chunk pointer has not got initialised &
got passed as it is to load_from_blob() in frame 11 above.
As this contains a garbage address, when method load_from_blob()
tried cloning the memory regions through chunk_clone() ->
chunk_create_clone() -> memcpy() -> memcpy_noop(), it crashed with
SIGBUS (frames 10, 9, 8).
It could also be that chunk_map() has a bug which does not memmap()
the full or correct areas.
Upstream-Status: Pending
Tested By: Anuj Chougule <Anuj.Chougule@kpit.com>
Signed-off-by: Anuj Chougule <Anuj.Chougule@kpit.com>
Signed-off-by: Saloni Jain <Saloni.Jain@kpit.com>
---
.../strongswan/files/fix-charon-crash.patch | 23 ++++++++++++++++++++++
1 file changed, 23 insertions(+)
create mode 100644 recipes-support/strongswan/files/fix-charon-crash.patch
diff --git a/recipes-support/strongswan/files/fix-charon-crash.patch b/recipes-support/strongswan/files/fix-charon-crash.patch
new file mode 100644
index 0000000..95e71a2
--- /dev/null
+++ b/recipes-support/strongswan/files/fix-charon-crash.patch
@@ -0,0 +1,23 @@
+strongswan: avoid charon crash
+
+Variable chunk is an uninitialised pointer,which
+is expected to get initialised through method chunk_map()
+& then passed to load_from_blob() as a parameter.
+But somehow, if the chunk pointer did not get initialised & gets
+passed as it is to load_from_blob(), it may lead crash as this
+contains a garbage address.
+
+Signed-off-by: Anuj Chougule <Anuj.Chougule@kpit.com>
+Upstream-Status: Pending
+
+--- a/src/libstrongswan/plugins/pem/pem_builder.c
++++ b/src/libstrongswan/plugins/pem/pem_builder.c
+@@ -441,7 +441,7 @@ static void *load_from_file(char *file, credential_type_t type, int subtype,
+ identification_t *subject, x509_flag_t flags)
+ {
+ void *cred;
+- chunk_t *chunk;
++ chunk_t *chunk = NULL;
+
+ chunk = chunk_map(file, FALSE);
+ if (!chunk)
--
2.7.4
This message contains information that may be privileged or confidential and is the property of the KPIT Technologies Ltd. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message. KPIT Technologies Ltd. does not accept any liability for virus infected mails.
[-- Attachment #2: Type: text/html, Size: 10479 bytes --]
^ permalink raw reply related
* Re: usb cdc-acm TIOCSSERIAL may wrongly report EPERM
From: Oliver Neukum @ 2020-02-20 10:27 UTC (permalink / raw)
To: Anthony Mallet; +Cc: linux-usb
In-Reply-To: <24141.6739.313167.448875@beetle.laas.fr>
Am Mittwoch, den 19.02.2020, 12:21 +0100 schrieb Anthony Mallet:
> On Wednesday 19 Feb 2020, at 10:56, Oliver Neukum wrote:
> > thank you for the detailed report about an unusual bug. Could you
> > test the attached patch?
>
> I did not actually run it yet, but at first sight it seems that it will
> mishandle the ASYNC_CLOSING_WAIT_NONE case.
You are right.
> Yes, no problem. Thank you.
> I hope my patches follow the required format, I'm not sure about all
> the details.
The patches themselves look good. Please follow
Documentation/SubmittingPatches
Regards
Oliver
PS: my mailer seems to suffer a malfunction with HTML.
Sorry for the erstwhiole empty post
^ permalink raw reply
* Re: [PATCH v4 1/6] driver core: Fix driver_deferred_probe_check_state() logic
From: Rafael J. Wysocki @ 2020-02-20 10:28 UTC (permalink / raw)
To: John Stultz
Cc: lkml, Rob Herring, Rafael J. Wysocki, Kevin Hilman, Ulf Hansson,
Pavel Machek, Len Brown, Todd Kjos, Bjorn Andersson,
Liam Girdwood, Mark Brown, Thierry Reding, Linus Walleij,
Greg Kroah-Hartman, Linux PM
In-Reply-To: <20200220050440.45878-2-john.stultz@linaro.org>
On Thu, Feb 20, 2020 at 6:05 AM John Stultz <john.stultz@linaro.org> wrote:
>
> driver_deferred_probe_check_state() has some uninituitive behavior.
>
> * From boot to late_initcall, it returns -EPROBE_DEFER
>
> * From late_initcall to the deferred_probe_timeout (if set)
> it returns -ENODEV
>
> * If the deferred_probe_timeout it set, after it fires, it
> returns -ETIMEDOUT
>
> This is a bit confusing, as its useful to have the function
> return -EPROBE_DEFER while the timeout is still running. This
> behavior has resulted in the somwhat duplicative
> driver_deferred_probe_check_state_continue() function being
> added.
>
> Thus this patch tries to improve the logic, so that it behaves
> as such:
>
> * If deferred_probe_timeout is set, it returns -EPROBE_DEFER
> until the timeout, afterwhich it returns -ETIMEDOUT.
>
> * If deferred_probe_timeout is not set (-1), it returns
> -EPROBE_DEFER until late_initcall, after which it returns
>
> This will make the deferred_probe_timeout value much more
> functional, and will allow us to consolidate the
> driver_deferred_probe_check_state() and
> driver_deferred_probe_check_state_continue() logic in a later
> patch.
>
> Cc: Rob Herring <robh@kernel.org>
> Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
> Cc: Kevin Hilman <khilman@kernel.org>
> Cc: Ulf Hansson <ulf.hansson@linaro.org>
> Cc: Pavel Machek <pavel@ucw.cz>
> Cc: Len Brown <len.brown@intel.com>
> Cc: Todd Kjos <tkjos@google.com>
> Cc: Bjorn Andersson <bjorn.andersson@linaro.org>
> Cc: Liam Girdwood <lgirdwood@gmail.com>
> Cc: Mark Brown <broonie@kernel.org>
> Cc: Thierry Reding <treding@nvidia.com>
> Cc: Linus Walleij <linus.walleij@linaro.org>
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Cc: linux-pm@vger.kernel.org
> Signed-off-by: John Stultz <john.stultz@linaro.org>
> Change-Id: I8349b7a403ce8cbce485ea0a0a5512fddffb635c
> ---
> v4:
> * Simplified logic suggested by Andy Shevchenko
> * Clarified commit message to focus on logic change
> ---
> drivers/base/dd.c | 10 ++++++----
> 1 file changed, 6 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/base/dd.c b/drivers/base/dd.c
> index b25bcab2a26b..bb383dca39c1 100644
> --- a/drivers/base/dd.c
> +++ b/drivers/base/dd.c
> @@ -237,7 +237,7 @@ __setup("deferred_probe_timeout=", deferred_probe_timeout_setup);
>
> static int __driver_deferred_probe_check_state(struct device *dev)
> {
> - if (!initcalls_done)
> + if (!initcalls_done || deferred_probe_timeout > 0)
> return -EPROBE_DEFER;
Makes sense to me.
>
> if (!deferred_probe_timeout) {
> @@ -252,9 +252,11 @@ static int __driver_deferred_probe_check_state(struct device *dev)
> * driver_deferred_probe_check_state() - Check deferred probe state
> * @dev: device to check
> *
> - * Returns -ENODEV if init is done and all built-in drivers have had a chance
> - * to probe (i.e. initcalls are done), -ETIMEDOUT if deferred probe debug
> - * timeout has expired, or -EPROBE_DEFER if none of those conditions are met.
> + * Returnes -EPROBE_DEFER if initcalls have not completed, or the deferred
s/Returnes/Returns/
And I would write
* Return:
* -EPROBE_DEFER if initcalls have not completed, or the deferred
* probe timeout is set, but not expried.
* -ETIMEDOUT if the deferred probe timeout was set and has expired.
* -ENODEV if initcalls have completed and the deferred probe timeout
was not set.
> + * probe timeout is set, but not expried.
> + * Returns -ETIMEDOUT if the probe timeout was set and has expired.
> + * Returns -ENODEV if initcalls have completed and the deferred probe timeout
> + * was not set.
> *
> * Drivers or subsystems can opt-in to calling this function instead of directly
> * returning -EPROBE_DEFER.
> --
^ permalink raw reply
* Re: [PATCH V3 0/7] gpio: zynq: Update on gpio-zynq driver
From: Bartosz Golaszewski @ 2020-02-20 10:28 UTC (permalink / raw)
To: Srinivas Neeli
Cc: Linus Walleij, Michal Simek, shubhrajyoti.datta, linux-gpio,
arm-soc, LKML, git
In-Reply-To: <1581942793-19468-1-git-send-email-srinivas.neeli@xilinx.com>
pon., 17 lut 2020 o 13:33 Srinivas Neeli <srinivas.neeli@xilinx.com> napisał(a):
>
> This patch series does the following:
> -protect direction in/out with a spinlock
> -Add binding for Versal gpio
> -Add binding for pmc gpio node
> -Add Versal support
> -Disable the irq if it is not a wakeup source
> -Add pmc gpio support
> -Remove error prints in EPROBE_DEFER
>
> ---
> Changes in V2:
> - In previous series [PATCH 1/8] already applied on "linux-next".
> - Fixed checkpatch warning for spinlock description.
> - Added description for Versal PS_GPIO and PMC_GPIO.
> Changes in V3:
> - Updated commit description for PATCH 4 and 6.
> ---
>
> Glenn Langedock (1):
> gpio: zynq: protect direction in/out with a spinlock
>
> Shubhrajyoti Datta (6):
> dt-bindings: gpio: Add binding for Versal gpio
> devicetree-binding: Add pmc gpio node
> gpio: zynq: Add Versal support
> gpio: zynq: Disable the irq if it is not a wakeup source
> gpio: zynq: Add pmc gpio support
> gpio: zynq: Remove error prints in EPROBE_DEFER
>
> .../devicetree/bindings/gpio/gpio-zynq.txt | 4 +-
> drivers/gpio/gpio-zynq.c | 66 +++++++++++++++++++++-
> 2 files changed, 67 insertions(+), 3 deletions(-)
>
> --
> 2.7.4
>
Other than the commit messages, the series looks good to me.
Bart
^ permalink raw reply
* Re: [PATCH V3 0/7] gpio: zynq: Update on gpio-zynq driver
From: Bartosz Golaszewski @ 2020-02-20 10:28 UTC (permalink / raw)
To: Srinivas Neeli
Cc: Linus Walleij, shubhrajyoti.datta, Michal Simek, LKML, linux-gpio,
git, arm-soc
In-Reply-To: <1581942793-19468-1-git-send-email-srinivas.neeli@xilinx.com>
pon., 17 lut 2020 o 13:33 Srinivas Neeli <srinivas.neeli@xilinx.com> napisał(a):
>
> This patch series does the following:
> -protect direction in/out with a spinlock
> -Add binding for Versal gpio
> -Add binding for pmc gpio node
> -Add Versal support
> -Disable the irq if it is not a wakeup source
> -Add pmc gpio support
> -Remove error prints in EPROBE_DEFER
>
> ---
> Changes in V2:
> - In previous series [PATCH 1/8] already applied on "linux-next".
> - Fixed checkpatch warning for spinlock description.
> - Added description for Versal PS_GPIO and PMC_GPIO.
> Changes in V3:
> - Updated commit description for PATCH 4 and 6.
> ---
>
> Glenn Langedock (1):
> gpio: zynq: protect direction in/out with a spinlock
>
> Shubhrajyoti Datta (6):
> dt-bindings: gpio: Add binding for Versal gpio
> devicetree-binding: Add pmc gpio node
> gpio: zynq: Add Versal support
> gpio: zynq: Disable the irq if it is not a wakeup source
> gpio: zynq: Add pmc gpio support
> gpio: zynq: Remove error prints in EPROBE_DEFER
>
> .../devicetree/bindings/gpio/gpio-zynq.txt | 4 +-
> drivers/gpio/gpio-zynq.c | 66 +++++++++++++++++++++-
> 2 files changed, 67 insertions(+), 3 deletions(-)
>
> --
> 2.7.4
>
Other than the commit messages, the series looks good to me.
Bart
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [RFC v6 07/23] RISC-V: Use 64-bit time_t and off_t for RV32 and RV64
From: Lukasz Majewski @ 2020-02-20 10:28 UTC (permalink / raw)
To: Arnd Bergmann, Joseph Myers
Cc: fweimer@redhat.com, libc-alpha@sourceware.org, Andreas Schwab,
Vineet Gupta, palmerdabbelt@google.com, zongbox@gmail.com,
Alistair Francis, adhemerval.zanella@linaro.org, macro@wdc.com,
Alistair Francis, arcml
In-Reply-To: <CAK8P3a3MTQf_fnEWiGVxzexZzYNQ34h29aNxH_YApmsVzY6OsA@mail.gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 2436 bytes --]
Hi Arnd, Joseph,
> On Thu, Feb 20, 2020 at 1:46 AM Joseph Myers
> <joseph@codesourcery.com> wrote:
> >
> > On Thu, 20 Feb 2020, Vineet Gupta wrote:
> >
> > > The first 4 will need more work as sym aliasing like
> > > strong_alias (__xstat64, __xstat)
> > >
> > > will be needed in those ARM files (which in turn use i386).
> >
> > The situation for Arm is fundamentally different from that for ARC.
> >
> > For ARC, you only need a single public stat structure (using 64-bit
> > times and offsets).
> >
> > For Arm, a third public stat structure will need to be added
> > alongside the existing two, initially used internally in
> > 64-bit-time stat functions that aren't exported from glibc,
> > eventually to be used with _TIME_BITS=64 with the 64-bit-time stat
> > interfaces exported once all the _TIME_BITS=64 interfaces are
> > ready.
>
> But surely that structure layout would be the same on ARM and ARC
> as well as all other 32-bit architectures with _TIME_BITS=64, right?
>
For ARM32 stat case (current):
./io/stat.c -> __xstat -> ./sysdeps/unix/sysv/linux/xstat64.c
and then struct stat64 buf is filled by the kernel.
The generic idea (which requires converting
./sysdeps/unix/sysv/linux/xstat64.c) would be to use statx always in
glibc instead of stat* syscalls (as it is done in
sysdeps/unix/sysv/linux/generic/wordsize-32/xstat64.c)
To do that we do need in-glibc internal new type - namely struct
stat64_time64
which would have always:
__time64_t st_atime; (and st_mtime, st_ctime).
instead of
__time_t st_atime;
and also introduce __cp_stat64_time64_statx along with __cp_stat64_statx
as struct statx inherently support 64 bit time via struct
statx_timestamp even on 32 bit archs.
IMHO using statx as widely as possible in glibc is the easiest way to
convert stat* and friends functions to support Y2038.
> What's wrong with having a single implementation for the most
> recent set of stat syscalls, with the older variants being only
> compiled for architectures that need them to support _TIME_BITS=32
> and/or _FILE_OFFSET_BITS=32?
>
> Arnd
Best regards,
Lukasz Majewski
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lukma@denx.de
[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #2: Type: text/plain, Size: 170 bytes --]
_______________________________________________
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
^ permalink raw reply
* Re: [RFC PATCH 0/5] Removing support for 32bit KVM/arm host
From: Marc Zyngier @ 2020-02-20 10:29 UTC (permalink / raw)
To: Jan Kiszka
Cc: Arnd Bergmann, Linux ARM, kvmarm, kvm list, James Morse,
Julien Thierry, Suzuki K Poulose, Paolo Bonzini, Christoffer Dall,
Will Deacon, Quentin Perret, Russell King, Vladimir Murzin,
Anders Berg, jailhouse-dev, jean-philippe.brucker
In-Reply-To: <ea7bc1d0-0a11-8ed6-da70-d603d8107bf6@siemens.com>
On 2020-02-19 15:46, Jan Kiszka wrote:
> On 19.02.20 16:09, Arnd Bergmann wrote:
>> On Mon, Feb 10, 2020 at 3:13 PM Marc Zyngier <maz@kernel.org> wrote:
>>>
>>> KVM/arm was merged just over 7 years ago, and has lived a very quiet
>>> life so far. It mostly works if you're prepared to deal with its
>>> limitations, it has been a good prototype for the arm64 version,
>>> but it suffers a few problems:
>>>
>>> - It is incomplete (no debug support, no PMU)
>>> - It hasn't followed any of the architectural evolutions
>>> - It has zero users (I don't count myself here)
>>> - It is more and more getting in the way of new arm64 developments
>>>
>>> So here it is: unless someone screams and shows that they rely on
>>> KVM/arm to be maintained upsteam, I'll remove 32bit host support
>>> form the tree. One of the reasons that makes me confident nobody is
>>> using it is that I never receive *any* bug report. Yes, it is
>>> perfect.
>>> But if you depend on KVM/arm being available in mainline, please
>>> shout.
>>>
>>> To reiterate: 32bit guest support for arm64 stays, of course. Only
>>> 32bit host goes. Once this is merged, I plan to move virt/kvm/arm to
>>> arm64, and cleanup all the now unnecessary abstractions.
>>>
>>> The patches have been generated with the -D option to avoid spamming
>>> everyone with huge diffs, and there is a kvm-arm/goodbye branch in
>>> my kernel.org repository.
>>
>> Just one more thought before it's gone: is there any shared code
>> (header files?) that is used by the jailhouse hypervisor?
>>
>> If there is, are there any plans to merge that into the mainline
>> kernel
>> for arm32 in the near future?
>>
>> I'm guessing the answer to at least one of those questions is 'no', so
>> we don't need to worry about it, but it seems better to ask.
>
> Good that you mention it: There is one thing we share on ARM (and
> ARM64), and that is the hypervisor enabling stub, to install our own
> vectors. If that was to be removed as well, we would have to patch it
> back downstream. So far, we only carry few EXPORT_SYMBOL patches for
> essential enabling.
I actually have a few extra patches on top of the series, one of them
actually removing the ability to register new vectors (mostly because
I don't like leaving unused stuff behind), see [1]. I'll post an update
so that we can discuss whether we want this particular to stay or not.
> That said, I was also starting to think about how long we will
> continue to support Jailhouse on 32-bit ARM. We currently have no
> supported SoC there that comes with an SMMU, and I doubt to see one
> still showing up. So, Jailhouse on ARM is really just a testing/demo
> case, maybe useful (but I didn't get concrete feedback) for cleaner
> collaborative AMP for real-time purposes, without security concerns. I
> assume 32-bit ARM will never be part of what would be proposed of
> Jailhouse for upstream.
I guess we all come to the same conclusion...
M.
[1]
https://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git/commit/?h=kvm-arm/goodbye&id=0943dd119105b65197adffda52c402cce28da56d
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* Re: [RFC PATCH 0/5] Removing support for 32bit KVM/arm host
From: Marc Zyngier @ 2020-02-20 10:29 UTC (permalink / raw)
To: Jan Kiszka
Cc: jailhouse-dev, Anders Berg, Vladimir Murzin, Russell King,
Arnd Bergmann, kvm list, Suzuki K Poulose, jean-philippe.brucker,
Quentin Perret, Christoffer Dall, James Morse, Linux ARM,
Paolo Bonzini, Will Deacon, kvmarm, Julien Thierry
In-Reply-To: <ea7bc1d0-0a11-8ed6-da70-d603d8107bf6@siemens.com>
On 2020-02-19 15:46, Jan Kiszka wrote:
> On 19.02.20 16:09, Arnd Bergmann wrote:
>> On Mon, Feb 10, 2020 at 3:13 PM Marc Zyngier <maz@kernel.org> wrote:
>>>
>>> KVM/arm was merged just over 7 years ago, and has lived a very quiet
>>> life so far. It mostly works if you're prepared to deal with its
>>> limitations, it has been a good prototype for the arm64 version,
>>> but it suffers a few problems:
>>>
>>> - It is incomplete (no debug support, no PMU)
>>> - It hasn't followed any of the architectural evolutions
>>> - It has zero users (I don't count myself here)
>>> - It is more and more getting in the way of new arm64 developments
>>>
>>> So here it is: unless someone screams and shows that they rely on
>>> KVM/arm to be maintained upsteam, I'll remove 32bit host support
>>> form the tree. One of the reasons that makes me confident nobody is
>>> using it is that I never receive *any* bug report. Yes, it is
>>> perfect.
>>> But if you depend on KVM/arm being available in mainline, please
>>> shout.
>>>
>>> To reiterate: 32bit guest support for arm64 stays, of course. Only
>>> 32bit host goes. Once this is merged, I plan to move virt/kvm/arm to
>>> arm64, and cleanup all the now unnecessary abstractions.
>>>
>>> The patches have been generated with the -D option to avoid spamming
>>> everyone with huge diffs, and there is a kvm-arm/goodbye branch in
>>> my kernel.org repository.
>>
>> Just one more thought before it's gone: is there any shared code
>> (header files?) that is used by the jailhouse hypervisor?
>>
>> If there is, are there any plans to merge that into the mainline
>> kernel
>> for arm32 in the near future?
>>
>> I'm guessing the answer to at least one of those questions is 'no', so
>> we don't need to worry about it, but it seems better to ask.
>
> Good that you mention it: There is one thing we share on ARM (and
> ARM64), and that is the hypervisor enabling stub, to install our own
> vectors. If that was to be removed as well, we would have to patch it
> back downstream. So far, we only carry few EXPORT_SYMBOL patches for
> essential enabling.
I actually have a few extra patches on top of the series, one of them
actually removing the ability to register new vectors (mostly because
I don't like leaving unused stuff behind), see [1]. I'll post an update
so that we can discuss whether we want this particular to stay or not.
> That said, I was also starting to think about how long we will
> continue to support Jailhouse on 32-bit ARM. We currently have no
> supported SoC there that comes with an SMMU, and I doubt to see one
> still showing up. So, Jailhouse on ARM is really just a testing/demo
> case, maybe useful (but I didn't get concrete feedback) for cleaner
> collaborative AMP for real-time purposes, without security concerns. I
> assume 32-bit ARM will never be part of what would be proposed of
> Jailhouse for upstream.
I guess we all come to the same conclusion...
M.
[1]
https://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git/commit/?h=kvm-arm/goodbye&id=0943dd119105b65197adffda52c402cce28da56d
--
Jazz is not dead. It just smells funny...
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [RFC PATCH 0/5] Removing support for 32bit KVM/arm host
From: Marc Zyngier @ 2020-02-20 10:29 UTC (permalink / raw)
To: Jan Kiszka
Cc: jailhouse-dev, Anders Berg, Russell King, Arnd Bergmann, kvm list,
jean-philippe.brucker, Linux ARM, Paolo Bonzini, Will Deacon,
kvmarm
In-Reply-To: <ea7bc1d0-0a11-8ed6-da70-d603d8107bf6@siemens.com>
On 2020-02-19 15:46, Jan Kiszka wrote:
> On 19.02.20 16:09, Arnd Bergmann wrote:
>> On Mon, Feb 10, 2020 at 3:13 PM Marc Zyngier <maz@kernel.org> wrote:
>>>
>>> KVM/arm was merged just over 7 years ago, and has lived a very quiet
>>> life so far. It mostly works if you're prepared to deal with its
>>> limitations, it has been a good prototype for the arm64 version,
>>> but it suffers a few problems:
>>>
>>> - It is incomplete (no debug support, no PMU)
>>> - It hasn't followed any of the architectural evolutions
>>> - It has zero users (I don't count myself here)
>>> - It is more and more getting in the way of new arm64 developments
>>>
>>> So here it is: unless someone screams and shows that they rely on
>>> KVM/arm to be maintained upsteam, I'll remove 32bit host support
>>> form the tree. One of the reasons that makes me confident nobody is
>>> using it is that I never receive *any* bug report. Yes, it is
>>> perfect.
>>> But if you depend on KVM/arm being available in mainline, please
>>> shout.
>>>
>>> To reiterate: 32bit guest support for arm64 stays, of course. Only
>>> 32bit host goes. Once this is merged, I plan to move virt/kvm/arm to
>>> arm64, and cleanup all the now unnecessary abstractions.
>>>
>>> The patches have been generated with the -D option to avoid spamming
>>> everyone with huge diffs, and there is a kvm-arm/goodbye branch in
>>> my kernel.org repository.
>>
>> Just one more thought before it's gone: is there any shared code
>> (header files?) that is used by the jailhouse hypervisor?
>>
>> If there is, are there any plans to merge that into the mainline
>> kernel
>> for arm32 in the near future?
>>
>> I'm guessing the answer to at least one of those questions is 'no', so
>> we don't need to worry about it, but it seems better to ask.
>
> Good that you mention it: There is one thing we share on ARM (and
> ARM64), and that is the hypervisor enabling stub, to install our own
> vectors. If that was to be removed as well, we would have to patch it
> back downstream. So far, we only carry few EXPORT_SYMBOL patches for
> essential enabling.
I actually have a few extra patches on top of the series, one of them
actually removing the ability to register new vectors (mostly because
I don't like leaving unused stuff behind), see [1]. I'll post an update
so that we can discuss whether we want this particular to stay or not.
> That said, I was also starting to think about how long we will
> continue to support Jailhouse on 32-bit ARM. We currently have no
> supported SoC there that comes with an SMMU, and I doubt to see one
> still showing up. So, Jailhouse on ARM is really just a testing/demo
> case, maybe useful (but I didn't get concrete feedback) for cleaner
> collaborative AMP for real-time purposes, without security concerns. I
> assume 32-bit ARM will never be part of what would be proposed of
> Jailhouse for upstream.
I guess we all come to the same conclusion...
M.
[1]
https://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git/commit/?h=kvm-arm/goodbye&id=0943dd119105b65197adffda52c402cce28da56d
--
Jazz is not dead. It just smells funny...
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
^ permalink raw reply
* Re: [CFT 4/8] net: axienet: use resolved link config in mac_link_up()
From: Russell King - ARM Linux admin @ 2020-02-20 10:29 UTC (permalink / raw)
To: Andre Przywara
Cc: Andrew Lunn, Florian Fainelli, Heiner Kallweit, David S. Miller,
netdev, Radhey Shyam Pandey, Michal Simek, linux-arm-kernel
In-Reply-To: <E1j3k7t-00072J-RS@rmk-PC.armlinux.org.uk>
Hi Andre,
Are you able to give this (along with patch 1) some testing please?
The series can be grabbed from:
https://patchwork.ozlabs.org/series/159037/mbox/
Strangely, google doesn't find it in the lore.kernel.org archives,
but does in spinics.net archives and patchwork...
On Mon, Feb 17, 2020 at 05:24:09PM +0000, Russell King wrote:
> Convert the Xilinx AXI ethernet driver to use the finalised link
> parameters in mac_link_up() rather than the parameters in mac_config().
>
> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
> ---
> .../net/ethernet/xilinx/xilinx_axienet_main.c | 38 +++++++++----------
> 1 file changed, 19 insertions(+), 19 deletions(-)
>
> diff --git a/drivers/net/ethernet/xilinx/xilinx_axienet_main.c b/drivers/net/ethernet/xilinx/xilinx_axienet_main.c
> index 197740781157..c2f4c5ca2e80 100644
> --- a/drivers/net/ethernet/xilinx/xilinx_axienet_main.c
> +++ b/drivers/net/ethernet/xilinx/xilinx_axienet_main.c
> @@ -1440,6 +1440,22 @@ static void axienet_mac_an_restart(struct phylink_config *config)
>
> static void axienet_mac_config(struct phylink_config *config, unsigned int mode,
> const struct phylink_link_state *state)
> +{
> + /* nothing meaningful to do */
> +}
> +
> +static void axienet_mac_link_down(struct phylink_config *config,
> + unsigned int mode,
> + phy_interface_t interface)
> +{
> + /* nothing meaningful to do */
> +}
> +
> +static void axienet_mac_link_up(struct phylink_config *config,
> + struct phy_device *phy,
> + unsigned int mode, phy_interface_t interface,
> + int speed, int duplex,
> + bool tx_pause, bool rx_pause)
> {
> struct net_device *ndev = to_net_dev(config->dev);
> struct axienet_local *lp = netdev_priv(ndev);
> @@ -1448,7 +1464,7 @@ static void axienet_mac_config(struct phylink_config *config, unsigned int mode,
> emmc_reg = axienet_ior(lp, XAE_EMMC_OFFSET);
> emmc_reg &= ~XAE_EMMC_LINKSPEED_MASK;
>
> - switch (state->speed) {
> + switch (speed) {
> case SPEED_1000:
> emmc_reg |= XAE_EMMC_LINKSPD_1000;
> break;
> @@ -1467,33 +1483,17 @@ static void axienet_mac_config(struct phylink_config *config, unsigned int mode,
> axienet_iow(lp, XAE_EMMC_OFFSET, emmc_reg);
>
> fcc_reg = axienet_ior(lp, XAE_FCC_OFFSET);
> - if (state->pause & MLO_PAUSE_TX)
> + if (tx_pause)
> fcc_reg |= XAE_FCC_FCTX_MASK;
> else
> fcc_reg &= ~XAE_FCC_FCTX_MASK;
> - if (state->pause & MLO_PAUSE_RX)
> + if (rx_pause)
> fcc_reg |= XAE_FCC_FCRX_MASK;
> else
> fcc_reg &= ~XAE_FCC_FCRX_MASK;
> axienet_iow(lp, XAE_FCC_OFFSET, fcc_reg);
> }
>
> -static void axienet_mac_link_down(struct phylink_config *config,
> - unsigned int mode,
> - phy_interface_t interface)
> -{
> - /* nothing meaningful to do */
> -}
> -
> -static void axienet_mac_link_up(struct phylink_config *config,
> - struct phy_device *phy,
> - unsigned int mode, phy_interface_t interface,
> - int speed, int duplex,
> - bool tx_pause, bool rx_pause)
> -{
> - /* nothing meaningful to do */
> -}
> -
> static const struct phylink_mac_ops axienet_phylink_ops = {
> .validate = axienet_validate,
> .mac_pcs_get_state = axienet_mac_pcs_get_state,
> --
> 2.20.1
>
>
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up
^ permalink raw reply
* Re: [PATCH net-next v3 6/9] drivers/base/power: add dpm_sysfs_change_owner()
From: Rafael J. Wysocki @ 2020-02-20 10:30 UTC (permalink / raw)
To: Christian Brauner
Cc: Rafael J. Wysocki, David S. Miller, Greg Kroah-Hartman,
Linux Kernel Mailing List, netdev, Pavel Machek, Jakub Kicinski,
Eric Dumazet, Stephen Hemminger, Linux PM
In-Reply-To: <20200220102107.grkyypt7swrufzas@wittgenstein>
On Thu, Feb 20, 2020 at 11:21 AM Christian Brauner
<christian.brauner@ubuntu.com> wrote:
>
> On Thu, Feb 20, 2020 at 11:02:04AM +0100, Rafael J. Wysocki wrote:
> > On Tue, Feb 18, 2020 at 5:30 PM Christian Brauner
> > <christian.brauner@ubuntu.com> wrote:
> > >
> > > Add a helper to change the owner of a device's power entries. This
> > > needs to happen when the ownership of a device is changed, e.g. when
> > > moving network devices between network namespaces.
> > > This function will be used to correctly account for ownership changes,
> > > e.g. when moving network devices between network namespaces.
> > >
> > > Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>
> > > ---
> > > /* v2 */
> > > - "Rafael J. Wysocki" <rafael@kernel.org>:
> > > - Fold if (dev->power.wakeup && dev->power.wakeup->dev) check into
> > > if (device_can_wakeup(dev)) check since the former can never be true if
> > > the latter is false.
> > >
> > > - Christian Brauner <christian.brauner@ubuntu.com>:
> > > - Place (dev->power.wakeup && dev->power.wakeup->dev) check under
> > > CONFIG_PM_SLEEP ifdefine since it will wakeup_source will only be available
> > > when this config option is set.
> > >
> > > /* v3 */
> > > - Greg Kroah-Hartman <gregkh@linuxfoundation.org>:
> > > - Add explicit uid/gid parameters.
> > > ---
> > > drivers/base/core.c | 4 ++++
> > > drivers/base/power/power.h | 3 +++
> > > drivers/base/power/sysfs.c | 42 ++++++++++++++++++++++++++++++++++++++
> > > 3 files changed, 49 insertions(+)
> > >
> > > diff --git a/drivers/base/core.c b/drivers/base/core.c
> > > index ec0d5e8cfd0f..efec2792f5d7 100644
> > > --- a/drivers/base/core.c
> > > +++ b/drivers/base/core.c
> > > @@ -3522,6 +3522,10 @@ int device_change_owner(struct device *dev, kuid_t kuid, kgid_t kgid)
> > > if (error)
> > > goto out;
> > >
> > > + error = dpm_sysfs_change_owner(dev, kuid, kgid);
> > > + if (error)
> > > + goto out;
> > > +
> > > #ifdef CONFIG_BLOCK
> > > if (sysfs_deprecated && dev->class == &block_class)
> > > goto out;
> > > diff --git a/drivers/base/power/power.h b/drivers/base/power/power.h
> > > index 444f5c169a0b..54292cdd7808 100644
> > > --- a/drivers/base/power/power.h
> > > +++ b/drivers/base/power/power.h
> > > @@ -74,6 +74,7 @@ extern int pm_qos_sysfs_add_flags(struct device *dev);
> > > extern void pm_qos_sysfs_remove_flags(struct device *dev);
> > > extern int pm_qos_sysfs_add_latency_tolerance(struct device *dev);
> > > extern void pm_qos_sysfs_remove_latency_tolerance(struct device *dev);
> > > +extern int dpm_sysfs_change_owner(struct device *dev, kuid_t kuid, kgid_t kgid);
> > >
> > > #else /* CONFIG_PM */
> > >
> > > @@ -88,6 +89,8 @@ static inline void pm_runtime_remove(struct device *dev) {}
> > >
> > > static inline int dpm_sysfs_add(struct device *dev) { return 0; }
> > > static inline void dpm_sysfs_remove(struct device *dev) {}
> > > +static inline int dpm_sysfs_change_owner(struct device *dev, kuid_t kuid,
> > > + kgid_t kgid) { return 0; }
> > >
> > > #endif
> > >
> > > diff --git a/drivers/base/power/sysfs.c b/drivers/base/power/sysfs.c
> > > index d7d82db2e4bc..4e79afcd5ca8 100644
> > > --- a/drivers/base/power/sysfs.c
> > > +++ b/drivers/base/power/sysfs.c
> > > @@ -684,6 +684,48 @@ int dpm_sysfs_add(struct device *dev)
> > > return rc;
> > > }
> > >
> > > +int dpm_sysfs_change_owner(struct device *dev, kuid_t kuid, kgid_t kgid)
> > > +{
> > > + int rc;
> > > +
> > > + if (device_pm_not_required(dev))
> > > + return 0;
> > > +
> > > + rc = sysfs_group_change_owner(&dev->kobj, &pm_attr_group, kuid, kgid);
> > > + if (rc)
> > > + return rc;
> > > +
> > > + if (pm_runtime_callbacks_present(dev)) {
> > > + rc = sysfs_group_change_owner(
> > > + &dev->kobj, &pm_runtime_attr_group, kuid, kgid);
> > > + if (rc)
> > > + return rc;
> > > + }
> > > + if (device_can_wakeup(dev)) {
> > > + rc = sysfs_group_change_owner(&dev->kobj, &pm_wakeup_attr_group,
> > > + kuid, kgid);
> > > + if (rc)
> > > + return rc;
> > > +
> > > +#ifdef CONFIG_PM_SLEEP
> > > + if (dev->power.wakeup && dev->power.wakeup->dev) {
> > > + rc = device_change_owner(dev->power.wakeup->dev, kuid,
> > > + kgid);
> > > + if (rc)
> > > + return rc;
> > > + }
> > > +#endif
> >
> > First off, I don't particularly like #ifdefs in function bodies. In
> > particular, there is a CONFIG_PM_SLEEP block in this file already and
> > you could define a new function in there to carry out the above
> > operations, and provide an empty stub of it for the "unset" case.
> > Failing to do so is somewhat on the "rushing things in" side in my
> > view.
>
> How ifdefines are used is highly dependent on the subsystem; networking
> ofen uses in-place ifdefines in some parts and not in others. That has
> nothing to do with rushing things. I'm happy to change it to your
> preferences.
Thanks!
> Thanks for pointing out your expectations. But please don't
> assume bad intentions on my part because I'm not meeting them right
> away. It often is the case that adding a helper that is called in one
> place is not well-received.
Fair enough, sorry for being harsh.
^ permalink raw reply
* Re: [PATCH] asm-generic/atomic: Add try_cmpxchg() fallbacks
From: Will Deacon @ 2020-02-20 10:30 UTC (permalink / raw)
To: Peter Zijlstra
Cc: Jens Axboe, Carter Li 李通洲, Pavel Begunkov,
io-uring, Oleg Nesterov, Mark Rutland, linux-kernel
In-Reply-To: <20200218142700.GB14946@hirez.programming.kicks-ass.net>
On Tue, Feb 18, 2020 at 03:27:00PM +0100, Peter Zijlstra wrote:
> On Tue, Feb 18, 2020 at 02:13:10PM +0100, Peter Zijlstra wrote:
> > (with the caveat that try_cmpxchg() doesn't seem available on !x86 -- I
> > should go fix that)
>
> Completely untested (lemme go do that shortly), but something like so I
> suppose.
>
> ---
> Subject: asm-generic/atomic: Add try_cmpxchg() fallbacks
>
> Only x86 provides try_cmpxchg() outside of the atomic_t interfaces,
> provide generic fallbacks to create this interface from the widely
> available cmpxchg() function.
>
> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
> ---
> diff --git a/include/linux/atomic-fallback.h b/include/linux/atomic-fallback.h
> index 656b5489b673..243f61d6c35f 100644
> --- a/include/linux/atomic-fallback.h
> +++ b/include/linux/atomic-fallback.h
> @@ -77,6 +77,50 @@
>
> #endif /* cmpxchg64_relaxed */
>
> +#ifndef try_cmpxchg
> +#define try_cmpxchg(_ptr, _oldp, _new) \
> +({ \
> + typeof(*ptr) ___r, ___o = *(_oldp); \
Probably worth pointing out that this will have the nasty behaviour
for volatile pointers that we're tackling for READ_ONCE. Obviously no
need to hold this up, but just mentioning it here in the hope that one
of us remembers to fix it later on.
> diff --git a/scripts/atomic/gen-atomic-fallback.sh b/scripts/atomic/gen-atomic-fallback.sh
> index b6c6f5d306a7..3c9be8d550e0 100755
> --- a/scripts/atomic/gen-atomic-fallback.sh
> +++ b/scripts/atomic/gen-atomic-fallback.sh
> @@ -140,6 +140,32 @@ cat <<EOF
> EOF
> }
>
> +gen_try_cmpxchg_fallback()
> +{
> + local order="$1"; shift;
> +
> +cat <<EOF
> +#ifndef try_cmpxchg${order}
> +#define try_cmpxchg${order}(_ptr, _oldp, _new) \\
> +({ \\
> + typeof(*ptr) ___r, ___o = *(_oldp); \\
> + ___r = cmpxchg${order}((_ptr), ___o, (_new)); \\
> + if (unlikely(___r != ___o)) \\
> + *(_old) = ___r; \\
This doesn't compile because _old isn't declared. Probably best to avoid
evaluating _oldp twice though.
Will
^ permalink raw reply
* Re: [PATCH 2/3] dt-bindings: leds: Shiji Lighting APA102C LED driver
From: Geert Uytterhoeven @ 2020-02-20 10:30 UTC (permalink / raw)
To: Nicolas Belin
Cc: Linux Kernel Mailing List, linux-leds, Jacek Anaszewski,
Pavel Machek, Dan Murphy,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Lukas Wunner
In-Reply-To: <1582018657-5720-3-git-send-email-nbelin@baylibre.com>
Hi Nicolas,
CC devicetree, Lukas
On Tue, Feb 18, 2020 at 10:39 AM Nicolas Belin <nbelin@baylibre.com> wrote:
> Document Shiji Lighting APA102C LED driver device tree bindings.
>
> Signed-off-by: Nicolas Belin <nbelin@baylibre.com>
> ---
> .../devicetree/bindings/leds/leds-apa102c.yaml | 91 ++++++++++++++++++++++
> 1 file changed, 91 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/leds/leds-apa102c.yaml
>
> diff --git a/Documentation/devicetree/bindings/leds/leds-apa102c.yaml b/Documentation/devicetree/bindings/leds/leds-apa102c.yaml
> new file mode 100644
> index 000000000000..24bc2fc19fcb
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/leds/leds-apa102c.yaml
> @@ -0,0 +1,91 @@
> +# SPDX-License-Identifier: GPL-2.0
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/leds/leds-apa102c.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: LED driver for Shiji Lighting - APA102C
> +
> +maintainers:
> + - Nicolas Belin <nbelin@baylibre.com>
> +
> +description:
> + Each LED is represented as a sub-node of the leds-apa102c device. Each LED
> + is a three color RGB LED with 32 levels brightness adjustment that can be
> + cascaded so that multiple LEDs can be set with a single command.
> +
> +properties:
> + compatible:
> + const: shiji,apa102c
> +
> + reg:
> + maxItems: 1
> +
> + spi-max-frequency:
> + maximum: 1000000
> +
> + "#address-cells":
> + const: 1
> +
> + "#size-cells":
> + const: 0
> +
> +required:
> + - compatible
> + - reg
> + - spi-max-frequency
> + - '#address-cells'
> + - '#size-cells'
> +
> +patternProperties:
> + "^led@[0-9]+$":
> + type: object
> + description: |
> + Properties for an array of connected LEDs.
> +
> + properties:
> + reg:
> + description: |
> + This property corresponds to the led index. It has to be between 0
> + and the number of managed leds minus 1
> + maxItems: 1
> +
> + label:
> + description: |
> + This property corresponds to the name of the led. If not set,
> + the led index will be used to create the led name instead
> + maxItems: 1
> +
> + linux,default-trigger: true
> +
> + required:
> + - reg
> +
> +examples:
> + - |
> + spi {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + led-controller@0 {
> + compatible = "shiji,apa102c";
> + reg = <0>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + spi-max-frequency = <1000000>;
> + led@0 {
> + reg = <0>;
> + label = "led1";
> + };
> +
> + led@1 {
> + reg = <1>;
> + label = "led2";
> + };
> +
> + led@2 {
> + reg = <2>;
> + label = "led3";
> + };
> + };
> + };
Perhaps this should use "#daisy-chained-devices" instead of listing all LEDs
explicitly?
Or would that cause problems w.r.t. LED labeling?
Documentation/devicetree/bindings/common-properties.txt
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
^ permalink raw reply
* [LTP] [PATCH] syscalls/fgetxattr02: Use loop instead of RAM disk
From: Yang Xu @ 2020-02-20 10:31 UTC (permalink / raw)
To: ltp
In-Reply-To: <20200220101811.GA11142@rei>
Hi
> Hi!
>>> which makes this test fail with ENXIO when we attempt to open the block
>>> device in the test setup.
>>>
>>> LTP depends on heavily on loop device driver already so it makes sense
>>> to switch over to a loop device backed block device instead.
>>>
>>> Signed-off-by: Cyril Hrubis <chrubis@suse.cz>
>>> ---
>>> testcases/kernel/syscalls/fgetxattr/fgetxattr02.c | 7 ++++---
>>> 1 file changed, 4 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/testcases/kernel/syscalls/fgetxattr/fgetxattr02.c b/testcases/kernel/syscalls/fgetxattr/fgetxattr02.c
>>> index 02e81810a..82fb676be 100644
>>> --- a/testcases/kernel/syscalls/fgetxattr/fgetxattr02.c
>>> +++ b/testcases/kernel/syscalls/fgetxattr/fgetxattr02.c
>>> @@ -210,7 +210,8 @@ static void setup(void)
>>> size_t i = 0;
>>> struct sockaddr_un sun;
>>>
>>> - dev_t dev = makedev(1, 3);
>>> + dev_t chr_dev = makedev(1, 3);
>>> + dev_t blk_dev = makedev(7, 3);
>> Can we use tst_find_free_loopdev to avoid a fixed loop dev like
>> copy_file_range02.c?
>
> I do not think that it matters here, we are not actually touching the
> block device here, we just need to be able to open the block device so
> that we can add an attribute to the file we have created. I does not
> matter if it's used or not.
Sound reasonable, feel free to add
Reviewed-by: Yang Xu <xuyang2018.jy@cn.fujitsu.com>
>
^ permalink raw reply
* Re: [PATCH] sched/fair: add !se->on_rq check before dequeue entity
From: Vincent Guittot @ 2020-02-20 10:31 UTC (permalink / raw)
To: chenqiwu
Cc: Ingo Molnar, Peter Zijlstra, Juri Lelli, Dietmar Eggemann,
Steven Rostedt, Ben Segall, Mel Gorman, linux-kernel, chenqiwu
In-Reply-To: <20200220100915.GA14721@cqw-OptiPlex-7050>
On Thu, 20 Feb 2020 at 11:09, chenqiwu <qiwuchen55@gmail.com> wrote:
>
> On Thu, Feb 20, 2020 at 10:38:02AM +0100, Vincent Guittot wrote:
> > On Thu, 20 Feb 2020 at 08:29, <qiwuchen55@gmail.com> wrote:
> > >
> > > From: chenqiwu <chenqiwu@xiaomi.com>
> > >
> > > We igonre checking for !se->on_rq condition before dequeue one
> > > entity from cfs rq. It must be required in case the entity has
> > > been dequeued.
> >
> > Do you have a use case that triggers this situation ?
> >
> > This is the only way to reach this situation seems to be dequeuing a
> > task on a throttled cfs_rq
> >
> Sorry, I have no use case triggers this situation. It's just found by
> reading code.
> I agree the situation you mentioned above may have a racy with
> dequeue_task_fair() in the following code path:
> __schedule
> pick_next_task_fair
> put_prev_entity
> check_cfs_rq_runtime
> throttle_cfs_rq
> dequeue_entity
>
> So this check is worth to be added for dequeue_task_fair().
In fact the check is already done thanks to the: if (cfs_rq_throttled(cfs_rq))
AFAICT, there is no other way to enqueue a task on a cfs_rq for which
the group entity is not enqueued
^ permalink raw reply
* Re: [PATCH v2 1/2] RDMA/rw: fix error flow during RDMA context initialization
From: Leon Romanovsky @ 2020-02-20 10:31 UTC (permalink / raw)
To: Max Gurtovoy; +Cc: jgg, linux-rdma, israelr, logang
In-Reply-To: <20200220100819.41860-1-maxg@mellanox.com>
On Thu, Feb 20, 2020 at 12:08:18PM +0200, Max Gurtovoy wrote:
> In case the SGL was mapped for P2P DMA operation, we must unmap it using
> pci_p2pdma_unmap_sg.
>
> Fixes: 7f73eac3a713 ("PCI/P2PDMA: Introduce pci_p2pdma_unmap_sg()")
> Signed-off-by: Max Gurtovoy <maxg@mellanox.com>
> ---
> drivers/infiniband/core/rw.c | 32 +++++++++++++++++++++-----------
> 1 file changed, 21 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/infiniband/core/rw.c b/drivers/infiniband/core/rw.c
> index 4fad732f9b3c..69513b484507 100644
> --- a/drivers/infiniband/core/rw.c
> +++ b/drivers/infiniband/core/rw.c
> @@ -273,6 +273,24 @@ static int rdma_rw_init_single_wr(struct rdma_rw_ctx *ctx, struct ib_qp *qp,
> return 1;
> }
>
> +static void rdma_rw_unmap_sg(struct ib_device *dev, struct scatterlist *sg,
> + u32 sg_cnt, enum dma_data_direction dir)
> +{
> + if (is_pci_p2pdma_page(sg_page(sg)))
> + pci_p2pdma_unmap_sg(dev->dma_device, sg, sg_cnt, dir);
> + else
> + ib_dma_unmap_sg(dev, sg, sg_cnt, dir);
> +}
> +
> +static int rdma_rw_map_sg(struct ib_device *dev, struct scatterlist *sg,
> + u32 sg_cnt, enum dma_data_direction dir)
> +{
> + if (is_pci_p2pdma_page(sg_page(sg)))
> + return pci_p2pdma_map_sg(dev->dma_device, sg, sg_cnt, dir);
> + else
This "else" is not needed.
> + return ib_dma_map_sg(dev, sg, sg_cnt, dir);
> +}> +
> /**
Thanks,
Reviewed-by: Leon Romanovsky <leonro@mellanox.com>
^ permalink raw reply
* Re: [CFT 4/8] net: axienet: use resolved link config in mac_link_up()
From: Russell King - ARM Linux admin @ 2020-02-20 10:29 UTC (permalink / raw)
To: Andre Przywara
Cc: Andrew Lunn, Florian Fainelli, netdev, Radhey Shyam Pandey,
Michal Simek, David S. Miller, linux-arm-kernel, Heiner Kallweit
In-Reply-To: <E1j3k7t-00072J-RS@rmk-PC.armlinux.org.uk>
Hi Andre,
Are you able to give this (along with patch 1) some testing please?
The series can be grabbed from:
https://patchwork.ozlabs.org/series/159037/mbox/
Strangely, google doesn't find it in the lore.kernel.org archives,
but does in spinics.net archives and patchwork...
On Mon, Feb 17, 2020 at 05:24:09PM +0000, Russell King wrote:
> Convert the Xilinx AXI ethernet driver to use the finalised link
> parameters in mac_link_up() rather than the parameters in mac_config().
>
> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
> ---
> .../net/ethernet/xilinx/xilinx_axienet_main.c | 38 +++++++++----------
> 1 file changed, 19 insertions(+), 19 deletions(-)
>
> diff --git a/drivers/net/ethernet/xilinx/xilinx_axienet_main.c b/drivers/net/ethernet/xilinx/xilinx_axienet_main.c
> index 197740781157..c2f4c5ca2e80 100644
> --- a/drivers/net/ethernet/xilinx/xilinx_axienet_main.c
> +++ b/drivers/net/ethernet/xilinx/xilinx_axienet_main.c
> @@ -1440,6 +1440,22 @@ static void axienet_mac_an_restart(struct phylink_config *config)
>
> static void axienet_mac_config(struct phylink_config *config, unsigned int mode,
> const struct phylink_link_state *state)
> +{
> + /* nothing meaningful to do */
> +}
> +
> +static void axienet_mac_link_down(struct phylink_config *config,
> + unsigned int mode,
> + phy_interface_t interface)
> +{
> + /* nothing meaningful to do */
> +}
> +
> +static void axienet_mac_link_up(struct phylink_config *config,
> + struct phy_device *phy,
> + unsigned int mode, phy_interface_t interface,
> + int speed, int duplex,
> + bool tx_pause, bool rx_pause)
> {
> struct net_device *ndev = to_net_dev(config->dev);
> struct axienet_local *lp = netdev_priv(ndev);
> @@ -1448,7 +1464,7 @@ static void axienet_mac_config(struct phylink_config *config, unsigned int mode,
> emmc_reg = axienet_ior(lp, XAE_EMMC_OFFSET);
> emmc_reg &= ~XAE_EMMC_LINKSPEED_MASK;
>
> - switch (state->speed) {
> + switch (speed) {
> case SPEED_1000:
> emmc_reg |= XAE_EMMC_LINKSPD_1000;
> break;
> @@ -1467,33 +1483,17 @@ static void axienet_mac_config(struct phylink_config *config, unsigned int mode,
> axienet_iow(lp, XAE_EMMC_OFFSET, emmc_reg);
>
> fcc_reg = axienet_ior(lp, XAE_FCC_OFFSET);
> - if (state->pause & MLO_PAUSE_TX)
> + if (tx_pause)
> fcc_reg |= XAE_FCC_FCTX_MASK;
> else
> fcc_reg &= ~XAE_FCC_FCTX_MASK;
> - if (state->pause & MLO_PAUSE_RX)
> + if (rx_pause)
> fcc_reg |= XAE_FCC_FCRX_MASK;
> else
> fcc_reg &= ~XAE_FCC_FCRX_MASK;
> axienet_iow(lp, XAE_FCC_OFFSET, fcc_reg);
> }
>
> -static void axienet_mac_link_down(struct phylink_config *config,
> - unsigned int mode,
> - phy_interface_t interface)
> -{
> - /* nothing meaningful to do */
> -}
> -
> -static void axienet_mac_link_up(struct phylink_config *config,
> - struct phy_device *phy,
> - unsigned int mode, phy_interface_t interface,
> - int speed, int duplex,
> - bool tx_pause, bool rx_pause)
> -{
> - /* nothing meaningful to do */
> -}
> -
> static const struct phylink_mac_ops axienet_phylink_ops = {
> .validate = axienet_validate,
> .mac_pcs_get_state = axienet_mac_pcs_get_state,
> --
> 2.20.1
>
>
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: Yocto Project Status WW07'20
From: Richard Purdie @ 2020-02-20 10:33 UTC (permalink / raw)
To: Jain, Sangeeta, sjolley.yp.pm@gmail.com, yocto@yoctoproject.org,
openembedded-core@lists.openembedded.org
In-Reply-To: <CY4PR11MB18792EA8DAE6F08AD3CED448E3130@CY4PR11MB1879.namprd11.prod.outlook.com>
On Thu, 2020-02-20 at 07:46 +0000, Jain, Sangeeta wrote:
> Planned upcoming dot releases:
> YP 2.7.3 built and in QA
>
> I didn’t see any notification for this build. Am I missing something?
No, its due to be built but isn't built yet!
I think that was meant to say 3.0.2, sorry about any confusion.
Cheers,
Richard
^ permalink raw reply
* Re: [OE-core] Yocto Project Status WW07'20
From: Richard Purdie @ 2020-02-20 10:33 UTC (permalink / raw)
To: Jain, Sangeeta, sjolley.yp.pm@gmail.com, yocto@yoctoproject.org,
openembedded-core@lists.openembedded.org
In-Reply-To: <CY4PR11MB18792EA8DAE6F08AD3CED448E3130@CY4PR11MB1879.namprd11.prod.outlook.com>
On Thu, 2020-02-20 at 07:46 +0000, Jain, Sangeeta wrote:
> Planned upcoming dot releases:
> YP 2.7.3 built and in QA
>
> I didn’t see any notification for this build. Am I missing something?
No, its due to be built but isn't built yet!
I think that was meant to say 3.0.2, sorry about any confusion.
Cheers,
Richard
^ permalink raw reply
* Re: Hard Disk consumes lots of power in s2idle
From: Rafael J. Wysocki @ 2020-02-20 10:34 UTC (permalink / raw)
To: Kai-Heng Feng
Cc: Rafael J. Wysocki, Srinivas Pandruvada, Linux PM,
open list:LIBATA SUBSYSTEM (Serial and Parallel ATA drivers),
open list, Kent Lin, Tejun Heo
In-Reply-To: <CA007B3C-C084-429E-B774-70264A9E609F@canonical.com>
On Thu, Feb 20, 2020 at 11:25 AM Kai-Heng Feng
<kai.heng.feng@canonical.com> wrote:
>
>
>
> > On Feb 20, 2020, at 18:12, Rafael J. Wysocki <rafael@kernel.org> wrote:
> >
> > On Thu, Feb 20, 2020 at 9:08 AM Kai-Heng Feng
> > <kai.heng.feng@canonical.com> wrote:
> >>
> >> Hi Srinivas,
> >>
> >>> On Feb 20, 2020, at 02:36, Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> wrote:
> >>>
> >>> Hi Kai,
> >>>
> >>> On Wed, 2020-02-19 at 22:22 +0800, Kai-Heng Feng wrote:
> >>>> Hi Srinivas,
> >>>>
> >>>> Your previous work to support DEVSLP works well on SATA SSDs, so I am
> >>>> asking you the issue I am facing:
> >>>> Once a laptop has a HDD installed, the power consumption during
> >>>> S2Idle increases ~0.4W, which is quite a lot.
> >>>> However, HDDs don't seem to support DEVSLP, so I wonder if you know
> >>>> to do proper power management for HDDs?
> >>> What is the default here
> >>> cat /sys/power/mem_sleep
> >>> s2idle or deep?
> >>
> >> It defaults to s2idle.
> >>
> >>>
> >>> Please follow debug steps here:
> >>> https://01.org/blogs/qwang59/2018/how-achieve-s0ix-states-linux
> >>>
> >>> We need to check whether you get any PC10 residency or not.
> >>
> >> Yes it reaches PC10. It doesn't reach SLP_S0 though.
> >> The real number on S2Idle power consumption:
> >> No HDD: ~1.4W
> >> One HDD: ~1.8W
> >>
> >> If the SoC doesn't hit PC10 the number should be significantly higher.
> >> That's why I think the issue is the power management on HDD itself.
> >
> > I'm assuming that you mean a non-SSD device here.
>
> Yes, it's spinning rust here.
>
> >
> > That would be handled via ata_port_suspend() I gather and whatever
> > that does should do the right thing.
> >
> > Do you think that the disk doesn't spin down or it spins down, but the
> > logic stays on?
>
> The spin sound is audible, so I am certain the HDD spins down during S2Idle.
OK
> How do I know if the logic is on or off?
Well, if it were off, it would not draw power. :-)
So IMO it is reasonable to assume that the logic on the drive stays
on. I'm not aware of anything that can be done to turn it off,
however.
^ 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.