[PATCH] Input: cros_ec_keyb: mask out extra flags in event_type
http://crosreview.com/1341159 added a EC_MKBP_HAS_MORE_EVENTS flag to
the event_type field, the receiver side should mask out this extra bit when
processing the event.
Signed-off-by: Ting Shen
---
drivers/input/keyboard/cros_ec_keyb.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/input/keyboard/cros_ec_keyb.c
b/drivers/input/keyboard/cros_ec_keyb.c
index d5600118159835..38cb6d82d8fe67 100644
--- a/drivers/input/keyboard/cros_ec_keyb.c
+++ b/drivers/input/keyboard/cros_ec_keyb.c
@@ -237,7 +237,7 @@ static int cros_ec_keyb_work(struct notifier_block *nb,
if (queued_during_suspend && !device_may_wakeup(ckdev->dev))
return NOTIFY_OK;
- switch (ckdev->ec->event_data.event_type) {
+ switch (ckdev->ec->event_data.event_type & EC_MKBP_EVENT_TYPE_MASK) {
case EC_MKBP_EVENT_KEY_MATRIX:
pm_wakeup_event(ckdev->dev, 0);
--
2.22.0.rc2.383.gf4fbbf30c2-goog
Re: [PATCH v7 18/18] x86/fsgsbase/64: Add documentation for FSGSBASE
On Wed, 8 May 2019, Chang S. Bae wrote: > Subject: x86/fsgsbase/64: Add documentation for FSGSBASE The proper prefix is Documentation/x86: > From: Andi Kleen > > v2: Minor updates to documentation requested in review. > v3: Update for new gcc and various improvements. > v4: Address the typos pointed by Randy Dunlap Please move the vX annoations below the --- marker so they are stripped out automatically and I don't have to do it manually. They are not part of the final changelog. > Documentation/x86/fsgs.txt | 103 > + The x86 documentation got converted to RST recently. Also as this is a 64bit specific documentation it belongs into Documentation/x86/x86_64 and not into the generic x86 directory. > +++ b/Documentation/x86/fsgs.txt > @@ -0,0 +1,103 @@ > + Documentation files require a SPDX license identifier as any other file. > +Using FS and GS prefixes on 64-bit x86 linux Moving this into the 64 bit specific folder spares all the 'oh this is 64bit only' notices all over the place. > + > +The x86 architecture supports segment prefixes per instruction to add an per instruction? It's only for instructions which access memory, not for instructions which are purely register based. > +offset to an address. On 64-bit x86, these are mostly nops, except for FS > +and GS. > + > +This offers an efficient way to reference a global pointer. That sentence does not make any sense. What has this to do with global pointers? > +The compiler has to generate special code to use these base registers, > +or they can be accessed with inline assembler. > + > + mov %gs:offset,%reg > + mov %fs:offset,%reg > + > +On 64-bit code, FS is used to address the thread local segment (TLS), > declared TLS is Thread Local Storage not Segment. > +using thread. The compiler then automatically generates the correct prefixes What means: declared using thread? I assume you meant declared with the __thread storage class specifier. If so, why not using the proper technical terms? > +and relocations to access these values. > + > +FS is normally managed by the runtime code or the threading library. > +Overwriting it can break a lot of things (including syscalls and gdb), > +but it can make sense to save/restore it for threading purposes. > + > +GS is freely available, but may need special (compiler or inline assembler) > +code to use. > + > +Traditionally 64-bit FS and GS could be set by the arch_prctl system call I don't see a tradition here and 'could' is just wrong. > + > + arch_prctl(ARCH_SET_GS, value) > + arch_prctl(ARCH_SET_FS, value) > + > +[There was also an older method using modify_ldt(), inherited from 32-bit, > +but this is not discussed here.] So why is it even mentioned when it's not longer existing? > +However, using a syscall is problematic for user space threading libraries > +that want to context switch in user space. The whole point of them > +is avoiding the overhead of a syscall. User space threading libraries are one particular use case and not really interesting for documenting this functionality. Documentation is about the concepts and not about what a particular usecase prefers. > It's also cleaner for compilers > +wanting to use the extra register to use instructions to write > +it, or read it directly to compute addresses and offsets. I don't see the value of this either. > +Newer Intel CPUs (Ivy Bridge and later) added new instructions to directly > +access these registers quickly from user context: The CPUs added new instructions? > + RDFSBASE %reg read the FS base(or _readfsbase_u64) > + RDGSBASE %reg read the GS base(or _readgsbase_u64) > + > + WRFSBASE %reg write the FS base (or _writefsbase_u64) > + WRGSBASE %reg write the GS base (or _writegsbase_u64) > + > +If you use the intrinsics, include and set the -mfsgsbase > option. > + > +The instructions are supported by the CPU when the "fsgsbase" string is shown > +in /proc/cpuinfo (or directly retrieved through the CPUID instruction, > +7:0 (ebx), word 9, bit 0). > + > +The instructions are only available to 64-bit binaries. > + > +In addition the kernel needs to explicitly enable these instructions, as it > +may otherwise not correctly context switch the state. Newer Linux > +kernels enable this. When the kernel does not enable the instruction > +they will fault with a #UD exception. . This is completely unstructured information hastily cobbled together. As time is pressing for the 5.3 merge window, I reworked the documentation as below. Please review and comment ASAP so I can merge the whole lot. Thanks, tglx 8<-- From: Thomas Gleixner Subject: Documentation/x86/64: Add documentation for GS/FS addressing mode Date: Thu, 13 Jun 2019 22:04:24 +0300 Originally-by: Andi Kleen Signed-off-by: Thomas Gleixner --- Documentation/x86/x86_64/fsgs.rst | 200 +++
[PATCH v2] PCI: aardvark: Fix PCI_EXP_RTCTL conf register writing
PCI_EXP_RTCTL is used to activate PME interrupt only, so writing into it
should not modify other interrupts' mask. The ISR mask polarity was also
inverted, when PCI_EXP_RTCTL_PMEIE is set PCIE_MSG_PM_PME_MASK mask bit
should actually be cleared.
Fixes: 6302bf3ef78d ("PCI: Init PCIe feature bits for managed host bridge
alloc")
Signed-off-by: Remi Pommarel
---
Changes since v1:
* Improve code readability
* Fix mask polarity
* PME_MASK shift was off by one
---
drivers/pci/controller/pci-aardvark.c | 13 +
1 file changed, 9 insertions(+), 4 deletions(-)
diff --git a/drivers/pci/controller/pci-aardvark.c
b/drivers/pci/controller/pci-aardvark.c
index 134e0306ff00..f6e55c4597b1 100644
--- a/drivers/pci/controller/pci-aardvark.c
+++ b/drivers/pci/controller/pci-aardvark.c
@@ -415,7 +415,7 @@ advk_pci_bridge_emul_pcie_conf_read(struct pci_bridge_emul
*bridge,
case PCI_EXP_RTCTL: {
u32 val = advk_readl(pcie, PCIE_ISR0_MASK_REG);
- *value = (val & PCIE_MSG_PM_PME_MASK) ? PCI_EXP_RTCTL_PMEIE : 0;
+ *value = (val & PCIE_MSG_PM_PME_MASK) ? 0 : PCI_EXP_RTCTL_PMEIE;
return PCI_BRIDGE_EMUL_HANDLED;
}
@@ -451,10 +451,15 @@ advk_pci_bridge_emul_pcie_conf_write(struct
pci_bridge_emul *bridge,
advk_writel(pcie, new, PCIE_CORE_PCIEXP_CAP + reg);
break;
- case PCI_EXP_RTCTL:
- new = (new & PCI_EXP_RTCTL_PMEIE) << 3;
- advk_writel(pcie, new, PCIE_ISR0_MASK_REG);
+ case PCI_EXP_RTCTL: {
+ /* Only mask/unmask PME interrupt */
+ u32 val = advk_readl(pcie, PCIE_ISR0_MASK_REG) &
+ ~PCIE_MSG_PM_PME_MASK;
+ if ((new & PCI_EXP_RTCTL_PMEIE) == 0)
+ val |= PCIE_MSG_PM_PME_MASK;
+ advk_writel(pcie, val, PCIE_ISR0_MASK_REG);
break;
+ }
case PCI_EXP_RTSTA:
new = (new & PCI_EXP_RTSTA_PME) >> 9;
--
2.20.1
Re: [PATCH 1/8] platform: x86: acer-wmi: no need to check return value of debugfs_create functions
On Fri, Jun 14, 2019 at 09:48:04AM +0300, Andy Shevchenko wrote: > On Wed, Jun 12, 2019 at 3:13 PM Greg Kroah-Hartman > wrote: > > > > When calling debugfs functions, there is no need to ever check the > > return value. The function can work or not, but the code logic should > > never do something different based on this. > > > > Also, because there is no need to save the file dentry, remove the > > variable that was saving it and just recursively delete the whole > > directory. > > > > Through which tree you want to proceed this? What ever is easier for you, I can take it through mine, as I have a lot of other patches like this queued up already, or it can go through yours. thanks, greg k-h
[PATCH v2] usb: dwc2: Force 8bit UTMI width for Samsung Exynos SoCs
Samsung Exynos SoCs require to force UTMI width to 8bit, otherwise the
host side of the shared USB2 PHY doesn't work.
Reported-by: Krzysztof Kozlowski
Fixes: 707d80f0a3c5 ("usb: dwc2: gadget: Replace phyif with phy_utmi_width")
Signed-off-by: Marek Szyprowski
Acked-by: Minas Harutyunyan
Acked-by: Krzysztof Kozlowski
Tested-by: Krzysztof Kozlowski
---
v2:
- added collected tags
---
drivers/usb/dwc2/params.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/usb/dwc2/params.c b/drivers/usb/dwc2/params.c
index 6900eea57526..9ece4affb9d4 100644
--- a/drivers/usb/dwc2/params.c
+++ b/drivers/usb/dwc2/params.c
@@ -76,6 +76,7 @@ static void dwc2_set_s3c6400_params(struct dwc2_hsotg *hsotg)
struct dwc2_core_params *p = &hsotg->params;
p->power_down = 0;
+ p->phy_utmi_width = 8;
}
static void dwc2_set_rk_params(struct dwc2_hsotg *hsotg)
--
2.17.1
Re: [PATCH 5.1 000/155] 5.1.10-stable review
On Fri, Jun 14, 2019 at 01:44:56AM -0500, Jiunn Chang wrote: > On Fri, Jun 14, 2019 at 07:50:40AM +0200, Greg Kroah-Hartman wrote: > > On Thu, Jun 13, 2019 at 03:08:49PM -0500, Jiunn Chang wrote: > > > On Thu, Jun 13, 2019 at 10:31:52AM +0200, Greg Kroah-Hartman wrote: > > > > This is the start of the stable review cycle for the 5.1.10 release. > > > > There are 155 patches in this series, all will be posted as a response > > > > to this one. If anyone has any issues with these being applied, please > > > > let me know. > > > > > > > > Responses should be made by Sat 15 Jun 2019 07:54:40 AM UTC. > > > > Anything received after that time might be too late. > > > > > > > > The whole patch series can be found in one patch at: > > > > > > > > https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.1.10-rc1.gz > > > > or in the git tree and branch at: > > > > > > > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > > > > linux-5.1.y > > > > and the diffstat can be found below. > > > > > > > > thanks, > > > > > > > > greg k-h > > > > > > > > - > > > Compiled and booted. No regressions on x86_64. > > > > > > This is for 5.1.10-rc2 from git --no-pager log --oneline -1. > > > > What do you mean by 'git --no-pager log --oneline -1' ? > > Hello. I must have missed an email somewhere. The review request was for > 5.1.10-rc1 > but I only had 5.1.10-rc2 from the logs. Sorry for the confusion. Ah, thanks, that made sense. I pushed out a -rc2 because of some missed patches and dropping one as well. thanks, greg k-h
Re: [PATCH 1/8] platform: x86: acer-wmi: no need to check return value of debugfs_create functions
On Wed, Jun 12, 2019 at 3:13 PM Greg Kroah-Hartman
wrote:
>
> When calling debugfs functions, there is no need to ever check the
> return value. The function can work or not, but the code logic should
> never do something different based on this.
>
> Also, because there is no need to save the file dentry, remove the
> variable that was saving it and just recursively delete the whole
> directory.
>
Through which tree you want to proceed this?
> Cc: "Lee, Chun-Yi"
> Cc: Darren Hart
> Cc: Andy Shevchenko
> Cc: platform-driver-...@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> Signed-off-by: Greg Kroah-Hartman
> ---
> drivers/platform/x86/acer-wmi.c | 29 +
> 1 file changed, 5 insertions(+), 24 deletions(-)
>
> diff --git a/drivers/platform/x86/acer-wmi.c b/drivers/platform/x86/acer-wmi.c
> index 521b526cd467..f8f0e98b1f0b 100644
> --- a/drivers/platform/x86/acer-wmi.c
> +++ b/drivers/platform/x86/acer-wmi.c
> @@ -259,7 +259,6 @@ struct acer_data {
>
> struct acer_debug {
> struct dentry *root;
> - struct dentry *devices;
> u32 wmid_devices;
> };
>
> @@ -2148,29 +2147,15 @@ static struct platform_device *acer_platform_device;
>
> static void remove_debugfs(void)
> {
> - debugfs_remove(interface->debug.devices);
> - debugfs_remove(interface->debug.root);
> + debugfs_remove_recursive(interface->debug.root);
> }
>
> -static int __init create_debugfs(void)
> +static void __init create_debugfs(void)
> {
> interface->debug.root = debugfs_create_dir("acer-wmi", NULL);
> - if (!interface->debug.root) {
> - pr_err("Failed to create debugfs directory");
> - return -ENOMEM;
> - }
>
> - interface->debug.devices = debugfs_create_u32("devices", S_IRUGO,
> - interface->debug.root,
> - &interface->debug.wmid_devices);
> - if (!interface->debug.devices)
> - goto error_debugfs;
> -
> - return 0;
> -
> -error_debugfs:
> - remove_debugfs();
> - return -ENOMEM;
> + debugfs_create_u32("devices", S_IRUGO, interface->debug.root,
> + &interface->debug.wmid_devices);
> }
>
> static int __init acer_wmi_init(void)
> @@ -2300,9 +2285,7 @@ static int __init acer_wmi_init(void)
>
> if (wmi_has_guid(WMID_GUID2)) {
> interface->debug.wmid_devices = get_wmid_devices();
> - err = create_debugfs();
> - if (err)
> - goto error_create_debugfs;
> + create_debugfs();
> }
>
> /* Override any initial settings with values from the commandline */
> @@ -2310,8 +2293,6 @@ static int __init acer_wmi_init(void)
>
> return 0;
>
> -error_create_debugfs:
> - platform_device_del(acer_platform_device);
> error_device_add:
> platform_device_put(acer_platform_device);
> error_device_alloc:
> --
> 2.22.0
>
--
With Best Regards,
Andy Shevchenko
Re: [PATCH 5.1 000/155] 5.1.10-stable review
On Fri, Jun 14, 2019 at 07:50:40AM +0200, Greg Kroah-Hartman wrote: > On Thu, Jun 13, 2019 at 03:08:49PM -0500, Jiunn Chang wrote: > > On Thu, Jun 13, 2019 at 10:31:52AM +0200, Greg Kroah-Hartman wrote: > > > This is the start of the stable review cycle for the 5.1.10 release. > > > There are 155 patches in this series, all will be posted as a response > > > to this one. If anyone has any issues with these being applied, please > > > let me know. > > > > > > Responses should be made by Sat 15 Jun 2019 07:54:40 AM UTC. > > > Anything received after that time might be too late. > > > > > > The whole patch series can be found in one patch at: > > > > > > https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.1.10-rc1.gz > > > or in the git tree and branch at: > > > > > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > > > linux-5.1.y > > > and the diffstat can be found below. > > > > > > thanks, > > > > > > greg k-h > > > > > > - > > Compiled and booted. No regressions on x86_64. > > > > This is for 5.1.10-rc2 from git --no-pager log --oneline -1. > > What do you mean by 'git --no-pager log --oneline -1' ? Hello. I must have missed an email somewhere. The review request was for 5.1.10-rc1 but I only had 5.1.10-rc2 from the logs. Sorry for the confusion. > > thanks for testing, > > greg k-h
[PATCH v3 03/10] powerpc/8xx: compact microcode arrays
Compact obscure microcode arrays by putting 4 values per line
in order to reduce number of lines in the file to increase
readability.
Signed-off-by: Christophe Leroy
---
arch/powerpc/platforms/8xx/micropatch.c | 699 +++-
1 file changed, 140 insertions(+), 559 deletions(-)
diff --git a/arch/powerpc/platforms/8xx/micropatch.c
b/arch/powerpc/platforms/8xx/micropatch.c
index 7bbaf9914f32..e14b6bcadce3 100644
--- a/arch/powerpc/platforms/8xx/micropatch.c
+++ b/arch/powerpc/platforms/8xx/micropatch.c
@@ -27,153 +27,45 @@
#ifdef CONFIG_I2C_SPI_UCODE_PATCH
static uint patch_2000[] __initdata = {
- 0x7FFFEFD9,
- 0x3FFD,
- 0x7FFB49F7,
- 0x7FF9,
- 0x5FEFADF7,
- 0x5F89ADF7,
- 0x5FEFAFF7,
- 0x5F89AFF7,
- 0x3A9CFBC8,
- 0xE7C0EDF0,
- 0x77C1E1BB,
- 0xF4DC7F1D,
- 0xABAD932F,
- 0x4E08FDCF,
- 0x6E0FAFF8,
- 0x7CCF76CF,
- 0xFD1FF9CF,
- 0xABF88DC6,
- 0xAB5679F7,
- 0xB0937383,
- 0xDFCE79F7,
- 0xB091E6BB,
- 0xE5BBE74F,
- 0xB3FA6F0F,
- 0x6FFB76CE,
- 0xEE0DF9CF,
- 0x2BFBEFEF,
- 0xCFEEF9CF,
- 0x76CEAD24,
- 0x90B2DF9A,
- 0x7FDDD0BF,
- 0x4BF847FD,
- 0x7CCF76CE,
- 0xCFEF7E1F,
- 0x7F1D7DFD,
- 0xF0B6EF71,
- 0x7FC177C1,
- 0xFBC86079,
- 0xE722FBC8,
- 0x5FFFDFFF,
- 0x5FB2FFFB,
- 0xFBC8F3C8,
- 0x94A67F01,
- 0x7F1D5F39,
- 0xAFE85F5E,
- 0xFFDFDF96,
- 0xCB9FAF7D,
- 0x5FC1AFED,
- 0x8C1C5FC1,
- 0xAFDD5FC3,
- 0xDF9A7EFD,
- 0xB0B25FB2,
- 0xFFFEABAD,
- 0x5FB2FFFE,
- 0x5FCE600B,
- 0xE6BB600B,
- 0x5FCEDFC6,
- 0x27FBEFDF,
- 0x5FC8CFDE,
- 0x3A9CE7C0,
- 0xEDF0F3C8,
- 0x7F0154CD,
- 0x7F1D2D3D,
- 0x363A7570,
- 0x7E0AF1CE,
- 0x37EF2E68,
- 0x7FEE10EC,
- 0xADF8EFDE,
- 0xCFEAE52F,
- 0x7D0FE12B,
- 0xF1CE5F65,
- 0x7E0A4DF8,
- 0xCFEA5F72,
- 0x7D0BEFEE,
- 0xCFEA5F74,
- 0xE522EFDE,
- 0x5F74CFDA,
- 0x0B627385,
- 0xDF627E0A,
- 0x30D8145B,
- 0xB3C8,
- 0x5FFFDFFF,
- 0xA7F85F5E,
- 0xBFFE7F7D,
- 0x10D31450,
- 0x5F36BFFF,
- 0xAF785F5E,
- 0xBFFDA7F8,
- 0x5F36BFFE,
- 0x77FD30C0,
- 0x4E08FDCF,
- 0xE5FF6E0F,
- 0xAFF87E1F,
- 0x7E0FFD1F,
- 0xF1CF5F1B,
- 0xABF80D5E,
- 0x5F5EFFEF,
- 0x79F730A2,
- 0xAFDD5F34,
- 0x47F85F34,
- 0xAFED7FDD,
- 0x50B24978,
- 0x47FD7F1D,
- 0x7DFD70AD,
- 0xEF717EC1,
- 0x6BA47F01,
- 0x2D267EFD,
- 0x30DE5F5E,
- 0xFFFD5F5E,
- 0xFFEF5F5E,
- 0xFFDF0CA0,
- 0xAFED0A9E,
- 0xAFDD0C3A,
- 0x5F3AAFBD,
- 0x7FBDB082,
- 0x5F8247F8
+ 0x7FFFEFD9, 0x3FFD, 0x7FFB49F7, 0x7FF9,
+ 0x5FEFADF7, 0x5F89ADF7, 0x5FEFAFF7, 0x5F89AFF7,
+ 0x3A9CFBC8, 0xE7C0EDF0, 0x77C1E1BB, 0xF4DC7F1D,
+ 0xABAD932F, 0x4E08FDCF, 0x6E0FAFF8, 0x7CCF76CF,
+ 0xFD1FF9CF, 0xABF88DC6, 0xAB5679F7, 0xB0937383,
+ 0xDFCE79F7, 0xB091E6BB, 0xE5BBE74F, 0xB3FA6F0F,
+ 0x6FFB76CE, 0xEE0DF9CF, 0x2BFBEFEF, 0xCFEEF9CF,
+ 0x76CEAD24, 0x90B2DF9A, 0x7FDDD0BF, 0x4BF847FD,
+ 0x7CCF76CE, 0xCFEF7E1F, 0x7F1D7DFD, 0xF0B6EF71,
+ 0x7FC177C1, 0xFBC86079, 0xE722FBC8, 0x5FFFDFFF,
+ 0x5FB2FFFB, 0xFBC8F3C8, 0x94A67F01, 0x7F1D5F39,
+ 0xAFE85F5E, 0xFFDFDF96, 0xCB9FAF7D, 0x5FC1AFED,
+ 0x8C1C5FC1, 0xAFDD5FC3, 0xDF9A7EFD, 0xB0B25FB2,
+ 0xFFFEABAD, 0x5FB2FFFE, 0x5FCE600B, 0xE6BB600B,
+ 0x5FCEDFC6, 0x27FBEFDF, 0x5FC8CFDE, 0x3A9CE7C0,
+ 0xEDF0F3C8, 0x7F0154CD, 0x7F1D2D3D, 0x363A7570,
+ 0x7E0AF1CE, 0x37EF2E68, 0x7FEE10EC, 0xADF8EFDE,
+ 0xCFEAE52F, 0x7D0FE12B, 0xF1CE5F65, 0x7E0A4DF8,
+ 0xCFEA5F72, 0x7D0BEFEE, 0xCFEA5F74, 0xE522EFDE,
+ 0x5F74CFDA, 0x0B627385, 0xDF627E0A, 0x30D8145B,
+ 0xB3C8, 0x5FFFDFFF, 0xA7F85F5E, 0xBFFE7F7D,
+ 0x10D31450, 0x5F36BFFF, 0xAF785F5E, 0xBFFDA7F8,
+ 0x5F36BFFE, 0x77FD30C0, 0x4E08FDCF, 0xE5FF6E0F,
+ 0xAFF87E1F, 0x7E0FFD1F, 0xF1CF5F1B, 0xABF80D5E,
+ 0x5F5EFFEF, 0x79F730A2, 0xAFDD5F34, 0x47F85F34,
+ 0xAFED7FDD, 0x50B24978, 0x47FD7F1D, 0x7DFD70AD,
+ 0xEF717EC1, 0x6BA47F01, 0x2D267EFD, 0x30DE5F5E,
+ 0xFFFD5F5E, 0xFFEF5F5E, 0xFFDF0CA0, 0xAFED0A9E,
+ 0xAFDD0C3A, 0x5F3AAFBD, 0x7FBDB082, 0x5F8247F8
};
static uint patch_2f00[] __initdata = {
- 0x3E303430,
- 0x34343737,
- 0xABF7BF9B,
- 0x994B4FBD,
- 0xBD599493,
- 0x349FFF37,
- 0xFB9B177D,
- 0xD9936956,
- 0xBBFDD697,
- 0xBDD2FD11,
- 0x31DB9BB3,
- 0x63139637,
- 0x93733693,
- 0x193137F7,
- 0x331737AF,
- 0x7BB9B999,
- 0xBB197957,
- 0x7FDFD3D5,
- 0x73B773F
[PATCH v3 02/10] powerpc/8xx: drop verify_patch()
verify_patch() has been opted out since many years, and
the comment suggests it doesn't work. So drop it.
Signed-off-by: Christophe Leroy
---
arch/powerpc/platforms/8xx/micropatch.c | 40 -
1 file changed, 40 deletions(-)
diff --git a/arch/powerpc/platforms/8xx/micropatch.c
b/arch/powerpc/platforms/8xx/micropatch.c
index 33a9042fca80..7bbaf9914f32 100644
--- a/arch/powerpc/platforms/8xx/micropatch.c
+++ b/arch/powerpc/platforms/8xx/micropatch.c
@@ -707,43 +707,3 @@ void __init cpm_load_patch(cpm8xx_t *cp)
#endif /* some variation of the I2C/SPI patch was selected */
}
-
-/*
- * Take this entire routine out, since no one calls it and its
- * logic is suspect.
- */
-
-#if 0
-void
-verify_patch(volatile immap_t *immr)
-{
- volatile uint *dp;
- volatile cpm8xx_t *commproc;
- int i;
-
- commproc = (cpm8xx_t *)&immr->im_cpm;
-
- printk("cp_rccr %x\n", commproc->cp_rccr);
- commproc->cp_rccr = 0;
-
- dp = (uint *)(commproc->cp_dpmem);
- for (i=0; i<(sizeof(patch_2000)/4); i++)
- if (*dp++ != patch_2000[i]) {
- printk("patch_2000 bad at %d\n", i);
- dp--;
- printk("found 0x%X, wanted 0x%X\n", *dp, patch_2000[i]);
- break;
- }
-
- dp = (uint *)&(commproc->cp_dpmem[0x0f00]);
- for (i=0; i<(sizeof(patch_2f00)/4); i++)
- if (*dp++ != patch_2f00[i]) {
- printk("patch_2f00 bad at %d\n", i);
- dp--;
- printk("found 0x%X, wanted 0x%X\n", *dp, patch_2f00[i]);
- break;
- }
-
- commproc->cp_rccr = 0x0009;
-}
-#endif
--
2.13.3
[PATCH v3 06/10] powerpc/8xx: refactor printing of microcode patch name.
Define patch name together with the patch code, and refactor
the associated printk() while replacing it by a pr_info()
Signed-off-by: Christophe Leroy
---
arch/powerpc/platforms/8xx/micropatch.c | 14 --
1 file changed, 8 insertions(+), 6 deletions(-)
diff --git a/arch/powerpc/platforms/8xx/micropatch.c
b/arch/powerpc/platforms/8xx/micropatch.c
index 410968a0b177..5e5ac2378d3f 100644
--- a/arch/powerpc/platforms/8xx/micropatch.c
+++ b/arch/powerpc/platforms/8xx/micropatch.c
@@ -26,6 +26,8 @@
#ifdef CONFIG_I2C_SPI_UCODE_PATCH
+static char patch_name[] __initdata = "I2C/SPI";
+
static uint patch_2000[] __initdata = {
0x7FFFEFD9, 0x3FFD, 0x7FFB49F7, 0x7FF9,
0x5FEFADF7, 0x5F89ADF7, 0x5FEFAFF7, 0x5F89AFF7,
@@ -78,6 +80,8 @@ static uint patch_2e00[] __initdata = {};
#ifdef CONFIG_I2C_SPI_SMC1_UCODE_PATCH
+static char patch_name[] __initdata = "I2C/SPI/SMC1";
+
static uint patch_2000[] __initdata = {
0x3fff, 0x3ffd, 0x3ffb, 0x3ff9,
0x5f13eff8, 0x5eb5eff8, 0x5f88adf7, 0x5fefadf7,
@@ -194,6 +198,8 @@ static uint patch_2e00[] __initdata = {
#ifdef CONFIG_USB_SOF_UCODE_PATCH
+static char patch_name[] __initdata = "USB SOF";
+
static uint patch_2000[] __initdata = {
0x7fff, 0x7ffd, 0x7ffb, 0x49f7ba5b,
0xba383ffb, 0xf9b8b46d, 0xe5ab4e07, 0xaf77bffe,
@@ -235,8 +241,6 @@ void __init cpm_load_patch(cpm8xx_t *cp)
#ifdef CONFIG_USB_SOF_UCODE_PATCH
commproc->cp_rccr = 0x0009;
-
- printk("USB SOF microcode patch installed\n");
#endif /* CONFIG_USB_SOF_UCODE_PATCH */
#if defined(CONFIG_I2C_SPI_UCODE_PATCH) || \
@@ -257,8 +261,6 @@ void __init cpm_load_patch(cpm8xx_t *cp)
commproc->cp_cpmcr3 = 0x802e;
commproc->cp_cpmcr4 = 0x802c;
commproc->cp_rccr = 1;
-
- printk("I2C/SPI microcode patch installed.\n");
# endif /* CONFIG_I2C_SPI_UCODE_PATCH */
# if defined(CONFIG_I2C_SPI_SMC1_UCODE_PATCH)
@@ -270,9 +272,9 @@ void __init cpm_load_patch(cpm8xx_t *cp)
smp = (smc_uart_t *)&commproc->cp_dparam[PROFF_SMC1];
smp->smc_rpbase = 0x1FC0;
-
- printk("I2C/SPI/SMC1 microcode patch installed.\n");
# endif /* CONFIG_I2C_SPI_SMC1_UCODE_PATCH) */
#endif /* some variation of the I2C/SPI patch was selected */
+
+ pr_info("%s microcode patch installed\n", patch_name);
}
--
2.13.3
[PATCH v3 05/10] powerpc/8xx: Refactor microcode write
Add empty microcode tables so that all tables are defined
all the time. Regroup the writing of the 3 tables regardless
of the selected microcode.
Signed-off-by: Christophe Leroy
---
arch/powerpc/platforms/8xx/micropatch.c | 15 ++-
1 file changed, 6 insertions(+), 9 deletions(-)
diff --git a/arch/powerpc/platforms/8xx/micropatch.c
b/arch/powerpc/platforms/8xx/micropatch.c
index 2abc226d1139..410968a0b177 100644
--- a/arch/powerpc/platforms/8xx/micropatch.c
+++ b/arch/powerpc/platforms/8xx/micropatch.c
@@ -68,6 +68,8 @@ static uint patch_2f00[] __initdata = {
0x31497353, 0x76956D69, 0x7B9D9693, 0x13131979,
0x79376935
};
+
+static uint patch_2e00[] __initdata = {};
#endif
/*
@@ -201,6 +203,8 @@ static uint patch_2000[] __initdata = {
static uint patch_2f00[] __initdata = {
0x3030304c, 0xcab9e441, 0xa1aaf220
};
+
+static uint patch_2e00[] __initdata = {};
#endif
static void __init cpm_write_patch(cpm8xx_t *cp, int offset, uint *patch, int
len)
@@ -223,12 +227,13 @@ void __init cpm_load_patch(cpm8xx_t *cp)
#endif
commproc = cp;
-#ifdef CONFIG_USB_SOF_UCODE_PATCH
commproc->cp_rccr = 0;
cpm_write_patch(cp, 0, patch_2000, sizeof(patch_2000));
cpm_write_patch(cp, 0xf00, patch_2f00, sizeof(patch_2f00));
+ cpm_write_patch(cp, 0xe00, patch_2e00, sizeof(patch_2e00));
+#ifdef CONFIG_USB_SOF_UCODE_PATCH
commproc->cp_rccr = 0x0009;
printk("USB SOF microcode patch installed\n");
@@ -237,11 +242,6 @@ void __init cpm_load_patch(cpm8xx_t *cp)
#if defined(CONFIG_I2C_SPI_UCODE_PATCH) || \
defined(CONFIG_I2C_SPI_SMC1_UCODE_PATCH)
- commproc->cp_rccr = 0;
-
- cpm_write_patch(cp, 0, patch_2000, sizeof(patch_2000));
- cpm_write_patch(cp, 0xf00, patch_2f00, sizeof(patch_2f00));
-
iip = (iic_t *)&commproc->cp_dparam[PROFF_IIC];
# define RPBASE 0x0500
iip->iic_rpbase = RPBASE;
@@ -262,9 +262,6 @@ void __init cpm_load_patch(cpm8xx_t *cp)
# endif /* CONFIG_I2C_SPI_UCODE_PATCH */
# if defined(CONFIG_I2C_SPI_SMC1_UCODE_PATCH)
-
- cpm_write_patch(cp, 0xe00, patch_2e00, sizeof(patch_2e00));
-
commproc->cp_cpmcr1 = 0x8080;
commproc->cp_cpmcr2 = 0x808a;
commproc->cp_cpmcr3 = 0x8028;
--
2.13.3
[PATCH v3 09/10] powerpc/8xx: Use IO accessors in microcode programming.
Change microcode functions to use IO accessors and get rid
of volatile attributes.
Signed-off-by: Christophe Leroy
---
arch/powerpc/platforms/8xx/micropatch.c | 34 -
1 file changed, 16 insertions(+), 18 deletions(-)
diff --git a/arch/powerpc/platforms/8xx/micropatch.c
b/arch/powerpc/platforms/8xx/micropatch.c
index 252db7c90599..986aa6978ab7 100644
--- a/arch/powerpc/platforms/8xx/micropatch.c
+++ b/arch/powerpc/platforms/8xx/micropatch.c
@@ -242,13 +242,7 @@ static void __init cpm_write_patch(cpm8xx_t *cp, int
offset, uint *patch, int le
void __init cpm_load_patch(cpm8xx_t *cp)
{
- volatile cpm8xx_t *commproc;
- volatile iic_t *iip;
- volatile struct spi_pram *spp;
- volatile smc_uart_t *smp;
- commproc = cp;
-
- commproc->cp_rccr = 0;
+ out_be16(&cp->cp_rccr, 0);
cpm_write_patch(cp, 0, patch_2000, sizeof(patch_2000));
cpm_write_patch(cp, 0xf00, patch_2f00, sizeof(patch_2f00));
@@ -257,26 +251,30 @@ void __init cpm_load_patch(cpm8xx_t *cp)
if (IS_ENABLED(CONFIG_I2C_SPI_UCODE_PATCH) ||
IS_ENABLED(CONFIG_I2C_SPI_SMC1_UCODE_PATCH)) {
u16 rpbase = 0x500;
+ iic_t *iip;
+ struct spi_pram *spp;
- iip = (iic_t *)&commproc->cp_dparam[PROFF_IIC];
- iip->iic_rpbase = rpbase;
+ iip = (iic_t *)&cp->cp_dparam[PROFF_IIC];
+ out_be16(&iip->iic_rpbase, rpbase);
/* Put SPI above the IIC, also 32-byte aligned. */
- spp = (struct spi_pram *)&commproc->cp_dparam[PROFF_SPI];
- spp->rpbase = (rpbase + sizeof(iic_t) + 31) & ~31;
+ spp = (struct spi_pram *)&cp->cp_dparam[PROFF_SPI];
+ out_be16(&spp->rpbase, (rpbase + sizeof(iic_t) + 31) & ~31);
if (IS_ENABLED(CONFIG_I2C_SPI_SMC1_UCODE_PATCH)) {
- smp = (smc_uart_t *)&commproc->cp_dparam[PROFF_SMC1];
- smp->smc_rpbase = 0x1FC0;
+ smc_uart_t *smp;
+
+ smp = (smc_uart_t *)&cp->cp_dparam[PROFF_SMC1];
+ out_be16(&smp->smc_rpbase, 0x1FC0);
}
}
- commproc->cp_cpmcr1 = patch_params.cpmcr1;
- commproc->cp_cpmcr2 = patch_params.cpmcr2;
- commproc->cp_cpmcr3 = patch_params.cpmcr3;
- commproc->cp_cpmcr4 = patch_params.cpmcr4;
+ out_be16(&cp->cp_cpmcr1, patch_params.cpmcr1);
+ out_be16(&cp->cp_cpmcr2, patch_params.cpmcr2);
+ out_be16(&cp->cp_cpmcr3, patch_params.cpmcr3);
+ out_be16(&cp->cp_cpmcr4, patch_params.cpmcr4);
- commproc->cp_rccr = patch_params.rccr;
+ out_be16(&cp->cp_rccr, patch_params.rccr);
pr_info("%s microcode patch installed\n", patch_name);
}
--
2.13.3
[PATCH v3 10/10] powerpc/8xx: Add microcode patch to move SMC parameter RAM.
Some SCC functions like the QMC requires an extended parameter RAM.
On modern 8xx (ie 866 and 885), SPI area can already be relocated,
allowing the use of those functions on SCC2. But SCC3 and SCC4
parameter RAM collide with SMC1 and SMC2 parameter RAMs.
This patch adds microcode to allow the relocation of both SMC1 and
SMC2, and relocate them at offsets 0x1ec0 and 0x1fc0.
Those offsets are by default for the CPM1 DSP1 and DSP2, but there
is no kernel driver using them at the moment so this area can be
reused.
This microcode is provided by Freescale/NXP in Engineering Bulletin
EB662 ("MPC8xx I2C/SPI and SMC Relocation Microcode Packages")
dated 2006. The binary code is public. The source is not available.
Signed-off-by: Christophe Leroy
---
arch/powerpc/platforms/8xx/Kconfig | 7 +++
arch/powerpc/platforms/8xx/micropatch.c | 97 +
2 files changed, 104 insertions(+)
diff --git a/arch/powerpc/platforms/8xx/Kconfig
b/arch/powerpc/platforms/8xx/Kconfig
index d408162d5af4..e0fe670f06f6 100644
--- a/arch/powerpc/platforms/8xx/Kconfig
+++ b/arch/powerpc/platforms/8xx/Kconfig
@@ -157,6 +157,13 @@ config I2C_SPI_SMC1_UCODE_PATCH
help
Help not implemented yet, coming soon.
+config SMC_UCODE_PATCH
+ bool "SMC relocation patch"
+ help
+ This microcode relocates SMC1 and SMC2 parameter RAMs at
+ offset 0x1ec0 and 0x1fc0 to allow extended parameter RAM
+ for SCC3 and SCC4.
+
endchoice
config UCODE_PATCH
diff --git a/arch/powerpc/platforms/8xx/micropatch.c
b/arch/powerpc/platforms/8xx/micropatch.c
index 986aa6978ab7..c571555c12d3 100644
--- a/arch/powerpc/platforms/8xx/micropatch.c
+++ b/arch/powerpc/platforms/8xx/micropatch.c
@@ -233,6 +233,94 @@ static uint patch_2f00[] __initdata = {
static uint patch_2e00[] __initdata = {};
#endif
+/*
+ * SMC relocation patch arrays.
+ */
+
+#ifdef CONFIG_SMC_UCODE_PATCH
+
+static char patch_name[] __initdata = "SMC";
+
+static struct patch_params patch_params __initdata = {
+ 2, 0x8080, 0x8088,
+};
+
+static uint patch_2000[] __initdata = {
+ 0x3fff, 0x3ffd, 0x3ffb, 0x3ff9,
+ 0x5fefeff8, 0x5f91eff8, 0x3ff3, 0x3ff1,
+ 0x3a11e710, 0xedf0ccb9, 0xf318ed66, 0x7f0e5fe2,
+ 0x7fedbb38, 0x3afe7468, 0x7fedf4d8, 0x8ffbb92d,
+ 0xb83b77fd, 0xb0bb5eb9, 0xdfda7fed, 0x90bde74d,
+ 0x6f0dcbd3, 0xe7decfed, 0xcb50cfed, 0xcfeddf6d,
+ 0x914d4f74, 0x5eaedfcb, 0x9ee0e7df, 0xefbb6ffb,
+ 0xe7ef7f0e, 0x9ee57fed, 0xebb7effa, 0xeb30affb,
+ 0x7fea90b3, 0x7e0cf09f, 0xb318, 0x5fffdfff,
+ 0xac35efea, 0x7fce1fc1, 0xe2ff5fbd, 0xaffbe2ff,
+ 0x5fbfaffb, 0xf9a87d0f, 0xaef8770f, 0x7d0fb0a2,
+ 0xeffbbfff, 0xcfef5fba, 0x7d0fbfff, 0x5fba4cf8,
+ 0x7fddd09b, 0x49f847fd, 0x7efdf097, 0x7fedfffd,
+ 0x7dfdf093, 0xef7e7e1e, 0x5fba7f0e, 0x3a11e710,
+ 0xedf0cc87, 0xfb18ad0a, 0x1f85bbb8, 0x74283b7e,
+ 0x7375e4bb, 0x2ab64fb8, 0x5c7de4bb, 0x32fdffbf,
+ 0x5f0843f8, 0x7ce3e1bb, 0xe74f7ded, 0x6f0f4fe8,
+ 0xc7ba32be, 0x73f2efeb, 0x600b4f78, 0xe5bb760b,
+ 0x5388aef8, 0x4ef80b6a, 0xcfef9ee5, 0xabf8751f,
+ 0xefef5b88, 0x741f4fe8, 0x751e760d, 0x7fdb70dd,
+ 0x741cafce, 0xefcc7fce, 0x751e7088, 0x741ce7bb,
+ 0x334ecfed, 0xafdbefeb, 0xe5bb760b, 0x53ceaef8,
+ 0xafe8e7eb, 0x4bf8771e, 0x7e007fed, 0x4fcbe2cc,
+ 0x7fbc3085, 0x7b0f7a0f, 0x34b177fd, 0xb0e75e93,
+ 0xdf313e3b, 0xaf78741f, 0x741f30cc, 0xcfef5f08,
+ 0x741f3e88, 0xafb8771e, 0x5f437fed, 0x0bafe2cc,
+ 0x741ccfec, 0xe5ca53a9, 0x6fcb4f74, 0x5e89df27,
+ 0x2a923d14, 0x4b8fdf0c, 0x751f741c, 0x6c1eeffa,
+ 0xefea7fce, 0x6ffc309a, 0xefec3fca, 0x308fdf0a,
+ 0xadf85e7a, 0xaf7daefd, 0x5e7adf0a, 0x5e7aafdd,
+ 0x761f1088, 0x1e7c7efd, 0x3089fffe, 0x4908fb18,
+ 0x5fffdfff, 0xafbbf0f7, 0x4ef85f43, 0xadf81489,
+ 0x7a0f7089, 0xcfef5089, 0x7a0fdf0c, 0x5e7cafed,
+ 0xbc6e780f, 0xefef780f, 0xefef790f, 0xa7f85eeb,
+ 0xffef790f, 0xefef790f, 0x1489df0a, 0x5e7aadfd,
+ 0x5f09fffb, 0xe79aded9, 0xeff96079, 0x607ae79a,
+ 0xded8eff9, 0x60795edb, 0x607acfef, 0xefefefdf,
+ 0xefbfef7f, 0xeeffedff, 0xebffe7ff, 0xafefafdf,
+ 0xafbfaf7f, 0xaeffadff, 0xabffa7ff, 0x6fef6fdf,
+ 0x6fbf6f7f, 0x6eff6dff, 0x6bff67ff, 0x2fef2fdf,
+ 0x2fbf2f7f, 0x2eff2dff, 0x2bff27ff, 0x4e08fd1f,
+ 0xe5ff6e0f, 0xaff87eef, 0x7e0ffdef, 0xf11f6079,
+ 0xabf8f51e, 0x7e0af11c, 0x37cfae16, 0x7fec909a,
+ 0xadf8efdc, 0xcfeae52f, 0x7d0fe12b, 0xf11c6079,
+ 0x7e0a4df8, 0xcfea5ea0, 0x7d0befec, 0xcfea5ea2,
+ 0xe522efdc, 0x5ea2cfda, 0x4e08fd1f, 0x6e0faff8,
+ 0x7c1f761f, 0xfdeff91f, 0x6079abf8, 0x761cee00,
+ 0xf91f2bfb, 0xefefcfec, 0xf91f6079, 0x761c27fb,
+ 0xefdf5e83, 0xcfdc7fdd, 0x50f84bf8, 0x47fd7c1f,
+ 0x761ccfcf, 0x7eef7fed, 0x7dfd70ef, 0xef7e7f1e,
+ 0x771efb18, 0x6079e722, 0xe6bbe5bb, 0x2e66e5bb,
+ 0x600b2ee1, 0xe2bbe2
[PATCH v3 07/10] powerpc/8xx: refactor programming of microcode CPM params.
The CPM registers RCCR and CPMCR1..4 registers has to be set in
accordance with the microcode patch beeing programmed. Lets
define them as part of the patch set and refactor their
programming from that definition.
Signed-off-by: Christophe Leroy
---
arch/powerpc/platforms/8xx/micropatch.c | 45 -
1 file changed, 27 insertions(+), 18 deletions(-)
diff --git a/arch/powerpc/platforms/8xx/micropatch.c
b/arch/powerpc/platforms/8xx/micropatch.c
index 5e5ac2378d3f..02490c54ebac 100644
--- a/arch/powerpc/platforms/8xx/micropatch.c
+++ b/arch/powerpc/platforms/8xx/micropatch.c
@@ -20,6 +20,14 @@
#include
#include
+struct patch_params {
+ ushort rccr;
+ ushort cpmcr1;
+ ushort cpmcr2;
+ ushort cpmcr3;
+ ushort cpmcr4;
+};
+
/*
* I2C/SPI relocation patch arrays.
*/
@@ -28,6 +36,10 @@
static char patch_name[] __initdata = "I2C/SPI";
+static struct patch_params patch_params __initdata = {
+ 1, 0x802a, 0x8028, 0x802e, 0x802c,
+};
+
static uint patch_2000[] __initdata = {
0x7FFFEFD9, 0x3FFD, 0x7FFB49F7, 0x7FF9,
0x5FEFADF7, 0x5F89ADF7, 0x5FEFAFF7, 0x5F89AFF7,
@@ -82,6 +94,10 @@ static uint patch_2e00[] __initdata = {};
static char patch_name[] __initdata = "I2C/SPI/SMC1";
+static struct patch_params patch_params __initdata = {
+ 3, 0x8080, 0x808a, 0x8028, 0x802a,
+};
+
static uint patch_2000[] __initdata = {
0x3fff, 0x3ffd, 0x3ffb, 0x3ff9,
0x5f13eff8, 0x5eb5eff8, 0x5f88adf7, 0x5fefadf7,
@@ -200,6 +216,10 @@ static uint patch_2e00[] __initdata = {
static char patch_name[] __initdata = "USB SOF";
+static struct patch_params patch_params __initdata = {
+ 9,
+};
+
static uint patch_2000[] __initdata = {
0x7fff, 0x7ffd, 0x7ffb, 0x49f7ba5b,
0xba383ffb, 0xf9b8b46d, 0xe5ab4e07, 0xaf77bffe,
@@ -239,10 +259,6 @@ void __init cpm_load_patch(cpm8xx_t *cp)
cpm_write_patch(cp, 0xf00, patch_2f00, sizeof(patch_2f00));
cpm_write_patch(cp, 0xe00, patch_2e00, sizeof(patch_2e00));
-#ifdef CONFIG_USB_SOF_UCODE_PATCH
- commproc->cp_rccr = 0x0009;
-#endif /* CONFIG_USB_SOF_UCODE_PATCH */
-
#if defined(CONFIG_I2C_SPI_UCODE_PATCH) || \
defined(CONFIG_I2C_SPI_SMC1_UCODE_PATCH)
@@ -255,26 +271,19 @@ void __init cpm_load_patch(cpm8xx_t *cp)
spp = (struct spi_pram *)&commproc->cp_dparam[PROFF_SPI];
spp->rpbase = (RPBASE + sizeof(iic_t) + 31) & ~31;
-# if defined(CONFIG_I2C_SPI_UCODE_PATCH)
- commproc->cp_cpmcr1 = 0x802a;
- commproc->cp_cpmcr2 = 0x8028;
- commproc->cp_cpmcr3 = 0x802e;
- commproc->cp_cpmcr4 = 0x802c;
- commproc->cp_rccr = 1;
-# endif /* CONFIG_I2C_SPI_UCODE_PATCH */
-
# if defined(CONFIG_I2C_SPI_SMC1_UCODE_PATCH)
- commproc->cp_cpmcr1 = 0x8080;
- commproc->cp_cpmcr2 = 0x808a;
- commproc->cp_cpmcr3 = 0x8028;
- commproc->cp_cpmcr4 = 0x802a;
- commproc->cp_rccr = 3;
-
smp = (smc_uart_t *)&commproc->cp_dparam[PROFF_SMC1];
smp->smc_rpbase = 0x1FC0;
# endif /* CONFIG_I2C_SPI_SMC1_UCODE_PATCH) */
#endif /* some variation of the I2C/SPI patch was selected */
+ commproc->cp_cpmcr1 = patch_params.cpmcr1;
+ commproc->cp_cpmcr2 = patch_params.cpmcr2;
+ commproc->cp_cpmcr3 = patch_params.cpmcr3;
+ commproc->cp_cpmcr4 = patch_params.cpmcr4;
+
+ commproc->cp_rccr = patch_params.rccr;
+
pr_info("%s microcode patch installed\n", patch_name);
}
--
2.13.3
[PATCH v3 04/10] powerpc/8xx: refactor writing of CPM microcode arrays
Create a function to refactor the writing of CPM microcode arrays.
Signed-off-by: Christophe Leroy
---
arch/powerpc/platforms/8xx/micropatch.c | 35 -
1 file changed, 13 insertions(+), 22 deletions(-)
diff --git a/arch/powerpc/platforms/8xx/micropatch.c
b/arch/powerpc/platforms/8xx/micropatch.c
index e14b6bcadce3..2abc226d1139 100644
--- a/arch/powerpc/platforms/8xx/micropatch.c
+++ b/arch/powerpc/platforms/8xx/micropatch.c
@@ -203,9 +203,15 @@ static uint patch_2f00[] __initdata = {
};
#endif
+static void __init cpm_write_patch(cpm8xx_t *cp, int offset, uint *patch, int
len)
+{
+ if (!len)
+ return;
+ memcpy_toio(cp->cp_dpmem + offset, patch, len);
+}
+
void __init cpm_load_patch(cpm8xx_t *cp)
{
- volatile uint *dp;/* Dual-ported RAM. */
volatile cpm8xx_t *commproc;
#if defined(CONFIG_I2C_SPI_UCODE_PATCH) || \
defined(CONFIG_I2C_SPI_SMC1_UCODE_PATCH)
@@ -215,20 +221,13 @@ void __init cpm_load_patch(cpm8xx_t *cp)
volatile smc_uart_t *smp;
#endif
#endif
- int i;
-
commproc = cp;
#ifdef CONFIG_USB_SOF_UCODE_PATCH
commproc->cp_rccr = 0;
- dp = (uint *)(commproc->cp_dpmem);
- for (i=0; i<(sizeof(patch_2000)/4); i++)
- *dp++ = patch_2000[i];
-
- dp = (uint *)&(commproc->cp_dpmem[0x0f00]);
- for (i=0; i<(sizeof(patch_2f00)/4); i++)
- *dp++ = patch_2f00[i];
+ cpm_write_patch(cp, 0, patch_2000, sizeof(patch_2000));
+ cpm_write_patch(cp, 0xf00, patch_2f00, sizeof(patch_2f00));
commproc->cp_rccr = 0x0009;
@@ -240,13 +239,8 @@ void __init cpm_load_patch(cpm8xx_t *cp)
commproc->cp_rccr = 0;
- dp = (uint *)(commproc->cp_dpmem);
- for (i=0; i<(sizeof(patch_2000)/4); i++)
- *dp++ = patch_2000[i];
-
- dp = (uint *)&(commproc->cp_dpmem[0x0f00]);
- for (i=0; i<(sizeof(patch_2f00)/4); i++)
- *dp++ = patch_2f00[i];
+ cpm_write_patch(cp, 0, patch_2000, sizeof(patch_2000));
+ cpm_write_patch(cp, 0xf00, patch_2f00, sizeof(patch_2f00));
iip = (iic_t *)&commproc->cp_dparam[PROFF_IIC];
# define RPBASE 0x0500
@@ -254,9 +248,8 @@ void __init cpm_load_patch(cpm8xx_t *cp)
/* Put SPI above the IIC, also 32-byte aligned.
*/
- i = (RPBASE + sizeof(iic_t) + 31) & ~31;
spp = (struct spi_pram *)&commproc->cp_dparam[PROFF_SPI];
- spp->rpbase = i;
+ spp->rpbase = (RPBASE + sizeof(iic_t) + 31) & ~31;
# if defined(CONFIG_I2C_SPI_UCODE_PATCH)
commproc->cp_cpmcr1 = 0x802a;
@@ -270,9 +263,7 @@ void __init cpm_load_patch(cpm8xx_t *cp)
# if defined(CONFIG_I2C_SPI_SMC1_UCODE_PATCH)
- dp = (uint *)&(commproc->cp_dpmem[0x0e00]);
- for (i=0; i<(sizeof(patch_2e00)/4); i++)
- *dp++ = patch_2e00[i];
+ cpm_write_patch(cp, 0xe00, patch_2e00, sizeof(patch_2e00));
commproc->cp_cpmcr1 = 0x8080;
commproc->cp_cpmcr2 = 0x808a;
--
2.13.3
[PATCH v3 08/10] powerpc/8xx: replace #ifdefs by IS_ENABLED() in microcode.c
Reduce #ifdef mess by using IS_ENABLED() instead.
Signed-off-by: Christophe Leroy
---
arch/powerpc/platforms/8xx/micropatch.c | 33 +
1 file changed, 13 insertions(+), 20 deletions(-)
diff --git a/arch/powerpc/platforms/8xx/micropatch.c
b/arch/powerpc/platforms/8xx/micropatch.c
index 02490c54ebac..252db7c90599 100644
--- a/arch/powerpc/platforms/8xx/micropatch.c
+++ b/arch/powerpc/platforms/8xx/micropatch.c
@@ -243,14 +243,9 @@ static void __init cpm_write_patch(cpm8xx_t *cp, int
offset, uint *patch, int le
void __init cpm_load_patch(cpm8xx_t *cp)
{
volatile cpm8xx_t *commproc;
-#if defined(CONFIG_I2C_SPI_UCODE_PATCH) || \
-defined(CONFIG_I2C_SPI_SMC1_UCODE_PATCH)
volatile iic_t *iip;
volatile struct spi_pram *spp;
-#ifdef CONFIG_I2C_SPI_SMC1_UCODE_PATCH
volatile smc_uart_t *smp;
-#endif
-#endif
commproc = cp;
commproc->cp_rccr = 0;
@@ -259,24 +254,22 @@ void __init cpm_load_patch(cpm8xx_t *cp)
cpm_write_patch(cp, 0xf00, patch_2f00, sizeof(patch_2f00));
cpm_write_patch(cp, 0xe00, patch_2e00, sizeof(patch_2e00));
-#if defined(CONFIG_I2C_SPI_UCODE_PATCH) || \
-defined(CONFIG_I2C_SPI_SMC1_UCODE_PATCH)
-
- iip = (iic_t *)&commproc->cp_dparam[PROFF_IIC];
-# define RPBASE 0x0500
- iip->iic_rpbase = RPBASE;
+ if (IS_ENABLED(CONFIG_I2C_SPI_UCODE_PATCH) ||
+ IS_ENABLED(CONFIG_I2C_SPI_SMC1_UCODE_PATCH)) {
+ u16 rpbase = 0x500;
- /* Put SPI above the IIC, also 32-byte aligned.
- */
- spp = (struct spi_pram *)&commproc->cp_dparam[PROFF_SPI];
- spp->rpbase = (RPBASE + sizeof(iic_t) + 31) & ~31;
+ iip = (iic_t *)&commproc->cp_dparam[PROFF_IIC];
+ iip->iic_rpbase = rpbase;
-# if defined(CONFIG_I2C_SPI_SMC1_UCODE_PATCH)
- smp = (smc_uart_t *)&commproc->cp_dparam[PROFF_SMC1];
- smp->smc_rpbase = 0x1FC0;
-# endif /* CONFIG_I2C_SPI_SMC1_UCODE_PATCH) */
+ /* Put SPI above the IIC, also 32-byte aligned. */
+ spp = (struct spi_pram *)&commproc->cp_dparam[PROFF_SPI];
+ spp->rpbase = (rpbase + sizeof(iic_t) + 31) & ~31;
-#endif /* some variation of the I2C/SPI patch was selected */
+ if (IS_ENABLED(CONFIG_I2C_SPI_SMC1_UCODE_PATCH)) {
+ smp = (smc_uart_t *)&commproc->cp_dparam[PROFF_SMC1];
+ smp->smc_rpbase = 0x1FC0;
+ }
+ }
commproc->cp_cpmcr1 = patch_params.cpmcr1;
commproc->cp_cpmcr2 = patch_params.cpmcr2;
--
2.13.3
[PATCH v3 01/10] powerpc/8xx: move CPM1 related files from sysdev/ to platforms/8xx
Only 8xx selects CPM1 and related CONFIG options are already
in platforms/8xx/Kconfig
Move the related C files to platforms/8xx/.
Signed-off-by: Christophe Leroy
---
v3: cpm_gpio is also used by CPM2, so it has to remain in sysdev for now ; no
change to other patches of the series.
v2: added several patches in the series to clean up the microcode patching.
arch/powerpc/platforms/8xx/Makefile | 2 ++
arch/powerpc/{sysdev => platforms/8xx}/cpm1.c | 0
arch/powerpc/{sysdev => platforms/8xx}/micropatch.c | 0
arch/powerpc/sysdev/Makefile| 2 --
4 files changed, 2 insertions(+), 2 deletions(-)
rename arch/powerpc/{sysdev => platforms/8xx}/cpm1.c (100%)
rename arch/powerpc/{sysdev => platforms/8xx}/micropatch.c (100%)
diff --git a/arch/powerpc/platforms/8xx/Makefile
b/arch/powerpc/platforms/8xx/Makefile
index 708ab099e886..27a7c6f828e0 100644
--- a/arch/powerpc/platforms/8xx/Makefile
+++ b/arch/powerpc/platforms/8xx/Makefile
@@ -3,6 +3,8 @@
# Makefile for the PowerPC 8xx linux kernel.
#
obj-y += m8xx_setup.o machine_check.o pic.o
+obj-$(CONFIG_CPM1) += cpm1.o
+obj-$(CONFIG_UCODE_PATCH) += micropatch.o
obj-$(CONFIG_MPC885ADS) += mpc885ads_setup.o
obj-$(CONFIG_MPC86XADS) += mpc86xads_setup.o
obj-$(CONFIG_PPC_EP88XC) += ep88xc.o
diff --git a/arch/powerpc/sysdev/cpm1.c b/arch/powerpc/platforms/8xx/cpm1.c
similarity index 100%
rename from arch/powerpc/sysdev/cpm1.c
rename to arch/powerpc/platforms/8xx/cpm1.c
diff --git a/arch/powerpc/sysdev/micropatch.c
b/arch/powerpc/platforms/8xx/micropatch.c
similarity index 100%
rename from arch/powerpc/sysdev/micropatch.c
rename to arch/powerpc/platforms/8xx/micropatch.c
diff --git a/arch/powerpc/sysdev/Makefile b/arch/powerpc/sysdev/Makefile
index aaf23283ba0c..9d73dfddf060 100644
--- a/arch/powerpc/sysdev/Makefile
+++ b/arch/powerpc/sysdev/Makefile
@@ -37,12 +37,10 @@ obj-$(CONFIG_XILINX_PCI)+= xilinx_pci.o
obj-$(CONFIG_OF_RTC) += of_rtc.o
obj-$(CONFIG_CPM) += cpm_common.o
-obj-$(CONFIG_CPM1) += cpm1.o
obj-$(CONFIG_CPM2) += cpm2.o cpm2_pic.o cpm_gpio.o
obj-$(CONFIG_8xx_GPIO) += cpm_gpio.o
obj-$(CONFIG_QUICC_ENGINE) += cpm_common.o
obj-$(CONFIG_PPC_DCR) += dcr.o
-obj-$(CONFIG_UCODE_PATCH) += micropatch.o
obj-$(CONFIG_PPC_MPC512x) += mpc5xxx_clocks.o
obj-$(CONFIG_PPC_MPC52xx) += mpc5xxx_clocks.o
--
2.13.3
[PATCH] mips: Remove q-accessors from non-64bit platforms
There are some generic drivers in the kernel, which make use of the
q-accessors or their derivatives. While at current asm/io.h the accessors
are defined, their implementation is only applicable either for 64bit
systems, or for systems with cpu_has_64bits flag set. Obviously there
are MIPS systems which are neither of these, but still need to have
those drivers supported. In this case the solution is to define some
generic versions of the q-accessors, but with a limitation to be
non-atomic. Such accessors are defined in the
io-64-nonatomic-{hi-lo,lo-hi}.h file. The drivers which utilize the
q-suffixed IO-methods are supposed to include the header file, so
in case if these accessors aren't defined for the platform, the generic
non-atomic versions are utilized. Currently the MIPS-specific asm/io.h
file provides the q-accessors for any MIPS system even for ones, which
in fact don't support them and raise BUG() in case if any of them is
called. Due to this the generic versions of the accessors are never
used while an attempt to call the IO-methods causes the kernel BUG().
In order to fix this we need to define the q-accessors only for
the MIPS systems, which actually support them, and don't define them
otherwise, so to let the corresponding drivers to use the non-atomic
q-suffixed accessors.
Signed-off-by: Serge Semin
Suggested-by: Arnd Bergmann
Cc: Vadim V. Vlasov
---
arch/mips/include/asm/io.h | 11 +++
1 file changed, 11 insertions(+)
diff --git a/arch/mips/include/asm/io.h b/arch/mips/include/asm/io.h
index 29997e42480e..4597017f147b 100644
--- a/arch/mips/include/asm/io.h
+++ b/arch/mips/include/asm/io.h
@@ -462,7 +462,12 @@ __BUILD_MEMORY_PFX(, bwlq, type, 0)
BUILDIO_MEM(b, u8)
BUILDIO_MEM(w, u16)
BUILDIO_MEM(l, u32)
+#ifdef CONFIG_64BIT
BUILDIO_MEM(q, u64)
+#else
+__BUILD_MEMORY_PFX(__raw_, q, u64, 0)
+__BUILD_MEMORY_PFX(__mem_, q, u64, 0)
+#endif
#define __BUILD_IOPORT_PFX(bus, bwlq, type)\
__BUILD_IOPORT_SINGLE(bus, bwlq, type, 1, 0,) \
@@ -488,12 +493,16 @@ __BUILDIO(q, u64)
#define readb_relaxed __relaxed_readb
#define readw_relaxed __relaxed_readw
#define readl_relaxed __relaxed_readl
+#ifdef CONFIG_64BIT
#define readq_relaxed __relaxed_readq
+#endif
#define writeb_relaxed __relaxed_writeb
#define writew_relaxed __relaxed_writew
#define writel_relaxed __relaxed_writel
+#ifdef CONFIG_64BIT
#define writeq_relaxed __relaxed_writeq
+#endif
#define readb_be(addr) \
__raw_readb((__force unsigned *)(addr))
@@ -516,8 +525,10 @@ __BUILDIO(q, u64)
/*
* Some code tests for these symbols
*/
+#ifdef CONFIG_64BIT
#define readq readq
#define writeq writeq
+#endif
#define __BUILD_MEMORY_STRING(bwlq, type) \
\
--
2.21.0
Re: [PATCH] gsmi: replace printk with relevant dev_
On Fri, Jun 14, 2019 at 12:27:05AM +0530, Saiyam Doshi wrote: > Replace printk() with dev_* macros for logging consistency. > In process of replacing printk with dev_err, dev_info etc., > removed unnecessary "out of memory" debug message. That is multiple things done in the same patch, please break this up into a patch series, only doing one "logical" thing per patch. Note, generic cleanup patches like this are tough to get done in the "real" part of the kernel, I strongly recommend you start out in drivers/staging/ where these types of changes are welcomed. Get experience there and then move out into other areas of the kernel if you want to, that way you don't annoy developers/maintainers with basic errors like this. good luck! greg k-h
Re: [PATCH] kernel/memremap.c: use ALIGN/ALIGN_DOWN to calculate align_start/end
On Thu, Jun 13, 2019 at 11:02 PM Wei Yang wrote: > > The purpose of align_start/end is to expand to SECTION boundary. Use > ALIGN/ALIGN_DOWN directly is more self-explain and clean. I'm actively trying to kill this code [1] so I don't see the need for this patch. [1]: https://lore.kernel.org/lkml/155977193326.2443951.14201009973429527491.st...@dwillia2-desk3.amr.corp.intel.com/
[PATCH] kernel/memremap.c: use ALIGN/ALIGN_DOWN to calculate align_start/end
The purpose of align_start/end is to expand to SECTION boundary. Use
ALIGN/ALIGN_DOWN directly is more self-explain and clean.
Signed-off-by: Wei Yang
---
kernel/memremap.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/kernel/memremap.c b/kernel/memremap.c
index 1490e63f69a9..53cf751f0721 100644
--- a/kernel/memremap.c
+++ b/kernel/memremap.c
@@ -159,10 +159,9 @@ void *devm_memremap_pages(struct device *dev, struct
dev_pagemap *pgmap)
if (!pgmap->ref || !pgmap->kill)
return ERR_PTR(-EINVAL);
- align_start = res->start & ~(SECTION_SIZE - 1);
- align_size = ALIGN(res->start + resource_size(res), SECTION_SIZE)
- - align_start;
- align_end = align_start + align_size - 1;
+ align_start = ALIGN_DOWN(res->start, SECTION_SIZE);
+ align_end = ALIGN(res->end, SECTION_SIZE) - 1;
+ align_size = align_end - align_start + 1;
conflict_pgmap = get_dev_pagemap(PHYS_PFN(align_start), NULL);
if (conflict_pgmap) {
--
2.19.1
Re: [PATCH 7/9] x86/unwind/orc: Fall back to using frame pointers for generated code
On Thu, Jun 13, 2019 at 11:50:37PM -0500, Josh Poimboeuf wrote:
> On Thu, Jun 13, 2019 at 09:28:48PM -0500, Josh Poimboeuf wrote:
> > On Thu, Jun 13, 2019 at 08:58:48PM -0500, Josh Poimboeuf wrote:
> > > On Thu, Jun 13, 2019 at 06:42:45PM -0700, Alexei Starovoitov wrote:
> > > > On Thu, Jun 13, 2019 at 08:30:51PM -0500, Josh Poimboeuf wrote:
> > > > > On Thu, Jun 13, 2019 at 03:00:55PM -0700, Alexei Starovoitov wrote:
> > > > > > > @@ -392,8 +402,16 @@ bool unwind_next_frame(struct unwind_state
> > > > > > > *state)
> > > > > > >* calls and calls to noreturn functions.
> > > > > > >*/
> > > > > > > orc = orc_find(state->signal ? state->ip : state->ip - 1);
> > > > > > > - if (!orc)
> > > > > > > - goto err;
> > > > > > > + if (!orc) {
> > > > > > > + /*
> > > > > > > + * As a fallback, try to assume this code uses a frame
> > > > > > > pointer.
> > > > > > > + * This is useful for generated code, like BPF, which
> > > > > > > ORC
> > > > > > > + * doesn't know about. This is just a guess, so the
> > > > > > > rest of
> > > > > > > + * the unwind is no longer considered reliable.
> > > > > > > + */
> > > > > > > + orc = &orc_fp_entry;
> > > > > > > + state->error = true;
> > > > > >
> > > > > > That seems fragile.
> > > > >
> > > > > I don't think so. The unwinder has sanity checks to make sure it
> > > > > doesn't go off the rails. And it works just fine. The beauty is that
> > > > > it should work for all generated code (not just BPF).
> > > > >
> > > > > > Can't we populate orc_unwind tables after JIT ?
> > > > >
> > > > > As I mentioned it would introduce a lot more complexity. For each JIT
> > > > > function, BPF would have to tell ORC the following:
> > > > >
> > > > > - where the BPF function lives
> > > > > - how big the stack frame is
> > > > > - where RBP and other callee-saved regs are on the stack
> > > >
> > > > that sounds like straightforward addition that ORC should have anyway.
> > > > right now we're not using rbp in the jit-ed code,
> > > > but one day we definitely will.
> > > > Same goes for r12. It's reserved right now for 'strategic use'.
> > > > We've been thinking to add another register to bpf isa.
> > > > It will map to r12 on x86. arm64 and others have plenty of regs to use.
> > > > The programs are getting bigger and register spill/fill starting to
> > > > become a performance concern. Extra register will give us more room.
> > >
> > > With CONFIG_FRAME_POINTER, RBP isn't available. If you look at all the
> > > code in the entire kernel you'll notice that BPF JIT is pretty much the
> > > only one still clobbering it.
> >
> > Hm. If you wanted to eventually use R12 for other purposes, there might
> > be a way to abstract BPF_REG_FP such that it doesn't actually need a
> > dedicated register. The BPF program's frame pointer will always be a
> > certain constant offset away from RBP (real frame pointer), so accesses
> > to BPF_REG_FP could still be based on RBP, but with an offset added to
> > it.
>
> How about something like this (based on top of patch 4)? This fixes
> frame pointers without using R12, by making BPF_REG_FP equivalent to
> RBP, minus a constant offset (callee-save area + tail_call_cnt = 40).
>
> diff --git a/arch/x86/net/bpf_jit_comp.c b/arch/x86/net/bpf_jit_comp.c
> index 485692d4b163..2f313622c741 100644
> --- a/arch/x86/net/bpf_jit_comp.c
> +++ b/arch/x86/net/bpf_jit_comp.c
> @@ -104,6 +104,9 @@ static int bpf_size_to_x86_bytes(int bpf_size)
> * register in load/store instructions, it always needs an
> * extra byte of encoding and is callee saved.
> *
> + * BPF_REG_FP corresponds to x86-64 register RBP, but 40 bytes must be
> + * subtracted from it to get the BPF_REG_FP value.
> + *
> * Also x86-64 register R9 is unused. x86-64 register R10 is
> * used for blinding (if enabled).
> */
> @@ -118,11 +121,18 @@ static const int reg2hex[] = {
> [BPF_REG_7] = 5, /* R13 callee saved */
> [BPF_REG_8] = 6, /* R14 callee saved */
> [BPF_REG_9] = 7, /* R15 callee saved */
> - [BPF_REG_FP] = 5, /* RBP readonly */
> + [BPF_REG_FP] = 5, /* (RBP - 40 bytes) readonly */
> [BPF_REG_AX] = 2, /* R10 temp register */
> [AUX_REG] = 3,/* R11 temp register */
> };
>
> +static s16 offset(struct bpf_insn *insn)
> +{
> + if (insn->src_reg == BPF_REG_FP || insn->dst_reg == BPF_REG_FP)
> + return insn->off - 40;
> + return insn->off;
> +}
> +
> /*
> * is_ereg() == true if BPF register 'reg' maps to x86-64 r8..r15
> * which need extra byte of encoding.
> @@ -197,14 +207,18 @@ static void emit_prologue(u8 **pprog, u32 stack_depth)
> u8 *prog = *pprog;
> int cnt = 0;
>
> + /* push rbp */
> + EMIT1(0x55);
> +
> + /* mov rbp,rsp */
> + EMIT3(0x48, 0x89, 0xE5);
> +
> /* push r15 */
> EMIT2(0x41, 0x57);
> /* push r14 */
> EMIT2(0x41, 0x56);
> /*
Re: [PATCH 1/6] dma: amba-pl08x: no need to cast away call to debugfs_create_file()
On Fri, Jun 14, 2019 at 11:16:13AM +0530, Vinod Koul wrote: > On 12-06-19, 14:25, Greg Kroah-Hartman wrote: > > No need to check the return value of debugfs_create_file(), so no need > > to provide a fake "cast away" of the return value either. > > Applied all after fixing the subsystem tag (dmaengine), thanks Sorry about that, and thanks! greg k-h
Re: [PATCH 5.1 000/155] 5.1.10-stable review
On Thu, Jun 13, 2019 at 01:03:08PM -0700, Guenter Roeck wrote: > On 6/13/19 1:31 AM, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 5.1.10 release. > > There are 155 patches in this series, all will be posted as a response > > to this one. If anyone has any issues with these being applied, please > > let me know. > > > > Responses should be made by Sat 15 Jun 2019 07:54:40 AM UTC. > > Anything received after that time might be too late. > > > > Build results: > total: 159 pass: 159 fail: 0 > Qemu test results: > total: 354 pass: 354 fail: 0 Great, thanks for testing and letting me know. greg k-h
Re: [PATCH 5.1 000/155] 5.1.10-stable review
On Thu, Jun 13, 2019 at 03:08:49PM -0500, Jiunn Chang wrote: > On Thu, Jun 13, 2019 at 10:31:52AM +0200, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 5.1.10 release. > > There are 155 patches in this series, all will be posted as a response > > to this one. If anyone has any issues with these being applied, please > > let me know. > > > > Responses should be made by Sat 15 Jun 2019 07:54:40 AM UTC. > > Anything received after that time might be too late. > > > > The whole patch series can be found in one patch at: > > > > https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.1.10-rc1.gz > > or in the git tree and branch at: > > > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > > linux-5.1.y > > and the diffstat can be found below. > > > > thanks, > > > > greg k-h > > > > - > Compiled and booted. No regressions on x86_64. > > This is for 5.1.10-rc2 from git --no-pager log --oneline -1. What do you mean by 'git --no-pager log --oneline -1' ? thanks for testing, greg k-h
Re: [PATCH 1/6] dma: amba-pl08x: no need to cast away call to debugfs_create_file()
On 12-06-19, 14:25, Greg Kroah-Hartman wrote: > No need to check the return value of debugfs_create_file(), so no need > to provide a fake "cast away" of the return value either. Applied all after fixing the subsystem tag (dmaengine), thanks -- ~Vinod
Re: [PATCH 5.1 000/155] 5.1.10-stable review
On Thu, Jun 13, 2019 at 06:44:40PM -0600, shuah wrote: > On 6/13/19 2:31 AM, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 5.1.10 release. > > There are 155 patches in this series, all will be posted as a response > > to this one. If anyone has any issues with these being applied, please > > let me know. > > > > Responses should be made by Sat 15 Jun 2019 07:54:40 AM UTC. > > Anything received after that time might be too late. > > > > The whole patch series can be found in one patch at: > > > > https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.1.10-rc1.gz > > or in the git tree and branch at: > > > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > > linux-5.1.y > > and the diffstat can be found below. > > > > thanks, > > > > greg k-h > > > > Compiled and booted on my test system. No dmesg regressions. Great, thanks for testing and letting me know. greg k-h
Re: [PATCH 5.1 000/155] 5.1.10-stable review
On Fri, Jun 14, 2019 at 12:09:12AM +0530, Naresh Kamboju wrote: > On Thu, 13 Jun 2019 at 14:15, Greg Kroah-Hartman > wrote: > > > > This is the start of the stable review cycle for the 5.1.10 release. > > There are 155 patches in this series, all will be posted as a response > > to this one. If anyone has any issues with these being applied, please > > let me know. > > > > Responses should be made by Sat 15 Jun 2019 07:54:40 AM UTC. > > Anything received after that time might be too late. > > > > The whole patch series can be found in one patch at: > > > > https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.1.10-rc1.gz > > or in the git tree and branch at: > > > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > > linux-5.1.y > > and the diffstat can be found below. > > > > thanks, > > > > greg k-h > > > > Results from Linaro’s test farm. > No regressions on arm64, arm, x86_64, and i386. Thanks for testing all of these and letting me know. greg k-h
Re: [PATCH v2] RDMA/cma: Make CM response timeout and # CM retries configurable
> On 13 Jun 2019, at 22:25, Doug Ledford wrote:
>
> On Thu, 2019-06-13 at 18:58 +0200, Håkon Bugge wrote:
>>> On 13 Jun 2019, at 16:25, Doug Ledford wrote:
>>>
>>> On Tue, 2019-02-26 at 08:57 +0100, Håkon Bugge wrote:
During certain workloads, the default CM response timeout is too
short, leading to excessive retries. Hence, make it configurable
through sysctl. While at it, also make number of CM retries
configurable.
The defaults are not changed.
Signed-off-by: Håkon Bugge
---
v1 -> v2:
* Added unregister_net_sysctl_table() in cma_cleanup()
---
drivers/infiniband/core/cma.c | 52
++---
--
1 file changed, 45 insertions(+), 7 deletions(-)
>>>
>>> This has been sitting on patchworks since forever. Presumably
>>> because
>>> Jason and I neither one felt like we really wanted it, but also
>>> couldn't justify flat refusing it.
>>
>> I thought the agreement was to use NL and iproute2. But I haven't had
>> the capacity.
>
> To be fair, the email thread was gone from my linux-rdma folder. So, I
> just had to review the entry in patchworks, and there was no captured
> discussion there. So, if the agreement was made, it must have been
> face to face some time and if I was involed, I had certainly forgotten
> by now. But I still needed to clean up patchworks, hence my email ;-).
This is the "agreement" I was referring too:
> On 4 Mar 2019, at 07:27, Parav Pandit wrote:
>
>> []
>
> I think we should use rdma_nl_register(RDMA_NL_RDMA_CM, cma_cb_table) which
> was removed as part of ID stats removal.
> Because of below reasons.
> 1. rdma netlink command auto loads the module
> 2. we don't need to write any extra code to do register_net_sysctl () in each
> netns.
> Caller's skb's netns will read/write value of response_timeout in 'struct
> cma_pernet'.
> 3. last time sysctl added in ipv6 was in 2017 in net/ipv6/addrconf.c, however
> ipv4 was done in 2018.
>
> Currently rdma_cm/rdma_ucma has configfs, sysctl.
> We are adding netlink sys params to ib_core.
>
> We already have 3 clients and infra built using rdma_nl_register() netlink ,
> so hooking up to netlink will provide unified way to set rdma params.
> Let's just use netlink for any new params unless it is not doable.
>
>>> Well, I've made up my mind, so
>>> unless Jason wants to argue the other side, I'm rejecting this
>>> patch.
>>> Here's why. The whole concept of a timeout is to help recovery in
>>> a
>>> situation that overloads one end of the connection. There is a
>>> relationship between the max queue backlog on the one host and the
>>> timeout on the other host.
>>
>> If you refer to the backlog parameter in rdma_listen(), I cannot see
>> it being used at all for IB.
>
> No, not exactly. I was more referring to heavy load causing an
> overflow in the mad packet receive processing. We have
> IB_MAD_QP_RECV_SIZE set to 512 by default, but it can be changed at
> module load time of the ib_core module and that represents the maximum
> number of backlogged mad packets we can have waiting to be processed
> before we just drop them on the floor. There can be other places to
> drop them too, but this is the one I was referring to.
That is another scenario than what I try to solve. What I see, is that the MAD
packets are delayed, not lost. The delay is longer than the CMA timeout. Hence,
the MAD packets are retried, adding more burden to the PF proxying and inducing
even longer delays. And excessive CM retries are observed. See 2612d723aadc
("IB/mlx4: Increase the timeout for CM cache") where I have some quantification
thereof.
Back to your scenario above, yes indeed, the queue sizes are module params. If
the MADs are tossed, we will see rq_num_udsdprd incrementing on a CX-3.
But I do not understand how the dots are connected. Assume one client does
rdma_listen(, backlog = 1000); Where are those 1000 REQs stored, assuming an
"infinite slow processor"?
Thxs, Håkon
>
>> For CX-3, which is paravirtualized wrt. MAD packets, it is the proxy
>> UD receive queue length for the PF driver that can be construed as a
>> backlog. Remember that any MAD packet being sent from a VF or the PF
>> itself, is sent to a proxy UD QP in the PF. Those packets are then
>> multiplexed out on the real QP0/1. Incoming MAD packets are
>> demultiplexed and sent once more to the proxy QP in the VF.
>>
>>> Generally, in order for a request to get
>>> dropped and us to need to retransmit, the queue must already have a
>>> full backlog. So, how long does it take a heavily loaded system to
>>> process a full backlog? That, plus a fuzz for a margin of error,
>>> should be our timeout. We shouldn't be asking users to configure
>>> it.
>>
>> Customer configures #VMs and different workload may lead to way
>> different number of CM connections. The proxying of MAD packet
>> through the PF driver has a finite packet rate. With 64 VMs, 1
linux-next: build failure after merge of the integrity tree
Hi all,
After merging the integrity tree, today's linux-next build (powerpc
ppc64_defconfig) failed like this:
drivers/infiniband/core/device.c: In function 'ib_core_init':
drivers/infiniband/core/device.c:2531:8: error: implicit declaration of
function 'register_blocking_lsm_notifier'; did you mean
'register_lsm_notifier'? [-Werror=implicit-function-declaration]
ret = register_blocking_lsm_notifier(&ibdev_lsm_nb);
^~
register_lsm_notifier
drivers/infiniband/core/device.c:2550:2: error: implicit declaration of
function 'unregister_blocking_lsm_notifier'; did you mean
'unregister_lsm_notifier'? [-Werror=implicit-function-declaration]
unregister_blocking_lsm_notifier(&ibdev_lsm_nb);
^~~~
unregister_lsm_notifier
Caused by commit
bafe78e69508 ("LSM: switch to blocking policy update notifiers")
CONFIG_SECURITY is not set for this build and the !CONFIG_SECURITY
declarations were not fixed up in linux/security.h.
I have used the integrity tree from next-20190613 for today.
--
Cheers,
Stephen Rothwell
pgpIivfEWTn5B.pgp
Description: OpenPGP digital signature
[PATCH 2/2] pinctrl: qcom: Add SM8150 pinctrl driver
From: Prasad Sodagudi
Add initial pinctrl driver to support pin configuration with
pinctrl framework for SM8150
Signed-off-by: Prasad Sodagudi
Signed-off-by: Isaac J. Manjarres
Signed-off-by: Vinod Koul
---
drivers/pinctrl/qcom/Kconfig |9 +
drivers/pinctrl/qcom/Makefile |1 +
drivers/pinctrl/qcom/pinctrl-sm8150.c | 1803 +
3 files changed, 1813 insertions(+)
create mode 100644 drivers/pinctrl/qcom/pinctrl-sm8150.c
diff --git a/drivers/pinctrl/qcom/Kconfig b/drivers/pinctrl/qcom/Kconfig
index 2e66ab72c10b..47be1622dcf6 100644
--- a/drivers/pinctrl/qcom/Kconfig
+++ b/drivers/pinctrl/qcom/Kconfig
@@ -175,4 +175,13 @@ config PINCTRL_SDM845
Qualcomm Technologies Inc TLMM block found on the Qualcomm
Technologies Inc SDM845 platform.
+config PINCTRL_SM8150
+ tristate "Qualcomm Technologies Inc SM8150 pin controller driver"
+ depends on GPIOLIB && OF
+ select PINCTRL_MSM
+ help
+ This is the pinctrl, pinmux, pinconf and gpiolib driver for the
+ Qualcomm Technologies Inc TLMM block found on the Qualcomm
+ Technologies Inc SM8150 platform.
+
endif
diff --git a/drivers/pinctrl/qcom/Makefile b/drivers/pinctrl/qcom/Makefile
index 344b4c6a6c6e..ebe906872272 100644
--- a/drivers/pinctrl/qcom/Makefile
+++ b/drivers/pinctrl/qcom/Makefile
@@ -22,3 +22,4 @@ obj-$(CONFIG_PINCTRL_QCOM_SSBI_PMIC) += pinctrl-ssbi-gpio.o
obj-$(CONFIG_PINCTRL_QCOM_SSBI_PMIC) += pinctrl-ssbi-mpp.o
obj-$(CONFIG_PINCTRL_SDM660) += pinctrl-sdm660.o
obj-$(CONFIG_PINCTRL_SDM845) += pinctrl-sdm845.o
+obj-$(CONFIG_PINCTRL_SM8150) += pinctrl-sm8150.o
diff --git a/drivers/pinctrl/qcom/pinctrl-sm8150.c
b/drivers/pinctrl/qcom/pinctrl-sm8150.c
new file mode 100644
index ..c9e5a03f262d
--- /dev/null
+++ b/drivers/pinctrl/qcom/pinctrl-sm8150.c
@@ -0,0 +1,1803 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2018, The Linux Foundation. All rights reserved.
+ */
+
+#include
+#include
+#include
+#include
+
+#include "pinctrl-msm.h"
+
+static const char * const sm8150_tiles[] = {
+ "north",
+ "south",
+ "east",
+ "west"
+};
+
+enum {
+ NORTH,
+ SOUTH,
+ EAST,
+ WEST
+};
+
+#define FUNCTION(fname)\
+ [msm_mux_##fname] = { \
+ .name = #fname, \
+ .groups = fname##_groups, \
+ .ngroups = ARRAY_SIZE(fname##_groups), \
+ }
+
+#define PINGROUP(id, _tile, f1, f2, f3, f4, f5, f6, f7, f8, f9)\
+ { \
+ .name = "gpio" #id, \
+ .pins = gpio##id##_pins,\
+ .npins = (unsigned int)ARRAY_SIZE(gpio##id##_pins), \
+ .funcs = (int[]){ \
+ msm_mux_gpio, /* gpio mode */ \
+ msm_mux_##f1, \
+ msm_mux_##f2, \
+ msm_mux_##f3, \
+ msm_mux_##f4, \
+ msm_mux_##f5, \
+ msm_mux_##f6, \
+ msm_mux_##f7, \
+ msm_mux_##f8, \
+ msm_mux_##f9\
+ }, \
+ .nfuncs = 10, \
+ .ctl_reg = 0x1000 * id, \
+ .io_reg = 0x1000 * id + 0x4,\
+ .intr_cfg_reg = 0x1000 * id + 0x8, \
+ .intr_status_reg = 0x1000 * id + 0xc, \
+ .intr_target_reg = 0x1000 * id + 0x8, \
+ .tile = _tile, \
+ .mux_bit = 2, \
+ .pull_bit = 0, \
+ .drv_bit = 6, \
+ .oe_bit = 9,\
+ .in_bit = 0,\
+ .out_bit = 1, \
+ .intr_enable_bit = 0, \
+ .intr_status_bit = 0, \
+ .intr_target_bit = 5, \
+ .intr_target_kpss_val = 3, \
+ .intr_raw_status_bit = 4, \
+ .intr_polarity_bit = 1, \
+ .intr_detection_bit = 2,\
+ .intr_detection_width = 2, \
+ }
+
+#define SDC_QDSD_PINGROUP(pg_name, ctl, pull, drv) \
+ { \
+ .name = #pg_name, \
+ .pins = pg_name##_pins, \
+ .npins = (unsigned int)ARRAY_SIZE(pg_name##_pins), \
+
[PATCH 1/2] dt-bindings: pinctrl: qcom: Add SM8150 pinctrl binding
From: Prasad Sodagudi Add the binding for the TLMM pinctrl block found in the SM8150 platform. Signed-off-by: Prasad Sodagudi Signed-off-by: Isaac J. Manjarres Signed-off-by: Vinod Koul --- .../bindings/pinctrl/qcom,sm8150-pinctrl | 200 ++ 1 file changed, 200 insertions(+) create mode 100644 Documentation/devicetree/bindings/pinctrl/qcom,sm8150-pinctrl diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,sm8150-pinctrl b/Documentation/devicetree/bindings/pinctrl/qcom,sm8150-pinctrl new file mode 100644 index ..4f21d18b0be2 --- /dev/null +++ b/Documentation/devicetree/bindings/pinctrl/qcom,sm8150-pinctrl @@ -0,0 +1,200 @@ +Qualcomm SM8150 TLMM block + +This binding describes the Top Level Mode Multiplexer block found in the +QCS404 platform. + +- compatible: + Usage: required + Value type: + Definition: must be "qcom,sm8150-pinctrl" + +- reg: + Usage: required + Value type: + Definition: the base address and size of the north, south , west + and east TLMM tiles. + +- reg-names: + Usage: required + Value type: + Defintiion: names for the cells of reg, must contain "north", "south" + "west" and "east". + +- interrupts: + Usage: required + Value type: + Definition: should specify the TLMM summary IRQ. + +- interrupt-controller: + Usage: required + Value type: + Definition: identifies this node as an interrupt controller + +- #interrupt-cells: + Usage: required + Value type: + Definition: must be 2. Specifying the pin number and flags, as defined + in + +- gpio-controller: + Usage: required + Value type: + Definition: identifies this node as a gpio controller + +- #gpio-cells: + Usage: required + Value type: + Definition: must be 2. Specifying the pin number and flags, as defined + in + +Please refer to ../gpio/gpio.txt and ../interrupt-controller/interrupts.txt for +a general description of GPIO and interrupt bindings. + +Please refer to pinctrl-bindings.txt in this directory for details of the +common pinctrl bindings used by client devices, including the meaning of the +phrase "pin configuration node". + +The pin configuration nodes act as a container for an arbitrary number of +subnodes. Each of these subnodes represents some desired configuration for a +pin, a group, or a list of pins or groups. This configuration can include the +mux function to select on those pin(s)/group(s), and various pin configuration +parameters, such as pull-up, drive strength, etc. + + +PIN CONFIGURATION NODES: + +The name of each subnode is not important; all subnodes should be enumerated +and processed purely based on their content. + +Each subnode only affects those parameters that are explicitly listed. In +other words, a subnode that lists a mux function but no pin configuration +parameters implies no information about any pin configuration parameters. +Similarly, a pin subnode that describes a pullup parameter implies no +information about e.g. the mux function. + + +The following generic properties as defined in pinctrl-bindings.txt are valid +to specify in a pin configuration subnode: + +- pins: + Usage: required + Value type: + Definition: List of gpio pins affected by the properties specified in + this subnode. + + Valid pins are: + gpio0-gpio149 + Supports mux, bias and drive-strength + + sdc1_clk, sdc1_cmd, sdc1_data sdc2_clk, sdc2_cmd, + sdc2_data sdc1_rclk + Supports bias and drive-strength + + ufs_reset + Supports bias and drive-strength + +- function: + Usage: required + Value type: + Definition: Specify the alternative function to be configured for the + specified pins. Functions are only valid for gpio pins. + Valid values are: + + blsp_uart1, blsp_spi1, blsp_i2c1, blsp_uim1, atest_tsens, + bimc_dte1, dac_calib0, blsp_spi8, blsp_uart8, blsp_uim8, + qdss_cti_trig_out_b, bimc_dte0, dac_calib1, qdss_cti_trig_in_b, + dac_calib2, atest_tsens2, atest_usb1, blsp_spi10, blsp_uart10, + blsp_uim10, atest_bbrx1, atest_usb13, atest_bbrx0, atest_usb12, + mdp_vsync, edp_lcd, blsp_i2c10, atest_gpsadc1, atest_usb11, + atest_gpsadc0, edp_hot, atest_usb10, m_voc, dac_gpio, atest_char, + cam_mclk, pll_bypassnl, qdss_stm7, blsp_i2c8, qdss_tracedata_b, + pll_reset, qdss_stm6, qdss_stm5, qdss_stm4, atest_usb2, cci_i2c, + qdss_stm3, dac_calib3, atest_usb23, atest_char3, dac_calib4, + qdss_stm2, atest_usb22, ate
Re: [PATCH] mm/vmalloc: Check absolute error return from vmap_[p4d|pud|pmd|pte]_range()
On 06/13/2019 09:01 PM, Matthew Wilcox wrote: > On Thu, Jun 13, 2019 at 08:51:17PM +0530, Anshuman Khandual wrote: >> acceptable ? What we have currently is wrong where vmap_pmd_range() could >> just wrap EBUSY as ENOMEM and send up the call chain. > > It's not wrong. We do it in lots of places. Unless there's a caller > which really needs to know the difference, it's often better than > returning the "real error". I can understand the fact that because there are no active users of this return code, the current situation has been alright. But then I fail to understand how can EBUSY be made ENOMEM and let the caller to think that vmap_page_rage() failed because of lack of memory when it is clearly not the case. It is really surprising how it can be acceptable inside kernel (init_mm) page table functions which need to be thorough enough.
[PATCH 2/2] mmc: mediatek: fix SDIO IRQ detection issue
From: jjian zhou If cmd19 timeout or response crcerr occurs during execute_tuning(), it need invoke msdc_reset_hw(). Otherwise SDIO IRQ can't be detected. Signed-off-by: jjian zhou Signed-off-by: Chaotian Jing Signed-off-by: Yong Mao --- drivers/mmc/host/mtk-sd.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/mmc/host/mtk-sd.c b/drivers/mmc/host/mtk-sd.c index 29992ae..df8f09d 100644 --- a/drivers/mmc/host/mtk-sd.c +++ b/drivers/mmc/host/mtk-sd.c @@ -1031,6 +1031,8 @@ static void msdc_request_done(struct msdc_host *host, struct mmc_request *mrq) msdc_track_cmd_data(host, mrq->cmd, mrq->data); if (mrq->data) msdc_unprepare_data(host, mrq); + if (host->error) + msdc_reset_hw(host); mmc_request_done(host->mmc, mrq); } -- 1.9.1
[PATCH 1/2] mmc: mediatek: fix SDIO IRQ interrupt handle flow
From: jjian zhou
SDIO IRQ is triggered by low level. It need disable SDIO IRQ
detected function. Otherwise the interrupt register can't be cleared.
It will process the interrupt more.
Signed-off-by: Jjian Zhou
Signed-off-by: Chaotian Jing
Signed-off-by: Yong Mao
---
drivers/mmc/host/mtk-sd.c | 13 +++--
1 file changed, 7 insertions(+), 6 deletions(-)
diff --git a/drivers/mmc/host/mtk-sd.c b/drivers/mmc/host/mtk-sd.c
index c518cc2..29992ae 100644
--- a/drivers/mmc/host/mtk-sd.c
+++ b/drivers/mmc/host/mtk-sd.c
@@ -1389,10 +1389,12 @@ static void __msdc_enable_sdio_irq(struct mmc_host
*mmc, int enb)
struct msdc_host *host = mmc_priv(mmc);
spin_lock_irqsave(&host->lock, flags);
- if (enb)
+ if (enb) {
sdr_set_bits(host->base + MSDC_INTEN, MSDC_INTEN_SDIOIRQ);
- else
+ sdr_set_bits(host->base + SDC_CFG, SDC_CFG_SDIOIDE);
+ } else {
sdr_clr_bits(host->base + MSDC_INTEN, MSDC_INTEN_SDIOIRQ);
+ }
spin_unlock_irqrestore(&host->lock, flags);
}
@@ -1422,6 +1424,8 @@ static irqreturn_t msdc_irq(int irq, void *dev_id)
spin_lock_irqsave(&host->lock, flags);
events = readl(host->base + MSDC_INT);
event_mask = readl(host->base + MSDC_INTEN);
+ if ((events & event_mask) & MSDC_INT_SDIOIRQ)
+ sdr_clr_bits(host->base + SDC_CFG, SDC_CFG_SDIOIDE);
/* clear interrupts */
writel(events & event_mask, host->base + MSDC_INT);
@@ -1572,10 +1576,7 @@ static void msdc_init_hw(struct msdc_host *host)
sdr_set_bits(host->base + SDC_CFG, SDC_CFG_SDIO);
/* Config SDIO device detect interrupt function */
- if (host->mmc->caps & MMC_CAP_SDIO_IRQ)
- sdr_set_bits(host->base + SDC_CFG, SDC_CFG_SDIOIDE);
- else
- sdr_clr_bits(host->base + SDC_CFG, SDC_CFG_SDIOIDE);
+ sdr_clr_bits(host->base + SDC_CFG, SDC_CFG_SDIOIDE);
/* Configure to default data timeout */
sdr_set_field(host->base + SDC_CFG, SDC_CFG_DTOC, 3);
--
1.9.1
Re: [PATCH 5/5] x86/vsyscall: Change the default vsyscall mode to xonly
On Thu, Jun 13, 2019 at 12:14:50PM -0700, Andy Lutomirski wrote: > On Mon, Jun 10, 2019 at 1:44 PM Kees Cook wrote: > > > > On Mon, Jun 10, 2019 at 01:25:31PM -0700, Andy Lutomirski wrote: > > > The use case for full emulation over xonly is very esoteric. Let's > > > change the default to the safer xonly mode. > > > > Perhaps describe the esoteric cases here (and maybe in the Kconfig help > > text)? That should a user determine if they actually need it. (What > > would the failure under xonly look like for someone needing emulate?) > > I added it to the Kconfig text. > > Right now, the failure will just be a segfault. I could add some > logic so that it would log "invalid read to vsyscall page -- fix your > userspace or boot with vsyscall=emulate". Do you think that's > important? I think it would be a friendly way to help anyone wondering why something suddenly started segfaulting, yeah. Just a pr_warn_once() or something (not a WARN() since it's "intentionally" reachable by userspace). -- Kees Cook
Re: [PATCH] mm: Generalize and rename notify_page_fault() as kprobe_page_fault()
On 06/14/2019 01:34 AM, Andrew Morton wrote:
> On Thu, 13 Jun 2019 15:37:24 +0530 Anshuman Khandual
> wrote:
>
>> Architectures which support kprobes have very similar boilerplate around
>> calling kprobe_fault_handler(). Use a helper function in kprobes.h to unify
>> them, based on the x86 code.
>>
>> This changes the behaviour for other architectures when preemption is
>> enabled. Previously, they would have disabled preemption while calling the
>> kprobe handler. However, preemption would be disabled if this fault was
>> due to a kprobe, so we know the fault was not due to a kprobe handler and
>> can simply return failure.
>>
>> This behaviour was introduced in the commit a980c0ef9f6d ("x86/kprobes:
>> Refactor kprobes_fault() like kprobe_exceptions_notify()")
>>
>> ...
>>
>> --- a/arch/arm/mm/fault.c
>> +++ b/arch/arm/mm/fault.c
>> @@ -30,28 +30,6 @@
>>
>> #ifdef CONFIG_MMU
>>
>> -#ifdef CONFIG_KPROBES
>> -static inline int notify_page_fault(struct pt_regs *regs, unsigned int fsr)
>
> Some architectures make this `static inline'. Others make it
> `nokprobes_inline', others make it `static inline __kprobes'. The
> latter seems weird - why try to put an inline function into
> .kprobes.text?
>
> So.. what's the best thing to do here? You chose `static
> nokprobe_inline' - is that the best approach, if so why? Does
> kprobe_page_fault() actually need to be inlined?
Matthew had suggested that (nokprobe_-inline) based on current x86
implementation. But every architecture already had an inlined definition
which I did not want to deviate from.
>
> Also, some architectures had notify_page_fault returning int, others
> bool. You chose bool and that seems appropriate and all callers are OK
> with that.
I would believe so. No one has complained yet :)
Re: [RFC PATCH 0/1] security: add SECURE_KEEP_FSUID to preserve fsuid/fsgid across execve
On Thu, 13 Jun 2019, Igor Lubashev wrote: > I've posted this in March but received no response. Reposting. > > This patch introduces SECURE_KEEP_FSUID to allow fsuid/fsgid to be > preserved across execve. It is currently impossible to execve a > program such that effective and filesystem uid differ. > > The need for this functionality arose from a desire to allow certain > non-privileged users to run perf. To do this, we install perf without > set-uid-root and have a set-uid-root wrapper decide who is allowed to > run perf (and with what arguments). > > The wrapper must execve perf with real and effective root uid, because > perf and KASLR require this. However, that presently resets fsuid to > root, giving the user ability to read and overwrite any file owned by > root (perf report -i, perf record -o). Also, perf record will create > perf.data that cannot be deleted by the user. > > We cannot reset /proc/sys/kernel/perf_event_paranoid to a permissive > level, since we must be selective which users have the permissions. > > Of course, we could fix our problem by a patch to perf to allow > passing a username on the command line and having perf execute > setfsuid before opening files. However, perf is not the only program > that uses kernel features that require root uid/euid, so a general > solution that does not involve updating all such programs seems > warranted. This seems like a very specific corner case, depending on fsuid!=0 for an euid=0 process, along with a whitelist policy for perf arguments. It would be a great way to escalate to root via a bug in an executed app or via a wrapper misconfiguration. It also adds complexity to kernel credential handling -- it's yet another thing to consider when trying to reason about this. Have you considered the example security configuration in Documentation/admin-guide/perf-security.rst ? What are some other examples of programs that could utilize this scheme? -- James Morris
Re: [PATCH 7/9] x86/unwind/orc: Fall back to using frame pointers for generated code
On Thu, Jun 13, 2019 at 09:28:48PM -0500, Josh Poimboeuf wrote:
> On Thu, Jun 13, 2019 at 08:58:48PM -0500, Josh Poimboeuf wrote:
> > On Thu, Jun 13, 2019 at 06:42:45PM -0700, Alexei Starovoitov wrote:
> > > On Thu, Jun 13, 2019 at 08:30:51PM -0500, Josh Poimboeuf wrote:
> > > > On Thu, Jun 13, 2019 at 03:00:55PM -0700, Alexei Starovoitov wrote:
> > > > > > @@ -392,8 +402,16 @@ bool unwind_next_frame(struct unwind_state
> > > > > > *state)
> > > > > > * calls and calls to noreturn functions.
> > > > > > */
> > > > > > orc = orc_find(state->signal ? state->ip : state->ip - 1);
> > > > > > - if (!orc)
> > > > > > - goto err;
> > > > > > + if (!orc) {
> > > > > > + /*
> > > > > > +* As a fallback, try to assume this code uses a frame
> > > > > > pointer.
> > > > > > +* This is useful for generated code, like BPF, which
> > > > > > ORC
> > > > > > +* doesn't know about. This is just a guess, so the
> > > > > > rest of
> > > > > > +* the unwind is no longer considered reliable.
> > > > > > +*/
> > > > > > + orc = &orc_fp_entry;
> > > > > > + state->error = true;
> > > > >
> > > > > That seems fragile.
> > > >
> > > > I don't think so. The unwinder has sanity checks to make sure it
> > > > doesn't go off the rails. And it works just fine. The beauty is that
> > > > it should work for all generated code (not just BPF).
> > > >
> > > > > Can't we populate orc_unwind tables after JIT ?
> > > >
> > > > As I mentioned it would introduce a lot more complexity. For each JIT
> > > > function, BPF would have to tell ORC the following:
> > > >
> > > > - where the BPF function lives
> > > > - how big the stack frame is
> > > > - where RBP and other callee-saved regs are on the stack
> > >
> > > that sounds like straightforward addition that ORC should have anyway.
> > > right now we're not using rbp in the jit-ed code,
> > > but one day we definitely will.
> > > Same goes for r12. It's reserved right now for 'strategic use'.
> > > We've been thinking to add another register to bpf isa.
> > > It will map to r12 on x86. arm64 and others have plenty of regs to use.
> > > The programs are getting bigger and register spill/fill starting to
> > > become a performance concern. Extra register will give us more room.
> >
> > With CONFIG_FRAME_POINTER, RBP isn't available. If you look at all the
> > code in the entire kernel you'll notice that BPF JIT is pretty much the
> > only one still clobbering it.
>
> Hm. If you wanted to eventually use R12 for other purposes, there might
> be a way to abstract BPF_REG_FP such that it doesn't actually need a
> dedicated register. The BPF program's frame pointer will always be a
> certain constant offset away from RBP (real frame pointer), so accesses
> to BPF_REG_FP could still be based on RBP, but with an offset added to
> it.
How about something like this (based on top of patch 4)? This fixes
frame pointers without using R12, by making BPF_REG_FP equivalent to
RBP, minus a constant offset (callee-save area + tail_call_cnt = 40).
diff --git a/arch/x86/net/bpf_jit_comp.c b/arch/x86/net/bpf_jit_comp.c
index 485692d4b163..2f313622c741 100644
--- a/arch/x86/net/bpf_jit_comp.c
+++ b/arch/x86/net/bpf_jit_comp.c
@@ -104,6 +104,9 @@ static int bpf_size_to_x86_bytes(int bpf_size)
* register in load/store instructions, it always needs an
* extra byte of encoding and is callee saved.
*
+ * BPF_REG_FP corresponds to x86-64 register RBP, but 40 bytes must be
+ * subtracted from it to get the BPF_REG_FP value.
+ *
* Also x86-64 register R9 is unused. x86-64 register R10 is
* used for blinding (if enabled).
*/
@@ -118,11 +121,18 @@ static const int reg2hex[] = {
[BPF_REG_7] = 5, /* R13 callee saved */
[BPF_REG_8] = 6, /* R14 callee saved */
[BPF_REG_9] = 7, /* R15 callee saved */
- [BPF_REG_FP] = 5, /* RBP readonly */
+ [BPF_REG_FP] = 5, /* (RBP - 40 bytes) readonly */
[BPF_REG_AX] = 2, /* R10 temp register */
[AUX_REG] = 3,/* R11 temp register */
};
+static s16 offset(struct bpf_insn *insn)
+{
+ if (insn->src_reg == BPF_REG_FP || insn->dst_reg == BPF_REG_FP)
+ return insn->off - 40;
+ return insn->off;
+}
+
/*
* is_ereg() == true if BPF register 'reg' maps to x86-64 r8..r15
* which need extra byte of encoding.
@@ -197,14 +207,18 @@ static void emit_prologue(u8 **pprog, u32 stack_depth)
u8 *prog = *pprog;
int cnt = 0;
+ /* push rbp */
+ EMIT1(0x55);
+
+ /* mov rbp,rsp */
+ EMIT3(0x48, 0x89, 0xE5);
+
/* push r15 */
EMIT2(0x41, 0x57);
/* push r14 */
EMIT2(0x41, 0x56);
/* push r13 */
EMIT2(0x41, 0x55);
- /* push rbp */
- EMIT1(0x55);
/* push rbx */
EMIT1(0x53);
@@ -216,14 +230,6 @@ static void emit_prologue(u8 **pprog, u32 stack_depth)
*/
[PATCH v4] platform/chrome: cros_ec_lpc: Choose Microchip EC at runtime
On many boards, communication between the kernel and the Embedded Controller happens over an LPC bus. In these cases, the kernel config CONFIG_CROS_EC_LPC is enabled. Some of these LPC boards contain a Microchip Embedded Controller (MEC) that is different from the regular EC. On these devices, the same LPC bus is used, but the protocol is a little different. In these cases, the CONFIG_CROS_EC_LPC_MEC kernel config is enabled. Currently, the kernel decides at compile-time whether or not to use the MEC variant, and, when that kernel option is selected it breaks the other boards. We would like a kind of runtime detection to avoid this. This patch adds that detection mechanism by probing the protocol at runtime, first we assume that a MEC variant is connected, and if the protocol fails it fallbacks to the regular EC. This adds a bit of overload because we try to read twice on those LPC boards that doesn't contain a MEC variant, but is a better solution than having to select the EC variant at compile-time. While here also fix the alignment in Kconfig file for this config option replacing the spaces by tabs. Signed-off-by: Enric Balletbo i Serra Reviewed-by: Ezequiel Garcia Tested-by: Nick Crews --- Hi, This is another attempt to solve the issue to be able to select at runtime the CrOS MEC variant. My first thought was check for a device ID, the MEC1322 has a register that contains the device ID, however I am not sure if we can read that register from the host without modifying the firmware. Also, I am not sure if the MEC1322 is the only device used that supports that LPC protocol variant, so I ended with a more easy solution, check if the protocol fails or not. Some background on this issue can be found [1] and [2] The patch has been tested on: - Acer Chromebook R11 (Cyan - MEC variant) - Pixel Chromebook 2015 (Samus - non-MEC variant) - Dell Chromebook 11 (Wolf - non-MEC variant) - Toshiba Chromebook (Leon - non-MEC variant) Best regards, Enric [1] https://bugs.chromium.org/p/chromium/issues/detail?id=932626 [2] https://chromium-review.googlesource.com/c/chromiumos/overlays/chromiumos-overlay/+/1474254 Changes in v4: - Change the logic to test the protocols as suggested by Nick Crews. - Add the proper cros_ec_lpc_mec.h include. (Nick Crews) - Fix some const and missing casts. (Nick Crews) - Clean up related doc-strings. (Nick Crews) Changes in v3: - Kconfig: Split across multiple lines to keep it under 80 characters. - Improve kernel-doc as suggested by Nick Crews. - Convert msg in write function to const. - Add rb and tb tags. Changes in v2: - Remove global bool to indicate the kind of variant as suggested by Ezequiel. - Create an internal operations struct to allow different variants. drivers/platform/chrome/Kconfig | 29 +++-- drivers/platform/chrome/Makefile | 2 +- drivers/platform/chrome/cros_ec_lpc.c | 78 --- drivers/platform/chrome/cros_ec_lpc_mec.h | 14 drivers/platform/chrome/cros_ec_lpc_reg.c | 41 drivers/platform/chrome/cros_ec_lpc_reg.h | 23 +++ drivers/platform/chrome/wilco_ec/Kconfig | 2 +- 7 files changed, 98 insertions(+), 91 deletions(-) diff --git a/drivers/platform/chrome/Kconfig b/drivers/platform/chrome/Kconfig index 2826f7136f65..453e69733842 100644 --- a/drivers/platform/chrome/Kconfig +++ b/drivers/platform/chrome/Kconfig @@ -83,28 +83,17 @@ config CROS_EC_SPI 'pre-amble' bytes before the response actually starts. config CROS_EC_LPC -tristate "ChromeOS Embedded Controller (LPC)" -depends on MFD_CROS_EC && ACPI && (X86 || COMPILE_TEST) -help - If you say Y here, you get support for talking to the ChromeOS EC - over an LPC bus. This uses a simple byte-level protocol with a - checksum. This is used for userspace access only. The kernel - typically has its own communication methods. - - To compile this driver as a module, choose M here: the - module will be called cros_ec_lpc. - -config CROS_EC_LPC_MEC - bool "ChromeOS Embedded Controller LPC Microchip EC (MEC) variant" - depends on CROS_EC_LPC - default n + tristate "ChromeOS Embedded Controller (LPC)" + depends on MFD_CROS_EC && ACPI && (X86 || COMPILE_TEST) help - If you say Y here, a variant LPC protocol for the Microchip EC - will be used. Note that this variant is not backward compatible - with non-Microchip ECs. + If you say Y here, you get support for talking to the ChromeOS EC + over an LPC bus, including the LPC Microchip EC (MEC) variant. + This uses a simple byte-level protocol with a checksum. This is + used for userspace access only. The kernel typically has its own + communication methods. - If you have a ChromeOS Embedded Controller Microchip EC variant - choose Y here. + To compile this driver as a module, choo
Re: [PATCH net v2] tcp: avoid creating multiple req socks with the same tuples
On 6/13/19 9:19 PM, maowenan wrote:
>
>
> @Eric, for this issue I only want to check TCP_NEW_SYN_RECV sk, is it OK like
> below?
> + if (!osk && sk->sk_state == TCP_NEW_SYN_RECV)
> + reqsk = __inet_lookup_established(sock_net(sk),
> &tcp_hashinfo,
> + sk->sk_daddr,
> sk->sk_dport,
> + sk->sk_rcv_saddr,
> sk->sk_num,
> + sk->sk_bound_dev_if,
> sk->sk_bound_dev_if);
> + if (unlikely(reqsk)) {
>
Not enough.
If we have many cpus here, there is a chance another cpu has inserted a request
socket, then
replaced it by an ESTABLISH socket for the same 4-tuple.
We need to take the per bucket spinlock much sooner.
And this is fine, all what matters is that we do no longer grab the listener
spinlock.
Re: [PATCH 1/2] Input: synaptics-rmi4 - clear irqs before set irqs
On 6/12/19 1:35 AM, Dmitry Torokhov wrote: > On Tue, Jun 11, 2019 at 12:55:58AM +0800, Aaron Ma wrote: >> On 6/10/19 12:55 AM, Dmitry Torokhov wrote: >>> Hi Aaron, >>> >>> On Wed, Feb 20, 2019 at 05:41:59PM +0100, Aaron Ma wrote: rmi4 got spam data after S3 resume on some ThinkPads. Then TrackPoint lost when be detected by psmouse. Clear irqs status before set irqs will make TrackPoint back. >>> Could you please give me an idea as to what this spam data is? >>> >> It should be some data 0 during suspend/resume. >> Actually I don't know how these data 0 is produced. >> Not all synaptics touchpads have this issue. >> >>> In F03 probe we clear all pending data before enabling the function, >> Yes we did, but not after resume. > Yes, I understand that. The question I was asking: if we add code > consuming all pending data to f03->suspend(), similarly to what we are > doing at probe time, will it fix the issue with trackstick losing > synchronization and attempting disconnect? > I just do some test via adding code in suspend or resume. But they didn't work out. >>> maybe the same needs to be done on resume, instead of changing the way >>> we handle IRQ bits? >> This patch is supposed to clear irq status like it in fn probe. Not >> changing IRQ bits. > What I meant is changing how we enable IRQ bits. I would really prefer > we did not lose IRQ state for other functions when we enable interrupts > for given function. > Not only F03 with problem, F12 too which is touchpad . User verified this patch fixes problem of F12 too. Clear IRQ status before enable IRQ should be safe. Or we can add code before enable IRQ in F03/F12. Thanks, Aaron > Thanks. > > -- Dmitry >
Re: memory leak in create_ctx
Hillf Danton wrote: > > Hi Dmitry > > On Tue, 11 Jun 2019 19:45:28 +0800 Dmitry Vyukov wrote: > > > > I've run the repro as "./syz-execprog -repeat=0 -procs=6 repro" and > > in 10 mins I got the following splat, which indeed suggests a bpf bug. > > But we of course can have both bpf stack overflow and a memory leak in tls. > > > > > > > > 2019/06/11 10:26:52 executed programs: 887 > > 2019/06/11 10:26:57 executed programs: 899 > > 2019/06/11 10:27:02 executed programs: 916 > > [ 429.171049][ T9870] BUG: stack guard page was hit at a78467b9 > > (stack is 1452e9df..4fb93e51) > > [ 429.173714][ T9870] kernel stack overflow (double-fault): [#1] > > PREEMPT SMP > > [ 429.174819][ T9870] CPU: 3 PID: 9870 Comm: syz-executor Not tainted > > 5.2.0-rc4+ #6 > > [ 429.175901][ T9870] Hardware name: QEMU Standard PC (i440FX + PIIX, > > 1996), BIOS 1.10.2-1 04/01/2014 > > [ 429.177215][ T9870] RIP: 0010:tcp_bpf_unhash+0xc/0x80 > > [ 429.177950][ T9870] Code: 28 4c 89 ee 48 89 df ff 10 e8 30 56 66 fe > > 5b 41 5c 41 5d 41 5e 5d c3 0f 1f 80 00 00 00 00 55 48 89 e5 41 55 41 > > 54 53 48 89 fb 0f 56 66 fe e8 6a bb 5f fe 4c 8b a3 80 02 00 00 4d > > 85 e4 74 2f > > [ 429.180707][ T9870] RSP: 0018:c9000369 EFLAGS: 00010293 > > [ 429.181562][ T9870] RAX: 888066a72000 RBX: 88806695b640 RCX: > > 82c82f80 > > [ 429.182681][ T9870] RDX: RSI: 0007 RDI: > > 88806695b640 > > [ 429.183807][ T9870] RBP: c90003690018 R08: R09: > > > > [ 429.184931][ T9870] R10: c90003693e70 R11: R12: > > 82c82f10 > > [ 429.186104][ T9870] R13: 0007 R14: 88806695b710 R15: > > 88806695b710 > > [ 429.187303][ T9870] FS: 569fc940() > > GS:88807db8() knlGS: > > [ 429.188678][ T9870] CS: 0010 DS: ES: CR0: 80050033 > > [ 429.189674][ T9870] CR2: c9000368fff8 CR3: 762bc002 CR4: > > 007606e0 > > [ 429.190880][ T9870] DR0: DR1: DR2: > > > > [ 429.192094][ T9870] DR3: DR6: fffe0ff0 DR7: > > 0400 > > [ 429.193295][ T9870] PKRU: 5554 > > [ 429.193829][ T9870] Call Trace: > > [ 429.194326][ T9870] ? tcp_bpf_close+0xa0/0xa0 > > [ 429.195020][ T9870] tcp_bpf_unhash+0x76/0x80 > > [ 429.195706][ T9870] ? tcp_bpf_close+0xa0/0xa0 > > [ 429.196400][ T9870] tcp_bpf_unhash+0x76/0x80 > > [ 429.197079][ T9870] ? tcp_bpf_close+0xa0/0xa0 > > [ 429.197773][ T9870] tcp_bpf_unhash+0x76/0x80 > > [ 429.651942][ T9870] ? tcp_bpf_close+0xa0/0xa0 > > > ... duplicated info trimed ... > > > > [ 429.652512][ T9870] tcp_bpf_unhash+0x76/0x80 > > [ 429.656467][ T9870] ? tcp_bpf_close+0xa0/0xa0 > > [ 429.657037][ T9870] tcp_bpf_unhash+0x76/0x80 > > [ 429.657600][ T9870] tcp_set_state+0x7b/0x220 > > [ 429.658160][ T9870] ? put_object+0x20/0x30 > > [ 429.658699][ T9870] ? debug_smp_processor_id+0x2b/0x130 > > [ 429.659382][ T9870] tcp_disconnect+0x518/0x610 > > [ 429.659973][ T9870] tcp_close+0x41d/0x540 > > [ 429.660501][ T9870] ? tcp_check_oom+0x180/0x180 > > [ 429.661095][ T9870] tls_sk_proto_close+0x86/0x2a0 > > [ 429.661711][ T9870] ? locks_remove_posix+0x114/0x1c0 > > [ 429.662359][ T9870] inet_release+0x44/0x80 > > [ 429.662899][ T9870] inet6_release+0x36/0x50 > > [ 429.663453][ T9870] __sock_release+0x4b/0x100 > > [ 429.664024][ T9870] ? __sock_release+0x100/0x100 > > [ 429.664625][ T9870] sock_close+0x19/0x20 > > [ 429.665141][ T9870] __fput+0xe7/0x2f0 > > [ 429.665624][ T9870] fput+0x15/0x20 > > [ 429.666120][ T9870] task_work_run+0xa4/0xd0 > > [ 429.71][ T9870] exit_to_usermode_loop+0x16f/0x180 > > [ 429.667329][ T9870] do_syscall_64+0x187/0x1b0 > > [ 429.667920][ T9870] entry_SYSCALL_64_after_hwframe+0x44/0xa9 > > [ 429.668654][ T9870] RIP: 0033:0x412451 > > [ 429.669141][ T9870] Code: 75 14 b8 03 00 00 00 0f 05 48 3d 01 f0 ff > > ff 0f 83 94 1a 00 00 c3 48 83 ec 08 e8 0a fc ff ff 48 89 04 24 b8 03 > > 00 00 00 0f 05 <48> 8b 3c 24 48 89 c2 e8 53 fc ff ff 48 89 d0 48 83 c4 > > 08 48 3d 01 > > [ 429.671586][ T9870] RSP: 002b:7ffde18b5470 EFLAGS: 0293 > > ORIG_RAX: 0003 > > [ 429.672636][ T9870] RAX: RBX: 0005 RCX: > > 00412451 > > [ 429.673628][ T9870] RDX: RSI: 0081 RDI: > > 0004 > > [ 429.674643][ T9870] RBP: R08: 00721170 R09: > > > > [ 429.675641][ T9870] R10: 7ffde18b5580 R11: 0293 R12: > > > > [ 429.676636][ T9870] R13: 0071bf00 R14: 006e3140 R15: > > > > [ 429.677630][ T9870] Modules linked in: > > [ 429.678119][ T9870] ---[ end trace a429c7ce256ca7bb ]--- > > [ 429.678798][ T9870] RIP: 0010:tcp_bpf_unhash+0xc/0x80 > > [ 4
Re: [PATCH net v2] tcp: avoid creating multiple req socks with the same tuples
>>> diff --git a/net/ipv4/inet_connection_sock.c
>>> b/net/ipv4/inet_connection_sock.c
>>> index 13ec7c3a9c49..fd45ed2fd985 100644
>>> --- a/net/ipv4/inet_connection_sock.c
>>> +++ b/net/ipv4/inet_connection_sock.c
>>> @@ -749,7 +749,7 @@ static void reqsk_timer_handler(struct timer_list *t)
>>> inet_csk_reqsk_queue_drop_and_put(sk_listener, req);
>>> }
>>>
>>> -static void reqsk_queue_hash_req(struct request_sock *req,
>>> +static bool reqsk_queue_hash_req(struct request_sock *req,
>>> unsigned long timeout)
>>> {
>>> req->num_retrans = 0;
>>> @@ -759,19 +759,27 @@ static void reqsk_queue_hash_req(struct request_sock
>>> *req,
>>> timer_setup(&req->rsk_timer, reqsk_timer_handler, TIMER_PINNED);
>>> mod_timer(&req->rsk_timer, jiffies + timeout);
>>>
>>> - inet_ehash_insert(req_to_sk(req), NULL);
>>> + if (!inet_ehash_insert(req_to_sk(req), NULL)) {
>>> + if (timer_pending(&req->rsk_timer))
>>> + del_timer_sync(&req->rsk_timer);
>>> + return false;
>>> + }
>>> /* before letting lookups find us, make sure all req fields
>>> * are committed to memory and refcnt initialized.
>>> */
>>> smp_wmb();
>>> refcount_set(&req->rsk_refcnt, 2 + 1);
>>> + return true;
>>> }
>>>
>>> -void inet_csk_reqsk_queue_hash_add(struct sock *sk, struct request_sock
>>> *req,
>>> +bool inet_csk_reqsk_queue_hash_add(struct sock *sk, struct request_sock
>>> *req,
>>>unsigned long timeout)
>>> {
>>> - reqsk_queue_hash_req(req, timeout);
>>> + if (!reqsk_queue_hash_req(req, timeout))
>>> + return false;
>>> +
>>> inet_csk_reqsk_queue_added(sk);
>>> + return true;
>>> }
>>> EXPORT_SYMBOL_GPL(inet_csk_reqsk_queue_hash_add);
>>>
>>> diff --git a/net/ipv4/inet_hashtables.c b/net/ipv4/inet_hashtables.c
>>> index c4503073248b..b6a1b5334565 100644
>>> --- a/net/ipv4/inet_hashtables.c
>>> +++ b/net/ipv4/inet_hashtables.c
>>> @@ -477,6 +477,7 @@ bool inet_ehash_insert(struct sock *sk, struct sock
>>> *osk)
>>> struct inet_ehash_bucket *head;
>>> spinlock_t *lock;
>>> bool ret = true;
>>> + struct sock *reqsk = NULL;
>>>
>>> WARN_ON_ONCE(!sk_unhashed(sk));
>>>
>>> @@ -486,6 +487,18 @@ bool inet_ehash_insert(struct sock *sk, struct sock
>>> *osk)
>>> lock = inet_ehash_lockp(hashinfo, sk->sk_hash);
>>>
>>> spin_lock(lock);
>>> + if (!osk)
>>> + reqsk = __inet_lookup_established(sock_net(sk),
>>> &tcp_hashinfo,
>>> + sk->sk_daddr,
>>> sk->sk_dport,
>>> + sk->sk_rcv_saddr,
>>> sk->sk_num,
>>> +
>>> sk->sk_bound_dev_if, sk->sk_bound_dev_if);
>>> + if (unlikely(reqsk)) {
>>
>> What reqsk would be a SYN_RECV socket, and not a ESTABLISH one (or a
>> TIME_WAIT ?)
>
> It wouldn't be SYN_RECV,ESTABLISH or TIME_WAIT, just TCP_NEW_SYN_RECV.
>
> When server receives the third handshake packet ACK, SYN_RECV sk will insert
> to hash with osk(!= NULL).
> The looking up here just avoid to create two or more request sk with
> TCP_NEW_SYN_RECV when receive syn packet.
>
@Eric, for this issue I only want to check TCP_NEW_SYN_RECV sk, is it OK like
below?
+ if (!osk && sk->sk_state == TCP_NEW_SYN_RECV)
+ reqsk = __inet_lookup_established(sock_net(sk), &tcp_hashinfo,
+ sk->sk_daddr,
sk->sk_dport,
+ sk->sk_rcv_saddr,
sk->sk_num,
+ sk->sk_bound_dev_if,
sk->sk_bound_dev_if);
+ if (unlikely(reqsk)) {
>>
>>> + ret = false;
>>> + reqsk_free(inet_reqsk(sk));
>>> + spin_unlock(lock);
>>> + return ret;
>>> + }
>>> +
>>> if (osk) {
>>
>> This test should have be a hint here : Sometime we _expect_ to have an
>> old socket (TIMEWAIT) and remove it
> I will check TIMEWAIT sk.
>>
>>
>>> WARN_ON_ONCE(sk->sk_hash != osk->sk_hash);
>>> ret = sk_nulls_del_node_init_rcu(osk);
>>> diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
>>> index 38dfc308c0fb..358272394590 100644
>>> --- a/net/ipv4/tcp_input.c
>>> +++ b/net/ipv4/tcp_input.c
>>> @@ -6570,9 +6570,10 @@ int tcp_conn_request(struct request_sock_ops
>>> *rsk_ops,
>>> sock_put(fastopen_sk);
>>> } else {
>>> tcp_rsk(req)->tfo_listener = false;
>>> - if (!want_cookie)
>>> - inet_csk_reqsk_queue_hash_add(sk, req,
>>> - tcp_timeout_init((struct sock *)req));
>>> + if (!want_cookie && !inet_csk_reqsk_queu
[PATCH v2 10/11] OPP: Allow copying OPPs tables between devices
Some hardware devices might create multiple children devices to manage
different components of the hardware. In these cases, it might be necessary
for the original hardware device to copy specific OPP tables to a specific
the new child device. Add dev_pm_opp_add_opp_table() to do that.
Signed-off-by: Saravana Kannan
---
drivers/opp/core.c | 8
include/linux/pm_opp.h | 7 +++
2 files changed, 15 insertions(+)
diff --git a/drivers/opp/core.c b/drivers/opp/core.c
index c9914afd508a..668a377f59a5 100644
--- a/drivers/opp/core.c
+++ b/drivers/opp/core.c
@@ -943,6 +943,14 @@ struct opp_device *_add_opp_dev(const struct device *dev,
return opp_dev;
}
+int dev_pm_opp_add_opp_table(struct device *dev, struct opp_table *opp_table)
+{
+ if (!dev || !opp_table)
+ return -EINVAL;
+
+ return _add_opp_dev(dev, opp_table) ? 0 : -ENOMEM;
+}
+
static struct opp_table *_allocate_opp_table(struct device *dev, int index)
{
struct opp_table *opp_table;
diff --git a/include/linux/pm_opp.h b/include/linux/pm_opp.h
index d9156b62d966..3694d703817f 100644
--- a/include/linux/pm_opp.h
+++ b/include/linux/pm_opp.h
@@ -81,6 +81,7 @@ struct dev_pm_set_opp_data {
struct opp_table *dev_pm_opp_get_opp_table(struct device *dev);
struct opp_table *dev_pm_opp_get_opp_table_indexed(struct device *dev, int
index);
void dev_pm_opp_put_opp_table(struct opp_table *opp_table);
+int dev_pm_opp_add_opp_table(struct device *dev, struct opp_table *opp_table);
unsigned long dev_pm_opp_get_voltage(struct dev_pm_opp *opp);
@@ -158,6 +159,12 @@ static inline struct opp_table
*dev_pm_opp_get_opp_table_indexed(struct device *
static inline void dev_pm_opp_put_opp_table(struct opp_table *opp_table) {}
+static int dev_pm_opp_add_opp_table(struct device *dev,
+ struct opp_table *opp_table)
+{
+ return -ENOTSUPP;
+}
+
static inline unsigned long dev_pm_opp_get_voltage(struct dev_pm_opp *opp)
{
return 0;
--
2.22.0.rc2.383.gf4fbbf30c2-goog
[PATCH v2 09/11] interconnect: Add OPP table support for interconnects
Interconnect paths can have different performance points. Now that OPP
framework supports bandwidth OPP tables, add OPP table support for
interconnects.
Devices can use the interconnect-opp-table DT property to specify OPP
tables for interconnect paths. And the driver can obtain the OPP table for
an interconnect path by calling icc_get_opp_table().
Signed-off-by: Saravana Kannan
---
drivers/interconnect/core.c | 27 ++-
include/linux/interconnect.h | 7 +++
2 files changed, 33 insertions(+), 1 deletion(-)
diff --git a/drivers/interconnect/core.c b/drivers/interconnect/core.c
index 871eb4bc4efc..881bac80bc1e 100644
--- a/drivers/interconnect/core.c
+++ b/drivers/interconnect/core.c
@@ -47,6 +47,7 @@ struct icc_req {
*/
struct icc_path {
size_t num_nodes;
+ struct opp_table *opp_table;
struct icc_req reqs[];
};
@@ -313,7 +314,7 @@ struct icc_path *of_icc_get(struct device *dev, const char
*name)
{
struct icc_path *path = ERR_PTR(-EPROBE_DEFER);
struct icc_node *src_node, *dst_node;
- struct device_node *np = NULL;
+ struct device_node *np = NULL, *opp_node;
struct of_phandle_args src_args, dst_args;
int idx = 0;
int ret;
@@ -381,10 +382,34 @@ struct icc_path *of_icc_get(struct device *dev, const
char *name)
dev_err(dev, "%s: invalid path=%ld\n", __func__, PTR_ERR(path));
mutex_unlock(&icc_lock);
+ opp_node = of_parse_phandle(np, "interconnect-opp-table", idx);
+ if (opp_node) {
+ path->opp_table = dev_pm_opp_of_find_table_from_node(opp_node);
+ of_node_put(opp_node);
+ }
+
+
return path;
}
EXPORT_SYMBOL_GPL(of_icc_get);
+/**
+ * icc_get_opp_table() - Get the OPP table that corresponds to a path
+ * @path: reference to the path returned by icc_get()
+ *
+ * This function will return the OPP table that corresponds to a path handle.
+ * If the interconnect API is disabled, NULL is returned and the consumer
+ * drivers will still build. Drivers are free to handle this specifically, but
+ * they don't have to.
+ *
+ * Return: opp_table pointer on success. NULL is returned when the API is
+ * disabled or the OPP table is missing.
+ */
+struct opp_table *icc_get_opp_table(struct icc_path *path)
+{
+ return path->opp_table;
+}
+
/**
* icc_set_bw() - set bandwidth constraints on an interconnect path
* @path: reference to the path returned by icc_get()
diff --git a/include/linux/interconnect.h b/include/linux/interconnect.h
index dc25864755ba..0c0bc55f0e89 100644
--- a/include/linux/interconnect.h
+++ b/include/linux/interconnect.h
@@ -9,6 +9,7 @@
#include
#include
+#include
/* macros for converting to icc units */
#define Bps_to_icc(x) ((x) / 1000)
@@ -28,6 +29,7 @@ struct device;
struct icc_path *icc_get(struct device *dev, const int src_id,
const int dst_id);
struct icc_path *of_icc_get(struct device *dev, const char *name);
+struct opp_table *icc_get_opp_table(struct icc_path *path);
void icc_put(struct icc_path *path);
int icc_set_bw(struct icc_path *path, u32 avg_bw, u32 peak_bw);
@@ -49,6 +51,11 @@ static inline void icc_put(struct icc_path *path)
{
}
+static inline struct opp_table *icc_get_opp_table(struct icc_path *path)
+{
+ return NULL;
+}
+
static inline int icc_set_bw(struct icc_path *path, u32 avg_bw, u32 peak_bw)
{
return 0;
--
2.22.0.rc2.383.gf4fbbf30c2-goog
[PATCH v2 07/11] OPP: Add API to find an OPP table from its DT node
This allows finding a device's OPP table (when it has multiple) from a
phandle to the OPP table in DT.
Signed-off-by: Saravana Kannan
---
drivers/opp/of.c | 42 ++
include/linux/pm_opp.h | 7 +++
2 files changed, 41 insertions(+), 8 deletions(-)
diff --git a/drivers/opp/of.c b/drivers/opp/of.c
index d5815289518a..e8697a4ca3bc 100644
--- a/drivers/opp/of.c
+++ b/drivers/opp/of.c
@@ -42,14 +42,9 @@ struct device_node *dev_pm_opp_of_get_opp_desc_node(struct
device *dev)
}
EXPORT_SYMBOL_GPL(dev_pm_opp_of_get_opp_desc_node);
-struct opp_table *_managed_opp(struct device *dev, int index)
+struct opp_table *_find_opp_table_from_node(struct device_node *np)
{
struct opp_table *opp_table, *managed_table = NULL;
- struct device_node *np;
-
- np = _opp_of_get_opp_desc_node(dev->of_node, index);
- if (!np)
- return NULL;
list_for_each_entry(opp_table, &opp_tables, node) {
if (opp_table->np == np) {
@@ -69,11 +64,42 @@ struct opp_table *_managed_opp(struct device *dev, int
index)
}
}
- of_node_put(np);
-
return managed_table;
}
+/**
+ * dev_pm_opp_of_find_table_from_node() - Find OPP table from its DT node
+ * @np: DT node used for finding the OPP table
+ *
+ * Return: OPP table corresponding to the DT node, else NULL on failure.
+ *
+ * The caller needs to put the node with of_node_put() after using it.
+ */
+struct opp_table *dev_pm_opp_of_find_table_from_node(struct device_node *np)
+{
+ struct opp_table *opp_table;
+
+ mutex_lock(&opp_table_lock);
+ opp_table = _find_opp_table_from_node(np);
+ mutex_unlock(&opp_table_lock);
+ return opp_table;
+}
+EXPORT_SYMBOL_GPL(dev_pm_opp_of_find_table_from_node);
+
+struct opp_table *_managed_opp(struct device *dev, int index)
+{
+ struct device_node *np;
+ struct opp_table *opp_table;
+
+ np = _opp_of_get_opp_desc_node(dev->of_node, index);
+ if (!np)
+ return NULL;
+
+ opp_table = _find_opp_table_from_node(np);
+ of_node_put(np);
+ return opp_table;
+}
+
/* The caller must call dev_pm_opp_put() after the OPP is used */
static struct dev_pm_opp *_find_opp_of_np(struct opp_table *opp_table,
struct device_node *opp_np)
diff --git a/include/linux/pm_opp.h b/include/linux/pm_opp.h
index 2e122af26b8e..d9156b62d966 100644
--- a/include/linux/pm_opp.h
+++ b/include/linux/pm_opp.h
@@ -370,6 +370,7 @@ int dev_pm_opp_of_cpumask_add_table(const struct cpumask
*cpumask);
void dev_pm_opp_of_cpumask_remove_table(const struct cpumask *cpumask);
int dev_pm_opp_of_get_sharing_cpus(struct device *cpu_dev, struct cpumask
*cpumask);
struct device_node *dev_pm_opp_of_get_opp_desc_node(struct device *dev);
+struct opp_table *dev_pm_opp_of_find_table_from_node(struct device_node *np);
struct device_node *dev_pm_opp_get_of_node(struct dev_pm_opp *opp);
int of_get_required_opp_performance_state(struct device_node *np, int index);
void dev_pm_opp_of_register_em(struct cpumask *cpus);
@@ -407,6 +408,12 @@ static inline struct device_node
*dev_pm_opp_of_get_opp_desc_node(struct device
return NULL;
}
+static inline struct opp_table *dev_pm_opp_of_find_table_from_node(
+ struct device_node *np)
+{
+ return NULL;
+}
+
static inline struct device_node *dev_pm_opp_get_of_node(struct dev_pm_opp
*opp)
{
return NULL;
--
2.22.0.rc2.383.gf4fbbf30c2-goog
[PATCH v2 06/11] OPP: Add helper function for bandwidth OPP tables
The frequency OPP tables have helper functions to search for entries in the
table based on frequency and get the frequency values for a given (or
suspend) OPP entry.
Add similar helper functions for bandwidth OPP tables to search for entries
in the table based on peak bandwidth and to get the peak and average
bandwidth for a given (or suspend) OPP entry.
Signed-off-by: Saravana Kannan
---
drivers/opp/core.c | 51 ++
include/linux/pm_opp.h | 19
2 files changed, 70 insertions(+)
diff --git a/drivers/opp/core.c b/drivers/opp/core.c
index 4f7870bffbf8..c9914afd508a 100644
--- a/drivers/opp/core.c
+++ b/drivers/opp/core.c
@@ -130,6 +130,29 @@ unsigned long dev_pm_opp_get_freq(struct dev_pm_opp *opp)
}
EXPORT_SYMBOL_GPL(dev_pm_opp_get_freq);
+/**
+ * dev_pm_opp_get_bw() - Gets the bandwidth corresponding to an available opp
+ * @opp: opp for which frequency has to be returned for
+ * @avg_bw:Pointer where the corresponding average bandwidth is stored.
+ * Can be NULL.
+ *
+ * Return: Peak bandwidth in KBps corresponding to the opp, else
+ * return 0
+ */
+unsigned long dev_pm_opp_get_bw(struct dev_pm_opp *opp, unsigned long *avg_bw)
+{
+ if (IS_ERR_OR_NULL(opp) || !opp->available) {
+ pr_err("%s: Invalid parameters\n", __func__);
+ return 0;
+ }
+
+ if (avg_bw)
+ *avg_bw = opp->avg_bw;
+
+ return opp->rate;
+}
+EXPORT_SYMBOL_GPL(dev_pm_opp_get_bw);
+
/**
* dev_pm_opp_get_level() - Gets the level corresponding to an available opp
* @opp: opp for which level value has to be returned for
@@ -302,6 +325,34 @@ unsigned long dev_pm_opp_get_suspend_opp_freq(struct
device *dev)
}
EXPORT_SYMBOL_GPL(dev_pm_opp_get_suspend_opp_freq);
+/**
+ * dev_pm_opp_get_suspend_opp_bw() - Get peak bandwidth of suspend opp in KBps
+ * @dev: device for which we do this operation
+ * @avg_bw:Pointer where the corresponding average bandwidth is stored.
+ * Can be NULL.
+ *
+ * Return: This function returns the peak bandwidth of the OPP marked as
+ * suspend_opp if one is available, else returns 0;
+ */
+unsigned long dev_pm_opp_get_suspend_opp_bw(struct device *dev,
+ unsigned long *avg_bw)
+{
+ struct opp_table *opp_table;
+ unsigned long peak_bw = 0;
+
+ opp_table = _find_opp_table(dev);
+ if (IS_ERR(opp_table))
+ return 0;
+
+ if (opp_table->suspend_opp && opp_table->suspend_opp->available)
+ peak_bw = dev_pm_opp_get_bw(opp_table->suspend_opp, avg_bw);
+
+ dev_pm_opp_put_opp_table(opp_table);
+
+ return peak_bw;
+}
+EXPORT_SYMBOL_GPL(dev_pm_opp_get_suspend_opp_bw);
+
int _get_opp_count(struct opp_table *opp_table)
{
struct dev_pm_opp *opp;
diff --git a/include/linux/pm_opp.h b/include/linux/pm_opp.h
index bc5c68bdfc8d..2e122af26b8e 100644
--- a/include/linux/pm_opp.h
+++ b/include/linux/pm_opp.h
@@ -85,6 +85,7 @@ void dev_pm_opp_put_opp_table(struct opp_table *opp_table);
unsigned long dev_pm_opp_get_voltage(struct dev_pm_opp *opp);
unsigned long dev_pm_opp_get_freq(struct dev_pm_opp *opp);
+unsigned long dev_pm_opp_get_bw(struct dev_pm_opp *opp, unsigned long *avg_bw);
unsigned int dev_pm_opp_get_level(struct dev_pm_opp *opp);
@@ -95,6 +96,8 @@ unsigned long dev_pm_opp_get_max_clock_latency(struct device
*dev);
unsigned long dev_pm_opp_get_max_volt_latency(struct device *dev);
unsigned long dev_pm_opp_get_max_transition_latency(struct device *dev);
unsigned long dev_pm_opp_get_suspend_opp_freq(struct device *dev);
+unsigned long dev_pm_opp_get_suspend_opp_bw(struct device *dev,
+ unsigned long *avg_bw);
struct dev_pm_opp *dev_pm_opp_find_freq_exact(struct device *dev,
unsigned long freq,
@@ -164,6 +167,11 @@ static inline unsigned long dev_pm_opp_get_freq(struct
dev_pm_opp *opp)
{
return 0;
}
+static inline unsigned long dev_pm_opp_get_bw(struct dev_pm_opp *opp,
+ unsigned long *avg_bw)
+{
+ return 0;
+}
static inline unsigned int dev_pm_opp_get_level(struct dev_pm_opp *opp)
{
@@ -200,6 +208,12 @@ static inline unsigned long
dev_pm_opp_get_suspend_opp_freq(struct device *dev)
return 0;
}
+static inline unsigned long dev_pm_opp_get_suspend_opp_bw(struct device *dev,
+ unsigned long *avg_bw)
+{
+ return 0;
+}
+
static inline struct dev_pm_opp *dev_pm_opp_find_freq_exact(struct device *dev,
unsigned long freq, bool available)
{
@@ -343,6 +357,11 @@ static inline void dev_pm_opp_cpumask_remove_table(const
struct cpumask *cpumask
#endif /* CONFIG_PM_OPP */
+#define dev_pm_opp_find_peak_bw_exact dev_pm_opp_find_freq_exact
+#define dev
[PATCH v2 02/11] OPP: Add function to look up required OPP's for a given OPP
Add a function that allows looking up required OPPs given a source OPP
table, destination OPP table and the source OPP.
Signed-off-by: Saravana Kannan
---
drivers/opp/core.c | 54 ++
include/linux/pm_opp.h | 11 +
2 files changed, 65 insertions(+)
diff --git a/drivers/opp/core.c b/drivers/opp/core.c
index 74c7bdc6f463..4f7870bffbf8 100644
--- a/drivers/opp/core.c
+++ b/drivers/opp/core.c
@@ -1830,6 +1830,60 @@ void dev_pm_opp_put_genpd_virt_dev(struct opp_table
*opp_table,
dev_err(virt_dev, "Failed to find required device entry\n");
}
+/**
+ * dev_pm_opp_xlate_opp() - Find required OPP for src_table OPP.
+ * @src_table: OPP table which has dst_table as one of its required OPP table.
+ * @dst_table: Required OPP table of the src_table.
+ * @pstate: OPP of the src_table.
+ *
+ * This function returns the OPP (present in @dst_table) pointed out by the
+ * "required-opps" property of the OPP (present in @src_table).
+ *
+ * The callers are required to call dev_pm_opp_put() for the returned OPP after
+ * use.
+ *
+ * Return: destination table OPP on success, otherwise NULL on errors.
+ */
+struct dev_pm_opp *dev_pm_opp_xlate_opp(struct opp_table *src_table,
+ struct opp_table *dst_table,
+ struct dev_pm_opp *src_opp)
+{
+ struct dev_pm_opp *opp, *dest_opp = NULL;
+ int i;
+
+ if (!src_table || !dst_table || !src_opp)
+ return NULL;
+
+ for (i = 0; i < src_table->required_opp_count; i++) {
+ if (src_table->required_opp_tables[i]->np == dst_table->np)
+ break;
+ }
+
+ if (unlikely(i == src_table->required_opp_count)) {
+ pr_err("%s: Couldn't find matching OPP table (%p: %p)\n",
+ __func__, src_table, dst_table);
+ return NULL;
+ }
+
+ mutex_lock(&src_table->lock);
+
+ list_for_each_entry(opp, &src_table->opp_list, node) {
+ if (opp == src_opp) {
+ dest_opp = opp->required_opps[i];
+ dev_pm_opp_get(dest_opp);
+ goto unlock;
+ }
+ }
+
+ pr_err("%s: Couldn't find matching OPP (%p: %p)\n", __func__, src_table,
+ dst_table);
+
+unlock:
+ mutex_unlock(&src_table->lock);
+
+ return dest_opp;
+}
+
/**
* dev_pm_opp_xlate_performance_state() - Find required OPP's pstate for
src_table.
* @src_table: OPP table which has dst_table as one of its required OPP table.
diff --git a/include/linux/pm_opp.h b/include/linux/pm_opp.h
index b150fe97ce5a..bc5c68bdfc8d 100644
--- a/include/linux/pm_opp.h
+++ b/include/linux/pm_opp.h
@@ -134,6 +134,9 @@ void dev_pm_opp_unregister_set_opp_helper(struct opp_table
*opp_table);
struct opp_table *dev_pm_opp_set_genpd_virt_dev(struct device *dev, struct
device *virt_dev, int index);
void dev_pm_opp_put_genpd_virt_dev(struct opp_table *opp_table, struct device
*virt_dev);
int dev_pm_opp_xlate_performance_state(struct opp_table *src_table, struct
opp_table *dst_table, unsigned int pstate);
+struct dev_pm_opp *dev_pm_opp_xlate_opp(struct opp_table *src_table,
+ struct opp_table *dst_table,
+ struct dev_pm_opp *src_opp);
int dev_pm_opp_set_rate(struct device *dev, unsigned long target_freq);
int dev_pm_opp_set_sharing_cpus(struct device *cpu_dev, const struct cpumask
*cpumask);
int dev_pm_opp_get_sharing_cpus(struct device *cpu_dev, struct cpumask
*cpumask);
@@ -307,6 +310,14 @@ static inline int
dev_pm_opp_xlate_performance_state(struct opp_table *src_table
return -ENOTSUPP;
}
+static inline struct dev_pm_opp *dev_pm_opp_xlate_opp(
+ struct opp_table *src_table,
+ struct opp_table *dst_table,
+ struct dev_pm_opp *src_opp)
+{
+ return NULL;
+}
+
static inline int dev_pm_opp_set_rate(struct device *dev, unsigned long
target_freq)
{
return -ENOTSUPP;
--
2.22.0.rc2.383.gf4fbbf30c2-goog
[PATCH v2 00/11] Introduce Bandwidth OPPs & interconnect devfreq driver
I replied[1] to this patch series[2] and described how I think interconnect
bandwidth voting should be captured in DT and how it should work.
So sending out a patch series implementing that. This patch series does the
following:
- Allow required-opps to point to any device's OPP
- Add support to devfreq passive governor to look at the "parent"
devfreq's required-opps to decide the "slave" device's frequency
- Adds Bandwidth OPP table support
- Adds a devfreq library for interconnect paths
Interconnects and interconnect paths quantify they performance levels in
terms of bandwidth. So similar to how we have frequency based OPP tables
in DT and in the OPP framework, this patch series adds bandwidth OPP
table support in the OPP framework and in DT.
To simplify voting for interconnects, this patch series adds helper
functions to create devfreq devices out of interconnect paths. This
allows drivers to add a single line of code to add interconnect voting
capability.
To add devfreq device for the "gpu-mem" interconnect path and use
required OPPs to do decide gpu-mem bandwidth:
icc_create_devfreq(dev, "gpu-mem", gpu_devfreq);
To add devfreq device for the "gpu-mem" interconnect path and use some
other governor to device gpu-mem bandwidth:
icc_create_devfreq(dev, "gpu-mem", NULL);
So with the DT bindings added in this patch series, the DT for a GPU
that does bandwidth voting from GPU to Cache and GPU to DDR would look
something like this:
gpu_cache_opp_table: gpu_cache_opp_table {
compatible = "operating-points-v2";
gpu_cache_3000: opp-3000 {
opp-peak-KBps = <3000>;
opp-avg-KBps = <1000>;
};
gpu_cache_6000: opp-6000 {
opp-peak-KBps = <6000>;
opp-avg-KBps = <2000>;
};
gpu_cache_9000: opp-9000 {
opp-peak-KBps = <9000>;
opp-avg-KBps = <9000>;
};
};
gpu_ddr_opp_table: gpu_ddr_opp_table {
compatible = "operating-points-v2";
gpu_ddr_1525: opp-1525 {
opp-peak-KBps = <1525>;
opp-avg-KBps = <452>;
};
gpu_ddr_3051: opp-3051 {
opp-peak-KBps = <3051>;
opp-avg-KBps = <915>;
};
gpu_ddr_7500: opp-7500 {
opp-peak-KBps = <7500>;
opp-avg-KBps = <3000>;
};
};
gpu_opp_table: gpu_opp_table {
compatible = "operating-points-v2";
opp-shared;
opp-2 {
opp-hz = /bits/ 64 <2>;
required-opps = <&gpu_cache_3000>, <&gpu_ddr_1525>;
};
opp-4 {
opp-hz = /bits/ 64 <4>;
required-opps = <&gpu_cache_6000>, <&gpu_ddr_3051>;
};
};
gpu@7864000 {
...
operating-points-v2 = <&gpu_opp_table>, <&gpu_cache_opp_table>,
<&gpu_ddr_opp_table>;
interconnects = <&mmnoc MASTER_GPU_1 &bimc SLAVE_SYSTEL_CACHE>,
<&mmnoc MASTER_GPU_1 &bimc SLAVE_DDR>;
interconnect-names = "gpu-cache", "gpu-mem";
interconnect-opp-table = <&gpu_cache_opp_table>, <&gpu_ddr_opp_table>
};
Cheers,
Saravana
[1] - https://lore.kernel.org/lkml/20190601021228.210574-1-sarava...@google.com/
[2] -
https://lore.kernel.org/lkml/20190423132823.7915-1-georgi.dja...@linaro.org/
Saravana Kannan (11):
OPP: Allow required-opps even if the device doesn't have power-domains
OPP: Add function to look up required OPP's for a given OPP
PM / devfreq: Add required OPPs support to passive governor
dt-bindings: opp: Introduce opp-peak-KBps and opp-avg-KBps bindings
OPP: Add support for bandwidth OPP tables
OPP: Add helper function for bandwidth OPP tables
OPP: Add API to find an OPP table from its DT node
dt-bindings: interconnect: Add interconnect-opp-table property
interconnect: Add OPP table support for interconnects
OPP: Allow copying OPPs tables between devices
interconnect: Add devfreq support
.../bindings/interconnect/interconnect.txt| 8 +
Documentation/devicetree/bindings/opp/opp.txt | 15 +-
drivers/devfreq/governor_passive.c| 25 ++-
drivers/interconnect/Makefile | 2 +-
drivers/interconnect/core.c | 27 ++-
drivers/interconnect/icc-devfreq.c| 156 ++
drivers/opp/core.c| 115 -
drivers/opp/of.c | 90 +++---
drivers/opp/opp.h | 4 +-
include/linux/interconnect.h | 21 +++
include/linux/pm_opp.h| 44 +
11 files changed, 474 insertions(+), 33 deletions(-)
create mode 100644 drivers/interconnect/icc-devfreq.c
--
2.22.0.rc2.383.gf4fbbf30c2-goog
[PATCH v2 05/11] OPP: Add support for bandwidth OPP tables
Not all devices quantify their performance points in terms of frequency.
Devices like interconnects quantify their performance points in terms of
bandwidth. We need a way to represent these bandwidth levels in OPP. So,
add support for parsing bandwidth OPPs from DT.
Signed-off-by: Saravana Kannan
---
drivers/opp/of.c | 34 --
drivers/opp/opp.h | 4 +++-
2 files changed, 35 insertions(+), 3 deletions(-)
diff --git a/drivers/opp/of.c b/drivers/opp/of.c
index 7c8336e94aff..d5815289518a 100644
--- a/drivers/opp/of.c
+++ b/drivers/opp/of.c
@@ -538,6 +538,35 @@ void dev_pm_opp_of_remove_table(struct device *dev)
}
EXPORT_SYMBOL_GPL(dev_pm_opp_of_remove_table);
+static int _read_opp_key(struct dev_pm_opp *new_opp, struct device_node *np)
+{
+ int ret;
+ u64 rate;
+ u32 bw;
+
+ ret = of_property_read_u64(np, "opp-hz", &rate);
+ if (!ret) {
+ /*
+* Rate is defined as an unsigned long in clk API, and so
+* casting explicitly to its type. Must be fixed once rate is 64
+* bit guaranteed in clk API.
+*/
+ new_opp->rate = (unsigned long)rate;
+ return 0;
+ }
+
+ ret = of_property_read_u32(np, "opp-peak-KBps", &bw);
+ if (ret)
+ return ret;
+ new_opp->rate = (unsigned long) &bw;
+
+ ret = of_property_read_u32(np, "opp-avg-KBps", &bw);
+ if (!ret)
+ new_opp->avg_bw = (unsigned long) &bw;
+
+ return 0;
+}
+
/**
* _opp_add_static_v2() - Allocate static OPPs (As per 'v2' DT bindings)
* @opp_table: OPP table
@@ -575,11 +604,12 @@ static struct dev_pm_opp *_opp_add_static_v2(struct
opp_table *opp_table,
if (!new_opp)
return ERR_PTR(-ENOMEM);
- ret = of_property_read_u64(np, "opp-hz", &rate);
+ ret = _read_opp_key(new_opp, np);
if (ret < 0) {
/* "opp-hz" is optional for devices like power domains. */
if (!opp_table->is_genpd) {
- dev_err(dev, "%s: opp-hz not found\n", __func__);
+ dev_err(dev, "%s: opp-hz or opp-peak-bw not found\n",
+ __func__);
goto free_opp;
}
diff --git a/drivers/opp/opp.h b/drivers/opp/opp.h
index 569b3525aa67..ead2cdafe957 100644
--- a/drivers/opp/opp.h
+++ b/drivers/opp/opp.h
@@ -59,7 +59,8 @@ extern struct list_head opp_tables;
* @turbo: true if turbo (boost) OPP
* @suspend: true if suspend OPP
* @pstate: Device's power domain's performance state.
- * @rate: Frequency in hertz
+ * @rate: Frequency in hertz OR Peak bandwidth in kilobytes per second
+ * @avg_bw:Average bandwidth in kilobytes per second
* @level: Performance level
* @supplies: Power supplies voltage/current values
* @clock_latency_ns: Latency (in nanoseconds) of switching to this OPP's
@@ -81,6 +82,7 @@ struct dev_pm_opp {
bool suspend;
unsigned int pstate;
unsigned long rate;
+ unsigned long avg_bw;
unsigned int level;
struct dev_pm_opp_supply *supplies;
--
2.22.0.rc2.383.gf4fbbf30c2-goog
[PATCH v2 04/11] dt-bindings: opp: Introduce opp-peak-KBps and opp-avg-KBps bindings
Interconnects often quantify their performance points in terms of bandwidth. So, add opp-peak-KBps (required) and opp-avg-KBps (optional) to allow specifying Bandwidth OPP tables in DT. opp-peak-KBps is a required property that replace opp-hz for Bandwidth OPP tables. opp-avg-KBps is an optional property that can be used in Bandwidth OPP tables. Signed-off-by: Saravana Kannan --- Documentation/devicetree/bindings/opp/opp.txt | 15 --- 1 file changed, 12 insertions(+), 3 deletions(-) diff --git a/Documentation/devicetree/bindings/opp/opp.txt b/Documentation/devicetree/bindings/opp/opp.txt index 76b6c79604a5..c869e87caa2a 100644 --- a/Documentation/devicetree/bindings/opp/opp.txt +++ b/Documentation/devicetree/bindings/opp/opp.txt @@ -83,9 +83,14 @@ properties. Required properties: - opp-hz: Frequency in Hz, expressed as a 64-bit big-endian integer. This is a - required property for all device nodes but devices like power domains. The - power domain nodes must have another (implementation dependent) property which - uniquely identifies the OPP nodes. + required property for all device nodes but for devices like power domains or + bandwidth opp tables. The power domain nodes must have another (implementation + dependent) property which uniquely identifies the OPP nodes. The interconnect + opps are required to have the opp-peak-bw property. + +- opp-peak-KBps: Peak bandwidth in kilobytes per second, expressed as a 32-bit + big-endian integer. This is a required property for all devices that don't + have opp-hz. For example, bandwidth OPP tables for interconnect paths. Optional properties: - opp-microvolt: voltage in micro Volts. @@ -132,6 +137,10 @@ Optional properties: - opp-level: A value representing the performance level of the device, expressed as a 32-bit integer. +- opp-avg-KBps: Average bandwidth in kilobytes per second, expressed as a + 32-bit big-endian integer. This property is only meaningful in OPP tables + where opp-peak-KBps is present. + - clock-latency-ns: Specifies the maximum possible transition latency (in nanoseconds) for switching to this OPP from any other OPP. -- 2.22.0.rc2.383.gf4fbbf30c2-goog
[PATCH v2 03/11] PM / devfreq: Add required OPPs support to passive governor
Look at the required OPPs of the "parent" device to determine the OPP that
is required from the slave device managed by the passive governor. This
allows having mappings between a parent device and a slave device even when
they don't have the same number of OPPs.
Signed-off-by: Saravana Kannan
---
drivers/devfreq/governor_passive.c | 25 +++--
1 file changed, 23 insertions(+), 2 deletions(-)
diff --git a/drivers/devfreq/governor_passive.c
b/drivers/devfreq/governor_passive.c
index 3bc29acbd54e..bd4a98bb15b1 100644
--- a/drivers/devfreq/governor_passive.c
+++ b/drivers/devfreq/governor_passive.c
@@ -21,8 +21,9 @@ static int devfreq_passive_get_target_freq(struct devfreq
*devfreq,
struct devfreq_passive_data *p_data
= (struct devfreq_passive_data *)devfreq->data;
struct devfreq *parent_devfreq = (struct devfreq *)p_data->parent;
+ struct opp_table *opp_table = NULL, *c_opp_table = NULL;
unsigned long child_freq = ULONG_MAX;
- struct dev_pm_opp *opp;
+ struct dev_pm_opp *opp = NULL, *c_opp = NULL;
int i, count, ret = 0;
/*
@@ -65,7 +66,20 @@ static int devfreq_passive_get_target_freq(struct devfreq
*devfreq,
goto out;
}
- dev_pm_opp_put(opp);
+ opp_table = dev_pm_opp_get_opp_table(parent_devfreq->dev.parent);
+ if (IS_ERR_OR_NULL(opp_table)) {
+ ret = PTR_ERR(opp_table);
+ goto out;
+ }
+
+ c_opp_table = dev_pm_opp_get_opp_table(devfreq->dev.parent);
+ if (!IS_ERR_OR_NULL(c_opp_table))
+ c_opp = dev_pm_opp_xlate_opp(opp_table, c_opp_table, opp);
+ if (c_opp) {
+ *freq = dev_pm_opp_get_freq(c_opp);
+ dev_pm_opp_put(c_opp);
+ goto out;
+ }
/*
* Get the OPP table's index of decided freqeuncy by governor
@@ -92,6 +106,13 @@ static int devfreq_passive_get_target_freq(struct devfreq
*devfreq,
*freq = child_freq;
out:
+ if (!IS_ERR_OR_NULL(opp_table))
+ dev_pm_opp_put_opp_table(opp_table);
+ if (!IS_ERR_OR_NULL(c_opp_table))
+ dev_pm_opp_put_opp_table(c_opp_table);
+ if (!IS_ERR_OR_NULL(opp))
+ dev_pm_opp_put(opp);
+
return ret;
}
--
2.22.0.rc2.383.gf4fbbf30c2-goog
[PATCH v2 11/11] interconnect: Add devfreq support
Add a icc_create_devfreq() and icc_remove_devfreq() to create and remove
devfreq devices for interconnect paths. A driver can create/remove devfreq
devices for the interconnects needed for its device by calling these APIs.
This would allow various devfreq governors to work with interconnect paths
and the device driver itself doesn't have to actively manage the bandwidth
votes for the interconnects.
Signed-off-by: Saravana Kannan
---
drivers/interconnect/Makefile | 2 +-
drivers/interconnect/icc-devfreq.c | 156 +
include/linux/interconnect.h | 14 +++
3 files changed, 171 insertions(+), 1 deletion(-)
create mode 100644 drivers/interconnect/icc-devfreq.c
diff --git a/drivers/interconnect/Makefile b/drivers/interconnect/Makefile
index 28f2ab0824d5..ddfb65b7fa55 100644
--- a/drivers/interconnect/Makefile
+++ b/drivers/interconnect/Makefile
@@ -1,6 +1,6 @@
# SPDX-License-Identifier: GPL-2.0
-icc-core-objs := core.o
+icc-core-objs := core.o icc-devfreq.o
obj-$(CONFIG_INTERCONNECT) += icc-core.o
obj-$(CONFIG_INTERCONNECT_QCOM)+= qcom/
diff --git a/drivers/interconnect/icc-devfreq.c
b/drivers/interconnect/icc-devfreq.c
new file mode 100644
index ..608716fbe612
--- /dev/null
+++ b/drivers/interconnect/icc-devfreq.c
@@ -0,0 +1,156 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * A devfreq device driver for interconnect paths
+ *
+ * Copyright (C) 2019 Google, Inc
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+struct icc_devfreq {
+ struct device icc_dev;
+ struct icc_path *path;
+ struct devfreq_dev_profile dp;
+ struct devfreq *df;
+ unsigned long peak_bw;
+ unsigned long avg_bw;
+#if IS_ENABLED(CONFIG_DEVFREQ_GOV_PASSIVE)
+ struct devfreq_passive_data p_data;
+#endif
+};
+
+static int icc_target(struct device *dev, unsigned long *freq,
+ u32 flags)
+{
+ struct icc_devfreq *d = dev_get_drvdata(dev);
+ struct dev_pm_opp *opp;
+ unsigned long peak_bw, avg_bw;
+
+ opp = devfreq_recommended_opp(dev, &peak_bw, flags);
+ if (IS_ERR(opp)) {
+ dev_err(dev, "Failed to find opp for %lu KHz\n", *freq);
+ return PTR_ERR(opp);
+ }
+ peak_bw = dev_pm_opp_get_bw(opp, &avg_bw);
+ dev_pm_opp_put(opp);
+
+ if (!icc_set_bw(d->path, avg_bw, peak_bw)) {
+ *freq = peak_bw;
+ d->peak_bw = peak_bw;
+ d->avg_bw = avg_bw;
+ }
+
+ return 0;
+}
+
+static int icc_get_dev_status(struct device *dev,
+ struct devfreq_dev_status *stat)
+{
+ struct icc_devfreq *d = dev_get_drvdata(dev);
+
+ stat->current_frequency = d->peak_bw;
+ return 0;
+}
+
+#define icc_dev_to_data(DEV) container_of((DEV), struct icc_devfreq, icc_dev)
+static void icc_dev_release(struct device *dev)
+{
+ struct icc_devfreq *d = icc_dev_to_data(dev);
+
+ kfree(d);
+}
+
+struct icc_devfreq *icc_create_devfreq(struct device *dev, char *name,
+ struct devfreq *devf)
+{
+ struct icc_devfreq *d;
+ struct icc_path *path;
+ struct opp_table *opp_table;
+ struct dev_pm_opp *opp;
+ void *p_data = NULL;
+ unsigned long peak_bw = U32_MAX, avg_bw = U32_MAX;
+ int err;
+
+ if (!name)
+ return ERR_PTR(-EINVAL);
+
+ path = of_icc_get(dev, name);
+ if (IS_ERR(path))
+ return (void *) path;
+
+ opp_table = icc_get_opp_table(path);
+ if (!opp_table) {
+ err = -EINVAL;
+ goto out_path;
+ }
+
+ d = kzalloc(sizeof(*d), GFP_KERNEL);
+ if (!d) {
+ err = -ENOMEM;
+ goto out_path;
+ }
+ d->path = path;
+
+ d->icc_dev.parent = dev;
+ d->icc_dev.release = icc_dev_release;
+ dev_set_name(&d->icc_dev, "%s-icc-%s", dev_name(dev), name);
+ err = device_register(&d->icc_dev);
+ if (err) {
+ put_device(&d->icc_dev);
+ goto out_path;
+ }
+
+ dev_pm_opp_add_opp_table(&d->icc_dev, opp_table);
+ opp = dev_pm_opp_find_peak_bw_floor(dev, &peak_bw);
+ peak_bw = dev_pm_opp_get_bw(opp, &avg_bw);
+ dev_pm_opp_put(opp);
+
+ if (!icc_set_bw(d->path, avg_bw, peak_bw)) {
+ d->peak_bw = peak_bw;
+ d->avg_bw = avg_bw;
+ }
+
+#if !IS_ENABLED(CONFIG_DEVFREQ_GOV_PASSIVE)
+ if (devf) {
+ d->p_data.parent = devf;
+ pdata = &d->p_data;
+ }
+#endif
+ d->dp.initial_freq = peak_bw;
+ d->dp.polling_ms = 0;
+ d->dp.target = icc_target;
+ d->dp.get_dev_status = icc_get_dev_status;
+ d->df = devm_devfreq_add_device(&d->icc_dev,
+
[PATCH v2 08/11] dt-bindings: interconnect: Add interconnect-opp-table property
Add support for listing bandwidth OPP tables for each interconnect path
listed using the interconnects property.
Signed-off-by: Saravana Kannan
---
.../devicetree/bindings/interconnect/interconnect.txt | 8
1 file changed, 8 insertions(+)
diff --git a/Documentation/devicetree/bindings/interconnect/interconnect.txt
b/Documentation/devicetree/bindings/interconnect/interconnect.txt
index 6f5d23a605b7..fc5b75b76a2c 100644
--- a/Documentation/devicetree/bindings/interconnect/interconnect.txt
+++ b/Documentation/devicetree/bindings/interconnect/interconnect.txt
@@ -55,10 +55,18 @@ interconnect-names : List of interconnect path name strings
sorted in the same
* dma-mem: Path from the device to the main memory of
the system
+interconnect-opp-table: List of phandles to OPP tables (bandwidth OPP tables)
+ that specify the OPPs for the interconnect paths listed
+ in the interconnects property. This property can only
+ point to OPP tables that belong to the device and are
+ listed in the device's operating-points-v2 property.
+
Example:
sdhci@7864000 {
+ operating-points-v2 = <&sdhc_opp_table>, <&sdhc_mem_opp_table>;
...
interconnects = <&pnoc MASTER_SDCC_1 &bimc SLAVE_EBI_CH0>;
interconnect-names = "sdhc-mem";
+ interconnect-opp-table = <&sdhc_mem_opp_table>;
};
--
2.22.0.rc2.383.gf4fbbf30c2-goog
[PATCH v2 01/11] OPP: Allow required-opps even if the device doesn't have power-domains
A Device-A can have a (minimum) performance requirement on another
Device-B to be able to function correctly. This performance requirement
on Device-B can also change based on the current performance level of
Device-A.
The existing required-opps feature fits well to describe this need. So,
instead of limiting required-opps to point to only PM-domain devices,
allow it to point to any device.
Signed-off-by: Saravana Kannan
---
drivers/opp/core.c | 2 +-
drivers/opp/of.c | 14 --
2 files changed, 1 insertion(+), 15 deletions(-)
diff --git a/drivers/opp/core.c b/drivers/opp/core.c
index 0e7703fe733f..74c7bdc6f463 100644
--- a/drivers/opp/core.c
+++ b/drivers/opp/core.c
@@ -710,7 +710,7 @@ static int _set_required_opps(struct device *dev,
return 0;
/* Single genpd case */
- if (!genpd_virt_devs) {
+ if (!genpd_virt_devs && required_opp_tables[0]->is_genpd) {
pstate = opp->required_opps[0]->pstate;
ret = dev_pm_genpd_set_performance_state(dev, pstate);
if (ret) {
diff --git a/drivers/opp/of.c b/drivers/opp/of.c
index c10c782d15aa..7c8336e94aff 100644
--- a/drivers/opp/of.c
+++ b/drivers/opp/of.c
@@ -195,9 +195,6 @@ static void _opp_table_alloc_required_tables(struct
opp_table *opp_table,
*/
count_pd = of_count_phandle_with_args(dev->of_node, "power-domains",
"#power-domain-cells");
- if (!count_pd)
- goto put_np;
-
if (count_pd > 1) {
genpd_virt_devs = kcalloc(count, sizeof(*genpd_virt_devs),
GFP_KERNEL);
@@ -226,17 +223,6 @@ static void _opp_table_alloc_required_tables(struct
opp_table *opp_table,
if (IS_ERR(required_opp_tables[i]))
goto free_required_tables;
-
- /*
-* We only support genpd's OPPs in the "required-opps" for now,
-* as we don't know how much about other cases. Error out if the
-* required OPP doesn't belong to a genpd.
-*/
- if (!required_opp_tables[i]->is_genpd) {
- dev_err(dev, "required-opp doesn't belong to genpd:
%pOF\n",
- required_np);
- goto free_required_tables;
- }
}
goto put_np;
--
2.22.0.rc2.383.gf4fbbf30c2-goog
Re: [PATCH 1/1] PCI/IOV: Fix VF0 cached config space size for other VFs
Alex Williamson 于2019年6月5日周三 上午1:29写道： > > On Mon, 20 May 2019 21:17:24 +0800 > Hao Zheng wrote: > > > Set the pcie_cap field before getting the config space size for > > other VFs. Otherwise, the config space size of other VFs are error > > set to 256, while the size of VF0 is 4096. > > > > Signed-off-by: Hao Zheng > > Signed-off-by: Quan Xu > > --- > > drivers/pci/iov.c | 1 + > > 1 file changed, 1 insertion(+) > > > > diff --git a/drivers/pci/iov.c b/drivers/pci/iov.c > > index 3aa115e..239fad1 100644 > > --- a/drivers/pci/iov.c > > +++ b/drivers/pci/iov.c > > @@ -133,6 +133,7 @@ static void pci_read_vf_config_common(struct pci_dev > > *virtfn) > > pci_read_config_word(virtfn, PCI_SUBSYSTEM_ID, > >&physfn->sriov->subsystem_device); > > > > + set_pcie_port_type(virtfn); > > physfn->sriov->cfg_size = pci_cfg_space_size(virtfn); > > } > > > > This results in set_pci_port_type() being called multiple times on > VF0. Why not simply delay calling pci_read_vf_config_common() until > after pci_setup_device()? Here's the alternate approach: > > https://lore.kernel.org/linux-pci/155966918965.10361.16228304474160813310.st...@gimli.home/ I get it. This is a better approach. Thank you for your advice! > > Thanks, > Alex -- Best Regards!
Re: [PATCH] mfd: stmfx: Fix macro definition spelling
On Tue, May 14, 2019 at 07:54:04PM +0100, Lee Jones wrote:
> On Tue, 14 May 2019, Nathan Chancellor wrote:
>
> > On Mon, May 13, 2019 at 08:30:59AM +0100, Lee Jones wrote:
> > > On Fri, 10 May 2019, Nathan Chancellor wrote:
> > >
> > > > Clang warns:
> > > >
> > > > In file included from drivers/mfd/stmfx.c:13:
> > > > include/linux/mfd/stmfx.h:7:9: warning: 'MFD_STMFX_H' is used as a
> > > > header guard here, followed by #define of a different macro
> > > > [-Wheader-guard]
> > > >
> > > > Fixes: 06252ade9156 ("mfd: Add ST Multi-Function eXpander (STMFX) core
> > > > driver")
> > > > Link: https://github.com/ClangBuiltLinux/linux/issues/475
> > > > Signed-off-by: Nathan Chancellor
> > > > ---
> > > > include/linux/mfd/stmfx.h | 2 +-
> > > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > Applied, thanks.
> > >
> >
> > Hi Lee,
> >
> > Thanks for picking it up. It seems this didn't make it into your MFD
> > pull request for 5.2, was that intentional? It would be nice to avoid
> > this warning.
>
> Hmm... no it was not intentional. Not sure what happened there.
>
> I will pick it up for the -rcs.
Hi Lee,
Have you picked this up yet? I don't see it in -next or your public
tree.
Cheers,
Nathan
Re: [PATCH RFC 00/10] RDMA/FS DAX truncate proposal
On Thu, Jun 13, 2019 at 01:34:06PM -0700, Ira Weiny wrote:
> On Thu, Jun 13, 2019 at 10:55:52AM +1000, Dave Chinner wrote:
> > On Wed, Jun 12, 2019 at 04:30:24PM -0700, Ira Weiny wrote:
> > > On Wed, Jun 12, 2019 at 05:37:53AM -0700, Matthew Wilcox wrote:
> > > > On Sat, Jun 08, 2019 at 10:10:36AM +1000, Dave Chinner wrote:
> > > > > On Fri, Jun 07, 2019 at 11:25:35AM -0700, Ira Weiny wrote:
> > > > > > Are you suggesting that we have something like this from user space?
> > > > > >
> > > > > > fcntl(fd, F_SETLEASE, F_LAYOUT | F_UNBREAKABLE);
> > > > >
> > > > > Rather than "unbreakable", perhaps a clearer description of the
> > > > > policy it entails is "exclusive"?
> > > > >
> > > > > i.e. what we are talking about here is an exclusive lease that
> > > > > prevents other processes from changing the layout. i.e. the
> > > > > mechanism used to guarantee a lease is exclusive is that the layout
> > > > > becomes "unbreakable" at the filesystem level, but the policy we are
> > > > > actually presenting to uses is "exclusive access"...
> > > >
> > > > That's rather different from the normal meaning of 'exclusive' in the
> > > > context of locks, which is "only one user can have access to this at
> > > > a time". As I understand it, this is rather more like a 'shared' or
> > > > 'read' lock. The filesystem would be the one which wants an exclusive
> > > > lock, so it can modify the mapping of logical to physical blocks.
> > > >
> > > > The complication being that by default the filesystem has an exclusive
> > > > lock on the mapping, and what we're trying to add is the ability for
> > > > readers to ask the filesystem to give up its exclusive lock.
> > >
> > > This is an interesting view...
> > >
> > > And after some more thought, exclusive does not seem like a good name for
> > > this
> > > because technically F_WRLCK _is_ an exclusive lease...
> > >
> > > In addition, the user does not need to take the "exclusive" write lease
> > > to be
> > > notified of (broken by) an unexpected truncate. A "read" lease is broken
> > > by
> > > truncate. (And "write" leases really don't do anything different WRT the
> > > interaction of the FS and the user app. Write leases control "exclusive"
> > > access between other file descriptors.)
> >
> > I've been assuming that there is only one type of layout lease -
> > there is no use case I've heard of for read/write layout leases, and
> > like you say there is zero difference in behaviour at the filesystem
> > level - they all have to be broken to allow a non-lease truncate to
> > proceed.
> >
> > IMO, taking a "read lease" to be able to modify and write to the
> > underlying mapping of a file makes absolutely no sense at all.
> > IOWs, we're talking exaclty about a revokable layout lease vs an
> > exclusive layout lease here, and so read/write really doesn't match
> > the policy or semantics we are trying to provide.
>
> I humbly disagree, at least depending on how you look at it... :-D
>
> The patches as they stand expect the user to take a "read" layout lease which
> indicates they are currently using "reading" the layout as is.
> They are not
> changing ("writing" to) the layout.
As I said in a another email in the thread, a layout lease does not
make the layout "read only". It just means the lease owner will be
notified when someone else is about to modify it. The lease owner
can modify the mapping themselves, and they will not get notified
about their own modifications.
> They then pin pages which locks parts of
> the layout and therefore they expect no "writers" to change the layout.
Except they can change the layout themselves. It's perfectly valid
to get a layout lease, write() from offset 0 to EOF and fsync() to
intiialise the file and allocate all the space in the file, then
mmap() it and hand to off to RMDA, all while holding the layout
lease.
> The "write" layout lease breaks the "read" layout lease indicating that the
> layout is being written to.
Layout leases do not work this way.
> In fact, this is what NFS does right now. The lease it puts on the file is of
> "read" type.
>
> nfs4layouts.c:
> static int
> nfsd4_layout_setlease(struct nfs4_layout_stateid *ls)
> {
> ...
> fl->fl_flags = FL_LAYOUT;
> fl->fl_type = F_RDLCK;
> ...
> }
Yes, the existing /implementation/ uses F_RDLCK, but that doesn't
mean the layout is "read only". Look at the pNFS mapping layout code
- the ->map_blocks export operation:
int (*map_blocks)(struct inode *inode, loff_t offset,
u64 len, struct iomap *iomap,
bool write, u32 *device_generation);
^^
Yup, it has a write variable that, when set, causes the filesystem
to _allocate_ blocks if the range to be written to falls over a hole
in the file. IOWs, a pNFS layout lease can modify the file layout -
you're conflating use of a "read lock" API to mean that what the
lease _manages_ is "read only"
Re: [RFC PATCH 0/1] security: add SECURE_KEEP_FSUID to preserve fsuid/fsgid across execve
[Adding David and Al] On Thu, 13 Jun 2019, Igor Lubashev wrote: > I've posted this in March but received no response. Reposting. > > This patch introduces SECURE_KEEP_FSUID to allow fsuid/fsgid to be > preserved across execve. It is currently impossible to execve a > program such that effective and filesystem uid differ. > > The need for this functionality arose from a desire to allow certain > non-privileged users to run perf. To do this, we install perf without > set-uid-root and have a set-uid-root wrapper decide who is allowed to > run perf (and with what arguments). > > The wrapper must execve perf with real and effective root uid, because > perf and KASLR require this. However, that presently resets fsuid to > root, giving the user ability to read and overwrite any file owned by > root (perf report -i, perf record -o). Also, perf record will create > perf.data that cannot be deleted by the user. > > We cannot reset /proc/sys/kernel/perf_event_paranoid to a permissive > level, since we must be selective which users have the permissions. > > Of course, we could fix our problem by a patch to perf to allow > passing a username on the command line and having perf execute > setfsuid before opening files. However, perf is not the only program > that uses kernel features that require root uid/euid, so a general > solution that does not involve updating all such programs seems > warranted. > > I will update man pages, if this patch is deemed a good idea. > > Igor Lubashev (1): > security: add SECURE_KEEP_FSUID to preserve fsuid/fsgid across execve > > include/uapi/linux/securebits.h | 10 +- > security/commoncap.c| 9 +++-- > 2 files changed, 16 insertions(+), 3 deletions(-) > > -- James Morris
Re: [PATCH v2 1/2] mtd: concat: refactor concat_lock/concat_unlock
Hi All,
Ping?
On 23/05/19 11:19 AM, Chris Packham wrote:
> concat_lock() and concat_unlock() only differed in terms of the mtd_xx
> operation they called. Refactor them to use a common helper function and
> pass a boolean flag to indicate whether lock or unlock is needed.
>
> Signed-off-by: Chris Packham
> ---
> Changes in v2:
> - Use a boolean flag instead of passing a function pointer.
>
> drivers/mtd/mtdconcat.c | 44 +++--
> 1 file changed, 12 insertions(+), 32 deletions(-)
>
> diff --git a/drivers/mtd/mtdconcat.c b/drivers/mtd/mtdconcat.c
> index cbc5925e6440..6cb60dea509a 100644
> --- a/drivers/mtd/mtdconcat.c
> +++ b/drivers/mtd/mtdconcat.c
> @@ -451,7 +451,8 @@ static int concat_erase(struct mtd_info *mtd, struct
> erase_info *instr)
> return err;
> }
>
> -static int concat_lock(struct mtd_info *mtd, loff_t ofs, uint64_t len)
> +static int concat_xxlock(struct mtd_info *mtd, loff_t ofs, uint64_t len,
> + bool is_lock)
> {
> struct mtd_concat *concat = CONCAT(mtd);
> int i, err = -EINVAL;
> @@ -470,7 +471,10 @@ static int concat_lock(struct mtd_info *mtd, loff_t ofs,
> uint64_t len)
> else
> size = len;
>
> - err = mtd_lock(subdev, ofs, size);
> + if (is_lock)
> + err = mtd_lock(subdev, ofs, size);
> + else
> + err = mtd_unlock(subdev, ofs, size);
> if (err)
> break;
>
> @@ -485,38 +489,14 @@ static int concat_lock(struct mtd_info *mtd, loff_t
> ofs, uint64_t len)
> return err;
> }
>
> -static int concat_unlock(struct mtd_info *mtd, loff_t ofs, uint64_t len)
> +static int concat_lock(struct mtd_info *mtd, loff_t ofs, uint64_t len)
> {
> - struct mtd_concat *concat = CONCAT(mtd);
> - int i, err = 0;
> -
> - for (i = 0; i < concat->num_subdev; i++) {
> - struct mtd_info *subdev = concat->subdev[i];
> - uint64_t size;
> -
> - if (ofs >= subdev->size) {
> - size = 0;
> - ofs -= subdev->size;
> - continue;
> - }
> - if (ofs + len > subdev->size)
> - size = subdev->size - ofs;
> - else
> - size = len;
> -
> - err = mtd_unlock(subdev, ofs, size);
> - if (err)
> - break;
> -
> - len -= size;
> - if (len == 0)
> - break;
> -
> - err = -EINVAL;
> - ofs = 0;
> - }
> + return concat_xxlock(mtd, ofs, len, true);
> +}
>
> - return err;
> +static int concat_unlock(struct mtd_info *mtd, loff_t ofs, uint64_t len)
> +{
> + return concat_xxlock(mtd, ofs, len, false);
> }
>
> static void concat_sync(struct mtd_info *mtd)
>
Re: [PATCH] mtd: cfi_cmdset_0002: dynamically determine the max sectors
Hi All,
I think this may have got lost in the change of maintainer for mtd.
On 22/05/19 12:06 PM, Chris Packham wrote:
> Because PPB unlocking unlocks the whole chip cfi_ppb_unlock() needs to
> remember the locked status for each sector so it can re-lock the
> unaddressed sectors. Dynamically calculate the maximum number of sectors
> rather than using a hardcoded value that is too small for larger chips.
>
> Tested with Spansion S29GL01GS11TFI flash device.
>
> Signed-off-by: Chris Packham
> ---
> drivers/mtd/chips/cfi_cmdset_0002.c | 13 -
> 1 file changed, 8 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/mtd/chips/cfi_cmdset_0002.c
> b/drivers/mtd/chips/cfi_cmdset_0002.c
> index c8fa5906bdf9..a1a7d334aa82 100644
> --- a/drivers/mtd/chips/cfi_cmdset_0002.c
> +++ b/drivers/mtd/chips/cfi_cmdset_0002.c
> @@ -2533,8 +2533,6 @@ struct ppb_lock {
> int locked;
> };
>
> -#define MAX_SECTORS 512
> -
> #define DO_XXLOCK_ONEBLOCK_LOCK ((void *)1)
> #define DO_XXLOCK_ONEBLOCK_UNLOCK ((void *)2)
> #define DO_XXLOCK_ONEBLOCK_GETLOCK ((void *)3)
> @@ -2633,6 +2631,7 @@ static int __maybe_unused cfi_ppb_unlock(struct
> mtd_info *mtd, loff_t ofs,
> int i;
> int sectors;
> int ret;
> + int max_sectors;
>
> /*
>* PPB unlocking always unlocks all sectors of the flash chip.
> @@ -2640,7 +2639,11 @@ static int __maybe_unused cfi_ppb_unlock(struct
> mtd_info *mtd, loff_t ofs,
>* first check the locking status of all sectors and save
>* it for future use.
>*/
> - sect = kcalloc(MAX_SECTORS, sizeof(struct ppb_lock), GFP_KERNEL);
> + max_sectors = 0;
> + for (i = 0; i < mtd->numeraseregions; i++)
> + max_sectors += regions[i].numblocks;
> +
> + sect = kcalloc(max_sectors, sizeof(struct ppb_lock), GFP_KERNEL);
> if (!sect)
> return -ENOMEM;
>
> @@ -2689,9 +2692,9 @@ static int __maybe_unused cfi_ppb_unlock(struct
> mtd_info *mtd, loff_t ofs,
> }
>
> sectors++;
> - if (sectors >= MAX_SECTORS) {
> + if (sectors >= max_sectors) {
> printk(KERN_ERR "Only %d sectors for PPB locking
> supported!\n",
> -MAX_SECTORS);
> +max_sectors);
> kfree(sect);
> return -EINVAL;
> }
>
[PATCH v9 0/6] support a new type of PMIC,including two chips(rk817 and rk809)
Most of functions and registers of the rk817 and rk808 are the same, so they can share allmost all codes. Their specifications are as follows: 1) The RK809 and RK809 consist of 5 DCDCs, 9 LDOs and have the same registers for these components except dcdc5. 2) The dcdc5 is a boost dcdc for RK817 and is a buck for RK809. 3) The RK817 has one switch but The Rk809 has two. Changes in V2: 1. initialize the pm_pwroff_fn to NULL. 2. use EXPORT_SYMBOL_GPL to export pm_power_off_prepare. 3. change patch 2/3/4/5 subjects. Changes in V3 1. change patch 4 subjects 2. replace pr_ with dev_ for printing in patch 2 3. modify switch1 and switch2 configs in patch 2 4. explain gpio information for rk809 and rk817 in patch 4 Changes in V4: 1. modify some codes for patch 2 and patch 5 according to comments 2. add reviewer mail lists for patch 3 and 4 Changes in V5: modify some codes for patch 1 according to reveiw comments for v3. 1) remove the pm_power_off_prepare() and replace with shutdown call-back from syscore 2) move the macro REGMAP_IRQ_M into the regmap.h and rename it REGMAP_IRQ_LINE 3) make some dev_warn() log clear Changes in V6: modify some codes according to reveiw comments for v5. Changes in V7: modify some codes for patch 2 according to reveiw comments. Changes in V8: For helping me promote this work, Heiko send the V8 Changes in V9: 1.base on the V8 2.modify some codes according to reveiw comments for V8 from Mark Brown Tony Xie (6): mfd: rk808: remove the id_table mfd: rk808: Add RK817 and RK809 support regulator: rk808: add RK809 and RK817 support. dt-bindings: mfd: rk808: Add binding information for RK809 and RK817. rtc: rk808: add RK809 and RK817 support. clk: RK808: add RK809 and RK817 support. .../devicetree/bindings/mfd/rk808.txt | 44 ++ drivers/clk/Kconfig | 9 +- drivers/clk/clk-rk808.c | 64 +- drivers/mfd/Kconfig | 6 +- drivers/mfd/rk808.c | 199 +- drivers/regulator/Kconfig | 4 +- drivers/regulator/rk808-regulator.c | 646 +- drivers/rtc/Kconfig | 4 +- drivers/rtc/rtc-rk808.c | 68 +- include/linux/mfd/rk808.h | 175 + 10 files changed, 1155 insertions(+), 64 deletions(-) -- 2.17.1
[PATCH v9 4/6] dt-bindings: mfd: rk808: Add binding information for RK809 and RK817.
Add device tree bindings documentation for Rockchip's RK809 & RK817 PMIC. Signed-off-by: Tony Xie Reviewed-by: Rob Herring Acked-for-MFD-by: Lee Jones --- .../devicetree/bindings/mfd/rk808.txt | 44 +++ 1 file changed, 44 insertions(+) diff --git a/Documentation/devicetree/bindings/mfd/rk808.txt b/Documentation/devicetree/bindings/mfd/rk808.txt index 1683ec3245bc..04df07f6f793 100644 --- a/Documentation/devicetree/bindings/mfd/rk808.txt +++ b/Documentation/devicetree/bindings/mfd/rk808.txt @@ -3,11 +3,15 @@ RK8XX Power Management Integrated Circuit The rk8xx family current members: rk805 rk808 +rk809 +rk817 rk818 Required properties: - compatible: "rockchip,rk805" - compatible: "rockchip,rk808" +- compatible: "rockchip,rk809" +- compatible: "rockchip,rk817" - compatible: "rockchip,rk818" - reg: I2C slave address - interrupts: the interrupt outputs of the controller. @@ -45,6 +49,23 @@ Optional RK808 properties: the gpio controller. If DVS GPIOs aren't present, voltage changes will happen very quickly with no slow ramp time. +Optional shared RK809 and RK817 properties: +- vcc1-supply: The input supply for DCDC_REG1 +- vcc2-supply: The input supply for DCDC_REG2 +- vcc3-supply: The input supply for DCDC_REG3 +- vcc4-supply: The input supply for DCDC_REG4 +- vcc5-supply: The input supply for LDO_REG1, LDO_REG2, LDO_REG3 +- vcc6-supply: The input supply for LDO_REG4, LDO_REG5, LDO_REG6 +- vcc7-supply: The input supply for LDO_REG7, LDO_REG8, LDO_REG9 + +Optional RK809 properties: +- vcc8-supply: The input supply for SWITCH_REG1 +- vcc9-supply: The input supply for DCDC_REG5, SWITCH_REG2 + +Optional RK817 properties: +- vcc8-supply: The input supply for BOOST +- vcc9-supply: The input supply for OTG_SWITCH + Optional RK818 properties: - vcc1-supply: The input supply for DCDC_REG1 - vcc2-supply: The input supply for DCDC_REG2 @@ -86,6 +107,21 @@ number as described in RK808 datasheet. - SWITCH_REGn - valid values for n are 1 to 2 +Following regulators of the RK809 and RK817 PMIC blocks are supported. Note that +the 'n' in regulator name, as in DCDC_REGn or LDOn, represents the DCDC or LDO +number as described in RK809 and RK817 datasheets. + + - DCDC_REGn + - valid values for n are 1 to 5 for RK809. + - valid values for n are 1 to 4 for RK817. + - LDO_REGn + - valid values for n are 1 to 9 for RK809. + - valid values for n are 1 to 9 for RK817. + - SWITCH_REGn + - valid values for n are 1 to 2 for RK809. + - BOOST for RK817 + - OTG_SWITCH for RK817 + Following regulators of the RK818 PMIC block are supported. Note that the 'n' in regulator name, as in DCDC_REGn or LDOn, represents the DCDC or LDO number as described in RK818 datasheet. @@ -98,6 +134,14 @@ number as described in RK818 datasheet. - HDMI_SWITCH - OTG_SWITCH +It is necessary to configure three pins for both the RK809 and RK817, the three +pins are "gpio_ts" "gpio_gt" "gpio_slp". + The gpio_gt and gpio_ts pins support the gpio function. + The gpio_slp pin is for controlling the pmic states, as below: + - reset + - power down + - sleep + Standard regulator bindings are used inside regulator subnodes. Check Documentation/devicetree/bindings/regulator/regulator.txt for more details -- 2.17.1
[PATCH v9 2/6] mfd: rk808: Add RK817 and RK809 support
The RK809 and RK817 are a Power Management IC (PMIC) for multimedia
and handheld devices. They contains the following components:
- Regulators
- RTC
- Clocking
Both RK809 and RK817 chips are using a similar register map,
so we can reuse the RTC and Clocking functionality.
Most of regulators have a some implementation also.
Signed-off-by: Tony Xie
Acked-by: Stephen Boyd
Acked-for-MFD-by: Lee Jones
---
drivers/mfd/Kconfig | 6 +-
drivers/mfd/rk808.c | 192 +-
include/linux/mfd/rk808.h | 172 ++
3 files changed, 364 insertions(+), 6 deletions(-)
diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index 8c5dfdce4326..a8a2833407b1 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -1006,14 +1006,14 @@ config MFD_RC5T583
different functionality of the device.
config MFD_RK808
- tristate "Rockchip RK805/RK808/RK818 Power Management Chip"
+ tristate "Rockchip RK805/RK808/RK809/RK817/RK818 Power Management Chip"
depends on I2C && OF
select MFD_CORE
select REGMAP_I2C
select REGMAP_IRQ
help
- If you say yes here you get support for the RK805, RK808 and RK818
- Power Management chips.
+ If you say yes here you get support for the RK805, RK808, RK809,
+ RK817 and RK818 Power Management chips.
This driver provides common support for accessing the device
through I2C interface. The device supports multiple sub-devices
including interrupts, RTC, LDO & DCDC regulators, and onkey.
diff --git a/drivers/mfd/rk808.c b/drivers/mfd/rk808.c
index 94377782d208..6ee1c461a3bb 100644
--- a/drivers/mfd/rk808.c
+++ b/drivers/mfd/rk808.c
@@ -27,6 +27,7 @@
#include
#include
#include
+#include
struct rk808_reg_data {
int addr;
@@ -62,6 +63,27 @@ static bool rk808_is_volatile_reg(struct device *dev,
unsigned int reg)
return false;
}
+static bool rk817_is_volatile_reg(struct device *dev, unsigned int reg)
+{
+ /*
+* Notes:
+* - Technically the ROUND_30s bit makes RTC_CTRL_REG volatile, but
+* we don't use that feature. It's better to cache.
+*/
+
+ switch (reg) {
+ case RK817_SECONDS_REG ... RK817_WEEKS_REG:
+ case RK817_RTC_STATUS_REG:
+ case RK817_INT_STS_REG0:
+ case RK817_INT_STS_REG1:
+ case RK817_INT_STS_REG2:
+ case RK817_SYS_STS:
+ return true;
+ }
+
+ return true;
+}
+
static const struct regmap_config rk818_regmap_config = {
.reg_bits = 8,
.val_bits = 8,
@@ -86,6 +108,14 @@ static const struct regmap_config rk808_regmap_config = {
.volatile_reg = rk808_is_volatile_reg,
};
+static const struct regmap_config rk817_regmap_config = {
+ .reg_bits = 8,
+ .val_bits = 8,
+ .max_register = RK817_GPIO_INT_CFG,
+ .cache_type = REGCACHE_NONE,
+ .volatile_reg = rk817_is_volatile_reg,
+};
+
static struct resource rtc_resources[] = {
{
.start = RK808_IRQ_RTC_ALARM,
@@ -94,6 +124,10 @@ static struct resource rtc_resources[] = {
}
};
+static struct resource rk817_rtc_resources[] = {
+ DEFINE_RES_IRQ(RK817_IRQ_RTC_ALARM),
+};
+
static struct resource rk805_key_resources[] = {
{
.start = RK805_IRQ_PWRON_FALL,
@@ -107,6 +141,11 @@ static struct resource rk805_key_resources[] = {
}
};
+static struct resource rk817_pwrkey_resources[] = {
+ DEFINE_RES_IRQ(RK817_IRQ_PWRON_RISE),
+ DEFINE_RES_IRQ(RK817_IRQ_PWRON_FALL),
+};
+
static const struct mfd_cell rk805s[] = {
{ .name = "rk808-clkout", },
{ .name = "rk808-regulator", },
@@ -132,6 +171,21 @@ static const struct mfd_cell rk808s[] = {
},
};
+static const struct mfd_cell rk817s[] = {
+ { .name = "rk808-clkout",},
+ { .name = "rk808-regulator",},
+ {
+ .name = "rk8xx-pwrkey",
+ .num_resources = ARRAY_SIZE(rk817_pwrkey_resources),
+ .resources = &rk817_pwrkey_resources[0],
+ },
+ {
+ .name = "rk808-rtc",
+ .num_resources = ARRAY_SIZE(rk817_rtc_resources),
+ .resources = &rk817_rtc_resources[0],
+ },
+};
+
static const struct mfd_cell rk818s[] = {
{ .name = "rk808-clkout", },
{ .name = "rk808-regulator", },
@@ -167,6 +221,13 @@ static const struct rk808_reg_data rk808_pre_init_reg[] = {
VB_LO_SEL_3500MV },
};
+static const struct rk808_reg_data rk817_pre_init_reg[] = {
+ {RK817_RTC_CTRL_REG, RTC_STOP, RTC_STOP},
+ {RK817_GPIO_INT_CFG, RK817_INT_POL_MSK, RK817_INT_POL_H},
+ {RK817_SYS_CFG(1), RK817_HOTDIE_TEMP_MSK | RK817_TSD_TEMP_MSK,
+ RK817_HOTDIE_105 | RK817_TSD_140},
+};
+
static const struct rk808_reg_data rk818_
[PATCH v9 3/6] regulator: rk808: add RK809 and RK817 support.
Add support for the rk809 and rk817 regulator driver.
Their specifications are as follows：
1. The RK809 and RK809 consist of 5 DCDCs, 9 LDOs
and have the same registers for these components except dcdc5.
2. The dcdc5 is a boost dcdc for RK817 and is a buck for RK809.
3. The RK817 has one switch but The Rk809 has two.
The output voltages are configurable and are meant to supply power
to the main processor and other components.
Signed-off-by: Tony Xie
Acked-by: Lee Jones
---
drivers/regulator/Kconfig | 4 +-
drivers/regulator/rk808-regulator.c | 646 ++--
include/linux/mfd/rk808.h | 3 +
3 files changed, 625 insertions(+), 28 deletions(-)
diff --git a/drivers/regulator/Kconfig b/drivers/regulator/Kconfig
index ee60a222f5eb..3bfd820afcdd 100644
--- a/drivers/regulator/Kconfig
+++ b/drivers/regulator/Kconfig
@@ -742,11 +742,11 @@ config REGULATOR_RC5T583
outputs which can be controlled by i2c communication.
config REGULATOR_RK808
- tristate "Rockchip RK805/RK808/RK818 Power regulators"
+ tristate "Rockchip RK805/RK808/RK809/RK817/RK818 Power regulators"
depends on MFD_RK808
help
Select this option to enable the power regulator of ROCKCHIP
- PMIC RK805,RK808 and RK818.
+ PMIC RK805,RK809&RK817,RK808 and RK818.
This driver supports the control of different power rails of device
through regulator interface. The device supports multiple DCDC/LDO
outputs which can be controlled by i2c communication.
diff --git a/drivers/regulator/rk808-regulator.c
b/drivers/regulator/rk808-regulator.c
index 213b68743cc8..6d71ae8cb3bd 100644
--- a/drivers/regulator/rk808-regulator.c
+++ b/drivers/regulator/rk808-regulator.c
@@ -36,6 +36,12 @@
#define RK808_BUCK4_VSEL_MASK 0xf
#define RK808_LDO_VSEL_MASK0x1f
+#define RK809_BUCK5_VSEL_MASK 0x7
+
+#define RK817_LDO_VSEL_MASK0x7f
+#define RK817_BOOST_VSEL_MASK 0x7
+#define RK817_BUCK_VSEL_MASK 0x7f
+
#define RK818_BUCK_VSEL_MASK 0x3f
#define RK818_BUCK4_VSEL_MASK 0x1f
#define RK818_LDO_VSEL_MASK0x1f
@@ -65,30 +71,36 @@
/* max steps for increase voltage of Buck1/2, equal 100mv*/
#define MAX_STEPS_ONE_TIME 8
-#define RK805_DESC(_id, _match, _supply, _min, _max, _step, _vreg, \
- _vmask, _ereg, _emask, _etime) \
- [_id] = { \
- .name = (_match), \
- .supply_name= (_supply),\
- .of_match = of_match_ptr(_match), \
- .regulators_node = of_match_ptr("regulators"), \
- .type = REGULATOR_VOLTAGE,\
- .id = (_id),\
- .n_voltages = (((_max) - (_min)) / (_step) + 1),\
- .owner = THIS_MODULE, \
- .min_uV = (_min) * 1000,\
- .uV_step= (_step) * 1000, \
- .vsel_reg = (_vreg), \
- .vsel_mask = (_vmask), \
- .enable_reg = (_ereg), \
- .enable_mask= (_emask), \
- .enable_time= (_etime), \
- .ops= &rk805_reg_ops, \
+#define ENABLE_MASK(id)(BIT(id) | BIT(4 + (id)))
+#define DISABLE_VAL(id)(BIT(4 + (id)))
+
+#define RK817_BOOST_DESC(_id, _match, _supply, _min, _max, _step, _vreg,\
+ _vmask, _ereg, _emask, _enval, _disval, _etime, m_drop) \
+ { \
+ .name = (_match), \
+ .supply_name= (_supply),\
+ .of_match = of_match_ptr(_match), \
+ .regulators_node = of_match_ptr("regulators"), \
+ .type = REGULATOR_VOLTAGE,\
+ .id = (_id),\
+ .n_voltages = (((_max) - (_min)) / (_step) + 1),\
+ .owner = THIS_MODULE, \
+ .min_uV = (_min) * 1000,\
+ .uV_step= (_step) * 1000, \
+ .vsel_reg = (_vreg), \
+ .vsel_mask = (_vmask), \
+
[PATCH v9 1/6] mfd: rk808: remove the id_table
Remove the id_table because it's not used.
Signed-off-by: Tony Xie
---
drivers/mfd/rk808.c | 9 -
1 file changed, 9 deletions(-)
diff --git a/drivers/mfd/rk808.c b/drivers/mfd/rk808.c
index 216fbf6adec9..94377782d208 100644
--- a/drivers/mfd/rk808.c
+++ b/drivers/mfd/rk808.c
@@ -568,14 +568,6 @@ static int rk808_remove(struct i2c_client *client)
return 0;
}
-static const struct i2c_device_id rk808_ids[] = {
- { "rk805" },
- { "rk808" },
- { "rk818" },
- { },
-};
-MODULE_DEVICE_TABLE(i2c, rk808_ids);
-
static struct i2c_driver rk808_i2c_driver = {
.driver = {
.name = "rk808",
@@ -583,7 +575,6 @@ static struct i2c_driver rk808_i2c_driver = {
},
.probe= rk808_probe,
.remove = rk808_remove,
- .id_table = rk808_ids,
};
module_i2c_driver(rk808_i2c_driver);
--
2.17.1
Mrs patricia lugan
Dear Friend, I am Mrs Patricia lugan.am sending you this brief letter to solicit your partnership to transfer $18.5 million US Dollars.I shall send you more information and procedures when I receive positive response from you. please send me a message in my Email box(mrs.patricialu...@gmail.com) as i wait to hear from you. Best regard Mrs patricia lugan
[PATCH v9 6/6] clk: RK808: add RK809 and RK817 support.
RK809 and RK817 are power management IC chips for multimedia products.
most of their functions and registers are same, including the clkout
funciton.
Signed-off-by: Tony Xie
Acked-by: Stephen Boyd
---
drivers/clk/Kconfig | 9 +++---
drivers/clk/clk-rk808.c | 64 -
2 files changed, 67 insertions(+), 6 deletions(-)
diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig
index e5b2fe80eab4..532ab112fa8a 100644
--- a/drivers/clk/Kconfig
+++ b/drivers/clk/Kconfig
@@ -52,13 +52,12 @@ config COMMON_CLK_MAX9485
This driver supports Maxim 9485 Programmable Audio Clock Generator
config COMMON_CLK_RK808
- tristate "Clock driver for RK805/RK808/RK818"
+ tristate "Clock driver for RK805/RK808/RK809/RK817/RK818"
depends on MFD_RK808
---help---
- This driver supports RK805, RK808 and RK818 crystal oscillator clock.
These
- multi-function devices have two fixed-rate oscillators,
- clocked at 32KHz each. Clkout1 is always on, Clkout2 can off
- by control register.
+ This driver supports RK805, RK809 and RK817, RK808 and RK818 crystal
oscillator clock.
+ These multi-function devices have two fixed-rate oscillators, clocked
at 32KHz each.
+ Clkout1 is always on, Clkout2 can off by control register.
config COMMON_CLK_HI655X
tristate "Clock driver for Hi655x" if EXPERT
diff --git a/drivers/clk/clk-rk808.c b/drivers/clk/clk-rk808.c
index 8d90bdf5b946..75f2cf0dfc9f 100644
--- a/drivers/clk/clk-rk808.c
+++ b/drivers/clk/clk-rk808.c
@@ -96,6 +96,68 @@ of_clk_rk808_get(struct of_phandle_args *clkspec, void *data)
return idx ? &rk808_clkout->clkout2_hw : &rk808_clkout->clkout1_hw;
}
+static int rk817_clkout2_enable(struct clk_hw *hw, bool enable)
+{
+ struct rk808_clkout *rk808_clkout = container_of(hw,
+struct rk808_clkout,
+clkout2_hw);
+ struct rk808 *rk808 = rk808_clkout->rk808;
+
+ return regmap_update_bits(rk808->regmap, RK817_SYS_CFG(1),
+ RK817_CLK32KOUT2_EN,
+ enable ? RK817_CLK32KOUT2_EN : 0);
+}
+
+static int rk817_clkout2_prepare(struct clk_hw *hw)
+{
+ return rk817_clkout2_enable(hw, true);
+}
+
+static void rk817_clkout2_unprepare(struct clk_hw *hw)
+{
+ rk817_clkout2_enable(hw, false);
+}
+
+static int rk817_clkout2_is_prepared(struct clk_hw *hw)
+{
+ struct rk808_clkout *rk808_clkout = container_of(hw,
+struct rk808_clkout,
+clkout2_hw);
+ struct rk808 *rk808 = rk808_clkout->rk808;
+ unsigned int val;
+
+ int ret = regmap_read(rk808->regmap, RK817_SYS_CFG(1), &val);
+
+ if (ret < 0)
+ return 0;
+
+ return (val & RK817_CLK32KOUT2_EN) ? 1 : 0;
+}
+
+static const struct clk_ops rk817_clkout2_ops = {
+ .prepare = rk817_clkout2_prepare,
+ .unprepare = rk817_clkout2_unprepare,
+ .is_prepared = rk817_clkout2_is_prepared,
+ .recalc_rate = rk808_clkout_recalc_rate,
+};
+
+static const struct clk_ops *rkpmic_get_ops(long variant)
+{
+ switch (variant) {
+ case RK809_ID:
+ case RK817_ID:
+ return &rk817_clkout2_ops;
+ /*
+* For the default case, it match the following PMIC type.
+* RK805_ID
+* RK808_ID
+* RK818_ID
+*/
+ default:
+ return &rk808_clkout2_ops;
+ }
+}
+
static int rk808_clkout_probe(struct platform_device *pdev)
{
struct rk808 *rk808 = dev_get_drvdata(pdev->dev.parent);
@@ -127,7 +189,7 @@ static int rk808_clkout_probe(struct platform_device *pdev)
return ret;
init.name = "rk808-clkout2";
- init.ops = &rk808_clkout2_ops;
+ init.ops = rkpmic_get_ops(rk808->variant);
rk808_clkout->clkout2_hw.init = &init;
/* optional override of the clockname */
--
2.17.1
[PATCH v9 5/6] rtc: rk808: add RK809 and RK817 support.
RK809 and RK817 are power management IC chips for multimedia products.
Most of their functions and registers are same, including the rtc.
Signed-off-by: Tony Xie
Acked-by: Alexandre Belloni
---
drivers/rtc/Kconfig | 4 +--
drivers/rtc/rtc-rk808.c | 68 -
2 files changed, 56 insertions(+), 16 deletions(-)
diff --git a/drivers/rtc/Kconfig b/drivers/rtc/Kconfig
index a819ef07b7ec..8c34f7ec0a59 100644
--- a/drivers/rtc/Kconfig
+++ b/drivers/rtc/Kconfig
@@ -363,11 +363,11 @@ config RTC_DRV_MAX77686
will be called rtc-max77686.
config RTC_DRV_RK808
- tristate "Rockchip RK805/RK808/RK818 RTC"
+ tristate "Rockchip RK805/RK808/RK809/RK817/RK818 RTC"
depends on MFD_RK808
help
If you say yes here you will get support for the
- RTC of RK805, RK808 and RK818 PMIC.
+ RTC of RK805, RK809 and RK817, RK808 and RK818 PMIC.
This driver can also be built as a module. If so, the module
will be called rk808-rtc.
diff --git a/drivers/rtc/rtc-rk808.c b/drivers/rtc/rtc-rk808.c
index 739c0d42e835..5bacdafb7b21 100644
--- a/drivers/rtc/rtc-rk808.c
+++ b/drivers/rtc/rtc-rk808.c
@@ -50,9 +50,18 @@
#define NUM_TIME_REGS (RK808_WEEKS_REG - RK808_SECONDS_REG + 1)
#define NUM_ALARM_REGS (RK808_ALARM_YEARS_REG - RK808_ALARM_SECONDS_REG + 1)
+struct rk_rtc_compat_reg {
+ unsigned int ctrl_reg;
+ unsigned int status_reg;
+ unsigned int alarm_seconds_reg;
+ unsigned int int_reg;
+ unsigned int seconds_reg;
+};
+
struct rk808_rtc {
struct rk808 *rk808;
struct rtc_device *rtc;
+ struct rk_rtc_compat_reg *creg;
int irq;
};
@@ -101,7 +110,7 @@ static int rk808_rtc_readtime(struct device *dev, struct
rtc_time *tm)
int ret;
/* Force an update of the shadowed registers right now */
- ret = regmap_update_bits(rk808->regmap, RK808_RTC_CTRL_REG,
+ ret = regmap_update_bits(rk808->regmap, rk808_rtc->creg->ctrl_reg,
BIT_RTC_CTRL_REG_RTC_GET_TIME,
BIT_RTC_CTRL_REG_RTC_GET_TIME);
if (ret) {
@@ -115,7 +124,7 @@ static int rk808_rtc_readtime(struct device *dev, struct
rtc_time *tm)
* 32khz. If we clear the GET_TIME bit here, the time of i2c transfer
* certainly more than 31.25us: 16 * 2.5us at 400kHz bus frequency.
*/
- ret = regmap_update_bits(rk808->regmap, RK808_RTC_CTRL_REG,
+ ret = regmap_update_bits(rk808->regmap, rk808_rtc->creg->ctrl_reg,
BIT_RTC_CTRL_REG_RTC_GET_TIME,
0);
if (ret) {
@@ -123,7 +132,7 @@ static int rk808_rtc_readtime(struct device *dev, struct
rtc_time *tm)
return ret;
}
- ret = regmap_bulk_read(rk808->regmap, RK808_SECONDS_REG,
+ ret = regmap_bulk_read(rk808->regmap, rk808_rtc->creg->seconds_reg,
rtc_data, NUM_TIME_REGS);
if (ret) {
dev_err(dev, "Failed to bulk read rtc_data: %d\n", ret);
@@ -166,7 +175,7 @@ static int rk808_rtc_set_time(struct device *dev, struct
rtc_time *tm)
rtc_data[6] = bin2bcd(tm->tm_wday);
/* Stop RTC while updating the RTC registers */
- ret = regmap_update_bits(rk808->regmap, RK808_RTC_CTRL_REG,
+ ret = regmap_update_bits(rk808->regmap, rk808_rtc->creg->ctrl_reg,
BIT_RTC_CTRL_REG_STOP_RTC_M,
BIT_RTC_CTRL_REG_STOP_RTC_M);
if (ret) {
@@ -174,14 +183,14 @@ static int rk808_rtc_set_time(struct device *dev, struct
rtc_time *tm)
return ret;
}
- ret = regmap_bulk_write(rk808->regmap, RK808_SECONDS_REG,
+ ret = regmap_bulk_write(rk808->regmap, rk808_rtc->creg->seconds_reg,
rtc_data, NUM_TIME_REGS);
if (ret) {
dev_err(dev, "Failed to bull write rtc_data: %d\n", ret);
return ret;
}
/* Start RTC again */
- ret = regmap_update_bits(rk808->regmap, RK808_RTC_CTRL_REG,
+ ret = regmap_update_bits(rk808->regmap, rk808_rtc->creg->ctrl_reg,
BIT_RTC_CTRL_REG_STOP_RTC_M, 0);
if (ret) {
dev_err(dev, "Failed to update RTC control: %d\n", ret);
@@ -199,8 +208,13 @@ static int rk808_rtc_readalarm(struct device *dev, struct
rtc_wkalrm *alrm)
uint32_t int_reg;
int ret;
- ret = regmap_bulk_read(rk808->regmap, RK808_ALARM_SECONDS_REG,
+ ret = regmap_bulk_read(rk808->regmap,
+ rk808_rtc->creg->alarm_seconds_reg,
alrm_data, NUM_ALARM_REGS);
+ if (ret) {
+ dev_err(dev, "Failed to read RTC alarm date REG: %d\n", ret);
+ return ret;
+ }
alrm->time.tm_sec = bcd2bin(alrm_data[0] & SECONDS_REG_MSK);
Re: pagecache locking (was: bcachefs status update) merged)
On Thu, Jun 13, 2019 at 1:56 PM Dave Chinner wrote: > > - buffered read and buffered write can run concurrently if they > don't overlap, but right now they are serialised because that's the > only way to provide POSIX atomic write vs read semantics (only XFS > provides userspace with that guarantee). I do not believe that posix itself actually requires that at all, although extended standards may. That said, from a quality of implementation standpoint, it's obviously a good thing to do, so it might be worth looking at if something reasonable can be done. The XFS atomicity guarantees are better than what other filesystems give, but they might also not be exactly required. But POSIX actually ends up being pretty lax, and says "Writes can be serialized with respect to other reads and writes. If a read() of file data can be proven (by any means) to occur after a write() of the data, it must reflect that write(), even if the calls are made by different processes. A similar requirement applies to multiple write operations to the same file position. This is needed to guarantee the propagation of data from write() calls to subsequent read() calls. This requirement is particularly significant for networked file systems, where some caching schemes violate these semantics." Note the "can" in "can be serialized", not "must". Also note that whole language about how the read file data must match the written data only if the read can be proven to have occurred after a write of that data. Concurrency is very much left in the air, only provably serial operations matter. (There is also language that talks about "after the write has successfully returned" etc - again, it's about reads that occur _after_ the write, not concurrently with the write). The only atomicity guarantees are about the usual pipe writes and PIPE_BUF. Those are very explicit. Of course, there are lots of standards outside of just the POSIX read/write thing, so you may be thinking of some other stricter standard. POSIX itself has always been pretty permissive. And as mentioned, I do agree from a QoI standpoint that atomicity is nice, and that the XFS behavior is better. However, it does seem that nobody really cares, because I'm not sure we've ever done it in general (although we do have that i_rwsem, but I think it's mainly used to give the proper lseek behavior). And so the XFS behavior may not necessarily be *worth* it, although I presume you have some test for this as part of xfstests. Linus
Re: [PATCH RFC 00/10] RDMA/FS DAX truncate proposal
On Thu, Jun 13, 2019 at 07:31:07PM -0700, Matthew Wilcox wrote: > On Fri, Jun 14, 2019 at 12:09:21PM +1000, Dave Chinner wrote: > > If the lease holder modifies the mapping in a way that causes it's > > own internal state to screw up, then that's a bug in the lease > > holder application. > > Sounds like the lease semantics aren't the right ones for the longterm > GUP users then. The point of the longterm GUP is so the pages can be > written to, and if the filesystem is going to move the pages around when > they're written to, that just won't work. And now we go full circle back to the constraints we decided on long ago because we can't rely on demand paging RDMA hardware any time soon to do everything we need to transparently support long-term GUP on file-backed mappings. i.e.: RDMA to file backed mappings must first preallocate and write zeros to the range of the file they are mapping so that the filesystem block mapping is complete and static for the life of the RDMA mapping that will pin it. IOWs, the layout lease will tell the RDMA application that the static setup it has already done to work correctly with a file backed mapping may be about to be broken by a third party. -Dave. -- Dave Chinner da...@fromorbit.com
Re: memory leak in vhost_net_ioctl
Hello, syzbot has tested the proposed patch but the reproducer still triggered crash: memory leak in batadv_tvlv_handler_register 484.626788][ T156] bond0 (unregistering): Releasing backup interface bond_slave_1 Warning: Permanently added '10.128.0.87' (ECDSA) to the list of known hosts. BUG: memory leak unreferenced object 0x88811d25c4c0 (size 64): comm "softirq", pid 0, jiffies 4294943668 (age 434.830s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 e0 fc 5b 20 81 88 ff ff ..[ 00 00 00 00 00 00 00 00 20 91 15 83 ff ff ff ff ... backtrace: [<0045bc9d>] kmemleak_alloc_recursive include/linux/kmemleak.h:43 [inline] [<0045bc9d>] slab_post_alloc_hook mm/slab.h:439 [inline] [<0045bc9d>] slab_alloc mm/slab.c:3326 [inline] [<0045bc9d>] kmem_cache_alloc_trace+0x13d/0x280 mm/slab.c:3553 [<197d773e>] kmalloc include/linux/slab.h:547 [inline] [<197d773e>] kzalloc include/linux/slab.h:742 [inline] [<197d773e>] batadv_tvlv_handler_register+0xae/0x140 net/batman-adv/tvlv.c:529 [] batadv_tt_init+0x78/0x180 net/batman-adv/translation-table.c:4411 [<8c50839d>] batadv_mesh_init+0x196/0x230 net/batman-adv/main.c:208 [<1c5a74a3>] batadv_softif_init_late+0x1ca/0x220 net/batman-adv/soft-interface.c:861 [<4e676cd1>] register_netdevice+0xbf/0x600 net/core/dev.c:8635 [<5601497b>] __rtnl_newlink+0xaca/0xb30 net/core/rtnetlink.c:3199 [ ] rtnl_newlink+0x4e/0x80 net/core/rtnetlink.c:3245 [ ] rtnetlink_rcv_msg+0x178/0x4b0 net/core/rtnetlink.c:5214 [<140451f6>] netlink_rcv_skb+0x61/0x170 net/netlink/af_netlink.c:2482 [<237e38f7>] rtnetlink_rcv+0x1d/0x30 net/core/rtnetlink.c:5232 [<0d47c000>] netlink_unicast_kernel net/netlink/af_netlink.c:1307 [inline] [<0d47c000>] netlink_unicast+0x1ec/0x2d0 net/netlink/af_netlink.c:1333 [<98503d79>] netlink_sendmsg+0x26a/0x480 net/netlink/af_netlink.c:1922 [<9263e868>] sock_sendmsg_nosec net/socket.c:646 [inline] [<9263e868>] sock_sendmsg+0x54/0x70 net/socket.c:665 [<7791ad47>] __sys_sendto+0x148/0x1f0 net/socket.c:1958 [ ] __do_sys_sendto net/socket.c:1970 [inline] [ ] __se_sys_sendto net/socket.c:1966 [inline] [ ] __x64_sys_sendto+0x2a/0x30 net/socket.c:1966 BUG: memory leak unreferenced object 0x8881024a3340 (size 64): comm "softirq", pid 0, jiffies 4294943678 (age 434.730s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 e0 2c 66 04 81 88 ff ff .,f. 00 00 00 00 00 00 00 00 20 91 15 83 ff ff ff ff ... backtrace: [<0045bc9d>] kmemleak_alloc_recursive include/linux/kmemleak.h:43 [inline] [<0045bc9d>] slab_post_alloc_hook mm/slab.h:439 [inline] [<0045bc9d>] slab_alloc mm/slab.c:3326 [inline] [<0045bc9d>] kmem_cache_alloc_trace+0x13d/0x280 mm/slab.c:3553 [<197d773e>] kmalloc include/linux/slab.h:547 [inline] [<197d773e>] kzalloc include/linux/slab.h:742 [inline] [<197d773e>] batadv_tvlv_handler_register+0xae/0x140 net/batman-adv/tvlv.c:529 [ ] batadv_tt_init+0x78/0x180 net/batman-adv/translation-table.c:4411 [<8c50839d>] batadv_mesh_init+0x196/0x230 net/batman-adv/main.c:208 [<1c5a74a3>] batadv_softif_init_late+0x1ca/0x220 net/batman-adv/soft-interface.c:861 [<4e676cd1>] register_netdevice+0xbf/0x600 net/core/dev.c:8635 [<5601497b>] __rtnl_newlink+0xaca/0xb30 net/core/rtnetlink.c:3199 [ ] rtnl_newlink+0x4e/0x80 net/core/rtnetlink.c:3245 [ ] rtnetlink_rcv_msg+0x178/0x4b0 net/core/rtnetlink.c:5214 [<140451f6>] netlink_rcv_skb+0x61/0x170 net/netlink/af_netlink.c:2482 [<237e38f7>] rtnetlink_rcv+0x1d/0x30 net/core/rtnetlink.c:5232 [<0d47c000>] netlink_unicast_kernel net/netlink/af_netlink.c:1307 [inline] [<0d47c000>] netlink_unicast+0x1ec/0x2d0 net/netlink/af_netlink.c:1333 [<98503d79>] netlink_sendmsg+0x26a/0x480 net/netlink/af_netlink.c:1922 [<9263e868>] sock_sendmsg_nosec net/socket.c:646 [inline] [<9263e868>] sock_sendmsg+0x54/0x70 net/socket.c:665 [<7791ad47>] __sys_sendto+0x148/0x1f0 net/socket.c:1958 [ ] __do_sys_sendto net/socket.c:1970 [inline] [ ] __se_sys_sendto net/socket.c:1966 [inline] [ ] __x64_sys_sendto+0x2a/0x30 net/socket.c:1966 BUG: memory leak unreferenced object 0x888108a71b80 (size 128): comm "syz-executor.3", pid 7367, jiffies 4294943696 (age 434.550s) hex dump (first 32 bytes): f0 f8 bf 02 81 88 ff ff f0 f8 bf 0
[linux-next:master 5930/6350] drivers/net/ethernet/amazon/ena/ena_netdev.c:1158:6: sparse: sparse: symbol 'ena_adjust_intr_moderation' was not declared. Should it be static?
tree: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master head: da151e650328dcd37176cf49fc626a7f42bfbe17 commit: c2b542044761965db0e4cc400ab6abf670fc25b7 [5930/6350] net: ena: remove inline keyword from functions in *.c reproduce: # apt-get install sparse # sparse version: v0.6.1-rc1-7-g2b96cd8-dirty git checkout c2b542044761965db0e4cc400ab6abf670fc25b7 make ARCH=x86_64 allmodconfig make C=1 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' If you fix the issue, kindly add following tag Reported-by: kbuild test robot sparse warnings: (new ones prefixed by >>) >> drivers/net/ethernet/amazon/ena/ena_netdev.c:1158:6: sparse: sparse: symbol >> 'ena_adjust_intr_moderation' was not declared. Should it be static? drivers/net/ethernet/amazon/ena/ena_netdev.c:3428:59: sparse: sparse: Using plain integer as NULL pointer Please review and possibly fold the followup patch. --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation
[RFC PATCH linux-next] net: ena: ena_adjust_intr_moderation() can be static
Fixes: c2b542044761 ("net: ena: remove inline keyword from functions in *.c")
Signed-off-by: kbuild test robot
---
ena_netdev.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/amazon/ena/ena_netdev.c
b/drivers/net/ethernet/amazon/ena/ena_netdev.c
index b7865ee..b63ae9b 100644
--- a/drivers/net/ethernet/amazon/ena/ena_netdev.c
+++ b/drivers/net/ethernet/amazon/ena/ena_netdev.c
@@ -1155,7 +1155,7 @@ static int ena_clean_rx_irq(struct ena_ring *rx_ring,
struct napi_struct *napi,
return 0;
}
-void ena_adjust_intr_moderation(struct ena_ring *rx_ring,
+static void ena_adjust_intr_moderation(struct ena_ring *rx_ring,
struct ena_ring *tx_ring)
{
/* We apply adaptive moderation on Rx path only.
linux-next: manual merge of the rdma tree with Linus' tree
Hi all,
Today's linux-next merge of the rdma tree got conflicts in:
drivers/infiniband/core/uverbs_cmd.c
drivers/infiniband/core/uverbs_std_types_cq.c
between commit:
6876aaedc8a1 ("RDMA/uverbs: Pass udata on uverbs error unwind")
from Linus' tree and commit:
e39afe3d6dbd ("RDMA: Convert CQ allocations to be under core responsibility")
from the rdma tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc drivers/infiniband/core/uverbs_cmd.c
index 63fe14c7c68f,5c00d9a5698a..
--- a/drivers/infiniband/core/uverbs_cmd.c
+++ b/drivers/infiniband/core/uverbs_cmd.c
@@@ -1053,8 -1045,10 +1056,10 @@@ static struct ib_ucq_object *create_cq(
return obj;
err_cb:
- ib_destroy_cq(cq);
+ ib_destroy_cq_user(cq, uverbs_get_cleared_udata(attrs));
-
+ cq = NULL;
+ err_free:
+ kfree(cq);
err_file:
if (ev_file)
ib_uverbs_release_ucq(attrs->ufile, ev_file, obj);
diff --cc drivers/infiniband/core/uverbs_std_types_cq.c
index 07ea4e3c4566,06b8c7d017b7..
--- a/drivers/infiniband/core/uverbs_std_types_cq.c
+++ b/drivers/infiniband/core/uverbs_std_types_cq.c
@@@ -135,8 -140,10 +140,10 @@@ static int UVERBS_HANDLER(UVERBS_METHOD
return 0;
err_cq:
- ib_destroy_cq(cq);
+ ib_destroy_cq_user(cq, uverbs_get_cleared_udata(attrs));
-
+ cq = NULL;
+ err_free:
+ kfree(cq);
err_event_file:
if (ev_file)
uverbs_uobject_put(ev_file_uobj);
pgpYG48_ZSejO.pgp
Description: OpenPGP digital signature
[PATCH] arm64: Allow user selection of ARM64_MODULE_PLTS
Make ARM64_MODULE_PLTS a selectable Kconfig symbol, since some people might have very big modules spilling out of the dedicated module area into vmalloc. Help text is copied from the ARM 32-bit counterpart. Signed-off-by: Florian Fainelli --- arch/arm64/Kconfig | 14 +- 1 file changed, 13 insertions(+), 1 deletion(-) diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig index 697ea0510729..36befe987b73 100644 --- a/arch/arm64/Kconfig +++ b/arch/arm64/Kconfig @@ -1418,8 +1418,20 @@ config ARM64_SVE KVM in the same kernel image. config ARM64_MODULE_PLTS - bool + bool "Use PLTs to allow module memory to spill over into vmalloc area" select HAVE_MOD_ARCH_SPECIFIC + help + Allocate PLTs when loading modules so that jumps and calls whose + targets are too far away for their relative offsets to be encoded + in the instructions themselves can be bounced via veneers in the + module's PLT. This allows modules to be allocated in the generic + vmalloc area after the dedicated module memory area has been + exhausted. The modules will use slightly more memory, but after + rounding up to page size, the actual memory footprint is usually + the same. + + Disabling this is usually safe for small single-platform + configurations. If unsure, say y. config ARM64_PSEUDO_NMI bool "Support for NMI-like interrupts" -- 2.17.1
Re: [PATCH RFC 00/10] RDMA/FS DAX truncate proposal
On Thu, Jun 13, 2019 at 01:34:05PM -0700, Ira Weiny wrote: > On Thu, Jun 13, 2019 at 10:25:55AM +1000, Dave Chinner wrote: > > On Wed, Jun 12, 2019 at 05:37:53AM -0700, Matthew Wilcox wrote: > > > On Sat, Jun 08, 2019 at 10:10:36AM +1000, Dave Chinner wrote: > > > > On Fri, Jun 07, 2019 at 11:25:35AM -0700, Ira Weiny wrote: > > > > > Are you suggesting that we have something like this from user space? > > > > > > > > > > fcntl(fd, F_SETLEASE, F_LAYOUT | F_UNBREAKABLE); > > > > > > > > Rather than "unbreakable", perhaps a clearer description of the > > > > policy it entails is "exclusive"? > > > > > > > > i.e. what we are talking about here is an exclusive lease that > > > > prevents other processes from changing the layout. i.e. the > > > > mechanism used to guarantee a lease is exclusive is that the layout > > > > becomes "unbreakable" at the filesystem level, but the policy we are > > > > actually presenting to uses is "exclusive access"... > > > > > > That's rather different from the normal meaning of 'exclusive' in the > > > context of locks, which is "only one user can have access to this at > > > a time". > > > > > > Layout leases are not locks, they are a user access policy object. > > It is the process/fd which holds the lease and it's the process/fd > > that is granted exclusive access. This is exactly the same semantic > > as O_EXCL provides for granting exclusive access to a block device > > via open(), yes? > > > > > As I understand it, this is rather more like a 'shared' or > > > 'read' lock. The filesystem would be the one which wants an exclusive > > > lock, so it can modify the mapping of logical to physical blocks. > > > > ISTM that you're conflating internal filesystem implementation with > > application visible semantics. Yes, the filesystem uses internal > > locks to serialise the modification of the things the lease manages > > access too, but that has nothing to do with the access policy the > > lease provides to users. > > > > e.g. Process A has an exclusive layout lease on file F. It does an > > IO to file F. The filesystem IO path checks that Process A owns the > > lease on the file and so skips straight through layout breaking > > because it owns the lease and is allowed to modify the layout. It > > then takes the inode metadata locks to allocate new space and write > > new data. > > > > Process B now tries to write to file F. The FS checks whether > > Process B owns a layout lease on file F. It doesn't, so then it > > tries to break the layout lease so the IO can proceed. The layout > > breaking code sees that process A has an exclusive layout lease > > granted, and so returns -ETXTBSY to process B - it is not allowed to > > break the lease and so the IO fails with -ETXTBSY. > > > > i.e. the exclusive layout lease prevents other processes from > > performing operations that may need to modify the layout from > > performing those operations. It does not "lock" the file/inode in > > any way, it just changes how the layout lease breaking behaves. > > Question: Do we expect Process A to get notified that Process B was attempting > to change the layout? In which case? In the non-exclusive case, yes, the lease gets recalled and the application needs to play nice and release it's references and drop the lease. In the exclusive case, no. The application has said "I don't play nice with others" and so we basically tell process B to get stuffed and process A can continue onwards oblivious to the wreckage it leaves behind > This changes the exclusivity semantics. While Process A has an exclusive > lease > it could release it if notified to allow process B temporary exclusivity. And then it's not an exclusive lease - it's just a normal layout lease. Process B -does not need a lease- to write to the file. All the layout lease does is provide notification to applications that rely on the layout of the file being under their control that someone else is about to modify the layout. The lease holder that "plays nice" then releases the layout and drops it's lease, allowing process B to begin it's operation. Process A then immediately takes a new layout lease, and remaps the file layout via FIEMAP or by creating a new RDMA MR for the mmap region. THose operations get serialised by the filesystem because the operation being run by process B is run atomically w.r.t. the original lease being broken. Hence the new mapping that process A gets with it's new lease reflects whatever change was made by process B. IOWs, the "normal" layout lease recall behaviour provides "temporary exclusivity" for third parties. If you are able to release leases temporarily and regain them then there is no need for an exclusive lease. > Question 2: Do we expect other process' (say Process C) to also be able to map > and pin the file? I believe users will need this and for layout purposes it > is > ok to do so. But this means that Process A does not have "exclusive" access > to > the le
[Patch v2 3/3] staging: rtl8723bs: hal: sdio_halinit: fix Comparison to NULL
This patch fixes below issue reported by checkpatch
CHECK: Comparison to NULL could be written "psta"
CHECK: Comparison to NULL could be written "psta"
Signed-off-by: Hariprasad Kelam
-
changes in v2: Send proper patch with out corruption
---
drivers/staging/rtl8723bs/hal/sdio_halinit.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/rtl8723bs/hal/sdio_halinit.c
b/drivers/staging/rtl8723bs/hal/sdio_halinit.c
index 5c7cff0..6f10349 100644
--- a/drivers/staging/rtl8723bs/hal/sdio_halinit.c
+++ b/drivers/staging/rtl8723bs/hal/sdio_halinit.c
@@ -1558,7 +1558,7 @@ static void SetHwReg8723BS(struct adapter *padapter, u8
variable, u8 *val)
DBG_871X_LEVEL(_drv_always_, "WOWLAN_DISABLE\n");
psta = rtw_get_stainfo(&padapter->stapriv,
get_bssid(pmlmepriv));
- if (psta != NULL)
+ if (psta)
rtl8723b_set_FwMediaStatusRpt_cmd(padapter,
RT_MEDIA_DISCONNECT, psta->mac_id);
else
DBG_871X("psta is null\n");
@@ -1673,7 +1673,7 @@ static void SetHwReg8723BS(struct adapter *padapter, u8
variable, u8 *val)
(pwrctl->wowlan_wake_reason != Rx_DeAuth)
) {
rtl8723b_set_FwJoinBssRpt_cmd(padapter,
RT_MEDIA_CONNECT);
- if (psta != NULL)
+ if (psta)
rtl8723b_set_FwMediaStatusRpt_cmd(padapter, RT_MEDIA_CONNECT, psta->mac_id);
}
#ifdef CONFIG_PNO_SUPPORT
--
2.7.4
[Patch v2 2/3] staging: rtl8723bs: hal: sdio_halinit: fix spaces preferred around that unary operator
This patch fixes below issues reported by checkpatch CHECK: spaces preferred around that '+' (ctx:VxV) CHECK: spaces preferred around that '<<' (ctx:VxV) CHECK: spaces preferred around that '|' (ctx:VxV) Signed-off-by: Hariprasad Kelam -- changes in v2: Send proper patch without corruption --- drivers/staging/rtl8723bs/hal/sdio_halinit.c | 90 ++-- 1 file changed, 45 insertions(+), 45 deletions(-) diff --git a/drivers/staging/rtl8723bs/hal/sdio_halinit.c b/drivers/staging/rtl8723bs/hal/sdio_halinit.c index 4db3211..5c7cff0 100644 --- a/drivers/staging/rtl8723bs/hal/sdio_halinit.c +++ b/drivers/staging/rtl8723bs/hal/sdio_halinit.c @@ -112,17 +112,17 @@ u8 _InitPowerOn_8723BS(struct adapter *padapter) /* all of these MUST be configured before power on */ #ifdef CONFIG_EXT_CLK /* Use external crystal(XTAL) */ - value8 = rtw_read8(padapter, REG_PAD_CTRL1_8723B+2); + value8 = rtw_read8(padapter, REG_PAD_CTRL1_8723B + 2); value8 |= BIT(7); - rtw_write8(padapter, REG_PAD_CTRL1_8723B+2, value8); + rtw_write8(padapter, REG_PAD_CTRL1_8723B + 2, value8); /* CLK_REQ High active or Low Active */ /* Request GPIO polarity: */ /* 0: low active */ /* 1: high active */ - value8 = rtw_read8(padapter, REG_MULTI_FUNC_CTRL+1); + value8 = rtw_read8(padapter, REG_MULTI_FUNC_CTRL + 1); value8 |= BIT(5); - rtw_write8(padapter, REG_MULTI_FUNC_CTRL+1, value8); + rtw_write8(padapter, REG_MULTI_FUNC_CTRL + 1, value8); #endif /* CONFIG_EXT_CLK */ /* only cmd52 can be used before power on(card enable) */ @@ -137,12 +137,12 @@ u8 _InitPowerOn_8723BS(struct adapter *padapter) } /* Radio-Off Pin Trigger */ - value8 = rtw_read8(padapter, REG_GPIO_INTM+1); + value8 = rtw_read8(padapter, REG_GPIO_INTM + 1); value8 |= BIT(1); /* Enable falling edge triggering interrupt */ - rtw_write8(padapter, REG_GPIO_INTM+1, value8); - value8 = rtw_read8(padapter, REG_GPIO_IO_SEL_2+1); + rtw_write8(padapter, REG_GPIO_INTM + 1, value8); + value8 = rtw_read8(padapter, REG_GPIO_IO_SEL_2 + 1); value8 |= BIT(1); - rtw_write8(padapter, REG_GPIO_IO_SEL_2+1, value8); + rtw_write8(padapter, REG_GPIO_IO_SEL_2 + 1, value8); /* Enable power down and GPIO interrupt */ value16 = rtw_read16(padapter, REG_APS_FSMCO); @@ -203,13 +203,13 @@ static void _init_available_page_threshold(struct adapter *padapter, u8 numHQ, u u16 HQ_threshold, NQ_threshold, LQ_threshold; HQ_threshold = (numPubQ + numHQ + 1) >> 1; - HQ_threshold |= (HQ_threshold<<8); + HQ_threshold |= (HQ_threshold << 8); NQ_threshold = (numPubQ + numNQ + 1) >> 1; - NQ_threshold |= (NQ_threshold<<8); + NQ_threshold |= (NQ_threshold << 8); LQ_threshold = (numPubQ + numLQ + 1) >> 1; - LQ_threshold |= (LQ_threshold<<8); + LQ_threshold |= (LQ_threshold << 8); rtw_write16(padapter, 0x218, HQ_threshold); rtw_write16(padapter, 0x21A, NQ_threshold); @@ -271,7 +271,7 @@ static void _InitTxBufferBoundary(struct adapter *padapter) rtw_write8(padapter, REG_TXPKTBUF_MGQ_BDNY_8723B, txpktbuf_bndy); rtw_write8(padapter, REG_TXPKTBUF_WMAC_LBK_BF_HD_8723B, txpktbuf_bndy); rtw_write8(padapter, REG_TRXFF_BNDY, txpktbuf_bndy); - rtw_write8(padapter, REG_TDECTRL+1, txpktbuf_bndy); + rtw_write8(padapter, REG_TDECTRL + 1, txpktbuf_bndy); } static void _InitNormalChipRegPriority( @@ -569,7 +569,7 @@ static void HalRxAggr8723BSdio(struct adapter *padapter) valueDMAPageCount = 0x06; } - rtw_write8(padapter, REG_RXDMA_AGG_PG_TH+1, valueDMATimeout); + rtw_write8(padapter, REG_RXDMA_AGG_PG_TH + 1, valueDMATimeout); rtw_write8(padapter, REG_RXDMA_AGG_PG_TH, valueDMAPageCount); } @@ -588,8 +588,8 @@ static void sdio_AggSettingRxUpdate(struct adapter *padapter) rtw_write8(padapter, REG_TRXDMA_CTRL, valueDMA); valueRxAggCtrl |= RXDMA_AGG_MODE_EN; - valueRxAggCtrl |= ((aggBurstNum<<2) & 0x0C); - valueRxAggCtrl |= ((aggBurstSize<<4) & 0x30); + valueRxAggCtrl |= ((aggBurstNum << 2) & 0x0C); + valueRxAggCtrl |= ((aggBurstSize << 4) & 0x30); rtw_write8(padapter, REG_RXDMA_MODE_CTRL_8723B, valueRxAggCtrl);/* RxAggLowThresh = 4*1K */ } @@ -754,11 +754,11 @@ static u32 rtl8723bs_hal_init(struct adapter *padapter) rtw_hal_get_hwreg(padapter, HW_VAR_CPWM, &cpwm_orig); /* ser rpwm */ - val8 = rtw_read8(padapter, SDIO_LOCAL_BASE|SDIO_REG_HRPWM1); + val8 = rtw_read8(padapter, SDIO_LOCAL_BASE | SDIO_REG_HRPWM1); val8 &= 0x80; val8 += 0x80; val8 |= BIT(6); - rtw_write8(padapter, SDIO_LOCAL_BASE|SDIO_REG_HRPWM1, val8); + rt
[Patch v2 1/3] staging: rtl8723bs: hal: sdio_halinit: fix comparison to true/false is error prone
fix below issues reported by checkpatch
CHECK: Using comparison to false is error prone
CHECK: Using comparison to true is error prone
Signed-off-by: Hariprasad Kelam
changes in v2: send proper patch without corruption
---
drivers/staging/rtl8723bs/hal/sdio_halinit.c | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/drivers/staging/rtl8723bs/hal/sdio_halinit.c
b/drivers/staging/rtl8723bs/hal/sdio_halinit.c
index 3c65a9c..4db3211 100644
--- a/drivers/staging/rtl8723bs/hal/sdio_halinit.c
+++ b/drivers/staging/rtl8723bs/hal/sdio_halinit.c
@@ -26,7 +26,7 @@ static u8 CardEnable(struct adapter *padapter)
rtw_hal_get_hwreg(padapter, HW_VAR_APFM_ON_MAC, &bMacPwrCtrlOn);
- if (bMacPwrCtrlOn == false) {
+ if (!bMacPwrCtrlOn) {
/* RSV_CTRL 0x1C[7:0] = 0x00 */
/* unlock ISO/CLK/Power control register */
rtw_write8(padapter, REG_RSV_CTRL, 0x0);
@@ -127,7 +127,7 @@ u8 _InitPowerOn_8723BS(struct adapter *padapter)
/* only cmd52 can be used before power on(card enable) */
ret = CardEnable(padapter);
- if (ret == false) {
+ if (!ret) {
RT_TRACE(
_module_hci_hal_init_c_,
_drv_emerg_,
@@ -838,7 +838,7 @@ static u32 rtl8723bs_hal_init(struct adapter *padapter)
/* SIC_Init(padapter); */
- if (pwrctrlpriv->reg_rfoff == true)
+ if (pwrctrlpriv->reg_rfoff)
pwrctrlpriv->rf_pwrstate = rf_off;
/* 2010/08/09 MH We need to check if we need to turnon or off RF after
detecting */
@@ -1081,7 +1081,7 @@ static void CardDisableRTL8723BSdio(struct adapter
*padapter)
ret = false;
rtw_hal_set_hwreg(padapter, HW_VAR_APFM_ON_MAC, &bMacPwrCtrlOn);
ret = HalPwrSeqCmdParsing(padapter, PWR_CUT_ALL_MSK, PWR_FAB_ALL_MSK,
PWR_INTF_SDIO_MSK, rtl8723B_card_disable_flow);
- if (ret == false) {
+ if (!ret) {
DBG_8192C(KERN_ERR "%s: run CARD DISABLE flow fail!\n",
__func__);
}
}
@@ -1091,9 +1091,9 @@ static u32 rtl8723bs_hal_deinit(struct adapter *padapter)
struct dvobj_priv *psdpriv = padapter->dvobj;
struct debug_priv *pdbgpriv = &psdpriv->drv_dbg;
- if (padapter->hw_init_completed == true) {
- if (adapter_to_pwrctl(padapter)->bips_processing == true) {
- if (padapter->netif_up == true) {
+ if (padapter->hw_init_completed) {
+ if (adapter_to_pwrctl(padapter)->bips_processing) {
+ if (padapter->netif_up) {
int cnt = 0;
u8 val8 = 0;
@@ -1387,7 +1387,7 @@ static s32 _ReadAdapterInfo8723BS(struct adapter
*padapter)
RT_TRACE(_module_hci_hal_init_c_, _drv_info_,
("+_ReadAdapterInfo8723BS\n"));
/* before access eFuse, make sure card enable has been called */
- if (padapter->hw_init_completed == false)
+ if (!padapter->hw_init_completed)
_InitPowerOn_8723BS(padapter);
@@ -1404,7 +1404,7 @@ static s32 _ReadAdapterInfo8723BS(struct adapter
*padapter)
_ReadPROMContent(padapter);
_InitOtherVariable(padapter);
- if (padapter->hw_init_completed == false) {
+ if (!padapter->hw_init_completed) {
rtw_write8(padapter, 0x67, 0x00); /* for BT, Switch Ant
control to BT */
CardDisableRTL8723BSdio(padapter);/* for the power consumption
issue, wifi ko module is loaded during booting, but wifi GUI is off */
}
--
2.7.4
[PATCH -next] scsi: cxgb4i: remove set but not used variable 'ppmax'
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/scsi/cxgbi/cxgb4i/cxgb4i.c: In function 'cxgb4i_ddp_init':
drivers/scsi/cxgbi/cxgb4i/cxgb4i.c:2072:15: warning:
variable 'ppmax' set but not used [-Wunused-but-set-variable]
It's not used since commit a248384e6420 ("cxgb4/libcxgb/cxgb4i/cxgbit:
enable eDRAM page pods for iSCSI")
Signed-off-by: YueHaibing
---
drivers/scsi/cxgbi/cxgb4i/cxgb4i.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/scsi/cxgbi/cxgb4i/cxgb4i.c
b/drivers/scsi/cxgbi/cxgb4i/cxgb4i.c
index 66d6e1f4b3c3..0fbb4edc4161 100644
--- a/drivers/scsi/cxgbi/cxgb4i/cxgb4i.c
+++ b/drivers/scsi/cxgbi/cxgb4i/cxgb4i.c
@@ -2069,7 +2069,6 @@ static int cxgb4i_ddp_init(struct cxgbi_device *cdev)
struct cxgb4_lld_info *lldi = cxgbi_cdev_priv(cdev);
struct net_device *ndev = cdev->ports[0];
struct cxgbi_tag_format tformat;
- unsigned int ppmax;
int i, err;
if (!lldi->vr->iscsi.size) {
@@ -2078,7 +2077,6 @@ static int cxgb4i_ddp_init(struct cxgbi_device *cdev)
}
cdev->flags |= CXGBI_FLAG_USE_PPOD_OFLDQ;
- ppmax = lldi->vr->iscsi.size >> PPOD_SIZE_SHIFT;
memset(&tformat, 0, sizeof(struct cxgbi_tag_format));
for (i = 0; i < 4; i++)
Re: [PATCH 4.14 00/81] 4.14.126-stable review
On 6/13/19 2:32 AM, Greg Kroah-Hartman wrote: This is the start of the stable review cycle for the 4.14.126 release. There are 81 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. Responses should be made by Sat 15 Jun 2019 07:54:51 AM UTC. Anything received after that time might be too late. The whole patch series can be found in one patch at: https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.14.126-rc1.gz or in the git tree and branch at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.14.y and the diffstat can be found below. thanks, greg k-h Compiled and booted on my test system. No dmesg regressions. thanks, -- Shuah
Re: [PATCH 4.19 000/118] 4.19.51-stable review
On 6/13/19 2:32 AM, Greg Kroah-Hartman wrote: This is the start of the stable review cycle for the 4.19.51 release. There are 118 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. Responses should be made by Sat 15 Jun 2019 07:54:44 AM UTC. Anything received after that time might be too late. The whole patch series can be found in one patch at: https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.19.51-rc1.gz or in the git tree and branch at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.19.y and the diffstat can be found below. thanks, greg k-h Compiled and booted on my test system. No dmesg regressions. thanks, -- Shuah
[PATCH -next] cxgbit: remove set but not used variable 'ppmax'
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/target/iscsi/cxgbit/cxgbit_ddp.c: In function 'cxgbit_ddp_init':
drivers/target/iscsi/cxgbit/cxgbit_ddp.c:303:15: warning:
variable 'ppmax' set but not used [-Wunused-but-set-variable]
It's not used since commit a248384e6420 ("cxgb4/libcxgb/cxgb4i/cxgbit:
enable eDRAM page pods for iSCSI")
Signed-off-by: YueHaibing
---
drivers/target/iscsi/cxgbit/cxgbit_ddp.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/target/iscsi/cxgbit/cxgbit_ddp.c
b/drivers/target/iscsi/cxgbit/cxgbit_ddp.c
index 1443ef045a5f..fe1be5feaf21 100644
--- a/drivers/target/iscsi/cxgbit/cxgbit_ddp.c
+++ b/drivers/target/iscsi/cxgbit/cxgbit_ddp.c
@@ -300,7 +300,6 @@ int cxgbit_ddp_init(struct cxgbit_device *cdev)
struct cxgb4_lld_info *lldi = &cdev->lldi;
struct net_device *ndev = cdev->lldi.ports[0];
struct cxgbi_tag_format tformat;
- unsigned int ppmax;
int ret, i;
if (!lldi->vr->iscsi.size) {
@@ -308,8 +307,6 @@ int cxgbit_ddp_init(struct cxgbit_device *cdev)
return -EACCES;
}
- ppmax = lldi->vr->iscsi.size >> PPOD_SIZE_SHIFT;
-
memset(&tformat, 0, sizeof(struct cxgbi_tag_format));
for (i = 0; i < 4; i++)
tformat.pgsz_order[i] = (lldi->iscsi_pgsz_order >> (i << 3))
Re: [PATCH v3] kasan: add memory corruption identification for software tag-based mode
On Fri, 2019-06-14 at 01:46 +0800, Walter Wu wrote:
> On Thu, 2019-06-13 at 15:27 +0300, Andrey Ryabinin wrote:
> >
> > On 6/13/19 11:13 AM, Walter Wu wrote:
> > > This patch adds memory corruption identification at bug report for
> > > software tag-based mode, the report show whether it is "use-after-free"
> > > or "out-of-bound" error instead of "invalid-access" error.This will make
> > > it easier for programmers to see the memory corruption problem.
> > >
> > > Now we extend the quarantine to support both generic and tag-based kasan.
> > > For tag-based kasan, the quarantine stores only freed object information
> > > to check if an object is freed recently. When tag-based kasan reports an
> > > error, we can check if the tagged addr is in the quarantine and make a
> > > good guess if the object is more like "use-after-free" or "out-of-bound".
> > >
> >
> >
> > We already have all the information and don't need the quarantine to make
> > such guess.
> > Basically if shadow of the first byte of object has the same tag as tag in
> > pointer than it's out-of-bounds,
> > otherwise it's use-after-free.
> >
> > In pseudo-code it's something like this:
> >
> > u8 object_tag = *(u8 *)kasan_mem_to_shadow(nearest_object(cacche, page,
> > access_addr));
> >
> > if (access_addr_tag == object_tag && object_tag != KASAN_TAG_INVALID)
> > // out-of-bounds
> > else
> > // use-after-free
>
> Thanks your explanation.
> I see, we can use it to decide corruption type.
> But some use-after-free issues, it may not have accurate free-backtrace.
> Unfortunately in that situation, free-backtrace is the most important.
> please see below example
>
> In generic KASAN, it gets accurate free-backrace(ptr1).
> In tag-based KASAN, it gets wrong free-backtrace(ptr2). It will make
> programmer misjudge, so they may not believe tag-based KASAN.
> So We provide this patch, we hope tag-based KASAN bug report is the same
> accurate with generic KASAN.
>
> ---
> ptr1 = kmalloc(size, GFP_KERNEL);
> ptr1_free(ptr1);
>
> ptr2 = kmalloc(size, GFP_KERNEL);
> ptr2_free(ptr2);
>
> ptr1[size] = 'x'; //corruption here
>
>
> static noinline void ptr1_free(char* ptr)
> {
> kfree(ptr);
> }
> static noinline void ptr2_free(char* ptr)
> {
> kfree(ptr);
> }
> ---
>
We think of another question about deciding by that shadow of the first
byte.
In tag-based KASAN, it is immediately released after calling kfree(), so
the slub is easy to be used by another pointer, then it will change
shadow memory to the tag of new pointer, it will not be the
KASAN_TAG_INVALID, so there are many false negative cases, especially in
small size allocation.
Our patch is to solve those problems. so please consider it, thanks.
Re: [PATCH RFC 00/10] RDMA/FS DAX truncate proposal
On Fri, Jun 14, 2019 at 12:09:21PM +1000, Dave Chinner wrote: > On Thu, Jun 13, 2019 at 08:45:30PM -0300, Jason Gunthorpe wrote: > > On Thu, Jun 13, 2019 at 02:13:21PM -0700, Ira Weiny wrote: > > > On Thu, Jun 13, 2019 at 08:27:55AM -0700, Matthew Wilcox wrote: > > > > On Thu, Jun 13, 2019 at 10:25:55AM +1000, Dave Chinner wrote: > > > > > e.g. Process A has an exclusive layout lease on file F. It does an > > > > > IO to file F. The filesystem IO path checks that Process A owns the > > > > > lease on the file and so skips straight through layout breaking > > > > > because it owns the lease and is allowed to modify the layout. It > > > > > then takes the inode metadata locks to allocate new space and write > > > > > new data. > > > > > > > > > > Process B now tries to write to file F. The FS checks whether > > > > > Process B owns a layout lease on file F. It doesn't, so then it > > > > > tries to break the layout lease so the IO can proceed. The layout > > > > > breaking code sees that process A has an exclusive layout lease > > > > > granted, and so returns -ETXTBSY to process B - it is not allowed to > > > > > break the lease and so the IO fails with -ETXTBSY. > > > > > > > > This description doesn't match the behaviour that RDMA wants either. > > > > Even if Process A has a lease on the file, an IO from Process A which > > > > results in blocks being freed from the file is going to result in the > > > > RDMA device being able to write to blocks which are now freed (and > > > > potentially reallocated to another file). > > > > > > I don't understand why this would not work for RDMA? As long as the > > > layout > > > does not change the page pins can remain in place. > > > > Because process A had a layout lease (and presumably a MR) and the > > layout was still modified in way that invalidates the RDMA MR. > > The lease holder is allowed to modify the mapping it has a lease > over. That's necessary so lease holders can write data into > unallocated space in the file. The lease is there to prevent third > parties from modifying the layout without the lease holder being > informed and taking appropriate action to allow that 3rd party > modification to occur. > > If the lease holder modifies the mapping in a way that causes it's > own internal state to screw up, then that's a bug in the lease > holder application. Sounds like the lease semantics aren't the right ones for the longterm GUP users then. The point of the longterm GUP is so the pages can be written to, and if the filesystem is going to move the pages around when they're written to, that just won't work.
Re: pagecache locking (was: bcachefs status update) merged)
On Thu, Jun 13, 2019 at 1:56 PM Dave Chinner wrote: > > That said, the page cache is still far, far slower than direct IO, Bullshit, Dave. You've made that claim before, and it's been complete bullshit before too, and I've called you out on it then too. Why do you continue to make this obviously garbage argument? The key word in the "page cache" name is "cache". Caches work, Dave. Anybody who thinks caches don't work is incompetent. 99% of all filesystem accesses are cached, and they never do any IO at all, and the page cache handles them beautifully. When you say that the page cache is slower than direct IO, it's because you don't even see or care about the *fast* case. You only get involved once there is actual IO to be done. So you're making that statement without taking into account all the cases that you don't see, and that you don't care about, because the page cache has already handled them for you, and done so much better than DIO can do or ever _will_ do. Is direct IO faster when you *know* it's not cached, and shouldn't be cached? Sure. But that/s actually quite rare. How often do you use non-temporal stores when you do non-IO programming? Approximately never, perhaps? Because caches work. And no, SSD's haven't made caches irrelevant. Not doing IO at all is still orders of magnitude faster than doing IO. And it's not clear nvdimms will either. So stop with the stupid and dishonest argument already, where you ignore the effects of caching. Linus
Re: [PATCH 7/9] x86/unwind/orc: Fall back to using frame pointers for generated code
On Thu, Jun 13, 2019 at 08:58:48PM -0500, Josh Poimboeuf wrote:
> On Thu, Jun 13, 2019 at 06:42:45PM -0700, Alexei Starovoitov wrote:
> > On Thu, Jun 13, 2019 at 08:30:51PM -0500, Josh Poimboeuf wrote:
> > > On Thu, Jun 13, 2019 at 03:00:55PM -0700, Alexei Starovoitov wrote:
> > > > > @@ -392,8 +402,16 @@ bool unwind_next_frame(struct unwind_state
> > > > > *state)
> > > > >* calls and calls to noreturn functions.
> > > > >*/
> > > > > orc = orc_find(state->signal ? state->ip : state->ip - 1);
> > > > > - if (!orc)
> > > > > - goto err;
> > > > > + if (!orc) {
> > > > > + /*
> > > > > + * As a fallback, try to assume this code uses a frame
> > > > > pointer.
> > > > > + * This is useful for generated code, like BPF, which
> > > > > ORC
> > > > > + * doesn't know about. This is just a guess, so the
> > > > > rest of
> > > > > + * the unwind is no longer considered reliable.
> > > > > + */
> > > > > + orc = &orc_fp_entry;
> > > > > + state->error = true;
> > > >
> > > > That seems fragile.
> > >
> > > I don't think so. The unwinder has sanity checks to make sure it
> > > doesn't go off the rails. And it works just fine. The beauty is that
> > > it should work for all generated code (not just BPF).
> > >
> > > > Can't we populate orc_unwind tables after JIT ?
> > >
> > > As I mentioned it would introduce a lot more complexity. For each JIT
> > > function, BPF would have to tell ORC the following:
> > >
> > > - where the BPF function lives
> > > - how big the stack frame is
> > > - where RBP and other callee-saved regs are on the stack
> >
> > that sounds like straightforward addition that ORC should have anyway.
> > right now we're not using rbp in the jit-ed code,
> > but one day we definitely will.
> > Same goes for r12. It's reserved right now for 'strategic use'.
> > We've been thinking to add another register to bpf isa.
> > It will map to r12 on x86. arm64 and others have plenty of regs to use.
> > The programs are getting bigger and register spill/fill starting to
> > become a performance concern. Extra register will give us more room.
>
> With CONFIG_FRAME_POINTER, RBP isn't available. If you look at all the
> code in the entire kernel you'll notice that BPF JIT is pretty much the
> only one still clobbering it.
Hm. If you wanted to eventually use R12 for other purposes, there might
be a way to abstract BPF_REG_FP such that it doesn't actually need a
dedicated register. The BPF program's frame pointer will always be a
certain constant offset away from RBP (real frame pointer), so accesses
to BPF_REG_FP could still be based on RBP, but with an offset added to
it.
--
Josh
[PATCH] staging: rtl8723bs: Resolve checkpatch error "that open brace { should be on the previous line" in the rtl8723bs driver
Cleaned up the code from the following files to get rid of
check patch error "that open brace { should be on the previous line"
drivers/staging/rtl8723bs/os_dep/mlme_linux.c
drivers/staging/rtl8723bs/os_dep/recv_linux.c
drivers/staging/rtl8723bs/os_dep/rtw_proc.c
drivers/staging/rtl8723bs/os_dep/sdio_intf.c
drivers/staging/rtl8723bs/os_dep/sdio_ops_linux.c
Signed-off-by: Shobhit Kukreti
---
drivers/staging/rtl8723bs/os_dep/mlme_linux.c | 14 ++---
drivers/staging/rtl8723bs/os_dep/recv_linux.c | 76 ---
drivers/staging/rtl8723bs/os_dep/rtw_proc.c | 6 +-
drivers/staging/rtl8723bs/os_dep/sdio_intf.c | 15 ++---
drivers/staging/rtl8723bs/os_dep/sdio_ops_linux.c | 24 +++
5 files changed, 47 insertions(+), 88 deletions(-)
diff --git a/drivers/staging/rtl8723bs/os_dep/mlme_linux.c
b/drivers/staging/rtl8723bs/os_dep/mlme_linux.c
index aa2499f..6799ed4 100644
--- a/drivers/staging/rtl8723bs/os_dep/mlme_linux.c
+++ b/drivers/staging/rtl8723bs/os_dep/mlme_linux.c
@@ -46,8 +46,7 @@ void rtw_os_indicate_connect(struct adapter *adapter)
struct mlme_priv *pmlmepriv = &(adapter->mlmepriv);
if ((check_fwstate(pmlmepriv, WIFI_ADHOC_MASTER_STATE) == true) ||
- (check_fwstate(pmlmepriv, WIFI_ADHOC_STATE) == true))
- {
+ (check_fwstate(pmlmepriv, WIFI_ADHOC_STATE) == true)) {
rtw_cfg80211_ibss_indicate_connect(adapter);
}
else
@@ -77,8 +76,8 @@ void rtw_reset_securitypriv(struct adapter *adapter)
spin_lock_bh(&adapter->security_key_mutex);
- if (adapter->securitypriv.dot11AuthAlgrthm == dot11AuthAlgrthm_8021X)/*
802.1x */
- {
+ if (adapter->securitypriv.dot11AuthAlgrthm == dot11AuthAlgrthm_8021X) {
/* 802.1x */
+
/* Added by Albert 2009/02/18 */
/* We have to backup the PMK information for WiFi PMK Caching
test item. */
/* */
@@ -106,8 +105,8 @@ void rtw_reset_securitypriv(struct adapter *adapter)
adapter->securitypriv.ndisencryptstatus = Ndis802_11WEPDisabled;
}
- else /* reset values in securitypriv */
- {
+ else { /* reset values in securitypriv */
+
/* if (adapter->mlmepriv.fw_state & WIFI_STATION_STATE) */
/* */
struct security_priv *psec_priv = &adapter->securitypriv;
@@ -150,8 +149,7 @@ void rtw_report_sec_ie(struct adapter *adapter, u8
authmode, u8 *sec_ie)
RT_TRACE(_module_mlme_osdep_c_, _drv_info_, ("+rtw_report_sec_ie,
authmode =%d\n", authmode));
buff = NULL;
- if (authmode == _WPA_IE_ID_)
- {
+ if (authmode == _WPA_IE_ID_) {
RT_TRACE(_module_mlme_osdep_c_, _drv_info_,
("rtw_report_sec_ie, authmode =%d\n", authmode));
buff = rtw_zmalloc(IW_CUSTOM_MAX);
diff --git a/drivers/staging/rtl8723bs/os_dep/recv_linux.c
b/drivers/staging/rtl8723bs/os_dep/recv_linux.c
index 3fe9c22..44a8920 100644
--- a/drivers/staging/rtl8723bs/os_dep/recv_linux.c
+++ b/drivers/staging/rtl8723bs/os_dep/recv_linux.c
@@ -12,8 +12,7 @@
void rtw_os_free_recvframe(union recv_frame *precvframe)
{
- if (precvframe->u.hdr.pkt)
- {
+ if (precvframe->u.hdr.pkt) {
dev_kfree_skb_any(precvframe->u.hdr.pkt);/* free skb by driver
*/
precvframe->u.hdr.pkt = NULL;
@@ -34,10 +33,8 @@ void rtw_os_recv_resource_free(struct recv_priv *precvpriv)
precvframe = (union recv_frame*) precvpriv->precv_frame_buf;
- for (i = 0; i < NR_RECVFRAME; i++)
- {
- if (precvframe->u.hdr.pkt)
- {
+ for (i = 0; i < NR_RECVFRAME; i++) {
+ if (precvframe->u.hdr.pkt) {
dev_kfree_skb_any(precvframe->u.hdr.pkt);/* free skb by
driver */
precvframe->u.hdr.pkt = NULL;
}
@@ -48,8 +45,7 @@ void rtw_os_recv_resource_free(struct recv_priv *precvpriv)
/* free os related resource in struct recv_buf */
void rtw_os_recvbuf_resource_free(struct adapter *padapter, struct recv_buf
*precvbuf)
{
- if (precvbuf->pskb)
- {
+ if (precvbuf->pskb) {
dev_kfree_skb_any(precvbuf->pskb);
}
}
@@ -63,22 +59,18 @@ _pkt *rtw_os_alloc_msdu_pkt(union recv_frame *prframe, u16
nSubframe_Length, u8
pattrib = &prframe->u.hdr.attrib;
sub_skb = rtw_skb_alloc(nSubframe_Length + 12);
- if (sub_skb)
- {
+ if (sub_skb) {
skb_reserve(sub_skb, 12);
skb_put_data(sub_skb, (pdata + ETH_HLEN), nSubframe_Length);
}
- else
- {
+ else {
sub_skb = rtw_skb_clone(prframe->u.hdr.pkt);
- if (sub_skb)
- {
+ if (sub_skb) {
sub_skb->data = pdata + ETH_HLEN;
sub_skb->len = nSubframe_Length;
skb_set_ta
Re: [PATCH RFC 00/10] RDMA/FS DAX truncate proposal
On Thu, Jun 13, 2019 at 08:45:30PM -0300, Jason Gunthorpe wrote: > On Thu, Jun 13, 2019 at 02:13:21PM -0700, Ira Weiny wrote: > > On Thu, Jun 13, 2019 at 08:27:55AM -0700, Matthew Wilcox wrote: > > > On Thu, Jun 13, 2019 at 10:25:55AM +1000, Dave Chinner wrote: > > > > e.g. Process A has an exclusive layout lease on file F. It does an > > > > IO to file F. The filesystem IO path checks that Process A owns the > > > > lease on the file and so skips straight through layout breaking > > > > because it owns the lease and is allowed to modify the layout. It > > > > then takes the inode metadata locks to allocate new space and write > > > > new data. > > > > > > > > Process B now tries to write to file F. The FS checks whether > > > > Process B owns a layout lease on file F. It doesn't, so then it > > > > tries to break the layout lease so the IO can proceed. The layout > > > > breaking code sees that process A has an exclusive layout lease > > > > granted, and so returns -ETXTBSY to process B - it is not allowed to > > > > break the lease and so the IO fails with -ETXTBSY. > > > > > > This description doesn't match the behaviour that RDMA wants either. > > > Even if Process A has a lease on the file, an IO from Process A which > > > results in blocks being freed from the file is going to result in the > > > RDMA device being able to write to blocks which are now freed (and > > > potentially reallocated to another file). > > > > I don't understand why this would not work for RDMA? As long as the layout > > does not change the page pins can remain in place. > > Because process A had a layout lease (and presumably a MR) and the > layout was still modified in way that invalidates the RDMA MR. The lease holder is allowed to modify the mapping it has a lease over. That's necessary so lease holders can write data into unallocated space in the file. The lease is there to prevent third parties from modifying the layout without the lease holder being informed and taking appropriate action to allow that 3rd party modification to occur. If the lease holder modifies the mapping in a way that causes it's own internal state to screw up, then that's a bug in the lease holder application. Cheers, Dave. -- Dave Chinner da...@fromorbit.com
Re: [PATCH] drivers/acpi: Turn off power resources while entering S5
On Fri, May 31, 2019 at 3:13 AM Rafael J. Wysocki wrote: > > On Wednesday, April 24, 2019 1:39:04 AM CEST Furquan Shaikh wrote: > > During boot-up, ACPI bus scan enables all power resources > > so that respective device drivers can talk to their device. This causes acpi > > ref_count for the power resource to be incremented to 1. When system > > suspends (S3/S0ix) or hibernates(S4), DPM is responsible for calling > > power off on all power resources whose ref_count is 1 i.e. no other > > user of this power resource and thus resulting in _OFF routine being > > called for it. > > > > However, in case of poweroff, DPM is not involved and so the power > > resources are left on when the system is entering S5. This results in > > the violation of power down sequencing for certain devices > > e.g. touchscreen or digitizer I2C devices. > > I'm not sure I can follow you here. Any details? On the platforms that I am currently testing, I noticed that ACPI _OFF routine does not get called for the touchscreen I2C device. Since the device has power-on and power-down sequencing requirements, not calling _OFF routine results in its power-down sequence being violated when the system is entering S5. On further debug, I identified that this is true for all the ACPI devices on the platform i.e. _OFF routine does not get called when entering S5. In case of S3/S0ix, I see that the _OFF ACPI routine gets called using the following code flow: pm_suspend() ... --> suspend_devices_and_enter() ... --> dpm_suspend() for every device ... --> acpi_power_off() for every ACPI device On the other hand, in case of S5, _OFF routine never gets called because of the following code flow: kernel_poweroff() ... --> acpi_power_off_prepare() --> acpi_sleep_prepare() --> acpi_disable_all_gpes() --> acpi_os_wait_events_complete() ... --> machine_power_off() In this sequence acpi_power_off is not executed for the devices. > > > In order to ensure that the > > power down sequencing does the right thing, it is necessary for ACPI > > to disable all power resources while preparing for S5. > > Well, I would say that this is not just about power resources. ACPI PM > methods should be > invoked for the devices as well, so generally there should be subject to the > normal PM > during S5 transitions. Agree. > > Generally speaking, S5 should follow the code flow of the last phase of > hibernation. By last phase of hibernation, do you mean HIBERNATION_SHUTDOWN? My platforms do not support hibernation, so I can't really test it, but from my reading of the code sequence below: hibernate() ... --> power_down() ... It seems the "last phase of hibernation" i.e. HIBERNATION_SHUTDOWN is also going to have the same issue i.e. it will not lead to calling the ACPI _OFF routine. HIBERNATION_PLATFORM which calls hibernation_platform_enter() actually makes calls to dpm_suspend() and dpm_suspend_end() which will end up calling acpi_power_off. I'm sure I'm missing something here as I'm not too familiar with this code. Can you please help me by pointing me to the code sequence you expect should result in getting the _OFF ACPI routine called for: (1) Hibernation (2) Shutdown (S5) Many Thanks! > > > This change updates the function acpi_turn_off_unused_power_resources > > to accept a parameter acpi_system_state, This function turns off power > > resources according to the targeted system ACPI state: > > 1. For S0: Unused power resources are turned off i.e. power resources > > whose ref_count is already 0. > > 2. For S5: ref_count is decremented first to undo the increment > > performed during ACPI bus scan and then power resources with ref_count > > 0 are turned off. > > 3. All other suspend/hibernate states: No action is required since DPM > > takes care of turning off power resources. > > > > This change should not affect the wake capable devices since: > > 1. If wake capable devices are enabled before this call, their > > refcount should be greater than 1. Thus, they won't be turned off. > > 2. If wake capable devices are not enabled yet when this call is made, > > they would eventually get turned on by call to > > acpi_enable_wakeup_devices. > > Quite frankly, this looks like a hack causing a particular platform to behave > as expected, but it very well may not be applicable to other platforms. > > > Signed-off-by: Furquan Shaikh > > --- > > drivers/acpi/power.c | 47 ++-- > > drivers/acpi/sleep.c | 5 - > > drivers/acpi/sleep.h | 2 +- > > 3 files changed, 46 insertions(+), 8 deletions(-) > > > > diff --git a/drivers/acpi/power.c b/drivers/acpi/power.c > > index 665e93ca0b40f..945db762861a3 100644 > > --- a/drivers/acpi/power.c > > +++ b/drivers/acpi/power.c > > @@ -889,10 +889,42 @@ void acpi_resume_power_resources(void) > > > > mutex_unlock(&power_resource_list_lock); > > } >
Re: [PATCH 7/9] x86/unwind/orc: Fall back to using frame pointers for generated code
On Thu, Jun 13, 2019 at 06:42:45PM -0700, Alexei Starovoitov wrote:
> On Thu, Jun 13, 2019 at 08:30:51PM -0500, Josh Poimboeuf wrote:
> > On Thu, Jun 13, 2019 at 03:00:55PM -0700, Alexei Starovoitov wrote:
> > > > @@ -392,8 +402,16 @@ bool unwind_next_frame(struct unwind_state *state)
> > > > * calls and calls to noreturn functions.
> > > > */
> > > > orc = orc_find(state->signal ? state->ip : state->ip - 1);
> > > > - if (!orc)
> > > > - goto err;
> > > > + if (!orc) {
> > > > + /*
> > > > +* As a fallback, try to assume this code uses a frame
> > > > pointer.
> > > > +* This is useful for generated code, like BPF, which
> > > > ORC
> > > > +* doesn't know about. This is just a guess, so the
> > > > rest of
> > > > +* the unwind is no longer considered reliable.
> > > > +*/
> > > > + orc = &orc_fp_entry;
> > > > + state->error = true;
> > >
> > > That seems fragile.
> >
> > I don't think so. The unwinder has sanity checks to make sure it
> > doesn't go off the rails. And it works just fine. The beauty is that
> > it should work for all generated code (not just BPF).
> >
> > > Can't we populate orc_unwind tables after JIT ?
> >
> > As I mentioned it would introduce a lot more complexity. For each JIT
> > function, BPF would have to tell ORC the following:
> >
> > - where the BPF function lives
> > - how big the stack frame is
> > - where RBP and other callee-saved regs are on the stack
>
> that sounds like straightforward addition that ORC should have anyway.
> right now we're not using rbp in the jit-ed code,
> but one day we definitely will.
> Same goes for r12. It's reserved right now for 'strategic use'.
> We've been thinking to add another register to bpf isa.
> It will map to r12 on x86. arm64 and others have plenty of regs to use.
> The programs are getting bigger and register spill/fill starting to
> become a performance concern. Extra register will give us more room.
With CONFIG_FRAME_POINTER, RBP isn't available. If you look at all the
code in the entire kernel you'll notice that BPF JIT is pretty much the
only one still clobbering it.
--
Josh
Re: [PATCH 6/9] x86/bpf: Fix JIT frame pointer usage
On Thu, Jun 13, 2019 at 06:39:05PM -0700, Alexei Starovoitov wrote:
> On Thu, Jun 13, 2019 at 08:22:48PM -0500, Josh Poimboeuf wrote:
> > On Thu, Jun 13, 2019 at 02:58:09PM -0700, Alexei Starovoitov wrote:
> > > On Thu, Jun 13, 2019 at 08:21:03AM -0500, Josh Poimboeuf wrote:
> > > > The BPF JIT code clobbers RBP. This breaks frame pointer convention and
> > > > thus prevents the FP unwinder from unwinding through JIT generated code.
> > > >
> > > > RBP is currently used as the BPF stack frame pointer register. The
> > > > actual register used is opaque to the user, as long as it's a
> > > > callee-saved register. Change it to use R12 instead.
> > > >
> > > > Fixes: d15d356887e7 ("perf/x86: Make perf callchains work without
> > > > CONFIG_FRAME_POINTER")
> > > > Reported-by: Song Liu
> > > > Signed-off-by: Josh Poimboeuf
> > > > ---
> > > > arch/x86/net/bpf_jit_comp.c | 43 +
> > > > 1 file changed, 25 insertions(+), 18 deletions(-)
> > > >
> > > > diff --git a/arch/x86/net/bpf_jit_comp.c b/arch/x86/net/bpf_jit_comp.c
> > > > index e649f977f8e1..bb1968fea50a 100644
> > > > --- a/arch/x86/net/bpf_jit_comp.c
> > > > +++ b/arch/x86/net/bpf_jit_comp.c
> > > > @@ -100,9 +100,8 @@ static int bpf_size_to_x86_bytes(int bpf_size)
> > > > /*
> > > > * The following table maps BPF registers to x86-64 registers.
> > > > *
> > > > - * x86-64 register R12 is unused, since if used as base address
> > > > - * register in load/store instructions, it always needs an
> > > > - * extra byte of encoding and is callee saved.
> > > > + * RBP isn't used; it needs to be preserved to allow the unwinder to
> > > > move
> > > > + * through generated code stacks.
> > >
> > > Extra register save/restore is kinda annoying just to fix ORC.
> >
> > It's not just for the ORC unwinder. It also fixes the frame pointer
> > unwinder (see above commit msg). And it's standard frame pointer
> > practice to not clobber RBP.
>
> not true.
> generated JITed code has no issues with regular stack unwinder.
> it breaks down under ORC only.
>
> > > Also every stack access from bpf prog will be encoded via r12 and consume
> > > extra byte of encoding. I really don't like this approach.
> >
> > Do you have another callee-saved register you'd prefer to use as the
> > stack pointer?
>
> RBP must be used.
>
> > > Can you teach ORC to understand JIT-ed frames instead?
> >
> > We could, but it would add a lot more complexity than this. And anyway,
> > the frame pointer unwinder would still be broken.
>
> I disagree. See above. Only ORC is broken. Hence ORC should be fixed.
You're clobbering RBP. Frame pointer unwinding is broken. Period.
--
Josh
Re: [PATCH 2/9] objtool: Fix ORC unwinding in non-JIT BPF generated code
On Thu, Jun 13, 2019 at 06:37:21PM -0700, Alexei Starovoitov wrote:
> On Thu, Jun 13, 2019 at 08:20:30PM -0500, Josh Poimboeuf wrote:
> > On Thu, Jun 13, 2019 at 01:57:11PM -0700, Alexei Starovoitov wrote:
> > > On Thu, Jun 13, 2019 at 08:20:59AM -0500, Josh Poimboeuf wrote:
> > > > Objtool currently ignores ___bpf_prog_run() because it doesn't
> > > > understand the jump table. This results in the ORC unwinder not being
> > > > able to unwind through non-JIT BPF code.
> > > >
> > > > Luckily, the BPF jump table resembles a GCC switch jump table, which
> > > > objtool already knows how to read.
> > > >
> > > > Add generic support for reading any static local jump table array named
> > > > "jump_table", and rename the BPF variable accordingly, so objtool can
> > > > generate ORC data for ___bpf_prog_run().
> > > >
> > > > Fixes: d15d356887e7 ("perf/x86: Make perf callchains work without
> > > > CONFIG_FRAME_POINTER")
> > > > Reported-by: Song Liu
> > > > Signed-off-by: Josh Poimboeuf
> > > > ---
> > > > kernel/bpf/core.c | 5 ++---
> > > > tools/objtool/check.c | 16 ++--
> > > > 2 files changed, 16 insertions(+), 5 deletions(-)
> > > >
> > > > diff --git a/kernel/bpf/core.c b/kernel/bpf/core.c
> > > > index 7c473f208a10..aa546ef7dbdc 100644
> > > > --- a/kernel/bpf/core.c
> > > > +++ b/kernel/bpf/core.c
> > > > @@ -1299,7 +1299,7 @@ static u64 ___bpf_prog_run(u64 *regs, const
> > > > struct bpf_insn *insn, u64 *stack)
> > > > {
> > > > #define BPF_INSN_2_LBL(x, y)[BPF_##x | BPF_##y] = &&x##_##y
> > > > #define BPF_INSN_3_LBL(x, y, z) [BPF_##x | BPF_##y | BPF_##z] =
> > > > &&x##_##y##_##z
> > > > - static const void *jumptable[256] = {
> > > > + static const void *jump_table[256] = {
> > >
> > > Nack to the change like above
> >
> > "jump table" is two words, so does it not make sense to separate them
> > with an underscore for readability?
> >
> > I created a generic feature in objtool for this so that other code can
> > also use it. So a generic name (and typical Linux naming convention --
> > separating words with an underscore) makes sense here.
> >
> > > and to patches 8 and 9.
> >
> > Well, it's your code, but ... can I ask why? AT&T syntax is the
> > standard for Linux, which is in fact the OS we are developing for.
> >
> > It makes the code extra confusing for it to be annotated differently
> > than all other Linux asm code. And due to the inherent complexity of
> > generating code at runtime, I'd think we'd want to make the code as
> > readable as possible, for as many people as possible (i.e. other Linux
> > developers).
>
> imo your changes make it less readable.
How does introducing an underscore between two words make them less
readable?
> please do not randomly change names and style based on your own preferences.
These are Linux standards, not my own preferences.
> dst=src
> mov(dst,src)
> memcpy(dst,src)
> if people want to have more bugs in assembler code. it's their call.
> bpf_jit_comp.c is C code. dest is on the left.
So you don't like the ordering of the src,dst function arguments? Ok.
But what do you think about the AT&T syntax comments?
--
Josh
Re: [PATCH 7/9] x86/unwind/orc: Fall back to using frame pointers for generated code
On Thu, Jun 13, 2019 at 08:30:51PM -0500, Josh Poimboeuf wrote:
> On Thu, Jun 13, 2019 at 03:00:55PM -0700, Alexei Starovoitov wrote:
> > > @@ -392,8 +402,16 @@ bool unwind_next_frame(struct unwind_state *state)
> > >* calls and calls to noreturn functions.
> > >*/
> > > orc = orc_find(state->signal ? state->ip : state->ip - 1);
> > > - if (!orc)
> > > - goto err;
> > > + if (!orc) {
> > > + /*
> > > + * As a fallback, try to assume this code uses a frame pointer.
> > > + * This is useful for generated code, like BPF, which ORC
> > > + * doesn't know about. This is just a guess, so the rest of
> > > + * the unwind is no longer considered reliable.
> > > + */
> > > + orc = &orc_fp_entry;
> > > + state->error = true;
> >
> > That seems fragile.
>
> I don't think so. The unwinder has sanity checks to make sure it
> doesn't go off the rails. And it works just fine. The beauty is that
> it should work for all generated code (not just BPF).
>
> > Can't we populate orc_unwind tables after JIT ?
>
> As I mentioned it would introduce a lot more complexity. For each JIT
> function, BPF would have to tell ORC the following:
>
> - where the BPF function lives
> - how big the stack frame is
> - where RBP and other callee-saved regs are on the stack
that sounds like straightforward addition that ORC should have anyway.
right now we're not using rbp in the jit-ed code,
but one day we definitely will.
Same goes for r12. It's reserved right now for 'strategic use'.
We've been thinking to add another register to bpf isa.
It will map to r12 on x86. arm64 and others have plenty of regs to use.
The programs are getting bigger and register spill/fill starting to
become a performance concern. Extra register will give us more room.
RE: [EXT] Re: [V3 2/2] dmaengine: fsl-dpaa2-qdma: Add NXP dpaa2 qDMA controller driver for Layerscape SoCs
Hi Vinod, >-Original Message- >From: Vinod Koul >Sent: 2019年6月13日 19:03 >To: Peng Ma >Cc: dan.j.willi...@intel.com; Leo Li ; >linux-kernel@vger.kernel.org; dmaeng...@vger.kernel.org >Subject: Re: [EXT] Re: [V3 2/2] dmaengine: fsl-dpaa2-qdma: Add NXP dpaa2 >qDMA controller driver for Layerscape SoCs > >Caution: EXT Email > >On 10-06-19, 09:51, Peng Ma wrote: > >> >> + goto err; >> >> + >> >> + comp_temp->fl_virt_addr = >> >> + (void *)((struct dpaa2_fd *) >> >> + comp_temp->fd_virt_addr + 1); >> > >> >casts and pointer math, what could go wrong!! This doesnt smell right! >> > >> >> + comp_temp->fl_bus_addr = comp_temp->fd_bus_addr + >> >> + sizeof(struct dpaa2_fd); >> > >> >why not use fl_virt_addr and get the bus_address? >> What you mean is I should use virt_to_phys to get the bus_address? > >Yes instead of maintaining both pointers, just use one and then when required >use one to get other. For bus address I would prefer dma_map_single rather >than virt_to_phys() [Peng Ma] ok, thanks, I have already send V4 for this series patch, Please review it in your spare time. Patchwork link: https://patchwork.kernel.org/project/linux-dmaengine/list/?series=131767 Best Regars, Peng >-- >~Vinod
[PATCH] perf vendor events: Add Icelake V1.00 event file
Add a Intel event file for perf.
Signed-off-by: Haiyan Song
---
tools/perf/pmu-events/arch/x86/icelake/cache.json | 552 +
.../arch/x86/icelake/floating-point.json | 102 +++
.../perf/pmu-events/arch/x86/icelake/frontend.json | 424 ++
tools/perf/pmu-events/arch/x86/icelake/memory.json | 410 ++
tools/perf/pmu-events/arch/x86/icelake/other.json | 121 +++
.../perf/pmu-events/arch/x86/icelake/pipeline.json | 892 +
.../arch/x86/icelake/virtual-memory.json | 236 ++
tools/perf/pmu-events/arch/x86/mapfile.csv | 1 +
8 files changed, 2738 insertions(+)
create mode 100644 tools/perf/pmu-events/arch/x86/icelake/cache.json
create mode 100644 tools/perf/pmu-events/arch/x86/icelake/floating-point.json
create mode 100644 tools/perf/pmu-events/arch/x86/icelake/frontend.json
create mode 100644 tools/perf/pmu-events/arch/x86/icelake/memory.json
create mode 100644 tools/perf/pmu-events/arch/x86/icelake/other.json
create mode 100644 tools/perf/pmu-events/arch/x86/icelake/pipeline.json
create mode 100644 tools/perf/pmu-events/arch/x86/icelake/virtual-memory.json
diff --git a/tools/perf/pmu-events/arch/x86/icelake/cache.json
b/tools/perf/pmu-events/arch/x86/icelake/cache.json
new file mode 100644
index ..3529fc338c17
--- /dev/null
+++ b/tools/perf/pmu-events/arch/x86/icelake/cache.json
@@ -0,0 +1,552 @@
+[
+{
+"CollectPEBSRecord": "2",
+"PublicDescription": "Counts the number of demand Data Read requests
that miss L2 cache. Only not rejected loads are counted.",
+"EventCode": "0x24",
+"Counter": "0,1,2,3",
+"UMask": "0x21",
+"PEBScounters": "0,1,2,3",
+"EventName": "L2_RQSTS.DEMAND_DATA_RD_MISS",
+"SampleAfterValue": "23",
+"BriefDescription": "Demand Data Read miss L2, no rejects"
+},
+{
+"CollectPEBSRecord": "2",
+"PublicDescription": "Counts the RFO (Read-for-Ownership) requests
that miss L2 cache.",
+"EventCode": "0x24",
+"Counter": "0,1,2,3",
+"UMask": "0x22",
+"PEBScounters": "0,1,2,3",
+"EventName": "L2_RQSTS.RFO_MISS",
+"SampleAfterValue": "23",
+"BriefDescription": "RFO requests that miss L2 cache"
+},
+{
+"CollectPEBSRecord": "2",
+"PublicDescription": "Counts L2 cache misses when fetching
instructions.",
+"EventCode": "0x24",
+"Counter": "0,1,2,3",
+"UMask": "0x24",
+"PEBScounters": "0,1,2,3",
+"EventName": "L2_RQSTS.CODE_RD_MISS",
+"SampleAfterValue": "23",
+"BriefDescription": "L2 cache misses when fetching instructions"
+},
+{
+"CollectPEBSRecord": "2",
+"PublicDescription": "Counts demand requests that miss L2 cache.",
+"EventCode": "0x24",
+"Counter": "0,1,2,3",
+"UMask": "0x27",
+"PEBScounters": "0,1,2,3",
+"EventName": "L2_RQSTS.ALL_DEMAND_MISS",
+"SampleAfterValue": "23",
+"BriefDescription": "Demand requests that miss L2 cache"
+},
+{
+"CollectPEBSRecord": "2",
+"PublicDescription": "Counts Software prefetch requests that miss the
L2 cache. This event accounts for PREFETCHNTA and PREFETCHT0/1/2 instructions.",
+"EventCode": "0x24",
+"Counter": "0,1,2,3",
+"UMask": "0x28",
+"PEBScounters": "0,1,2,3",
+"EventName": "L2_RQSTS.SWPF_MISS",
+"SampleAfterValue": "23",
+"BriefDescription": "SW prefetch requests that miss L2 cache."
+},
+{
+"CollectPEBSRecord": "2",
+"PublicDescription": "Counts the number of demand Data Read requests
initiated by load instructions that hit L2 cache.",
+"EventCode": "0x24",
+"Counter": "0,1,2,3",
+"UMask": "0xc1",
+"PEBScounters": "0,1,2,3",
+"EventName": "L2_RQSTS.DEMAND_DATA_RD_HIT",
+"SampleAfterValue": "23",
+"BriefDescription": "Demand Data Read requests that hit L2 cache"
+},
+{
+"CollectPEBSRecord": "2",
+"PublicDescription": "Counts the RFO (Read-for-Ownership) requests
that hit L2 cache.",
+"EventCode": "0x24",
+"Counter": "0,1,2,3",
+"UMask": "0xc2",
+"PEBScounters": "0,1,2,3",
+"EventName": "L2_RQSTS.RFO_HIT",
+"SampleAfterValue": "23",
+"BriefDescription": "RFO requests that hit L2 cache"
+},
+{
+"CollectPEBSRecord": "2",
+"PublicDescription": "Counts L2 cache hits when fetching instructions,
code reads.",
+"EventCode": "0x24",
+"Counter": "0,1,2,3",
+"UMask": "0xc4",
+"PEBScounters": "0,1,2,3",
+"EventName": "L2_RQSTS.CODE_RD_HIT",
+"SampleAfterValue": "23",
+"BriefDescription": "L2 cache hits when fetching instructions, code
reads."
+},
+{
+"CollectPEBSRecord": "2",
+"Publ
Re: [PATCH 6/9] x86/bpf: Fix JIT frame pointer usage
On Thu, Jun 13, 2019 at 08:22:48PM -0500, Josh Poimboeuf wrote:
> On Thu, Jun 13, 2019 at 02:58:09PM -0700, Alexei Starovoitov wrote:
> > On Thu, Jun 13, 2019 at 08:21:03AM -0500, Josh Poimboeuf wrote:
> > > The BPF JIT code clobbers RBP. This breaks frame pointer convention and
> > > thus prevents the FP unwinder from unwinding through JIT generated code.
> > >
> > > RBP is currently used as the BPF stack frame pointer register. The
> > > actual register used is opaque to the user, as long as it's a
> > > callee-saved register. Change it to use R12 instead.
> > >
> > > Fixes: d15d356887e7 ("perf/x86: Make perf callchains work without
> > > CONFIG_FRAME_POINTER")
> > > Reported-by: Song Liu
> > > Signed-off-by: Josh Poimboeuf
> > > ---
> > > arch/x86/net/bpf_jit_comp.c | 43 +
> > > 1 file changed, 25 insertions(+), 18 deletions(-)
> > >
> > > diff --git a/arch/x86/net/bpf_jit_comp.c b/arch/x86/net/bpf_jit_comp.c
> > > index e649f977f8e1..bb1968fea50a 100644
> > > --- a/arch/x86/net/bpf_jit_comp.c
> > > +++ b/arch/x86/net/bpf_jit_comp.c
> > > @@ -100,9 +100,8 @@ static int bpf_size_to_x86_bytes(int bpf_size)
> > > /*
> > > * The following table maps BPF registers to x86-64 registers.
> > > *
> > > - * x86-64 register R12 is unused, since if used as base address
> > > - * register in load/store instructions, it always needs an
> > > - * extra byte of encoding and is callee saved.
> > > + * RBP isn't used; it needs to be preserved to allow the unwinder to move
> > > + * through generated code stacks.
> >
> > Extra register save/restore is kinda annoying just to fix ORC.
>
> It's not just for the ORC unwinder. It also fixes the frame pointer
> unwinder (see above commit msg). And it's standard frame pointer
> practice to not clobber RBP.
not true.
generated JITed code has no issues with regular stack unwinder.
it breaks down under ORC only.
> > Also every stack access from bpf prog will be encoded via r12 and consume
> > extra byte of encoding. I really don't like this approach.
>
> Do you have another callee-saved register you'd prefer to use as the
> stack pointer?
RBP must be used.
> > Can you teach ORC to understand JIT-ed frames instead?
>
> We could, but it would add a lot more complexity than this. And anyway,
> the frame pointer unwinder would still be broken.
I disagree. See above. Only ORC is broken. Hence ORC should be fixed.
