Re: [PATCH 2/3] pagewalk: separate function pointers from iterator data
On Sun, Sep 01, 2019 at 01:35:16PM -0700, Guenter Roeck wrote:
> > I belive the macros above are missing brackets.. Can you confirm the
> > below takes care of things? I'll add a patch if so
> >
>
> Good catch. Yes, that fixes the build problem.
I added this to the hmm tree to fix it:
>From 6a7e550e0f1c1eeab75e0e2c7ffe5e9e9ae649ba Mon Sep 17 00:00:00 2001
From: Jason Gunthorpe
Date: Mon, 2 Sep 2019 02:47:05 -0300
Subject: [PATCH] csky: add missing brackets in a macro for tlb.h
As an earlier patch made the macro argument more complicated, compilation
now fails with:
In file included from mm/madvise.c:30:
mm/madvise.c: In function 'madvise_free_single_vma':
arch/csky/include/asm/tlb.h:11:11: error:
invalid type argument of '->' (have 'struct mmu_gather')
Link: https://lore.kernel.org/r/20190901193601.gb5...@mellanox.com
Fixes: 923bfc561e75 ("pagewalk: separate function pointers from iterator data")
Reported-by: Guenter Roeck
Signed-off-by: Jason Gunthorpe
---
arch/csky/include/asm/tlb.h | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/csky/include/asm/tlb.h b/arch/csky/include/asm/tlb.h
index 8c7cc097666f04..fdff9b8d70c811 100644
--- a/arch/csky/include/asm/tlb.h
+++ b/arch/csky/include/asm/tlb.h
@@ -8,14 +8,14 @@
#define tlb_start_vma(tlb, vma) \
do { \
- if (!tlb->fullmm) \
- flush_cache_range(vma, vma->vm_start, vma->vm_end); \
+ if (!(tlb)->fullmm) \
+ flush_cache_range(vma, (vma)->vm_start, (vma)->vm_end);
\
} while (0)
#define tlb_end_vma(tlb, vma) \
do { \
- if (!tlb->fullmm) \
- flush_tlb_range(vma, vma->vm_start, vma->vm_end); \
+ if (!(tlb)->fullmm) \
+ flush_tlb_range(vma, (vma)->vm_start, (vma)->vm_end); \
} while (0)
#define tlb_flush(tlb) flush_tlb_mm((tlb)->mm)
--
2.23.0
[PATCHv4-next 1/3] arm64: dts: meson: odroid-c2: p5v0 is the main 5V power input
As per the schematic Monolithic Power Systems MP2161GJ-C499
supply a fixed output voltage of 5.0V. This supplies linked
to VDD_EE, HDMI_P5V0, USB_POWER, VCCK, VDDIO_AO1V8, VDDIO_AO3V3,
VDD3V3, DDR3_1V5 according to the schematics.
Cc: Martin Blumenstingl
Cc: Jerome Brunet
Cc: Neil Armstrong
Acked-by: Martin Blumenstingl
Signed-off-by: Anand Moon
---
Rebased on linux-next.
Added Acked by Martin.
Fixed the commit message to add misssing VDDIO_AO3V3 and VDD3V3.
---
arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts | 9 +
1 file changed, 9 insertions(+)
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
b/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
index 6039adda12ee..0cb5831d9daf 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
@@ -50,6 +50,15 @@
};
};
+ p5v0: regulator-p5v0 {
+ compatible = "regulator-fixed";
+
+ regulator-name = "P5V0";
+ regulator-min-microvolt = <500>;
+ regulator-max-microvolt = <500>;
+ regulator-always-on;
+ };
+
tflash_vdd: regulator-tflash_vdd {
/*
* signal name from schematics: TFLASH_VDD_EN
--
2.23.0
[PATCHv4-next 2/3] arm64: dts: meson: odroid-c2: Add missing linking regulator to usb bus
Add missing linking regulator node to usb bus for power usb devices.
Cc: Martin Blumenstingl
Cc: Jerome Brunet
Cc: Neil Armstrong
Acked-by: Martin Blumenstingl
Signed-off-by: Anand Moon
---
Re-base on linux-next
Added Ack from Martin.
Changes from previous patch
[1] https://lore.kernel.org/patchwork/patch/1031243/
split the changes and add the comments to power source
---
arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts | 7 +++
1 file changed, 7 insertions(+)
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
b/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
index 0cb5831d9daf..d4c8b896dd26 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
@@ -36,8 +36,15 @@
regulator-min-microvolt = <500>;
regulator-max-microvolt = <500>;
+ /*
+* signal name from schematics: PWREN
+*/
gpio = <_ao GPIOAO_5 GPIO_ACTIVE_HIGH>;
enable-active-high;
+ /*
+* signal name from sehematics: USB_POWER
+*/
+ vin-supply = <>;
};
leds {
--
2.23.0
[PATCHv4-next 3/3] arm64: dts: meson: odroid-c2: Disable usb_otg bus to avoid power failed warning
usb_otg bus needs to get initialize from the u-boot to be configured to used as power source to SBC or usb otg port will get configured as host device. Right now this support is missing in the u-boot and phy driver so to avoid power failed warning, we would disable this feature until proper fix is found. [2.716048] phy phy-c000.phy.0: USB ID detect failed! [2.720186] phy phy-c000.phy.0: phy poweron failed --> -22 [2.726001] [ cut here ] [2.730583] WARNING: CPU: 0 PID: 12 at drivers/regulator/core.c:2039 _regulator_put+0x3c/0xe8 [2.738983] Modules linked in: [2.742005] CPU: 0 PID: 12 Comm: kworker/0:1 Not tainted 5.2.9-1-ARCH #1 [2.748643] Hardware name: Hardkernel ODROID-C2 (DT) [2.753566] Workqueue: events deferred_probe_work_func [2.758649] pstate: 6005 (nZCv daif -PAN -UAO) [2.763394] pc : _regulator_put+0x3c/0xe8 [2.767361] lr : _regulator_put+0x3c/0xe8 [2.771326] sp : 11aa3a50 [2.774604] x29: 11aa3a50 x28: 80007ed1b600 [2.779865] x27: 80007f7036a8 x26: 80007f7036a8 [2.785126] x25: x24: 11a44458 [2.790387] x23: 11344218 x22: 0009 [2.795649] x21: 11aa3b68 x20: 80007ed1b500 [2.800910] x19: 80007ed1b500 x18: 0010 [2.806171] x17: 5be5943c x16: f1c73b29 [2.811432] x15: x14: 117396c8 [2.816694] x13: 91aa37a7 x12: 11aa37af [2.821955] x11: 11763000 x10: 11aa3730 [2.827216] x9 : ffd0 x8 : 10871760 [2.832477] x7 : 00d0 x6 : 119d151b [2.837739] x5 : 000f x4 : [2.843000] x3 : x2 : 38104b2678c20100 [2.848261] x1 : x0 : 0024 [2.853523] Call trace: [2.855940] _regulator_put+0x3c/0xe8 [2.859562] regulator_put+0x34/0x48 [2.863098] regulator_bulk_free+0x40/0x58 [2.867153] devm_regulator_bulk_release+0x24/0x30 [2.871896] release_nodes+0x1f0/0x2e0 [2.875604] devres_release_all+0x64/0xa4 [2.879571] really_probe+0x1c8/0x3e0 [2.883194] driver_probe_device+0xe4/0x138 [2.887334] __device_attach_driver+0x90/0x110 [2.891733] bus_for_each_drv+0x8c/0xd8 [2.895527] __device_attach+0xdc/0x160 [2.899322] device_initial_probe+0x24/0x30 [2.903463] bus_probe_device+0x9c/0xa8 [2.907258] deferred_probe_work_func+0xa0/0xf0 [2.911745] process_one_work+0x1b4/0x408 [2.915711] worker_thread+0x54/0x4b8 [2.919334] kthread+0x12c/0x130 [2.922526] ret_from_fork+0x10/0x1c [2.926060] ---[ end trace 51a68f4c0035d6c0 ]--- [2.930691] [ cut here ] [2.935242] WARNING: CPU: 0 PID: 12 at drivers/regulator/core.c:2039 _regulator_put+0x3c/0xe8 [2.943653] Modules linked in: [2.946675] CPU: 0 PID: 12 Comm: kworker/0:1 Tainted: GW 5.2.9-1-ARCH #1 [2.954694] Hardware name: Hardkernel ODROID-C2 (DT) [2.959613] Workqueue: events deferred_probe_work_func [2.964700] pstate: 6005 (nZCv daif -PAN -UAO) [2.969445] pc : _regulator_put+0x3c/0xe8 [2.973412] lr : _regulator_put+0x3c/0xe8 [2.977377] sp : 11aa3a50 [2.980655] x29: 11aa3a50 x28: 80007ed1b600 [2.985916] x27: 80007f7036a8 x26: 80007f7036a8 [2.991177] x25: x24: 11a44458 [2.996439] x23: 11344218 x22: 0009 [3.001700] x21: 11aa3b68 x20: 80007ed1bd00 [3.006961] x19: 80007ed1bd00 x18: 0010 [3.01] x17: 5be5943c x16: f1c73b29 [3.017484] x15: x14: 117396c8 [3.022745] x13: 91aa37a7 x12: 11aa37af [3.028006] x11: 11763000 x10: 11aa3730 [3.033267] x9 : ffd0 x8 : 10871760 [3.038528] x7 : 00fd x6 : 119d151b [3.043790] x5 : 000f x4 : [3.049051] x3 : x2 : 38104b2678c20100 [3.054312] x1 : x0 : 0024 [3.059574] Call trace: [3.061991] _regulator_put+0x3c/0xe8 [3.065613] regulator_put+0x34/0x48 [3.069149] regulator_bulk_free+0x40/0x58 [3.073203] devm_regulator_bulk_release+0x24/0x30 [3.077947] release_nodes+0x1f0/0x2e0 [3.081655] devres_release_all+0x64/0xa4 [3.085622] really_probe+0x1c8/0x3e0 [3.089245] driver_probe_device+0xe4/0x138 [3.093385] __device_attach_driver+0x90/0x110 [3.097784] bus_for_each_drv+0x8c/0xd8 [3.101578] __device_attach+0xdc/0x160 [3.105373] device_initial_probe+0x24/0x30 [3.109514] bus_probe_device+0x9c/0xa8 [3.113309] deferred_probe_work_func+0xa0/0xf0 [3.117796] process_one_work+0x1b4/0x408 [3.121762] worker_thread+0x54/0x4b8 [3.125384] kthread+0x12c/0x130 [
[PATCHv4-next 0/3] Odroid c2 usb fixs rebase on linux-next
Some time ago I had tired to enable usb bus 1 for Odroid C2/C1 but it's look like some more work is needed to u-boot and usb_phy driver to initialize this port. Below patches tries to address the issue regarding usb bus 2 (4 port) while disable the usb bus 1 on this board. Previous patch [0] https://lkml.org/lkml/2019/1/29/325 Re send below series based re based on linux-next-20190830. For review and testing. [1] https://patchwork.kernel.org/cover/3091/ Small changes from previous series. Fix the commit message for patch 1 Best Regards -Anand Anand Moon (3): arm64: dts: meson: odroid-c2: p5v0 is the main 5V power input arm64: dts: meson: odroid-c2: Add missing linking regulator to usb bus arm64: dts: meson: odroid-c2: Disable usb_otg bus to avoid power failed warning .../boot/dts/amlogic/meson-gxbb-odroidc2.dts | 20 +-- 1 file changed, 18 insertions(+), 2 deletions(-) -- 2.23.0
Re: [PATCH 1/4] regulator: provide regulator_bulk_set_supply_names()
Hi Bartosz, I love your patch! Yet something to improve: [auto build test ERROR on linus/master] [cannot apply to v5.3-rc6 next-20190830] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Bartosz-Golaszewski/regulator-add-and-use-a-helper-for-setting-supply-names/20190901-140224 config: nds32-allnoconfig (attached as .config) compiler: nds32le-linux-gcc (GCC) 8.1.0 reproduce: 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 GCC_VERSION=8.1.0 make.cross ARCH=nds32 If you fix the issue, kindly add following tag Reported-by: kbuild test robot All errors (new ones prefixed by >>): nds32le-linux-ld: drivers/of/platform.o: in function `regulator_bulk_set_supply_names': >> platform.c:(.text+0xe8): multiple definition of >> `regulator_bulk_set_supply_names'; drivers/usb/phy/of.o:of.c:(.text+0x0): >> first defined here --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation .config.gz Description: application/gzip
Re: [PATCH v2 1/4] mmc: sdhci-of-aspeed: Fix link failure for SPARC
On Mon, 2 Sep 2019, at 13:42, Joel Stanley wrote:
> On Mon, 2 Sep 2019 at 03:58, Andrew Jeffery wrote:
> >
> > Resolves the following build error reported by the 0-day bot:
> >
> > ERROR: "of_platform_device_create"
> > [drivers/mmc/host/sdhci-of-aspeed.ko] undefined!
> >
> > SPARC does not set CONFIG_OF_ADDRESS so the symbol is missing. Guard the
> > callsite to maintain build coverage for the rest of the driver.
> >
> > Reported-by: kbuild test robot
> > Signed-off-by: Andrew Jeffery
> > ---
> > drivers/mmc/host/sdhci-of-aspeed.c | 38 --
> > 1 file changed, 25 insertions(+), 13 deletions(-)
> >
> > diff --git a/drivers/mmc/host/sdhci-of-aspeed.c
> > b/drivers/mmc/host/sdhci-of-aspeed.c
> > index d5acb5afc50f..96ca494752c5 100644
> > --- a/drivers/mmc/host/sdhci-of-aspeed.c
> > +++ b/drivers/mmc/host/sdhci-of-aspeed.c
> > @@ -224,10 +224,30 @@ static struct platform_driver aspeed_sdhci_driver = {
> > .remove = aspeed_sdhci_remove,
> > };
> >
> > -static int aspeed_sdc_probe(struct platform_device *pdev)
> > -
> > +static int aspeed_sdc_create_sdhcis(struct platform_device *pdev)
> > {
> > +#if defined(CONFIG_OF_ADDRESS)
>
> This is going to be untested code forever, as no one will be running
> on a chip with this hardware present but OF_ADDRESS disabled.
>
> How about we make the driver depend on OF_ADDRESS instead?
Testing is split into two pieces here: compile-time and run-time.
Clearly the run-time behaviour is going to be broken on configurations
without CONFIG_OF_ADDRESS (SPARC as mentioned), but I don't think
that means we shouldn't allow it to be compiled in that case
(e.g. CONFIG_COMPILE_TEST performs a similar role).
With respect to compile-time it's possible to compile either path as
demonstrated by the build failure report.
Having said that there's no reason we couldn't do what you suggest,
just it wasn't the existing solution pattern for the problem (there are
several other drivers that suffered the same bug that were fixed in the
style of this patch). Either way works, it's all somewhat academic.
Your suggestion is more obvious in terms of correctness, but this
patch is basically just code motion (the only addition is the `#if`/
`#endif` lines over what was already there if we disregard the
function declaration/invocation). I'll change it if there are further
complaints and a reason to do a v3.
Andrew
[PATCH RESEND] fs/epoll: fix the edge-triggered mode for nested epoll
From: Heiher
The structure of event pools:
efd[1]: { efd[2] (EPOLLIN) }efd[0]: { efd[2] (EPOLLIN | EPOLLET) }
| |
+-+-+
|
v
efd[2]: { sfd[0] (EPOLLIN) }
When sfd[0] to be readable:
* the epoll_wait(efd[0], ..., 0) should return efd[2]'s events on first call,
and returns 0 on next calls, because efd[2] is added in edge-triggered mode.
* the epoll_wait(efd[1], ..., 0) should returns efd[2]'s events on every calls
until efd[2] is not readable (epoll_wait(efd[2], ...) => 0), because efd[1]
is added in level-triggered mode.
* the epoll_wait(efd[2], ..., 0) should returns sfd[0]'s events on every calls
until sfd[0] is not readable (read(sfd[0], ...) => EAGAIN), because sfd[0]
is added in level-triggered mode.
Test code:
#include
#include
#include
#include
int main(int argc, char *argv[])
{
int sfd[2];
int efd[3];
int nfds;
struct epoll_event e;
if (socketpair(AF_UNIX, SOCK_STREAM, 0, sfd) < 0)
goto out;
efd[0] = epoll_create(1);
if (efd[0] < 0)
goto out;
efd[1] = epoll_create(1);
if (efd[1] < 0)
goto out;
efd[2] = epoll_create(1);
if (efd[2] < 0)
goto out;
e.events = EPOLLIN;
if (epoll_ctl(efd[2], EPOLL_CTL_ADD, sfd[0], ) < 0)
goto out;
e.events = EPOLLIN;
if (epoll_ctl(efd[1], EPOLL_CTL_ADD, efd[2], ) < 0)
goto out;
e.events = EPOLLIN | EPOLLET;
if (epoll_ctl(efd[0], EPOLL_CTL_ADD, efd[2], ) < 0)
goto out;
if (write(sfd[1], "w", 1) != 1)
goto out;
nfds = epoll_wait(efd[0], , 1, 0);
if (nfds != 1)
goto out;
nfds = epoll_wait(efd[0], , 1, 0);
if (nfds != 0)
goto out;
nfds = epoll_wait(efd[1], , 1, 0);
if (nfds != 1)
goto out;
nfds = epoll_wait(efd[1], , 1, 0);
if (nfds != 1)
goto out;
nfds = epoll_wait(efd[2], , 1, 0);
if (nfds != 1)
goto out;
nfds = epoll_wait(efd[2], , 1, 0);
if (nfds != 1)
goto out;
close(efd[2]);
close(efd[1]);
close(efd[0]);
close(sfd[0]);
close(sfd[1]);
printf("PASS\n");
return 0;
out:
printf("FAIL\n");
return -1;
}
Cc: Al Viro
Cc: Andrew Morton
Cc: Davide Libenzi
Cc: Davidlohr Bueso
Cc: Dominik Brodowski
Cc: Eric Wong
Cc: Jason Baron
Cc: Linus Torvalds
Cc: Roman Penyaev
Cc: Sridhar Samudrala
Cc: linux-kernel@vger.kernel.org
Cc: linux-fsde...@vger.kernel.org
Signed-off-by: hev
---
fs/eventpoll.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/fs/eventpoll.c b/fs/eventpoll.c
index d7f1f5011fac..a44cb27c636c 100644
--- a/fs/eventpoll.c
+++ b/fs/eventpoll.c
@@ -672,6 +672,7 @@ static __poll_t ep_scan_ready_list(struct eventpoll *ep,
{
__poll_t res;
int pwake = 0;
+ int nwake = 0;
struct epitem *epi, *nepi;
LIST_HEAD(txlist);
@@ -685,6 +686,9 @@ static __poll_t ep_scan_ready_list(struct eventpoll *ep,
if (!ep_locked)
mutex_lock_nested(>mtx, depth);
+ if (!depth || list_empty(>rdllist))
+ nwake = 1;
+
/*
* Steal the ready list, and re-init the original one to the
* empty list. Also, set ep->ovflist to NULL so that events
@@ -739,7 +743,7 @@ static __poll_t ep_scan_ready_list(struct eventpoll *ep,
list_splice(, >rdllist);
__pm_relax(ep->ws);
- if (!list_empty(>rdllist)) {
+ if (nwake && !list_empty(>rdllist)) {
/*
* Wake up (if active) both the eventpoll wait list and
* the ->poll() wait list (delayed after we release the lock).
--
2.23.0
Re: [PATCH v3] arch/microblaze: add support for get_user() of size 8 bytes
On Sun, Sep 1, 2019 at 7:10 PM Randy Dunlap wrote:
>
> I guess we need a way to coerce that to call get_user_1(),
> such as a typecast. This _seems_ to work (i.e., call get_user_1()):
No, I oversimplified.
Try this slightly modified patch instead.
Linus
arch/microblaze/include/asm/uaccess.h | 42 ---
1 file changed, 9 insertions(+), 33 deletions(-)
diff --git a/arch/microblaze/include/asm/uaccess.h b/arch/microblaze/include/asm/uaccess.h
index bff2a71c828a..a1f206b90753 100644
--- a/arch/microblaze/include/asm/uaccess.h
+++ b/arch/microblaze/include/asm/uaccess.h
@@ -163,44 +163,15 @@ extern long __user_bad(void);
* Returns zero on success, or -EFAULT on error.
* On error, the variable @x is set to zero.
*/
-#define get_user(x, ptr) \
- __get_user_check((x), (ptr), sizeof(*(ptr)))
-
-#define __get_user_check(x, ptr, size) \
-({ \
- unsigned long __gu_val = 0; \
- const typeof(*(ptr)) __user *__gu_addr = (ptr); \
- int __gu_err = 0; \
- \
- if (access_ok(__gu_addr, size)) { \
- switch (size) { \
- case 1: \
- __get_user_asm("lbu", __gu_addr, __gu_val, \
- __gu_err); \
- break; \
- case 2: \
- __get_user_asm("lhu", __gu_addr, __gu_val, \
- __gu_err); \
- break; \
- case 4: \
- __get_user_asm("lw", __gu_addr, __gu_val, \
- __gu_err); \
- break; \
- default: \
- __gu_err = __user_bad(); \
- break; \
- } \
- } else { \
- __gu_err = -EFAULT; \
- }\
- x = (__force typeof(*(ptr)))__gu_val;\
- __gu_err; \
+#define get_user(x, ptr) ({\
+ const typeof(*(ptr)) __user *__gu_ptr = (ptr); \
+ access_ok(__gu_ptr, sizeof(*__gu_ptr)) ? \
+ __get_user(x, __gu_ptr) : -EFAULT; \
})
#define __get_user(x, ptr) \
({ \
unsigned long __gu_val = 0; \
- /*unsigned long __gu_ptr = (unsigned long)(ptr);*/ \
long __gu_err; \
switch (sizeof(*(ptr))) { \
case 1:\
@@ -212,6 +183,11 @@ extern long __user_bad(void);
case 4:\
__get_user_asm("lw", (ptr), __gu_val, __gu_err); \
break; \
+ case 8:\
+ __gu_err = __copy_from_user(&__gu_val, ptr, 8); \
+ if (__gu_err) \
+ __gu_err = -EFAULT;\
+ break; \
default: \
/* __gu_val = 0; __gu_err = -EINVAL;*/ __gu_err = __user_bad();\
}\
[PATCH] rtc: pcf85063: Add pcf85063 clkout control to common clock framework
Signed-off-by: Michael McCormick
---
drivers/rtc/rtc-pcf85063.c | 153 +
1 file changed, 153 insertions(+)
diff --git a/drivers/rtc/rtc-pcf85063.c b/drivers/rtc/rtc-pcf85063.c
index 1afa6d9fa9fb..f47d3a6b997d 100644
--- a/drivers/rtc/rtc-pcf85063.c
+++ b/drivers/rtc/rtc-pcf85063.c
@@ -9,6 +9,7 @@
* Copyright (C) 2019 Micro Crystal AG
* Author: Alexandre Belloni
*/
+#include
#include
#include
#include
@@ -44,6 +45,16 @@
#define PCF85063_OFFSET_STEP0 4340
#define PCF85063_OFFSET_STEP1 4069
+#define PCF85063_REG_CLKO_F_MASK 0x07 /* frequency mask */
+#define PCF85063_REG_CLKO_F_32768HZ0x00
+#define PCF85063_REG_CLKO_F_16384HZ0x01
+#define PCF85063_REG_CLKO_F_8192HZ 0x02
+#define PCF85063_REG_CLKO_F_4096HZ 0x03
+#define PCF85063_REG_CLKO_F_2048HZ 0x04
+#define PCF85063_REG_CLKO_F_1024HZ 0x05
+#define PCF85063_REG_CLKO_F_1HZ0x06
+#define PCF85063_REG_CLKO_F_OFF0x07
+
#define PCF85063_REG_RAM 0x03
#define PCF85063_REG_SC0x04 /* datetime */
@@ -61,6 +72,9 @@ struct pcf85063_config {
struct pcf85063 {
struct rtc_device *rtc;
struct regmap *regmap;
+#ifdef CONFIG_COMMON_CLK
+ struct clk_hw clkout_hw;
+#endif
};
static int pcf85063_rtc_read_time(struct device *dev, struct rtc_time *tm)
@@ -369,6 +383,140 @@ static int pcf85063_load_capacitance(struct pcf85063
*pcf85063,
PCF85063_REG_CTRL1_CAP_SEL, reg);
}
+#ifdef CONFIG_COMMON_CLK
+/*
+ * Handling of the clkout
+ */
+
+#define clkout_hw_to_pcf85063(_hw) container_of(_hw, struct pcf85063,
clkout_hw)
+
+static int clkout_rates[] = {
+ 32768,
+ 16384,
+ 8192,
+ 4096,
+ 2048,
+ 1024,
+ 1,
+};
+
+static unsigned long pcf85063_clkout_recalc_rate(struct clk_hw *hw,
+unsigned long parent_rate)
+{
+ struct pcf85063 *pcf85063 = clkout_hw_to_pcf85063(hw);
+ unsigned int buf;
+ int ret = regmap_read(pcf85063->regmap, PCF85063_REG_CTRL2, );
+
+ if (ret < 0)
+ return 0;
+
+ buf &= PCF85063_REG_CLKO_F_MASK;
+ return clkout_rates[buf];
+}
+
+static long pcf85063_clkout_round_rate(struct clk_hw *hw, unsigned long rate,
+ unsigned long *prate)
+{
+ int i;
+
+ for (i = 0; i < ARRAY_SIZE(clkout_rates); i++)
+ if (clkout_rates[i] <= rate)
+ return clkout_rates[i];
+
+ return 0;
+}
+
+static int pcf85063_clkout_set_rate(struct clk_hw *hw, unsigned long rate,
+ unsigned long parent_rate)
+{
+ struct pcf85063 *pcf85063 = clkout_hw_to_pcf85063(hw);
+ int i;
+
+ for (i = 0; i < ARRAY_SIZE(clkout_rates); i++)
+ if (clkout_rates[i] == rate)
+ return regmap_update_bits(pcf85063->regmap,
PCF85063_REG_CTRL2,
+ PCF85063_REG_CLKO_F_MASK, i);
+
+ return -EINVAL;
+}
+
+static int pcf85063_clkout_control(struct clk_hw *hw, bool enable)
+{
+ struct pcf85063 *pcf85063 = clkout_hw_to_pcf85063(hw);
+ unsigned char buf;
+
+ if (enable)
+ buf = PCF85063_REG_CLKO_F_32768HZ;
+ else
+ buf = PCF85063_REG_CLKO_F_OFF;
+
+ return regmap_update_bits(pcf85063->regmap, PCF85063_REG_CTRL2,
+ PCF85063_REG_CLKO_F_MASK, buf);
+}
+
+static int pcf85063_clkout_prepare(struct clk_hw *hw)
+{
+ return pcf85063_clkout_control(hw, 1);
+}
+
+static void pcf85063_clkout_unprepare(struct clk_hw *hw)
+{
+ pcf85063_clkout_control(hw, 0);
+}
+
+static int pcf85063_clkout_is_prepared(struct clk_hw *hw)
+{
+ struct pcf85063 *pcf85063 = clkout_hw_to_pcf85063(hw);
+ unsigned int buf;
+ int ret = regmap_read(pcf85063->regmap, PCF85063_REG_CTRL2, );
+
+ if (ret < 0)
+ return 0;
+
+ return (buf & PCF85063_REG_CLKO_F_MASK) != PCF85063_REG_CLKO_F_OFF;
+}
+
+static const struct clk_ops pcf85063_clkout_ops = {
+ .prepare = pcf85063_clkout_prepare,
+ .unprepare = pcf85063_clkout_unprepare,
+ .is_prepared = pcf85063_clkout_is_prepared,
+ .recalc_rate = pcf85063_clkout_recalc_rate,
+ .round_rate = pcf85063_clkout_round_rate,
+ .set_rate = pcf85063_clkout_set_rate,
+};
+
+static struct clk *pcf85063_clkout_register_clk(struct pcf85063 *pcf85063)
+{
+ struct clk *clk;
+ struct clk_init_data init;
+ int ret;
+
+ /* disable the clkout output */
+ ret = regmap_update_bits(pcf85063->regmap, PCF85063_REG_CTRL2,
+PCF85063_REG_CLKO_F_MASK,
PCF85063_REG_CLKO_F_OFF);
+ if (ret < 0)
+ return ERR_PTR(ret);
+
+ init.name = "pcf85063-clkout";
+ init.ops =
[PATCH v3 1/5] mdev: Introduce sha1 based mdev alias
Some vendor drivers want an identifier for an mdev device that is
shorter than the UUID, due to length restrictions in the consumers of
that identifier.
Add a callback that allows a vendor driver to request an alias of a
specified length to be generated for an mdev device. If generated,
that alias is checked for collisions.
It is an optional attribute.
mdev alias is generated using sha1 from the mdev name.
Signed-off-by: Parav Pandit
---
Changelog:
v1->v2:
- Kept mdev_device naturally aligned
- Added error checking for crypt_*() calls
- Corrected a typo from 'and' to 'an'
- Changed return type of generate_alias() from int to char*
v0->v1:
- Moved alias length check outside of the parent lock
- Moved alias and digest allocation from kvzalloc to kzalloc
- [0] changed to alias
- alias_length check is nested under get_alias_length callback check
- Changed comments to start with an empty line
- Fixed cleaunup of hash if mdev_bus_register() fails
- Added comment where alias memory ownership is handed over to mdev device
- Updated commit log to indicate motivation for this feature
---
drivers/vfio/mdev/mdev_core.c| 123 ++-
drivers/vfio/mdev/mdev_private.h | 5 +-
drivers/vfio/mdev/mdev_sysfs.c | 13 ++--
include/linux/mdev.h | 4 +
4 files changed, 135 insertions(+), 10 deletions(-)
diff --git a/drivers/vfio/mdev/mdev_core.c b/drivers/vfio/mdev/mdev_core.c
index b558d4cfd082..3bdff0469607 100644
--- a/drivers/vfio/mdev/mdev_core.c
+++ b/drivers/vfio/mdev/mdev_core.c
@@ -10,9 +10,11 @@
#include
#include
#include
+#include
#include
#include
#include
+#include
#include "mdev_private.h"
@@ -27,6 +29,8 @@ static struct class_compat *mdev_bus_compat_class;
static LIST_HEAD(mdev_list);
static DEFINE_MUTEX(mdev_list_lock);
+static struct crypto_shash *alias_hash;
+
struct device *mdev_parent_dev(struct mdev_device *mdev)
{
return mdev->parent->dev;
@@ -150,6 +154,16 @@ int mdev_register_device(struct device *dev, const struct
mdev_parent_ops *ops)
if (!ops || !ops->create || !ops->remove || !ops->supported_type_groups)
return -EINVAL;
+ if (ops->get_alias_length) {
+ unsigned int digest_size;
+ unsigned int aligned_len;
+
+ aligned_len = roundup(ops->get_alias_length(), 2);
+ digest_size = crypto_shash_digestsize(alias_hash);
+ if (aligned_len / 2 > digest_size)
+ return -EINVAL;
+ }
+
dev = get_device(dev);
if (!dev)
return -EINVAL;
@@ -259,6 +273,7 @@ static void mdev_device_free(struct mdev_device *mdev)
mutex_unlock(_list_lock);
dev_dbg(>dev, "MDEV: destroying\n");
+ kfree(mdev->alias);
kfree(mdev);
}
@@ -269,18 +284,101 @@ static void mdev_device_release(struct device *dev)
mdev_device_free(mdev);
}
-int mdev_device_create(struct kobject *kobj,
- struct device *dev, const guid_t *uuid)
+static const char *
+generate_alias(const char *uuid, unsigned int max_alias_len)
+{
+ struct shash_desc *hash_desc;
+ unsigned int digest_size;
+ unsigned char *digest;
+ unsigned int alias_len;
+ char *alias;
+ int ret;
+
+ /*
+* Align to multiple of 2 as bin2hex will generate
+* even number of bytes.
+*/
+ alias_len = roundup(max_alias_len, 2);
+ alias = kzalloc(alias_len + 1, GFP_KERNEL);
+ if (!alias)
+ return ERR_PTR(-ENOMEM);
+
+ /* Allocate and init descriptor */
+ hash_desc = kvzalloc(sizeof(*hash_desc) +
+crypto_shash_descsize(alias_hash),
+GFP_KERNEL);
+ if (!hash_desc) {
+ ret = -ENOMEM;
+ goto desc_err;
+ }
+
+ hash_desc->tfm = alias_hash;
+
+ digest_size = crypto_shash_digestsize(alias_hash);
+
+ digest = kzalloc(digest_size, GFP_KERNEL);
+ if (!digest) {
+ ret = -ENOMEM;
+ goto digest_err;
+ }
+ ret = crypto_shash_init(hash_desc);
+ if (ret)
+ goto hash_err;
+
+ ret = crypto_shash_update(hash_desc, uuid, UUID_STRING_LEN);
+ if (ret)
+ goto hash_err;
+
+ ret = crypto_shash_final(hash_desc, digest);
+ if (ret)
+ goto hash_err;
+
+ bin2hex(alias, digest, min_t(unsigned int, digest_size, alias_len / 2));
+ /*
+* When alias length is odd, zero out an additional last byte
+* that bin2hex has copied.
+*/
+ if (max_alias_len % 2)
+ alias[max_alias_len] = 0;
+
+ kfree(digest);
+ kvfree(hash_desc);
+ return alias;
+
+hash_err:
+ kfree(digest);
+digest_err:
+ kvfree(hash_desc);
+desc_err:
+ kfree(alias);
+ return ERR_PTR(ret);
+}
+
+int mdev_device_create(struct kobject
[PATCH v3 3/5] mdev: Expose mdev alias in sysfs tree
Expose the optional alias for an mdev device as a sysfs attribute.
This way, userspace tools such as udev may make use of the alias, for
example to create a netdevice name for the mdev.
Updated documentation for optional read only sysfs attribute.
Signed-off-by: Parav Pandit
---
Changelog:
v2->v3:
- Merged sysfs documentation patch with sysfs addition
- Added more description for alias return value
v0->v1:
- Addressed comments from Cornelia Huck
- Updated commit description
---
Documentation/driver-api/vfio-mediated-device.rst | 9 +
drivers/vfio/mdev/mdev_sysfs.c| 13 +
2 files changed, 22 insertions(+)
diff --git a/Documentation/driver-api/vfio-mediated-device.rst
b/Documentation/driver-api/vfio-mediated-device.rst
index 25eb7d5b834b..0b7d2bf843b6 100644
--- a/Documentation/driver-api/vfio-mediated-device.rst
+++ b/Documentation/driver-api/vfio-mediated-device.rst
@@ -270,6 +270,7 @@ Directories and Files Under the sysfs for Each mdev Device
|--- remove
|--- mdev_type {link to its type}
|--- vendor-specific-attributes [optional]
+ |--- alias
* remove (write only)
@@ -281,6 +282,14 @@ Example::
# echo 1 > /sys/bus/mdev/devices/$mdev_UUID/remove
+* alias (read only, optional)
+Whenever a parent requested to generate an alias, each mdev device of such
+parent is assigned unique alias by the mdev core.
+This file shows the alias of the mdev device.
+
+Reading file either returns valid alias when assigned or returns error code
+-EOPNOTSUPP when unsupported.
+
Mediated device Hot plug
diff --git a/drivers/vfio/mdev/mdev_sysfs.c b/drivers/vfio/mdev/mdev_sysfs.c
index 43afe0e80b76..59f4e3cc5233 100644
--- a/drivers/vfio/mdev/mdev_sysfs.c
+++ b/drivers/vfio/mdev/mdev_sysfs.c
@@ -246,7 +246,20 @@ static ssize_t remove_store(struct device *dev, struct
device_attribute *attr,
static DEVICE_ATTR_WO(remove);
+static ssize_t alias_show(struct device *device,
+ struct device_attribute *attr, char *buf)
+{
+ struct mdev_device *dev = mdev_from_dev(device);
+
+ if (!dev->alias)
+ return -EOPNOTSUPP;
+
+ return sprintf(buf, "%s\n", dev->alias);
+}
+static DEVICE_ATTR_RO(alias);
+
static const struct attribute *mdev_device_attrs[] = {
+ _attr_alias.attr,
_attr_remove.attr,
NULL,
};
--
2.19.2
[PATCH v3 4/5] mdev: Introduce an API mdev_alias
Introduce an API mdev_alias() to provide access to optionally generated
alias.
Signed-off-by: Parav Pandit
---
drivers/vfio/mdev/mdev_core.c | 12
include/linux/mdev.h | 1 +
2 files changed, 13 insertions(+)
diff --git a/drivers/vfio/mdev/mdev_core.c b/drivers/vfio/mdev/mdev_core.c
index c8cd40366783..9eec556fbdd4 100644
--- a/drivers/vfio/mdev/mdev_core.c
+++ b/drivers/vfio/mdev/mdev_core.c
@@ -517,6 +517,18 @@ struct device *mdev_get_iommu_device(struct device *dev)
}
EXPORT_SYMBOL(mdev_get_iommu_device);
+/**
+ * mdev_alias: Return alias string of a mdev device
+ * @mdev: Pointer to the mdev device
+ * mdev_alias() returns alias string of a mdev device if alias is present,
+ * returns NULL otherwise.
+ */
+const char *mdev_alias(struct mdev_device *mdev)
+{
+ return mdev->alias;
+}
+EXPORT_SYMBOL(mdev_alias);
+
static int __init mdev_init(void)
{
int ret;
diff --git a/include/linux/mdev.h b/include/linux/mdev.h
index f036fe9854ee..6da82213bc4e 100644
--- a/include/linux/mdev.h
+++ b/include/linux/mdev.h
@@ -148,5 +148,6 @@ void mdev_unregister_driver(struct mdev_driver *drv);
struct device *mdev_parent_dev(struct mdev_device *mdev);
struct device *mdev_dev(struct mdev_device *mdev);
struct mdev_device *mdev_from_dev(struct device *dev);
+const char *mdev_alias(struct mdev_device *mdev);
#endif /* MDEV_H */
--
2.19.2
[PATCH v3 0/5] Introduce variable length mdev alias
To have consistent naming for the netdevice of a mdev and to have consistent naming of the devlink port [1] of a mdev, which is formed using phys_port_name of the devlink port, current UUID is not usable because UUID is too long. UUID in string format is 36-characters long and in binary 128-bit. Both formats are not able to fit within 15 characters limit of netdev name. It is desired to have mdev device naming consistent using UUID. So that widely used user space framework such as ovs [2] can make use of mdev representor in similar way as PCIe SR-IOV VF and PF representors. Hence, (a) mdev alias is created which is derived using sha1 from the mdev name. (b) Vendor driver describes how long an alias should be for the child mdev created for a given parent. (c) Mdev aliases are unique at system level. (d) alias is created optionally whenever parent requested. This ensures that non networking mdev parents can function without alias creation overhead. This design is discussed at [3]. An example systemd/udev extension will have, 1. netdev name created using mdev alias available in sysfs. mdev UUID=83b8f4f2-509f-382f-3c1e-e6bfe0fa1001 mdev 12 character alias=cd5b146a80a5 netdev name of this mdev = enmcd5b146a80a5 Here en = Ethernet link m = mediated device 2. devlink port phys_port_name created using mdev alias. devlink phys_port_name=pcd5b146a80a5 This patchset enables mdev core to maintain unique alias for a mdev. Patch-1 Introduces mdev alias using sha1. Patch-2 Ensures that mdev alias is unique in a system. Patch-3 Exposes mdev alias in a sysfs hirerchy, update Documentation Patch-4 Introduces mdev_alias() API. Patch-5 Extends mtty driver to optionally provide alias generation. This also enables to test UUID based sha1 collision and trigger error handling for duplicate sha1 results. [1] http://man7.org/linux/man-pages/man8/devlink-port.8.html [2] https://docs.openstack.org/os-vif/latest/user/plugins/ovs.html [3] https://patchwork.kernel.org/cover/11084231/ --- Changelog: v2->v3: - Addressed comment from Yunsheng Lin - Changed strcmp() ==0 to !strcmp() - Addressed comment from Cornelia Hunk - Merged sysfs Documentation patch with syfs patch - Added more description for alias return value v1->v2: - Corrected a typo from 'and' to 'an' - Addressed comments from Alex Williamson - Kept mdev_device naturally aligned - Added error checking for crypt_*() calls - Moved alias NULL check at beginning - Added mdev_alias() API - Updated mtty driver to show example mdev_alias() usage - Changed return type of generate_alias() from int to char* v0->v1: - Addressed comments from Alex Williamson, Cornelia Hunk and Mark Bloch - Moved alias length check outside of the parent lock - Moved alias and digest allocation from kvzalloc to kzalloc - [0] changed to alias - alias_length check is nested under get_alias_length callback check - Changed comments to start with an empty line - Added comment where alias memory ownership is handed over to mdev device - Fixed cleaunup of hash if mdev_bus_register() fails - Updated documentation for new sysfs alias file - Improved commit logs to make description more clear - Fixed inclusiong of alias for NULL check - Added ratelimited debug print for sha1 hash collision error Parav Pandit (5): mdev: Introduce sha1 based mdev alias mdev: Make mdev alias unique among all mdevs mdev: Expose mdev alias in sysfs tree mdev: Introduce an API mdev_alias mtty: Optionally support mtty alias .../driver-api/vfio-mediated-device.rst | 9 ++ drivers/vfio/mdev/mdev_core.c | 142 +- drivers/vfio/mdev/mdev_private.h | 5 +- drivers/vfio/mdev/mdev_sysfs.c| 26 +++- include/linux/mdev.h | 5 + samples/vfio-mdev/mtty.c | 13 ++ 6 files changed, 190 insertions(+), 10 deletions(-) -- 2.19.2
[PATCH v3 2/5] mdev: Make mdev alias unique among all mdevs
Mdev alias should be unique among all the mdevs, so that when such alias
is used by the mdev users to derive other objects, there is no
collision in a given system.
Signed-off-by: Parav Pandit
---
Changelog:
v2->v3:
- Changed strcmp() ==0 to !strcmp()
v1->v2:
- Moved alias NULL check at beginning
v0->v1:
- Fixed inclusiong of alias for NULL check
- Added ratelimited debug print for sha1 hash collision error
---
drivers/vfio/mdev/mdev_core.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/vfio/mdev/mdev_core.c b/drivers/vfio/mdev/mdev_core.c
index 3bdff0469607..c8cd40366783 100644
--- a/drivers/vfio/mdev/mdev_core.c
+++ b/drivers/vfio/mdev/mdev_core.c
@@ -388,6 +388,13 @@ int mdev_device_create(struct kobject *kobj, struct device
*dev,
ret = -EEXIST;
goto mdev_fail;
}
+ if (alias && tmp->alias && !strcmp(alias, tmp->alias)) {
+ mutex_unlock(_list_lock);
+ ret = -EEXIST;
+ dev_dbg_ratelimited(dev, "Hash collision in alias
creation for UUID %pUl\n",
+ uuid);
+ goto mdev_fail;
+ }
}
mdev = kzalloc(sizeof(*mdev), GFP_KERNEL);
--
2.19.2
[PATCH v3 5/5] mtty: Optionally support mtty alias
Provide a module parameter to set alias length to optionally generate
mdev alias.
Example to request mdev alias.
$ modprobe mtty alias_length=12
Make use of mtty_alias() API when alias_length module parameter is set.
Signed-off-by: Parav Pandit
---
Changelog:
v1->v2:
- Added mdev_alias() usage sample
---
samples/vfio-mdev/mtty.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/samples/vfio-mdev/mtty.c b/samples/vfio-mdev/mtty.c
index 92e770a06ea2..075d65440bc0 100644
--- a/samples/vfio-mdev/mtty.c
+++ b/samples/vfio-mdev/mtty.c
@@ -150,6 +150,10 @@ static const struct file_operations vd_fops = {
.owner = THIS_MODULE,
};
+static unsigned int mtty_alias_length;
+module_param_named(alias_length, mtty_alias_length, uint, 0444);
+MODULE_PARM_DESC(alias_length, "mdev alias length; default=0");
+
/* function prototypes */
static int mtty_trigger_interrupt(const guid_t *uuid);
@@ -770,6 +774,9 @@ static int mtty_create(struct kobject *kobj, struct
mdev_device *mdev)
list_add(_state->next, _devices_list);
mutex_unlock(_list_lock);
+ if (mtty_alias_length)
+ dev_dbg(mdev_dev(mdev), "alias is %s\n", mdev_alias(mdev));
+
return 0;
}
@@ -1410,6 +1417,11 @@ static struct attribute_group *mdev_type_groups[] = {
NULL,
};
+static unsigned int mtty_get_alias_length(void)
+{
+ return mtty_alias_length;
+}
+
static const struct mdev_parent_ops mdev_fops = {
.owner = THIS_MODULE,
.dev_attr_groups= mtty_dev_groups,
@@ -1422,6 +1434,7 @@ static const struct mdev_parent_ops mdev_fops = {
.read = mtty_read,
.write = mtty_write,
.ioctl = mtty_ioctl,
+ .get_alias_length = mtty_get_alias_length
};
static void mtty_device_release(struct device *dev)
--
2.19.2
Re: [RFC v3] vhost: introduce mdev based hardware vhost backend
On 2019/8/28 下午1:37, Tiwei Bie wrote:
Details about this can be found here:
https://lwn.net/Articles/750770/
What's new in this version
==
There are three choices based on the discussion [1] in RFC v2:
#1. We expose a VFIO device, so we can reuse the VFIO container/group
based DMA API and potentially reuse a lot of VFIO code in QEMU.
But in this case, we have two choices for the VFIO device interface
(i.e. the interface on top of VFIO device fd):
A) we may invent a new vhost protocol (as demonstrated by the code
in this RFC) on VFIO device fd to make it work in VFIO's way,
i.e. regions and irqs.
B) Or as you proposed, instead of inventing a new vhost protocol,
we can reuse most existing vhost ioctls on the VFIO device fd
directly. There should be no conflicts between the VFIO ioctls
(type is 0x3B) and VHOST ioctls (type is 0xAF) currently.
#2. Instead of exposing a VFIO device, we may expose a VHOST device.
And we will introduce a new mdev driver vhost-mdev to do this.
It would be natural to reuse the existing kernel vhost interface
(ioctls) on it as much as possible. But we will need to invent
some APIs for DMA programming (reusing VHOST_SET_MEM_TABLE is a
choice, but it's too heavy and doesn't support vIOMMU by itself).
This version is more like a quick PoC to try Jason's proposal on
reusing vhost ioctls. And the second way (#1/B) in above three
choices was chosen in this version to demonstrate the idea quickly.
Now the userspace API looks like this:
- VFIO's container/group based IOMMU API is used to do the
DMA programming.
- Vhost's existing ioctls are used to setup the device.
And the device will report device_api as "vfio-vhost".
Note that, there are dirty hacks in this version. If we decide to
go this way, some refactoring in vhost.c/vhost.h may be needed.
PS. The direct mapping of the notify registers isn't implemented
in this version.
[1] https://lkml.org/lkml/2019/7/9/101
Thanks for the patch, see comments inline.
Signed-off-by: Tiwei Bie
---
drivers/vhost/Kconfig | 9 +
drivers/vhost/Makefile | 3 +
drivers/vhost/mdev.c | 382 +
include/linux/vhost_mdev.h | 58 ++
include/uapi/linux/vfio.h | 2 +
include/uapi/linux/vhost.h | 8 +
6 files changed, 462 insertions(+)
create mode 100644 drivers/vhost/mdev.c
create mode 100644 include/linux/vhost_mdev.h
diff --git a/drivers/vhost/Kconfig b/drivers/vhost/Kconfig
index 3d03ccbd1adc..2ba54fcf43b7 100644
--- a/drivers/vhost/Kconfig
+++ b/drivers/vhost/Kconfig
@@ -34,6 +34,15 @@ config VHOST_VSOCK
To compile this driver as a module, choose M here: the module will be
called
vhost_vsock.
+config VHOST_MDEV
+ tristate "Hardware vhost accelerator abstraction"
+ depends on EVENTFD && VFIO && VFIO_MDEV
+ select VHOST
+ default n
+ ---help---
+ Say Y here to enable the vhost_mdev module
+ for use with hardware vhost accelerators
+
config VHOST
tristate
---help---
diff --git a/drivers/vhost/Makefile b/drivers/vhost/Makefile
index 6c6df24f770c..ad9c0f8c6d8c 100644
--- a/drivers/vhost/Makefile
+++ b/drivers/vhost/Makefile
@@ -10,4 +10,7 @@ vhost_vsock-y := vsock.o
obj-$(CONFIG_VHOST_RING) += vringh.o
+obj-$(CONFIG_VHOST_MDEV) += vhost_mdev.o
+vhost_mdev-y := mdev.o
+
obj-$(CONFIG_VHOST) += vhost.o
diff --git a/drivers/vhost/mdev.c b/drivers/vhost/mdev.c
new file mode 100644
index ..6bef1d9ae2e6
--- /dev/null
+++ b/drivers/vhost/mdev.c
@@ -0,0 +1,382 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2018-2019 Intel Corporation.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "vhost.h"
+
+struct vhost_mdev {
+ struct vhost_dev dev;
+ bool opened;
+ int nvqs;
+ u64 state;
+ u64 acked_features;
+ u64 features;
+ const struct vhost_mdev_device_ops *ops;
+ struct mdev_device *mdev;
+ void *private;
+ struct vhost_virtqueue vqs[];
+};
+
+static void handle_vq_kick(struct vhost_work *work)
+{
+ struct vhost_virtqueue *vq = container_of(work, struct vhost_virtqueue,
+ poll.work);
+ struct vhost_mdev *vdpa = container_of(vq->dev, struct vhost_mdev, dev);
+
+ vdpa->ops->notify(vdpa, vq - vdpa->vqs);
+}
+
+static int vhost_set_state(struct vhost_mdev *vdpa, u64 __user *statep)
+{
+ u64 state;
+
+ if (copy_from_user(, statep, sizeof(state)))
+ return -EFAULT;
+
+ if (state >= VHOST_MDEV_S_MAX)
+ return -EINVAL;
+
+ if (vdpa->state == state)
+ return 0;
+
+ mutex_lock(>dev.mutex);
+
+ vdpa->state = state;
+
+ switch (vdpa->state) {
+ case VHOST_MDEV_S_RUNNING:
+
Re: [PATCH v2 1/4] mmc: sdhci-of-aspeed: Fix link failure for SPARC
On Mon, 2 Sep 2019 at 03:58, Andrew Jeffery wrote:
>
> Resolves the following build error reported by the 0-day bot:
>
> ERROR: "of_platform_device_create" [drivers/mmc/host/sdhci-of-aspeed.ko]
> undefined!
>
> SPARC does not set CONFIG_OF_ADDRESS so the symbol is missing. Guard the
> callsite to maintain build coverage for the rest of the driver.
>
> Reported-by: kbuild test robot
> Signed-off-by: Andrew Jeffery
> ---
> drivers/mmc/host/sdhci-of-aspeed.c | 38 --
> 1 file changed, 25 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/mmc/host/sdhci-of-aspeed.c
> b/drivers/mmc/host/sdhci-of-aspeed.c
> index d5acb5afc50f..96ca494752c5 100644
> --- a/drivers/mmc/host/sdhci-of-aspeed.c
> +++ b/drivers/mmc/host/sdhci-of-aspeed.c
> @@ -224,10 +224,30 @@ static struct platform_driver aspeed_sdhci_driver = {
> .remove = aspeed_sdhci_remove,
> };
>
> -static int aspeed_sdc_probe(struct platform_device *pdev)
> -
> +static int aspeed_sdc_create_sdhcis(struct platform_device *pdev)
> {
> +#if defined(CONFIG_OF_ADDRESS)
This is going to be untested code forever, as no one will be running
on a chip with this hardware present but OF_ADDRESS disabled.
How about we make the driver depend on OF_ADDRESS instead?
Cheers,
Joel
> struct device_node *parent, *child;
> +
> + parent = pdev->dev.of_node;
> +
> + for_each_available_child_of_node(parent, child) {
> + struct platform_device *cpdev;
> +
> + cpdev = of_platform_device_create(child, NULL, >dev);
> + if (!cpdev) {
> + of_node_put(child);
> + return -ENODEV;
> + }
> + }
> +#endif
> +
> + return 0;
> +}
> +
> +static int aspeed_sdc_probe(struct platform_device *pdev)
> +
> +{
> struct aspeed_sdc *sdc;
> int ret;
>
> @@ -256,17 +276,9 @@ static int aspeed_sdc_probe(struct platform_device *pdev)
>
> dev_set_drvdata(>dev, sdc);
>
> - parent = pdev->dev.of_node;
> - for_each_available_child_of_node(parent, child) {
> - struct platform_device *cpdev;
> -
> - cpdev = of_platform_device_create(child, NULL, >dev);
> - if (!cpdev) {
> - of_node_put(child);
> - ret = -ENODEV;
> - goto err_clk;
> - }
> - }
> + ret = aspeed_sdc_create_sdhcis(pdev);
> + if (ret)
> + goto err_clk;
>
> return 0;
>
> --
> 2.20.1
>
[PATCH v6 2/3] genirq: introduce irq_update_devid()
Sometimes, only the dev_id field of irqaction needs to be changed.
E.g. KVM VM with device passthru via VFIO may switch the interrupt
injection path between KVM irqfd and userspace eventfd. These two
paths share the same interrupt number and handler for the same msi
vector of a device, only with different 'dev_id's referencing to
different fds' contexts. Set interrupt affinity in this VM is a way
to trigger the path switching.
Currently, VFIO uses a free-then-request-irq way for the path switching.
There is a time window between free_irq() and request_irq() where the
target IRTE is invalid. So, in-flight interrupts (buffering in hardware
layer and unfortunately cannot be synchronized in software) can cause
DMAR faults and even worse, this VM may hang in waiting IO completion.
By using irq_update_devid(), this issue can be avoided since IRTE will
not be invalidated during the whole process.
Signed-off-by: Ben Luo
---
include/linux/interrupt.h | 3 ++
kernel/irq/manage.c | 75 +++
2 files changed, 78 insertions(+)
diff --git a/include/linux/interrupt.h b/include/linux/interrupt.h
index 5b8328a..09b6a0f 100644
--- a/include/linux/interrupt.h
+++ b/include/linux/interrupt.h
@@ -172,6 +172,9 @@ struct irqaction {
request_percpu_nmi(unsigned int irq, irq_handler_t handler,
const char *devname, void __percpu *dev);
+extern int __must_check
+irq_update_devid(unsigned int irq, void *dev_id, void *new_dev_id);
+
extern const void *free_irq(unsigned int, void *);
extern void free_percpu_irq(unsigned int, void __percpu *);
diff --git a/kernel/irq/manage.c b/kernel/irq/manage.c
index 10ec3e9..adb1980 100644
--- a/kernel/irq/manage.c
+++ b/kernel/irq/manage.c
@@ -2063,6 +2063,81 @@ int request_threaded_irq(unsigned int irq, irq_handler_t
handler,
EXPORT_SYMBOL(request_threaded_irq);
/**
+ * irq_update_devid - update irq dev_id to a new one
+ *
+ * @irq: Interrupt line to update
+ * @dev_id:A cookie to find the irqaction to update
+ * @new_dev_id:New cookie passed to the handler function
+ *
+ * Sometimes, only the cookie data need to be changed. Instead of
+ * free-then-request interrupt, only update dev_id of irqaction can
+ * not only gain some performance benefit, but also reduce the risk
+ * of losing interrupt.
+ *
+ * This function won't update dev_id until any executing interrupts
+ * for this IRQ have completed. This function must not be called
+ * from interrupt context.
+ *
+ * On failure, it returns a negative value. On success,
+ * it returns 0
+ */
+int irq_update_devid(unsigned int irq, void *dev_id, void *new_dev_id)
+{
+ struct irq_desc *desc = irq_to_desc(irq);
+ struct irqaction *action, **action_ptr;
+ unsigned long flags;
+
+ if (WARN(in_interrupt(),
+"Trying to update IRQ %d (dev_id %p to %p) from IRQ
context!\n",
+irq, dev_id, new_dev_id))
+ return -EPERM;
+
+ if (!desc)
+ return -EINVAL;
+
+ /*
+* Ensure that an interrupt in flight on another CPU which uses the
+* old 'dev_id' has completed because the caller can free the memory
+* to which it points after this function returns. And also avoid to
+* update 'dev_id' in the middle of a threaded interrupt process, it
+* can lead to a twist that primary handler uses old 'dev_id' but new
+* 'dev_id' is used by secondary handler.
+*/
+ disable_irq(irq);
+ raw_spin_lock_irqsave(>lock, flags);
+
+ /*
+* There can be multiple actions per IRQ descriptor, find the right
+* one based on the dev_id:
+*/
+ action_ptr = >action;
+ for (;;) {
+ action = *action_ptr;
+
+ if (!action) {
+ raw_spin_unlock_irqrestore(>lock, flags);
+ enable_irq(irq);
+ WARN(1,
+"Trying to update already-free IRQ %d (dev_id %p
to %p)\n",
+irq, dev_id, new_dev_id);
+ return -ENXIO;
+ }
+
+ if (action->dev_id == dev_id) {
+ action->dev_id = new_dev_id;
+ break;
+ }
+ action_ptr = >next;
+ }
+
+ raw_spin_unlock_irqrestore(>lock, flags);
+ enable_irq(irq);
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(irq_update_devid);
+
+/**
* request_any_context_irq - allocate an interrupt line
* @irq: Interrupt line to allocate
* @handler: Function to be called when the IRQ occurs.
--
1.8.3.1
linux-next: manual merge of the sound-asoc tree with the jc_docs tree
Hi all,
Today's linux-next merge of the sound-asoc tree got a conflict in:
Documentation/devicetree/bindings/sound/sun8i-a33-codec.txt
between commit:
aa95b4a960ab ("docs: fix a couple of new broken references")
from the jc_docs tree and commit:
8a99f76ac1a5 ("ASoC: dt-bindings: Convert Allwinner A33 codec to a schema")
from the sound-asoc tree.
I fixed it up (the latter removed the file, so I did that) and can
carry the fix as necessary. This is now fixed as far as linux-next is
concerned, but any non trivial conflicts should be mentioned to your
upstream maintainer when your tree is submitted for merging. You may
also want to consider cooperating with the maintainer of the conflicting
tree to minimise any particularly complex conflicts.
--
Cheers,
Stephen Rothwell
pgpgKuScaefD2.pgp
Description: OpenPGP digital signature
[PATCH v6 3/3] vfio/pci: make use of irq_update_devid() and optimize irq ops
When userspace (e.g. qemu) triggers a switch between KVM
irqfd and userspace eventfd, only dev_id of irqaction
(i.e. the "trigger" in this patch's context) will be
changed, but a free-then-request-irq action is taken in
current code. And, interrupt affinity setting in VM will
also trigger a free-then-request-irq action, which actually
changes nothing in irqaction.
This patch makes use of irq_update_devid() and optimize
both cases above, which reduces the risk of losing interrupt
and also cuts some overhead.
Signed-off-by: Ben Luo
---
drivers/vfio/pci/vfio_pci_intrs.c | 118 ++
1 file changed, 81 insertions(+), 37 deletions(-)
diff --git a/drivers/vfio/pci/vfio_pci_intrs.c
b/drivers/vfio/pci/vfio_pci_intrs.c
index 3fa3f72..57b2de3 100644
--- a/drivers/vfio/pci/vfio_pci_intrs.c
+++ b/drivers/vfio/pci/vfio_pci_intrs.c
@@ -284,8 +284,8 @@ static int vfio_msi_enable(struct vfio_pci_device *vdev,
int nvec, bool msix)
static int vfio_msi_set_vector_signal(struct vfio_pci_device *vdev,
int vector, int fd, bool msix)
{
+ struct eventfd_ctx *trigger = NULL;
struct pci_dev *pdev = vdev->pdev;
- struct eventfd_ctx *trigger;
int irq, ret;
if (vector < 0 || vector >= vdev->num_ctx)
@@ -293,61 +293,105 @@ static int vfio_msi_set_vector_signal(struct
vfio_pci_device *vdev,
irq = pci_irq_vector(pdev, vector);
+ if (fd >= 0)
+ trigger = eventfd_ctx_fdget(fd);
+
+ /*
+* 'trigger' is NULL or invalid, disable the interrupt
+* 'trigger' is same as before, only bounce the bypass registration
+* 'trigger' is a new valid one, update it to irqaction and other
+* data structures referencing to the old one; fallback to disable
+* the interrupt on error
+*/
if (vdev->ctx[vector].trigger) {
- free_irq(irq, vdev->ctx[vector].trigger);
+ /*
+* even if the trigger is unchanged, we need to bounce the
+* interrupt bypass connection to allow affinity changes in
+* the guest to be realized.
+*/
irq_bypass_unregister_producer(>ctx[vector].producer);
- kfree(vdev->ctx[vector].name);
- eventfd_ctx_put(vdev->ctx[vector].trigger);
- vdev->ctx[vector].trigger = NULL;
+
+ if (vdev->ctx[vector].trigger == trigger) {
+ /* avoid duplicated referencing to the same trigger */
+ eventfd_ctx_put(trigger);
+
+ } else if (trigger && !IS_ERR(trigger)) {
+ ret = irq_update_devid(irq,
+ vdev->ctx[vector].trigger,
+ trigger);
+ if (unlikely(ret)) {
+ dev_info(>dev,
+"update devid of %d (token %p) failed:
%d\n",
+irq, vdev->ctx[vector].trigger, ret);
+ eventfd_ctx_put(trigger);
+ free_irq(irq, vdev->ctx[vector].trigger);
+ kfree(vdev->ctx[vector].name);
+ eventfd_ctx_put(vdev->ctx[vector].trigger);
+ vdev->ctx[vector].trigger = NULL;
+ return ret;
+ }
+ eventfd_ctx_put(vdev->ctx[vector].trigger);
+ vdev->ctx[vector].producer.token = trigger;
+ vdev->ctx[vector].trigger = trigger;
+
+ } else {
+ free_irq(irq, vdev->ctx[vector].trigger);
+ kfree(vdev->ctx[vector].name);
+ eventfd_ctx_put(vdev->ctx[vector].trigger);
+ vdev->ctx[vector].trigger = NULL;
+ }
}
if (fd < 0)
return 0;
+ else if (IS_ERR(trigger))
+ return PTR_ERR(trigger);
- vdev->ctx[vector].name = kasprintf(GFP_KERNEL, "vfio-msi%s[%d](%s)",
- msix ? "x" : "", vector,
- pci_name(pdev));
- if (!vdev->ctx[vector].name)
- return -ENOMEM;
+ if (!vdev->ctx[vector].trigger) {
+ vdev->ctx[vector].name = kasprintf(GFP_KERNEL,
+ "vfio-msi%s[%d](%s)",
+ msix ? "x" : "", vector,
+ pci_name(pdev));
+ if (!vdev->ctx[vector].name) {
+ eventfd_ctx_put(trigger);
+ return -ENOMEM;
+ }
- trigger = eventfd_ctx_fdget(fd);
- if (IS_ERR(trigger)) {
-
[PATCH v6 1/3] genirq: enhance error recovery code in free irq
__free_irq()/__free_percpu_irq() need to return if called from IRQ
context because the interrupt handler loop runs with desc->lock dropped
and dev_id can be subject to load and store tearing. Also move WARNs
out of lock region and print out dev_id to help debugging.
Signed-off-by: Ben Luo
---
kernel/irq/manage.c | 30 ++
1 file changed, 18 insertions(+), 12 deletions(-)
diff --git a/kernel/irq/manage.c b/kernel/irq/manage.c
index e8f7f17..10ec3e9 100644
--- a/kernel/irq/manage.c
+++ b/kernel/irq/manage.c
@@ -1690,7 +1690,10 @@ static struct irqaction *__free_irq(struct irq_desc
*desc, void *dev_id)
struct irqaction *action, **action_ptr;
unsigned long flags;
- WARN(in_interrupt(), "Trying to free IRQ %d from IRQ context!\n", irq);
+ if (WARN(in_interrupt(),
+"Trying to free IRQ %d (dev_id %p) from IRQ context!\n",
+irq, dev_id))
+ return NULL;
mutex_lock(>request_mutex);
chip_bus_lock(desc);
@@ -1705,10 +1708,11 @@ static struct irqaction *__free_irq(struct irq_desc
*desc, void *dev_id)
action = *action_ptr;
if (!action) {
- WARN(1, "Trying to free already-free IRQ %d\n", irq);
raw_spin_unlock_irqrestore(>lock, flags);
chip_bus_sync_unlock(desc);
mutex_unlock(>request_mutex);
+ WARN(1, "Trying to free already-free IRQ %d (dev_id
%p)\n",
+irq, dev_id);
return NULL;
}
@@ -2286,7 +2290,10 @@ static struct irqaction *__free_percpu_irq(unsigned int
irq, void __percpu *dev_
struct irqaction *action;
unsigned long flags;
- WARN(in_interrupt(), "Trying to free IRQ %d from IRQ context!\n", irq);
+ if (WARN(in_interrupt(),
+"Trying to free IRQ %d (dev_id %p) from IRQ context!\n",
+irq, dev_id))
+ return NULL;
if (!desc)
return NULL;
@@ -2295,14 +2302,17 @@ static struct irqaction *__free_percpu_irq(unsigned int
irq, void __percpu *dev_
action = desc->action;
if (!action || action->percpu_dev_id != dev_id) {
- WARN(1, "Trying to free already-free IRQ %d\n", irq);
- goto bad;
+ raw_spin_unlock_irqrestore(>lock, flags);
+ WARN(1, "Trying to free already-free IRQ (dev_id %p) %d\n",
+dev_id, irq);
+ return NULL;
}
if (!cpumask_empty(desc->percpu_enabled)) {
- WARN(1, "percpu IRQ %d still enabled on CPU%d!\n",
-irq, cpumask_first(desc->percpu_enabled));
- goto bad;
+ raw_spin_unlock_irqrestore(>lock, flags);
+ WARN(1, "percpu IRQ %d (dev_id %p) still enabled on CPU%d!\n",
+irq, dev_id, cpumask_first(desc->percpu_enabled));
+ return NULL;
}
/* Found it - now remove it from the list of entries: */
@@ -2317,10 +2327,6 @@ static struct irqaction *__free_percpu_irq(unsigned int
irq, void __percpu *dev_
irq_chip_pm_put(>irq_data);
module_put(desc->owner);
return action;
-
-bad:
- raw_spin_unlock_irqrestore(>lock, flags);
- return NULL;
}
/**
--
1.8.3.1
[PATCH v6 0/3] genirq/vfio: Introduce irq_update_devid() and optimize VFIO irq ops
Currently, VFIO takes a free-then-request-irq way to do interrupt affinity setting and masking/unmasking for a VM with device passthru via VFIO. Sometimes it only changes the cookie data of irqaction or even changes nothing. The free-then-request-irq not only adds more latency, but also increases the risk of losing interrupt, which may lead to a VM hang forever in waiting for IO completion This patchset solved the issue by: Patch 2 introduces irq_update_devid() to only update dev_id of irqaction Patch 3 make use of this function and optimize irq operations in VFIO changes from v5: - Patch 3: remove an error log to avoid potential DDoS attacking _ Patch 3: fix typo in comment changes from v4: - Patch 3: follow the previous behavior to disable interrupt on error path - Patch 3: do irqbypass registration before update or free the interrupt - Patch 3: add more comments changes from v3: - Patch 2: rename the new function to irq_update_devid() - Patch 2: use disbale_irq() to avoid a twist for threaded interrupt - ALL: amend commit messages and code comments changes from v2: - reformat to avoid quoted string split across lines and etc. changes from v1: - add Patch 1 to enhance error recovery etc. in free irq per tglx's comments - enhance error recovery code and debugging info in irq_update_devid - use __must_check in external referencing of this function - use EXPORT_SYMBOL_GPL for irq_update_devid - reformat code of patch 3 for better readability Ben Luo (3): genirq: enhance error recovery code in free irq genirq: introduce irq_update_devid() vfio/pci: make use of irq_update_devid() and optimize irq ops drivers/vfio/pci/vfio_pci_intrs.c | 118 ++ include/linux/interrupt.h | 3 + kernel/irq/manage.c | 105 + 3 files changed, 177 insertions(+), 49 deletions(-) -- 1.8.3.1
Re: [PATCH v7 3/6] powerpc/perf: consolidate read_user_stack_32
Michael Ellerman writes:
> Michal Suchanek writes:
...
>> @@ -295,6 +279,12 @@ static inline int current_is_64bit(void)
>> }
>>
>> #else /* CONFIG_PPC64 */
>> +static int read_user_stack_slow(void __user *ptr, void *buf, int nb)
>> +{
>> +return 0;
>> +}
>> +#endif /* CONFIG_PPC64 */
>
> Ending the PPC64 else case here, and then restarting it below with an
> ifndef means we end up with two parts of the file that define 32-bit
> code, with a common chunk in the middle, which I dislike.
>
> I'd rather you add the empty read_user_stack_slow() in the existing
> #else section and then move read_user_stack_32() below the whole ifdef
> PPC64/else/endif section.
>
> Is there some reason that doesn't work?
Gah, I missed that you split the whole file later in the series. Any
reason you did it in two steps rather than moving patch 6 earlier in the
series?
cheers
[PATCH v2 4/4] mmc: sdhci-of-aspeed: Allow max-frequency limitation of SDCLK
Add a get_max_clock() handler to sdhci-of-aspeed to report f_max as the
maximum clock rate if it is set. This enables artificial limitation of
the bus speed via max-frequency in the devicetree for e.g. the AST2600
evaluation board where I was seeing errors at 200MHz.
Signed-off-by: Andrew Jeffery
---
drivers/mmc/host/sdhci-of-aspeed.c | 20 ++--
1 file changed, 18 insertions(+), 2 deletions(-)
diff --git a/drivers/mmc/host/sdhci-of-aspeed.c
b/drivers/mmc/host/sdhci-of-aspeed.c
index c31d74427c49..a8a5341b526c 100644
--- a/drivers/mmc/host/sdhci-of-aspeed.c
+++ b/drivers/mmc/host/sdhci-of-aspeed.c
@@ -52,16 +52,24 @@ static void aspeed_sdc_configure_8bit_mode(struct
aspeed_sdc *sdc,
static void aspeed_sdhci_set_clock(struct sdhci_host *host, unsigned int clock)
{
+ struct sdhci_pltfm_host *pltfm_host;
+ unsigned long parent;
int div;
u16 clk;
+ pltfm_host = sdhci_priv(host);
+ parent = clk_get_rate(pltfm_host->clk);
+
sdhci_writew(host, 0, SDHCI_CLOCK_CONTROL);
if (clock == 0)
return;
+ if (WARN_ON(clock > host->max_clk))
+ clock = host->max_clk;
+
for (div = 1; div < 256; div *= 2) {
- if ((host->max_clk / div) <= clock)
+ if ((parent / div) <= clock)
break;
}
div >>= 1;
@@ -71,6 +79,14 @@ static void aspeed_sdhci_set_clock(struct sdhci_host *host,
unsigned int clock)
sdhci_enable_clk(host, clk);
}
+static unsigned int aspeed_sdhci_get_max_clock(struct sdhci_host *host)
+{
+ if (host->mmc->f_max)
+ return host->mmc->f_max;
+
+ return sdhci_pltfm_clk_get_max_clock(host);
+}
+
static void aspeed_sdhci_set_bus_width(struct sdhci_host *host, int width)
{
struct sdhci_pltfm_host *pltfm_priv;
@@ -97,7 +113,7 @@ static void aspeed_sdhci_set_bus_width(struct sdhci_host
*host, int width)
static const struct sdhci_ops aspeed_sdhci_ops = {
.set_clock = aspeed_sdhci_set_clock,
- .get_max_clock = sdhci_pltfm_clk_get_max_clock,
+ .get_max_clock = aspeed_sdhci_get_max_clock,
.set_bus_width = aspeed_sdhci_set_bus_width,
.get_timeout_clock = sdhci_pltfm_clk_get_max_clock,
.reset = sdhci_reset,
--
2.20.1
[PATCH v2 3/4] mmc: sdhci-of-aspeed: Uphold clocks-on post-condition of set_clock()
The early-exit didn't seem to matter on the AST2500, but on the AST2600 the SD clock genuinely may not be running on entry to aspeed_sdhci_set_clock(). Remove the early exit to ensure we always run sdhci_enable_clk(). Signed-off-by: Andrew Jeffery --- drivers/mmc/host/sdhci-of-aspeed.c | 3 --- 1 file changed, 3 deletions(-) diff --git a/drivers/mmc/host/sdhci-of-aspeed.c b/drivers/mmc/host/sdhci-of-aspeed.c index 213b3dbd49ef..c31d74427c49 100644 --- a/drivers/mmc/host/sdhci-of-aspeed.c +++ b/drivers/mmc/host/sdhci-of-aspeed.c @@ -55,9 +55,6 @@ static void aspeed_sdhci_set_clock(struct sdhci_host *host, unsigned int clock) int div; u16 clk; - if (clock == host->clock) - return; - sdhci_writew(host, 0, SDHCI_CLOCK_CONTROL); if (clock == 0) -- 2.20.1
[PATCH v2 2/4] mmc: sdhci-of-aspeed: Drop redundant assignment to host->clock
host->clock is already managed by sdhci_set_ios().
Suggested-by: Ulf Hansson
Signed-off-by: Andrew Jeffery
---
drivers/mmc/host/sdhci-of-aspeed.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/drivers/mmc/host/sdhci-of-aspeed.c
b/drivers/mmc/host/sdhci-of-aspeed.c
index 96ca494752c5..213b3dbd49ef 100644
--- a/drivers/mmc/host/sdhci-of-aspeed.c
+++ b/drivers/mmc/host/sdhci-of-aspeed.c
@@ -61,7 +61,7 @@ static void aspeed_sdhci_set_clock(struct sdhci_host *host,
unsigned int clock)
sdhci_writew(host, 0, SDHCI_CLOCK_CONTROL);
if (clock == 0)
- goto out;
+ return;
for (div = 1; div < 256; div *= 2) {
if ((host->max_clk / div) <= clock)
@@ -72,9 +72,6 @@ static void aspeed_sdhci_set_clock(struct sdhci_host *host,
unsigned int clock)
clk = div << SDHCI_DIVIDER_SHIFT;
sdhci_enable_clk(host, clk);
-
-out:
- host->clock = clock;
}
static void aspeed_sdhci_set_bus_width(struct sdhci_host *host, int width)
--
2.20.1
[PATCH v2 1/4] mmc: sdhci-of-aspeed: Fix link failure for SPARC
Resolves the following build error reported by the 0-day bot:
ERROR: "of_platform_device_create" [drivers/mmc/host/sdhci-of-aspeed.ko]
undefined!
SPARC does not set CONFIG_OF_ADDRESS so the symbol is missing. Guard the
callsite to maintain build coverage for the rest of the driver.
Reported-by: kbuild test robot
Signed-off-by: Andrew Jeffery
---
drivers/mmc/host/sdhci-of-aspeed.c | 38 --
1 file changed, 25 insertions(+), 13 deletions(-)
diff --git a/drivers/mmc/host/sdhci-of-aspeed.c
b/drivers/mmc/host/sdhci-of-aspeed.c
index d5acb5afc50f..96ca494752c5 100644
--- a/drivers/mmc/host/sdhci-of-aspeed.c
+++ b/drivers/mmc/host/sdhci-of-aspeed.c
@@ -224,10 +224,30 @@ static struct platform_driver aspeed_sdhci_driver = {
.remove = aspeed_sdhci_remove,
};
-static int aspeed_sdc_probe(struct platform_device *pdev)
-
+static int aspeed_sdc_create_sdhcis(struct platform_device *pdev)
{
+#if defined(CONFIG_OF_ADDRESS)
struct device_node *parent, *child;
+
+ parent = pdev->dev.of_node;
+
+ for_each_available_child_of_node(parent, child) {
+ struct platform_device *cpdev;
+
+ cpdev = of_platform_device_create(child, NULL, >dev);
+ if (!cpdev) {
+ of_node_put(child);
+ return -ENODEV;
+ }
+ }
+#endif
+
+ return 0;
+}
+
+static int aspeed_sdc_probe(struct platform_device *pdev)
+
+{
struct aspeed_sdc *sdc;
int ret;
@@ -256,17 +276,9 @@ static int aspeed_sdc_probe(struct platform_device *pdev)
dev_set_drvdata(>dev, sdc);
- parent = pdev->dev.of_node;
- for_each_available_child_of_node(parent, child) {
- struct platform_device *cpdev;
-
- cpdev = of_platform_device_create(child, NULL, >dev);
- if (!cpdev) {
- of_node_put(child);
- ret = -ENODEV;
- goto err_clk;
- }
- }
+ ret = aspeed_sdc_create_sdhcis(pdev);
+ if (ret)
+ goto err_clk;
return 0;
--
2.20.1
[PATCH v2 0/4] mmc: sdhci-of-aspeed: Fixes for AST2600 eMMC support
Hello, I've added a couple of patches since v1 of this series. The horizon has broadened slightly with a fix for SPARC builds as well in patch 1/4. Ulf suggested a minor cleanup on v1 with respect to handling of the current clock value, so that's now patch 2/4. Patches 3/4 and 4/4 are as they were in v1. The v1 series can be found here: https://patchwork.ozlabs.org/cover/1155757/ Please review! Andrew Andrew Jeffery (4): mmc: sdhci-of-aspeed: Fix link failure for SPARC mmc: sdhci-of-aspeed: Drop redundant assignment to host->clock mmc: sdhci-of-aspeed: Uphold clocks-on post-condition of set_clock() mmc: sdhci-of-aspeed: Allow max-frequency limitation of SDCLK drivers/mmc/host/sdhci-of-aspeed.c | 62 -- 1 file changed, 42 insertions(+), 20 deletions(-) -- 2.20.1
RE: [PATCH v3 00/11] *** SUBJECT HERE ***
> -Original Message- > From: Z.q. Hou > Sent: 2019年9月2日 11:52 > To: Xiaowei Bao ; robh...@kernel.org; > mark.rutl...@arm.com; shawn...@kernel.org; Leo Li > ; kis...@ti.com; lorenzo.pieral...@arm.com; M.h. Lian > ; Mingkai Hu ; Roy Zang > ; jingooh...@gmail.com; > gustavo.pimen...@synopsys.com; linux-...@vger.kernel.org; > devicet...@vger.kernel.org; linux-kernel@vger.kernel.org; > linux-arm-ker...@lists.infradead.org; linuxppc-...@lists.ozlabs.org > Cc: a...@arndb.de; gre...@linuxfoundation.org; Xiaowei Bao > > Subject: RE: [PATCH v3 00/11] *** SUBJECT HERE *** > > Xiaowei, > > > -Original Message- > > From: Xiaowei Bao > > Sent: 2019年9月2日 11:17 > > To: robh...@kernel.org; mark.rutl...@arm.com; shawn...@kernel.org; > Leo > > Li ; kis...@ti.com; lorenzo.pieral...@arm.com; > > M.h. Lian ; Mingkai Hu ; > > Roy Zang ; jingooh...@gmail.com; > > gustavo.pimen...@synopsys.com; linux-...@vger.kernel.org; > > devicet...@vger.kernel.org; linux-kernel@vger.kernel.org; > > linux-arm-ker...@lists.infradead.org; linuxppc-...@lists.ozlabs.org > > Cc: a...@arndb.de; gre...@linuxfoundation.org; Z.q. Hou > > ; Xiaowei Bao > > Subject: [PATCH v3 00/11] *** SUBJECT HERE *** > > > > *** BLURB HERE *** > > Add subject and blurb for this series. OK, thanks. > > Thanks, > Zhiqiang > > > > > Xiaowei Bao (11): > > PCI: designware-ep: Add multiple PFs support for DWC > > PCI: designware-ep: Add the doorbell mode of MSI-X in EP mode > > PCI: designware-ep: Move the function of getting MSI capability > > forward > > PCI: designware-ep: Modify MSI and MSIX CAP way of finding > > dt-bindings: pci: layerscape-pci: add compatible strings for ls1088a > > and ls2088a > > PCI: layerscape: Fix some format issue of the code > > PCI: layerscape: Modify the way of getting capability with different > > PEX > > PCI: layerscape: Modify the MSIX to the doorbell mode > > PCI: layerscape: Add EP mode support for ls1088a and ls2088a > > arm64: dts: layerscape: Add PCIe EP node for ls1088a > > misc: pci_endpoint_test: Add LS1088a in pci_device_id table > > > > .../devicetree/bindings/pci/layerscape-pci.txt | 4 +- > > arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi | 31 +++ > > drivers/misc/pci_endpoint_test.c | 1 + > > drivers/pci/controller/dwc/pci-layerscape-ep.c | 100 ++-- > > drivers/pci/controller/dwc/pcie-designware-ep.c| 255 > > + > > drivers/pci/controller/dwc/pcie-designware.c | 59 +++-- > > drivers/pci/controller/dwc/pcie-designware.h | 48 +++- > > 7 files changed, 404 insertions(+), 94 deletions(-) > > > > -- > > 2.9.5
[PATCH v6 1/3] dt-bindings: pci: layerscape-pci: add compatible strings "fsl,ls1028a-pcie"
Add the PCIe compatible string for LS1028A Signed-off-by: Xiaowei Bao Signed-off-by: Hou Zhiqiang Reviewed-by: Rob Herring --- v2: - No change. v3: - No change. v4: - No change. v5: - No change. v6: - No change. Documentation/devicetree/bindings/pci/layerscape-pci.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/pci/layerscape-pci.txt b/Documentation/devicetree/bindings/pci/layerscape-pci.txt index e20ceaa..99a386e 100644 --- a/Documentation/devicetree/bindings/pci/layerscape-pci.txt +++ b/Documentation/devicetree/bindings/pci/layerscape-pci.txt @@ -21,6 +21,7 @@ Required properties: "fsl,ls1046a-pcie" "fsl,ls1043a-pcie" "fsl,ls1012a-pcie" +"fsl,ls1028a-pcie" EP mode: "fsl,ls1046a-pcie-ep", "fsl,ls-pcie-ep" - reg: base addresses and lengths of the PCIe controller register blocks. -- 2.9.5
[PATCH v6 3/3] PCI: layerscape: Add LS1028a support
Add support for the LS1028a PCIe controller.
Signed-off-by: Xiaowei Bao
Signed-off-by: Hou Zhiqiang
---
v2:
- No change.
v3:
- Reuse the ls2088 driver data structurt.
v4:
- No change.
v5:
- No change.
v6:
- No change.
drivers/pci/controller/dwc/pci-layerscape.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/pci/controller/dwc/pci-layerscape.c
b/drivers/pci/controller/dwc/pci-layerscape.c
index 3a5fa26..f24f79a 100644
--- a/drivers/pci/controller/dwc/pci-layerscape.c
+++ b/drivers/pci/controller/dwc/pci-layerscape.c
@@ -263,6 +263,7 @@ static const struct ls_pcie_drvdata ls2088_drvdata = {
static const struct of_device_id ls_pcie_of_match[] = {
{ .compatible = "fsl,ls1012a-pcie", .data = _drvdata },
{ .compatible = "fsl,ls1021a-pcie", .data = _drvdata },
+ { .compatible = "fsl,ls1028a-pcie", .data = _drvdata },
{ .compatible = "fsl,ls1043a-pcie", .data = _drvdata },
{ .compatible = "fsl,ls1046a-pcie", .data = _drvdata },
{ .compatible = "fsl,ls2080a-pcie", .data = _drvdata },
--
2.9.5
[PATCH v6 2/3] arm64: dts: ls1028a: Add PCIe controller DT nodes
LS1028a implements 2 PCIe 3.0 controllers.
Signed-off-by: Xiaowei Bao
Signed-off-by: Hou Zhiqiang
---
v2:
- Fix up the legacy INTx allocate failed issue.
v3:
- No change.
v4:
- Remove the num-lanes property.
v5:
- Add the num-viewport property.
v6:
- move num-viewport to 8.
arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi | 52 ++
1 file changed, 52 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi
b/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi
index 72b9a75..c043b1d 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi
@@ -625,6 +625,58 @@
};
};
+ pcie@340 {
+ compatible = "fsl,ls1028a-pcie";
+ reg = <0x00 0x0340 0x0 0x0010 /* controller
registers */
+ 0x80 0x 0x0 0x2000>; /*
configuration space */
+ reg-names = "regs", "config";
+ interrupts = , /* PME
interrupt */
+; /* aer
interrupt */
+ interrupt-names = "pme", "aer";
+ #address-cells = <3>;
+ #size-cells = <2>;
+ device_type = "pci";
+ dma-coherent;
+ num-viewport = <8>;
+ bus-range = <0x0 0xff>;
+ ranges = <0x8100 0x0 0x 0x80 0x0001 0x0
0x0001 /* downstream I/O */
+ 0x8200 0x0 0x4000 0x80 0x4000 0x0
0x4000>; /* non-prefetchable memory */
+ msi-parent = <>;
+ #interrupt-cells = <1>;
+ interrupt-map-mask = <0 0 0 7>;
+ interrupt-map = < 0 0 1 0 0 GIC_SPI 109
IRQ_TYPE_LEVEL_HIGH>,
+ < 0 0 2 0 0 GIC_SPI 110
IRQ_TYPE_LEVEL_HIGH>,
+ < 0 0 3 0 0 GIC_SPI 111
IRQ_TYPE_LEVEL_HIGH>,
+ < 0 0 4 0 0 GIC_SPI 112
IRQ_TYPE_LEVEL_HIGH>;
+ status = "disabled";
+ };
+
+ pcie@350 {
+ compatible = "fsl,ls1028a-pcie";
+ reg = <0x00 0x0350 0x0 0x0010 /* controller
registers */
+ 0x88 0x 0x0 0x2000>; /*
configuration space */
+ reg-names = "regs", "config";
+ interrupts = ,
+;
+ interrupt-names = "pme", "aer";
+ #address-cells = <3>;
+ #size-cells = <2>;
+ device_type = "pci";
+ dma-coherent;
+ num-viewport = <8>;
+ bus-range = <0x0 0xff>;
+ ranges = <0x8100 0x0 0x 0x88 0x0001 0x0
0x0001 /* downstream I/O */
+ 0x8200 0x0 0x4000 0x88 0x4000 0x0
0x4000>; /* non-prefetchable memory */
+ msi-parent = <>;
+ #interrupt-cells = <1>;
+ interrupt-map-mask = <0 0 0 7>;
+ interrupt-map = < 0 0 1 0 0 GIC_SPI 114
IRQ_TYPE_LEVEL_HIGH>,
+ < 0 0 2 0 0 GIC_SPI 115
IRQ_TYPE_LEVEL_HIGH>,
+ < 0 0 3 0 0 GIC_SPI 116
IRQ_TYPE_LEVEL_HIGH>,
+ < 0 0 4 0 0 GIC_SPI 117
IRQ_TYPE_LEVEL_HIGH>;
+ status = "disabled";
+ };
+
pcie@1f000 { /* Integrated Endpoint Root Complex */
compatible = "pci-host-ecam-generic";
reg = <0x01 0xf000 0x0 0x10>;
--
2.9.5
Re: [PATCH v7 3/6] powerpc/perf: consolidate read_user_stack_32
Michal Suchanek writes:
> There are two almost identical copies for 32bit and 64bit.
>
> The function is used only in 32bit code which will be split out in next
> patch so consolidate to one function.
>
> Signed-off-by: Michal Suchanek
> Reviewed-by: Christophe Leroy
> ---
> new patch in v6
> ---
> arch/powerpc/perf/callchain.c | 25 +
> 1 file changed, 9 insertions(+), 16 deletions(-)
>
> diff --git a/arch/powerpc/perf/callchain.c b/arch/powerpc/perf/callchain.c
> index c84bbd4298a0..b7cdcce20280 100644
> --- a/arch/powerpc/perf/callchain.c
> +++ b/arch/powerpc/perf/callchain.c
> @@ -165,22 +165,6 @@ static int read_user_stack_64(unsigned long __user *ptr,
> unsigned long *ret)
> return read_user_stack_slow(ptr, ret, 8);
> }
>
> -static int read_user_stack_32(unsigned int __user *ptr, unsigned int *ret)
> -{
> - if ((unsigned long)ptr > TASK_SIZE - sizeof(unsigned int) ||
> - ((unsigned long)ptr & 3))
> - return -EFAULT;
> -
> - pagefault_disable();
> - if (!__get_user_inatomic(*ret, ptr)) {
> - pagefault_enable();
> - return 0;
> - }
> - pagefault_enable();
> -
> - return read_user_stack_slow(ptr, ret, 4);
> -}
> -
> static inline int valid_user_sp(unsigned long sp, int is_64)
> {
> if (!sp || (sp & 7) || sp > (is_64 ? TASK_SIZE : 0x1UL) - 32)
> @@ -295,6 +279,12 @@ static inline int current_is_64bit(void)
> }
>
> #else /* CONFIG_PPC64 */
> +static int read_user_stack_slow(void __user *ptr, void *buf, int nb)
> +{
> + return 0;
> +}
> +#endif /* CONFIG_PPC64 */
Ending the PPC64 else case here, and then restarting it below with an
ifndef means we end up with two parts of the file that define 32-bit
code, with a common chunk in the middle, which I dislike.
I'd rather you add the empty read_user_stack_slow() in the existing
#else section and then move read_user_stack_32() below the whole ifdef
PPC64/else/endif section.
Is there some reason that doesn't work?
cheers
> @@ -313,9 +303,12 @@ static int read_user_stack_32(unsigned int __user *ptr,
> unsigned int *ret)
> rc = __get_user_inatomic(*ret, ptr);
> pagefault_enable();
>
> + if (IS_ENABLED(CONFIG_PPC64) && rc)
> + return read_user_stack_slow(ptr, ret, 4);
> return rc;
> }
>
> +#ifndef CONFIG_PPC64
> static inline void perf_callchain_user_64(struct perf_callchain_entry_ctx
> *entry,
> struct pt_regs *regs)
> {
> --
> 2.22.0
RE: [PATCH v3 00/11] *** SUBJECT HERE ***
Xiaowei, > -Original Message- > From: Xiaowei Bao > Sent: 2019年9月2日 11:17 > To: robh...@kernel.org; mark.rutl...@arm.com; shawn...@kernel.org; > Leo Li ; kis...@ti.com; lorenzo.pieral...@arm.com; > M.h. Lian ; Mingkai Hu ; > Roy Zang ; jingooh...@gmail.com; > gustavo.pimen...@synopsys.com; linux-...@vger.kernel.org; > devicet...@vger.kernel.org; linux-kernel@vger.kernel.org; > linux-arm-ker...@lists.infradead.org; linuxppc-...@lists.ozlabs.org > Cc: a...@arndb.de; gre...@linuxfoundation.org; Z.q. Hou > ; Xiaowei Bao > Subject: [PATCH v3 00/11] *** SUBJECT HERE *** > > *** BLURB HERE *** Add subject and blurb for this series. Thanks, Zhiqiang > > Xiaowei Bao (11): > PCI: designware-ep: Add multiple PFs support for DWC > PCI: designware-ep: Add the doorbell mode of MSI-X in EP mode > PCI: designware-ep: Move the function of getting MSI capability > forward > PCI: designware-ep: Modify MSI and MSIX CAP way of finding > dt-bindings: pci: layerscape-pci: add compatible strings for ls1088a > and ls2088a > PCI: layerscape: Fix some format issue of the code > PCI: layerscape: Modify the way of getting capability with different > PEX > PCI: layerscape: Modify the MSIX to the doorbell mode > PCI: layerscape: Add EP mode support for ls1088a and ls2088a > arm64: dts: layerscape: Add PCIe EP node for ls1088a > misc: pci_endpoint_test: Add LS1088a in pci_device_id table > > .../devicetree/bindings/pci/layerscape-pci.txt | 4 +- > arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi | 31 +++ > drivers/misc/pci_endpoint_test.c | 1 + > drivers/pci/controller/dwc/pci-layerscape-ep.c | 100 ++-- > drivers/pci/controller/dwc/pcie-designware-ep.c| 255 > + > drivers/pci/controller/dwc/pcie-designware.c | 59 +++-- > drivers/pci/controller/dwc/pcie-designware.h | 48 +++- > 7 files changed, 404 insertions(+), 94 deletions(-) > > -- > 2.9.5
[PATCH v2] perf/x86/intel: Update ICL Core and Package C-state event counters
Ice Lake microarchitecture inherits Cannon Lake, it has CC1/PC8/PC9/PC10
residency counters.
Update the list of Ice Lake PMU event counters from the snb_cstates[] list
of events to the cnl_cstates[] list of events, which keeps all previously
supported events and also adds the CORE_C1, PKG_C8, PKG_C9, and PKG_C10
residency counters.
This benefits users to profile them through the perf interface.
Signed-off-by: Harry Pan
---
arch/x86/events/intel/cstate.c | 32 +---
1 file changed, 17 insertions(+), 15 deletions(-)
diff --git a/arch/x86/events/intel/cstate.c b/arch/x86/events/intel/cstate.c
index 688592b34564..82fbc4c6e5e6 100644
--- a/arch/x86/events/intel/cstate.c
+++ b/arch/x86/events/intel/cstate.c
@@ -35,56 +35,58 @@
*The counters include PKG_C*_RESIDENCY.
*
* All of these counters are specified in the Intel® 64 and IA-32
- * Architectures Software Developer.s Manual Vol3b.
+ * Architectures Software Developer's Manual Vol4.
*
* Model specific counters:
* MSR_CORE_C1_RES: CORE C1 Residency Counter
* perf code: 0x00
- * Available model: SLM,AMT,GLM,CNL
+ * Available model: SLM,AMT,GLM,CNL,ICL
* Scope: Core (each processor core has a MSR)
* MSR_CORE_C3_RESIDENCY: CORE C3 Residency Counter
*perf code: 0x01
*Available model: NHM,WSM,SNB,IVB,HSW,BDW,SKL,GLM,
- CNL
+ * CNL,ICL
*Scope: Core
* MSR_CORE_C6_RESIDENCY: CORE C6 Residency Counter
*perf code: 0x02
*Available model: SLM,AMT,NHM,WSM,SNB,IVB,HSW,BDW,
- * SKL,KNL,GLM,CNL
+ * SKL,KNL,GLM,CNL,ICL
*Scope: Core
* MSR_CORE_C7_RESIDENCY: CORE C7 Residency Counter
*perf code: 0x03
- *Available model: SNB,IVB,HSW,BDW,SKL,CNL
+ *Available model: SNB,IVB,HSW,BDW,SKL,CNL,ICL
*Scope: Core
* MSR_PKG_C2_RESIDENCY: Package C2 Residency Counter.
*perf code: 0x00
- *Available model: SNB,IVB,HSW,BDW,SKL,KNL,GLM,CNL
+ *Available model: SNB,IVB,HSW,BDW,SKL,KNL,GLM,CNL,
+ * ICL
*Scope: Package (physical package)
* MSR_PKG_C3_RESIDENCY: Package C3 Residency Counter.
*perf code: 0x01
*Available model: NHM,WSM,SNB,IVB,HSW,BDW,SKL,KNL,
- * GLM,CNL
+ * GLM,CNL,ICL
*Scope: Package (physical package)
* MSR_PKG_C6_RESIDENCY: Package C6 Residency Counter.
*perf code: 0x02
- *Available model: SLM,AMT,NHM,WSM,SNB,IVB,HSW,BDW
- * SKL,KNL,GLM,CNL
+ *Available model: SLM,AMT,NHM,WSM,SNB,IVB,HSW,BDW,
+ * SKL,KNL,GLM,CNL,ICL
*Scope: Package (physical package)
* MSR_PKG_C7_RESIDENCY: Package C7 Residency Counter.
*perf code: 0x03
- *Available model: NHM,WSM,SNB,IVB,HSW,BDW,SKL,CNL
+ *Available model: NHM,WSM,SNB,IVB,HSW,BDW,SKL,CNL,
+ * ICL
*Scope: Package (physical package)
* MSR_PKG_C8_RESIDENCY: Package C8 Residency Counter.
*perf code: 0x04
- *Available model: HSW ULT,KBL,CNL
+ *Available model: HSW ULT,KBL,CNL,ICL
*Scope: Package (physical package)
* MSR_PKG_C9_RESIDENCY: Package C9 Residency Counter.
*perf code: 0x05
- *Available model: HSW ULT,KBL,CNL
+ *Available model: HSW ULT,KBL,CNL,ICL
*Scope: Package (physical package)
* MSR_PKG_C10_RESIDENCY: Package C10 Residency Counter.
*perf code: 0x06
- *Available model: HSW ULT,KBL,GLM,CNL
+ *Available model: HSW ULT,KBL,GLM,CNL,ICL
*Scope: Package (physical package)
*
*/
@@ -625,8 +627,8 @@ static const struct x86_cpu_id intel_cstates_match[]
__initconst = {
X86_CSTATES_MODEL(INTEL_FAM6_ATOM_GOLDMONT_PLUS, glm_cstates),
Re: [PATCH v2] powerpc/32: Add VDSO version of getcpu
Hi Christophe, Thank you for the patch! Yet something to improve: [auto build test ERROR on linus/master] [cannot apply to v5.3-rc6 next-20190830] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Christophe-Leroy/powerpc-32-Add-VDSO-version-of-getcpu/20190819-034351 config: powerpc-sequoia_defconfig (attached as .config) compiler: powerpc-linux-gcc (GCC) 7.4.0 reproduce: 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 GCC_VERSION=7.4.0 make.cross ARCH=powerpc If you fix the issue, kindly add following tag Reported-by: kbuild test robot All errors (new ones prefixed by >>): In file included from arch/powerpc/kernel/head_booke.h:7:0, from arch/powerpc/kernel/asm-offsets.c:61: >> arch/powerpc/include/asm/asm-offsets.h:1:10: fatal error: >> generated/asm-offsets.h: No such file or directory #include ^ compilation terminated. make[2]: *** [arch/powerpc/kernel/asm-offsets.s] Error 1 make[2]: Target '__build' not remade because of errors. make[1]: *** [prepare0] Error 2 make[1]: Target 'prepare' not remade because of errors. make: *** [sub-make] Error 2 20 real 7 user 6 sys 67.53% cpu make prepare vim +1 arch/powerpc/include/asm/asm-offsets.h 559df2e0210352 Sam Ravnborg 2009-04-19 @1 #include :: The code at line 1 was first introduced by commit :: 559df2e0210352f83926d178c40c51142292a18c kbuild: move asm-offsets.h to include/generated :: TO: Sam Ravnborg :: CC: Michal Marek --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation .config.gz Description: application/gzip
Re: [PATCH v2 2/2] uacce: add uacce driver
Hi, Greg
On 2019/8/30 下午10:54, zhangfei wrote:
On 2019/8/28 下午11:22, Greg Kroah-Hartman wrote:
On Wed, Aug 28, 2019 at 09:27:56PM +0800, Zhangfei Gao wrote:
+struct uacce {
+ const char *drv_name;
+ const char *algs;
+ const char *api_ver;
+ unsigned int flags;
+ unsigned long qf_pg_start[UACCE_QFRT_MAX];
+ struct uacce_ops *ops;
+ struct device *pdev;
+ bool is_vf;
+ u32 dev_id;
+ struct cdev cdev;
+ struct device dev;
+ void *priv;
+ atomic_t state;
+ int prot;
+ struct mutex q_lock;
+ struct list_head qs;
+};
At a quick glance, this problem really stood out to me. You CAN NOT
have two different objects within a structure that have different
lifetime rules and reference counts. You do that here with both a
'struct cdev' and a 'struct device'. Pick one or the other, but never
both.
I would recommend using a 'struct device' and then a 'struct cdev *'.
That way you get the advantage of using the driver model properly, and
then just adding your char device node pointer to "the side" which
interacts with this device.
Then you might want to call this "struct uacce_device" :)
I think I understand now.
'struct device' and then a 'struct cdev' have different refcounts.
Using 'struct cdev *', the release is not in uacce.c, but controlled by
cdev itself.
So uacce is decoupled with cdev.
//Using 'struct cdev *'
cdev_alloc->cdev_dynamic_release:kfree(p);
uacce_destroy_chrdev:
cdev_device_del->cdev_del(cdev)->kobject_put(>kobj);
if (refcount--) == 0
cdev_dynamic_release->kfree(p);
//Using 'struct device'
cdev_init->cdev_default_release
cdev is freed in uacce.c,
So 'struct device' and then a 'struct cdev' are bind together, while
cdev and uacce->dev have different refcount.
Thanks for the patience.
Re: KASAN: use-after-free Write in __xfrm_policy_unlink (2)
On Thu, May 16, 2019 at 3:35 AM syzbot wrote: > > Hello, > > syzbot found the following crash on: > > HEAD commit:3b0f31f2 genetlink: make policy common to family > git tree: net-next > console output: https://syzkaller.appspot.com/x/log.txt?x=12a319df20 > kernel config: https://syzkaller.appspot.com/x/.config?x=f05902bca21d8935 > dashboard link: https://syzkaller.appspot.com/bug?extid=0025447b4cb6f208558f > compiler: gcc (GCC) 9.0.0 20181231 (experimental) > > Unfortunately, I don't have any reproducer for this crash yet. > > IMPORTANT: if you fix the bug, please add the following tag to the commit: > Reported-by: syzbot+0025447b4cb6f2085...@syzkaller.appspotmail.com This looks like what has been fixed by: #syz fix: xfrm: policy: Fix out-of-bound array accesses in __xfrm_policy_unlink > == > BUG: KASAN: use-after-free in __write_once_size > include/linux/compiler.h:220 [inline] > BUG: KASAN: use-after-free in __hlist_del include/linux/list.h:713 [inline] > BUG: KASAN: use-after-free in hlist_del_rcu include/linux/rculist.h:455 > [inline] > BUG: KASAN: use-after-free in __xfrm_policy_unlink+0x4b1/0x5c0 > net/xfrm/xfrm_policy.c:2212 > Write of size 8 at addr 8880a55a9e80 by task kworker/u4:6/7431 > > CPU: 1 PID: 7431 Comm: kworker/u4:6 Not tainted 5.0.0+ #106 > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS > Google 01/01/2011 > Workqueue: netns cleanup_net > Call Trace: > __dump_stack lib/dump_stack.c:77 [inline] > dump_stack+0x172/0x1f0 lib/dump_stack.c:113 > print_address_description.cold+0x7c/0x20d mm/kasan/report.c:187 > kasan_report.cold+0x1b/0x40 mm/kasan/report.c:317 > __asan_report_store8_noabort+0x17/0x20 mm/kasan/generic_report.c:137 > __write_once_size include/linux/compiler.h:220 [inline] > __hlist_del include/linux/list.h:713 [inline] > hlist_del_rcu include/linux/rculist.h:455 [inline] > __xfrm_policy_unlink+0x4b1/0x5c0 net/xfrm/xfrm_policy.c:2212 > xfrm_policy_flush+0x331/0x460 net/xfrm/xfrm_policy.c:1789 > xfrm_policy_fini+0x49/0x3a0 net/xfrm/xfrm_policy.c:3871 > xfrm_net_exit+0x1d/0x70 net/xfrm/xfrm_policy.c:3933 > ops_exit_list.isra.0+0xb0/0x160 net/core/net_namespace.c:153 > cleanup_net+0x3fb/0x960 net/core/net_namespace.c:551 > process_one_work+0x98e/0x1790 kernel/workqueue.c:2269 > worker_thread+0x98/0xe40 kernel/workqueue.c:2415 > kthread+0x357/0x430 kernel/kthread.c:253 > ret_from_fork+0x3a/0x50 arch/x86/entry/entry_64.S:352 > > Allocated by task 7242: > save_stack+0x45/0xd0 mm/kasan/common.c:75 > set_track mm/kasan/common.c:87 [inline] > __kasan_kmalloc mm/kasan/common.c:497 [inline] > __kasan_kmalloc.constprop.0+0xcf/0xe0 mm/kasan/common.c:470 > kasan_kmalloc+0x9/0x10 mm/kasan/common.c:511 > __do_kmalloc mm/slab.c:3726 [inline] > __kmalloc+0x15c/0x740 mm/slab.c:3735 > kmalloc include/linux/slab.h:550 [inline] > kzalloc include/linux/slab.h:740 [inline] > ext4_htree_store_dirent+0x8a/0x650 fs/ext4/dir.c:450 > htree_dirblock_to_tree+0x4fe/0x910 fs/ext4/namei.c:1021 > ext4_htree_fill_tree+0x252/0xa50 fs/ext4/namei.c:1098 > ext4_dx_readdir fs/ext4/dir.c:574 [inline] > ext4_readdir+0x1999/0x3490 fs/ext4/dir.c:121 > iterate_dir+0x489/0x5f0 fs/readdir.c:51 > __do_sys_getdents fs/readdir.c:231 [inline] > __se_sys_getdents fs/readdir.c:212 [inline] > __x64_sys_getdents+0x1dd/0x370 fs/readdir.c:212 > do_syscall_64+0x103/0x610 arch/x86/entry/common.c:290 > entry_SYSCALL_64_after_hwframe+0x49/0xbe > > Freed by task 7242: > save_stack+0x45/0xd0 mm/kasan/common.c:75 > set_track mm/kasan/common.c:87 [inline] > __kasan_slab_free+0x102/0x150 mm/kasan/common.c:459 > kasan_slab_free+0xe/0x10 mm/kasan/common.c:467 > __cache_free mm/slab.c:3498 [inline] > kfree+0xcf/0x230 mm/slab.c:3821 > free_rb_tree_fname+0x87/0xe0 fs/ext4/dir.c:402 > ext4_htree_free_dir_info fs/ext4/dir.c:424 [inline] > ext4_release_dir+0x46/0x70 fs/ext4/dir.c:622 > __fput+0x2e5/0x8d0 fs/file_table.c:278 > fput+0x16/0x20 fs/file_table.c:309 > task_work_run+0x14a/0x1c0 kernel/task_work.c:113 > tracehook_notify_resume include/linux/tracehook.h:188 [inline] > exit_to_usermode_loop+0x273/0x2c0 arch/x86/entry/common.c:166 > prepare_exit_to_usermode arch/x86/entry/common.c:197 [inline] > syscall_return_slowpath arch/x86/entry/common.c:268 [inline] > do_syscall_64+0x52d/0x610 arch/x86/entry/common.c:293 > entry_SYSCALL_64_after_hwframe+0x49/0xbe > > The buggy address belongs to the object at 8880a55a9e80 > which belongs to the cache kmalloc-64 of size 64 > The buggy address is located 0 bytes inside of > 64-byte region [8880a55a9e80, 8880a55a9ec0) > The buggy address belongs to the page: > page:ea0002956a40 count:1 mapcount:0 mapping:88812c3f0340 index:0x0 > flags: 0x1fffc000200(slab) > raw: 01fffc000200 ea0002a0d748 ea00018af1c8 88812c3f0340 > raw:
Re: [PATCH 1/6] powerpc/32s: add an option to exclusively select powerpc 601
On Mon, 2019-08-26 at 15:52:13 UTC, Christophe Leroy wrote: > Powerpc 601 is rather old powerpc which as some important > limitations compared to other book3s/32 powerpcs: > - No Timebase. > - Common BATs for instruction and data. > - No execution protection in segment registers. > - No RI bit in MSR > - ... > > It is starting to be difficult and cumbersome to maintain > kernels that are compatible both with 601 and other 6xx cores. > > Create a compiletime option to exclusively select either powerpc 601 > or other 6xx. > > Signed-off-by: Christophe Leroy Series applied to powerpc next, thanks. https://git.kernel.org/powerpc/c/f7a0bf7d904e902e13024986b7b357181ee30849 cheers
Re: [PATCH v4 2/2] drm/bridge: Add NWL MIPI DSI host controller support
Hi "Guido,
I love your patch! Perhaps something to improve:
[auto build test WARNING on linus/master]
[cannot apply to v5.3-rc6 next-20190830]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Guido-G-nther/dt-bindings-display-bridge-Add-binding-for-NWL-mipi-dsi-host-controller/20190901-114958
config: i386-allmodconfig (attached as .config)
compiler: gcc-7 (Debian 7.4.0-11) 7.4.0
reproduce:
# save the attached .config to linux build tree
make ARCH=i386
If you fix the issue, kindly add following tag
Reported-by: kbuild test robot
All warnings (new ones prefixed by >>):
In file included from drivers/gpu/drm/bridge/nwl-dsi/nwl-dsi.c:22:0:
drivers/gpu/drm/bridge/nwl-dsi/nwl-dsi.c: In function 'nwl_dsi_read_packet':
>> include/drm/drm_print.h:313:32: warning: format '%lu' expects argument of
>> type 'long unsigned int', but argument 5 has type 'size_t {aka const
>> unsigned int}' [-Wformat=]
drm_dev_printk(dev, KERN_ERR, "*ERROR* " fmt, ##__VA_ARGS__)
^
>> drivers/gpu/drm/bridge/nwl-dsi/nwl-dsi.c:402:4: note: in expansion of macro
>> 'DRM_DEV_ERROR'
DRM_DEV_ERROR(
^
drivers/gpu/drm/bridge/nwl-dsi/nwl-dsi.c:404:41: note: format string is
defined here
"[%02X] Receive buffer too small: %lu (< %u)\n",
~~^
%u
coccinelle warnings: (new ones prefixed by >>)
>> drivers/gpu/drm/bridge/nwl-dsi/nwl-dsi.c:233:5-17: WARNING: Unsigned
>> expression compared with zero: color_format < 0
vim +313 include/drm/drm_print.h
02c9656b2f0d69 Haneen Mohammed 2017-10-17 288
02c9656b2f0d69 Haneen Mohammed 2017-10-17 289 #define _DRM_PRINTK(once,
level, fmt, ...) \
db87086492581c Joe Perches 2018-03-16 290
printk##once(KERN_##level "[" DRM_NAME "] " fmt, ##__VA_ARGS__)
02c9656b2f0d69 Haneen Mohammed 2017-10-17 291
02c9656b2f0d69 Haneen Mohammed 2017-10-17 292 #define DRM_INFO(fmt, ...)
\
02c9656b2f0d69 Haneen Mohammed 2017-10-17 293 _DRM_PRINTK(, INFO,
fmt, ##__VA_ARGS__)
02c9656b2f0d69 Haneen Mohammed 2017-10-17 294 #define DRM_NOTE(fmt, ...)
\
02c9656b2f0d69 Haneen Mohammed 2017-10-17 295 _DRM_PRINTK(, NOTICE,
fmt, ##__VA_ARGS__)
02c9656b2f0d69 Haneen Mohammed 2017-10-17 296 #define DRM_WARN(fmt, ...)
\
02c9656b2f0d69 Haneen Mohammed 2017-10-17 297 _DRM_PRINTK(, WARNING,
fmt, ##__VA_ARGS__)
02c9656b2f0d69 Haneen Mohammed 2017-10-17 298
02c9656b2f0d69 Haneen Mohammed 2017-10-17 299 #define DRM_INFO_ONCE(fmt, ...)
\
02c9656b2f0d69 Haneen Mohammed 2017-10-17 300 _DRM_PRINTK(_once,
INFO, fmt, ##__VA_ARGS__)
02c9656b2f0d69 Haneen Mohammed 2017-10-17 301 #define DRM_NOTE_ONCE(fmt, ...)
\
02c9656b2f0d69 Haneen Mohammed 2017-10-17 302 _DRM_PRINTK(_once,
NOTICE, fmt, ##__VA_ARGS__)
02c9656b2f0d69 Haneen Mohammed 2017-10-17 303 #define DRM_WARN_ONCE(fmt, ...)
\
02c9656b2f0d69 Haneen Mohammed 2017-10-17 304 _DRM_PRINTK(_once,
WARNING, fmt, ##__VA_ARGS__)
02c9656b2f0d69 Haneen Mohammed 2017-10-17 305
02c9656b2f0d69 Haneen Mohammed 2017-10-17 306 /**
02c9656b2f0d69 Haneen Mohammed 2017-10-17 307 * Error output.
02c9656b2f0d69 Haneen Mohammed 2017-10-17 308 *
091756bbb1a961 Haneen Mohammed 2017-10-17 309 * @dev: device pointer
091756bbb1a961 Haneen Mohammed 2017-10-17 310 * @fmt: printf() like format
string.
02c9656b2f0d69 Haneen Mohammed 2017-10-17 311 */
02c9656b2f0d69 Haneen Mohammed 2017-10-17 312 #define DRM_DEV_ERROR(dev, fmt,
...)\
db87086492581c Joe Perches 2018-03-16 @313 drm_dev_printk(dev,
KERN_ERR, "*ERROR* " fmt, ##__VA_ARGS__)
02c9656b2f0d69 Haneen Mohammed 2017-10-17 314 #define DRM_ERROR(fmt, ...)
\
99a954874e7b9f Joe Perches 2018-03-13 315 drm_err(fmt,
##__VA_ARGS__)
02c9656b2f0d69 Haneen Mohammed 2017-10-17 316
:: The code at line 313 was first introduced by commit
:: db87086492581c87f768b7d17d01308153ecffc1 drm: Reduce object size of
DRM_DEV_ uses
:: TO: Joe Perches
:: CC: Daniel Vetter
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: application/gzip
Re: [PATCH v4 02/16] powerpc/pseries: Introduce option to build secure virtual machines
On Tue, 2019-08-20 at 02:13:12 UTC, Thiago Jung Bauermann wrote: > Introduce CONFIG_PPC_SVM to control support for secure guests and include > Ultravisor-related helpers when it is selected > > Signed-off-by: Thiago Jung Bauermann Patch 2-14 & 16 applied to powerpc next, thanks. https://git.kernel.org/powerpc/c/136bc0397ae21dbf63ca02e5775ad353a479cd2f cheers
Re: [PATCH] powerpc/8xx: drop unused self-modifying code alternative to FixupDAR.
On Wed, 2019-08-21 at 20:00:34 UTC, Christophe Leroy wrote: > The code which fixups the DAR on TLB errors for dbcX instructions > has a self-modifying code alternative that has never been used. > > Drop it. > > Signed-off-by: Christophe Leroy Applied to powerpc next, thanks. https://git.kernel.org/powerpc/c/a04565741284f695db4cfe5a3e61940d2259cb8f cheers
Re: [PATCH] powerpc/8xx: set STACK_END_MAGIC earlier on the init_stack
On Wed, 2019-08-21 at 10:20:51 UTC, Christophe Leroy wrote: > Today, the STACK_END_MAGIC is set on init_stack in start_kernel(). > > To avoid a false 'Thread overran stack, or stack corrupted' message > on early Oopses, setup STACK_END_MAGIC as soon as possible. > > Signed-off-by: Christophe Leroy Applied to powerpc next, thanks. https://git.kernel.org/powerpc/c/3bbd2343734e44de92238eea1a5cd3ad32a6baf0 cheers
Re: [PATCH] powerpc/prom: convert PROM_BUG() to standard trap
On Mon, 2019-08-26 at 11:10:23 UTC, Christophe Leroy wrote:
> Prior to commit 1bd98d7fbaf5 ("ppc64: Update BUG handling based on
> ppc32"), BUG() family was using BUG_ILLEGAL_INSTRUCTION which
> was an invalid instruction opcode to trap into program check
> exception.
>
> That commit converted them to using standard trap instructions,
> but prom/prom_init and their PROM_BUG() macro were left over.
> head_64.S and exception-64s.S were left aside as well.
>
> Convert them to using the standard BUG infrastructure.
>
> Signed-off-by: Christophe Leroy
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/63ce271b5e377deaddace4bac6dafb6e79d2bee4
cheers
[PATCH v3 03/11] PCI: designware-ep: Move the function of getting MSI capability forward
Move the function of getting MSI capability to the front of init
function, because the init function of the EP platform driver will use
the return value by the function of getting MSI capability.
Signed-off-by: Xiaowei Bao
Reviewed-by: Andrew Murray
---
v2:
- No change.
v3:
- No change.
drivers/pci/controller/dwc/pcie-designware-ep.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/pci/controller/dwc/pcie-designware-ep.c
b/drivers/pci/controller/dwc/pcie-designware-ep.c
index 55b23ce..c3bc7bd 100644
--- a/drivers/pci/controller/dwc/pcie-designware-ep.c
+++ b/drivers/pci/controller/dwc/pcie-designware-ep.c
@@ -624,6 +624,10 @@ int dw_pcie_ep_init(struct dw_pcie_ep *ep)
if (ret < 0)
epc->max_functions = 1;
+ ep->msi_cap = dw_pcie_find_capability(pci, PCI_CAP_ID_MSI);
+
+ ep->msix_cap = dw_pcie_find_capability(pci, PCI_CAP_ID_MSIX);
+
if (ep->ops->ep_init)
ep->ops->ep_init(ep);
@@ -640,9 +644,6 @@ int dw_pcie_ep_init(struct dw_pcie_ep *ep)
dev_err(dev, "Failed to reserve memory for MSI/MSI-X\n");
return -ENOMEM;
}
- ep->msi_cap = dw_pcie_find_capability(pci, PCI_CAP_ID_MSI);
-
- ep->msix_cap = dw_pcie_find_capability(pci, PCI_CAP_ID_MSIX);
offset = dw_pcie_ep_find_ext_capability(pci, PCI_EXT_CAP_ID_REBAR);
if (offset) {
--
2.9.5
[PATCH v3 09/11] PCI: layerscape: Add EP mode support for ls1088a and ls2088a
Add PCIe EP mode support for ls1088a and ls2088a, there are some
difference between LS1 and LS2 platform, so refactor the code of
the EP driver.
Signed-off-by: Xiaowei Bao
---
v2:
- This is a new patch for supporting the ls1088a and ls2088a platform.
v3:
- Adjust the some struct assignment order in probe function.
drivers/pci/controller/dwc/pci-layerscape-ep.c | 72 +++---
1 file changed, 53 insertions(+), 19 deletions(-)
diff --git a/drivers/pci/controller/dwc/pci-layerscape-ep.c
b/drivers/pci/controller/dwc/pci-layerscape-ep.c
index 5f0cb99..723bbe5 100644
--- a/drivers/pci/controller/dwc/pci-layerscape-ep.c
+++ b/drivers/pci/controller/dwc/pci-layerscape-ep.c
@@ -20,27 +20,29 @@
#define PCIE_DBI2_OFFSET 0x1000 /* DBI2 base address*/
-struct ls_pcie_ep {
- struct dw_pcie *pci;
- struct pci_epc_features *ls_epc;
+#define to_ls_pcie_ep(x) dev_get_drvdata((x)->dev)
+
+struct ls_pcie_ep_drvdata {
+ u32 func_offset;
+ const struct dw_pcie_ep_ops *ops;
+ const struct dw_pcie_ops*dw_pcie_ops;
};
-#define to_ls_pcie_ep(x) dev_get_drvdata((x)->dev)
+struct ls_pcie_ep {
+ struct dw_pcie *pci;
+ struct pci_epc_features *ls_epc;
+ const struct ls_pcie_ep_drvdata *drvdata;
+};
static int ls_pcie_establish_link(struct dw_pcie *pci)
{
return 0;
}
-static const struct dw_pcie_ops ls_pcie_ep_ops = {
+static const struct dw_pcie_ops dw_ls_pcie_ep_ops = {
.start_link = ls_pcie_establish_link,
};
-static const struct of_device_id ls_pcie_ep_of_match[] = {
- { .compatible = "fsl,ls-pcie-ep",},
- { },
-};
-
static const struct pci_epc_features*
ls_pcie_ep_get_features(struct dw_pcie_ep *ep)
{
@@ -87,10 +89,39 @@ static int ls_pcie_ep_raise_irq(struct dw_pcie_ep *ep, u8
func_no,
}
}
-static const struct dw_pcie_ep_ops pcie_ep_ops = {
+static unsigned int ls_pcie_ep_func_conf_select(struct dw_pcie_ep *ep,
+ u8 func_no)
+{
+ struct dw_pcie *pci = to_dw_pcie_from_ep(ep);
+ struct ls_pcie_ep *pcie = to_ls_pcie_ep(pci);
+
+ WARN_ON(func_no && !pcie->drvdata->func_offset);
+ return pcie->drvdata->func_offset * func_no;
+}
+
+static const struct dw_pcie_ep_ops ls_pcie_ep_ops = {
.ep_init = ls_pcie_ep_init,
.raise_irq = ls_pcie_ep_raise_irq,
.get_features = ls_pcie_ep_get_features,
+ .func_conf_select = ls_pcie_ep_func_conf_select,
+};
+
+static const struct ls_pcie_ep_drvdata ls1_ep_drvdata = {
+ .ops = _pcie_ep_ops,
+ .dw_pcie_ops = _ls_pcie_ep_ops,
+};
+
+static const struct ls_pcie_ep_drvdata ls2_ep_drvdata = {
+ .func_offset = 0x2,
+ .ops = _pcie_ep_ops,
+ .dw_pcie_ops = _ls_pcie_ep_ops,
+};
+
+static const struct of_device_id ls_pcie_ep_of_match[] = {
+ { .compatible = "fsl,ls1046a-pcie-ep", .data = _ep_drvdata },
+ { .compatible = "fsl,ls1088a-pcie-ep", .data = _ep_drvdata },
+ { .compatible = "fsl,ls2088a-pcie-ep", .data = _ep_drvdata },
+ { },
};
static int __init ls_add_pcie_ep(struct ls_pcie_ep *pcie,
@@ -103,7 +134,7 @@ static int __init ls_add_pcie_ep(struct ls_pcie_ep *pcie,
int ret;
ep = >ep;
- ep->ops = _ep_ops;
+ ep->ops = pcie->drvdata->ops;
res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "addr_space");
if (!res)
@@ -142,20 +173,23 @@ static int __init ls_pcie_ep_probe(struct platform_device
*pdev)
if (!ls_epc)
return -ENOMEM;
- dbi_base = platform_get_resource_byname(pdev, IORESOURCE_MEM, "regs");
- pci->dbi_base = devm_pci_remap_cfg_resource(dev, dbi_base);
- if (IS_ERR(pci->dbi_base))
- return PTR_ERR(pci->dbi_base);
+ pcie->drvdata = of_device_get_match_data(dev);
- pci->dbi_base2 = pci->dbi_base + PCIE_DBI2_OFFSET;
pci->dev = dev;
- pci->ops = _pcie_ep_ops;
- pcie->pci = pci;
+ pci->ops = pcie->drvdata->dw_pcie_ops;
ls_epc->bar_fixed_64bit = (1 << BAR_2) | (1 << BAR_4),
+ pcie->pci = pci;
pcie->ls_epc = ls_epc;
+ dbi_base = platform_get_resource_byname(pdev, IORESOURCE_MEM, "regs");
+ pci->dbi_base = devm_pci_remap_cfg_resource(dev, dbi_base);
+ if (IS_ERR(pci->dbi_base))
+ return PTR_ERR(pci->dbi_base);
+
+ pci->dbi_base2 = pci->dbi_base + PCIE_DBI2_OFFSET;
+
platform_set_drvdata(pdev, pcie);
ret = ls_add_pcie_ep(pcie, pdev);
--
2.9.5
[PATCH v3 06/11] PCI: layerscape: Fix some format issue of the code
Fix some format issue of the code in EP driver.
Signed-off-by: Xiaowei Bao
Reviewed-by: Andrew Murray
---
v2:
- No change.
v3:
- No change.
drivers/pci/controller/dwc/pci-layerscape-ep.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/pci/controller/dwc/pci-layerscape-ep.c
b/drivers/pci/controller/dwc/pci-layerscape-ep.c
index ca9aa45..a9c552e 100644
--- a/drivers/pci/controller/dwc/pci-layerscape-ep.c
+++ b/drivers/pci/controller/dwc/pci-layerscape-ep.c
@@ -63,7 +63,7 @@ static void ls_pcie_ep_init(struct dw_pcie_ep *ep)
}
static int ls_pcie_ep_raise_irq(struct dw_pcie_ep *ep, u8 func_no,
- enum pci_epc_irq_type type, u16 interrupt_num)
+ enum pci_epc_irq_type type, u16 interrupt_num)
{
struct dw_pcie *pci = to_dw_pcie_from_ep(ep);
@@ -87,7 +87,7 @@ static const struct dw_pcie_ep_ops pcie_ep_ops = {
};
static int __init ls_add_pcie_ep(struct ls_pcie_ep *pcie,
- struct platform_device *pdev)
+struct platform_device *pdev)
{
struct dw_pcie *pci = pcie->pci;
struct device *dev = pci->dev;
--
2.9.5
[PATCH v3 08/11] PCI: layerscape: Modify the MSIX to the doorbell mode
dw_pcie_ep_raise_msix_irq was never called in the exisitng driver before, because the ls1046a platform don't support the MSIX feature and msix_capable was always set to false. Now that add the ls1088a platform with MSIX support, but the existing dw_pcie_ep_raise_msix_irq doesn't work, so use the doorbell method to support the MSIX feature. Signed-off-by: Xiaowei Bao --- v2: - No change v3: - Modify the commit message make it clearly. drivers/pci/controller/dwc/pci-layerscape-ep.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/pci/controller/dwc/pci-layerscape-ep.c b/drivers/pci/controller/dwc/pci-layerscape-ep.c index 1e07287..5f0cb99 100644 --- a/drivers/pci/controller/dwc/pci-layerscape-ep.c +++ b/drivers/pci/controller/dwc/pci-layerscape-ep.c @@ -79,7 +79,8 @@ static int ls_pcie_ep_raise_irq(struct dw_pcie_ep *ep, u8 func_no, case PCI_EPC_IRQ_MSI: return dw_pcie_ep_raise_msi_irq(ep, func_no, interrupt_num); case PCI_EPC_IRQ_MSIX: - return dw_pcie_ep_raise_msix_irq(ep, func_no, interrupt_num); + return dw_pcie_ep_raise_msix_irq_doorbell(ep, func_no, + interrupt_num); default: dev_err(pci->dev, "UNKNOWN IRQ type\n"); return -EINVAL; -- 2.9.5
[PATCH v3 11/11] misc: pci_endpoint_test: Add LS1088a in pci_device_id table
Add LS1088a in pci_device_id table so that pci-epf-test can be used
for testing PCIe EP in LS1088a.
Signed-off-by: Xiaowei Bao
---
v2:
- No change.
v3:
- No change.
drivers/misc/pci_endpoint_test.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/misc/pci_endpoint_test.c b/drivers/misc/pci_endpoint_test.c
index 6e208a0..d531951 100644
--- a/drivers/misc/pci_endpoint_test.c
+++ b/drivers/misc/pci_endpoint_test.c
@@ -793,6 +793,7 @@ static const struct pci_device_id pci_endpoint_test_tbl[] =
{
{ PCI_DEVICE(PCI_VENDOR_ID_TI, PCI_DEVICE_ID_TI_DRA74x) },
{ PCI_DEVICE(PCI_VENDOR_ID_TI, PCI_DEVICE_ID_TI_DRA72x) },
{ PCI_DEVICE(PCI_VENDOR_ID_FREESCALE, 0x81c0) },
+ { PCI_DEVICE(PCI_VENDOR_ID_FREESCALE, 0x80c0) },
{ PCI_DEVICE_DATA(SYNOPSYS, EDDA, NULL) },
{ PCI_DEVICE(PCI_VENDOR_ID_TI, PCI_DEVICE_ID_TI_AM654),
.driver_data = (kernel_ulong_t)_data
--
2.9.5
[PATCH v3 10/11] arm64: dts: layerscape: Add PCIe EP node for ls1088a
Add PCIe EP node for ls1088a to support EP mode.
Signed-off-by: Xiaowei Bao
---
v2:
- Remove the pf-offset proparty.
v3:
- No change.
arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi | 31 ++
1 file changed, 31 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi
b/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi
index c676d07..da246ab 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi
@@ -483,6 +483,17 @@
status = "disabled";
};
+ pcie_ep@340 {
+ compatible = "fsl,ls1088a-pcie-ep","fsl,ls-pcie-ep";
+ reg = <0x00 0x0340 0x0 0x0010
+ 0x20 0x 0x8 0x>;
+ reg-names = "regs", "addr_space";
+ num-ib-windows = <24>;
+ num-ob-windows = <128>;
+ max-functions = /bits/ 8 <2>;
+ status = "disabled";
+ };
+
pcie@350 {
compatible = "fsl,ls1088a-pcie";
reg = <0x00 0x0350 0x0 0x0010 /* controller
registers */
@@ -508,6 +519,16 @@
status = "disabled";
};
+ pcie_ep@350 {
+ compatible = "fsl,ls1088a-pcie-ep","fsl,ls-pcie-ep";
+ reg = <0x00 0x0350 0x0 0x0010
+ 0x28 0x 0x8 0x>;
+ reg-names = "regs", "addr_space";
+ num-ib-windows = <6>;
+ num-ob-windows = <8>;
+ status = "disabled";
+ };
+
pcie@360 {
compatible = "fsl,ls1088a-pcie";
reg = <0x00 0x0360 0x0 0x0010 /* controller
registers */
@@ -533,6 +554,16 @@
status = "disabled";
};
+ pcie_ep@360 {
+ compatible = "fsl,ls1088a-pcie-ep","fsl,ls-pcie-ep";
+ reg = <0x00 0x0360 0x0 0x0010
+ 0x30 0x 0x8 0x>;
+ reg-names = "regs", "addr_space";
+ num-ib-windows = <6>;
+ num-ob-windows = <8>;
+ status = "disabled";
+ };
+
smmu: iommu@500 {
compatible = "arm,mmu-500";
reg = <0 0x500 0 0x80>;
--
2.9.5
[PATCH v3 05/11] dt-bindings: pci: layerscape-pci: add compatible strings for ls1088a and ls2088a
Add compatible strings for ls1088a and ls2088a. Signed-off-by: Xiaowei Bao --- v2: - No change. v3: - Use one valid combination of compatible strings. Documentation/devicetree/bindings/pci/layerscape-pci.txt | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/pci/layerscape-pci.txt b/Documentation/devicetree/bindings/pci/layerscape-pci.txt index e20ceaa..762ae41 100644 --- a/Documentation/devicetree/bindings/pci/layerscape-pci.txt +++ b/Documentation/devicetree/bindings/pci/layerscape-pci.txt @@ -22,7 +22,9 @@ Required properties: "fsl,ls1043a-pcie" "fsl,ls1012a-pcie" EP mode: - "fsl,ls1046a-pcie-ep", "fsl,ls-pcie-ep" + "fsl,ls1046a-pcie-ep" "fsl,ls-pcie-ep" + "fsl,ls1088a-pcie-ep" "fsl,ls-pcie-ep" + "fsl,ls2088a-pcie-ep" "fsl,ls-pcie-ep" - reg: base addresses and lengths of the PCIe controller register blocks. - interrupts: A list of interrupt outputs of the controller. Must contain an entry for each entry in the interrupt-names property. -- 2.9.5
[PATCH v3 07/11] PCI: layerscape: Modify the way of getting capability with different PEX
The different PCIe controller in one board may be have different
capability of MSI or MSIX, so change the way of getting the MSI
capability, make it more flexible.
Signed-off-by: Xiaowei Bao
---
v2:
- Remove the repeated assignment code.
v3:
- Use ep_func msi_cap and msix_cap to decide the msi_capable and
msix_capable of pci_epc_features struct.
drivers/pci/controller/dwc/pci-layerscape-ep.c | 31 +++---
1 file changed, 23 insertions(+), 8 deletions(-)
diff --git a/drivers/pci/controller/dwc/pci-layerscape-ep.c
b/drivers/pci/controller/dwc/pci-layerscape-ep.c
index a9c552e..1e07287 100644
--- a/drivers/pci/controller/dwc/pci-layerscape-ep.c
+++ b/drivers/pci/controller/dwc/pci-layerscape-ep.c
@@ -22,6 +22,7 @@
struct ls_pcie_ep {
struct dw_pcie *pci;
+ struct pci_epc_features *ls_epc;
};
#define to_ls_pcie_ep(x) dev_get_drvdata((x)->dev)
@@ -40,26 +41,31 @@ static const struct of_device_id ls_pcie_ep_of_match[] = {
{ },
};
-static const struct pci_epc_features ls_pcie_epc_features = {
- .linkup_notifier = false,
- .msi_capable = true,
- .msix_capable = false,
- .bar_fixed_64bit = (1 << BAR_2) | (1 << BAR_4),
-};
-
static const struct pci_epc_features*
ls_pcie_ep_get_features(struct dw_pcie_ep *ep)
{
- return _pcie_epc_features;
+ struct dw_pcie *pci = to_dw_pcie_from_ep(ep);
+ struct ls_pcie_ep *pcie = to_ls_pcie_ep(pci);
+
+ return pcie->ls_epc;
}
static void ls_pcie_ep_init(struct dw_pcie_ep *ep)
{
struct dw_pcie *pci = to_dw_pcie_from_ep(ep);
+ struct ls_pcie_ep *pcie = to_ls_pcie_ep(pci);
+ struct dw_pcie_ep_func *ep_func;
enum pci_barno bar;
+ ep_func = dw_pcie_ep_get_func_from_ep(ep, 0);
+ if (!ep_func)
+ return;
+
for (bar = BAR_0; bar <= BAR_5; bar++)
dw_pcie_ep_reset_bar(pci, bar);
+
+ pcie->ls_epc->msi_capable = ep_func->msi_cap ? true : false;
+ pcie->ls_epc->msix_capable = ep_func->msix_cap ? true : false;
}
static int ls_pcie_ep_raise_irq(struct dw_pcie_ep *ep, u8 func_no,
@@ -119,6 +125,7 @@ static int __init ls_pcie_ep_probe(struct platform_device
*pdev)
struct device *dev = >dev;
struct dw_pcie *pci;
struct ls_pcie_ep *pcie;
+ struct pci_epc_features *ls_epc;
struct resource *dbi_base;
int ret;
@@ -130,6 +137,10 @@ static int __init ls_pcie_ep_probe(struct platform_device
*pdev)
if (!pci)
return -ENOMEM;
+ ls_epc = devm_kzalloc(dev, sizeof(*ls_epc), GFP_KERNEL);
+ if (!ls_epc)
+ return -ENOMEM;
+
dbi_base = platform_get_resource_byname(pdev, IORESOURCE_MEM, "regs");
pci->dbi_base = devm_pci_remap_cfg_resource(dev, dbi_base);
if (IS_ERR(pci->dbi_base))
@@ -140,6 +151,10 @@ static int __init ls_pcie_ep_probe(struct platform_device
*pdev)
pci->ops = _pcie_ep_ops;
pcie->pci = pci;
+ ls_epc->bar_fixed_64bit = (1 << BAR_2) | (1 << BAR_4),
+
+ pcie->ls_epc = ls_epc;
+
platform_set_drvdata(pdev, pcie);
ret = ls_add_pcie_ep(pcie, pdev);
--
2.9.5
[PATCH v3 04/11] PCI: designware-ep: Modify MSI and MSIX CAP way of finding
Each PF of EP device should have it's own MSI or MSIX capabitily
struct, so create a dw_pcie_ep_func struct and remover the msi_cap
and msix_cap to this struce, and manage the PFs with a list.
Signed-off-by: Xiaowei Bao
---
v1:
- This is a new patch, to fix the issue of MSI and MSIX CAP way of
finding.
v2:
- No change.
v3:
- No change.
drivers/pci/controller/dwc/pcie-designware-ep.c | 135 +---
drivers/pci/controller/dwc/pcie-designware.h| 18 +++-
2 files changed, 134 insertions(+), 19 deletions(-)
diff --git a/drivers/pci/controller/dwc/pcie-designware-ep.c
b/drivers/pci/controller/dwc/pcie-designware-ep.c
index c3bc7bd..144eb12 100644
--- a/drivers/pci/controller/dwc/pcie-designware-ep.c
+++ b/drivers/pci/controller/dwc/pcie-designware-ep.c
@@ -19,6 +19,19 @@ void dw_pcie_ep_linkup(struct dw_pcie_ep *ep)
pci_epc_linkup(epc);
}
+struct dw_pcie_ep_func *
+dw_pcie_ep_get_func_from_ep(struct dw_pcie_ep *ep, u8 func_no)
+{
+ struct dw_pcie_ep_func *ep_func;
+
+ list_for_each_entry(ep_func, >func_list, list) {
+ if (ep_func->func_no == func_no)
+ return ep_func;
+ }
+
+ return NULL;
+}
+
static unsigned int dw_pcie_ep_func_select(struct dw_pcie_ep *ep, u8 func_no)
{
unsigned int func_offset = 0;
@@ -59,6 +72,47 @@ void dw_pcie_ep_reset_bar(struct dw_pcie *pci, enum
pci_barno bar)
__dw_pcie_ep_reset_bar(pci, func_no, bar, 0);
}
+static u8 __dw_pcie_ep_find_next_cap(struct dw_pcie_ep *ep, u8 func_no,
+ u8 cap_ptr, u8 cap)
+{
+ struct dw_pcie *pci = to_dw_pcie_from_ep(ep);
+ unsigned int func_offset = 0;
+ u8 cap_id, next_cap_ptr;
+ u16 reg;
+
+ if (!cap_ptr)
+ return 0;
+
+ func_offset = dw_pcie_ep_func_select(ep, func_no);
+
+ reg = dw_pcie_readw_dbi(pci, func_offset + cap_ptr);
+ cap_id = (reg & 0x00ff);
+
+ if (cap_id > PCI_CAP_ID_MAX)
+ return 0;
+
+ if (cap_id == cap)
+ return cap_ptr;
+
+ next_cap_ptr = (reg & 0xff00) >> 8;
+ return __dw_pcie_ep_find_next_cap(ep, func_no, next_cap_ptr, cap);
+}
+
+static u8 dw_pcie_ep_find_capability(struct dw_pcie_ep *ep, u8 func_no, u8 cap)
+{
+ struct dw_pcie *pci = to_dw_pcie_from_ep(ep);
+ unsigned int func_offset = 0;
+ u8 next_cap_ptr;
+ u16 reg;
+
+ func_offset = dw_pcie_ep_func_select(ep, func_no);
+
+ reg = dw_pcie_readw_dbi(pci, func_offset + PCI_CAPABILITY_LIST);
+ next_cap_ptr = (reg & 0x00ff);
+
+ return __dw_pcie_ep_find_next_cap(ep, func_no, next_cap_ptr, cap);
+}
+
static int dw_pcie_ep_write_header(struct pci_epc *epc, u8 func_no,
struct pci_epf_header *hdr)
{
@@ -246,13 +300,18 @@ static int dw_pcie_ep_get_msi(struct pci_epc *epc, u8
func_no)
struct dw_pcie *pci = to_dw_pcie_from_ep(ep);
u32 val, reg;
unsigned int func_offset = 0;
+ struct dw_pcie_ep_func *ep_func;
- if (!ep->msi_cap)
+ ep_func = dw_pcie_ep_get_func_from_ep(ep, func_no);
+ if (!ep_func)
+ return -EINVAL;
+
+ if (!ep_func->msi_cap)
return -EINVAL;
func_offset = dw_pcie_ep_func_select(ep, func_no);
- reg = ep->msi_cap + func_offset + PCI_MSI_FLAGS;
+ reg = ep_func->msi_cap + func_offset + PCI_MSI_FLAGS;
val = dw_pcie_readw_dbi(pci, reg);
if (!(val & PCI_MSI_FLAGS_ENABLE))
return -EINVAL;
@@ -268,13 +327,18 @@ static int dw_pcie_ep_set_msi(struct pci_epc *epc, u8
func_no, u8 interrupts)
struct dw_pcie *pci = to_dw_pcie_from_ep(ep);
u32 val, reg;
unsigned int func_offset = 0;
+ struct dw_pcie_ep_func *ep_func;
+
+ ep_func = dw_pcie_ep_get_func_from_ep(ep, func_no);
+ if (!ep_func)
+ return -EINVAL;
- if (!ep->msi_cap)
+ if (!ep_func->msi_cap)
return -EINVAL;
func_offset = dw_pcie_ep_func_select(ep, func_no);
- reg = ep->msi_cap + func_offset + PCI_MSI_FLAGS;
+ reg = ep_func->msi_cap + func_offset + PCI_MSI_FLAGS;
val = dw_pcie_readw_dbi(pci, reg);
val &= ~PCI_MSI_FLAGS_QMASK;
val |= (interrupts << 1) & PCI_MSI_FLAGS_QMASK;
@@ -291,13 +355,18 @@ static int dw_pcie_ep_get_msix(struct pci_epc *epc, u8
func_no)
struct dw_pcie *pci = to_dw_pcie_from_ep(ep);
u32 val, reg;
unsigned int func_offset = 0;
+ struct dw_pcie_ep_func *ep_func;
+
+ ep_func = dw_pcie_ep_get_func_from_ep(ep, func_no);
+ if (!ep_func)
+ return -EINVAL;
- if (!ep->msix_cap)
+ if (!ep_func->msix_cap)
return -EINVAL;
func_offset = dw_pcie_ep_func_select(ep, func_no);
- reg = ep->msix_cap + func_offset + PCI_MSIX_FLAGS;
+ reg = ep_func->msix_cap + func_offset + PCI_MSIX_FLAGS;
val =
[PATCH v3 02/11] PCI: designware-ep: Add the doorbell mode of MSI-X in EP mode
Add the doorbell mode of MSI-X in EP mode.
Signed-off-by: Xiaowei Bao
Reviewed-by: Andrew Murray
---
v2:
- Remove the macro of no used.
v3:
- No change.
drivers/pci/controller/dwc/pcie-designware-ep.c | 14 ++
drivers/pci/controller/dwc/pcie-designware.h| 12
2 files changed, 26 insertions(+)
diff --git a/drivers/pci/controller/dwc/pcie-designware-ep.c
b/drivers/pci/controller/dwc/pcie-designware-ep.c
index eb851c2..55b23ce 100644
--- a/drivers/pci/controller/dwc/pcie-designware-ep.c
+++ b/drivers/pci/controller/dwc/pcie-designware-ep.c
@@ -449,6 +449,20 @@ int dw_pcie_ep_raise_msi_irq(struct dw_pcie_ep *ep, u8
func_no,
return 0;
}
+int dw_pcie_ep_raise_msix_irq_doorbell(struct dw_pcie_ep *ep, u8 func_no,
+ u16 interrupt_num)
+{
+ struct dw_pcie *pci = to_dw_pcie_from_ep(ep);
+ u32 msg_data;
+
+ msg_data = (func_no << PCIE_MSIX_DOORBELL_PF_SHIFT) |
+ (interrupt_num - 1);
+
+ dw_pcie_writel_dbi(pci, PCIE_MSIX_DOORBELL, msg_data);
+
+ return 0;
+}
+
int dw_pcie_ep_raise_msix_irq(struct dw_pcie_ep *ep, u8 func_no,
u16 interrupt_num)
{
diff --git a/drivers/pci/controller/dwc/pcie-designware.h
b/drivers/pci/controller/dwc/pcie-designware.h
index 6aca0bb..56789be 100644
--- a/drivers/pci/controller/dwc/pcie-designware.h
+++ b/drivers/pci/controller/dwc/pcie-designware.h
@@ -88,6 +88,9 @@
#define PCIE_MISC_CONTROL_1_OFF0x8BC
#define PCIE_DBI_RO_WR_EN BIT(0)
+#define PCIE_MSIX_DOORBELL 0x948
+#define PCIE_MSIX_DOORBELL_PF_SHIFT24
+
#define PCIE_PL_CHK_REG_CONTROL_STATUS 0xB20
#define PCIE_PL_CHK_REG_CHK_REG_START BIT(0)
#define PCIE_PL_CHK_REG_CHK_REG_CONTINUOUS BIT(1)
@@ -419,6 +422,8 @@ int dw_pcie_ep_raise_msi_irq(struct dw_pcie_ep *ep, u8
func_no,
u8 interrupt_num);
int dw_pcie_ep_raise_msix_irq(struct dw_pcie_ep *ep, u8 func_no,
u16 interrupt_num);
+int dw_pcie_ep_raise_msix_irq_doorbell(struct dw_pcie_ep *ep, u8 func_no,
+ u16 interrupt_num);
void dw_pcie_ep_reset_bar(struct dw_pcie *pci, enum pci_barno bar);
#else
static inline void dw_pcie_ep_linkup(struct dw_pcie_ep *ep)
@@ -451,6 +456,13 @@ static inline int dw_pcie_ep_raise_msix_irq(struct
dw_pcie_ep *ep, u8 func_no,
return 0;
}
+static inline int dw_pcie_ep_raise_msix_irq_doorbell(struct dw_pcie_ep *ep,
+u8 func_no,
+u16 interrupt_num)
+{
+ return 0;
+}
+
static inline void dw_pcie_ep_reset_bar(struct dw_pcie *pci, enum pci_barno
bar)
{
}
--
2.9.5
[PATCH v3 00/11] *** SUBJECT HERE ***
*** BLURB HERE *** Xiaowei Bao (11): PCI: designware-ep: Add multiple PFs support for DWC PCI: designware-ep: Add the doorbell mode of MSI-X in EP mode PCI: designware-ep: Move the function of getting MSI capability forward PCI: designware-ep: Modify MSI and MSIX CAP way of finding dt-bindings: pci: layerscape-pci: add compatible strings for ls1088a and ls2088a PCI: layerscape: Fix some format issue of the code PCI: layerscape: Modify the way of getting capability with different PEX PCI: layerscape: Modify the MSIX to the doorbell mode PCI: layerscape: Add EP mode support for ls1088a and ls2088a arm64: dts: layerscape: Add PCIe EP node for ls1088a misc: pci_endpoint_test: Add LS1088a in pci_device_id table .../devicetree/bindings/pci/layerscape-pci.txt | 4 +- arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi | 31 +++ drivers/misc/pci_endpoint_test.c | 1 + drivers/pci/controller/dwc/pci-layerscape-ep.c | 100 ++-- drivers/pci/controller/dwc/pcie-designware-ep.c| 255 + drivers/pci/controller/dwc/pcie-designware.c | 59 +++-- drivers/pci/controller/dwc/pcie-designware.h | 48 +++- 7 files changed, 404 insertions(+), 94 deletions(-) -- 2.9.5
[PATCH v3 01/11] PCI: designware-ep: Add multiple PFs support for DWC
Add multiple PFs support for DWC, different PF have different config space
we use pf-offset property which get from the DTS to access the different pF
config space.
Signed-off-by: Xiaowei Bao
---
v2:
- Remove duplicate redundant code.
- Reimplement the PF config space access way.
v3:
- Integrate duplicate code for func_select.
- Move PCIE_ATU_FUNC_NUM(pf) (pf << 20) to ((pf) << 20).
- Add the comments for func_conf_select function.
drivers/pci/controller/dwc/pcie-designware-ep.c | 123
drivers/pci/controller/dwc/pcie-designware.c| 59
drivers/pci/controller/dwc/pcie-designware.h| 18 +++-
3 files changed, 142 insertions(+), 58 deletions(-)
diff --git a/drivers/pci/controller/dwc/pcie-designware-ep.c
b/drivers/pci/controller/dwc/pcie-designware-ep.c
index 65f4792..eb851c2 100644
--- a/drivers/pci/controller/dwc/pcie-designware-ep.c
+++ b/drivers/pci/controller/dwc/pcie-designware-ep.c
@@ -19,12 +19,26 @@ void dw_pcie_ep_linkup(struct dw_pcie_ep *ep)
pci_epc_linkup(epc);
}
-static void __dw_pcie_ep_reset_bar(struct dw_pcie *pci, enum pci_barno bar,
- int flags)
+static unsigned int dw_pcie_ep_func_select(struct dw_pcie_ep *ep, u8 func_no)
+{
+ unsigned int func_offset = 0;
+
+ if (ep->ops->func_conf_select)
+ func_offset = ep->ops->func_conf_select(ep, func_no);
+
+ return func_offset;
+}
+
+static void __dw_pcie_ep_reset_bar(struct dw_pcie *pci, u8 func_no,
+ enum pci_barno bar, int flags)
{
u32 reg;
+ unsigned int func_offset = 0;
+ struct dw_pcie_ep *ep = >ep;
+
+ func_offset = dw_pcie_ep_func_select(ep, func_no);
- reg = PCI_BASE_ADDRESS_0 + (4 * bar);
+ reg = func_offset + PCI_BASE_ADDRESS_0 + (4 * bar);
dw_pcie_dbi_ro_wr_en(pci);
dw_pcie_writel_dbi2(pci, reg, 0x0);
dw_pcie_writel_dbi(pci, reg, 0x0);
@@ -37,7 +51,12 @@ static void __dw_pcie_ep_reset_bar(struct dw_pcie *pci, enum
pci_barno bar,
void dw_pcie_ep_reset_bar(struct dw_pcie *pci, enum pci_barno bar)
{
- __dw_pcie_ep_reset_bar(pci, bar, 0);
+ u8 func_no, funcs;
+
+ funcs = pci->ep.epc->max_functions;
+
+ for (func_no = 0; func_no < funcs; func_no++)
+ __dw_pcie_ep_reset_bar(pci, func_no, bar, 0);
}
static int dw_pcie_ep_write_header(struct pci_epc *epc, u8 func_no,
@@ -45,28 +64,31 @@ static int dw_pcie_ep_write_header(struct pci_epc *epc, u8
func_no,
{
struct dw_pcie_ep *ep = epc_get_drvdata(epc);
struct dw_pcie *pci = to_dw_pcie_from_ep(ep);
+ unsigned int func_offset = 0;
+
+ func_offset = dw_pcie_ep_func_select(ep, func_no);
dw_pcie_dbi_ro_wr_en(pci);
- dw_pcie_writew_dbi(pci, PCI_VENDOR_ID, hdr->vendorid);
- dw_pcie_writew_dbi(pci, PCI_DEVICE_ID, hdr->deviceid);
- dw_pcie_writeb_dbi(pci, PCI_REVISION_ID, hdr->revid);
- dw_pcie_writeb_dbi(pci, PCI_CLASS_PROG, hdr->progif_code);
- dw_pcie_writew_dbi(pci, PCI_CLASS_DEVICE,
+ dw_pcie_writew_dbi(pci, func_offset + PCI_VENDOR_ID, hdr->vendorid);
+ dw_pcie_writew_dbi(pci, func_offset + PCI_DEVICE_ID, hdr->deviceid);
+ dw_pcie_writeb_dbi(pci, func_offset + PCI_REVISION_ID, hdr->revid);
+ dw_pcie_writeb_dbi(pci, func_offset + PCI_CLASS_PROG, hdr->progif_code);
+ dw_pcie_writew_dbi(pci, func_offset + PCI_CLASS_DEVICE,
hdr->subclass_code | hdr->baseclass_code << 8);
- dw_pcie_writeb_dbi(pci, PCI_CACHE_LINE_SIZE,
+ dw_pcie_writeb_dbi(pci, func_offset + PCI_CACHE_LINE_SIZE,
hdr->cache_line_size);
- dw_pcie_writew_dbi(pci, PCI_SUBSYSTEM_VENDOR_ID,
+ dw_pcie_writew_dbi(pci, func_offset + PCI_SUBSYSTEM_VENDOR_ID,
hdr->subsys_vendor_id);
- dw_pcie_writew_dbi(pci, PCI_SUBSYSTEM_ID, hdr->subsys_id);
- dw_pcie_writeb_dbi(pci, PCI_INTERRUPT_PIN,
+ dw_pcie_writew_dbi(pci, func_offset + PCI_SUBSYSTEM_ID, hdr->subsys_id);
+ dw_pcie_writeb_dbi(pci, func_offset + PCI_INTERRUPT_PIN,
hdr->interrupt_pin);
dw_pcie_dbi_ro_wr_dis(pci);
return 0;
}
-static int dw_pcie_ep_inbound_atu(struct dw_pcie_ep *ep, enum pci_barno bar,
- dma_addr_t cpu_addr,
+static int dw_pcie_ep_inbound_atu(struct dw_pcie_ep *ep, u8 func_no,
+ enum pci_barno bar, dma_addr_t cpu_addr,
enum dw_pcie_as_type as_type)
{
int ret;
@@ -79,7 +101,7 @@ static int dw_pcie_ep_inbound_atu(struct dw_pcie_ep *ep,
enum pci_barno bar,
return -EINVAL;
}
- ret = dw_pcie_prog_inbound_atu(pci, free_win, bar, cpu_addr,
+ ret = dw_pcie_prog_inbound_atu(pci, func_no, free_win, bar, cpu_addr,
as_type);
if (ret < 0) {
Re: kernel panic: stack is corrupted in lock_release (2)
On Sun, Sep 1, 2019 at 4:27 PM syzbot wrote: > > Hello, > > syzbot found the following crash on: > > HEAD commit:dd7078f0 enetc: Add missing call to 'pci_free_irq_vectors(.. > git tree: net > console output: https://syzkaller.appspot.com/x/log.txt?x=115fe0fa60 > kernel config: https://syzkaller.appspot.com/x/.config?x=2a6a2b9826fdadf9 > dashboard link: https://syzkaller.appspot.com/bug?extid=97deee97cf14574b96d0 > compiler: gcc (GCC) 9.0.0 20181231 (experimental) > syz repro: https://syzkaller.appspot.com/x/repro.syz?x=11f7c2fe60 Stack corruption + bpf maps in repro triggers some bells. +bpf mailing list. > IMPORTANT: if you fix the bug, please add the following tag to the commit: > Reported-by: syzbot+97deee97cf14574b9...@syzkaller.appspotmail.com > > Kernel panic - not syncing: stack-protector: Kernel stack is corrupted in: > lock_release+0x866/0x960 kernel/locking/lockdep.c:4435 > CPU: 0 PID: 9965 Comm: syz-executor.0 Not tainted 5.3.0-rc6+ #182 > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS > Google 01/01/2011 > Call Trace: > Kernel Offset: disabled > Rebooting in 86400 seconds.. > > > --- > This bug is generated by a bot. It may contain errors. > See https://goo.gl/tpsmEJ for more information about syzbot. > syzbot engineers can be reached at syzkal...@googlegroups.com. > > syzbot will keep track of this bug report. See: > https://goo.gl/tpsmEJ#status for how to communicate with syzbot. > syzbot can test patches for this bug, for details see: > https://goo.gl/tpsmEJ#testing-patches > > -- > You received this message because you are subscribed to the Google Groups > "syzkaller-bugs" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to syzkaller-bugs+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/syzkaller-bugs/88cdb2059186312f%40google.com.
Re: kernel panic: stack is corrupted in __lock_acquire (4)
On Sun, Sep 1, 2019 at 3:48 PM syzbot wrote: > > syzbot has found a reproducer for the following crash on: > > HEAD commit:38320f69 Merge branch 'Minor-cleanup-in-devlink' > git tree: net-next > console output: https://syzkaller.appspot.com/x/log.txt?x=13d7435660 > kernel config: https://syzkaller.appspot.com/x/.config?x=1bbf70b6300045af > dashboard link: https://syzkaller.appspot.com/bug?extid=83979935eb6304f8cd46 > compiler: gcc (GCC) 9.0.0 20181231 (experimental) > syz repro: https://syzkaller.appspot.com/x/repro.syz?x=1008b23260 Stack corruption + bpf maps in repro triggers some bells. +bpf mailing list. > IMPORTANT: if you fix the bug, please add the following tag to the commit: > Reported-by: syzbot+83979935eb6304f8c...@syzkaller.appspotmail.com > > Kernel panic - not syncing: stack-protector: Kernel stack is corrupted in: > __lock_acquire+0x36fa/0x4c30 kernel/locking/lockdep.c:3907 > CPU: 0 PID: 8662 Comm: syz-executor.4 Not tainted 5.3.0-rc6+ #153 > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS > Google 01/01/2011 > Call Trace: > Kernel Offset: disabled > Rebooting in 86400 seconds.. > > -- > You received this message because you are subscribed to the Google Groups > "syzkaller-bugs" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to syzkaller-bugs+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/syzkaller-bugs/0ec274059185a63e%40google.com.
[PATCH] phy: tegra: xusb: remove unused variable
The local variable @priv is set but not used, can be removed Signed-off-by: Chunfeng Yun --- drivers/phy/tegra/xusb-tegra210.c | 3 --- 1 file changed, 3 deletions(-) diff --git a/drivers/phy/tegra/xusb-tegra210.c b/drivers/phy/tegra/xusb-tegra210.c index 0c0df6897a3b..bc71c897298a 100644 --- a/drivers/phy/tegra/xusb-tegra210.c +++ b/drivers/phy/tegra/xusb-tegra210.c @@ -1225,13 +1225,10 @@ static int tegra210_hsic_phy_power_on(struct phy *phy) struct tegra_xusb_hsic_lane *hsic = to_hsic_lane(lane); struct tegra_xusb_hsic_pad *pad = to_hsic_pad(lane->pad); struct tegra_xusb_padctl *padctl = lane->pad->padctl; - struct tegra210_xusb_padctl *priv; unsigned int index = lane->index; u32 value; int err; - priv = to_tegra210_xusb_padctl(padctl); - err = regulator_enable(pad->supply); if (err) return err; -- 2.23.0
RE: [PATCH net-next] r8152: fix accessing skb after napi_gro_receive
Eric Dumazet [mailto:eric.duma...@gmail.com]
> Sent: Friday, August 30, 2019 12:32 AM
> To: Hayes Wang; net...@vger.kernel.org
> Cc: nic_swsd; linux-kernel@vger.kernel.org
> Subject: Re: [PATCH net-next] r8152: fix accessing skb after napi_gro_receive
>
> On 8/19/19 5:15 AM, Hayes Wang wrote:
> > Fix accessing skb after napi_gro_receive which is caused by
> > commit 47922fcde536 ("r8152: support skb_add_rx_frag").
> >
> > Fixes: 47922fcde536 ("r8152: support skb_add_rx_frag")
> > Signed-off-by: Hayes Wang
> > ---
>
> It is customary to add a tag to credit the reporter...
>
> Something like :
>
> Reported-by:
>
> Thanks.
Sorry. It's my mistake.
I would note that next time.
Best Regards,
Hayes
Re: [PATCH v2 1/2] powerpc: Add PowerPC Capabilities ELF note
On Thu, 2019-08-29 at 15:50:20 UTC, "Maxiwell S. Garcia" wrote: > From: Claudio Carvalho > > Add the PowerPC name and the PPC_ELFNOTE_CAPABILITIES type in the > kernel binary ELF note. This type is a bitmap that can be used to > advertise kernel capabilities to userland. > > This patch also defines PPCCAP_ULTRAVISOR_BIT as being the bit zero. > > Suggested-by: Paul Mackerras > Signed-off-by: Claudio Carvalho > [ maxiwell: Define the 'PowerPC' type in the elfnote.h ] > Signed-off-by: Maxiwell S. Garcia Series applied to powerpc topic/ppc-kvm, thanks. https://git.kernel.org/powerpc/c/70ed86f4de5bd74dd2d884dcd2f3275c4cfe665f cheers
Re: [PATCH V1 3/6] USB: serial: f81232: Add generator for F81534A
Hi Johan,
Johan Hovold 於 2019/8/28 下午 11:02 寫道:
On Thu, Jun 06, 2019 at 10:54:13AM +0800, Ji-Ze Hong (Peter Hong) wrote:
The Fintek F81534A series is contains 1 HUB / 1 GPIO device / n UARTs,
but the UART is default disable and need enabled by GPIO device(2c42/16F8).
When F81534A plug to host, we can only see 1 HUB & 1 GPIO device, add
GPIO device USB interface to device_list and trigger generate worker,
f81534a_generate_worker to run f81534a_ctrl_generate_ports().
The operation in f81534a_ctrl_generate_ports() as following:
1: Write 0x8fff to F81534A_CMD_ENABLE_PORT register for enable all
UART device.
2: Read port existence & current status from F81534A_CMD_PORT_STATUS
register. the higher 16bit will indicate the UART existence. If the
UART is existence, we'll check it GPIO mode as long as not default
value (default is all input mode).
3: 1 GPIO device will check with max 15s and check next GPIO device when
timeout. (F81534A_CTRL_RETRY * F81534A_CTRL_TIMER)
Signed-off-by: Ji-Ze Hong (Peter Hong)
This is all looks crazy... Please better describe how the device works,
and you want to implement support.
I'll try to refactor more simply for first add into kernel.
---
drivers/usb/serial/f81232.c | 356 +++-
1 file changed, 355 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/serial/f81232.c b/drivers/usb/serial/f81232.c
index 75dfc0b9ef30..e9470fb0d691 100644
--- a/drivers/usb/serial/f81232.c
+++ b/drivers/usb/serial/f81232.c
@@ -41,6 +41,12 @@ static const struct usb_device_id id_table[] = {
};
MODULE_DEVICE_TABLE(usb, id_table);
+static const struct usb_device_id f81534a_ctrl_id_table[] = {
+ { USB_DEVICE(0x2c42, 0x16f8) }, /* Global control device */
+ { } /* Terminating entry */
+};
+MODULE_DEVICE_TABLE(usb, f81534a_ctrl_id_table);
You can only have one MODULE_DEVICE_TABLE()...
I had a question about this. In this file, we'll need support 3 sets of
id f81232(1)/f81534a(9)/f81534a_ctrl(1). So I will refactor the code
about id section to the below due to the id table will use more than
once:
===
#define F81232_ID \
{ USB_DEVICE(0x1934, 0x0706) } /* 1 port UART device */
#define F81534A_SERIES_ID \
{ USB_DEVICE(0x2c42, 0x1602) }, /* In-Box 2 port UART device */ \
{ USB_DEVICE(0x2c42, 0x1604) }, /* In-Box 4 port UART device */ \
{ USB_DEVICE(0x2c42, 0x1605) }, /* In-Box 8 port UART device */ \
{ USB_DEVICE(0x2c42, 0x1606) }, /* In-Box 12 port UART device */ \
{ USB_DEVICE(0x2c42, 0x1608) }, /* Non-Flash type */ \
{ USB_DEVICE(0x2c42, 0x1632) }, /* 2 port UART device */ \
{ USB_DEVICE(0x2c42, 0x1634) }, /* 4 port UART device */ \
{ USB_DEVICE(0x2c42, 0x1635) }, /* 8 port UART device */ \
{ USB_DEVICE(0x2c42, 0x1636) } /* 12 port UART device */
#define F81534A_CTRL_ID \
{ USB_DEVICE(0x2c42, 0x16f8) } /* Global control device */
static const struct usb_device_id id_table[] = {
F81232_ID,
{ } /* Terminating entry */
};
static const struct usb_device_id f81534a_id_table[] = {
F81534A_SERIES_ID,
{ } /* Terminating entry */
};
static const struct usb_device_id f81534a_ctrl_id_table[] = {
F81534A_CTRL_ID,
{ } /* Terminating entry */
};
static const struct usb_device_id all_serial_id_table[] = {
F81232_ID,
F81534A_SERIES_ID,
{ } /* Terminating entry */
};
MODULE_DEVICE_TABLE(usb, all_serial_id_table);
===
but the checkpatch.pl give me the warning below:
ERROR: Macros with complex values should be enclosed in parentheses
#42: FILE: f81232.c:28:
+#define F81534A_SERIES_ID \
+ { USB_DEVICE(0x2c42, 0x1602) }, /* In-Box 2 port UART device */ \
+ { USB_DEVICE(0x2c42, 0x1604) }, /* In-Box 4 port UART device */ \
+ { USB_DEVICE(0x2c42, 0x1605) }, /* In-Box 8 port UART device */ \
+ { USB_DEVICE(0x2c42, 0x1606) }, /* In-Box 12 port UART device */ \
+ { USB_DEVICE(0x2c42, 0x1608) }, /* Non-Flash type */ \
+ { USB_DEVICE(0x2c42, 0x1632) }, /* 2 port UART device */ \
+ { USB_DEVICE(0x2c42, 0x1634) }, /* 4 port UART device */ \
+ { USB_DEVICE(0x2c42, 0x1635) }, /* 8 port UART device */ \
+ { USB_DEVICE(0x2c42, 0x1636) } /* 12 port UART device */
Is any suggestion ?
Thanks
--
With Best Regards,
Peter Hong
Re: [PATCH v6 6/6] powerpc/perf: split callchain.c by bitness
Michal Suchánek writes: > On Fri, 30 Aug 2019 20:57:57 +0200 > Michal Suchanek wrote: > >> Building callchain.c with !COMPAT proved quite ugly with all the >> defines. Splitting out the 32bit and 64bit parts looks better. >> > > BTW the powerpc callchain.c does not match any of the patterns of PERF > CORE in MAINTAINERS (unlike callchain implementation on other > platforms). Is that intentional? No. cheers
[PATCH net-next] net/ncsi: support unaligned payload size in NC-SI cmd handler
Update NC-SI command handler (both standard and OEM) to take into
account of payload paddings in allocating skb (in case of payload
size is not 32-bit aligned).
The checksum field follows payload field, without taking payload
padding into account can cause checksum being truncated, leading to
dropped packets.
Signed-off-by: Ben Wei
---
net/ncsi/ncsi-cmd.c | 19 ++-
1 file changed, 14 insertions(+), 5 deletions(-)
diff --git a/net/ncsi/ncsi-cmd.c b/net/ncsi/ncsi-cmd.c
index 0187e65176c0..42636ed3cf3a 100644
--- a/net/ncsi/ncsi-cmd.c
+++ b/net/ncsi/ncsi-cmd.c
@@ -213,17 +213,22 @@ static int ncsi_cmd_handler_oem(struct sk_buff *skb,
{
struct ncsi_cmd_oem_pkt *cmd;
unsigned int len;
+ /* NC-SI spec requires payload to be padded with 0
+* to 32-bit boundary before the checksum field.
+* Ensure the padding bytes are accounted for in
+* skb allocation
+*/
+ unsigned short payload = ALIGN(nca->payload, 4);
len = sizeof(struct ncsi_cmd_pkt_hdr) + 4;
- if (nca->payload < 26)
+ if (payload < 26)
len += 26;
else
- len += nca->payload;
+ len += payload;
cmd = skb_put_zero(skb, len);
memcpy(>mfr_id, nca->data, nca->payload);
ncsi_cmd_build_header(>cmd.common, nca);
-
return 0;
}
@@ -272,6 +277,7 @@ static struct ncsi_request *ncsi_alloc_command(struct
ncsi_cmd_arg *nca)
struct net_device *dev = nd->dev;
int hlen = LL_RESERVED_SPACE(dev);
int tlen = dev->needed_tailroom;
+ int payload;
int len = hlen + tlen;
struct sk_buff *skb;
struct ncsi_request *nr;
@@ -281,14 +287,17 @@ static struct ncsi_request *ncsi_alloc_command(struct
ncsi_cmd_arg *nca)
return NULL;
/* NCSI command packet has 16-bytes header, payload, 4 bytes checksum.
+* Payload needs padding so that the checksum field follwoing payload is
+* aligned to 32bit boundary.
* The packet needs padding if its payload is less than 26 bytes to
* meet 64 bytes minimal ethernet frame length.
*/
len += sizeof(struct ncsi_cmd_pkt_hdr) + 4;
- if (nca->payload < 26)
+ payload = ALIGN(nca->payload, 4);
+ if (payload < 26)
len += 26;
else
- len += nca->payload;
+ len += payload;
/* Allocate skb */
skb = alloc_skb(len, GFP_ATOMIC);
--
2.17.1
Re: [PATCH v3] arch/microblaze: add support for get_user() of size 8 bytes
On 9/1/19 12:10 PM, Randy Dunlap wrote:
> On 9/1/19 10:31 AM, Linus Torvalds wrote:
>> On Sun, Sep 1, 2019 at 10:07 AM Linus Torvalds
>> wrote:
>>>
>>> I guess I'll apply it. I'm not sure why you _care_ about microblaze, but ...
>
> It was just a response to the 0day build bot reporting build errors.
>
>
>> Ugh. As I was going to apply it, my code cleanliness conscience struck.
>>
>> I can't deal with that unnecessary duplication of code. Does something
>> like the attached patch work instead?
>>
>> Totally untested, but looks much cleaner.
>
> Hm, I'm getting one (confusing) build error, in block/scsi_ioctl.c:
>
> CC block/scsi_ioctl.o
> In file included from ../include/linux/uaccess.h:11,
> from ../include/linux/highmem.h:9,
> from ../include/linux/pagemap.h:11,
> from ../include/linux/blkdev.h:16,
> from ../block/scsi_ioctl.c:9:
> ../block/scsi_ioctl.c: In function 'sg_scsi_ioctl':
> ../arch/microblaze/include/asm/uaccess.h:167:25: error: invalid initializer
> typeof(ptr) __gu_ptr = (ptr); \
> ^
> ../block/scsi_ioctl.c:426:6: note: in expansion of macro 'get_user'
> if (get_user(opcode, sic->data))
> ^~~~
if (get_user(opcode, sic->data))
return -EFAULT;
where sic->data is unsigned char data[0] here:
typedef struct scsi_ioctl_command {
unsigned int inlen;
unsigned int outlen;
unsigned char data[0];
} Scsi_Ioctl_Command;
On x86_64 this builds as a call to get_user_1().
(cannot do objdump on arch/microblaze/, unknown arch/machine)
I guess we need a way to coerce that to call get_user_1(),
such as a typecast. This _seems_ to work (i.e., call get_user_1()):
if (get_user(opcode, (unsigned char *)(sic->data)))
return -EFAULT;
??
--
~Randy
Re: [PATCH] ocfs2: remove deadcode on variable tmp_oh check
On 19/8/30 19:16, Colin King wrote:
> From: Colin Ian King
>
> At the end of cfs2_inode_lock_tracker tmp_oh is true because an
s/cfs2_inode_lock_tracker/ocfs2_inode_lock_tracker/
BTW, could you please correct the following description of this
function as well?
"return == -1 if this lock attempt will cause an upgrade which is forbidden."
In fact, it returns -EINVAL.
Thanks,
Joseph
> earlier check on tmp_oh being false returns out of the function.
> Since tmp_oh is true, the function will always return 1 so remove
> the redundant check and return of 0.
>
> Addresses-Coverity: ("Logically dead code")
> Signed-off-by: Colin Ian King
> ---
> fs/ocfs2/dlmglue.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/fs/ocfs2/dlmglue.c b/fs/ocfs2/dlmglue.c
> index ad594fef2ab0..ff0cf851c9e6 100644
> --- a/fs/ocfs2/dlmglue.c
> +++ b/fs/ocfs2/dlmglue.c
> @@ -2712,7 +2712,7 @@ int ocfs2_inode_lock_tracker(struct inode *inode,
> return status;
> }
> }
> - return tmp_oh ? 1 : 0;
> + return 1;
> }
>
> void ocfs2_inode_unlock_tracker(struct inode *inode,
>
Re: [PATCH v7 5/6] powerpc/64: Make COMPAT user-selectable disabled on littleendian by default.
Michal Suchanek writes: > On bigendian ppc64 it is common to have 32bit legacy binaries but much > less so on littleendian. I think the toolchain people will tell you that there is no 32-bit little endian ABI defined at all, if anything works it's by accident. So I think we should not make this selectable, unless someone puts their hand up to say they want it and are willing to test it and keep it working. cheers > v3: make configurable > --- > arch/powerpc/Kconfig | 5 +++-- > 1 file changed, 3 insertions(+), 2 deletions(-) > > diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig > index 5bab0bb6b833..b0339e892329 100644 > --- a/arch/powerpc/Kconfig > +++ b/arch/powerpc/Kconfig > @@ -264,8 +264,9 @@ config PANIC_TIMEOUT > default 180 > > config COMPAT > - bool > - default y if PPC64 > + bool "Enable support for 32bit binaries" > + depends on PPC64 > + default y if !CPU_LITTLE_ENDIAN > select COMPAT_BINFMT_ELF > select ARCH_WANT_OLD_COMPAT_IPC > select COMPAT_OLD_SIGACTION > -- > 2.22.0
RE: [RFC PATCH] powerpc: Convert ____flush_dcache_icache_phys() to C
"Alastair D'Silva" writes: > On Wed, 2019-08-21 at 22:27 +0200, Christophe Leroy wrote: >> >> Le 20/08/2019 à 06:36, Alastair D'Silva a écrit : >> > On Fri, 2019-08-16 at 15:52 +, Christophe Leroy wrote: >> >> [...] >> >> > >> > Thanks Christophe, >> > >> > I'm trying a somewhat different approach that requires less >> > knowledge >> > of assembler. Handling of CPU_FTR_COHERENT_ICACHE is outside this >> > function. The code below is not a patch as my tree is a bit messy, >> > sorry: >> >> Can we be 100% sure that GCC won't add any code accessing some >> global data or stack while the Data MMU is OFF ? > > +mpe > > I'm not sure how we would go about making such a guarantee, but I've > tied every variable used to a register and addr is passed in a > register, so there is no stack usage, and every call in there only > operates on it's operands. That's not safe, I can believe it happens to work but the compiler people will laugh at us if it ever breaks. Let's leave it in asm. cheers
Re: linux-next: manual merge of the powerpc tree with the arm64 tree
Stephen Rothwell writes:
> Hi all,
>
> Today's linux-next merge of the powerpc tree got a conflict in:
>
> arch/Kconfig
>
> between commit:
>
> 5cf896fb6be3 ("arm64: Add support for relocating the kernel with RELR
> relocations")
>
> from the arm64 tree and commit:
>
> 0c9c1d563975 ("x86, s390: Move ARCH_HAS_MEM_ENCRYPT definition to
> arch/Kconfig")
>
> from the powerpc tree.
>
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging. You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
Thanks.
That conflict seems entirely trivial, but Catalin/Will if it bothers you
I have the conflicting commit in a topic branch based on rc2 which you
could merge to resolve it:
https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git/commit/?h=topic/mem-encrypt=0c9c1d56397518eb823d458b00b06bcccd956794
cheers
> --
> Cheers,
> Stephen Rothwell
>
> diff --cc arch/Kconfig
> index 6f4d3e9bf486,89e2e3f64f79..
> --- a/arch/Kconfig
> +++ b/arch/Kconfig
> @@@ -932,20 -925,9 +932,23 @@@ config LOCK_EVENT_COUNT
> the chance of application behavior change because of timing
> differences. The counts are reported via debugfs.
>
> +# Select if the architecture has support for applying RELR relocations.
> +config ARCH_HAS_RELR
> +bool
> +
> +config RELR
> +bool "Use RELR relocation packing"
> +depends on ARCH_HAS_RELR && TOOLS_SUPPORT_RELR
> +default y
> +help
> + Store the kernel's dynamic relocations in the RELR relocation packing
> + format. Requires a compatible linker (LLD supports this feature), as
> + well as compatible NM and OBJCOPY utilities (llvm-nm and llvm-objcopy
> + are compatible).
> +
> + config ARCH_HAS_MEM_ENCRYPT
> + bool
> +
> source "kernel/gcov/Kconfig"
>
> source "scripts/gcc-plugins/Kconfig"
[PATCH v2] usb: chipidea: msm: Use device-managed registration API
Use devm_reset_controller_register to get rid of manual unregistration. Signed-off-by: Chuhong Yuan --- Changes in v2: - Remove not needed err_fs. drivers/usb/chipidea/ci_hdrc_msm.c | 9 +++-- 1 file changed, 3 insertions(+), 6 deletions(-) diff --git a/drivers/usb/chipidea/ci_hdrc_msm.c b/drivers/usb/chipidea/ci_hdrc_msm.c index bb4645a8ca46..af648ba6544d 100644 --- a/drivers/usb/chipidea/ci_hdrc_msm.c +++ b/drivers/usb/chipidea/ci_hdrc_msm.c @@ -216,13 +216,13 @@ static int ci_hdrc_msm_probe(struct platform_device *pdev) ci->rcdev.ops = _hdrc_msm_reset_ops; ci->rcdev.of_node = pdev->dev.of_node; ci->rcdev.nr_resets = 2; - ret = reset_controller_register(>rcdev); + ret = devm_reset_controller_register(>dev, >rcdev); if (ret) return ret; ret = clk_prepare_enable(ci->fs_clk); if (ret) - goto err_fs; + return ret; reset_control_assert(reset); usleep_range(1, 12000); @@ -232,7 +232,7 @@ static int ci_hdrc_msm_probe(struct platform_device *pdev) ret = clk_prepare_enable(ci->core_clk); if (ret) - goto err_fs; + return ret; ret = clk_prepare_enable(ci->iface_clk); if (ret) @@ -271,8 +271,6 @@ static int ci_hdrc_msm_probe(struct platform_device *pdev) clk_disable_unprepare(ci->iface_clk); err_iface: clk_disable_unprepare(ci->core_clk); -err_fs: - reset_controller_unregister(>rcdev); return ret; } @@ -284,7 +282,6 @@ static int ci_hdrc_msm_remove(struct platform_device *pdev) ci_hdrc_remove_device(ci->ci); clk_disable_unprepare(ci->iface_clk); clk_disable_unprepare(ci->core_clk); - reset_controller_unregister(>rcdev); return 0; } -- 2.20.1
Re: [PATCHv1 1/3] arm64: dts: meson: odroid-c2: Add missing regulator linked to P5V0 regulator
Hi Martin, On Mon, 2 Sep 2019 at 03:23, Martin Blumenstingl wrote: > > Hi Anand, > > On Sun, Sep 1, 2019 at 3:58 PM Anand Moon wrote: > > > > Hi Martin, > > > > Thanks for your review comments. > > > > Their have been some revision changes in S905 Odroid Schematics. > > [0] https://dn.odroid.com/S905/Schematic/ > > > > Well I have make my changes based on old odroid-c2_rev0.2_20151218.pdf > > [...] > > > > > > according to the schematics there's both: > > > - VDDIO_AO3V3 > > > - VCC3V3 (which is turned on by VDDIO_AO3V3, see [0]) > > > > > > > From the schematics it seams same. > > > > VDDIO_AO3V3---DMG340LSQN4 (Q4)---VCC3V3 > yes, they are the same signal. the only difference is that VCC3V3 is > turned on later in the power-up sequence > > > But this name change was done to link TFLASH_VDD_EN to TFLASH_VDD for eMMC > > > > VDDIO_AO3V3-TFLASH_VDD using TFLASH_VDD_EN gpio pin. > > > > Well I have tested this changes on eMMC module. > I cannot see any of the TFLASH_* regulators being linked to eMMC (they > are only linked to the SD card slot, I also checked > odroid-c2_rev0.2_20151218.pdf and odroid-c2_rev0.2_20171114.pdf). > which page of the odroid-c2_rev0.2_20151218.pdf schematics shows how > TFLASH_VDD is linked to eMMC? > > please note that I don't have an Odroid-C2 board myself (so I cannot > test any of this). > > > Martin Thanks I will double check again and re-post then with correction again. Best Regards -Anand
Re: [kbuild-all] [tip: x86/vmware] input/vmmouse: Update the backdoor call with support for new instructions
On Fri, Aug 30, 2019 at 09:35:57PM +0200, Borislav Petkov wrote: > On Fri, Aug 30, 2019 at 11:08:56PM +0800, Philip Li wrote: > > hi Boris, for the build status notification, we currently send to below > > address, is it still valid? If not, can you suggest one for us? > > Sure, here's an update patch ontop of your master branch: Thanks Boris, it is applied, and will take effect soon. > > --- > From: Borislav Petkov > Date: Fri, 30 Aug 2019 21:33:29 +0200 > Subject: [PATCH] repo/linux/tip: Update tip tree contact information > > Replace hpa with Borislav and change contact mail address. > > Signed-off-by: Borislav Petkov > --- > repo/linux/tip | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) > > diff --git a/repo/linux/tip b/repo/linux/tip > index 4fc5d88176fd..96a7dec66f97 100644 > --- a/repo/linux/tip > +++ b/repo/linux/tip > @@ -2,11 +2,11 @@ url: > https://kernel.googlesource.com/pub/scm/linux/kernel/git/tip/tip.git > integration_testing_branches: auto-latest > mail_cc: > - linux-kernel@vger.kernel.org > -- tipbu...@zytor.com > +- x...@kernel.org > owner: > - Ingo Molnar > -- H. Peter Anvin > - Thomas Gleixner > +- Borislav Petkov > subsystems: > - x86 > - fpu > @@ -16,4 +16,4 @@ subsystems: > - locking > blacklist_branch: auto-.*|tmp-.*|base-.*|test.*|.*-for-linus > notify_build_success_branch: .* > -build_success_mail_to: tip build status > +build_success_mail_to: x86-ml > -- > 2.21.0 > > Thx. > > -- > Regards/Gruss, > Boris. > > Good mailing practices for 400: avoid top-posting and trim the reply.
Re: [PATCH] ext4 crypto: fix to check feature status before get policy
On 2019/8/31 23:02, Eric Biggers wrote:
> On Sat, Aug 31, 2019 at 06:32:28PM +0800, Chao Yu wrote:
>> Hi,
>>
>> Is this change not necessary? A month has passed...
>>
>> Thanks,
>>
>> On 2019/8/4 17:56, Chao Yu wrote:
>>> From: Chao Yu
>>>
>>> When getting fscrypto policy via EXT4_IOC_GET_ENCRYPTION_POLICY, if
>>> encryption feature is off, it's better to return EOPNOTSUPP instead
>>> of ENODATA, so let's add ext4_has_feature_encrypt() to do the check
>>> for that.
>>>
>>> Signed-off-by: Chao Yu
>>> ---
>>> fs/ext4/ioctl.c | 6 --
>>> 1 file changed, 4 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/fs/ext4/ioctl.c b/fs/ext4/ioctl.c
>>> index 442f7ef873fc..bf87835c1237 100644
>>> --- a/fs/ext4/ioctl.c
>>> +++ b/fs/ext4/ioctl.c
>>> @@ -1112,9 +1112,11 @@ long ext4_ioctl(struct file *filp, unsigned int cmd,
>>> unsigned long arg)
>>> return -EOPNOTSUPP;
>>> #endif
>>> }
>>> - case EXT4_IOC_GET_ENCRYPTION_POLICY:
>>> + case EXT4_IOC_GET_ENCRYPTION_POLICY: {
>>> + if (!ext4_has_feature_encrypt(sb))
>>> + return -EOPNOTSUPP;
>>> return fscrypt_ioctl_get_policy(filp, (void __user *)arg);
>>> -
>>> + }
>>> case EXT4_IOC_FSGETXATTR:
>>> {
>>> struct fsxattr fa;
>>>
>
> Sorry, I was preoccupied with all the other fscrypt changes, and was thinking
> of
> waiting until 5.5 for this to avoid a potential extra merge conflict or a
> potentially breaking change. Looking at this again though, the new ioctl
> FS_IOC_GET_ENCRYPTION_POLICY_EX *does* do the feature check, which doesn't
> match
> the documentation, which implies the check isn't done. Also, f2fs does the
> check in FS_IOC_GET_ENCRYPTION_POLICY, so the filesystems are inconsistent.
>
> So, it makes some sense to apply this now. So I've gone ahead and applied the
> following to fscrypt.git#master, edited a bit from your original patch:
>
>>From 0642ea2409f3bfa105570e12854b8e2628db6835 Mon Sep 17 00:00:00 2001
> From: Chao Yu
> Date: Sun, 4 Aug 2019 17:56:43 +0800
> Subject: [PATCH] ext4 crypto: fix to check feature status before get policy
>
> When getting fscrypt policy via EXT4_IOC_GET_ENCRYPTION_POLICY, if
> encryption feature is off, it's better to return EOPNOTSUPP instead of
> ENODATA, so let's add ext4_has_feature_encrypt() to do the check for
> that.
>
> This makes it so that all fscrypt ioctls consistently check for the
> encryption feature, and makes ext4 consistent with f2fs in this regard.
>
> Signed-off-by: Chao Yu
> [EB - removed unneeded braces, updated the documentation, and
> added more explanation to commit message]
The patch looks better now, thanks for the help.
Thanks,
> Signed-off-by: Eric Biggers
> ---
> Documentation/filesystems/fscrypt.rst | 3 ++-
> fs/ext4/ioctl.c | 2 ++
> 2 files changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/filesystems/fscrypt.rst
> b/Documentation/filesystems/fscrypt.rst
> index 4289c29d7c5a..8a0700af9596 100644
> --- a/Documentation/filesystems/fscrypt.rst
> +++ b/Documentation/filesystems/fscrypt.rst
> @@ -562,7 +562,8 @@ FS_IOC_GET_ENCRYPTION_POLICY_EX can fail with the
> following errors:
>or this kernel is too old to support FS_IOC_GET_ENCRYPTION_POLICY_EX
>(try FS_IOC_GET_ENCRYPTION_POLICY instead)
> - ``EOPNOTSUPP``: the kernel was not configured with encryption
> - support for this filesystem
> + support for this filesystem, or the filesystem superblock has not
> + had encryption enabled on it
> - ``EOVERFLOW``: the file is encrypted and uses a recognized
>encryption policy version, but the policy struct does not fit into
>the provided buffer
> diff --git a/fs/ext4/ioctl.c b/fs/ext4/ioctl.c
> index fe5a4b13f939..5703d607f5af 100644
> --- a/fs/ext4/ioctl.c
> +++ b/fs/ext4/ioctl.c
> @@ -1113,6 +1113,8 @@ long ext4_ioctl(struct file *filp, unsigned int cmd,
> unsigned long arg)
> #endif
> }
> case EXT4_IOC_GET_ENCRYPTION_POLICY:
> + if (!ext4_has_feature_encrypt(sb))
> + return -EOPNOTSUPP;
> return fscrypt_ioctl_get_policy(filp, (void __user *)arg);
>
> case FS_IOC_GET_ENCRYPTION_POLICY_EX:
>
[PATCH 2/2] staging: iio: accel: adis16240: move out of staging
Move ADIS16240 driver from staging to mainline. The ADIS16240 is a fully integrated digital shock detection and recorder system. Signed-off-by: Rodrigo Ribeiro Carvalho --- drivers/iio/accel/Kconfig | 12 + drivers/iio/accel/Makefile| 1 + drivers/iio/accel/adis16240.c | 454 ++ drivers/staging/iio/accel/Kconfig | 12 - drivers/staging/iio/accel/Makefile| 1 - drivers/staging/iio/accel/adis16240.c | 454 -- 6 files changed, 467 insertions(+), 467 deletions(-) create mode 100644 drivers/iio/accel/adis16240.c delete mode 100644 drivers/staging/iio/accel/adis16240.c diff --git a/drivers/iio/accel/Kconfig b/drivers/iio/accel/Kconfig index d4ef35aeb579..91fd8741c95f 100644 --- a/drivers/iio/accel/Kconfig +++ b/drivers/iio/accel/Kconfig @@ -30,6 +30,18 @@ config ADIS16209 To compile this driver as a module, say M here: the module will be called adis16209. +config ADIS16240 + tristate "Analog Devices ADIS16240 Programmable Impact Sensor and Recorder" + depends on SPI + select IIO_ADIS_LIB + select IIO_ADIS_LIB_BUFFER if IIO_BUFFER + help + Say Y here to build support for Analog Devices adis16240 programmable + impact Sensor and recorder. + + To compile this driver as a module, say M here: the module will be + called adis16240. + config ADXL345 tristate diff --git a/drivers/iio/accel/Makefile b/drivers/iio/accel/Makefile index 56bd0215e0d4..f7e025a86dd9 100644 --- a/drivers/iio/accel/Makefile +++ b/drivers/iio/accel/Makefile @@ -6,6 +6,7 @@ # When adding new entries keep the list in alphabetical order obj-$(CONFIG_ADIS16201) += adis16201.o obj-$(CONFIG_ADIS16209) += adis16209.o +obj-$(CONFIG_ADIS16240) += adis16240.o obj-$(CONFIG_ADXL345) += adxl345_core.o obj-$(CONFIG_ADXL345_I2C) += adxl345_i2c.o obj-$(CONFIG_ADXL345_SPI) += adxl345_spi.o diff --git a/drivers/iio/accel/adis16240.c b/drivers/iio/accel/adis16240.c new file mode 100644 index ..82099db4bf0c --- /dev/null +++ b/drivers/iio/accel/adis16240.c @@ -0,0 +1,454 @@ +// SPDX-License-Identifier: GPL-2.0+ +/* + * ADIS16240 Programmable Impact Sensor and Recorder driver + * + * Copyright 2010 Analog Devices Inc. + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include +#include +#include +#include + +#define ADIS16240_STARTUP_DELAY220 /* ms */ + +/* Flash memory write count */ +#define ADIS16240_FLASH_CNT 0x00 + +/* Output, power supply */ +#define ADIS16240_SUPPLY_OUT 0x02 + +/* Output, x-axis accelerometer */ +#define ADIS16240_XACCL_OUT 0x04 + +/* Output, y-axis accelerometer */ +#define ADIS16240_YACCL_OUT 0x06 + +/* Output, z-axis accelerometer */ +#define ADIS16240_ZACCL_OUT 0x08 + +/* Output, auxiliary ADC input */ +#define ADIS16240_AUX_ADC0x0A + +/* Output, temperature */ +#define ADIS16240_TEMP_OUT 0x0C + +/* Output, x-axis acceleration peak */ +#define ADIS16240_XPEAK_OUT 0x0E + +/* Output, y-axis acceleration peak */ +#define ADIS16240_YPEAK_OUT 0x10 + +/* Output, z-axis acceleration peak */ +#define ADIS16240_ZPEAK_OUT 0x12 + +/* Output, sum-of-squares acceleration peak */ +#define ADIS16240_XYZPEAK_OUT0x14 + +/* Output, Capture Buffer 1, X and Y acceleration */ +#define ADIS16240_CAPT_BUF1 0x16 + +/* Output, Capture Buffer 2, Z acceleration */ +#define ADIS16240_CAPT_BUF2 0x18 + +/* Diagnostic, error flags */ +#define ADIS16240_DIAG_STAT 0x1A + +/* Diagnostic, event counter */ +#define ADIS16240_EVNT_CNTR 0x1C + +/* Diagnostic, check sum value from firmware test */ +#define ADIS16240_CHK_SUM0x1E + +/* Calibration, x-axis acceleration offset adjustment */ +#define ADIS16240_XACCL_OFF 0x20 + +/* Calibration, y-axis acceleration offset adjustment */ +#define ADIS16240_YACCL_OFF 0x22 + +/* Calibration, z-axis acceleration offset adjustment */ +#define ADIS16240_ZACCL_OFF 0x24 + +/* Clock, hour and minute */ +#define ADIS16240_CLK_TIME 0x2E + +/* Clock, month and day */ +#define ADIS16240_CLK_DATE 0x30 + +/* Clock, year */ +#define ADIS16240_CLK_YEAR 0x32 + +/* Wake-up setting, hour and minute */ +#define ADIS16240_WAKE_TIME 0x34 + +/* Wake-up setting, month and day */ +#define ADIS16240_WAKE_DATE 0x36 + +/* Alarm 1 amplitude threshold */ +#define ADIS16240_ALM_MAG1 0x38 + +/* Alarm 2 amplitude threshold */ +#define ADIS16240_ALM_MAG2 0x3A + +/* Alarm control */ +#define ADIS16240_ALM_CTRL 0x3C + +/* Capture, external trigger control */ +#define ADIS16240_XTRIG_CTRL 0x3E + +/* Capture, address pointer */ +#define ADIS16240_CAPT_PNTR 0x40 + +/* Capture, configuration and control */ +#define ADIS16240_CAPT_CTRL 0x42 + +/* General-purpose digital input/output control */ +#define
[PATCH 1/2] dt-bindings: iio: accel: add binding documentation for ADIS16240
This patch add device tree binding documentation for ADIS16240.
Signed-off-by: Rodrigo Ribeiro Carvalho
---
I have doubt about what maintainer I may to put in that documentation. I
put Alexandru as maintainer because he reviewed my last patch on this
driver, so I think that he is a good candidate.
.../bindings/iio/accel/adi,adis16240.yaml | 55 +++
1 file changed, 55 insertions(+)
create mode 100644
Documentation/devicetree/bindings/iio/accel/adi,adis16240.yaml
diff --git a/Documentation/devicetree/bindings/iio/accel/adi,adis16240.yaml
b/Documentation/devicetree/bindings/iio/accel/adi,adis16240.yaml
new file mode 100644
index ..08019b51611c
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/accel/adi,adis16240.yaml
@@ -0,0 +1,55 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iio/accel/adi,adis16240.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: ADIS16240 Programmable Impact Sensor and Recorder driver
+
+maintainers:
+ - Alexandru Ardelean
+
+description: |
+ ADIS16240 Programmable Impact Sensor and Recorder driver that supports
+ SPI interface.
+https://www.analog.com/en/products/adis16240.html
+
+properties:
+ compatible:
+enum:
+ - adi,adis16240
+
+ reg:
+maxItems: 1
+
+ spi-cpha: true
+
+ spi-cpol: true
+
+ interrupts:
+maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - interrupts
+
+examples:
+ - |
+#include
+#include
+spi0 {
+#address-cells = <1>;
+#size-cells = <0>;
+
+/* Example for a SPI device node */
+accelerometer@0 {
+compatible = "adi,adis16240";
+reg = <0>;
+spi-max-frequency = <250>;
+spi-cpol;
+spi-cpha;
+interrupt-parent = <>;
+interrupts = <0 IRQ_TYPE_LEVEL_HIGH>;
+};
+};
--
2.23.0.rc1
linux-next: manual merge of the afs tree with the net tree
Hi all, Today's linux-next merge of the afs tree got conflicts in: include/trace/events/rxrpc.h net/rxrpc/ar-internal.h net/rxrpc/call_object.c net/rxrpc/conn_client.c net/rxrpc/input.c net/rxrpc/recvmsg.c net/rxrpc/skbuff.c between various commits from the net tree and similar commits from the afs tree. I fixed it up (I just dropped the afs tree for today) and can carry the fix as necessary. This is now fixed as far as linux-next is concerned, but any non trivial conflicts should be mentioned to your upstream maintainer when your tree is submitted for merging. You may also want to consider cooperating with the maintainer of the conflicting tree to minimise any particularly complex conflicts. It looks like the afs tree has older versions fo some commits in the net tree ... plus some more. -- Cheers, Stephen Rothwell pgp6V0b3XB4Pw.pgp Description: OpenPGP digital signature
RE: [PATCH] powerpc: Perform a bounds check in arch_add_memory
On Tue, 2019-08-27 at 09:13 +0200, David Hildenbrand wrote:
> On 27.08.19 08:39, Alastair D'Silva wrote:
> > On Tue, 2019-08-27 at 08:28 +0200, Michal Hocko wrote:
> > > On Tue 27-08-19 15:20:46, Alastair D'Silva wrote:
> > > > From: Alastair D'Silva
> > > >
> > > > It is possible for firmware to allocate memory ranges outside
> > > > the range of physical memory that we support
> > > > (MAX_PHYSMEM_BITS).
> > >
> > > Doesn't that count as a FW bug? Do you have any evidence of that
> > > in
> > > the
> > > field? Just wondering...
> > >
> >
> > Not outside our lab, but OpenCAPI attached LPC memory is assigned
> > addresses based on the slot/NPU it is connected to. These addresses
> > prior to:
> > 4ffe713b7587 ("powerpc/mm: Increase the max addressable memory to
> > 2PB")
> > were inaccessible and resulted in bogus sections - see our
> > discussion
> > on 'mm: Trigger bug on if a section is not found in __section_nr'.
> > Doing this check here was your suggestion :)
> >
> > It's entirely possible that a similar problem will occur in the
> > future,
> > and it's cheap to guard against, which is why I've added this.
> >
>
> If you keep it here, I guess this should be wrapped by a
> WARN_ON_ONCE().
>
> If we move it to common code (e.g., __add_pages() or add_memory()),
> then
> probably not. I can see that s390x allows to configure
> MAX_PHYSMEM_BITS,
> so the check could actually make sense.
>
I couldn't see a nice platform indepedent way to determine the
allowable address range, but if there is, then I'll move this to the
generic code instead.
--
Alastair D'Silva
Open Source Developer
Linux Technology Centre, IBM Australia
mob: 0423 762 819
linux-next: manual merge of the powerpc tree with the arm64 tree
Hi all,
Today's linux-next merge of the powerpc tree got a conflict in:
arch/Kconfig
between commit:
5cf896fb6be3 ("arm64: Add support for relocating the kernel with RELR
relocations")
from the arm64 tree and commit:
0c9c1d563975 ("x86, s390: Move ARCH_HAS_MEM_ENCRYPT definition to
arch/Kconfig")
from the powerpc tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc arch/Kconfig
index 6f4d3e9bf486,89e2e3f64f79..
--- a/arch/Kconfig
+++ b/arch/Kconfig
@@@ -932,20 -925,9 +932,23 @@@ config LOCK_EVENT_COUNT
the chance of application behavior change because of timing
differences. The counts are reported via debugfs.
+# Select if the architecture has support for applying RELR relocations.
+config ARCH_HAS_RELR
+ bool
+
+config RELR
+ bool "Use RELR relocation packing"
+ depends on ARCH_HAS_RELR && TOOLS_SUPPORT_RELR
+ default y
+ help
+Store the kernel's dynamic relocations in the RELR relocation packing
+format. Requires a compatible linker (LLD supports this feature), as
+well as compatible NM and OBJCOPY utilities (llvm-nm and llvm-objcopy
+are compatible).
+
+ config ARCH_HAS_MEM_ENCRYPT
+ bool
+
source "kernel/gcov/Kconfig"
source "scripts/gcc-plugins/Kconfig"
pgpbJIsmVQDoo.pgp
Description: OpenPGP digital signature
linux-next: Fixes tag needs some work in the battery tree
Hi all,
In commit
b19aca4eb2d2 ("power: supply: sbs-battery: only return health when battery
present")
Fixes tag
Fixes: 76b16f4cdfb8 ("power: supply: sbs-battery: don't assume
has these problem(s):
- Subject has leading but no trailing parentheses
- Subject has leading but no trailing quotes
In commit
38fa8b9f75ea ("power: supply: sbs-battery: use correct flags field")
Fixes tag
Fixes: 76b16f4cdfb8 ("power: supply: sbs-battery: don't assume
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
pgpZdkE1Tsksb.pgp
Description: OpenPGP digital signature
kernel panic: stack is corrupted in lock_release (2)
Hello, syzbot found the following crash on: HEAD commit:dd7078f0 enetc: Add missing call to 'pci_free_irq_vectors(.. git tree: net console output: https://syzkaller.appspot.com/x/log.txt?x=115fe0fa60 kernel config: https://syzkaller.appspot.com/x/.config?x=2a6a2b9826fdadf9 dashboard link: https://syzkaller.appspot.com/bug?extid=97deee97cf14574b96d0 compiler: gcc (GCC) 9.0.0 20181231 (experimental) syz repro: https://syzkaller.appspot.com/x/repro.syz?x=11f7c2fe60 IMPORTANT: if you fix the bug, please add the following tag to the commit: Reported-by: syzbot+97deee97cf14574b9...@syzkaller.appspotmail.com Kernel panic - not syncing: stack-protector: Kernel stack is corrupted in: lock_release+0x866/0x960 kernel/locking/lockdep.c:4435 CPU: 0 PID: 9965 Comm: syz-executor.0 Not tainted 5.3.0-rc6+ #182 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: Kernel Offset: disabled Rebooting in 86400 seconds.. --- This bug is generated by a bot. It may contain errors. See https://goo.gl/tpsmEJ for more information about syzbot. syzbot engineers can be reached at syzkal...@googlegroups.com. syzbot will keep track of this bug report. See: https://goo.gl/tpsmEJ#status for how to communicate with syzbot. syzbot can test patches for this bug, for details see: https://goo.gl/tpsmEJ#testing-patches
Re: [PATCH] drivers/staging/exfat - by default, prohibit mount of fat/vfat
On Mon, 02 Sep 2019 08:43:29 +1000, Dave Chinner said: > I don't know the details of the exfat spec or the code to know what > the best approach is. I've worked fairly closely with Christoph for > more than a decade - you need to think about what he says rather > than /how he says it/ because there's a lot of thought and knowledge > behind his reasoning. Hence if I were implementing exfat and > Christoph was saying "throw it away and extend fs/fat" > then that's what I'd be doing. Again, I'm not ruling that out if that's the consensus direction. After all, the goal is to merge a working driver - and for that, I need to produce something that the file system maintainers will be willing to merge, which means doing it in a way they want it... Hopefully next week a few other people will weigh in with what they prefer as far as approach goes. Only definite statement I've heard so far was Christoph's... > and we don't want more. Implementing exfat on top of fs/fat kills > two birds with one stone - it modernises the fs/fat code base and > brings new functionality that will have more developers interested > in maintaining it over the long term. Any recommendations on how to approach that? Clone the current fs/fat code and develop on top of that, or create a branch of it and on occasion do the merging needed to track further fs/fat development? Mostly asking for workflow suggestions - what's known to work well for this sort of situation, where we know we won't be merging until we have several thousand lines of new code? And any "don't do or you'll regret it later" advice is also appreciated. :) pgp5MXKs2UlE7.pgp Description: PGP signature
Re: [PATCH] counter: fix devm_platform_ioremap_resource.cocci warnings
On 8/9/19 4:41 AM, Julia Lawall wrote:
From: kbuild test robot
Use devm_platform_ioremap_resource helper which wraps
platform_get_resource() and devm_ioremap_resource() together.
Generated by: scripts/coccinelle/api/devm_platform_ioremap_resource.cocci
Fixes: 78958c294246 ("counter: new TI eQEP driver")
Signed-off-by: kbuild test robot
Signed-off-by: Julia Lawall
---
Included this change in v2 of the "counter: new TI eQEP driver" series.
Thanks.
[PATCH v3 2/6] dt-bindings: counter: new bindings for TI eQEP
This documents device tree binding for the Texas Instruments Enhanced
Quadrature Encoder Pulse (eQEP) Module found in various TI SoCs.
Signed-off-by: David Lechner
---
v3 changes:
- fixed style issues
- fixed generic node name
- (was suggested to drop descriptions since there is only one interrupt and one
clock, but I opted to keep them anyway)
v2 changes:
- convert to .yaml format
- rename clock to "sysclkout"
.../devicetree/bindings/counter/ti-eqep.yaml | 50 +++
1 file changed, 50 insertions(+)
create mode 100644 Documentation/devicetree/bindings/counter/ti-eqep.yaml
diff --git a/Documentation/devicetree/bindings/counter/ti-eqep.yaml
b/Documentation/devicetree/bindings/counter/ti-eqep.yaml
new file mode 100644
index ..85f1ff83afe7
--- /dev/null
+++ b/Documentation/devicetree/bindings/counter/ti-eqep.yaml
@@ -0,0 +1,50 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/counter/ti-eqep.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Texas Instruments Enhanced Quadrature Encoder Pulse (eQEP) Module
+
+maintainers:
+ - David Lechner
+
+properties:
+ compatible:
+const: ti,am3352-eqep
+
+ reg:
+maxItems: 1
+
+ interrupts:
+description: The eQEP event interrupt
+maxItems: 1
+
+ clocks:
+description: The clock that determines the SYSCLKOUT rate for the eQEP
+ peripheral.
+maxItems: 1
+
+ clock-names:
+const: sysclkout
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+ - clock-names
+
+additionalProperties: false
+
+examples:
+ - |
+eqep0: counter@180 {
+compatible = "ti,am3352-eqep";
+reg = <0x180 0x80>;
+clocks = <_gclk>;
+clock-names = "sysclkout";
+interrupts = <79>;
+};
+
+...
--
2.17.1
[PATCH v3 1/6] bus/ti-pwmss: move TI PWMSS driver from PWM to bus subsystem
The TI PWMSS driver is a simple bus driver for providing power
power management for the PWM peripherals on TI AM33xx SoCs, namely
eCAP, eHRPWM and eQEP. The eQEP is a counter rather than a PWM, so
it does not make sense to have the bus driver in the PWM subsystem
since the PWMSS is not exclusive to PWM devices.
Signed-off-by: David Lechner
---
v3 changes:
- none
v2 changes:
- new patch
drivers/bus/Kconfig | 9 +
drivers/bus/Makefile | 1 +
drivers/{pwm/pwm-tipwmss.c => bus/ti-pwmss.c} | 0
drivers/pwm/Kconfig | 9 -
drivers/pwm/Makefile | 1 -
5 files changed, 10 insertions(+), 10 deletions(-)
rename drivers/{pwm/pwm-tipwmss.c => bus/ti-pwmss.c} (100%)
diff --git a/drivers/bus/Kconfig b/drivers/bus/Kconfig
index 1851112ccc29..4eeb15839ce0 100644
--- a/drivers/bus/Kconfig
+++ b/drivers/bus/Kconfig
@@ -140,6 +140,15 @@ config TEGRA_GMI
Driver for the Tegra Generic Memory Interface bus which can be used
to attach devices such as NOR, UART, FPGA and more.
+config TI_PWMSS
+ bool
+ default y if (ARCH_OMAP2PLUS) && (PWM_TIECAP || PWM_TIEHRPWM)
+ help
+ PWM Subsystem driver support for AM33xx SOC.
+
+ PWM submodules require PWM config space access from submodule
+ drivers and require common parent driver support.
+
config TI_SYSC
bool "TI sysc interconnect target module driver"
depends on ARCH_OMAP2PLUS
diff --git a/drivers/bus/Makefile b/drivers/bus/Makefile
index ca300b1914ce..a2d13cf4a877 100644
--- a/drivers/bus/Makefile
+++ b/drivers/bus/Makefile
@@ -26,6 +26,7 @@ obj-$(CONFIG_SUNXI_RSB) += sunxi-rsb.o
obj-$(CONFIG_SIMPLE_PM_BUS)+= simple-pm-bus.o
obj-$(CONFIG_TEGRA_ACONNECT) += tegra-aconnect.o
obj-$(CONFIG_TEGRA_GMI)+= tegra-gmi.o
+obj-$(CONFIG_TI_PWMSS) += ti-pwmss.o
obj-$(CONFIG_TI_SYSC) += ti-sysc.o
obj-$(CONFIG_TS_NBUS) += ts-nbus.o
obj-$(CONFIG_UNIPHIER_SYSTEM_BUS) += uniphier-system-bus.o
diff --git a/drivers/pwm/pwm-tipwmss.c b/drivers/bus/ti-pwmss.c
similarity index 100%
rename from drivers/pwm/pwm-tipwmss.c
rename to drivers/bus/ti-pwmss.c
diff --git a/drivers/pwm/Kconfig b/drivers/pwm/Kconfig
index a7e57516959e..300396564769 100644
--- a/drivers/pwm/Kconfig
+++ b/drivers/pwm/Kconfig
@@ -497,15 +497,6 @@ config PWM_TIEHRPWM
To compile this driver as a module, choose M here: the module
will be called pwm-tiehrpwm.
-config PWM_TIPWMSS
- bool
- default y if (ARCH_OMAP2PLUS) && (PWM_TIECAP || PWM_TIEHRPWM)
- help
- PWM Subsystem driver support for AM33xx SOC.
-
- PWM submodules require PWM config space access from submodule
- drivers and require common parent driver support.
-
config PWM_TWL
tristate "TWL4030/6030 PWM support"
depends on TWL4030_CORE
diff --git a/drivers/pwm/Makefile b/drivers/pwm/Makefile
index 76b555b51887..f67eb6e9294d 100644
--- a/drivers/pwm/Makefile
+++ b/drivers/pwm/Makefile
@@ -49,7 +49,6 @@ obj-$(CONFIG_PWM_SUN4I) += pwm-sun4i.o
obj-$(CONFIG_PWM_TEGRA)+= pwm-tegra.o
obj-$(CONFIG_PWM_TIECAP) += pwm-tiecap.o
obj-$(CONFIG_PWM_TIEHRPWM) += pwm-tiehrpwm.o
-obj-$(CONFIG_PWM_TIPWMSS) += pwm-tipwmss.o
obj-$(CONFIG_PWM_TWL) += pwm-twl.o
obj-$(CONFIG_PWM_TWL_LED) += pwm-twl-led.o
obj-$(CONFIG_PWM_VT8500) += pwm-vt8500.o
--
2.17.1
[PATCH v3 0/6] counter: new TI eQEP driver
This series adds device tree bindings and a new counter driver for the Texas
Instruments Enhanced Quadrature Encoder Pulse (eQEP).
As mentioned in one of the commit messages, to start with, the driver only
supports reading the current counter value and setting the min/max values.
Other features can be added as the counter subsystem gains support for them.
v3 changes:
- Minor changes to device tree bindings (style and generic node name)
- Drop action in initializer
- Fix ordering of pm runtime disable
v2 changes:
- New patch to move TI PWMSS driver from drivers/pwm/ to drivers/bus/
- Device tree bindings converted to .yaml format
- Device tree clock renamed from "fck" to "sysclkout"
- Dropped unused index and strobe signals from counter driver
- Added synapses and actions to counter driver
- Fixed base in of kstrtouint()
- Clarifications in commit messages
This series has been tested on a BeagleBone Blue with the following script:
#!/usr/bin/env python3
from os import path
from time import sleep
COUNTER_PATH = '/sys/bus/counter/devices'
COUNTERS = ['counter0', 'counter1', 'counter2']
COUNT0 = 'count0'
COUNT = 'count'
FUNCTION = 'function'
CEILING = 'ceiling'
FLOOR = 'floor'
ENABLE = 'enable'
cnts = []
for c in COUNTERS:
function_path = path.join(COUNTER_PATH, c, COUNT0, FUNCTION)
with open(function_path, 'w') as f:
f.write('quadrature x4')
floor_path = path.join(COUNTER_PATH, c, COUNT0, FLOOR)
with open(floor_path, 'w') as f:
f.write(str(0))
ceiling_path = path.join(COUNTER_PATH, c, COUNT0, CEILING)
with open(ceiling_path, 'w') as f:
f.write(str(0x))
enable_path = path.join(COUNTER_PATH, c, COUNT0, ENABLE)
with open(enable_path, 'w') as f:
f.write('1')
cnt_path = path.join(COUNTER_PATH, c, COUNT0, COUNT)
cnts.append(open(cnt_path, 'r'))
while True:
for c in cnts:
c.seek(0)
val = int(c.read())
if val >= 0x8000:
val -= 0x1
print(val, end=' ')
print()
sleep(1)
David Lechner (6):
bus/ti-pwmss: move TI PWMSS driver from PWM to bus subsystem
dt-bindings: counter: new bindings for TI eQEP
counter: new TI eQEP driver
ARM: dts: am33xx: Add nodes for eQEP
ARM: dts: am335x-boneblue: Enable eQEP
ARM: dts: am335x-boneblue: Use of am335x-osd335x-common.dtsi
.../devicetree/bindings/counter/ti-eqep.yaml | 50 ++
MAINTAINERS | 6 +
arch/arm/boot/dts/am335x-boneblue.dts | 146 +++---
arch/arm/boot/dts/am33xx-l4.dtsi | 27 +
drivers/bus/Kconfig | 9 +
drivers/bus/Makefile | 1 +
drivers/{pwm/pwm-tipwmss.c => bus/ti-pwmss.c} | 0
drivers/counter/Kconfig | 11 +
drivers/counter/Makefile | 1 +
drivers/counter/ti-eqep.c | 473 ++
drivers/pwm/Kconfig | 9 -
drivers/pwm/Makefile | 1 -
12 files changed, 634 insertions(+), 100 deletions(-)
create mode 100644 Documentation/devicetree/bindings/counter/ti-eqep.yaml
rename drivers/{pwm/pwm-tipwmss.c => bus/ti-pwmss.c} (100%)
create mode 100644 drivers/counter/ti-eqep.c
--
2.17.1
[PATCH v3 5/6] ARM: dts: am335x-boneblue: Enable eQEP
This enables the Enhanced Quadrature Encoder Pulse (eQEP) module for
connectors E1, E2 and E3 on BeagleBone Blue.
Signed-off-by: David Lechner
---
v3 changes:
- none
v2 changes:
- none
arch/arm/boot/dts/am335x-boneblue.dts | 54 +++
1 file changed, 54 insertions(+)
diff --git a/arch/arm/boot/dts/am335x-boneblue.dts
b/arch/arm/boot/dts/am335x-boneblue.dts
index 0257576d5d16..df3978ce061c 100644
--- a/arch/arm/boot/dts/am335x-boneblue.dts
+++ b/arch/arm/boot/dts/am335x-boneblue.dts
@@ -258,6 +258,30 @@
AM33XX_PADCONF(AM335X_PIN_MII1_RXD0, PIN_OUTPUT,
MUX_MODE7) /* (M16) gmii1_rxd0.gpio2[21] */
>;
};
+
+ /* E1 */
+ eqep0_pins: pinmux_eqep0_pins {
+ pinctrl-single,pins = <
+ AM33XX_PADCONF(AM335X_PIN_MCASP0_AXR0, PIN_INPUT,
MUX_MODE1)/* (B12) mcasp0_aclkr.eQEP0A_in */
+ AM33XX_PADCONF(AM335X_PIN_MCASP0_FSR, PIN_INPUT,
MUX_MODE1) /* (C13) mcasp0_fsr.eQEP0B_in */
+ >;
+ };
+
+ /* E2 */
+ eqep1_pins: pinmux_eqep1_pins {
+ pinctrl-single,pins = <
+ AM33XX_PADCONF(AM335X_PIN_LCD_DATA12, PIN_INPUT,
MUX_MODE2) /* (V2) lcd_data12.eQEP1A_in */
+ AM33XX_PADCONF(AM335X_PIN_LCD_DATA13, PIN_INPUT,
MUX_MODE2) /* (V3) lcd_data13.eQEP1B_in */
+ >;
+ };
+
+ /* E3 */
+ eqep2_pins: pinmux_eqep2_pins {
+ pinctrl-single,pins = <
+ AM33XX_PADCONF(AM335X_PIN_GPMC_AD12, PIN_INPUT,
MUX_MODE4) /* (T12) gpmc_ad12.eQEP2A_in */
+ AM33XX_PADCONF(AM335X_PIN_GPMC_AD13, PIN_INPUT,
MUX_MODE4) /* (R12) gpmc_ad13.eQEP2B_in */
+ >;
+ };
};
{
@@ -530,3 +554,33 @@
line-name = "LS_BUF_EN";
};
};
+
+ {
+ status = "okay";
+};
+
+ {
+ status = "okay";
+ pinctrl-names = "default";
+ pinctrl-0 = <_pins>;
+};
+
+ {
+ status = "okay";
+};
+
+ {
+ status = "okay";
+ pinctrl-names = "default";
+ pinctrl-0 = <_pins>;
+};
+
+ {
+ status = "okay";
+};
+
+ {
+ status = "okay";
+ pinctrl-names = "default";
+ pinctrl-0 = <_pins>;
+};
--
2.17.1
[PATCH v3 3/6] counter: new TI eQEP driver
This adds a new counter driver for the Texas Instruments Enhanced Quadrature Encoder Pulse (eQEP) module. Only very basic functionality is currently implemented - only enough to be able to read the position. The actual device has many more features which can be added to the driver on an as-needed basis. It is not possible to read the QEPA/B signal values in hardware, so that feature is omitted. The TI_PWMSS kernel option is selected in Kconfig to enable the parent bus, which is needed for power management. Signed-off-by: David Lechner --- v3 changes: - Fixed ordering of pm runtime disable - Added comment explaining where pm runtime is handled - Dropped initialization of .action in ti_eqep_position_synapses v2 changes: - Dropped unused index and strobe signals - Added synapses and actions - Fixed base in of kstrtouint() - Clarifications in commit message MAINTAINERS | 6 + drivers/bus/Kconfig | 2 +- drivers/counter/Kconfig | 11 + drivers/counter/Makefile | 1 + drivers/counter/ti-eqep.c | 473 ++ 5 files changed, 492 insertions(+), 1 deletion(-) create mode 100644 drivers/counter/ti-eqep.c diff --git a/MAINTAINERS b/MAINTAINERS index 783569e3c4b4..53c28d52964c 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -16014,6 +16014,12 @@ S: Maintained F: drivers/media/platform/davinci/ F: include/media/davinci/ +TI ENHANCED QUADRATURE ENCODER PULSE (eQEP) DRIVER +R: David Lechner +L: linux-...@vger.kernel.org +F: Documentation/devicetree/bindings/counter/ti-eqep.yaml +F: drivers/counter/ti-eqep.c + TI ETHERNET SWITCH DRIVER (CPSW) R: Grygorii Strashko L: linux-o...@vger.kernel.org diff --git a/drivers/bus/Kconfig b/drivers/bus/Kconfig index 4eeb15839ce0..04db7fce4604 100644 --- a/drivers/bus/Kconfig +++ b/drivers/bus/Kconfig @@ -142,7 +142,7 @@ config TEGRA_GMI config TI_PWMSS bool - default y if (ARCH_OMAP2PLUS) && (PWM_TIECAP || PWM_TIEHRPWM) + default y if (ARCH_OMAP2PLUS) && (PWM_TIECAP || PWM_TIEHRPWM || TI_EQEP) help PWM Subsystem driver support for AM33xx SOC. diff --git a/drivers/counter/Kconfig b/drivers/counter/Kconfig index 2967d0a9ff91..c80fa76bb531 100644 --- a/drivers/counter/Kconfig +++ b/drivers/counter/Kconfig @@ -49,6 +49,17 @@ config STM32_LPTIMER_CNT To compile this driver as a module, choose M here: the module will be called stm32-lptimer-cnt. +config TI_EQEP + tristate "TI eQEP counter driver" + depends on (SOC_AM33XX || COMPILE_TEST) + select REGMAP_MMIO + help + Select this option to enable the Texas Instruments Enhanced Quadrature + Encoder Pulse (eQEP) counter driver. + + To compile this driver as a module, choose M here: the module will be + called ti-eqep. + config FTM_QUADDEC tristate "Flex Timer Module Quadrature decoder driver" depends on HAS_IOMEM && OF diff --git a/drivers/counter/Makefile b/drivers/counter/Makefile index 40d35522937d..55142d1f4c43 100644 --- a/drivers/counter/Makefile +++ b/drivers/counter/Makefile @@ -8,4 +8,5 @@ obj-$(CONFIG_COUNTER) += counter.o obj-$(CONFIG_104_QUAD_8) += 104-quad-8.o obj-$(CONFIG_STM32_TIMER_CNT) += stm32-timer-cnt.o obj-$(CONFIG_STM32_LPTIMER_CNT)+= stm32-lptimer-cnt.o +obj-$(CONFIG_TI_EQEP) += ti-eqep.o obj-$(CONFIG_FTM_QUADDEC) += ftm-quaddec.o diff --git a/drivers/counter/ti-eqep.c b/drivers/counter/ti-eqep.c new file mode 100644 index ..4b3ef2449c06 --- /dev/null +++ b/drivers/counter/ti-eqep.c @@ -0,0 +1,473 @@ +// SPDX-License-Identifier: GPL-2.0-only +/* + * Copyright (C) 2019 David Lechner + * + * Counter driver for Texas Instruments Enhanced Quadrature Encoder Pulse (eQEP) + */ + +#include +#include +#include +#include +#include +#include +#include +#include + +/* 32-bit registers */ +#define QPOSCNT0x0 +#define QPOSINIT 0x4 +#define QPOSMAX0x8 +#define QPOSCMP0xc +#define QPOSILAT 0x10 +#define QPOSSLAT 0x14 +#define QPOSLAT0x18 +#define QUTMR 0x1c +#define QUPRD 0x20 + +/* 16-bit registers */ +#define QWDTMR 0x0 /* 0x24 */ +#define QWDPRD 0x2 /* 0x26 */ +#define QDECCTL0x4 /* 0x28 */ +#define QEPCTL 0x6 /* 0x2a */ +#define QCAPCTL0x8 /* 0x2c */ +#define QPOSCTL0xa /* 0x2e */ +#define QEINT 0xc /* 0x30 */ +#define QFLG 0xe /* 0x32 */ +#define QCLR 0x10/* 0x34 */ +#define QFRC 0x12/* 0x36 */ +#define QEPSTS 0x14/* 0x38 */ +#define QCTMR 0x16/* 0x3a */ +#define QCPRD 0x18/* 0x3c */ +#define QCTMRLAT 0x1a/* 0x3e */ +#define QCPRDLAT 0x1c/* 0x40 */ + +#define QDECCTL_QSRC_SHIFT 14 +#define QDECCTL_QSRC
[PATCH v3 4/6] ARM: dts: am33xx: Add nodes for eQEP
This adds new nodes for the Texas Instruments Enhanced Quadrature
Encoder Pulse (eQEP) module in the PWM subsystem on AM33XX.
Signed-off-by: David Lechner
---
v3 changes:
- rename eqep@ to counter@
v2 changes:
- clocks renamed to "sysclkout"
arch/arm/boot/dts/am33xx-l4.dtsi | 27 +++
1 file changed, 27 insertions(+)
diff --git a/arch/arm/boot/dts/am33xx-l4.dtsi b/arch/arm/boot/dts/am33xx-l4.dtsi
index 3b1fb2ba4dff..8dd5fd9eb862 100644
--- a/arch/arm/boot/dts/am33xx-l4.dtsi
+++ b/arch/arm/boot/dts/am33xx-l4.dtsi
@@ -1908,6 +1908,15 @@
status = "disabled";
};
+ eqep0: counter@180 {
+ compatible = "ti,am3352-eqep";
+ reg = <0x180 0x80>;
+ clocks = <_gclk>;
+ clock-names = "sysclkout";
+ interrupts = <79>;
+ status = "disabled";
+ };
+
ehrpwm0: pwm@200 {
compatible = "ti,am3352-ehrpwm",
"ti,am33xx-ehrpwm";
@@ -1961,6 +1970,15 @@
status = "disabled";
};
+ eqep1: counter@180 {
+ compatible = "ti,am3352-eqep";
+ reg = <0x180 0x80>;
+ clocks = <_gclk>;
+ clock-names = "sysclkout";
+ interrupts = <88>;
+ status = "disabled";
+ };
+
ehrpwm1: pwm@200 {
compatible = "ti,am3352-ehrpwm",
"ti,am33xx-ehrpwm";
@@ -2014,6 +2032,15 @@
status = "disabled";
};
+ eqep2: counter@180 {
+ compatible = "ti,am3352-eqep";
+ reg = <0x180 0x80>;
+ clocks = <_gclk>;
+ clock-names = "sysclkout";
+ interrupts = <89>;
+ status = "disabled";
+ };
+
ehrpwm2: pwm@200 {
compatible = "ti,am3352-ehrpwm",
"ti,am33xx-ehrpwm";
--
2.17.1
Re: kernel panic: stack is corrupted in __lock_acquire (4)
syzbot has found a reproducer for the following crash on: HEAD commit:38320f69 Merge branch 'Minor-cleanup-in-devlink' git tree: net-next console output: https://syzkaller.appspot.com/x/log.txt?x=13d7435660 kernel config: https://syzkaller.appspot.com/x/.config?x=1bbf70b6300045af dashboard link: https://syzkaller.appspot.com/bug?extid=83979935eb6304f8cd46 compiler: gcc (GCC) 9.0.0 20181231 (experimental) syz repro: https://syzkaller.appspot.com/x/repro.syz?x=1008b23260 IMPORTANT: if you fix the bug, please add the following tag to the commit: Reported-by: syzbot+83979935eb6304f8c...@syzkaller.appspotmail.com Kernel panic - not syncing: stack-protector: Kernel stack is corrupted in: __lock_acquire+0x36fa/0x4c30 kernel/locking/lockdep.c:3907 CPU: 0 PID: 8662 Comm: syz-executor.4 Not tainted 5.3.0-rc6+ #153 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: Kernel Offset: disabled Rebooting in 86400 seconds..
Re: [PATCH] drivers/staging/exfat - by default, prohibit mount of fat/vfat
On Sat, Aug 31, 2019 at 11:37:27PM -0400, Valdis Klētnieks wrote: > On Sun, 01 Sep 2019 11:07:21 +1000, Dave Chinner said: > > Totally irrelevant to the issue at hand. You can easily co-ordinate > > out of tree contributions through a github tree, or a tree on > > kernel.org, etc. > > Well.. I'm not personally wedded to the staging tree. I'm just interested in > getting a driver done and upstreamed with as little pain as possible. :) Understood - I'm trying to head off you guys getting delayed by sitting for a year in the staging tree polishing a turd and not addressing the things that really need to be done first... > Is there any preference for github versus kernel.org? I can set up a github > tree on my own, no idea who needs to do what for a kernel.org tree. What ever is most convenient for you to manage and co-ordinate. :P > Also, this (from another email of yours) was (at least to me) the most useful > thing said so far: > > > look at what other people have raised w.r.t. to that filesystem - > > on-disk format validation, re-implementation of largely generic > > code, lack of namespacing of functions leading to conflicts with > > generic/VFS functionality, etc. > > All of which are now on the to-do list, thanks. > > Now one big question: > > Should I heave all the vfat stuff overboard and make a module that > *only* does exfat, or is there enough interest in an extended FAT module > that does vfat and extfat, in which case the direction should be to re-align > this module's code with vfat? I don't know the details of the exfat spec or the code to know what the best approach is. I've worked fairly closely with Christoph for more than a decade - you need to think about what he says rather than /how he says it/ because there's a lot of thought and knowledge behind his reasoning. Hence if I were implementing exfat and Christoph was saying "throw it away and extend fs/fat" then that's what I'd be doing. A lot of this is largely risk management - there's a good chance that the people developing the code move on after the project is done and merged, which leaves the people like Christoph with the burden of long term code maintenance for that filesystem. There's enough crusty, old, largely unmaintained filesystem code already, and we don't want more. Implementing exfat on top of fs/fat kills two birds with one stone - it modernises the fs/fat code base and brings new functionality that will have more developers interested in maintaining it over the long term. So from an overall filesystem maintenance perspective, building on top of fs/fat makes a lot of sense to a kernel filesystem developer... This is not a judgement on the quality of the existing exfat code or it's developers - it's just that there are very good reasons for building on existing codebase rather than creating a whole new code base that has very similar functionality. That's my total involvement in this - I don't really care about exfat at all - my stake in this is to improve the development, review and merge process being undertaken. We have a history of lax review, poor processes and really shitty code being merged into the kernel and I've been on the cleanup squad for a few of them over the past couple of years. That's a burnout vector, so it's in the interests of my own sanity (and fs developers) to set standards and precedence to prevent more trainwrecks from happening before the train even leaves the station... > > That's the choice you have to make now: listen to the reviewers > > saying "resolve the fundamental issues before goign any further", > > Well... *getting* a laundry list of what the reviewers see as the fundamental > issues is the first step in resolving them ;) You won't get them all at once. You'll get something new every round of review as the bigger issues are worked out, the reviewers become more familiar with the code and notice more detailed/subtle issues. Most filesystem reviews start with developers trying to understand the on-disk structure and architecture rather that focus on whitespace and code cleanliness. Cleaning up the code can be done after we work through all the structural issues... Cheers, Dave. -- Dave Chinner da...@fromorbit.com
Re: [PATCH] tracing: Fix histogram referencing a variable
Hi Steve,
On Mon, 2019-08-26 at 22:44 -0400, Steven Rostedt wrote:
> From: Steven Rostedt (VMware)
>
> I performed a three way histogram with the following commands:
>
> echo 'irq_lat u64 lat pid_t pid' > synthetic_events
> echo 'wake_lat u64 lat u64 irqlat pid_t pid' >> synthetic_events
> echo 'hist:keys=common_pid:irqts=common_timestamp.usecs if function ==
> 0x81200580' > events/timer/hrtimer_start/trigger
> echo
> 'hist:keys=common_pid:lat=common_timestamp.usecs-$irqts:onmatch(timer.hrtimer_start).irq_lat($lat,pid)
> if common_flags & 1' > events/sched/sched_waking/trigger
> echo 'hist:keys=pid:wakets=common_timestamp.usecs,irqlat=lat' >
> events/synthetic/irq_lat/trigger
> echo
> 'hist:keys=next_pid:lat=common_timestamp.usecs-$wakets,irqlat=$irqlat:onmatch(synthetic.irq_lat).wake_lat($lat,$irqlat,next_pid)'
> > events/sched/sched_switch/trigger
> echo 1 > events/synthetic/wake_lat/enable
>
Thanks for digging into this and providing a patch. Looking into it
myself, I think the problem is actually in the alias-creation code
(which gets invoked for where you do irqlat=$irqlat). In that code,
the alias's var_ref_idx is always 0, so you get whatever's there rather
than the correct value if it should be something other than 0.
The patch below fixes that - I used your original commit message but
changed the last sentence and the offending commit that introduced the
problem, and of course the one-line code change is different too. Let
me know if that works for you.
Thanks,
Tom
[PATCH] tracing: Make sure variable reference alias has correct var_ref_idx
Original changelog from Steve Rostedt (except last sentence which
explains the problem, and the Fixes: tag):
I performed a three way histogram with the following commands:
echo 'irq_lat u64 lat pid_t pid' > synthetic_events
echo 'wake_lat u64 lat u64 irqlat pid_t pid' >> synthetic_events
echo 'hist:keys=common_pid:irqts=common_timestamp.usecs if function ==
0x81200580' > events/timer/hrtimer_start/trigger
echo
'hist:keys=common_pid:lat=common_timestamp.usecs-$irqts:onmatch(timer.hrtimer_start).irq_lat($lat,pid)
if common_flags & 1' > events/sched/sched_waking/trigger
echo 'hist:keys=pid:wakets=common_timestamp.usecs,irqlat=lat' >
events/synthetic/irq_lat/trigger
echo
'hist:keys=next_pid:lat=common_timestamp.usecs-$wakets,irqlat=$irqlat:onmatch(synthetic.irq_lat).wake_lat($lat,$irqlat,next_pid)'
> events/sched/sched_switch/trigger
echo 1 > events/synthetic/wake_lat/enable
Basically I wanted to see:
hrtimer_start (calling function tick_sched_timer)
Note:
# grep tick_sched_timer /proc/kallsyms
81200580 t tick_sched_timer
And save the time of that, and then record sched_waking if it is called
in interrupt context and with the same pid as the hrtimer_start, it
will record the latency between that and the waking event.
I then look at when the task that is woken is scheduled in, and record
the latency between the wakeup and the task running.
At the end, the wake_lat synthetic event will show the wakeup to
scheduled latency, as well as the irq latency in from hritmer_start to
the wakeup. The problem is that I found this:
-0 [007] d... 190.485261: wake_lat: lat=27
irqlat=190485230 pid=698
-0 [005] d... 190.485283: wake_lat: lat=40
irqlat=190485239 pid=10
-0 [002] d... 190.488327: wake_lat: lat=56
irqlat=190488266 pid=335
-0 [005] d... 190.489330: wake_lat: lat=64
irqlat=190489262 pid=10
-0 [003] d... 190.490312: wake_lat: lat=43
irqlat=190490265 pid=77
-0 [005] d... 190.493322: wake_lat: lat=54
irqlat=190493262 pid=10
-0 [005] d... 190.497305: wake_lat: lat=35
irqlat=190497267 pid=10
-0 [005] d... 190.501319: wake_lat: lat=50
irqlat=190501264 pid=10
The irqlat seemed quite large! Investigating this further, if I had
enabled the irq_lat synthetic event, I noticed this:
-0 [002] d.s. 249.429308: irq_lat: lat=164968 pid=335
-0 [002] d... 249.429369: wake_lat: lat=55
irqlat=249429308 pid=335
Notice that the timestamp of the irq_lat "249.429308" is awfully
similar to the reported irqlat variable. In fact, all instances were
like this. It appeared that:
irqlat=$irqlat
Wasn't assigning the old $irqlat to the new irqlat variable, but
instead was assigning the $irqts to it.
The issue is that assigning the old $irqlat to the new irqlat variable
creates a variable reference alias, but the alias creation code
forgets to make sure the alias uses the same var_ref_idx to access the
reference.
Cc: sta...@vger.kernel.org
Fixes: 7e8b88a30b085 ("tracing: Add hist trigger support for variable reference
aliases")
Reported-by: Steven Rostedt (VMware)
Signed-off-by: Steven Rostedt (VMware)
Signed-off-by: Tom Zanussi
---
kernel/trace/trace_events_hist.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/kernel/trace/trace_events_hist.c
[PATCH V2] x86/boot: Fix regression--secure boot info loss from bootparam sanitizing
From: "John S. Gruber"
commit a90118c445cc ("x86/boot: Save fields explicitly, zero out everything
else") now zeros the secure boot information passed by the boot loader or
by the kernel's efi handover mechanism. Include boot-params.secure_boot
in the preserve field list.
I noted a change in my computers between running signed 5.3-rc4 and 5.3-rc6
with signed kernels using the efi handoff protocol with grub. The kernel
log message "Secure boot enabled" becomes "Secure boot could not be
determined". The efi_main function in arch/x86/boot/compressed/eboot.c sets
this field early but it is subsequently zeroed by the above referenced
commit in the file arch/x86/include/asm/bootparam_utils.h
Fixes: commit a90118c445cc ("x86/boot: Save fields explicitly, zero
out everything else")
Signed-off-by: John S. Gruber
---
Adjusted the patch for John Hubbard's comments.
arch/x86/include/asm/bootparam_utils.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/x86/include/asm/bootparam_utils.h
b/arch/x86/include/asm/bootparam_utils.h
index 9e5f3c7..981fe92 100644
--- a/arch/x86/include/asm/bootparam_utils.h
+++ b/arch/x86/include/asm/bootparam_utils.h
@@ -70,6 +70,7 @@ static void sanitize_boot_params(struct boot_params
*boot_params)
BOOT_PARAM_PRESERVE(eddbuf_entries),
BOOT_PARAM_PRESERVE(edd_mbr_sig_buf_entries),
BOOT_PARAM_PRESERVE(edd_mbr_sig_buffer),
+ BOOT_PARAM_PRESERVE(secure_boot),
BOOT_PARAM_PRESERVE(hdr),
BOOT_PARAM_PRESERVE(e820_table),
BOOT_PARAM_PRESERVE(eddbuf),
--
2.7.4
Re: linux-next: Signed-off-by missing for commit in the asm-generic tree
On Sun, Sep 1, 2019 at 11:19 PM Stephen Rothwell wrote:
>
> Hi all,
>
> Commit
>
> adea510eaf35 ("__div64_const32(): improve the generic C version")
>
> is missing a Signed-off-by from its committer.
Fixed, thanks for pointing it out!
Arnd
Re: [PATCHv1 1/3] arm64: dts: meson: odroid-c2: Add missing regulator linked to P5V0 regulator
Hi Anand, On Sun, Sep 1, 2019 at 3:58 PM Anand Moon wrote: > > Hi Martin, > > Thanks for your review comments. > > Their have been some revision changes in S905 Odroid Schematics. > [0] https://dn.odroid.com/S905/Schematic/ > > Well I have make my changes based on old odroid-c2_rev0.2_20151218.pdf [...] > > > > according to the schematics there's both: > > - VDDIO_AO3V3 > > - VCC3V3 (which is turned on by VDDIO_AO3V3, see [0]) > > > > From the schematics it seams same. > > VDDIO_AO3V3---DMG340LSQN4 (Q4)---VCC3V3 yes, they are the same signal. the only difference is that VCC3V3 is turned on later in the power-up sequence > But this name change was done to link TFLASH_VDD_EN to TFLASH_VDD for eMMC > > VDDIO_AO3V3-TFLASH_VDD using TFLASH_VDD_EN gpio pin. > > Well I have tested this changes on eMMC module. I cannot see any of the TFLASH_* regulators being linked to eMMC (they are only linked to the SD card slot, I also checked odroid-c2_rev0.2_20151218.pdf and odroid-c2_rev0.2_20171114.pdf). which page of the odroid-c2_rev0.2_20151218.pdf schematics shows how TFLASH_VDD is linked to eMMC? please note that I don't have an Odroid-C2 board myself (so I cannot test any of this). Martin
Re: [PATCH v5 00/18] add thermal driver for h6
Hello Yangtao, On Sat, Aug 10, 2019 at 05:28:11AM +, Yangtao Li wrote: > This patchset add support for A64, H3, H5, H6 and R40 thermal sensor. > > Thx to Icenowy and Vasily. > > BTY, do a cleanup in thermal makfile. I've added support for A83T and also some cleanups, according to my feedback: https://megous.com/git/linux/log/?h=ths-5.3 Feel free to pick up whatever you like from that tree. For others, there are also DTS patches in that tree for H3, H5, A83T, and H6, so that shoul make testing of this driver easier. regards, Ondrej > Icenowy Zheng (3): > thermal: sun8i: allow to use custom temperature calculation function > thermal: sun8i: add support for Allwinner H5 thermal sensor > thermal: sun8i: add support for Allwinner R40 thermal sensor > > Vasily Khoruzhick (1): > thermal: sun8i: add thermal driver for A64 > > Yangtao Li (14): > thermal: sun8i: add thermal driver for h6 > dt-bindings: thermal: add binding document for h6 thermal controller > thermal: fix indentation in makefile > thermal: sun8i: get ths sensor number from device compatible > thermal: sun8i: rework for sun8i_ths_get_temp() > thermal: sun8i: get ths init func from device compatible > thermal: sun8i: rework for ths irq handler func > thermal: sun8i: support mod clocks > thermal: sun8i: rework for ths calibrate func > dt-bindings: thermal: add binding document for h3 thermal controller > thermal: sun8i: add thermal driver for h3 > dt-bindings: thermal: add binding document for a64 thermal controller > dt-bindings: thermal: add binding document for h5 thermal controller > dt-bindings: thermal: add binding document for r40 thermal controller > > .../bindings/thermal/sun8i-thermal.yaml | 157 + > MAINTAINERS | 7 + > drivers/thermal/Kconfig | 14 + > drivers/thermal/Makefile | 9 +- > drivers/thermal/sun8i_thermal.c | 596 ++ > 5 files changed, 779 insertions(+), 4 deletions(-) > create mode 100644 > Documentation/devicetree/bindings/thermal/sun8i-thermal.yaml > create mode 100644 drivers/thermal/sun8i_thermal.c > > --- > v5: > -add more support > -some trival fix > --- > 2.17.1 > > > ___ > linux-arm-kernel mailing list > linux-arm-ker...@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
linux-next: Fixes tag needs some work in the kselftest tree
Hi all,
In commit
c321d43b8da1 ("selftests/seccomp: fix build on older kernels")
Fixes tag
Fixes: Commit 201766a20e30 ("ptrace: add PTRACE_GET_SYSCALL_INFO request")
has these problem(s):
- leading word 'Commit' unexpected
--
Cheers,
Stephen Rothwell
pgpaqfcSGqaLX.pgp
Description: OpenPGP digital signature
Re: [PATCH v2 2/2] reset: Reset controller driver for Intel LGM SoC
Hi,
On Fri, Aug 30, 2019 at 5:02 AM Chuan Hua, Lei
wrote:
>
> Hi Martin,
>
> On 8/30/2019 5:40 AM, Martin Blumenstingl wrote:
> > Hi,
> >
> > On Thu, Aug 29, 2019 at 4:51 AM Chuan Hua, Lei
> > wrote:
> >
> >>> I'm not surprised that we got some of the IP block layout for the
> >>> VRX200 RCU "wrong" - all "documentation" we have is the old Lantiq UGW
> >>> (BSP).
> >>> with proper documentation (as in a "public datasheet for the SoC") it
> >>> would be easy to spot these mistakes (at least I assume that the
> >>> quality of the Infineon / Lantiq datasheets is excellent).
> >>>
> >>> back to reset-intel-syscon:
> >>> assigning only one job to the RCU hardware is a good idea (in my opinion).
> >>> that brings up a question: why do we need the "syscon" compatible for
> >>> the RCU node?
> >>> this is typically used when registers are accessed by another IP block
> >>> and the other driver has to access these registers as well. does this
> >>> mean that there's more hidden in the RCU registers?
> >> As I mentioned, some other misc registers are put into RCU even they
> >> don't belong to reset functions.
> > OK, just be aware that there are also rules for syscon compatible
> > drivers, see for example: [0]
> > if Rob (dt-bindings maintainer) is happy with the documentation in
> > patch 1 then I'm fine with it as well.
> > for my own education I would appreciate if you could describe these
> > "other misc registers" with a few sentences (I assume that this can
> > also help Rob)
> For LGM, RCU is clean. There would be no MISC register after software's
> feedback. These misc registers will be moved to chiptop/misc
> groups(implemented by syscon). For legacy SoC, we do have a lot MISC
> registers for different SoCs.
OK, I think I understand now: chiptop != RCU
so RCU really only has one purpose: handling resets
while chiptop manages all the random bits
does this means we don't need RCU to match "syscon"?
> >
> > [...]
> 4. Code not optimized and intel internal review not assessed.
> >>> insights from you (like the issue with the reset callback) are very
> >>> valuable - this shows that we should focus on having one driver.
> >>>
> Based on the above findings, I would suggest reset-lantiq.c to move
> to
> reset-intel-syscon.c
> >>> my concern with having two separate drivers is that it will be hard to
> >>> migrate from reset-lantiq to the "optimized" reset-intel-syscon
> >>> driver.
> >>> I don't have access to the datasheets for the any Lantiq/Intel SoC
> >>> (VRX200 and even older).
> >>> so debugging issues after switching from one driver to another is
> >>> tedious because I cannot tell which part of the driver is causing a
> >>> problem (it's either "all code from driver A" vs "all code from driver
> >>> B", meaning it's hard to narrow it down).
> >>> with separate commits/patches that are improving the reset-lantiq
> >>> driver I can do git bisect to find the cause of a problem on the older
> >>> SoCs (VRX200 for example)
> >> Our internal version supports XRX350/XRX500/PRX300(MIPS based) and
> >> latest Lighting Mountain(X86 based). Migration to reset-intel-syscon.c
> >> should be straight forward.
> > what about the _reset callback on the XRX350/XRX500/PRX300 SoCs - do
> > they only use level resets (_assert and _deassert) or are some reset
> > lines using reset pulses (_reset)?
> >
> > when we wanted to switch from reset-lantiq.c to reset-intel-syscon.c
> > we still had to add support for the _reset callback as this is missing
> > in reset-intel-syscon.c currently
> Yes. We have reset pulse(assert, then check the reset status).
> >>> only now I realized that the reset-intel-syscon driver does not seem
> >>> to use the status registers (instead it's looking at the reset
> >>> registers when checking the status).
> >>> what happened to the status registers - do they still exist in newer
> >>> SoCs (like LGM)? why are they not used?
> >> Reset status check is there. regmap_read_poll_timeout to check status
> >> big. Status register offset <4) from request register. For legacy, there
> >> is one exception, we can add soc specific data to handle it.
> > I see, thank you for the explanation
> > this won't work on VRX200 for example because the status register is
> > not always at (reset register - 0x4)
>
> As I mentioned, VRX200 and all legacy SoCs (MIPS based) can be solved
> with one soc data in the compatible array.
>
> For example(not same as upstream, but idea is similar)
>
> static u32 intel_stat_reg_off(struct intel_reset_data *data, u32 req_off)
> {
> if (data->soc_data->legacy && req_off == RCU_RST_REQ)
> return RCU_RST_STAT;
> else
> return req_off + 0x4;
> }
>
> >
> >>> on VRX200 for example there seem to be some cases where the bits in
> >>> the reset and status registers are different (for example: the first
> >>> GPHY seems
linux-next: Fixes tag needs some work in the iommu tree
Hi all,
In commit
7893b59b1e2d ("iommu/vt-d: Remove global page flush support")
Fixes tag
Fixes: 1c4f88b7f1f9 ("iommu/vt-d: Shared virtual address in scalable
has these problem(s):
- Subject has leading but no trailing parentheses
- Subject has leading but no trailing quotes
In commit
b9475b3471f8 ("iommu/mediatek: Fix VLD_PA_RNG register backup when suspend")
Fixes tag
Fixes: 30e2fccf9512 ("iommu/mediatek: Enlarge the validate PA range
has these problem(s):
- Subject has leading but no trailing parentheses
- Subject has leading but no trailing quotes
In commit
76ce65464fcd ("iommu/mediatek: Fix iova_to_phys PA start for 4GB mode")
Fixes tag
Fixes: 30e2fccf9512 ("iommu/mediatek: Enlarge the validate PA range
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
pgpbmTzqgdeK9.pgp
Description: OpenPGP digital signature
linux-next: Signed-off-by missing for commit in the tpmdd tree
Hi all,
Commit
8dbcb44f392e ("tpm_tis_core: Set TPM_CHIP_FLAG_IRQ before probing for
interrupts")
is missing a Signed-off-by from its committer.
--
Cheers,
Stephen Rothwell
pgpuSZHOKd4Zg.pgp
Description: OpenPGP digital signature
