Re: [Xen-devel] [PATCH 3/8] drm/xen-front: fix 32-bit build warning
Hi,
On 05/25/2018 06:50 PM, Arnd Bergmann wrote:
In 32-bit kernel builds, we cannot cast between a pointer and a 64-bit
type:
In file included from drivers/gpu/drm/xen/xen_drm_front_cfg.c:18:
drivers/gpu/drm/xen/xen_drm_front.h: In function 'xen_drm_front_fb_to_cookie':
drivers/gpu/drm/xen/xen_drm_front.h:129:9: error: cast from pointer to integer
of different size [-Werror=pointer-to-int-cast]
return (u64)fb;
drivers/gpu/drm/xen/xen_drm_front.h: In function 'xen_drm_front_dbuf_to_cookie':
drivers/gpu/drm/xen/xen_drm_front.h:134:9: error: cast from pointer to integer
of different size [-Werror=pointer-to-int-cast]
return (u64)gem_obj;
drivers/gpu/drm/xen/xen_drm_front_shbuf.c: In function 'backend_unmap':
drivers/gpu/drm/xen/xen_drm_front_shbuf.c:125:4: error: cast from pointer to
integer of different size [-Werror=pointer-to-int-cast]
((phys_addr_t)pfn_to_kaddr(page_to_xen_pfn(page)))
Using uintptr_t instead probably does what we want here, although it's
not clear to me why we assign a virtual address pointer to a phys_addr_t
in backend_unmap().
Fixes: c575b7eeb89f ("drm/xen-front: Add support for Xen PV display frontend")
Signed-off-by: Arnd Bergmann
---
drivers/gpu/drm/xen/xen_drm_front.h | 4 ++--
drivers/gpu/drm/xen/xen_drm_front_shbuf.c | 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/xen/xen_drm_front.h
b/drivers/gpu/drm/xen/xen_drm_front.h
index 2c2479b571ae..5693b4a4b02b 100644
--- a/drivers/gpu/drm/xen/xen_drm_front.h
+++ b/drivers/gpu/drm/xen/xen_drm_front.h
@@ -126,12 +126,12 @@ struct xen_drm_front_drm_info {
static inline u64 xen_drm_front_fb_to_cookie(struct drm_framebuffer *fb)
{
- return (u64)fb;
+ return (uintptr_t)fb;
}
static inline u64 xen_drm_front_dbuf_to_cookie(struct drm_gem_object *gem_obj)
{
- return (u64)gem_obj;
+ return (uintptr_t)gem_obj;
}
int xen_drm_front_mode_set(struct xen_drm_front_drm_pipeline *pipeline,
diff --git a/drivers/gpu/drm/xen/xen_drm_front_shbuf.c
b/drivers/gpu/drm/xen/xen_drm_front_shbuf.c
index 8099cb343ae3..d333b67cc1a0 100644
--- a/drivers/gpu/drm/xen/xen_drm_front_shbuf.c
+++ b/drivers/gpu/drm/xen/xen_drm_front_shbuf.c
@@ -122,7 +122,7 @@ static void guest_calc_num_grefs(struct xen_drm_front_shbuf
*buf)
}
#define xen_page_to_vaddr(page) \
- ((phys_addr_t)pfn_to_kaddr(page_to_xen_pfn(page)))
+ ((uintptr_t)pfn_to_kaddr(page_to_xen_pfn(page)))
static int backend_unmap(struct xen_drm_front_shbuf *buf)
{
Thank you for your patch: this issue was already discussed [1] and
applied [2] to
drm-misc-next.
Thank you,
Oleksandr
[1] https://patchwork.freedesktop.org/patch/224359/
[2] https://patchwork.freedesktop.org/patch/224920/
Re: [Xen-devel] [PATCH 3/8] drm/xen-front: fix 32-bit build warning
Hi,
On 05/25/2018 06:50 PM, Arnd Bergmann wrote:
In 32-bit kernel builds, we cannot cast between a pointer and a 64-bit
type:
In file included from drivers/gpu/drm/xen/xen_drm_front_cfg.c:18:
drivers/gpu/drm/xen/xen_drm_front.h: In function 'xen_drm_front_fb_to_cookie':
drivers/gpu/drm/xen/xen_drm_front.h:129:9: error: cast from pointer to integer
of different size [-Werror=pointer-to-int-cast]
return (u64)fb;
drivers/gpu/drm/xen/xen_drm_front.h: In function 'xen_drm_front_dbuf_to_cookie':
drivers/gpu/drm/xen/xen_drm_front.h:134:9: error: cast from pointer to integer
of different size [-Werror=pointer-to-int-cast]
return (u64)gem_obj;
drivers/gpu/drm/xen/xen_drm_front_shbuf.c: In function 'backend_unmap':
drivers/gpu/drm/xen/xen_drm_front_shbuf.c:125:4: error: cast from pointer to
integer of different size [-Werror=pointer-to-int-cast]
((phys_addr_t)pfn_to_kaddr(page_to_xen_pfn(page)))
Using uintptr_t instead probably does what we want here, although it's
not clear to me why we assign a virtual address pointer to a phys_addr_t
in backend_unmap().
Fixes: c575b7eeb89f ("drm/xen-front: Add support for Xen PV display frontend")
Signed-off-by: Arnd Bergmann
---
drivers/gpu/drm/xen/xen_drm_front.h | 4 ++--
drivers/gpu/drm/xen/xen_drm_front_shbuf.c | 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/xen/xen_drm_front.h
b/drivers/gpu/drm/xen/xen_drm_front.h
index 2c2479b571ae..5693b4a4b02b 100644
--- a/drivers/gpu/drm/xen/xen_drm_front.h
+++ b/drivers/gpu/drm/xen/xen_drm_front.h
@@ -126,12 +126,12 @@ struct xen_drm_front_drm_info {
static inline u64 xen_drm_front_fb_to_cookie(struct drm_framebuffer *fb)
{
- return (u64)fb;
+ return (uintptr_t)fb;
}
static inline u64 xen_drm_front_dbuf_to_cookie(struct drm_gem_object *gem_obj)
{
- return (u64)gem_obj;
+ return (uintptr_t)gem_obj;
}
int xen_drm_front_mode_set(struct xen_drm_front_drm_pipeline *pipeline,
diff --git a/drivers/gpu/drm/xen/xen_drm_front_shbuf.c
b/drivers/gpu/drm/xen/xen_drm_front_shbuf.c
index 8099cb343ae3..d333b67cc1a0 100644
--- a/drivers/gpu/drm/xen/xen_drm_front_shbuf.c
+++ b/drivers/gpu/drm/xen/xen_drm_front_shbuf.c
@@ -122,7 +122,7 @@ static void guest_calc_num_grefs(struct xen_drm_front_shbuf
*buf)
}
#define xen_page_to_vaddr(page) \
- ((phys_addr_t)pfn_to_kaddr(page_to_xen_pfn(page)))
+ ((uintptr_t)pfn_to_kaddr(page_to_xen_pfn(page)))
static int backend_unmap(struct xen_drm_front_shbuf *buf)
{
Thank you for your patch: this issue was already discussed [1] and
applied [2] to
drm-misc-next.
Thank you,
Oleksandr
[1] https://patchwork.freedesktop.org/patch/224359/
[2] https://patchwork.freedesktop.org/patch/224920/
[PATCH] kdb: prefer strlcpy to strncpy
Fixes stringop-truncation and stringop-overflow warnings from gcc-8.
Signed-off-by: Nick Desaulniers
---
kernel/debug/kdb/kdb_io.c | 2 +-
kernel/debug/kdb/kdb_main.c| 4 ++--
kernel/debug/kdb/kdb_support.c | 2 +-
3 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/kernel/debug/kdb/kdb_io.c b/kernel/debug/kdb/kdb_io.c
index ed5d349..b5dfff1 100644
--- a/kernel/debug/kdb/kdb_io.c
+++ b/kernel/debug/kdb/kdb_io.c
@@ -443,7 +443,7 @@ static char *kdb_read(char *buffer, size_t bufsize)
char *kdb_getstr(char *buffer, size_t bufsize, const char *prompt)
{
if (prompt && kdb_prompt_str != prompt)
- strncpy(kdb_prompt_str, prompt, CMD_BUFLEN);
+ strlcpy(kdb_prompt_str, prompt, CMD_BUFLEN);
kdb_printf(kdb_prompt_str);
kdb_nextline = 1; /* Prompt and input resets line number */
return kdb_read(buffer, bufsize);
diff --git a/kernel/debug/kdb/kdb_main.c b/kernel/debug/kdb/kdb_main.c
index e405677..c30a0d8 100644
--- a/kernel/debug/kdb/kdb_main.c
+++ b/kernel/debug/kdb/kdb_main.c
@@ -1103,12 +1103,12 @@ static int handle_ctrl_cmd(char *cmd)
case CTRL_P:
if (cmdptr != cmd_tail)
cmdptr = (cmdptr-1) % KDB_CMD_HISTORY_COUNT;
- strncpy(cmd_cur, cmd_hist[cmdptr], CMD_BUFLEN);
+ strlcpy(cmd_cur, cmd_hist[cmdptr], CMD_BUFLEN);
return 1;
case CTRL_N:
if (cmdptr != cmd_head)
cmdptr = (cmdptr+1) % KDB_CMD_HISTORY_COUNT;
- strncpy(cmd_cur, cmd_hist[cmdptr], CMD_BUFLEN);
+ strlcpy(cmd_cur, cmd_hist[cmdptr], CMD_BUFLEN);
return 1;
}
return 0;
diff --git a/kernel/debug/kdb/kdb_support.c b/kernel/debug/kdb/kdb_support.c
index 990b3cc..dcfbf8f 100644
--- a/kernel/debug/kdb/kdb_support.c
+++ b/kernel/debug/kdb/kdb_support.c
@@ -236,7 +236,7 @@ int kallsyms_symbol_next(char *prefix_name, int flag)
while ((name = kdb_walk_kallsyms())) {
if (strncmp(name, prefix_name, prefix_len) == 0) {
- strncpy(prefix_name, name, strlen(name)+1);
+ strlcpy(prefix_name, name, prefix_len);
return 1;
}
}
--
2.7.4
[PATCH] kdb: prefer strlcpy to strncpy
Fixes stringop-truncation and stringop-overflow warnings from gcc-8.
Signed-off-by: Nick Desaulniers
---
kernel/debug/kdb/kdb_io.c | 2 +-
kernel/debug/kdb/kdb_main.c| 4 ++--
kernel/debug/kdb/kdb_support.c | 2 +-
3 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/kernel/debug/kdb/kdb_io.c b/kernel/debug/kdb/kdb_io.c
index ed5d349..b5dfff1 100644
--- a/kernel/debug/kdb/kdb_io.c
+++ b/kernel/debug/kdb/kdb_io.c
@@ -443,7 +443,7 @@ static char *kdb_read(char *buffer, size_t bufsize)
char *kdb_getstr(char *buffer, size_t bufsize, const char *prompt)
{
if (prompt && kdb_prompt_str != prompt)
- strncpy(kdb_prompt_str, prompt, CMD_BUFLEN);
+ strlcpy(kdb_prompt_str, prompt, CMD_BUFLEN);
kdb_printf(kdb_prompt_str);
kdb_nextline = 1; /* Prompt and input resets line number */
return kdb_read(buffer, bufsize);
diff --git a/kernel/debug/kdb/kdb_main.c b/kernel/debug/kdb/kdb_main.c
index e405677..c30a0d8 100644
--- a/kernel/debug/kdb/kdb_main.c
+++ b/kernel/debug/kdb/kdb_main.c
@@ -1103,12 +1103,12 @@ static int handle_ctrl_cmd(char *cmd)
case CTRL_P:
if (cmdptr != cmd_tail)
cmdptr = (cmdptr-1) % KDB_CMD_HISTORY_COUNT;
- strncpy(cmd_cur, cmd_hist[cmdptr], CMD_BUFLEN);
+ strlcpy(cmd_cur, cmd_hist[cmdptr], CMD_BUFLEN);
return 1;
case CTRL_N:
if (cmdptr != cmd_head)
cmdptr = (cmdptr+1) % KDB_CMD_HISTORY_COUNT;
- strncpy(cmd_cur, cmd_hist[cmdptr], CMD_BUFLEN);
+ strlcpy(cmd_cur, cmd_hist[cmdptr], CMD_BUFLEN);
return 1;
}
return 0;
diff --git a/kernel/debug/kdb/kdb_support.c b/kernel/debug/kdb/kdb_support.c
index 990b3cc..dcfbf8f 100644
--- a/kernel/debug/kdb/kdb_support.c
+++ b/kernel/debug/kdb/kdb_support.c
@@ -236,7 +236,7 @@ int kallsyms_symbol_next(char *prefix_name, int flag)
while ((name = kdb_walk_kallsyms())) {
if (strncmp(name, prefix_name, prefix_len) == 0) {
- strncpy(prefix_name, name, strlen(name)+1);
+ strlcpy(prefix_name, name, prefix_len);
return 1;
}
}
--
2.7.4
Re: [PATCH] platform: chrome: Add input dependency for tablet switch driver
Hi Arnd,
On Mon, May 28, 2018 at 05:58:46PM +0200, Arnd Bergmann wrote:
> Without CONFIG_INPUT, or with a modular input layer and built-in
> tablet driver, we get a link error:
>
> ERROR: "input_event" [drivers/platform/chrome/chromeos_tbmc.ko] undefined!
> ERROR: "input_register_device" [drivers/platform/chrome/chromeos_tbmc.ko]
> undefined!
> ERROR: "input_set_capability" [drivers/platform/chrome/chromeos_tbmc.ko]
> undefined!
> ERROR: "devm_input_allocate_device"
> [drivers/platform/chrome/chromeos_tbmc.ko] undefined!
>
> This adds the corresponding Kconfig dependency
>
> Fixes: b418f74170d7 ("platform: chrome: Add Tablet Switch ACPI driver")
> Signed-off-by: Arnd Bergmann
Thanks for the catch! Applied for 4.18.
Benson
--
Benson Leung
Staff Software Engineer
Chrome OS Kernel
Google Inc.
ble...@google.com
Chromium OS Project
ble...@chromium.org
signature.asc
Description: PGP signature
Re: [PATCH] platform: chrome: Add input dependency for tablet switch driver
Hi Arnd,
On Mon, May 28, 2018 at 05:58:46PM +0200, Arnd Bergmann wrote:
> Without CONFIG_INPUT, or with a modular input layer and built-in
> tablet driver, we get a link error:
>
> ERROR: "input_event" [drivers/platform/chrome/chromeos_tbmc.ko] undefined!
> ERROR: "input_register_device" [drivers/platform/chrome/chromeos_tbmc.ko]
> undefined!
> ERROR: "input_set_capability" [drivers/platform/chrome/chromeos_tbmc.ko]
> undefined!
> ERROR: "devm_input_allocate_device"
> [drivers/platform/chrome/chromeos_tbmc.ko] undefined!
>
> This adds the corresponding Kconfig dependency
>
> Fixes: b418f74170d7 ("platform: chrome: Add Tablet Switch ACPI driver")
> Signed-off-by: Arnd Bergmann
Thanks for the catch! Applied for 4.18.
Benson
--
Benson Leung
Staff Software Engineer
Chrome OS Kernel
Google Inc.
ble...@google.com
Chromium OS Project
ble...@chromium.org
signature.asc
Description: PGP signature
linux-next: manual merge of the irqchip tree with the arm-soc tree
Hi all,
Today's linux-next merge of the irqchip tree got a conflict in:
arch/arm/boot/dts/stm32mp157c.dtsi
between commit:
3c00436fdb20 ("ARM: dts: stm32: add USBPHYC support to stm32mp157c")
from the arm-soc tree and commit:
5f0e9d2557d7 ("ARM: dts: stm32: Add exti support for stm32mp157c")
from the irqchip tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc arch/arm/boot/dts/stm32mp157c.dtsi
index b66f673b5038,4fa0df853c8a..
--- a/arch/arm/boot/dts/stm32mp157c.dtsi
+++ b/arch/arm/boot/dts/stm32mp157c.dtsi
@@@ -777,26 -183,13 +777,33 @@@
status = "disabled";
};
+ usbphyc: usbphyc@5a006000 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "st,stm32mp1-usbphyc";
+ reg = <0x5a006000 0x1000>;
+ clocks = < USBPHY_K>;
+ resets = < USBPHY_R>;
+ status = "disabled";
+
+ usbphyc_port0: usb-phy@0 {
+ #phy-cells = <0>;
+ reg = <0>;
+ };
+
+ usbphyc_port1: usb-phy@1 {
+ #phy-cells = <1>;
+ reg = <1>;
+ };
+ };
+
+ exti: interrupt-controller@5000d000 {
+ compatible = "st,stm32mp1-exti", "syscon";
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ reg = <0x5000d000 0x400>;
+ };
+
usart1: serial@5c00 {
compatible = "st,stm32h7-uart";
reg = <0x5c00 0x400>;
pgpwFKklK9QPx.pgp
Description: OpenPGP digital signature
linux-next: manual merge of the irqchip tree with the arm-soc tree
Hi all,
Today's linux-next merge of the irqchip tree got a conflict in:
arch/arm/boot/dts/stm32mp157c.dtsi
between commit:
3c00436fdb20 ("ARM: dts: stm32: add USBPHYC support to stm32mp157c")
from the arm-soc tree and commit:
5f0e9d2557d7 ("ARM: dts: stm32: Add exti support for stm32mp157c")
from the irqchip tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc arch/arm/boot/dts/stm32mp157c.dtsi
index b66f673b5038,4fa0df853c8a..
--- a/arch/arm/boot/dts/stm32mp157c.dtsi
+++ b/arch/arm/boot/dts/stm32mp157c.dtsi
@@@ -777,26 -183,13 +777,33 @@@
status = "disabled";
};
+ usbphyc: usbphyc@5a006000 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "st,stm32mp1-usbphyc";
+ reg = <0x5a006000 0x1000>;
+ clocks = < USBPHY_K>;
+ resets = < USBPHY_R>;
+ status = "disabled";
+
+ usbphyc_port0: usb-phy@0 {
+ #phy-cells = <0>;
+ reg = <0>;
+ };
+
+ usbphyc_port1: usb-phy@1 {
+ #phy-cells = <1>;
+ reg = <1>;
+ };
+ };
+
+ exti: interrupt-controller@5000d000 {
+ compatible = "st,stm32mp1-exti", "syscon";
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ reg = <0x5000d000 0x400>;
+ };
+
usart1: serial@5c00 {
compatible = "st,stm32h7-uart";
reg = <0x5c00 0x400>;
pgpwFKklK9QPx.pgp
Description: OpenPGP digital signature
Re: [alsa-devel] [PATCH] ALSA: xen: ensure nul-terminated device name
On 05/28/2018 06:59 PM, Arnd Bergmann wrote:
gcc-8 warns that pcm_instance->name is not necessarily terminated correctly
if the input is more than 80 characters long or lacks a termination byte
itself:
In function 'strncpy',
inlined from 'cfg_device' at sound/xen/xen_snd_front_cfg.c:399:3,
inlined from 'xen_snd_front_cfg_card' at
sound/xen/xen_snd_front_cfg.c:509:9:
include/linux/string.h:254:9: error: '__builtin_strncpy' specified bound 80
equals destination size [-Werror=stringop-truncation]
return __builtin_strncpy(p, q, size);
Using strlcpy() instead of strncpy() makes this a bit safer.
Fixes: fd3b36045c2c ("ALSA: xen-front: Read sound driver configuration from Xen
store")
Signed-off-by: Arnd Bergmann
---
sound/xen/xen_snd_front_cfg.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/sound/xen/xen_snd_front_cfg.c b/sound/xen/xen_snd_front_cfg.c
index 38c7e1eefbb9..684b5f1d51ac 100644
--- a/sound/xen/xen_snd_front_cfg.c
+++ b/sound/xen/xen_snd_front_cfg.c
@@ -396,7 +396,7 @@ static int cfg_device(struct xen_snd_front_info *front_info,
str = xenbus_read(XBT_NIL, device_path, XENSND_FIELD_DEVICE_NAME, NULL);
if (!IS_ERR(str)) {
- strncpy(pcm_instance->name, str, sizeof(pcm_instance->name));
+ strlcpy(pcm_instance->name, str, sizeof(pcm_instance->name));
kfree(str);
}
Thank you for your patch,
Reviewed-by: Oleksandr Andrushchenko
Re: [alsa-devel] [PATCH] ALSA: xen: ensure nul-terminated device name
On 05/28/2018 06:59 PM, Arnd Bergmann wrote:
gcc-8 warns that pcm_instance->name is not necessarily terminated correctly
if the input is more than 80 characters long or lacks a termination byte
itself:
In function 'strncpy',
inlined from 'cfg_device' at sound/xen/xen_snd_front_cfg.c:399:3,
inlined from 'xen_snd_front_cfg_card' at
sound/xen/xen_snd_front_cfg.c:509:9:
include/linux/string.h:254:9: error: '__builtin_strncpy' specified bound 80
equals destination size [-Werror=stringop-truncation]
return __builtin_strncpy(p, q, size);
Using strlcpy() instead of strncpy() makes this a bit safer.
Fixes: fd3b36045c2c ("ALSA: xen-front: Read sound driver configuration from Xen
store")
Signed-off-by: Arnd Bergmann
---
sound/xen/xen_snd_front_cfg.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/sound/xen/xen_snd_front_cfg.c b/sound/xen/xen_snd_front_cfg.c
index 38c7e1eefbb9..684b5f1d51ac 100644
--- a/sound/xen/xen_snd_front_cfg.c
+++ b/sound/xen/xen_snd_front_cfg.c
@@ -396,7 +396,7 @@ static int cfg_device(struct xen_snd_front_info *front_info,
str = xenbus_read(XBT_NIL, device_path, XENSND_FIELD_DEVICE_NAME, NULL);
if (!IS_ERR(str)) {
- strncpy(pcm_instance->name, str, sizeof(pcm_instance->name));
+ strlcpy(pcm_instance->name, str, sizeof(pcm_instance->name));
kfree(str);
}
Thank you for your patch,
Reviewed-by: Oleksandr Andrushchenko
[PATCH] crypto: blkcipher: prefer strlcpy to strncpy
Fixes stringop-truncation warnings from gcc-8.
Signed-off-by: Nick Desaulniers
---
crypto/ablkcipher.c | 8
crypto/blkcipher.c | 4 ++--
2 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/crypto/ablkcipher.c b/crypto/ablkcipher.c
index d880a48..e38867f 100644
--- a/crypto/ablkcipher.c
+++ b/crypto/ablkcipher.c
@@ -370,8 +370,8 @@ static int crypto_ablkcipher_report(struct sk_buff *skb,
struct crypto_alg *alg)
{
struct crypto_report_blkcipher rblkcipher;
- strncpy(rblkcipher.type, "ablkcipher", sizeof(rblkcipher.type));
- strncpy(rblkcipher.geniv, alg->cra_ablkcipher.geniv ?: "",
+ strlcpy(rblkcipher.type, "ablkcipher", sizeof(rblkcipher.type));
+ strlcpy(rblkcipher.geniv, alg->cra_ablkcipher.geniv ?: "",
sizeof(rblkcipher.geniv));
rblkcipher.blocksize = alg->cra_blocksize;
@@ -444,8 +444,8 @@ static int crypto_givcipher_report(struct sk_buff *skb,
struct crypto_alg *alg)
{
struct crypto_report_blkcipher rblkcipher;
- strncpy(rblkcipher.type, "givcipher", sizeof(rblkcipher.type));
- strncpy(rblkcipher.geniv, alg->cra_ablkcipher.geniv ?: "",
+ strlcpy(rblkcipher.type, "givcipher", sizeof(rblkcipher.type));
+ strlcpy(rblkcipher.geniv, alg->cra_ablkcipher.geniv ?: "",
sizeof(rblkcipher.geniv));
rblkcipher.blocksize = alg->cra_blocksize;
diff --git a/crypto/blkcipher.c b/crypto/blkcipher.c
index 01c0d4a..ee88e48 100644
--- a/crypto/blkcipher.c
+++ b/crypto/blkcipher.c
@@ -509,8 +509,8 @@ static int crypto_blkcipher_report(struct sk_buff *skb,
struct crypto_alg *alg)
{
struct crypto_report_blkcipher rblkcipher;
- strncpy(rblkcipher.type, "blkcipher", sizeof(rblkcipher.type));
- strncpy(rblkcipher.geniv, alg->cra_blkcipher.geniv ?: "",
+ strlcpy(rblkcipher.type, "blkcipher", sizeof(rblkcipher.type));
+ strlcpy(rblkcipher.geniv, alg->cra_blkcipher.geniv ?: "",
sizeof(rblkcipher.geniv));
rblkcipher.blocksize = alg->cra_blocksize;
--
2.7.4
[PATCH] crypto: blkcipher: prefer strlcpy to strncpy
Fixes stringop-truncation warnings from gcc-8.
Signed-off-by: Nick Desaulniers
---
crypto/ablkcipher.c | 8
crypto/blkcipher.c | 4 ++--
2 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/crypto/ablkcipher.c b/crypto/ablkcipher.c
index d880a48..e38867f 100644
--- a/crypto/ablkcipher.c
+++ b/crypto/ablkcipher.c
@@ -370,8 +370,8 @@ static int crypto_ablkcipher_report(struct sk_buff *skb,
struct crypto_alg *alg)
{
struct crypto_report_blkcipher rblkcipher;
- strncpy(rblkcipher.type, "ablkcipher", sizeof(rblkcipher.type));
- strncpy(rblkcipher.geniv, alg->cra_ablkcipher.geniv ?: "",
+ strlcpy(rblkcipher.type, "ablkcipher", sizeof(rblkcipher.type));
+ strlcpy(rblkcipher.geniv, alg->cra_ablkcipher.geniv ?: "",
sizeof(rblkcipher.geniv));
rblkcipher.blocksize = alg->cra_blocksize;
@@ -444,8 +444,8 @@ static int crypto_givcipher_report(struct sk_buff *skb,
struct crypto_alg *alg)
{
struct crypto_report_blkcipher rblkcipher;
- strncpy(rblkcipher.type, "givcipher", sizeof(rblkcipher.type));
- strncpy(rblkcipher.geniv, alg->cra_ablkcipher.geniv ?: "",
+ strlcpy(rblkcipher.type, "givcipher", sizeof(rblkcipher.type));
+ strlcpy(rblkcipher.geniv, alg->cra_ablkcipher.geniv ?: "",
sizeof(rblkcipher.geniv));
rblkcipher.blocksize = alg->cra_blocksize;
diff --git a/crypto/blkcipher.c b/crypto/blkcipher.c
index 01c0d4a..ee88e48 100644
--- a/crypto/blkcipher.c
+++ b/crypto/blkcipher.c
@@ -509,8 +509,8 @@ static int crypto_blkcipher_report(struct sk_buff *skb,
struct crypto_alg *alg)
{
struct crypto_report_blkcipher rblkcipher;
- strncpy(rblkcipher.type, "blkcipher", sizeof(rblkcipher.type));
- strncpy(rblkcipher.geniv, alg->cra_blkcipher.geniv ?: "",
+ strlcpy(rblkcipher.type, "blkcipher", sizeof(rblkcipher.type));
+ strlcpy(rblkcipher.geniv, alg->cra_blkcipher.geniv ?: "",
sizeof(rblkcipher.geniv));
rblkcipher.blocksize = alg->cra_blocksize;
--
2.7.4
Re: [RFC PATCH] m68k: set dma and coherent masks for Macintosh SONIC based ethernet
On Tue, 29 May 2018, Michael Schmitz wrote: > > > > Since an arch gets to apply limits in the dma ops it implements, why > > would arch code also have to set a limit in the form of default > > platform device masks? Powerpc seems to be the only arch that does > > this. > > One of Christoph's recent patches removed most of arches' dma ops, > replacing them by one generic implementation instead. m68k was one of > the affected arches. I concede his patch series is experimental still > and not in mainline, but may be included at some time. I found some patches here, http://git.infradead.org/users/hch/misc.git/shortlog/refs/heads/generic-dma-noncoherent.2 Looks like m68k_dma_alloc() gets renamed arch_dma_alloc() and the generic ops don't use the dma masks. Maybe I'm looking at the wrong patches? --
Re: [RFC PATCH] m68k: set dma and coherent masks for Macintosh SONIC based ethernet
On Tue, 29 May 2018, Michael Schmitz wrote: > > > > Since an arch gets to apply limits in the dma ops it implements, why > > would arch code also have to set a limit in the form of default > > platform device masks? Powerpc seems to be the only arch that does > > this. > > One of Christoph's recent patches removed most of arches' dma ops, > replacing them by one generic implementation instead. m68k was one of > the affected arches. I concede his patch series is experimental still > and not in mainline, but may be included at some time. I found some patches here, http://git.infradead.org/users/hch/misc.git/shortlog/refs/heads/generic-dma-noncoherent.2 Looks like m68k_dma_alloc() gets renamed arch_dma_alloc() and the generic ops don't use the dma masks. Maybe I'm looking at the wrong patches? --
Re: [PATCH 4.9 000/329] 4.9.104-stable review
On 28 May 2018 at 15:28, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.9.104 release. > There are 329 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 May 30 10:00:51 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.9.104-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.9.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. NOTE: The failed LTP test case "cve-2017-5669" is a waiver here. Summary kernel: 4.9.104-rc1 git repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git git branch: linux-4.9.y git commit: e11d3afa71760bdd9a9687b439d3e28c0b0fd3af git describe: v4.9.103-330-ge11d3afa7176 Test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-4.9-oe/build/v4.9.103-330-ge11d3afa7176 No regressions (compared to build v4.9.103-331-g892592b6a7d3) Ran 11129 total tests in the following environments and test suites. Environments -- - dragonboard-410c - arm64 - hi6220-hikey - arm64 - juno-r2 - arm64 - qemu_arm - qemu_arm64 - qemu_x86_64 - x15 - arm - x86_64 Test Suites --- * boot * kselftest * libhugetlbfs * ltp-cap_bounds-tests * ltp-containers-tests * ltp-cve-tests * ltp-fcntl-locktests-tests * ltp-filecaps-tests * ltp-fs-tests * ltp-fs_bind-tests * ltp-fs_perms_simple-tests * ltp-fsx-tests * ltp-hugetlb-tests * ltp-io-tests * ltp-ipc-tests * ltp-math-tests * ltp-nptl-tests * ltp-pty-tests * ltp-sched-tests * ltp-securebits-tests * ltp-syscalls-tests * ltp-timers-tests * kselftest-vsyscall-mode-native * kselftest-vsyscall-mode-none -- Linaro LKFT https://lkft.linaro.org
Re: [PATCH 4.9 000/329] 4.9.104-stable review
On 28 May 2018 at 15:28, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.9.104 release. > There are 329 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 May 30 10:00:51 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.9.104-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.9.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. NOTE: The failed LTP test case "cve-2017-5669" is a waiver here. Summary kernel: 4.9.104-rc1 git repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git git branch: linux-4.9.y git commit: e11d3afa71760bdd9a9687b439d3e28c0b0fd3af git describe: v4.9.103-330-ge11d3afa7176 Test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-4.9-oe/build/v4.9.103-330-ge11d3afa7176 No regressions (compared to build v4.9.103-331-g892592b6a7d3) Ran 11129 total tests in the following environments and test suites. Environments -- - dragonboard-410c - arm64 - hi6220-hikey - arm64 - juno-r2 - arm64 - qemu_arm - qemu_arm64 - qemu_x86_64 - x15 - arm - x86_64 Test Suites --- * boot * kselftest * libhugetlbfs * ltp-cap_bounds-tests * ltp-containers-tests * ltp-cve-tests * ltp-fcntl-locktests-tests * ltp-filecaps-tests * ltp-fs-tests * ltp-fs_bind-tests * ltp-fs_perms_simple-tests * ltp-fsx-tests * ltp-hugetlb-tests * ltp-io-tests * ltp-ipc-tests * ltp-math-tests * ltp-nptl-tests * ltp-pty-tests * ltp-sched-tests * ltp-securebits-tests * ltp-syscalls-tests * ltp-timers-tests * kselftest-vsyscall-mode-native * kselftest-vsyscall-mode-none -- Linaro LKFT https://lkft.linaro.org
Re: linux-next: build failure after merge of the net-next tree
> [Christoph, I noticed that the comment above datagram_poll in > net/core/datagram.c needs the function name updated] I'll send a fix for that. > > I have added the following merge fix patch for today: This looks correct, thanks!
Re: linux-next: build failure after merge of the net-next tree
> [Christoph, I noticed that the comment above datagram_poll in > net/core/datagram.c needs the function name updated] I'll send a fix for that. > > I have added the following merge fix patch for today: This looks correct, thanks!
Re: [PATCH 4.16 000/272] 4.16.13-stable review
On 28 May 2018 at 15:30, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.16.13 release. > There are 272 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 May 30 10:01:02 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.16.13-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.16.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. NOTE: The failed LTP test case "cve-2017-5669" is a waiver here. Summary kernel: 4.16.13-rc1 git repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git git branch: linux-4.16.y git commit: ca67f014e67013cd3d8312e68d2967332dae8654 git describe: v4.16.12-273-gca67f014e670 Test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-4.16-oe/build/v4.16.12-273-gca67f014e670 No regressions (compared to build v4.16.12-271-g2cb370dedebb) Ran 10312 total tests in the following environments and test suites. Environments -- - dragonboard-410c - arm64 - hi6220-hikey - arm64 - juno-r2 - arm64 - qemu_arm - qemu_arm64 - qemu_x86_64 - x15 - arm - x86_64 Test Suites --- * boot * kselftest * libhugetlbfs * ltp-cap_bounds-tests * ltp-containers-tests * ltp-fcntl-locktests-tests * ltp-fs-tests * ltp-fs_bind-tests * ltp-fs_perms_simple-tests * ltp-fsx-tests * ltp-hugetlb-tests * ltp-io-tests * ltp-ipc-tests * ltp-math-tests * ltp-nptl-tests * ltp-pty-tests * ltp-sched-tests * ltp-securebits-tests * ltp-timers-tests * ltp-cve-tests * ltp-filecaps-tests * ltp-syscalls-tests * kselftest-vsyscall-mode-native * kselftest-vsyscall-mode-none -- Linaro LKFT https://lkft.linaro.org
Re: [PATCH 4.16 000/272] 4.16.13-stable review
On 28 May 2018 at 15:30, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.16.13 release. > There are 272 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 May 30 10:01:02 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.16.13-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.16.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. NOTE: The failed LTP test case "cve-2017-5669" is a waiver here. Summary kernel: 4.16.13-rc1 git repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git git branch: linux-4.16.y git commit: ca67f014e67013cd3d8312e68d2967332dae8654 git describe: v4.16.12-273-gca67f014e670 Test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-4.16-oe/build/v4.16.12-273-gca67f014e670 No regressions (compared to build v4.16.12-271-g2cb370dedebb) Ran 10312 total tests in the following environments and test suites. Environments -- - dragonboard-410c - arm64 - hi6220-hikey - arm64 - juno-r2 - arm64 - qemu_arm - qemu_arm64 - qemu_x86_64 - x15 - arm - x86_64 Test Suites --- * boot * kselftest * libhugetlbfs * ltp-cap_bounds-tests * ltp-containers-tests * ltp-fcntl-locktests-tests * ltp-fs-tests * ltp-fs_bind-tests * ltp-fs_perms_simple-tests * ltp-fsx-tests * ltp-hugetlb-tests * ltp-io-tests * ltp-ipc-tests * ltp-math-tests * ltp-nptl-tests * ltp-pty-tests * ltp-sched-tests * ltp-securebits-tests * ltp-timers-tests * ltp-cve-tests * ltp-filecaps-tests * ltp-syscalls-tests * kselftest-vsyscall-mode-native * kselftest-vsyscall-mode-none -- Linaro LKFT https://lkft.linaro.org
Re: [RFC v5 2/5] virtio_ring: support creating packed ring
On Tue, May 29, 2018 at 10:49:11AM +0800, Jason Wang wrote:
> On 2018年05月22日 16:16, Tiwei Bie wrote:
> > This commit introduces the support for creating packed ring.
> > All split ring specific functions are added _split suffix.
> > Some necessary stubs for packed ring are also added.
> >
> > Signed-off-by: Tiwei Bie
> > ---
> > drivers/virtio/virtio_ring.c | 801 +++
> > include/linux/virtio_ring.h | 8 +-
> > 2 files changed, 546 insertions(+), 263 deletions(-)
> >
> > diff --git a/drivers/virtio/virtio_ring.c b/drivers/virtio/virtio_ring.c
> > index 71458f493cf8..f5ef5f42a7cf 100644
> > --- a/drivers/virtio/virtio_ring.c
> > +++ b/drivers/virtio/virtio_ring.c
> > @@ -61,11 +61,15 @@ struct vring_desc_state {
> > struct vring_desc *indir_desc; /* Indirect descriptor, if any. */
> > };
> > +struct vring_desc_state_packed {
> > + int next; /* The next desc state. */
> > +};
> > +
> > struct vring_virtqueue {
> > struct virtqueue vq;
> > - /* Actual memory layout for this queue */
> > - struct vring vring;
> > + /* Is this a packed ring? */
> > + bool packed;
> > /* Can we use weak barriers? */
> > bool weak_barriers;
> > @@ -87,11 +91,39 @@ struct vring_virtqueue {
> > /* Last used index we've seen. */
> > u16 last_used_idx;
> > - /* Last written value to avail->flags */
> > - u16 avail_flags_shadow;
> > + union {
> > + /* Available for split ring */
> > + struct {
> > + /* Actual memory layout for this queue. */
> > + struct vring vring;
> > - /* Last written value to avail->idx in guest byte order */
> > - u16 avail_idx_shadow;
> > + /* Last written value to avail->flags */
> > + u16 avail_flags_shadow;
> > +
> > + /* Last written value to avail->idx in
> > +* guest byte order. */
> > + u16 avail_idx_shadow;
> > + };
> > +
> > + /* Available for packed ring */
> > + struct {
> > + /* Actual memory layout for this queue. */
> > + struct vring_packed vring_packed;
> > +
> > + /* Driver ring wrap counter. */
> > + u8 avail_wrap_counter;
> > +
> > + /* Device ring wrap counter. */
> > + u8 used_wrap_counter;
>
> How about just use boolean?
I can change it to bool if you want.
>
[...]
> > -static int vring_mapping_error(const struct vring_virtqueue *vq,
> > - dma_addr_t addr)
> > -{
> > - if (!vring_use_dma_api(vq->vq.vdev))
> > - return 0;
> > -
> > - return dma_mapping_error(vring_dma_dev(vq), addr);
> > -}
>
> It looks to me if you keep vring_mapping_error behind
> vring_unmap_one_split(), lots of changes were unncessary.
>
[...]
> > + }
> > + /* That should have freed everything. */
> > + BUG_ON(vq->vq.num_free != vq->vring.num);
> > +
> > + END_USE(vq);
> > + return NULL;
> > +}
>
> I think the those copy-and-paste hunks could be avoided and the diff should
> only contains renaming of the function. If yes, it would be very welcomed
> since it requires to compare the changes verbatim otherwise.
Michael suggested to lay out the code as:
XXX_split
XXX_packed
XXX wrappers
https://lkml.org/lkml/2018/4/13/410
That's why I moved some code.
>
> > +
> > +/*
> > + * The layout for the packed ring is a continuous chunk of memory
> > + * which looks like this.
> > + *
> > + * struct vring_packed {
> > + * // The actual descriptors (16 bytes each)
> > + * struct vring_packed_desc desc[num];
> > + *
> > + * // Padding to the next align boundary.
> > + * char pad[];
> > + *
> > + * // Driver Event Suppression
> > + * struct vring_packed_desc_event driver;
> > + *
> > + * // Device Event Suppression
> > + * struct vring_packed_desc_event device;
> > + * };
> > + */
> > +static inline void vring_init_packed(struct vring_packed *vr, unsigned int
> > num,
> > +void *p, unsigned long align)
> > +{
> > + vr->num = num;
> > + vr->desc = p;
> > + vr->driver = (void *)(((uintptr_t)p + sizeof(struct vring_packed_desc)
> > + * num + align - 1) & ~(align - 1));
>
> If we choose not to go uapi, maybe we can use ALIGN() macro here?
Okay.
>
> > + vr->device = vr->driver + 1;
> > +}
[...]
> > +/* Only available for split ring */
> > const struct vring *virtqueue_get_vring(struct virtqueue *vq)
> > {
>
> A possible issue with this is:
>
> After commit d4674240f31f8c4289abba07d64291c6ddce51bc ("KVM: s390:
> virtio-ccw revision 1 SET_VQ"). CCW tries to use
> virtqueue_get_avail()/virtqueue_get_used(). Looks like a bug either here or
> ccw code.
Do we still need to support:
include/linux/virtio.h
/*
* Legacy accessors -- in almost all cases, these are the wrong functions
* to use.
*/
static inline void
Re: [RFC v5 2/5] virtio_ring: support creating packed ring
On Tue, May 29, 2018 at 10:49:11AM +0800, Jason Wang wrote:
> On 2018年05月22日 16:16, Tiwei Bie wrote:
> > This commit introduces the support for creating packed ring.
> > All split ring specific functions are added _split suffix.
> > Some necessary stubs for packed ring are also added.
> >
> > Signed-off-by: Tiwei Bie
> > ---
> > drivers/virtio/virtio_ring.c | 801 +++
> > include/linux/virtio_ring.h | 8 +-
> > 2 files changed, 546 insertions(+), 263 deletions(-)
> >
> > diff --git a/drivers/virtio/virtio_ring.c b/drivers/virtio/virtio_ring.c
> > index 71458f493cf8..f5ef5f42a7cf 100644
> > --- a/drivers/virtio/virtio_ring.c
> > +++ b/drivers/virtio/virtio_ring.c
> > @@ -61,11 +61,15 @@ struct vring_desc_state {
> > struct vring_desc *indir_desc; /* Indirect descriptor, if any. */
> > };
> > +struct vring_desc_state_packed {
> > + int next; /* The next desc state. */
> > +};
> > +
> > struct vring_virtqueue {
> > struct virtqueue vq;
> > - /* Actual memory layout for this queue */
> > - struct vring vring;
> > + /* Is this a packed ring? */
> > + bool packed;
> > /* Can we use weak barriers? */
> > bool weak_barriers;
> > @@ -87,11 +91,39 @@ struct vring_virtqueue {
> > /* Last used index we've seen. */
> > u16 last_used_idx;
> > - /* Last written value to avail->flags */
> > - u16 avail_flags_shadow;
> > + union {
> > + /* Available for split ring */
> > + struct {
> > + /* Actual memory layout for this queue. */
> > + struct vring vring;
> > - /* Last written value to avail->idx in guest byte order */
> > - u16 avail_idx_shadow;
> > + /* Last written value to avail->flags */
> > + u16 avail_flags_shadow;
> > +
> > + /* Last written value to avail->idx in
> > +* guest byte order. */
> > + u16 avail_idx_shadow;
> > + };
> > +
> > + /* Available for packed ring */
> > + struct {
> > + /* Actual memory layout for this queue. */
> > + struct vring_packed vring_packed;
> > +
> > + /* Driver ring wrap counter. */
> > + u8 avail_wrap_counter;
> > +
> > + /* Device ring wrap counter. */
> > + u8 used_wrap_counter;
>
> How about just use boolean?
I can change it to bool if you want.
>
[...]
> > -static int vring_mapping_error(const struct vring_virtqueue *vq,
> > - dma_addr_t addr)
> > -{
> > - if (!vring_use_dma_api(vq->vq.vdev))
> > - return 0;
> > -
> > - return dma_mapping_error(vring_dma_dev(vq), addr);
> > -}
>
> It looks to me if you keep vring_mapping_error behind
> vring_unmap_one_split(), lots of changes were unncessary.
>
[...]
> > + }
> > + /* That should have freed everything. */
> > + BUG_ON(vq->vq.num_free != vq->vring.num);
> > +
> > + END_USE(vq);
> > + return NULL;
> > +}
>
> I think the those copy-and-paste hunks could be avoided and the diff should
> only contains renaming of the function. If yes, it would be very welcomed
> since it requires to compare the changes verbatim otherwise.
Michael suggested to lay out the code as:
XXX_split
XXX_packed
XXX wrappers
https://lkml.org/lkml/2018/4/13/410
That's why I moved some code.
>
> > +
> > +/*
> > + * The layout for the packed ring is a continuous chunk of memory
> > + * which looks like this.
> > + *
> > + * struct vring_packed {
> > + * // The actual descriptors (16 bytes each)
> > + * struct vring_packed_desc desc[num];
> > + *
> > + * // Padding to the next align boundary.
> > + * char pad[];
> > + *
> > + * // Driver Event Suppression
> > + * struct vring_packed_desc_event driver;
> > + *
> > + * // Device Event Suppression
> > + * struct vring_packed_desc_event device;
> > + * };
> > + */
> > +static inline void vring_init_packed(struct vring_packed *vr, unsigned int
> > num,
> > +void *p, unsigned long align)
> > +{
> > + vr->num = num;
> > + vr->desc = p;
> > + vr->driver = (void *)(((uintptr_t)p + sizeof(struct vring_packed_desc)
> > + * num + align - 1) & ~(align - 1));
>
> If we choose not to go uapi, maybe we can use ALIGN() macro here?
Okay.
>
> > + vr->device = vr->driver + 1;
> > +}
[...]
> > +/* Only available for split ring */
> > const struct vring *virtqueue_get_vring(struct virtqueue *vq)
> > {
>
> A possible issue with this is:
>
> After commit d4674240f31f8c4289abba07d64291c6ddce51bc ("KVM: s390:
> virtio-ccw revision 1 SET_VQ"). CCW tries to use
> virtqueue_get_avail()/virtqueue_get_used(). Looks like a bug either here or
> ccw code.
Do we still need to support:
include/linux/virtio.h
/*
* Legacy accessors -- in almost all cases, these are the wrong functions
* to use.
*/
static inline void
Re: Revert "dmaengine: pl330: add DMA_PAUSE feature"
Hi Vinod, On 2018-05-18 09:21, Vinod wrote: > On 18-05-18, 08:28, Marek Szyprowski wrote: >> Hi Vinod, >> >> Okay, I see that in theory, there are some tricky bits in implementing DMA >> support in UART drivers. On the other hand there are already drivers >> with seems >> to be working fine. This discussion is about revert of the feature >> present in >> pl330 driver, which is required by other in-kernel driver without proper >> fix to >> them. >> >> Can we drop it for now and discuss what and how should be implemented to >> make >> everyone happy, without any regressions? > Sure am dropping the revert, we can always bring it back if it is required This revert is still in your -next branch. Do you plan to update it as well? Best regards -- Marek Szyprowski, PhD Samsung R Institute Poland
Re: Revert "dmaengine: pl330: add DMA_PAUSE feature"
Hi Vinod, On 2018-05-18 09:21, Vinod wrote: > On 18-05-18, 08:28, Marek Szyprowski wrote: >> Hi Vinod, >> >> Okay, I see that in theory, there are some tricky bits in implementing DMA >> support in UART drivers. On the other hand there are already drivers >> with seems >> to be working fine. This discussion is about revert of the feature >> present in >> pl330 driver, which is required by other in-kernel driver without proper >> fix to >> them. >> >> Can we drop it for now and discuss what and how should be implemented to >> make >> everyone happy, without any regressions? > Sure am dropping the revert, we can always bring it back if it is required This revert is still in your -next branch. Do you plan to update it as well? Best regards -- Marek Szyprowski, PhD Samsung R Institute Poland
Re: [PATCH v2 1/8] driver core: make deferring probe after init optional
On 05/24/18 11:18, Mark Brown wrote: > On Thu, May 24, 2018 at 12:50:17PM -0500, Rob Herring wrote: > >> Subsystems or drivers may opt-in to this behavior by calling >> driver_deferred_probe_check_init_done() instead of just returning >> -EPROBE_DEFER. They may use additional information from DT or kernel's >> config to decide whether to continue to defer probe or not. > > Should userspace have some involvement in this decision? It knows if > it's got any intention of loading modules for example. Kernel config > checks might be good enough, though it's going to be a pain to work out > if the relevant driver is built as a module for example. > A parallel issue is that loading an overlay could provide the resource that will allow the deferred probe to complete. (That is, once we finish implementing the run time overlays feature.) -Frank
Re: [PATCH v2 1/8] driver core: make deferring probe after init optional
On 05/24/18 11:18, Mark Brown wrote: > On Thu, May 24, 2018 at 12:50:17PM -0500, Rob Herring wrote: > >> Subsystems or drivers may opt-in to this behavior by calling >> driver_deferred_probe_check_init_done() instead of just returning >> -EPROBE_DEFER. They may use additional information from DT or kernel's >> config to decide whether to continue to defer probe or not. > > Should userspace have some involvement in this decision? It knows if > it's got any intention of loading modules for example. Kernel config > checks might be good enough, though it's going to be a pain to work out > if the relevant driver is built as a module for example. > A parallel issue is that loading an overlay could provide the resource that will allow the deferred probe to complete. (That is, once we finish implementing the run time overlays feature.) -Frank
Re: [RFC v5 3/5] virtio_ring: add packed ring support
On Tue, May 29, 2018 at 11:18:57AM +0800, Jason Wang wrote:
> On 2018年05月22日 16:16, Tiwei Bie wrote:
[...]
> > +static void detach_buf_packed(struct vring_virtqueue *vq,
> > + unsigned int id, void **ctx)
> > +{
> > + struct vring_desc_state_packed *state;
> > + struct vring_packed_desc *desc;
> > + unsigned int i;
> > + int *next;
> > +
> > + /* Clear data ptr. */
> > + vq->desc_state_packed[id].data = NULL;
> > +
> > + next =
> > + for (i = 0; i < vq->desc_state_packed[id].num; i++) {
> > + state = >desc_state_packed[*next];
> > + vring_unmap_state_packed(vq, state);
> > + next = >desc_state_packed[*next].next;
>
> Have a short discussion with Michael. It looks like the only thing we care
> is DMA address and length here.
The length tracked by desc_state_packed[] is also necessary
when INDIRECT is used and the buffers are writable.
>
> So a thought is to avoid using desc_state_packed() is vring_use_dma_api() is
> false? Probably need another id allocator or just use desc_state_packed for
> free id list.
I think it's a good suggestion. Thanks!
I won't track the addr/len/flags for non-indirect descs
when vring_use_dma_api() returns false.
>
> > + }
> > +
> > + vq->vq.num_free += vq->desc_state_packed[id].num;
> > + *next = vq->free_head;
>
> Using pointer seems not elegant and unnecessary here. You can just track
> next in integer I think?
It's possible to use integer, but will need one more var
to track `prev` (desc_state_packed[prev].next == next in
this case).
>
> > + vq->free_head = id;
> > +
> > + if (vq->indirect) {
> > + u32 len;
> > +
> > + /* Free the indirect table, if any, now that it's unmapped. */
> > + desc = vq->desc_state_packed[id].indir_desc;
> > + if (!desc)
> > + return;
> > +
> > + len = vq->desc_state_packed[id].len;
> > + for (i = 0; i < len / sizeof(struct vring_packed_desc); i++)
> > + vring_unmap_desc_packed(vq, [i]);
> > +
> > + kfree(desc);
> > + vq->desc_state_packed[id].indir_desc = NULL;
> > + } else if (ctx) {
> > + *ctx = vq->desc_state_packed[id].indir_desc;
> > + }
> > }
> > static inline bool more_used_packed(const struct vring_virtqueue *vq)
> > {
> > - return false;
> > + u16 last_used, flags;
> > + u8 avail, used;
> > +
> > + last_used = vq->last_used_idx;
> > + flags = virtio16_to_cpu(vq->vq.vdev,
> > + vq->vring_packed.desc[last_used].flags);
> > + avail = !!(flags & VRING_DESC_F_AVAIL(1));
> > + used = !!(flags & VRING_DESC_F_USED(1));
> > +
> > + return avail == used && used == vq->used_wrap_counter;
>
> Spec does not check avail == used? So there's probably a bug in either of
> the two places.
>
> In what condition that avail != used but used == vq_used_wrap_counter? A
> buggy device or device set the two bits in two writes?
Currently, spec doesn't forbid devices to set the status
bits as: avail != used but used == vq_used_wrap_counter.
So I think driver cannot assume this won't happen.
>
> > }
[...]
> > static unsigned virtqueue_enable_cb_prepare_packed(struct virtqueue *_vq)
> > {
> > - return 0;
> > + struct vring_virtqueue *vq = to_vvq(_vq);
> > +
> > + START_USE(vq);
> > +
> > + /* We optimistically turn back on interrupts, then check if there was
> > +* more to do. */
> > +
> > + if (vq->event_flags_shadow == VRING_EVENT_F_DISABLE) {
> > + virtio_wmb(vq->weak_barriers);
>
> Missing comments for the barrier.
Will add some comments.
>
> > + vq->event_flags_shadow = VRING_EVENT_F_ENABLE;
> > + vq->vring_packed.driver->flags = cpu_to_virtio16(_vq->vdev,
> > + vq->event_flags_shadow);
> > + }
> > +
> > + END_USE(vq);
> > + return vq->last_used_idx;
> > }
> > static bool virtqueue_poll_packed(struct virtqueue *_vq, unsigned
> > last_used_idx)
> > {
> > - return false;
> > + struct vring_virtqueue *vq = to_vvq(_vq);
> > + u8 avail, used;
> > + u16 flags;
> > +
> > + virtio_mb(vq->weak_barriers);
> > + flags = virtio16_to_cpu(vq->vq.vdev,
> > + vq->vring_packed.desc[last_used_idx].flags);
> > + avail = !!(flags & VRING_DESC_F_AVAIL(1));
> > + used = !!(flags & VRING_DESC_F_USED(1));
> > +
> > + return avail == used && used == vq->used_wrap_counter;
> > }
> > static bool virtqueue_enable_cb_delayed_packed(struct virtqueue *_vq)
> > {
> > - return false;
> > + struct vring_virtqueue *vq = to_vvq(_vq);
> > +
> > + START_USE(vq);
> > +
> > + /* We optimistically turn back on interrupts, then check if there was
> > +* more to do. */
> > +
> > + if (vq->event_flags_shadow == VRING_EVENT_F_DISABLE) {
> > + virtio_wmb(vq->weak_barriers);
>
> Need comments for the barrier.
Will add some comments.
Best regards,
Tiwei Bie
Re: [RFC v5 3/5] virtio_ring: add packed ring support
On Tue, May 29, 2018 at 11:18:57AM +0800, Jason Wang wrote:
> On 2018年05月22日 16:16, Tiwei Bie wrote:
[...]
> > +static void detach_buf_packed(struct vring_virtqueue *vq,
> > + unsigned int id, void **ctx)
> > +{
> > + struct vring_desc_state_packed *state;
> > + struct vring_packed_desc *desc;
> > + unsigned int i;
> > + int *next;
> > +
> > + /* Clear data ptr. */
> > + vq->desc_state_packed[id].data = NULL;
> > +
> > + next =
> > + for (i = 0; i < vq->desc_state_packed[id].num; i++) {
> > + state = >desc_state_packed[*next];
> > + vring_unmap_state_packed(vq, state);
> > + next = >desc_state_packed[*next].next;
>
> Have a short discussion with Michael. It looks like the only thing we care
> is DMA address and length here.
The length tracked by desc_state_packed[] is also necessary
when INDIRECT is used and the buffers are writable.
>
> So a thought is to avoid using desc_state_packed() is vring_use_dma_api() is
> false? Probably need another id allocator or just use desc_state_packed for
> free id list.
I think it's a good suggestion. Thanks!
I won't track the addr/len/flags for non-indirect descs
when vring_use_dma_api() returns false.
>
> > + }
> > +
> > + vq->vq.num_free += vq->desc_state_packed[id].num;
> > + *next = vq->free_head;
>
> Using pointer seems not elegant and unnecessary here. You can just track
> next in integer I think?
It's possible to use integer, but will need one more var
to track `prev` (desc_state_packed[prev].next == next in
this case).
>
> > + vq->free_head = id;
> > +
> > + if (vq->indirect) {
> > + u32 len;
> > +
> > + /* Free the indirect table, if any, now that it's unmapped. */
> > + desc = vq->desc_state_packed[id].indir_desc;
> > + if (!desc)
> > + return;
> > +
> > + len = vq->desc_state_packed[id].len;
> > + for (i = 0; i < len / sizeof(struct vring_packed_desc); i++)
> > + vring_unmap_desc_packed(vq, [i]);
> > +
> > + kfree(desc);
> > + vq->desc_state_packed[id].indir_desc = NULL;
> > + } else if (ctx) {
> > + *ctx = vq->desc_state_packed[id].indir_desc;
> > + }
> > }
> > static inline bool more_used_packed(const struct vring_virtqueue *vq)
> > {
> > - return false;
> > + u16 last_used, flags;
> > + u8 avail, used;
> > +
> > + last_used = vq->last_used_idx;
> > + flags = virtio16_to_cpu(vq->vq.vdev,
> > + vq->vring_packed.desc[last_used].flags);
> > + avail = !!(flags & VRING_DESC_F_AVAIL(1));
> > + used = !!(flags & VRING_DESC_F_USED(1));
> > +
> > + return avail == used && used == vq->used_wrap_counter;
>
> Spec does not check avail == used? So there's probably a bug in either of
> the two places.
>
> In what condition that avail != used but used == vq_used_wrap_counter? A
> buggy device or device set the two bits in two writes?
Currently, spec doesn't forbid devices to set the status
bits as: avail != used but used == vq_used_wrap_counter.
So I think driver cannot assume this won't happen.
>
> > }
[...]
> > static unsigned virtqueue_enable_cb_prepare_packed(struct virtqueue *_vq)
> > {
> > - return 0;
> > + struct vring_virtqueue *vq = to_vvq(_vq);
> > +
> > + START_USE(vq);
> > +
> > + /* We optimistically turn back on interrupts, then check if there was
> > +* more to do. */
> > +
> > + if (vq->event_flags_shadow == VRING_EVENT_F_DISABLE) {
> > + virtio_wmb(vq->weak_barriers);
>
> Missing comments for the barrier.
Will add some comments.
>
> > + vq->event_flags_shadow = VRING_EVENT_F_ENABLE;
> > + vq->vring_packed.driver->flags = cpu_to_virtio16(_vq->vdev,
> > + vq->event_flags_shadow);
> > + }
> > +
> > + END_USE(vq);
> > + return vq->last_used_idx;
> > }
> > static bool virtqueue_poll_packed(struct virtqueue *_vq, unsigned
> > last_used_idx)
> > {
> > - return false;
> > + struct vring_virtqueue *vq = to_vvq(_vq);
> > + u8 avail, used;
> > + u16 flags;
> > +
> > + virtio_mb(vq->weak_barriers);
> > + flags = virtio16_to_cpu(vq->vq.vdev,
> > + vq->vring_packed.desc[last_used_idx].flags);
> > + avail = !!(flags & VRING_DESC_F_AVAIL(1));
> > + used = !!(flags & VRING_DESC_F_USED(1));
> > +
> > + return avail == used && used == vq->used_wrap_counter;
> > }
> > static bool virtqueue_enable_cb_delayed_packed(struct virtqueue *_vq)
> > {
> > - return false;
> > + struct vring_virtqueue *vq = to_vvq(_vq);
> > +
> > + START_USE(vq);
> > +
> > + /* We optimistically turn back on interrupts, then check if there was
> > +* more to do. */
> > +
> > + if (vq->event_flags_shadow == VRING_EVENT_F_DISABLE) {
> > + virtio_wmb(vq->weak_barriers);
>
> Need comments for the barrier.
Will add some comments.
Best regards,
Tiwei Bie
Re: [PATCH v5 05/10] cpufreq/schedutil: get max utilization
On Mon, May 28, 2018 at 12:12:34PM +0200, Juri Lelli wrote: [..] > > + > > + util = max_t(unsigned long, util, READ_ONCE(rq->avg_dl.util_avg)); > > + > > + return util; > > Anyway, just a quick thought. I guess we should experiment with this a > bit. Now, I don't unfortunately have a Arm platform at hand for testing. > Claudio, Luca (now Cc-ed), would you be able to fire some tests with > this change? > > Oh, adding Joel and Alessio as well that experimented with DEADLINE > lately. I also feel that for power reasons, dl.util_avg shouldn't drive the OPP beyond what the running bandwidth is, or atleast do that only if CFS tasks are running and being preempted as you/Vincent mentioned in one of the threads. With our DL experiments, I didn't measure power but got it to a point where the OPP is scaling correctly based on DL parameters. I think Alessio did measure power at his setup but I can't recall now. Alessio? thanks, - Joel
Re: [PATCH v5 05/10] cpufreq/schedutil: get max utilization
On Mon, May 28, 2018 at 12:12:34PM +0200, Juri Lelli wrote: [..] > > + > > + util = max_t(unsigned long, util, READ_ONCE(rq->avg_dl.util_avg)); > > + > > + return util; > > Anyway, just a quick thought. I guess we should experiment with this a > bit. Now, I don't unfortunately have a Arm platform at hand for testing. > Claudio, Luca (now Cc-ed), would you be able to fire some tests with > this change? > > Oh, adding Joel and Alessio as well that experimented with DEADLINE > lately. I also feel that for power reasons, dl.util_avg shouldn't drive the OPP beyond what the running bandwidth is, or atleast do that only if CFS tasks are running and being preempted as you/Vincent mentioned in one of the threads. With our DL experiments, I didn't measure power but got it to a point where the OPP is scaling correctly based on DL parameters. I think Alessio did measure power at his setup but I can't recall now. Alessio? thanks, - Joel
Re: [PATCH v2] remoteproc: Introduce prepare/unprepare ops for rproc coredump
On Mon 21 May 11:45 PDT 2018, Sibi Sankar wrote: > In some occasions the remoteproc device might need to > prepare some hardware before the coredump can be performed > and cleanup the state afterwards. > > Q6V5 modem requires the mba to be loaded before the > coredump and some cleanup of the resources afterwards. > This describes two different changes, so please put it in two+ patches. [..] > diff --git a/include/linux/remoteproc.h b/include/linux/remoteproc.h > index dfdaede9139e..010819e01279 100644 > --- a/include/linux/remoteproc.h > +++ b/include/linux/remoteproc.h > @@ -333,6 +333,8 @@ struct firmware; > * @kick:kick a virtqueue (virtqueue id given as a parameter) > * @da_to_va:optional platform hook to perform address translations > * @load_rsc_table: load resource table from firmware image > + * @prepare_coredump:prepare function, called before coredump > + * @unprepare_coredump: unprepare function, called post coredump I believe there will be other cases where we will need driver-specific logic to extract the memory content of the segments, e.g. through custom hardware sequences or non-mmio reads. To support this I think we should extend the struct rproc_dump_segment to carry an optional "dump" function that if specified will be used instead of the memcpy in rproc_coredump(). Drivers can then for each segment specify this function, if needed. Through some restructuring in the msa driver and your patch you should be able to implement this using such a mechanism instead - and it would be useful to these other cases as well. PS. I hope we can get away from some of the conditionals in your patch through some restructuring of the code. Regards, Bjorn
Re: [PATCH v2] remoteproc: Introduce prepare/unprepare ops for rproc coredump
On Mon 21 May 11:45 PDT 2018, Sibi Sankar wrote: > In some occasions the remoteproc device might need to > prepare some hardware before the coredump can be performed > and cleanup the state afterwards. > > Q6V5 modem requires the mba to be loaded before the > coredump and some cleanup of the resources afterwards. > This describes two different changes, so please put it in two+ patches. [..] > diff --git a/include/linux/remoteproc.h b/include/linux/remoteproc.h > index dfdaede9139e..010819e01279 100644 > --- a/include/linux/remoteproc.h > +++ b/include/linux/remoteproc.h > @@ -333,6 +333,8 @@ struct firmware; > * @kick:kick a virtqueue (virtqueue id given as a parameter) > * @da_to_va:optional platform hook to perform address translations > * @load_rsc_table: load resource table from firmware image > + * @prepare_coredump:prepare function, called before coredump > + * @unprepare_coredump: unprepare function, called post coredump I believe there will be other cases where we will need driver-specific logic to extract the memory content of the segments, e.g. through custom hardware sequences or non-mmio reads. To support this I think we should extend the struct rproc_dump_segment to carry an optional "dump" function that if specified will be used instead of the memcpy in rproc_coredump(). Drivers can then for each segment specify this function, if needed. Through some restructuring in the msa driver and your patch you should be able to implement this using such a mechanism instead - and it would be useful to these other cases as well. PS. I hope we can get away from some of the conditionals in your patch through some restructuring of the code. Regards, Bjorn
[PATCH 1/2] dt-bindings: Add vendor prefix for ArcherMind
Add vendor prefix for ArcherMind Technology (Nanjing) Co., Ltd. Signed-off-by: Manivannan Sadhasivam --- Documentation/devicetree/bindings/vendor-prefixes.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt index a38d8bfae19c..f601acb5a0b4 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.txt +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt @@ -32,6 +32,7 @@ andestech Andes Technology Corporation apmApplied Micro Circuits Corporation (APM) aptina Aptina Imaging arasan Arasan Chip Systems +archermind ArcherMind Technology (Nanjing) Co., Ltd. arctic Arctic Sand aries Aries Embedded GmbH armARM Ltd. -- 2.17.0
Re: [PATCH v3 net-next 2/2] tcp: minor optimization around tcp_hdr() usage in tcp receive path
On 05/28/2018 05:41 PM, Yafang Shao wrote:
> OK.
>
> And what about introducing a new helper tcp_hdr_fast() ?
>
> /* use it when tcp header has not been pulled yet */
> static inline struct tcphdr *tcp_hdr_fast(const struct sk_buff *skb)
>
> {
>
> return (const struct tcphdr *)skb->data;
>
> }
>
>
> That could help us to use this optimized one instead of the original
> one if possilbe.
I would rather not add such macro...
The call site needs to know what is going on, so having a macro like that would
not help.
[PATCH 2/2] arm64: dts: Add Mediatek X20 Development Board support
Add initial device tree support for Mediatek X20 Development Board
based on MT6797 Deca core SoC. This board is one of the 96Boards
Consumer Edition platform.
Signed-off-by: Manivannan Sadhasivam
---
arch/arm64/boot/dts/mediatek/Makefile | 1 +
.../boot/dts/mediatek/mt6797-x20-dev.dts | 33 +++
2 files changed, 34 insertions(+)
create mode 100644 arch/arm64/boot/dts/mediatek/mt6797-x20-dev.dts
diff --git a/arch/arm64/boot/dts/mediatek/Makefile
b/arch/arm64/boot/dts/mediatek/Makefile
index ac17f60f998c..5b7fd6ad96e4 100644
--- a/arch/arm64/boot/dts/mediatek/Makefile
+++ b/arch/arm64/boot/dts/mediatek/Makefile
@@ -3,5 +3,6 @@ dtb-$(CONFIG_ARCH_MEDIATEK) += mt2712-evb.dtb
dtb-$(CONFIG_ARCH_MEDIATEK) += mt6755-evb.dtb
dtb-$(CONFIG_ARCH_MEDIATEK) += mt6795-evb.dtb
dtb-$(CONFIG_ARCH_MEDIATEK) += mt6797-evb.dtb
+dtb-$(CONFIG_ARCH_MEDIATEK) += mt6797-x20-dev.dtb
dtb-$(CONFIG_ARCH_MEDIATEK) += mt7622-rfb1.dtb
dtb-$(CONFIG_ARCH_MEDIATEK) += mt8173-evb.dtb
diff --git a/arch/arm64/boot/dts/mediatek/mt6797-x20-dev.dts
b/arch/arm64/boot/dts/mediatek/mt6797-x20-dev.dts
new file mode 100644
index ..2c09ca95d9e2
--- /dev/null
+++ b/arch/arm64/boot/dts/mediatek/mt6797-x20-dev.dts
@@ -0,0 +1,33 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Device Tree Source for MediaTek X20 Development Board
+ *
+ * Copyright (C) 2018, Linaro Ltd.
+ *
+ */
+
+/dts-v1/;
+
+#include "mt6797.dtsi"
+
+/ {
+ model = "Mediatek X20 Development Board";
+ compatible = "archermind,mt6797-x20-dev", "mediatek,mt6797";
+
+ aliases {
+ serial0 =
+ };
+
+ memory@4000 {
+ device_type = "memory";
+ reg = <0 0x4000 0 0x1e605000>;
+ };
+
+ chosen {
+ stdout-path = "serial0:115200n8";
+ };
+};
+
+ {
+ status = "okay";
+};
--
2.17.0
[PATCH 1/2] dt-bindings: Add vendor prefix for ArcherMind
Add vendor prefix for ArcherMind Technology (Nanjing) Co., Ltd. Signed-off-by: Manivannan Sadhasivam --- Documentation/devicetree/bindings/vendor-prefixes.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt index a38d8bfae19c..f601acb5a0b4 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.txt +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt @@ -32,6 +32,7 @@ andestech Andes Technology Corporation apmApplied Micro Circuits Corporation (APM) aptina Aptina Imaging arasan Arasan Chip Systems +archermind ArcherMind Technology (Nanjing) Co., Ltd. arctic Arctic Sand aries Aries Embedded GmbH armARM Ltd. -- 2.17.0
Re: [PATCH v3 net-next 2/2] tcp: minor optimization around tcp_hdr() usage in tcp receive path
On 05/28/2018 05:41 PM, Yafang Shao wrote:
> OK.
>
> And what about introducing a new helper tcp_hdr_fast() ?
>
> /* use it when tcp header has not been pulled yet */
> static inline struct tcphdr *tcp_hdr_fast(const struct sk_buff *skb)
>
> {
>
> return (const struct tcphdr *)skb->data;
>
> }
>
>
> That could help us to use this optimized one instead of the original
> one if possilbe.
I would rather not add such macro...
The call site needs to know what is going on, so having a macro like that would
not help.
[PATCH 2/2] arm64: dts: Add Mediatek X20 Development Board support
Add initial device tree support for Mediatek X20 Development Board
based on MT6797 Deca core SoC. This board is one of the 96Boards
Consumer Edition platform.
Signed-off-by: Manivannan Sadhasivam
---
arch/arm64/boot/dts/mediatek/Makefile | 1 +
.../boot/dts/mediatek/mt6797-x20-dev.dts | 33 +++
2 files changed, 34 insertions(+)
create mode 100644 arch/arm64/boot/dts/mediatek/mt6797-x20-dev.dts
diff --git a/arch/arm64/boot/dts/mediatek/Makefile
b/arch/arm64/boot/dts/mediatek/Makefile
index ac17f60f998c..5b7fd6ad96e4 100644
--- a/arch/arm64/boot/dts/mediatek/Makefile
+++ b/arch/arm64/boot/dts/mediatek/Makefile
@@ -3,5 +3,6 @@ dtb-$(CONFIG_ARCH_MEDIATEK) += mt2712-evb.dtb
dtb-$(CONFIG_ARCH_MEDIATEK) += mt6755-evb.dtb
dtb-$(CONFIG_ARCH_MEDIATEK) += mt6795-evb.dtb
dtb-$(CONFIG_ARCH_MEDIATEK) += mt6797-evb.dtb
+dtb-$(CONFIG_ARCH_MEDIATEK) += mt6797-x20-dev.dtb
dtb-$(CONFIG_ARCH_MEDIATEK) += mt7622-rfb1.dtb
dtb-$(CONFIG_ARCH_MEDIATEK) += mt8173-evb.dtb
diff --git a/arch/arm64/boot/dts/mediatek/mt6797-x20-dev.dts
b/arch/arm64/boot/dts/mediatek/mt6797-x20-dev.dts
new file mode 100644
index ..2c09ca95d9e2
--- /dev/null
+++ b/arch/arm64/boot/dts/mediatek/mt6797-x20-dev.dts
@@ -0,0 +1,33 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Device Tree Source for MediaTek X20 Development Board
+ *
+ * Copyright (C) 2018, Linaro Ltd.
+ *
+ */
+
+/dts-v1/;
+
+#include "mt6797.dtsi"
+
+/ {
+ model = "Mediatek X20 Development Board";
+ compatible = "archermind,mt6797-x20-dev", "mediatek,mt6797";
+
+ aliases {
+ serial0 =
+ };
+
+ memory@4000 {
+ device_type = "memory";
+ reg = <0 0x4000 0 0x1e605000>;
+ };
+
+ chosen {
+ stdout-path = "serial0:115200n8";
+ };
+};
+
+ {
+ status = "okay";
+};
--
2.17.0
[PATCH 0/2] Add Mediatek X20 Development Board support
Add devicetree support for Mediatek X20 Development Board by Archermind. This board is based on the Deca-Core MT6797 SoC from Mediatek and is one of the 96Boards Consumer Edition platform. With this devicetree change, board can boot into initramfs. More information about this board can be found in 96Boards product page: https://www.96boards.org/product/mediatek-x20/ Manivannan Sadhasivam (2): dt-bindings: Add vendor prefix for ArcherMind arm64: dts: Add Mediatek X20 Development Board support .../devicetree/bindings/vendor-prefixes.txt | 1 + arch/arm64/boot/dts/mediatek/Makefile | 1 + .../boot/dts/mediatek/mt6797-x20-dev.dts | 33 +++ 3 files changed, 35 insertions(+) create mode 100644 arch/arm64/boot/dts/mediatek/mt6797-x20-dev.dts -- 2.17.0
[PATCH 0/2] Add Mediatek X20 Development Board support
Add devicetree support for Mediatek X20 Development Board by Archermind. This board is based on the Deca-Core MT6797 SoC from Mediatek and is one of the 96Boards Consumer Edition platform. With this devicetree change, board can boot into initramfs. More information about this board can be found in 96Boards product page: https://www.96boards.org/product/mediatek-x20/ Manivannan Sadhasivam (2): dt-bindings: Add vendor prefix for ArcherMind arm64: dts: Add Mediatek X20 Development Board support .../devicetree/bindings/vendor-prefixes.txt | 1 + arch/arm64/boot/dts/mediatek/Makefile | 1 + .../boot/dts/mediatek/mt6797-x20-dev.dts | 33 +++ 3 files changed, 35 insertions(+) create mode 100644 arch/arm64/boot/dts/mediatek/mt6797-x20-dev.dts -- 2.17.0
Re: [PATCH V4 1/2] dmaengine: sprd: Optimize the sprd_dma_prep_dma_memcpy()
On 23-05-18, 17:31, Baolin Wang wrote: > From: Eric Long > > This is one preparation patch, we can use default DMA configuration to > implement the device_prep_dma_memcpy() interface instead of issuing > sprd_dma_config(). > > We will implement one new sprd_dma_config() function with introducing > device_prep_slave_sg() interface in following patch. So we can remove > the obsolete sprd_dma_config() firstly. Applied both, thanks -- ~Vinod
Re: [PATCH V4 1/2] dmaengine: sprd: Optimize the sprd_dma_prep_dma_memcpy()
On 23-05-18, 17:31, Baolin Wang wrote: > From: Eric Long > > This is one preparation patch, we can use default DMA configuration to > implement the device_prep_dma_memcpy() interface instead of issuing > sprd_dma_config(). > > We will implement one new sprd_dma_config() function with introducing > device_prep_slave_sg() interface in following patch. So we can remove > the obsolete sprd_dma_config() firstly. Applied both, thanks -- ~Vinod
[PATCH 0/4] migrate swapper_pg_dir
Because the offset between swapper_pg_dir and _text is fixed, when attackers break KASLR, they can calculate the address of swapper_pg_dir, and then they can apply KSMA(Kernel Space Mirror Attack). The principle of KSMA is to insert an entry to PGD, and this entry has type of block with AP = 01, so attackers can read/write kernel memory directly. Details can reference: https://www.blackhat.com/docs/asia-18/asia-18-WANG-KSMA-Breaking-Android-kernel-isolation-and-Rooting-with-ARM-MMU-features.pdf These patches migrate swapper_pg_dir to new place, and there is no relationship between swapper_pg_dir and _text. Because this is done during kernel booting, the physical address of new swapper_pg_dir may be fixed. Do we need to further randomize it? YaoJun (4): Introduce a variable to record physical address of swapper_pg_dir. Introduce a variable to record new virtual address of swapper_pg_dir. Make tramp_pg_dir and swapper_pg_dir adjacent Migrate swapper_pg_dir and tramp_pg_dir. arch/arm64/include/asm/mmu_context.h | 6 +-- arch/arm64/include/asm/pgtable.h | 2 + arch/arm64/kernel/cpufeature.c | 2 +- arch/arm64/kernel/entry.S| 4 +- arch/arm64/kernel/head.S | 10 ++-- arch/arm64/kernel/hibernate.c| 2 +- arch/arm64/kernel/sleep.S| 2 + arch/arm64/kernel/vmlinux.lds.S | 10 ++-- arch/arm64/mm/kasan_init.c | 6 +-- arch/arm64/mm/mmu.c | 72 +++- 10 files changed, 74 insertions(+), 42 deletions(-) -- 2.17.0
[PATCH 0/4] migrate swapper_pg_dir
Because the offset between swapper_pg_dir and _text is fixed, when attackers break KASLR, they can calculate the address of swapper_pg_dir, and then they can apply KSMA(Kernel Space Mirror Attack). The principle of KSMA is to insert an entry to PGD, and this entry has type of block with AP = 01, so attackers can read/write kernel memory directly. Details can reference: https://www.blackhat.com/docs/asia-18/asia-18-WANG-KSMA-Breaking-Android-kernel-isolation-and-Rooting-with-ARM-MMU-features.pdf These patches migrate swapper_pg_dir to new place, and there is no relationship between swapper_pg_dir and _text. Because this is done during kernel booting, the physical address of new swapper_pg_dir may be fixed. Do we need to further randomize it? YaoJun (4): Introduce a variable to record physical address of swapper_pg_dir. Introduce a variable to record new virtual address of swapper_pg_dir. Make tramp_pg_dir and swapper_pg_dir adjacent Migrate swapper_pg_dir and tramp_pg_dir. arch/arm64/include/asm/mmu_context.h | 6 +-- arch/arm64/include/asm/pgtable.h | 2 + arch/arm64/kernel/cpufeature.c | 2 +- arch/arm64/kernel/entry.S| 4 +- arch/arm64/kernel/head.S | 10 ++-- arch/arm64/kernel/hibernate.c| 2 +- arch/arm64/kernel/sleep.S| 2 + arch/arm64/kernel/vmlinux.lds.S | 10 ++-- arch/arm64/mm/kasan_init.c | 6 +-- arch/arm64/mm/mmu.c | 72 +++- 10 files changed, 74 insertions(+), 42 deletions(-) -- 2.17.0
[PATCH v6 3/3] dt-bindings: phy-qcom-qmp: Add UFS phy compatible string for sdm845
Update the compatible string for UFS QMP PHY on SDM845. Signed-off-by: Can Guo Reviewed-by: Rob Herring --- Documentation/devicetree/bindings/phy/qcom-qmp-phy.txt | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/phy/qcom-qmp-phy.txt b/Documentation/devicetree/bindings/phy/qcom-qmp-phy.txt index cef8765..930d94c 100644 --- a/Documentation/devicetree/bindings/phy/qcom-qmp-phy.txt +++ b/Documentation/devicetree/bindings/phy/qcom-qmp-phy.txt @@ -11,7 +11,8 @@ Required properties: "qcom,msm8996-qmp-usb3-phy" for 14nm USB3 phy on msm8996, "qcom,qmp-v3-usb3-phy" for USB3 QMP V3 phy, "qcom,sdm845-qmp-usb3-phy" for USB3 QMP V3 phy on sdm845, - "qcom,sdm845-qmp-usb3-uni-phy" for USB3 QMP V3 UNI phy on sdm845. + "qcom,sdm845-qmp-usb3-uni-phy" for USB3 QMP V3 UNI phy on sdm845, + "qcom,sdm845-qmp-ufs-phy" for UFS QMP phy on sdm845. - reg: offset and length of register set for PHY's common serdes block. @@ -29,6 +30,7 @@ Required properties: "aux" for phy aux clock, "ref" for 19.2 MHz ref clk, "com_aux" for phy common block aux clock, + "ref_aux" for phy reference aux clock, For "qcom,msm8996-qmp-pcie-phy" must contain: "aux", "cfg_ahb", "ref". For "qcom,msm8996-qmp-usb3-phy" must contain: -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project
[PATCH v6 3/3] dt-bindings: phy-qcom-qmp: Add UFS phy compatible string for sdm845
Update the compatible string for UFS QMP PHY on SDM845. Signed-off-by: Can Guo Reviewed-by: Rob Herring --- Documentation/devicetree/bindings/phy/qcom-qmp-phy.txt | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/phy/qcom-qmp-phy.txt b/Documentation/devicetree/bindings/phy/qcom-qmp-phy.txt index cef8765..930d94c 100644 --- a/Documentation/devicetree/bindings/phy/qcom-qmp-phy.txt +++ b/Documentation/devicetree/bindings/phy/qcom-qmp-phy.txt @@ -11,7 +11,8 @@ Required properties: "qcom,msm8996-qmp-usb3-phy" for 14nm USB3 phy on msm8996, "qcom,qmp-v3-usb3-phy" for USB3 QMP V3 phy, "qcom,sdm845-qmp-usb3-phy" for USB3 QMP V3 phy on sdm845, - "qcom,sdm845-qmp-usb3-uni-phy" for USB3 QMP V3 UNI phy on sdm845. + "qcom,sdm845-qmp-usb3-uni-phy" for USB3 QMP V3 UNI phy on sdm845, + "qcom,sdm845-qmp-ufs-phy" for UFS QMP phy on sdm845. - reg: offset and length of register set for PHY's common serdes block. @@ -29,6 +30,7 @@ Required properties: "aux" for phy aux clock, "ref" for 19.2 MHz ref clk, "com_aux" for phy common block aux clock, + "ref_aux" for phy reference aux clock, For "qcom,msm8996-qmp-pcie-phy" must contain: "aux", "cfg_ahb", "ref". For "qcom,msm8996-qmp-usb3-phy" must contain: -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project
[PATCH v6 2/3] phy: Add QMP phy based UFS phy support for sdm845
Add UFS PHY support to make SDM845 UFS work with common PHY framework.
Signed-off-by: Can Guo
---
drivers/phy/qualcomm/phy-qcom-qmp.c | 200 +---
drivers/phy/qualcomm/phy-qcom-qmp.h | 15 +++
2 files changed, 203 insertions(+), 12 deletions(-)
diff --git a/drivers/phy/qualcomm/phy-qcom-qmp.c
b/drivers/phy/qualcomm/phy-qcom-qmp.c
index f779b0f..ee74dcd 100644
--- a/drivers/phy/qualcomm/phy-qcom-qmp.c
+++ b/drivers/phy/qualcomm/phy-qcom-qmp.c
@@ -156,6 +156,11 @@ enum qphy_reg_layout {
[QPHY_PCS_LFPS_RXTERM_IRQ_STATUS] = 0x170,
};
+static const unsigned int sdm845_ufsphy_regs_layout[] = {
+ [QPHY_START_CTRL] = 0x00,
+ [QPHY_PCS_READY_STATUS] = 0x160,
+};
+
static const struct qmp_phy_init_tbl msm8996_pcie_serdes_tbl[] = {
QMP_PHY_INIT_CFG(QSERDES_COM_BIAS_EN_CLKBUFLR_EN, 0x1c),
QMP_PHY_INIT_CFG(QSERDES_COM_CLK_ENABLE1, 0x10),
@@ -601,6 +606,83 @@ enum qphy_reg_layout {
QMP_PHY_INIT_CFG(QPHY_V3_PCS_REFGEN_REQ_CONFIG2, 0x60),
};
+static const struct qmp_phy_init_tbl sdm845_ufsphy_serdes_tbl[] = {
+ QMP_PHY_INIT_CFG(QSERDES_V3_COM_SYS_CLK_CTRL, 0x02),
+ QMP_PHY_INIT_CFG(QSERDES_V3_COM_BIAS_EN_CLKBUFLR_EN, 0x04),
+ QMP_PHY_INIT_CFG(QSERDES_V3_COM_BG_TIMER, 0x0a),
+ QMP_PHY_INIT_CFG(QSERDES_V3_COM_PLL_IVCO, 0x07),
+ QMP_PHY_INIT_CFG(QSERDES_V3_COM_CMN_CONFIG, 0x06),
+ QMP_PHY_INIT_CFG(QSERDES_V3_COM_SYSCLK_EN_SEL, 0xd5),
+ QMP_PHY_INIT_CFG(QSERDES_V3_COM_RESETSM_CNTRL, 0x20),
+ QMP_PHY_INIT_CFG(QSERDES_V3_COM_CLK_SELECT, 0x30),
+ QMP_PHY_INIT_CFG(QSERDES_V3_COM_HSCLK_SEL, 0x00),
+ QMP_PHY_INIT_CFG(QSERDES_V3_COM_LOCK_CMP_EN, 0x01),
+ QMP_PHY_INIT_CFG(QSERDES_V3_COM_VCO_TUNE_CTRL, 0x00),
+ QMP_PHY_INIT_CFG(QSERDES_V3_COM_CORE_CLK_EN, 0x00),
+ QMP_PHY_INIT_CFG(QSERDES_V3_COM_VCO_TUNE_MAP, 0x04),
+ QMP_PHY_INIT_CFG(QSERDES_V3_COM_SVS_MODE_CLK_SEL, 0x05),
+ QMP_PHY_INIT_CFG(QSERDES_V3_COM_VCO_TUNE_INITVAL1, 0xff),
+ QMP_PHY_INIT_CFG(QSERDES_V3_COM_VCO_TUNE_INITVAL2, 0x00),
+ QMP_PHY_INIT_CFG(QSERDES_V3_COM_DEC_START_MODE0, 0x82),
+ QMP_PHY_INIT_CFG(QSERDES_V3_COM_CP_CTRL_MODE0, 0x06),
+ QMP_PHY_INIT_CFG(QSERDES_V3_COM_PLL_RCTRL_MODE0, 0x16),
+ QMP_PHY_INIT_CFG(QSERDES_V3_COM_PLL_CCTRL_MODE0, 0x36),
+ QMP_PHY_INIT_CFG(QSERDES_V3_COM_INTEGLOOP_GAIN0_MODE0, 0x3f),
+ QMP_PHY_INIT_CFG(QSERDES_V3_COM_INTEGLOOP_GAIN1_MODE0, 0x00),
+ QMP_PHY_INIT_CFG(QSERDES_V3_COM_VCO_TUNE1_MODE0, 0xda),
+ QMP_PHY_INIT_CFG(QSERDES_V3_COM_VCO_TUNE2_MODE0, 0x01),
+ QMP_PHY_INIT_CFG(QSERDES_V3_COM_LOCK_CMP1_MODE0, 0xff),
+ QMP_PHY_INIT_CFG(QSERDES_V3_COM_LOCK_CMP2_MODE0, 0x0c),
+ QMP_PHY_INIT_CFG(QSERDES_V3_COM_DEC_START_MODE1, 0x98),
+ QMP_PHY_INIT_CFG(QSERDES_V3_COM_CP_CTRL_MODE1, 0x06),
+ QMP_PHY_INIT_CFG(QSERDES_V3_COM_PLL_RCTRL_MODE1, 0x16),
+ QMP_PHY_INIT_CFG(QSERDES_V3_COM_PLL_CCTRL_MODE1, 0x36),
+ QMP_PHY_INIT_CFG(QSERDES_V3_COM_INTEGLOOP_GAIN0_MODE1, 0x3f),
+ QMP_PHY_INIT_CFG(QSERDES_V3_COM_INTEGLOOP_GAIN1_MODE1, 0x00),
+ QMP_PHY_INIT_CFG(QSERDES_V3_COM_VCO_TUNE1_MODE1, 0xc1),
+ QMP_PHY_INIT_CFG(QSERDES_V3_COM_VCO_TUNE2_MODE1, 0x00),
+ QMP_PHY_INIT_CFG(QSERDES_V3_COM_LOCK_CMP1_MODE1, 0x32),
+ QMP_PHY_INIT_CFG(QSERDES_V3_COM_LOCK_CMP2_MODE1, 0x0f),
+
+ /* Rate B */
+ QMP_PHY_INIT_CFG(QSERDES_V3_COM_VCO_TUNE_MAP, 0x44),
+};
+
+static const struct qmp_phy_init_tbl sdm845_ufsphy_tx_tbl[] = {
+ QMP_PHY_INIT_CFG(QSERDES_V3_TX_LANE_MODE_1, 0x06),
+ QMP_PHY_INIT_CFG(QSERDES_V3_TX_RES_CODE_LANE_OFFSET_TX, 0x04),
+ QMP_PHY_INIT_CFG(QSERDES_V3_TX_RES_CODE_LANE_OFFSET_RX, 0x07),
+};
+
+static const struct qmp_phy_init_tbl sdm845_ufsphy_rx_tbl[] = {
+ QMP_PHY_INIT_CFG(QSERDES_V3_RX_SIGDET_LVL, 0x24),
+ QMP_PHY_INIT_CFG(QSERDES_V3_RX_SIGDET_CNTRL, 0x0f),
+ QMP_PHY_INIT_CFG(QSERDES_V3_RX_SIGDET_DEGLITCH_CNTRL, 0x1e),
+ QMP_PHY_INIT_CFG(QSERDES_V3_RX_RX_INTERFACE_MODE, 0x40),
+ QMP_PHY_INIT_CFG(QSERDES_V3_RX_UCDR_FASTLOCK_FO_GAIN, 0x0b),
+ QMP_PHY_INIT_CFG(QSERDES_V3_RX_RX_TERM_BW, 0x5b),
+ QMP_PHY_INIT_CFG(QSERDES_V3_RX_RX_EQU_ADAPTOR_CNTRL2, 0x06),
+ QMP_PHY_INIT_CFG(QSERDES_V3_RX_RX_EQU_ADAPTOR_CNTRL3, 0x04),
+ QMP_PHY_INIT_CFG(QSERDES_V3_RX_RX_EQU_ADAPTOR_CNTRL4, 0x1b),
+ QMP_PHY_INIT_CFG(QSERDES_V3_RX_UCDR_SVS_SO_GAIN_HALF, 0x04),
+ QMP_PHY_INIT_CFG(QSERDES_V3_RX_UCDR_SVS_SO_GAIN_QUARTER, 0x04),
+ QMP_PHY_INIT_CFG(QSERDES_V3_RX_UCDR_SVS_SO_GAIN, 0x04),
+ QMP_PHY_INIT_CFG(QSERDES_V3_RX_UCDR_SO_SATURATION_AND_ENABLE, 0x4b),
+ QMP_PHY_INIT_CFG(QSERDES_V3_RX_UCDR_PI_CONTROLS, 0x81),
+ QMP_PHY_INIT_CFG(QSERDES_V3_RX_UCDR_FASTLOCK_COUNT_LOW, 0x80),
+ QMP_PHY_INIT_CFG(QSERDES_V3_RX_RX_MODE_00, 0x59),
+};
+
+static const struct qmp_phy_init_tbl sdm845_ufsphy_pcs_tbl[] = {
+
[PATCH v6 2/3] phy: Add QMP phy based UFS phy support for sdm845
Add UFS PHY support to make SDM845 UFS work with common PHY framework.
Signed-off-by: Can Guo
---
drivers/phy/qualcomm/phy-qcom-qmp.c | 200 +---
drivers/phy/qualcomm/phy-qcom-qmp.h | 15 +++
2 files changed, 203 insertions(+), 12 deletions(-)
diff --git a/drivers/phy/qualcomm/phy-qcom-qmp.c
b/drivers/phy/qualcomm/phy-qcom-qmp.c
index f779b0f..ee74dcd 100644
--- a/drivers/phy/qualcomm/phy-qcom-qmp.c
+++ b/drivers/phy/qualcomm/phy-qcom-qmp.c
@@ -156,6 +156,11 @@ enum qphy_reg_layout {
[QPHY_PCS_LFPS_RXTERM_IRQ_STATUS] = 0x170,
};
+static const unsigned int sdm845_ufsphy_regs_layout[] = {
+ [QPHY_START_CTRL] = 0x00,
+ [QPHY_PCS_READY_STATUS] = 0x160,
+};
+
static const struct qmp_phy_init_tbl msm8996_pcie_serdes_tbl[] = {
QMP_PHY_INIT_CFG(QSERDES_COM_BIAS_EN_CLKBUFLR_EN, 0x1c),
QMP_PHY_INIT_CFG(QSERDES_COM_CLK_ENABLE1, 0x10),
@@ -601,6 +606,83 @@ enum qphy_reg_layout {
QMP_PHY_INIT_CFG(QPHY_V3_PCS_REFGEN_REQ_CONFIG2, 0x60),
};
+static const struct qmp_phy_init_tbl sdm845_ufsphy_serdes_tbl[] = {
+ QMP_PHY_INIT_CFG(QSERDES_V3_COM_SYS_CLK_CTRL, 0x02),
+ QMP_PHY_INIT_CFG(QSERDES_V3_COM_BIAS_EN_CLKBUFLR_EN, 0x04),
+ QMP_PHY_INIT_CFG(QSERDES_V3_COM_BG_TIMER, 0x0a),
+ QMP_PHY_INIT_CFG(QSERDES_V3_COM_PLL_IVCO, 0x07),
+ QMP_PHY_INIT_CFG(QSERDES_V3_COM_CMN_CONFIG, 0x06),
+ QMP_PHY_INIT_CFG(QSERDES_V3_COM_SYSCLK_EN_SEL, 0xd5),
+ QMP_PHY_INIT_CFG(QSERDES_V3_COM_RESETSM_CNTRL, 0x20),
+ QMP_PHY_INIT_CFG(QSERDES_V3_COM_CLK_SELECT, 0x30),
+ QMP_PHY_INIT_CFG(QSERDES_V3_COM_HSCLK_SEL, 0x00),
+ QMP_PHY_INIT_CFG(QSERDES_V3_COM_LOCK_CMP_EN, 0x01),
+ QMP_PHY_INIT_CFG(QSERDES_V3_COM_VCO_TUNE_CTRL, 0x00),
+ QMP_PHY_INIT_CFG(QSERDES_V3_COM_CORE_CLK_EN, 0x00),
+ QMP_PHY_INIT_CFG(QSERDES_V3_COM_VCO_TUNE_MAP, 0x04),
+ QMP_PHY_INIT_CFG(QSERDES_V3_COM_SVS_MODE_CLK_SEL, 0x05),
+ QMP_PHY_INIT_CFG(QSERDES_V3_COM_VCO_TUNE_INITVAL1, 0xff),
+ QMP_PHY_INIT_CFG(QSERDES_V3_COM_VCO_TUNE_INITVAL2, 0x00),
+ QMP_PHY_INIT_CFG(QSERDES_V3_COM_DEC_START_MODE0, 0x82),
+ QMP_PHY_INIT_CFG(QSERDES_V3_COM_CP_CTRL_MODE0, 0x06),
+ QMP_PHY_INIT_CFG(QSERDES_V3_COM_PLL_RCTRL_MODE0, 0x16),
+ QMP_PHY_INIT_CFG(QSERDES_V3_COM_PLL_CCTRL_MODE0, 0x36),
+ QMP_PHY_INIT_CFG(QSERDES_V3_COM_INTEGLOOP_GAIN0_MODE0, 0x3f),
+ QMP_PHY_INIT_CFG(QSERDES_V3_COM_INTEGLOOP_GAIN1_MODE0, 0x00),
+ QMP_PHY_INIT_CFG(QSERDES_V3_COM_VCO_TUNE1_MODE0, 0xda),
+ QMP_PHY_INIT_CFG(QSERDES_V3_COM_VCO_TUNE2_MODE0, 0x01),
+ QMP_PHY_INIT_CFG(QSERDES_V3_COM_LOCK_CMP1_MODE0, 0xff),
+ QMP_PHY_INIT_CFG(QSERDES_V3_COM_LOCK_CMP2_MODE0, 0x0c),
+ QMP_PHY_INIT_CFG(QSERDES_V3_COM_DEC_START_MODE1, 0x98),
+ QMP_PHY_INIT_CFG(QSERDES_V3_COM_CP_CTRL_MODE1, 0x06),
+ QMP_PHY_INIT_CFG(QSERDES_V3_COM_PLL_RCTRL_MODE1, 0x16),
+ QMP_PHY_INIT_CFG(QSERDES_V3_COM_PLL_CCTRL_MODE1, 0x36),
+ QMP_PHY_INIT_CFG(QSERDES_V3_COM_INTEGLOOP_GAIN0_MODE1, 0x3f),
+ QMP_PHY_INIT_CFG(QSERDES_V3_COM_INTEGLOOP_GAIN1_MODE1, 0x00),
+ QMP_PHY_INIT_CFG(QSERDES_V3_COM_VCO_TUNE1_MODE1, 0xc1),
+ QMP_PHY_INIT_CFG(QSERDES_V3_COM_VCO_TUNE2_MODE1, 0x00),
+ QMP_PHY_INIT_CFG(QSERDES_V3_COM_LOCK_CMP1_MODE1, 0x32),
+ QMP_PHY_INIT_CFG(QSERDES_V3_COM_LOCK_CMP2_MODE1, 0x0f),
+
+ /* Rate B */
+ QMP_PHY_INIT_CFG(QSERDES_V3_COM_VCO_TUNE_MAP, 0x44),
+};
+
+static const struct qmp_phy_init_tbl sdm845_ufsphy_tx_tbl[] = {
+ QMP_PHY_INIT_CFG(QSERDES_V3_TX_LANE_MODE_1, 0x06),
+ QMP_PHY_INIT_CFG(QSERDES_V3_TX_RES_CODE_LANE_OFFSET_TX, 0x04),
+ QMP_PHY_INIT_CFG(QSERDES_V3_TX_RES_CODE_LANE_OFFSET_RX, 0x07),
+};
+
+static const struct qmp_phy_init_tbl sdm845_ufsphy_rx_tbl[] = {
+ QMP_PHY_INIT_CFG(QSERDES_V3_RX_SIGDET_LVL, 0x24),
+ QMP_PHY_INIT_CFG(QSERDES_V3_RX_SIGDET_CNTRL, 0x0f),
+ QMP_PHY_INIT_CFG(QSERDES_V3_RX_SIGDET_DEGLITCH_CNTRL, 0x1e),
+ QMP_PHY_INIT_CFG(QSERDES_V3_RX_RX_INTERFACE_MODE, 0x40),
+ QMP_PHY_INIT_CFG(QSERDES_V3_RX_UCDR_FASTLOCK_FO_GAIN, 0x0b),
+ QMP_PHY_INIT_CFG(QSERDES_V3_RX_RX_TERM_BW, 0x5b),
+ QMP_PHY_INIT_CFG(QSERDES_V3_RX_RX_EQU_ADAPTOR_CNTRL2, 0x06),
+ QMP_PHY_INIT_CFG(QSERDES_V3_RX_RX_EQU_ADAPTOR_CNTRL3, 0x04),
+ QMP_PHY_INIT_CFG(QSERDES_V3_RX_RX_EQU_ADAPTOR_CNTRL4, 0x1b),
+ QMP_PHY_INIT_CFG(QSERDES_V3_RX_UCDR_SVS_SO_GAIN_HALF, 0x04),
+ QMP_PHY_INIT_CFG(QSERDES_V3_RX_UCDR_SVS_SO_GAIN_QUARTER, 0x04),
+ QMP_PHY_INIT_CFG(QSERDES_V3_RX_UCDR_SVS_SO_GAIN, 0x04),
+ QMP_PHY_INIT_CFG(QSERDES_V3_RX_UCDR_SO_SATURATION_AND_ENABLE, 0x4b),
+ QMP_PHY_INIT_CFG(QSERDES_V3_RX_UCDR_PI_CONTROLS, 0x81),
+ QMP_PHY_INIT_CFG(QSERDES_V3_RX_UCDR_FASTLOCK_COUNT_LOW, 0x80),
+ QMP_PHY_INIT_CFG(QSERDES_V3_RX_RX_MODE_00, 0x59),
+};
+
+static const struct qmp_phy_init_tbl sdm845_ufsphy_pcs_tbl[] = {
+
[PATCH v6 1/3] phy: Update PHY power control sequence
All PHYs should be powered on before register configuration starts. And
only PCIe PHYs need an extra power control before deasserts reset state.
Signed-off-by: Can Guo
---
drivers/phy/qualcomm/phy-qcom-qmp.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/phy/qualcomm/phy-qcom-qmp.c
b/drivers/phy/qualcomm/phy-qcom-qmp.c
index 97ef942..f779b0f 100644
--- a/drivers/phy/qualcomm/phy-qcom-qmp.c
+++ b/drivers/phy/qualcomm/phy-qcom-qmp.c
@@ -982,6 +982,8 @@ static int qcom_qmp_phy_com_init(struct qcom_qmp *qmp)
if (cfg->has_phy_com_ctrl)
qphy_setbits(serdes, cfg->regs[QPHY_COM_POWER_DOWN_CONTROL],
SW_PWRDN);
+ else
+ qphy_setbits(pcs, QPHY_POWER_DOWN_CONTROL, cfg->pwrdn_ctrl);
if (cfg->has_phy_dp_com_ctrl) {
qphy_setbits(dp_com, QPHY_V3_DP_COM_POWER_DOWN_CTRL,
@@ -1127,7 +1129,8 @@ static int qcom_qmp_phy_init(struct phy *phy)
* Pull out PHY from POWER DOWN state.
* This is active low enable signal to power-down PHY.
*/
- qphy_setbits(pcs, QPHY_POWER_DOWN_CONTROL, cfg->pwrdn_ctrl);
+ if (cfg->type == PHY_TYPE_PCIE)
+ qphy_setbits(pcs, QPHY_POWER_DOWN_CONTROL, cfg->pwrdn_ctrl);
if (cfg->has_pwrdn_delay)
usleep_range(cfg->pwrdn_delay_min, cfg->pwrdn_delay_max);
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
[PATCH v6 1/3] phy: Update PHY power control sequence
All PHYs should be powered on before register configuration starts. And
only PCIe PHYs need an extra power control before deasserts reset state.
Signed-off-by: Can Guo
---
drivers/phy/qualcomm/phy-qcom-qmp.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/phy/qualcomm/phy-qcom-qmp.c
b/drivers/phy/qualcomm/phy-qcom-qmp.c
index 97ef942..f779b0f 100644
--- a/drivers/phy/qualcomm/phy-qcom-qmp.c
+++ b/drivers/phy/qualcomm/phy-qcom-qmp.c
@@ -982,6 +982,8 @@ static int qcom_qmp_phy_com_init(struct qcom_qmp *qmp)
if (cfg->has_phy_com_ctrl)
qphy_setbits(serdes, cfg->regs[QPHY_COM_POWER_DOWN_CONTROL],
SW_PWRDN);
+ else
+ qphy_setbits(pcs, QPHY_POWER_DOWN_CONTROL, cfg->pwrdn_ctrl);
if (cfg->has_phy_dp_com_ctrl) {
qphy_setbits(dp_com, QPHY_V3_DP_COM_POWER_DOWN_CTRL,
@@ -1127,7 +1129,8 @@ static int qcom_qmp_phy_init(struct phy *phy)
* Pull out PHY from POWER DOWN state.
* This is active low enable signal to power-down PHY.
*/
- qphy_setbits(pcs, QPHY_POWER_DOWN_CONTROL, cfg->pwrdn_ctrl);
+ if (cfg->type == PHY_TYPE_PCIE)
+ qphy_setbits(pcs, QPHY_POWER_DOWN_CONTROL, cfg->pwrdn_ctrl);
if (cfg->has_pwrdn_delay)
usleep_range(cfg->pwrdn_delay_min, cfg->pwrdn_delay_max);
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
[PATCH v6 0/3] Support for Qualcomm UFS QMP PHY on SDM845
This patch series adds support for UFS QMP PHY on SDM845 and the compatible string for it. This patch series depends on the current proposed QMP V3 USB3 UNI PHY support for sdm845 driver [1], on the DT bindings for the QMP V3 USB3 PHYs based dirver [2], and also rebased on updated pipe_clk initialization sequence [3]. This series can only be merged once the dependent patches do. [1] http://lists-archives.com/linux-kernel/29071659-dt-bindings-phy-qcom-qmp-update-bindings-for-sdm845.html [2] http://lists-archives.com/linux-kernel/29071660-phy-qcom-qmp-add-qmp-v3-usb3-uni-phy-support-for-sdm845.html [3] https://patchwork.kernel.org/patch/10376551/ Changes since v5: - Updates the PHY power control sequence. - Updates UFS PHY power on condition check. Changes since v4: - Adds 'ref_aux' clock back to SDM845 UFS PHY clock list. - Power on PHY before serdes configuration starts. - Updates the UFS PHY initialization sequence. - Updates a few UFS PHY registers. - Incorporated review comments from Vivek and Manu. Changes since v3: - Incorporated review comments from Vivek and Rob. Changes since v2: - Incorporated review comments from Vivek and Rob. - Remove "ref_aux" from sdm845 ufs phy clock list structure. Changes since v1: - Incorporated review comments from Vivek and Manu. - Update the commit title of patch 2. Can Guo (3): phy: Update PHY power control sequence phy: Add QMP phy based UFS phy support for sdm845 dt-bindings: phy-qcom-qmp: Add UFS phy compatible string for sdm845 .../devicetree/bindings/phy/qcom-qmp-phy.txt | 4 +- drivers/phy/qualcomm/phy-qcom-qmp.c| 205 +++-- drivers/phy/qualcomm/phy-qcom-qmp.h| 15 ++ 3 files changed, 210 insertions(+), 14 deletions(-) -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project
[PATCH v6 0/3] Support for Qualcomm UFS QMP PHY on SDM845
This patch series adds support for UFS QMP PHY on SDM845 and the compatible string for it. This patch series depends on the current proposed QMP V3 USB3 UNI PHY support for sdm845 driver [1], on the DT bindings for the QMP V3 USB3 PHYs based dirver [2], and also rebased on updated pipe_clk initialization sequence [3]. This series can only be merged once the dependent patches do. [1] http://lists-archives.com/linux-kernel/29071659-dt-bindings-phy-qcom-qmp-update-bindings-for-sdm845.html [2] http://lists-archives.com/linux-kernel/29071660-phy-qcom-qmp-add-qmp-v3-usb3-uni-phy-support-for-sdm845.html [3] https://patchwork.kernel.org/patch/10376551/ Changes since v5: - Updates the PHY power control sequence. - Updates UFS PHY power on condition check. Changes since v4: - Adds 'ref_aux' clock back to SDM845 UFS PHY clock list. - Power on PHY before serdes configuration starts. - Updates the UFS PHY initialization sequence. - Updates a few UFS PHY registers. - Incorporated review comments from Vivek and Manu. Changes since v3: - Incorporated review comments from Vivek and Rob. Changes since v2: - Incorporated review comments from Vivek and Rob. - Remove "ref_aux" from sdm845 ufs phy clock list structure. Changes since v1: - Incorporated review comments from Vivek and Manu. - Update the commit title of patch 2. Can Guo (3): phy: Update PHY power control sequence phy: Add QMP phy based UFS phy support for sdm845 dt-bindings: phy-qcom-qmp: Add UFS phy compatible string for sdm845 .../devicetree/bindings/phy/qcom-qmp-phy.txt | 4 +- drivers/phy/qualcomm/phy-qcom-qmp.c| 205 +++-- drivers/phy/qualcomm/phy-qcom-qmp.h| 15 ++ 3 files changed, 210 insertions(+), 14 deletions(-) -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project
[PATCH 4/4] migrate swapper_pg_dir
Migrate swapper_pg_dir and tramp_pg_dir. And its placement in
the virtual address space does not correlate with the placement
of the kernel.
---
arch/arm64/mm/mmu.c | 67 ++---
1 file changed, 45 insertions(+), 22 deletions(-)
diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
index 26ba3e70a91c..0b1a77b8c757 100644
--- a/arch/arm64/mm/mmu.c
+++ b/arch/arm64/mm/mmu.c
@@ -55,6 +55,9 @@ u64 idmap_ptrs_per_pgd = PTRS_PER_PGD;
u64 kimage_voffset __ro_after_init;
EXPORT_SYMBOL(kimage_voffset);
+#ifdef CONFIG_UNMAP_KERNEL_AT_EL0
+pgd_t *new_tramp_pg_dir;
+#endif
phys_addr_t __pa_swapper_pg_dir;
pgd_t *new_swapper_pg_dir = swapper_pg_dir;
@@ -105,6 +108,25 @@ static phys_addr_t __init early_pgtable_alloc(void)
return phys;
}
+#ifdef CONFIG_UNMAP_KERNEL_AT_EL0
+static phys_addr_t __init early_pgtables_alloc(int num)
+{
+ int i;
+ phys_addr_t phys;
+ void *ptr;
+
+ phys = memblock_alloc(PAGE_SIZE * num, PAGE_SIZE);
+
+ for (i = 0; i < num; i++) {
+ ptr = pte_set_fixmap(phys + i * PAGE_SIZE);
+ memset(ptr, 0, PAGE_SIZE);
+ pte_clear_fixmap();
+ }
+
+ return phys;
+}
+#endif
+
static bool pgattr_change_is_safe(u64 old, u64 new)
{
/*
@@ -554,6 +576,10 @@ static int __init map_entry_trampoline(void)
__create_pgd_mapping(tramp_pg_dir, pa_start, TRAMP_VALIAS, PAGE_SIZE,
prot, pgd_pgtable_alloc, 0);
+ memcpy(new_tramp_pg_dir, tramp_pg_dir, PGD_SIZE);
+ memblock_free(__pa_symbol(tramp_pg_dir),
+ __pa_symbol(swapper_pg_dir) - __pa_symbol(tramp_pg_dir));
+
/* Map both the text and data into the kernel page table */
__set_fixmap(FIX_ENTRY_TRAMP_TEXT, pa_start, prot);
if (IS_ENABLED(CONFIG_RANDOMIZE_BASE)) {
@@ -631,36 +657,33 @@ static void __init map_kernel(pgd_t *pgdp)
*/
void __init paging_init(void)
{
- phys_addr_t pgd_phys = early_pgtable_alloc();
- pgd_t *pgdp = pgd_set_fixmap(pgd_phys);
+ phys_addr_t pgd_phys;
+ pgd_t *pgdp;
- __pa_swapper_pg_dir = __pa_symbol(swapper_pg_dir);
+#ifdef CONFIG_UNMAP_KERNEL_AT_EL0
+ int pages;
+ pages = (__pa_symbol(swapper_pg_dir) - __pa_symbol(tramp_pg_dir) +
+ PAGE_SIZE) >> PAGE_SHIFT;
+ pgd_phys = early_pgtables_alloc(pages);
+ new_tramp_pg_dir = __va(pgd_phys);
+ __pa_swapper_pg_dir = pgd_phys + PAGE_SIZE;
+#else
+ pgd_phys = early_pgtable_alloc();
+ __pa_swapper_pg_dir = pgd_phys;
+#endif
+ new_swapper_pg_dir = __va(__pa_swapper_pg_dir);
+
+ pgdp = pgd_set_fixmap(__pa_swapper_pg_dir);
map_kernel(pgdp);
map_mem(pgdp);
- /*
-* We want to reuse the original swapper_pg_dir so we don't have to
-* communicate the new address to non-coherent secondaries in
-* secondary_entry, and so cpu_switch_mm can generate the address with
-* adrp+add rather than a load from some global variable.
-*
-* To do this we need to go via a temporary pgd.
-*/
- cpu_replace_ttbr1(pgd_phys);
- memcpy(swapper_pg_dir, pgdp, PGD_SIZE);
cpu_replace_ttbr1(__pa_swapper_pg_dir);
+ init_mm.pgd = new_swapper_pg_dir;
pgd_clear_fixmap();
- memblock_free(pgd_phys, PAGE_SIZE);
-
- /*
-* We only reuse the PGD from the swapper_pg_dir, not the pud + pmd
-* allocated with it.
-*/
- memblock_free(__pa_symbol(swapper_pg_dir) + PAGE_SIZE,
- __pa_symbol(swapper_pg_end) - __pa_symbol(swapper_pg_dir)
- - PAGE_SIZE);
+ memblock_free(__pa_symbol(swapper_pg_dir),
+ __pa_symbol(swapper_pg_end) -
__pa_symbol(swapper_pg_dir));
}
/*
--
2.17.0
linux-next: manual merge of the block tree with the vfs tree
Hi all,
Today's linux-next merge of the block tree got a conflict in:
drivers/block/drbd/drbd_main.c
between commit:
004fd11db1d6 ("drbd: switch to proc_create_single")
from the vfs tree and commit:
5657a819a8d9 ("block drivers/block: Use octal not symbolic permissions")
from the block tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc drivers/block/drbd/drbd_main.c
index c2d154faac02,e6ec831ad472..
--- a/drivers/block/drbd/drbd_main.c
+++ b/drivers/block/drbd/drbd_main.c
@@@ -3010,8 -3010,7 +3010,8 @@@ static int __init drbd_init(void
goto fail;
err = -ENOMEM;
- drbd_proc = proc_create_single("drbd", S_IFREG | S_IRUGO , NULL,
- drbd_proc = proc_create_data("drbd", S_IFREG | 0444 , NULL,
_proc_fops, NULL);
++ drbd_proc = proc_create_single("drbd", S_IFREG | 0444 , NULL,
+ drbd_seq_show);
if (!drbd_proc) {
pr_err("unable to register proc file\n");
goto fail;
pgpl1YdX4Kt7T.pgp
Description: OpenPGP digital signature
[PATCH 2/4] migrate swapper_pg_dir
Introduce a variable to record new virtual address of
swapper_pg_dir.
---
arch/arm64/include/asm/mmu_context.h | 2 +-
arch/arm64/include/asm/pgtable.h | 1 +
arch/arm64/mm/kasan_init.c | 2 +-
arch/arm64/mm/mmu.c | 1 +
4 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/include/asm/mmu_context.h
b/arch/arm64/include/asm/mmu_context.h
index 3eddb871f251..481c2d16adeb 100644
--- a/arch/arm64/include/asm/mmu_context.h
+++ b/arch/arm64/include/asm/mmu_context.h
@@ -57,7 +57,7 @@ static inline void cpu_set_reserved_ttbr0(void)
static inline void cpu_switch_mm(pgd_t *pgd, struct mm_struct *mm)
{
- BUG_ON(pgd == swapper_pg_dir);
+ BUG_ON(pgd == new_swapper_pg_dir);
cpu_set_reserved_ttbr0();
cpu_do_switch_mm(virt_to_phys(pgd),mm);
}
diff --git a/arch/arm64/include/asm/pgtable.h b/arch/arm64/include/asm/pgtable.h
index 14ba344b1af7..7abec25cedd2 100644
--- a/arch/arm64/include/asm/pgtable.h
+++ b/arch/arm64/include/asm/pgtable.h
@@ -723,6 +723,7 @@ extern pgd_t swapper_pg_end[];
extern pgd_t idmap_pg_dir[PTRS_PER_PGD];
extern pgd_t tramp_pg_dir[PTRS_PER_PGD];
extern phys_addr_t __pa_swapper_pg_dir;
+extern pgd_t *new_swapper_pg_dir;
/*
* Encode and decode a swap entry:
diff --git a/arch/arm64/mm/kasan_init.c b/arch/arm64/mm/kasan_init.c
index dd4f28c19165..08bcaae4725e 100644
--- a/arch/arm64/mm/kasan_init.c
+++ b/arch/arm64/mm/kasan_init.c
@@ -197,7 +197,7 @@ void __init kasan_init(void)
* tmp_pg_dir used to keep early shadow mapped until full shadow
* setup will be finished.
*/
- memcpy(tmp_pg_dir, swapper_pg_dir, sizeof(tmp_pg_dir));
+ memcpy(tmp_pg_dir, new_swapper_pg_dir, sizeof(tmp_pg_dir));
dsb(ishst);
cpu_replace_ttbr1(__pa_symbol(tmp_pg_dir));
diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
index 41eee333f91a..26ba3e70a91c 100644
--- a/arch/arm64/mm/mmu.c
+++ b/arch/arm64/mm/mmu.c
@@ -56,6 +56,7 @@ u64 kimage_voffset __ro_after_init;
EXPORT_SYMBOL(kimage_voffset);
phys_addr_t __pa_swapper_pg_dir;
+pgd_t *new_swapper_pg_dir = swapper_pg_dir;
/*
* Empty_zero_page is a special page that is used for zero-initialized data
--
2.17.0
[PATCH 4/4] migrate swapper_pg_dir
Migrate swapper_pg_dir and tramp_pg_dir. And its placement in
the virtual address space does not correlate with the placement
of the kernel.
---
arch/arm64/mm/mmu.c | 67 ++---
1 file changed, 45 insertions(+), 22 deletions(-)
diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
index 26ba3e70a91c..0b1a77b8c757 100644
--- a/arch/arm64/mm/mmu.c
+++ b/arch/arm64/mm/mmu.c
@@ -55,6 +55,9 @@ u64 idmap_ptrs_per_pgd = PTRS_PER_PGD;
u64 kimage_voffset __ro_after_init;
EXPORT_SYMBOL(kimage_voffset);
+#ifdef CONFIG_UNMAP_KERNEL_AT_EL0
+pgd_t *new_tramp_pg_dir;
+#endif
phys_addr_t __pa_swapper_pg_dir;
pgd_t *new_swapper_pg_dir = swapper_pg_dir;
@@ -105,6 +108,25 @@ static phys_addr_t __init early_pgtable_alloc(void)
return phys;
}
+#ifdef CONFIG_UNMAP_KERNEL_AT_EL0
+static phys_addr_t __init early_pgtables_alloc(int num)
+{
+ int i;
+ phys_addr_t phys;
+ void *ptr;
+
+ phys = memblock_alloc(PAGE_SIZE * num, PAGE_SIZE);
+
+ for (i = 0; i < num; i++) {
+ ptr = pte_set_fixmap(phys + i * PAGE_SIZE);
+ memset(ptr, 0, PAGE_SIZE);
+ pte_clear_fixmap();
+ }
+
+ return phys;
+}
+#endif
+
static bool pgattr_change_is_safe(u64 old, u64 new)
{
/*
@@ -554,6 +576,10 @@ static int __init map_entry_trampoline(void)
__create_pgd_mapping(tramp_pg_dir, pa_start, TRAMP_VALIAS, PAGE_SIZE,
prot, pgd_pgtable_alloc, 0);
+ memcpy(new_tramp_pg_dir, tramp_pg_dir, PGD_SIZE);
+ memblock_free(__pa_symbol(tramp_pg_dir),
+ __pa_symbol(swapper_pg_dir) - __pa_symbol(tramp_pg_dir));
+
/* Map both the text and data into the kernel page table */
__set_fixmap(FIX_ENTRY_TRAMP_TEXT, pa_start, prot);
if (IS_ENABLED(CONFIG_RANDOMIZE_BASE)) {
@@ -631,36 +657,33 @@ static void __init map_kernel(pgd_t *pgdp)
*/
void __init paging_init(void)
{
- phys_addr_t pgd_phys = early_pgtable_alloc();
- pgd_t *pgdp = pgd_set_fixmap(pgd_phys);
+ phys_addr_t pgd_phys;
+ pgd_t *pgdp;
- __pa_swapper_pg_dir = __pa_symbol(swapper_pg_dir);
+#ifdef CONFIG_UNMAP_KERNEL_AT_EL0
+ int pages;
+ pages = (__pa_symbol(swapper_pg_dir) - __pa_symbol(tramp_pg_dir) +
+ PAGE_SIZE) >> PAGE_SHIFT;
+ pgd_phys = early_pgtables_alloc(pages);
+ new_tramp_pg_dir = __va(pgd_phys);
+ __pa_swapper_pg_dir = pgd_phys + PAGE_SIZE;
+#else
+ pgd_phys = early_pgtable_alloc();
+ __pa_swapper_pg_dir = pgd_phys;
+#endif
+ new_swapper_pg_dir = __va(__pa_swapper_pg_dir);
+
+ pgdp = pgd_set_fixmap(__pa_swapper_pg_dir);
map_kernel(pgdp);
map_mem(pgdp);
- /*
-* We want to reuse the original swapper_pg_dir so we don't have to
-* communicate the new address to non-coherent secondaries in
-* secondary_entry, and so cpu_switch_mm can generate the address with
-* adrp+add rather than a load from some global variable.
-*
-* To do this we need to go via a temporary pgd.
-*/
- cpu_replace_ttbr1(pgd_phys);
- memcpy(swapper_pg_dir, pgdp, PGD_SIZE);
cpu_replace_ttbr1(__pa_swapper_pg_dir);
+ init_mm.pgd = new_swapper_pg_dir;
pgd_clear_fixmap();
- memblock_free(pgd_phys, PAGE_SIZE);
-
- /*
-* We only reuse the PGD from the swapper_pg_dir, not the pud + pmd
-* allocated with it.
-*/
- memblock_free(__pa_symbol(swapper_pg_dir) + PAGE_SIZE,
- __pa_symbol(swapper_pg_end) - __pa_symbol(swapper_pg_dir)
- - PAGE_SIZE);
+ memblock_free(__pa_symbol(swapper_pg_dir),
+ __pa_symbol(swapper_pg_end) -
__pa_symbol(swapper_pg_dir));
}
/*
--
2.17.0
linux-next: manual merge of the block tree with the vfs tree
Hi all,
Today's linux-next merge of the block tree got a conflict in:
drivers/block/drbd/drbd_main.c
between commit:
004fd11db1d6 ("drbd: switch to proc_create_single")
from the vfs tree and commit:
5657a819a8d9 ("block drivers/block: Use octal not symbolic permissions")
from the block tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc drivers/block/drbd/drbd_main.c
index c2d154faac02,e6ec831ad472..
--- a/drivers/block/drbd/drbd_main.c
+++ b/drivers/block/drbd/drbd_main.c
@@@ -3010,8 -3010,7 +3010,8 @@@ static int __init drbd_init(void
goto fail;
err = -ENOMEM;
- drbd_proc = proc_create_single("drbd", S_IFREG | S_IRUGO , NULL,
- drbd_proc = proc_create_data("drbd", S_IFREG | 0444 , NULL,
_proc_fops, NULL);
++ drbd_proc = proc_create_single("drbd", S_IFREG | 0444 , NULL,
+ drbd_seq_show);
if (!drbd_proc) {
pr_err("unable to register proc file\n");
goto fail;
pgpl1YdX4Kt7T.pgp
Description: OpenPGP digital signature
[PATCH 2/4] migrate swapper_pg_dir
Introduce a variable to record new virtual address of
swapper_pg_dir.
---
arch/arm64/include/asm/mmu_context.h | 2 +-
arch/arm64/include/asm/pgtable.h | 1 +
arch/arm64/mm/kasan_init.c | 2 +-
arch/arm64/mm/mmu.c | 1 +
4 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/include/asm/mmu_context.h
b/arch/arm64/include/asm/mmu_context.h
index 3eddb871f251..481c2d16adeb 100644
--- a/arch/arm64/include/asm/mmu_context.h
+++ b/arch/arm64/include/asm/mmu_context.h
@@ -57,7 +57,7 @@ static inline void cpu_set_reserved_ttbr0(void)
static inline void cpu_switch_mm(pgd_t *pgd, struct mm_struct *mm)
{
- BUG_ON(pgd == swapper_pg_dir);
+ BUG_ON(pgd == new_swapper_pg_dir);
cpu_set_reserved_ttbr0();
cpu_do_switch_mm(virt_to_phys(pgd),mm);
}
diff --git a/arch/arm64/include/asm/pgtable.h b/arch/arm64/include/asm/pgtable.h
index 14ba344b1af7..7abec25cedd2 100644
--- a/arch/arm64/include/asm/pgtable.h
+++ b/arch/arm64/include/asm/pgtable.h
@@ -723,6 +723,7 @@ extern pgd_t swapper_pg_end[];
extern pgd_t idmap_pg_dir[PTRS_PER_PGD];
extern pgd_t tramp_pg_dir[PTRS_PER_PGD];
extern phys_addr_t __pa_swapper_pg_dir;
+extern pgd_t *new_swapper_pg_dir;
/*
* Encode and decode a swap entry:
diff --git a/arch/arm64/mm/kasan_init.c b/arch/arm64/mm/kasan_init.c
index dd4f28c19165..08bcaae4725e 100644
--- a/arch/arm64/mm/kasan_init.c
+++ b/arch/arm64/mm/kasan_init.c
@@ -197,7 +197,7 @@ void __init kasan_init(void)
* tmp_pg_dir used to keep early shadow mapped until full shadow
* setup will be finished.
*/
- memcpy(tmp_pg_dir, swapper_pg_dir, sizeof(tmp_pg_dir));
+ memcpy(tmp_pg_dir, new_swapper_pg_dir, sizeof(tmp_pg_dir));
dsb(ishst);
cpu_replace_ttbr1(__pa_symbol(tmp_pg_dir));
diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
index 41eee333f91a..26ba3e70a91c 100644
--- a/arch/arm64/mm/mmu.c
+++ b/arch/arm64/mm/mmu.c
@@ -56,6 +56,7 @@ u64 kimage_voffset __ro_after_init;
EXPORT_SYMBOL(kimage_voffset);
phys_addr_t __pa_swapper_pg_dir;
+pgd_t *new_swapper_pg_dir = swapper_pg_dir;
/*
* Empty_zero_page is a special page that is used for zero-initialized data
--
2.17.0
[PATCH 3/4] migrate swapper_pg_dir
Because tramp_map_kernel/tramp_unmap_kernel macro update ttbr1 by add/sub offset, so we need to migrate both swapper_pg_dir and tramp_pg_dir. Before doing that, make tramp_pg_dir and swapper_pg_dir adjacent. --- arch/arm64/kernel/entry.S | 4 ++-- arch/arm64/kernel/vmlinux.lds.S | 10 +- 2 files changed, 7 insertions(+), 7 deletions(-) diff --git a/arch/arm64/kernel/entry.S b/arch/arm64/kernel/entry.S index ec2ee720e33e..b35425feaf56 100644 --- a/arch/arm64/kernel/entry.S +++ b/arch/arm64/kernel/entry.S @@ -1004,7 +1004,7 @@ __ni_sys_trace: .macro tramp_map_kernel, tmp mrs \tmp, ttbr1_el1 - add \tmp, \tmp, #(PAGE_SIZE + RESERVED_TTBR0_SIZE) + add \tmp, \tmp, #(PAGE_SIZE) bic \tmp, \tmp, #USER_ASID_FLAG msr ttbr1_el1, \tmp #ifdef CONFIG_QCOM_FALKOR_ERRATUM_1003 @@ -1023,7 +1023,7 @@ alternative_else_nop_endif .macro tramp_unmap_kernel, tmp mrs \tmp, ttbr1_el1 - sub \tmp, \tmp, #(PAGE_SIZE + RESERVED_TTBR0_SIZE) + sub \tmp, \tmp, #(PAGE_SIZE) orr \tmp, \tmp, #USER_ASID_FLAG msr ttbr1_el1, \tmp /* diff --git a/arch/arm64/kernel/vmlinux.lds.S b/arch/arm64/kernel/vmlinux.lds.S index 0221aca6493d..a094156e05a4 100644 --- a/arch/arm64/kernel/vmlinux.lds.S +++ b/arch/arm64/kernel/vmlinux.lds.S @@ -219,15 +219,15 @@ SECTIONS idmap_pg_dir = .; . += IDMAP_DIR_SIZE; -#ifdef CONFIG_UNMAP_KERNEL_AT_EL0 - tramp_pg_dir = .; - . += PAGE_SIZE; -#endif - #ifdef CONFIG_ARM64_SW_TTBR0_PAN reserved_ttbr0 = .; . += RESERVED_TTBR0_SIZE; #endif + +#ifdef CONFIG_UNMAP_KERNEL_AT_EL0 + tramp_pg_dir = .; + . += PAGE_SIZE; +#endif swapper_pg_dir = .; . += SWAPPER_DIR_SIZE; swapper_pg_end = .; -- 2.17.0
[PATCH 3/4] migrate swapper_pg_dir
Because tramp_map_kernel/tramp_unmap_kernel macro update ttbr1 by add/sub offset, so we need to migrate both swapper_pg_dir and tramp_pg_dir. Before doing that, make tramp_pg_dir and swapper_pg_dir adjacent. --- arch/arm64/kernel/entry.S | 4 ++-- arch/arm64/kernel/vmlinux.lds.S | 10 +- 2 files changed, 7 insertions(+), 7 deletions(-) diff --git a/arch/arm64/kernel/entry.S b/arch/arm64/kernel/entry.S index ec2ee720e33e..b35425feaf56 100644 --- a/arch/arm64/kernel/entry.S +++ b/arch/arm64/kernel/entry.S @@ -1004,7 +1004,7 @@ __ni_sys_trace: .macro tramp_map_kernel, tmp mrs \tmp, ttbr1_el1 - add \tmp, \tmp, #(PAGE_SIZE + RESERVED_TTBR0_SIZE) + add \tmp, \tmp, #(PAGE_SIZE) bic \tmp, \tmp, #USER_ASID_FLAG msr ttbr1_el1, \tmp #ifdef CONFIG_QCOM_FALKOR_ERRATUM_1003 @@ -1023,7 +1023,7 @@ alternative_else_nop_endif .macro tramp_unmap_kernel, tmp mrs \tmp, ttbr1_el1 - sub \tmp, \tmp, #(PAGE_SIZE + RESERVED_TTBR0_SIZE) + sub \tmp, \tmp, #(PAGE_SIZE) orr \tmp, \tmp, #USER_ASID_FLAG msr ttbr1_el1, \tmp /* diff --git a/arch/arm64/kernel/vmlinux.lds.S b/arch/arm64/kernel/vmlinux.lds.S index 0221aca6493d..a094156e05a4 100644 --- a/arch/arm64/kernel/vmlinux.lds.S +++ b/arch/arm64/kernel/vmlinux.lds.S @@ -219,15 +219,15 @@ SECTIONS idmap_pg_dir = .; . += IDMAP_DIR_SIZE; -#ifdef CONFIG_UNMAP_KERNEL_AT_EL0 - tramp_pg_dir = .; - . += PAGE_SIZE; -#endif - #ifdef CONFIG_ARM64_SW_TTBR0_PAN reserved_ttbr0 = .; . += RESERVED_TTBR0_SIZE; #endif + +#ifdef CONFIG_UNMAP_KERNEL_AT_EL0 + tramp_pg_dir = .; + . += PAGE_SIZE; +#endif swapper_pg_dir = .; . += SWAPPER_DIR_SIZE; swapper_pg_end = .; -- 2.17.0
[PATCH 1/4] migrate swapper_pg_dir
Currently, __enable_mmu() uses swapper_pg_dir directly.
To migrate swapper_pg_dir, we need to pass it as an
argument to __enable_mmu(). At the same time,
__pa_swapper_pg_dir is introduced to save physical
address of swapper_pg_dir. By changing its value, we
can migrate swapper_pg_dir.
---
arch/arm64/include/asm/mmu_context.h | 4 +---
arch/arm64/include/asm/pgtable.h | 1 +
arch/arm64/kernel/cpufeature.c | 2 +-
arch/arm64/kernel/head.S | 10 ++
arch/arm64/kernel/hibernate.c| 2 +-
arch/arm64/kernel/sleep.S| 2 ++
arch/arm64/mm/kasan_init.c | 4 ++--
arch/arm64/mm/mmu.c | 8 ++--
8 files changed, 20 insertions(+), 13 deletions(-)
diff --git a/arch/arm64/include/asm/mmu_context.h
b/arch/arm64/include/asm/mmu_context.h
index 39ec0b8a689e..3eddb871f251 100644
--- a/arch/arm64/include/asm/mmu_context.h
+++ b/arch/arm64/include/asm/mmu_context.h
@@ -141,14 +141,12 @@ static inline void cpu_install_idmap(void)
* Atomically replaces the active TTBR1_EL1 PGD with a new VA-compatible PGD,
* avoiding the possibility of conflicting TLB entries being allocated.
*/
-static inline void cpu_replace_ttbr1(pgd_t *pgdp)
+static inline void cpu_replace_ttbr1(phys_addr_t pgd_phys)
{
typedef void (ttbr_replace_func)(phys_addr_t);
extern ttbr_replace_func idmap_cpu_replace_ttbr1;
ttbr_replace_func *replace_phys;
- phys_addr_t pgd_phys = virt_to_phys(pgdp);
-
replace_phys = (void *)__pa_symbol(idmap_cpu_replace_ttbr1);
cpu_install_idmap();
diff --git a/arch/arm64/include/asm/pgtable.h b/arch/arm64/include/asm/pgtable.h
index 7c4c8f318ba9..14ba344b1af7 100644
--- a/arch/arm64/include/asm/pgtable.h
+++ b/arch/arm64/include/asm/pgtable.h
@@ -722,6 +722,7 @@ extern pgd_t swapper_pg_dir[PTRS_PER_PGD];
extern pgd_t swapper_pg_end[];
extern pgd_t idmap_pg_dir[PTRS_PER_PGD];
extern pgd_t tramp_pg_dir[PTRS_PER_PGD];
+extern phys_addr_t __pa_swapper_pg_dir;
/*
* Encode and decode a swap entry:
diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
index 9d1b06d67c53..5b9448688d80 100644
--- a/arch/arm64/kernel/cpufeature.c
+++ b/arch/arm64/kernel/cpufeature.c
@@ -917,7 +917,7 @@ kpti_install_ng_mappings(const struct
arm64_cpu_capabilities *__unused)
remap_fn = (void *)__pa_symbol(idmap_kpti_install_ng_mappings);
cpu_install_idmap();
- remap_fn(cpu, num_online_cpus(), __pa_symbol(swapper_pg_dir));
+ remap_fn(cpu, num_online_cpus(), __pa_swapper_pg_dir);
cpu_uninstall_idmap();
if (!cpu)
diff --git a/arch/arm64/kernel/head.S b/arch/arm64/kernel/head.S
index b0853069702f..e3bb44b4b6c6 100644
--- a/arch/arm64/kernel/head.S
+++ b/arch/arm64/kernel/head.S
@@ -706,6 +706,8 @@ secondary_startup:
* Common entry point for secondary CPUs.
*/
bl __cpu_setup // initialise processor
+ adrpx25, idmap_pg_dir
+ ldr_l x26, __pa_swapper_pg_dir
bl __enable_mmu
ldr x8, =__secondary_switched
br x8
@@ -761,10 +763,8 @@ ENTRY(__enable_mmu)
cmp x2, #ID_AA64MMFR0_TGRAN_SUPPORTED
b.ne__no_granule_support
update_early_cpu_boot_status 0, x1, x2
- adrpx1, idmap_pg_dir
- adrpx2, swapper_pg_dir
- phys_to_ttbr x3, x1
- phys_to_ttbr x4, x2
+ phys_to_ttbr x3, x25
+ phys_to_ttbr x4, x26
msr ttbr0_el1, x3 // load TTBR0
msr ttbr1_el1, x4 // load TTBR1
isb
@@ -823,6 +823,8 @@ __primary_switch:
mrs x20, sctlr_el1 // preserve old SCTLR_EL1 value
#endif
+ adrpx25, idmap_pg_dir
+ adrpx26, swapper_pg_dir
bl __enable_mmu
#ifdef CONFIG_RELOCATABLE
bl __relocate_kernel
diff --git a/arch/arm64/kernel/hibernate.c b/arch/arm64/kernel/hibernate.c
index 1ec5f28c39fc..12948949202c 100644
--- a/arch/arm64/kernel/hibernate.c
+++ b/arch/arm64/kernel/hibernate.c
@@ -125,7 +125,7 @@ int arch_hibernation_header_save(void *addr, unsigned int
max_size)
return -EOVERFLOW;
arch_hdr_invariants(>invariants);
- hdr->ttbr1_el1 = __pa_symbol(swapper_pg_dir);
+ hdr->ttbr1_el1 = __pa_swapper_pg_dir;
hdr->reenter_kernel = _cpu_resume;
/* We can't use __hyp_get_vectors() because kvm may still be loaded */
diff --git a/arch/arm64/kernel/sleep.S b/arch/arm64/kernel/sleep.S
index bebec8ef9372..860d46395be1 100644
--- a/arch/arm64/kernel/sleep.S
+++ b/arch/arm64/kernel/sleep.S
@@ -101,6 +101,8 @@ ENTRY(cpu_resume)
bl el2_setup // if in EL2 drop to EL1 cleanly
bl __cpu_setup
/* enable the MMU early - so we can access sleep_save_stash by va */
+ adrpx25, idmap_pg_dir
+ ldr_l x26, __pa_swapper_pg_dir
bl
[PATCH 1/4] migrate swapper_pg_dir
Currently, __enable_mmu() uses swapper_pg_dir directly.
To migrate swapper_pg_dir, we need to pass it as an
argument to __enable_mmu(). At the same time,
__pa_swapper_pg_dir is introduced to save physical
address of swapper_pg_dir. By changing its value, we
can migrate swapper_pg_dir.
---
arch/arm64/include/asm/mmu_context.h | 4 +---
arch/arm64/include/asm/pgtable.h | 1 +
arch/arm64/kernel/cpufeature.c | 2 +-
arch/arm64/kernel/head.S | 10 ++
arch/arm64/kernel/hibernate.c| 2 +-
arch/arm64/kernel/sleep.S| 2 ++
arch/arm64/mm/kasan_init.c | 4 ++--
arch/arm64/mm/mmu.c | 8 ++--
8 files changed, 20 insertions(+), 13 deletions(-)
diff --git a/arch/arm64/include/asm/mmu_context.h
b/arch/arm64/include/asm/mmu_context.h
index 39ec0b8a689e..3eddb871f251 100644
--- a/arch/arm64/include/asm/mmu_context.h
+++ b/arch/arm64/include/asm/mmu_context.h
@@ -141,14 +141,12 @@ static inline void cpu_install_idmap(void)
* Atomically replaces the active TTBR1_EL1 PGD with a new VA-compatible PGD,
* avoiding the possibility of conflicting TLB entries being allocated.
*/
-static inline void cpu_replace_ttbr1(pgd_t *pgdp)
+static inline void cpu_replace_ttbr1(phys_addr_t pgd_phys)
{
typedef void (ttbr_replace_func)(phys_addr_t);
extern ttbr_replace_func idmap_cpu_replace_ttbr1;
ttbr_replace_func *replace_phys;
- phys_addr_t pgd_phys = virt_to_phys(pgdp);
-
replace_phys = (void *)__pa_symbol(idmap_cpu_replace_ttbr1);
cpu_install_idmap();
diff --git a/arch/arm64/include/asm/pgtable.h b/arch/arm64/include/asm/pgtable.h
index 7c4c8f318ba9..14ba344b1af7 100644
--- a/arch/arm64/include/asm/pgtable.h
+++ b/arch/arm64/include/asm/pgtable.h
@@ -722,6 +722,7 @@ extern pgd_t swapper_pg_dir[PTRS_PER_PGD];
extern pgd_t swapper_pg_end[];
extern pgd_t idmap_pg_dir[PTRS_PER_PGD];
extern pgd_t tramp_pg_dir[PTRS_PER_PGD];
+extern phys_addr_t __pa_swapper_pg_dir;
/*
* Encode and decode a swap entry:
diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
index 9d1b06d67c53..5b9448688d80 100644
--- a/arch/arm64/kernel/cpufeature.c
+++ b/arch/arm64/kernel/cpufeature.c
@@ -917,7 +917,7 @@ kpti_install_ng_mappings(const struct
arm64_cpu_capabilities *__unused)
remap_fn = (void *)__pa_symbol(idmap_kpti_install_ng_mappings);
cpu_install_idmap();
- remap_fn(cpu, num_online_cpus(), __pa_symbol(swapper_pg_dir));
+ remap_fn(cpu, num_online_cpus(), __pa_swapper_pg_dir);
cpu_uninstall_idmap();
if (!cpu)
diff --git a/arch/arm64/kernel/head.S b/arch/arm64/kernel/head.S
index b0853069702f..e3bb44b4b6c6 100644
--- a/arch/arm64/kernel/head.S
+++ b/arch/arm64/kernel/head.S
@@ -706,6 +706,8 @@ secondary_startup:
* Common entry point for secondary CPUs.
*/
bl __cpu_setup // initialise processor
+ adrpx25, idmap_pg_dir
+ ldr_l x26, __pa_swapper_pg_dir
bl __enable_mmu
ldr x8, =__secondary_switched
br x8
@@ -761,10 +763,8 @@ ENTRY(__enable_mmu)
cmp x2, #ID_AA64MMFR0_TGRAN_SUPPORTED
b.ne__no_granule_support
update_early_cpu_boot_status 0, x1, x2
- adrpx1, idmap_pg_dir
- adrpx2, swapper_pg_dir
- phys_to_ttbr x3, x1
- phys_to_ttbr x4, x2
+ phys_to_ttbr x3, x25
+ phys_to_ttbr x4, x26
msr ttbr0_el1, x3 // load TTBR0
msr ttbr1_el1, x4 // load TTBR1
isb
@@ -823,6 +823,8 @@ __primary_switch:
mrs x20, sctlr_el1 // preserve old SCTLR_EL1 value
#endif
+ adrpx25, idmap_pg_dir
+ adrpx26, swapper_pg_dir
bl __enable_mmu
#ifdef CONFIG_RELOCATABLE
bl __relocate_kernel
diff --git a/arch/arm64/kernel/hibernate.c b/arch/arm64/kernel/hibernate.c
index 1ec5f28c39fc..12948949202c 100644
--- a/arch/arm64/kernel/hibernate.c
+++ b/arch/arm64/kernel/hibernate.c
@@ -125,7 +125,7 @@ int arch_hibernation_header_save(void *addr, unsigned int
max_size)
return -EOVERFLOW;
arch_hdr_invariants(>invariants);
- hdr->ttbr1_el1 = __pa_symbol(swapper_pg_dir);
+ hdr->ttbr1_el1 = __pa_swapper_pg_dir;
hdr->reenter_kernel = _cpu_resume;
/* We can't use __hyp_get_vectors() because kvm may still be loaded */
diff --git a/arch/arm64/kernel/sleep.S b/arch/arm64/kernel/sleep.S
index bebec8ef9372..860d46395be1 100644
--- a/arch/arm64/kernel/sleep.S
+++ b/arch/arm64/kernel/sleep.S
@@ -101,6 +101,8 @@ ENTRY(cpu_resume)
bl el2_setup // if in EL2 drop to EL1 cleanly
bl __cpu_setup
/* enable the MMU early - so we can access sleep_save_stash by va */
+ adrpx25, idmap_pg_dir
+ ldr_l x26, __pa_swapper_pg_dir
bl
Re: [PATCH] remoteproc: Add APSS based Qualcomm ADSP PIL driver for SDM845
On Wed 23 May 22:18 PDT 2018, Rohit Kumar wrote:
> Thanks Bjorn for reviewing.
>
>
> On 5/23/2018 11:56 AM, Bjorn Andersson wrote:
> > On Sun 13 May 00:01 PDT 2018, Rohit kumar wrote:
> >
> > > --- a/Documentation/devicetree/bindings/remoteproc/qcom,adsp.txt
> > > +++ b/Documentation/devicetree/bindings/remoteproc/qcom,adsp.txt
> > > @@ -10,6 +10,7 @@ on the Qualcomm ADSP Hexagon core.
> > > "qcom,msm8974-adsp-pil"
> > > "qcom,msm8996-adsp-pil"
> > > "qcom,msm8996-slpi-pil"
> > > + "qcom,sdm845-apss-adsp-pil"
> > Afaict there's nothing in this binding that ties this to the apss, so I
> > don't think we should base the compatible on this. The differentiation
> > is PAS vs non-PAS; so let's start naming the PAS variants
> > "qcom,platform-subsystem-pas" and the non-PAS
> > "qcom,platform-subsystem-pil" instead.
> >
> > I.e. please make this "qcom,sdm845-adsp-pil".
> >
> > More importantly, any resources such as clocks or reset lines should
> > come from DT and as such you need to extend the binding quite a bit -
> > which I suggest you do by introducing a new binding document.
> Sure. Will create new dt-binding document with clocks and reset driver info
> added for sdm845 PIL.
>
> > > - interrupts-extended:
> > > Usage: required
> > > diff --git a/drivers/remoteproc/Makefile b/drivers/remoteproc/Makefile
> > > index 02627ed..759831b 100644
> > > --- a/drivers/remoteproc/Makefile
> > > +++ b/drivers/remoteproc/Makefile
> > > @@ -14,7 +14,8 @@ obj-$(CONFIG_OMAP_REMOTEPROC) +=
> > > omap_remoteproc.o
> > > obj-$(CONFIG_WKUP_M3_RPROC) += wkup_m3_rproc.o
> > > obj-$(CONFIG_DA8XX_REMOTEPROC) += da8xx_remoteproc.o
> > > obj-$(CONFIG_KEYSTONE_REMOTEPROC) += keystone_remoteproc.o
> > > -obj-$(CONFIG_QCOM_ADSP_PIL) += qcom_adsp_pil.o
> > > +obj-$(CONFIG_QCOM_ADSP_PIL) += qcom_adsp.o
> > > +qcom_adsp-objs += qcom_adsp_pil.o
> > > qcom_adsp_pil_sdm845.o
> > > obj-$(CONFIG_QCOM_RPROC_COMMON) += qcom_common.o
> > > obj-$(CONFIG_QCOM_Q6V5_PIL) += qcom_q6v5_pil.o
> > > obj-$(CONFIG_QCOM_SYSMON) += qcom_sysmon.o
> > > diff --git a/drivers/remoteproc/qcom_adsp_pil.c
> > > b/drivers/remoteproc/qcom_adsp_pil.c
> > I get the feeling that the main reason for modifying this file is its
> > name, not that it reduces the complexity of the final solution. I
> > definitely think it's cleaner to have some structural duplication and
> > keep this driver handling the various PAS based remoteprocs.
> The main intention was to re-use exisiting APIs in PAS based PIL
> driver as the major change was w.r.t. start and stop of ADSP firmware.
> Load(), interrupt handling and few other APIs will be same as done in
> exisiting PAS based PIL driver.
A very good intention, I just think it's good to keep the PAS driver
only dealing with PAS targets and work on reducing the duplication in
other ways; keeping the logic as simple as possible.
> > Please see the RFC series I posted reducing the duplication between the
> > various "Q6V5 drivers".
> I went through the RFC. Our code will fit into the design. However, we
> will still have some amount of code duplication between PAS and
> Non-PAS ADSP PIL driver. Will this be fine?
I'm sorry for not finding the time to provide you this feedback earlier.
> Please suggest.
> Will wait for your response whether to write complete new driver or reuse
> exisitng one.
>
For the Hexagon based non-PAS WCSS remoteproc in IPQ8074 we're creating
a new driver [1], in doing so I extracted some common helper functions
that reduces the duplication between the drivers and there are a few
more things on the way (e.g. reduce the code needed to deal with
memory-regions).
Please have a look at either extending this (non-PAS, non-MSA) driver to
cover the ADSP as well. It's hard for me to see how the exact details
will look after extracting the clocks and resets to their appropriate
drivers, if it doesn't fit the details we should work further on making
sure frameworks and helper functions reduces the logical duplication
between drivers.
[1] https://patchwork.kernel.org/patch/10420185/
> > [..]
> > > diff --git a/drivers/remoteproc/qcom_adsp_pil.h
> > > b/drivers/remoteproc/qcom_adsp_pil.h
> > [..]
> > > +static inline void update_bits(void *reg, u32 mask_val, u32 set_val, u32
> > > shift)
> > > +{
> > > + u32 reg_val = 0;
> > > +
> > > + reg_val = ((readl(reg)) & ~mask_val) | ((set_val << shift) & mask_val);
> > > + writel(reg_val, reg);
> > > +}
> > > +
> > > +static inline unsigned int read_bit(void *reg, u32 mask, int shift)
> > > +{
> > > + return ((readl(reg) & mask) >> shift);
> > > +}
> > I don't like these helper functions, their prototype is nonstandard and
> > makes it really hard to read all the calling code.
> >
> > I would prefer if you just inline the operations directly,
Re: [LKP] [lkp-robot] [mm, memcontrol] 309fe96bfc: vm-scalability.throughput +23.0% improvement
On Mon, 2018-05-28 at 14:03 +0200, Michal Hocko wrote:
> On Mon 28-05-18 19:40:19, kernel test robot wrote:
> >
> > Greeting,
> >
> > FYI, we noticed a +23.0% improvement of vm-scalability.throughput due to
> > commit:
> >
> >
> > commit: 309fe96bfc0ae387f53612927a8f0dc3eb056efd ("mm, memcontrol:
> > implement memory.swap.events")
> > https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git master
>
> This doesn't make any sense to me. The patch merely adds an accounting.
> It doesn't optimize anything. So I strongly suspect the result is just
> misleading or the test (environment) misconfigured. Not the first time
> I am seeing something like that I am afraid.
>
Most likely the same situation as:
"
FYI, we noticed a -27.2% regression of will-it-scale.per_process_ops
due to commit:
commit: e27be240df53f1a20c659168e722b5d9f16cc7f4 ("mm: memcg: make sure
memory.events is uptodate when waking pollers")
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git master
"
Where the performance change is due to layout change of
'struct mem_cgroup':
http://lkml.kernel.org/r/20180528085201.ga2...@intel.com
Re: [PATCH] remoteproc: Add APSS based Qualcomm ADSP PIL driver for SDM845
On Wed 23 May 22:18 PDT 2018, Rohit Kumar wrote:
> Thanks Bjorn for reviewing.
>
>
> On 5/23/2018 11:56 AM, Bjorn Andersson wrote:
> > On Sun 13 May 00:01 PDT 2018, Rohit kumar wrote:
> >
> > > --- a/Documentation/devicetree/bindings/remoteproc/qcom,adsp.txt
> > > +++ b/Documentation/devicetree/bindings/remoteproc/qcom,adsp.txt
> > > @@ -10,6 +10,7 @@ on the Qualcomm ADSP Hexagon core.
> > > "qcom,msm8974-adsp-pil"
> > > "qcom,msm8996-adsp-pil"
> > > "qcom,msm8996-slpi-pil"
> > > + "qcom,sdm845-apss-adsp-pil"
> > Afaict there's nothing in this binding that ties this to the apss, so I
> > don't think we should base the compatible on this. The differentiation
> > is PAS vs non-PAS; so let's start naming the PAS variants
> > "qcom,platform-subsystem-pas" and the non-PAS
> > "qcom,platform-subsystem-pil" instead.
> >
> > I.e. please make this "qcom,sdm845-adsp-pil".
> >
> > More importantly, any resources such as clocks or reset lines should
> > come from DT and as such you need to extend the binding quite a bit -
> > which I suggest you do by introducing a new binding document.
> Sure. Will create new dt-binding document with clocks and reset driver info
> added for sdm845 PIL.
>
> > > - interrupts-extended:
> > > Usage: required
> > > diff --git a/drivers/remoteproc/Makefile b/drivers/remoteproc/Makefile
> > > index 02627ed..759831b 100644
> > > --- a/drivers/remoteproc/Makefile
> > > +++ b/drivers/remoteproc/Makefile
> > > @@ -14,7 +14,8 @@ obj-$(CONFIG_OMAP_REMOTEPROC) +=
> > > omap_remoteproc.o
> > > obj-$(CONFIG_WKUP_M3_RPROC) += wkup_m3_rproc.o
> > > obj-$(CONFIG_DA8XX_REMOTEPROC) += da8xx_remoteproc.o
> > > obj-$(CONFIG_KEYSTONE_REMOTEPROC) += keystone_remoteproc.o
> > > -obj-$(CONFIG_QCOM_ADSP_PIL) += qcom_adsp_pil.o
> > > +obj-$(CONFIG_QCOM_ADSP_PIL) += qcom_adsp.o
> > > +qcom_adsp-objs += qcom_adsp_pil.o
> > > qcom_adsp_pil_sdm845.o
> > > obj-$(CONFIG_QCOM_RPROC_COMMON) += qcom_common.o
> > > obj-$(CONFIG_QCOM_Q6V5_PIL) += qcom_q6v5_pil.o
> > > obj-$(CONFIG_QCOM_SYSMON) += qcom_sysmon.o
> > > diff --git a/drivers/remoteproc/qcom_adsp_pil.c
> > > b/drivers/remoteproc/qcom_adsp_pil.c
> > I get the feeling that the main reason for modifying this file is its
> > name, not that it reduces the complexity of the final solution. I
> > definitely think it's cleaner to have some structural duplication and
> > keep this driver handling the various PAS based remoteprocs.
> The main intention was to re-use exisiting APIs in PAS based PIL
> driver as the major change was w.r.t. start and stop of ADSP firmware.
> Load(), interrupt handling and few other APIs will be same as done in
> exisiting PAS based PIL driver.
A very good intention, I just think it's good to keep the PAS driver
only dealing with PAS targets and work on reducing the duplication in
other ways; keeping the logic as simple as possible.
> > Please see the RFC series I posted reducing the duplication between the
> > various "Q6V5 drivers".
> I went through the RFC. Our code will fit into the design. However, we
> will still have some amount of code duplication between PAS and
> Non-PAS ADSP PIL driver. Will this be fine?
I'm sorry for not finding the time to provide you this feedback earlier.
> Please suggest.
> Will wait for your response whether to write complete new driver or reuse
> exisitng one.
>
For the Hexagon based non-PAS WCSS remoteproc in IPQ8074 we're creating
a new driver [1], in doing so I extracted some common helper functions
that reduces the duplication between the drivers and there are a few
more things on the way (e.g. reduce the code needed to deal with
memory-regions).
Please have a look at either extending this (non-PAS, non-MSA) driver to
cover the ADSP as well. It's hard for me to see how the exact details
will look after extracting the clocks and resets to their appropriate
drivers, if it doesn't fit the details we should work further on making
sure frameworks and helper functions reduces the logical duplication
between drivers.
[1] https://patchwork.kernel.org/patch/10420185/
> > [..]
> > > diff --git a/drivers/remoteproc/qcom_adsp_pil.h
> > > b/drivers/remoteproc/qcom_adsp_pil.h
> > [..]
> > > +static inline void update_bits(void *reg, u32 mask_val, u32 set_val, u32
> > > shift)
> > > +{
> > > + u32 reg_val = 0;
> > > +
> > > + reg_val = ((readl(reg)) & ~mask_val) | ((set_val << shift) & mask_val);
> > > + writel(reg_val, reg);
> > > +}
> > > +
> > > +static inline unsigned int read_bit(void *reg, u32 mask, int shift)
> > > +{
> > > + return ((readl(reg) & mask) >> shift);
> > > +}
> > I don't like these helper functions, their prototype is nonstandard and
> > makes it really hard to read all the calling code.
> >
> > I would prefer if you just inline the operations directly,
Re: [LKP] [lkp-robot] [mm, memcontrol] 309fe96bfc: vm-scalability.throughput +23.0% improvement
On Mon, 2018-05-28 at 14:03 +0200, Michal Hocko wrote:
> On Mon 28-05-18 19:40:19, kernel test robot wrote:
> >
> > Greeting,
> >
> > FYI, we noticed a +23.0% improvement of vm-scalability.throughput due to
> > commit:
> >
> >
> > commit: 309fe96bfc0ae387f53612927a8f0dc3eb056efd ("mm, memcontrol:
> > implement memory.swap.events")
> > https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git master
>
> This doesn't make any sense to me. The patch merely adds an accounting.
> It doesn't optimize anything. So I strongly suspect the result is just
> misleading or the test (environment) misconfigured. Not the first time
> I am seeing something like that I am afraid.
>
Most likely the same situation as:
"
FYI, we noticed a -27.2% regression of will-it-scale.per_process_ops
due to commit:
commit: e27be240df53f1a20c659168e722b5d9f16cc7f4 ("mm: memcg: make sure
memory.events is uptodate when waking pollers")
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git master
"
Where the performance change is due to layout change of
'struct mem_cgroup':
http://lkml.kernel.org/r/20180528085201.ga2...@intel.com
linux-next: manual merge of the block tree with the vfs tree
Hi all,
Today's linux-next merge of the block tree got a conflict in:
drivers/block/DAC960.c
between commit:
3f3942aca6da ("proc: introduce proc_create_single{,_data}")
from the vfs tree and commit:
5657a819a8d9 ("block drivers/block: Use octal not symbolic permissions")
from the block tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc drivers/block/DAC960.c
index 6918c3d9482e,7c3887a7e534..
--- a/drivers/block/DAC960.c
+++ b/drivers/block/DAC960.c
@@@ -6553,11 -6587,9 +6548,11 @@@ static void DAC960_CreateProcEntries(DA
"c%d", Controller->ControllerNumber);
ControllerProcEntry = proc_mkdir(Controller->ControllerName,
DAC960_ProcDirectoryEntry);
- proc_create_data("initial_status", 0, ControllerProcEntry,
_initial_status_proc_fops, Controller);
- proc_create_data("current_status", 0, ControllerProcEntry,
_current_status_proc_fops, Controller);
+ proc_create_single_data("initial_status", 0, ControllerProcEntry,
+ dac960_initial_status_proc_show, Controller);
+ proc_create_single_data("current_status", 0, ControllerProcEntry,
+ dac960_current_status_proc_show, Controller);
- proc_create_data("user_command", S_IWUSR | S_IRUSR,
ControllerProcEntry, _user_command_proc_fops, Controller);
+ proc_create_data("user_command", 0600, ControllerProcEntry,
_user_command_proc_fops, Controller);
Controller->ControllerProcEntry = ControllerProcEntry;
}
pgpaqkplpnzMA.pgp
Description: OpenPGP digital signature
linux-next: manual merge of the block tree with the vfs tree
Hi all,
Today's linux-next merge of the block tree got a conflict in:
drivers/block/DAC960.c
between commit:
3f3942aca6da ("proc: introduce proc_create_single{,_data}")
from the vfs tree and commit:
5657a819a8d9 ("block drivers/block: Use octal not symbolic permissions")
from the block tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc drivers/block/DAC960.c
index 6918c3d9482e,7c3887a7e534..
--- a/drivers/block/DAC960.c
+++ b/drivers/block/DAC960.c
@@@ -6553,11 -6587,9 +6548,11 @@@ static void DAC960_CreateProcEntries(DA
"c%d", Controller->ControllerNumber);
ControllerProcEntry = proc_mkdir(Controller->ControllerName,
DAC960_ProcDirectoryEntry);
- proc_create_data("initial_status", 0, ControllerProcEntry,
_initial_status_proc_fops, Controller);
- proc_create_data("current_status", 0, ControllerProcEntry,
_current_status_proc_fops, Controller);
+ proc_create_single_data("initial_status", 0, ControllerProcEntry,
+ dac960_initial_status_proc_show, Controller);
+ proc_create_single_data("current_status", 0, ControllerProcEntry,
+ dac960_current_status_proc_show, Controller);
- proc_create_data("user_command", S_IWUSR | S_IRUSR,
ControllerProcEntry, _user_command_proc_fops, Controller);
+ proc_create_data("user_command", 0600, ControllerProcEntry,
_user_command_proc_fops, Controller);
Controller->ControllerProcEntry = ControllerProcEntry;
}
pgpaqkplpnzMA.pgp
Description: OpenPGP digital signature
Re: [PATCH] remoteproc: qcom_q6v5: don't auto boot remote processor
On Thu 24 May 12:21 PDT 2018, Ramon Fried wrote: > Sometimes that rmtfs userspace module is not brought > up fast enough and the modem crashes. > disabling automated boot in the driver and triggering > the boot from user-space sovles the problem. > > Signed-off-by: Ramon Fried Thanks for your patch Ramon. While this nudges the behavior to make things work slightly better I think we need to describe the explicit dependency between the mss firmware and the existence of rmtfs. As our remoteprocs are essentially always-on I would prefer that they start "automatically" and not through use of the sysfs interface. But we're at the point where this is a real problem on 410, 820 and 845, so we have to come up with some way to tie these pieces together. If your patch suits that solution I will happily take it. Regards, Bjorn > --- > drivers/remoteproc/qcom_q6v5_pil.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/drivers/remoteproc/qcom_q6v5_pil.c > b/drivers/remoteproc/qcom_q6v5_pil.c > index cbbafdcaaecb..719ee96445b3 100644 > --- a/drivers/remoteproc/qcom_q6v5_pil.c > +++ b/drivers/remoteproc/qcom_q6v5_pil.c > @@ -1133,6 +1133,8 @@ static int q6v5_probe(struct platform_device *pdev) > return -ENOMEM; > } > > + rproc->auto_boot = false; > + > qproc = (struct q6v5 *)rproc->priv; > qproc->dev = >dev; > qproc->rproc = rproc; > -- > 2.17.0 >
Re: [PATCH] remoteproc: qcom_q6v5: don't auto boot remote processor
On Thu 24 May 12:21 PDT 2018, Ramon Fried wrote: > Sometimes that rmtfs userspace module is not brought > up fast enough and the modem crashes. > disabling automated boot in the driver and triggering > the boot from user-space sovles the problem. > > Signed-off-by: Ramon Fried Thanks for your patch Ramon. While this nudges the behavior to make things work slightly better I think we need to describe the explicit dependency between the mss firmware and the existence of rmtfs. As our remoteprocs are essentially always-on I would prefer that they start "automatically" and not through use of the sysfs interface. But we're at the point where this is a real problem on 410, 820 and 845, so we have to come up with some way to tie these pieces together. If your patch suits that solution I will happily take it. Regards, Bjorn > --- > drivers/remoteproc/qcom_q6v5_pil.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/drivers/remoteproc/qcom_q6v5_pil.c > b/drivers/remoteproc/qcom_q6v5_pil.c > index cbbafdcaaecb..719ee96445b3 100644 > --- a/drivers/remoteproc/qcom_q6v5_pil.c > +++ b/drivers/remoteproc/qcom_q6v5_pil.c > @@ -1133,6 +1133,8 @@ static int q6v5_probe(struct platform_device *pdev) > return -ENOMEM; > } > > + rproc->auto_boot = false; > + > qproc = (struct q6v5 *)rproc->priv; > qproc->dev = >dev; > qproc->rproc = rproc; > -- > 2.17.0 >
Re: Why is the length of max mount option a page size??
On Tue, May 29, 2018 at 02:14:12AM +0100, Al Viro wrote: > On Tue, May 29, 2018 at 09:24:56AM +0900, Jungsub Shin wrote: > > Mount command : mount -t aufs -o > >
Re: Why is the length of max mount option a page size??
On Tue, May 29, 2018 at 02:14:12AM +0100, Al Viro wrote: > On Tue, May 29, 2018 at 09:24:56AM +0900, Jungsub Shin wrote: > > Mount command : mount -t aufs -o > >
Re: [PATCH net-next 00/12] Misc. bug fixes & some minor additions to HNS3 driver
From: Salil Mehta Date: Fri, 25 May 2018 19:42:55 +0100 > This patch-set provides some bug fixes figured out during testing > and review. It also provides some additions due to running of the > existing code on the new revision of the HNS3 hardware. Series applied.
Re: [RFC PATCH 5/5] remoteproc: qcom: Introduce Hexagon V5 based WCSS driver
On Wed 23 May 07:48 PDT 2018, Sricharan R wrote: > On 5/23/2018 1:07 PM, Vinod wrote: > > On 22-05-18, 23:58, Bjorn Andersson wrote: > >> On Tue 22 May 23:05 PDT 2018, Vinod wrote: > >>> On 22-05-18, 22:20, Bjorn Andersson wrote: [..] > >>> Looking at the patch, few other comments would be applicable too, so > >>> would be > >>> great if you/Sricharan can update this > >>> > >> > >> I agree, the primary purpose of this patch was rather to get feedback on > >> the structure of the drivers, I do expect this to take another round > >> through the editor to get some polishing touches. Sorry if this wasn't > >> clear from the description. > > > > Since Sricharan replied to comments, I though they would be fixed. Yeah > > this is > > fine from RFC.. > > > > Thanks for this. > > Tested this on ipq8074 and wcss rproc is up with this. > > Tested-by: Sricharan R > Thanks Sricharan! > So regarding the cleanup, as i see, this consolidates the code much better. > > so about the point of avoiding duplication for soc specific functions like > qcv5_wcss_reset common between qcv5_wcss and qcv5_pil drivers as done in my > series, with a second thought that feels it might be difficult to maintain > in the longer run. Since the sequences are specific to each soc and for now > although some part of it is common, for a minor update in one soc, common > code needs to reworked every time and tested on all boards that share them. > > So feels like having the duplication for hw init sequences is the cleaner > way. > Sounds good, then let's go with this approach! > Apart from that for other comments on the q6v5 wcss driver, i can address > them > on this final patch that you have posted and same can be included in your > next version. Please let me know how you want to go about it. > If you can help me review the first 4 patches and fix up and resend the 5th that would be greatly appreciated. Regards, Bjorn
Re: [PATCH net-next 00/12] Misc. bug fixes & some minor additions to HNS3 driver
From: Salil Mehta Date: Fri, 25 May 2018 19:42:55 +0100 > This patch-set provides some bug fixes figured out during testing > and review. It also provides some additions due to running of the > existing code on the new revision of the HNS3 hardware. Series applied.
Re: [RFC PATCH 5/5] remoteproc: qcom: Introduce Hexagon V5 based WCSS driver
On Wed 23 May 07:48 PDT 2018, Sricharan R wrote: > On 5/23/2018 1:07 PM, Vinod wrote: > > On 22-05-18, 23:58, Bjorn Andersson wrote: > >> On Tue 22 May 23:05 PDT 2018, Vinod wrote: > >>> On 22-05-18, 22:20, Bjorn Andersson wrote: [..] > >>> Looking at the patch, few other comments would be applicable too, so > >>> would be > >>> great if you/Sricharan can update this > >>> > >> > >> I agree, the primary purpose of this patch was rather to get feedback on > >> the structure of the drivers, I do expect this to take another round > >> through the editor to get some polishing touches. Sorry if this wasn't > >> clear from the description. > > > > Since Sricharan replied to comments, I though they would be fixed. Yeah > > this is > > fine from RFC.. > > > > Thanks for this. > > Tested this on ipq8074 and wcss rproc is up with this. > > Tested-by: Sricharan R > Thanks Sricharan! > So regarding the cleanup, as i see, this consolidates the code much better. > > so about the point of avoiding duplication for soc specific functions like > qcv5_wcss_reset common between qcv5_wcss and qcv5_pil drivers as done in my > series, with a second thought that feels it might be difficult to maintain > in the longer run. Since the sequences are specific to each soc and for now > although some part of it is common, for a minor update in one soc, common > code needs to reworked every time and tested on all boards that share them. > > So feels like having the duplication for hw init sequences is the cleaner > way. > Sounds good, then let's go with this approach! > Apart from that for other comments on the q6v5 wcss driver, i can address > them > on this final patch that you have posted and same can be included in your > next version. Please let me know how you want to go about it. > If you can help me review the first 4 patches and fix up and resend the 5th that would be greatly appreciated. Regards, Bjorn
Re: [PATCH] mm-kasan-dont-vfree-nonexistent-vm_area-fix
On Mon, 2018-05-28 at 12:39 +0800, Ian Kent wrote: > On Mon, 2018-05-28 at 12:13 +0800, Ian Kent wrote: > > On Fri, 2018-05-25 at 20:48 -0700, Andrew Morton wrote: > > > On Sat, 26 May 2018 11:31:35 +0800 kbuild test robot > > > wrote: > > > > > > > Hi Andrey, > > > > > > > > I love your patch! Yet something to improve: > > > > > > > > [auto build test ERROR on mmotm/master] > > > > [cannot apply to v4.17-rc6] > > > > [if your patch is applied to the wrong git tree, please drop us a note > > > > to > > > > help improve the system] > > > > > > > > url:https://github.com/0day-ci/linux/commits/Andrey-Ryabinin/mm-kasa > > > > n- > > > > do > > > > nt-vfree-nonexistent-vm_area-fix/20180526-093255 > > > > base: git://git.cmpxchg.org/linux-mmotm.git master > > > > config: sparc-allyesconfig (attached as .config) > > > > compiler: sparc64-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0 > > > > reproduce: > > > > wget https://raw.githubusercontent.com/intel/lkp-tests/master/sb > > > > in > > > > /m > > > > ake.cross -O ~/bin/make.cross > > > > chmod +x ~/bin/make.cross > > > > # save the attached .config to linux build tree > > > > make.cross ARCH=sparc > > > > > > > > All errors (new ones prefixed by >>): > > > > > > > >fs/autofs/inode.o: In function `autofs_new_ino': > > > >inode.c:(.text+0x220): multiple definition of `autofs_new_ino' > > > >fs/autofs/inode.o:inode.c:(.text+0x220): first defined here > > > >fs/autofs/inode.o: In function `autofs_clean_ino': > > > >inode.c:(.text+0x280): multiple definition of `autofs_clean_ino' > > > >fs/autofs/inode.o:inode.c:(.text+0x280): first defined here > > > > > > There's bot breakage here - clearly that patch didn't cause this error. > > > > > > Ian, this autofs glitch may still not be fixed. > > > > Yes, autofs-make-autofs4-Kconfig-depend-on-AUTOFS_FS.patch should have > > fixed that. > > > > I tied a bunch of .config combinations and I was unable to find any that > > lead to both CONFIG_AUTOFS_FS and CONFIG_AUTOFS4_FS being defined. > > Oh, autofs-make-autofs4-Kconfig-depend-on-AUTOFS_FS.patch was sent as > a follow up patch which means it's still possible to have both > CONFIG_AUTOFS_FS and CONFIG_AUTOFS4_FS set between > autofs-create-autofs-Kconfig-and-Makefile.patch and the above patch. > > Perhaps all that's needed is to fold the follow up patch into > autofs-create-autofs-Kconfig-and-Makefile.patch to close that > possibility. > > I'll check that can be done without problem. I've had a look and I can't see any reason for this other than CONFIG_AUTOFS_FS and CONFIG_AUTOFS4_FS both being set which isn't ok because the file system name is the same for both. I have seen build system configs that have both of these set even though the "autofs" module was removed years ago so that's probably still present in some site build systems. I see you've added the follow up patch I mentioned above as "autofs-update-fs-autofs4-kconfig-fix.patch" with title "autofs - make autofs4 Kconfig depend on AUTOFS_FS" Folding this patch into the patch "autofs-create-autofs-kconfig-and-makefile.patch" with title "autofs: create autofs Kconfig and Makefile" I'm unable to reproduce the breakage which leads me to think the problem must be due to .config having both the CONFIG_AUTOFS* entries defined to something other than n (which certainly does produce the breakage if the follow up patch is not present, so the result is not bisectable until the follow up patch is added). Also, I don't think there is a need to update the description of "autofs: create autofs Kconfig and Makefile" because the patch that is folded into it adds a NOTE to the fs/autofs4/Kconfig help that essentially re-states what is in the description. If this continues to happen I'll need more information about applied patches and kernel config used to work out what's going on. For completeness here's the resulting patch after folding in the follow up patch above: autofs - create autofs Kconfig and Makefile From: Ian Kent Create Makefile and Kconfig for autofs module. Signed-off-by: Ian Kent --- fs/Kconfig |1 + fs/Makefile|1 + fs/autofs/Kconfig | 20 fs/autofs/Makefile |7 +++ fs/autofs4/Kconfig |8 5 files changed, 37 insertions(+) create mode 100644 fs/autofs/Kconfig create mode 100644 fs/autofs/Makefile diff --git a/fs/Kconfig b/fs/Kconfig index bc821a86d965..e712e62afe59 100644 --- a/fs/Kconfig +++ b/fs/Kconfig @@ -108,6 +108,7 @@ source "fs/notify/Kconfig" source "fs/quota/Kconfig" +source "fs/autofs/Kconfig" source "fs/autofs4/Kconfig" source "fs/fuse/Kconfig" source "fs/overlayfs/Kconfig" diff --git a/fs/Makefile b/fs/Makefile index c9375fd2c8c4..2e005525cc19 100644 --- a/fs/Makefile +++ b/fs/Makefile @@ -102,6 +102,7 @@ obj-$(CONFIG_AFFS_FS) += affs/ obj-$(CONFIG_ROMFS_FS) += romfs/ obj-$(CONFIG_QNX4FS_FS)+= qnx4/
Re: [PATCH] mm-kasan-dont-vfree-nonexistent-vm_area-fix
On Mon, 2018-05-28 at 12:39 +0800, Ian Kent wrote: > On Mon, 2018-05-28 at 12:13 +0800, Ian Kent wrote: > > On Fri, 2018-05-25 at 20:48 -0700, Andrew Morton wrote: > > > On Sat, 26 May 2018 11:31:35 +0800 kbuild test robot > > > wrote: > > > > > > > Hi Andrey, > > > > > > > > I love your patch! Yet something to improve: > > > > > > > > [auto build test ERROR on mmotm/master] > > > > [cannot apply to v4.17-rc6] > > > > [if your patch is applied to the wrong git tree, please drop us a note > > > > to > > > > help improve the system] > > > > > > > > url:https://github.com/0day-ci/linux/commits/Andrey-Ryabinin/mm-kasa > > > > n- > > > > do > > > > nt-vfree-nonexistent-vm_area-fix/20180526-093255 > > > > base: git://git.cmpxchg.org/linux-mmotm.git master > > > > config: sparc-allyesconfig (attached as .config) > > > > compiler: sparc64-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0 > > > > reproduce: > > > > wget https://raw.githubusercontent.com/intel/lkp-tests/master/sb > > > > in > > > > /m > > > > ake.cross -O ~/bin/make.cross > > > > chmod +x ~/bin/make.cross > > > > # save the attached .config to linux build tree > > > > make.cross ARCH=sparc > > > > > > > > All errors (new ones prefixed by >>): > > > > > > > >fs/autofs/inode.o: In function `autofs_new_ino': > > > >inode.c:(.text+0x220): multiple definition of `autofs_new_ino' > > > >fs/autofs/inode.o:inode.c:(.text+0x220): first defined here > > > >fs/autofs/inode.o: In function `autofs_clean_ino': > > > >inode.c:(.text+0x280): multiple definition of `autofs_clean_ino' > > > >fs/autofs/inode.o:inode.c:(.text+0x280): first defined here > > > > > > There's bot breakage here - clearly that patch didn't cause this error. > > > > > > Ian, this autofs glitch may still not be fixed. > > > > Yes, autofs-make-autofs4-Kconfig-depend-on-AUTOFS_FS.patch should have > > fixed that. > > > > I tied a bunch of .config combinations and I was unable to find any that > > lead to both CONFIG_AUTOFS_FS and CONFIG_AUTOFS4_FS being defined. > > Oh, autofs-make-autofs4-Kconfig-depend-on-AUTOFS_FS.patch was sent as > a follow up patch which means it's still possible to have both > CONFIG_AUTOFS_FS and CONFIG_AUTOFS4_FS set between > autofs-create-autofs-Kconfig-and-Makefile.patch and the above patch. > > Perhaps all that's needed is to fold the follow up patch into > autofs-create-autofs-Kconfig-and-Makefile.patch to close that > possibility. > > I'll check that can be done without problem. I've had a look and I can't see any reason for this other than CONFIG_AUTOFS_FS and CONFIG_AUTOFS4_FS both being set which isn't ok because the file system name is the same for both. I have seen build system configs that have both of these set even though the "autofs" module was removed years ago so that's probably still present in some site build systems. I see you've added the follow up patch I mentioned above as "autofs-update-fs-autofs4-kconfig-fix.patch" with title "autofs - make autofs4 Kconfig depend on AUTOFS_FS" Folding this patch into the patch "autofs-create-autofs-kconfig-and-makefile.patch" with title "autofs: create autofs Kconfig and Makefile" I'm unable to reproduce the breakage which leads me to think the problem must be due to .config having both the CONFIG_AUTOFS* entries defined to something other than n (which certainly does produce the breakage if the follow up patch is not present, so the result is not bisectable until the follow up patch is added). Also, I don't think there is a need to update the description of "autofs: create autofs Kconfig and Makefile" because the patch that is folded into it adds a NOTE to the fs/autofs4/Kconfig help that essentially re-states what is in the description. If this continues to happen I'll need more information about applied patches and kernel config used to work out what's going on. For completeness here's the resulting patch after folding in the follow up patch above: autofs - create autofs Kconfig and Makefile From: Ian Kent Create Makefile and Kconfig for autofs module. Signed-off-by: Ian Kent --- fs/Kconfig |1 + fs/Makefile|1 + fs/autofs/Kconfig | 20 fs/autofs/Makefile |7 +++ fs/autofs4/Kconfig |8 5 files changed, 37 insertions(+) create mode 100644 fs/autofs/Kconfig create mode 100644 fs/autofs/Makefile diff --git a/fs/Kconfig b/fs/Kconfig index bc821a86d965..e712e62afe59 100644 --- a/fs/Kconfig +++ b/fs/Kconfig @@ -108,6 +108,7 @@ source "fs/notify/Kconfig" source "fs/quota/Kconfig" +source "fs/autofs/Kconfig" source "fs/autofs4/Kconfig" source "fs/fuse/Kconfig" source "fs/overlayfs/Kconfig" diff --git a/fs/Makefile b/fs/Makefile index c9375fd2c8c4..2e005525cc19 100644 --- a/fs/Makefile +++ b/fs/Makefile @@ -102,6 +102,7 @@ obj-$(CONFIG_AFFS_FS) += affs/ obj-$(CONFIG_ROMFS_FS) += romfs/ obj-$(CONFIG_QNX4FS_FS)+= qnx4/
[v2] MAINTAINERS: add myself as maintainer for QorIQ PTP clock driver
Added myself as maintainer for QorIQ PTP clock driver. Since gianfar_ptp.c was renamed to ptp_qoriq.c, let's maintain it under QorIQ PTP clock driver. Signed-off-by: Yangbo Lu --- Changes for v2: - Dropped dpaa2/rtc part. --- MAINTAINERS | 10 -- 1 files changed, 8 insertions(+), 2 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index f492431..c16340c 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -5620,7 +5620,6 @@ M:Claudiu Manoil L: net...@vger.kernel.org S: Maintained F: drivers/net/ethernet/freescale/gianfar* -X: drivers/net/ethernet/freescale/gianfar_ptp.c F: Documentation/devicetree/bindings/net/fsl-tsec-phy.txt FREESCALE GPMI NAND DRIVER @@ -5667,6 +5666,14 @@ S: Maintained F: drivers/net/ethernet/freescale/fman F: Documentation/devicetree/bindings/powerpc/fsl/fman.txt +FREESCALE QORIQ PTP CLOCK DRIVER +M: Yangbo Lu +L: net...@vger.kernel.org +S: Maintained +F: drivers/ptp/ptp_qoriq.c +F: include/linux/fsl/ptp_qoriq.h +F: Documentation/devicetree/bindings/ptp/ptp-qoriq.txt + FREESCALE QUAD SPI DRIVER M: Han Xu L: linux-...@lists.infradead.org @@ -11405,7 +11412,6 @@ S: Maintained W: http://linuxptp.sourceforge.net/ F: Documentation/ABI/testing/sysfs-ptp F: Documentation/ptp/* -F: drivers/net/ethernet/freescale/gianfar_ptp.c F: drivers/net/phy/dp83640* F: drivers/ptp/* F: include/linux/ptp_cl* -- 1.7.1
[v2] MAINTAINERS: add myself as maintainer for QorIQ PTP clock driver
Added myself as maintainer for QorIQ PTP clock driver. Since gianfar_ptp.c was renamed to ptp_qoriq.c, let's maintain it under QorIQ PTP clock driver. Signed-off-by: Yangbo Lu --- Changes for v2: - Dropped dpaa2/rtc part. --- MAINTAINERS | 10 -- 1 files changed, 8 insertions(+), 2 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index f492431..c16340c 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -5620,7 +5620,6 @@ M:Claudiu Manoil L: net...@vger.kernel.org S: Maintained F: drivers/net/ethernet/freescale/gianfar* -X: drivers/net/ethernet/freescale/gianfar_ptp.c F: Documentation/devicetree/bindings/net/fsl-tsec-phy.txt FREESCALE GPMI NAND DRIVER @@ -5667,6 +5666,14 @@ S: Maintained F: drivers/net/ethernet/freescale/fman F: Documentation/devicetree/bindings/powerpc/fsl/fman.txt +FREESCALE QORIQ PTP CLOCK DRIVER +M: Yangbo Lu +L: net...@vger.kernel.org +S: Maintained +F: drivers/ptp/ptp_qoriq.c +F: include/linux/fsl/ptp_qoriq.h +F: Documentation/devicetree/bindings/ptp/ptp-qoriq.txt + FREESCALE QUAD SPI DRIVER M: Han Xu L: linux-...@lists.infradead.org @@ -11405,7 +11412,6 @@ S: Maintained W: http://linuxptp.sourceforge.net/ F: Documentation/ABI/testing/sysfs-ptp F: Documentation/ptp/* -F: drivers/net/ethernet/freescale/gianfar_ptp.c F: drivers/net/phy/dp83640* F: drivers/ptp/* F: include/linux/ptp_cl* -- 1.7.1
RE: [PATCH 5/5] MAINTAINERS: add myself as maintainer for QorIQ PTP clock driver
Hi David, > -Original Message- > From: David Miller [mailto:da...@davemloft.net] > Sent: Tuesday, May 29, 2018 11:07 AM > To: Y.b. Lu > Cc: net...@vger.kernel.org; devicet...@vger.kernel.org; > linux-kernel@vger.kernel.org; richardcoch...@gmail.com; Claudiu Manoil > ; robh...@kernel.org > Subject: Re: [PATCH 5/5] MAINTAINERS: add myself as maintainer for QorIQ > PTP clock driver > > From: Yangbo Lu > Date: Fri, 25 May 2018 12:40:38 +0800 > > > Added myself as maintainer for QorIQ PTP clock driver. > > Since gianfar_ptp.c was renamed to ptp_qoriq.c, let's also maintain it > > under QorIQ PTP clock driver. > > > > Signed-off-by: Yangbo Lu > > Because of the dependency on the staging tree changes, this doesn't apply > cleanly to net-next. > > You'll have to figure out how you want to sort this out. [Y.b. Lu] I sent out a v2 MAINTAINERS patch. I think it also makes sense to drop dpaa2 rtc drivers in the entry. Thanks a lot.
RE: [PATCH 5/5] MAINTAINERS: add myself as maintainer for QorIQ PTP clock driver
Hi David, > -Original Message- > From: David Miller [mailto:da...@davemloft.net] > Sent: Tuesday, May 29, 2018 11:07 AM > To: Y.b. Lu > Cc: net...@vger.kernel.org; devicet...@vger.kernel.org; > linux-kernel@vger.kernel.org; richardcoch...@gmail.com; Claudiu Manoil > ; robh...@kernel.org > Subject: Re: [PATCH 5/5] MAINTAINERS: add myself as maintainer for QorIQ > PTP clock driver > > From: Yangbo Lu > Date: Fri, 25 May 2018 12:40:38 +0800 > > > Added myself as maintainer for QorIQ PTP clock driver. > > Since gianfar_ptp.c was renamed to ptp_qoriq.c, let's also maintain it > > under QorIQ PTP clock driver. > > > > Signed-off-by: Yangbo Lu > > Because of the dependency on the staging tree changes, this doesn't apply > cleanly to net-next. > > You'll have to figure out how you want to sort this out. [Y.b. Lu] I sent out a v2 MAINTAINERS patch. I think it also makes sense to drop dpaa2 rtc drivers in the entry. Thanks a lot.
linux-next: build failure after merge of the net-next tree
Hi all,
After merging the net-next tree, today's linux-next build (x86_64
allmodconfig) failed like this:
net/xdp/xsk.c: In function 'xsk_poll':
net/xdp/xsk.c:207:22: error: implicit declaration of function 'datagram_poll';
did you mean 'datagram_poll_mask'? [-Werror=implicit-function-declaration]
unsigned int mask = datagram_poll(file, sock, wait);
^
datagram_poll_mask
Caused by commit
c497176cb2e4 ("xsk: add Rx receive functions and poll support")
interacting with commit
db5051ead64a ("net: convert datagram_poll users tp ->poll_mask")
from the vfs tree.
[Christoph, I noticed that the comment above datagram_poll in
net/core/datagram.c needs the function name updated]
I have added the following merge fix patch for today:
From: Stephen Rothwell
Date: Tue, 29 May 2018 13:34:25 +1000
Subject: [PATCH] xsk: update for "net: convert datagram_poll users
tp->poll_mask"
Signed-off-by: Stephen Rothwell
---
net/xdp/xsk.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/net/xdp/xsk.c b/net/xdp/xsk.c
index cce0e4f8a536..4ee140afbc61 100644
--- a/net/xdp/xsk.c
+++ b/net/xdp/xsk.c
@@ -201,10 +201,9 @@ static int xsk_sendmsg(struct socket *sock, struct msghdr
*m, size_t total_len)
return xsk_generic_xmit(sk, m, total_len);
}
-static unsigned int xsk_poll(struct file *file, struct socket *sock,
-struct poll_table_struct *wait)
+static __poll_t xsk_poll_mask(struct socket *sock, __poll_t events)
{
- unsigned int mask = datagram_poll(file, sock, wait);
+ __poll_t mask = datagram_poll_mask(sock, events);
struct sock *sk = sock->sk;
struct xdp_sock *xs = xdp_sk(sk);
@@ -580,7 +579,7 @@ static const struct proto_ops xsk_proto_ops = {
.socketpair = sock_no_socketpair,
.accept = sock_no_accept,
.getname= sock_no_getname,
- .poll = xsk_poll,
+ .poll_mask = xsk_poll_mask,
.ioctl = sock_no_ioctl,
.listen = sock_no_listen,
.shutdown = sock_no_shutdown,
--
2.17.0
--
Cheers,
Stephen Rothwell
pgprUrc9ZlJi4.pgp
Description: OpenPGP digital signature
linux-next: build failure after merge of the net-next tree
Hi all,
After merging the net-next tree, today's linux-next build (x86_64
allmodconfig) failed like this:
net/xdp/xsk.c: In function 'xsk_poll':
net/xdp/xsk.c:207:22: error: implicit declaration of function 'datagram_poll';
did you mean 'datagram_poll_mask'? [-Werror=implicit-function-declaration]
unsigned int mask = datagram_poll(file, sock, wait);
^
datagram_poll_mask
Caused by commit
c497176cb2e4 ("xsk: add Rx receive functions and poll support")
interacting with commit
db5051ead64a ("net: convert datagram_poll users tp ->poll_mask")
from the vfs tree.
[Christoph, I noticed that the comment above datagram_poll in
net/core/datagram.c needs the function name updated]
I have added the following merge fix patch for today:
From: Stephen Rothwell
Date: Tue, 29 May 2018 13:34:25 +1000
Subject: [PATCH] xsk: update for "net: convert datagram_poll users
tp->poll_mask"
Signed-off-by: Stephen Rothwell
---
net/xdp/xsk.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/net/xdp/xsk.c b/net/xdp/xsk.c
index cce0e4f8a536..4ee140afbc61 100644
--- a/net/xdp/xsk.c
+++ b/net/xdp/xsk.c
@@ -201,10 +201,9 @@ static int xsk_sendmsg(struct socket *sock, struct msghdr
*m, size_t total_len)
return xsk_generic_xmit(sk, m, total_len);
}
-static unsigned int xsk_poll(struct file *file, struct socket *sock,
-struct poll_table_struct *wait)
+static __poll_t xsk_poll_mask(struct socket *sock, __poll_t events)
{
- unsigned int mask = datagram_poll(file, sock, wait);
+ __poll_t mask = datagram_poll_mask(sock, events);
struct sock *sk = sock->sk;
struct xdp_sock *xs = xdp_sk(sk);
@@ -580,7 +579,7 @@ static const struct proto_ops xsk_proto_ops = {
.socketpair = sock_no_socketpair,
.accept = sock_no_accept,
.getname= sock_no_getname,
- .poll = xsk_poll,
+ .poll_mask = xsk_poll_mask,
.ioctl = sock_no_ioctl,
.listen = sock_no_listen,
.shutdown = sock_no_shutdown,
--
2.17.0
--
Cheers,
Stephen Rothwell
pgprUrc9ZlJi4.pgp
Description: OpenPGP digital signature
linux-next: build failure after merge of the net-next tree
Hi all,
After merging the net-next tree, today's linux-next build (x86_64
allmodconfig) failed like this:
x86_64-linux-ld: unknown architecture of input file
`net/bpfilter/bpfilter_umh.o' is incompatible with i386:x86-64 output
Caused by commit
d2ba09c17a06 ("net: add skeleton of bpfilter kernel module")
In my builds, the host is PowerPC 64 LE ...
I have reverted that commit along with
61a552eb487f ("bpfilter: fix build dependency")
13405468f49d ("bpfilter: don't pass O_CREAT when opening console for debug")
for today.
--
Cheers,
Stephen Rothwell
pgpm6oFwkyrCl.pgp
Description: OpenPGP digital signature
linux-next: build failure after merge of the net-next tree
Hi all,
After merging the net-next tree, today's linux-next build (x86_64
allmodconfig) failed like this:
x86_64-linux-ld: unknown architecture of input file
`net/bpfilter/bpfilter_umh.o' is incompatible with i386:x86-64 output
Caused by commit
d2ba09c17a06 ("net: add skeleton of bpfilter kernel module")
In my builds, the host is PowerPC 64 LE ...
I have reverted that commit along with
61a552eb487f ("bpfilter: fix build dependency")
13405468f49d ("bpfilter: don't pass O_CREAT when opening console for debug")
for today.
--
Cheers,
Stephen Rothwell
pgpm6oFwkyrCl.pgp
Description: OpenPGP digital signature
Re: [RFC PATCH] m68k: set dma and coherent masks for Macintosh SONIC based ethernet
Hi Finn, Am 29.05.2018 um 14:15 schrieb Finn Thain: > > Since an arch gets to apply limits in the dma ops it implements, why would > arch code also have to set a limit in the form of default platform device > masks? Powerpc seems to be the only arch that does this. One of Christoph's recent patches removed most of arches' dma ops, replacing them by one generic implementation instead. m68k was one of the affected arches. I concede his patch series is experimental still and not in mainline, but may be included at some time. Otherwise - your patches, so if you prefer to have each driver handle this on an as-needed basis, I'm not objecting. Cheers, Michael
Re: [RFC PATCH] m68k: set dma and coherent masks for Macintosh SONIC based ethernet
Hi Finn, Am 29.05.2018 um 14:15 schrieb Finn Thain: > > Since an arch gets to apply limits in the dma ops it implements, why would > arch code also have to set a limit in the form of default platform device > masks? Powerpc seems to be the only arch that does this. One of Christoph's recent patches removed most of arches' dma ops, replacing them by one generic implementation instead. m68k was one of the affected arches. I concede his patch series is experimental still and not in mainline, but may be included at some time. Otherwise - your patches, so if you prefer to have each driver handle this on an as-needed basis, I'm not objecting. Cheers, Michael
Re: [RFC v5 3/5] virtio_ring: add packed ring support
On 2018年05月22日 16:16, Tiwei Bie wrote:
This commit introduces the support (without EVENT_IDX) for
packed ring.
Signed-off-by: Tiwei Bie
---
drivers/virtio/virtio_ring.c | 474 ++-
1 file changed, 468 insertions(+), 6 deletions(-)
diff --git a/drivers/virtio/virtio_ring.c b/drivers/virtio/virtio_ring.c
index f5ef5f42a7cf..eb9fd5207a68 100644
--- a/drivers/virtio/virtio_ring.c
+++ b/drivers/virtio/virtio_ring.c
@@ -62,6 +62,12 @@ struct vring_desc_state {
};
struct vring_desc_state_packed {
+ void *data; /* Data for callback. */
+ struct vring_packed_desc *indir_desc; /* Indirect descriptor, if any. */
+ int num;/* Descriptor list length. */
+ dma_addr_t addr;/* Buffer DMA addr. */
+ u32 len;/* Buffer length. */
+ u16 flags; /* Descriptor flags. */
int next; /* The next desc state. */
};
@@ -758,6 +764,72 @@ static inline unsigned vring_size_packed(unsigned int num, unsigned long align)
& ~(align - 1)) + sizeof(struct vring_packed_desc_event) * 2;
}
+static void vring_unmap_state_packed(const struct vring_virtqueue *vq,
+struct vring_desc_state_packed *state)
+{
+ u16 flags;
+
+ if (!vring_use_dma_api(vq->vq.vdev))
+ return;
+
+ flags = state->flags;
+
+ if (flags & VRING_DESC_F_INDIRECT) {
+ dma_unmap_single(vring_dma_dev(vq),
+state->addr, state->len,
+(flags & VRING_DESC_F_WRITE) ?
+DMA_FROM_DEVICE : DMA_TO_DEVICE);
+ } else {
+ dma_unmap_page(vring_dma_dev(vq),
+ state->addr, state->len,
+ (flags & VRING_DESC_F_WRITE) ?
+ DMA_FROM_DEVICE : DMA_TO_DEVICE);
+ }
+}
+
+static void vring_unmap_desc_packed(const struct vring_virtqueue *vq,
+ struct vring_packed_desc *desc)
+{
+ u16 flags;
+
+ if (!vring_use_dma_api(vq->vq.vdev))
+ return;
+
+ flags = virtio16_to_cpu(vq->vq.vdev, desc->flags);
+
+ if (flags & VRING_DESC_F_INDIRECT) {
+ dma_unmap_single(vring_dma_dev(vq),
+virtio64_to_cpu(vq->vq.vdev, desc->addr),
+virtio32_to_cpu(vq->vq.vdev, desc->len),
+(flags & VRING_DESC_F_WRITE) ?
+DMA_FROM_DEVICE : DMA_TO_DEVICE);
+ } else {
+ dma_unmap_page(vring_dma_dev(vq),
+ virtio64_to_cpu(vq->vq.vdev, desc->addr),
+ virtio32_to_cpu(vq->vq.vdev, desc->len),
+ (flags & VRING_DESC_F_WRITE) ?
+ DMA_FROM_DEVICE : DMA_TO_DEVICE);
+ }
+}
+
+static struct vring_packed_desc *alloc_indirect_packed(struct virtqueue *_vq,
+ unsigned int total_sg,
+ gfp_t gfp)
+{
+ struct vring_packed_desc *desc;
+
+ /*
+* We require lowmem mappings for the descriptors because
+* otherwise virt_to_phys will give us bogus addresses in the
+* virtqueue.
+*/
+ gfp &= ~__GFP_HIGHMEM;
+
+ desc = kmalloc(total_sg * sizeof(struct vring_packed_desc), gfp);
+
+ return desc;
+}
+
static inline int virtqueue_add_packed(struct virtqueue *_vq,
struct scatterlist *sgs[],
unsigned int total_sg,
@@ -767,47 +839,437 @@ static inline int virtqueue_add_packed(struct virtqueue
*_vq,
void *ctx,
gfp_t gfp)
{
+ struct vring_virtqueue *vq = to_vvq(_vq);
+ struct vring_packed_desc *desc;
+ struct scatterlist *sg;
+ unsigned int i, n, descs_used, uninitialized_var(prev), err_idx;
+ __virtio16 uninitialized_var(head_flags), flags;
+ u16 head, avail_wrap_counter, id, cur;
+ bool indirect;
+
+ START_USE(vq);
+
+ BUG_ON(data == NULL);
+ BUG_ON(ctx && vq->indirect);
+
+ if (unlikely(vq->broken)) {
+ END_USE(vq);
+ return -EIO;
+ }
+
+#ifdef DEBUG
+ {
+ ktime_t now = ktime_get();
+
+ /* No kick or get, with .1 second between? Warn. */
+ if (vq->last_add_time_valid)
+ WARN_ON(ktime_to_ms(ktime_sub(now, vq->last_add_time))
+ > 100);
+ vq->last_add_time = now;
+ vq->last_add_time_valid = true;
+ }
+#endif
+
+
Re: [RFC v5 3/5] virtio_ring: add packed ring support
On 2018年05月22日 16:16, Tiwei Bie wrote:
This commit introduces the support (without EVENT_IDX) for
packed ring.
Signed-off-by: Tiwei Bie
---
drivers/virtio/virtio_ring.c | 474 ++-
1 file changed, 468 insertions(+), 6 deletions(-)
diff --git a/drivers/virtio/virtio_ring.c b/drivers/virtio/virtio_ring.c
index f5ef5f42a7cf..eb9fd5207a68 100644
--- a/drivers/virtio/virtio_ring.c
+++ b/drivers/virtio/virtio_ring.c
@@ -62,6 +62,12 @@ struct vring_desc_state {
};
struct vring_desc_state_packed {
+ void *data; /* Data for callback. */
+ struct vring_packed_desc *indir_desc; /* Indirect descriptor, if any. */
+ int num;/* Descriptor list length. */
+ dma_addr_t addr;/* Buffer DMA addr. */
+ u32 len;/* Buffer length. */
+ u16 flags; /* Descriptor flags. */
int next; /* The next desc state. */
};
@@ -758,6 +764,72 @@ static inline unsigned vring_size_packed(unsigned int num, unsigned long align)
& ~(align - 1)) + sizeof(struct vring_packed_desc_event) * 2;
}
+static void vring_unmap_state_packed(const struct vring_virtqueue *vq,
+struct vring_desc_state_packed *state)
+{
+ u16 flags;
+
+ if (!vring_use_dma_api(vq->vq.vdev))
+ return;
+
+ flags = state->flags;
+
+ if (flags & VRING_DESC_F_INDIRECT) {
+ dma_unmap_single(vring_dma_dev(vq),
+state->addr, state->len,
+(flags & VRING_DESC_F_WRITE) ?
+DMA_FROM_DEVICE : DMA_TO_DEVICE);
+ } else {
+ dma_unmap_page(vring_dma_dev(vq),
+ state->addr, state->len,
+ (flags & VRING_DESC_F_WRITE) ?
+ DMA_FROM_DEVICE : DMA_TO_DEVICE);
+ }
+}
+
+static void vring_unmap_desc_packed(const struct vring_virtqueue *vq,
+ struct vring_packed_desc *desc)
+{
+ u16 flags;
+
+ if (!vring_use_dma_api(vq->vq.vdev))
+ return;
+
+ flags = virtio16_to_cpu(vq->vq.vdev, desc->flags);
+
+ if (flags & VRING_DESC_F_INDIRECT) {
+ dma_unmap_single(vring_dma_dev(vq),
+virtio64_to_cpu(vq->vq.vdev, desc->addr),
+virtio32_to_cpu(vq->vq.vdev, desc->len),
+(flags & VRING_DESC_F_WRITE) ?
+DMA_FROM_DEVICE : DMA_TO_DEVICE);
+ } else {
+ dma_unmap_page(vring_dma_dev(vq),
+ virtio64_to_cpu(vq->vq.vdev, desc->addr),
+ virtio32_to_cpu(vq->vq.vdev, desc->len),
+ (flags & VRING_DESC_F_WRITE) ?
+ DMA_FROM_DEVICE : DMA_TO_DEVICE);
+ }
+}
+
+static struct vring_packed_desc *alloc_indirect_packed(struct virtqueue *_vq,
+ unsigned int total_sg,
+ gfp_t gfp)
+{
+ struct vring_packed_desc *desc;
+
+ /*
+* We require lowmem mappings for the descriptors because
+* otherwise virt_to_phys will give us bogus addresses in the
+* virtqueue.
+*/
+ gfp &= ~__GFP_HIGHMEM;
+
+ desc = kmalloc(total_sg * sizeof(struct vring_packed_desc), gfp);
+
+ return desc;
+}
+
static inline int virtqueue_add_packed(struct virtqueue *_vq,
struct scatterlist *sgs[],
unsigned int total_sg,
@@ -767,47 +839,437 @@ static inline int virtqueue_add_packed(struct virtqueue
*_vq,
void *ctx,
gfp_t gfp)
{
+ struct vring_virtqueue *vq = to_vvq(_vq);
+ struct vring_packed_desc *desc;
+ struct scatterlist *sg;
+ unsigned int i, n, descs_used, uninitialized_var(prev), err_idx;
+ __virtio16 uninitialized_var(head_flags), flags;
+ u16 head, avail_wrap_counter, id, cur;
+ bool indirect;
+
+ START_USE(vq);
+
+ BUG_ON(data == NULL);
+ BUG_ON(ctx && vq->indirect);
+
+ if (unlikely(vq->broken)) {
+ END_USE(vq);
+ return -EIO;
+ }
+
+#ifdef DEBUG
+ {
+ ktime_t now = ktime_get();
+
+ /* No kick or get, with .1 second between? Warn. */
+ if (vq->last_add_time_valid)
+ WARN_ON(ktime_to_ms(ktime_sub(now, vq->last_add_time))
+ > 100);
+ vq->last_add_time = now;
+ vq->last_add_time_valid = true;
+ }
+#endif
+
+
linux-next: build warning after merge of the net-next tree
Hi all,
After merging the net-next tree, today's linux-next build (powerpc
ppc64_defconfig) produced this warning:
net/core/filter.c: In function 'sk_msg_convert_ctx_access':
net/core/filter.c:6450:6: warning: unused variable 'off' [-Wunused-variable]
int off;
^~~
Introduced by commit
303def35f64e ("bpf: allow sk_msg programs to read sock fields")
--
Cheers,
Stephen Rothwell
pgpjckujcMn2y.pgp
Description: OpenPGP digital signature
linux-next: build warning after merge of the net-next tree
Hi all,
After merging the net-next tree, today's linux-next build (powerpc
ppc64_defconfig) produced this warning:
net/core/filter.c: In function 'sk_msg_convert_ctx_access':
net/core/filter.c:6450:6: warning: unused variable 'off' [-Wunused-variable]
int off;
^~~
Introduced by commit
303def35f64e ("bpf: allow sk_msg programs to read sock fields")
--
Cheers,
Stephen Rothwell
pgpjckujcMn2y.pgp
Description: OpenPGP digital signature
Re: [PATCH V0:net-next 0/4] net: ethernet: stmmac: add support for stm32mp1
From: Christophe Roullier Date: Fri, 25 May 2018 09:46:37 +0200 > Patches to have Ethernet support on stm32mp1 Series applied.
Re: [PATCH V0:net-next 0/4] net: ethernet: stmmac: add support for stm32mp1
From: Christophe Roullier Date: Fri, 25 May 2018 09:46:37 +0200 > Patches to have Ethernet support on stm32mp1 Series applied.
Re: [PATCH 5/5] MAINTAINERS: add myself as maintainer for QorIQ PTP clock driver
From: Yangbo Lu Date: Fri, 25 May 2018 12:40:38 +0800 > Added myself as maintainer for QorIQ PTP clock driver. > Since gianfar_ptp.c was renamed to ptp_qoriq.c, let's > also maintain it under QorIQ PTP clock driver. > > Signed-off-by: Yangbo Lu Because of the dependency on the staging tree changes, this doesn't apply cleanly to net-next. You'll have to figure out how you want to sort this out.
Re: [PATCH 5/5] MAINTAINERS: add myself as maintainer for QorIQ PTP clock driver
From: Yangbo Lu Date: Fri, 25 May 2018 12:40:38 +0800 > Added myself as maintainer for QorIQ PTP clock driver. > Since gianfar_ptp.c was renamed to ptp_qoriq.c, let's > also maintain it under QorIQ PTP clock driver. > > Signed-off-by: Yangbo Lu Because of the dependency on the staging tree changes, this doesn't apply cleanly to net-next. You'll have to figure out how you want to sort this out.
Re: [PATCH 3/5] net: ethernet: gianfar_ethtool: get phc index through drvdata
From: Yangbo Lu Date: Fri, 25 May 2018 12:40:36 +0800 > Global variable gfar_phc_index was used to get and store > phc index through gianfar_ptp driver. However gianfar_ptp > had been renamed as ptp_qoriq for QorIQ common PTP driver. > This gfar_phc_index doesn't work any more, and the phc index > is stored in drvdata now. This patch is to support getting > phc index through ptp_qoriq drvdata. > > Signed-off-by: Yangbo Lu Applied.
Re: [PATCH 3/5] net: ethernet: gianfar_ethtool: get phc index through drvdata
From: Yangbo Lu Date: Fri, 25 May 2018 12:40:36 +0800 > Global variable gfar_phc_index was used to get and store > phc index through gianfar_ptp driver. However gianfar_ptp > had been renamed as ptp_qoriq for QorIQ common PTP driver. > This gfar_phc_index doesn't work any more, and the phc index > is stored in drvdata now. This patch is to support getting > phc index through ptp_qoriq drvdata. > > Signed-off-by: Yangbo Lu Applied.
Re: [PATCH 4/5] dt-bindings: ptp: add ptp-qoriq.txt
From: Yangbo Lu Date: Fri, 25 May 2018 12:40:37 +0800 > This patch is to add a documentation for ptp_qoriq dt-bindings. > The description for ptp_qoriq dt-bindings was actually moved > from Documentation/devicetree/bindings/net/fsl-tsec-phy.txt, > since gianfar_ptp driver was moved to ptp_qoriq driver. > > Signed-off-by: Yangbo Lu Applied.
Re: [PATCH 4/5] dt-bindings: ptp: add ptp-qoriq.txt
From: Yangbo Lu Date: Fri, 25 May 2018 12:40:37 +0800 > This patch is to add a documentation for ptp_qoriq dt-bindings. > The description for ptp_qoriq dt-bindings was actually moved > from Documentation/devicetree/bindings/net/fsl-tsec-phy.txt, > since gianfar_ptp driver was moved to ptp_qoriq driver. > > Signed-off-by: Yangbo Lu Applied.
