drivers/net/can/kvaser_pciefd.c:801:17: sparse: sparse: cast removes address space '' of expression
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: b791d1bdf9212d944d749a5c7ff6febdba241771 commit: 26ad340e582d3d5958ed8456a1911d79cfb567b4 can: kvaser_pciefd: Add driver for Kvaser PCIEcan devices date: 11 months ago config: m68k-randconfig-s032-20200612 (attached as .config) compiler: m68k-linux-gcc (GCC) 9.3.0 reproduce: # apt-get install sparse # sparse version: v0.6.1-250-g42323db3-dirty git checkout 26ad340e582d3d5958ed8456a1911d79cfb567b4 # save the attached .config to linux build tree make W=1 C=1 ARCH=m68k CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot sparse warnings: (new ones prefixed by >>) >> drivers/net/can/kvaser_pciefd.c:801:17: sparse: sparse: cast removes address >> space '' of expression drivers/net/can/kvaser_pciefd.c:805:17: sparse: sparse: cast removes address space '' of expression arch/m68k/include/asm/io_no.h:77:24: sparse: sparse: cast removes address space '' of expression arch/m68k/include/asm/io_no.h:78:16: sparse: sparse: cast removes address space '' of expression arch/m68k/include/asm/io_no.h:78:16: sparse: sparse: cast to restricted __le32 arch/m68k/include/asm/io_no.h:78:16: sparse: sparse: cast removes address space '' of expression arch/m68k/include/asm/io_no.h:78:16: sparse: sparse: cast to restricted __le32 arch/m68k/include/asm/io_no.h:78:16: sparse: sparse: cast removes address space '' of expression arch/m68k/include/asm/io_no.h:78:16: sparse: sparse: cast to restricted __le32 arch/m68k/include/asm/io_no.h:78:16: sparse: sparse: cast removes address space '' of expression arch/m68k/include/asm/io_no.h:78:16: sparse: sparse: cast to restricted __le32 arch/m68k/include/asm/io_no.h:78:16: sparse: sparse: cast removes address space '' of expression arch/m68k/include/asm/io_no.h:78:16: sparse: sparse: cast to restricted __le32 arch/m68k/include/asm/io_no.h:78:16: sparse: sparse: cast removes address space '' of expression arch/m68k/include/asm/io_no.h:78:16: sparse: sparse: cast to restricted __le32 arch/m68k/include/asm/io_no.h:77:24: sparse: sparse: cast removes address space '' of expression arch/m68k/include/asm/io_no.h:78:16: sparse: sparse: cast removes address space '' of expression arch/m68k/include/asm/io_no.h:78:16: sparse: sparse: cast to restricted __le32 arch/m68k/include/asm/io_no.h:78:16: sparse: sparse: cast removes address space '' of expression arch/m68k/include/asm/io_no.h:78:16: sparse: sparse: cast to restricted __le32 arch/m68k/include/asm/io_no.h:78:16: sparse: sparse: cast removes address space '' of expression arch/m68k/include/asm/io_no.h:78:16: sparse: sparse: cast to restricted __le32 arch/m68k/include/asm/io_no.h:78:16: sparse: sparse: cast removes address space '' of expression arch/m68k/include/asm/io_no.h:78:16: sparse: sparse: cast to restricted __le32 arch/m68k/include/asm/io_no.h:78:16: sparse: sparse: cast removes address space '' of expression arch/m68k/include/asm/io_no.h:78:16: sparse: sparse: cast to restricted __le32 arch/m68k/include/asm/io_no.h:78:16: sparse: sparse: cast removes address space '' of expression arch/m68k/include/asm/io_no.h:78:16: sparse: sparse: cast to restricted __le32 arch/m68k/include/asm/io_no.h:77:24: sparse: sparse: cast removes address space '' of expression arch/m68k/include/asm/io_no.h:78:16: sparse: sparse: cast removes address space '' of expression arch/m68k/include/asm/io_no.h:78:16: sparse: sparse: cast to restricted __le32 arch/m68k/include/asm/io_no.h:78:16: sparse: sparse: cast removes address space '' of expression arch/m68k/include/asm/io_no.h:78:16: sparse: sparse: cast to restricted __le32 arch/m68k/include/asm/io_no.h:78:16: sparse: sparse: cast removes address space '' of expression arch/m68k/include/asm/io_no.h:78:16: sparse: sparse: cast to restricted __le32 arch/m68k/include/asm/io_no.h:78:16: sparse: sparse: cast removes address space '' of expression arch/m68k/include/asm/io_no.h:78:16: sparse: sparse: cast to restricted __le32 arch/m68k/include/asm/io_no.h:78:16: sparse: sparse: cast removes address space '' of expression arch/m68k/include/asm/io_no.h:78:16: sparse: sparse: cast to restricted __le32 arch/m68k/include/asm/io_no.h:78:16: sparse: sparse: cast removes address space '' of expression arch/m68k/include/asm/io_no.h:78:16: sparse: sparse: cast to restricted __le32 arch/m68k/include/asm/io_no.h:77:24: sparse: sparse: cast removes address space '' of expression arch/m68k/include/asm/io_no.h:78:16: sparse: sparse: cast removes address space '' of expression arch/m68k/include/asm/io_no.h:78:16: sparse: sparse: cast to restricted __le32 arch/m68k/include/asm/io_no.h:78:16: sparse: sparse: cast removes address space '' of
Re: [PATCH] i2c: imx: Fix external abort on early interrupt
Hi Krzysztof,
thank you for your patch.
On Wed, Jun 10, 2020 at 03:46:42PM +0200, Krzysztof Kozlowski wrote:
> If interrupt comes early (could be triggered with CONFIG_DEBUG_SHIRQ),
> the i2c_imx_isr() will access registers before the I2C hardware is
> initialized. This leads to external abort on non-linefetch on Toradex
> Colibri VF50 module (with Vybrid VF5xx):
>
> Unhandled fault: external abort on non-linefetch (0x1008) at 0x8882d003
> Internal error: : 1008 [#1] ARM
> Modules linked in:
> CPU: 0 PID: 1 Comm: swapper Not tainted 5.7.0 #607
> Hardware name: Freescale Vybrid VF5xx/VF6xx (Device Tree)
> (i2c_imx_isr) from [<8017009c>] (free_irq+0x25c/0x3b0)
> (free_irq) from [<805844ec>] (release_nodes+0x178/0x284)
> (release_nodes) from [<80580030>] (really_probe+0x10c/0x348)
> (really_probe) from [<80580380>] (driver_probe_device+0x60/0x170)
> (driver_probe_device) from [<80580630>] (device_driver_attach+0x58/0x60)
> (device_driver_attach) from [<805806bc>] (__driver_attach+0x84/0xc0)
> (__driver_attach) from [<8057e228>] (bus_for_each_dev+0x68/0xb4)
> (bus_for_each_dev) from [<8057f3ec>] (bus_add_driver+0x144/0x1ec)
> (bus_add_driver) from [<80581320>] (driver_register+0x78/0x110)
> (driver_register) from [<8010213c>] (do_one_initcall+0xa8/0x2f4)
> (do_one_initcall) from [<80c0100c>] (kernel_init_freeable+0x178/0x1dc)
> (kernel_init_freeable) from [<80807048>] (kernel_init+0x8/0x110)
> (kernel_init) from [<80100114>] (ret_from_fork+0x14/0x20)
>
> Additionally, the i2c_imx_isr() could wake up the wait queue
> (imx_i2c_struct->queue) before its initialization happens.
>
> Fixes: 1c4b6c3bcf30 ("i2c: imx: implement bus recovery")
> Cc:
> Signed-off-by: Krzysztof Kozlowski
I assume register access is aborted, because the IP core clock is not
enabled. In this case we have bigger problem then just probe.
Since this driver support runtime power management, the clock will be
disabled as soon as transfer is done. It means, on shared interrupt, we
will get in trouble even if there is no active transfer.
So, probably the only way to fix it, is to check in i2c_imx_isr() if the
HW is expected to be active and register access should be save.
Regards,
Oleksij
> ---
> drivers/i2c/busses/i2c-imx.c | 20 ++--
> 1 file changed, 10 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/i2c/busses/i2c-imx.c b/drivers/i2c/busses/i2c-imx.c
> index 0ab5381aa012..e28a39f4840f 100644
> --- a/drivers/i2c/busses/i2c-imx.c
> +++ b/drivers/i2c/busses/i2c-imx.c
> @@ -1171,14 +1171,6 @@ static int i2c_imx_probe(struct platform_device *pdev)
> return ret;
> }
>
> - /* Request IRQ */
> - ret = devm_request_irq(>dev, irq, i2c_imx_isr, IRQF_SHARED,
> - pdev->name, i2c_imx);
> - if (ret) {
> - dev_err(>dev, "can't claim irq %d\n", irq);
> - goto clk_disable;
> - }
> -
> /* Init queue */
> init_waitqueue_head(_imx->queue);
>
> @@ -1223,6 +1215,14 @@ static int i2c_imx_probe(struct platform_device *pdev)
> if (ret < 0)
> goto clk_notifier_unregister;
>
> + /* Request IRQ */
> + ret = devm_request_irq(>dev, irq, i2c_imx_isr, IRQF_SHARED,
> + pdev->name, i2c_imx);
> + if (ret) {
> + dev_err(>dev, "can't claim irq %d\n", irq);
> + goto i2c_del_adapter;
> + }
> +
> pm_runtime_mark_last_busy(>dev);
> pm_runtime_put_autosuspend(>dev);
>
> @@ -1237,6 +1237,8 @@ static int i2c_imx_probe(struct platform_device *pdev)
>
> return 0; /* Return OK */
>
> +i2c_del_adapter:
> + i2c_del_adapter(_imx->adapter);
> clk_notifier_unregister:
> clk_notifier_unregister(i2c_imx->clk, _imx->clk_change_nb);
> rpm_disable:
> @@ -1244,8 +1246,6 @@ static int i2c_imx_probe(struct platform_device *pdev)
> pm_runtime_disable(>dev);
> pm_runtime_set_suspended(>dev);
> pm_runtime_dont_use_autosuspend(>dev);
> -
> -clk_disable:
> clk_disable_unprepare(i2c_imx->clk);
> return ret;
> }
> --
> 2.7.4
>
>
--
Pengutronix e.K. | |
Steuerwalder Str. 21 | http://www.pengutronix.de/ |
31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
signature.asc
Description: PGP signature
Re: [PATCH 4.19 24/25] uprobes: ensure that uprobe->offset and ->ref_ctr_offset are properly aligned
On Thu, Jun 11, 2020 at 06:51:17PM +0200, Oleg Nesterov wrote: > On 06/10, Greg Kroah-Hartman wrote: > > > > > Greg, please let me know if you want me to send the patches for > > > 4.9/4.14/4.19. > > > > Please do. I tried to backport it to those trees, and it seems to > > build/boot/run, but I would like verification I didn't mess anything up > > :) > > > > Your 4.4 version below matched my version, so I think I'm ok... > > Greg, I was going to send the patches, but after I've cloned > git/stable/linux-stable-rc.git I see that you have already updated these > > origin/queue/4.14 > origin/queue/4.19 > origin/queue/4.4 > origin/queue/4.9 > > branches, and the new patches look good to me. > > So I think I can relax? ;) Yes, please relax, all is fine, thanks for verifying. greg k-h
[GIT PULL] xen: branch for v5.8-rc1
Linus, Please git pull the following tag: git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git for-linus-5.8b-rc1-tag xen: branch for v5.8-rc1 It contains the following patches: - several smaller cleanups - a fix for a Xen guest regression with CPU offlining - a small fix in the xen pvcalls backend driver - an update of MAINTAINERS Thanks. Juergen MAINTAINERS | 4 +-- drivers/pci/xen-pcifront.c | 27 ++ drivers/xen/Kconfig | 4 +++ drivers/xen/cpu_hotplug.c | 8 ++--- drivers/xen/platform-pci.c | 2 +- drivers/xen/pvcalls-back.c | 5 +-- drivers/xen/xen-pciback/conf_space.c| 16 - drivers/xen/xen-pciback/conf_space_header.c | 44 --- drivers/xen/xen-pciback/conf_space_quirks.c | 6 ++-- drivers/xen/xen-pciback/pci_stub.c | 38 +--- drivers/xen/xen-pciback/pciback.h | 2 -- drivers/xen/xen-pciback/pciback_ops.c | 55 + drivers/xen/xen-pciback/vpci.c | 10 +++--- drivers/xen/xenbus/xenbus_probe.c | 11 +++--- 14 files changed, 90 insertions(+), 142 deletions(-) Bjorn Helgaas (2): xen-pciback: Use dev_printk() when possible xenbus: Use dev_printk() when possible Boris Ostrovsky (2): xen/cpuhotplug: Fix initial CPU offlining for PV(H) guests xen/pci: Get rid of verbose_request and use dev_dbg() instead Deep Shah (1): MAINTAINERS: Update PARAVIRT_OPS_INTERFACE and VMWARE_HYPERVISOR_INTERFACE Juergen Gross (1): xen/pvcalls-back: test for errors when calling backend_connect() Rikard Falkeborn (1): xen-platform: Constify dev_pm_ops Roger Pau Monne (2): xen: expand BALLOON_MEMORY_HOTPLUG description xen: enable BALLOON_MEMORY_HOTPLUG by default YueHaibing (1): xen/pvcalls: Make pvcalls_back_global static
[PATCH] usb: replace hardcoded maximum usb string length by definition
Replace hardcoded maximum usb string length (126 bytes) by definition
"MAX_USB_STRING_LEN".
Signed-off-by: Macpaul Lin
---
drivers/usb/gadget/composite.c |4 ++--
drivers/usb/gadget/configfs.c |3 ++-
drivers/usb/gadget/usbstring.c |5 +++--
include/linux/usb.h|2 ++
4 files changed, 9 insertions(+), 5 deletions(-)
diff --git a/drivers/usb/gadget/composite.c b/drivers/usb/gadget/composite.c
index cb4950c..d0de016 100644
--- a/drivers/usb/gadget/composite.c
+++ b/drivers/usb/gadget/composite.c
@@ -1041,7 +1041,7 @@ static void collect_langs(struct usb_gadget_strings **sp,
__le16 *buf)
while (*sp) {
s = *sp;
language = cpu_to_le16(s->language);
- for (tmp = buf; *tmp && tmp < [126]; tmp++) {
+ for (tmp = buf; *tmp && tmp < [MAX_USB_STRING_LEN]; tmp++) {
if (*tmp == language)
goto repeat;
}
@@ -1116,7 +1116,7 @@ static int get_string(struct usb_composite_dev *cdev,
collect_langs(sp, s->wData);
}
- for (len = 0; len <= 126 && s->wData[len]; len++)
+ for (len = 0; len <= MAX_USB_STRING_LEN && s->wData[len]; len++)
continue;
if (!len)
return -EINVAL;
diff --git a/drivers/usb/gadget/configfs.c b/drivers/usb/gadget/configfs.c
index 32b637e..c9d61ac 100644
--- a/drivers/usb/gadget/configfs.c
+++ b/drivers/usb/gadget/configfs.c
@@ -4,6 +4,7 @@
#include
#include
#include
+#include
#include
#include
#include "configfs.h"
@@ -115,7 +116,7 @@ static int usb_string_copy(const char *s, char **s_copy)
char *str;
char *copy = *s_copy;
ret = strlen(s);
- if (ret > 126)
+ if (ret > MAX_USB_STRING_LEN)
return -EOVERFLOW;
str = kstrdup(s, GFP_KERNEL);
diff --git a/drivers/usb/gadget/usbstring.c b/drivers/usb/gadget/usbstring.c
index 7c24d1c..c125d59 100644
--- a/drivers/usb/gadget/usbstring.c
+++ b/drivers/usb/gadget/usbstring.c
@@ -11,6 +11,7 @@
#include
#include
+#include
#include
#include
@@ -55,9 +56,9 @@
return -EINVAL;
/* string descriptors have length, tag, then UTF16-LE text */
- len = min ((size_t) 126, strlen (s->s));
+ len = min((size_t)MAX_USB_STRING_LEN, strlen(s->s));
len = utf8s_to_utf16s(s->s, len, UTF16_LITTLE_ENDIAN,
- (wchar_t *) [2], 126);
+ (wchar_t *) [2], MAX_USB_STRING_LEN);
if (len < 0)
return -EINVAL;
buf [0] = (len + 1) * 2;
diff --git a/include/linux/usb.h b/include/linux/usb.h
index 9f3c721..df4a9cb 100644
--- a/include/linux/usb.h
+++ b/include/linux/usb.h
@@ -1815,6 +1815,8 @@ static inline int usb_get_ptm_status(struct usb_device
*dev, void *data)
0, data);
}
+/* USB String descriptors can contain at most 126 characters. */
+#define MAX_USB_STRING_LEN 126
extern int usb_string(struct usb_device *dev, int index,
char *buf, size_t size);
--
1.7.9.5
Re: [PATCH v2 01/14] Documentation: PCI: Add specification for the *PCI NTB* function device
Hi Matthew, On 6/11/2020 8:43 PM, Matthew Wilcox wrote: > On Thu, Jun 11, 2020 at 06:35:12PM +0530, Kishon Vijay Abraham I wrote: >> +++ b/Documentation/PCI/endpoint/pci-ntb-function.rst >> @@ -0,0 +1,344 @@ >> +.. SPDX-License-Identifier: GPL-2.0 >> + >> += >> +PCI NTB Function >> += >> + >> +:Author: Kishon Vijay Abraham I >> + >> +PCI NTB Function allows two different systems (or hosts) to communicate >> +with each other by configurig the endpoint instances in such a way that >> +transactions from one system is routed to the other system. > > At no point in this document do you expand "NTB" into Non-Transparent > Bridge. The above paragraph probably also needs to say something like "By > making each host appear as a device to the other host". Although maybe > that's not entirely accurate? It's been a few years since I last played > with NTBs. > > So how about the following opening paragraph: > > PCI Non Transparent Bridges (NTB) allow two host systems to communicate > with each other by exposing each host as a device to the other host. > NTBs typically support the ability to generate interrupts on the remote > machine, expose memory ranges as BARs and perform DMA. They also support > scratchpads which are areas of memory within the NTB that are accessible > from both machines. > > ... feel free to fix that up if my memory is out of date or corrupted. I think that's accurate. I'll wait for review comments on the rest of the series and I'll fix this one in my next revision. Thanks Kishon
Re: [PATCH RFC] x86/entry: Ask RCU if it needs rcu_irq_{enter,exit}()
On Thu, Jun 11, 2020 at 4:53 PM Paul E. McKenney wrote: > > RCU needs to detect when one if its interrupt handlers interrupted an idle > state, where an idle state is either the idle loop itself or nohz_full > userspace execution. When a CPU has been interrupted from one of these > idle states, RCU can report a quiescent state, helping the current grace > period to come to an end. > > However, there are optimized kernel-entry paths where handlers that > would normally be executed in interrupt context are instead executed > directly from the base process context, but with interrupts disabled. > When such a directly-executed handler is followed by softirq processing > (which re-enables interrupts), it is possible that one of RCU's interrupt > handlers will interrupt this softirq processing. Why is the softirq processing special? ISTM the basic sequence of events is: idle, RCU not watching, IRQs on because we're using a lousy idle mechanism that requires IRQs on. IRQ hits. The ones you're describing are the DEFINE_IDTENTRY_SYSVEC_SIMPLE ones, but I'm not sure why it would matter. IRQ does idtentry_enter_cond_rcu(). idtentry_entry_cond_rcu() sees __rcu_is_watching() return true and does not do rcu_irq_enter(). softirq processing turns on IRQs, a new IRQ hits, and kaboom. But this is a bit of a strange explanation. The SYSVEC_SIMPLE paths don't seem to do irq_exit_rcu(), so there's no softirq processing unless I missed something. But more importantly, what are we doing making it through idtentry_enter_cond_rcu() with rcu not watching at the end? If we hit the idle loop, surely __rcu_is_watching() should have returned false, right? So I added a little warning to detect the case where your patch actually changes something (I don't believe for a second that this warning should be committed -- it's just to get the stack trace): diff --git a/arch/x86/entry/common.c b/arch/x86/entry/common.c index f0b657097a2a..77330b96d8e5 100644 --- a/arch/x86/entry/common.c +++ b/arch/x86/entry/common.c @@ -592,6 +592,8 @@ bool noinstr idtentry_enter_cond_rcu(struct pt_regs *regs) return true; } + WARN_ON_ONCE(system_state == SYSTEM_RUNNING && is_idle_task(current)); + /* * If RCU is watching then RCU only wants to check * whether it needs to restart the tick in NOHZ And I get this: [1.054927] [ cut here ] [1.054928] WARNING: CPU: 1 PID: 0 at arch/x86/entry/common.c:595 idtentry_enter_cond_rcu+0x86/0xa0 [1.054929] Modules linked in: [1.054930] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 5.7.0+ #145 [1.054931] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS ?-20190727_073836-buildvm-ppc64le-16.ppc.fedoraproject.org-3.fc31 04/01/2014 [1.054931] RIP: 0010:idtentry_enter_cond_rcu+0x86/0xa0 [1.054933] Code: 7c 24 08 e8 3c 3e 00 00 e8 57 a5 6e ff e8 d2 49 00 00 84 c0 74 19 90 31 c0 5b c3 65 48 8b 04 25 c0 7e 01 00 f6 40 24 02 74 99 <0f> 0b 90 eb 94 0f 0b 90 eb e2 0f 0b 90 eb 9d 66 66 2e 0f 1f 84 00 [1.054933] RSP: :c906bc10 EFLAGS: 00010002 [1.054934] RAX: 88807d529800 RBX: c906bc38 RCX: 81c01327 [1.054935] RDX: RSI: 81c00f49 RDI: c906bc38 [1.054935] RBP: c906bc38 R08: R09: [1.054936] R10: R11: R12: [1.054936] R13: R14: R15: [1.054937] FS: () GS:88807dd0() knlGS: [1.054937] CS: 0010 DS: ES: CR0: 80050033 [1.054938] CR2: CR3: 02620001 CR4: 00360ee0 [1.054938] Call Trace: [1.054939] sysvec_call_function_single+0xa/0xd0 [1.054939] asm_sysvec_call_function_single+0x31/0x40 [1.054940] RIP: 0010:__do_softirq+0xaa/0x437 [1.054941] Code: 24 2c 0a 00 00 00 48 89 44 24 10 48 89 44 24 20 44 89 34 24 65 66 c7 05 22 b3 22 7e 00 00 e8 ad dc 40 ff fb 66 0f 1f 44 00 00 ff ff ff ff 48 c7 c6 00 51 60 82 0f bc 04 24 83 c0 01 49 89 f7 [1.054941] RSP: :c906bd18 EFLAGS: 0202 [1.054942] RAX: 1a6e RBX: 88807d529800 RCX: [1.054943] RDX: RSI: RDI: 81e000a3 [1.054944] RBP: c906bdc8 R08: R09: [1.054944] R10: 0001 R11: R12: [1.054945] R13: R14: 0082 R15: [1.054945] ? __do_softirq+0xa3/0x437 [1.054945] ? __do_softirq+0xaa/0x437 [1.054946] ? __do_softirq+0xa3/0x437 [1.054946] ? update_ts_time_stats+0x4c/0x70 [1.054947] irq_exit_rcu+0xaf/0xc0 [1.054947] sysvec_apic_timer_interrupt+0x51/0xd0 [1.054948] asm_sysvec_apic_timer_interrupt+0x31/0x40 [1.054948] RIP: 0010:native_safe_halt+0xe/0x10
[PATCH] mptcp: unify MPTCP_PM_MAX_ADDR and MPTCP_PM_ADDR_MAX
Unify these two duplicate macros into 8.
Signed-off-by: Geliang Tang
---
net/mptcp/pm_netlink.c | 2 --
net/mptcp/protocol.h | 2 +-
2 files changed, 1 insertion(+), 3 deletions(-)
diff --git a/net/mptcp/pm_netlink.c b/net/mptcp/pm_netlink.c
index b78edf237ba0..b694f13caba8 100644
--- a/net/mptcp/pm_netlink.c
+++ b/net/mptcp/pm_netlink.c
@@ -41,8 +41,6 @@ struct pm_nl_pernet {
unsigned intnext_id;
};
-#define MPTCP_PM_ADDR_MAX 8
-
static bool addresses_equal(const struct mptcp_addr_info *a,
struct mptcp_addr_info *b, bool use_port)
{
diff --git a/net/mptcp/protocol.h b/net/mptcp/protocol.h
index 809687d3f410..86d265500cf6 100644
--- a/net/mptcp/protocol.h
+++ b/net/mptcp/protocol.h
@@ -135,7 +135,7 @@ static inline __be32 mptcp_option(u8 subopt, u8 len, u8
nib, u8 field)
((nib & 0xF) << 8) | field);
}
-#define MPTCP_PM_MAX_ADDR 4
+#define MPTCP_PM_ADDR_MAX 8
struct mptcp_addr_info {
sa_family_t family;
--
2.17.1
Re: [RFC] dt-bindings: mailbox: add doorbell support to ARM MHU
On 11-06-20, 19:34, Jassi Brar wrote: > In the first post in this thread, Viresh lamented that mailbox > introduces "a few ms" delay in the scheduler path. > Your own tests show that is certainly not the case -- average is the > same as proposed virtual channels 50-100us, the best case is 3us vs > 53us for virtual channels. Hmmm, I am not sure where is the confusion here Jassi. There are two things which are very very different from each other. - Time taken by the mailbox framework (and remote for acknowledging it) for completion of a single request, this can be 3us to 100s of us. This is clear for everyone. THIS IS NOT THE PROBLEM. - Delay introduced by few of such requests on the last one, i.e. 5 normal requests followed by an important one (like DVFS), the last one needs to wait for the first 5 to finish first. THIS IS THE PROBLEM. Just increasing the timeout isn't going to solve anything as I said in the last email, we can make it 5 minutes for what's its worth. The idea is to make the turn-around-time less for all the requests.. >From Google (I know you must already know it, I am just trying to highlight the importance of this thing here): Turnaround time (TAT) is the time interval from the time of submission of a process (read request) to the time of the completion of the process. This is what people care about, that is the whole reason kernel has multi-processing support in the first place. If making things sequential was good enough, we would have never reached here. The whole idea is to parallelize things as much as possible without hurting efficiency in a bad way (like too much parallelism). The hardware allows parallelism and there is absolutely no point in not allowing that. The kernel doesn't need to worry about how the remote is going to handle it. Remote may be simple and handle it sequentially or it may be running Linux itself and can schedule multiple threads for requests. -- viresh
RE: [PATCH v1 01/11] perf/x86/core: Support KVM to assign a dedicated counter for guest PEBS
> > > Suppose your KVM thing claims counter 0/2 (ICL/SKL) for some random > > > PEBS event, and then the host wants to use PREC_DIST.. Then one of > > > them will be screwed for no reason what so ever. > > > > > > > The multiplexing should be triggered. > > > > For host, if both user A and user B requires PREC_DIST, the > > multiplexing should be triggered for them. > > Now, the user B is KVM. I don't think there is difference. The > > multiplexing should still be triggered. Why it is screwed? > > Becuase if KVM isn't PREC_DIST we should be able to reschedule it to a > different counter. > > > > How is that not destroying scheduling freedom? Any other situation > > > we'd have moved the !PREC_DIST PEBS event to another counter. > > > > > > > All counters are equivalent for them. It doesn't matter if we move it > > to another counter. There is no impact for the user. > > But we cannot move it to another counter, because you're pinning it. Hi Peter, To avoid the pinning counters, I have tried to do some evaluation about patching the PEBS record for guest in KVM. In this approach, about ~30% time increased on guest PEBS PMI handler latency ( e.g.perf record -e branch-loads:p -c 1000 ~/Tools/br_instr a). Some implementation details as below: 1. Patching the guest PEBS records "Applicable Counters" filed when the guest required counter is not the same with the host. Because the guest PEBS driver will drop these PEBS records if the "Applicable Counters" not the same with the required counter index. 2. Traping the guest driver's behavior(VM-exit) of disabling PEBS. It happens before reading PEBS records (e.g. PEBS PMI handler, before application exit and so on) 3. To patch the Guest PEBS records in KVM, we need to get the HPA of the guest PEBS buffer. <1> Trapping the guest write of IA32_DS_AREA register and get the GVA of guest DS_AREA. <2> Translate the DS AREA GVA to GPA(kvm_mmu_gva_to_gpa_read) and get the GVA of guest PEBS buffer from DS AREA (kvm_vcpu_read_guest_atomic). <3> Although we have got the GVA of PEBS buffer, we need to do the address translation(GVA->GPA->HPA) for each page. Because we can't assume the GPAs of Guest PEBS buffer are always continuous. But we met another issue about the PEBS counter reset field in DS AREA. pebs_event_reset in DS area has to be set for auto reload, which is per counter. Guest and Host may use different counters. Let's say guest wants to use counter 0, but host assign counter 1 to guest. Guest sets the reset value to pebs_event_reset[0]. However, since counter 1 is the one which is eventually scheduled, HW will use pebs_event_reset[1] as reset value. We can't copy the value of the guest pebs_event_reset[0] to pebs_event_reset[1] directly(Patching DS AREA) because the guest driver may confused, and we can't assume the guest counter 0 and 1 are not used for this PEBS task at the same time. And what's more, KVM can't aware the guest read/write to the DS AREA because it just a general memory for guest. What is your opinion or do you have a better proposal? Thanks, Luwei Kang > > > In the new proposal, KVM user is treated the same as other host events > > with event constraint. The scheduler is free to choose whether or not > > to assign a counter for it. > > That's what it does, I understand that. I'm saying that that is creating > artificial > contention. > > > Why is this needed anyway? Can't we force the guest to flush and then move it > over to a new counter?
[tip:locking/urgent] BUILD SUCCESS 37f8173dd84936ea78000ed1cad24f8b18d48ebb
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git locking/urgent branch HEAD: 37f8173dd84936ea78000ed1cad24f8b18d48ebb locking/atomics: Flip fallbacks and instrumentation elapsed time: 817m configs tested: 117 configs skipped: 1 The following configs have been built successfully. More configs may be tested in the coming days. arm defconfig arm allyesconfig arm allmodconfig arm allnoconfig arm64allyesconfig arm64 defconfig arm64allmodconfig arm64 allnoconfig powerpc ps3_defconfig m68k m5475evb_defconfig shtitan_defconfig parisc allyesconfig c6xevmc6457_defconfig nds32 defconfig alphaalldefconfig mips loongson1b_defconfig alpha defconfig mips bmips_be_defconfig i386 allnoconfig i386 allyesconfig i386defconfig i386 debian-10.3 ia64 allmodconfig ia64defconfig ia64 allnoconfig ia64 allyesconfig m68k allmodconfig m68k allnoconfig m68k sun3_defconfig m68kdefconfig m68k allyesconfig nios2 defconfig nios2allyesconfig openriscdefconfig c6x allyesconfig c6x allnoconfig openrisc allyesconfig nds32 allnoconfig csky allyesconfig cskydefconfig alphaallyesconfig xtensa allyesconfig h8300allyesconfig h8300allmodconfig xtensa defconfig arc defconfig arc allyesconfig sh allmodconfig shallnoconfig microblazeallnoconfig mips allyesconfig mips allnoconfig mips allmodconfig pariscallnoconfig parisc defconfig parisc allmodconfig powerpc allyesconfig powerpc rhel-kconfig powerpc allmodconfig powerpc allnoconfig powerpc defconfig i386 randconfig-a006-20200611 i386 randconfig-a002-20200611 i386 randconfig-a001-20200611 i386 randconfig-a004-20200611 i386 randconfig-a005-20200611 i386 randconfig-a003-20200611 i386 randconfig-a006-20200612 i386 randconfig-a002-20200612 i386 randconfig-a001-20200612 i386 randconfig-a004-20200612 i386 randconfig-a005-20200612 i386 randconfig-a003-20200612 x86_64 randconfig-a015-20200611 x86_64 randconfig-a011-20200611 x86_64 randconfig-a016-20200611 x86_64 randconfig-a012-20200611 x86_64 randconfig-a014-20200611 x86_64 randconfig-a013-20200611 x86_64 randconfig-a001-20200612 x86_64 randconfig-a003-20200612 x86_64 randconfig-a002-20200612 x86_64 randconfig-a006-20200612 x86_64 randconfig-a005-20200612 x86_64 randconfig-a004-20200612 i386 randconfig-a015-20200611 i386 randconfig-a011-20200611 i386 randconfig-a014-20200611 i386 randconfig-a013-20200611 i386 randconfig-a016-20200611 i386 randconfig-a012-20200611 riscvallyesconfig riscv allnoconfig riscv defconfig riscvallmodconfig s390 allyesconfig s390 allnoconfig s390 allmodconfig s390defconfig sparcallyesconfig sparc
Re: [PATCH v8 5/7] iommu/arm-smmu: Add implementation for the adreno GPU SMMU
Hi Jordan,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on linus/master]
[also build test ERROR on next-20200611]
[cannot apply to iommu/next robh/for-next arm/for-next keystone/next
rockchip/for-next arm64/for-next/core shawnguo/for-next soc/for-next v5.7]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we also suggest to use '--base' option to specify the
base tree in git format-patch, please see https://stackoverflow.com/a/37406982]
url:
https://github.com/0day-ci/linux/commits/Jordan-Crouse/iommu-arm-smmu-Enable-split-pagetable-support/20200612-094718
base: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
b961f8dc8976c091180839f4483d67b7c2ca2578
config: arm64-randconfig-s031-20200612 (attached as .config)
compiler: aarch64-linux-gcc (GCC) 9.3.0
reproduce:
# apt-get install sparse
# sparse version: v0.6.1-250-g42323db3-dirty
# save the attached .config to linux build tree
make W=1 C=1 ARCH=arm64 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__'
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All error/warnings (new ones prefixed by >>, old ones prefixed by <<):
drivers/iommu/arm-smmu-qcom.c: In function 'qcom_adreno_smmu_is_gpu_device':
>> drivers/iommu/arm-smmu-qcom.c:17:49: error: 'smmu_domain->dev' is a pointer;
>> did you mean to use '->'?
17 | return of_device_is_compatible(smmu_domain->dev.of_node, "qcom,adreno");
| ^
| ->
>> drivers/iommu/arm-smmu-qcom.c:18:1: warning: control reaches end of non-void
>> function [-Wreturn-type]
18 | }
| ^
vim +17 drivers/iommu/arm-smmu-qcom.c
14
15 static bool qcom_adreno_smmu_is_gpu_device(struct arm_smmu_domain
*smmu_domain)
16 {
> 17 return of_device_is_compatible(smmu_domain->dev.of_node,
"qcom,adreno");
> 18 }
19
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
.config.gz
Description: application/gzip
Re: [PATCH v4] powerpc/fadump: fix race between pstore write and fadump crash trigger
Hi Sourabh,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on powerpc/next]
[also build test ERROR on linus/master linux/master v5.7 next-20200611]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we also suggest to use '--base' option to specify the
base tree in git format-patch, please see https://stackoverflow.com/a/37406982]
url:
https://github.com/0day-ci/linux/commits/Sourabh-Jain/powerpc-fadump-fix-race-between-pstore-write-and-fadump-crash-trigger/20200605-033545
base: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git next
config: powerpc-randconfig-r002-20200612 (attached as .config)
compiler: powerpc64le-linux-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross
ARCH=powerpc
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All errors (new ones prefixed by >>, old ones prefixed by <<):
arch/powerpc/kernel/fadump.c: In function 'crash_fadump':
>> arch/powerpc/kernel/fadump.c:700:15: error: 'cpus_in_crash' undeclared
>> (first use in this function)
700 | atomic_inc(_in_crash);
| ^
arch/powerpc/kernel/fadump.c:700:15: note: each undeclared identifier is
reported only once for each function it appears in
arch/powerpc/kernel/fadump.c: In function 'fadump_update_elfcore_header':
arch/powerpc/kernel/fadump.c:755:17: warning: variable 'elf' set but not used
[-Wunused-but-set-variable]
755 | struct elfhdr *elf;
| ^~~
arch/powerpc/kernel/fadump.c: At top level:
arch/powerpc/kernel/fadump.c:1706:22: warning: no previous prototype for
'arch_reserved_kernel_pages' [-Wmissing-prototypes]
1706 | unsigned long __init arch_reserved_kernel_pages(void)
| ^~
vim +/cpus_in_crash +700 arch/powerpc/kernel/fadump.c
678
679 void crash_fadump(struct pt_regs *regs, const char *str)
680 {
681 unsigned int msecs;
682 struct fadump_crash_info_header *fdh = NULL;
683 int old_cpu, this_cpu;
684 unsigned int ncpus = num_online_cpus() - 1; /* Do not include
first CPU */
685
686 if (!should_fadump_crash())
687 return;
688
689 /*
690 * old_cpu == -1 means this is the first CPU which has come
here,
691 * go ahead and trigger fadump.
692 *
693 * old_cpu != -1 means some other CPU has already on it's way
694 * to trigger fadump, just keep looping here.
695 */
696 this_cpu = smp_processor_id();
697 old_cpu = cmpxchg(_cpu, -1, this_cpu);
698
699 if (old_cpu != -1) {
> 700 atomic_inc(_in_crash);
701
702 /*
703 * We can't loop here indefinitely. Wait as long as
fadump
704 * is in force. If we race with fadump un-registration
this
705 * loop will break and then we go down to normal panic
path
706 * and reboot. If fadump is in force the first crashing
707 * cpu will definitely trigger fadump.
708 */
709 while (fw_dump.dump_registered)
710 cpu_relax();
711 return;
712 }
713
714 fdh = __va(fw_dump.fadumphdr_addr);
715 fdh->crashing_cpu = crashing_cpu;
716 crash_save_vmcoreinfo();
717
718 if (regs)
719 fdh->regs = *regs;
720 else
721 ppc_save_regs(>regs);
722
723 fdh->online_mask = *cpu_online_mask;
724
725 /*
726 * If we came in via system reset, wait a while for the
secondary
727 * CPUs to enter.
728 */
729 if (TRAP(&(fdh->regs)) == 0x100) {
730 msecs = CRASH_TIMEOUT;
731 while ((atomic_read(_in_crash) < ncpus) &&
(--msecs > 0))
732 mdelay(1);
733 }
734
735 fw_dump.ops->fadump_trigger(fdh, str);
736 }
737
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
.config.gz
Description: application/gzip
Re: arch/powerpc/kexec/core.c:246:29: sparse: sparse: incorrect type in assignment (different base types)
Le 11/06/2020 à 18:01, kernel test robot a écrit :
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: b29482fde649c72441d5478a4ea2c52c56d97a5e
commit: 793b08e2efff3ec020c5c5861d00ed394fcdd488 powerpc/kexec: Move kexec
files into a dedicated subdir.
date: 7 months ago
config: powerpc-randconfig-s032-20200611 (attached as .config)
compiler: powerpc-linux-gcc (GCC) 9.3.0
reproduce:
# apt-get install sparse
# sparse version: v0.6.1-250-g42323db3-dirty
git checkout 793b08e2efff3ec020c5c5861d00ed394fcdd488
# save the attached .config to linux build tree
make W=1 C=1 ARCH=powerpc CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__'
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
That's the second time the robot reports sparse errors on that commit,
but the only thing I did is move code, that commit didn't add any code,
so I don't know what I should do about it.
Christophe
sparse warnings: (new ones prefixed by >>)
arch/powerpc/kexec/core.c:246:29: sparse: sparse: incorrect type in assignment
(different base types) @@ expected unsigned long long static [addressable]
[toplevel] [usertype] crashk_base @@ got restricted __be32 [usertype] @@
arch/powerpc/kexec/core.c:246:29: sparse: expected unsigned long long
static [addressable] [toplevel] [usertype] crashk_base
arch/powerpc/kexec/core.c:246:29: sparse: got restricted __be32
[usertype]
arch/powerpc/kexec/core.c:248:29: sparse: sparse: incorrect type in assignment
(different base types) @@ expected unsigned long long static [addressable]
[toplevel] [usertype] crashk_size @@ got restricted __be32 [usertype] @@
arch/powerpc/kexec/core.c:248:29: sparse: expected unsigned long long
static [addressable] [toplevel] [usertype] crashk_size
arch/powerpc/kexec/core.c:248:29: sparse: got restricted __be32
[usertype]
arch/powerpc/kexec/core.c:256:19: sparse: sparse: incorrect type in
assignment (different base types) @@ expected unsigned long long static
[addressable] [toplevel] mem_limit @@ got restricted __be32 [usertype] @@
arch/powerpc/kexec/core.c:256:19: sparse: expected unsigned long long
static [addressable] [toplevel] mem_limit
arch/powerpc/kexec/core.c:256:19: sparse: got restricted __be32
[usertype]
arch/powerpc/kexec/core.c:272:20: sparse: sparse: incorrect type in assignment
(different base types) @@ expected unsigned long long static [addressable]
[toplevel] [usertype] kernel_end @@ got restricted __be32 [usertype] @@
arch/powerpc/kexec/core.c:272:20: sparse: expected unsigned long long
static [addressable] [toplevel] [usertype] kernel_end
arch/powerpc/kexec/core.c:272:20: sparse: got restricted __be32
[usertype]
vim +246 arch/powerpc/kexec/core.c
ea961a828fe725 arch/powerpc/kernel/machine_kexec.c Anton Blanchard
2014-01-22 235
6f29c3298b1821 arch/powerpc/kernel/machine_kexec.c Dale Farnsworth
2008-12-17 236 static void __init export_crashk_values(struct device_node
*node)
6f29c3298b1821 arch/powerpc/kernel/machine_kexec.c Dale Farnsworth
2008-12-17 237 {
6f29c3298b1821 arch/powerpc/kernel/machine_kexec.c Dale Farnsworth
2008-12-17 238 /* There might be existing crash kernel properties, but
we can't
6f29c3298b1821 arch/powerpc/kernel/machine_kexec.c Dale Farnsworth
2008-12-17 239 * be sure what's in them, so remove them. */
925e2d1ded80fc arch/powerpc/kernel/machine_kexec.c Suraj Jitindar Singh
2016-04-28 240 of_remove_property(node, of_find_property(node,
925e2d1ded80fc arch/powerpc/kernel/machine_kexec.c Suraj Jitindar Singh 2016-04-28 241
"linux,crashkernel-base", NULL));
925e2d1ded80fc arch/powerpc/kernel/machine_kexec.c Suraj Jitindar Singh
2016-04-28 242 of_remove_property(node, of_find_property(node,
925e2d1ded80fc arch/powerpc/kernel/machine_kexec.c Suraj Jitindar Singh 2016-04-28 243
"linux,crashkernel-size", NULL));
6f29c3298b1821 arch/powerpc/kernel/machine_kexec.c Dale Farnsworth
2008-12-17 244
6f29c3298b1821 arch/powerpc/kernel/machine_kexec.c Dale Farnsworth
2008-12-17 245 if (crashk_res.start != 0) {
ea961a828fe725 arch/powerpc/kernel/machine_kexec.c Anton Blanchard
2014-01-22 @246 crashk_base = cpu_to_be_ulong(crashk_res.start),
79d1c712958f94 arch/powerpc/kernel/machine_kexec.c Nathan Fontenot 2012-10-02
247 of_add_property(node, _base_prop);
ea961a828fe725 arch/powerpc/kernel/machine_kexec.c Anton Blanchard 2014-01-22
@248 crashk_size = cpu_to_be_ulong(resource_size(_res));
79d1c712958f94 arch/powerpc/kernel/machine_kexec.c Nathan Fontenot 2012-10-02
249 of_add_property(node, _size_prop);
6f29c329
Re: [Linaro-mm-sig] [PATCH 04/18] dma-fence: prime lockdep annotations
On Fri, Jun 12, 2020 at 1:35 AM Felix Kuehling wrote: > > Am 2020-06-11 um 10:15 a.m. schrieb Jason Gunthorpe: > > On Thu, Jun 11, 2020 at 10:34:30AM +0200, Daniel Vetter wrote: > >>> I still have my doubts about allowing fence waiting from within shrinkers. > >>> IMO ideally they should use a trywait approach, in order to allow memory > >>> allocation during command submission for drivers that > >>> publish fences before command submission. (Since early reservation object > >>> release requires that). > >> Yeah it is a bit annoying, e.g. for drm/scheduler I think we'll end up > >> with a mempool to make sure it can handle it's allocations. > >> > >>> But since drivers are already waiting from within shrinkers and I take > >>> your > >>> word for HMM requiring this, > >> Yeah the big trouble is HMM and mmu notifiers. That's the really awkward > >> one, the shrinker one is a lot less established. > > I really question if HW that needs something like DMA fence should > > even be using mmu notifiers - the best use is HW that can fence the > > DMA directly without having to get involved with some command stream > > processing. > > > > Or at the very least it should not be a generic DMA fence but a > > narrowed completion tied only into the same GPU driver's command > > completion processing which should be able to progress without > > blocking. > > > > The intent of notifiers was never to endlessly block while vast > > amounts of SW does work. > > > > Going around and switching everything in a GPU to GFP_ATOMIC seems > > like bad idea. > > > >> I've pinged a bunch of armsoc gpu driver people and ask them how much this > >> hurts, so that we have a clear answer. On x86 I don't think we have much > >> of a choice on this, with userptr in amd and i915 and hmm work in nouveau > >> (but nouveau I think doesn't use dma_fence in there). > > Soon nouveau will get company. We're working on a recoverable page fault > implementation for HMM in amdgpu where we'll need to update page tables > using the GPUs SDMA engine and wait for corresponding fences in MMU > notifiers. Well amdgpu already has dma_fence waits in the hmm callbacks, so nothing new. But since you start using these in amdkfd ... perfect opportunity to annotate the amdkfd paths for fence signalling critical sections? Especially the preempt-ctx fence should be an interesting case to annotate and see whether lockdep finds anything. Not sure what else there is. -Daniel > > Regards, > Felix > > > > Right, nor will RDMA ODP. > > > > Jason > > ___ > > amd-gfx mailing list > > amd-...@lists.freedesktop.org > > https://lists.freedesktop.org/mailman/listinfo/amd-gfx > ___ > dri-devel mailing list > dri-de...@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
drivers/net/ethernet/brocade/bna/bfa_ioc.c:1905:24: sparse: sparse: incorrect type in argument 1 (different base types)
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: b791d1bdf9212d944d749a5c7ff6febdba241771 commit: 05933aac7b11911955de307a329dc2a7a14b7bd0 ia64: remove now unused machvec indirections date: 10 months ago config: ia64-randconfig-s031-20200612 (attached as .config) compiler: ia64-linux-gcc (GCC) 9.3.0 reproduce: # apt-get install sparse # sparse version: v0.6.1-250-g42323db3-dirty git checkout 05933aac7b11911955de307a329dc2a7a14b7bd0 # save the attached .config to linux build tree make W=1 C=1 ARCH=ia64 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot sparse warnings: (new ones prefixed by >>) ./arch/ia64/include/generated/uapi/asm/unistd_64.h:348:39: sparse: sparse: no newline at end of file drivers/net/ethernet/brocade/bna/bfa_ioc.c:1925:28: sparse: sparse: incorrect type in assignment (different base types) @@ expected unsigned short [assigned] [usertype] clscode @@ got restricted __be16 [usertype] @@ drivers/net/ethernet/brocade/bna/bfa_ioc.c:1925:28: sparse: expected unsigned short [assigned] [usertype] clscode drivers/net/ethernet/brocade/bna/bfa_ioc.c:1925:28: sparse: got restricted __be16 [usertype] drivers/net/ethernet/brocade/bna/bfa_ioc.c:1926:25: sparse: sparse: incorrect type in assignment (different base types) @@ expected unsigned short [assigned] [usertype] rsvd @@ got restricted __be16 [usertype] @@ drivers/net/ethernet/brocade/bna/bfa_ioc.c:1926:25: sparse: expected unsigned short [assigned] [usertype] rsvd drivers/net/ethernet/brocade/bna/bfa_ioc.c:1926:25: sparse: got restricted __be16 [usertype] drivers/net/ethernet/brocade/bna/bfa_ioc.c:1928:29: sparse: sparse: cast to restricted __be32 drivers/net/ethernet/brocade/bna/bfa_ioc.c:1928:29: sparse: sparse: cast to restricted __be32 drivers/net/ethernet/brocade/bna/bfa_ioc.c:1928:29: sparse: sparse: cast to restricted __be32 drivers/net/ethernet/brocade/bna/bfa_ioc.c:1928:29: sparse: sparse: cast to restricted __be32 drivers/net/ethernet/brocade/bna/bfa_ioc.c:1928:29: sparse: sparse: cast to restricted __be32 drivers/net/ethernet/brocade/bna/bfa_ioc.c:1928:29: sparse: sparse: cast to restricted __be32 drivers/net/ethernet/brocade/bna/bfa_ioc.c:1939:29: sparse: sparse: incorrect type in assignment (different base types) @@ expected unsigned short [assigned] [usertype] clscode @@ got restricted __be16 [usertype] @@ drivers/net/ethernet/brocade/bna/bfa_ioc.c:1939:29: sparse: expected unsigned short [assigned] [usertype] clscode drivers/net/ethernet/brocade/bna/bfa_ioc.c:1939:29: sparse: got restricted __be16 [usertype] drivers/net/ethernet/brocade/bna/bfa_ioc.c:1940:26: sparse: sparse: incorrect type in assignment (different base types) @@ expected unsigned short [assigned] [usertype] rsvd @@ got restricted __be16 [usertype] @@ drivers/net/ethernet/brocade/bna/bfa_ioc.c:1940:26: sparse: expected unsigned short [assigned] [usertype] rsvd drivers/net/ethernet/brocade/bna/bfa_ioc.c:1940:26: sparse: got restricted __be16 [usertype] drivers/net/ethernet/brocade/bna/bfa_ioc.c:1942:30: sparse: sparse: cast to restricted __be32 drivers/net/ethernet/brocade/bna/bfa_ioc.c:1942:30: sparse: sparse: cast to restricted __be32 drivers/net/ethernet/brocade/bna/bfa_ioc.c:1942:30: sparse: sparse: cast to restricted __be32 drivers/net/ethernet/brocade/bna/bfa_ioc.c:1942:30: sparse: sparse: cast to restricted __be32 drivers/net/ethernet/brocade/bna/bfa_ioc.c:1942:30: sparse: sparse: cast to restricted __be32 drivers/net/ethernet/brocade/bna/bfa_ioc.c:1942:30: sparse: sparse: cast to restricted __be32 include/asm-generic/io.h:179:15: sparse: sparse: cast to restricted __le32 >> drivers/net/ethernet/brocade/bna/bfa_ioc.c:1905:24: sparse: sparse: >> incorrect type in argument 1 (different base types) @@ expected unsigned >> int [usertype] value @@ got restricted __le32 [usertype] @@ >> drivers/net/ethernet/brocade/bna/bfa_ioc.c:1905:24: sparse: expected >> unsigned int [usertype] value drivers/net/ethernet/brocade/bna/bfa_ioc.c:1905:24: sparse: got restricted __le32 [usertype] drivers/net/ethernet/brocade/bna/bfa_ioc.c:2107:31: sparse: sparse: cast to restricted __be32 drivers/net/ethernet/brocade/bna/bfa_ioc.c:2107:31: sparse: sparse: cast to restricted __be32 drivers/net/ethernet/brocade/bna/bfa_ioc.c:2107:31: sparse: sparse: cast to restricted __be32 drivers/net/ethernet/brocade/bna/bfa_ioc.c:2107:31: sparse: sparse: cast to restricted __be32 drivers/net/ethernet/brocade/bna/bfa_ioc.c:2107:31: sparse: sparse: cast to restricted __be32 drivers/net/ethernet/brocade/bna/bfa_ioc.c:2107:31: sparse: sparse: cast to restricted __be32
Re: Regression bisected to f2f84b05e02b (bug: consolidate warn_slowpath_fmt() usage)
On Thu, Jun 11, 2020 at 09:23:52PM -0700, Matt Turner wrote: > Since I noticed earlier that using maxcpus=1 on a 2-CPU system > prevented the system from hanging, I tried disabling CONFIG_SMP on my > 1-CPU system as well. In doing so, I discovered that the RCU torture > module (RCU_TORTURE_TEST) triggers some null pointer dereferences on > Alpha when CONFIG_SMP is set, but works successfully when CONFIG_SMP > is unset. > > That seems likely to be a symptom of the same underlying problem that > started this thread, don't you think? If so, I'll focus my attention > on that. I wonder if that is related to user space segfaults we are now seeing on SMP systems but not UP systems while building Alpha debian-ports. It's happening in the test-suites of builds of certain software (such as autogen and guile) but they always build successfully with the test suite passing on a UP system. When investigating I seem to recall it was a NULL (or near NULL) pointer dereference but couldn't make any sense of how it might have got into such an obviously wrong state. Cheers, Michael.
[PATCH] drm/msm: fix potential memleak issue
Function msm_gpu_crashstate_capture maybe called for several
times, and then the state->bos is a potential memleak. Also
the state->pos maybe alloc failed, but now without any handle.
This change is to fix some potential memleak and add error
handle when alloc failed.
Signed-off-by: Bernard Zhao
---
drivers/gpu/drm/msm/msm_gpu.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/msm/msm_gpu.c b/drivers/gpu/drm/msm/msm_gpu.c
index a22d30622306..d67a9933f3ce 100644
--- a/drivers/gpu/drm/msm/msm_gpu.c
+++ b/drivers/gpu/drm/msm/msm_gpu.c
@@ -366,8 +366,11 @@ static void msm_gpu_crashstate_capture(struct msm_gpu *gpu,
if (!should_dump(submit, submit->cmd[i].idx))
nr++;
+ kfree(state->bos);
state->bos = kcalloc(nr,
sizeof(struct msm_gpu_state_bo), GFP_KERNEL);
+ if (!state->bos)
+ return;
for (i = 0; i < submit->nr_bos; i++) {
if (should_dump(submit, i)) {
--
2.17.1
Re: Regression bisected to f2f84b05e02b (bug: consolidate warn_slowpath_fmt() usage)
On Fri, Jun 12, 2020 at 04:47:57PM +1200, Michael Cree wrote: > On Thu, Jun 11, 2020 at 09:23:52PM -0700, Matt Turner wrote: > > Since I noticed earlier that using maxcpus=1 on a 2-CPU system > > prevented the system from hanging, I tried disabling CONFIG_SMP on my > > 1-CPU system as well. In doing so, I discovered that the RCU torture > > module (RCU_TORTURE_TEST) triggers some null pointer dereferences on > > Alpha when CONFIG_SMP is set, but works successfully when CONFIG_SMP > > is unset. > > > > That seems likely to be a symptom of the same underlying problem that > > started this thread, don't you think? If so, I'll focus my attention > > on that. > > I wonder if that is related to user space segfaults we are now seeing > on SMP systems but not UP systems while building Alpha debian-ports. > It's happening in the test-suites of builds of certain software > (such as autogen and guile) but they always build successfully with > the test suite passing on a UP system. > > When investigating I seem to recall it was a NULL (or near NULL) > pointer dereference but couldn't make any sense of how it might > have got into such an obviously wrong state. By some miracle, I have avoided any experience with RCU bugs. ;) If the RCU_TORTURE_TEST Oopses or the segfaults are repeatable and don't go away with the WARN patch reverted, then perhaps it might be used to bisect to something closer to the root cause? Given the similarity to the SMP vs UP stuff and the RCU tests, I'd agree that does seem like the best path to investigate. -- Kees Cook
Re: [RFC PATCH v2 3/3] ASoC: fsl_asrc_dma: Reuse the dma channel if available in Back-End
On Fri, Jun 12, 2020 at 10:17:08AM +0800, Shengjiu Wang wrote:
> > > diff --git a/sound/soc/fsl/fsl_asrc_common.h
> > > b/sound/soc/fsl/fsl_asrc_common.h
> > > + * @req_dma_chan_dev_to_dev: flag for release dev_to_dev chan
> >
> > Since we only have dma_request call for back-end only:
> > + * @req_dma_chan: flag to release back-end dma chan
>
> I prefer to use the description "flag to release dev_to_dev chan"
> because we won't release the dma chan of the back-end. if the chan
> is from the back-end, it is owned by the back-end component.
TBH, it just looks too long. But I wouldn't have problem if you
insist so.
> > > @@ -273,19 +299,21 @@ static int fsl_asrc_dma_hw_params(struct
> > > snd_soc_component *component,
> > > static int fsl_asrc_dma_hw_free(struct snd_soc_component *component,
> > > struct snd_pcm_substream *substream)
> > > {
> > > + bool tx = substream->stream == SNDRV_PCM_STREAM_PLAYBACK;
> > > struct snd_pcm_runtime *runtime = substream->runtime;
> > > struct fsl_asrc_pair *pair = runtime->private_data;
> > > + u8 dir = tx ? OUT : IN;
> > >
> > > snd_pcm_set_runtime_buffer(substream, NULL);
> > >
> > > - if (pair->dma_chan[IN])
> > > - dma_release_channel(pair->dma_chan[IN]);
> > > + if (pair->dma_chan[!dir])
> > > + dma_release_channel(pair->dma_chan[!dir]);
> > >
> > > - if (pair->dma_chan[OUT])
> > > - dma_release_channel(pair->dma_chan[OUT]);
> > > + if (pair->dma_chan[dir] && pair->req_dma_chan_dev_to_dev)
> > > + dma_release_channel(pair->dma_chan[dir]);
> >
> > Why we only apply this to one direction?
>
> if the chan is from the back-end, it is owned by the back-end
> component, so it should be released by the back-end component,
> not here. That's why I added the flag "req_dma_chan".
Ah...I forgot the IN and OUT is for front-end and back-end. The
naming isn't very good indeed. Probably we should add a line of
comments somewhere as a reminder.
Thanks
[RFC PATCH] watchdog: f71808e_wdt: fintek_variants[] can be static
Signed-off-by: kernel test robot
---
f71808e_wdt.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/watchdog/f71808e_wdt.c b/drivers/watchdog/f71808e_wdt.c
index c866d05e8788b..849620041c0ef 100644
--- a/drivers/watchdog/f71808e_wdt.c
+++ b/drivers/watchdog/f71808e_wdt.c
@@ -484,7 +484,7 @@ static void f81866_pinconf(struct fintek_wdog_data *wd)
superio_clear_bit(wd->sioaddr, SIO_F81866_REG_GPIO1, 5);
}
-struct fintek_variant fintek_variants[] = {
+static struct fintek_variant fintek_variants[] = {
{ SIO_F71808_ID, "f71808fg", f71808fg_pinconf },
{ SIO_F71862_ID, "f71862fg", f71862fg_pinconf },
{ SIO_F71868_ID, "f71868", f71868_pinconf },
Re: [PATCH v1 8/8] watchdog: f71808e_wdt: rename variant-independent identifiers appropriately
Hi Ahmad, Thank you for the patch! Perhaps something to improve: [auto build test WARNING on hwmon/hwmon-next] [also build test WARNING on linus/master linux/master v5.7 next-20200611] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system. BTW, we also suggest to use '--base' option to specify the base tree in git format-patch, please see https://stackoverflow.com/a/37406982] url: https://github.com/0day-ci/linux/commits/Ahmad-Fatoum/watchdog-f71808e_wdt-migrate-to-kernel/20200612-093801 base: https://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging.git hwmon-next config: i386-randconfig-s001-20200612 (attached as .config) compiler: gcc-9 (Debian 9.3.0-13) 9.3.0 reproduce: # apt-get install sparse # sparse version: v0.6.1-250-g42323db3-dirty # save the attached .config to linux build tree make W=1 C=1 ARCH=i386 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot sparse warnings: (new ones prefixed by >>) >> drivers/watchdog/f71808e_wdt.c:487:23: sparse: sparse: symbol >> 'fintek_variants' was not declared. Should it be static? Please review and possibly fold the followup patch. --- 0-DAY CI Kernel Test Service, Intel Corporation https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org .config.gz Description: application/gzip
[PATCH] ACPI: sysfs: Fix pm_profile_attr type
When running a kernel with Clang's Control Flow Integrity implemented,
there is a violation that happens when accessing
/sys/firmware/acpi/pm_profile:
$ cat /sys/firmware/acpi/pm_profile
0
$ dmesg
...
[ 17.352564] [ cut here ]
[ 17.352568] CFI failure (target: acpi_show_profile+0x0/0x8):
[ 17.352572] WARNING: CPU: 3 PID: 497 at kernel/cfi.c:29
__cfi_check_fail+0x33/0x40
[ 17.352573] Modules linked in:
[ 17.352575] CPU: 3 PID: 497 Comm: cat Tainted: GW
5.7.0-microsoft-standard+ #1
[ 17.352576] RIP: 0010:__cfi_check_fail+0x33/0x40
[ 17.352577] Code: 48 c7 c7 50 b3 85 84 48 c7 c6 50 0a 4e 84 e8 a4 d8 60 00
85 c0 75 02 5b c3 48 c7 c7 dc 5e 49 84 48 89 de 31 c0 e8 7d 06 eb ff <0f> 0b 5b
c3 00 00 cc cc 00 00 cc cc 00 85 f6 74 25 41 b9 ea ff ff
[ 17.352577] RSP: 0018:aa6dc3c53d30 EFLAGS: 00010246
[ 17.352578] RAX: 331267e0c06cee00 RBX: 83d85890 RCX: 8483a6f8
[ 17.352579] RDX: 9cceabbb37c0 RSI: 0082 RDI: 84bb9e1c
[ 17.352579] RBP: 845b2bc8 R08: 0001 R09: 9cceabbba200
[ 17.352579] R10: 019d R11: R12: 9cc947766f00
[ 17.352580] R13: 83d6bd50 R14: 9ccc6fa8 R15: 845bd328
[ 17.352582] FS: 7fdbc8d13580() GS:9cce91ac()
knlGS:
[ 17.352582] CS: 0010 DS: ES: CR0: 80050033
[ 17.352583] CR2: 7fdbc858e000 CR3: 0005174d CR4: 00340ea0
[ 17.352584] Call Trace:
[ 17.352586] ? rev_id_show+0x8/0x8
[ 17.352587] ? __cfi_check+0x45bac/0x4b640
[ 17.352589] ? kobj_attr_show+0x73/0x80
[ 17.352590] ? sysfs_kf_seq_show+0xc1/0x140
[ 17.352592] ? ext4_seq_options_show.cfi_jt+0x8/0x8
[ 17.352593] ? seq_read+0x180/0x600
[ 17.352595] ? sysfs_create_file_ns.cfi_jt+0x10/0x10
[ 17.352596] ? tlbflush_read_file+0x8/0x8
[ 17.352597] ? __vfs_read+0x6b/0x220
[ 17.352598] ? handle_mm_fault+0xa23/0x11b0
[ 17.352599] ? vfs_read+0xa2/0x130
[ 17.352599] ? ksys_read+0x6a/0xd0
[ 17.352601] ? __do_sys_getpgrp+0x8/0x8
[ 17.352602] ? do_syscall_64+0x72/0x120
[ 17.352603] ? entry_SYSCALL_64_after_hwframe+0x44/0xa9
[ 17.352604] ---[ end trace 7b1fa81dc897e419 ]---
When /sys/firmware/acpi/pm_profile is read, sysfs_kf_seq_show is called,
which in turn calls kobj_attr_show, which gets the ->show callback
member by calling container_of on attr (casting it to struct
kobj_attribute) then calls it.
There is a CFI violation because pm_profile_attr is of type
struct device_attribute but kobj_attr_show calls ->show expecting it
to be from struct kobj_attribute. CFI checking ensures that function
pointer types match when doing indirect calls. Fix pm_profile_attr to
be defined in terms of kobj_attribute so there is no violation or
mismatch.
Fixes: 362b646062b2 ("ACPI: Export FADT pm_profile integer value to userspace")
Link: https://github.com/ClangBuiltLinux/linux/issues/1051
Reported-by: yuu ichii
Signed-off-by: Nathan Chancellor
---
drivers/acpi/sysfs.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/acpi/sysfs.c b/drivers/acpi/sysfs.c
index 3a89909b50a6..76c668c05fa0 100644
--- a/drivers/acpi/sysfs.c
+++ b/drivers/acpi/sysfs.c
@@ -938,13 +938,13 @@ static void __exit interrupt_stats_exit(void)
}
static ssize_t
-acpi_show_profile(struct device *dev, struct device_attribute *attr,
+acpi_show_profile(struct kobject *kobj, struct kobj_attribute *attr,
char *buf)
{
return sprintf(buf, "%d\n", acpi_gbl_FADT.preferred_profile);
}
-static const struct device_attribute pm_profile_attr =
+static const struct kobj_attribute pm_profile_attr =
__ATTR(pm_profile, S_IRUGO, acpi_show_profile, NULL);
static ssize_t hotplug_enabled_show(struct kobject *kobj,
base-commit: b791d1bdf9212d944d749a5c7ff6febdba241771
--
2.27.0
[PATCH 2/2] gpiolib: cdev: fix file comment
Replace file comment carried over from gpiolib.c with one more appropriate for gpiolib-cdev.c. Signed-off-by: Kent Gibson --- drivers/gpio/gpiolib-cdev.c | 7 +++ 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/drivers/gpio/gpiolib-cdev.c b/drivers/gpio/gpiolib-cdev.c index 58011ba88a1d..17d5541d76a0 100644 --- a/drivers/gpio/gpiolib-cdev.c +++ b/drivers/gpio/gpiolib-cdev.c @@ -25,11 +25,10 @@ #include "gpiolib.h" #include "gpiolib-cdev.h" -/* Implementation infrastructure for GPIO interfaces. +/* Character device interface to GPIO. * - * The GPIO programming interface allows for inlining speed-critical - * get/set operations for common cases, so that access to SOC-integrated - * GPIOs can sometimes cost only an instruction or two per bit. + * The GPIO character device, /dev/gpiochipN, provides userspace an + * interface to gpiolib GPIOs via ioctl()s. */ /* -- 2.27.0
[PATCH 1/2] gpiolib: cdev: fix -Wmissing-prototypes warnings
Fix -Wmissing-prototypes warnings by including module's header. Fixes: f6d984418ffd (gpiolib: split character device into gpiolib-cdev) Reported-by: kernel test robot Signed-off-by: Kent Gibson --- drivers/gpio/gpiolib-cdev.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpio/gpiolib-cdev.c b/drivers/gpio/gpiolib-cdev.c index 971470bdc9c9..58011ba88a1d 100644 --- a/drivers/gpio/gpiolib-cdev.c +++ b/drivers/gpio/gpiolib-cdev.c @@ -23,6 +23,7 @@ #include "gpiolib.h" +#include "gpiolib-cdev.h" /* Implementation infrastructure for GPIO interfaces. * -- 2.27.0
[PATCH 0/2] gpiolib: cdev: fixes for split from gpiolib.c
A couple of minor fixes for the recent split from gpiolib.c: The first fixes a couple of W=1 build warnings by including the module's own header. The second fixes the file comment. This was in v3 of the split patch, but v2 got merged... Kent Gibson (2): gpiolib: cdev: fix -Wmissing-prototypes warnings gpiolib: cdev: fix file comment drivers/gpio/gpiolib-cdev.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) base-commit: f6d984418ffde19322fd149105200224ac2bc089 -- 2.27.0
Re: [PATCH] extend IMA boot_aggregate with kernel measurements
Hi Maurizio,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on integrity/next-integrity]
[also build test WARNING on next-20200611]
[cannot apply to v5.7]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we also suggest to use '--base' option to specify the
base tree in git format-patch, please see https://stackoverflow.com/a/37406982]
url:
https://github.com/0day-ci/linux/commits/Maurizio-Drocco/extend-IMA-boot_aggregate-with-kernel-measurements/20200612-091504
base:
https://git.kernel.org/pub/scm/linux/kernel/git/zohar/linux-integrity.git
next-integrity
config: x86_64-allyesconfig (attached as .config)
compiler: clang version 11.0.0 (https://github.com/llvm/llvm-project
3b43f006294971b8049d4807110032169780e5b8)
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# install x86_64 cross compiling tool for clang build
# apt-get install binutils-x86-64-linux-gnu
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=x86_64
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All warnings (new ones prefixed by >>, old ones prefixed by <<):
>> security/integrity/ima/ima_crypto.c:838:35: warning: size argument in
>> 'memcmp' call is a comparison [-Wmemsize-comparison]
crypto_shash_digestsize(tfm) != 0))
~^~~~
security/integrity/ima/ima_crypto.c:837:7: note: did you mean to compare the
result of 'memcmp' instead?
if (memcmp(d.digest, d0.digest,
^
security/integrity/ima/ima_crypto.c:838:6: note: explicitly cast the argument
to size_t to silence this warning
crypto_shash_digestsize(tfm) != 0))
^
(size_t)()
1 warning generated.
vim +/memcmp +838 security/integrity/ima/ima_crypto.c
797
798 /*
799 * The boot_aggregate is a cumulative hash over TPM registers 0 - 7.
With
800 * TPM 1.2 the boot_aggregate was based on reading the SHA1 PCRs, but
with
801 * TPM 2.0 hash agility, TPM chips could support multiple TPM PCR banks,
802 * allowing firmware to configure and enable different banks.
803 *
804 * Knowing which TPM bank is read to calculate the boot_aggregate digest
805 * needs to be conveyed to a verifier. For this reason, use the same
806 * hash algorithm for reading the TPM PCRs as for calculating the boot
807 * aggregate digest as stored in the measurement list.
808 */
809 static int ima_calc_boot_aggregate_tfm(char *digest, u16 alg_id,
810 struct crypto_shash *tfm)
811 {
812 struct tpm_digest d = { .alg_id = alg_id, .digest = {0} }, d0 =
d;
813 int rc;
814 u32 i;
815 SHASH_DESC_ON_STACK(shash, tfm);
816
817 shash->tfm = tfm;
818
819 pr_devel("calculating the boot-aggregate based on TPM bank:
%04x\n",
820 d.alg_id);
821
822 rc = crypto_shash_init(shash);
823 if (rc != 0)
824 return rc;
825
826 /* cumulative sha1 over tpm registers 0-7 */
827 for (i = TPM_PCR0; i < TPM_PCR8; i++) {
828 ima_pcrread(i, );
829 /* now accumulate with current aggregate */
830 rc = crypto_shash_update(shash, d.digest,
831 crypto_shash_digestsize(tfm));
832 }
833 /* extend cumulative sha1 over tpm registers 8-9 */
834 for (i = TPM_PCR8; i < TPM_PCR10; i++) {
835 ima_pcrread(i, );
836 /* if not zero, accumulate with current aggregate */
837 if (memcmp(d.digest, d0.digest,
> 838 crypto_shash_digestsize(tfm) !=
> 0))
839 rc = crypto_shash_update(shash, d.digest,
840 crypto_shash_digestsize(tfm));
841 }
842 if (!rc)
843 crypto_shash_final(shash, digest);
844 return rc;
845 }
846
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
.config.gz
Description: application/gzip
Re: [PATCH 4/6] spi: altera: use regmap instead of direct mmio register access
On Thu, Jun 11, 2020 at 12:02:11PM +0100, Mark Brown wrote:
> On Thu, Jun 11, 2020 at 11:25:09AM +0800, Xu Yilun wrote:
>
> > + if (pdata && pdata->use_parent_regmap) {
> > + hw->regmap = dev_get_regmap(pdev->dev.parent, NULL);
> > + if (!hw->regmap) {
> > + dev_err(>dev, "get regmap failed\n");
> > + goto exit;
> > + }
> > + hw->base = pdata->regoff;
>
> This seems very confused - there's some abstraction problem here. This
> looks like the driver should know about whatever is causing it to use
> the parent regmap, it shouldn't just be "use the parent regmap" directly
> since that is too much of an implementation detail. This new feature
Our usecase is that, we have the PCIE card which integrates this
spi-altera soft IP. So It seems reasonable we reuse this driver. But the
IP registers are not directly accessed by MMIO. It is accessed via an
indirect access interfaces, SW need to operate on the indirect access
interfaces to RW the spi-altera registers. like the following:
+--+ ++ ++
| PCIE |---| indirect |---| spi-altera |
+--+ | access | ++
| interfaces |
++
| SPI params |
++
So we think of creating regmap to abstract the actually register accessing
detail. The parent device driver creates the regmap of indirect access,
and it creates the spi-altera platform device as child. Spi-altera
driver could just get the regmap from parent, don't have to care about
the indirect access detail.
It seems your concern is how to gracefully let spi-altera driver get the
regmap. or not using it. Since our platform doesn't enable device tree
support, seems the only way to talk to platform device is the
platform_data.
Do you have any suggestion on that?
I think the driver may need to figure out the role of the device in
system, whether it is a subdev of other device (like MFD? Many mfd subdev
driver will get parent regmap by default), or it is an independent mmio
device. But I'm not sure how to do it in right way.
> also seems like a separate change which should be in a separate patch,
> the changelog only talked about converting to use regmap which I'd have
> expected to be a straight 1:1 replacement of non-regmap stuff with
> regmap stuff.
Understood. I should make a patch to do 1:1 replacement of regmap first,
then a second patch to handle the parent regmap.
Re: [PATCH stable 4.9 00/21] Unbreak 32-bit DVB applications on 64-bit kernels
On 6/5/2020 9:24 AM, Florian Fainelli wrote: > Hi all, > > This long patch series was motivated by backporting Jaedon's changes > which add a proper ioctl compatibility layer for 32-bit applications > running on 64-bit kernels. We have a number of Android TV-based products > currently running on the 4.9 kernel and this was broken for them. > > Thanks to Robert McConnell for identifying and providing the patches in > their initial format. > > In order for Jaedon's patches to apply cleanly a number of changes were > applied to support those changes. If you deem the patch series too big > please let me know. Mauro, can you review this? I would prefer not to maintain those patches in our downstream 4.9 kernel as there are quite a few of them, and this is likely beneficial to other people. Thank you! > > Thanks > > Colin Ian King (2): > media: dvb_frontend: ensure that inital front end status initialized > media: dvb_frontend: initialize variable s with FE_NONE instead of 0 > > Jaedon Shin (3): > media: dvb_frontend: Add unlocked_ioctl in dvb_frontend.c > media: dvb_frontend: Add compat_ioctl callback > media: dvb_frontend: Add commands implementation for compat ioct > > Katsuhiro Suzuki (1): > media: dvb_frontend: fix wrong cast in compat_ioctl > > Mauro Carvalho Chehab (14): > media: dvb/frontend.h: move out a private internal structure > media: dvb/frontend.h: document the uAPI file > media: dvb_frontend: get rid of get_property() callback > media: stv0288: get rid of set_property boilerplate > media: stv6110: get rid of a srate dead code > media: friio-fe: get rid of set_property() > media: dvb_frontend: get rid of set_property() callback > media: dvb_frontend: cleanup dvb_frontend_ioctl_properties() > media: dvb_frontend: cleanup ioctl handling logic > media: dvb_frontend: get rid of property cache's state > media: dvb_frontend: better document the -EPERM condition > media: dvb_frontend: fix return values for FE_SET_PROPERTY > media: dvb_frontend: be sure to init dvb_frontend_handle_ioctl() > return code > media: dvb_frontend: fix return error code > > Satendra Singh Thakur (1): > media: dvb_frontend: dtv_property_process_set() cleanups > > .../media/uapi/dvb/fe-get-property.rst| 7 +- > drivers/media/dvb-core/dvb_frontend.c | 571 +++-- > drivers/media/dvb-core/dvb_frontend.h | 13 - > drivers/media/dvb-frontends/lg2160.c | 14 - > drivers/media/dvb-frontends/stv0288.c | 7 - > drivers/media/dvb-frontends/stv6110.c | 9 - > drivers/media/usb/dvb-usb/friio-fe.c | 24 - > fs/compat_ioctl.c | 17 - > include/uapi/linux/dvb/frontend.h | 592 +++--- > 9 files changed, 881 insertions(+), 373 deletions(-) > -- Florian
[PATCH stable 4.9] arm64: entry: Place an SB sequence following an ERET instruction
From: Will Deacon commit 679db70801da9fda91d26caf13bf5b5ccc74e8e8 upstream Some CPUs can speculate past an ERET instruction and potentially perform speculative accesses to memory before processing the exception return. Since the register state is often controlled by a lower privilege level at the point of an ERET, this could potentially be used as part of a side-channel attack. This patch emits an SB sequence after each ERET so that speculation is held up on exception return. Signed-off-by: Will Deacon [florian: Adjust hyp-entry.S to account for the label] Signed-off-by: Florian Fainelli --- Will, Can you confirm that for 4.9 these are the only places that require patching? Thank you! arch/arm64/kernel/entry.S | 2 ++ arch/arm64/kvm/hyp/entry.S | 1 + arch/arm64/kvm/hyp/hyp-entry.S | 4 3 files changed, 7 insertions(+) diff --git a/arch/arm64/kernel/entry.S b/arch/arm64/kernel/entry.S index ca978d7d98eb..3408c782702c 100644 --- a/arch/arm64/kernel/entry.S +++ b/arch/arm64/kernel/entry.S @@ -255,6 +255,7 @@ alternative_insn eret, nop, ARM64_UNMAP_KERNEL_AT_EL0 .else eret .endif + sb .endm .macro get_thread_info, rd @@ -945,6 +946,7 @@ __ni_sys_trace: mrs x30, far_el1 .endif eret + sb .endm .align 11 diff --git a/arch/arm64/kvm/hyp/entry.S b/arch/arm64/kvm/hyp/entry.S index a360ac6e89e9..bc5c6cdb8538 100644 --- a/arch/arm64/kvm/hyp/entry.S +++ b/arch/arm64/kvm/hyp/entry.S @@ -83,6 +83,7 @@ ENTRY(__guest_enter) // Do not touch any register after this! eret + sb ENDPROC(__guest_enter) ENTRY(__guest_exit) diff --git a/arch/arm64/kvm/hyp/hyp-entry.S b/arch/arm64/kvm/hyp/hyp-entry.S index bf4988f9dae8..3675e7f0ab72 100644 --- a/arch/arm64/kvm/hyp/hyp-entry.S +++ b/arch/arm64/kvm/hyp/hyp-entry.S @@ -97,6 +97,7 @@ el1_sync: // Guest trapped into EL2 do_el2_call 2: eret + sb el1_hvc_guest: /* @@ -147,6 +148,7 @@ wa_epilogue: mov x0, xzr add sp, sp, #16 eret + sb el1_trap: get_vcpu_ptrx1, x0 @@ -198,6 +200,7 @@ el2_error: b.ne__hyp_panic mov x0, #(1 << ARM_EXIT_WITH_SERROR_BIT) eret + sb ENTRY(__hyp_do_panic) mov lr, #(PSR_F_BIT | PSR_I_BIT | PSR_A_BIT | PSR_D_BIT |\ @@ -206,6 +209,7 @@ ENTRY(__hyp_do_panic) ldr lr, =panic msr elr_el2, lr eret + sb ENDPROC(__hyp_do_panic) ENTRY(__hyp_panic) -- 2.17.1
[tip:ras/core] BUILD SUCCESS 7ccddc4613db446dc3cbb69a3763ba60ec651d13
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git ras/core branch HEAD: 7ccddc4613db446dc3cbb69a3763ba60ec651d13 x86/mce/dev-mcelog: Fix -Wstringop-truncation warning about strncpy() elapsed time: 768m configs tested: 102 configs skipped: 1 The following configs have been built successfully. More configs may be tested in the coming days. arm defconfig arm allyesconfig arm allmodconfig arm allnoconfig arm64allyesconfig arm64 defconfig arm64allmodconfig arm64 allnoconfig c6xevmc6457_defconfig nds32 defconfig alphaalldefconfig mips loongson1b_defconfig alpha defconfig mips bmips_be_defconfig i386 allnoconfig i386 allyesconfig i386defconfig i386 debian-10.3 ia64 allmodconfig ia64defconfig ia64 allnoconfig ia64 allyesconfig m68k allmodconfig m68k allnoconfig m68k sun3_defconfig m68kdefconfig m68k allyesconfig nios2 defconfig nios2allyesconfig openriscdefconfig c6x allyesconfig c6x allnoconfig openrisc allyesconfig nds32 allnoconfig csky allyesconfig cskydefconfig alphaallyesconfig xtensa allyesconfig h8300allyesconfig h8300allmodconfig xtensa defconfig arc defconfig arc allyesconfig sh allmodconfig shallnoconfig microblazeallnoconfig mips allyesconfig mips allnoconfig mips allmodconfig pariscallnoconfig parisc defconfig parisc allyesconfig parisc allmodconfig powerpc allyesconfig powerpc rhel-kconfig powerpc allmodconfig powerpc allnoconfig powerpc defconfig i386 randconfig-a006-20200611 i386 randconfig-a002-20200611 i386 randconfig-a001-20200611 i386 randconfig-a004-20200611 i386 randconfig-a005-20200611 i386 randconfig-a003-20200611 x86_64 randconfig-a001-20200612 x86_64 randconfig-a003-20200612 x86_64 randconfig-a002-20200612 x86_64 randconfig-a006-20200612 x86_64 randconfig-a005-20200612 x86_64 randconfig-a004-20200612 i386 randconfig-a015-20200612 i386 randconfig-a011-20200612 i386 randconfig-a014-20200612 i386 randconfig-a016-20200612 i386 randconfig-a013-20200612 i386 randconfig-a012-20200612 riscvallyesconfig riscv allnoconfig riscv defconfig riscvallmodconfig s390 allyesconfig s390 allnoconfig s390 allmodconfig s390defconfig sparcallyesconfig sparc defconfig sparc64 defconfig sparc64 allnoconfig sparc64 allyesconfig sparc64 allmodconfig um allmodconfig umallnoconfig um defconfig um allyesconfig x86_64 rhel x86_64 rhel-7.2-clear x86_64lkp x86_64 fedora-25 x86_64 rhel-7.6 x86_64rhel-7.6-kselftests x86_64
[v2 PATCH] printk: Make linux/printk.h self-contained
As it stands if you include printk.h by itself it will fail to
compile because it requires definitions from ratelimit.h. However,
simply including ratelimit.h from printk.h does not work due to
inclusion loops involving sched.h and kernel.h.
This patch solves this by moving bits from ratelimit.h into a new
header file which can then be included by printk.h without any
worries about header loops.
The build bot then revealed some intriguing failures arising out
of this patch. On s390 there is an inclusion loop with asm/bug.h
and linux/kernel.h that triggers a compile failure, because kernel.h
will cause asm-generic/bug.h to be included before s390's own
asm/bug.h has finished processing. This has been fixed by not
including kernel.h in arch/s390/include/asm/bug.h.
A related failure was seen on powerpc where asm/bug.h leads to
the inclusion of linux/kernel.h via asm-generic/bug.h which then
prematurely tries to use the very macros defined in asm/bug.h.
The particular inclusion path which led to this involves lockdep.h.
I have fixed this moving the type definitions lockdep.h into the
new lockdep_types.h.
Signed-off-by: Herbert Xu
diff --git a/include/linux/ratelimit_types.h b/include/linux/ratelimit_types.h
new file mode 100644
index ..b676aa419eef
--- /dev/null
+++ b/include/linux/ratelimit_types.h
@@ -0,0 +1,43 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#ifndef _LINUX_RATELIMIT_TYPES_H
+#define _LINUX_RATELIMIT_TYPES_H
+
+#include
+#include
+#include
+
+#define DEFAULT_RATELIMIT_INTERVAL (5 * HZ)
+#define DEFAULT_RATELIMIT_BURST10
+
+/* issue num suppressed message on exit */
+#define RATELIMIT_MSG_ON_RELEASE BIT(0)
+
+struct ratelimit_state {
+ raw_spinlock_t lock; /* protect the state */
+
+ int interval;
+ int burst;
+ int printed;
+ int missed;
+ unsigned long begin;
+ unsigned long flags;
+};
+
+#define RATELIMIT_STATE_INIT(name, interval_init, burst_init) {
\
+ .lock = __RAW_SPIN_LOCK_UNLOCKED(name.lock), \
+ .interval = interval_init,\
+ .burst = burst_init, \
+ }
+
+#define RATELIMIT_STATE_INIT_DISABLED \
+ RATELIMIT_STATE_INIT(ratelimit_state, 0, DEFAULT_RATELIMIT_BURST)
+
+#define DEFINE_RATELIMIT_STATE(name, interval_init, burst_init)
\
+ \
+ struct ratelimit_state name = \
+ RATELIMIT_STATE_INIT(name, interval_init, burst_init) \
+
+extern int ___ratelimit(struct ratelimit_state *rs, const char *func);
+#define __ratelimit(state) ___ratelimit(state, __func__)
+
+#endif /* _LINUX_RATELIMIT_TYPES_H */
diff --git a/include/linux/printk.h b/include/linux/printk.h
index e061635e0409..1cd862cfd2f4 100644
--- a/include/linux/printk.h
+++ b/include/linux/printk.h
@@ -7,6 +7,7 @@
#include
#include
#include
+#include
extern const char linux_banner[];
extern const char linux_proc_banner[];
diff --git a/include/linux/ratelimit.h b/include/linux/ratelimit.h
index 8ddf79e9207a..b17e0cd0a30c 100644
--- a/include/linux/ratelimit.h
+++ b/include/linux/ratelimit.h
@@ -2,41 +2,10 @@
#ifndef _LINUX_RATELIMIT_H
#define _LINUX_RATELIMIT_H
-#include
+#include
#include
#include
-#define DEFAULT_RATELIMIT_INTERVAL (5 * HZ)
-#define DEFAULT_RATELIMIT_BURST10
-
-/* issue num suppressed message on exit */
-#define RATELIMIT_MSG_ON_RELEASE BIT(0)
-
-struct ratelimit_state {
- raw_spinlock_t lock; /* protect the state */
-
- int interval;
- int burst;
- int printed;
- int missed;
- unsigned long begin;
- unsigned long flags;
-};
-
-#define RATELIMIT_STATE_INIT(name, interval_init, burst_init) {
\
- .lock = __RAW_SPIN_LOCK_UNLOCKED(name.lock), \
- .interval = interval_init,\
- .burst = burst_init, \
- }
-
-#define RATELIMIT_STATE_INIT_DISABLED \
- RATELIMIT_STATE_INIT(ratelimit_state, 0, DEFAULT_RATELIMIT_BURST)
-
-#define DEFINE_RATELIMIT_STATE(name, interval_init, burst_init)
\
- \
- struct ratelimit_state name = \
- RATELIMIT_STATE_INIT(name, interval_init, burst_init) \
-
static inline void ratelimit_state_init(struct ratelimit_state *rs,
int interval, int burst)
{
@@ -73,9 +42,6 @@ ratelimit_set_flags(struct ratelimit_state *rs, unsigned long
[tip:x86/entry] BUILD SUCCESS f0178fc01fe46bab6a95415f5647d1a74efcad1b
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git x86/entry branch HEAD: f0178fc01fe46bab6a95415f5647d1a74efcad1b x86/entry: Unbreak __irqentry_text_start/end magic elapsed time: 767m configs tested: 96 configs skipped: 1 The following configs have been built successfully. More configs may be tested in the coming days. arm defconfig arm allyesconfig arm allmodconfig arm allnoconfig arm64allyesconfig arm64 defconfig arm64allmodconfig arm64 allnoconfig c6xevmc6457_defconfig alphaalldefconfig mips loongson1b_defconfig mips bmips_be_defconfig nds32 defconfig alpha defconfig i386 allnoconfig i386 allyesconfig i386defconfig i386 debian-10.3 ia64 allmodconfig ia64defconfig ia64 allnoconfig ia64 allyesconfig m68k allmodconfig m68k allnoconfig m68k sun3_defconfig m68kdefconfig m68k allyesconfig nios2 defconfig nios2allyesconfig openriscdefconfig c6x allyesconfig c6x allnoconfig openrisc allyesconfig nds32 allnoconfig csky allyesconfig cskydefconfig alphaallyesconfig xtensa allyesconfig h8300allyesconfig h8300allmodconfig xtensa defconfig arc defconfig arc allyesconfig sh allmodconfig shallnoconfig microblazeallnoconfig mips allyesconfig mips allnoconfig mips allmodconfig pariscallnoconfig parisc defconfig parisc allyesconfig parisc allmodconfig powerpc allyesconfig powerpc rhel-kconfig powerpc allmodconfig powerpc allnoconfig powerpc defconfig i386 randconfig-a006-20200611 i386 randconfig-a002-20200611 i386 randconfig-a001-20200611 i386 randconfig-a004-20200611 i386 randconfig-a005-20200611 i386 randconfig-a003-20200611 i386 randconfig-a015-20200612 i386 randconfig-a011-20200612 i386 randconfig-a014-20200612 i386 randconfig-a016-20200612 i386 randconfig-a013-20200612 i386 randconfig-a012-20200612 riscvallyesconfig riscv allnoconfig riscv defconfig riscvallmodconfig s390 allyesconfig s390 allnoconfig s390 allmodconfig s390defconfig sparc64 defconfig sparcallyesconfig sparc defconfig sparc64 allnoconfig sparc64 allyesconfig sparc64 allmodconfig um allmodconfig umallnoconfig um defconfig um allyesconfig x86_64 rhel x86_64 rhel-7.2-clear x86_64lkp x86_64 fedora-25 x86_64 rhel-7.6 x86_64rhel-7.6-kselftests x86_64 rhel-8.3 x86_64 kexec --- 0-DAY CI Kernel Test Service, Intel Corporation https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
[tip:master] BUILD SUCCESS 8a7fd399f1a0bcf4943245dc87d75964546596a8
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git master branch HEAD: 8a7fd399f1a0bcf4943245dc87d75964546596a8 Merge branch 'ras/core' into auto-latest elapsed time: 625m configs tested: 96 configs skipped: 1 The following configs have been built successfully. More configs may be tested in the coming days. arm defconfig arm allyesconfig arm allmodconfig arm allnoconfig arm64allyesconfig arm64 defconfig arm64allmodconfig arm64 allnoconfig c6xevmc6457_defconfig nds32 defconfig alphaalldefconfig mips loongson1b_defconfig alpha defconfig mips bmips_be_defconfig i386 allnoconfig i386 allyesconfig i386defconfig i386 debian-10.3 ia64 allmodconfig ia64defconfig ia64 allnoconfig ia64 allyesconfig m68k allmodconfig m68k allnoconfig m68k sun3_defconfig m68kdefconfig m68k allyesconfig nios2 defconfig nios2allyesconfig openriscdefconfig c6x allyesconfig c6x allnoconfig openrisc allyesconfig nds32 allnoconfig csky allyesconfig cskydefconfig alphaallyesconfig xtensa allyesconfig h8300allyesconfig h8300allmodconfig xtensa defconfig arc defconfig arc allyesconfig sh allmodconfig shallnoconfig microblazeallnoconfig mips allyesconfig mips allnoconfig mips allmodconfig pariscallnoconfig parisc defconfig parisc allyesconfig parisc allmodconfig powerpc defconfig powerpc allyesconfig powerpc rhel-kconfig powerpc allmodconfig powerpc allnoconfig x86_64 randconfig-a015-20200611 x86_64 randconfig-a011-20200611 x86_64 randconfig-a016-20200611 x86_64 randconfig-a012-20200611 x86_64 randconfig-a014-20200611 x86_64 randconfig-a013-20200611 i386 randconfig-a015-20200612 i386 randconfig-a011-20200612 i386 randconfig-a014-20200612 i386 randconfig-a016-20200612 i386 randconfig-a013-20200612 i386 randconfig-a012-20200612 riscvallyesconfig riscv allnoconfig riscv defconfig riscvallmodconfig s390 allyesconfig s390 allnoconfig s390 allmodconfig s390defconfig sparcallyesconfig sparc defconfig sparc64 defconfig sparc64 allnoconfig sparc64 allyesconfig sparc64 allmodconfig um allmodconfig umallnoconfig um defconfig um allyesconfig x86_64 rhel x86_64lkp x86_64 fedora-25 x86_64 rhel-7.2-clear x86_64 rhel-7.6 x86_64rhel-7.6-kselftests x86_64 rhel-8.3 x86_64 kexec --- 0-DAY CI Kernel Test Service, Intel Corporation https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
[tip:locking/kcsan] BUILD SUCCESS 1f44328ea24c9de368a3cfe5cc0e110b949afb2e
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git locking/kcsan branch HEAD: 1f44328ea24c9de368a3cfe5cc0e110b949afb2e compiler_types.h, kasan: Use __SANITIZE_ADDRESS__ instead of CONFIG_KASAN to decide inlining elapsed time: 628m configs tested: 96 configs skipped: 1 The following configs have been built successfully. More configs may be tested in the coming days. arm defconfig arm allyesconfig arm allmodconfig arm allnoconfig arm64allyesconfig arm64 defconfig arm64allmodconfig arm64 allnoconfig c6xevmc6457_defconfig nds32 defconfig alphaalldefconfig mips loongson1b_defconfig alpha defconfig mips bmips_be_defconfig c6xevmc6678_defconfig powerpc g5_defconfig archsdk_defconfig arm tango4_defconfig mips ip32_defconfig shedosk7705_defconfig i386 allnoconfig i386 allyesconfig i386defconfig i386 debian-10.3 ia64 allmodconfig ia64defconfig ia64 allnoconfig ia64 allyesconfig m68k allmodconfig m68k allnoconfig m68k sun3_defconfig m68kdefconfig m68k allyesconfig nios2 defconfig nios2allyesconfig openriscdefconfig c6x allyesconfig c6x allnoconfig openrisc allyesconfig nds32 allnoconfig csky allyesconfig cskydefconfig alphaallyesconfig xtensa allyesconfig h8300allyesconfig h8300allmodconfig xtensa defconfig arc defconfig arc allyesconfig sh allmodconfig shallnoconfig microblazeallnoconfig mips allyesconfig mips allnoconfig mips allmodconfig pariscallnoconfig parisc defconfig parisc allyesconfig parisc allmodconfig powerpc allyesconfig powerpc rhel-kconfig powerpc allmodconfig powerpc allnoconfig powerpc defconfig i386 randconfig-a015-20200612 i386 randconfig-a011-20200612 i386 randconfig-a014-20200612 i386 randconfig-a016-20200612 i386 randconfig-a013-20200612 i386 randconfig-a012-20200612 riscvallyesconfig riscv allnoconfig riscv defconfig riscvallmodconfig s390 allyesconfig s390 allnoconfig s390 allmodconfig s390defconfig sparcallyesconfig sparc defconfig sparc64 defconfig sparc64 allnoconfig sparc64 allyesconfig sparc64 allmodconfig um allmodconfig umallnoconfig um allyesconfig um defconfig x86_64 rhel x86_64 rhel-7.2-clear x86_64lkp x86_64 fedora-25 x86_64 rhel-7.6 x86_64rhel-7.6-kselftests x86_64 rhel-8.3 x86_64 kexec --- 0-DAY CI Kernel Test Service, Intel Corporation https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
sound/soc/fsl/fsl-asoc-card.c:684:45: sparse: sparse: incorrect type in argument 3 (different base types)
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: b791d1bdf9212d944d749a5c7ff6febdba241771
commit: 859e364302c510cfdd9abda13a3c4c1d1bc68c57 ASoC: fsl-asoc-card: Support
new property fsl, asrc-format
date: 7 weeks ago
config: arm-randconfig-s032-20200612 (attached as .config)
compiler: arm-linux-gnueabi-gcc (GCC) 9.3.0
reproduce:
# apt-get install sparse
# sparse version: v0.6.1-250-g42323db3-dirty
git checkout 859e364302c510cfdd9abda13a3c4c1d1bc68c57
# save the attached .config to linux build tree
make W=1 C=1 ARCH=arm CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__'
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
sparse warnings: (new ones prefixed by >>)
>> sound/soc/fsl/fsl-asoc-card.c:684:45: sparse: sparse: incorrect type in
>> argument 3 (different base types) @@ expected unsigned int [usertype]
>> *out_value @@ got restricted snd_pcm_format_t * @@
>> sound/soc/fsl/fsl-asoc-card.c:684:45: sparse: expected unsigned int
>> [usertype] *out_value
>> sound/soc/fsl/fsl-asoc-card.c:684:45: sparse: got restricted
>> snd_pcm_format_t *
vim +684 sound/soc/fsl/fsl-asoc-card.c
480
481 static int fsl_asoc_card_probe(struct platform_device *pdev)
482 {
483 struct device_node *cpu_np, *codec_np, *asrc_np;
484 struct device_node *np = pdev->dev.of_node;
485 struct platform_device *asrc_pdev = NULL;
486 struct platform_device *cpu_pdev;
487 struct fsl_asoc_card_priv *priv;
488 struct i2c_client *codec_dev;
489 const char *codec_dai_name;
490 u32 width;
491 int ret;
492
493 priv = devm_kzalloc(>dev, sizeof(*priv), GFP_KERNEL);
494 if (!priv)
495 return -ENOMEM;
496
497 cpu_np = of_parse_phandle(np, "audio-cpu", 0);
498 /* Give a chance to old DT binding */
499 if (!cpu_np)
500 cpu_np = of_parse_phandle(np, "ssi-controller", 0);
501 if (!cpu_np) {
502 dev_err(>dev, "CPU phandle missing or invalid\n");
503 ret = -EINVAL;
504 goto fail;
505 }
506
507 cpu_pdev = of_find_device_by_node(cpu_np);
508 if (!cpu_pdev) {
509 dev_err(>dev, "failed to find CPU DAI device\n");
510 ret = -EINVAL;
511 goto fail;
512 }
513
514 codec_np = of_parse_phandle(np, "audio-codec", 0);
515 if (codec_np)
516 codec_dev = of_find_i2c_device_by_node(codec_np);
517 else
518 codec_dev = NULL;
519
520 asrc_np = of_parse_phandle(np, "audio-asrc", 0);
521 if (asrc_np)
522 asrc_pdev = of_find_device_by_node(asrc_np);
523
524 /* Get the MCLK rate only, and leave it controlled by CODEC
drivers */
525 if (codec_dev) {
526 struct clk *codec_clk = clk_get(_dev->dev, NULL);
527
528 if (!IS_ERR(codec_clk)) {
529 priv->codec_priv.mclk_freq =
clk_get_rate(codec_clk);
530 clk_put(codec_clk);
531 }
532 }
533
534 /* Default sample rate and format, will be updated in
hw_params() */
535 priv->sample_rate = 44100;
536 priv->sample_format = SNDRV_PCM_FORMAT_S16_LE;
537
538 /* Assign a default DAI format, and allow each card to
overwrite it */
539 priv->dai_fmt = DAI_FMT_BASE;
540
541 /* Diversify the card configurations */
542 if (of_device_is_compatible(np, "fsl,imx-audio-cs42888")) {
543 codec_dai_name = "cs42888";
544 priv->card.set_bias_level = NULL;
545 priv->cpu_priv.sysclk_freq[TX] =
priv->codec_priv.mclk_freq;
546 priv->cpu_priv.sysclk_freq[RX] =
priv->codec_priv.mclk_freq;
547 priv->cpu_priv.sysclk_dir[TX] = SND_SOC_CLOCK_OUT;
548 priv->cpu_priv.sysclk_dir[RX] = SND_SOC_CLOCK_OUT;
549 priv->cpu_priv.slot_width = 32;
550 priv->dai_fmt |= SND_SOC_DAIFMT_CBS_CFS;
551 } else if (of_device_is_compatible(np, "fsl,imx-audio-cs427x"))
{
552 codec_dai_name = "cs4271-hifi";
553 priv->codec_priv.mclk_id = CS427x_SYSCLK_MCLK;
554 priv->dai_fmt |= SND_SOC_DAIFMT_CBM_CFM;
555 } else if (of_device_is_compatible(np,
"fsl,imx-audio-sgtl5000")) {
556 codec_dai_name = "sgtl5000";
557 priv->codec_priv.mclk_id = SGTL5000_SYSCLK;
558
Re: [PATCH v8 4/7] iommu/arm-smmu: Add a pointer to the attached device to smmu_domain
Hi Jordan,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on linus/master]
[also build test ERROR on v5.7 next-20200611]
[cannot apply to iommu/next robh/for-next arm/for-next keystone/next
rockchip/for-next arm64/for-next/core shawnguo/for-next soc/for-next]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we also suggest to use '--base' option to specify the
base tree in git format-patch, please see https://stackoverflow.com/a/37406982]
url:
https://github.com/0day-ci/linux/commits/Jordan-Crouse/iommu-arm-smmu-Enable-split-pagetable-support/20200612-094718
base: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
b961f8dc8976c091180839f4483d67b7c2ca2578
config: arm64-randconfig-s031-20200612 (attached as .config)
compiler: aarch64-linux-gcc (GCC) 9.3.0
reproduce:
# apt-get install sparse
# sparse version: v0.6.1-250-g42323db3-dirty
# save the attached .config to linux build tree
make W=1 C=1 ARCH=arm64 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__'
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All errors (new ones prefixed by >>, old ones prefixed by <<):
drivers/iommu/arm-smmu.c: In function 'arm_smmu_init_domain_context':
>> drivers/iommu/arm-smmu.c:804:21: error: 'dev' undeclared (first use in this
>> function); did you mean 'cdev'?
804 | smmu_domain->dev = dev;
| ^~~
| cdev
drivers/iommu/arm-smmu.c:804:21: note: each undeclared identifier is reported
only once for each function it appears in
vim +804 drivers/iommu/arm-smmu.c
669
670 static int arm_smmu_init_domain_context(struct iommu_domain *domain,
671 struct arm_smmu_device *smmu)
672 {
673 int irq, start, ret = 0;
674 unsigned long ias, oas;
675 struct io_pgtable_ops *pgtbl_ops;
676 struct io_pgtable_cfg pgtbl_cfg;
677 enum io_pgtable_fmt fmt;
678 struct arm_smmu_domain *smmu_domain = to_smmu_domain(domain);
679 struct arm_smmu_cfg *cfg = _domain->cfg;
680
681 mutex_lock(_domain->init_mutex);
682 if (smmu_domain->smmu)
683 goto out_unlock;
684
685 if (domain->type == IOMMU_DOMAIN_IDENTITY) {
686 smmu_domain->stage = ARM_SMMU_DOMAIN_BYPASS;
687 smmu_domain->smmu = smmu;
688 goto out_unlock;
689 }
690
691 /*
692 * Mapping the requested stage onto what we support is
surprisingly
693 * complicated, mainly because the spec allows S1+S2 SMMUs
without
694 * support for nested translation. That means we end up with the
695 * following table:
696 *
697 * RequestedSupportedActual
698 * S1 N S1
699 * S1 S1+S2S1
700 * S1 S2 S2
701 * S1 S1 S1
702 * NN N
703 * N S1+S2S2
704 * NS2 S2
705 * NS1 S1
706 *
707 * Note that you can't actually request stage-2 mappings.
708 */
709 if (!(smmu->features & ARM_SMMU_FEAT_TRANS_S1))
710 smmu_domain->stage = ARM_SMMU_DOMAIN_S2;
711 if (!(smmu->features & ARM_SMMU_FEAT_TRANS_S2))
712 smmu_domain->stage = ARM_SMMU_DOMAIN_S1;
713
714 /*
715 * Choosing a suitable context format is even more fiddly.
Until we
716 * grow some way for the caller to express a preference, and/or
move
717 * the decision into the io-pgtable code where it arguably
belongs,
718 * just aim for the closest thing to the rest of the system,
and hope
719 * that the hardware isn't esoteric enough that we can't assume
AArch64
720 * support to be a superset of AArch32 support...
721 */
722 if (smmu->features & ARM_SMMU_FEAT_FMT_AARCH32_L)
723 cfg->fmt = ARM_SMMU_CTX_FMT_AARCH32_L;
724 if (IS_ENABLED(CONFIG_IOMMU_IO_PGTABLE_ARMV7S) &&
725 !IS_ENABLED(CONFIG_64BIT) && !IS_ENABLED(CONFIG_ARM_LPAE) &&
726 (smmu->features & ARM_SMMU_FEAT_FMT_AARCH32_S) &&
727 (smmu_domain->stage == ARM_SMMU_DOMAIN_S1))
728 cfg->fmt = ARM_SMMU_CTX_FMT_AARCH32_S;
Re: [RFC PATCH 2/5] scsi: ufs: Add UFS-feature layer
On 2020-06-11 19:27, Daejun Park wrote:
>>> @@ -2525,6 +2525,8 @@ static int ufshcd_queuecommand(struct Scsi_Host
>>> *host, struct scsi_cmnd *cmd)
>>>
>>>ufshcd_comp_scsi_upiu(hba, lrbp);
>>>
>>> + ufsf_ops_prep_fn(hba, lrbp);
>>> +
>>>err = ufshcd_map_sg(hba, lrbp);
>>>if (err) {
>>> lrbp->cmd = NULL;
>
>> What happens if a SCSI command is retried and hence ufsf_ops_prep_fn()
>> is called multiple times for the same SCSI command?
>
> Developers of UFS features should implement it so that prep_fn does not have
> any problems even if it processes the same SCSI command multiple times.
> In HPB feature, prep_fn modifies only upiu structure. So it is ok to call
> it multiple times because the upiu is rebuilt from ufshcd_comp_scsi_upiu().
Please make sure that this expectation is documented somewhere.
Thanks,
Bart.
Re: Regression bisected to f2f84b05e02b (bug: consolidate warn_slowpath_fmt() usage)
On Tue, Jun 2, 2020 at 11:03 AM Kees Cook wrote: > > On Mon, Jun 01, 2020 at 07:48:04PM -0700, Matt Turner wrote: > > I bisected a regression on alpha to f2f84b05e02b (bug: consolidate > > warn_slowpath_fmt() usage) which looks totally innocuous. > > > > Reverting it on master confirms that it somehow is the trigger. At or a > > little after starting userspace, I'll see an oops like this: > > > > Unable to handle kernel paging request at virtual address > > CPU 0 > > kworker/u2:5(98): Oops -1 > > pc = [<>] ra = [<>] ps = Not > > tainted > > pc is at 0x0 > > so, the instruction pointer is NULL. The only way I can imagine > that happening would be from this line: > > worker->current_func(work); > > > ra is at 0x0 > > v0 = 0007 t0 = 0001 t1 = 0001 > > t2 = t3 = fc00bfe68780 t4 = 0001 > > t5 = fc00bf8cc780 t6 = 026f8000 t7 = fc00bfe7 > > s0 = fc000250d310 s1 = fc000250d310 s2 = fc000250d310 > > s3 = fc000250ca40 s4 = fc000250caa0 s5 = > > s6 = fc000250ca40 > > a0 = fc00024f0488 a1 = fc00bfe73d98 a2 = fc00bfe68800 > > a3 = fc00bf881400 a4 = 0001 a5 = 0002 > > t8 = t9 = t10= 01321800 > > t11= ba4e pv = fc000189ca00 at = > > gp = fc000253e430 sp = 43a83c2e > > Disabling lock debugging due to kernel taint > > Trace: > > [] process_one_work+0x25c/0x5a0 > > Can you verify where this ^^ is? It is kernel/workqueue.c:2268, which contains worker->current_func(work); as you predicted. > > [] worker_thread+0x5c/0x7d0 > > [] kthread+0x188/0x1f0 > > [] ret_from_kernel_thread+0x18/0x20 > > [] kthread+0x0/0x1f0 > > [] worker_thread+0x0/0x7d0 > > > > Code: > > > > > > 00063301 > > 12e2 > > > > 0005ffde > > > > It seems to cause a hard lock on an SMP system, but not on a system with > > a single CPU. Similarly, if I boot the SMP system (2 CPUs) with > > maxcpus=1 the oops doesn't happen. Until I tested on a non-SMP system > > today I suspected that it was unaffected, but I saw the oops there too. > > With the revert applied, I don't see a warning or an oops. > > > > Any clues how this patch could have triggered the oops? > > I cannot begin to imagine. :P Compared to other things I've seen like > this in the past maybe it's some kind of effect from the code size > changing the location/alignment or timing of something else? > > Various questions ranging in degrees of sanity: > > Does alpha use work queues for WARN? I do not know. I don't see much in a few greps of arch/alpha that would indicate that it uses work queues. > Which work queue is getting a NULL function? (And then things like "if > WARN was much slower or much faster, is there a race to something > setting itself to NULL?") > > Was there a WARN before the above Oops? No, which I suspect means that your much scarier suggestion that this is somehow due to code size or alignment is increasingly plausible. > Does WARN have side-effects on alpha? alpha just uses the asm-generic implementation of WARN as far as I can tell, so I think not. > Does __WARN_printf() do something bad that warn_slowpath_null() doesn't? > > Does making incremental changes narrow anything down? (e.g. instead of > this revert, remove the __warn() call in warn_slowpath_fmt() that was > added? (I mean, that'll be quite broken for WARN, but will it not oops?) Commenting out the added __warn does not work around the problem. Readding warn_slowpath_null and the EXPORT_SYMBOL (but not calling it from WARN) does not work around the problem. Calling warn_slowpath_fmt() with fmt=" " instead of fmt=NULL does not work around the problem. I also tried GCC-10.1 as a stab in the dark, and that doesn't work around the problem. So I'm thinking it's something about code size or alignment. I would be worried it's to do with memory ordering (since this is on Alpha) but I'm seeing the problem on a single CPU system, so that should be ruled out, I think? Using CONFIG_CC_OPTIMIZE_FOR_SIZE=y doesn't work around the problem. So that hurts the theory of code size being the trigger. Since I noticed earlier that using maxcpus=1 on a 2-CPU system prevented the system from hanging, I tried disabling CONFIG_SMP on my 1-CPU system as well. In doing so, I discovered that the RCU torture module (RCU_TORTURE_TEST) triggers some null pointer dereferences on Alpha when CONFIG_SMP is set, but works successfully when CONFIG_SMP is unset. That seems likely to be a symptom of the same underlying problem that started this thread, don't you think? If so, I'll focus my attention on that. > Does alpha have hardware breakpoints? When I had to track down a > corruption in the io scheduler, I ended up setting breakpoints
Re: [PATCH 1/3] usb: typec: Add QCOM PMIC typec detection driver
On 6/10/2020 12:37 PM, Bjorn Andersson wrote: >> along with USB_BASE @ 0x1300, is it ok to allow this driver to access >> registers outside of its 'reg' base (0x1500 according to the DT >> bindings)? >> > > Depending on how entangled a future driver for the charger blocks would > be one could either just upstream a dcdc regulator driver to control > vbus today, or a "lite version" of a charging driver exposing just the > vbus regulator. > > Either way I would prefer this over poking the register directly from > this driver, as it will make it tricky to migrate to a proper charger > driver later. > > Regards, > Bjorn > Hi Bjorn/Jack, I have removed the need for referencing other base addresses other than the type C block within the driver, and have moved the DCDC set to be handled by another regulator driver, which solely controls the vbus output. The type C driver will control the vbus output using the regulator APIs. Thanks for the input. -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project
Re: [PATCH 1/3] usb: typec: Add QCOM PMIC typec detection driver
On 6/9/2020 7:27 PM, Jun Li wrote:
>> +static int qcom_pmic_typec_probe(struct platform_device *pdev)
>> +{
>> + struct device *dev = >dev;
>> + struct qcom_pmic_typec *qcom_usb;
>> + struct typec_capability *cap;
>> + const char *buf;
>> + int ret, irq, role;
>> +
>> + qcom_usb = kzalloc(sizeof(*qcom_usb), GFP_KERNEL);
>
> devm_kzalloc().
>
Hi Jun,
Thanks for the input. I have replaced with devm_kzalloc() as you
recommended.
>> + if (!qcom_usb)
>> + return -ENOMEM;
>> +
>> + qcom_usb->dev = dev;
>> +
>> + qcom_usb->regmap = dev_get_regmap(dev->parent, NULL);
>> + if (!qcom_usb->regmap) {
>> + dev_err(dev, "Failed to get regmap\n");
>> + return -EINVAL;
>> + }
>> +
>> + irq = platform_get_irq(pdev, 0);
>> + if (irq < 0) {
>> + dev_err(dev, "Failed to get CC irq\n");
>> + return -EINVAL;
>> + }
>> +
>> + ret = devm_request_irq(qcom_usb->dev, irq, qcom_pmic_typec_interrupt,
>> + IRQF_SHARED, "qcom-pmic-typec", qcom_usb);
>> + if (ret) {
>> + dev_err(>dev, "Could not request IRQ\n");
>> + return ret;
>> + }
>> +
>> + qcom_usb->fwnode = device_get_named_child_node(dev, "connector");
>> + if (!qcom_usb->fwnode)
>> + return -EINVAL;
>> +
>> + cap = kzalloc(sizeof(*cap), GFP_KERNEL);
>
> devm_kzalloc().
>
>> + if (!cap) {
>> + ret = -ENOMEM;
>> + goto err_put_node;
>> + }
>> +
>> + ret = fwnode_property_read_string(qcom_usb->fwnode, "power-role",
>> );
>> + if (!ret)
>> + role = typec_find_port_power_role(buf);
>
> if (role < 0)
>
Added a check for role <0, if so, set to SNK as well
>> + else
>> + role = TYPEC_PORT_SNK;
>> + cap->type = role;
>> +
>> + ret = fwnode_property_read_string(qcom_usb->fwnode, "data-role",
>> );
>> + if (!ret)
>> + role = typec_find_port_data_role(buf);
>
> if (role < 0)
>
Added a check for role <0, if so, set to UFP as well
>> + else
>> + role = TYPEC_PORT_UFP;
>> + cap->data = role;
>> +
>> + cap->prefer_role = -1;
>
> TYPEC_NO_PREFERRED_ROLE
>
Done.
>> + cap->fwnode = qcom_usb->fwnode;
>> + qcom_usb->port = typec_register_port(dev, cap);
>> + if (IS_ERR(qcom_usb->port)) {
>> + dev_err(dev, "Failed to register type c port %d\n",
>> + IS_ERR(qcom_usb->port));
>> + ret = PTR_ERR(qcom_usb->port);
>
> dev_err(dev, , ret)?
>
> Li Jun
Agreed. Thanks!
>> + goto err_put_node;
>> + }
>> +
>> + qcom_usb->cap = cap;
>> +
>> + qcom_usb->role_sw = fwnode_usb_role_switch_get(qcom_usb->fwnode);
>> + if (IS_ERR(qcom_usb->role_sw)) {
>> + if (PTR_ERR(qcom_usb->role_sw) != -EPROBE_DEFER)
>> + dev_err(dev, "failed to get role switch\n");
>> + ret = PTR_ERR(qcom_usb->role_sw);
>> + goto err_typec_port;
>> + }
>> +
>> + INIT_WORK(_usb->bh_work, qcom_pmic_typec_bh_work);
>> + platform_set_drvdata(pdev, qcom_usb);
>> + qcom_pmic_typec_typec_hw_init(qcom_usb);
>> +
>> + queue_work(system_power_efficient_wq, _usb->bh_work);
>> +
>> + return 0;
>> +
>> +err_typec_port:
>> + typec_unregister_port(qcom_usb->port);
>> +err_put_node:
>> + fwnode_handle_put(qcom_usb->fwnode);
>> +
>> + return ret;
>> +}
>> +
>> +static int qcom_pmic_typec_remove(struct platform_device *pdev)
>> +{
>> + struct qcom_pmic_typec *qcom_usb = platform_get_drvdata(pdev);
>> +
>> + cancel_work_sync(_usb->bh_work);
>> + usb_role_switch_set_role(qcom_usb->role_sw, USB_ROLE_NONE);
>> + qcom_pmic_typec_vbus_disable(qcom_usb);
>> +
>> + typec_unregister_port(qcom_usb->port);
>> + usb_role_switch_put(qcom_usb->role_sw);
>> + fwnode_handle_put(qcom_usb->fwnode);
>> +
>> + return 0;
>> +}
>> +
>> +static const struct of_device_id qcom_pmic_typec_table[] = {
>> + { .compatible = "qcom,pm8150b-usb-typec" },
>> + { },
>> +};
>> +MODULE_DEVICE_TABLE(of, qcom_pmic_typec_table);
>> +
>> +static struct platform_driver qcom_pmic_typec = {
>> + .driver = {
>> + .name = "qcom,pmic-typec",
>> + .of_match_table = qcom_pmic_typec_table,
>> + },
>> + .probe = qcom_pmic_typec_probe,
>> + .remove = qcom_pmic_typec_remove,
>> +};
>> +
>> +module_platform_driver(qcom_pmic_typec);
>> +
>> +MODULE_DESCRIPTION("QCOM PMIC USB type C driver");
>> +MODULE_LICENSE("GPL v2");
>> --
>> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
>> a Linux Foundation Collaborative Project
>>
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation
Re: [PATCH 1/3] usb: typec: Add QCOM PMIC typec detection driver
On 6/9/2020 2:20 PM, Randy Dunlap wrote: > On 6/9/20 1:58 PM, Wesley Cheng wrote: >> diff --git a/drivers/usb/typec/Kconfig b/drivers/usb/typec/Kconfig >> index 559dd06..8de2520 100644 >> --- a/drivers/usb/typec/Kconfig >> +++ b/drivers/usb/typec/Kconfig >> @@ -73,6 +73,17 @@ config TYPEC_TPS6598X >>If you choose to build this driver as a dynamically linked module, the >>module will be called tps6598x.ko. >> > > Hi, > Please spell "Type-C" like all of the other drivers do. > >> +config TYPEC_QCOM_PMIC >> +tristate "Qualcomm PMIC USB typec driver" >> +depends on ARCH_QCOM >> +help >> + Driver for supporting role switch over the Qualcomm PMIC. This will >> + handle the type C role and orientation detection reported by the QCOM >> + PMIC if the PMIC has the capability to handle type C detection. >> + >> + It will also enable the VBUS output to connected devices when a >> + DFP connection is made. >> + >> source "drivers/usb/typec/mux/Kconfig" >> >> source "drivers/usb/typec/altmodes/Kconfig" Hi Randy, Will do. Thanks > > -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project
Re: [PATCH] x86/entry: Treat BUG/WARN as NMI-like entries
On Thu, Jun 11, 2020 at 8:26 PM Andy Lutomirski wrote:
>
> If we BUG or WARN in a funny RCU context, we cleverly optimize the
> BUG/WARN using the ud2 hack, which takes us through the
> idtentry_enter...() paths, which might helpfully WARN that the RCU
> context is invalid, which results in infinite recursion.
>
> Split the BUG/WARN handling into an nmi_enter()/nmi_exit() path in
> exc_invalid_op() to increase the chance that we survive the
> experience.
>
> Signed-off-by: Andy Lutomirski
> ---
>
> This is not as well tested as I would like, but it does cause the splat
> I'm chasing to display a nice warning instead of causing an undebuggable
> stack overflow.
>
> (It would have been debuggable on x86_64, but it's a 32-bit splat, and
> x86_32 doesn't have ORC.)
>
> arch/x86/kernel/traps.c | 61 +++--
> arch/x86/mm/extable.c | 15 --
> 2 files changed, 48 insertions(+), 28 deletions(-)
>
> diff --git a/arch/x86/kernel/traps.c b/arch/x86/kernel/traps.c
> index cb8c3d26cdf5..6340b12a6616 100644
> --- a/arch/x86/kernel/traps.c
> +++ b/arch/x86/kernel/traps.c
> @@ -98,24 +98,6 @@ int is_valid_bugaddr(unsigned long addr)
> return ud == INSN_UD0 || ud == INSN_UD2;
> }
>
> -int fixup_bug(struct pt_regs *regs, int trapnr)
> -{
> - if (trapnr != X86_TRAP_UD)
> - return 0;
> -
> - switch (report_bug(regs->ip, regs)) {
> - case BUG_TRAP_TYPE_NONE:
> - case BUG_TRAP_TYPE_BUG:
> - break;
> -
> - case BUG_TRAP_TYPE_WARN:
> - regs->ip += LEN_UD2;
> - return 1;
> - }
> -
> - return 0;
> -}
> -
> static nokprobe_inline int
> do_trap_no_signal(struct task_struct *tsk, int trapnr, const char *str,
> struct pt_regs *regs, long error_code)
> @@ -191,13 +173,6 @@ static void do_error_trap(struct pt_regs *regs, long
> error_code, char *str,
> {
> RCU_LOCKDEP_WARN(!rcu_is_watching(), "entry code didn't wake RCU");
>
> - /*
> -* WARN*()s end up here; fix them up before we call the
> -* notifier chain.
> -*/
> - if (!user_mode(regs) && fixup_bug(regs, trapnr))
> - return;
> -
> if (notify_die(DIE_TRAP, str, regs, error_code, trapnr, signr) !=
> NOTIFY_STOP) {
> cond_local_irq_enable(regs);
> @@ -242,9 +217,43 @@ static inline void handle_invalid_op(struct pt_regs
> *regs)
> ILL_ILLOPN, error_get_trap_addr(regs));
> }
>
> -DEFINE_IDTENTRY(exc_invalid_op)
> +DEFINE_IDTENTRY_RAW(exc_invalid_op)
> {
> + bool rcu_exit;
> +
> + /*
> +* Handle BUG/WARN like NMIs instead of like normal idtentries:
> +* if we bugged/warned in a bad RCU context, for example, the last
> +* thing we want is to BUG/WARN again in the idtentry code, ad
> +* infinitum.
> +*/
> + if (!user_mode(regs) && is_valid_bugaddr(regs->ip)) {
> + enum bug_trap_type type;
> +
> + nmi_enter();
> + instrumentation_begin();
> + type = report_bug(regs->ip, regs);
> + instrumentation_end();
> + nmi_exit();
Hmm, maybe this should be:
nmi_enter();
instrumentation_begin();
trace_hardirqs_off_finish();
type = report_bug(regs->ip, regs);
if (regs->flags & X86_EFLAGS_IF)
trace_hardirqs_on_prepare();
instrumentation_end();
nmi_exit();
tglx or peterz, feel free to fix this up and apply it however you like.
linux-next: Fixes tag needs some work in the drm-msm tree
Hi all,
In commit
5fddd4f5db87 ("drm/msm/dpu: request for display color blocks based on hw
catalog entry")
Fixes tag
Fixes: e47616df008b ("drm/msm/dpu: add support for color processing
has these problem(s):
- Subject has leading but no trailing parentheses
- Subject has leading but no trailing quotes
Please do not truncate Fixes tags or split them over more than one line.
Fixes: e47616df008b ("drm/msm/dpu: add support for color processing blocks in
dpu driver")
--
Cheers,
Stephen Rothwell
pgpN1EHIhZeN0.pgp
Description: OpenPGP digital signature
Re: [RFC] MFD's relationship with Device Tree (OF)
Hi Lee,
On 2020-06-09 06:01, Lee Jones wrote:
> Good morning,
>
> After a number of reports/queries surrounding a known long-term issue
> in the MFD core, including the submission of a couple of attempted
> solutions, I've decided to finally tackle this one myself.
>
> Currently, when a child platform device (sometimes referred to as a
> sub-device) is registered via the Multi-Functional Device (MFD) API,
> the framework attempts to match the newly registered platform device
> with its associated Device Tree (OF) node. Until now, the device has
> been allocated the first node found with an identical OF compatible
> string. Unfortunately, if there are, say for example '3' devices
> which are to be handled by the same driver and therefore have the same
> compatible string, each of them will be allocated a pointer to the
> *first* node.
>
> Let me give you an example.
>
> I have knocked up an example 'parent' and 'child' device driver. The
> parent utilises the MFD API to register 3 identical children, each
> controlled by the same driver. This happens a lot. Fortunately, in
> the majority of cases, the OF nodes are also totally identical, but
> what if you wish to configure one of the child devices with different
> attributes or resources supplied via Device Tree, like a clock? This
> is currently impossible.
>
> Here is the Device Tree representation for the 1 parent and the 3
> child (sub) devices described above:
>
> parent {
> compatible = "mfd,of-test-parent";
>
> child@0 {
> compatible = "mfd,of-test-child";
> clocks = < 0>;
> };
>
> child@1 {
> compatible = "mfd,of-test-child";
> clocks = < 1>;
> };
>
> child@2 {
> compatible = "mfd,of-test-child";
> clocks = < 2>;
> };
> };
>
> This is how we register those devices from MFD:
>
> static const struct mfd_cell mfd_of_test_cell[] = {
> OF_MFD_CELL("mfd_of_test_child", NULL, NULL, 0, 0,
> "mfd,of-test-child"),
> OF_MFD_CELL("mfd_of_test_child", NULL, NULL, 0, 1,
> "mfd,of-test-child"),
> OF_MFD_CELL("mfd_of_test_child", NULL, NULL, 0, 2, "mfd,of-test-child")
> };
>
> ... which we pass into mfd_add_devices() for processing.
>
> In an ideal world. The devices with the platform_id; 0, 1 and 2 would
> be matched up to Device Tree nodes; child@0, child@1 and child@2
> respectively. Instead all 3 devices will be allocated a pointer to
> child@0's OF node, which is obviously not correct.
>
> This is how it looks when each of the child devices are probed:
>
> [0.708287] mfd-of-test-parent mfd_of_test: Registering 3 devices
> [...]
> [0.712511] mfd-of-test-child mfd_of_test_child.0: Probing platform device: 0
> [0.712710] mfd-of-test-child mfd_of_test_child.0: Using OF node: child@0
> [0.713033] mfd-of-test-child mfd_of_test_child.1: Probing platform device: 1
> [0.713381] mfd-of-test-child mfd_of_test_child.1: Using OF node: child@0
> [0.713691] mfd-of-test-child mfd_of_test_child.2: Probing platform device: 2
> [0.713889] mfd-of-test-child mfd_of_test_child.2: Using OF node: child@0
>
> "Why is it when I change child 2's clock rate, it also changes 0's?"
>
> Whoops!
>
> So in order to fix this, we need to make MFD more-cleverer!
>
> However, this is not so simple. There are some rules we should abide
> by (I use "should" intentionally here, as something might just have to
> give):
>
> a) Since Device Tree is designed to describe hardware, inserting
> arbitrary properties into DT is forbidden. This precludes things
> we would ordinarily be able to match on, like 'id' or 'name'.
> b) As an extension to a) DTs should also be OS agnostic, so
> properties like 'mfd-device', 'mfd-order' etc are also not
> not suitable for inclusion.
> c) The final solution should ideally be capable of supporting both
> newly defined and current trees (without retroactive edits)
> alike.
> d) Existing properties could be used, but not abused. For example,
> one of my suggestions (see below) is to use the 'reg' property.
> This is fine in principle but loading 'reg' with arbitrary values
> (such as; 0, 1, 2 ... x) which 1) clearly do not have anything to
> do with registers and 2) would be meaningless in other OSes/
> implementations, just to serve our purpose, is to be interpreted
> as an abuse.
>
> Proposal 1:
>
> As mentioned above, my initial thoughts were to use the 'reg' property
> to match an MFD cell entry with the correct DT node. However, not
> all Device Tree nodes have 'reg' properties. Particularly true in the
> case of MFD, where memory resources are usually shared with the parent
> via Regmap, or (as in the case of the ab8500) the MFD handles all
> register transactions via its own API.
>
>
linux-next: Fixes tag needs some work in the ext4 tree
Hi all,
In commit
811985365378 ("ext4: mballoc: Use this_cpu_read instead of this_cpu_ptr")
Fixes tag
Fixes: 42f56b7a4a7d ("ext4: mballoc: introduce pcpu seqcnt for freeing PA
has these problem(s):
- Subject has leading but no trailing parentheses
- Subject has leading but no trailing quotes
Please do not split Fixes tags over more than one line.
--
Cheers,
Stephen Rothwell
pgplDxfREZOaN.pgp
Description: OpenPGP digital signature
Re: [RFC] MFD's relationship with Device Tree (OF)
Hi Lee,
Please add me to the distribution list for future versions of this.
-Frank
On 2020-06-09 06:01, Lee Jones wrote:
> Good morning,
>
> After a number of reports/queries surrounding a known long-term issue
> in the MFD core, including the submission of a couple of attempted
> solutions, I've decided to finally tackle this one myself.
>
> Currently, when a child platform device (sometimes referred to as a
> sub-device) is registered via the Multi-Functional Device (MFD) API,
> the framework attempts to match the newly registered platform device
> with its associated Device Tree (OF) node. Until now, the device has
> been allocated the first node found with an identical OF compatible
> string. Unfortunately, if there are, say for example '3' devices
> which are to be handled by the same driver and therefore have the same
> compatible string, each of them will be allocated a pointer to the
> *first* node.
>
> Let me give you an example.
>
> I have knocked up an example 'parent' and 'child' device driver. The
> parent utilises the MFD API to register 3 identical children, each
> controlled by the same driver. This happens a lot. Fortunately, in
> the majority of cases, the OF nodes are also totally identical, but
> what if you wish to configure one of the child devices with different
> attributes or resources supplied via Device Tree, like a clock? This
> is currently impossible.
>
> Here is the Device Tree representation for the 1 parent and the 3
> child (sub) devices described above:
>
> parent {
> compatible = "mfd,of-test-parent";
>
> child@0 {
> compatible = "mfd,of-test-child";
> clocks = < 0>;
> };
>
> child@1 {
> compatible = "mfd,of-test-child";
> clocks = < 1>;
> };
>
> child@2 {
> compatible = "mfd,of-test-child";
> clocks = < 2>;
> };
> };
>
> This is how we register those devices from MFD:
>
> static const struct mfd_cell mfd_of_test_cell[] = {
> OF_MFD_CELL("mfd_of_test_child", NULL, NULL, 0, 0,
> "mfd,of-test-child"),
> OF_MFD_CELL("mfd_of_test_child", NULL, NULL, 0, 1,
> "mfd,of-test-child"),
> OF_MFD_CELL("mfd_of_test_child", NULL, NULL, 0, 2, "mfd,of-test-child")
> };
>
> ... which we pass into mfd_add_devices() for processing.
>
> In an ideal world. The devices with the platform_id; 0, 1 and 2 would
> be matched up to Device Tree nodes; child@0, child@1 and child@2
> respectively. Instead all 3 devices will be allocated a pointer to
> child@0's OF node, which is obviously not correct.
>
> This is how it looks when each of the child devices are probed:
>
> [0.708287] mfd-of-test-parent mfd_of_test: Registering 3 devices
> [...]
> [0.712511] mfd-of-test-child mfd_of_test_child.0: Probing platform device: 0
> [0.712710] mfd-of-test-child mfd_of_test_child.0: Using OF node: child@0
> [0.713033] mfd-of-test-child mfd_of_test_child.1: Probing platform device: 1
> [0.713381] mfd-of-test-child mfd_of_test_child.1: Using OF node: child@0
> [0.713691] mfd-of-test-child mfd_of_test_child.2: Probing platform device: 2
> [0.713889] mfd-of-test-child mfd_of_test_child.2: Using OF node: child@0
>
> "Why is it when I change child 2's clock rate, it also changes 0's?"
>
> Whoops!
>
> So in order to fix this, we need to make MFD more-cleverer!
>
> However, this is not so simple. There are some rules we should abide
> by (I use "should" intentionally here, as something might just have to
> give):
>
> a) Since Device Tree is designed to describe hardware, inserting
> arbitrary properties into DT is forbidden. This precludes things
> we would ordinarily be able to match on, like 'id' or 'name'.
> b) As an extension to a) DTs should also be OS agnostic, so
> properties like 'mfd-device', 'mfd-order' etc are also not
> not suitable for inclusion.
> c) The final solution should ideally be capable of supporting both
> newly defined and current trees (without retroactive edits)
> alike.
> d) Existing properties could be used, but not abused. For example,
> one of my suggestions (see below) is to use the 'reg' property.
> This is fine in principle but loading 'reg' with arbitrary values
> (such as; 0, 1, 2 ... x) which 1) clearly do not have anything to
> do with registers and 2) would be meaningless in other OSes/
> implementations, just to serve our purpose, is to be interpreted
> as an abuse.
>
> Proposal 1:
>
> As mentioned above, my initial thoughts were to use the 'reg' property
> to match an MFD cell entry with the correct DT node. However, not
> all Device Tree nodes have 'reg' properties. Particularly true in the
> case of MFD, where memory resources are usually shared with the parent
> via Regmap, or (as in the case of the
[PATCH v6 3/3] regulator: Add driver for cros-ec-regulator
Add driver for cros-ec-regulator, representing a voltage regulator that
is connected and controlled by ChromeOS EC, and is controlled by kernel
with EC host commands.
Signed-off-by: Pi-Hsun Shih
Reviewed-by: Prashant Malani
Reviewed-by: Enric Balletbo i Serra
---
Changes from v5:
* Move introduction of new host command to a separate patch.
* Use devm_regulator_register.
* sizeof -> ARRAY_SIZE.
* Small whitespace change.
Changes from v4:
* Change compatible name from regulator-cros-ec to cros-ec-regulator.
Changes from v3:
* Remove check around CONFIG_OF.
* Add new host commands to cros_ec_trace.
* Use devm_kstrdup for duping regulator name.
* Change license header and add MODULE_AUTHOR.
* Address review comments.
Changes from v2:
* Add 'depends on OF' to Kconfig.
* Add Kconfig description about compiling as module.
Changes from v1:
* Change compatible string to google,regulator-cros-ec.
* Use reg property in device tree.
* Address comments on code styles.
This patch contains function cros_ec_cmd that is copied from the series:
https://lore.kernel.org/patchwork/project/lkml/list/?series=428457.
I can't find the first patch in that v2 series, so the function is
modified from v1 of that series according to reviewers comment:
https://lore.kernel.org/patchwork/patch/1188110/
I copied the function instead of depending on that series since I feel
the function is small enough, and the series has stalled for some time.
---
drivers/regulator/Kconfig | 10 +
drivers/regulator/Makefile| 1 +
drivers/regulator/cros-ec-regulator.c | 257 ++
3 files changed, 268 insertions(+)
create mode 100644 drivers/regulator/cros-ec-regulator.c
diff --git a/drivers/regulator/Kconfig b/drivers/regulator/Kconfig
index 8f677f5d79b4..c398e90e0e73 100644
--- a/drivers/regulator/Kconfig
+++ b/drivers/regulator/Kconfig
@@ -238,6 +238,16 @@ config REGULATOR_CPCAP
Say y here for CPCAP regulator found on some Motorola phones
and tablets such as Droid 4.
+config REGULATOR_CROS_EC
+ tristate "ChromeOS EC regulators"
+ depends on CROS_EC && OF
+ help
+ This driver supports voltage regulators that is connected to ChromeOS
+ EC and controlled through EC host commands.
+
+ This driver can also be built as a module. If so, the module
+ will be called cros-ec-regulator.
+
config REGULATOR_DA903X
tristate "Dialog Semiconductor DA9030/DA9034 regulators"
depends on PMIC_DA903X
diff --git a/drivers/regulator/Makefile b/drivers/regulator/Makefile
index e8f163371071..46592c160d22 100644
--- a/drivers/regulator/Makefile
+++ b/drivers/regulator/Makefile
@@ -13,6 +13,7 @@ obj-$(CONFIG_REGULATOR_USERSPACE_CONSUMER) +=
userspace-consumer.o
obj-$(CONFIG_REGULATOR_88PG86X) += 88pg86x.o
obj-$(CONFIG_REGULATOR_88PM800) += 88pm800-regulator.o
obj-$(CONFIG_REGULATOR_88PM8607) += 88pm8607.o
+obj-$(CONFIG_REGULATOR_CROS_EC) += cros-ec-regulator.o
obj-$(CONFIG_REGULATOR_CPCAP) += cpcap-regulator.o
obj-$(CONFIG_REGULATOR_AAT2870) += aat2870-regulator.o
obj-$(CONFIG_REGULATOR_AB3100) += ab3100.o
diff --git a/drivers/regulator/cros-ec-regulator.c
b/drivers/regulator/cros-ec-regulator.c
new file mode 100644
index ..35f97246bc48
--- /dev/null
+++ b/drivers/regulator/cros-ec-regulator.c
@@ -0,0 +1,257 @@
+// SPDX-License-Identifier: GPL-2.0-only
+//
+// Copyright 2020 Google LLC.
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+struct cros_ec_regulator_data {
+ struct regulator_desc desc;
+ struct regulator_dev *dev;
+ struct cros_ec_device *ec_dev;
+
+ u32 index;
+
+ u16 *voltages_mV;
+ u16 num_voltages;
+};
+
+static int cros_ec_cmd(struct cros_ec_device *ec, u32 version, u32 command,
+ void *outdata, u32 outsize, void *indata, u32 insize)
+{
+ struct cros_ec_command *msg;
+ int ret;
+
+ msg = kzalloc(sizeof(*msg) + max(outsize, insize), GFP_KERNEL);
+ if (!msg)
+ return -ENOMEM;
+
+ msg->version = version;
+ msg->command = command;
+ msg->outsize = outsize;
+ msg->insize = insize;
+
+ if (outdata && outsize > 0)
+ memcpy(msg->data, outdata, outsize);
+
+ ret = cros_ec_cmd_xfer_status(ec, msg);
+ if (ret < 0)
+ goto cleanup;
+
+ if (insize)
+ memcpy(indata, msg->data, insize);
+
+cleanup:
+ kfree(msg);
+ return ret;
+}
+
+static int cros_ec_regulator_enable(struct regulator_dev *dev)
+{
+ struct cros_ec_regulator_data *data = rdev_get_drvdata(dev);
+ struct ec_params_regulator_enable cmd = {
+ .index = data->index,
+ .enable = 1,
+ };
+
+ return cros_ec_cmd(data->ec_dev, 0, EC_CMD_REGULATOR_ENABLE, ,
+ sizeof(cmd), NULL, 0);
+}
+
+static int cros_ec_regulator_disable(struct regulator_dev
[PATCH v6 0/3] Add support for voltage regulator on ChromeOS EC.
Add support for controlling voltage regulator that is connected and controlled by ChromeOS EC. Kernel controls these regulators through newly added EC host commands. Changes from v5: * Move new host command to a separate patch. * Use devm_regulator_register. * Address review comments. Changes from v4: * Change compatible name from regulator-cros-ec to cros-ec-regulator. Changes from v3: * Fix dt bindings file name. * Remove check around CONFIG_OF in driver. * Add new host commands to cros_ec_trace. * Address review comments. Changes from v2: * Add 'depends on OF' to Kconfig. * Add Kconfig description about compiling as module. Changes from v1: * Change compatible string to google,regulator-cros-ec. * Use reg property in device tree. * Change license for dt binding according to checkpatch.pl. * Address comments on code styles. Pi-Hsun Shih (3): dt-bindings: regulator: Add DT binding for cros-ec-regulator platform/chrome: cros_ec: Add command for regulator control. regulator: Add driver for cros-ec-regulator .../regulator/google,cros-ec-regulator.yaml | 51 drivers/platform/chrome/cros_ec_trace.c | 5 + drivers/regulator/Kconfig | 10 + drivers/regulator/Makefile| 1 + drivers/regulator/cros-ec-regulator.c | 257 ++ .../linux/platform_data/cros_ec_commands.h| 82 ++ 6 files changed, 406 insertions(+) create mode 100644 Documentation/devicetree/bindings/regulator/google,cros-ec-regulator.yaml create mode 100644 drivers/regulator/cros-ec-regulator.c base-commit: b791d1bdf9212d944d749a5c7ff6febdba241771 -- 2.27.0.290.gba653c62da-goog
[PATCH v6 1/3] dt-bindings: regulator: Add DT binding for cros-ec-regulator
Add DT binding documentation for cros-ec-regulator, a voltage regulator
controlled by ChromeOS EC.
Signed-off-by: Pi-Hsun Shih
Reviewed-by: Enric Balletbo i Serra
---
Changes from v5:
* No change
Changes from v4:
* Change compatible name from regulator-cros-ec to cros-ec-regulator.
Changes from v3:
* Fix dt bindings file name.
* Add full example.
Changes from v2:
* No change
Changes from v1:
* Change compatible string to google,regulator-cros-ec.
* Use reg property in device tree.
* Change license for dt binding according to checkpatch.pl.
---
.../regulator/google,cros-ec-regulator.yaml | 51 +++
1 file changed, 51 insertions(+)
create mode 100644
Documentation/devicetree/bindings/regulator/google,cros-ec-regulator.yaml
diff --git
a/Documentation/devicetree/bindings/regulator/google,cros-ec-regulator.yaml
b/Documentation/devicetree/bindings/regulator/google,cros-ec-regulator.yaml
new file mode 100644
index ..c9453d7ce227
--- /dev/null
+++ b/Documentation/devicetree/bindings/regulator/google,cros-ec-regulator.yaml
@@ -0,0 +1,51 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/regulator/google,cros-ec-regulator.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: ChromeOS EC controlled voltage regulators
+
+maintainers:
+ - Pi-Hsun Shih
+
+description:
+ Any property defined as part of the core regulator binding, defined in
+ regulator.yaml, can also be used.
+
+allOf:
+ - $ref: "regulator.yaml#"
+
+properties:
+ compatible:
+const: google,cros-ec-regulator
+
+ reg:
+maxItems: 1
+description: Identifier for the voltage regulator to ChromeOS EC.
+
+required:
+ - compatible
+ - reg
+
+examples:
+ - |
+spi0 {
+#address-cells = <1>;
+#size-cells = <0>;
+
+cros_ec: ec@0 {
+compatible = "google,cros-ec-spi";
+reg = <0>;
+#address-cells = <1>;
+#size-cells = <0>;
+
+regulator@0 {
+compatible = "google,cros-ec-regulator";
+regulator-min-microvolt = <180>;
+regulator-max-microvolt = <330>;
+reg = <0>;
+};
+};
+};
+...
--
2.27.0.290.gba653c62da-goog
[PATCH v6 2/3] platform/chrome: cros_ec: Add command for regulator control.
Add host commands for voltage regulator control through ChromeOS EC.
Signed-off-by: Pi-Hsun Shih
Reviewed-by: Enric Balletbo i Serra
---
Changes from v5:
* Extract into a separate patch.
---
drivers/platform/chrome/cros_ec_trace.c | 5 ++
.../linux/platform_data/cros_ec_commands.h| 82 +++
2 files changed, 87 insertions(+)
diff --git a/drivers/platform/chrome/cros_ec_trace.c
b/drivers/platform/chrome/cros_ec_trace.c
index 523a39bd0ff6..425e9441b7ca 100644
--- a/drivers/platform/chrome/cros_ec_trace.c
+++ b/drivers/platform/chrome/cros_ec_trace.c
@@ -161,6 +161,11 @@
TRACE_SYMBOL(EC_CMD_ADC_READ), \
TRACE_SYMBOL(EC_CMD_ROLLBACK_INFO), \
TRACE_SYMBOL(EC_CMD_AP_RESET), \
+ TRACE_SYMBOL(EC_CMD_REGULATOR_GET_INFO), \
+ TRACE_SYMBOL(EC_CMD_REGULATOR_ENABLE), \
+ TRACE_SYMBOL(EC_CMD_REGULATOR_IS_ENABLED), \
+ TRACE_SYMBOL(EC_CMD_REGULATOR_SET_VOLTAGE), \
+ TRACE_SYMBOL(EC_CMD_REGULATOR_GET_VOLTAGE), \
TRACE_SYMBOL(EC_CMD_CR51_BASE), \
TRACE_SYMBOL(EC_CMD_CR51_LAST), \
TRACE_SYMBOL(EC_CMD_FP_PASSTHRU), \
diff --git a/include/linux/platform_data/cros_ec_commands.h
b/include/linux/platform_data/cros_ec_commands.h
index 69210881ebac..a417b51b5764 100644
--- a/include/linux/platform_data/cros_ec_commands.h
+++ b/include/linux/platform_data/cros_ec_commands.h
@@ -5430,6 +5430,88 @@ struct ec_response_rollback_info {
/* Issue AP reset */
#define EC_CMD_AP_RESET 0x0125
+/*/
+/* Voltage regulator controls */
+
+/*
+ * Get basic info of voltage regulator for given index.
+ *
+ * Returns the regulator name and supported voltage list in mV.
+ */
+#define EC_CMD_REGULATOR_GET_INFO 0x012B
+
+/* Maximum length of regulator name */
+#define EC_REGULATOR_NAME_MAX_LEN 16
+
+/* Maximum length of the supported voltage list. */
+#define EC_REGULATOR_VOLTAGE_MAX_COUNT 16
+
+struct ec_params_regulator_get_info {
+ uint32_t index;
+} __ec_align4;
+
+struct ec_response_regulator_get_info {
+ char name[EC_REGULATOR_NAME_MAX_LEN];
+ uint16_t num_voltages;
+ uint16_t voltages_mv[EC_REGULATOR_VOLTAGE_MAX_COUNT];
+} __ec_align1;
+
+/*
+ * Configure the regulator as enabled / disabled.
+ */
+#define EC_CMD_REGULATOR_ENABLE 0x012C
+
+struct ec_params_regulator_enable {
+ uint32_t index;
+ uint8_t enable;
+} __ec_align4;
+
+/*
+ * Query if the regulator is enabled.
+ *
+ * Returns 1 if the regulator is enabled, 0 if not.
+ */
+#define EC_CMD_REGULATOR_IS_ENABLED 0x012D
+
+struct ec_params_regulator_is_enabled {
+ uint32_t index;
+} __ec_align4;
+
+struct ec_response_regulator_is_enabled {
+ uint8_t enabled;
+} __ec_align1;
+
+/*
+ * Set voltage for the voltage regulator within the range specified.
+ *
+ * The driver should select the voltage in range closest to min_mv.
+ *
+ * Also note that this might be called before the regulator is enabled, and the
+ * setting should be in effect after the regulator is enabled.
+ */
+#define EC_CMD_REGULATOR_SET_VOLTAGE 0x012E
+
+struct ec_params_regulator_set_voltage {
+ uint32_t index;
+ uint32_t min_mv;
+ uint32_t max_mv;
+} __ec_align4;
+
+/*
+ * Get the currently configured voltage for the voltage regulator.
+ *
+ * Note that this might be called before the regulator is enabled.
+ */
+#define EC_CMD_REGULATOR_GET_VOLTAGE 0x012F
+
+struct ec_params_regulator_get_voltage {
+ uint32_t index;
+} __ec_align4;
+
+struct ec_response_regulator_get_voltage {
+ uint32_t voltage_mv;
+} __ec_align4;
+
/*/
/* The command range 0x200-0x2FF is reserved for Rotor. */
--
2.27.0.290.gba653c62da-goog
Re: [PATCH -tip v3 1/2] kcov: Make runtime functions noinstr-compatible
On Thu, Jun 11, 2020 at 11:55 PM Peter Zijlstra wrote:
>
> On Mon, Jun 08, 2020 at 01:01:08PM +0200, Peter Zijlstra wrote:
> > On Mon, Jun 08, 2020 at 09:57:39AM +0200, Dmitry Vyukov wrote:
> >
> > > As a crazy idea: is it possible to employ objtool (linker script?) to
> > > rewrite all coverage calls to nops in the noinstr section? Or relocate
> > > to nop function?
> > > What we are trying to do is very static, it _should_ have been done
> > > during build. We don't have means in existing _compilers_ to do this,
> > > but maybe we could do it elsewhere during build?...
> >
> > Let me try and figure out how to make objtool actually rewrite code.
>
> The below is quite horrific but seems to sorta work.
>
> It turns this:
>
> 12: e8 00 00 00 00 callq 17
> 13: R_X86_64_PLT32 __sanitizer_cov_trace_pc-0x4
>
> Into this:
>
> 12: 90 nop
> 13: 90 nop
> 13: R_X86_64_NONE __sanitizer_cov_trace_pc-0x4
> 14: 90 nop
> 15: 90 nop
> 16: 90 nop
>
>
> I'll have to dig around a little more to see if I can't get rid of the
> relocation entirely. Also, I need to steal better arch_nop_insn() from
> the kernel :-)
Wow! Cool!
Thanks for resolving this. I guess this can be used to wipe more
unwanted things in future :)
Marco double checked and his patch did not actually fix the existing
crash under KCSAN. The call itself was the problem or something,
returning early did not really help. This should hopefully fix it.
Marco, please double check.
Re better nop insn, I don't know how much work it is (or how much you
are striving for perfection :)). But from KCOV point of view, I think
we can live with more or less any nop insn. The main thing was
removing overhead from all other (not noinstr) cases, I would assume
the noinstr cases where we use nops are very rare. I mean don't spend
too much time on it, if it's not needed for something else.
Thanks again!
> ---
> tools/objtool/arch.h| 2 ++
> tools/objtool/arch/x86/decode.c | 24 ++
> tools/objtool/check.c | 15 +-
> tools/objtool/elf.c | 45
> -
> tools/objtool/elf.h | 11 --
> 5 files changed, 93 insertions(+), 4 deletions(-)
>
> diff --git a/tools/objtool/arch.h b/tools/objtool/arch.h
> index eda15a5a285e..3c5967748abb 100644
> --- a/tools/objtool/arch.h
> +++ b/tools/objtool/arch.h
> @@ -84,4 +84,6 @@ unsigned long arch_jump_destination(struct instruction
> *insn);
>
> unsigned long arch_dest_rela_offset(int addend);
>
> +const char *arch_nop_insn(int len);
> +
> #endif /* _ARCH_H */
> diff --git a/tools/objtool/arch/x86/decode.c b/tools/objtool/arch/x86/decode.c
> index 4b504fc90bbb..b615c32e21db 100644
> --- a/tools/objtool/arch/x86/decode.c
> +++ b/tools/objtool/arch/x86/decode.c
> @@ -565,3 +565,27 @@ void arch_initial_func_cfi_state(struct cfi_init_state
> *state)
> state->regs[16].base = CFI_CFA;
> state->regs[16].offset = -8;
> }
> +
> +const char *arch_nop_insn(int len)
> +{
> + static const char insn[16] = {
> + 0x90,
> + 0x90,
> + 0x90,
> + 0x90,
> + 0x90,
> + 0x90,
> + 0x90,
> + 0x90,
> + 0x90,
> + 0x90,
> + 0x90,
> + 0x90,
> + 0x90,
> + 0x90,
> + 0x90,
> + 0x90,
> + };
> +
> + return insn;
> +}
> diff --git a/tools/objtool/check.c b/tools/objtool/check.c
> index 5fbb90a80d23..487b4dc3d122 100644
> --- a/tools/objtool/check.c
> +++ b/tools/objtool/check.c
> @@ -765,6 +765,17 @@ static int add_call_destinations(struct objtool_file
> *file)
> } else
> insn->call_dest = rela->sym;
>
> + if (insn->sec->noinstr &&
> + !strncmp(insn->call_dest->name, "__sanitizer_cov_", 16)) {
> + if (rela)
> + elf_write_rela(file->elf, rela);
> +
> + elf_write_insn(file->elf, insn->sec,
> + insn->offset, insn->len,
> + arch_nop_insn(insn->len));
> + insn->type = INSN_NOP;
> + }
> +
> /*
> * Whatever stack impact regular CALLs have, should be undone
> * by the RETURN of the called function.
> @@ -2802,11 +2813,13 @@ int check(const char *_objname, bool orc)
> if (ret < 0)
> goto out;
>
> + }
> +
> + if (file.elf->changed) {
> ret = elf_write(file.elf);
> if (ret < 0)
> goto out;
> }
> -
>
Good Day!
Dear how are you, How Are You? I Know That This Mail May Come To You Almost A Surprise As We Never Met Before And Please Before You Proceed Reading This mail,This Is True and not An Well I Saw Your Contact Email From Yahoo Search when I Was Looking For a Foreign Partner, please I don’t now if you can keep secret? A word of your own as a human-being? As I have gone through your profile.Well I have a deal worth 15.5m$ from the dormant account in the bank where I am working.so Please if you can keep secret, I will give you more details and the nest thing to do, Also all the documents that will back you up must send to you. Meanwhile before I contact you I have done every underground work through the documents of the deceases person, I have put or attachment his file to our favor. Also with my position every thing works successfully. Your Full Name, Phone No…., Receiver Country.., Occupation.., thanks for your understandplease contact me base if you can control this fund once it transferinto your account before my family and I will arriver in your country for the sharing, 40% for you. 10% for the poorest, rest is for me. Give me your Phone number Let me call you so that we can talk one and one You should contact me immediately as soon as you receive this letter,if only you are interested and ready to help On this Contact me. through my private email address(abd747...@gmail.com)Trusting to hear from you immediately. Do keep this a top secret for security reasons. Yours faithfully, MR.Abd Manaf.
[PATCH v4 2/2] phy: intel: Add Keem Bay eMMC PHY support
Add support for eMMC PHY on Intel Keem Bay SoC.
Signed-off-by: Wan Ahmad Zainie
---
drivers/phy/intel/Kconfig| 8 +
drivers/phy/intel/Makefile | 1 +
drivers/phy/intel/phy-keembay-emmc.c | 316 +++
3 files changed, 325 insertions(+)
create mode 100644 drivers/phy/intel/phy-keembay-emmc.c
diff --git a/drivers/phy/intel/Kconfig b/drivers/phy/intel/Kconfig
index 7b47682a4e0e..5f5497d1624a 100644
--- a/drivers/phy/intel/Kconfig
+++ b/drivers/phy/intel/Kconfig
@@ -22,3 +22,11 @@ config PHY_INTEL_EMMC
select GENERIC_PHY
help
Enable this to support the Intel EMMC PHY
+
+config PHY_KEEMBAY_EMMC
+ tristate "Intel Keem Bay EMMC PHY Driver"
+ depends on OF
+ select GENERIC_PHY
+ select REGMAP_MMIO
+ help
+ Enable this to support the Keem Bay EMMC PHY.
diff --git a/drivers/phy/intel/Makefile b/drivers/phy/intel/Makefile
index 233d530dadde..6566334e7b77 100644
--- a/drivers/phy/intel/Makefile
+++ b/drivers/phy/intel/Makefile
@@ -1,3 +1,4 @@
# SPDX-License-Identifier: GPL-2.0
obj-$(CONFIG_PHY_INTEL_COMBO) += phy-intel-combo.o
obj-$(CONFIG_PHY_INTEL_EMMC)+= phy-intel-emmc.o
+obj-$(CONFIG_PHY_KEEMBAY_EMMC) += phy-keembay-emmc.o
diff --git a/drivers/phy/intel/phy-keembay-emmc.c
b/drivers/phy/intel/phy-keembay-emmc.c
new file mode 100644
index ..68a0e0be7d3c
--- /dev/null
+++ b/drivers/phy/intel/phy-keembay-emmc.c
@@ -0,0 +1,316 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Intel Keem Bay eMMC PHY driver
+ * Copyright (C) 2020 Intel Corporation
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+/* eMMC/SD/SDIO core/phy configuration registers */
+#define PHY_CFG_0 0x24
+#define SEL_DLY_TXCLK_MASKBIT(29)
+#define SEL_DLY_TXCLK(x) (((x) << 29) & SEL_DLY_TXCLK_MASK)
+#define OTAP_DLY_ENA_MASK BIT(27)
+#define OTAP_DLY_ENA(x) (((x) << 27) & OTAP_DLY_ENA_MASK)
+#define OTAP_DLY_SEL_MASK GENMASK(26, 23)
+#define OTAP_DLY_SEL(x) (((x) << 23) & OTAP_DLY_SEL_MASK)
+#define DLL_EN_MASK BIT(10)
+#define DLL_EN(x) (((x) << 10) & DLL_EN_MASK)
+#define PWR_DOWN_MASK BIT(0)
+#define PWR_DOWN(x) (((x) << 0) & PWR_DOWN_MASK)
+
+#define PHY_CFG_2 0x2c
+#define SEL_FREQ_MASK GENMASK(12, 10)
+#define SEL_FREQ(x) (((x) << 10) & SEL_FREQ_MASK)
+
+#define PHY_STAT 0x40
+#define CAL_DONE_MASK BIT(6)
+#define IS_CALDONE(x) ((x) & CAL_DONE_MASK)
+#define DLL_RDY_MASK BIT(5)
+#define IS_DLLRDY(x) ((x) & DLL_RDY_MASK)
+
+/* From ACS_eMMC51_16nFFC_RO1100_Userguide_v1p0.pdf p17 */
+#define FREQSEL_200M_170M 0x0
+#define FREQSEL_170M_140M 0x1
+#define FREQSEL_140M_110M 0x2
+#define FREQSEL_110M_80M 0x3
+#define FREQSEL_80M_50M0x4
+
+struct keembay_emmc_phy {
+ struct regmap *syscfg;
+ struct clk *emmcclk;
+};
+
+static const struct regmap_config keembay_regmap_config = {
+ .reg_bits = 32,
+ .val_bits = 32,
+ .reg_stride = 4,
+};
+
+static int keembay_emmc_phy_power(struct phy *phy, bool on_off)
+{
+ struct keembay_emmc_phy *priv = phy_get_drvdata(phy);
+ unsigned int caldone;
+ unsigned int dllrdy;
+ unsigned int freqsel;
+ unsigned int mhz;
+ int ret;
+
+ /*
+* Keep phyctrl_pdb and phyctrl_endll low to allow
+* initialization of CALIO state M/C DFFs
+*/
+ ret = regmap_update_bits(priv->syscfg, PHY_CFG_0, PWR_DOWN_MASK,
+PWR_DOWN(0));
+ if (ret) {
+ dev_err(>dev, "CALIO power down bar failed: %d\n", ret);
+ return ret;
+ }
+
+ ret = regmap_update_bits(priv->syscfg, PHY_CFG_0, DLL_EN_MASK,
+DLL_EN(0));
+ if (ret) {
+ dev_err(>dev, "turn off the dll failed: %d\n", ret);
+ return ret;
+ }
+
+ /* Already finish power off above */
+ if (!on_off)
+ return 0;
+
+ mhz = DIV_ROUND_CLOSEST(clk_get_rate(priv->emmcclk), 100);
+ if (mhz <= 200 && mhz >= 170)
+ freqsel = FREQSEL_200M_170M;
+ else if (mhz <= 170 && mhz >= 140)
+ freqsel = FREQSEL_170M_140M;
+ else if (mhz <= 140 && mhz >= 110)
+ freqsel = FREQSEL_140M_110M;
+ else if (mhz <= 110 && mhz >= 80)
+ freqsel = FREQSEL_110M_80M;
+ else if (mhz <= 80 && mhz >= 50)
+ freqsel = FREQSEL_80M_50M;
+ else
+ freqsel = 0x0;
+
+ if (mhz < 50 || mhz > 200)
+ dev_warn(>dev, "Unsupported rate: %d MHz\n", mhz);
+
+ /*
+* According to the user manual, calpad calibration
+* cycle takes more than 2us without the minimal recommended
+* value,
[PATCH v4 1/2] dt-bindings: phy: intel: Add Keem Bay eMMC PHY bindings
Binding description for Intel Keem Bay eMMC PHY.
Signed-off-by: Wan Ahmad Zainie
---
.../bindings/phy/intel,keembay-emmc-phy.yaml | 45 +++
1 file changed, 45 insertions(+)
create mode 100644
Documentation/devicetree/bindings/phy/intel,keembay-emmc-phy.yaml
diff --git a/Documentation/devicetree/bindings/phy/intel,keembay-emmc-phy.yaml
b/Documentation/devicetree/bindings/phy/intel,keembay-emmc-phy.yaml
new file mode 100644
index ..639f2b2d8950
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/intel,keembay-emmc-phy.yaml
@@ -0,0 +1,45 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+# Copyright 2020 Intel Corporation
+%YAML 1.2
+---
+$id: "http://devicetree.org/schemas/phy/intel,keembay-emmc-phy.yaml#;
+$schema: "http://devicetree.org/meta-schemas/core.yaml#;
+
+title: Intel Keem Bay eMMC PHY bindings
+
+maintainers:
+ - Wan Ahmad Zainie
+
+properties:
+ compatible:
+const: intel,keembay-emmc-phy
+
+ reg:
+maxItems: 1
+
+ clocks:
+maxItems: 1
+
+ clock-names:
+items:
+ - const: emmcclk
+
+ "#phy-cells":
+const: 0
+
+required:
+ - compatible
+ - reg
+ - "#phy-cells"
+
+additionalProperties: false
+
+examples:
+ - |
+phy@2029 {
+ compatible = "intel,keembay-emmc-phy";
+ reg = <0x2029 0x54>;
+ clocks = <>;
+ clock-names = "emmcclk";
+ #phy-cells = <0>;
+};
--
2.17.1
[PATCH v4 0/2] phy: intel: Add Keem Bay eMMC PHY support
Hi. The first part is to document DT bindings for Keem Bay eMMC PHY. The second is the driver file, loosely based on phy-rockchip-emmc.c and phy-intel-emmc.c. The latter is not being reused as there are quite a number of differences i.e. registers offset, supported clock rates, bitfield to set. The patch was tested with Keem Bay evaluation module board. Thank you. Best regards, Zainie Changes since v3: - Exit keembay_emmc_phy_power() with return ret;. - In keembay_emmc_phy_init(), use PTR_ERR_OR_ZERO(...). - In keembay_emmc_phy_probe(), devm_regmap_init_mmio(...) in single line. Changes since v2: - Modify DT example to use single cell for address and size. Changes since v1: - Rework phy-keembay-emmc.c to make it similar to phy-intel-emmc.c. - Use regmap_mmio, and remove reference to intel,syscon. - Use node name phy@ - Update license i.e. use dual license. Wan Ahmad Zainie (2): dt-bindings: phy: intel: Add Keem Bay eMMC PHY bindings phy: intel: Add Keem Bay eMMC PHY support .../bindings/phy/intel,keembay-emmc-phy.yaml | 45 +++ drivers/phy/intel/Kconfig | 8 + drivers/phy/intel/Makefile| 1 + drivers/phy/intel/phy-keembay-emmc.c | 316 ++ 4 files changed, 370 insertions(+) create mode 100644 Documentation/devicetree/bindings/phy/intel,keembay-emmc-phy.yaml create mode 100644 drivers/phy/intel/phy-keembay-emmc.c -- 2.17.1
Re: [RFC PATCH 4/5] scsi: ufs: L2P map management for HPB read
> > +static struct ufshpb_req *ufshpb_get_map_req(struct ufshpb_lu *hpb,
> > +struct ufshpb_subregion *srgn)
> > +{
> > + struct ufshpb_req *map_req;
> > + struct request *req;
> > + struct bio *bio;
> > +
> > + map_req = kmem_cache_alloc(hpb->map_req_cache, GFP_KERNEL);
> > + if (!map_req)
> > + return NULL;
> > +
> > + req = blk_get_request(hpb->sdev_ufs_lu->request_queue,
> > + REQ_OP_SCSI_IN, BLK_MQ_REQ_PREEMPT);
> > + if (IS_ERR(req))
> > + goto free_map_req;
> > +
> > + bio = bio_alloc(GFP_KERNEL, hpb->pages_per_srgn);
> > + if (!bio) {
> > + blk_put_request(req);
> > + goto free_map_req;
> > + }
> > +
> > + map_req->hpb = hpb;
> > + map_req->req = req;
> > + map_req->bio = bio;
> > +
> > + map_req->rgn_idx = srgn->rgn_idx;
> > + map_req->srgn_idx = srgn->srgn_idx;
> > + map_req->mctx = srgn->mctx;
> > + map_req->lun = hpb->lun;
> > +
> > + return map_req;
> > +free_map_req:
> > + kmem_cache_free(hpb->map_req_cache, map_req);
> > + return NULL;
> > +}
> Will blk_get_request() fail if all tags have been allocated? Can that
> cause a deadlock or infinite loop?
If the worker fails to receive the tag, it stops and exits. The remained
lists are processed again at the next work. Therefore, no deadlock or
infinite loop occurs.
> > +static inline void ufshpb_set_read_buf_cmd(unsigned char *cdb, int rgn_idx,
> > + int srgn_idx, int srgn_mem_size)
> > +{
> > + cdb[0] = UFSHPB_READ_BUFFER;
> > + cdb[1] = UFSHPB_READ_BUFFER_ID;
> > +
> > + put_unaligned_be32(srgn_mem_size, [5]);
> > + /* cdb[5] = 0x00; */
> > + put_unaligned_be16(rgn_idx, [2]);
> > + put_unaligned_be16(srgn_idx, [4]);
> > +
> > + cdb[9] = 0x00;
> > +}
> So the put_unaligned_be32(srgn_mem_size, [5]) comes first because
> the put_unaligned_be16(srgn_idx, [4]) overwrites byte cdb[5]? That
> is really ugly. Please use put_unaligned_be24() instead if that is what
> you meant and keep the put_*() calls in increasing cdb offset order.
OK, I will.
> > +static int ufshpb_map_req_add_bio_page(struct ufshpb_lu *hpb,
> > + struct request_queue *q, struct bio *bio,
> > + struct ufshpb_map_ctx *mctx)
> > +{
> > + int i, ret = 0;
> > +
> > + for (i = 0; i < hpb->pages_per_srgn; i++) {
> > + ret = bio_add_pc_page(q, bio, mctx->m_page[i], PAGE_SIZE, 0);
> > + if (ret != PAGE_SIZE) {
> > + dev_notice(>hpb_lu_dev,
> > + "bio_add_pc_page fail %d\n", ret);
> > + return -ENOMEM;
> > + }
> > + }
> > +
> > + return 0;
> > +}
> Why bio_add_pc_page() instead of bio_add_page()?
Since this map request is created under the block layer and it is a
passthrough command, I think bio_add_pc_page is a more suitable API than
bio_add_page. If bio_add_page is used in scsi LLD, the checking codes that
examine the max segment size in the block layer is not performed.
> > +static int ufshpb_execute_map_req(struct ufshpb_lu *hpb,
> > + struct ufshpb_req *map_req)
> > +{
> > + struct request_queue *q;
> > + struct request *req;
> > + struct scsi_request *rq;
> > + int ret = 0;
> > +
> > + q = hpb->sdev_ufs_lu->request_queue;
> > + ret = ufshpb_map_req_add_bio_page(hpb, q, map_req->bio,
> > + map_req->mctx);
> > + if (ret) {
> > + dev_notice(>hpb_lu_dev,
> > + "map_req_add_bio_page fail %d - %d\n",
> > + map_req->rgn_idx, map_req->srgn_idx);
> > + return ret;
> > + }
> > +
> > + req = map_req->req;
> > +
> > + blk_rq_append_bio(req, _req->bio);
> > + req->rq_flags |= RQF_QUIET;
> > + req->timeout = MAP_REQ_TIMEOUT;
> > + req->end_io_data = (void *)map_req;
> > +
> > + rq = scsi_req(req);
> > + ufshpb_set_read_buf_cmd(rq->cmd, map_req->rgn_idx,
> > + map_req->srgn_idx, hpb->srgn_mem_size);
> > + rq->cmd_len = HPB_READ_BUFFER_CMD_LENGTH;
> > +
> > + blk_execute_rq_nowait(q, NULL, req, 1, ufshpb_map_req_compl_fn);
> > +
> > + atomic_inc(>stats.map_req_cnt);
> > + return 0;
> > +}
> Why RQF_QUIET?
I refered scsi execute function. I will delete the needless flag.
> Why a custom timeout instead of the SCSI LUN timeout?
There was no suitable timeout value to use. I've included sd.h, so I'll
use sd_timeout.
> Can this function be made asynchronous such that it does not have to be
> executed on the context of a workqueue?
If this code doesn't work in your workq, map related task is handled in
interrupt context. Using workq, it avoids frequent active/inactive requests
to UFS devices by batched manner.
Thanks,
Daejun.
Re: [RFC PATCH 5/5] scsi: ufs: Prepare HPB read for cached sub-region
On 2020-06-04 18:38, Daejun Park wrote:
> > + if (total_srgn_cnt != 0) {
> > +dev_err(hba->dev, "ufshpb(%d) error total_subregion_count %d",
> > + hpb->lun, total_srgn_cnt);
> > +goto release_srgn_table;
> > + }
> > +
> > + return 0;
> > +release_srgn_table:
> > + for (i = 0; i < rgn_idx; i++) {
> > +rgn = rgn_table + i;
> > +if (rgn->srgn_tbl)
> > + kvfree(rgn->srgn_tbl);
> > + }
> Please insert a blank line above goto labels as is done in most of the
> kernel code.
OK, I will fix it.
> > +static struct device_attribute ufshpb_sysfs_entries[] = {
> > + __ATTR(hit_count, 0444, ufshpb_sysfs_show_hit_cnt, NULL),
> > + __ATTR(miss_count, 0444, ufshpb_sysfs_show_miss_cnt, NULL),
> > + __ATTR(rb_noti_count, 0444, ufshpb_sysfs_show_rb_noti_cnt, NULL),
> > + __ATTR(rb_active_count, 0444, ufshpb_sysfs_show_rb_active_cnt, NULL),
> > + __ATTR(rb_inactive_count, 0444, ufshpb_sysfs_show_rb_inactive_cnt,
> > + NULL),
> > + __ATTR(map_req_count, 0444, ufshpb_sysfs_show_map_req_cnt, NULL),
> > + __ATTR_NULL
> > +};
> Please use __ATTR_RO() where appropriate.
They are only readable attributes. So I changed the code to use __ATTR_RO.
> > +static int ufshpb_create_sysfs(struct ufs_hba *hba, struct ufshpb_lu *hpb)
> > +{
> > + struct device_attribute *attr;
> > + int ret;
> > +
> > + device_initialize(>hpb_lu_dev);
> > +
> > + ufshpb_stat_init(hpb);
> > +
> > + hpb->hpb_lu_dev.parent = get_device(>ufsf.hpb_dev);
> > + hpb->hpb_lu_dev.release = ufshpb_dev_release;
> > + dev_set_name(>hpb_lu_dev, "ufshpb_lu%d", hpb->lun);
> > +
> > + ret = device_add(>hpb_lu_dev);
> > + if (ret) {
> > +dev_err(hba->dev, "ufshpb(%d) device_add failed",
> > + hpb->lun);
> > +return -ENODEV;
> > + }
> > +
> > + for (attr = ufshpb_sysfs_entries; attr->attr.name != NULL; attr++) {
> > +if (device_create_file(>hpb_lu_dev, attr))
> > + dev_err(hba->dev, "ufshpb(%d) %s create file error\n",
> > +hpb->lun, attr->attr.name);
> > + }
> > +
> > + return 0;
> > +}
> This is the wrong way to create sysfs attributes. Please set the
> 'groups' member of struct device instead of using a loop to create sysfs
> attributes. The former approach is compatible with udev but the latter
> approach is not.
OK, I changed to create attributes without loop.
> > +static void ufshpb_probe_async(void *data, async_cookie_t cookie)
> > +{
> > + struct ufshpb_dev_info hpb_dev_info = { 0 };
> > + struct ufs_hba *hba = data;
> > + char *desc_buf;
> > + int ret;
> > +
> > + desc_buf = kzalloc(QUERY_DESC_MAX_SIZE, GFP_KERNEL);
> > + if (!desc_buf)
> > +goto release_desc_buf;
> > +
> > + ret = ufshpb_get_dev_info(hba, _dev_info, desc_buf);
> > + if (ret)
> > +goto release_desc_buf;
> > +
> > + /*
> > + * Because HPB driver uses scsi_device data structure,
> > + * we should wait at this point until finishing initialization of all
> > + * scsi devices. Even if timeout occurs, HPB driver will search
> > + * the scsi_device list on struct scsi_host (shost->__host list_head)
> > + * and can find out HPB logical units in all scsi_devices
> > + */
> > + wait_event_timeout(hba->ufsf.sdev_wait,
> > + (atomic_read(>ufsf.slave_conf_cnt)
> > +== hpb_dev_info.num_lu),
> > + SDEV_WAIT_TIMEOUT);
> > +
> > + dev_dbg(hba->dev, "ufshpb: slave count %d, lu count %d\n",
> > +atomic_read(>ufsf.slave_conf_cnt), hpb_dev_info.num_lu);
> > +
> > + ufshpb_scan_hpb_lu(hba, _dev_info, desc_buf);
> > +release_desc_buf:
> > + kfree(desc_buf);
> > +}
> What happens if two LUNs are added before the above code is woken up?
> Will that perhaps cause the wait_event_timeout() call to wait forever?
I don't think it is problem. I think that the wait_event_timeout() will
check the condition before waiting.
> > +static int ufshpb_probe(struct device *dev)
> > +{
> > + struct ufs_hba *hba;
> > + struct ufsf_feature_info *ufsf;
> > +
> > + if (dev->type != _dev_type)
> > +return -ENODEV;
> > +
> > + ufsf = container_of(dev, struct ufsf_feature_info, hpb_dev);
> > + hba = container_of(ufsf, struct ufs_hba, ufsf);
> > +
> > + async_schedule(ufshpb_probe_async, hba);
> > + return 0;
> > +}
> So this is an asynchronous probe that is not visible to the device
> driver core? Could the PROBE_PREFER_ASYNCHRONOUS flag have been used
> instead to make device probing asynchronous?
I added the PROBE_PREFER_ASYNCHRONOUS flag to code and changed it to probe
synchronously.
> > +static int ufshpb_remove(struct device *dev)
> > +{
> > + struct ufshpb_lu *hpb, *n_hpb;
> > + struct ufsf_feature_info *ufsf;
> > + struct scsi_device *sdev;
> > +
> > + ufsf = container_of(dev, struct ufsf_feature_info, hpb_dev);
> > +
> > + dev_set_drvdata(>hpb_dev, NULL);
> > +
> > + list_for_each_entry_safe(hpb, n_hpb, _drv.lh_hpb_lu,
> > + list_hpb_lu) {
> > +ufshpb_set_state(hpb, HPB_FAILED);
> > +
> > +sdev = hpb->sdev_ufs_lu;
> > +sdev->hostdata = NULL;
> > +
>
[PATCH v3] usb: usbtest: fix missing kfree(dev->buf) in usbtest_disconnect
From: Zqiang BUG: memory leak unreferenced object 0x888055046e00 (size 256): comm "kworker/2:9", pid 2570, jiffies 4294942129 (age 1095.500s) hex dump (first 32 bytes): 00 70 04 55 80 88 ff ff 18 bb 5a 81 ff ff ff ff .p.U..Z. f5 96 78 81 ff ff ff ff 37 de 8e 81 ff ff ff ff ..x.7... backtrace: [] kmemleak_alloc_recursive include/linux/kmemleak.h:43 [inline] [ ] slab_post_alloc_hook mm/slab.h:586 [inline] [ ] slab_alloc_node mm/slub.c:2786 [inline] [ ] slab_alloc mm/slub.c:2794 [inline] [ ] kmem_cache_alloc_trace+0x15e/0x2d0 mm/slub.c:2811 [<5c3c3381>] kmalloc include/linux/slab.h:555 [inline] [<5c3c3381>] usbtest_probe+0x286/0x19d0 drivers/usb/misc/usbtest.c:2790 [<1cec6910>] usb_probe_interface+0x2bd/0x870 drivers/usb/core/driver.c:361 [<7806c118>] really_probe+0x48d/0x8f0 drivers/base/dd.c:551 [ ] driver_probe_device+0xfc/0x2a0 drivers/base/dd.c:724 [<3ef66004>] __device_attach_driver+0x1b6/0x240 drivers/base/dd.c:831 [ ] bus_for_each_drv+0x14e/0x1e0 drivers/base/bus.c:431 [ ] __device_attach+0x1f9/0x350 drivers/base/dd.c:897 [<838b324a>] device_initial_probe+0x1a/0x20 drivers/base/dd.c:944 [<30d501c1>] bus_probe_device+0x1e1/0x280 drivers/base/bus.c:491 [<5bd7adef>] device_add+0x131d/0x1c40 drivers/base/core.c:2504 [ ] usb_set_configuration+0xe84/0x1ab0 drivers/usb/core/message.c:2030 [ ] generic_probe+0x6a/0xe0 drivers/usb/core/generic.c:210 [<98ade0f1>] usb_probe_device+0x90/0xd0 drivers/usb/core/driver.c:266 [<7806c118>] really_probe+0x48d/0x8f0 drivers/base/dd.c:551 [ ] driver_probe_device+0xfc/0x2a0 drivers/base/dd.c:724 Acked-by: Alan Stern Reported-by: Kyungtae Kim Signed-off-by: Zqiang --- v1->v2: Remove Fixes field. v2->v3: Add Acked-by tags. drivers/usb/misc/usbtest.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/usb/misc/usbtest.c b/drivers/usb/misc/usbtest.c index 98ada1a3425c..bae88893ee8e 100644 --- a/drivers/usb/misc/usbtest.c +++ b/drivers/usb/misc/usbtest.c @@ -2873,6 +2873,7 @@ static void usbtest_disconnect(struct usb_interface *intf) usb_set_intfdata(intf, NULL); dev_dbg(>dev, "disconnect\n"); + kfree(dev->buf); kfree(dev); } -- 2.24.1
Re: [PATCH 6/6] spi: altera: fix size mismatch on 64 bit processors
On Thu, Jun 11, 2020 at 12:04:08PM +0100, Mark Brown wrote: > On Thu, Jun 11, 2020 at 11:25:11AM +0800, Xu Yilun wrote: > > From: Matthew Gerlach > > > > The spi-altera driver was originally written with a 32 > > bit processor, where sizeof(unsigned long) is 4. On a > > 64 bit processor sizeof(unsigned long) is 8. Change the structure > > member to u32 to match the actual size of the control > > register. > > > > Signed-off-by: Matthew Gerlach > > --- > > You've not provided a Signed-off-by for this, I can't do anything with > it. For details on what Signed-off-by means and why it's important > please see Documentation/process/submitting-patches.rst. Thanks for your explanation. I'll add my Signed-off-by.
[PATCH v2 0/2] Some improvements for iommu
Hi, The first patch masks some functions as static, and the second patch changes to use the gfp parameter from iommu_ops->map() to allocate ARM page pages. Any comments are welcome. Thanks. Changes from v1: - Fix the building errors when enabling CONFIG_IOMMU_IO_PGTABLE_LPAE_SELFTEST Baolin Wang (2): iommu: Mark __iommu_map/__iommu_map_sg as static iommu: Add gfp parameter to io_pgtable_ops->map() drivers/gpu/drm/panfrost/panfrost_mmu.c | 2 +- drivers/iommu/arm-smmu-v3.c | 2 +- drivers/iommu/arm-smmu.c| 2 +- drivers/iommu/io-pgtable-arm-v7s.c | 18 +- drivers/iommu/io-pgtable-arm.c | 18 +- drivers/iommu/iommu.c | 10 +- drivers/iommu/ipmmu-vmsa.c | 2 +- drivers/iommu/msm_iommu.c | 2 +- drivers/iommu/mtk_iommu.c | 2 +- drivers/iommu/qcom_iommu.c | 2 +- include/linux/io-pgtable.h | 2 +- 11 files changed, 31 insertions(+), 31 deletions(-) -- 1.8.3.1
[PATCH v2 1/2] iommu: Mark __iommu_map/__iommu_map_sg as static
Now the __iommu_map() and __iommu_map_sg() are used only in iommu.c
file, so mark them as static.
Signed-off-by: Baolin Wang
---
drivers/iommu/iommu.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
index 8584f48..14eca9f 100644
--- a/drivers/iommu/iommu.c
+++ b/drivers/iommu/iommu.c
@@ -2174,8 +2174,8 @@ static size_t iommu_pgsize(struct iommu_domain *domain,
return pgsize;
}
-int __iommu_map(struct iommu_domain *domain, unsigned long iova,
- phys_addr_t paddr, size_t size, int prot, gfp_t gfp)
+static int __iommu_map(struct iommu_domain *domain, unsigned long iova,
+ phys_addr_t paddr, size_t size, int prot, gfp_t gfp)
{
const struct iommu_ops *ops = domain->ops;
unsigned long orig_iova = iova;
@@ -2325,9 +2325,9 @@ size_t iommu_unmap_fast(struct iommu_domain *domain,
}
EXPORT_SYMBOL_GPL(iommu_unmap_fast);
-size_t __iommu_map_sg(struct iommu_domain *domain, unsigned long iova,
- struct scatterlist *sg, unsigned int nents, int prot,
- gfp_t gfp)
+static size_t __iommu_map_sg(struct iommu_domain *domain, unsigned long iova,
+struct scatterlist *sg, unsigned int nents, int
prot,
+gfp_t gfp)
{
size_t len = 0, mapped = 0;
phys_addr_t start;
--
1.8.3.1
[PATCH v2 2/2] iommu: Add gfp parameter to io_pgtable_ops->map()
Now the ARM page tables are always allocated by GFP_ATOMIC parameter,
but the iommu_ops->map() function has been added a gfp_t parameter by
commit 781ca2de89ba ("iommu: Add gfp parameter to iommu_ops::map"),
thus io_pgtable_ops->map() should use the gfp parameter passed from
iommu_ops->map() to allocate page pages, which can avoid wasting the
memory allocators atomic pools for some non-atomic contexts.
Signed-off-by: Baolin Wang
---
drivers/gpu/drm/panfrost/panfrost_mmu.c | 2 +-
drivers/iommu/arm-smmu-v3.c | 2 +-
drivers/iommu/arm-smmu.c| 2 +-
drivers/iommu/io-pgtable-arm-v7s.c | 18 +-
drivers/iommu/io-pgtable-arm.c | 18 +-
drivers/iommu/ipmmu-vmsa.c | 2 +-
drivers/iommu/msm_iommu.c | 2 +-
drivers/iommu/mtk_iommu.c | 2 +-
drivers/iommu/qcom_iommu.c | 2 +-
include/linux/io-pgtable.h | 2 +-
10 files changed, 26 insertions(+), 26 deletions(-)
diff --git a/drivers/gpu/drm/panfrost/panfrost_mmu.c
b/drivers/gpu/drm/panfrost/panfrost_mmu.c
index ed28aeb..5a39eee 100644
--- a/drivers/gpu/drm/panfrost/panfrost_mmu.c
+++ b/drivers/gpu/drm/panfrost/panfrost_mmu.c
@@ -262,7 +262,7 @@ static int mmu_map_sg(struct panfrost_device *pfdev, struct
panfrost_mmu *mmu,
while (len) {
size_t pgsize = get_pgsize(iova | paddr, len);
- ops->map(ops, iova, paddr, pgsize, prot);
+ ops->map(ops, iova, paddr, pgsize, prot, GFP_KERNEL);
iova += pgsize;
paddr += pgsize;
len -= pgsize;
diff --git a/drivers/iommu/arm-smmu-v3.c b/drivers/iommu/arm-smmu-v3.c
index f578677..7b59f06 100644
--- a/drivers/iommu/arm-smmu-v3.c
+++ b/drivers/iommu/arm-smmu-v3.c
@@ -2850,7 +2850,7 @@ static int arm_smmu_map(struct iommu_domain *domain,
unsigned long iova,
if (!ops)
return -ENODEV;
- return ops->map(ops, iova, paddr, size, prot);
+ return ops->map(ops, iova, paddr, size, prot, gfp);
}
static size_t arm_smmu_unmap(struct iommu_domain *domain, unsigned long iova,
diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
index 243bc4c..dc1d253 100644
--- a/drivers/iommu/arm-smmu.c
+++ b/drivers/iommu/arm-smmu.c
@@ -1227,7 +1227,7 @@ static int arm_smmu_map(struct iommu_domain *domain,
unsigned long iova,
return -ENODEV;
arm_smmu_rpm_get(smmu);
- ret = ops->map(ops, iova, paddr, size, prot);
+ ret = ops->map(ops, iova, paddr, size, prot, gfp);
arm_smmu_rpm_put(smmu);
return ret;
diff --git a/drivers/iommu/io-pgtable-arm-v7s.c
b/drivers/iommu/io-pgtable-arm-v7s.c
index 4272fe4..a688f22 100644
--- a/drivers/iommu/io-pgtable-arm-v7s.c
+++ b/drivers/iommu/io-pgtable-arm-v7s.c
@@ -470,7 +470,7 @@ static arm_v7s_iopte arm_v7s_install_table(arm_v7s_iopte
*table,
static int __arm_v7s_map(struct arm_v7s_io_pgtable *data, unsigned long iova,
phys_addr_t paddr, size_t size, int prot,
-int lvl, arm_v7s_iopte *ptep)
+int lvl, arm_v7s_iopte *ptep, gfp_t gfp)
{
struct io_pgtable_cfg *cfg = >iop.cfg;
arm_v7s_iopte pte, *cptep;
@@ -491,7 +491,7 @@ static int __arm_v7s_map(struct arm_v7s_io_pgtable *data,
unsigned long iova,
/* Grab a pointer to the next level */
pte = READ_ONCE(*ptep);
if (!pte) {
- cptep = __arm_v7s_alloc_table(lvl + 1, GFP_ATOMIC, data);
+ cptep = __arm_v7s_alloc_table(lvl + 1, gfp, data);
if (!cptep)
return -ENOMEM;
@@ -512,11 +512,11 @@ static int __arm_v7s_map(struct arm_v7s_io_pgtable *data,
unsigned long iova,
}
/* Rinse, repeat */
- return __arm_v7s_map(data, iova, paddr, size, prot, lvl + 1, cptep);
+ return __arm_v7s_map(data, iova, paddr, size, prot, lvl + 1, cptep,
gfp);
}
static int arm_v7s_map(struct io_pgtable_ops *ops, unsigned long iova,
- phys_addr_t paddr, size_t size, int prot)
+ phys_addr_t paddr, size_t size, int prot, gfp_t gfp)
{
struct arm_v7s_io_pgtable *data = io_pgtable_ops_to_data(ops);
struct io_pgtable *iop = >iop;
@@ -530,7 +530,7 @@ static int arm_v7s_map(struct io_pgtable_ops *ops, unsigned
long iova,
paddr >= (1ULL << data->iop.cfg.oas)))
return -ERANGE;
- ret = __arm_v7s_map(data, iova, paddr, size, prot, 1, data->pgd);
+ ret = __arm_v7s_map(data, iova, paddr, size, prot, 1, data->pgd, gfp);
/*
* Synchronise all PTE updates for the new mapping before there's
* a chance for anything to kick off a table walk for the new iova.
@@ -922,12 +922,12 @@ static int __init arm_v7s_do_selftests(void)
if (ops->map(ops, iova, iova,
Re: [PATCH v2] usb/gadget/function: introduce Built-in CDROM support
On Wed, 2020-06-10 at 10:31 -0400, Alan Stern wrote:
> On Wed, Jun 10, 2020 at 02:15:18PM +0800, Macpaul Lin wrote:
> > Introduce Built-In CDROM (BICR) support.
> > This feature depends on USB_CONFIGFS_MASS_STORAGE option.
> >
> > 1. Some settings and new function is introduced for BICR.
> > 2. Some work around for adapting Android settings is introduced as well.
>
> You're going to have to give a much better explanation of what this
> does. For people who don't know what Built-In CDROM support is, what
> you wrote is meaningless.
>
> For example, how is BICR support different from the CDROM support
> already present in the driver? And what's so special about it that it
> needs its own kconfig setting?
>
> > @@ -369,6 +372,10 @@ static void set_bulk_out_req_length(struct fsg_common
> > *common,
> > if (rem > 0)
> > length += common->bulk_out_maxpacket - rem;
> > bh->outreq->length = length;
> > +
> > + /* some USB 2.0 hardware requires this setting */
> > + if (common->bicr)
> > + bh->outreq->short_not_ok = 1;
>
> How is this connected with BICR? If some USB 2.0 hardware requires this
> setting, shouldn't it always be turned on?
>
> Besides, why does some hardware require this? What goes wrong if
> short_not_ok is set to 0? If it causes problems, why didn't we become
> aware of them many years ago?
Thanks for Alan and Greg's suggestion, we will check these issues and
see if a better solution could be work out.
> > @@ -527,7 +534,16 @@ static int fsg_setup(struct usb_function *f,
> > w_length != 1)
> > return -EDOM;
> > VDBG(fsg, "get max LUN\n");
> > - *(u8 *)req->buf = _fsg_common_get_max_lun(fsg->common);
> > + if (IS_ENABLED(USB_CONFIGFS_BICR) && fsg->common->bicr) {
> > + /*
> > +* When Built-In CDROM is enabled,
> > +* we share only one LUN.
> > +*/
> > + *(u8 *)req->buf = 0;
> > + } else {
> > + *(u8 *)req->buf = _fsg_common_get_max_lun(fsg->common);
> > + }
>
> This is a very strange way of enforcing a single-LUN restriction. Why
> do it here? A much more logical place would be where cfg->nluns is set
> up originally.
>
> > + INFO(fsg, "get max LUN = %d\n", *(u8 *)req->buf);
>
> This debugging line isn't needed.
>
> > /* Respond with data/status */
> > req->length = min((u16)1, w_length);
> > @@ -1329,7 +1345,7 @@ static int do_start_stop(struct fsg_common *common)
> > }
> >
> > /* Are we allowed to unload the media? */
> > - if (curlun->prevent_medium_removal) {
> > + if (!curlun->nofua && curlun->prevent_medium_removal) {
>
> How is nofua connected to BICR? Or to prevent_medium_removal?
>
> > LDBG(curlun, "unload attempt prevented\n");
> > curlun->sense_data = SS_MEDIUM_REMOVAL_PREVENTED;
> > return -EINVAL;
> > @@ -2692,6 +2708,7 @@ int fsg_common_set_cdev(struct fsg_common *common,
> > common->ep0 = cdev->gadget->ep0;
> > common->ep0req = cdev->req;
> > common->cdev = cdev;
> > + common->bicr = 0;
> >
> > us = usb_gstrings_attach(cdev, fsg_strings_array,
> > ARRAY_SIZE(fsg_strings));
> > @@ -2895,6 +2912,33 @@ static void fsg_common_release(struct fsg_common
> > *common)
> > kfree(common);
> > }
> >
> > +#ifdef CONFIG_USB_CONFIGFS_BICR
> > +ssize_t fsg_bicr_show(struct fsg_common *common, char *buf)
> > +{
> > + return sprintf(buf, "%d\n", common->bicr);
> > +}
> > +
> > +ssize_t fsg_bicr_store(struct fsg_common *common, const char *buf, size_t
> > size)
> > +{
> > + int ret;
> > +
> > + ret = kstrtou8(buf, 10, >bicr);
> > + if (ret)
> > + return -EINVAL;
> > +
> > + /* Set Lun[0] is a CDROM when enable bicr.*/
> > + if (!strcmp(buf, "1"))
> > + common->luns[0]->cdrom = 1;
> > + else {
> > + common->luns[0]->cdrom = 0;
> > + common->luns[0]->blkbits = 0;
> > + common->luns[0]->blksize = 0;
> > + common->luns[0]->num_sectors = 0;
> > + }
> > +
> > + return size;
> > +}
>
> Where do these attributes ever get exported to sysfs?
>
> > +#endif
> >
> >
> > /*-*/
> >
> > @@ -3463,6 +3507,7 @@ void fsg_config_from_params(struct fsg_config *cfg,
> > lun->ro = !!params->ro[i];
> > lun->cdrom = !!params->cdrom[i];
> > lun->removable = !!params->removable[i];
> > + lun->nofua = !!params->nofua[i];
>
> Isn't this set already? If not, it is a bug that has nothing to do with
> BICR.
>
> > lun->filename =
> > params->file_count > i && params->file[i][0]
> > ? params->file[i]
> > diff --git
linux-next: Tree for Jun 12
Hi all,
News: The merge window has opened, so please do *not* add v5.9 material
to your linux-next included branches until after v5.8-rc1 has been
released.
Changes since 20200611:
My fixes tree contains:
4cb4bfffe2c1 ("device_cgroup: Fix RCU list debugging warning")
The amdgpu tree gained a semantic conflict against Linus' tree.
Non-merge commits (relative to Linus' tree): 1363
1903 files changed, 254063 insertions(+), 23715 deletions(-)
I have created today's linux-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
(patches at http://www.kernel.org/pub/linux/kernel/next/ ). If you
are tracking the linux-next tree using git, you should not use "git pull"
to do so as that will try to merge the new linux-next release with the
old one. You should use "git fetch" and checkout or reset to the new
master.
You can see which trees have been included by looking in the Next/Trees
file in the source. There are also quilt-import.log and merge.log
files in the Next directory. Between each merge, the tree was built
with a ppc64_defconfig for powerpc, an allmodconfig for x86_64, a
multi_v7_defconfig for arm and a native build of tools/perf. After
the final fixups (if any), I do an x86_64 modules_install followed by
builds for x86_64 allnoconfig, powerpc allnoconfig (32 and 64 bit),
ppc44x_defconfig, allyesconfig and pseries_le_defconfig and i386, sparc
and sparc64 defconfig and htmldocs. And finally, a simple boot test
of the powerpc pseries_le_defconfig kernel in qemu (with and without
kvm enabled).
Below is a summary of the state of the merge.
I am currently merging 324 trees (counting Linus' and 82 trees of bug
fix patches pending for the current merge release).
Stats about the size of the tree over time can be seen at
http://neuling.org/linux-next-size.html .
Status of my local build tests will be at
http://kisskb.ellerman.id.au/linux-next . If maintainers want to give
advice about cross compilers/configs that work, we are always open to add
more builds.
Thanks to Randy Dunlap for doing many randconfig builds. And to Paul
Gortmaker for triage and bug fixes.
--
Cheers,
Stephen Rothwell
$ git checkout master
$ git reset --hard stable
Merging origin/master (623f6dc593ea Merge branch 'akpm' (patches from Andrew))
Merging fixes/master (df8cb0ea9423 device_cgroup: Fix RCU list debugging
warning)
Merging kbuild-current/fixes (e4a42c82e943 kbuild: fix broken builds because of
GZIP,BZIP2,LZOP variables)
Merging arc-current/for-curr (9d9368e839c2 ARC: [arcompact] fix bitrot with 2
levels of interrupt)
Merging arm-current/fixes (3866f217aaa8 ARM: 8977/1: ptrace: Fix mask for thumb
breakpoint hook)
Merging arm-soc-fixes/arm/fixes (99706d62fb50 Merge tag
'omap-for-v5.7/cpsw-fixes-signed' of
git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap into arm/fixes)
Merging uniphier-fixes/fixes (0e698dfa2822 Linux 5.7-rc4)
Merging arm64-fixes/for-next/fixes (ba051f097fc3 arm64/kernel: Fix return value
when cpu_online() fails in __cpu_up())
Merging m68k-current/for-linus (3381df095419 m68k: tools: Replace zero-length
array with flexible-array member)
Merging powerpc-fixes/fixes (2f26ed1764b4 powerpc/64s: Disable sanitisers for C
syscall/interrupt entry/exit code)
Merging s390-fixes/fixes (3d77e6a8804a Linux 5.7)
Merging sparc/master (af7b4801030c Merge
git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net)
Merging fscrypt-current/for-stable (2b4eae95c736 fscrypt: don't evict dirty
inodes after removing key)
Merging net/master (9798278260e8 tipc: fix NULL pointer dereference in
tipc_disc_rcv())
CONFLICT (content): Merge conflict in net/ipv4/tcp.c
Merging bpf/master (2c4779eff837 tools, bpftool: Exit on error in function
codegen)
Merging ipsec/master (a4902d914e50 xfrm: merge fixup for "remove output_finish
indirection from xfrm_state_afinfo")
Merging netfilter/master (c3829285b2e6 netfilter: nft_set_pipapo: Disable
preemption before getting per-CPU pointer)
Merging ipvs/master (bdc48fa11e46 checkpatch/coding-style: deprecate 80-column
warning)
Merging wireless-drivers/master (f92f26f2ed2c iwlwifi: pcie: handle QuZ configs
with killer NICs as well)
Merging mac80211/master (59d4bfc1e2c0 net: fix wiki website url mac80211 and
wireless files)
Merging rdma-fixes/for-rc (3d77e6a8804a Linux 5.7)
Merging sound-current/for-linus (adb36a820383 ALSA: hda: Add NVIDIA codec IDs
9a & 9d through a0 to patch table)
Merging sound-asoc-fixes/for-linus (9f045ed020a5 Merge remote-tracking branch
'asoc/for-5.8' into asoc-linus)
Merging regmap-fixes/for-linus (7e295e6576af Merge remote-tracking branch
'regmap/for-5.8' into regmap-linus)
Merging regulator-fixes/for-linus (5fb565b69dab Merge remote-tracking branch
'regulator/for-5.8' into regulator-linus)
Merging spi-fixes/for-linus (a86cc4cfcd0b Merge remote-tracking branch
'spi/for-5.8' i
Re: Perf: WARNING: arch/x86/entry/common.c:624 idtentry_exit_cond_rcu+0x92/0xc0
On Thu, Jun 11, 2020 at 4:22 PM Andy Lutomirski wrote: > > On Thu, Jun 11, 2020 at 12:25 PM Peter Zijlstra wrote: > > > > On Thu, Jun 11, 2020 at 12:10:50PM -0700, Andy Lutomirski wrote: > > > On Thu, Jun 11, 2020 at 11:56 AM Naresh Kamboju > > > wrote: > > > > > > > > While running perf test and selftest x86 single_step_syscall_32 on > > > > i386 kernel linux > > > > next 5.7.0-next-20200610 kernel warning noticed. > > > > > > > > steps to reproduce: > > > > -- > > > > perf test > > > > and > > > > cd /opt/kselftests/default-in-kernel/x86 > > > > ./single_step_syscall_32 > > > > > > > > perf warning log: > > > > -- > > > > [ 57.260865] [ cut here ] > > > > [ 57.266576] IRQs not disabled as expected > > > > [ 57.270583] WARNING: CPU: 1 PID: 500 at > > > > /usr/src/kernel/arch/x86/entry/common.c:624 > > > > idtentry_exit_cond_rcu+0x92/0xc0 > > > > [ 57.281092] Modules linked in: x86_pkg_temp_thermal fuse > > > > [ 57.286406] CPU: 1 PID: 500 Comm: perf Not tainted > > > > 5.7.0-next-20200610 #1 > > > > [ 57.293190] Hardware name: Supermicro SYS-5019S-ML/X11SSH-F, BIOS > > > > 2.2 05/23/2018 > > > > [ 57.300577] EIP: idtentry_exit_cond_rcu+0x92/0xc0 > > > > [ 57.305280] Code: 8b 89 d8 05 00 00 85 c9 74 ae 80 3d b1 64 2c d4 > > > > 00 75 a5 68 94 2d fb d3 89 55 f8 89 45 fc c6 05 b1 64 2c d4 01 e8 8e > > > > f5 2b ff <0f> 0b 58 8b 55 f8 8b 45 fc eb 83 8d 76 00 e8 5b fd ff ff c9 > > > > c3 89 > > > > [ 57.324017] EAX: 001d EBX: 0d00022a ECX: 0027 EDX: f5b9e14c > > > > [ 57.330274] ESI: f2a2ffb4 EDI: 0ff4 EBP: f2a2ff8c ESP: f2a2ff80 > > > > [ 57.336531] DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068 EFLAGS: > > > > 00010096 > > > > [ 57.343345] CR0: 80050033 CR2: 08700a58 CR3: 14ad7000 CR4: 003406d0 > > > > [ 57.349608] DR0: 080dfb80 DR1: 080dfc00 DR2: 08700a58 DR3: > > > > [ 57.355866] DR6: fffe0ff0 DR7: 0d00062a > > > > [ 57.359697] Call Trace: > > > > [ 57.362143] exc_debug+0x84/0x1b0 > > > > [ 57.365487] ? exc_int3+0x1d0/0x1d0 > > > > [ 57.368981] handle_exception+0x145/0x145 > > > > [ 57.372991] EIP: 0x80dfbcd > > > > [ 57.375694] Code: Bad RIP value. > > > > [ 57.378918] EAX: EBX: 0005 ECX: 2400 EDX: > > > > [ 57.385175] ESI: 0003 EDI: 0004 EBP: bfd59798 ESP: bfd59770 > > > > [ 57.391431] DS: 007b ES: 007b FS: GS: 0033 SS: 007b EFLAGS: > > > > 0246 > > > > [ 57.398215] irq event stamp: 1896 > > > > > > A regrettable property of the current entry code structure is that we > > > lose any real indication of the vector. Presumably this is #DB, hence > > > exc_debug. I don't know what perf has to do with it. > > > > > > I'll bang on this after lunch if no one beats me to it. > > > > Puzzling, CR3 seems to suggest this is !user_mode(), but either way #DB > > has either idtentry_enter_user() or nmi_enter(). > > > > I just got this splat on 32-bit while running my perf abuser here: > > https://git.kernel.org/pub/scm/linux/kernel/git/luto/misc-tests.git/tree/perf_lots_of_nmi.c > > [ 21.874114] traps: PANIC: double fault, error_code: 0x0 Two bugs here. 1. We had an issue with WARN. Patch sent. 2. idtentry.h has, for x86_32: # define DEFINE_IDTENTRY_IST DEFINE_IDTENTRY This is nonsense. It's getting late over here and I'd rather focus on the more interesting RCU issue, so that's all from me today. --Andy
Re: [PATCH v2] x86/mm: use max memory block size on bare metal
On Thu, Jun 11, 2020 at 10:05:38AM -0700, Dave Hansen wrote:
> One other nit for this. We *do* have actual hardware hotplug, and I'm
> pretty sure the alignment guarantees for hardware hotplug are pretty
> weak. For instance, the alignment guarantees for persistent memory are
> still only 64MB even on modern platforms.
>
> Let's say we're on bare metal and we see an SRAT table that has some
> areas that show that hotplug might happen there. Is this patch still
> ideal there?
Well, not if there's concern about hardware hotplug.
My assumption going in was that this wasn't a problem in practice.
078eb6aa50dc50 ("x86/mm/memory_hotplug: determine block size based on the end
of boot memory") was merged in 2018 to address qemu hotplug failures and >64G
systems have used a 2G block since 2014 with no complaints about alignment
issues, to my knowledge anyway.
[PATCH] x86/entry: Treat BUG/WARN as NMI-like entries
If we BUG or WARN in a funny RCU context, we cleverly optimize the
BUG/WARN using the ud2 hack, which takes us through the
idtentry_enter...() paths, which might helpfully WARN that the RCU
context is invalid, which results in infinite recursion.
Split the BUG/WARN handling into an nmi_enter()/nmi_exit() path in
exc_invalid_op() to increase the chance that we survive the
experience.
Signed-off-by: Andy Lutomirski
---
This is not as well tested as I would like, but it does cause the splat
I'm chasing to display a nice warning instead of causing an undebuggable
stack overflow.
(It would have been debuggable on x86_64, but it's a 32-bit splat, and
x86_32 doesn't have ORC.)
arch/x86/kernel/traps.c | 61 +++--
arch/x86/mm/extable.c | 15 --
2 files changed, 48 insertions(+), 28 deletions(-)
diff --git a/arch/x86/kernel/traps.c b/arch/x86/kernel/traps.c
index cb8c3d26cdf5..6340b12a6616 100644
--- a/arch/x86/kernel/traps.c
+++ b/arch/x86/kernel/traps.c
@@ -98,24 +98,6 @@ int is_valid_bugaddr(unsigned long addr)
return ud == INSN_UD0 || ud == INSN_UD2;
}
-int fixup_bug(struct pt_regs *regs, int trapnr)
-{
- if (trapnr != X86_TRAP_UD)
- return 0;
-
- switch (report_bug(regs->ip, regs)) {
- case BUG_TRAP_TYPE_NONE:
- case BUG_TRAP_TYPE_BUG:
- break;
-
- case BUG_TRAP_TYPE_WARN:
- regs->ip += LEN_UD2;
- return 1;
- }
-
- return 0;
-}
-
static nokprobe_inline int
do_trap_no_signal(struct task_struct *tsk, int trapnr, const char *str,
struct pt_regs *regs, long error_code)
@@ -191,13 +173,6 @@ static void do_error_trap(struct pt_regs *regs, long
error_code, char *str,
{
RCU_LOCKDEP_WARN(!rcu_is_watching(), "entry code didn't wake RCU");
- /*
-* WARN*()s end up here; fix them up before we call the
-* notifier chain.
-*/
- if (!user_mode(regs) && fixup_bug(regs, trapnr))
- return;
-
if (notify_die(DIE_TRAP, str, regs, error_code, trapnr, signr) !=
NOTIFY_STOP) {
cond_local_irq_enable(regs);
@@ -242,9 +217,43 @@ static inline void handle_invalid_op(struct pt_regs *regs)
ILL_ILLOPN, error_get_trap_addr(regs));
}
-DEFINE_IDTENTRY(exc_invalid_op)
+DEFINE_IDTENTRY_RAW(exc_invalid_op)
{
+ bool rcu_exit;
+
+ /*
+* Handle BUG/WARN like NMIs instead of like normal idtentries:
+* if we bugged/warned in a bad RCU context, for example, the last
+* thing we want is to BUG/WARN again in the idtentry code, ad
+* infinitum.
+*/
+ if (!user_mode(regs) && is_valid_bugaddr(regs->ip)) {
+ enum bug_trap_type type;
+
+ nmi_enter();
+ instrumentation_begin();
+ type = report_bug(regs->ip, regs);
+ instrumentation_end();
+ nmi_exit();
+
+ if (type == BUG_TRAP_TYPE_WARN) {
+ /* Skip the ud2. */
+ regs->ip += LEN_UD2;
+ return;
+ }
+
+ /*
+* Else, if this was a BUG and report_bug returns or if this
+* was just a normal #UD, we want to continue onward and
+* crash.
+*/
+ }
+
+ rcu_exit = idtentry_enter_cond_rcu(regs);
+ instrumentation_begin();
handle_invalid_op(regs);
+ instrumentation_end();
+ idtentry_exit_cond_rcu(regs, rcu_exit);
}
DEFINE_IDTENTRY(exc_coproc_segment_overrun)
diff --git a/arch/x86/mm/extable.c b/arch/x86/mm/extable.c
index b991aa4bdfae..1d6cb07f4f86 100644
--- a/arch/x86/mm/extable.c
+++ b/arch/x86/mm/extable.c
@@ -204,8 +204,19 @@ void __init early_fixup_exception(struct pt_regs *regs,
int trapnr)
if (fixup_exception(regs, trapnr, regs->orig_ax, 0))
return;
- if (fixup_bug(regs, trapnr))
- return;
+ if (trapnr == X86_TRAP_UD) {
+ if (report_bug(regs->ip, regs) == BUG_TRAP_TYPE_WARN) {
+ /* Skip the ud2. */
+ regs->ip += LEN_UD2;
+ return;
+ }
+
+ /*
+* If this was a BUG and report_bug returns or if this
+* was just a normal #UD, we want to continue onward and
+* crash.
+*/
+ }
fail:
early_printk("PANIC: early exception 0x%02x IP %lx:%lx error %lx cr2
0x%lx\n",
--
2.25.4
Re: [PATCH 6/6] drm/msm/a6xx: Add support for per-instance pagetables
On Thu, Jun 11, 2020 at 3:29 PM Jordan Crouse wrote:
>
> Add support for using per-instance pagetables if all the dependencies are
> available.
>
> Signed-off-by: Jordan Crouse
> ---
>
> drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 69 ++-
> drivers/gpu/drm/msm/msm_ringbuffer.h | 1 +
> 2 files changed, 69 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
> b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
> index a1589e040c57..5e82b85d4d55 100644
> --- a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
> +++ b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
> @@ -79,6 +79,58 @@ static void get_stats_counter(struct msm_ringbuffer *ring,
> u32 counter,
> OUT_RING(ring, upper_32_bits(iova));
> }
>
> +static void a6xx_set_pagetable(struct msm_gpu *gpu, struct msm_ringbuffer
> *ring,
> + struct msm_file_private *ctx)
> +{
> + phys_addr_t ttbr;
> + u32 asid;
> +
> + if (msm_iommu_pagetable_params(ctx->aspace->mmu, , ))
> + return;
> +
> + OUT_PKT7(ring, CP_SET_PROTECTED_MODE, 1);
> + OUT_RING(ring, 0);
> +
> + /* Turn on APIV mode to access critical regions */
> + OUT_PKT4(ring, REG_A6XX_CP_MISC_CNTL, 1);
> + OUT_RING(ring, 1);
> +
> + /* Make sure the ME is synchronized before staring the update */
> + OUT_PKT7(ring, CP_WAIT_FOR_ME, 0);
> +
> + /* Execute the table update */
> + OUT_PKT7(ring, CP_SMMU_TABLE_UPDATE, 4);
> + OUT_RING(ring, lower_32_bits(ttbr));
> + OUT_RING(ring, (((u64) asid) << 48) | upper_32_bits(ttbr));
> + /* CONTEXTIDR is currently unused */
> + OUT_RING(ring, 0);
> + /* CONTEXTBANK is currently unused */
> + OUT_RING(ring, 0);
I can add this to xml (on userspace side, we've been describing packet
payload in xml and using the generated builders), and update generated
headers, if you agree to not add more open-coded pkt7 building ;-)
> +
> + /*
> +* Write the new TTBR0 to the memstore. This is good for debugging.
> +*/
> + OUT_PKT7(ring, CP_MEM_WRITE, 4);
> + OUT_RING(ring, lower_32_bits(rbmemptr(ring, ttbr0)));
> + OUT_RING(ring, upper_32_bits(rbmemptr(ring, ttbr0)));
> + OUT_RING(ring, lower_32_bits(ttbr));
> + OUT_RING(ring, (((u64) asid) << 48) | upper_32_bits(ttbr));
> +
> + /* Invalidate the draw state so we start off fresh */
> + OUT_PKT7(ring, CP_SET_DRAW_STATE, 3);
> + OUT_RING(ring, 0x4);
> + OUT_RING(ring, 1);
> + OUT_RING(ring, 0);
Ie, this would look like:
OUT_PKT7(ring, CP_SET_DRAW_STATE, 3);
OUT_RING(ring, CP_SET_DRAW_STATE__0_COUNT(0) |
CP_SET_DRAW_STATE__0_DISABLE_ALL_GROUPS |
CP_SET_DRAW_STATE__0_GROUP_ID(0));
OUT_RING(ring, CP_SET_DRAW_STATE__1_ADDR_LO(1));
OUT_RING(ring, CP_SET_DRAW_STATE__2_ADDR_HI(0));
.. but written that way, I think you meant ADDR_LO to be zero?
(it is possible we need to regen headers for that to work, the kernel
headers are somewhat out of date by now)
BR,
-R
> +
> + /* Turn off APRIV */
> + OUT_PKT4(ring, REG_A6XX_CP_MISC_CNTL, 1);
> + OUT_RING(ring, 0);
> +
> + /* Turn off protected mode */
> + OUT_PKT7(ring, CP_SET_PROTECTED_MODE, 1);
> + OUT_RING(ring, 1);
> +}
> +
> static void a6xx_submit(struct msm_gpu *gpu, struct msm_gem_submit *submit,
> struct msm_file_private *ctx)
> {
> @@ -89,6 +141,8 @@ static void a6xx_submit(struct msm_gpu *gpu, struct
> msm_gem_submit *submit,
> struct msm_ringbuffer *ring = submit->ring;
> unsigned int i;
>
> + a6xx_set_pagetable(gpu, ring, ctx);
> +
> get_stats_counter(ring, REG_A6XX_RBBM_PERFCTR_CP_0_LO,
> rbmemptr_stats(ring, index, cpcycles_start));
>
> @@ -872,6 +926,18 @@ static unsigned long a6xx_gpu_busy(struct msm_gpu *gpu)
> return (unsigned long)busy_time;
> }
>
> +struct msm_gem_address_space *a6xx_address_space_instance(struct msm_gpu
> *gpu)
> +{
> + struct msm_mmu *mmu;
> +
> + mmu = msm_iommu_pagetable_create(gpu->aspace->mmu);
> + if (IS_ERR(mmu))
> + return msm_gem_address_space_get(gpu->aspace);
> +
> + return msm_gem_address_space_create(mmu,
> + "gpu", 0x1ULL, 0x1ULL);
> +}
> +
> static const struct adreno_gpu_funcs funcs = {
> .base = {
> .get_param = adreno_get_param,
> @@ -893,8 +959,9 @@ static const struct adreno_gpu_funcs funcs = {
> #if defined(CONFIG_DRM_MSM_GPU_STATE)
> .gpu_state_get = a6xx_gpu_state_get,
> .gpu_state_put = a6xx_gpu_state_put,
> - .create_address_space = adreno_iommu_create_address_space,
> #endif
> + .create_address_space = adreno_iommu_create_address_space,
> + .address_space_instance = a6xx_address_space_instance,
> },
> .get_timestamp = a6xx_get_timestamp,
> };
> diff --git
Re: [PATCH 05/14] mm: workingset: let cache workingset challenge anon
2020년 6월 5일 (금) 오전 12:06, Johannes Weiner 님이 작성:
>
> On Thu, Jun 04, 2020 at 03:35:27PM +0200, Vlastimil Babka wrote:
> > On 6/1/20 10:44 PM, Johannes Weiner wrote:
> > > From a8faceabc1454dfd878caee2a8422493d937a394 Mon Sep 17 00:00:00 2001
> > > From: Johannes Weiner
> > > Date: Mon, 1 Jun 2020 14:04:09 -0400
> > > Subject: [PATCH] mm: workingset: let cache workingset challenge anon fix
> >
> > Looks like the whole series is now in mainline (that was quick!) without
> > this
> > followup? As such it won't be squashed so perhaps the subject should be more
> > "standalone" now, description referencing commit 34e58cac6d8f ("mm:
> > workingset:
> > let cache workingset challenge anon"), possibly with Fixes: tag etc...
>
> Yep, I'll send a stand-alone version of this. It was a bit fat to get
> squashed last minute anyway, and I don't mind having a bit of extra
> time to quantify the actual impact of this delta.
Hello, Johannes.
Now, a week has passed. I hope that this patch is merged as soon as possible,
since my WIP patchset depends on this patch. How about trying to merge
this patch now? If you don't mind, I could send it on your behalf.
Thanks.
Re: [PATCH 5/6] spi: altera: move driver name string to header file
On Thu, Jun 11, 2020 at 03:03:01PM +0100, Mark Brown wrote: > On Thu, Jun 11, 2020 at 11:25:10AM +0800, Xu Yilun wrote: > > This allows other driver to reuse the name string for spi-altera > > platform device creation. > > This is a very unusual thing to do, normally we just have the users use > the strong directly. It feels like if we are going to change this idiom > we should do so globally but that seems like far more trouble thanit's > worth. Sure, I'll discard this patch and just use string for spi-altera device creation. Thanks, Yilun.
Re: [PATCH v6] media: rcar-csi2: Correct the selection of hsfreqrange
On Wed, Jun 10, 2020 at 03:40:04PM +0200, Niklas Söderlund wrote:
> Hi Suresh,
>
> Thanks for your persistent work!
>
> On 2020-06-08 12:25:03 +0900, Suresh Udipi wrote:
> > hsfreqrange should be chosen based on the calculated mbps which
> > is closer to the default bit rate and within the range as per
> > table[1]. But current calculation always selects first value which
> > is greater than or equal to the calculated mbps which may lead
> > to chosing a wrong range in some cases.
> >
> > For example for 360 mbps for H3/M3N
> > Existing logic selects
> > Calculated value 360Mbps : Default 400Mbps Range [368.125 -433.125 mbps]
> >
> > This hsfreqrange is out of range.
> >
> > The logic is changed to get the default value which is closest to the
> > calculated value [1]
> >
> > Calculated value 360Mbps : Default 350Mbps Range [320.625 -380.625 mpbs]
> >
> > [1] specs r19uh0105ej0200-r-car-3rd-generation.pdf [Table 25.9]
> >
> > Please note that According to Renesas in Table 25.9 the range for
> > 220 default value is corrected as below
> >
> > |Range (Mbps) | Default Bit rate (Mbps) |
> > ---
> > | 197.125-244.125 | 220 |
> > ---
> >
> > Fixes: 769afd212b16 ("media: rcar-csi2: add Renesas R-Car MIPI CSI-2
> > receiver driver")
> >
> > Signed-off-by: Suresh Udipi
> > Signed-off-by: Kazuyoshi Akiyama
> > Signed-off-by: Michael Rodin
> > ---
> > Changes in v2:
> > - Added the boundary check for the maximum bit rate.
> >
> > - Simplified the logic by remmoving range check
> > as only the closest default value covers most
> > of the use cases.
> >
> > - Aligning the commit message based on the above change
> >
> >
> > Changes in v3:
> > - Added max member from struct rcsi2_mbps_reg.
> > mbps varialbe cannot be removed from rcsi2_mbps_reg,
> > since this structure is reused for
> > phtw_mbps_h3_v3h_m3n/phtw_mbps_v3m_e3 where mbps is
> > used.
> >
> >
> >- Update the walk of the array in rcsi2_set_phypll() so that it finds
> > the first entry where the calculated bit rate is less than the max.
> >
> >- Support lower bit rates less than 80Mbps like 48Mbps
> > (Raspberry pi camera 640x480 connected to Kingfisher)
> > can also be supported by selecting the lowest default bit rate 80Mbps
> > as done before this fix
> >
> >- Alignement of the commit message based on above changes.
> >
> > Changes in v4:
> > - Remove unncessary braces.
> >
> > Changes in v5:
> >- Removed mbps variable in rcsi2_mbps_reg and aligned all
> > tables accordingly
> >
> > Changes in v6
> >- Renesas correct the range of default value 220Mbps. Now
> > if we select the nearest value to the default value all
> > the values are in range. So reverting back to original patch
> >
> >- Added warning for values less than Minimum 80Mbps
> >
> >
> > drivers/media/platform/rcar-vin/rcar-csi2.c | 23 ++-
> > 1 file changed, 18 insertions(+), 5 deletions(-)
> >
> > diff --git a/drivers/media/platform/rcar-vin/rcar-csi2.c
> > b/drivers/media/platform/rcar-vin/rcar-csi2.c
> > index 151e6a9..8c502b7 100644
> > --- a/drivers/media/platform/rcar-vin/rcar-csi2.c
> > +++ b/drivers/media/platform/rcar-vin/rcar-csi2.c
> > @@ -199,6 +199,8 @@ static const struct rcsi2_mbps_reg phtw_mbps_v3m_e3[] =
> > {
> > /* PHY Frequency Control */
> > #define PHYPLL_REG 0x68
> > #define PHYPLL_HSFREQRANGE(n) ((n) << 16)
> > +#define PHYPLL_HSFREQRANGE_MAX 1500
> > +#define PHYPLL_HSFREQRANGE_MIN 80
> >
> > static const struct rcsi2_mbps_reg hsfreqrange_h3_v3h_m3n[] = {
> > { .mbps = 80, .reg = 0x00 },
> > @@ -431,16 +433,27 @@ static int rcsi2_wait_phy_start(struct rcar_csi2
> > *priv)
> > static int rcsi2_set_phypll(struct rcar_csi2 *priv, unsigned int mbps)
> > {
> > const struct rcsi2_mbps_reg *hsfreq;
> > + const struct rcsi2_mbps_reg *hsfreq_prev = NULL;
> >
> > - for (hsfreq = priv->info->hsfreqrange; hsfreq->mbps != 0; hsfreq++)
> > - if (hsfreq->mbps >= mbps)
> > - break;
> > -
> > - if (!hsfreq->mbps) {
> > + if (mbps > PHYPLL_HSFREQRANGE_MAX) {
> > dev_err(priv->dev, "Unsupported PHY speed (%u Mbps)", mbps);
> > return -ERANGE;
> > }
> >
> > + if (mbps < PHYPLL_HSFREQRANGE_MIN)
> > + dev_warn(priv->dev, "PHY speed (%u Mbps) less \
> > +than Min 80Mbps\n", mbps);
>
> I would drop this warning.
>
This was suggested by Michael. Michael is it ok to drop this warning
as it is not available before this changes also.
> > +
> > + for (hsfreq = priv->info->hsfreqrange; hsfreq->mbps != 0; hsfreq++) {
> > + if (hsfreq->mbps >= mbps)
> > + break;
> > + hsfreq_prev =
Re: [PATCH v12 00/16] per memcg lru lock
在 2020/6/12 上午6:26, Hugh Dickins 写道: >> ..." > It was well worth exploring, and may help in a few cases; > Johannes's memcg swap simplifications have helped a lot more; > but crashes under rotate_reclaimable_page() show that this series > still does not give enough protection from mem_cgroup_move_account(). > > I'll send a couple of fixes to compaction bugs in reply to this: > with those in, compaction appears to be solid. > Thanks a lot for fixing. I will look into them and try to merge into the patchset. Thanks a lot! Alex
Re: [PATCH 2/2] soc: mediatek: devapc: add devapc-mt6873 driver
Hi Chun-Kuang,
[snip]
> > > > +/*
> > > > + * devapc_violation_irq - the devapc Interrupt Service Routine (ISR)
> > > > will dump
> > > > + * violation information including which master
> > > > violates
> > > > + * access slave.
> > > > + */
> > > > +static irqreturn_t devapc_violation_irq(int irq_number, void *dev_id)
> > > > +{
> > > > + u32 slave_type_num = mtk_devapc_ctx->soc->slave_type_num;
> > > > + const struct mtk_device_info **device_info;
> > > > + struct mtk_devapc_vio_info *vio_info;
> > > > + int slave_type, vio_idx, index;
> > > > + const char *vio_master;
> > > > + unsigned long flags;
> > > > + bool normal;
> > > > + u8 perm;
> > > > +
> > > > + spin_lock_irqsave(_lock, flags);
> > > > +
> > > > + device_info = mtk_devapc_ctx->soc->device_info;
> > > > + vio_info = mtk_devapc_ctx->soc->vio_info;
> > > > + normal = false;
> > > > + vio_idx = -1;
> > > > + index = -1;
> > > > +
> > > > + /* There are multiple DEVAPC_PD */
> > > > + for (slave_type = 0; slave_type < slave_type_num; slave_type++)
> > > > {
> > > > + if (!check_type2_vio_status(slave_type, _idx,
> > > > ))
> > > > + if (!mtk_devapc_dump_vio_dbg(slave_type,
> > > > _idx,
> > > > +))
> > > > + continue;
> > > > +
> > > > + /* Ensure that violation info are written before
> > > > +* further operations
> > > > +*/
> > > > + smp_mb();
> > > > + normal = true;
> > > > +
> > > > + mask_module_irq(slave_type, vio_idx, true);
> > > > +
> > > > + if (clear_vio_status(slave_type, vio_idx))
> > > > + pr_warn(PFX "%s, %s:0x%x, %s:0x%x\n",
> > > > + "clear vio status failed",
> > > > + "slave_type", slave_type,
> > > > + "vio_index", vio_idx);
> > > > +
> > > > + perm = get_permission(slave_type, index,
> > > > vio_info->domain_id);
> > > > +
> > > > + vio_master = mtk_devapc_ctx->soc->master_get
> > > > + (vio_info->master_id,
> > > > +vio_info->vio_addr,
> > > > +slave_type,
> > > > +vio_info->shift_sta_bit,
> > > > +vio_info->domain_id);
> > >
> > > Call mt6873_bus_id_to_master() directly. For first patch, make things
> > > as simple as possible.
> >
> > In devapc_violation_irq() function, we use common flow to handle each
> > devapc violation on different platforms. The master_get() has different
> > implementation on different platforms, that why it called indirectly.
> >
> > Once we have new platform, we only have to update devapc-mt.c
> > instead of common handler flow.
>
> You just upstream one SoC now, so I have no information of 2nd SoC.
> Without the 2nd SoC, how do we know what is common and what is SoC special?
> So the first patch should not consider the things which does not exist yet.
>
> Regards,
> Chun-Kuang.
>
It has lots of refactoring work need to do if you really want make it
"simple". Could I explain more details and let you judge it is simple
enough?
For most MediaTek DEVAPC hw, the violation interrupt handling sequence
is shown below.
1. Domain processor receives a interrupt issued by DEVAPC.
2. Software read the violation status and identify it.
3. Software read the debug information which are stored in hw register.
a. debug information includes master ID, domain ID, violation
address, ...
4. Transfer debug information to human readable strings.
5. Extra handler to dispatch owner directly.
What we really care is which master violates the rules, and which slave
had been accessed unexpectedly.
Here are platform specific information:
1. Slaves layout (platform devices)
2. hw register layout which are stored violation information
3. Master ID mapping table
4. Domain ID mapping table
Hope these steps could help you understand what is common and what is
SoC specific. If you want to see the 2nd SoC's driver, I can also send
it for you to take a look.
Thanks,
Neal
> >
> > >
> > > > +
> > > > + if (!vio_master) {
> > > > + pr_warn(PFX "master_get failed\n");
> > > > + vio_master = "UNKNOWN_MASTER";
> > > > + }
> > > > +
> > > > + pr_info(PFX "%s - %s:0x%x, %s:0x%x, %s:0x%x, %s:0x%x\n",
> > > > + "Violation", "slave_type", slave_type,
> > > > + "sys_index",
> > > > + device_info[slave_type][index].sys_index,
> > > > + "ctrl_index",
> > > > + device_info[slave_type][index].ctrl_index,
> > > > +
[PATCH v3 2/2] usb: phy: Add USB3 PHY support for Intel LGM SoC
From: Ramuthevar Vadivel Murugan
Add support for USB PHY on Intel LGM SoC.
Signed-off-by: Ramuthevar Vadivel Murugan
---
drivers/usb/phy/Kconfig | 11 ++
drivers/usb/phy/Makefile | 1 +
drivers/usb/phy/phy-lgm-usb.c | 278 ++
3 files changed, 290 insertions(+)
create mode 100644 drivers/usb/phy/phy-lgm-usb.c
diff --git a/drivers/usb/phy/Kconfig b/drivers/usb/phy/Kconfig
index 4b3fa78995cf..95f2e737d663 100644
--- a/drivers/usb/phy/Kconfig
+++ b/drivers/usb/phy/Kconfig
@@ -192,4 +192,15 @@ config JZ4770_PHY
This driver provides PHY support for the USB controller found
on the JZ4770 SoC from Ingenic.
+config USB_LGM_PHY
+ tristate "INTEL Lightning Mountain USB PHY Driver"
+ depends on USB_SUPPORT
+ select USB_PHY
+ select REGULATOR
+ select REGULATOR_FIXED_VOLTAGE
+ help
+ Enable this to support Intel DWC3 PHY USB phy. This driver provides
+ interface to interact with USB GEN-II and USB 3.x PHY that is part
+ of the Intel network SOC.
+
endmenu
diff --git a/drivers/usb/phy/Makefile b/drivers/usb/phy/Makefile
index b352bdbe8712..ef5345164e10 100644
--- a/drivers/usb/phy/Makefile
+++ b/drivers/usb/phy/Makefile
@@ -25,3 +25,4 @@ obj-$(CONFIG_USB_ULPI)+= phy-ulpi.o
obj-$(CONFIG_USB_ULPI_VIEWPORT)+= phy-ulpi-viewport.o
obj-$(CONFIG_KEYSTONE_USB_PHY) += phy-keystone.o
obj-$(CONFIG_JZ4770_PHY) += phy-jz4770.o
+obj-$(CONFIG_USB_LGM_PHY) += phy-lgm-usb.o
diff --git a/drivers/usb/phy/phy-lgm-usb.c b/drivers/usb/phy/phy-lgm-usb.c
new file mode 100644
index ..90a1e5ef0825
--- /dev/null
+++ b/drivers/usb/phy/phy-lgm-usb.c
@@ -0,0 +1,278 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Intel LGM USB PHY driver
+ *
+ * Copyright (C) 2020 Intel Corporation.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define CTRL1_OFFSET 0x14
+#define SRAM_EXT_LD_DONE BIT(25)
+#define SRAM_INIT_DONE BIT(26)
+
+#define TCPC_OFFSET0x1014
+#define TCPC_MUX_CTL GENMASK(1, 0)
+#define MUX_NC 0
+#define MUX_USB1
+#define MUX_DP 2
+#define MUX_USBDP 3
+#define TCPC_FLIPPED BIT(2)
+#define TCPC_LOW_POWER_EN BIT(3)
+#define TCPC_VALID BIT(4)
+#define TCPC_DISCONN \
+ (TCPC_VALID | FIELD_PREP(TCPC_MUX_CTL, MUX_NC) | TCPC_LOW_POWER_EN)
+
+static const char *const PHY_RESETS[] = { "phy31", "phy", };
+static const char *const CTL_RESETS[] = { "apb", "ctrl", };
+
+struct tca_apb {
+ struct reset_control *resets[ARRAY_SIZE(PHY_RESETS)];
+ struct regulator *vbus;
+ struct work_struct wk;
+ struct usb_phy phy;
+
+ bool phy_initialized;
+ bool connected;
+};
+
+static int get_flipped(struct tca_apb *ta, bool *flipped)
+{
+ union extcon_property_value property;
+ int ret;
+
+ ret = extcon_get_property(ta->phy.edev, EXTCON_USB_HOST,
+ EXTCON_PROP_USB_TYPEC_POLARITY, );
+ if (ret) {
+ dev_err(ta->phy.dev, "no polarity property from extcon\n");
+ return ret;
+ }
+
+ *flipped = property.intval;
+
+ return ret;
+}
+
+static int phy_init(struct usb_phy *phy)
+{
+ struct tca_apb *ta = container_of(phy, struct tca_apb, phy);
+ void __iomem *ctrl1 = phy->io_priv + CTRL1_OFFSET;
+ int val, ret, i;
+
+ if (ta->phy_initialized)
+ return 0;
+
+ for (i = 0; i < ARRAY_SIZE(PHY_RESETS); i++)
+ reset_control_deassert(ta->resets[i]);
+
+ ret = readl_poll_timeout(ctrl1, val, val & SRAM_INIT_DONE, 10, 10 *
1000);
+ if (ret) {
+ dev_err(ta->phy.dev, "SRAM init failed, 0x%x\n", val);
+ return ret;
+ }
+
+ writel(readl(ctrl1) | SRAM_EXT_LD_DONE, ctrl1);
+
+ ta->phy_initialized = true;
+ if (!ta->phy.edev)
+ return phy->set_vbus(phy, true);
+
+ schedule_work(>wk);
+
+ return ret;
+}
+
+static void phy_shutdown(struct usb_phy *phy)
+{
+ struct tca_apb *ta = container_of(phy, struct tca_apb, phy);
+ int i;
+
+ if (!ta->phy_initialized)
+ return;
+
+ ta->phy_initialized = false;
+ flush_work(>wk);
+ ta->phy.set_vbus(>phy, false);
+ if (ta->connected) {
+ ta->connected = false;
+ writel(TCPC_DISCONN, ta->phy.io_priv + TCPC_OFFSET);
+ }
+
+ for (i = 0; i < ARRAY_SIZE(PHY_RESETS); i++)
+ reset_control_assert(ta->resets[i]);
+}
+
+static int phy_set_vbus(struct usb_phy *phy, int on)
+{
+ struct tca_apb *ta = container_of(phy, struct tca_apb, phy);
+ int ret;
+
+ if (on) {
+ ret = regulator_enable(ta->vbus);
+
[PATCH v3 1/2] dt-bindings: usb: Add USB PHY support for Intel LGM SoC
From: Ramuthevar Vadivel Murugan
Add the dt-schema to support USB PHY on Intel LGM SoC
Signed-off-by: Ramuthevar Vadivel Murugan
---
.../devicetree/bindings/usb/intel,lgm-usb-phy.yaml | 53 ++
1 file changed, 53 insertions(+)
create mode 100644 Documentation/devicetree/bindings/usb/intel,lgm-usb-phy.yaml
diff --git a/Documentation/devicetree/bindings/usb/intel,lgm-usb-phy.yaml
b/Documentation/devicetree/bindings/usb/intel,lgm-usb-phy.yaml
new file mode 100644
index ..0fc76cd23774
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/intel,lgm-usb-phy.yaml
@@ -0,0 +1,53 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/usb/intel,lgm-usb-phy.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Intel LGM USB PHY Device Tree Bindings
+
+maintainers:
+ - Vadivel Murugan Ramuthevar
+
+properties:
+ compatible:
+const: intel,lgm-usb-phy
+
+ reg:
+maxItems: 1
+
+ clocks:
+maxItems: 1
+
+ resets:
+items:
+ - description: USB PHY and Host controller reset
+ - description: APB BUS reset
+ - description: General Hardware reset
+
+ reset-names:
+items:
+ - const: phy
+ - const: apb
+ - const: phy31
+
+required:
+ - compatible
+ - clocks
+ - reg
+ - resets
+ - reset-names
+
+additionalProperties: false
+
+examples:
+ - |
+usb_phy: usb_phy@e7e0 {
+compatible = "intel,lgm-usb-phy";
+reg = <0xe7e0 0x1>;
+clocks = < 153>;
+resets = < 0x70 0x24>,
+ < 0x70 0x26>,
+ < 0x70 0x28>;
+reset-names = "phy", "apb", "phy31";
+};
--
2.11.0
[PATCH v3 0/2] usb : phy: Add USB PHY support on Intel LGM SoC
The USB PHY provides the optimized for low power dissipation while active, idle, or on standby. Requires minimal external components, a single resistor, for best operation. Supports 10/5-Gbps high-speed data transmission rates through 3-m USB 3.x cable --- v3: - Andy's review comments update - hardcode return value changed to actual return value from the callee - add error check is fixed according to the above - correct the assignment in redundant - combine the split line into one line v2: - Address Phillip's review comments - replace devm_reset_control_get() by devm_reset_control_get_exclusive() - re-design the assert and deassert fucntion calls as per review comments - address kbuild bot warnings - add the comments v1: - initial version --- dt-bindings: usb: Add USB PHY support for Intel LGM SoC v3: - No Change v2: - No Change v1: - initial version Ramuthevar Vadivel Murugan (2): dt-bindings: usb: Add USB PHY support for Intel LGM SoC usb: phy: Add USB3 PHY support for Intel LGM SoC .../devicetree/bindings/usb/intel,lgm-usb-phy.yaml | 53 drivers/usb/phy/Kconfig| 11 + drivers/usb/phy/Makefile | 1 + drivers/usb/phy/phy-lgm-usb.c | 278 + 4 files changed, 343 insertions(+) create mode 100644 Documentation/devicetree/bindings/usb/intel,lgm-usb-phy.yaml create mode 100644 drivers/usb/phy/phy-lgm-usb.c -- 2.11.0
Compliment of the day,
Dear sir/madam
My name is Mrs Kadi Hamanin.I have decided to seek a confidential
co-operation with you for the execution of the deal described
hereunder for our mutual benefit. I Hope you will keep it a secret due
to the nature of the transaction. During the course of our audit last
month, I discovered an unclaimed/abandoned fund total US$3.5 million
in a bank account that belongs to a customer who unfortunately lost
his life and entire family in a car accident.
Now our bank has been waiting for any of the relatives to come-up for
the claim but nobody has done that. I personally has been unsuccessful
in locating any of the relatives, now, I sincerely seek your consent
to present you as the next of kin / Will Beneficiary to the deceased
so that the proceeds of this account valued at {US$3.5 Million United
State Dollars} can be paid to you, which we will share in these
percentages ratio, 60% to me and 40% to you. All I request is your
utmost sincere co- operation; trust and maximum confidentiality to
achieve this project successfully. I have carefully mapped out the
moralities for execution of this transaction under a legitimate
arrangement to protect you from any breach of the law both in your
country and here in my country when the fund is being transferred to
your bank account.
I will have to provide the entire relevant document that will be
requested to indicate that you are the rightful beneficiary of this
legacy and our bank will release the fund to you without any further
delay, upon your consideration and acceptance of this offer, please
send me the following information as stated below so we can proceed
and get this fund transferred to your designated bank account
immediately. I know much about the existence of this fund and the
secrets surrounding this money.
-Your Full Name:
-Your Contact Address:
-Your direct Mobile telephone Number:
-Your Date of Birth:
Re: [RFC PATCH 3/5] scsi: ufs: Introduce HPB module
> > + if (total_srgn_cnt != 0) {
> > +dev_err(hba->dev, "ufshpb(%d) error total_subregion_count %d",
> > + hpb->lun, total_srgn_cnt);
> > +goto release_srgn_table;
> > + }
> > +
> > + return 0;
> > +release_srgn_table:
> > + for (i = 0; i < rgn_idx; i++) {
> > +rgn = rgn_table + i;
> > +if (rgn->srgn_tbl)
> > + kvfree(rgn->srgn_tbl);
> > + }
> Please insert a blank line above goto labels as is done in most of the
> kernel code.
OK, I will fix it.
> > +static struct device_attribute ufshpb_sysfs_entries[] = {
> > + __ATTR(hit_count, 0444, ufshpb_sysfs_show_hit_cnt, NULL),
> > + __ATTR(miss_count, 0444, ufshpb_sysfs_show_miss_cnt, NULL),
> > + __ATTR(rb_noti_count, 0444, ufshpb_sysfs_show_rb_noti_cnt, NULL),
> > + __ATTR(rb_active_count, 0444, ufshpb_sysfs_show_rb_active_cnt, NULL),
> > + __ATTR(rb_inactive_count, 0444, ufshpb_sysfs_show_rb_inactive_cnt,
> > + NULL),
> > + __ATTR(map_req_count, 0444, ufshpb_sysfs_show_map_req_cnt, NULL),
> > + __ATTR_NULL
> > +};
> Please use __ATTR_RO() where appropriate.
They are only readable attributes. So I changed the code to use __ATTR_RO.
> > +static int ufshpb_create_sysfs(struct ufs_hba *hba, struct ufshpb_lu *hpb)
> > +{
> > + struct device_attribute *attr;
> > + int ret;
> > +
> > + device_initialize(>hpb_lu_dev);
> > +
> > + ufshpb_stat_init(hpb);
> > +
> > + hpb->hpb_lu_dev.parent = get_device(>ufsf.hpb_dev);
> > + hpb->hpb_lu_dev.release = ufshpb_dev_release;
> > + dev_set_name(>hpb_lu_dev, "ufshpb_lu%d", hpb->lun);
> > +
> > + ret = device_add(>hpb_lu_dev);
> > + if (ret) {
> > +dev_err(hba->dev, "ufshpb(%d) device_add failed",
> > + hpb->lun);
> > +return -ENODEV;
> > + }
> > +
> > + for (attr = ufshpb_sysfs_entries; attr->attr.name != NULL; attr++) {
> > +if (device_create_file(>hpb_lu_dev, attr))
> > + dev_err(hba->dev, "ufshpb(%d) %s create file error\n",
> > +hpb->lun, attr->attr.name);
> > + }
> > +
> > + return 0;
> > +}
> This is the wrong way to create sysfs attributes. Please set the
> 'groups' member of struct device instead of using a loop to create sysfs
> attributes. The former approach is compatible with udev but the latter
> approach is not.
OK, I changed to create attributes without loop.
> > +static void ufshpb_probe_async(void *data, async_cookie_t cookie)
> > +{
> > + struct ufshpb_dev_info hpb_dev_info = { 0 };
> > + struct ufs_hba *hba = data;
> > + char *desc_buf;
> > + int ret;
> > +
> > + desc_buf = kzalloc(QUERY_DESC_MAX_SIZE, GFP_KERNEL);
> > + if (!desc_buf)
> > +goto release_desc_buf;
> > +
> > + ret = ufshpb_get_dev_info(hba, _dev_info, desc_buf);
> > + if (ret)
> > +goto release_desc_buf;
> > +
> > + /*
> > + * Because HPB driver uses scsi_device data structure,
> > + * we should wait at this point until finishing initialization of all
> > + * scsi devices. Even if timeout occurs, HPB driver will search
> > + * the scsi_device list on struct scsi_host (shost->__host list_head)
> > + * and can find out HPB logical units in all scsi_devices
> > + */
> > + wait_event_timeout(hba->ufsf.sdev_wait,
> > + (atomic_read(>ufsf.slave_conf_cnt)
> > +== hpb_dev_info.num_lu),
> > + SDEV_WAIT_TIMEOUT);
> > +
> > + dev_dbg(hba->dev, "ufshpb: slave count %d, lu count %d\n",
> > +atomic_read(>ufsf.slave_conf_cnt), hpb_dev_info.num_lu);
> > +
> > + ufshpb_scan_hpb_lu(hba, _dev_info, desc_buf);
> > +release_desc_buf:
> > + kfree(desc_buf);
> > +}
> What happens if two LUNs are added before the above code is woken up?
> Will that perhaps cause the wait_event_timeout() call to wait forever?
I don't think it is problem. I think that the wait_event_timeout() will
check the condition before waiting.
> > +static int ufshpb_probe(struct device *dev)
> > +{
> > + struct ufs_hba *hba;
> > + struct ufsf_feature_info *ufsf;
> > +
> > + if (dev->type != _dev_type)
> > +return -ENODEV;
> > +
> > + ufsf = container_of(dev, struct ufsf_feature_info, hpb_dev);
> > + hba = container_of(ufsf, struct ufs_hba, ufsf);
> > +
> > + async_schedule(ufshpb_probe_async, hba);
> > + return 0;
> > +}
> So this is an asynchronous probe that is not visible to the device
> driver core? Could the PROBE_PREFER_ASYNCHRONOUS flag have been used
> instead to make device probing asynchronous?
I added the PROBE_PREFER_ASYNCHRONOUS flag to code and changed it to
probe synchronously.
> > +static int ufshpb_remove(struct device *dev)
> > +{
> > + struct ufshpb_lu *hpb, *n_hpb;
> > + struct ufsf_feature_info *ufsf;
> > + struct scsi_device *sdev;
> > +
> > + ufsf = container_of(dev, struct ufsf_feature_info, hpb_dev);
> > +
> > + dev_set_drvdata(>hpb_dev, NULL);
> > +
> > + list_for_each_entry_safe(hpb, n_hpb, _drv.lh_hpb_lu,
> > + list_hpb_lu) {
> > +ufshpb_set_state(hpb, HPB_FAILED);
> > +
> > +sdev = hpb->sdev_ufs_lu;
> > +sdev->hostdata = NULL;
> > +
> > +device_del(>hpb_lu_dev);
> > +
Re: [RFC PATCH 2/5] scsi: ufs: Add UFS-feature layer
Hi Bart,
On 2020-06-04 18:30, Daejun Park wrote:
> > +inline void ufsf_slave_configure(struct ufs_hba *hba,
> > + struct scsi_device *sdev)
> > +{
> > + /* skip well-known LU */
> > + if (sdev->lun >= UFS_UPIU_MAX_UNIT_NUM_ID)
> > +return;
> > +
> > + if (!(hba->dev_info.b_ufs_feature_sup & UFS_FEATURE_SUPPORT_HPB_BIT))
> > +return;
> > +
> > + atomic_inc(>ufsf.slave_conf_cnt);
> > + smp_mb__after_atomic(); /* for slave_conf_cnt */
> > +
> > + /* waiting sdev init.*/
> > + if (waitqueue_active(>ufsf.sdev_wait))
> > +wake_up(>ufsf.sdev_wait);
> > +}
> Guarding a wake_up() call with a waitqueue_active() check is an
> anti-pattern. Please don't do that and call wake_up() directly.
> Additionally, wake_up() includes a barrier if it wakes up a kernel
> thread so the smp_mb__after_atomic() can be left out if the
> waitqueue_active() call is removed.
OK, I will change it.
> > +/**
> > + * struct ufsf_operation - UFS feature specific callbacks
> > + * @prep_fn: called after construct upiu structure
> > + * @reset: called after proving hba
^^^
> Is this a typo? Should "proving" perhaps be changed into "probing"?
Yes, I will change.
> > +struct ufshpb_driver {
> > + struct device_driver drv;
> > + struct list_head lh_hpb_lu;
> > +
> > + struct ufsf_operation ufshpb_ops;
> > +
> > + /* memory management */
> > + struct kmem_cache *ufshpb_mctx_cache;
> > + mempool_t *ufshpb_mctx_pool;
> > + mempool_t *ufshpb_page_pool;
> > +
> > + struct workqueue_struct *ufshpb_wq;
> > +};
> Why is a dedicated workqueue needed? Why are the standard workqueues not
> good enough?
The map_work handles map related operations, including IO operations. So, adding
this task to the standard WQ can interfere with other jobs and degrade HPB
related performance.
> > @@ -2525,6 +2525,8 @@ static int ufshcd_queuecommand(struct Scsi_Host
> > *host, struct scsi_cmnd *cmd)
> >
> >ufshcd_comp_scsi_upiu(hba, lrbp);
> >
> > + ufsf_ops_prep_fn(hba, lrbp);
> > +
> >err = ufshcd_map_sg(hba, lrbp);
> >if (err) {
> > lrbp->cmd = NULL;
> What happens if a SCSI command is retried and hence ufsf_ops_prep_fn()
> is called multiple times for the same SCSI command?
Developers of UFS features should implement it so that prep_fn does not have
any problems even if it processes the same SCSI command multiple times.
In HPB feature, prep_fn modifies only upiu structure. So it is ok to call
it multiple times because the upiu is rebuilt from ufshcd_comp_scsi_upiu().
Thanks,
Daejun.
RE: [RFC PATCH 3/5] scsi: ufs: Introduce HPB module
> I think this module parameter makes its first appearance in patch 4/5 - so >maybe there? OK, I will write module parameter in patch message 4/5. Thanks, Daejun
RE: [PATCH 1/2] dmaengine: fsl-edma: Add lockdep assert for exported function
On 2020/06/11 20:18 Krzysztof Kozlowski wrote:
> Add lockdep assert for an exported function expected to be called under spin
> lock. Since this function is called in different modules, the lockdep assert
> will
> be self-documenting note about need for locking.
>
> Signed-off-by: Krzysztof Kozlowski
Reviewed-by: Robin Gong
> ---
> drivers/dma/fsl-edma-common.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/dma/fsl-edma-common.c
> b/drivers/dma/fsl-edma-common.c index 5697c3622699..4550818cca4a
> 100644
> --- a/drivers/dma/fsl-edma-common.c
> +++ b/drivers/dma/fsl-edma-common.c
> @@ -589,6 +589,8 @@ void fsl_edma_xfer_desc(struct fsl_edma_chan
> *fsl_chan) {
> struct virt_dma_desc *vdesc;
>
> + lockdep_assert_held(_chan->vchan.lock);
> +
> vdesc = vchan_next_desc(_chan->vchan);
> if (!vdesc)
> return;
> --
> 2.7.4
RE: [PATCH 2/2] dmaengine: fsl-edma: Fix NULL pointer exception in fsl_edma_tx_handler
On 2020/06/11 20:18 Krzysztof Kozlowski wrote:
> NULL pointer exception happens occasionally on serial output initiated by
> login
> timeout. This was reproduced only if kernel was built with significant
> debugging options and EDMA driver is used with serial console.
>
> col-vf50 login: root
> Password:
> Login timed out after 60 seconds.
> Unable to handle kernel NULL pointer dereference at virtual address
> 0044
> Internal error: Oops: 5 [#1] ARM
> CPU: 0 PID: 157 Comm: login Not tainted 5.7.0-next-20200610-dirty #4
> Hardware name: Freescale Vybrid VF5xx/VF6xx (Device Tree)
> (fsl_edma_tx_handler) from [<8016eb10>]
> (__handle_irq_event_percpu+0x64/0x304)
> (__handle_irq_event_percpu) from [<8016eddc>]
> (handle_irq_event_percpu+0x2c/0x7c)
> (handle_irq_event_percpu) from [<8016ee64>]
> (handle_irq_event+0x38/0x5c)
> (handle_irq_event) from [<801729e4>]
> (handle_fasteoi_irq+0xa4/0x160)
> (handle_fasteoi_irq) from [<8016ddcc>]
> (generic_handle_irq+0x34/0x44)
> (generic_handle_irq) from [<8016e40c>]
> (__handle_domain_irq+0x54/0xa8)
> (__handle_domain_irq) from [<80508bc8>] (gic_handle_irq+0x4c/0x80)
> (gic_handle_irq) from [<80100af0>] (__irq_svc+0x70/0x98)
> Exception stack(0x8459fe80 to 0x8459fec8)
> fe80: 72286b00 e3359f64 0001 412d a0070013 85c98840
> 85c98840 a0070013
> fea0: 8054e0d4 0002 0002 8459fed0
> 8081fbe8 8081fbec
> fec0: 60070013
> (__irq_svc) from [<8081fbec>]
> (_raw_spin_unlock_irqrestore+0x30/0x58)
> (_raw_spin_unlock_irqrestore) from [<8056cb48>]
> (uart_flush_buffer+0x88/0xf8)
> (uart_flush_buffer) from [<80554e60>] (tty_ldisc_hangup+0x38/0x1ac)
> (tty_ldisc_hangup) from [<8054c7f4>] (__tty_hangup+0x158/0x2bc)
> (__tty_hangup) from [<80557b90>]
> (disassociate_ctty.part.1+0x30/0x23c)
> (disassociate_ctty.part.1) from [<8011fc18>] (do_exit+0x580/0xba0)
> (do_exit) from [<801214f8>] (do_group_exit+0x3c/0xb4)
> (do_group_exit) from [<80121580>] (__wake_up_parent+0x0/0x14)
>
> Issue looks like race condition between interrupt handler
> fsl_edma_tx_handler()
> (called as result of fsl_edma_xfer_desc()) and terminating the transfer with
> fsl_edma_terminate_all().
>
> The fsl_edma_tx_handler() handles interrupt for a transfer with already freed
> edesc and idle==true.
>
> Fixes: d6be34fbd39b ("dma: Add Freescale eDMA engine driver support")
> Cc:
> Signed-off-by: Krzysztof Kozlowski
> ---
> drivers/dma/fsl-edma.c | 7 +++
> 1 file changed, 7 insertions(+)
>
> diff --git a/drivers/dma/fsl-edma.c b/drivers/dma/fsl-edma.c index
> eff7ebd8cf35..90bb72af306c 100644
> --- a/drivers/dma/fsl-edma.c
> +++ b/drivers/dma/fsl-edma.c
> @@ -45,6 +45,13 @@ static irqreturn_t fsl_edma_tx_handler(int irq, void
> *dev_id)
> fsl_chan = _edma->chans[ch];
>
> spin_lock(_chan->vchan.lock);
> +
> + if (!fsl_chan->edesc) {
> + /* terminate_all called before */
> + spin_unlock(_chan->vchan.lock);
> + continue;
> + }
Reviewed-by: Robin Gong
> +
> if (!fsl_chan->edesc->iscyclic) {
> list_del(_chan->edesc->vdesc.node);
> vchan_cookie_complete(_chan->edesc->vdesc);
> --
> 2.7.4
RE: [PATCH] dmaengine: mcf-edma: Fix NULL pointer exception in mcf_edma_tx_handler
On 2020/06/11 Krzysztof Kozlowski wrote:
> On Toradex Colibri VF50 (Vybrid VF5xx) with fsl-edma driver NULL pointer
> exception happens occasionally on serial output initiated by login timeout.
>
> This was reproduced only if kernel was built with significant debugging
> options
> and EDMA driver is used with serial console.
>
> Issue looks like a race condition between interrupt handler
> fsl_edma_tx_handler() (called as a result of fsl_edma_xfer_desc()) and
> terminating the transfer with fsl_edma_terminate_all().
>
> The fsl_edma_tx_handler() handles interrupt for a transfer with already freed
> edesc and idle==true.
>
> The mcf-edma driver shares design and lot of code with fsl-edma. It looks
> like
> being affected by same problem. Fix this pattern the same way as fix for
> fsl-edma driver.
>
> Fixes: e7a3ff92eaf1 ("dmaengine: fsl-edma: add ColdFire mcf5441x edma
> support")
> Cc:
> Signed-off-by: Krzysztof Kozlowski
Reviewed-by: Robin Gong
>
> ---
>
> Not tested on HW.
> ---
> drivers/dma/mcf-edma.c | 7 +++
> 1 file changed, 7 insertions(+)
>
> diff --git a/drivers/dma/mcf-edma.c b/drivers/dma/mcf-edma.c index
> e15bd15a9ef6..e12b754e6398 100644
> --- a/drivers/dma/mcf-edma.c
> +++ b/drivers/dma/mcf-edma.c
> @@ -35,6 +35,13 @@ static irqreturn_t mcf_edma_tx_handler(int irq, void
> *dev_id)
> mcf_chan = _edma->chans[ch];
>
> spin_lock(_chan->vchan.lock);
> +
> + if (!mcf_chan->edesc) {
> + /* terminate_all called before */
> + spin_unlock(_chan->vchan.lock);
> + continue;
> + }
> +
> if (!mcf_chan->edesc->iscyclic) {
> list_del(_chan->edesc->vdesc.node);
> vchan_cookie_complete(_chan->edesc->vdesc);
> --
> 2.7.4
RE: [PATCH v1 RFC 1/2] spi: introduce fallback to pio
On 2020/06/11 21: 41 Mark Brown wrote:
> On Thu, Jun 11, 2020 at 08:58:29PM +0800, Robin Gong wrote:
> > Add SPI_CONTROLLER_FALLBACK to fallback to pio mode in case dma
> > transfer failed.
> > If spi client driver want to enable this feature please set
> > master->flags with SPI_MASTER_FALLBACK and add master->fallback
> > checking in its can_dma() as spi-imx.c
>
> If we were going to do this I don't see why we'd have a flag for this rather
> than
> just doing it unconditionally but...
What do you mean flag here, 'master->flags' or SPI_MASTER_FALLBACK?
'master->flags'
could let client fallback to PIO finally and spi core clear this flag once this
transfer done,
so that DMA could be tried again in the next transfer. Client could enable this
feature by choosing SPI_MASTER_FALLBACK freely without any impact on others.
>
> > ret = ctlr->transfer_one(ctlr, msg->spi, xfer);
> > if (ret < 0) {
> > + if (ctlr->cur_msg_mapped &&
> > + (ctlr->flags & SPI_CONTROLLER_FALLBACK)) {
> > + __spi_unmap_msg(ctlr, msg);
> > + ctlr->fallback = true;
> > + goto fallback_pio;
> > + }
>
> ...I don't think this can work sensibly - this is going to try PIO if there's
> *any*
> error. We might have had some sort of issue during the transfer for example
> so have some noise on the bus. Like I said on a prior version of this I
> really
Any error happen in DMA could fallback to PIO , seems a nice to have, because
it could
give chance to run in PIO which is more reliable. But if there is also error in
PIO, thus may loop here, it's better adding limit try times here?
> think that we need to be figuring out if the DMA controller can support the
> transaction before we even map the buffer for it, having the controller just
> randomly fail underneath the consumer just does not sound robust.
But dmaengine_prep_slave_sg still may return failure even if anything about
DMA is ok before spi transfer start, such as dma description malloc failure.
This
patch seems could make spi a bit robust...
Re: [RFC PATCH v2 3/3] ASoC: fsl_asrc_dma: Reuse the dma channel if available in Back-End
On Fri, Jun 12, 2020 at 8:33 AM Nicolin Chen wrote:
>
> On Wed, Jun 10, 2020 at 06:05:49PM +0800, Shengjiu Wang wrote:
> > The dma channel has been requested by Back-End cpu dai driver already.
> > If fsl_asrc_dma requests dma chan with same dma:tx symlink, then
> > there will be below warning with SDMA.
> >
> > [ 48.174236] fsl-esai-dai 2024000.esai: Cannot create DMA dma:tx symlink
> >
> > or with EDMA the request operation will fail for EDMA channel
> > can only be requested once.
> >
> > So If we can reuse the dma channel of Back-End, then the issue can be
> > fixed.
> >
> > In order to get the dma channel which is already requested in Back-End.
> > we use the exported two functions (snd_soc_lookup_component_nolocked
> > and soc_component_to_pcm). If we can get the dma channel, then reuse it,
> > if can't, then request a new one.
> >
> > Signed-off-by: Shengjiu Wang
> > ---
> > sound/soc/fsl/fsl_asrc_common.h | 2 ++
> > sound/soc/fsl/fsl_asrc_dma.c| 52 +
> > 2 files changed, 42 insertions(+), 12 deletions(-)
>
> > diff --git a/sound/soc/fsl/fsl_asrc_common.h
> > b/sound/soc/fsl/fsl_asrc_common.h
> > index 77665b15c8db..09512bc79b80 100644
> > --- a/sound/soc/fsl/fsl_asrc_common.h
> > +++ b/sound/soc/fsl/fsl_asrc_common.h
> > @@ -32,6 +32,7 @@ enum asrc_pair_index {
> > * @dma_chan: inputer and output DMA channels
> > * @dma_data: private dma data
> > * @pos: hardware pointer position
> > + * @req_dma_chan_dev_to_dev: flag for release dev_to_dev chan
>
> Since we only have dma_request call for back-end only:
> + * @req_dma_chan: flag to release back-end dma chan
I prefer to use the description "flag to release dev_to_dev chan"
because we won't release the dma chan of the back-end. if the chan
is from the back-end, it is owned by the back-end component.
>
> > diff --git a/sound/soc/fsl/fsl_asrc_dma.c b/sound/soc/fsl/fsl_asrc_dma.c
> > index d6a3fc5f87e5..5ecb77d466d3 100644
> > --- a/sound/soc/fsl/fsl_asrc_dma.c
> > +++ b/sound/soc/fsl/fsl_asrc_dma.c
> > @@ -160,6 +161,9 @@ static int fsl_asrc_dma_hw_params(struct
> > snd_soc_component *component,
> > substream_be = snd_soc_dpcm_get_substream(be, stream);
> > dma_params_be = snd_soc_dai_get_dma_data(dai, substream_be);
> > dev_be = dai->dev;
> > + component_be = snd_soc_lookup_component_nolocked(dev_be,
> > SND_DMAENGINE_PCM_DRV_NAME);
> > + if (component_be)
> > + tmp_chan =
> > soc_component_to_pcm(component_be)->chan[substream->stream];
>
> Should we use substream_be->stream or just substream->stream?
substream_be->stream should be better.
>
> And would be better to add these lines right before we really use
> tmp_chan because there's still some distance till it reaches that
> point. And would be better to have a line of comments too.
ok.
>
> > @@ -205,10 +209,14 @@ static int fsl_asrc_dma_hw_params(struct
> > snd_soc_component *component,
> >*/
> > if (!asrc->use_edma) {
> > /* Get DMA request of Back-End */
> > - tmp_chan = dma_request_slave_channel(dev_be, tx ? "tx" :
> > "rx");
> > + if (!tmp_chan) {
> > + tmp_chan_new = dma_request_slave_channel(dev_be, tx ?
> > "tx" : "rx");
> > + tmp_chan = tmp_chan_new;
>
> This is a bit confusing...though I finally got it :)
> So probably better to have a line of comments.
ok.
>
> > @@ -220,9 +228,26 @@ static int fsl_asrc_dma_hw_params(struct
> > snd_soc_component *component,
> >
> > pair->dma_chan[dir] =
> > dma_request_channel(mask, filter, >dma_data);
> > + pair->req_dma_chan_dev_to_dev = true;
> > } else {
> > - pair->dma_chan[dir] =
> > - asrc->get_dma_channel(pair, dir);
> > + /*
> > + * With EDMA, there is two dma channels can be used for p2p,
> > + * one is from ASRC, one is from another peripheral
> > + * (ESAI or SAI). Previously we select the dma channel of
> > ASRC,
> > + * but find an issue for ideal ratio case, there is no control
> > + * for data copy speed, the speed is faster than sample
> > + * frequency.
> > + *
> > + * So we switch to use dma channel of peripheral (ESAI or
> > SAI),
> > + * that copy speed of DMA is controlled by data consumption
> > + * speed in the peripheral FIFO.
> > + */
>
> This sounds like a different issue and should be fixed separately?
> If you prefer not to, better to move this one to commit log, other
> than having a changelog here, in my opinion.
ok, will move it in commit log.
>
> Since it no longer uses get_dma_channel() for EDMA case, we should
> update the comments at the top as well.
>
> > + pair->req_dma_chan_dev_to_dev = false;
> > +
Re: [PATCH 2/2] arm-nommu: Add use_reserved_mem() to check if device support reserved memory
On Thu, Jun 11, 2020 at 11:45 PM Vladimir Murzin
wrote:
>
> On 6/10/20 9:19 AM, Vladimir Murzin wrote:
> > On 6/10/20 8:24 AM, Christoph Hellwig wrote:
> >> Ok, I finally found the original patch from Vladimir. Comments below:
> >>
> >>> +++ b/kernel/dma/direct.c
> >>> @@ -456,14 +456,14 @@ int dma_direct_mmap(struct device *dev, struct
> >>> vm_area_struct *vma,
> >>> #else /* CONFIG_MMU */
> >>> bool dma_direct_can_mmap(struct device *dev)
> >>> {
> >>> - return false;
> >>> + return true;
> >>> }
> >>>
> >>> int dma_direct_mmap(struct device *dev, struct vm_area_struct *vma,
> >>> void *cpu_addr, dma_addr_t dma_addr, size_t size,
> >>> unsigned long attrs)
> >>> {
> >>> - return -ENXIO;
> >>> + return vm_iomap_memory(vma, vma->vm_start, (vma->vm_end -
> >>> vma->vm_start));;
> >>
> >> I think we should try to reuse the mmu dma_direct_mmap implementation,
> >> which does about the same. This version has been compile tested on
> >> arm-nommu only, let me know what you think: (btw, a nommu_defconfig of
> >> some kind for arm would be nice..)
> >
> > Catch-all nommu_defconfig is not easy for ARM, AFAIK folk carry few hacks
> > for randconfig...
> >
> > Meanwhile, known working NOMMU configs
> >
> > $ git grep "# CONFIG_MMU is not set" arch/arm/configs/
> > arch/arm/configs/efm32_defconfig:# CONFIG_MMU is not set
> > arch/arm/configs/lpc18xx_defconfig:# CONFIG_MMU is not set
> > arch/arm/configs/mps2_defconfig:# CONFIG_MMU is not set
> > arch/arm/configs/stm32_defconfig:# CONFIG_MMU is not set
> > arch/arm/configs/vf610m4_defconfig:# CONFIG_MMU is not set
> >
> >>
> >> diff --git a/kernel/dma/Kconfig b/kernel/dma/Kconfig
> >> index d006668c0027d2..e0dae570a51530 100644
> >> --- a/kernel/dma/Kconfig
> >> +++ b/kernel/dma/Kconfig
> >> @@ -71,6 +71,7 @@ config SWIOTLB
> >> # in the pagetables
> >> #
> >> config DMA_NONCOHERENT_MMAP
> >> +default y if !MMU
> >> bool
> >
> > Nit: def_bool !MMU
> >
> >>
> >> config DMA_REMAP
> >> diff --git a/kernel/dma/direct.c b/kernel/dma/direct.c
> >> index 0a4881e59aa7d6..9ec6a5c3fc578c 100644
> >> --- a/kernel/dma/direct.c
> >> +++ b/kernel/dma/direct.c
> >> @@ -459,7 +459,6 @@ int dma_direct_get_sgtable(struct device *dev, struct
> >> sg_table *sgt,
> >> return ret;
> >> }
> >>
> >> -#ifdef CONFIG_MMU
> >> bool dma_direct_can_mmap(struct device *dev)
> >> {
> >> return dev_is_dma_coherent(dev) ||
> >> @@ -485,19 +484,6 @@ int dma_direct_mmap(struct device *dev, struct
> >> vm_area_struct *vma,
> >> return remap_pfn_range(vma, vma->vm_start, pfn + vma->vm_pgoff,
> >> user_count << PAGE_SHIFT, vma->vm_page_prot);
> >> }
> >> -#else /* CONFIG_MMU */
> >> -bool dma_direct_can_mmap(struct device *dev)
> >> -{
> >> -return false;
> >> -}
> >> -
> >> -int dma_direct_mmap(struct device *dev, struct vm_area_struct *vma,
> >> -void *cpu_addr, dma_addr_t dma_addr, size_t size,
> >> -unsigned long attrs)
> >> -{
> >> -return -ENXIO;
> >> -}
> >> -#endif /* CONFIG_MMU */
> >>
> >> int dma_direct_supported(struct device *dev, u64 mask)
> >> {
> >>
> >
> > LGTM. FWIW:
> >
> > Reviewed-by: Vladimir Murzin
> >
> >
>
> @dillon, can you give it a try?
>
> I think Christoph would appreciate your Tested-by and that might speed up
> getting fix mainline.
>
sorry for the late response. Yes, it's working
Thanks Christoph
index 8f4bbdaf965e..3e0ecf0b5fb3 100644
--- a/kernel/dma/direct.c
+++ b/kernel/dma/direct.c
@@ -427,7 +427,6 @@ int dma_direct_get_sgtable(struct device *dev,
struct sg_table *sgt,
return ret;
}
-#ifdef CONFIG_MMU
bool dma_direct_can_mmap(struct device *dev)
{
return dev_is_dma_coherent(dev) ||
@@ -453,19 +452,6 @@ int dma_direct_mmap(struct device *dev, struct
vm_area_struct *vma,
return remap_pfn_range(vma, vma->vm_start, pfn + vma->vm_pgoff,
user_count << PAGE_SHIFT, vma->vm_page_prot);
}
-#else /* CONFIG_MMU */
-bool dma_direct_can_mmap(struct device *dev)
-{
- return false;
-}
-
-int dma_direct_mmap(struct device *dev, struct vm_area_struct *vma,
- void *cpu_addr, dma_addr_t dma_addr, size_t size,
- unsigned long attrs)
-{
- return -ENXIO;
-}
-#endif /* CONFIG_MMU */
Tested-by: dillon min
>
> Cheers
> Vladimir
>
> > ___
> > linux-arm-kernel mailing list
> > linux-arm-ker...@lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> >
>
RE: [PATCH v2 0/2] scsi: ufs: Fix and cleanup device quirks
Hi Stanley, > -Original Message- > From: Stanley Chu > Sent: 12 June 2020 06:56 > To: linux-s...@vger.kernel.org; martin.peter...@oracle.com; > avri.alt...@wdc.com; alim.akh...@samsung.com; j...@linux.ibm.com; > asuto...@codeaurora.org > Cc: bean...@micron.com; c...@codeaurora.org; matthias@gmail.com; > bvanass...@acm.org; linux-media...@lists.infradead.org; linux-arm- > ker...@lists.infradead.org; linux-kernel@vger.kernel.org; > kuohong.w...@mediatek.com; peter.w...@mediatek.com; chun- > hung...@mediatek.com; andy.t...@mediatek.com; > chaotian.j...@mediatek.com; cc.c...@mediatek.com; Stanley Chu > > Subject: [PATCH v2 0/2] scsi: ufs: Fix and cleanup device quirks > > Hi, > this series provides some device quirk fixes and cleanups. > > v1 -> v2: > - Sort device quirks in alphabetical order (Alim Akhtar) > > Stanley Chu (2): > scsi: ufs: Add DELAY_BEFORE_LPM quirk for Micron devices > scsi: ufs: Cleanup device vendor name and device quirk table > > drivers/scsi/ufs/ufs_quirks.h | 3 ++- > drivers/scsi/ufs/ufshcd.c | 15 +++ > 2 files changed, 9 insertions(+), 9 deletions(-) > For this series Reviewed-by: Alim Akhtar Thanks! > -- > 2.18.0
Re: [GIT pull V2] locking/kcsan for v5.8
The pull request you sent on Fri, 12 Jun 2020 00:24:49 -: > git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git > locking-kcsan-2020-06-11 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/b791d1bdf9212d944d749a5c7ff6febdba241771 Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
Re: [GIT pull V2] locking/urgent for v5.8
The pull request you sent on Fri, 12 Jun 2020 00:24:48 -: > git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git > locking-urgent-2020-06-11 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/37d1a04b13a6d2fec91a6813fc034947a27db034 Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
[PATCH 2/4] rcu: grplo/grphi just records CPU number
We store lowest and highest CPU number belongs to a rcu_node, which is
not the group number.
Signed-off-by: Wei Yang
---
kernel/rcu/tree.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/kernel/rcu/tree.h b/kernel/rcu/tree.h
index ed9b534ad870..ce9ab7371706 100644
--- a/kernel/rcu/tree.h
+++ b/kernel/rcu/tree.h
@@ -73,8 +73,8 @@ struct rcu_node {
unsigned long ffmask; /* Fully functional CPUs. */
unsigned long grpmask; /* Mask to apply to parent qsmask. */
/* Only one bit will be set in this mask. */
- int grplo; /* lowest-numbered CPU or group here. */
- int grphi; /* highest-numbered CPU or group here. */
+ int grplo; /* lowest-numbered CPU here. */
+ int grphi; /* highest-numbered CPU here. */
u8 grpnum; /* CPU/group number for next level up. */
u8 level; /* root is at level 0. */
boolwait_blkd_tasks;/* Necessary to wait for blocked tasks to */
--
2.20.1 (Apple Git-117)
[PATCH 1/4] rcu: gp_max is protected by root rcu_node's lock
gp_max is protected by root rcu_node's lock, let's move the definition
to the place where comments indicate.
Signed-off-by: Wei Yang
---
kernel/rcu/tree.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/kernel/rcu/tree.h b/kernel/rcu/tree.h
index 43991a40b084..ed9b534ad870 100644
--- a/kernel/rcu/tree.h
+++ b/kernel/rcu/tree.h
@@ -301,6 +301,8 @@ struct rcu_state {
u8 boost cacheline_internodealigned_in_smp;
/* Subject to priority boost. */
unsigned long gp_seq; /* Grace-period sequence #. */
+ unsigned long gp_max; /* Maximum GP duration in */
+ /* jiffies. */
struct task_struct *gp_kthread; /* Task for grace periods. */
struct swait_queue_head gp_wq; /* Where GP task waits. */
short gp_flags; /* Commands for GP task. */
@@ -346,8 +348,6 @@ struct rcu_state {
/* a reluctant CPU. */
unsigned long n_force_qs_gpstart; /* Snapshot of n_force_qs at */
/* GP start. */
- unsigned long gp_max; /* Maximum GP duration in */
- /* jiffies. */
const char *name; /* Name of structure. */
char abbr; /* Abbreviated name. */
--
2.20.1 (Apple Git-117)
[PATCH 0/4] rcu: trivial adjust for comments
During code reading, I found there are several mismatch between comments and code implementation. Adjust the comment for better understanding. Wei Yang (4): rcu: gp_max is protected by root rcu_node's lock rcu: grplo/grphi just records CPU number rcu: grpnum just records group number rcu: use gp_seq instead of rcu_gp_seq for consistency kernel/rcu/tree.h | 14 +++--- 1 file changed, 7 insertions(+), 7 deletions(-) -- 2.20.1 (Apple Git-117)
[PATCH 3/4] rcu: grpnum just records group number
grpnum in rcu_node means the position in its parent, which is not the
CPU number even in last level.
Signed-off-by: Wei Yang
---
kernel/rcu/tree.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/rcu/tree.h b/kernel/rcu/tree.h
index ce9ab7371706..512829eed545 100644
--- a/kernel/rcu/tree.h
+++ b/kernel/rcu/tree.h
@@ -75,7 +75,7 @@ struct rcu_node {
/* Only one bit will be set in this mask. */
int grplo; /* lowest-numbered CPU here. */
int grphi; /* highest-numbered CPU here. */
- u8 grpnum; /* CPU/group number for next level up. */
+ u8 grpnum; /* group number for next level up. */
u8 level; /* root is at level 0. */
boolwait_blkd_tasks;/* Necessary to wait for blocked tasks to */
/* exit RCU read-side critical sections */
--
2.20.1 (Apple Git-117)
[PATCH 4/4] rcu: use gp_seq instead of rcu_gp_seq for consistency
Commit de30ad512a66 ("rcu: Introduce grace-period sequence numbers")
introduce gp_seq in rcu_state/rcu_node/rcu_data. And this field in last
two structure track the one in first.
While the comment use rcu_gp_seq which is a little misleading for
audience. Let's use the exact name gp_seq for consistency.
Signed-off-by: Wei Yang
---
kernel/rcu/tree.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/kernel/rcu/tree.h b/kernel/rcu/tree.h
index 512829eed545..3356842bc185 100644
--- a/kernel/rcu/tree.h
+++ b/kernel/rcu/tree.h
@@ -41,7 +41,7 @@ struct rcu_node {
raw_spinlock_t __private lock; /* Root rcu_node's lock protects */
/* some rcu_state fields as well as */
/* following. */
- unsigned long gp_seq; /* Track rsp->rcu_gp_seq. */
+ unsigned long gp_seq; /* Track rsp->gp_seq. */
unsigned long gp_seq_needed; /* Track furthest future GP request. */
unsigned long completedqs; /* All QSes done for this node. */
unsigned long qsmask; /* CPUs or groups that need to switch in */
@@ -149,7 +149,7 @@ union rcu_noqs {
/* Per-CPU data for read-copy update. */
struct rcu_data {
/* 1) quiescent-state and grace-period handling : */
- unsigned long gp_seq; /* Track rsp->rcu_gp_seq counter. */
+ unsigned long gp_seq; /* Track rsp->gp_seq. */
unsigned long gp_seq_needed; /* Track furthest future GP request. */
union rcu_noqs cpu_no_qs; /* No QSes yet for this CPU. */
boolcore_needs_qs; /* Core waits for quiesc state. */
--
2.20.1 (Apple Git-117)
Re: [PATCH V2] crypto: talitos - fix ECB and CBC algs ivsize
Cool, thanks!
yin
On Thu, 11 Jun 2020 at 21:57, Greg KH wrote:
>
> On Thu, Jun 11, 2020 at 07:50:47PM +0800, Su Kang Yin wrote:
> > commit e1de42fdfc6a ("crypto: talitos - fix ECB algs ivsize")
> > wrongly modified CBC algs ivsize instead of ECB aggs ivsize.
> >
> > This restore the CBC algs original ivsize of removes ECB's ones.
> >
> > Fixes: e1de42fdfc6a ("crypto: talitos - fix ECB algs ivsize")
> > Signed-off-by: Su Kang Yin
> > ---
> > Patch for 4.9 upstream.
>
> Also seems to be an issue for the 4.14 and 4.19 backport, so I'll queue
> it up there too, thanks!
>
> greg k-h
Re: [PATCH v4 1/2] hugetlb: use f_mode & FMODE_HUGETLBFS to identify hugetlbfs files
On Thu, Jun 11, 2020 at 05:46:43PM -0700, Mike Kravetz wrote: > The routine is_file_hugepages() checks f_op == hugetlbfs_file_operations > to determine if the file resides in hugetlbfs. This is problematic when > the file is on a union or overlay. Instead, define a new file mode > FMODE_HUGETLBFS which is set when a hugetlbfs file is opened. The mode > can easily be copied to other 'files' derived from the original hugetlbfs > file. > > With this change hugetlbfs_file_operations can be static as it should be. > > There is also a (duplicate) set of shm file operations used for the routine > is_file_shm_hugepages(). Instead of setting/using special f_op's, just > propagate the FMODE_HUGETLBFS mode. This means is_file_shm_hugepages() and > the duplicate f_ops can be removed. s/HUGETLBFS/HUGEPAGES/, please. > While cleaning things up, change the name of is_file_hugepages() to > is_file_hugetlbfs(). The term hugepages is a bit ambiguous. Don't, especially since the very next patch adds such on overlayfs... Incidentally, can a hugetlbfs be a lower layer, while the upper one is a normal filesystem? What should happen on copyup?
Re: possible deadlock in send_sigio
On 6/11/20 7:55 PM, Boqun Feng wrote: Hi Peter and Waiman, On Thu, Jun 11, 2020 at 12:09:59PM -0400, Waiman Long wrote: On 6/11/20 10:22 AM, Peter Zijlstra wrote: On Thu, Jun 11, 2020 at 09:51:29AM -0400, Waiman Long wrote: There was an old lockdep patch that I think may address the issue, but was not merged at the time. I will need to dig it out and see if it can be adapted to work in the current kernel. It may take some time. Boqun was working on that; I can't remember what happened, but ISTR it was shaping up nice. Yes, I am talking about Boqun's patch. However, I think he had moved to another company and so may not be able to actively work on that again. I think you are talking about the rescursive read deadlock detection patchset: https://lore.kernel.org/lkml/20180411135110.9217-1-boqun.f...@gmail.com/ Let me have a good and send a new version based on today's master of tip tree. Regards, Boqun Good to hear back from you. I thought you may not able to work on it again. Cheers, Longman
Re: [PATCH v4 1/2] hugetlb: use f_mode & FMODE_HUGETLBFS to identify hugetlbfs files
On Thu, Jun 11, 2020 at 05:46:43PM -0700, Mike Kravetz wrote: > The routine is_file_hugepages() checks f_op == hugetlbfs_file_operations > to determine if the file resides in hugetlbfs. This is problematic when > the file is on a union or overlay. Instead, define a new file mode > FMODE_HUGETLBFS which is set when a hugetlbfs file is opened. The mode > can easily be copied to other 'files' derived from the original hugetlbfs > file. > > With this change hugetlbfs_file_operations can be static as it should be. > > There is also a (duplicate) set of shm file operations used for the routine > is_file_shm_hugepages(). Instead of setting/using special f_op's, just > propagate the FMODE_HUGETLBFS mode. This means is_file_shm_hugepages() and > the duplicate f_ops can be removed. > > While cleaning things up, change the name of is_file_hugepages() to > is_file_hugetlbfs(). The term hugepages is a bit ambiguous. I was going to have objections to this before I read it more carefully and realised that the "shm" here is sysvipc and doesn't have anything to do with the huge page support in shmfs. > A subsequent patch will propagate FMODE_HUGETLBFS in overlayfs. > > Suggested-by: Al Viro > Signed-off-by: Mike Kravetz Reviewed-by: Matthew Wilcox (Oracle) I might have suggested splitting the rename of is_file_hugetlbfs() from the rest of this patch, but I wouldn't resend to change that.
[PATCH v6 4/5] drm/msm/dp: add support for DP PLL driver
From: Chandan Uddaraju
Add the needed DP PLL specific files to support
display port interface on msm targets.
The DP driver calls the DP PLL driver registration.
The DP driver sets the link and pixel clock sources.
Changes in v2:
-- Update copyright markings on all relevant files.
-- Use DRM_DEBUG_DP for debug msgs.
Changes in v4:
-- Update the DP link clock provider names
Changes in V5:
-- Addressed comments from Stephen Boyd, Rob clark.
Changes in V6:
-- Remove PLL as separate driver and include PLL as DP module
-- Remove redundant clock parsing from PLL module and make DP as
clock provider
-- Map USB3 DPCOM and PHY IO using hardcoded register address and
move mapping form parser to PLL module
-- Access DP PHY modules from same base address using offsets instead of
deriving base address of individual module from device tree.
-- Remove dp_pll_10nm_util.c and include its functionality in
dp_pll_10nm.c
-- Introduce new data structures private to PLL module
Signed-off-by: Chandan Uddaraju
Signed-off-by: Vara Reddy
Signed-off-by: Tanmay Shah
---
drivers/gpu/drm/msm/Kconfig | 13 +
drivers/gpu/drm/msm/Makefile| 3 +
drivers/gpu/drm/msm/dp/dp_catalog.c | 64 +-
drivers/gpu/drm/msm/dp/dp_display.c | 17 +-
drivers/gpu/drm/msm/dp/dp_display.h | 3 +
drivers/gpu/drm/msm/dp/dp_parser.c | 51 +-
drivers/gpu/drm/msm/dp/dp_parser.h | 9 +-
drivers/gpu/drm/msm/dp/dp_pll.c | 93 +++
drivers/gpu/drm/msm/dp/dp_pll.h | 59 ++
drivers/gpu/drm/msm/dp/dp_pll_10nm.c| 903
drivers/gpu/drm/msm/dp/dp_pll_private.h | 103 +++
drivers/gpu/drm/msm/dp/dp_power.c | 10 +
drivers/gpu/drm/msm/dp/dp_power.h | 71 +-
drivers/gpu/drm/msm/dp/dp_reg.h | 16 +
14 files changed, 1349 insertions(+), 66 deletions(-)
create mode 100644 drivers/gpu/drm/msm/dp/dp_pll.c
create mode 100644 drivers/gpu/drm/msm/dp/dp_pll.h
create mode 100644 drivers/gpu/drm/msm/dp/dp_pll_10nm.c
create mode 100644 drivers/gpu/drm/msm/dp/dp_pll_private.h
diff --git a/drivers/gpu/drm/msm/Kconfig b/drivers/gpu/drm/msm/Kconfig
index ea3c4d094d09..43544c18b4ee 100644
--- a/drivers/gpu/drm/msm/Kconfig
+++ b/drivers/gpu/drm/msm/Kconfig
@@ -65,6 +65,19 @@ config DRM_MSM_DP
display support is enabled through this config option. It can
be primary or secondary display on device.
+config DRM_MSM_DP_PLL
+ bool "Enable DP PLL driver in MSM DRM"
+ depends on DRM_MSM_DP && COMMON_CLK
+ help
+ Choose this option to enable DP PLL driver which provides DP
+ source clocks under common clock framework.
+
+config DRM_MSM_DP_10NM_PLL
+ bool "Enable DP 10nm PLL driver in MSM DRM (used by SDM845)"
+ depends on DRM_MSM_DP_PLL
+ help
+ Choose this option if DP PLL on SDM845 is used on the platform.
+
config DRM_MSM_DSI
bool "Enable DSI support in MSM DRM driver"
depends on DRM_MSM
diff --git a/drivers/gpu/drm/msm/Makefile b/drivers/gpu/drm/msm/Makefile
index af868e791210..af259c6a13da 100644
--- a/drivers/gpu/drm/msm/Makefile
+++ b/drivers/gpu/drm/msm/Makefile
@@ -140,4 +140,7 @@ msm-$(CONFIG_DRM_MSM_DSI_14NM_PHY) += dsi/pll/dsi_pll_14nm.o
msm-$(CONFIG_DRM_MSM_DSI_10NM_PHY) += dsi/pll/dsi_pll_10nm.o
endif
+msm-$(CONFIG_DRM_MSM_DP_PLL)+= dp/dp_pll.o
+msm-$(CONFIG_DRM_MSM_DP_10NM_PLL)+= dp/dp_pll_10nm.o
+
obj-$(CONFIG_DRM_MSM) += msm.o
diff --git a/drivers/gpu/drm/msm/dp/dp_catalog.c
b/drivers/gpu/drm/msm/dp/dp_catalog.c
index d02f4eba5d1d..2b982f02c4cd 100644
--- a/drivers/gpu/drm/msm/dp/dp_catalog.c
+++ b/drivers/gpu/drm/msm/dp/dp_catalog.c
@@ -5,6 +5,7 @@
#define pr_fmt(fmt)"[drm-dp] %s: " fmt, __func__
+#include
#include
#include
#include
@@ -134,59 +135,61 @@ static inline void dp_write_ahb(struct dp_catalog_private
*catalog,
writel(data, catalog->io->dp_controller.base + offset);
}
-static inline u32 dp_read_cc(struct dp_catalog_private *catalog, u32 offset)
-{
- return readl_relaxed(catalog->io->dp_cc_io.base + offset);
-}
-
static inline void dp_write_phy(struct dp_catalog_private *catalog,
u32 offset, u32 data)
{
+ offset += DP_PHY_REG_OFFSET;
/*
* To make sure phy reg writes happens before any other operation,
* this function uses writel() instread of writel_relaxed()
*/
- writel(data, catalog->io->phy_io.base + offset);
+ writel(data, catalog->io->phy_reg.base + offset);
}
static inline u32 dp_read_phy(struct dp_catalog_private *catalog,
u32 offset)
{
+ offset += DP_PHY_REG_OFFSET;
/*
* To make sure phy reg writes happens before any other operation,
* this function uses writel() instread of writel_relaxed()
*/
- return readl_relaxed(catalog->io->phy_io.base + offset);
+ return readl_relaxed(catalog->io->phy_reg.base +
