[PATCH 4.14 41/49] usb: u132-hcd: fix resource leak
[ Upstream commit f276e002793cdb820862e8ea8f76769d56bba575 ]
if platform_driver_register fails, cleanup the allocated resource
gracefully.
Signed-off-by: Mukesh Ojha
Signed-off-by: Greg Kroah-Hartman
Signed-off-by: Sasha Levin (Microsoft)
---
drivers/usb/host/u132-hcd.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/usb/host/u132-hcd.c b/drivers/usb/host/u132-hcd.c
index 65c0086e25ae..8d349230b2c7 100644
--- a/drivers/usb/host/u132-hcd.c
+++ b/drivers/usb/host/u132-hcd.c
@@ -3208,6 +3208,9 @@ static int __init u132_hcd_init(void)
printk(KERN_INFO "driver %s\n", hcd_name);
workqueue = create_singlethread_workqueue("u132");
retval = platform_driver_register(&u132_platform_driver);
+ if (retval)
+ destroy_workqueue(workqueue);
+
return retval;
}
--
2.19.1
[PATCH 4.14 31/49] ARM: dts: imx6qdl: Fix typo in imx6qdl-icore-rqs.dtsi
[ Upstream commit 41b37f4c0fa67185691bcbd30201cad566f2f0d1 ]
This patch fixes a spelling typo.
Signed-off-by: Masanari Iida
Fixes: cc42603de320 ("ARM: dts: imx6q-icore-rqs: Add Engicam IMX6 Q7 initial
support")
Signed-off-by: Shawn Guo
Signed-off-by: Sasha Levin (Microsoft)
---
arch/arm/boot/dts/imx6qdl-icore-rqs.dtsi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/imx6qdl-icore-rqs.dtsi
b/arch/arm/boot/dts/imx6qdl-icore-rqs.dtsi
index 7ca291e9dbdb..80f1b3fb6abc 100644
--- a/arch/arm/boot/dts/imx6qdl-icore-rqs.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-icore-rqs.dtsi
@@ -222,7 +222,7 @@
pinctrl-2 = <&pinctrl_usdhc3_200mhz>;
vmcc-supply = <®_sd3_vmmc>;
cd-gpios = <&gpio1 1 GPIO_ACTIVE_LOW>;
- bus-witdh = <4>;
+ bus-width = <4>;
no-1-8-v;
status = "okay";
};
@@ -233,7 +233,7 @@
pinctrl-1 = <&pinctrl_usdhc4_100mhz>;
pinctrl-2 = <&pinctrl_usdhc4_200mhz>;
vmcc-supply = <®_sd4_vmmc>;
- bus-witdh = <8>;
+ bus-width = <8>;
no-1-8-v;
non-removable;
status = "okay";
--
2.19.1
[PATCH 4.14 45/49] gpio: of: Fix of_gpiochip_add() error path
[ Upstream commit f7299d441a4da8a5088e651ea55023525a793a13 ]
If the call to of_gpiochip_scan_gpios() in of_gpiochip_add() fails, no
error handling is performed. This lead to the need of callers to call
of_gpiochip_remove() on failure, which causes "BAD of_node_put() on ..."
if the failure happened before the call to of_node_get().
Fix this by adding proper error handling.
Note that calling gpiochip_remove_pin_ranges() multiple times causes no
harm: subsequent calls are a no-op.
Fixes: dfbd379ba9b7431e ("gpio: of: Return error if gpio hog configuration
failed")
Signed-off-by: Geert Uytterhoeven
Reviewed-by: Mukesh Ojha
Signed-off-by: Linus Walleij
Signed-off-by: Sasha Levin (Microsoft)
---
drivers/gpio/gpiolib-of.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/gpio/gpiolib-of.c b/drivers/gpio/gpiolib-of.c
index ee8c046cab62..d6ed4e891b34 100644
--- a/drivers/gpio/gpiolib-of.c
+++ b/drivers/gpio/gpiolib-of.c
@@ -499,7 +499,13 @@ int of_gpiochip_add(struct gpio_chip *chip)
of_node_get(chip->of_node);
- return of_gpiochip_scan_gpios(chip);
+ status = of_gpiochip_scan_gpios(chip);
+ if (status) {
+ of_node_put(chip->of_node);
+ gpiochip_remove_pin_ranges(chip);
+ }
+
+ return status;
}
void of_gpiochip_remove(struct gpio_chip *chip)
--
2.19.1
[PATCH 4.14 46/49] kconfig/[mn]conf: handle backspace (^H) key
[ Upstream commit 9c38f1f044080392603c497ecca4d7d09876ff99 ]
Backspace is not working on some terminal emulators which do not send the
key code defined by terminfo. Terminals either send '^H' (8) or '^?' (127).
But currently only '^?' is handled. Let's also handle '^H' for those
terminals.
Signed-off-by: Changbin Du
Signed-off-by: Masahiro Yamada
Signed-off-by: Sasha Levin (Microsoft)
---
scripts/kconfig/lxdialog/inputbox.c | 3 ++-
scripts/kconfig/nconf.c | 2 +-
scripts/kconfig/nconf.gui.c | 3 ++-
3 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/scripts/kconfig/lxdialog/inputbox.c
b/scripts/kconfig/lxdialog/inputbox.c
index d58de1dc5360..510049a7bd1d 100644
--- a/scripts/kconfig/lxdialog/inputbox.c
+++ b/scripts/kconfig/lxdialog/inputbox.c
@@ -126,7 +126,8 @@ int dialog_inputbox(const char *title, const char *prompt,
int height, int width
case KEY_DOWN:
break;
case KEY_BACKSPACE:
- case 127:
+ case 8: /* ^H */
+ case 127: /* ^? */
if (pos) {
wattrset(dialog, dlg.inputbox.atr);
if (input_x == 0) {
diff --git a/scripts/kconfig/nconf.c b/scripts/kconfig/nconf.c
index 003114779815..e8e1944fa09b 100644
--- a/scripts/kconfig/nconf.c
+++ b/scripts/kconfig/nconf.c
@@ -1048,7 +1048,7 @@ static int do_match(int key, struct match_state *state,
int *ans)
state->match_direction = FIND_NEXT_MATCH_UP;
*ans = get_mext_match(state->pattern,
state->match_direction);
- } else if (key == KEY_BACKSPACE || key == 127) {
+ } else if (key == KEY_BACKSPACE || key == 8 || key == 127) {
state->pattern[strlen(state->pattern)-1] = '\0';
adj_match_dir(&state->match_direction);
} else
diff --git a/scripts/kconfig/nconf.gui.c b/scripts/kconfig/nconf.gui.c
index a64b1c31253e..0b63357f1d33 100644
--- a/scripts/kconfig/nconf.gui.c
+++ b/scripts/kconfig/nconf.gui.c
@@ -439,7 +439,8 @@ int dialog_inputbox(WINDOW *main_window,
case KEY_F(F_EXIT):
case KEY_F(F_BACK):
break;
- case 127:
+ case 8: /* ^H */
+ case 127: /* ^? */
case KEY_BACKSPACE:
if (cursor_position > 0) {
memmove(&result[cursor_position-1],
--
2.19.1
[PATCH 4.14 30/49] net/sched: dont dereference a->goto_chain to read the chain index
[ Upstream commit fe384e2fa36ca084a456fd3055875b4b3fbd ]
callers of tcf_gact_goto_chain_index() can potentially read an old value
of the chain index, or even dereference a NULL 'goto_chain' pointer,
because 'goto_chain' and 'tcfa_action' are read in the traffic path
without caring of concurrent write in the control path. The most recent
value of chain index can be read also from a->tcfa_action (it's encoded
there together with TC_ACT_GOTO_CHAIN bits), so we don't really need to
dereference 'goto_chain': just read the chain id from the control action.
Fixes: e457d86ada27 ("net: sched: add couple of goto_chain helpers")
Signed-off-by: Davide Caratti
Signed-off-by: David S. Miller
Signed-off-by: Sasha Levin (Microsoft)
---
include/net/tc_act/tc_gact.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/net/tc_act/tc_gact.h b/include/net/tc_act/tc_gact.h
index e82d93346b63..bb74ea83d57d 100644
--- a/include/net/tc_act/tc_gact.h
+++ b/include/net/tc_act/tc_gact.h
@@ -51,7 +51,7 @@ static inline bool is_tcf_gact_goto_chain(const struct
tc_action *a)
static inline u32 tcf_gact_goto_chain_index(const struct tc_action *a)
{
- return a->goto_chain->index;
+ return READ_ONCE(a->tcfa_action) & TC_ACT_EXT_VAL_MASK;
}
#endif /* __NET_TC_GACT_H */
--
2.19.1
[PATCH 4.14 40/49] usb: usb251xb: fix to avoid potential NULL pointer dereference
[ Upstream commit 41f00e6e9e55546390031996b773e7f3c1d95928 ]
of_match_device in usb251xb_probe can fail and returns a NULL pointer.
The patch avoids a potential NULL pointer dereference in this scenario.
Signed-off-by: Aditya Pakki
Reviewed-by: Richard Leitner
Signed-off-by: Greg Kroah-Hartman
Signed-off-by: Sasha Levin (Microsoft)
---
drivers/usb/misc/usb251xb.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/misc/usb251xb.c b/drivers/usb/misc/usb251xb.c
index 135c91c434bf..ba8fcdb377e8 100644
--- a/drivers/usb/misc/usb251xb.c
+++ b/drivers/usb/misc/usb251xb.c
@@ -530,7 +530,7 @@ static int usb251xb_probe(struct usb251xb *hub)
dev);
int err;
- if (np) {
+ if (np && of_id) {
err = usb251xb_get_ofdata(hub,
(struct usb251xb_data *)of_id->data);
if (err) {
--
2.19.1
[PATCH 4.14 39/49] scsi: qla4xxx: fix a potential NULL pointer dereference
[ Upstream commit fba1bdd2a9a93f3e2181ec1936a3c2f6b37e7ed6 ] In case iscsi_lookup_endpoint fails, the fix returns -EINVAL to avoid NULL pointer dereference. Signed-off-by: Kangjie Lu Acked-by: Manish Rangankar Reviewed-by: Mukesh Ojha Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin (Microsoft) --- drivers/scsi/qla4xxx/ql4_os.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/scsi/qla4xxx/ql4_os.c b/drivers/scsi/qla4xxx/ql4_os.c index 22dc70a2138e..630b7404843d 100644 --- a/drivers/scsi/qla4xxx/ql4_os.c +++ b/drivers/scsi/qla4xxx/ql4_os.c @@ -3207,6 +3207,8 @@ static int qla4xxx_conn_bind(struct iscsi_cls_session *cls_session, if (iscsi_conn_bind(cls_session, cls_conn, is_leading)) return -EINVAL; ep = iscsi_lookup_endpoint(transport_fd); + if (!ep) + return -EINVAL; conn = cls_conn->dd_data; qla_conn = conn->dd_data; qla_conn->qla_ep = ep->dd_data; -- 2.19.1
[PATCH 4.14 08/49] ARM: dts: bcm283x: Fix hdmi hpd gpio pull
[ Upstream commit 544e784188f1dd7c797c70b213385e67d92005b6 ]
Raspberry pi board model B revison 2 have the hot plug detector gpio
active high (and not low as it was in the dts).
Signed-off-by: Helen Koike
Fixes: 49ac67e0c39c ("ARM: bcm2835: Add VC4 to the device tree.")
Reviewed-by: Eric Anholt
Signed-off-by: Eric Anholt
Signed-off-by: Sasha Levin (Microsoft)
---
arch/arm/boot/dts/bcm2835-rpi-b-rev2.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/bcm2835-rpi-b-rev2.dts
b/arch/arm/boot/dts/bcm2835-rpi-b-rev2.dts
index 4bc70efe43d6..3178a5664942 100644
--- a/arch/arm/boot/dts/bcm2835-rpi-b-rev2.dts
+++ b/arch/arm/boot/dts/bcm2835-rpi-b-rev2.dts
@@ -93,7 +93,7 @@
};
&hdmi {
- hpd-gpios = <&gpio 46 GPIO_ACTIVE_LOW>;
+ hpd-gpios = <&gpio 46 GPIO_ACTIVE_HIGH>;
};
&uart0 {
--
2.19.1
[PATCH 4.14 05/49] mm: add try_get_page() helper function
From: Linus Torvalds
commit 88b1a17dfc3ed7728316478fae0f5ad508f50397 upstream.
This is the same as the traditional 'get_page()' function, but instead
of unconditionally incrementing the reference count of the page, it only
does so if the count was "safe". It returns whether the reference count
was incremented (and is marked __must_check, since the caller obviously
has to be aware of it).
Also like 'get_page()', you can't use this function unless you already
had a reference to the page. The intent is that you can use this
exactly like get_page(), but in situations where you want to limit the
maximum reference count.
The code currently does an unconditional WARN_ON_ONCE() if we ever hit
the reference count issues (either zero or negative), as a notification
that the conditional non-increment actually happened.
NOTE! The count access for the "safety" check is inherently racy, but
that doesn't matter since the buffer we use is basically half the range
of the reference count (ie we look at the sign of the count).
Acked-by: Matthew Wilcox
Cc: Jann Horn
Cc: sta...@kernel.org
Signed-off-by: Linus Torvalds
Signed-off-by: Greg Kroah-Hartman
---
include/linux/mm.h |9 +
1 file changed, 9 insertions(+)
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -839,6 +839,15 @@ static inline void get_page(struct page
page_ref_inc(page);
}
+static inline __must_check bool try_get_page(struct page *page)
+{
+ page = compound_head(page);
+ if (WARN_ON_ONCE(page_ref_count(page) <= 0))
+ return false;
+ page_ref_inc(page);
+ return true;
+}
+
static inline void put_page(struct page *page)
{
page = compound_head(page);
[PATCH 4.14 04/49] mm: make page ref count overflow check tighter and more explicit
From: Linus Torvalds
commit f958d7b528b1b40c44cfda5eabe2d82760d868c3 upstream.
We have a VM_BUG_ON() to check that the page reference count doesn't
underflow (or get close to overflow) by checking the sign of the count.
That's all fine, but we actually want to allow people to use a "get page
ref unless it's already very high" helper function, and we want that one
to use the sign of the page ref (without triggering this VM_BUG_ON).
Change the VM_BUG_ON to only check for small underflows (or _very_ close
to overflowing), and ignore overflows which have strayed into negative
territory.
Acked-by: Matthew Wilcox
Cc: Jann Horn
Cc: sta...@kernel.org
Signed-off-by: Linus Torvalds
Signed-off-by: Greg Kroah-Hartman
---
include/linux/mm.h |6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -824,6 +824,10 @@ static inline bool is_device_public_page
#endif /* CONFIG_DEVICE_PRIVATE || CONFIG_DEVICE_PUBLIC */
+/* 127: arbitrary random number, small enough to assemble well */
+#define page_ref_zero_or_close_to_overflow(page) \
+ ((unsigned int) page_ref_count(page) + 127u <= 127u)
+
static inline void get_page(struct page *page)
{
page = compound_head(page);
@@ -831,7 +835,7 @@ static inline void get_page(struct page
* Getting a normal page or the head of a compound page
* requires to already have an elevated page->_refcount.
*/
- VM_BUG_ON_PAGE(page_ref_count(page) <= 0, page);
+ VM_BUG_ON_PAGE(page_ref_zero_or_close_to_overflow(page), page);
page_ref_inc(page);
}
[PATCH 4.14 03/49] usbnet: ipheth: fix potential null pointer dereference in ipheth_carrier_set
From: Gustavo A. R. Silva
commit 61c59355e0154a938b28710dfa6c1d8be2ddcefa upstream.
_dev_ is being dereferenced before it is null checked, hence there
is a potential null pointer dereference.
Fix this by moving the pointer dereference after _dev_ has been null
checked.
Addresses-Coverity-ID: 1462020
Fixes: bb1b40c7cb86 ("usbnet: ipheth: prevent TX queue timeouts when device not
ready")
Signed-off-by: Gustavo A. R. Silva
Signed-off-by: David S. Miller
Signed-off-by: Guenter Roeck
Signed-off-by: Greg Kroah-Hartman
---
drivers/net/usb/ipheth.c |5 -
1 file changed, 4 insertions(+), 1 deletion(-)
--- a/drivers/net/usb/ipheth.c
+++ b/drivers/net/usb/ipheth.c
@@ -290,12 +290,15 @@ static void ipheth_sndbulk_callback(stru
static int ipheth_carrier_set(struct ipheth_device *dev)
{
- struct usb_device *udev = dev->udev;
+ struct usb_device *udev;
int retval;
+
if (!dev)
return 0;
if (!dev->confirmed_pairing)
return 0;
+
+ udev = dev->udev;
retval = usb_control_msg(udev,
usb_rcvctrlpipe(udev, IPHETH_CTRL_ENDP),
IPHETH_CMD_CARRIER_CHECK, /* request */
[PATCH 4.14 27/49] staging: rtl8712: uninitialized memory in read_bbreg_hdl()
[ Upstream commit 22c971db7dd4b0ad8dd88e99c407f7a1f4231a2e ]
Colin King reported a bug in read_bbreg_hdl():
memcpy(pcmd->rsp, (u8 *)&val, pcmd->rspsz);
The problem is that "val" is uninitialized.
This code is obviously not useful, but so far as I can tell
"pcmd->cmdcode" is never GEN_CMD_CODE(_Read_BBREG) so it's not harmful
either. For now the easiest fix is to just call r8712_free_cmd_obj()
and return.
Fixes: 2865d42c78a9 ("staging: r8712u: Add the new driver to the mainline
kernel")
Reported-by: Colin Ian King
Signed-off-by: Dan Carpenter
Signed-off-by: Greg Kroah-Hartman
Signed-off-by: Sasha Levin (Microsoft)
---
drivers/staging/rtl8712/rtl8712_cmd.c | 10 +-
drivers/staging/rtl8712/rtl8712_cmd.h | 2 +-
2 files changed, 2 insertions(+), 10 deletions(-)
diff --git a/drivers/staging/rtl8712/rtl8712_cmd.c
b/drivers/staging/rtl8712/rtl8712_cmd.c
index 0104aced113e..ccda04e916c5 100644
--- a/drivers/staging/rtl8712/rtl8712_cmd.c
+++ b/drivers/staging/rtl8712/rtl8712_cmd.c
@@ -159,17 +159,9 @@ static u8 write_macreg_hdl(struct _adapter *padapter, u8
*pbuf)
static u8 read_bbreg_hdl(struct _adapter *padapter, u8 *pbuf)
{
- u32 val;
- void (*pcmd_callback)(struct _adapter *dev, struct cmd_obj *pcmd);
struct cmd_obj *pcmd = (struct cmd_obj *)pbuf;
- if (pcmd->rsp && pcmd->rspsz > 0)
- memcpy(pcmd->rsp, (u8 *)&val, pcmd->rspsz);
- pcmd_callback = cmd_callback[pcmd->cmdcode].callback;
- if (!pcmd_callback)
- r8712_free_cmd_obj(pcmd);
- else
- pcmd_callback(padapter, pcmd);
+ r8712_free_cmd_obj(pcmd);
return H2C_SUCCESS;
}
diff --git a/drivers/staging/rtl8712/rtl8712_cmd.h
b/drivers/staging/rtl8712/rtl8712_cmd.h
index 67e9e910aef9..d10a59d4a550 100644
--- a/drivers/staging/rtl8712/rtl8712_cmd.h
+++ b/drivers/staging/rtl8712/rtl8712_cmd.h
@@ -152,7 +152,7 @@ enum rtl8712_h2c_cmd {
static struct _cmd_callbackcmd_callback[] = {
{GEN_CMD_CODE(_Read_MACREG), NULL}, /*0*/
{GEN_CMD_CODE(_Write_MACREG), NULL},
- {GEN_CMD_CODE(_Read_BBREG), &r8712_getbbrfreg_cmdrsp_callback},
+ {GEN_CMD_CODE(_Read_BBREG), NULL},
{GEN_CMD_CODE(_Write_BBREG), NULL},
{GEN_CMD_CODE(_Read_RFREG), &r8712_getbbrfreg_cmdrsp_callback},
{GEN_CMD_CODE(_Write_RFREG), NULL}, /*5*/
--
2.19.1
[PATCH 4.14 25/49] staging: rtl8188eu: Fix potential NULL pointer dereference of kcalloc
[ Upstream commit 7671ce0d92933762f469266daf43bd34d422d58c ]
hwxmits is allocated via kcalloc and not checked for failure before its
dereference. The patch fixes this problem by returning error upstream
in rtl8723bs, rtl8188eu.
Signed-off-by: Aditya Pakki
Acked-by: Mukesh Ojha
Reviewed-by: Hans de Goede
Signed-off-by: Greg Kroah-Hartman
Signed-off-by: Sasha Levin (Microsoft)
---
drivers/staging/rtl8188eu/core/rtw_xmit.c| 9 +++--
drivers/staging/rtl8188eu/include/rtw_xmit.h | 2 +-
drivers/staging/rtl8723bs/core/rtw_xmit.c| 14 +++---
drivers/staging/rtl8723bs/include/rtw_xmit.h | 2 +-
4 files changed, 16 insertions(+), 11 deletions(-)
diff --git a/drivers/staging/rtl8188eu/core/rtw_xmit.c
b/drivers/staging/rtl8188eu/core/rtw_xmit.c
index be2f46eb9f78..904b988ecc4e 100644
--- a/drivers/staging/rtl8188eu/core/rtw_xmit.c
+++ b/drivers/staging/rtl8188eu/core/rtw_xmit.c
@@ -188,7 +188,9 @@ s32 _rtw_init_xmit_priv(struct xmit_priv *pxmitpriv, struct
adapter *padapter)
pxmitpriv->free_xmit_extbuf_cnt = num_xmit_extbuf;
- rtw_alloc_hwxmits(padapter);
+ res = rtw_alloc_hwxmits(padapter);
+ if (res == _FAIL)
+ goto exit;
rtw_init_hwxmits(pxmitpriv->hwxmits, pxmitpriv->hwxmit_entry);
for (i = 0; i < 4; i++)
@@ -1573,7 +1575,7 @@ s32 rtw_xmit_classifier(struct adapter *padapter, struct
xmit_frame *pxmitframe)
return res;
}
-void rtw_alloc_hwxmits(struct adapter *padapter)
+s32 rtw_alloc_hwxmits(struct adapter *padapter)
{
struct hw_xmit *hwxmits;
struct xmit_priv *pxmitpriv = &padapter->xmitpriv;
@@ -1582,6 +1584,8 @@ void rtw_alloc_hwxmits(struct adapter *padapter)
pxmitpriv->hwxmits = kcalloc(pxmitpriv->hwxmit_entry,
sizeof(struct hw_xmit), GFP_KERNEL);
+ if (!pxmitpriv->hwxmits)
+ return _FAIL;
hwxmits = pxmitpriv->hwxmits;
@@ -1589,6 +1593,7 @@ void rtw_alloc_hwxmits(struct adapter *padapter)
hwxmits[1] .sta_queue = &pxmitpriv->vi_pending;
hwxmits[2] .sta_queue = &pxmitpriv->be_pending;
hwxmits[3] .sta_queue = &pxmitpriv->bk_pending;
+ return _SUCCESS;
}
void rtw_free_hwxmits(struct adapter *padapter)
diff --git a/drivers/staging/rtl8188eu/include/rtw_xmit.h
b/drivers/staging/rtl8188eu/include/rtw_xmit.h
index dd6b7a9a8d4a..1be4b478475a 100644
--- a/drivers/staging/rtl8188eu/include/rtw_xmit.h
+++ b/drivers/staging/rtl8188eu/include/rtw_xmit.h
@@ -342,7 +342,7 @@ s32 rtw_txframes_sta_ac_pending(struct adapter *padapter,
void rtw_init_hwxmits(struct hw_xmit *phwxmit, int entry);
s32 _rtw_init_xmit_priv(struct xmit_priv *pxmitpriv, struct adapter *padapter);
void _rtw_free_xmit_priv(struct xmit_priv *pxmitpriv);
-void rtw_alloc_hwxmits(struct adapter *padapter);
+s32 rtw_alloc_hwxmits(struct adapter *padapter);
void rtw_free_hwxmits(struct adapter *padapter);
s32 rtw_xmit(struct adapter *padapter, struct sk_buff **pkt);
diff --git a/drivers/staging/rtl8723bs/core/rtw_xmit.c
b/drivers/staging/rtl8723bs/core/rtw_xmit.c
index 022f654419e4..91dab7f8a739 100644
--- a/drivers/staging/rtl8723bs/core/rtw_xmit.c
+++ b/drivers/staging/rtl8723bs/core/rtw_xmit.c
@@ -271,7 +271,9 @@ s32 _rtw_init_xmit_priv(struct xmit_priv *pxmitpriv, struct
adapter *padapter)
}
}
- rtw_alloc_hwxmits(padapter);
+ res = rtw_alloc_hwxmits(padapter);
+ if (res == _FAIL)
+ goto exit;
rtw_init_hwxmits(pxmitpriv->hwxmits, pxmitpriv->hwxmit_entry);
for (i = 0; i < 4; i++) {
@@ -2157,7 +2159,7 @@ s32 rtw_xmit_classifier(struct adapter *padapter, struct
xmit_frame *pxmitframe)
return res;
}
-void rtw_alloc_hwxmits(struct adapter *padapter)
+s32 rtw_alloc_hwxmits(struct adapter *padapter)
{
struct hw_xmit *hwxmits;
struct xmit_priv *pxmitpriv = &padapter->xmitpriv;
@@ -2168,10 +2170,8 @@ void rtw_alloc_hwxmits(struct adapter *padapter)
pxmitpriv->hwxmits = (struct hw_xmit *)rtw_zmalloc(sizeof(struct
hw_xmit) * pxmitpriv->hwxmit_entry);
- if (pxmitpriv->hwxmits == NULL) {
- DBG_871X("alloc hwxmits fail!...\n");
- return;
- }
+ if (!pxmitpriv->hwxmits)
+ return _FAIL;
hwxmits = pxmitpriv->hwxmits;
@@ -2217,7 +2217,7 @@ void rtw_alloc_hwxmits(struct adapter *padapter)
}
-
+ return _SUCCESS;
}
void rtw_free_hwxmits(struct adapter *padapter)
diff --git a/drivers/staging/rtl8723bs/include/rtw_xmit.h
b/drivers/staging/rtl8723bs/include/rtw_xmit.h
index 11571649cd2c..92236ca8a1ef 100644
--- a/drivers/staging/rtl8723bs/include/rtw_xmit.h
+++ b/drivers/staging/rtl8723bs/include/rtw_xmit.h
@@ -494,7 +494,7 @@ s32 _rtw_init_xmit_priv(struct xmit_priv *pxmitpriv, struct
adapter *padapter);
void _rtw_free_xmit_priv (struct xmit_priv *pxmitpriv);
-void rtw_alloc_hwxmits(struct adapter *padapter);
+s32 rtw_allo
[PATCH 4.14 24/49] net: ks8851: Set initial carrier state to down
[ Upstream commit 9624bafa5f6418b9ca5b3f66d1f6a6a2e8bf6d4c ] The ks8851 chip's initial carrier state is down. A Link Change Interrupt is signaled once interrupts are enabled if the carrier is up. The ks8851 driver has it backwards by assuming that the initial carrier state is up. The state is therefore misrepresented if the interface is opened with no cable attached. Fix it. The Link Change interrupt is sometimes not signaled unless the P1MBSR register (which contains the Link Status bit) is read on ->ndo_open(). This might be a hardware erratum. Read the register by calling mii_check_link(), which has the desirable side effect of setting the carrier state to down if the cable was detached while the interface was closed. Signed-off-by: Lukas Wunner Cc: Frank Pavlic Cc: Ben Dooks Cc: Tristram Ha Signed-off-by: David S. Miller Signed-off-by: Sasha Levin (Microsoft) --- drivers/net/ethernet/micrel/ks8851.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/net/ethernet/micrel/ks8851.c b/drivers/net/ethernet/micrel/ks8851.c index b8f20aa2b7ad..7ddaa7d88f1d 100644 --- a/drivers/net/ethernet/micrel/ks8851.c +++ b/drivers/net/ethernet/micrel/ks8851.c @@ -849,6 +849,7 @@ static int ks8851_net_open(struct net_device *dev) netif_dbg(ks, ifup, ks->netdev, "network device up\n"); mutex_unlock(&ks->lock); + mii_check_link(&ks->mii); return 0; } @@ -1510,6 +1511,7 @@ static int ks8851_probe(struct spi_device *spi) spi_set_drvdata(spi, ks); + netif_carrier_off(ks->netdev); ndev->if_port = IF_PORT_100BASET; ndev->netdev_ops = &ks8851_netdev_ops; ndev->irq = spi->irq; -- 2.19.1
[PATCH 4.14 22/49] net: ks8851: Reassert reset pin if chip ID check fails
[ Upstream commit 761cfa979a0c177d6c2d93ef5585cd79ae49a7d5 ]
Commit 73fdeb82e963 ("net: ks8851: Add optional vdd_io regulator and
reset gpio") amended the ks8851 driver to briefly assert the chip's
reset pin on probe. It also amended the probe routine's error path to
reassert the reset pin if a subsequent initialization step fails.
However the commit misplaced reassertion of the reset pin in the error
path such that it is not performed if the check of the Chip ID and
Enable Register (CIDER) fails. The error path is therefore slightly
asymmetrical to the probe routine's body. Fix it.
Signed-off-by: Lukas Wunner
Cc: Frank Pavlic
Cc: Stephen Boyd
Cc: Nishanth Menon
Signed-off-by: David S. Miller
Signed-off-by: Sasha Levin (Microsoft)
---
drivers/net/ethernet/micrel/ks8851.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/micrel/ks8851.c
b/drivers/net/ethernet/micrel/ks8851.c
index 55b0d756..546a79b9cb15 100644
--- a/drivers/net/ethernet/micrel/ks8851.c
+++ b/drivers/net/ethernet/micrel/ks8851.c
@@ -1545,9 +1545,9 @@ static int ks8851_probe(struct spi_device *spi)
free_irq(ndev->irq, ks);
err_irq:
+err_id:
if (gpio_is_valid(gpio))
gpio_set_value(gpio, 0);
-err_id:
regulator_disable(ks->vdd_reg);
err_reg:
regulator_disable(ks->vdd_io);
--
2.19.1
[PATCH 4.14 23/49] net: ks8851: Delay requesting IRQ until opened
[ Upstream commit d268f31552794abf5b6aa5af31021643411f25f5 ]
The ks8851 driver currently requests the IRQ before registering the
net_device. Because the net_device name is used as IRQ name and is
still "eth%d" when the IRQ is requested, it's impossibe to tell IRQs
apart if multiple ks8851 chips are present. Most other drivers delay
requesting the IRQ until the net_device is opened. Do the same.
The driver doesn't enable interrupts on the chip before opening the
net_device and disables them when closing it, so there doesn't seem to
be a need to request the IRQ already on probe.
Signed-off-by: Lukas Wunner
Cc: Frank Pavlic
Cc: Ben Dooks
Cc: Tristram Ha
Signed-off-by: David S. Miller
Signed-off-by: Sasha Levin (Microsoft)
---
drivers/net/ethernet/micrel/ks8851.c | 24 +++-
1 file changed, 11 insertions(+), 13 deletions(-)
diff --git a/drivers/net/ethernet/micrel/ks8851.c
b/drivers/net/ethernet/micrel/ks8851.c
index 546a79b9cb15..b8f20aa2b7ad 100644
--- a/drivers/net/ethernet/micrel/ks8851.c
+++ b/drivers/net/ethernet/micrel/ks8851.c
@@ -776,6 +776,15 @@ static void ks8851_tx_work(struct work_struct *work)
static int ks8851_net_open(struct net_device *dev)
{
struct ks8851_net *ks = netdev_priv(dev);
+ int ret;
+
+ ret = request_threaded_irq(dev->irq, NULL, ks8851_irq,
+ IRQF_TRIGGER_LOW | IRQF_ONESHOT,
+ dev->name, ks);
+ if (ret < 0) {
+ netdev_err(dev, "failed to get irq\n");
+ return ret;
+ }
/* lock the card, even if we may not actually be doing anything
* else at the moment */
@@ -890,6 +899,8 @@ static int ks8851_net_stop(struct net_device *dev)
dev_kfree_skb(txb);
}
+ free_irq(dev->irq, ks);
+
return 0;
}
@@ -1520,14 +1531,6 @@ static int ks8851_probe(struct spi_device *spi)
ks8851_read_selftest(ks);
ks8851_init_mac(ks);
- ret = request_threaded_irq(spi->irq, NULL, ks8851_irq,
- IRQF_TRIGGER_LOW | IRQF_ONESHOT,
- ndev->name, ks);
- if (ret < 0) {
- dev_err(&spi->dev, "failed to get irq\n");
- goto err_irq;
- }
-
ret = register_netdev(ndev);
if (ret) {
dev_err(&spi->dev, "failed to register network device\n");
@@ -1540,11 +1543,7 @@ static int ks8851_probe(struct spi_device *spi)
return 0;
-
err_netdev:
- free_irq(ndev->irq, ks);
-
-err_irq:
err_id:
if (gpio_is_valid(gpio))
gpio_set_value(gpio, 0);
@@ -1565,7 +1564,6 @@ static int ks8851_remove(struct spi_device *spi)
dev_info(&spi->dev, "remove\n");
unregister_netdev(priv->netdev);
- free_irq(spi->irq, priv);
if (gpio_is_valid(priv->gpio))
gpio_set_value(priv->gpio, 0);
regulator_disable(priv->vdd_reg);
--
2.19.1
[PATCH 4.14 16/49] KVM: arm/arm64: vgic-its: Take the srcu lock when parsing the memslots
[ Upstream commit 7494cec6cb3ba7385a6a223b81906384f15aae34 ]
Calling kvm_is_visible_gfn() implies that we're parsing the memslots,
and doing this without the srcu lock is frown upon:
[12704.164532] =
[12704.164544] WARNING: suspicious RCU usage
[12704.164560] 5.1.0-rc1-8-g600025238f51-dirty #16 Tainted: GW
[12704.164573] -
[12704.164589] ./include/linux/kvm_host.h:605 suspicious
rcu_dereference_check() usage!
[12704.164602] other info that might help us debug this:
[12704.164616] rcu_scheduler_active = 2, debug_locks = 1
[12704.164631] 6 locks held by qemu-system-aar/13968:
[12704.164644] #0: 7ebdae4f (&kvm->lock){+.+.}, at:
vgic_its_set_attr+0x244/0x3a0
[12704.164691] #1: 7d751022 (&its->its_lock){+.+.}, at:
vgic_its_set_attr+0x250/0x3a0
[12704.164726] #2: 219d2706 (&vcpu->mutex){+.+.}, at:
lock_all_vcpus+0x64/0xd0
[12704.164761] #3: a760aecd (&vcpu->mutex){+.+.}, at:
lock_all_vcpus+0x64/0xd0
[12704.164794] #4: 0ef8e31d (&vcpu->mutex){+.+.}, at:
lock_all_vcpus+0x64/0xd0
[12704.164827] #5: 7a872093 (&vcpu->mutex){+.+.}, at:
lock_all_vcpus+0x64/0xd0
[12704.164861] stack backtrace:
[12704.164878] CPU: 2 PID: 13968 Comm: qemu-system-aar Tainted: GW
5.1.0-rc1-8-g600025238f51-dirty #16
[12704.164887] Hardware name: rockchip evb_rk3399/evb_rk3399, BIOS
2019.04-rc3-00124-g2feec69fb1 03/15/2019
[12704.164896] Call trace:
[12704.164910] dump_backtrace+0x0/0x138
[12704.164920] show_stack+0x24/0x30
[12704.164934] dump_stack+0xbc/0x104
[12704.164946] lockdep_rcu_suspicious+0xcc/0x110
[12704.164958] gfn_to_memslot+0x174/0x190
[12704.164969] kvm_is_visible_gfn+0x28/0x70
[12704.164980] vgic_its_check_id.isra.0+0xec/0x1e8
[12704.164991] vgic_its_save_tables_v0+0x1ac/0x330
[12704.165001] vgic_its_set_attr+0x298/0x3a0
[12704.165012] kvm_device_ioctl_attr+0x9c/0xd8
[12704.165022] kvm_device_ioctl+0x8c/0xf8
[12704.165035] do_vfs_ioctl+0xc8/0x960
[12704.165045] ksys_ioctl+0x8c/0xa0
[12704.165055] __arm64_sys_ioctl+0x28/0x38
[12704.165067] el0_svc_common+0xd8/0x138
[12704.165078] el0_svc_handler+0x38/0x78
[12704.165089] el0_svc+0x8/0xc
Make sure the lock is taken when doing this.
Fixes: bf308242ab98 ("KVM: arm/arm64: VGIC/ITS: protect kvm_read_guest() calls
with SRCU lock")
Reviewed-by: Eric Auger
Signed-off-by: Marc Zyngier
Signed-off-by: Sasha Levin (Microsoft)
---
virt/kvm/arm/vgic/vgic-its.c | 13 ++---
1 file changed, 10 insertions(+), 3 deletions(-)
diff --git a/virt/kvm/arm/vgic/vgic-its.c b/virt/kvm/arm/vgic/vgic-its.c
index d72b8481f250..dc06f5e40041 100644
--- a/virt/kvm/arm/vgic/vgic-its.c
+++ b/virt/kvm/arm/vgic/vgic-its.c
@@ -704,8 +704,9 @@ static bool vgic_its_check_id(struct vgic_its *its, u64
baser, u32 id,
int l1_tbl_size = GITS_BASER_NR_PAGES(baser) * SZ_64K;
u64 indirect_ptr, type = GITS_BASER_TYPE(baser);
int esz = GITS_BASER_ENTRY_SIZE(baser);
- int index;
+ int index, idx;
gfn_t gfn;
+ bool ret;
switch (type) {
case GITS_BASER_TYPE_DEVICE:
@@ -732,7 +733,8 @@ static bool vgic_its_check_id(struct vgic_its *its, u64
baser, u32 id,
if (eaddr)
*eaddr = addr;
- return kvm_is_visible_gfn(its->dev->kvm, gfn);
+
+ goto out;
}
/* calculate and check the index into the 1st level */
@@ -766,7 +768,12 @@ static bool vgic_its_check_id(struct vgic_its *its, u64
baser, u32 id,
if (eaddr)
*eaddr = indirect_ptr;
- return kvm_is_visible_gfn(its->dev->kvm, gfn);
+
+out:
+ idx = srcu_read_lock(&its->dev->kvm->srcu);
+ ret = kvm_is_visible_gfn(its->dev->kvm, gfn);
+ srcu_read_unlock(&its->dev->kvm->srcu, idx);
+ return ret;
}
static int vgic_its_alloc_collection(struct vgic_its *its,
--
2.19.1
[PATCH 4.14 18/49] usb: gadget: net2280: Fix net2280_dequeue()
[ Upstream commit f1d3fba17cd4eeea20397f1324b7b9c69a6a935c ]
When a request must be dequeued with net2280_dequeue() e.g. due
to a device clear action and the same request is finished by the
function scan_dma_completions() then the function net2280_dequeue()
does not find the request in the following search loop and
returns the error -EINVAL without restoring the status ep->stopped.
Thus the endpoint keeps blocked and does not receive any data
anymore.
This fix restores the status and does not issue an error message.
Acked-by: Alan Stern
Signed-off-by: Guido Kiener
Signed-off-by: Felipe Balbi
Signed-off-by: Sasha Levin (Microsoft)
---
drivers/usb/gadget/udc/net2280.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/gadget/udc/net2280.c b/drivers/usb/gadget/udc/net2280.c
index a071ab0c163b..170327f84ea1 100644
--- a/drivers/usb/gadget/udc/net2280.c
+++ b/drivers/usb/gadget/udc/net2280.c
@@ -1277,9 +1277,9 @@ static int net2280_dequeue(struct usb_ep *_ep, struct
usb_request *_req)
break;
}
if (&req->req != _req) {
+ ep->stopped = stopped;
spin_unlock_irqrestore(&ep->dev->lock, flags);
- dev_err(&ep->dev->pdev->dev, "%s: Request mismatch\n",
- __func__);
+ ep_dbg(ep->dev, "%s: Request mismatch\n", __func__);
return -EINVAL;
}
--
2.19.1
[PATCH 4.14 19/49] usb: gadget: net2272: Fix net2272_dequeue()
[ Upstream commit 091dacc3cc10979ab0422f0a9f7fcc27eee97e69 ]
Restore the status of ep->stopped in function net2272_dequeue().
When the given request is not found in the endpoint queue
the function returns -EINVAL without restoring the state of
ep->stopped. Thus the endpoint keeps blocked and does not transfer
any data anymore.
This fix is only compile-tested, since we do not have a
corresponding hardware. An analogous fix was tested in the sibling
driver. See "usb: gadget: net2280: Fix net2280_dequeue()"
Acked-by: Alan Stern
Signed-off-by: Guido Kiener
Signed-off-by: Felipe Balbi
Signed-off-by: Sasha Levin (Microsoft)
---
drivers/usb/gadget/udc/net2272.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/usb/gadget/udc/net2272.c b/drivers/usb/gadget/udc/net2272.c
index e0759a826b60..7fb31a3b53e6 100644
--- a/drivers/usb/gadget/udc/net2272.c
+++ b/drivers/usb/gadget/udc/net2272.c
@@ -958,6 +958,7 @@ net2272_dequeue(struct usb_ep *_ep, struct usb_request
*_req)
break;
}
if (&req->req != _req) {
+ ep->stopped = stopped;
spin_unlock_irqrestore(&ep->dev->lock, flags);
return -EINVAL;
}
--
2.19.1
[PATCH 4.14 02/49] usbnet: ipheth: prevent TX queue timeouts when device not ready
From: Alexander Kappner
commit bb1b40c7cb863f0800a6410c7dcb86cf3f28d3b1 upstream.
iOS devices require the host to be "trusted" before servicing network
packets. Establishing trust requires the user to confirm a dialog on the
iOS device.Until trust is established, the iOS device will silently discard
network packets from the host. Currently, the ipheth driver does not detect
whether an iOS device has established trust with the host, and immediately
sets up the transmit queues.
This causes the following problems:
- Kernel taint due to WARN() in netdev watchdog.
- Dmesg spam ("TX timeout").
- Disruption of user space networking activity (dhcpd, etc...) when new
interface comes up but cannot be used.
- Unnecessary host and device wakeups and USB traffic
Example dmesg output:
[ 1101.319778] NETDEV WATCHDOG: eth1 (ipheth): transmit queue 0 timed out
[ 1101.319817] [ cut here ]
[ 1101.319828] WARNING: CPU: 0 PID: 0 at net/sched/sch_generic.c:316
dev_watchdog+0x20f/0x220
[ 1101.319831] Modules linked in: ipheth usbmon nvidia_drm(PO)
nvidia_modeset(PO) nvidia(PO) iwlmvm mac80211 iwlwifi btusb btrtl btbcm btintel
qmi_wwan bluetooth cfg80211 ecdh_generic thinkpad_acpi rfkill [last unloaded:
ipheth]
[ 1101.319861] CPU: 0 PID: 0 Comm: swapper/0 Tainted: P O
4.13.12.1 #1
[ 1101.319864] Hardware name: LENOVO 20ENCTO1WW/20ENCTO1WW, BIOS N1EET62W (1.35
) 11/10/2016
[ 1101.319867] task: 81e11500 task.stack: 81e0
[ 1101.319873] RIP: 0010:dev_watchdog+0x20f/0x220
[ 1101.319876] RSP: 0018:8810a3c03e98 EFLAGS: 00010292
[ 1101.319880] RAX: 003a RBX: RCX:
[ 1101.319883] RDX: 8810a3c15c48 RSI: 81ccbfc2 RDI:
[ 1101.319886] RBP: 880c04ebc41c R08: R09: 0379
[ 1101.319889] R10: 0100696589d0 R11: 0378 R12: 880c04ebc000
[ 1101.319892] R13: R14: 0001 R15: 880c2865fc80
[ 1101.319896] FS: () GS:8810a3c0()
knlGS:
[ 1101.319899] CS: 0010 DS: ES: CR0: 80050033
[ 1101.319902] CR2: 7f3ff24ac000 CR3: 01e0a000 CR4: 003406f0
[ 1101.319905] DR0: DR1: DR2:
[ 1101.319908] DR3: DR6: fffe0ff0 DR7: 0400
[ 1101.319910] Call Trace:
[ 1101.319914]
[ 1101.319921] ? dev_graft_qdisc+0x70/0x70
[ 1101.319928] ? dev_graft_qdisc+0x70/0x70
[ 1101.319934] ? call_timer_fn+0x2e/0x170
[ 1101.319939] ? dev_graft_qdisc+0x70/0x70
[ 1101.319944] ? run_timer_softirq+0x1ea/0x440
[ 1101.319951] ? timerqueue_add+0x54/0x80
[ 1101.319956] ? enqueue_hrtimer+0x38/0xa0
[ 1101.319963] ? __do_softirq+0xed/0x2e7
[ 1101.319970] ? irq_exit+0xb4/0xc0
[ 1101.319976] ? smp_apic_timer_interrupt+0x39/0x50
[ 1101.319981] ? apic_timer_interrupt+0x8c/0xa0
[ 1101.319983]
[ 1101.319992] ? cpuidle_enter_state+0xfa/0x2a0
[ 1101.31] ? do_idle+0x1a3/0x1f0
[ 1101.320004] ? cpu_startup_entry+0x5f/0x70
[ 1101.320011] ? start_kernel+0x444/0x44c
[ 1101.320017] ? early_idt_handler_array+0x120/0x120
[ 1101.320023] ? x86_64_start_kernel+0x145/0x154
[ 1101.320028] ? secondary_startup_64+0x9f/0x9f
[ 1101.320033] Code: 20 04 00 00 eb 9f 4c 89 e7 c6 05 59 44 71 00 01 e8 a7 df
fd ff 89 d9 4c 89 e6 48 c7 c7 70 b7 cd 81 48 89 c2 31 c0 e8 97 64 90 ff <0f> ff
eb bf 66 66 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00
[ 1101.320103] ---[ end trace 0cc4d251e2b57080 ]---
[ 1101.320110] ipheth 1-5:4.2: ipheth_tx_timeout: TX timeout
The last message "TX timeout" is repeated every 5 seconds until trust is
established or the device is disconnected, filling up dmesg.
The proposed patch eliminates the problem by, upon connection, keeping the
TX queue and carrier disabled until a packet is first received from the iOS
device. This is reflected by the confirmed_pairing variable in the device
structure. Only after at least one packet has been received from the iOS
device, the transmit queue and carrier are brought up during the periodic
device poll in ipheth_carrier_set. Because the iOS device will always send
a packet immediately upon trust being established, this should not delay
the interface becoming useable. To prevent failed UBRs in
ipheth_rcvbulk_callback from perpetually re-enabling the queue if it was
disabled, a new check is added so only successful transfers re-enable the
queue, whereas failed transfers only trigger an immediate poll.
This has the added benefit of removing the periodic control requests to the
iOS device until trust has been established and thus should reduce wakeup
events on both the host and the iOS device.
Signed-off-by: Alexander Kappner
Signed-off-by: David S. Miller
[groeck: Fixed context conflict seen because 45611c61dd50 was applied first]
Signed-off-by: Guenter Roeck
Signed-off-by: Greg Kroah-Hartman
---
drivers/net/usb/ipheth.c | 30 +++
[PATCH 4.14 15/49] serial: ar933x_uart: Fix build failure with disabled console
[ Upstream commit 72ff51d8dd262d1fef25baedc2ac35116435be47 ]
Andrey has reported on OpenWrt's bug tracking system[1], that he
currently can't use ar93xx_uart as pure serial UART without console
(CONFIG_SERIAL_8250_CONSOLE and CONFIG_SERIAL_AR933X_CONSOLE undefined),
because compilation ends with following error:
ar933x_uart.c: In function 'ar933x_uart_console_write':
ar933x_uart.c:550:14: error: 'struct uart_port' has no
member named 'sysrq'
So this patch moves all the code related to console handling behind
series of CONFIG_SERIAL_AR933X_CONSOLE ifdefs.
1. https://bugs.openwrt.org/index.php?do=details&task_id=2152
Cc: Greg Kroah-Hartman
Cc: Jiri Slaby
Cc: Andrey Batyiev
Reported-by: Andrey Batyiev
Tested-by: Andrey Batyiev
Signed-off-by: Petr Štetiar
Signed-off-by: Greg Kroah-Hartman
Signed-off-by: Sasha Levin (Microsoft)
---
drivers/tty/serial/ar933x_uart.c | 24
1 file changed, 8 insertions(+), 16 deletions(-)
diff --git a/drivers/tty/serial/ar933x_uart.c b/drivers/tty/serial/ar933x_uart.c
index decc7f3c1ab2..ed545a61413c 100644
--- a/drivers/tty/serial/ar933x_uart.c
+++ b/drivers/tty/serial/ar933x_uart.c
@@ -52,11 +52,6 @@ struct ar933x_uart_port {
struct clk *clk;
};
-static inline bool ar933x_uart_console_enabled(void)
-{
- return IS_ENABLED(CONFIG_SERIAL_AR933X_CONSOLE);
-}
-
static inline unsigned int ar933x_uart_read(struct ar933x_uart_port *up,
int offset)
{
@@ -511,6 +506,7 @@ static const struct uart_ops ar933x_uart_ops = {
.verify_port= ar933x_uart_verify_port,
};
+#ifdef CONFIG_SERIAL_AR933X_CONSOLE
static struct ar933x_uart_port *
ar933x_console_ports[CONFIG_SERIAL_AR933X_NR_UARTS];
@@ -607,14 +603,7 @@ static struct console ar933x_uart_console = {
.index = -1,
.data = &ar933x_uart_driver,
};
-
-static void ar933x_uart_add_console_port(struct ar933x_uart_port *up)
-{
- if (!ar933x_uart_console_enabled())
- return;
-
- ar933x_console_ports[up->port.line] = up;
-}
+#endif /* CONFIG_SERIAL_AR933X_CONSOLE */
static struct uart_driver ar933x_uart_driver = {
.owner = THIS_MODULE,
@@ -703,7 +692,9 @@ static int ar933x_uart_probe(struct platform_device *pdev)
baud = ar933x_uart_get_baud(port->uartclk, 0, AR933X_UART_MAX_STEP);
up->max_baud = min_t(unsigned int, baud, AR933X_UART_MAX_BAUD);
- ar933x_uart_add_console_port(up);
+#ifdef CONFIG_SERIAL_AR933X_CONSOLE
+ ar933x_console_ports[up->port.line] = up;
+#endif
ret = uart_add_one_port(&ar933x_uart_driver, &up->port);
if (ret)
@@ -752,8 +743,9 @@ static int __init ar933x_uart_init(void)
{
int ret;
- if (ar933x_uart_console_enabled())
- ar933x_uart_driver.cons = &ar933x_uart_console;
+#ifdef CONFIG_SERIAL_AR933X_CONSOLE
+ ar933x_uart_driver.cons = &ar933x_uart_console;
+#endif
ret = uart_register_driver(&ar933x_uart_driver);
if (ret)
--
2.19.1
[PATCH 4.14 20/49] ARM: dts: pfla02: increase phy reset duration
[ Upstream commit 032f85c9360fb1a08385c584c2c4ed114b33c260 ]
Increase the reset duration to ensure correct phy functionality. The
reset duration is taken from barebox commit 52fdd510de ("ARM: dts:
pfla02: use long enough reset for ethernet phy"):
Use a longer reset time for ethernet phy Micrel KSZ9031RNX. Otherwise a
small percentage of modules have 'transmission timeouts' errors like
barebox@Phytec phyFLEX-i.MX6 Quad Carrier-Board:/ ifup eth0
warning: No MAC address set. Using random address 7e:94:4d:02:f8:f3
eth0: 1000Mbps full duplex link detected
eth0: transmission timeout
T eth0: transmission timeout
T eth0: transmission timeout
T eth0: transmission timeout
T eth0: transmission timeout
Cc: Stefan Christ
Cc: Christian Hemp
Signed-off-by: Marco Felsch
Fixes: 3180f956668e ("ARM: dts: Phytec imx6q pfla02 and pbab01 support")
Signed-off-by: Shawn Guo
Signed-off-by: Sasha Levin (Microsoft)
---
arch/arm/boot/dts/imx6qdl-phytec-pfla02.dtsi | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/boot/dts/imx6qdl-phytec-pfla02.dtsi
b/arch/arm/boot/dts/imx6qdl-phytec-pfla02.dtsi
index d81b0078a100..25b0704c6054 100644
--- a/arch/arm/boot/dts/imx6qdl-phytec-pfla02.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-phytec-pfla02.dtsi
@@ -89,6 +89,7 @@
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_enet>;
phy-mode = "rgmii";
+ phy-reset-duration = <10>; /* in msecs */
phy-reset-gpios = <&gpio3 23 GPIO_ACTIVE_LOW>;
phy-supply = <&vdd_eth_io_reg>;
status = "disabled";
--
2.19.1
[PATCH 4.9 16/32] net: ks8851: Reassert reset pin if chip ID check fails
[ Upstream commit 761cfa979a0c177d6c2d93ef5585cd79ae49a7d5 ]
Commit 73fdeb82e963 ("net: ks8851: Add optional vdd_io regulator and
reset gpio") amended the ks8851 driver to briefly assert the chip's
reset pin on probe. It also amended the probe routine's error path to
reassert the reset pin if a subsequent initialization step fails.
However the commit misplaced reassertion of the reset pin in the error
path such that it is not performed if the check of the Chip ID and
Enable Register (CIDER) fails. The error path is therefore slightly
asymmetrical to the probe routine's body. Fix it.
Signed-off-by: Lukas Wunner
Cc: Frank Pavlic
Cc: Stephen Boyd
Cc: Nishanth Menon
Signed-off-by: David S. Miller
Signed-off-by: Sasha Levin (Microsoft)
---
drivers/net/ethernet/micrel/ks8851.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/micrel/ks8851.c
b/drivers/net/ethernet/micrel/ks8851.c
index 247a3377b951..a8c5641ff955 100644
--- a/drivers/net/ethernet/micrel/ks8851.c
+++ b/drivers/net/ethernet/micrel/ks8851.c
@@ -1567,9 +1567,9 @@ static int ks8851_probe(struct spi_device *spi)
free_irq(ndev->irq, ks);
err_irq:
+err_id:
if (gpio_is_valid(gpio))
gpio_set_value(gpio, 0);
-err_id:
regulator_disable(ks->vdd_reg);
err_reg:
regulator_disable(ks->vdd_io);
--
2.19.1
[PATCH 4.9 15/32] net: ks8851: Dequeue RX packets explicitly
[ Upstream commit 536d3680fd2dab5c39857d62a3e084198fc74ff9 ]
The ks8851 driver lets the chip auto-dequeue received packets once they
have been read in full. It achieves that by setting the ADRFE flag in
the RXQCR register ("Auto-Dequeue RXQ Frame Enable").
However if allocation of a packet's socket buffer or retrieval of the
packet over the SPI bus fails, the packet will not have been read in
full and is not auto-dequeued. Such partial retrieval of a packet
confuses the chip's RX queue management: On the next RX interrupt,
the first packet read from the queue will be the one left there
previously and this one can be retrieved without issues. But for any
newly received packets, the frame header status and byte count registers
(RXFHSR and RXFHBCR) contain bogus values, preventing their retrieval.
The chip allows explicitly dequeueing a packet from the RX queue by
setting the RRXEF flag in the RXQCR register ("Release RX Error Frame").
This could be used to dequeue the packet in case of an error, but if
that error is a failed SPI transfer, it is unknown if the packet was
transferred in full and was auto-dequeued or if it was only transferred
in part and requires an explicit dequeue. The safest approach is thus
to always dequeue packets explicitly and forgo auto-dequeueing.
Without this change, I've witnessed packet retrieval break completely
when an SPI DMA transfer fails, requiring a chip reset. Explicit
dequeueing magically fixes this and makes packet retrieval absolutely
robust for me.
The chip's documentation suggests auto-dequeuing and uses the RRXEF
flag only to dequeue error frames which the driver doesn't want to
retrieve. But that seems to be a fair-weather approach.
Signed-off-by: Lukas Wunner
Cc: Frank Pavlic
Cc: Ben Dooks
Cc: Tristram Ha
Signed-off-by: David S. Miller
Signed-off-by: Sasha Levin (Microsoft)
---
drivers/net/ethernet/micrel/ks8851.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/micrel/ks8851.c
b/drivers/net/ethernet/micrel/ks8851.c
index 1edc973df4c4..247a3377b951 100644
--- a/drivers/net/ethernet/micrel/ks8851.c
+++ b/drivers/net/ethernet/micrel/ks8851.c
@@ -547,9 +547,8 @@ static void ks8851_rx_pkts(struct ks8851_net *ks)
/* set dma read address */
ks8851_wrreg16(ks, KS_RXFDPR, RXFDPR_RXFPAI | 0x00);
- /* start the packet dma process, and set auto-dequeue rx */
- ks8851_wrreg16(ks, KS_RXQCR,
- ks->rc_rxqcr | RXQCR_SDA | RXQCR_ADRFE);
+ /* start DMA access */
+ ks8851_wrreg16(ks, KS_RXQCR, ks->rc_rxqcr | RXQCR_SDA);
if (rxlen > 4) {
unsigned int rxalign;
@@ -580,7 +579,8 @@ static void ks8851_rx_pkts(struct ks8851_net *ks)
}
}
- ks8851_wrreg16(ks, KS_RXQCR, ks->rc_rxqcr);
+ /* end DMA access and dequeue packet */
+ ks8851_wrreg16(ks, KS_RXQCR, ks->rc_rxqcr | RXQCR_RRXEF);
}
}
--
2.19.1
[PATCH 4.9 30/32] kconfig/[mn]conf: handle backspace (^H) key
[ Upstream commit 9c38f1f044080392603c497ecca4d7d09876ff99 ]
Backspace is not working on some terminal emulators which do not send the
key code defined by terminfo. Terminals either send '^H' (8) or '^?' (127).
But currently only '^?' is handled. Let's also handle '^H' for those
terminals.
Signed-off-by: Changbin Du
Signed-off-by: Masahiro Yamada
Signed-off-by: Sasha Levin (Microsoft)
---
scripts/kconfig/lxdialog/inputbox.c | 3 ++-
scripts/kconfig/nconf.c | 2 +-
scripts/kconfig/nconf.gui.c | 3 ++-
3 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/scripts/kconfig/lxdialog/inputbox.c
b/scripts/kconfig/lxdialog/inputbox.c
index d58de1dc5360..510049a7bd1d 100644
--- a/scripts/kconfig/lxdialog/inputbox.c
+++ b/scripts/kconfig/lxdialog/inputbox.c
@@ -126,7 +126,8 @@ int dialog_inputbox(const char *title, const char *prompt,
int height, int width
case KEY_DOWN:
break;
case KEY_BACKSPACE:
- case 127:
+ case 8: /* ^H */
+ case 127: /* ^? */
if (pos) {
wattrset(dialog, dlg.inputbox.atr);
if (input_x == 0) {
diff --git a/scripts/kconfig/nconf.c b/scripts/kconfig/nconf.c
index d42d534a66cd..f7049e288e93 100644
--- a/scripts/kconfig/nconf.c
+++ b/scripts/kconfig/nconf.c
@@ -1046,7 +1046,7 @@ static int do_match(int key, struct match_state *state,
int *ans)
state->match_direction = FIND_NEXT_MATCH_UP;
*ans = get_mext_match(state->pattern,
state->match_direction);
- } else if (key == KEY_BACKSPACE || key == 127) {
+ } else if (key == KEY_BACKSPACE || key == 8 || key == 127) {
state->pattern[strlen(state->pattern)-1] = '\0';
adj_match_dir(&state->match_direction);
} else
diff --git a/scripts/kconfig/nconf.gui.c b/scripts/kconfig/nconf.gui.c
index 4b2f44c20caf..9a65035cf787 100644
--- a/scripts/kconfig/nconf.gui.c
+++ b/scripts/kconfig/nconf.gui.c
@@ -439,7 +439,8 @@ int dialog_inputbox(WINDOW *main_window,
case KEY_F(F_EXIT):
case KEY_F(F_BACK):
break;
- case 127:
+ case 8: /* ^H */
+ case 127: /* ^? */
case KEY_BACKSPACE:
if (cursor_position > 0) {
memmove(&result[cursor_position-1],
--
2.19.1
[PATCH 4.9 31/32] leds: pca9532: fix a potential NULL pointer dereference
[ Upstream commit 0aab8e4df4702b31314a27ec4b0631dfad0fae0a ]
In case of_match_device cannot find a match, return -EINVAL to avoid
NULL pointer dereference.
Fixes: fa4191a609f2 ("leds: pca9532: Add device tree support")
Signed-off-by: Kangjie Lu
Signed-off-by: Jacek Anaszewski
Signed-off-by: Sasha Levin (Microsoft)
---
drivers/leds/leds-pca9532.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/leds/leds-pca9532.c b/drivers/leds/leds-pca9532.c
index 09a7cffbc46f..896b38f6f9c0 100644
--- a/drivers/leds/leds-pca9532.c
+++ b/drivers/leds/leds-pca9532.c
@@ -488,6 +488,7 @@ static int pca9532_probe(struct i2c_client *client,
const struct i2c_device_id *id)
{
int devid;
+ const struct of_device_id *of_id;
struct pca9532_data *data = i2c_get_clientdata(client);
struct pca9532_platform_data *pca9532_pdata =
dev_get_platdata(&client->dev);
@@ -503,8 +504,11 @@ static int pca9532_probe(struct i2c_client *client,
dev_err(&client->dev, "no platform data\n");
return -EINVAL;
}
- devid = (int)(uintptr_t)of_match_device(
- of_pca9532_leds_match, &client->dev)->data;
+ of_id = of_match_device(of_pca9532_leds_match,
+ &client->dev);
+ if (unlikely(!of_id))
+ return -EINVAL;
+ devid = (int)(uintptr_t) of_id->data;
} else {
devid = id->driver_data;
}
--
2.19.1
[PATCH 4.9 28/32] libata: fix using DMA buffers on stack
[ Upstream commit dd08a8d9a66de4b54575c294a92630299f7e0fe7 ]
When CONFIG_VMAP_STACK=y, __pa() returns incorrect physical address for
a stack virtual address. Stack DMA buffers must be avoided.
Signed-off-by: raymond pang
Signed-off-by: Jens Axboe
Signed-off-by: Sasha Levin (Microsoft)
---
drivers/ata/libata-zpodd.c | 34 --
1 file changed, 24 insertions(+), 10 deletions(-)
diff --git a/drivers/ata/libata-zpodd.c b/drivers/ata/libata-zpodd.c
index 0ad96c647541..7017a81d53cf 100644
--- a/drivers/ata/libata-zpodd.c
+++ b/drivers/ata/libata-zpodd.c
@@ -51,38 +51,52 @@ static int eject_tray(struct ata_device *dev)
/* Per the spec, only slot type and drawer type ODD can be supported */
static enum odd_mech_type zpodd_get_mech_type(struct ata_device *dev)
{
- char buf[16];
+ char *buf;
unsigned int ret;
- struct rm_feature_desc *desc = (void *)(buf + 8);
+ struct rm_feature_desc *desc;
struct ata_taskfile tf;
static const char cdb[] = { GPCMD_GET_CONFIGURATION,
2, /* only 1 feature descriptor requested */
0, 3, /* 3, removable medium feature */
0, 0, 0,/* reserved */
- 0, sizeof(buf),
+ 0, 16,
0, 0, 0,
};
+ buf = kzalloc(16, GFP_KERNEL);
+ if (!buf)
+ return ODD_MECH_TYPE_UNSUPPORTED;
+ desc = (void *)(buf + 8);
+
ata_tf_init(dev, &tf);
tf.flags = ATA_TFLAG_ISADDR | ATA_TFLAG_DEVICE;
tf.command = ATA_CMD_PACKET;
tf.protocol = ATAPI_PROT_PIO;
- tf.lbam = sizeof(buf);
+ tf.lbam = 16;
ret = ata_exec_internal(dev, &tf, cdb, DMA_FROM_DEVICE,
- buf, sizeof(buf), 0);
- if (ret)
+ buf, 16, 0);
+ if (ret) {
+ kfree(buf);
return ODD_MECH_TYPE_UNSUPPORTED;
+ }
- if (be16_to_cpu(desc->feature_code) != 3)
+ if (be16_to_cpu(desc->feature_code) != 3) {
+ kfree(buf);
return ODD_MECH_TYPE_UNSUPPORTED;
+ }
- if (desc->mech_type == 0 && desc->load == 0 && desc->eject == 1)
+ if (desc->mech_type == 0 && desc->load == 0 && desc->eject == 1) {
+ kfree(buf);
return ODD_MECH_TYPE_SLOT;
- else if (desc->mech_type == 1 && desc->load == 0 && desc->eject == 1)
+ } else if (desc->mech_type == 1 && desc->load == 0 &&
+ desc->eject == 1) {
+ kfree(buf);
return ODD_MECH_TYPE_DRAWER;
- else
+ } else {
+ kfree(buf);
return ODD_MECH_TYPE_UNSUPPORTED;
+ }
}
/* Test if ODD is zero power ready by sense code */
--
2.19.1
[PATCH 4.9 24/32] scsi: qla4xxx: fix a potential NULL pointer dereference
[ Upstream commit fba1bdd2a9a93f3e2181ec1936a3c2f6b37e7ed6 ] In case iscsi_lookup_endpoint fails, the fix returns -EINVAL to avoid NULL pointer dereference. Signed-off-by: Kangjie Lu Acked-by: Manish Rangankar Reviewed-by: Mukesh Ojha Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin (Microsoft) --- drivers/scsi/qla4xxx/ql4_os.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/scsi/qla4xxx/ql4_os.c b/drivers/scsi/qla4xxx/ql4_os.c index f9f899ec9427..c158967b59d7 100644 --- a/drivers/scsi/qla4xxx/ql4_os.c +++ b/drivers/scsi/qla4xxx/ql4_os.c @@ -3207,6 +3207,8 @@ static int qla4xxx_conn_bind(struct iscsi_cls_session *cls_session, if (iscsi_conn_bind(cls_session, cls_conn, is_leading)) return -EINVAL; ep = iscsi_lookup_endpoint(transport_fd); + if (!ep) + return -EINVAL; conn = cls_conn->dd_data; qla_conn = conn->dd_data; qla_conn->qla_ep = ep->dd_data; -- 2.19.1
[PATCH 4.9 06/32] qlcnic: Avoid potential NULL pointer dereference
[ Upstream commit 5bf7295fe34a5251b1d241b9736af4697b590670 ]
netdev_alloc_skb can fail and return a NULL pointer which is
dereferenced without a check. The patch avoids such a scenario.
Signed-off-by: Aditya Pakki
Signed-off-by: David S. Miller
Signed-off-by: Sasha Levin (Microsoft)
---
drivers/net/ethernet/qlogic/qlcnic/qlcnic_ethtool.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/net/ethernet/qlogic/qlcnic/qlcnic_ethtool.c
b/drivers/net/ethernet/qlogic/qlcnic/qlcnic_ethtool.c
index 0a2318cad34d..63ebc491057b 100644
--- a/drivers/net/ethernet/qlogic/qlcnic/qlcnic_ethtool.c
+++ b/drivers/net/ethernet/qlogic/qlcnic/qlcnic_ethtool.c
@@ -1038,6 +1038,8 @@ int qlcnic_do_lb_test(struct qlcnic_adapter *adapter, u8
mode)
for (i = 0; i < QLCNIC_NUM_ILB_PKT; i++) {
skb = netdev_alloc_skb(adapter->netdev, QLCNIC_ILB_PKT_SIZE);
+ if (!skb)
+ break;
qlcnic_create_loopback_buff(skb->data, adapter->mac_addr);
skb_put(skb, QLCNIC_ILB_PKT_SIZE);
adapter->ahw->diag_cnt = 0;
--
2.19.1
[PATCH 4.9 07/32] netfilter: nft_set_rbtree: check for inactive element after flag mismatch
[ Upstream commit 05b7639da55fb9866a1f4b7e8995232a6323 ]
Otherwise, we hit bogus ENOENT when removing elements.
Fixes: e701001e7cbe ("netfilter: nft_rbtree: allow adjacent intervals with
dynamic updates")
Reported-by: Václav Zindulka
Signed-off-by: Pablo Neira Ayuso
Signed-off-by: Sasha Levin (Microsoft)
---
net/netfilter/nft_set_rbtree.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/net/netfilter/nft_set_rbtree.c b/net/netfilter/nft_set_rbtree.c
index 93820e0d8814..4ee8acded0a4 100644
--- a/net/netfilter/nft_set_rbtree.c
+++ b/net/netfilter/nft_set_rbtree.c
@@ -191,10 +191,6 @@ static void *nft_rbtree_deactivate(const struct net *net,
else if (d > 0)
parent = parent->rb_right;
else {
- if (!nft_set_elem_active(&rbe->ext, genmask)) {
- parent = parent->rb_left;
- continue;
- }
if (nft_rbtree_interval_end(rbe) &&
!nft_rbtree_interval_end(this)) {
parent = parent->rb_left;
@@ -203,6 +199,9 @@ static void *nft_rbtree_deactivate(const struct net *net,
nft_rbtree_interval_end(this)) {
parent = parent->rb_right;
continue;
+ } else if (!nft_set_elem_active(&rbe->ext, genmask)) {
+ parent = parent->rb_left;
+ continue;
}
nft_set_elem_change_active(net, set, &rbe->ext);
return rbe;
--
2.19.1
Re: [PATCH v2 1/2] Add polling support to pidfd
On Wed, May 01, 2019 at 05:13:12PM +0200, Oleg Nesterov wrote:
> On 04/30, Joel Fernandes (Google) wrote:
> >
> > +static unsigned int pidfd_poll(struct file *file, struct poll_table_struct
> > *pts)
> > +{
> > + struct task_struct *task;
> > + struct pid *pid = file->private_data;
> > + int poll_flags = 0;
> > +
> > + poll_wait(file, &pid->wait_pidfd, pts);
> > +
> > + rcu_read_lock();
> > + task = pid_task(pid, PIDTYPE_PID);
> > + WARN_ON_ONCE(task && !thread_group_leader(task));
> ^^
>
> Ah, this is not right, we can race with de_thread() which changes the leader,
> in particular it does leader->exit_signal = -1 to indicate that this thread is
> no longer a group leader, but pid_task() can return the old leader.
>
> We are going to check thread_group_empty() below, it won't be true in this
> case,
> so this race should not make any harm.
>
> Just remove this WARN_ON(). We can't use has_group_leader_pid(), it can return
> false if pid_task() returns the new leader.
>
> Otherwise I see no problems.
I'll remove the WARN_ON() check when applying this. Can I get your
Acked/Review, Oleg?
Christian
Re: [PATCH] sched: Provide a pointer to the valid CPU mask
* Sebastian Andrzej Siewior wrote:
> In commit 4b53a3412d66 ("sched/core: Remove the tsk_nr_cpus_allowed()
> wrapper") the tsk_nr_cpus_allowed() wrapper was removed. There was not
> much difference in !RT but in RT we used this to implement
> migrate_disable(). Within a migrate_disable() section the CPU mask is
> restricted to single CPU while the "normal" CPU mask remains untouched.
>
> As an alternative implementation Ingo suggested to use
> struct task_struct {
> const cpumask_t *cpus_ptr;
> cpumask_t cpus_mask;
> };
> with
> t->cpus_allowed_ptr = &t->cpus_allowed;
>
> In -RT we then can switch the cpus_ptr to
> t->cpus_allowed_ptr = &cpumask_of(task_cpu(p));
>
> in a migration disabled region. The rules are simple:
> - Code that 'uses' ->cpus_allowed would use the pointer.
> - Code that 'modifies' ->cpus_allowed would use the direct mask.
>
> I proposed this patch as a series earlier and it was shutdown due to the
> migrate_disable() bits. It has been said that migrate_disable() should
> only be used with RT and thus not introduced without it.
> I hereby propose only the mask CPU-bits.
>
> Cc: Peter Zijlstra
> Cc: Thomas Gleixner
> Cc: Ingo Molnar
> Signed-off-by: Sebastian Andrzej Siewior
> ---
> arch/ia64/kernel/mca.c | 2 +-
> arch/mips/include/asm/switch_to.h | 4 +--
> arch/mips/kernel/mips-mt-fpaff.c | 2 +-
> arch/mips/kernel/traps.c | 6 ++--
> arch/powerpc/platforms/cell/spufs/sched.c | 2 +-
> arch/x86/kernel/cpu/resctrl/pseudo_lock.c | 2 +-
> drivers/infiniband/hw/hfi1/affinity.c | 6 ++--
> drivers/infiniband/hw/hfi1/sdma.c | 3 +-
> drivers/infiniband/hw/qib/qib_file_ops.c | 7 ++--
> fs/proc/array.c| 4 +--
> include/linux/sched.h | 5 +--
> init/init_task.c | 3 +-
> kernel/cgroup/cpuset.c | 2 +-
> kernel/fork.c | 2 ++
> kernel/sched/core.c| 40 +++---
> kernel/sched/cpudeadline.c | 4 +--
> kernel/sched/cpupri.c | 4 +--
> kernel/sched/deadline.c| 6 ++--
> kernel/sched/fair.c| 34 +-
> kernel/sched/rt.c | 4 +--
> kernel/trace/trace_hwlat.c | 2 +-
> lib/smp_processor_id.c | 2 +-
> samples/trace_events/trace-events-sample.c | 2 +-
> 23 files changed, 75 insertions(+), 73 deletions(-)
Looks good to me in principle - Peter, Thomas, any fundamental
objections?
Thanks,
Ingo
Re: Linux 5.1-rc5
On Thu, 2 May 2019 16:31:10 +0200
Greg KH wrote:
> On Thu, May 02, 2019 at 04:17:58PM +0200, Martin Schwidefsky wrote:
> > On Thu, 2 May 2019 14:21:28 +0200
> > Greg KH wrote:
> >
> > > On Mon, Apr 15, 2019 at 09:17:10AM -0700, Linus Torvalds wrote:
> > > > On Sun, Apr 14, 2019 at 10:19 PM Christoph Hellwig
> > > > wrote:
> > > > >
> > > > > Can we please have the page refcount overflow fixes out on the list
> > > > > for review, even if it is after the fact?
> > > >
> > > > They were actually on a list for review long before the fact, but it
> > > > was the security mailing list. The issue actually got discussed back
> > > > in January along with early versions of the patches, but then we
> > > > dropped the ball because it just wasn't on anybody's radar and it got
> > > > resurrected late March. Willy wrote a rather bigger patch-series, and
> > > > review of that is what then resulted in those commits. So they may
> > > > look recent, but that's just because the original patches got
> > > > seriously edited down and rewritten.
> > > >
> > > > That said, powerpc and s390 should at least look at maybe adding a
> > > > check for the page ref in their gup paths too. Powerpc has the special
> > > > gup_hugepte() case, and s390 has its own version of gup entirely. I
> > > > was actually hoping the s390 guys would look at using the generic gup
> > > > code.
> > > >
> > > > I ruthlessly also entirely ignored MIPS, SH and sparc, since they seem
> > > > largely irrelevant, partly since even theoretically this whole issue
> > > > needs a _lot_ of memory.
> > > >
> > > > Michael, Martin, see commit 6b3a70773630 ("Merge branch 'page-refs'
> > > > (page ref overflow)"). You may or may not really care.
> > >
> > > I've now queued these patches up for the next round of stable releases,
> > > as some people seem to care about these.
> > >
> > > I didn't see any follow-on patches for s390 or ppc64 hit the tree for
> > > these changes, am I just missing them and should also queue up a few
> > > more to handle this issue on those platforms?
> >
> > I fixed that with a different approach. The following two patches are
> > queued for the next merge window:
> >
> > d1874a0c2805 "s390/mm: make the pxd_offset functions more robust"
> > 1a42010cdc26 "s390/mm: convert to the generic get_user_pages_fast code"
> >
> > With these two s390 now uses the generic gup code in mm/gup.c
>
> Nice! Do you want me to queue those up for the stable backports once
> they hit a public -rc release?
Yes please!
--
blue skies,
Martin.
"Reality continues to ruin my life." - Calvin.
Re: [PATCH] x86/entry/64: randomize kernel stack offset upon syscall
* Andy Lutomirski wrote: > Or we decide that calling get_random_bytes() is okay with IRQs off and > this all gets a bit simpler. BTW., before we go down this path any further, is the plan to bind this feature to a real CPU-RNG capability, i.e. to the RDRAND instruction, which excludes a significant group of x86 of CPUs? Because calling tens of millions of system calls per second will deplete any non-CPU-RNG sources of entropy and will also starve all other users of random numbers, which might have a more legitimate need for randomness, such as the networking stack ... I.e. I'm really *super sceptical* of this whole plan, as currently formulated. If we bind it to RDRAND then we shouldn't be using the generic drivers/char/random.c pool *at all*, but just call the darn instruction directly. This is an x86 patch-set after all, right? Furthermore the following post suggests that RDRAND isn't a per CPU capability, but a core or socket level facility, depending on CPU make: https://stackoverflow.com/questions/10484164/what-is-the-latency-and-throughput-of-the-rdrand-instruction-on-ivy-bridge 8 gigabits/sec sounds good throughput in principle, if there's no scalability pathologies with that. It would also be nice to know whether RDRAND does buffering *internally*, in which case it might be better to buffer as little at the system call level as possible, to allow the hardware RNG buffer to rebuild between system calls. I.e. I'd suggest to retrieve randomness via a fixed number of RDRAND-r64 calls (where '1' is a perfectly valid block size - it should be measured), which random bits are then used as-is for the ~6 bits of system call stack offset. (I'd even suggest 7 bits: that skips a full cache line almost for free and makes the fuzz actually meaningful: no spear attacker will take a 1/128, 0.8% chance to successfully attack a critical system.) Then those 64*N random bits get buffered and consumed in 5-7 bit chunk, in a super efficient fashion, possibly inlining the fast path, totally outside the flow of the drivers/char/random.c Any non-CPU source of randomness for system calls and plans to add several extra function calls to every x86 system call is crazy talk I believe... Thanks, Ingo
Re: [PATCH] overlayfs: ignore empty NFSv4 ACLs in ext4 upperdir
Am Do., 2. Mai 2019 um 16:28 Uhr schrieb Miklos Szeredi : > On Thu, May 2, 2019 at 10:05 AM Andreas Gruenbacher > wrote: > > On Thu, 2 May 2019 at 05:57, NeilBrown wrote: > > > On Wed, May 01 2019, Amir Goldstein wrote: > > > > On Wed, May 1, 2019 at 10:03 PM NeilBrown wrote: > > > >> On Tue, Dec 06 2016, J. Bruce Fields wrote: > > > >> > On Tue, Dec 06, 2016 at 02:18:31PM +0100, Andreas Gruenbacher wrote: > > > >> >> On Tue, Dec 6, 2016 at 11:08 AM, Miklos Szeredi > > > >> >> wrote: > > > >> >> > On Tue, Dec 6, 2016 at 12:24 AM, Andreas Grünbacher > > > >> >> > wrote: > > > >> >> >> 2016-12-06 0:19 GMT+01:00 Andreas Grünbacher > > > >> >> >> : > > > >> >> > > > > >> >> >>> It's not hard to come up with a heuristic that determines if a > > > >> >> >>> system.nfs4_acl value is equivalent to a file mode, and to > > > >> >> >>> ignore the > > > >> >> >>> attribute in that case. (The file mode is transmitted in its own > > > >> >> >>> attribute already, so actually converting .) That way, > > > >> >> >>> overlayfs could > > > >> >> >>> still fail copying up files that have an actual ACL. It's still > > > >> >> >>> an > > > >> >> >>> ugly hack ... > > > >> >> >> > > > >> >> >> Actually, that kind of heuristic would make sense in the NFS > > > >> >> >> client > > > >> >> >> which could then hide the "system.nfs4_acl" attribute. > > > > I still think the nfs client could make this problem mostly go away by > > not exposing "system.nfs4_acl" xattrs when the acl is equivalent to > > the file mode. The richacl patches contain a workable abgorithm for > > that. The problem would remain for files that have an actual NFS4 ACL, > > which just cannot be mapped to a file mode or to POSIX ACLs in the > > general case, as well as for files that have a POSIX ACL. Mapping NFS4 > > ACL that used to be a POSIX ACL back to POSIX ACLs could be achieved > > in many cases as well, but the code would be quite messy. A better way > > seems to be to using a filesystem that doesn't support POSIX ACLs in > > the first place. Unfortunately, xfs doesn't allow turning off POSIX > > ACLs, for example. > > How about mounting NFSv4 with noacl? That should fix this issue, right? You'll still see permissions that differ from what the filesystem enforces, and copy-up would change that behavior. Andreas > Thanks, > Miklos > > > > > > > Andreas > > > > > >> >> > Even simpler would be if knfsd didn't send the attribute if not > > > >> >> > necessary. Looks like there's code actively creating the > > > >> >> > nfs4_acl on > > > >> >> > the wire even if the filesystem had none: > > > >> >> > > > > >> >> > pacl = get_acl(inode, ACL_TYPE_ACCESS); > > > >> >> > if (!pacl) > > > >> >> > pacl = posix_acl_from_mode(inode->i_mode, GFP_KERNEL); > > > >> >> > > > > >> >> > What's the point? > > > >> >> > > > >> >> That's how the protocol is specified. > > > >> > > > > >> > Yep, even if we could make that change to nfsd it wouldn't help the > > > >> > client with the large number of other servers that are out there > > > >> > (including older knfsd's). > > > >> > > > > >> > --b. > > > >> > > > > >> >> (I'm not saying that that's very helpful.) > > > >> >> > > > >> >> Andreas > > > >> > > > >> Hi everyone. > > > >> I have a customer facing this problem, and so stumbled onto the email > > > >> thread. > > > >> Unfortunately it didn't resolve anything. Maybe I can help kick > > > >> things > > > >> along??? > > > >> > > > >> The core problem here is that NFSv4 and ext4 use different and largely > > > >> incompatible ACL implementations. There is no way to accurately > > > >> translate from one to the other in general (common specific examples > > > >> can be converted). > > > >> > > > >> This means that either: > > > >>1/ overlayfs cannot use ext4 for upper and NFS for lower (or vice > > > >> versa) or > > > >>2/ overlayfs need to accept that sometimes it cannot copy ACLs, and > > > >> that is OK. > > > >> > > > >> Silently not copying the ACLs is probably not a good idea as it might > > > >> result in inappropriate permissions being given away. > > > > > > > > For example? permissions given away to do what? > > > > Note that ovl_permission() only check permissions of *mounter* > > > > to read the lower NFS file and ovl_open()/ovl_read_iter() access > > > > the lower file with *mounter* credentials. > > > > > > > > I might be wrong, but seems to me that once admin mounted > > > > overlayfs with lower NFS, NFS ACLs are not being enforced at all > > > > even before copy up. > > > > > > I guess it is just as well that copy-up fails then - if the lower-level > > > permission check is being ignored. > > > > > > > > > > >> So if the > > > >> sysadmin wants this (and some clearly do), they need a way to > > > >> explicitly say "I accept the risk". If only standard Unix permissions > > > >> are used, there is no risk, so this seems reasonable. > > > >> > > > >> So I would like to propose a new o
[PATCH v2] mtd: nand: raw: brcmnand: When oops in progress use pio and interrupt polling
If mtd_oops is in progress, switch to polling during NAND command
completion instead of relying on DMA/interrupts so that the mtd_oops
buffer can be completely written in the assigned NAND partition.
This is needed in cases where and there is only one online CPU and
the panic is not on cpu0 as all IRQs are wired to cpu0.
Signed-off-by: Kamal Dasu
---
drivers/mtd/nand/raw/brcmnand/brcmnand.c | 55 ++--
1 file changed, 52 insertions(+), 3 deletions(-)
diff --git a/drivers/mtd/nand/raw/brcmnand/brcmnand.c
b/drivers/mtd/nand/raw/brcmnand/brcmnand.c
index 482c6f0..128a806 100644
--- a/drivers/mtd/nand/raw/brcmnand/brcmnand.c
+++ b/drivers/mtd/nand/raw/brcmnand/brcmnand.c
@@ -823,6 +823,12 @@ static inline bool has_flash_dma(struct
brcmnand_controller *ctrl)
return ctrl->flash_dma_base;
}
+static inline void disable_flash_dma_xfer(struct brcmnand_controller *ctrl)
+{
+ if (has_flash_dma(ctrl))
+ ctrl->flash_dma_base = 0;
+}
+
static inline bool flash_dma_buf_ok(const void *buf)
{
return buf && !is_vmalloc_addr(buf) &&
@@ -1237,15 +1243,58 @@ static void brcmnand_cmd_ctrl(struct nand_chip *chip,
int dat,
/* intentionally left blank */
}
+static bool is_mtd_oops_in_progress(void)
+{
+ int i = 0;
+
+#ifdef CONFIG_MTD_OOPS
+ if (oops_in_progress && smp_processor_id()) {
+ int cpu = 0;
+
+ for_each_online_cpu(cpu)
+ ++i;
+ }
+#endif
+ return (i == 1);
+}
+
+static bool brcmstb_nand_wait_for_completion(struct nand_chip *chip)
+{
+ struct brcmnand_host *host = nand_get_controller_data(chip);
+ struct brcmnand_controller *ctrl = host->ctrl;
+ bool err = false;
+ int sts;
+
+ if (is_mtd_oops_in_progress()) {
+ /* Switch to interrupt polling and PIO mode */
+ disable_flash_dma_xfer(ctrl);
+ sts = bcmnand_ctrl_poll_status(ctrl, NAND_CTRL_RDY |
+ NAND_STATUS_READY,
+ NAND_CTRL_RDY |
+ NAND_STATUS_READY, 0);
+ err = (sts < 0) ? true : false;
+ } else {
+ unsigned long timeo = msecs_to_jiffies(
+ NAND_POLL_STATUS_TIMEOUT_MS);
+ /* wait for completion interrupt */
+ sts = wait_for_completion_timeout(&ctrl->done, timeo);
+ err = (sts <= 0) ? true : false;
+ }
+
+ return err;
+}
+
static int brcmnand_waitfunc(struct nand_chip *chip)
{
struct brcmnand_host *host = nand_get_controller_data(chip);
struct brcmnand_controller *ctrl = host->ctrl;
- unsigned long timeo = msecs_to_jiffies(100);
+ bool err = false;
dev_dbg(ctrl->dev, "wait on native cmd %d\n", ctrl->cmd_pending);
- if (ctrl->cmd_pending &&
- wait_for_completion_timeout(&ctrl->done, timeo) <= 0) {
+ if (ctrl->cmd_pending)
+ err = brcmstb_nand_wait_for_completion(chip);
+
+ if (err) {
u32 cmd = brcmnand_read_reg(ctrl, BRCMNAND_CMD_START)
>> brcmnand_cmd_shift(ctrl);
--
1.9.0.138.g2de3478
Re: [PATCH v3 1/3] PCI: qcom: Use clk_bulk API for 2.4.0 controllers
On Thu 02 May 04:53 PDT 2019, Vinod Koul wrote:
> On 01-05-19, 17:19, Bjorn Andersson wrote:
[..]
> > diff --git a/drivers/pci/controller/dwc/pcie-qcom.c
> > b/drivers/pci/controller/dwc/pcie-qcom.c
> > index 0ed235d560e3..d740cbe0e56d 100644
> > --- a/drivers/pci/controller/dwc/pcie-qcom.c
> > +++ b/drivers/pci/controller/dwc/pcie-qcom.c
> > @@ -112,10 +112,10 @@ struct qcom_pcie_resources_2_3_2 {
> > struct regulator_bulk_data supplies[QCOM_PCIE_2_3_2_MAX_SUPPLY];
> > };
> >
> > +#define QCOM_PCIE_2_4_0_MAX_CLOCKS 3
>
> empty line after the define please
>
This follows the style of QCOM_PCIE_2_3_2_MAX_SUPPLY one block up, so
I think this is the way we want it.
> > struct qcom_pcie_resources_2_4_0 {
[..]
>
>
> rest lgtm:
>
> Reviewed-by: Vinod Koul
>
Thanks!
Regards,
Bjorn
Re: [PATCH V2 1/2] PCI: dwc: Add API support to de-initialize host
On Tue, Apr 16, 2019 at 07:45:15PM +0530, Vidya Sagar wrote:
> Add an API to group all the tasks to be done to de-initialize host which
> can then be called by any DesignWare core based driver implementations
> while adding .remove() support in their respective drivers.
>
> Signed-off-by: Vidya Sagar
> Acked-by: Gustavo Pimentel
> ---
> v2:
> * s/Designware/DesignWare
>
> drivers/pci/controller/dwc/pcie-designware-host.c | 7 +++
> drivers/pci/controller/dwc/pcie-designware.h | 5 +
> 2 files changed, 12 insertions(+)
>
> diff --git a/drivers/pci/controller/dwc/pcie-designware-host.c
> b/drivers/pci/controller/dwc/pcie-designware-host.c
> index 3e4169e738a5..d7881490282d 100644
> --- a/drivers/pci/controller/dwc/pcie-designware-host.c
> +++ b/drivers/pci/controller/dwc/pcie-designware-host.c
> @@ -516,6 +516,13 @@ int dw_pcie_host_init(struct pcie_port *pp)
> return ret;
> }
>
> +void dw_pcie_host_deinit(struct pcie_port *pp)
> +{
> + pci_stop_root_bus(pp->root_bus);
> + pci_remove_root_bus(pp->root_bus);
> + dw_pcie_free_msi(pp);
This must mirror the init path, so AFAICS it should not be done
if pp->ops->msi_host_init != NULL
Lorenzo
> +}
> +
> static int dw_pcie_access_other_conf(struct pcie_port *pp, struct pci_bus
> *bus,
>u32 devfn, int where, int size, u32 *val,
>bool write)
> diff --git a/drivers/pci/controller/dwc/pcie-designware.h
> b/drivers/pci/controller/dwc/pcie-designware.h
> index adff0c713665..ea8d1caf11c5 100644
> --- a/drivers/pci/controller/dwc/pcie-designware.h
> +++ b/drivers/pci/controller/dwc/pcie-designware.h
> @@ -343,6 +343,7 @@ void dw_pcie_msi_init(struct pcie_port *pp);
> void dw_pcie_free_msi(struct pcie_port *pp);
> void dw_pcie_setup_rc(struct pcie_port *pp);
> int dw_pcie_host_init(struct pcie_port *pp);
> +void dw_pcie_host_deinit(struct pcie_port *pp);
> int dw_pcie_allocate_domains(struct pcie_port *pp);
> #else
> static inline irqreturn_t dw_handle_msi_irq(struct pcie_port *pp)
> @@ -367,6 +368,10 @@ static inline int dw_pcie_host_init(struct pcie_port *pp)
> return 0;
> }
>
> +static inline void dw_pcie_host_deinit(struct pcie_port *pp)
> +{
> +}
> +
> static inline int dw_pcie_allocate_domains(struct pcie_port *pp)
> {
> return 0;
> --
> 2.17.1
>
Re: [PATCH][next] rtw88: fix shift of more than 32 bits of a integer
Colin King wrote:
> From: Colin Ian King
>
> Currently the shift of an integer value more than 32 bits can
> occur when nss is more than 32. Fix this by making the integer
> constants unsigned long longs before shifting and bit-wise or'ing
> with the u64 ra_mask to avoid the undefined shift behaviour.
>
> Addresses-Coverity: ("Bad shift operation")
> Fixes: e3037485c68e ("rtw88: new Realtek 802.11ac driver")
> Signed-off-by: Colin Ian King
Patch applied to wireless-drivers-next.git, thanks.
b85bd9a14c4b rtw88: fix shift of more than 32 bits of a integer
--
https://patchwork.kernel.org/patch/10925147/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: [alsa-devel] [PATCH v4 22/22] soundwire: add missing newlines in dynamic debug logs
On 5/2/19 1:32 AM, Greg KH wrote: On Thu, May 02, 2019 at 11:07:46AM +0530, Vinod Koul wrote: On 01-05-19, 10:57, Pierre-Louis Bossart wrote: For some reason the newlines are not used everywhere. Fix as needed. Reported-by: Joe Perches Reviewed-by: Takashi Iwai Signed-off-by: Pierre-Louis Bossart --- drivers/soundwire/bus.c| 74 +-- drivers/soundwire/cadence_master.c | 12 ++-- drivers/soundwire/intel.c | 12 ++-- drivers/soundwire/stream.c | 110 ++--- Sorry this needs to be split up. I think bus.c and stream.c should go in patch with cadence_master.c and intel.c in different ones Again, _way_ too picky. You can't look a gift horse _too_ closely in the mouth... greg k-h Vinod, your distinction between subsystem and driver is quite arbitrary and borderline unreasonable. I would counter that the Intel parts have actually nothing to do in this drivers/soundwire directory and should be moved to the SOF tree if you push your own logic one step. There already known variations on capabilities and number of links which would be better handled in sound/soc/sof/intel, just like SoundWire slaves are expected to be in sound/soc/codecs. Besides this fixes *newlines*... I will send an update but I am not happy about the directions here.
Re: Patch "x86/fpu: Don't export __kernel_fpu_{begin,end}()" has been added to the 4.19-stable tree
On Thu, May 02, 2019 at 07:42:21AM -0700, Andy Lutomirski wrote:
> On Thu, May 2, 2019 at 1:02 AM Greg KH wrote:
> >
> > On Wed, May 01, 2019 at 10:47:07AM -0700, Andy Lutomirski wrote:
> > > On Mon, Apr 29, 2019 at 6:36 AM wrote:
> > > >
> > > >
> > > > This is a note to let you know that I've just added the patch titled
> > > >
> > > > x86/fpu: Don't export __kernel_fpu_{begin,end}()
> > > >
> > > > to the 4.19-stable tree which can be found at:
> > > >
> > > > http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
> > >
> > > Why? ISTM the only possible effect is to break out-of-tree modules.
> > > I have no objection to breaking such modules if we need to, but, in
> > > this case, I don't see the benefit.
> >
> > The "benefit" is that people keep complaining that newer kernels do not
> > have this api for some reason and that it is a "regression", which
> > completely does not understand how the kernel handles internal apis.
>
> I suppose that's a reasonable point. But maybe we should actually
> give these modules a credible alternative first? I just send a patch.
That's your call, it's your code :)
thanks,
greg k-h
Re: [PATCH V2 2/2] PCI: dwc: Export APIs to support .remove() implementation
On Tue, Apr 16, 2019 at 07:45:16PM +0530, Vidya Sagar wrote:
> Export all configuration space access APIs and also other APIs to
> support host controller drivers of DesignWare core based
> implementations while adding support for .remove() hook to build their
> respective drivers as modules
>
> Signed-off-by: Vidya Sagar
> Acked-by: Gustavo Pimentel
> ---
> v2:
> * s/Designware/DesignWare
>
> .../pci/controller/dwc/pcie-designware-host.c | 4 ++
> drivers/pci/controller/dwc/pcie-designware.c | 38 +++
> drivers/pci/controller/dwc/pcie-designware.h | 35 +++--
> 3 files changed, 48 insertions(+), 29 deletions(-)
>
> diff --git a/drivers/pci/controller/dwc/pcie-designware-host.c
> b/drivers/pci/controller/dwc/pcie-designware-host.c
> index d7881490282d..2a5332e5ccfa 100644
> --- a/drivers/pci/controller/dwc/pcie-designware-host.c
> +++ b/drivers/pci/controller/dwc/pcie-designware-host.c
> @@ -333,6 +333,7 @@ void dw_pcie_msi_init(struct pcie_port *pp)
> dw_pcie_wr_own_conf(pp, PCIE_MSI_ADDR_HI, 4,
> upper_32_bits(msi_target));
> }
> +EXPORT_SYMBOL_GPL(dw_pcie_msi_init);
>
> int dw_pcie_host_init(struct pcie_port *pp)
> {
> @@ -515,6 +516,7 @@ int dw_pcie_host_init(struct pcie_port *pp)
> dw_pcie_free_msi(pp);
> return ret;
> }
> +EXPORT_SYMBOL_GPL(dw_pcie_host_init);
>
> void dw_pcie_host_deinit(struct pcie_port *pp)
> {
> @@ -522,6 +524,7 @@ void dw_pcie_host_deinit(struct pcie_port *pp)
> pci_remove_root_bus(pp->root_bus);
> dw_pcie_free_msi(pp);
> }
> +EXPORT_SYMBOL_GPL(dw_pcie_host_deinit);
>
> static int dw_pcie_access_other_conf(struct pcie_port *pp, struct pci_bus
> *bus,
>u32 devfn, int where, int size, u32 *val,
> @@ -731,3 +734,4 @@ void dw_pcie_setup_rc(struct pcie_port *pp)
> val |= PORT_LOGIC_SPEED_CHANGE;
> dw_pcie_wr_own_conf(pp, PCIE_LINK_WIDTH_SPEED_CONTROL, 4, val);
> }
> +EXPORT_SYMBOL_GPL(dw_pcie_setup_rc);
> diff --git a/drivers/pci/controller/dwc/pcie-designware.c
> b/drivers/pci/controller/dwc/pcie-designware.c
> index 31f6331ca46f..f98e2f284ae1 100644
> --- a/drivers/pci/controller/dwc/pcie-designware.c
> +++ b/drivers/pci/controller/dwc/pcie-designware.c
> @@ -40,6 +40,7 @@ int dw_pcie_read(void __iomem *addr, int size, u32 *val)
>
> return PCIBIOS_SUCCESSFUL;
> }
> +EXPORT_SYMBOL_GPL(dw_pcie_read);
>
> int dw_pcie_write(void __iomem *addr, int size, u32 val)
> {
> @@ -57,6 +58,7 @@ int dw_pcie_write(void __iomem *addr, int size, u32 val)
>
> return PCIBIOS_SUCCESSFUL;
> }
> +EXPORT_SYMBOL_GPL(dw_pcie_write);
>
> u32 __dw_pcie_read_dbi(struct dw_pcie *pci, void __iomem *base, u32 reg,
> size_t size)
> @@ -89,6 +91,42 @@ void __dw_pcie_write_dbi(struct dw_pcie *pci, void __iomem
> *base, u32 reg,
> dev_err(pci->dev, "Write DBI address failed\n");
> }
>
> +void dw_pcie_writel_dbi(struct dw_pcie *pci, u32 reg, u32 val)
> +{
> + __dw_pcie_write_dbi(pci, pci->dbi_base, reg, 0x4, val);
> +}
> +EXPORT_SYMBOL_GPL(dw_pcie_writel_dbi);
> +
> +u32 dw_pcie_readl_dbi(struct dw_pcie *pci, u32 reg)
> +{
> + return __dw_pcie_read_dbi(pci, pci->dbi_base, reg, 0x4);
> +}
> +EXPORT_SYMBOL_GPL(dw_pcie_readl_dbi);
> +
> +void dw_pcie_writew_dbi(struct dw_pcie *pci, u32 reg, u16 val)
> +{
> + __dw_pcie_write_dbi(pci, pci->dbi_base, reg, 0x2, val);
> +}
> +EXPORT_SYMBOL_GPL(dw_pcie_writew_dbi);
> +
> +u16 dw_pcie_readw_dbi(struct dw_pcie *pci, u32 reg)
> +{
> + return __dw_pcie_read_dbi(pci, pci->dbi_base, reg, 0x2);
> +}
> +EXPORT_SYMBOL_GPL(dw_pcie_readw_dbi);
> +
> +void dw_pcie_writeb_dbi(struct dw_pcie *pci, u32 reg, u8 val)
> +{
> + __dw_pcie_write_dbi(pci, pci->dbi_base, reg, 0x1, val);
> +}
> +EXPORT_SYMBOL_GPL(dw_pcie_writeb_dbi);
> +
> +u8 dw_pcie_readb_dbi(struct dw_pcie *pci, u32 reg)
> +{
> + return __dw_pcie_read_dbi(pci, pci->dbi_base, reg, 0x1);
> +}
> +EXPORT_SYMBOL_GPL(dw_pcie_readb_dbi);
> +
> static u32 dw_pcie_readl_ob_unroll(struct dw_pcie *pci, u32 index, u32 reg)
> {
> u32 offset = PCIE_GET_ATU_OUTB_UNR_REG_OFFSET(index);
> diff --git a/drivers/pci/controller/dwc/pcie-designware.h
> b/drivers/pci/controller/dwc/pcie-designware.h
> index ea8d1caf11c5..86df36701a37 100644
> --- a/drivers/pci/controller/dwc/pcie-designware.h
> +++ b/drivers/pci/controller/dwc/pcie-designware.h
> @@ -265,35 +265,12 @@ void dw_pcie_disable_atu(struct dw_pcie *pci, int index,
>enum dw_pcie_region_type type);
> void dw_pcie_setup(struct dw_pcie *pci);
>
> -static inline void dw_pcie_writel_dbi(struct dw_pcie *pci, u32 reg, u32 val)
> -{
> - __dw_pcie_write_dbi(pci, pci->dbi_base, reg, 0x4, val);
> -}
> -
> -static inline u32 dw_pcie_readl_dbi(struct dw_pcie *pci, u32 reg)
> -{
> - return __dw_pcie_read_dbi(pci, pci->dbi_base, reg, 0x4);
> -}
> -
> -static inline void dw_pcie_writew_dbi(struct dw_pcie *pci, u32 r
Re: [PATCH] ARM: dts: dra76x: Update MMC2_HS200_MANUAL1 iodelay values
* Faiz Abbas [190502 06:28]: > Hi Tony, > > On 30/04/19 9:24 PM, Tony Lindgren wrote: > > Hi, > > > > * Faiz Abbas [190429 23:09]: > >> Update the MMC2_HS200_MANUAL1 iodelay values to match with the latest > >> dra76x data manual[1]. > >> > >> Also this particular pinctrl-array is using spaces instead of tabs for > >> spacing between the values and the comments. Fix this as well. > > > > Is this needed as a fix or can this wait? > > > > This is a fix. The new iodelay values will have better marginality and > should prevent issues in corner cases. OK thanks tagging this one with cc stable as well. Regards, Tony
Re: [PATCH] x86/entry/64: randomize kernel stack offset upon syscall
On Thu, May 2, 2019 at 2:23 AM David Laight wrote:
>
> From: Reshetova, Elena
> > Sent: 02 May 2019 09:16
> ...
> > > I'm also guessing that get_cpu_var() disables pre-emption?
> >
> > Yes, in my understanding:
> >
> > #define get_cpu_var(var) \
> > (*({ \
> > preempt_disable(); \
> > this_cpu_ptr(&var); \
> > }))
> >
> > > This code could probably run 'fast and loose' and just ignore
> > > the fact that pre-emption would have odd effects.
> > > All it would do is perturb the randomness!
> >
> > Hm.. I see your point, but I am wondering what the odd effects might
> > be.. i.e. can we end up using the same random bits twice for two or more
> > different syscalls and attackers can try to trigger this situation?
>
> To trigger it you'd need to arrange for an interrupt in the right
> timing window to cause another process to run.
> There are almost certainly easier ways to break things.
>
> I think the main effects would be the increment writing to a different
> cpu local data (causing the same data to be used again and/or skipped)
> and the potential for updating the random buffer on the 'wrong cpu'.
>
> So something like:
> /* We don't really care if the update is written to the 'wrong'
> * cpu or if the vale comes from the wrong buffer. */
> offset = *this_cpu_ptr(&cpu_syscall_rand_offset);
> *this_cpu_ptr(&cpu_syscall_rand_offset) = offset + 1;
>
> if ((offset &= 4095)) return
> this_cpu_ptr(&cpu_syscall_rand_buffer)[offset];
>
> buffer = get_cpu_var((&cpu_syscall_rand_buffer);
> get_random_bytes();
> val = buffer[0];
> /* maybe set cpu_syscall_rand_offset to 1 */
> put_cpu_var();
> return val;
>
> The whole thing might even work with a global buffer!
>
I don't see how this makes sense in the context of the actual entry
code. The code looks like this right now:
enter_from_user_mode();
<--- IRQs off here
local_irq_enable();
Presumably this could become:
enter_from_user_mode();
if (the percpu buffer has enough bytes) {
use them;
local_irq_enable();
} else {
local_irq_enable();
get more bytes;
if (get_cpu() == the old cpu) {
refill the buffer;
} else {
feel rather silly;
}
put_cpu();
}
everything after the enter_from_user_mode() could get renamed
get_randstack_offset_and_irq_enable().
Or we decide that calling get_random_bytes() is okay with IRQs off and
this all gets a bit simpler.
--Andy
Re: Patch "x86/fpu: Don't export __kernel_fpu_{begin,end}()" has been added to the 4.19-stable tree
On Thu, May 2, 2019 at 1:02 AM Greg KH wrote:
>
> On Wed, May 01, 2019 at 10:47:07AM -0700, Andy Lutomirski wrote:
> > On Mon, Apr 29, 2019 at 6:36 AM wrote:
> > >
> > >
> > > This is a note to let you know that I've just added the patch titled
> > >
> > > x86/fpu: Don't export __kernel_fpu_{begin,end}()
> > >
> > > to the 4.19-stable tree which can be found at:
> > >
> > > http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
> >
> > Why? ISTM the only possible effect is to break out-of-tree modules.
> > I have no objection to breaking such modules if we need to, but, in
> > this case, I don't see the benefit.
>
> The "benefit" is that people keep complaining that newer kernels do not
> have this api for some reason and that it is a "regression", which
> completely does not understand how the kernel handles internal apis.
I suppose that's a reasonable point. But maybe we should actually
give these modules a credible alternative first? I just send a patch.
[PATCH] x86/fpu: Remove the _GPL from the kernel_fpu_begin/end() export
The FPU is not a super-Linuxy internal detail, so remove the _GPL
from its export. Without something like this patch, it's impossible
for even highly license-respecting non-GPL modules to use the FPU,
which seems silly to me. After all, the FPU is a CPU feature, not
really a kernel feature at all.
Cc: Sebastian Andrzej Siewior
Cc:: Borislav Petkov
Cc: Rik van Riel
Cc: "H. Peter Anvin"
Cc: "Jason A. Donenfeld"
Cc: Ard Biesheuvel
Cc: Dave Hansen
Cc: Ingo Molnar
Cc: Nicolai Stange
Cc: Paolo Bonzini
Cc: Radim Krčmář
Cc: Thomas Gleixner
Cc: x...@kernel.org
Cc: sta...@vger.kernel.org
Fixes: 12209993e98c ("x86/fpu: Don't export __kernel_fpu_{begin,end}()")
Signed-off-by: Andy Lutomirski
---
This fixes a genuine annoyance for ZFS on Linux. Regardless of what
one may think about the people who distribute ZFS on Linux
*binaries*, as far as I know, the source and the users who build it
themselves are entirely respectful of everyone's license. I have no
problem with EXPORT_SYMBOL_GPL() in general, but let's please avoid
using it for things that aren't fundamentally Linux internals.
arch/x86/kernel/fpu/core.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/x86/kernel/fpu/core.c b/arch/x86/kernel/fpu/core.c
index 2e5003fef51a..8de5687a470d 100644
--- a/arch/x86/kernel/fpu/core.c
+++ b/arch/x86/kernel/fpu/core.c
@@ -127,14 +127,14 @@ void kernel_fpu_begin(void)
preempt_disable();
__kernel_fpu_begin();
}
-EXPORT_SYMBOL_GPL(kernel_fpu_begin);
+EXPORT_SYMBOL(kernel_fpu_begin);
void kernel_fpu_end(void)
{
__kernel_fpu_end();
preempt_enable();
}
-EXPORT_SYMBOL_GPL(kernel_fpu_end);
+EXPORT_SYMBOL(kernel_fpu_end);
/*
* Save the FPU state (mark it for reload if necessary):
--
2.21.0
Re: [PATCH] ARM: dts: am57xx-idk: Remove support for voltage switching for SD card
* Faiz Abbas [190502 14:30]: > Hi Tony, > > On 02/05/19 7:50 PM, Tony Lindgren wrote: > > * Faiz Abbas [190502 01:48]: > >> If UHS speed modes are enabled, a compatible SD card switches down to > >> 1.8V during enumeration. If after this a software reboot/crash takes > >> place and on-chip ROM tries to enumerate the SD card, the difference in > >> IO voltages (host @ 3.3V and card @ 1.8V) may end up damaging the card. > >> > >> The fix for this is to have support for power cycling the card in > >> hardware (with a PORz/soft-reset line causing a power cycle of the > >> card). Since am571x-, am572x- and am574x-idk don't have this > >> capability, disable voltage switching for these boards. > >> > >> The major effect of this is that the maximum supported speed > >> mode is now high speed(50 MHz) down from SDR104(200 MHz). > > > > This sounds a bit urgent, does it also need a stable tag or is > > it safe to apply against any earlier kernels? > > > > This should be good to apply on any previous releases. OK applying both your MMC patches into fixes today. Thanks, Tony
Re: [PATCH] ARM: dts: am57xx-idk: Remove support for voltage switching for SD card
Hi Tony, On 02/05/19 7:50 PM, Tony Lindgren wrote: > * Faiz Abbas [190502 01:48]: >> If UHS speed modes are enabled, a compatible SD card switches down to >> 1.8V during enumeration. If after this a software reboot/crash takes >> place and on-chip ROM tries to enumerate the SD card, the difference in >> IO voltages (host @ 3.3V and card @ 1.8V) may end up damaging the card. >> >> The fix for this is to have support for power cycling the card in >> hardware (with a PORz/soft-reset line causing a power cycle of the >> card). Since am571x-, am572x- and am574x-idk don't have this >> capability, disable voltage switching for these boards. >> >> The major effect of this is that the maximum supported speed >> mode is now high speed(50 MHz) down from SDR104(200 MHz). > > This sounds a bit urgent, does it also need a stable tag or is > it safe to apply against any earlier kernels? > This should be good to apply on any previous releases. Thanks, Faiz
Re: [PATCH] overlayfs: ignore empty NFSv4 ACLs in ext4 upperdir
On Thu, May 2, 2019 at 10:05 AM Andreas Gruenbacher wrote: > > On Thu, 2 May 2019 at 05:57, NeilBrown wrote: > > On Wed, May 01 2019, Amir Goldstein wrote: > > > On Wed, May 1, 2019 at 10:03 PM NeilBrown wrote: > > >> On Tue, Dec 06 2016, J. Bruce Fields wrote: > > >> > On Tue, Dec 06, 2016 at 02:18:31PM +0100, Andreas Gruenbacher wrote: > > >> >> On Tue, Dec 6, 2016 at 11:08 AM, Miklos Szeredi > > >> >> wrote: > > >> >> > On Tue, Dec 6, 2016 at 12:24 AM, Andreas Grünbacher > > >> >> > wrote: > > >> >> >> 2016-12-06 0:19 GMT+01:00 Andreas Grünbacher > > >> >> >> : > > >> >> > > > >> >> >>> It's not hard to come up with a heuristic that determines if a > > >> >> >>> system.nfs4_acl value is equivalent to a file mode, and to ignore > > >> >> >>> the > > >> >> >>> attribute in that case. (The file mode is transmitted in its own > > >> >> >>> attribute already, so actually converting .) That way, overlayfs > > >> >> >>> could > > >> >> >>> still fail copying up files that have an actual ACL. It's still an > > >> >> >>> ugly hack ... > > >> >> >> > > >> >> >> Actually, that kind of heuristic would make sense in the NFS client > > >> >> >> which could then hide the "system.nfs4_acl" attribute. > > I still think the nfs client could make this problem mostly go away by > not exposing "system.nfs4_acl" xattrs when the acl is equivalent to > the file mode. The richacl patches contain a workable abgorithm for > that. The problem would remain for files that have an actual NFS4 ACL, > which just cannot be mapped to a file mode or to POSIX ACLs in the > general case, as well as for files that have a POSIX ACL. Mapping NFS4 > ACL that used to be a POSIX ACL back to POSIX ACLs could be achieved > in many cases as well, but the code would be quite messy. A better way > seems to be to using a filesystem that doesn't support POSIX ACLs in > the first place. Unfortunately, xfs doesn't allow turning off POSIX > ACLs, for example. How about mounting NFSv4 with noacl? That should fix this issue, right? Thanks, Miklos > > Andreas > > > >> >> > Even simpler would be if knfsd didn't send the attribute if not > > >> >> > necessary. Looks like there's code actively creating the nfs4_acl > > >> >> > on > > >> >> > the wire even if the filesystem had none: > > >> >> > > > >> >> > pacl = get_acl(inode, ACL_TYPE_ACCESS); > > >> >> > if (!pacl) > > >> >> > pacl = posix_acl_from_mode(inode->i_mode, GFP_KERNEL); > > >> >> > > > >> >> > What's the point? > > >> >> > > >> >> That's how the protocol is specified. > > >> > > > >> > Yep, even if we could make that change to nfsd it wouldn't help the > > >> > client with the large number of other servers that are out there > > >> > (including older knfsd's). > > >> > > > >> > --b. > > >> > > > >> >> (I'm not saying that that's very helpful.) > > >> >> > > >> >> Andreas > > >> > > >> Hi everyone. > > >> I have a customer facing this problem, and so stumbled onto the email > > >> thread. > > >> Unfortunately it didn't resolve anything. Maybe I can help kick things > > >> along??? > > >> > > >> The core problem here is that NFSv4 and ext4 use different and largely > > >> incompatible ACL implementations. There is no way to accurately > > >> translate from one to the other in general (common specific examples > > >> can be converted). > > >> > > >> This means that either: > > >>1/ overlayfs cannot use ext4 for upper and NFS for lower (or vice > > >> versa) or > > >>2/ overlayfs need to accept that sometimes it cannot copy ACLs, and > > >> that is OK. > > >> > > >> Silently not copying the ACLs is probably not a good idea as it might > > >> result in inappropriate permissions being given away. > > > > > > For example? permissions given away to do what? > > > Note that ovl_permission() only check permissions of *mounter* > > > to read the lower NFS file and ovl_open()/ovl_read_iter() access > > > the lower file with *mounter* credentials. > > > > > > I might be wrong, but seems to me that once admin mounted > > > overlayfs with lower NFS, NFS ACLs are not being enforced at all > > > even before copy up. > > > > I guess it is just as well that copy-up fails then - if the lower-level > > permission check is being ignored. > > > > > > > >> So if the > > >> sysadmin wants this (and some clearly do), they need a way to > > >> explicitly say "I accept the risk". If only standard Unix permissions > > >> are used, there is no risk, so this seems reasonable. > > >> > > >> So I would like to propose a new option for overlayfs > > >> nocopyupacl: when overlayfs is copying a file (or directory etc) > > >> from the lower filesystem to the upper filesystem, it does not > > >> copy extended attributes with the "system." prefix. These are > > >> used for storing ACL information and this is sometimes not > > >> compatible between different filesystem types (e.g. ext4 and > > >> NFSv4). Standard Uni
Re: [PATCH 04/12] mips: Reserve memory for the kernel image resources
On Tue, Apr 30, 2019 at 10:58:33PM +, Paul Burton wrote:
Hello Paul
> Hi Serge,
>
> On Fri, Apr 26, 2019 at 03:00:36AM +0300, Serge Semin wrote:
> > > 1) Older systems generally had something like an ISA bus which used
> > > addresses below the kernel, and bootloaders like YAMON left behind
> > > functions that could be called right at the start of RAM. This sort
> > > of thing should be accounted for by /memreserve/ in DT or similar
> > > platform-specific reservations though rather than generically, and
> > > at least Malta & SEAD-3 DTs already have /memreserve/ entries for
> > > it. So this part I think is OK. Some other older platforms might
> > > need updating, but that's fine.
> > >
> >
> > Regarding ISA. As far as I remember devices on that bus can DMA only to the
> > lowest 16MB. So in case if kernel is too big or placed pretty much high,
> > they may be left even without reachable memory at all in current
> > implementation.
>
> Sure - I'm not too worried about these old buses, platforms can continue
> to reserve the memory through DT or otherwise if they need to.
>
> > > 2) trap_init() only allocates memory for the exception vector if using
> > > a vectored interrupt mode. In other cases it just uses CAC_BASE
> > > which currently gets reserved as part of this region between
> > > PHYS_OFFSET & _text.
> > >
> > > I think this behavior is bogus, and we should instead:
> > >
> > > - Allocate the exception vector memory using memblock_alloc() for
> > > CPUs implementing MIPSr2 or higher (ie. CPUs with a programmable
> > > EBase register). If we're not using vectored interrupts then
> > > allocating one page will do, and we already have the size
> > > calculation for if we are.
> > >
> > > - Otherwise use CAC_BASE but call memblock_reserve() on the first
> > > page.
> > >
> > > I think we should make that change before this one goes in. I can
> > > try to get to it tomorrow, but feel free to beat me to it.
> > >
> >
> > As far as I understood you and the code this should be enough to fix
> > the problem:
> > diff --git a/arch/mips/kernel/traps.c b/arch/mips/kernel/traps.c
> > index 98ca55d62201..f680253e2617 100644
> > --- a/arch/mips/kernel/traps.c
> > +++ b/arch/mips/kernel/traps.c
> > @@ -2326,6 +2326,8 @@ void __init trap_init(void)
> > ebase += (read_c0_ebase() & 0x3000);
> > }
> > }
> > +
> > + memblock_reserve(ebase, PAGE_SIZE);
> > }
> >
> > if (cpu_has_mmips) {
> > ---
> >
> > Allocation has already been implemented in the if-branch under the
> > (cpu_has_veic || cpu_has_vint) condition. So we don't need to change
> > there anything.
> > In case if vectored interrupts aren't supported the else-clause is
> > taken and we need to reserve whatever is set in the exception base
> > address variable.
> >
> > I'll add this patch between 3d and 4th ones if you are ok with it.
>
> I think that would work, but I have other motivations to allocate the
> memory in non-vectored cases anyway. I just sent a series that does that
> & cleans up a little [1]. If you could take a look that would be great.
> With that change made I think this patch will be good to apply.
>
Just reviewed and tested your series on my machine. I tagged the whole series
in a response to the cover-letter of [1].
Could you please proceed with this patchset review procedure? There are
also eight more patches left without your tag or comment. This patch
is also left with no explicit tag.
BTW I see you already applied patches 1-3 to the mips-next, so what shall I
do when sending a v2 patchset with fixes asked to be provided for patch 12
and possibly for others in future? Shall I just resend the series without that
applied patches or send them over with your acked-by tagges?
-Sergey
> Thanks,
> Paul
>
> [1]
> https://lore.kernel.org/linux-mips/20190430225216.7164-1-paul.bur...@mips.com/T/#t
Re: [PATCH v6 03/10] clk: samsung: add BPLL rate table for Exynos 5422 SoC
Hi Chanwoo,
On 5/2/19 7:15 AM, Chanwoo Choi wrote:
> Hi Lukasz,
>
> On 19. 4. 19. 오후 11:19, Lukasz Luba wrote:
>> Add new table rate for BPLL for Exynos5422 SoC supporting Dynamic Memory
>> Controller frequencies for driver's DRAM timings.
>>
>> Signed-off-by: Lukasz Luba
>> ---
>> drivers/clk/samsung/clk-exynos5420.c | 13 -
>> 1 file changed, 12 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/clk/samsung/clk-exynos5420.c
>> b/drivers/clk/samsung/clk-exynos5420.c
>> index d9e6653..ddee8bd 100644
>> --- a/drivers/clk/samsung/clk-exynos5420.c
>> +++ b/drivers/clk/samsung/clk-exynos5420.c
>> @@ -1323,6 +1323,17 @@ static const struct samsung_pll_rate_table
>> exynos5420_pll2550x_24mhz_tbl[] __ini
>> PLL_35XX_RATE(24 * MHZ, 2, 200, 3, 3),
>> };
>>
>> +static const struct samsung_pll_rate_table exynos5422_bpll_rate_table[] = {
>> +PLL_35XX_RATE(24 * MHZ, 82500, 275, 4, 1),
>> +PLL_35XX_RATE(24 * MHZ, 72800, 182, 3, 1),
>> +PLL_35XX_RATE(24 * MHZ, 63300, 211, 4, 1),
>> +PLL_35XX_RATE(24 * MHZ, 54300, 181, 2, 2),
>> +PLL_35XX_RATE(24 * MHZ, 41300, 413, 6, 2),
>> +PLL_35XX_RATE(24 * MHZ, 27500, 275, 3, 3),
>> +PLL_35XX_RATE(24 * MHZ, 20600, 206, 3, 3),
>> +PLL_35XX_RATE(24 * MHZ, 16500, 110, 2, 3),
>> +};
>> +
>> static const struct samsung_pll_rate_table exynos5420_epll_24mhz_tbl[] = {
>> PLL_36XX_RATE(24 * MHZ, 6U, 100, 2, 1, 0),
>> PLL_36XX_RATE(24 * MHZ, 4U, 200, 3, 2, 0),
>> @@ -1465,7 +1476,7 @@ static void __init exynos5x_clk_init(struct
>> device_node *np,
>> exynos5x_plls[apll].rate_table = exynos5420_pll2550x_24mhz_tbl;
>> exynos5x_plls[epll].rate_table = exynos5420_epll_24mhz_tbl;
>> exynos5x_plls[kpll].rate_table = exynos5420_pll2550x_24mhz_tbl;
>> -exynos5x_plls[bpll].rate_table = exynos5420_pll2550x_24mhz_tbl;
>> +exynos5x_plls[bpll].rate_table = exynos5422_bpll_rate_table;
>
> According to your previous reply, the released odroid-xu3 board by hardkernel
> might be only CONFIG_SOC_EXYNOS5422_REV_0. Because the kernel configurattion
> from hardkernel has 'CONFIG_SOC_EXYNOS5422_REV_0=y'. I'm ok about adding bpll
> rate_table.
>
> But, just I have one question. I think that this bpll rate_table is for
> only Exynos5422 series. Because the kernel of hardkernel used
> driver/clk/samsung/clk-exynos5422.c instead of clk-exynos5420.c commonn
> driver.
> It means that the clk-exynos5422.c of hardkernel's kernel support only
> Exynos5422
> without any considering the Exynos5420 series.
>
> I think that it might need to check the soc version to use
> bpll rate_table as following:
Fair enough.
>
> --- a/drivers/clk/samsung/clk-exynos5420.c
> +++ b/drivers/clk/samsung/clk-exynos5420.c
> @@ -1438,7 +1438,10 @@ static void __init exynos5x_clk_init(struct
> device_node *np,
> exynos5x_plls[apll].rate_table =
> exynos5420_pll2550x_24mhz_tbl;
> exynos5x_plls[epll].rate_table = exynos5420_epll_24mhz_tbl;
> exynos5x_plls[kpll].rate_table =
> exynos5420_pll2550x_24mhz_tbl;
> - exynos5x_plls[bpll].rate_table = exynos5422_bpll_rate_table;
> +
> + if (soc == EXYNOS5800)
> + exynos5x_plls[bpll].rate_table
> + = exynos5422_bpll_rate_table;
> }
>
I will add this check. Thank you.
Regards,
Lukasz
>
>> }
>>
>> samsung_clk_register_pll(ctx, exynos5x_plls, ARRAY_SIZE(exynos5x_plls),
>>
>
>
[PATCH 2/2] regulator: ab3100: Set fixed_uV instead of min_uV for fixed regulators
Slightly better readability by setting fixed_uV instead of min_uV.
Signed-off-by: Axel Lin
---
drivers/regulator/ab3100.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/regulator/ab3100.c b/drivers/regulator/ab3100.c
index edde907a7062..438509f55f05 100644
--- a/drivers/regulator/ab3100.c
+++ b/drivers/regulator/ab3100.c
@@ -354,7 +354,6 @@ static int ab3100_get_voltage_regulator_external(struct
regulator_dev *reg)
}
static const struct regulator_ops regulator_ops_fixed = {
- .list_voltage = regulator_list_voltage_linear,
.enable = ab3100_enable_regulator,
.disable = ab3100_disable_regulator,
.is_enabled = ab3100_is_enabled_regulator,
@@ -401,7 +400,7 @@ ab3100_regulator_desc[AB3100_NUM_REGULATORS] = {
.n_voltages = 1,
.type = REGULATOR_VOLTAGE,
.owner = THIS_MODULE,
- .min_uV = LDO_A_VOLTAGE,
+ .fixed_uV = LDO_A_VOLTAGE,
.enable_time = 200,
},
{
@@ -411,7 +410,7 @@ ab3100_regulator_desc[AB3100_NUM_REGULATORS] = {
.n_voltages = 1,
.type = REGULATOR_VOLTAGE,
.owner = THIS_MODULE,
- .min_uV = LDO_C_VOLTAGE,
+ .fixed_uV = LDO_C_VOLTAGE,
.enable_time = 200,
},
{
@@ -421,7 +420,7 @@ ab3100_regulator_desc[AB3100_NUM_REGULATORS] = {
.n_voltages = 1,
.type = REGULATOR_VOLTAGE,
.owner = THIS_MODULE,
- .min_uV = LDO_D_VOLTAGE,
+ .fixed_uV = LDO_D_VOLTAGE,
.enable_time = 200,
},
{
--
2.20.1
[PATCH 1/2] regulator: ab3100: Constify regulator_ops and ab3100_regulator_desc
These regulator_ops variables and ab3100_regulator_desc array never need
to be modified, make them const so compiler can put them to .rodata.
Signed-off-by: Axel Lin
---
drivers/regulator/ab3100.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/regulator/ab3100.c b/drivers/regulator/ab3100.c
index c92966a79a7e..edde907a7062 100644
--- a/drivers/regulator/ab3100.c
+++ b/drivers/regulator/ab3100.c
@@ -353,14 +353,14 @@ static int ab3100_get_voltage_regulator_external(struct
regulator_dev *reg)
return 0;
}
-static struct regulator_ops regulator_ops_fixed = {
+static const struct regulator_ops regulator_ops_fixed = {
.list_voltage = regulator_list_voltage_linear,
.enable = ab3100_enable_regulator,
.disable = ab3100_disable_regulator,
.is_enabled = ab3100_is_enabled_regulator,
};
-static struct regulator_ops regulator_ops_variable = {
+static const struct regulator_ops regulator_ops_variable = {
.enable = ab3100_enable_regulator,
.disable = ab3100_disable_regulator,
.is_enabled = ab3100_is_enabled_regulator,
@@ -369,7 +369,7 @@ static struct regulator_ops regulator_ops_variable = {
.list_voltage = regulator_list_voltage_table,
};
-static struct regulator_ops regulator_ops_variable_sleepable = {
+static const struct regulator_ops regulator_ops_variable_sleepable = {
.enable = ab3100_enable_regulator,
.disable = ab3100_disable_regulator,
.is_enabled = ab3100_is_enabled_regulator,
@@ -385,14 +385,14 @@ static struct regulator_ops
regulator_ops_variable_sleepable = {
* is an on/off switch plain an simple. The external
* voltage is defined in the board set-up if any.
*/
-static struct regulator_ops regulator_ops_external = {
+static const struct regulator_ops regulator_ops_external = {
.enable = ab3100_enable_regulator,
.disable = ab3100_disable_regulator,
.is_enabled = ab3100_is_enabled_regulator,
.get_voltage = ab3100_get_voltage_regulator_external,
};
-static struct regulator_desc
+static const struct regulator_desc
ab3100_regulator_desc[AB3100_NUM_REGULATORS] = {
{
.name = "LDO_A",
@@ -499,7 +499,7 @@ static int ab3100_regulator_register(struct platform_device
*pdev,
struct device_node *np,
unsigned long id)
{
- struct regulator_desc *desc;
+ const struct regulator_desc *desc;
struct ab3100_regulator *reg;
struct regulator_dev *rdev;
struct regulator_config config = { };
@@ -688,7 +688,7 @@ static int ab3100_regulators_probe(struct platform_device
*pdev)
/* Register the regulators */
for (i = 0; i < AB3100_NUM_REGULATORS; i++) {
- struct regulator_desc *desc = &ab3100_regulator_desc[i];
+ const struct regulator_desc *desc = &ab3100_regulator_desc[i];
err = ab3100_regulator_register(pdev, plfdata, NULL, NULL,
desc->id);
--
2.20.1
Re: [PATCH v2 08/10] nvme/pci: implement the mdev external queue allocation interface
On Thu, 2019-05-02 at 14:47 +0300, Maxim Levitsky wrote: > Note that currently the number of hw queues reserved for mdev, > has to be pre determined on module load. > > (I used to allocate the queues dynamicaly on demand, but > recent changes to allocate polled/read queues made > this somewhat difficult, so I dropped this for now) > > Signed-off-by: Maxim Levitsky > --- > drivers/nvme/host/pci.c | 375 ++- > drivers/nvme/mdev/host.c | 46 ++--- > drivers/nvme/mdev/io.c | 46 +++-- > drivers/nvme/mdev/mmio.c | 3 - > 4 files changed, 421 insertions(+), 49 deletions(-) The changes in drivers/nvme/mdev aren't supposed to be here, this was some code moving around to reduce the diff in the generic block layer support code, it supposed to go to the main mdev commit. Best regards, Maxim Levitsky
Re: [PATCH] ARM: dts: am57xx-idk: Remove support for voltage switching for SD card
* Faiz Abbas [190502 01:48]:
> If UHS speed modes are enabled, a compatible SD card switches down to
> 1.8V during enumeration. If after this a software reboot/crash takes
> place and on-chip ROM tries to enumerate the SD card, the difference in
> IO voltages (host @ 3.3V and card @ 1.8V) may end up damaging the card.
>
> The fix for this is to have support for power cycling the card in
> hardware (with a PORz/soft-reset line causing a power cycle of the
> card). Since am571x-, am572x- and am574x-idk don't have this
> capability, disable voltage switching for these boards.
>
> The major effect of this is that the maximum supported speed
> mode is now high speed(50 MHz) down from SDR104(200 MHz).
This sounds a bit urgent, does it also need a stable tag or is
it safe to apply against any earlier kernels?
Regards,
Tony
> Signed-off-by: Faiz Abbas
> ---
> arch/arm/boot/dts/am57xx-idk-common.dtsi | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/arm/boot/dts/am57xx-idk-common.dtsi
> b/arch/arm/boot/dts/am57xx-idk-common.dtsi
> index f7bd26458915..42e433da79ec 100644
> --- a/arch/arm/boot/dts/am57xx-idk-common.dtsi
> +++ b/arch/arm/boot/dts/am57xx-idk-common.dtsi
> @@ -420,6 +420,7 @@
> vqmmc-supply = <&ldo1_reg>;
> bus-width = <4>;
> cd-gpios = <&gpio6 27 GPIO_ACTIVE_LOW>; /* gpio 219 */
> + no-1-8-v;
> };
>
> &mmc2 {
> --
> 2.19.2
>
[PATCH] EDAC, mpc85xx: Prevent building as a module
The mpc85xx EDAC code can be configured as a module but then fails to
build because it uses two unexported symbols:
ERROR: ".pci_find_hose_for_OF_device" [drivers/edac/mpc85xx_edac_mod.ko]
undefined!
ERROR: ".early_find_capability" [drivers/edac/mpc85xx_edac_mod.ko] undefined!
We don't want to export those symbols just for this driver, so make
the driver only configurable as a built-in.
This seems to have been broken since at least commit c92132f59806
("edac/85xx: Add PCIe error interrupt edac support") (Nov 2013).
Signed-off-by: Michael Ellerman
---
drivers/edac/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/edac/Kconfig b/drivers/edac/Kconfig
index 47eb4d13ed5f..6317519f9d88 100644
--- a/drivers/edac/Kconfig
+++ b/drivers/edac/Kconfig
@@ -263,7 +263,7 @@ config EDAC_PND2
micro-server but may appear on others in the future.
config EDAC_MPC85XX
- tristate "Freescale MPC83xx / MPC85xx"
+ bool "Freescale MPC83xx / MPC85xx"
depends on FSL_SOC
help
Support for error detection and correction on the Freescale
--
2.20.1
[PATCH V2 2/3] watchdog: stm32: update return values recommended by watchdog kernel api
From: Ludovic Barre
This patch updates return values on watchdog-kernel-api.txt:
return 0 on succes, -EINVAL for "parameter out of range"
and -EIO for "could not write value to the watchdog".
Signed-off-by: Ludovic Barre
---
drivers/watchdog/stm32_iwdg.c | 21 +
1 file changed, 13 insertions(+), 8 deletions(-)
diff --git a/drivers/watchdog/stm32_iwdg.c b/drivers/watchdog/stm32_iwdg.c
index e191bd8..f19a6d4 100644
--- a/drivers/watchdog/stm32_iwdg.c
+++ b/drivers/watchdog/stm32_iwdg.c
@@ -81,7 +81,6 @@ static int stm32_iwdg_start(struct watchdog_device *wdd)
struct stm32_iwdg *wdt = watchdog_get_drvdata(wdd);
u32 val = FLAG_PVU | FLAG_RVU;
u32 reload;
- int ret;
dev_dbg(wdd->parent, "%s\n", __func__);
@@ -98,13 +97,11 @@ static int stm32_iwdg_start(struct watchdog_device *wdd)
reg_write(wdt->regs, IWDG_KR, KR_KEY_ENABLE);
/* wait for the registers to be updated (max 100ms) */
- ret = readl_relaxed_poll_timeout(wdt->regs + IWDG_SR, val,
-!(val & (FLAG_PVU | FLAG_RVU)),
-SLEEP_US, TIMEOUT_US);
- if (ret) {
- dev_err(wdd->parent,
- "Fail to set prescaler or reload registers\n");
- return ret;
+ if (readl_relaxed_poll_timeout(wdt->regs + IWDG_SR, val,
+ !(val & (FLAG_PVU | FLAG_RVU)),
+ SLEEP_US, TIMEOUT_US)) {
+ dev_err(wdd->parent, "Fail to set prescaler, reload regs\n");
+ return -EIO;
}
/* reload watchdog */
@@ -128,8 +125,16 @@ static int stm32_iwdg_ping(struct watchdog_device *wdd)
static int stm32_iwdg_set_timeout(struct watchdog_device *wdd,
unsigned int timeout)
{
+ unsigned int tout = clamp(timeout, wdd->min_timeout,
+ wdd->max_hw_heartbeat_ms / 1000);
+
dev_dbg(wdd->parent, "%s timeout: %d sec\n", __func__, timeout);
+ if (tout != timeout) {
+ dev_err(wdd->parent, "parameter out of range\n");
+ return -EINVAL;
+ }
+
wdd->timeout = timeout;
if (watchdog_active(wdd))
--
2.7.4
Re: [PATCH] mtd: nand: raw: brcmnand: When oops in progress use pio and interrupt polling
On Thu, May 2, 2019 at 4:25 AM Miquel Raynal wrote:
>
> Hi Kamal,
>
> Kamal Dasu wrote on Wed, 1 May 2019 13:46:15
> -0400:
>
> > If mtd_oops is in progress switch to polling for nand command completion
>
> s/nand/NAND/
Will change this.
>
> > interrupts and use PIO mode wihtout DMA so that the mtd_oops buffer can
> > be completely written in the assinged nand partition.
>
> What about:
>
> "If mtd_oops is in progress, switch to polling during NAND command
> completion instead of relying on DMA/interrupts so that the mtd_oops
> buffer can be completely written in the assigned NAND partition."
>
Will make this change as well
> > This is needed in
> > cases where the panic does not happen on cpu0 and there is only one online
> > CPU and the panic is not on cpu0.
>
> "This is needed in case the panic does not happen on CPU0 and there is
> only one online CPU."
>
> I am not sure to understand the problem or how this can happen (and
> be a problem). Have you met such issue already or is this purely
> speculative?
We have seen this issue and tested it on multi core SoCs.
>
> >
> > Signed-off-by: Kamal Dasu
> > ---
> > drivers/mtd/nand/raw/brcmnand/brcmnand.c | 55
> > ++--
> > 1 file changed, 52 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/mtd/nand/raw/brcmnand/brcmnand.c
> > b/drivers/mtd/nand/raw/brcmnand/brcmnand.c
> > index 482c6f0..cfbe51a 100644
> > --- a/drivers/mtd/nand/raw/brcmnand/brcmnand.c
> > +++ b/drivers/mtd/nand/raw/brcmnand/brcmnand.c
> > @@ -823,6 +823,12 @@ static inline bool has_flash_dma(struct
> > brcmnand_controller *ctrl)
> > return ctrl->flash_dma_base;
> > }
> >
> > +static inline void disable_flash_dma_xfer(struct brcmnand_controller *ctrl)
> > +{
> > + if (has_flash_dma(ctrl))
> > + ctrl->flash_dma_base = 0;
> > +}
> > +
> > static inline bool flash_dma_buf_ok(const void *buf)
> > {
> > return buf && !is_vmalloc_addr(buf) &&
> > @@ -1237,15 +1243,58 @@ static void brcmnand_cmd_ctrl(struct nand_chip
> > *chip, int dat,
> > /* intentionally left blank */
> > }
> >
> > +static bool is_mtd_oops_in_progress(void)
> > +{
> > + int i = 0;
> > +
> > +#ifdef CONFIG_MTD_OOPS
> > + if (oops_in_progress && smp_processor_id()) {
> > + int cpu = 0;
> > +
> > + for_each_online_cpu(cpu)
> > + ++i;
> > + }
> > +#endif
> > + return i == 1 ? true : false;
>
> I suppose return (i == 1); is enough
>
Ok will make the change.
> > +}
> > +
> > +static bool brcmstb_nand_wait_for_completion(struct nand_chip *chip)
> > +{
> > + struct brcmnand_host *host = nand_get_controller_data(chip);
> > + struct brcmnand_controller *ctrl = host->ctrl;
> > + bool err = false;
> > + int sts;
> > +
> > + if (is_mtd_oops_in_progress()) {
> > + /* Switch to interrupt polling and PIO mode */
> > + disable_flash_dma_xfer(ctrl);
> > + sts = bcmnand_ctrl_poll_status(ctrl, NAND_CTRL_RDY |
> > +NAND_STATUS_READY,
> > +NAND_CTRL_RDY |
> > +NAND_STATUS_READY, 0);
> > + err = (sts < 0) ? true : false;
> > + } else {
> > + unsigned long timeo = msecs_to_jiffies(
> > + NAND_POLL_STATUS_TIMEOUT_MS);
> > + /* wait for completion interrupt */
> > + sts = wait_for_completion_timeout(&ctrl->done, timeo);
> > + err = (sts <= 0) ? true : false;
> > + }
> > +
> > + return err;
> > +}
> > +
> > static int brcmnand_waitfunc(struct nand_chip *chip)
> > {
> > struct brcmnand_host *host = nand_get_controller_data(chip);
> > struct brcmnand_controller *ctrl = host->ctrl;
> > - unsigned long timeo = msecs_to_jiffies(100);
> > + bool err = false;
> >
> > dev_dbg(ctrl->dev, "wait on native cmd %d\n", ctrl->cmd_pending);
> > - if (ctrl->cmd_pending &&
> > - wait_for_completion_timeout(&ctrl->done, timeo) <= 0)
> > {
>
> What about the wait_for_completion_timeout() call in brcmnand_write()?
>
brcmnand_write() too calls brcmnand_waitfunc(), will poll if it needs
to for completion.
> > + if (ctrl->cmd_pending)
> > + err = brcmstb_nand_wait_for_completion(chip);
> > +
> > + if (err) {
> > u32 cmd = brcmnand_read_reg(ctrl, BRCMNAND_CMD_START)
> > >> brcmnand_cmd_shift(ctrl);
> >
>
>
> Thanks,
> Miquèl
Thanks
Kamal
[PATCH V2 0/3] watchdog: stm32: add dynamic prescaler support
From: Ludovic Barre This patch series updates stm32 watchdog driver on: -use devm_watchdog_register_device -Guenter's recommendation about return value: set_timeout return 0 on succes, -EINVAL for "parameter out of range" and -EIO for "could not write value to the watchdog". Set of reload and prescaler registers are stay in start function, because the stm32 watchdog must be enabled to write these registers. -adds dynamic prescaler support Ludovic Barre (3): watchdog: stm32: update to devm_watchdog_register_device watchdog: stm32: update return values recommended by watchdog kernel api watchdog: stm32: add dynamic prescaler support drivers/watchdog/stm32_iwdg.c | 96 --- 1 file changed, 54 insertions(+), 42 deletions(-) -- 2.7.4
[PATCH V2 3/3] watchdog: stm32: add dynamic prescaler support
From: Ludovic Barre
This patch allows to define the max prescaler by compatible.
To set a large range of timeout, the prescaler should be set
dynamically (from the timeout request) to improve the resolution
in order to have a timeout close to the expected value.
Signed-off-by: Ludovic Barre
---
drivers/watchdog/stm32_iwdg.c | 76 ---
1 file changed, 42 insertions(+), 34 deletions(-)
diff --git a/drivers/watchdog/stm32_iwdg.c b/drivers/watchdog/stm32_iwdg.c
index f19a6d4..0c765d4 100644
--- a/drivers/watchdog/stm32_iwdg.c
+++ b/drivers/watchdog/stm32_iwdg.c
@@ -34,18 +34,12 @@
#define KR_KEY_EWA 0x /* write access enable */
#define KR_KEY_DWA 0x /* write access disable */
-/* IWDG_PR register bit values */
-#define PR_4 0x00 /* prescaler set to 4 */
-#define PR_8 0x01 /* prescaler set to 8 */
-#define PR_16 0x02 /* prescaler set to 16 */
-#define PR_32 0x03 /* prescaler set to 32 */
-#define PR_64 0x04 /* prescaler set to 64 */
-#define PR_128 0x05 /* prescaler set to 128 */
-#define PR_256 0x06 /* prescaler set to 256 */
+#define PR_SHIFT 2
+#define PR_MIN BIT(PR_SHIFT)
/* IWDG_RLR register values */
-#define RLR_MIN0x07C /* min value supported by reload register
*/
-#define RLR_MAX0xFFF /* max value supported by reload register
*/
+#define RLR_MIN0x2 /* min value recommended */
+#define RLR_MAXGENMASK(11, 0) /* max value of reload register
*/
/* IWDG_SR register bit mask */
#define FLAG_PVU BIT(0) /* Watchdog prescaler value update */
@@ -55,15 +49,28 @@
#define TIMEOUT_US 10
#define SLEEP_US 1000
-#define HAS_PCLK true
+struct stm32_iwdg_data {
+ bool has_pclk;
+ u32 max_prescaler;
+};
+
+static const struct stm32_iwdg_data stm32_iwdg_data = {
+ .has_pclk = false,
+ .max_prescaler = 256,
+};
+
+static const struct stm32_iwdg_data stm32mp1_iwdg_data = {
+ .has_pclk = true,
+ .max_prescaler = 1024,
+};
struct stm32_iwdg {
struct watchdog_device wdd;
+ const struct stm32_iwdg_data *data;
void __iomem*regs;
struct clk *clk_lsi;
struct clk *clk_pclk;
unsigned intrate;
- boolhas_pclk;
};
static inline u32 reg_read(void __iomem *base, u32 reg)
@@ -79,26 +86,28 @@ static inline void reg_write(void __iomem *base, u32 reg,
u32 val)
static int stm32_iwdg_start(struct watchdog_device *wdd)
{
struct stm32_iwdg *wdt = watchdog_get_drvdata(wdd);
- u32 val = FLAG_PVU | FLAG_RVU;
- u32 reload;
+ u32 presc, iwdg_rlr, iwdg_pr, iwdg_sr;
dev_dbg(wdd->parent, "%s\n", __func__);
- /* prescaler fixed to 256 */
- reload = clamp_t(unsigned int, ((wdd->timeout * wdt->rate) / 256) - 1,
-RLR_MIN, RLR_MAX);
+ presc = DIV_ROUND_UP(wdd->timeout * wdt->rate, RLR_MAX + 1);
+
+ /* The prescaler is align on power of 2 and start at 2 ^ PR_SHIFT. */
+ presc = roundup_pow_of_two(presc);
+ iwdg_pr = presc <= 1 << PR_SHIFT ? 0 : ilog2(presc) - PR_SHIFT;
+ iwdg_rlr = ((wdd->timeout * wdt->rate) / presc) - 1;
+ /* enable watchdog */
+ reg_write(wdt->regs, IWDG_KR, KR_KEY_ENABLE);
/* enable write access */
reg_write(wdt->regs, IWDG_KR, KR_KEY_EWA);
-
/* set prescaler & reload registers */
- reg_write(wdt->regs, IWDG_PR, PR_256); /* prescaler fix to 256 */
- reg_write(wdt->regs, IWDG_RLR, reload);
- reg_write(wdt->regs, IWDG_KR, KR_KEY_ENABLE);
+ reg_write(wdt->regs, IWDG_PR, iwdg_pr);
+ reg_write(wdt->regs, IWDG_RLR, iwdg_rlr);
/* wait for the registers to be updated (max 100ms) */
- if (readl_relaxed_poll_timeout(wdt->regs + IWDG_SR, val,
- !(val & (FLAG_PVU | FLAG_RVU)),
+ if (readl_relaxed_poll_timeout(wdt->regs + IWDG_SR, iwdg_sr,
+ !(iwdg_sr & (FLAG_PVU | FLAG_RVU)),
SLEEP_US, TIMEOUT_US)) {
dev_err(wdd->parent, "Fail to set prescaler, reload regs\n");
return -EIO;
@@ -155,7 +164,7 @@ static int stm32_iwdg_clk_init(struct platform_device *pdev,
}
/* optional peripheral clock */
- if (wdt->has_pclk) {
+ if (wdt->data->has_pclk) {
wdt->clk_pclk = devm_clk_get(&pdev->dev, "pclk");
if (IS_ERR(wdt->clk_pclk)) {
dev_err(&pdev->dev, "Unable to get pclk clock\n");
@@ -196,8 +205,8 @@ static const struct watchdog_ops stm32_iwdg_ops = {
};
static const struct of_device_id stm32_iwdg_of_match[] = {
- { .compatible = "st,stm32-iwdg", .data = (void *)!HAS_PCLK },
- { .compatible = "st,stm32mp1-iwdg", .
[PATCH V2 1/3] watchdog: stm32: update to devm_watchdog_register_device
From: Ludovic Barre
This patch updates to devm_watchdog_register_device interface
Signed-off-by: Ludovic Barre
---
drivers/watchdog/stm32_iwdg.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/watchdog/stm32_iwdg.c b/drivers/watchdog/stm32_iwdg.c
index e00e3b3..e191bd8 100644
--- a/drivers/watchdog/stm32_iwdg.c
+++ b/drivers/watchdog/stm32_iwdg.c
@@ -243,7 +243,7 @@ static int stm32_iwdg_probe(struct platform_device *pdev)
dev_warn(&pdev->dev,
"unable to set timeout value, using default\n");
- ret = watchdog_register_device(wdd);
+ ret = devm_watchdog_register_device(&pdev->dev, wdd);
if (ret) {
dev_err(&pdev->dev, "failed to register watchdog device\n");
goto err;
@@ -263,7 +263,6 @@ static int stm32_iwdg_remove(struct platform_device *pdev)
{
struct stm32_iwdg *wdt = platform_get_drvdata(pdev);
- watchdog_unregister_device(&wdt->wdd);
clk_disable_unprepare(wdt->clk_lsi);
clk_disable_unprepare(wdt->clk_pclk);
--
2.7.4
Re: [PATCH] overlayfs: ignore empty NFSv4 ACLs in ext4 upperdir
On Thu, 2 May 2019 at 05:57, NeilBrown wrote: > On Wed, May 01 2019, Amir Goldstein wrote: > > On Wed, May 1, 2019 at 10:03 PM NeilBrown wrote: > >> On Tue, Dec 06 2016, J. Bruce Fields wrote: > >> > On Tue, Dec 06, 2016 at 02:18:31PM +0100, Andreas Gruenbacher wrote: > >> >> On Tue, Dec 6, 2016 at 11:08 AM, Miklos Szeredi > >> >> wrote: > >> >> > On Tue, Dec 6, 2016 at 12:24 AM, Andreas Grünbacher > >> >> > wrote: > >> >> >> 2016-12-06 0:19 GMT+01:00 Andreas Grünbacher > >> >> >> : > >> >> > > >> >> >>> It's not hard to come up with a heuristic that determines if a > >> >> >>> system.nfs4_acl value is equivalent to a file mode, and to ignore > >> >> >>> the > >> >> >>> attribute in that case. (The file mode is transmitted in its own > >> >> >>> attribute already, so actually converting .) That way, overlayfs > >> >> >>> could > >> >> >>> still fail copying up files that have an actual ACL. It's still an > >> >> >>> ugly hack ... > >> >> >> > >> >> >> Actually, that kind of heuristic would make sense in the NFS client > >> >> >> which could then hide the "system.nfs4_acl" attribute. I still think the nfs client could make this problem mostly go away by not exposing "system.nfs4_acl" xattrs when the acl is equivalent to the file mode. The richacl patches contain a workable abgorithm for that. The problem would remain for files that have an actual NFS4 ACL, which just cannot be mapped to a file mode or to POSIX ACLs in the general case, as well as for files that have a POSIX ACL. Mapping NFS4 ACL that used to be a POSIX ACL back to POSIX ACLs could be achieved in many cases as well, but the code would be quite messy. A better way seems to be to using a filesystem that doesn't support POSIX ACLs in the first place. Unfortunately, xfs doesn't allow turning off POSIX ACLs, for example. Andreas > >> >> > Even simpler would be if knfsd didn't send the attribute if not > >> >> > necessary. Looks like there's code actively creating the nfs4_acl on > >> >> > the wire even if the filesystem had none: > >> >> > > >> >> > pacl = get_acl(inode, ACL_TYPE_ACCESS); > >> >> > if (!pacl) > >> >> > pacl = posix_acl_from_mode(inode->i_mode, GFP_KERNEL); > >> >> > > >> >> > What's the point? > >> >> > >> >> That's how the protocol is specified. > >> > > >> > Yep, even if we could make that change to nfsd it wouldn't help the > >> > client with the large number of other servers that are out there > >> > (including older knfsd's). > >> > > >> > --b. > >> > > >> >> (I'm not saying that that's very helpful.) > >> >> > >> >> Andreas > >> > >> Hi everyone. > >> I have a customer facing this problem, and so stumbled onto the email > >> thread. > >> Unfortunately it didn't resolve anything. Maybe I can help kick things > >> along??? > >> > >> The core problem here is that NFSv4 and ext4 use different and largely > >> incompatible ACL implementations. There is no way to accurately > >> translate from one to the other in general (common specific examples > >> can be converted). > >> > >> This means that either: > >>1/ overlayfs cannot use ext4 for upper and NFS for lower (or vice > >> versa) or > >>2/ overlayfs need to accept that sometimes it cannot copy ACLs, and > >> that is OK. > >> > >> Silently not copying the ACLs is probably not a good idea as it might > >> result in inappropriate permissions being given away. > > > > For example? permissions given away to do what? > > Note that ovl_permission() only check permissions of *mounter* > > to read the lower NFS file and ovl_open()/ovl_read_iter() access > > the lower file with *mounter* credentials. > > > > I might be wrong, but seems to me that once admin mounted > > overlayfs with lower NFS, NFS ACLs are not being enforced at all > > even before copy up. > > I guess it is just as well that copy-up fails then - if the lower-level > permission check is being ignored. > > > > >> So if the > >> sysadmin wants this (and some clearly do), they need a way to > >> explicitly say "I accept the risk". If only standard Unix permissions > >> are used, there is no risk, so this seems reasonable. > >> > >> So I would like to propose a new option for overlayfs > >> nocopyupacl: when overlayfs is copying a file (or directory etc) > >> from the lower filesystem to the upper filesystem, it does not > >> copy extended attributes with the "system." prefix. These are > >> used for storing ACL information and this is sometimes not > >> compatible between different filesystem types (e.g. ext4 and > >> NFSv4). Standard Unix ownership permission flags (rwx) *are* > >> copied so this option does not risk giving away inappropriate > >> permissions unless the lowerfs uses unusual ACLs. > >> > >> > > > > I am wondering if it would make more sense for nfs to register a > > security_inode_copy_up_xattr() hook. > > That is the mechanism that prevents copying up other security.* > >
Re: [PATCH 5/4] 9p: pass the correct prototype to read_cache_page
> On May 2, 2019, at 7:04 AM, Christoph Hellwig wrote: > > Except that we don't pass v9fs_vfs_readpage as the filler any more, > we now pass v9fs_fid_readpage. True, so never mind. :-)
Re: [PATCH] i2c: at91: handle TXRDY interrupt spam
On Tue, Apr 30, 2019 at 04:03:32AM +0530, Raag Jadav wrote:
> External E-Mail
>
>
> On Mon, Apr 29, 2019 at 11:00:05AM +0200, Ludovic Desroches wrote:
> > Hello Raag,
> >
> > On Tue, Apr 23, 2019 at 01:06:48PM +0530, Raag Jadav wrote:
> > > External E-Mail
> > >
> > >
> > > Performing i2c write operation while SDA or SCL line is held
> > > or grounded by slave device, we go into infinite at91_twi_write_next_byte
> > > loop with TXRDY interrupt spam.
> >
> > Sorry but I am not sure to have the full picture, the controller is in
> > slave or master mode?
> >
> > SVREAD is only used in slave mode. When SVREAD is set, it means that a read
> > access is performed and your issue concerns the write operation.
> >
> > Regards
> >
> > Ludovic
>
> Yes, even though the datasheet suggests that SVREAD is irrelevant in master
> mode,
> TXRDY and SVREAD are the only ones being set in status register upon
> reproducing the issue.
> Couldn't think of a better way to handle such strange behaviour.
> Any suggestions would be appreciated.
I have the confirmation that you can't rely on the SVREAD flag when in
master mode. This flag should always have the same value.
I am trying to understand what could lead to your situation. Can you
give me more details. What kind of device it is? What does lead to this
situation? Does it happen randomly or not?
Regards
Ludovic
>
> Cheers,
> Raag
>
> >
> > >
> > > Signed-off-by: Raag Jadav
> > > ---
> > > drivers/i2c/busses/i2c-at91.c | 6 +-
> > > 1 file changed, 5 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/i2c/busses/i2c-at91.c b/drivers/i2c/busses/i2c-at91.c
> > > index 3f3e8b3..b2f5fdb 100644
> > > --- a/drivers/i2c/busses/i2c-at91.c
> > > +++ b/drivers/i2c/busses/i2c-at91.c
> > > @@ -72,6 +72,7 @@
> > > #define AT91_TWI_TXCOMP BIT(0) /* Transmission Complete */
> > > #define AT91_TWI_RXRDY BIT(1) /* Receive Holding Register
> > > Ready */
> > > #define AT91_TWI_TXRDY BIT(2) /* Transmit Holding Register
> > > Ready */
> > > +#define AT91_TWI_SVREAD BIT(3) /* Slave Read */
> > > #define AT91_TWI_OVRE BIT(6) /* Overrun Error */
> > > #define AT91_TWI_UNRE BIT(7) /* Underrun Error */
> > > #define AT91_TWI_NACK BIT(8) /* Not Acknowledged */
> > > @@ -571,7 +572,10 @@ static irqreturn_t atmel_twi_interrupt(int irq, void
> > > *dev_id)
> > > at91_disable_twi_interrupts(dev);
> > > complete(&dev->cmd_complete);
> > > } else if (irqstatus & AT91_TWI_TXRDY) {
> > > - at91_twi_write_next_byte(dev);
> > > + if ((status & AT91_TWI_SVREAD) && (dev->buf_len == 0))
> > > + at91_twi_write(dev, AT91_TWI_IDR, AT91_TWI_TXRDY);
> > > + else
> > > + at91_twi_write_next_byte(dev);
> > > }
> > >
> > > /* catch error flags */
> > > --
> > > 2.7.4
> > >
> > >
>
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
Re: [PATCH] OVL: add honoracl=off mount option.
NeilBrown: > If the upper and lower layers use incompatible ACL formats, it is not > possible to copy the ACL xttr from one to the other, so overlayfs > cannot work with them. > This happens particularly with NFSv4 which uses system.nfs4_acl, and > ext4 which uses system.posix_acl_access. FYI, Aufs had met the same problem many years ago, and I introduced some options called ICEX (Ignore Copyup Error on Xattr). (from the design doc in aufs) For example, the src branch supports ACL but the dst branch doesn't because the dst branch may natively un-support it or temporary un-support it due to "noacl" mount option. Of course, the dst branch fs may NOT return an error even if the XATTR is not supported. It is totally up to the branch fs. Anyway when the aufs internal copy-up gets an error from the dst branch fs, then aufs tries removing the just copied entry and returns the error to the userspace. The worst case of this situation will be all copy-up will fail. For the copy-up operation, there two basic approaches. - copy the specified XATTR only (by category above), and return the error unconditionally if it happens. - copy all XATTR, and ignore the error on the specified category only. In order to support XATTR and to implement the correct behaviour, aufs chooses the latter approach and introduces some new branch attributes, "icexsec", "icexsys", "icextr", "icexusr", and "icexoth". They correspond to the XATTR namespaces (see above). Additionally, to be convenient, "icex" is also provided which means all "icex*" attributes are set (here the word "icex" stands for "ignore copy-error on XATTR"). The meaning of these attributes is to ignore the error from setting XATTR on that branch. Note that aufs tries copying all XATTR unconditionally, and ignores the error from the dst branch according to the specified attributes. But recent nfs4 got changed its behaviour around ACL, and it didn't pass my local tests. I had posted about that, but got no reply. J. R. Okajima
[GIT PULL] PCI fixes for v5.1
Hi Linus, I apologize for sending these so late in the cycle. We went back and forth about how to deal with the unexpected logging of intentional link state changes and finally decided to just config them off by default. PCI fixes: - Stop ignoring "pci=disable_acs_redir" parameter (Logan Gunthorpe) - Use shared MSI/MSI-X vector for Link Bandwidth Management (Alex Williamson) - Add Kconfig option for Link Bandwidth notification messages (Keith Busch) The following changes since commit 3943af9d01e94330d0cfac6fccdbc829aad50c92: PCI: pciehp: Ignore Link State Changes after powering off a slot (2019-04-10 16:06:43 -0500) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git tags/pci-v5.1-fixes-3 for you to fetch changes up to 2078e1e7f7e0e21bd0291908f3037c39e666d27b: PCI/LINK: Add Kconfig option (default off) (2019-05-02 08:34:32 -0500) pci-v5.1-fixes-3 Alex Williamson (1): PCI/portdrv: Use shared MSI/MSI-X vector for Bandwidth Management Keith Busch (1): PCI/LINK: Add Kconfig option (default off) Logan Gunthorpe (1): PCI: Fix issue with "pci=disable_acs_redir" parameter being ignored drivers/pci/pci.c | 19 +-- drivers/pci/pcie/Kconfig| 8 drivers/pci/pcie/Makefile | 2 +- drivers/pci/pcie/portdrv.h | 4 drivers/pci/pcie/portdrv_core.c | 3 ++- 5 files changed, 32 insertions(+), 4 deletions(-)
Re: [PATCH v2] clk: imx8mq: Add dsi_ipg_div
On Thu, May 2, 2019 at 10:07 AM Guido Günther wrote: > > It's defined in imx8mq-clock.h but wasn't assigned yet. It's used as > clk_tx_esc in the nwl dsi host controller (i.MX8MQ RM, Rev. 0, 01/2018 > Sect. 13.5.3.7.4). > > Signed-off-by: Guido Günther Reviewed-by: Fabio Estevam
Re: [PATCH 1/2] pinctrl: mediatek: Add mtk_eint_pm_ops to common-v2
On Mon, 2019-04-29 at 11:25 +0800, Nicolas Boichat wrote:
> pinctrl variants that include pinctrl-mtk-common-v2.h (and not
> pinctrl-mtk-common.h) also need to use mtk_eint_pm_ops to setup
> wake mask properly, so copy over the pm_ops to v2.
>
> It is not easy to merge the 2 copies (or move
> mtk_eint_suspend/resume to mtk-eint.c), as we need to
> dereference pctrl->eint, and struct mtk_pinctrl *pctl has a
> different structure definition for v1 and v2.
>
> Signed-off-by: Nicolas Boichat
> Reviewed-by: Chuanjia Liu
> ---
> .../pinctrl/mediatek/pinctrl-mtk-common-v2.c | 19 +++
> .../pinctrl/mediatek/pinctrl-mtk-common-v2.h | 1 +
> 2 files changed, 20 insertions(+)
>
> diff --git a/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.c
> b/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.c
> index 20e1c890e73b30c..7e19b5a4748eafe 100644
> --- a/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.c
> +++ b/drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.c
> @@ -723,3 +723,22 @@ int mtk_pinconf_adv_drive_get(struct mtk_pinctrl *hw,
>
> return 0;
> }
> +
> +static int mtk_eint_suspend(struct device *device)
> +{
> + struct mtk_pinctrl *pctl = dev_get_drvdata(device);
> +
> + return mtk_eint_do_suspend(pctl->eint);
> +}
> +
> +static int mtk_eint_resume(struct device *device)
> +{
> + struct mtk_pinctrl *pctl = dev_get_drvdata(device);
> +
> + return mtk_eint_do_resume(pctl->eint);
> +}
> +
> +const struct dev_pm_ops mtk_eint_pm_ops = {
> + .suspend_noirq = mtk_eint_suspend,
> + .resume_noirq = mtk_eint_resume,
> +};
This is identical to the one in pinctrl-mtk-common.c and will have name
clash if both pinctrl-mtk-common.c and pinctrl-mtk-common-v2.c are
built.
It would be better if we try to merge both version into mtk-eint.c, this
way we could also remove some global functions.
Joe.C
[PATCH v6 4/5] ARM: dts: sun8i: v40: bananapi-m2-berry: Enable AHCI
Just like the Bananapi M2 Ultra, enable the ahci controller and
the two regulators needed to activate it.
Reviewed-by: Jagan Teki
Signed-off-by: Pablo Greco
---
arch/arm/boot/dts/sun8i-v40-bananapi-m2-berry.dts | 18 ++
1 file changed, 18 insertions(+)
diff --git a/arch/arm/boot/dts/sun8i-v40-bananapi-m2-berry.dts
b/arch/arm/boot/dts/sun8i-v40-bananapi-m2-berry.dts
index 1f4f51f9..461683c 100644
--- a/arch/arm/boot/dts/sun8i-v40-bananapi-m2-berry.dts
+++ b/arch/arm/boot/dts/sun8i-v40-bananapi-m2-berry.dts
@@ -99,6 +99,12 @@
};
};
+&ahci {
+ ahci-supply = <®_dldo4>;
+ phy-supply = <®_eldo3>;
+ status = "okay";
+};
+
&de {
status = "okay";
};
@@ -233,6 +239,18 @@
regulator-name = "vcc-wifi";
};
+®_dldo4 {
+ regulator-min-microvolt = <250>;
+ regulator-max-microvolt = <250>;
+ regulator-name = "vdd2v5-sata";
+};
+
+®_eldo3 {
+ regulator-min-microvolt = <120>;
+ regulator-max-microvolt = <120>;
+ regulator-name = "vdd1v2-sata";
+};
+
&tcon_tv0 {
status = "okay";
};
--
1.8.3.1
[PATCH v6 5/5] ARM: dts: sun8i: v40: bananapi-m2-berry: Add Bluetooth device node
The AP6212 is based on the Broadcom BCM43430 or BCM43438. The WiFi side
identifies as BCM43430, while the Bluetooth side identifies as BCM43438.
The Bluetooth side is connected to UART3 in a 4 wire configuration. Same
as the WiFi side, due to being the same chip and package, DLDO1 and
DLDO2 regulator outputs from the PMIC provide overall power via VBAT and
I/O power via VDDIO. The CLK_OUT_A clock output from the SoC provides
the LPO low power clock at 32.768 kHz.
This patch enables Bluetooth on this board, and also adds the missing
LPO clock on the WiFi side. There is also a PCM connection for
Bluetooth, but this is not covered here.
The LPO clock is fed from CLK_OUT_A, which needs to be muxed on pin
PI12. This can be represented in multiple ways. This patch puts the
pinctrl property in the pin controller node. This is due to limitations
in Linux, where pinmux settings, even the same one, can not be shared
by multiple devices. Thus we cannot put it in both the WiFi and
Bluetooth device nodes. Putting it the CCU node is another option, but
Linux's CCU driver does not handle pinctrl. Also the pin controller is
guaranteed to be initialized after the CCU, when clocks are available.
And any other devices that use muxed pins are guaranteed to be
initialized after the pin controller. Thus having the CLK_OUT_A pinmux
reference be in the pin controller node is a good choice without having
to deal with implementation issues.
Signed-off-by: Pablo Greco
---
arch/arm/boot/dts/sun8i-v40-bananapi-m2-berry.dts | 38 +++
1 file changed, 38 insertions(+)
diff --git a/arch/arm/boot/dts/sun8i-v40-bananapi-m2-berry.dts
b/arch/arm/boot/dts/sun8i-v40-bananapi-m2-berry.dts
index 461683c..15c22b0 100644
--- a/arch/arm/boot/dts/sun8i-v40-bananapi-m2-berry.dts
+++ b/arch/arm/boot/dts/sun8i-v40-bananapi-m2-berry.dts
@@ -96,6 +96,8 @@
wifi_pwrseq: wifi_pwrseq {
compatible = "mmc-pwrseq-simple";
reset-gpios = <&pio 6 10 GPIO_ACTIVE_LOW>; /* PG10 WIFI_EN */
+ clocks = <&ccu CLK_OUTA>;
+ clock-names = "ext_clock";
};
};
@@ -172,6 +174,8 @@
};
&pio {
+ pinctrl-names = "default";
+ pinctrl-0 = <&clk_out_a_pin>;
vcc-pa-supply = <®_aldo2>;
vcc-pc-supply = <®_dcdc1>;
vcc-pd-supply = <®_dcdc1>;
@@ -233,12 +237,27 @@
regulator-name = "vcc-wifi-io";
};
+/*
+ * Our WiFi chip needs both DLDO2 and DLDO3 to be powered at the same
+ * time, with the two being in sync, to be able to meet maximum power
+ * consumption during transmits. Since this is not really supported
+ * right now, just use the two as always on, and we will fix it later.
+ */
+
®_dldo2 {
+ regulator-always-on;
regulator-min-microvolt = <330>;
regulator-max-microvolt = <330>;
regulator-name = "vcc-wifi";
};
+®_dldo3 {
+ regulator-always-on;
+ regulator-min-microvolt = <330>;
+ regulator-max-microvolt = <330>;
+ regulator-name = "vcc-wifi-2";
+};
+
®_dldo4 {
regulator-min-microvolt = <250>;
regulator-max-microvolt = <250>;
@@ -261,6 +280,25 @@
status = "okay";
};
+&uart3 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&uart3_pg_pins>, <&uart3_rts_cts_pg_pins>;
+ uart-has-rtscts;
+ status = "okay";
+
+ bluetooth {
+ compatible = "brcm,bcm43438-bt";
+ clocks = <&ccu CLK_OUTA>;
+ clock-names = "lpo";
+ vbat-supply = <®_dldo2>;
+ vddio-supply = <®_dldo1>;
+ device-wakeup-gpios = <&pio 6 11 GPIO_ACTIVE_HIGH>; /* PG11 */
+ /* TODO host wake line connected to PMIC GPIO pins */
+ shutdown-gpios = <&pio 7 12 GPIO_ACTIVE_HIGH>; /* PH12 */
+ max-speed = <150>;
+ };
+};
+
&usbphy {
usb1_vbus-supply = <®_vcc5v0>;
status = "okay";
--
1.8.3.1
[PATCH v6 3/5] ARM: dts: sun8i: v40: bananapi-m2-berry: Enable HDMI output
This patch adds the hdmi nodes to the Bananapi M2 Berry, the same way it
was done to the Bananapi M2 Ultra
Signed-off-by: Pablo Greco
---
arch/arm/boot/dts/sun8i-v40-bananapi-m2-berry.dts | 29 +++
1 file changed, 29 insertions(+)
diff --git a/arch/arm/boot/dts/sun8i-v40-bananapi-m2-berry.dts
b/arch/arm/boot/dts/sun8i-v40-bananapi-m2-berry.dts
index 0dfde58..1f4f51f9 100644
--- a/arch/arm/boot/dts/sun8i-v40-bananapi-m2-berry.dts
+++ b/arch/arm/boot/dts/sun8i-v40-bananapi-m2-berry.dts
@@ -58,6 +58,17 @@
stdout-path = "serial0:115200n8";
};
+ connector {
+ compatible = "hdmi-connector";
+ type = "a";
+
+ port {
+ hdmi_con_in: endpoint {
+ remote-endpoint = <&hdmi_out_con>;
+ };
+ };
+ };
+
leds {
compatible = "gpio-leds";
@@ -88,6 +99,10 @@
};
};
+&de {
+ status = "okay";
+};
+
&ehci1 {
/* Terminus Tech FE 1.1s 4-port USB 2.0 hub here */
status = "okay";
@@ -109,6 +124,16 @@
};
};
+&hdmi {
+ status = "okay";
+};
+
+&hdmi_out {
+ hdmi_out_con: endpoint {
+ remote-endpoint = <&hdmi_con_in>;
+ };
+};
+
&i2c0 {
status = "okay";
@@ -208,6 +233,10 @@
regulator-name = "vcc-wifi";
};
+&tcon_tv0 {
+ status = "okay";
+};
+
&uart0 {
pinctrl-names = "default";
pinctrl-0 = <&uart0_pb_pins>;
--
1.8.3.1
Re: [PATCH 0/6] Add support for Tegra186/Tegra194 and generic fixes
On 02/05/2019 13:55, Sameer Pujar wrote: > Audio DMA(ADMA) interface is a gateway in the AHUB for facilitating DMA > transfers between memory and all of its clients. Currently the driver > supports Tegra210 based platforms. This series adds support for Tegra186 > and Tegra194 based platforms and fixes few functional issues. > > Patches in the series are classified into three categories, > 1. Add support for Tegra186 and Tegra194 > 2. Add DMA pause/resume feature > 3. Fixes common to differernt Tegra generations > > Below change log describes the patches in detail. > > Change log: > = > v1 > > The series can be classified into 3 categories, > 1. Add support for Tegra186 and Tegra194 > [Patch 1/6] dmaengine: tegra210-adma: prepare for supporting newer > Tegra chips >* The support was there only for Tegra210 >* This is a preparation for adding support for newer Tegra chips >* chip_data is enhanced to support differences between Tegra210 and > Tegra186/Tegra194 > [Patch 2/6] Documentation: DT: Add compatibility binding for Tegra186 >* New compatibility string is required for driver to work for > Tegra186 and Tegra194. Hence new compatibility is introduced. >* Tegra194 can use the same compatibility as Tegra186 > [Patch 3/6] dmaengine: tegra210-adma: add support for Tegra186/ > Tegra194 >* Populates chip specific information for Tegra186 >* There is a difference in the way ADMA CH_CONFIG registers are > encoded for Tegra210 and Tegra186. Added helper fucntions to > support different versions of burst size configuration > > 2. Add DMA pause/resume feature > [Patch 4/6] dmaengine: tegra210-adma: add pause/resume support >* Adds support for ADMA pause/resume, otherwise audio loss was seen > during continuous pause/resume of audio playback. > > 3. Fixes common to differernt Tegra generations > [Patch 5/6] dmaengine: tegra210-dma: free dma controller in remove() >* Fixes kernel panic observed during driver reload. DMA controller > needs to be freed when driver is unloaded > [Patch 6/6] dmaengine: tegra210-adma: restore channel status >* Fixes resume across system suspend. If the channel state is not > restored, the transfers won't resume from the state from where it > was left during suspend entry. In this case, audio playback did > not resume properly once system exited from low power state. > > === > Sameer Pujar (6): > dmaengine: tegra210-adma: prepare for supporting newer Tegra chips > Documentation: DT: Add compatibility binding for Tegra186 > dmaengine: tegra210-adma: add support for Tegra186/Tegra194 > dmaengine: tegra210-adma: add pause/resume support > dmaengine: tegra210-dma: free dma controller in remove() > dmaengine: tegra210-adma: restore channel status > > .../bindings/dma/nvidia,tegra210-adma.txt | 4 +- > drivers/dma/tegra210-adma.c | 232 + > 2 files changed, 193 insertions(+), 43 deletions(-) > Thanks! For the series ... Reviewed-by: Jon Hunter Cheers Jon -- nvpublic
Re: [PATCH v2 2/2] RISC-V: sifive_l2_cache: Add L2 cache controller driver for SiFive SoCs
On 5/2/19 6:34 AM, Yash Shah wrote:
> The driver currently supports only SiFive FU540-C000 platform.
>
> The initial version of L2 cache controller driver includes:
> - Initial configuration reporting at boot up.
> - Support for ECC related functionality.
>
> Signed-off-by: Yash Shah
> ---
> arch/riscv/mm/Makefile | 1 +
> arch/riscv/mm/sifive_l2_cache.c | 221
>
> 2 files changed, 222 insertions(+)
> create mode 100644 arch/riscv/mm/sifive_l2_cache.c
>
> diff --git a/arch/riscv/mm/Makefile b/arch/riscv/mm/Makefile
> index eb22ab4..1523ee5 100644
> --- a/arch/riscv/mm/Makefile
> +++ b/arch/riscv/mm/Makefile
> @@ -3,3 +3,4 @@ obj-y += fault.o
> obj-y += extable.o
> obj-y += ioremap.o
> obj-y += cacheflush.o
> +obj-y += sifive_l2_cache.o
> diff --git a/arch/riscv/mm/sifive_l2_cache.c b/arch/riscv/mm/sifive_l2_cache.c
> new file mode 100644
> index 000..923ab34
> --- /dev/null
> +++ b/arch/riscv/mm/sifive_l2_cache.c
> @@ -0,0 +1,221 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * SiFive L2 cache controller Driver
> + *
> + * Copyright (C) 2018-2019 SiFive, Inc.
> + *
> + */
> +#include
> +#include
> +#include
> +#include
> +
> +#define SIFIVE_L2_DIRECCFIX_LOW 0x100
> +#define SIFIVE_L2_DIRECCFIX_HIGH 0x104
> +#define SIFIVE_L2_DIRECCFIX_COUNT 0x108
> +
> +#define SIFIVE_L2_DATECCFIX_LOW 0x140
> +#define SIFIVE_L2_DATECCFIX_HIGH 0x144
> +#define SIFIVE_L2_DATECCFIX_COUNT 0x148
> +
> +#define SIFIVE_L2_DATECCFAIL_LOW 0x160
> +#define SIFIVE_L2_DATECCFAIL_HIGH 0x164
> +#define SIFIVE_L2_DATECCFAIL_COUNT 0x168
> +
> +#define SIFIVE_L2_CONFIG 0x00
> +#define SIFIVE_L2_WAYENABLE 0x08
> +#define SIFIVE_L2_ECCINJECTERR 0x40
> +
> +#define SIFIVE_L2_ERR_TYPE_CE 0
> +#define SIFIVE_L2_ERR_TYPE_UE 1
> +#define SIFIVE_L2_MAX_ECCINTR 3
> +
> +static void __iomem *l2_base;
> +static int g_irq[SIFIVE_L2_MAX_ECCINTR];
> +
> +enum {
> + DIR_CORR = 0,
> + DATA_CORR,
> + DATA_UNCORR,
> +};
> +
> +static unsigned int l2_dirfix_addr_high(void)
> +{
> + return readl(l2_base + SIFIVE_L2_DIRECCFIX_HIGH);
> +}
> +
> +static unsigned int l2_dirfix_addr_low(void)
> +{
> + return readl(l2_base + SIFIVE_L2_DIRECCFIX_LOW);
> +}
> +
> +static unsigned int l2_dirfix_count(void)
> +{
> + return readl(l2_base + SIFIVE_L2_DIRECCFIX_COUNT);
> +}
> +
> +static unsigned int l2_datfix_addr_high(void)
> +{
> + return readl(l2_base + SIFIVE_L2_DATECCFIX_HIGH);
> +}
> +
> +static unsigned int l2_datfix_addr_low(void)
> +{
> + return readl(l2_base + SIFIVE_L2_DATECCFIX_LOW);
> +}
> +
> +static unsigned int l2_datfix_count(void)
> +{
> + return readl(l2_base + SIFIVE_L2_DATECCFIX_COUNT);
> +}
> +
> +static unsigned int l2_datfail_addr_high(void)
> +{
> + return readl(l2_base + SIFIVE_L2_DATECCFAIL_HIGH);
> +}
> +
> +static unsigned int l2_datfail_addr_low(void)
> +{
> + return readl(l2_base + SIFIVE_L2_DATECCFAIL_LOW);
> +}
> +
> +static unsigned int l2_datfail_count(void)
> +{
> + return readl(l2_base + SIFIVE_L2_DATECCFAIL_COUNT);
> +}
Do you really need all these single line functions? Below in several
spots you use the readl directly, just do that everywhere.
Andrew
> +
> +#ifdef CONFIG_DEBUG_FS
> +static struct dentry *sifive_test;
> +
> +static ssize_t l2_write(struct file *file, const char __user *data,
> + size_t count, loff_t *ppos)
> +{
> + unsigned int val;
> +
> + if (kstrtouint_from_user(data, count, 0, &val))
> + return -EINVAL;
> + if ((val >= 0 && val < 0xFF) || (val >= 0x1 && val < 0x100FF))
> + writel(val, l2_base + SIFIVE_L2_ECCINJECTERR);
> + else
> + return -EINVAL;
> + return count;
> +}
> +
> +static const struct file_operations l2_fops = {
> + .owner = THIS_MODULE,
> + .open = simple_open,
> + .write = l2_write
> +};
> +
> +static void setup_sifive_debug(void)
> +{
> + sifive_test = debugfs_create_dir("sifive_l2_cache", NULL);
> +
> + debugfs_create_file("sifive_debug_inject_error", 0200,
> + sifive_test, NULL, &l2_fops);
> +}
> +#endif
> +
> +static void l2_config_read(void)
> +{
> + u32 regval, val;
> +
> + regval = readl(l2_base + SIFIVE_L2_CONFIG);
> + val = regval & 0xFF;
> + pr_info("L2CACHE: No. of Banks in the cache: %d\n", val);
> + val = (regval & 0xFF00) >> 8;
> + pr_info("L2CACHE: No. of ways per bank: %d\n", val);
> + val = (regval & 0xFF) >> 16;
> + pr_info("L2CACHE: Sets per bank: %llu\n", (uint64_t)1 << val);
> + val = (regval & 0xFF00) >> 24;
> + pr_info("L2CACHE: Bytes per cache block: %llu\n", (uint64_t)1 << val);
> +
> + regval = readl(l2_base + SIFIVE_L2_WAYENABLE);
> + pr_info("L2CACHE: Index of the largest way enabled: %d\n", regval);
> +}
> +
> +static const struct of_device_id sifive_l2_ids[] = {
> + { .compatible = "sifive,fu540-c000-ccache" },
> + { /* end of table */ },
> +};
> +
> +static AT
Re: [PATCH] [RFC] dmaengine: add fifo_size member
On 5/2/2019 5:55 PM, Vinod Koul wrote:
On 02-05-19, 16:23, Sameer Pujar wrote:
On 5/2/2019 11:34 AM, Vinod Koul wrote:
On 30-04-19, 17:00, Sameer Pujar wrote:
During the DMA transfers from memory to I/O, it was observed that transfers
were inconsistent and resulted in glitches for audio playback. It happened
because fifo size on DMA did not match with slave channel configuration.
currently 'dma_slave_config' structure does not have a field for fifo size.
Hence the platform pcm driver cannot pass the fifo size as a slave_config.
Note that 'snd_dmaengine_dai_dma_data' structure has fifo_size field which
cannot be used to pass the size info. This patch introduces fifo_size field
and the same can be populated on slave side. Users can set required size
for slave peripheral (multiple channels can be independently running with
different fifo sizes) and the corresponding sizes are programmed through
dma_slave_config on DMA side.
FIFO size is a hardware property not sure why you would want an
interface to program that?
On mismatch, I guess you need to take care of src/dst_maxburst..
Yes, FIFO size is a HW property. But it is SW configurable(atleast in my
case) on
slave side and can be set to different sizes. The src/dst_maxburst is
Are you sure, have you talked to HW folks on that? IIUC you are
programming the data to be used in FIFO not the FIFO length!
Yes, I mentioned about FIFO length.
1. MAX FIFO size is fixed in HW. But there is a way to limit the usage
per channel
in multiples of 64 bytes.
2. Having a separate member would give independent control over MAX
BURST SIZE and
FIFO SIZE.
programmed
for specific values, I think this depends on few factors related to
bandwidth
needs of client, DMA needs of the system etc.,
Precisely
In such cases how does DMA know the actual FIFO depth of slave peripheral?
Why should DMA know? Its job is to push/pull data as configured by
peripheral driver. The peripheral driver knows and configures DMA
accordingly.
I am not sure if there is any HW logic that mandates DMA to know the size
of configured FIFO depth on slave side. I will speak to HW folks and
would update here.
Request for feedback/suggestions.
Signed-off-by: Sameer Pujar
---
include/linux/dmaengine.h | 3 +++
1 file changed, 3 insertions(+)
diff --git a/include/linux/dmaengine.h b/include/linux/dmaengine.h
index d49ec5c..9ec198b 100644
--- a/include/linux/dmaengine.h
+++ b/include/linux/dmaengine.h
@@ -351,6 +351,8 @@ enum dma_slave_buswidth {
* @slave_id: Slave requester id. Only valid for slave channels. The dma
* slave peripheral will have unique id as dma requester which need to be
* pass as slave config.
+ * @fifo_size: Fifo size value. The dma slave peripheral can configure required
+ * fifo size and the same needs to be passed as slave config.
*
* This struct is passed in as configuration data to a DMA engine
* in order to set up a certain channel for DMA transport at runtime.
@@ -376,6 +378,7 @@ struct dma_slave_config {
u32 dst_port_window_size;
bool device_fc;
unsigned int slave_id;
+ u32 fifo_size;
};
/**
--
2.7.4
Re: [PATCH net-next 1/3] genetlink: do not validate dump requests if there is no policy
On Thu, 2019-05-02 at 15:10 +0200, Michal Kubecek wrote: > On Thu, May 02, 2019 at 02:51:33PM +0200, Johannes Berg wrote: > > On Thu, 2019-05-02 at 12:48 +, Michal Kubecek wrote: > > > Unlike do requests, dump genetlink requests now perform strict validation > > > by default even if the genetlink family does not set policy and maxtype > > > because it does validation and parsing on its own (e.g. because it wants > > > to > > > allow different message format for different commands). While the null > > > policy will be ignored, maxtype (which would be zero) is still checked so > > > that any attribute will fail validation. > > > > > > The solution is to only call __nla_validate() from genl_family_rcv_msg() > > > if family->maxtype is set. > > > > D'oh. Which family was it that you found this on? I checked only ones > > with policy I guess. > > It was with my ethtool netlink series (still work in progress). Then you should probably *have* a policy to get all the other goodies like automatic policy export (once I repost those patches) johannes
Re: [PATCH] perf tools: Speed up report for perf compiled with linwunwind
Em Fri, Apr 26, 2019 at 09:38:04AM +0200, Jiri Olsa escreveu: > When compiled with libunwind, perf does some preparatory work > when processing side-band events. This is not needed when report > actually don't unwind dwarf callchains, so it's disabled with > dwarf_callchain_users bool. > > However we could move that check to higher level and shield more > unwanted code for normal report processing, giving us following > speed up on kernel build profile: Thanks, applied to perf/core. - Arnaldo
[PATCH v2] ASoC: mediatek: mt8516: register ADDA DAI
Register the ADDA DAI driver into the MT8516 PCM driver.
Signed-off-by: Fabien Parent
---
This patch depends on patch serie:
[PATCH 0/5] ASoC: mediatek: Add basic PCM driver for MT8516
v2:
* Register ADDA before memif to fix ordering issue.
---
sound/soc/mediatek/mt8516/mt8516-afe-pcm.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/sound/soc/mediatek/mt8516/mt8516-afe-pcm.c
b/sound/soc/mediatek/mt8516/mt8516-afe-pcm.c
index 84fbb5dbbd14..dea9221c67aa 100644
--- a/sound/soc/mediatek/mt8516/mt8516-afe-pcm.c
+++ b/sound/soc/mediatek/mt8516/mt8516-afe-pcm.c
@@ -10,6 +10,7 @@
#include
#include
+#include "mt8516-afe-common.h"
#include "mt8516-afe-regs.h"
#include "../common/mtk-afe-platform-driver.h"
@@ -669,6 +670,7 @@ static int mt8516_dai_memif_register(struct mtk_base_afe
*afe)
typedef int (*dai_register_cb)(struct mtk_base_afe *);
static const dai_register_cb dai_register_cbs[] = {
+ mt8516_dai_adda_register,
mt8516_dai_memif_register,
};
--
2.20.1
[PATCH 0/1] Add several Beckhoff Automation boards to critclk_systems DMI table
From: Steffen Dirkwinkel There are several Beckhoff Automation industrial PC boards which use pmc_plt_clk* clocks for ethernet controllers. The patch adds affected boards to critclk_systems DMI table so the clocks are marked as CLK_CRITICAL and not turned off. This should be applied on top of another patch as both change the same table: [PATCH] platform/x86: pmc_atom: Add Lex 3I380D industrial PC to critclk_systems DMI table Steffen Dirkwinkel (1): platform/x86: pmc_atom: Add several Beckhoff Automation boards to critclk_systems DMI table drivers/platform/x86/pmc_atom.c | 24 1 file changed, 24 insertions(+) -- 2.21.0
[PATCH 1/1] platform/x86: pmc_atom: Add several Beckhoff Automation boards to critclk_systems DMI table
From: Steffen Dirkwinkel
There are several Beckhoff Automation industrial PC boards which use
pmc_plt_clk* clocks for ethernet controllers. This adds affected boards
to critclk_systems DMI table so the clocks are marked as CLK_CRITICAL and
not turned off.
Fixes: 648e921888ad ("clk: x86: Stop marking clocks as CLK_IS_CRITICAL")
Signed-off-by: Steffen Dirkwinkel
---
drivers/platform/x86/pmc_atom.c | 24
1 file changed, 24 insertions(+)
diff --git a/drivers/platform/x86/pmc_atom.c b/drivers/platform/x86/pmc_atom.c
index a311f48ce7c9..b1d804376237 100644
--- a/drivers/platform/x86/pmc_atom.c
+++ b/drivers/platform/x86/pmc_atom.c
@@ -413,6 +413,30 @@ static const struct dmi_system_id critclk_systems[] = {
DMI_MATCH(DMI_PRODUCT_NAME, "3I380D"),
},
},
+ {
+ /* pmc_plt_clk* - are used for ethernet controllers */
+ .ident = "Beckhoff CB3163",
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "Beckhoff Automation"),
+ DMI_MATCH(DMI_BOARD_NAME, "CB3163"),
+ },
+ },
+ {
+ /* pmc_plt_clk* - are used for ethernet controllers */
+ .ident = "Beckhoff CB6263",
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "Beckhoff Automation"),
+ DMI_MATCH(DMI_BOARD_NAME, "CB6263"),
+ },
+ },
+ {
+ /* pmc_plt_clk* - are used for ethernet controllers */
+ .ident = "Beckhoff CB6363",
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "Beckhoff Automation"),
+ DMI_MATCH(DMI_BOARD_NAME, "CB6363"),
+ },
+ },
{ /*sentinel*/ }
};
--
2.21.0
[PATCH v2] clk: imx8mq: Add dsi_ipg_div
It's defined in imx8mq-clock.h but wasn't assigned yet. It's used as
clk_tx_esc in the nwl dsi host controller (i.MX8MQ RM, Rev. 0, 01/2018
Sect. 13.5.3.7.4).
Signed-off-by: Guido Günther
---
This is basically a resend January with a slightly more exhaustive
commit message.
drivers/clk/imx/clk-imx8mq.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/clk/imx/clk-imx8mq.c b/drivers/clk/imx/clk-imx8mq.c
index a9b3888aef0c..daf1841b2adb 100644
--- a/drivers/clk/imx/clk-imx8mq.c
+++ b/drivers/clk/imx/clk-imx8mq.c
@@ -458,6 +458,7 @@ static int imx8mq_clocks_probe(struct platform_device *pdev)
clks[IMX8MQ_CLK_DSI_DBI] = imx8m_clk_composite("dsi_dbi",
imx8mq_dsi_dbi_sels, base + 0xbc00);
clks[IMX8MQ_CLK_DSI_ESC] = imx8m_clk_composite("dsi_esc",
imx8mq_dsi_esc_sels, base + 0xbc80);
clks[IMX8MQ_CLK_DSI_AHB] = imx8m_clk_composite("dsi_ahb",
imx8mq_dsi_ahb_sels, base + 0x9200);
+ clks[IMX8MQ_CLK_DSI_IPG_DIV] = imx_clk_divider2("dsi_ipg_div",
"dsi_ahb", base + 0x9280, 0, 6);
clks[IMX8MQ_CLK_CSI1_CORE] = imx8m_clk_composite("csi1_core",
imx8mq_csi1_core_sels, base + 0xbd00);
clks[IMX8MQ_CLK_CSI1_PHY_REF] = imx8m_clk_composite("csi1_phy_ref",
imx8mq_csi1_phy_sels, base + 0xbd80);
clks[IMX8MQ_CLK_CSI1_ESC] = imx8m_clk_composite("csi1_esc",
imx8mq_csi1_esc_sels, base + 0xbe00);
--
2.20.1
Re: [PATCH] mod_devicetable.h: reduce sizeof(struct of_device_id) by 80 bytes
On 02/05/2019 14.29, Jeff Mahoney wrote: > On 5/2/19 5:41 AM, Rasmus Villemoes wrote: >> But we cannot really know whether there is some userspace tool that >> parses the .ko ELF objects the same way that file2alias does, doing >> pattern matching on the symbol names etc. I cannot see why anybody would >> _do_ that (the in-tree infrastructure already generates the >> MODULE_ALIAS() from which modules.alias gets generated), but the only >> way of knowing, I think, is to try to apply the patch and see if anybody >> complains. > > The size is part of the ABI, though. module-init-tools has a copy of > the same struct and uses that size to walk an array of of_device_id when > a module as more than one. If you shrink it, that will certainly break. Urgh, yes, didn't know about module-init-tools. But it seems to be abandoned? So does anybody actually use that with a modern kernel (there seems to be many new structs in mod_devicetable.h that the last release of module-init-tools doesn't know about)? Oh well. If it's not deemed worth the risk to do a release with this patch applied, I can always just add this to the list of trivial things to do when asked to trim a custom kernel. Rasmus
Re: [PATCH 5/4] 9p: pass the correct prototype to read_cache_page
On Thu, May 02, 2019 at 12:08:29AM -0600, William Kucharski wrote:
> 1) You need to pass "filp" rather than "filp->private_data" to
> read_cache_pages()
> in v9fs_fid_readpage().
With this patch v9fs_fid_readpage takes a void pointer that must be
a FID, and we pass the FID everywhere:
- v9fs_vfs_readpage passes filp->private_data
- v9fs_vfs_readpages passes filp->private_data through
read_cache_pages
- v9fs_write_begin passes the local fid variable
>
> The patched code passes "filp->private_data" as the "data" parameter to
> read_cache_pages(), which would generate a call to:
>
> filler(data, page)
>
> which would become a call to:
>
> static int v9fs_vfs_readpage(struct file *filp, struct page *page)
> {
> return v9fs_fid_readpage(filp->private_data, page);
> }
Except that we don't pass v9fs_vfs_readpage as the filler any more,
we now pass v9fs_fid_readpage.
Re: [PATCH 0/4] nvme-pci: support device coredump
On Thu, May 02, 2019 at 05:59:17PM +0900, Akinobu Mita wrote: > This enables to capture snapshot of controller information via device > coredump machanism, and it helps diagnose and debug issues. > > The nvme device coredump is triggered before resetting the controller > caused by I/O timeout, and creates the following coredump files. > > - regs: NVMe controller registers, including each I/O queue doorbell > registers, in nvme-show-regs style text format. You're supposed to treat queue doorbells as write-only. Spec says: The host should not read the doorbell registers. If a doorbell register is read, the value returned is vendor specific.
Re: [PATCH AUTOSEL 5.0 70/98] tty: fix NULL pointer issue when tty_port ops is not set
On Mon, Apr 22, 2019 at 10:40:02PM +0200, Greg Kroah-Hartman wrote: On Mon, Apr 22, 2019 at 03:41:37PM -0400, Sasha Levin wrote: From: Fabien Dessenne [ Upstream commit f4e68d58cf2b20a581759bbc7228052534652673 ] Unlike 'client_ops' which is initialized to 'default_client_ops', the port operations 'ops' may be left to NULL. Check the 'ops' value before checking the 'ops->x' value. Signed-off-by: Fabien Dessenne Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin (Microsoft) --- drivers/tty/tty_port.c | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) Nope, I have a revert for this in my tree for 5.2-rc1, no need for this in any stable tree, it doesn't do anything :) Please drop it from all branches, thanks. Dropped from my queue, thanks! -- Thanks, Sasha
[PATCH 6/6] dmaengine: tegra210-adma: restore channel status
Status of ADMA channel registers is not saved and restored during system
suspend. During active playback if system enters suspend, this results in
wrong state of channel registers during system resume and playback fails
to resume properly. Fix this by saving following channel registers in
runtime suspend and restore during runtime resume.
* ADMA_CH_LOWER_SRC_ADDR
* ADMA_CH_LOWER_TRG_ADDR
* ADMA_CH_FIFO_CTRL
* ADMA_CH_CONFIG
* ADMA_CH_CTRL
* ADMA_CH_CMD
* ADMA_CH_TC
Runtime PM calls will be inovked during system resume path if a playback
or capture needs to be resumed. Hence above changes work fine for system
suspend case.
Fixes: f46b195799b5 ("dmaengine: tegra-adma: Add support for Tegra210 ADMA")
Signed-off-by: Sameer Pujar
---
drivers/dma/tegra210-adma.c | 46 -
1 file changed, 45 insertions(+), 1 deletion(-)
diff --git a/drivers/dma/tegra210-adma.c b/drivers/dma/tegra210-adma.c
index 953669d..21f6be1 100644
--- a/drivers/dma/tegra210-adma.c
+++ b/drivers/dma/tegra210-adma.c
@@ -112,6 +112,7 @@ struct tegra_adma_chan_regs {
unsigned int src_addr;
unsigned int trg_addr;
unsigned int fifo_ctrl;
+ unsigned int cmd;
unsigned int tc;
};
@@ -141,6 +142,7 @@ struct tegra_adma_chan {
enum dma_transfer_direction sreq_dir;
unsigned intsreq_index;
boolsreq_reserved;
+ struct tegra_adma_chan_regs ch_regs;
/* Transfer count and position info */
unsigned inttx_buf_count;
@@ -711,8 +713,30 @@ static struct dma_chan *tegra_dma_of_xlate(struct
of_phandle_args *dma_spec,
static int tegra_adma_runtime_suspend(struct device *dev)
{
struct tegra_adma *tdma = dev_get_drvdata(dev);
+ struct tegra_adma_chan_regs *ch_reg;
+ struct tegra_adma_chan *tdc;
+ int i;
tdma->global_cmd = tdma_read(tdma, ADMA_GLOBAL_CMD);
+ if (!tdma->global_cmd)
+ goto clk_disable;
+
+ for (i = 0; i < tdma->nr_channels; i++) {
+ tdc = &tdma->channels[i];
+ ch_reg = &tdc->ch_regs;
+ ch_reg->cmd = tdma_ch_read(tdc, ADMA_CH_CMD);
+ /* skip if channel is not active */
+ if (!ch_reg->cmd)
+ continue;
+ ch_reg->tc = tdma_ch_read(tdc, ADMA_CH_TC);
+ ch_reg->src_addr = tdma_ch_read(tdc, ADMA_CH_LOWER_SRC_ADDR);
+ ch_reg->trg_addr = tdma_ch_read(tdc, ADMA_CH_LOWER_TRG_ADDR);
+ ch_reg->ctrl = tdma_ch_read(tdc, ADMA_CH_CTRL);
+ ch_reg->fifo_ctrl = tdma_ch_read(tdc, ADMA_CH_FIFO_CTRL);
+ ch_reg->config = tdma_ch_read(tdc, ADMA_CH_CONFIG);
+ }
+
+clk_disable:
clk_disable_unprepare(tdma->ahub_clk);
return 0;
@@ -721,7 +745,9 @@ static int tegra_adma_runtime_suspend(struct device *dev)
static int tegra_adma_runtime_resume(struct device *dev)
{
struct tegra_adma *tdma = dev_get_drvdata(dev);
- int ret;
+ struct tegra_adma_chan_regs *ch_reg;
+ struct tegra_adma_chan *tdc;
+ int ret, i;
ret = clk_prepare_enable(tdma->ahub_clk);
if (ret) {
@@ -730,6 +756,24 @@ static int tegra_adma_runtime_resume(struct device *dev)
}
tdma_write(tdma, ADMA_GLOBAL_CMD, tdma->global_cmd);
+ if (!tdma->global_cmd)
+ return 0;
+
+ for (i = 0; i < tdma->nr_channels; i++) {
+ tdc = &tdma->channels[i];
+ ch_reg = &tdc->ch_regs;
+ /* skip if channel was not active earlier */
+ if (!ch_reg->cmd)
+ continue;
+ tdma_ch_write(tdc, ADMA_CH_TC, ch_reg->tc);
+ tdma_ch_write(tdc, ADMA_CH_LOWER_SRC_ADDR, ch_reg->src_addr);
+ tdma_ch_write(tdc, ADMA_CH_LOWER_TRG_ADDR, ch_reg->trg_addr);
+ tdma_ch_write(tdc, ADMA_CH_CTRL, ch_reg->ctrl);
+ tdma_ch_write(tdc, ADMA_CH_FIFO_CTRL, ch_reg->fifo_ctrl);
+ tdma_ch_write(tdc, ADMA_CH_CONFIG, ch_reg->config);
+ tdma_ch_write(tdc, ADMA_CH_CMD, ch_reg->cmd);
+ }
+
return 0;
}
--
2.7.4
Re: [PATCH v2] media/doc: Allow sizeimage to be set by v4l clients
Em Fri, 12 Apr 2019 18:59:15 +0300 Stanimir Varbanov escreveu: > This changes v4l2_pix_format and v4l2_plane_pix_format sizeimage > field description to allow v4l clients to set bigger image size > in case of variable length compressed data. > > Signed-off-by: Stanimir Varbanov > --- > Documentation/media/uapi/v4l/pixfmt-v4l2-mplane.rst | 13 - > Documentation/media/uapi/v4l/pixfmt-v4l2.rst| 11 ++- > 2 files changed, 22 insertions(+), 2 deletions(-) > > diff --git a/Documentation/media/uapi/v4l/pixfmt-v4l2-mplane.rst > b/Documentation/media/uapi/v4l/pixfmt-v4l2-mplane.rst > index 5688c816e334..005428a8121e 100644 > --- a/Documentation/media/uapi/v4l/pixfmt-v4l2-mplane.rst > +++ b/Documentation/media/uapi/v4l/pixfmt-v4l2-mplane.rst > @@ -31,7 +31,18 @@ describing all planes of that format. > > * - __u32 >- ``sizeimage`` > - - Maximum size in bytes required for image data in this plane. > + - Maximum size in bytes required for image data in this plane, > + set by the driver. When the image consists of variable length > + compressed data this is the number of bytes required by the > + codec to support the worst-case compression scenario. > + > + For uncompressed images the driver will set the value. For > + variable length compressed data clients are allowed to set > + the sizeimage field, but the driver may ignore it and set the > + value itself, or it may modify the provided value based on > + alignment requirements or minimum/maximum size requirements. > + If the client wants to leave this to the driver, then it should > + set sizeimage to 0. > * - __u32 >- ``bytesperline`` >- Distance in bytes between the leftmost pixels in two adjacent > diff --git a/Documentation/media/uapi/v4l/pixfmt-v4l2.rst > b/Documentation/media/uapi/v4l/pixfmt-v4l2.rst > index 71eebfc6d853..0f7771151db9 100644 > --- a/Documentation/media/uapi/v4l/pixfmt-v4l2.rst > +++ b/Documentation/media/uapi/v4l/pixfmt-v4l2.rst > @@ -89,7 +89,16 @@ Single-planar format structure >- Size in bytes of the buffer to hold a complete image, set by the > driver. Usually this is ``bytesperline`` times ``height``. When > the image consists of variable length compressed data this is the > - maximum number of bytes required to hold an image. > + number of bytes required by the codec to support the worst-case > + compression scenario. > + > + For uncompressed images the driver will set the value. For > + variable length compressed data clients are allowed to set > + the sizeimage field, but the driver may ignore it and set the > + value itself, or it may modify the provided value based on > + alignment requirements or minimum/maximum size requirements. > + If the client wants to leave this to the driver, then it should > + set sizeimage to 0. It is very confusing to understand what you meant by the above paragraph, as you inverted the sentence order and forgot a comma. I would, instead, write the phrases using the direct order, and break into two paragraphs, e. g., changing the above to: "The driver will set the value for uncompressed images. Clients are allowed to set the sizeimage field for variable length compressed data, but the driver may ignore it and set the value itself, or it may modify the provided value based on alignment requirements or minimum/maximum size requirements. If the client wants to leave this to the driver, then it should set sizeimage to 0." That makes it a lot easier to read, hopefully preventing mistakes from app and driver developers when reading about sizeimage. Yet, I'm not too comfortable on letting this too generic. I mean, how an app writer would know what formats are "variable length compressed data", specially since libv4l may actually change that. Thanks, Mauro
[PATCH 5/6] dmaengine: tegra210-dma: free dma controller in remove()
Following kernel panic is seen during DMA driver unload->load sequence
==
Unable to handle kernel paging request at virtual address ff8001198880
Internal error: Oops: 8607 [#1] PREEMPT SMP
CPU: 0 PID: 5907 Comm: HwBinder:4123_1 Tainted: G C 4.9.128-tegra-g065839f
Hardware name: galen (DT)
task: ffc3590d1a80 task.stack: ffc3d0678000
PC is at 0xff8001198880
LR is at of_dma_request_slave_channel+0xd8/0x1f8
pc : [] lr : [] pstate: 60400045
sp : ffc3d067b710
x29: ffc3d067b710 x28: 002f
x27: ff800949e000 x26: ff800949e750
x25: ff800949e000 x24: ffbefe817d84
x23: ff8009f77cb0 x22: 0028
x21: ffc3ffda49c8 x20: 0029
x19: 0001 x18:
x17: x16: ff80082b66a0
x15: ff8009e78250 x14: 000a
x13: 0038 x12: 0101010101010101
x11: 0030 x10: 0101010101010101
x9 : fffc x8 : 7f7f7f7f7f7f7f7f
x7 : 62ff726b6b64622c x6 : 8064
x5 : 6400 x4 : ffbefe817c44
x3 : ffc3ffda3e08 x2 : ff8001198880
x1 : ffc3d48323c0 x0 : ffc3d067b788
Process HwBinder:4123_1 (pid: 5907, stack limit = 0xffc3d0678028)
Call trace:
[] 0xff8001198880
[] dma_request_chan+0x50/0x1f0
[] dma_request_slave_channel+0x28/0x40
[] tegra_alt_pcm_open+0x114/0x170
[] soc_pcm_open+0x10c/0x878
[] snd_pcm_open_substream+0xc0/0x170
[] snd_pcm_open+0xc4/0x240
[] snd_pcm_playback_open+0x58/0x80
[] snd_open+0xb4/0x178
[] chrdev_open+0xb8/0x1d0
[] do_dentry_open+0x214/0x318
[] vfs_open+0x58/0x88
[] do_last+0x450/0xde0
[] path_openat+0xa8/0x368
[] do_filp_open+0x8c/0x110
[] do_sys_open+0x164/0x220
[] compat_SyS_openat+0x3c/0x50
[] el0_svc_naked+0x34/0x38
---[ end trace 67e6d544e65b5145 ]---
Kernel panic - not syncing: Fatal exception
==
In device probe(), of_dma_controller_register() registers DMA controller.
But when driver is removed, this is not freed. During driver reload this
results in data abort and kernel panic. Add of_dma_controller_free() in
driver remove path to fix the issue.
Fixes: f46b195799b5 ("dmaengine: tegra-adma: Add support for Tegra210 ADMA")
Signed-off-by: Sameer Pujar
---
drivers/dma/tegra210-adma.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/dma/tegra210-adma.c b/drivers/dma/tegra210-adma.c
index f26c458..953669d 100644
--- a/drivers/dma/tegra210-adma.c
+++ b/drivers/dma/tegra210-adma.c
@@ -888,6 +888,7 @@ static int tegra_adma_remove(struct platform_device *pdev)
struct tegra_adma *tdma = platform_get_drvdata(pdev);
int i;
+ of_dma_controller_free(pdev->dev.of_node);
dma_async_device_unregister(&tdma->dma_dev);
for (i = 0; i < tdma->nr_channels; ++i)
--
2.7.4
[PATCH 4/6] dmaengine: tegra210-adma: add pause/resume support
During an audio playback session it is observed that, audio goes off after
few seconds of continuous pause and play. No audio is heard even when the
playback is resumed.
The reason for above is, currently ADMA driver does not handle DMA_PAUSE/
DMA_RESUME and relevant callbacks for dma_device are not implemented. This
patch implements device_pause and device_resume callbacks for the device.
During pause TRANSFER_PAUSE bit of dma channel control register is set and
the same is cleared during resume.
Signed-off-by: Sameer Pujar
---
drivers/dma/tegra210-adma.c | 51 +
1 file changed, 51 insertions(+)
diff --git a/drivers/dma/tegra210-adma.c b/drivers/dma/tegra210-adma.c
index 115ee10f..f26c458 100644
--- a/drivers/dma/tegra210-adma.c
+++ b/drivers/dma/tegra210-adma.c
@@ -30,6 +30,7 @@
#define ADMA_CH_CMD0x00
#define ADMA_CH_STATUS 0x0c
#define ADMA_CH_STATUS_XFER_EN BIT(0)
+#define ADMA_CH_STATUS_XFER_PAUSED BIT(1)
#define ADMA_CH_INT_STATUS 0x10
#define ADMA_CH_INT_STATUS_XFER_DONE BIT(0)
@@ -41,6 +42,7 @@
#define ADMA_CH_CTRL_DIR_MEM2AHUB 4
#define ADMA_CH_CTRL_MODE_CONTINUOUS (2 << 8)
#define ADMA_CH_CTRL_FLOWCTRL_EN BIT(1)
+#define ADMA_CH_CTRL_XFER_PAUSE_SHIFT 0
#define ADMA_CH_CONFIG 0x28
#define ADMA_CH_CONFIG_SRC_BUF(val)(((val) & 0x7) << 28)
@@ -67,6 +69,8 @@
#define ADMA_GLOBAL_CMD0x00
#define ADMA_GLOBAL_SOFT_RESET 0x04
+#define TEGRA_ADMA_BURST_COMPLETE_TIME 20
+
#define ADMA_CH_FIFO_CTRL_DEFAULT (ADMA_CH_FIFO_CTRL_OVRFW_THRES(1) | \
ADMA_CH_FIFO_CTRL_STARV_THRES(1))
@@ -437,6 +441,51 @@ static void tegra_adma_issue_pending(struct dma_chan *dc)
spin_unlock_irqrestore(&tdc->vc.lock, flags);
}
+static bool tegra_adma_is_paused(struct tegra_adma_chan *tdc)
+{
+ u32 csts;
+
+ csts = tdma_ch_read(tdc, ADMA_CH_STATUS);
+ csts &= ADMA_CH_STATUS_XFER_PAUSED;
+
+ return csts ? true : false;
+}
+
+static int tegra_adma_pause(struct dma_chan *dc)
+{
+ struct tegra_adma_chan *tdc = to_tegra_adma_chan(dc);
+ struct tegra_adma_desc *desc = tdc->desc;
+ struct tegra_adma_chan_regs *ch_regs = &desc->ch_regs;
+ int dcnt = 10;
+
+ ch_regs->ctrl = tdma_ch_read(tdc, ADMA_CH_CTRL);
+ ch_regs->ctrl |= (1 << ADMA_CH_CTRL_XFER_PAUSE_SHIFT);
+ tdma_ch_write(tdc, ADMA_CH_CTRL, ch_regs->ctrl);
+
+ while (dcnt-- && !tegra_adma_is_paused(tdc))
+ udelay(TEGRA_ADMA_BURST_COMPLETE_TIME);
+
+ if (dcnt < 0) {
+ dev_err(tdc2dev(tdc), "unable to pause DMA channel\n");
+ return -EBUSY;
+ }
+
+ return 0;
+}
+
+static int tegra_adma_resume(struct dma_chan *dc)
+{
+ struct tegra_adma_chan *tdc = to_tegra_adma_chan(dc);
+ struct tegra_adma_desc *desc = tdc->desc;
+ struct tegra_adma_chan_regs *ch_regs = &desc->ch_regs;
+
+ ch_regs->ctrl = tdma_ch_read(tdc, ADMA_CH_CTRL);
+ ch_regs->ctrl &= ~(1 << ADMA_CH_CTRL_XFER_PAUSE_SHIFT);
+ tdma_ch_write(tdc, ADMA_CH_CTRL, ch_regs->ctrl);
+
+ return 0;
+}
+
static int tegra_adma_terminate_all(struct dma_chan *dc)
{
struct tegra_adma_chan *tdc = to_tegra_adma_chan(dc);
@@ -798,6 +847,8 @@ static int tegra_adma_probe(struct platform_device *pdev)
tdma->dma_dev.dst_addr_widths = BIT(DMA_SLAVE_BUSWIDTH_4_BYTES);
tdma->dma_dev.directions = BIT(DMA_DEV_TO_MEM) | BIT(DMA_MEM_TO_DEV);
tdma->dma_dev.residue_granularity = DMA_RESIDUE_GRANULARITY_SEGMENT;
+ tdma->dma_dev.device_pause = tegra_adma_pause;
+ tdma->dma_dev.device_resume = tegra_adma_resume;
ret = dma_async_device_register(&tdma->dma_dev);
if (ret < 0) {
--
2.7.4
[PATCH] ARM: VDSO: Don't leak kernel addresses
Since commit ad67b74d2469d9b8 ("printk: hash addresses printed with
%p"), an obfuscated kernel pointer is printed at every boot if
debugging is enabled:
vdso: 1 text pages at base (ptrval)
Remove the print completely, as it's useless without the address.
Based on commit 0f1bf7e39822476b ("arm64/vdso: don't leak kernel
addresses").
Fixes: ad67b74d2469d9b8 ("printk: hash addresses printed with %p")
Signed-off-by: Geert Uytterhoeven
---
arch/arm/kernel/vdso.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/arm/kernel/vdso.c b/arch/arm/kernel/vdso.c
index f4dd7f9663c10a70..e8cda5e02b4ea7bd 100644
--- a/arch/arm/kernel/vdso.c
+++ b/arch/arm/kernel/vdso.c
@@ -205,7 +205,6 @@ static int __init vdso_init(void)
}
text_pages = (vdso_end - vdso_start) >> PAGE_SHIFT;
- pr_debug("vdso: %i text pages at base %p\n", text_pages, vdso_start);
/* Allocate the VDSO text pagelist */
vdso_text_pagelist = kcalloc(text_pages, sizeof(struct page *),
--
2.17.1
[PATCH 3/6] dmaengine: tegra210-adma: add support for Tegra186/Tegra194
Add Tegra186 specific macro defines and chip_data structure for chip
specific information. New compatibility is added to select relevant
chip details. There is no major change for Tegra194 and hence it can
use the same chip data.
The bits in the BURST_SIZE field of the ADMA CH_CONFIG register are
encoded differently on Tegra186 and Tegra194 compared with Tegra210.
On Tegra210 the bits are encoded as follows ...
1 = WORD_1
2 = WORDS_2
3 = WORDS_4
4 = WORDS_8
5 = WORDS_16
Where as on Tegra186 and Tegra194 the bits are encoded as ...
0 = WORD_1
1 = WORDS_2
2 = WORDS_3
3 = WORDS_4
4 = WORDS_5
...
15 = WORDS_16
Add helper functions for generating the correct burst size.
Signed-off-by: Sameer Pujar
---
drivers/dma/tegra210-adma.c | 45 +
1 file changed, 37 insertions(+), 8 deletions(-)
diff --git a/drivers/dma/tegra210-adma.c b/drivers/dma/tegra210-adma.c
index 9aee015..115ee10f 100644
--- a/drivers/dma/tegra210-adma.c
+++ b/drivers/dma/tegra210-adma.c
@@ -45,8 +45,8 @@
#define ADMA_CH_CONFIG 0x28
#define ADMA_CH_CONFIG_SRC_BUF(val)(((val) & 0x7) << 28)
#define ADMA_CH_CONFIG_TRG_BUF(val)(((val) & 0x7) << 24)
-#define ADMA_CH_CONFIG_BURST_SIZE(val) (((val) & 0x7) << 20)
-#define ADMA_CH_CONFIG_BURST_165
+#define ADMA_CH_CONFIG_BURST_SIZE_SHIFT20
+#define ADMA_CH_CONFIG_MAX_BURST_SIZE 16
#define ADMA_CH_CONFIG_WEIGHT_FOR_WRR(val) ((val) & 0xf)
#define ADMA_CH_CONFIG_MAX_BUFS8
@@ -87,6 +87,7 @@ struct tegra_adma;
* @nr_channels: Number of DMA channels available.
*/
struct tegra_adma_chip_data {
+ unsigned int (*adma_get_burst_config)(unsigned int burst_size);
unsigned int global_reg_offset;
unsigned int global_int_clear;
unsigned int ch_req_tx_shift;
@@ -489,6 +490,22 @@ static enum dma_status tegra_adma_tx_status(struct
dma_chan *dc,
return ret;
}
+static unsigned int tegra210_adma_get_burst_config(unsigned int burst_size)
+{
+ if (!burst_size || burst_size > ADMA_CH_CONFIG_MAX_BURST_SIZE)
+ burst_size = ADMA_CH_CONFIG_MAX_BURST_SIZE;
+
+ return fls(burst_size) << ADMA_CH_CONFIG_BURST_SIZE_SHIFT;
+}
+
+static unsigned int tegra186_adma_get_burst_config(unsigned int burst_size)
+{
+ if (!burst_size || burst_size > ADMA_CH_CONFIG_MAX_BURST_SIZE)
+ burst_size = ADMA_CH_CONFIG_MAX_BURST_SIZE;
+
+ return (burst_size - 1) << ADMA_CH_CONFIG_BURST_SIZE_SHIFT;
+}
+
static int tegra_adma_set_xfer_params(struct tegra_adma_chan *tdc,
struct tegra_adma_desc *desc,
dma_addr_t buf_addr,
@@ -504,7 +521,7 @@ static int tegra_adma_set_xfer_params(struct
tegra_adma_chan *tdc,
switch (direction) {
case DMA_MEM_TO_DEV:
adma_dir = ADMA_CH_CTRL_DIR_MEM2AHUB;
- burst_size = fls(tdc->sconfig.dst_maxburst);
+ burst_size = tdc->sconfig.dst_maxburst;
ch_regs->config = ADMA_CH_CONFIG_SRC_BUF(desc->num_periods - 1);
ch_regs->ctrl = ADMA_CH_REG_FIELD_VAL(tdc->sreq_index,
cdata->ch_req_mask,
@@ -514,7 +531,7 @@ static int tegra_adma_set_xfer_params(struct
tegra_adma_chan *tdc,
case DMA_DEV_TO_MEM:
adma_dir = ADMA_CH_CTRL_DIR_AHUB2MEM;
- burst_size = fls(tdc->sconfig.src_maxburst);
+ burst_size = tdc->sconfig.src_maxburst;
ch_regs->config = ADMA_CH_CONFIG_TRG_BUF(desc->num_periods - 1);
ch_regs->ctrl = ADMA_CH_REG_FIELD_VAL(tdc->sreq_index,
cdata->ch_req_mask,
@@ -527,13 +544,10 @@ static int tegra_adma_set_xfer_params(struct
tegra_adma_chan *tdc,
return -EINVAL;
}
- if (!burst_size || burst_size > ADMA_CH_CONFIG_BURST_16)
- burst_size = ADMA_CH_CONFIG_BURST_16;
-
ch_regs->ctrl |= ADMA_CH_CTRL_DIR(adma_dir) |
ADMA_CH_CTRL_MODE_CONTINUOUS |
ADMA_CH_CTRL_FLOWCTRL_EN;
- ch_regs->config |= ADMA_CH_CONFIG_BURST_SIZE(burst_size);
+ ch_regs->config |= cdata->adma_get_burst_config(burst_size);
ch_regs->config |= ADMA_CH_CONFIG_WEIGHT_FOR_WRR(1);
ch_regs->fifo_ctrl = ADMA_CH_FIFO_CTRL_DEFAULT;
ch_regs->tc = desc->period_len & ADMA_CH_TC_COUNT_MASK;
@@ -671,6 +685,7 @@ static int tegra_adma_runtime_resume(struct device *dev)
}
static const struct tegra_adma_chip_data tegra210_chip_data = {
+ .adma_get_burst_config = tegra210_adma_get_burst_config,
.global_reg_offset = 0xc00,
.global_int_clear = 0x20,
.ch_req_tx_shift= 28,
@@ -682,8 +697
[PATCH 1/6] dmaengine: tegra210-adma: prepare for supporting newer Tegra chips
This is a preparatory patch to add support for Tegra186 and Tegra194 chips.
Following changes are necessary to make driver code generic.
* chip_data structure is enhanced to have chip specific details and
following are the additions to the structure
* Offset addresses for ADMA global and channel registers
* Offset values for Tx and Rx channel selection
* Maximum supported Tx and Rx channels
* Tx and Rx channel request mask
* ADMA channel register space size
* Make use of above chip_data to generalise the driver code
Support for Tegra186 and Tegra194 will be added in subsequent patches of
the series.
Signed-off-by: Sameer Pujar
---
drivers/dma/tegra210-adma.c | 91 -
1 file changed, 57 insertions(+), 34 deletions(-)
diff --git a/drivers/dma/tegra210-adma.c b/drivers/dma/tegra210-adma.c
index 253d312..9aee015 100644
--- a/drivers/dma/tegra210-adma.c
+++ b/drivers/dma/tegra210-adma.c
@@ -36,10 +36,6 @@
#define ADMA_CH_INT_CLEAR 0x1c
#define ADMA_CH_CTRL 0x24
-#define ADMA_CH_CTRL_TX_REQ(val) (((val) & 0xf) << 28)
-#define ADMA_CH_CTRL_TX_REQ_MAX10
-#define ADMA_CH_CTRL_RX_REQ(val) (((val) & 0xf) << 24)
-#define ADMA_CH_CTRL_RX_REQ_MAX10
#define ADMA_CH_CTRL_DIR(val) (((val) & 0xf) << 12)
#define ADMA_CH_CTRL_DIR_AHUB2MEM 2
#define ADMA_CH_CTRL_DIR_MEM2AHUB 4
@@ -57,8 +53,8 @@
#define ADMA_CH_FIFO_CTRL 0x2c
#define ADMA_CH_FIFO_CTRL_OVRFW_THRES(val) (((val) & 0xf) << 24)
#define ADMA_CH_FIFO_CTRL_STARV_THRES(val) (((val) & 0xf) << 16)
-#define ADMA_CH_FIFO_CTRL_TX_SIZE(val) (((val) & 0xf) << 8)
-#define ADMA_CH_FIFO_CTRL_RX_SIZE(val) ((val) & 0xf)
+#define ADMA_CH_FIFO_CTRL_TX_FIFO_SIZE_SHIFT 8
+#define ADMA_CH_FIFO_CTRL_RX_FIFO_SIZE_SHIFT 0
#define ADMA_CH_LOWER_SRC_ADDR 0x34
#define ADMA_CH_LOWER_TRG_ADDR 0x3c
@@ -68,25 +64,38 @@
#define ADMA_CH_XFER_STATUS0x54
#define ADMA_CH_XFER_STATUS_COUNT_MASK 0x
-#define ADMA_GLOBAL_CMD0xc00
-#define ADMA_GLOBAL_SOFT_RESET 0xc04
-#define ADMA_GLOBAL_INT_CLEAR 0xc20
-#define ADMA_GLOBAL_CTRL 0xc24
-
-#define ADMA_CH_REG_OFFSET(a) (a * 0x80)
+#define ADMA_GLOBAL_CMD0x00
+#define ADMA_GLOBAL_SOFT_RESET 0x04
#define ADMA_CH_FIFO_CTRL_DEFAULT (ADMA_CH_FIFO_CTRL_OVRFW_THRES(1) | \
-ADMA_CH_FIFO_CTRL_STARV_THRES(1) | \
-ADMA_CH_FIFO_CTRL_TX_SIZE(3) | \
-ADMA_CH_FIFO_CTRL_RX_SIZE(3))
+ADMA_CH_FIFO_CTRL_STARV_THRES(1))
+
+#define ADMA_CH_REG_FIELD_VAL(val, mask, shift)(((val) & mask) <<
shift)
+
struct tegra_adma;
/*
* struct tegra_adma_chip_data - Tegra chip specific data
+ * @global_reg_offset: Register offset of DMA global register.
+ * @global_int_clear: Register offset of DMA global interrupt clear.
+ * @ch_req_tx_shift: Register offset for AHUB transmit channel select.
+ * @ch_req_rx_shift: Register offset for AHUB receive channel select.
+ * @ch_base_offset: Reister offset of DMA channel registers.
+ * @ch_req_mask: Mask for Tx or Rx channel select.
+ * @ch_req_max: Maximum number of Tx or Rx channels available.
+ * @ch_reg_size: Size of DMA channel register space.
* @nr_channels: Number of DMA channels available.
*/
struct tegra_adma_chip_data {
- int nr_channels;
+ unsigned int global_reg_offset;
+ unsigned int global_int_clear;
+ unsigned int ch_req_tx_shift;
+ unsigned int ch_req_rx_shift;
+ unsigned int ch_base_offset;
+ unsigned int ch_req_mask;
+ unsigned int ch_req_max;
+ unsigned int ch_reg_size;
+ unsigned int nr_channels;
};
/*
@@ -148,18 +157,20 @@ struct tegra_adma {
/* Used to store global command register state when suspending */
unsigned intglobal_cmd;
+ const struct tegra_adma_chip_data *cdata;
+
/* Last member of the structure */
struct tegra_adma_chan channels[0];
};
static inline void tdma_write(struct tegra_adma *tdma, u32 reg, u32 val)
{
- writel(val, tdma->base_addr + reg);
+ writel(val, tdma->base_addr + tdma->cdata->global_reg_offset + reg);
}
static inline u32 tdma_read(struct tegra_adma *tdma, u32 reg)
{
- return readl(tdma->base_addr + reg);
+ return readl(tdma->base_add
[PATCH 0/6] Add support for Tegra186/Tegra194 and generic fixes
Audio DMA(ADMA) interface is a gateway in the AHUB for facilitating DMA transfers between memory and all of its clients. Currently the driver supports Tegra210 based platforms. This series adds support for Tegra186 and Tegra194 based platforms and fixes few functional issues. Patches in the series are classified into three categories, 1. Add support for Tegra186 and Tegra194 2. Add DMA pause/resume feature 3. Fixes common to differernt Tegra generations Below change log describes the patches in detail. Change log: = v1 The series can be classified into 3 categories, 1. Add support for Tegra186 and Tegra194 [Patch 1/6] dmaengine: tegra210-adma: prepare for supporting newer Tegra chips * The support was there only for Tegra210 * This is a preparation for adding support for newer Tegra chips * chip_data is enhanced to support differences between Tegra210 and Tegra186/Tegra194 [Patch 2/6] Documentation: DT: Add compatibility binding for Tegra186 * New compatibility string is required for driver to work for Tegra186 and Tegra194. Hence new compatibility is introduced. * Tegra194 can use the same compatibility as Tegra186 [Patch 3/6] dmaengine: tegra210-adma: add support for Tegra186/ Tegra194 * Populates chip specific information for Tegra186 * There is a difference in the way ADMA CH_CONFIG registers are encoded for Tegra210 and Tegra186. Added helper fucntions to support different versions of burst size configuration 2. Add DMA pause/resume feature [Patch 4/6] dmaengine: tegra210-adma: add pause/resume support * Adds support for ADMA pause/resume, otherwise audio loss was seen during continuous pause/resume of audio playback. 3. Fixes common to differernt Tegra generations [Patch 5/6] dmaengine: tegra210-dma: free dma controller in remove() * Fixes kernel panic observed during driver reload. DMA controller needs to be freed when driver is unloaded [Patch 6/6] dmaengine: tegra210-adma: restore channel status * Fixes resume across system suspend. If the channel state is not restored, the transfers won't resume from the state from where it was left during suspend entry. In this case, audio playback did not resume properly once system exited from low power state. === Sameer Pujar (6): dmaengine: tegra210-adma: prepare for supporting newer Tegra chips Documentation: DT: Add compatibility binding for Tegra186 dmaengine: tegra210-adma: add support for Tegra186/Tegra194 dmaengine: tegra210-adma: add pause/resume support dmaengine: tegra210-dma: free dma controller in remove() dmaengine: tegra210-adma: restore channel status .../bindings/dma/nvidia,tegra210-adma.txt | 4 +- drivers/dma/tegra210-adma.c | 232 + 2 files changed, 193 insertions(+), 43 deletions(-) -- 2.7.4
[PATCH 2/6] Documentation: DT: Add compatibility binding for Tegra186
Tegra186 Audio DMA controller has new updates from Tegra210 version. Thus add new compatibility binding string and the same can be used by Tegra194 as well. Signed-off-by: Sameer Pujar --- Documentation/devicetree/bindings/dma/nvidia,tegra210-adma.txt | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/dma/nvidia,tegra210-adma.txt b/Documentation/devicetree/bindings/dma/nvidia,tegra210-adma.txt index 2f35b04..245d306 100644 --- a/Documentation/devicetree/bindings/dma/nvidia,tegra210-adma.txt +++ b/Documentation/devicetree/bindings/dma/nvidia,tegra210-adma.txt @@ -4,7 +4,9 @@ The Tegra Audio DMA controller that is used for transferring data between system memory and the Audio Processing Engine (APE). Required properties: -- compatible: Must be "nvidia,tegra210-adma". +- compatible: Should contain one of the following: + - "nvidia,tegra210-adma": for Tegra210 + - "nvidia,tegra186-adma": for Tegra186 and Tegra194 - reg: Should contain DMA registers location and length. This should be a single entry that includes all of the per-channel registers in one contiguous bank. -- 2.7.4
[PATCH] habanalabs: Update CPU DMA pool label name
From: Tomer Tayar The CPU accessible DMA pool is general and not used only for PQ. Accordingly, this patch rename the "free_cpu_pq_pool" label with "free_cpu_accessible_dma_pool". Signed-off-by: Tomer Tayar Signed-off-by: Oded Gabbay --- drivers/misc/habanalabs/goya/goya.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/misc/habanalabs/goya/goya.c b/drivers/misc/habanalabs/goya/goya.c index 9bf572a2d292..0fa0bdd7c852 100644 --- a/drivers/misc/habanalabs/goya/goya.c +++ b/drivers/misc/habanalabs/goya/goya.c @@ -670,14 +670,14 @@ static int goya_sw_init(struct hl_device *hdev) dev_err(hdev->dev, "Failed to add memory to CPU accessible DMA pool\n"); rc = -EFAULT; - goto free_cpu_pq_pool; + goto free_cpu_accessible_dma_pool; } spin_lock_init(&goya->hw_queues_lock); return 0; -free_cpu_pq_pool: +free_cpu_accessible_dma_pool: gen_pool_destroy(hdev->cpu_accessible_dma_pool); free_cpu_pq_dma_mem: hdev->asic_funcs->asic_dma_free_coherent(hdev, -- 2.17.1
[PATCH v3 0/2] Reduce mmap_sem usage for args manipulation
Hello. Just merged the two dicussed patches and fixed an overlooked warning. v2 - insert a patch refactoring validate_prctl_map - move find_vma out of the arg_lock critical section v3 - squash get_cmdline and prctl_set_mm patches (to keep locking consistency) - validate_prctl_map_addr: remove unused variable mm Michal Koutný (2): prctl_set_mm: Refactor checks from validate_prctl_map prctl_set_mm: downgrade mmap_sem to read lock kernel/sys.c | 56 mm/util.c| 4 ++-- 2 files changed, 30 insertions(+), 30 deletions(-) -- 2.16.4
[PATCH v3 2/2] prctl_set_mm: downgrade mmap_sem to read lock
The commit a3b609ef9f8b ("proc read mm's {arg,env}_{start,end} with mmap
semaphore taken.") added synchronization of reading argument/environment
boundaries under mmap_sem. Later commit 88aa7cc688d4 ("mm: introduce
arg_lock to protect arg_start|end and env_start|end in mm_struct")
avoided the coarse use of mmap_sem in similar situations. But there
still remained two places that (mis)use mmap_sem.
get_cmdline should also use arg_lock instead of mmap_sem when it reads the
boundaries.
The second place that should use arg_lock is in prctl_set_mm. By
protecting the boundaries fields with the arg_lock, we can downgrade
mmap_sem to reader lock (analogous to what we already do in
prctl_set_mm_map).
v2: call find_vma without arg_lock held
v3: squashed get_cmdline arg_lock patch
Fixes: 88aa7cc688d4 ("mm: introduce arg_lock to protect arg_start|end and
env_start|end in mm_struct")
Cc: Yang Shi
Cc: Mateusz Guzik
CC: Cyrill Gorcunov
Co-developed-by: Laurent Dufour
Signed-off-by: Laurent Dufour
Signed-off-by: Michal Koutný
---
kernel/sys.c | 10 --
mm/util.c| 4 ++--
2 files changed, 10 insertions(+), 4 deletions(-)
diff --git a/kernel/sys.c b/kernel/sys.c
index 5e0a5edf47f8..14be57840511 100644
--- a/kernel/sys.c
+++ b/kernel/sys.c
@@ -2122,9 +2122,14 @@ static int prctl_set_mm(int opt, unsigned long addr,
error = -EINVAL;
- down_write(&mm->mmap_sem);
+ /*
+* arg_lock protects concurent updates of arg boundaries, we need
mmap_sem for
+* a) concurrent sys_brk, b) finding VMA for addr validation.
+*/
+ down_read(&mm->mmap_sem);
vma = find_vma(mm, addr);
+ spin_lock(&mm->arg_lock);
prctl_map.start_code= mm->start_code;
prctl_map.end_code = mm->end_code;
prctl_map.start_data= mm->start_data;
@@ -2212,7 +2217,8 @@ static int prctl_set_mm(int opt, unsigned long addr,
error = 0;
out:
- up_write(&mm->mmap_sem);
+ spin_unlock(&mm->arg_lock);
+ up_read(&mm->mmap_sem);
return error;
}
diff --git a/mm/util.c b/mm/util.c
index 43a2984bccaa..5cf0e84a0823 100644
--- a/mm/util.c
+++ b/mm/util.c
@@ -758,12 +758,12 @@ int get_cmdline(struct task_struct *task, char *buffer,
int buflen)
if (!mm->arg_end)
goto out_mm;/* Shh! No looking before we're done */
- down_read(&mm->mmap_sem);
+ spin_lock(&mm->arg_lock);
arg_start = mm->arg_start;
arg_end = mm->arg_end;
env_start = mm->env_start;
env_end = mm->env_end;
- up_read(&mm->mmap_sem);
+ spin_unlock(&mm->arg_lock);
len = arg_end - arg_start;
--
2.16.4
[PATCH v3 1/2] prctl_set_mm: Refactor checks from validate_prctl_map
Despite comment of validate_prctl_map claims there are no capability
checks, it is not completely true since commit 4d28df6152aa ("prctl:
Allow local CAP_SYS_ADMIN changing exe_file"). Extract the check out of
the function and make the function perform purely arithmetic checks.
This patch should not change any behavior, it is mere refactoring for
following patch.
v1, v2: ---
v3: Remove unused mm variable from validate_prctl_map_addr
CC: Kirill Tkhai
CC: Cyrill Gorcunov
Signed-off-by: Michal Koutný
Reviewed-by: Kirill Tkhai
---
kernel/sys.c | 46 --
1 file changed, 20 insertions(+), 26 deletions(-)
diff --git a/kernel/sys.c b/kernel/sys.c
index 12df0e5434b8..5e0a5edf47f8 100644
--- a/kernel/sys.c
+++ b/kernel/sys.c
@@ -1882,13 +1882,14 @@ static int prctl_set_mm_exe_file(struct mm_struct *mm,
unsigned int fd)
}
/*
+ * Check arithmetic relations of passed addresses.
+ *
* WARNING: we don't require any capability here so be very careful
* in what is allowed for modification from userspace.
*/
-static int validate_prctl_map(struct prctl_mm_map *prctl_map)
+static int validate_prctl_map_addr(struct prctl_mm_map *prctl_map)
{
unsigned long mmap_max_addr = TASK_SIZE;
- struct mm_struct *mm = current->mm;
int error = -EINVAL, i;
static const unsigned char offsets[] = {
@@ -1949,24 +1950,6 @@ static int validate_prctl_map(struct prctl_mm_map
*prctl_map)
prctl_map->start_data))
goto out;
- /*
-* Someone is trying to cheat the auxv vector.
-*/
- if (prctl_map->auxv_size) {
- if (!prctl_map->auxv || prctl_map->auxv_size >
sizeof(mm->saved_auxv))
- goto out;
- }
-
- /*
-* Finally, make sure the caller has the rights to
-* change /proc/pid/exe link: only local sys admin should
-* be allowed to.
-*/
- if (prctl_map->exe_fd != (u32)-1) {
- if (!ns_capable(current_user_ns(), CAP_SYS_ADMIN))
- goto out;
- }
-
error = 0;
out:
return error;
@@ -1993,11 +1976,17 @@ static int prctl_set_mm_map(int opt, const void __user
*addr, unsigned long data
if (copy_from_user(&prctl_map, addr, sizeof(prctl_map)))
return -EFAULT;
- error = validate_prctl_map(&prctl_map);
+ error = validate_prctl_map_addr(&prctl_map);
if (error)
return error;
if (prctl_map.auxv_size) {
+ /*
+* Someone is trying to cheat the auxv vector.
+*/
+ if (!prctl_map.auxv || prctl_map.auxv_size >
sizeof(mm->saved_auxv))
+ return -EINVAL;
+
memset(user_auxv, 0, sizeof(user_auxv));
if (copy_from_user(user_auxv,
(const void __user *)prctl_map.auxv,
@@ -2010,6 +1999,14 @@ static int prctl_set_mm_map(int opt, const void __user
*addr, unsigned long data
}
if (prctl_map.exe_fd != (u32)-1) {
+ /*
+* Make sure the caller has the rights to
+* change /proc/pid/exe link: only local sys admin should
+* be allowed to.
+*/
+ if (!ns_capable(current_user_ns(), CAP_SYS_ADMIN))
+ return -EINVAL;
+
error = prctl_set_mm_exe_file(mm, prctl_map.exe_fd);
if (error)
return error;
@@ -2097,7 +2094,7 @@ static int prctl_set_mm(int opt, unsigned long addr,
unsigned long arg4, unsigned long arg5)
{
struct mm_struct *mm = current->mm;
- struct prctl_mm_map prctl_map;
+ struct prctl_mm_map prctl_map = { .auxv = NULL, .auxv_size = 0, .exe_fd
= -1 };
struct vm_area_struct *vma;
int error;
@@ -2139,9 +2136,6 @@ static int prctl_set_mm(int opt, unsigned long addr,
prctl_map.arg_end = mm->arg_end;
prctl_map.env_start = mm->env_start;
prctl_map.env_end = mm->env_end;
- prctl_map.auxv = NULL;
- prctl_map.auxv_size = 0;
- prctl_map.exe_fd= -1;
switch (opt) {
case PR_SET_MM_START_CODE:
@@ -2181,7 +2175,7 @@ static int prctl_set_mm(int opt, unsigned long addr,
goto out;
}
- error = validate_prctl_map(&prctl_map);
+ error = validate_prctl_map_addr(&prctl_map);
if (error)
goto out;
--
2.16.4
Re: [PATCH net-next 2/3] netlink: set bad attribute also on maxtype check
On Thu, 2019-05-02 at 12:48 +, Michal Kubecek wrote: > The check that attribute type is within 0...maxtype range in > __nla_validate_parse() sets only error message but not bad_attr in extack. > Set also bad_attr to tell userspace which attribute failed validation. Good catch, we actually do have an attribute in this case. Reviewed-by: Johannes Berg johannes
Re: [PATCH 2/4] devcoredump: allow to create several coredump files in one device
On Thu, 2019-05-02 at 17:59 +0900, Akinobu Mita wrote:
>
> static void devcd_del(struct work_struct *wk)
> {
> struct devcd_entry *devcd;
> + int i;
>
> devcd = container_of(wk, struct devcd_entry, del_wk.work);
>
> + for (i = 0; i < devcd->num_files; i++) {
> + device_remove_bin_file(&devcd->devcd_dev,
> +&devcd->files[i].bin_attr);
> + }
Not much value in the braces?
> +static struct devcd_entry *devcd_alloc(struct dev_coredumpm_bulk_data *files,
> +int num_files, gfp_t gfp)
> +{
> + struct devcd_entry *devcd;
> + int i;
> +
> + devcd = kzalloc(sizeof(*devcd), gfp);
> + if (!devcd)
> + return NULL;
> +
> + devcd->files = kcalloc(num_files, sizeof(devcd->files[0]), gfp);
> + if (!devcd->files) {
> + kfree(devcd);
> + return NULL;
> + }
> + devcd->num_files = num_files;
IMHO it would be nicer to allocate all of this in one struct, i.e. have
struct devcd_entry {
...
struct devcd_file files[];
}
(and then use struct_size())
> @@ -309,7 +339,41 @@ void dev_coredumpm(struct device *dev, struct module
> *owner,
> put_module:
> module_put(owner);
> free:
> - free(data);
> + for (i = 0; i < num_files; i++)
> + files[i].free(files[i].data);
> +}
and then you don't need to do all this kind of thing to free
Otherwise looks fine. I'd worry a bit that existing userspace will only
capture the 'data' file, rather than a tarball of all files, but I guess
that's something you'd have to work out then when actually desiring to
use multiple files.
johannes
[PATCH] of: unittest: Remove error printing on OOM
There is no need to print a backtrace or other error message if
kzalloc(), kmemdup(), or devm_kzalloc() fails, as the memory allocation
core already takes care of that.
Signed-off-by: Geert Uytterhoeven
---
drivers/of/unittest.c | 13 -
1 file changed, 4 insertions(+), 9 deletions(-)
diff --git a/drivers/of/unittest.c b/drivers/of/unittest.c
index 2f8e43876c3da70c..a3d31103962b7dd9 100644
--- a/drivers/of/unittest.c
+++ b/drivers/of/unittest.c
@@ -344,7 +344,7 @@ static void __init of_unittest_check_phandles(void)
}
nh = kzalloc(sizeof(*nh), GFP_KERNEL);
- if (WARN_ON(!nh))
+ if (!nh)
return;
nh->np = np;
@@ -1199,12 +1199,9 @@ static int __init unittest_data_add(void)
/* creating copy */
unittest_data = kmemdup(__dtb_testcases_begin, size, GFP_KERNEL);
-
- if (!unittest_data) {
- pr_warn("%s: Failed to allocate memory for unittest_data; "
- "not running tests\n", __func__);
+ if (!unittest_data)
return -ENOMEM;
- }
+
of_fdt_unflatten_tree(unittest_data, NULL, &unittest_data_node);
if (!unittest_data_node) {
pr_warn("%s: No tree to attach; not running tests\n", __func__);
@@ -1845,10 +1842,8 @@ static int unittest_i2c_bus_probe(struct platform_device
*pdev)
dev_dbg(dev, "%s for node @%pOF\n", __func__, np);
std = devm_kzalloc(dev, sizeof(*std), GFP_KERNEL);
- if (!std) {
- dev_err(dev, "Failed to allocate unittest i2c data\n");
+ if (!std)
return -ENOMEM;
- }
/* link them together */
std->pdev = pdev;
--
2.17.1
