Re: iommu: Improve exception handling in iommu_group_alloc()
On Tue, Jun 02, 2020 at 07:01:02AM +0200, Markus Elfring wrote: > >> * I suggest to avoid the specification of duplicate function calls. > >> Will it be helpful to add a few jump targets? > >> > >> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/coding-style.rst?id=3d77e6a8804abcc0504c904bd6e5cdf3a5cf8162#n455 > > > > I don't think it is helpful or readable to add some jump targets here, > > since the exception handling is very simple here. > > Do you disagree to the application of the Linux coding style then > for the recommended exception handling? No, that's not what I mean. My point is the exception handling in this patch is simple and no need to add 'goto' statement which does not help to improve readability. And I agree it is helpful for the cases where a function exits from multiple locations and more same cleanup work need to do.
Re: [PATCH v2] blkdev: Replace blksize_bits() with ilog2()
On Mon, Jun 01, 2020 at 10:44:26AM +0200, Greg KH wrote: > But does this code path actually show up anywhere that is actually > measurable as mattering? > > If so, please show that benchmark results. I think the requests are starting to be a bit unreasonable. Tao is replacing a reimplementation of a standard function with that standard function / compiler builtin. We don't put such a high burden on that. And once the proper existing fields are used where possible as shown in my reply just replacing the rest seems totally obvious - quite contrary I think keeping a reimplementation would need a high bar.
Re: [v2] afs: Fix memory leak in afs_put_sysnames()
>> * Is freeing and releasing an item a duplicate operation anyhow? > > You're missing the point. afs_put_sysnames() does release the things the > object points to (ie. the content), It is possible to distinguish the release of system resources for further items. > but not the object itself. How does this view fit to the proposed addition "kfree(sysnames);"? https://lore.kernel.org/linux-fsdevel/20200602013045.321855-1-chengzhih...@huawei.com/ https://lore.kernel.org/patchwork/patch/1251323/ Regards, Markus
linux-next: manual merge of the tty tree with the devicetree tree
Hi all,
Today's linux-next merge of the tty tree got a conflict in:
Documentation/devicetree/bindings/serial/rs485.yaml
between commit:
9f60a65bc5e6 ("dt-bindings: Clean-up schema indentation formatting")
from the devicetree tree and commit:
01c38ecff8b1 ("dt-bindings: serial: Add binding for rs485 bus termination
GPIO")
from the tty 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 Documentation/devicetree/bindings/serial/rs485.yaml
index 8141e4aad530,a9ad17864889..
--- a/Documentation/devicetree/bindings/serial/rs485.yaml
+++ b/Documentation/devicetree/bindings/serial/rs485.yaml
@@@ -39,6 -41,9 +39,10 @@@ properties
$ref: /schemas/types.yaml#/definitions/flag
rs485-rx-during-tx:
- description: enables the receiving of data even while sending data.
- $ref: /schemas/types.yaml#/definitions/flag
+description: enables the receiving of data even while sending data.
+$ref: /schemas/types.yaml#/definitions/flag
+
+ rs485-term-gpios:
+ description: GPIO pin to enable RS485 bus termination.
+ maxItems: 1
+...
pgpC_WLMO0Bi9.pgp
Description: OpenPGP digital signature
[PATCH] media: staging: tegra-vde: add missing pm_runtime_put_autosuspend
Call to pm_runtime_get_sync increments counter even in case of
failure leading to incorrect ref count.
Call pm_runtime_put_autosuspend if pm_runtime_get_sync fails.
Signed-off-by: Navid Emamdoost
---
drivers/staging/media/tegra-vde/vde.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/staging/media/tegra-vde/vde.c
b/drivers/staging/media/tegra-vde/vde.c
index d3e63512a765..52cdd4a91e93 100644
--- a/drivers/staging/media/tegra-vde/vde.c
+++ b/drivers/staging/media/tegra-vde/vde.c
@@ -776,8 +776,10 @@ static int tegra_vde_ioctl_decode_h264(struct tegra_vde
*vde,
goto release_dpb_frames;
ret = pm_runtime_get_sync(dev);
- if (ret < 0)
+ if (ret < 0) {
+ pm_runtime_put_autosuspend(dev);
goto unlock;
+ }
/*
* We rely on the VDE registers reset value, otherwise VDE
--
2.17.1
[PATCH] spi: img-spfi: add missing pm_runtime_pu
Call to pm_runtime_get_sync increments counter even in case of
failure leading to incorrect ref count.
Call pm_runtime_put if pm_runtime_get_sync fails.
Signed-off-by: Navid Emamdoost
---
drivers/spi/spi-img-spfi.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/spi/spi-img-spfi.c b/drivers/spi/spi-img-spfi.c
index 8543f5ed1099..c3d0452ac78a 100644
--- a/drivers/spi/spi-img-spfi.c
+++ b/drivers/spi/spi-img-spfi.c
@@ -785,8 +785,10 @@ static int img_spfi_resume(struct device *dev)
int ret;
ret = pm_runtime_get_sync(dev);
- if (ret)
+ if (ret) {
+ pm_runtime_put(dev);
return ret;
+ }
spfi_reset(spfi);
pm_runtime_put(dev);
--
2.17.1
[PATCH] iommu/vt-d: Don't apply gfx quirks to untrusted devices
Currently, an external malicious PCI device can masquerade the VID:PID
of faulty gfx devices, and thus apply iommu quirks to effectively
disable the IOMMU restrictions for itself.
Thus we need to ensure that the device we are applying quirks to, is
indeed an internal trusted device.
Signed-off-by: Rajat Jain
---
drivers/iommu/intel-iommu.c | 28
1 file changed, 28 insertions(+)
diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
index ef0a5246700e5..f2a480168a02f 100644
--- a/drivers/iommu/intel-iommu.c
+++ b/drivers/iommu/intel-iommu.c
@@ -6214,6 +6214,11 @@ const struct iommu_ops intel_iommu_ops = {
static void quirk_iommu_igfx(struct pci_dev *dev)
{
+ if (dev->untrusted) {
+ pci_warn(dev, "skipping iommu quirk for untrusted gfx dev\n");
+ return;
+ }
+
pci_info(dev, "Disabling IOMMU for graphics on this chipset\n");
dmar_map_gfx = 0;
}
@@ -6255,6 +6260,11 @@ DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x163D,
quirk_iommu_igfx);
static void quirk_iommu_rwbf(struct pci_dev *dev)
{
+ if (dev->untrusted) {
+ pci_warn(dev, "skipping iommu quirk for untrusted dev\n");
+ return;
+ }
+
/*
* Mobile 4 Series Chipset neglects to set RWBF capability,
* but needs it. Same seems to hold for the desktop versions.
@@ -6285,6 +6295,11 @@ static void quirk_calpella_no_shadow_gtt(struct pci_dev
*dev)
{
unsigned short ggc;
+ if (dev->untrusted) {
+ pci_warn(dev, "skipping iommu quirk for untrusted gfx dev\n");
+ return;
+ }
+
if (pci_read_config_word(dev, GGC, ))
return;
@@ -6318,6 +6333,13 @@ static void __init check_tylersburg_isoch(void)
pdev = pci_get_device(PCI_VENDOR_ID_INTEL, 0x3a3e, NULL);
if (!pdev)
return;
+
+ if (pdev->untrusted) {
+ pci_warn(pdev, "skipping iommu quirk due to untrusted dev\n");
+ pci_dev_put(pdev);
+ return;
+ }
+
pci_dev_put(pdev);
/* System Management Registers. Might be hidden, in which case
@@ -6327,6 +6349,12 @@ static void __init check_tylersburg_isoch(void)
if (!pdev)
return;
+ if (pdev->untrusted) {
+ pci_warn(pdev, "skipping iommu quirk due to untrusted dev\n");
+ pci_dev_put(pdev);
+ return;
+ }
+
if (pci_read_config_dword(pdev, 0x188, )) {
pci_dev_put(pdev);
return;
--
2.27.0.rc2.251.g90737beb825-goog
Re: [PATCH RFCv2 9/9] arm64: Support async page fault
Hi Marc, Paolo, On 6/1/20 7:21 PM, Paolo Bonzini wrote: On 31/05/20 14:44, Marc Zyngier wrote: Is there an ARM-approved way to reuse the S2 fault syndromes to detect async page faults? It would mean being able to set an ESR_EL2 register value into ESR_EL1, and there is nothing in the architecture that would allow that, I understand that this is not what you want to do and I'm not proposing it, but I want to understand this better: _in practice_ do CPUs check closely what is written in ESR_EL1? In any case, the only way to implement this, it seems to me, would be a completely paravirtualized exception vector that doesn't use ESR at all. On the other hand, for the page ready (interrupt) side assigning a PPI seems complicated but doable. Marc suggested to use SDEI in another reply. I think it might be the appropriate way to deliver page-not-present. To some extent, it could be regarded as exception, which doesn't use ESR at all. It matches with what Paolo is thinking of: paravirtualized exception vector that doesn't use ESR at all. However, it seems it's not supported in kvm-arm yet. So I assume it needs to be developed from scratch. Marc, could you please help to confirm? Thanks in advance. I agree with Paolo PPI (interrupt) might be the best way to deliver page-ready currently. I don't think SDEI is suitable because there are no big difference between SDEI and currently used DABT injection to some extent. With SDEI, We will have the issues we are facing. For example, some critical code section isn't safe to receive SDEI if I'm correct. Thanks, Gavin [...]
[PATCH] Documentation: kunit: Add some troubleshooting tips to the FAQ
Add an FAQ entry to the KUnit documentation with some tips for troubleshooting KUnit and kunit_tool. These suggestions largely came from an email thread: https://lore.kernel.org/linux-kselftest/41db8bbd-3ba0-8bde-7352-083bf4b94...@intel.com/T/#m23213d4e156db6d59b0b460a9014950f5ff6eb03 Signed-off-by: David Gow --- Documentation/dev-tools/kunit/faq.rst | 32 +++ 1 file changed, 32 insertions(+) diff --git a/Documentation/dev-tools/kunit/faq.rst b/Documentation/dev-tools/kunit/faq.rst index ea55b2467653..40109d425988 100644 --- a/Documentation/dev-tools/kunit/faq.rst +++ b/Documentation/dev-tools/kunit/faq.rst @@ -61,3 +61,35 @@ test, or an end-to-end test. kernel by installing a production configuration of the kernel on production hardware with a production userspace and then trying to exercise some behavior that depends on interactions between the hardware, the kernel, and userspace. + +KUnit isn't working, what should I do? +== + +Unfortunately, there are a number of things which can break, but here are some +things to try. + +1. Try running ``./tools/testing/kunit/kunit.py run`` with the ``--raw_output`` + parameter. This might show details or error messages hidden by the kunit_tool + parser. +2. Instead of running ``kunit.py run``, try running ``kunit.py config``, + ``kunit.py build``, and ``kunit.py exec`` independently. This can help track + down where an issue is occurring. (If you think the parser is at fault, you + can run it manually against stdin or a file with ``kunit.py parse``.) +3. Running the UML kernel directly can often reveal issues or error messages + kunit_tool ignores. This should be as simple as running ``./vmlinux`` after + building the UML kernel (e.g., by using ``kunit.py build``). Note that UML + has some unusual requirements (such as the host having a tmpfs filesystem + mounted), and has had issues in the past when built statically and the host + has KASLR enabled. (On older host kernels, you may need to run ``setarch + `uname -m` -R ./vmlinux`` to disable KASLR.) +4. Make sure the kernel .config has ``CONFIG_KUNIT=y`` and at least one test + (e.g. ``CONFIG_KUNIT_EXAMPLE_TEST=y``). kunit_tool will keep its .config + around, so you can see what config was used after running ``kunit.py run``. + It also preserves any config changes you might make, so you can + enable/disable things with ``make ARCH=um menuconfig`` or similar, and then + re-run kunit_tool. +5. Finally, running ``make ARCH=um defconfig`` before running ``kunit.py run`` + may help clean up any residual config items which could be causing problems. + +If none of the above tricks help, you are always welcome to email any issues to +kunit-...@googlegroups.com. -- 2.27.0.rc2.251.g90737beb825-goog
Re: [PATCH v8 0/5] support reserving crashkernel above 4G on arm64 kdump
On Tue, Jun 2, 2020 at 3:29 AM John Donnelly wrote: > > Hi . See below ! > > > On Jun 1, 2020, at 4:02 PM, Bhupesh Sharma wrote: > > > > Hi John, > > > > On Tue, Jun 2, 2020 at 1:01 AM John Donnelly > > wrote: > >> > >> Hi, > >> > >> > >> On 6/1/20 7:02 AM, Prabhakar Kushwaha wrote: > >>> Hi Chen, > >>> > >>> On Thu, May 21, 2020 at 3:05 PM Chen Zhou wrote: > This patch series enable reserving crashkernel above 4G in arm64. > > There are following issues in arm64 kdump: > 1. We use crashkernel=X to reserve crashkernel below 4G, which will fail > when there is no enough low memory. > 2. Currently, crashkernel=Y@X can be used to reserve crashkernel above > 4G, > in this case, if swiotlb or DMA buffers are required, crash dump kernel > will boot failure because there is no low memory available for > allocation. > > To solve these issues, introduce crashkernel=X,low to reserve specified > size low memory. > Crashkernel=X tries to reserve memory for the crash dump kernel under > 4G. If crashkernel=Y,low is specified simultaneously, reserve spcified > size low memory for crash kdump kernel devices firstly and then reserve > memory above 4G. > > When crashkernel is reserved above 4G in memory, that is, > crashkernel=X,low > is specified simultaneously, kernel should reserve specified size low > memory > for crash dump kernel devices. So there may be two crash kernel regions, > one > is below 4G, the other is above 4G. > In order to distinct from the high region and make no effect to the use > of > kexec-tools, rename the low region as "Crash kernel (low)", and add DT > property > "linux,low-memory-range" to crash dump kernel's dtb to pass the low > region. > > Besides, we need to modify kexec-tools: > arm64: kdump: add another DT property to crash dump kernel's dtb(see [1]) > > The previous changes and discussions can be retrieved from: > > Changes since [v7] > - Move x86 CRASH_ALIGN to 2M > Suggested by Dave and do some test, move x86 CRASH_ALIGN to 2M. > - Update Documentation/devicetree/bindings/chosen.txt > Add corresponding documentation to > Documentation/devicetree/bindings/chosen.txt suggested by Arnd. > - Add Tested-by from Jhon and pk > > Changes since [v6] > - Fix build errors reported by kbuild test robot. > > Changes since [v5] > - Move reserve_crashkernel_low() into kernel/crash_core.c. > - Delete crashkernel=X,high. > - Modify crashkernel=X,low. > If crashkernel=X,low is specified simultaneously, reserve spcified size > low > memory for crash kdump kernel devices firstly and then reserve memory > above 4G. > In addition, rename crashk_low_res as "Crash kernel (low)" for arm64, > and then > pass to crash dump kernel by DT property "linux,low-memory-range". > - Update Documentation/admin-guide/kdump/kdump.rst. > > Changes since [v4] > - Reimplement memblock_cap_memory_ranges for multiple ranges by Mike. > > Changes since [v3] > - Add memblock_cap_memory_ranges back for multiple ranges. > - Fix some compiling warnings. > > Changes since [v2] > - Split patch "arm64: kdump: support reserving crashkernel above 4G" as > two. Put "move reserve_crashkernel_low() into kexec_core.c" in a separate > patch. > > Changes since [v1]: > - Move common reserve_crashkernel_low() code into kernel/kexec_core.c. > - Remove memblock_cap_memory_ranges() i added in v1 and implement that > in fdt_enforce_memory_region(). > There are at most two crash kernel regions, for two crash kernel regions > case, we cap the memory range [min(regs[*].start), max(regs[*].end)] > and then remove the memory range in the middle. > > [1]: > https://urldefense.com/v3/__http://lists.infradead.org/pipermail/kexec/2020-May/025128.html__;!!GqivPVa7Brio!LnTSARkCt0V0FozR0KmqooaH5ADtdXvs3mPdP3KRVqALmvSK2VmCkIPIhsaxbvpn1uM1$ > [v1]: > https://urldefense.com/v3/__https://lkml.org/lkml/2019/4/2/1174__;!!GqivPVa7Brio!LnTSARkCt0V0FozR0KmqooaH5ADtdXvs3mPdP3KRVqALmvSK2VmCkIPIhsaxbt0xN9PE$ > [v2]: > https://urldefense.com/v3/__https://lkml.org/lkml/2019/4/9/86__;!!GqivPVa7Brio!LnTSARkCt0V0FozR0KmqooaH5ADtdXvs3mPdP3KRVqALmvSK2VmCkIPIhsaxbub7yUQH$ > [v3]: > https://urldefense.com/v3/__https://lkml.org/lkml/2019/4/9/306__;!!GqivPVa7Brio!LnTSARkCt0V0FozR0KmqooaH5ADtdXvs3mPdP3KRVqALmvSK2VmCkIPIhsaxbnc4zPPV$ > [v4]: > https://urldefense.com/v3/__https://lkml.org/lkml/2019/4/15/273__;!!GqivPVa7Brio!LnTSARkCt0V0FozR0KmqooaH5ADtdXvs3mPdP3KRVqALmvSK2VmCkIPIhsaxbvsAsZLu$ > [v5]: >
[PATCH v2] driver core: platform: expose numa_node to users in sysfs
For some platform devices like iommu, particually ARM smmu, users may
care about the numa locality. for example, if threads and drivers run
near iommu, they may get much better performance on dma_unmap_sg.
For other platform devices, users may still want to know the hardware
topology.
Cc: Prime Zeng
Cc: Robin Murphy
Signed-off-by: Barry Song
---
-v2: add the numa_node entry in Documentation/ABI/
Documentation/ABI/testing/sysfs-bus-platform | 10
drivers/base/platform.c | 26 +++-
2 files changed, 35 insertions(+), 1 deletion(-)
diff --git a/Documentation/ABI/testing/sysfs-bus-platform
b/Documentation/ABI/testing/sysfs-bus-platform
index 5172a6124b27..e8f5958c1d18 100644
--- a/Documentation/ABI/testing/sysfs-bus-platform
+++ b/Documentation/ABI/testing/sysfs-bus-platform
@@ -18,3 +18,13 @@ Description:
devices to opt-out of driver binding using a driver_override
name such as "none". Only a single driver may be specified in
the override, there is no support for parsing delimiters.
+
+What: /sys/bus/platform/devices/.../numa_node
+Date: June 2020
+Contact: Barry Song
+Description:
+ This file contains the NUMA node to which the platform device
+ is attached. It won't be visible if the node is unknown. The
+ value comes from an ACPI _PXM method or a similar firmware
+ source. Initial users for this file would be devices like
+ arm smmu which are populated by arm64 acpi_iort.
diff --git a/drivers/base/platform.c b/drivers/base/platform.c
index b27d0f6c18c9..7794b9a38d82 100644
--- a/drivers/base/platform.c
+++ b/drivers/base/platform.c
@@ -1062,13 +1062,37 @@ static ssize_t driver_override_show(struct device *dev,
}
static DEVICE_ATTR_RW(driver_override);
+static ssize_t numa_node_show(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ return sprintf(buf, "%d\n", dev_to_node(dev));
+}
+static DEVICE_ATTR_RO(numa_node);
+
+static umode_t platform_dev_attrs_visible(struct kobject *kobj, struct
attribute *a,
+ int n)
+{
+ struct device *dev = container_of(kobj, typeof(*dev), kobj);
+
+ if (a == _attr_numa_node.attr &&
+ dev_to_node(dev) == NUMA_NO_NODE)
+ return 0;
+
+ return a->mode;
+}
static struct attribute *platform_dev_attrs[] = {
_attr_modalias.attr,
+ _attr_numa_node.attr,
_attr_driver_override.attr,
NULL,
};
-ATTRIBUTE_GROUPS(platform_dev);
+
+static struct attribute_group platform_dev_group = {
+ .attrs = platform_dev_attrs,
+ .is_visible = platform_dev_attrs_visible,
+};
+__ATTRIBUTE_GROUPS(platform_dev);
static int platform_uevent(struct device *dev, struct kobj_uevent_env *env)
{
--
2.23.0
Re: [PATCH v3 1/1] clk: rockchip: rk3288: Handle clock tree for rk3288w
Hi Heiko,
Thank you very much for your quick review!
On 6/1/20 10:09 PM, Heiko Stübner wrote:
Hi Mylène,
Am Montag, 1. Juni 2020, 17:14:42 CEST schrieb Mylène Josserand:
The revision rk3288w has a different clock tree about "hclk_vio"
clock, according to the BSP kernel code.
This patch handles this difference by detecting which device-tree
we are using. If it is a "rockchip,rk3288-cru", let's register
the clock tree as it was before. If the compatible is
"rockchip,rk3288w-cru", we will apply the difference according to this
version of this SoC.
Noticed that this new device-tree compatible must be handled by
bootloader.
Signed-off-by: Mylène Josserand
approach looks good, but you should also update the clock-controller
dt-binding for the new compatible.
Okay, I will. As it was not implemented in the Kernel, I didn't know if
I should add it.
Style nits below.
---
drivers/clk/rockchip/clk-rk3288.c | 20 ++--
1 file changed, 18 insertions(+), 2 deletions(-)
diff --git a/drivers/clk/rockchip/clk-rk3288.c
b/drivers/clk/rockchip/clk-rk3288.c
index cc2a177bbdbf..5018d2f1e54c 100644
--- a/drivers/clk/rockchip/clk-rk3288.c
+++ b/drivers/clk/rockchip/clk-rk3288.c
@@ -425,8 +425,6 @@ static struct rockchip_clk_branch rk3288_clk_branches[]
__initdata = {
COMPOSITE(0, "aclk_vio0", mux_pll_src_cpll_gpll_usb480m_p,
CLK_IGNORE_UNUSED,
RK3288_CLKSEL_CON(31), 6, 2, MFLAGS, 0, 5, DFLAGS,
RK3288_CLKGATE_CON(3), 0, GFLAGS),
- DIV(0, "hclk_vio", "aclk_vio0", 0,
- RK3288_CLKSEL_CON(28), 8, 5, DFLAGS),
COMPOSITE(0, "aclk_vio1", mux_pll_src_cpll_gpll_usb480m_p,
CLK_IGNORE_UNUSED,
RK3288_CLKSEL_CON(31), 14, 2, MFLAGS, 8, 5, DFLAGS,
RK3288_CLKGATE_CON(3), 2, GFLAGS),
@@ -819,6 +817,16 @@ static struct rockchip_clk_branch rk3288_clk_branches[]
__initdata = {
INVERTER(0, "pclk_isp", "pclk_isp_in", RK3288_CLKSEL_CON(29), 3,
IFLAGS),
};
+static struct rockchip_clk_branch rk3288w_hclkvio_branch[] __initdata = {
+ DIV(0, "hclk_vio", "aclk_vio1", 0,
+ RK3288_CLKSEL_CON(28), 8, 5, DFLAGS),
please keep indentations as they were, the sub-lines starting where they
are is actually intentional :-)
Oups, I didn't know, I will update this in my V4.
+};
+
+static struct rockchip_clk_branch rk3288_hclkvio_branch[] __initdata = {
+ DIV(0, "hclk_vio", "aclk_vio0", 0,
+ RK3288_CLKSEL_CON(28), 8, 5, DFLAGS),
same here
same here
+};
+
static const char *const rk3288_critical_clocks[] __initconst = {
"aclk_cpu",
"aclk_peri",
@@ -936,6 +944,14 @@ static void __init rk3288_clk_init(struct device_node *np)
RK3288_GRF_SOC_STATUS1);
rockchip_clk_register_branches(ctx, rk3288_clk_branches,
ARRAY_SIZE(rk3288_clk_branches));
+
+ if (of_device_is_compatible(np, "rockchip,rk3288w-cru"))
+ rockchip_clk_register_branches(ctx, rk3288w_hclkvio_branch,
+
ARRAY_SIZE(rk3288w_hclkvio_branch));
+ else
+ rockchip_clk_register_branches(ctx, rk3288_hclkvio_branch,
+
ARRAY_SIZE(rk3288_hclkvio_branch));
+
rockchip_clk_protect_critical(rk3288_critical_clocks,
ARRAY_SIZE(rk3288_critical_clocks));
Best regards,
Mylène
Re: [PATCH] MAINTAINERS: rectify entry in ARM SMC WATCHDOG DRIVER
On 6/1/20 10:21 PM, Lukas Bulwahn wrote:
> Commit 5c24a28b4eb8 ("dt-bindings: watchdog: Add ARM smc wdt for mt8173
> watchdog") added the new ARM SMC WATCHDOG DRIVER entry in MAINTAINERS, but
> slipped in a minor mistake.
>
> Luckily, ./scripts/get_maintainer.pl --self-test=patterns complains:
>
> warning: no file matches F: devicetree/bindings/watchdog/arm-smc-wdt.yaml
>
> Update file entry to intended file location.
>
> Signed-off-by: Lukas Bulwahn
Reviewed-by: Guenter Roeck
> ---
> Julius, Evan, please ack.
>
> Wim, please pick this minor patch into your -next tree.
>
> applies cleanly on next-20200529
>
> MAINTAINERS | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index b045b70e54df..dcfb09700b96 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -1489,7 +1489,7 @@ ARM SMC WATCHDOG DRIVER
> M: Julius Werner
> R: Evan Benn
> S: Maintained
> -F: devicetree/bindings/watchdog/arm-smc-wdt.yaml
> +F: Documentation/devicetree/bindings/watchdog/arm-smc-wdt.yaml
> F: drivers/watchdog/arm_smc_wdt.c
>
> ARM SMMU DRIVERS
>
Re: [PATCH v7 3/6] irqchip: RISC-V per-HART local interrupt controller driver
On Tue, Jun 2, 2020 at 1:49 AM Atish Patra wrote:
>
> On Mon, Jun 1, 2020 at 2:16 AM Anup Patel wrote:
> >
> > The RISC-V per-HART local interrupt controller manages software
> > interrupts, timer interrupts, external interrupts (which are routed
> > via the platform level interrupt controller) and other per-HART
> > local interrupts.
> >
> > We add a driver for the RISC-V local interrupt controller, which
> > eventually replaces the RISC-V architecture code, allowing for a
> > better split between arch code and drivers.
> >
> > The driver is compliant with RISC-V Hart-Level Interrupt Controller
> > DT bindings located at:
> > Documentation/devicetree/bindings/interrupt-controller/riscv,cpu-intc.txt
> >
> > Co-developed-by: Palmer Dabbelt
> > Signed-off-by: Palmer Dabbelt
> > Signed-off-by: Anup Patel
> > Acked-by: Palmer Dabbelt
> > ---
> > arch/riscv/Kconfig| 1 +
> > arch/riscv/include/asm/irq.h | 2 -
> > arch/riscv/kernel/irq.c | 33 +--
> > arch/riscv/kernel/traps.c | 2 -
> > drivers/irqchip/Kconfig | 13 +++
> > drivers/irqchip/Makefile | 1 +
> > drivers/irqchip/irq-riscv-intc.c | 146 ++
> > drivers/irqchip/irq-sifive-plic.c | 30 --
> > include/linux/cpuhotplug.h| 1 +
> > 9 files changed, 188 insertions(+), 41 deletions(-)
> > create mode 100644 drivers/irqchip/irq-riscv-intc.c
> >
> > diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
> > index 90a008e28f7e..822cb0e1a380 100644
> > --- a/arch/riscv/Kconfig
> > +++ b/arch/riscv/Kconfig
> > @@ -40,6 +40,7 @@ config RISCV
> > select HAVE_PERF_REGS
> > select HAVE_PERF_USER_STACK_DUMP
> > select HAVE_SYSCALL_TRACEPOINTS
> > + select HANDLE_DOMAIN_IRQ
> > select IRQ_DOMAIN
> > select SPARSE_IRQ
> > select SYSCTL_EXCEPTION_TRACE
> > diff --git a/arch/riscv/include/asm/irq.h b/arch/riscv/include/asm/irq.h
> > index 0183e15ace66..a9e5f07a7e9c 100644
> > --- a/arch/riscv/include/asm/irq.h
> > +++ b/arch/riscv/include/asm/irq.h
> > @@ -10,8 +10,6 @@
> > #include
> > #include
> >
> > -#define NR_IRQS 0
> > -
> > void riscv_timer_interrupt(void);
> >
> > #include
> > diff --git a/arch/riscv/kernel/irq.c b/arch/riscv/kernel/irq.c
> > index bb0bfcd537e7..eb8777642ce6 100644
> > --- a/arch/riscv/kernel/irq.c
> > +++ b/arch/riscv/kernel/irq.c
> > @@ -7,7 +7,6 @@
> >
> > #include
> > #include
> > -#include
> > #include
> > #include
> >
> > @@ -19,39 +18,13 @@ int arch_show_interrupts(struct seq_file *p, int prec)
> >
> > asmlinkage __visible void __irq_entry do_IRQ(struct pt_regs *regs)
> > {
> > - struct pt_regs *old_regs;
> > -
> > - switch (regs->cause & ~CAUSE_IRQ_FLAG) {
> > - case RV_IRQ_TIMER:
> > - old_regs = set_irq_regs(regs);
> > - irq_enter();
> > - riscv_timer_interrupt();
> > - irq_exit();
> > - set_irq_regs(old_regs);
> > - break;
> > -#ifdef CONFIG_SMP
> > - case RV_IRQ_SOFT:
> > - /*
> > -* We only use software interrupts to pass IPIs, so if a
> > non-SMP
> > -* system gets one, then we don't know what to do.
> > -*/
> > - handle_IPI(regs);
> > - break;
> > -#endif
> > - case RV_IRQ_EXT:
> > - old_regs = set_irq_regs(regs);
> > - irq_enter();
> > + if (handle_arch_irq)
> > handle_arch_irq(regs);
> > - irq_exit();
> > - set_irq_regs(old_regs);
> > - break;
> > - default:
> > - pr_alert("unexpected interrupt cause 0x%lx", regs->cause);
> > - BUG();
> > - }
> > }
> >
> > void __init init_IRQ(void)
> > {
> > irqchip_init();
> > + if (!handle_arch_irq)
> > + panic("No interrupt controller found.");
> > }
> > diff --git a/arch/riscv/kernel/traps.c b/arch/riscv/kernel/traps.c
> > index 7f58fa53033f..f48c76aadbf3 100644
> > --- a/arch/riscv/kernel/traps.c
> > +++ b/arch/riscv/kernel/traps.c
> > @@ -178,6 +178,4 @@ void trap_init(void)
> > csr_write(CSR_SCRATCH, 0);
> > /* Set the exception vector address */
> > csr_write(CSR_TVEC, _exception);
> > - /* Enable interrupts */
> > - csr_write(CSR_IE, IE_SIE);
> > }
> > diff --git a/drivers/irqchip/Kconfig b/drivers/irqchip/Kconfig
> > index a85aada04a64..95d6137a8117 100644
> > --- a/drivers/irqchip/Kconfig
> > +++ b/drivers/irqchip/Kconfig
> > @@ -493,6 +493,19 @@ config TI_SCI_INTA_IRQCHIP
> > If you wish to use interrupt aggregator irq resources managed by
> > the
> > TI System Controller, say Y here. Otherwise, say N.
> >
> > +config RISCV_INTC
> > + bool "RISC-V Local Interrupt Controller"
> > + depends on RISCV
> > + default y
> > + help
> > +
Re: [PATCH] mm/vmstat: Add events for PMD based THP migration without split
On 06/02/2020 10:18 AM, John Hubbard wrote: > On 2020-06-01 21:20, Anshuman Khandual wrote: > ... >>> also important: maybe this patch should also be tracking other causes >>> of THP PMD migration failure, in order to get a truer accounting of the >>> situation. > > I hope one of the experts here can weigh in on that... > >> Is there any other failure reasons which are only specific to THP migration. >> Else, adding stats about generic migration failure reasons will just blur >> the overall understanding about THP migration successes and failure cases >> that results in splitting. >> > > Thinking about that: we do have PGMIGRATE_SUCCESS and PGMIGRATE_FAIL, so I > suppose comparing those numbers with the new THP_PMD_MIGRATION_SUCCESS and > THP_PMD_MIGRATION_FAILURE events should cover it. That is right. > > However, the fact that this is under discussion hints at the need for a > bit of documentation help. What do you think about adding some notes about > all of this to, say, Documentation/vm/page_migration.rst ? Sure but probably bit later. Because I am also planning to add couple of trace events for THP migration, hence will update the documentation part for both VM stat and trace events together.
[PATCH] spi: tegra20-slink: add missing pm_runtime_put
Call to pm_runtime_get_sync increments counter even in case of
failure leading to incorrect ref count.
Call pm_runtime_put if pm_runtime_get_sync fails.
Signed-off-by: Navid Emamdoost
---
drivers/spi/spi-tegra20-slink.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/spi/spi-tegra20-slink.c b/drivers/spi/spi-tegra20-slink.c
index 7f4d932dade7..0675b36d647b 100644
--- a/drivers/spi/spi-tegra20-slink.c
+++ b/drivers/spi/spi-tegra20-slink.c
@@ -1192,6 +1192,7 @@ static int tegra_slink_resume(struct device *dev)
ret = pm_runtime_get_sync(dev);
if (ret < 0) {
dev_err(dev, "pm runtime failed, e = %d\n", ret);
+ pm_runtime_put(dev);
return ret;
}
tegra_slink_writel(tspi, tspi->command_reg, SLINK_COMMAND);
--
2.17.1
RE: [PATCH V3 1/3] dt-bindings: mailbox: imx-mu: support i.MX8M
Hi Oleksij, > Subject: Re: [PATCH V3 1/3] dt-bindings: mailbox: imx-mu: support i.MX8M > > On Mon, Jun 01, 2020 at 04:20:00PM +0800, peng@nxp.com wrote: > > From: Peng Fan > > > > Add i.MX8MQ/M/N/P compatible string to support i.MX8M SoCs > > > > Reviewed-by: Dong Aisheng > > Signed-off-by: Peng Fan > > --- > > Documentation/devicetree/bindings/mailbox/fsl,mu.txt | 3 ++- > > 1 file changed, 2 insertions(+), 1 deletion(-) > > > > diff --git a/Documentation/devicetree/bindings/mailbox/fsl,mu.txt > > b/Documentation/devicetree/bindings/mailbox/fsl,mu.txt > > index 26b7a88c2fea..906377acf2cd 100644 > > --- a/Documentation/devicetree/bindings/mailbox/fsl,mu.txt > > +++ b/Documentation/devicetree/bindings/mailbox/fsl,mu.txt > > @@ -18,7 +18,8 @@ Messaging Unit Device Node: > > Required properties: > > --- > > - compatible : should be "fsl,-mu", the supported chips include > > - imx6sx, imx7s, imx8qxp, imx8qm. > > + imx6sx, imx7s, imx8qxp, imx8qm, imx8mq, imx8mm, imx8mn, > > + imx8mp. > > The "fsl,imx6sx-mu" compatible is seen as generic and should > > be included together with SoC specific compatible. > > There is a version 1.0 MU on imx7ulp, use "fsl,imx7ulp-mu" > > -- > > 2.16.4 > > > > > > Hi Peng, > > The fsl,mu.yaml was already taken by Rob, so one or other patch will break by > merge. I assume you should drop this change. Yes. I'll rebase this patch based on Rob's tree. Thanks for reminding me. Thanks, Peng. > > > Regards, > Oleksij > -- > Pengutronix e.K. | > | > Steuerwalder Str. 21 | > http://www.pengutronix.de/ | > 31137 Hildesheim, Germany | Phone: > +49-5121-206917-0| > Amtsgericht Hildesheim, HRA 2686 | Fax: > +49-5121-206917- |
drivers/net/ethernet/intel/e1000/e1000_osdep.h:13: warning: "CONFIG_RAM_BASE" redefined
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: f359287765c04711ff54fbd11645271d8e5ff763 commit: 5b49c82dadfe0f3741778f57385f964ec1514863 csky: Add PCI support date: 3 months ago config: csky-randconfig-r024-20200602 (attached as .config) compiler: csky-linux-gcc (GCC) 9.3.0 reproduce (this is a W=1 build): wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross git checkout 5b49c82dadfe0f3741778f57385f964ec1514863 # save the attached .config to linux build tree COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross ARCH=csky If you fix the issue, kindly add following tag as appropriate Reported-by: kbuild test robot All warnings (new ones prefixed by >>, old ones prefixed by <<): In file included from include/linux/kernel.h:11, from include/linux/list.h:9, from include/linux/module.h:12, from drivers/net/ethernet/intel/e1000/e1000.h:10, from drivers/net/ethernet/intel/e1000/e1000_main.c:4: include/asm-generic/fixmap.h: In function 'fix_to_virt': include/asm-generic/fixmap.h:32:19: warning: comparison of unsigned expression >= 0 is always true [-Wtype-limits] 32 | BUILD_BUG_ON(idx >= __end_of_fixed_addresses); | ^~ include/linux/compiler.h:330:9: note: in definition of macro '__compiletime_assert' 330 | if (!(condition)) | ^ include/linux/compiler.h:350:2: note: in expansion of macro '_compiletime_assert' 350 | _compiletime_assert(condition, msg, __compiletime_assert_, __LINE__) | ^~~ include/linux/build_bug.h:39:37: note: in expansion of macro 'compiletime_assert' 39 | #define BUILD_BUG_ON_MSG(cond, msg) compiletime_assert(!(cond), msg) | ^~ include/linux/build_bug.h:50:2: note: in expansion of macro 'BUILD_BUG_ON_MSG' 50 | BUILD_BUG_ON_MSG(condition, "BUILD_BUG_ON failed: " #condition) | ^~~~ include/asm-generic/fixmap.h:32:2: note: in expansion of macro 'BUILD_BUG_ON' 32 | BUILD_BUG_ON(idx >= __end_of_fixed_addresses); | ^~~~ In file included from drivers/net/ethernet/intel/e1000/e1000_hw.h:11, from drivers/net/ethernet/intel/e1000/e1000.h:54, from drivers/net/ethernet/intel/e1000/e1000_main.c:4: drivers/net/ethernet/intel/e1000/e1000_osdep.h: At top level: >> drivers/net/ethernet/intel/e1000/e1000_osdep.h:13: warning: >> "CONFIG_RAM_BASE" redefined 13 | #define CONFIG_RAM_BASE 0x6 | In file included from include/linux/kconfig.h:5, from : ./include/generated/autoconf.h:1690: note: this is the location of the previous definition 1690 | #define CONFIG_RAM_BASE 0x0 | -- In file included from include/linux/kernel.h:11, from include/linux/list.h:9, from include/linux/module.h:12, from drivers/net/ethernet/intel/e1000/e1000.h:10, from drivers/net/ethernet/intel/e1000/e1000_hw.c:8: include/asm-generic/fixmap.h: In function 'fix_to_virt': include/asm-generic/fixmap.h:32:19: warning: comparison of unsigned expression >= 0 is always true [-Wtype-limits] 32 | BUILD_BUG_ON(idx >= __end_of_fixed_addresses); | ^~ include/linux/compiler.h:330:9: note: in definition of macro '__compiletime_assert' 330 | if (!(condition)) | ^ include/linux/compiler.h:350:2: note: in expansion of macro '_compiletime_assert' 350 | _compiletime_assert(condition, msg, __compiletime_assert_, __LINE__) | ^~~ include/linux/build_bug.h:39:37: note: in expansion of macro 'compiletime_assert' 39 | #define BUILD_BUG_ON_MSG(cond, msg) compiletime_assert(!(cond), msg) | ^~ include/linux/build_bug.h:50:2: note: in expansion of macro 'BUILD_BUG_ON_MSG' 50 | BUILD_BUG_ON_MSG(condition, "BUILD_BUG_ON failed: " #condition) | ^~~~ include/asm-generic/fixmap.h:32:2: note: in expansion of macro 'BUILD_BUG_ON' 32 | BUILD_BUG_ON(idx >= __end_of_fixed_addresses); | ^~~~ In file included from drivers/net/ethernet/intel/e1000/e1000_hw.h:11, from drivers/net/ethernet/intel/e1000/e1000.h:54, from drivers/net/ethernet/intel/e1000/e1000_hw.c:8: drivers/net/ethernet/intel/e1000/e1000_osdep.h: At top level: >> drivers/net/ethernet/intel/e1000/e1000_osdep.h:13: warning: >> "CONFIG_RAM_BASE" redefined 13 | #define CONFIG_RAM_BASE 0x6 | In file included from include/linux/kconfig.h:5, from : ./include/generated/autoconf.h:1690: note: this is the location of the previous definition 1690 | #define CONFIG_RAM_BASE 0x0 | drivers/net/ethernet/intel/e1000/e1000_hw.c: In function 'e1000_phy_init_script': drivers/net/ethernet/intel/e1000/e1000_hw.c:132:6: warning: variable 'ret_val' set but not used [-Wunused-but-set-variable] 132 | u32 ret_val; | ^~~ drivers/net/ethernet/intel/e1000/e1000_hw.c: In function 'e1000_reset_hw': drivers/net/ethernet/intel/e1000/e1000_hw.c:380:6:
[PATCH v2 net-next 03/10] net: mscc: ocelot: allocated rules to different hardware VCAP TCAMs by chain index
There are three hardware TCAMs for ocelot chips: IS1, IS2 and ES0. Each
one supports different actions. The hardware flow order is: IS1->IS2->ES0.
This patch add three blocks to store rules according to chain index.
chain 0 is offloaded to IS1, chain 1 is offloaded to IS2, and egress chain
0 is offloaded to ES0.
Using action goto chain to express flow order as follows:
tc filter add dev swp0 chain 0 parent : flower skip_sw \
action goto chain 1
Signed-off-by: Xiaoliang Yang
---
drivers/net/ethernet/mscc/ocelot_ace.c| 51 +++
drivers/net/ethernet/mscc/ocelot_ace.h| 7 ++--
drivers/net/ethernet/mscc/ocelot_flower.c | 46 +---
include/soc/mscc/ocelot.h | 2 +-
include/soc/mscc/ocelot_vcap.h| 4 +-
5 files changed, 81 insertions(+), 29 deletions(-)
diff --git a/drivers/net/ethernet/mscc/ocelot_ace.c
b/drivers/net/ethernet/mscc/ocelot_ace.c
index 748c618db7d8..b76593b40097 100644
--- a/drivers/net/ethernet/mscc/ocelot_ace.c
+++ b/drivers/net/ethernet/mscc/ocelot_ace.c
@@ -341,6 +341,8 @@ static void is2_action_set(struct ocelot *ocelot, struct
vcap_data *data,
vcap_action_set(vcap, data, VCAP_IS2_ACT_CPU_QU_NUM, 0);
vcap_action_set(vcap, data, VCAP_IS2_ACT_CPU_COPY_ENA, 0);
break;
+ default:
+ break;
}
}
@@ -644,9 +646,9 @@ static void is2_entry_set(struct ocelot *ocelot, int ix,
}
static void vcap_entry_get(struct ocelot *ocelot, struct ocelot_ace_rule *rule,
- int ix)
+ int ix, int block_id)
{
- const struct vcap_props *vcap = >vcap[VCAP_IS2];
+ const struct vcap_props *vcap = >vcap[block_id];
struct vcap_data data;
int row, count;
u32 cnt;
@@ -663,6 +665,19 @@ static void vcap_entry_get(struct ocelot *ocelot, struct
ocelot_ace_rule *rule,
rule->stats.pkts = cnt;
}
+static void vcap_entry_set(struct ocelot *ocelot, int ix,
+ struct ocelot_ace_rule *ace,
+ int block_id)
+{
+ switch (block_id) {
+ case VCAP_IS2:
+ is2_entry_set(ocelot, ix, ace);
+ break;
+ default:
+ break;
+ }
+}
+
static void ocelot_ace_rule_add(struct ocelot *ocelot,
struct ocelot_acl_block *block,
struct ocelot_ace_rule *rule)
@@ -790,7 +805,7 @@ static bool ocelot_ace_is_problematic_non_mac_etype(struct
ocelot_ace_rule *ace)
static bool ocelot_exclusive_mac_etype_ace_rules(struct ocelot *ocelot,
struct ocelot_ace_rule *ace)
{
- struct ocelot_acl_block *block = >acl_block;
+ struct ocelot_acl_block *block = >acl_block[VCAP_IS2];
struct ocelot_ace_rule *tmp;
unsigned long port;
int i;
@@ -824,15 +839,16 @@ static bool ocelot_exclusive_mac_etype_ace_rules(struct
ocelot *ocelot,
return true;
}
-int ocelot_ace_rule_offload_add(struct ocelot *ocelot,
+int ocelot_ace_rule_offload_add(struct ocelot *ocelot, int block_id,
struct ocelot_ace_rule *rule,
struct netlink_ext_ack *extack)
{
- struct ocelot_acl_block *block = >acl_block;
+ struct ocelot_acl_block *block = >acl_block[block_id];
struct ocelot_ace_rule *ace;
int i, index;
- if (!ocelot_exclusive_mac_etype_ace_rules(ocelot, rule)) {
+ if (block_id == VCAP_IS2 &&
+ !ocelot_exclusive_mac_etype_ace_rules(ocelot, rule)) {
NL_SET_ERR_MSG_MOD(extack,
"Cannot mix MAC_ETYPE with non-MAC_ETYPE
rules");
return -EBUSY;
@@ -847,11 +863,11 @@ int ocelot_ace_rule_offload_add(struct ocelot *ocelot,
/* Move down the rules to make place for the new rule */
for (i = block->count - 1; i > index; i--) {
ace = ocelot_ace_rule_get_rule_index(block, i);
- is2_entry_set(ocelot, i, ace);
+ vcap_entry_set(ocelot, i, ace, block_id);
}
/* Now insert the new rule */
- is2_entry_set(ocelot, index, rule);
+ vcap_entry_set(ocelot, index, rule, block_id);
return 0;
}
@@ -902,10 +918,10 @@ static void ocelot_ace_rule_del(struct ocelot *ocelot,
block->count--;
}
-int ocelot_ace_rule_offload_del(struct ocelot *ocelot,
+int ocelot_ace_rule_offload_del(struct ocelot *ocelot, int block_id,
struct ocelot_ace_rule *rule)
{
- struct ocelot_acl_block *block = >acl_block;
+ struct ocelot_acl_block *block = >acl_block[block_id];
struct ocelot_ace_rule del_ace;
struct ocelot_ace_rule *ace;
int i, index;
@@ -921,29 +937,29 @@ int ocelot_ace_rule_offload_del(struct ocelot *ocelot,
/* Move up all the blocks over the
Re: [PATCH V3 1/3] dt-bindings: mailbox: imx-mu: support i.MX8M
On Mon, Jun 01, 2020 at 04:20:00PM +0800, peng@nxp.com wrote: > From: Peng Fan > > Add i.MX8MQ/M/N/P compatible string to support i.MX8M SoCs > > Reviewed-by: Dong Aisheng > Signed-off-by: Peng Fan > --- > Documentation/devicetree/bindings/mailbox/fsl,mu.txt | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/Documentation/devicetree/bindings/mailbox/fsl,mu.txt > b/Documentation/devicetree/bindings/mailbox/fsl,mu.txt > index 26b7a88c2fea..906377acf2cd 100644 > --- a/Documentation/devicetree/bindings/mailbox/fsl,mu.txt > +++ b/Documentation/devicetree/bindings/mailbox/fsl,mu.txt > @@ -18,7 +18,8 @@ Messaging Unit Device Node: > Required properties: > --- > - compatible : should be "fsl,-mu", the supported chips include > - imx6sx, imx7s, imx8qxp, imx8qm. > + imx6sx, imx7s, imx8qxp, imx8qm, imx8mq, imx8mm, imx8mn, > + imx8mp. > The "fsl,imx6sx-mu" compatible is seen as generic and should > be included together with SoC specific compatible. > There is a version 1.0 MU on imx7ulp, use "fsl,imx7ulp-mu" > -- > 2.16.4 > > Hi Peng, The fsl,mu.yaml was already taken by Rob, so one or other patch will break by merge. I assume you should drop this change. Regards, Oleksij -- Pengutronix e.K. | | Steuerwalder Str. 21 | http://www.pengutronix.de/ | 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | signature.asc Description: PGP signature
[PATCH] spi: tegra20-slink: add missing pm_runtime_put if pm_runtime_get_sync fails
Call to pm_runtime_get_sync increments counter even in case of
failure leading to incorrect ref count.
Call pm_runtime_put if pm_runtime_get_sync fails.
Signed-off-by: Navid Emamdoost
---
drivers/spi/spi-tegra20-slink.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/spi/spi-tegra20-slink.c b/drivers/spi/spi-tegra20-slink.c
index 7f4d932dade7..9509b7cb14e4 100644
--- a/drivers/spi/spi-tegra20-slink.c
+++ b/drivers/spi/spi-tegra20-slink.c
@@ -756,6 +756,7 @@ static int tegra_slink_setup(struct spi_device *spi)
ret = pm_runtime_get_sync(tspi->dev);
if (ret < 0) {
dev_err(tspi->dev, "pm runtime failed, e = %d\n", ret);
+ pm_runtime_put(tspi->dev);
return ret;
}
--
2.17.1
Re: [PATCH v6 0/2] Append new variables to vmcoreinfo (TCR_EL1.T1SZ for arm64 and MAX_PHYSMEM_BITS for all archs)
Hello, On Thu, May 14, 2020 at 12:22 AM Bhupesh Sharma wrote: > > Apologies for the delayed update. Its been quite some time since I > posted the last version (v5), but I have been really caught up in some > other critical issues. > > Changes since v5: > > - v5 can be viewed here: > http://lists.infradead.org/pipermail/kexec/2019-November/024055.html > - Addressed review comments from James Morse and Boris. > - Added Tested-by received from John on v5 patchset. > - Rebased against arm64 (for-next/ptr-auth) branch which has Amit's > patchset for ARMv8.3-A Pointer Authentication feature vmcoreinfo > applied. > > Changes since v4: > > - v4 can be seen here: > http://lists.infradead.org/pipermail/kexec/2019-November/023961.html > - Addressed comments from Dave and added patches for documenting > new variables appended to vmcoreinfo documentation. > - Added testing report shared by Akashi for PATCH 2/5. > > Changes since v3: > > - v3 can be seen here: > http://lists.infradead.org/pipermail/kexec/2019-March/022590.html > - Addressed comments from James and exported TCR_EL1.T1SZ in vmcoreinfo > instead of PTRS_PER_PGD. > - Added a new patch (via [PATCH 3/3]), which fixes a simple typo in > 'Documentation/arm64/memory.rst' > > Changes since v2: > > - v2 can be seen here: > http://lists.infradead.org/pipermail/kexec/2019-March/022531.html > - Protected 'MAX_PHYSMEM_BITS' vmcoreinfo variable under CONFIG_SPARSEMEM > ifdef sections, as suggested by Kazu. > - Updated vmcoreinfo documentation to add description about > 'MAX_PHYSMEM_BITS' variable (via [PATCH 3/3]). > > Changes since v1: > > - v1 was sent out as a single patch which can be seen here: > http://lists.infradead.org/pipermail/kexec/2019-February/022411.html > > - v2 breaks the single patch into two independent patches: > [PATCH 1/2] appends 'PTRS_PER_PGD' to vmcoreinfo for arm64 arch, whereas > [PATCH 2/2] appends 'MAX_PHYSMEM_BITS' to vmcoreinfo in core kernel code > (all archs) > > This patchset primarily fixes the regression reported in user-space > utilities like 'makedumpfile' and 'crash-utility' on arm64 architecture > with the availability of 52-bit address space feature in underlying > kernel. These regressions have been reported both on CPUs which don't > support ARMv8.2 extensions (i.e. LVA, LPA) and are running newer kernels > and also on prototype platforms (like ARMv8 FVP simulator model) which > support ARMv8.2 extensions and are running newer kernels. > > The reason for these regressions is that right now user-space tools > have no direct access to these values (since these are not exported > from the kernel) and hence need to rely on a best-guess method of > determining value of 'vabits_actual' and 'MAX_PHYSMEM_BITS' supported > by underlying kernel. > > Exporting these values via vmcoreinfo will help user-land in such cases. > In addition, as per suggestion from makedumpfile maintainer (Kazu), > it makes more sense to append 'MAX_PHYSMEM_BITS' to > vmcoreinfo in the core code itself rather than in arm64 arch-specific > code, so that the user-space code for other archs can also benefit from > this addition to the vmcoreinfo and use it as a standard way of > determining 'SECTIONS_SHIFT' value in user-land. > > Cc: Boris Petkov > Cc: Ingo Molnar > Cc: Thomas Gleixner > Cc: Jonathan Corbet > Cc: James Morse > Cc: Mark Rutland > Cc: Will Deacon > Cc: Steve Capper > Cc: Catalin Marinas > Cc: Ard Biesheuvel > Cc: Michael Ellerman > Cc: Paul Mackerras > Cc: Benjamin Herrenschmidt > Cc: Dave Anderson > Cc: Kazuhito Hagio > Cc: John Donnelly > Cc: scott.bran...@broadcom.com > Cc: Amit Kachhap > Cc: x...@kernel.org > Cc: linuxppc-...@lists.ozlabs.org > Cc: linux-arm-ker...@lists.infradead.org > Cc: linux-kernel@vger.kernel.org > Cc: linux-...@vger.kernel.org > Cc: ke...@lists.infradead.org > > Bhupesh Sharma (2): > crash_core, vmcoreinfo: Append 'MAX_PHYSMEM_BITS' to vmcoreinfo > arm64/crash_core: Export TCR_EL1.T1SZ in vmcoreinfo > > Documentation/admin-guide/kdump/vmcoreinfo.rst | 16 > arch/arm64/include/asm/pgtable-hwdef.h | 1 + > arch/arm64/kernel/crash_core.c | 10 ++ > kernel/crash_core.c| 1 + > 4 files changed, 28 insertions(+) Ping. @James Morse , Others Please share if you have some comments regarding this patchset. Thanks, Bhupesh
[PATCH] wireless: ath10k: Return early in ath10k_qmi_event_server_exit() to avoid hard crash on reboot
Ever since 5.7-rc1, if we call ath10k_qmi_remove_msa_permission(), the db845c hard crashes on reboot, resulting in the device getting stuck in the usb crash debug mode and not coming back up wihthout a hard power off. This hack avoids the issue by returning early in ath10k_qmi_event_server_exit(). A better solution is very much desired! Feedback and suggestions welcome! Cc: Rakesh Pillai Cc: Govind Singh Cc: Bjorn Andersson Cc: Niklas Cassel Cc: Manivannan Sadhasivam Cc: Amit Pundir Cc: Brian Norris Cc: Kalle Valo Cc: ath...@lists.infradead.org Reported-by: Amit Pundir Signed-off-by: John Stultz --- drivers/net/wireless/ath/ath10k/qmi.c | 5 + 1 file changed, 5 insertions(+) diff --git a/drivers/net/wireless/ath/ath10k/qmi.c b/drivers/net/wireless/ath/ath10k/qmi.c index 85dce43c5439..ab38562ce1cb 100644 --- a/drivers/net/wireless/ath/ath10k/qmi.c +++ b/drivers/net/wireless/ath/ath10k/qmi.c @@ -854,6 +854,11 @@ static void ath10k_qmi_event_server_exit(struct ath10k_qmi *qmi) struct ath10k *ar = qmi->ar; struct ath10k_snoc *ar_snoc = ath10k_snoc_priv(ar); + /* +* HACK: Calling ath10k_qmi_remove_msa_permission causes +* hardware to hard crash on reboot +*/ + return; ath10k_qmi_remove_msa_permission(qmi); ath10k_core_free_board_files(ar); if (!test_bit(ATH10K_SNOC_FLAG_UNREGISTERING, _snoc->flags)) -- 2.17.1
[PATCH v2 net-next 04/10] net: mscc: ocelot: change vcap to be compatible with full and quad entry
When calculating vcap data offset, the function only supports half key entry. This patch modify vcap_data_offset_get function to calculate a correct data offset when setting VCAP Type-Group to VCAP_TG_FULL or VCAP_TG_QUARTER. Signed-off-by: Xiaoliang Yang --- drivers/net/ethernet/mscc/ocelot_ace.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/net/ethernet/mscc/ocelot_ace.c b/drivers/net/ethernet/mscc/ocelot_ace.c index b76593b40097..8c384b0771bb 100644 --- a/drivers/net/ethernet/mscc/ocelot_ace.c +++ b/drivers/net/ethernet/mscc/ocelot_ace.c @@ -175,8 +175,8 @@ static void vcap_data_offset_get(const struct vcap_props *vcap, u32 i, col, offset, count, cnt, base; u32 width = vcap->tg_width; - count = (data->tg_sw == VCAP_TG_HALF ? 2 : 4); - col = (ix % 2); + count = (1 << (data->tg_sw - 1)); + col = (ix % count); cnt = (vcap->sw_count / count); base = (vcap->sw_count - col * cnt - cnt); data->tg_value = 0; -- 2.17.1
[PATCH v2 net-next 10/10] net: dsa: tag_ocelot: use VLAN information from tagging header when available
From: Vladimir Oltean
When the Extraction Frame Header contains a valid classified VLAN, use
that instead of the VLAN header present in the packet.
Signed-off-by: Vladimir Oltean
---
net/dsa/tag_ocelot.c | 29 +
1 file changed, 29 insertions(+)
diff --git a/net/dsa/tag_ocelot.c b/net/dsa/tag_ocelot.c
index b0c98ee4e13b..253188b0e56b 100644
--- a/net/dsa/tag_ocelot.c
+++ b/net/dsa/tag_ocelot.c
@@ -181,9 +181,16 @@ static struct sk_buff *ocelot_rcv(struct sk_buff *skb,
struct net_device *netdev,
struct packet_type *pt)
{
+ struct dsa_port *cpu_dp = netdev->dsa_ptr;
+ struct dsa_switch *ds = cpu_dp->ds;
+ struct ocelot *ocelot = ds->priv;
+ struct ocelot_port *ocelot_port;
u64 src_port, qos_class;
u8 *start = skb->data;
+ struct ethhdr *hdr;
u8 *extraction;
+ u64 vlan_tci;
+ u16 vid;
/* Revert skb->data by the amount consumed by the DSA master,
* so it points to the beginning of the frame.
@@ -211,6 +218,7 @@ static struct sk_buff *ocelot_rcv(struct sk_buff *skb,
packing(extraction, _port, 46, 43, OCELOT_TAG_LEN, UNPACK, 0);
packing(extraction, _class, 19, 17, OCELOT_TAG_LEN, UNPACK, 0);
+ packing(extraction, _tci, 15, 0, OCELOT_TAG_LEN, UNPACK, 0);
skb->dev = dsa_master_find_slave(netdev, 0, src_port);
if (!skb->dev)
@@ -225,6 +233,27 @@ static struct sk_buff *ocelot_rcv(struct sk_buff *skb,
skb->offload_fwd_mark = 1;
skb->priority = qos_class;
+ /* The VID from the extraction header contains the classified VLAN. But
+* if VLAN awareness is off and no retagging is done via VCAP IS1, that
+* classified VID will always be the pvid of the src_port.
+* port. We want Linux to see the classified VID, but only if the switch
+* intended to send the packet as untagged, i.e. if the VID is different
+* than the CPU port's untagged (native) VID.
+*/
+ vid = vlan_tci & VLAN_VID_MASK;
+ hdr = eth_hdr(skb);
+ ocelot_port = ocelot->ports[src_port];
+ if (hdr->h_proto == htons(ETH_P_8021Q) && vid != ocelot_port->pvid) {
+ u16 dummy_vlan_tci;
+
+ skb_push_rcsum(skb, ETH_HLEN);
+ __skb_vlan_pop(skb, _vlan_tci);
+ skb_pull_rcsum(skb, ETH_HLEN);
+ skb_reset_network_header(skb);
+ skb_reset_transport_header(skb);
+ __vlan_hwaccel_put_tag(skb, htons(ETH_P_8021Q), vlan_tci);
+ }
+
return skb;
}
--
2.17.1
[PATCH v2 net-next 05/10] net: mscc: ocelot: VCAP IS1 support
VCAP IS1 is a VCAP module which can filter MAC, IP, VLAN, protocol, and
TCP/UDP ports keys, and do Qos classified and VLAN retag actions.
This patch added VCAP IS1 support in ocelot ace driver, which can supports
vlan modify and skbedit priority action of tc filter.
Usage:
tc qdisc add dev swp0 ingress
tc filter add dev swp0 protocol 802.1Q parent : flower \
skip_sw vlan_id 1 vlan_prio 1 action vlan modify id 2 priority 2
Signed-off-by: Xiaoliang Yang
---
drivers/net/dsa/ocelot/felix_vsc9959.c| 102 +++
drivers/net/ethernet/mscc/ocelot.c| 7 +
drivers/net/ethernet/mscc/ocelot_ace.c| 198 +-
drivers/net/ethernet/mscc/ocelot_ace.h| 11 ++
drivers/net/ethernet/mscc/ocelot_flower.c | 11 ++
drivers/net/ethernet/mscc/ocelot_regs.c | 1 +
include/soc/mscc/ocelot.h | 1 +
include/soc/mscc/ocelot_vcap.h| 91 ++
8 files changed, 421 insertions(+), 1 deletion(-)
diff --git a/drivers/net/dsa/ocelot/felix_vsc9959.c
b/drivers/net/dsa/ocelot/felix_vsc9959.c
index ef3bf875e64c..f08a5f1c61a5 100644
--- a/drivers/net/dsa/ocelot/felix_vsc9959.c
+++ b/drivers/net/dsa/ocelot/felix_vsc9959.c
@@ -16,6 +16,8 @@
#define VSC9959_VCAP_IS2_CNT 1024
#define VSC9959_VCAP_IS2_ENTRY_WIDTH 376
#define VSC9959_VCAP_PORT_CNT 6
+#define VSC9959_VCAP_IS1_CNT 256
+#define VSC9959_VCAP_IS1_ENTRY_WIDTH 376
/* TODO: should find a better place for these */
#define USXGMII_BMCR_RESET BIT(15)
@@ -337,6 +339,7 @@ static const u32 *vsc9959_regmap[] = {
[QSYS] = vsc9959_qsys_regmap,
[REW] = vsc9959_rew_regmap,
[SYS] = vsc9959_sys_regmap,
+ [S1]= vsc9959_vcap_regmap,
[S2]= vsc9959_vcap_regmap,
[PTP] = vsc9959_ptp_regmap,
[GCB] = vsc9959_gcb_regmap,
@@ -369,6 +372,11 @@ static const struct resource vsc9959_target_io_res[] = {
.end= 0x001,
.name = "sys",
},
+ [S1] = {
+ .start = 0x005,
+ .end= 0x00503ff,
+ .name = "s1",
+ },
[S2] = {
.start = 0x006,
.end= 0x00603ff,
@@ -559,6 +567,80 @@ static const struct ocelot_stat_layout
vsc9959_stats_layout[] = {
{ .offset = 0x111, .name = "drop_green_prio_7", },
};
+struct vcap_field vsc9959_vcap_is1_keys[] = {
+ [VCAP_IS1_HK_TYPE] = { 0, 1},
+ [VCAP_IS1_HK_LOOKUP]= { 1, 2},
+ [VCAP_IS1_HK_IGR_PORT_MASK] = { 3, 7},
+ [VCAP_IS1_HK_RSV] = { 10, 9},
+ [VCAP_IS1_HK_OAM_Y1731] = { 19, 1},
+ [VCAP_IS1_HK_L2_MC] = { 20, 1},
+ [VCAP_IS1_HK_L2_BC] = { 21, 1},
+ [VCAP_IS1_HK_IP_MC] = { 22, 1},
+ [VCAP_IS1_HK_VLAN_TAGGED] = { 23, 1},
+ [VCAP_IS1_HK_VLAN_DBL_TAGGED] = { 24, 1},
+ [VCAP_IS1_HK_TPID] = { 25, 1},
+ [VCAP_IS1_HK_VID] = { 26, 12},
+ [VCAP_IS1_HK_DEI] = { 38, 1},
+ [VCAP_IS1_HK_PCP] = { 39, 3},
+ /* Specific Fields for IS1 Half Key S1_NORMAL */
+ [VCAP_IS1_HK_L2_SMAC] = { 42, 48},
+ [VCAP_IS1_HK_ETYPE_LEN] = { 90, 1},
+ [VCAP_IS1_HK_ETYPE] = { 91, 16},
+ [VCAP_IS1_HK_IP_SNAP] = {107, 1},
+ [VCAP_IS1_HK_IP4] = {108, 1},
+ /* Layer-3 Information */
+ [VCAP_IS1_HK_L3_FRAGMENT] = {109, 1},
+ [VCAP_IS1_HK_L3_FRAG_OFS_GT0] = {110, 1},
+ [VCAP_IS1_HK_L3_OPTIONS]= {111, 1},
+ [VCAP_IS1_HK_L3_DSCP] = {112, 6},
+ [VCAP_IS1_HK_L3_IP4_SIP]= {118, 32},
+ /* Layer-4 Information */
+ [VCAP_IS1_HK_TCP_UDP] = {150, 1},
+ [VCAP_IS1_HK_TCP] = {151, 1},
+ [VCAP_IS1_HK_L4_SPORT] = {152, 16},
+ [VCAP_IS1_HK_L4_RNG]= {168, 8},
+ /* Specific Fields for IS1 Half Key S1_5TUPLE_IP4 */
+ [VCAP_IS1_HK_IP4_INNER_TPID]= { 42, 1},
+ [VCAP_IS1_HK_IP4_INNER_VID] = { 43, 12},
+ [VCAP_IS1_HK_IP4_INNER_DEI] = { 55, 1},
+ [VCAP_IS1_HK_IP4_INNER_PCP] = { 56, 3},
+ [VCAP_IS1_HK_IP4_IP4] = { 59, 1},
+ [VCAP_IS1_HK_IP4_L3_FRAGMENT] = { 60, 1},
+ [VCAP_IS1_HK_IP4_L3_FRAG_OFS_GT0] = { 61, 1},
+ [VCAP_IS1_HK_IP4_L3_OPTIONS]= { 62, 1},
+ [VCAP_IS1_HK_IP4_L3_DSCP] = { 63, 6},
+ [VCAP_IS1_HK_IP4_L3_IP4_DIP]
[PATCH v2 net-next 09/10] net: dsa: felix: correct VCAP IS2 keys offset
Some of IS2 IP4_TCP_UDP keys are not correct, like L4_DPORT, L4_SPORT
and other L4 keys. It causes the issue that VCAP IS2 could not filter
a right dst/src port for TCP/UDP packages.
Signed-off-by: Xiaoliang Yang
---
drivers/net/dsa/ocelot/felix_vsc9959.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/net/dsa/ocelot/felix_vsc9959.c
b/drivers/net/dsa/ocelot/felix_vsc9959.c
index fceba87509ba..539f3c062b50 100644
--- a/drivers/net/dsa/ocelot/felix_vsc9959.c
+++ b/drivers/net/dsa/ocelot/felix_vsc9959.c
@@ -730,17 +730,17 @@ struct vcap_field vsc9959_vcap_is2_keys[] = {
[VCAP_IS2_HK_DIP_EQ_SIP]= {118, 1},
/* IP4_TCP_UDP (TYPE=100) */
[VCAP_IS2_HK_TCP] = {119, 1},
- [VCAP_IS2_HK_L4_SPORT] = {120, 16},
- [VCAP_IS2_HK_L4_DPORT] = {136, 16},
+ [VCAP_IS2_HK_L4_DPORT] = {120, 16},
+ [VCAP_IS2_HK_L4_SPORT] = {136, 16},
[VCAP_IS2_HK_L4_RNG]= {152, 8},
[VCAP_IS2_HK_L4_SPORT_EQ_DPORT] = {160, 1},
[VCAP_IS2_HK_L4_SEQUENCE_EQ0] = {161, 1},
- [VCAP_IS2_HK_L4_URG]= {162, 1},
- [VCAP_IS2_HK_L4_ACK]= {163, 1},
- [VCAP_IS2_HK_L4_PSH]= {164, 1},
- [VCAP_IS2_HK_L4_RST]= {165, 1},
- [VCAP_IS2_HK_L4_SYN]= {166, 1},
- [VCAP_IS2_HK_L4_FIN]= {167, 1},
+ [VCAP_IS2_HK_L4_FIN]= {162, 1},
+ [VCAP_IS2_HK_L4_SYN]= {163, 1},
+ [VCAP_IS2_HK_L4_RST]= {164, 1},
+ [VCAP_IS2_HK_L4_PSH]= {165, 1},
+ [VCAP_IS2_HK_L4_ACK]= {166, 1},
+ [VCAP_IS2_HK_L4_URG]= {167, 1},
[VCAP_IS2_HK_L4_1588_DOM] = {168, 8},
[VCAP_IS2_HK_L4_1588_VER] = {176, 4},
/* IP4_OTHER (TYPE=101) */
--
2.17.1
[PATCH v2 net-next 08/10] net: ocelot: return error if rule is not found
Return error if rule is not found in rule list to avoid Kernel panic.
Signed-off-by: Xiaoliang Yang
---
drivers/net/ethernet/mscc/ocelot_ace.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/mscc/ocelot_ace.c
b/drivers/net/ethernet/mscc/ocelot_ace.c
index bf2b7a03c832..2ba2859fa2cd 100644
--- a/drivers/net/ethernet/mscc/ocelot_ace.c
+++ b/drivers/net/ethernet/mscc/ocelot_ace.c
@@ -982,9 +982,9 @@ static int ocelot_ace_rule_get_index_id(struct
ocelot_acl_block *block,
list_for_each_entry(tmp, >rules, list) {
++index;
if (rule->id == tmp->id)
- break;
+ return index;
}
- return index;
+ return -ENOENT;
}
static struct ocelot_ace_rule*
@@ -1197,6 +1197,8 @@ int ocelot_ace_rule_offload_del(struct ocelot *ocelot,
int block_id,
/* Gets index of the rule */
index = ocelot_ace_rule_get_index_id(block, rule);
+ if (index < 0)
+ return -ENOENT;
/* Delete rule */
ocelot_ace_rule_del(ocelot, block, rule);
@@ -1221,6 +1223,9 @@ int ocelot_ace_rule_stats_update(struct ocelot *ocelot,
int block_id,
int index;
index = ocelot_ace_rule_get_index_id(block, rule);
+ if (index < 0)
+ return -ENOENT;
+
vcap_entry_get(ocelot, rule, index, block_id);
/* After we get the result we need to clear the counters */
--
2.17.1
[PATCH v2 net-next 07/10] net: mscc: ocelot: multiple actions support
Support multiple actions for each flower rule, multiple actions can only
set on the same VCAP, and all actions can mix with action goto chain.
Action drop, trap, and police on VCAP IS2 could not be mixed.
Signed-off-by: Xiaoliang Yang
---
drivers/net/ethernet/mscc/ocelot_ace.c| 15 +--
drivers/net/ethernet/mscc/ocelot_ace.h| 8 +++-
drivers/net/ethernet/mscc/ocelot_flower.c | 14 +-
3 files changed, 25 insertions(+), 12 deletions(-)
diff --git a/drivers/net/ethernet/mscc/ocelot_ace.c
b/drivers/net/ethernet/mscc/ocelot_ace.c
index 76d679b8d15e..bf2b7a03c832 100644
--- a/drivers/net/ethernet/mscc/ocelot_ace.c
+++ b/drivers/net/ethernet/mscc/ocelot_ace.c
@@ -651,20 +651,23 @@ static void is1_action_set(struct ocelot *ocelot, struct
vcap_data *data,
const struct vcap_props *vcap = >vcap[VCAP_IS1];
switch (ace->action) {
+ case OCELOT_ACL_ACTION_PRIORITY:
case OCELOT_ACL_ACTION_VLAN_MODIFY:
- vcap_action_set(vcap, data, VCAP_IS1_ACT_VID_REPLACE_ENA, 1);
+ vcap_action_set(vcap, data, VCAP_IS1_ACT_VID_REPLACE_ENA,
+ ace->vlan_modify.ena);
vcap_action_set(vcap, data, VCAP_IS1_ACT_VID_ADD_VAL,
ace->vlan_modify.vid);
- vcap_action_set(vcap, data, VCAP_IS1_ACT_PCP_DEI_ENA, 1);
+ vcap_action_set(vcap, data, VCAP_IS1_ACT_PCP_DEI_ENA,
+ ace->vlan_modify.ena);
vcap_action_set(vcap, data, VCAP_IS1_ACT_PCP_VAL,
ace->vlan_modify.pcp);
vcap_action_set(vcap, data, VCAP_IS1_ACT_DEI_VAL,
ace->vlan_modify.dei);
- break;
- case OCELOT_ACL_ACTION_PRIORITY:
- vcap_action_set(vcap, data, VCAP_IS1_ACT_QOS_ENA, 1);
+
+ vcap_action_set(vcap, data, VCAP_IS1_ACT_QOS_ENA,
+ ace->qos_modify.ena);
vcap_action_set(vcap, data, VCAP_IS1_ACT_QOS_VAL,
- ace->qos_val);
+ ace->qos_modify.qos_val);
break;
default:
break;
diff --git a/drivers/net/ethernet/mscc/ocelot_ace.h
b/drivers/net/ethernet/mscc/ocelot_ace.h
index 70fe45d747fb..02fa81b3fe92 100644
--- a/drivers/net/ethernet/mscc/ocelot_ace.h
+++ b/drivers/net/ethernet/mscc/ocelot_ace.h
@@ -97,6 +97,12 @@ struct ocelot_ace_action_vlan {
u16 vid;
u8 pcp;
u8 dei;
+ u8 ena;
+};
+
+struct ocelot_ace_action_qos {
+ u8 qos_val;
+ u8 ena;
};
struct ocelot_ace_frame_etype {
@@ -212,6 +218,7 @@ struct ocelot_ace_rule {
enum ocelot_vcap_bit dmac_bc;
struct ocelot_ace_vlan vlan;
struct ocelot_ace_action_vlan vlan_modify;
+ struct ocelot_ace_action_qos qos_modify;
enum ocelot_ace_type type;
union {
@@ -225,7 +232,6 @@ struct ocelot_ace_rule {
} frame;
struct ocelot_policer pol;
u32 pol_ix;
- u8 qos_val;
};
int ocelot_ace_rule_offload_add(struct ocelot *ocelot, int block_id,
diff --git a/drivers/net/ethernet/mscc/ocelot_flower.c
b/drivers/net/ethernet/mscc/ocelot_flower.c
index d598e103c796..6ce37f152f12 100644
--- a/drivers/net/ethernet/mscc/ocelot_flower.c
+++ b/drivers/net/ethernet/mscc/ocelot_flower.c
@@ -32,9 +32,6 @@ static int ocelot_flower_parse_action(struct flow_cls_offload
*f,
s64 burst;
u64 rate;
- if (!flow_offload_has_one_action(>rule->action))
- return -EOPNOTSUPP;
-
if (!flow_action_basic_hw_stats_check(>rule->action,
f->common.extack))
return -EOPNOTSUPP;
@@ -42,14 +39,20 @@ static int ocelot_flower_parse_action(struct
flow_cls_offload *f,
flow_action_for_each(i, a, >rule->action) {
switch (a->id) {
case FLOW_ACTION_DROP:
+ if (i)
+ return -EOPNOTSUPP;
ace->action = OCELOT_ACL_ACTION_DROP;
allowed_chain = 1;
break;
case FLOW_ACTION_TRAP:
+ if (i)
+ return -EOPNOTSUPP;
ace->action = OCELOT_ACL_ACTION_TRAP;
allowed_chain = 1;
break;
case FLOW_ACTION_POLICE:
+ if (i)
+ return -EOPNOTSUPP;
ace->action = OCELOT_ACL_ACTION_POLICE;
rate = a->police.rate_bytes_ps;
ace->pol.rate = div_u64(rate, 1000) * 8;
@@ -62,18 +65,19 @@ static int ocelot_flower_parse_action(struct
flow_cls_offload *f,
NL_SET_ERR_MSG_MOD(extack, "HW only support
goto next chain\n");
[PATCH v2 net-next 06/10] net: mscc: ocelot: VCAP ES0 support
VCAP ES0 is an egress VCAP working on all outgoing frames.
This patch added ES0 driver to support vlan push action of tc filter.
Usage:
tc filter add dev swp1 egress protocol 802.1Q flower skip_sw
vlan_id 1 vlan_prio 1 action vlan push id 2 priority 2
Signed-off-by: Xiaoliang Yang
---
drivers/net/dsa/ocelot/felix_vsc9959.c| 59 ++
drivers/net/ethernet/mscc/ocelot.c| 4 ++
drivers/net/ethernet/mscc/ocelot_ace.c| 74 ++-
drivers/net/ethernet/mscc/ocelot_ace.h| 2 +
drivers/net/ethernet/mscc/ocelot_flower.c | 29 ++---
include/soc/mscc/ocelot.h | 1 +
include/soc/mscc/ocelot_vcap.h| 42 +
7 files changed, 203 insertions(+), 8 deletions(-)
diff --git a/drivers/net/dsa/ocelot/felix_vsc9959.c
b/drivers/net/dsa/ocelot/felix_vsc9959.c
index f08a5f1c61a5..fceba87509ba 100644
--- a/drivers/net/dsa/ocelot/felix_vsc9959.c
+++ b/drivers/net/dsa/ocelot/felix_vsc9959.c
@@ -18,6 +18,7 @@
#define VSC9959_VCAP_PORT_CNT 6
#define VSC9959_VCAP_IS1_CNT 256
#define VSC9959_VCAP_IS1_ENTRY_WIDTH 376
+#define VSC9959_VCAP_ES0_CNT1024
/* TODO: should find a better place for these */
#define USXGMII_BMCR_RESET BIT(15)
@@ -339,6 +340,7 @@ static const u32 *vsc9959_regmap[] = {
[QSYS] = vsc9959_qsys_regmap,
[REW] = vsc9959_rew_regmap,
[SYS] = vsc9959_sys_regmap,
+ [S0]= vsc9959_vcap_regmap,
[S1]= vsc9959_vcap_regmap,
[S2]= vsc9959_vcap_regmap,
[PTP] = vsc9959_ptp_regmap,
@@ -372,6 +374,11 @@ static const struct resource vsc9959_target_io_res[] = {
.end= 0x001,
.name = "sys",
},
+ [S0] = {
+ .start = 0x004,
+ .end= 0x00403ff,
+ .name = "s0",
+ },
[S1] = {
.start = 0x005,
.end= 0x00503ff,
@@ -567,6 +574,38 @@ static const struct ocelot_stat_layout
vsc9959_stats_layout[] = {
{ .offset = 0x111, .name = "drop_green_prio_7", },
};
+struct vcap_field vsc9959_vcap_es0_keys[] = {
+ [VCAP_ES0_EGR_PORT] = { 0, 3},
+ [VCAP_ES0_IGR_PORT] = { 3, 3},
+ [VCAP_ES0_RSV] = { 6, 2},
+ [VCAP_ES0_L2_MC]= { 8, 1},
+ [VCAP_ES0_L2_BC]= { 9, 1},
+ [VCAP_ES0_VID] = { 10, 12},
+ [VCAP_ES0_DP] = { 22, 1},
+ [VCAP_ES0_PCP] = { 23, 3},
+};
+
+struct vcap_field vsc9959_vcap_es0_actions[] = {
+ [VCAP_ES0_ACT_PUSH_OUTER_TAG] = { 0, 2},
+ [VCAP_ES0_ACT_PUSH_INNER_TAG] = { 2, 1},
+ [VCAP_ES0_ACT_TAG_A_TPID_SEL] = { 3, 2},
+ [VCAP_ES0_ACT_TAG_A_VID_SEL]= { 5, 1},
+ [VCAP_ES0_ACT_TAG_A_PCP_SEL]= { 6, 2},
+ [VCAP_ES0_ACT_TAG_A_DEI_SEL]= { 8, 2},
+ [VCAP_ES0_ACT_TAG_B_TPID_SEL] = { 10, 2},
+ [VCAP_ES0_ACT_TAG_B_VID_SEL]= { 12, 1},
+ [VCAP_ES0_ACT_TAG_B_PCP_SEL]= { 13, 2},
+ [VCAP_ES0_ACT_TAG_B_DEI_SEL]= { 15, 2},
+ [VCAP_ES0_ACT_VID_A_VAL]= { 17, 12},
+ [VCAP_ES0_ACT_PCP_A_VAL]= { 29, 3},
+ [VCAP_ES0_ACT_DEI_A_VAL]= { 32, 1},
+ [VCAP_ES0_ACT_VID_B_VAL]= { 33, 12},
+ [VCAP_ES0_ACT_PCP_B_VAL]= { 45, 3},
+ [VCAP_ES0_ACT_DEI_B_VAL]= { 48, 1},
+ [VCAP_ES0_ACT_RSV] = { 49, 23},
+ [VCAP_ES0_ACT_HIT_STICKY] = { 72, 1},
+};
+
struct vcap_field vsc9959_vcap_is1_keys[] = {
[VCAP_IS1_HK_TYPE] = { 0, 1},
[VCAP_IS1_HK_LOOKUP]= { 1, 2},
@@ -740,6 +779,26 @@ struct vcap_field vsc9959_vcap_is2_actions[] = {
};
static const struct vcap_props vsc9959_vcap_props[] = {
+ [VCAP_ES0] = {
+ .tg_width = 1,
+ .sw_count = 1,
+ .entry_count = VSC9959_VCAP_ES0_CNT,
+ .entry_width = 29,
+ .action_count = VSC9959_VCAP_ES0_CNT + 6,
+ .action_width = 72,
+ .action_type_width = 0,
+ .action_table = {
+ [ES0_ACTION_TYPE_NORMAL] = {
+ .width = 72,
+ .count = 1
+ },
+ },
+ .counter_words = 1,
+ .counter_width = 1,
+ .target = S0,
+ .keys = vsc9959_vcap_es0_keys,
+ .actions = vsc9959_vcap_es0_actions,
+ },
[VCAP_IS1] = {
.tg_width = 2,
.sw_count = 4,
diff
[PATCH v2 net-next 02/10] net: mscc: ocelot: generalize existing code for VCAP
From: Vladimir Oltean
The Ocelot driver only supports VCAP IS2, the security enforcement block
which implements Access Control List actions (trap, drop, police).
In preparation of VCAP IS1 support, generalize the existing code to work
with any VCAP. In that direction, move all VCAP instantiation-specific
data to struct vcap_props, and pass that as an argument to each function
that does the key and action packing. Only the high-level functions need
to have access to ocelot->vcap[VCAP_IS2].
Signed-off-by: Vladimir Oltean
Signed-off-by: Xiaoliang Yang
---
drivers/net/dsa/ocelot/felix.c| 2 -
drivers/net/dsa/ocelot/felix.h| 2 -
drivers/net/dsa/ocelot/felix_vsc9959.c| 25 +-
drivers/net/ethernet/mscc/ocelot_ace.c| 400 --
drivers/net/ethernet/mscc/ocelot_board.c | 5 +-
drivers/net/ethernet/mscc/ocelot_flower.c | 1 +
drivers/net/ethernet/mscc/ocelot_regs.c | 20 +-
drivers/net/ethernet/mscc/ocelot_s2.h | 64
include/soc/mscc/ocelot.h | 21 +-
include/soc/mscc/ocelot_vcap.h| 62
10 files changed, 313 insertions(+), 289 deletions(-)
delete mode 100644 drivers/net/ethernet/mscc/ocelot_s2.h
diff --git a/drivers/net/dsa/ocelot/felix.c b/drivers/net/dsa/ocelot/felix.c
index 66648986e6e3..4508d6063fd9 100644
--- a/drivers/net/dsa/ocelot/felix.c
+++ b/drivers/net/dsa/ocelot/felix.c
@@ -432,8 +432,6 @@ static int felix_init_structs(struct felix *felix, int
num_phys_ports)
ocelot->num_stats = felix->info->num_stats;
ocelot->shared_queue_sz = felix->info->shared_queue_sz;
ocelot->num_mact_rows = felix->info->num_mact_rows;
- ocelot->vcap_is2_keys = felix->info->vcap_is2_keys;
- ocelot->vcap_is2_actions= felix->info->vcap_is2_actions;
ocelot->vcap= felix->info->vcap;
ocelot->ops = felix->info->ops;
diff --git a/drivers/net/dsa/ocelot/felix.h b/drivers/net/dsa/ocelot/felix.h
index a891736ca006..b1b6ecfa5a55 100644
--- a/drivers/net/dsa/ocelot/felix.h
+++ b/drivers/net/dsa/ocelot/felix.h
@@ -21,8 +21,6 @@ struct felix_info {
unsigned intnum_stats;
int num_ports;
int num_tx_queues;
- struct vcap_field *vcap_is2_keys;
- struct vcap_field *vcap_is2_actions;
const struct vcap_props *vcap;
int switch_pci_bar;
int imdio_pci_bar;
diff --git a/drivers/net/dsa/ocelot/felix_vsc9959.c
b/drivers/net/dsa/ocelot/felix_vsc9959.c
index 1dd9e348152d..ef3bf875e64c 100644
--- a/drivers/net/dsa/ocelot/felix_vsc9959.c
+++ b/drivers/net/dsa/ocelot/felix_vsc9959.c
@@ -156,14 +156,16 @@ static const u32 vsc9959_qs_regmap[] = {
REG_RESERVED(QS_INH_DBG),
};
-static const u32 vsc9959_s2_regmap[] = {
- REG(S2_CORE_UPDATE_CTRL,0x00),
- REG(S2_CORE_MV_CFG, 0x04),
- REG(S2_CACHE_ENTRY_DAT, 0x08),
- REG(S2_CACHE_MASK_DAT, 0x000108),
- REG(S2_CACHE_ACTION_DAT,0x000208),
- REG(S2_CACHE_CNT_DAT, 0x000308),
- REG(S2_CACHE_TG_DAT,0x000388),
+static const u32 vsc9959_vcap_regmap[] = {
+ /* VCAP_CORE_CFG */
+ REG(VCAP_CORE_UPDATE_CTRL, 0x00),
+ REG(VCAP_CORE_MV_CFG, 0x04),
+ /* VCAP_CORE_CACHE */
+ REG(VCAP_CACHE_ENTRY_DAT, 0x08),
+ REG(VCAP_CACHE_MASK_DAT,0x000108),
+ REG(VCAP_CACHE_ACTION_DAT, 0x000208),
+ REG(VCAP_CACHE_CNT_DAT, 0x000308),
+ REG(VCAP_CACHE_TG_DAT, 0x000388),
};
static const u32 vsc9959_qsys_regmap[] = {
@@ -335,7 +337,7 @@ static const u32 *vsc9959_regmap[] = {
[QSYS] = vsc9959_qsys_regmap,
[REW] = vsc9959_rew_regmap,
[SYS] = vsc9959_sys_regmap,
- [S2]= vsc9959_s2_regmap,
+ [S2]= vsc9959_vcap_regmap,
[PTP] = vsc9959_ptp_regmap,
[GCB] = vsc9959_gcb_regmap,
};
@@ -677,6 +679,9 @@ static const struct vcap_props vsc9959_vcap_props[] = {
},
.counter_words = 4,
.counter_width = 32,
+ .target = S2,
+ .keys = vsc9959_vcap_is2_keys,
+ .actions = vsc9959_vcap_is2_actions,
},
};
@@ -1401,8 +1406,6 @@ struct felix_info felix_info_vsc9959 = {
.ops= _ops,
.stats_layout = vsc9959_stats_layout,
.num_stats = ARRAY_SIZE(vsc9959_stats_layout),
- .vcap_is2_keys = vsc9959_vcap_is2_keys,
- .vcap_is2_actions = vsc9959_vcap_is2_actions,
.vcap = vsc9959_vcap_props,
.shared_queue_sz
[PATCH v2 net-next 01/10] net: mscc: ocelot: introduce a new ocelot_target_{read,write} API
From: Vladimir Oltean
There are some targets (register blocks) in the Ocelot switch that are
instantiated more than once. For example, the VCAP IS1, IS2 and ES0
blocks all share the same register layout for interacting with the cache
for the TCAM and the action RAM.
For the VCAPs, the procedure for servicing them is actually common. We
just need an API specifying which VCAP we are talking to, and we do that
via these raw ocelot_target_read and ocelot_target_write accessors.
In plain ocelot_read, the target is encoded into the register enum
itself:
u16 target = reg >> TARGET_OFFSET;
For the VCAPs, the registers are currently defined like this:
enum ocelot_reg {
[...]
S2_CORE_UPDATE_CTRL = S2 << TARGET_OFFSET,
S2_CORE_MV_CFG,
S2_CACHE_ENTRY_DAT,
S2_CACHE_MASK_DAT,
S2_CACHE_ACTION_DAT,
S2_CACHE_CNT_DAT,
S2_CACHE_TG_DAT,
[...]
};
which is precisely what we want to avoid, because we'd have to duplicate
the same register map for S1 and for S0, and then figure out how to pass
VCAP instance-specific registers to the ocelot_read calls (basically
another lookup table that undoes the effect of shifting with
TARGET_OFFSET).
So for some targets, propose a more raw API, similar to what is
currently done with ocelot_port_readl and ocelot_port_writel. Those
targets can only be accessed with ocelot_target_{read,write} and not
with ocelot_{read,write} after the conversion, which is fine.
The VCAP registers are not actually modified to use this new API as of
this patch. They will be modified in the next one.
Signed-off-by: Vladimir Oltean
---
drivers/net/ethernet/mscc/ocelot_io.c | 17 +
include/soc/mscc/ocelot.h | 14 ++
2 files changed, 31 insertions(+)
diff --git a/drivers/net/ethernet/mscc/ocelot_io.c
b/drivers/net/ethernet/mscc/ocelot_io.c
index b229b1cb68ef..9b52d82f5399 100644
--- a/drivers/net/ethernet/mscc/ocelot_io.c
+++ b/drivers/net/ethernet/mscc/ocelot_io.c
@@ -59,6 +59,23 @@ void ocelot_port_writel(struct ocelot_port *port, u32 val,
u32 reg)
}
EXPORT_SYMBOL(ocelot_port_writel);
+u32 __ocelot_target_read_ix(struct ocelot *ocelot, enum ocelot_target target,
+ u32 reg, u32 offset)
+{
+ u32 val;
+
+ regmap_read(ocelot->targets[target],
+ ocelot->map[target][reg] + offset, );
+ return val;
+}
+
+void __ocelot_target_write_ix(struct ocelot *ocelot, enum ocelot_target target,
+ u32 val, u32 reg, u32 offset)
+{
+ regmap_write(ocelot->targets[target],
+ocelot->map[target][reg] + offset, val);
+}
+
int ocelot_regfields_init(struct ocelot *ocelot,
const struct reg_field *const regfields)
{
diff --git a/include/soc/mscc/ocelot.h b/include/soc/mscc/ocelot.h
index 4953e9994df3..2ac08f3b8f68 100644
--- a/include/soc/mscc/ocelot.h
+++ b/include/soc/mscc/ocelot.h
@@ -578,6 +578,16 @@ struct ocelot_policer {
#define ocelot_rmw_rix(ocelot, val, m, reg, ri) __ocelot_rmw_ix(ocelot, val,
m, reg, reg##_RSZ * (ri))
#define ocelot_rmw(ocelot, val, m, reg) __ocelot_rmw_ix(ocelot, val, m, reg, 0)
+#define ocelot_target_read_ix(ocelot, target, reg, gi, ri)
__ocelot_target_read_ix(ocelot, target, reg, reg##_GSZ * (gi) + reg##_RSZ *
(ri))
+#define ocelot_target_read_gix(ocelot, target, reg, gi)
__ocelot_target_read_ix(ocelot, target, reg, reg##_GSZ * (gi))
+#define ocelot_target_read_rix(ocelot, target, reg, ri)
__ocelot_target_read_ix(ocelot, target, reg, reg##_RSZ * (ri))
+#define ocelot_target_read(ocelot, target, reg)
__ocelot_target_read_ix(ocelot, target, reg, 0)
+
+#define ocelot_target_write_ix(ocelot, target, val, reg, gi, ri)
__ocelot_target_write_ix(ocelot, target, val, reg, reg##_GSZ * (gi) + reg##_RSZ
* (ri))
+#define ocelot_target_write_gix(ocelot, target, val, reg, gi)
__ocelot_target_write_ix(ocelot, target, val, reg, reg##_GSZ * (gi))
+#define ocelot_target_write_rix(ocelot, target, val, reg, ri)
__ocelot_target_write_ix(ocelot, target, val, reg, reg##_RSZ * (ri))
+#define ocelot_target_write(ocelot, target, val, reg)
__ocelot_target_write_ix(ocelot, target, val, reg, 0)
+
/* I/O */
u32 ocelot_port_readl(struct ocelot_port *port, u32 reg);
void ocelot_port_writel(struct ocelot_port *port, u32 val, u32 reg);
@@ -585,6 +595,10 @@ u32 __ocelot_read_ix(struct ocelot *ocelot, u32 reg, u32
offset);
void __ocelot_write_ix(struct ocelot *ocelot, u32 val, u32 reg, u32 offset);
void __ocelot_rmw_ix(struct ocelot *ocelot, u32 val, u32 mask, u32 reg,
u32 offset);
+u32 __ocelot_target_read_ix(struct ocelot *ocelot, enum ocelot_target target,
+ u32 reg, u32 offset);
+void __ocelot_target_write_ix(struct ocelot *ocelot, enum ocelot_target target,
+ u32 val, u32 reg, u32 offset);
/* Hardware
[PATCH v2 net-next 00/10] net: ocelot: VCAP IS1 and ES0 support
This series patches adds support for VCAP IS1 and ES0 module, each VCAP
correspond to a flow chain to offload.
VCAP IS1 supports FLOW_ACTION_VLAN_MANGLE action to filter MAC, IP,
VLAN, protocol, and TCP/UDP ports keys and retag vlian tag,
FLOW_ACTION_PRIORITY action to classify packages to different Qos in hw.
VCAP ES0 supports FLOW_ACTION_VLAN_PUSH action to filter vlan keys
and push a specific vlan tag to frames.
Changes since v1->v2:
- Use different chain to assign rules to different hardware VCAP, and
use action goto chain to express flow order.
- Add FLOW_ACTION_PRIORITY to add Qos classification on VCAP IS1.
- Multiple actions support.
- Fix some code issues.
Vladimir Oltean (3):
net: mscc: ocelot: introduce a new ocelot_target_{read,write} API
net: mscc: ocelot: generalize existing code for VCAP
net: dsa: tag_ocelot: use VLAN information from tagging header when
available
Xiaoliang Yang (7):
net: mscc: ocelot: allocated rules to different hardware VCAP TCAMs by
chain index
net: mscc: ocelot: change vcap to be compatible with full and quad
entry
net: mscc: ocelot: VCAP IS1 support
net: mscc: ocelot: VCAP ES0 support
net: mscc: ocelot: multiple actions support
net: ocelot: return error if rule is not found
net: dsa: felix: correct VCAP IS2 keys offset
drivers/net/dsa/ocelot/felix.c| 2 -
drivers/net/dsa/ocelot/felix.h| 2 -
drivers/net/dsa/ocelot/felix_vsc9959.c| 202 +-
drivers/net/ethernet/mscc/ocelot.c| 11 +
drivers/net/ethernet/mscc/ocelot_ace.c| 729 --
drivers/net/ethernet/mscc/ocelot_ace.h| 26 +-
drivers/net/ethernet/mscc/ocelot_board.c | 5 +-
drivers/net/ethernet/mscc/ocelot_flower.c | 95 ++-
drivers/net/ethernet/mscc/ocelot_io.c | 17 +
drivers/net/ethernet/mscc/ocelot_regs.c | 21 +-
drivers/net/ethernet/mscc/ocelot_s2.h | 64 --
include/soc/mscc/ocelot.h | 39 +-
include/soc/mscc/ocelot_vcap.h| 199 +-
net/dsa/tag_ocelot.c | 29 +
14 files changed, 1105 insertions(+), 336 deletions(-)
delete mode 100644 drivers/net/ethernet/mscc/ocelot_s2.h
--
2.17.1
RE: [PATCH 2/4] firmware: imx: add resource management api
> Subject: RE: [PATCH 2/4] firmware: imx: add resource management api
>
> > From: Peng Fan
> > Sent: Thursday, April 23, 2020 3:00 PM
> >
> > Add resource management API, when we have multiple partition running
> > together, resources not owned to current partition should not be used.
> >
> > Reviewed-by: Leonard Crestez
> > Signed-off-by: Peng Fan
> > ---
> > drivers/firmware/imx/Makefile | 2 +-
> > drivers/firmware/imx/rm.c | 40 +
> > include/linux/firmware/imx/sci.h| 1 +
> > include/linux/firmware/imx/svc/rm.h | 69
> > +
> > 4 files changed, 111 insertions(+), 1 deletion(-) create mode 100644
> > drivers/firmware/imx/rm.c create mode 100644
> > include/linux/firmware/imx/svc/rm.h
> >
> > diff --git a/drivers/firmware/imx/Makefile
> > b/drivers/firmware/imx/Makefile index 08bc9ddfbdfb..17ea3613e142
> > 100644
> > --- a/drivers/firmware/imx/Makefile
> > +++ b/drivers/firmware/imx/Makefile
> > @@ -1,4 +1,4 @@
> > # SPDX-License-Identifier: GPL-2.0
> > obj-$(CONFIG_IMX_DSP) += imx-dsp.o
> > -obj-$(CONFIG_IMX_SCU) += imx-scu.o misc.o imx-scu-irq.o
> > +obj-$(CONFIG_IMX_SCU) += imx-scu.o misc.o imx-scu-irq.o rm.o
> > obj-$(CONFIG_IMX_SCU_PD) += scu-pd.o
> > diff --git a/drivers/firmware/imx/rm.c b/drivers/firmware/imx/rm.c new
> > file mode 100644 index ..7b0334de5486
> > --- /dev/null
> > +++ b/drivers/firmware/imx/rm.c
> > @@ -0,0 +1,40 @@
> > +// SPDX-License-Identifier: GPL-2.0+
> > +/*
> > + * Copyright 2020 NXP
> > + *
> > + * File containing client-side RPC functions for the RM service.
> > +These
> > + * function are ported to clients that communicate to the SC.
> > + */
> > +
> > +#include
> > +
> > +struct imx_sc_msg_rm_rsrc_owned {
> > + struct imx_sc_rpc_msg hdr;
> > + u16 resource;
> > +} __packed __aligned(4);
> > +
> > +/*
> > + * This function check @resource is owned by current partition or not
> > + *
> > + * @param[in] ipc IPC handle
> > + * @param[in] resourceresource the control is associated with
> > + *
> > + * @return Returns 0 for success and < 0 for errors.
> > + */
> > +bool imx_sc_rm_is_resource_owned(struct imx_sc_ipc *ipc, u16
> > +resource) {
> > + struct imx_sc_msg_rm_rsrc_owned msg;
> > + struct imx_sc_rpc_msg *hdr =
> > +
> > + hdr->ver = IMX_SC_RPC_VERSION;
> > + hdr->svc = IMX_SC_RPC_SVC_RM;
> > + hdr->func = IMX_SC_RM_FUNC_IS_RESOURCE_OWNED;
> > + hdr->size = 2;
> > +
> > + msg.resource = resource;
> > +
> > + imx_scu_call_rpc(ipc, , true);
>
> No need check err return?
No. it use hdr->func as the resource owner bool.
However imx_scu_call_rpc also use hdr->func
to check error value or not.
When hdr->func is 1, imx_sc_to_linux_errno
will report it -EINVAL. However here 1 means
not owned.
>
> > +
> > + return hdr->func;
> > +}
> > +EXPORT_SYMBOL(imx_sc_rm_is_resource_owned);
> > diff --git a/include/linux/firmware/imx/sci.h
> > b/include/linux/firmware/imx/sci.h
> > index 17ba4e405129..b5c5a56f29be 100644
> > --- a/include/linux/firmware/imx/sci.h
> > +++ b/include/linux/firmware/imx/sci.h
> > @@ -15,6 +15,7 @@
> >
> > #include #include
> >
> > +#include
> >
> > int imx_scu_enable_general_irq_channel(struct device *dev); int
> > imx_scu_irq_register_notifier(struct notifier_block *nb); diff --git
> > a/include/linux/firmware/imx/svc/rm.h
> > b/include/linux/firmware/imx/svc/rm.h
> > new file mode 100644
> > index ..fc6ea62d9d0e
> > --- /dev/null
> > +++ b/include/linux/firmware/imx/svc/rm.h
> > @@ -0,0 +1,69 @@
> > +/* SPDX-License-Identifier: GPL-2.0+ */
> > +/*
> > + * Copyright (C) 2016 Freescale Semiconductor, Inc.
> > + * Copyright 2017-2019 NXP
>
> Update copyright
ok
>
> > + *
> > + * Header file containing the public API for the System Controller
> > +(SC)
> > + * Power Management (PM) function. This includes functions for power
> > +state
> > + * control, clock control, reset control, and wake-up event control.
>
> Fix the code comments
>
> Otherwise, I'm fine with this patch.
Ok.
Thanks,
Peng.
>
> Regards
> Aisheng
>
> > + *
> > + * RM_SVC (SVC) Resource Management Service
> > + *
> > + * Module for the Resource Management (RM) service.
> > + */
> > +
> > +#ifndef _SC_RM_API_H
> > +#define _SC_RM_API_H
> > +
> > +#include
> > +
> > +/*
> > + * This type is used to indicate RPC RM function calls.
> > + */
> > +enum imx_sc_rm_func {
> > + IMX_SC_RM_FUNC_UNKNOWN = 0,
> > + IMX_SC_RM_FUNC_PARTITION_ALLOC = 1,
> > + IMX_SC_RM_FUNC_SET_CONFIDENTIAL = 31,
> > + IMX_SC_RM_FUNC_PARTITION_FREE = 2,
> > + IMX_SC_RM_FUNC_GET_DID = 26,
> > + IMX_SC_RM_FUNC_PARTITION_STATIC = 3,
> > + IMX_SC_RM_FUNC_PARTITION_LOCK = 4,
> > + IMX_SC_RM_FUNC_GET_PARTITION = 5,
> > + IMX_SC_RM_FUNC_SET_PARENT = 6,
> > + IMX_SC_RM_FUNC_MOVE_ALL = 7,
> > + IMX_SC_RM_FUNC_ASSIGN_RESOURCE = 8,
> > + IMX_SC_RM_FUNC_SET_RESOURCE_MOVABLE = 9,
> > +
[RESEND PATCH v1 5/6] staging: greybus: audio: Add helper APIs for dynamic audio modules
Greybus Codec driver allows modules to be dynamically added and removed,
which further requires updating the DAPM configurations as well.
With current snd_soc architecture, dynamic audio modules is not yet
supported. This patch provides helper APIs to update DAPM configurations
in response to modules which are dynamically added or removed. The
source is primarily based on snd_dapm.c
Signed-off-by: Vaibhav Agarwal
---
drivers/staging/greybus/Makefile | 2 +-
drivers/staging/greybus/audio_codec.c | 13 +-
drivers/staging/greybus/audio_helper.c | 197 +
drivers/staging/greybus/audio_helper.h | 17 +++
4 files changed, 224 insertions(+), 5 deletions(-)
create mode 100644 drivers/staging/greybus/audio_helper.c
create mode 100644 drivers/staging/greybus/audio_helper.h
diff --git a/drivers/staging/greybus/Makefile b/drivers/staging/greybus/Makefile
index 627e44f2a983..3b4b6cabff19 100644
--- a/drivers/staging/greybus/Makefile
+++ b/drivers/staging/greybus/Makefile
@@ -28,7 +28,7 @@ obj-$(CONFIG_GREYBUS_VIBRATOR)+= gb-vibrator.o
# Greybus Audio is a bunch of modules
gb-audio-module-y := audio_module.o audio_topology.o
-gb-audio-codec-y := audio_codec.o
+gb-audio-codec-y := audio_codec.o audio_helper.o
gb-audio-gb-y := audio_gb.o
gb-audio-apbridgea-y := audio_apbridgea.o
gb-audio-manager-y := audio_manager.o audio_manager_module.o
diff --git a/drivers/staging/greybus/audio_codec.c
b/drivers/staging/greybus/audio_codec.c
index bbd072acda5c..866b3342515f 100644
--- a/drivers/staging/greybus/audio_codec.c
+++ b/drivers/staging/greybus/audio_codec.c
@@ -14,6 +14,7 @@
#include "audio_codec.h"
#include "audio_apbridgea.h"
#include "audio_manager.h"
+#include "audio_helper.h"
static struct gbaudio_codec_info *gbcodec;
@@ -874,7 +875,7 @@ int gbaudio_register_module(struct gbaudio_module_info
*module)
/* card already instantiated, create widgets here only */
if (component->card->instantiated) {
- snd_soc_dapm_link_component_dai_widgets(component->card,
+ gbaudio_dapm_link_component_dai_widgets(component->card,
>dapm);
#ifdef CONFIG_SND_JACK
/*
@@ -1004,19 +1005,23 @@ void gbaudio_unregister_module(struct
gbaudio_module_info *module)
if (module->dapm_routes) {
dev_dbg(component->dev, "Removing %d routes\n",
module->num_dapm_routes);
+ /* verify routes with controls are removed */
snd_soc_dapm_del_routes(>dapm, module->dapm_routes,
module->num_dapm_routes);
}
if (module->controls) {
dev_dbg(component->dev, "Removing %d controls\n",
module->num_controls);
- snd_soc_remove_codec_controls(component, module->controls,
- module->num_controls);
+ /* release control semaphore */
+ up_write(>controls_rwsem);
+ gbaudio_remove_component_controls(component, module->controls,
+ module->num_controls);
+ down_write(>controls_rwsem);
}
if (module->dapm_widgets) {
dev_dbg(component->dev, "Removing %d widgets\n",
module->num_dapm_widgets);
- snd_soc_dapm_free_controls(>dapm,
+ gbaudio_dapm_free_controls(>dapm,
module->dapm_widgets,
module->num_dapm_widgets);
}
diff --git a/drivers/staging/greybus/audio_helper.c
b/drivers/staging/greybus/audio_helper.c
new file mode 100644
index ..e2f113a811ee
--- /dev/null
+++ b/drivers/staging/greybus/audio_helper.c
@@ -0,0 +1,197 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Greybus Audio Sound SoC helper APIs
+ */
+
+#include
+#include
+#include
+#include
+
+#define gbaudio_dapm_for_each_direction(dir) \
+ for ((dir) = SND_SOC_DAPM_DIR_IN; (dir) <= SND_SOC_DAPM_DIR_OUT; \
+ (dir)++)
+
+static void gbaudio_dapm_link_dai_widget(struct snd_soc_dapm_widget *dai_w,
+struct snd_soc_card *card)
+{
+ struct snd_soc_dapm_widget *w;
+ struct snd_soc_dapm_widget *src, *sink;
+ struct snd_soc_dai *dai = dai_w->priv;
+
+ /* ...find all widgets with the same stream and link them */
+ list_for_each_entry(w, >widgets, list) {
+ if (w->dapm != dai_w->dapm)
+ continue;
+
+ switch (w->id) {
+ case snd_soc_dapm_dai_in:
+ case snd_soc_dapm_dai_out:
+ continue;
+ default:
+ break;
+ }
+
+ if (!w->sname || !strstr(w->sname, dai_w->sname))
+
[RESEND PATCH v1 4/6] staging: greybus: audio: Resolve compilation error in topology parser
Fix compilation errors for GB Audio topology parser code with recent
kernel versions.
Signed-off-by: Vaibhav Agarwal
---
drivers/staging/greybus/audio_topology.c | 130 +++
1 file changed, 61 insertions(+), 69 deletions(-)
diff --git a/drivers/staging/greybus/audio_topology.c
b/drivers/staging/greybus/audio_topology.c
index 4ac30accf226..7d5e87341a5c 100644
--- a/drivers/staging/greybus/audio_topology.c
+++ b/drivers/staging/greybus/audio_topology.c
@@ -5,8 +5,8 @@
* Copyright 2015-2016 Linaro Ltd.
*/
+#include
#include "audio_codec.h"
-#include "greybus_protocols.h"
#define GBAUDIO_INVALID_ID 0xFF
@@ -165,15 +165,15 @@ static int gbcodec_mixer_ctl_info(struct snd_kcontrol
*kcontrol,
struct gbaudio_ctl_pvt *data;
struct gb_audio_ctl_elem_info *info;
struct gbaudio_module_info *module;
- struct snd_soc_codec *codec = snd_kcontrol_chip(kcontrol);
- struct gbaudio_codec_info *gbcodec = snd_soc_codec_get_drvdata(codec);
+ struct snd_soc_component *comp = snd_soc_kcontrol_component(kcontrol);
+ struct gbaudio_codec_info *gb = snd_soc_component_get_drvdata(comp);
- dev_dbg(codec->dev, "Entered %s:%s\n", __func__, kcontrol->id.name);
+ dev_dbg(comp->dev, "Entered %s:%s\n", __func__, kcontrol->id.name);
data = (struct gbaudio_ctl_pvt *)kcontrol->private_value;
info = (struct gb_audio_ctl_elem_info *)data->info;
if (!info) {
- dev_err(codec->dev, "NULL info for %s\n", uinfo->id.name);
+ dev_err(comp->dev, "NULL info for %s\n", uinfo->id.name);
return -EINVAL;
}
@@ -193,7 +193,7 @@ static int gbcodec_mixer_ctl_info(struct snd_kcontrol
*kcontrol,
uinfo->value.enumerated.items = max;
if (uinfo->value.enumerated.item > max - 1)
uinfo->value.enumerated.item = max - 1;
- module = find_gb_module(gbcodec, kcontrol->id.name);
+ module = find_gb_module(gb, kcontrol->id.name);
if (!module)
return -EINVAL;
name = gbaudio_map_controlid(module, data->ctl_id,
@@ -201,7 +201,7 @@ static int gbcodec_mixer_ctl_info(struct snd_kcontrol
*kcontrol,
strlcpy(uinfo->value.enumerated.name, name, NAME_SIZE);
break;
default:
- dev_err(codec->dev, "Invalid type: %d for %s:kcontrol\n",
+ dev_err(comp->dev, "Invalid type: %d for %s:kcontrol\n",
info->type, kcontrol->id.name);
break;
}
@@ -216,11 +216,11 @@ static int gbcodec_mixer_ctl_get(struct snd_kcontrol
*kcontrol,
struct gbaudio_ctl_pvt *data;
struct gb_audio_ctl_elem_value gbvalue;
struct gbaudio_module_info *module;
- struct snd_soc_codec *codec = snd_kcontrol_chip(kcontrol);
- struct gbaudio_codec_info *gb = snd_soc_codec_get_drvdata(codec);
+ struct snd_soc_component *comp = snd_soc_kcontrol_component(kcontrol);
+ struct gbaudio_codec_info *gb = snd_soc_component_get_drvdata(comp);
struct gb_bundle *bundle;
- dev_dbg(codec->dev, "Entered %s:%s\n", __func__, kcontrol->id.name);
+ dev_dbg(comp->dev, "Entered %s:%s\n", __func__, kcontrol->id.name);
module = find_gb_module(gb, kcontrol->id.name);
if (!module)
return -EINVAL;
@@ -239,7 +239,7 @@ static int gbcodec_mixer_ctl_get(struct snd_kcontrol
*kcontrol,
gb_pm_runtime_put_autosuspend(bundle);
if (ret) {
- dev_err_ratelimited(codec->dev, "%d:Error in %s for %s\n", ret,
+ dev_err_ratelimited(comp->dev, "%d:Error in %s for %s\n", ret,
__func__, kcontrol->id.name);
return ret;
}
@@ -262,7 +262,7 @@ static int gbcodec_mixer_ctl_get(struct snd_kcontrol
*kcontrol,
le32_to_cpu(gbvalue.value.enumerated_item[1]);
break;
default:
- dev_err(codec->dev, "Invalid type: %d for %s:kcontrol\n",
+ dev_err(comp->dev, "Invalid type: %d for %s:kcontrol\n",
info->type, kcontrol->id.name);
ret = -EINVAL;
break;
@@ -278,11 +278,11 @@ static int gbcodec_mixer_ctl_put(struct snd_kcontrol
*kcontrol,
struct gbaudio_ctl_pvt *data;
struct gb_audio_ctl_elem_value gbvalue;
struct gbaudio_module_info *module;
- struct snd_soc_codec *codec = snd_kcontrol_chip(kcontrol);
- struct gbaudio_codec_info *gb = snd_soc_codec_get_drvdata(codec);
+ struct snd_soc_component *comp = snd_soc_kcontrol_component(kcontrol);
+ struct gbaudio_codec_info *gb = snd_soc_component_get_drvdata(comp);
struct gb_bundle *bundle;
- dev_dbg(codec->dev, "Entered %s:%s\n", __func__, kcontrol->id.name);
+ dev_dbg(comp->dev, "Entered %s:%s\n",
[PATCH] spi: tegra20-slink: call pm_runtime_put if pm_runtime_get_sync fails
Call to pm_runtime_get_sync increments counter even in case of
failure leading to incorrect ref count.
Call pm_runtime_put if pm_runtime_get_sync fails.
Signed-off-by: Navid Emamdoost
---
drivers/spi/spi-tegra20-slink.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/spi/spi-tegra20-slink.c b/drivers/spi/spi-tegra20-slink.c
index 7f4d932dade7..15361db00982 100644
--- a/drivers/spi/spi-tegra20-slink.c
+++ b/drivers/spi/spi-tegra20-slink.c
@@ -1118,6 +1118,7 @@ static int tegra_slink_probe(struct platform_device *pdev)
ret = pm_runtime_get_sync(>dev);
if (ret < 0) {
dev_err(>dev, "pm runtime get failed, e = %d\n", ret);
+ pm_runtime_put(>dev);
goto exit_pm_disable;
}
tspi->def_command_reg = SLINK_M_S;
--
2.17.1
[RESEND PATCH v1 6/6] staging: greybus: audio: Enable GB codec, audio module compilation.
Currently, GB codec and audio module is conditionally compiled based on GREYBUS_AUDIO_MSM8994. However, audio module is not dependent on MSM8994 platform and can be used generically with any platform that follows GB Audio class specification. Also, GB codec driver corresponds to dummy codec represented by I2S port available on Toshiba AP Bridge. Added config option for the same in kconfig file and accordingly updated Makefile. Signed-off-by: Vaibhav Agarwal --- drivers/staging/greybus/Kconfig | 14 +- drivers/staging/greybus/Makefile | 4 ++-- 2 files changed, 15 insertions(+), 3 deletions(-) diff --git a/drivers/staging/greybus/Kconfig b/drivers/staging/greybus/Kconfig index d4777f5a8b90..cbcfcbba239b 100644 --- a/drivers/staging/greybus/Kconfig +++ b/drivers/staging/greybus/Kconfig @@ -3,7 +3,7 @@ if GREYBUS config GREYBUS_AUDIO tristate "Greybus Audio Class driver" - depends on SOUND + depends on SOUND && SND_SOC ---help--- Select this option if you have a device that follows the Greybus Audio Class specification. @@ -11,6 +11,18 @@ config GREYBUS_AUDIO To compile this code as a module, chose M here: the module will be called gb-audio.ko +config GREYBUS_AUDIO_APB_CODEC + tristate "Greybus APBridge Audio codec driver" + depends on SND_SOC && GREYBUS_AUDIO + help + Select this option if you have a Toshiba APB device that has I2S + ports and acts as a Greybus "Dummy codec". This device is a + bridge from an APB-I2S port to a Unipro network. + + To compile this code as a module, chose M here: the module + will be called gb-audio-codec.ko + + config GREYBUS_BOOTROM tristate "Greybus Bootrom Class driver" ---help--- diff --git a/drivers/staging/greybus/Makefile b/drivers/staging/greybus/Makefile index 3b4b6cabff19..7c5e89622334 100644 --- a/drivers/staging/greybus/Makefile +++ b/drivers/staging/greybus/Makefile @@ -40,8 +40,8 @@ gb-audio-manager-y:= audio_manager.o audio_manager_module.o #ccflags-y += -DGB_AUDIO_MANAGER_SYSFS #endif -obj-$(CONFIG_GREYBUS_AUDIO_MSM8994)+= gb-audio-codec.o -obj-$(CONFIG_GREYBUS_AUDIO_MSM8994)+= gb-audio-module.o +obj-$(CONFIG_GREYBUS_AUDIO_APB_CODEC) += gb-audio-codec.o +obj-$(CONFIG_GREYBUS_AUDIO_APB_CODEC) += gb-audio-module.o obj-$(CONFIG_GREYBUS_AUDIO)+= gb-audio-gb.o obj-$(CONFIG_GREYBUS_AUDIO)+= gb-audio-apbridgea.o obj-$(CONFIG_GREYBUS_AUDIO)+= gb-audio-manager.o -- 2.26.2
[RESEND PATCH v1 2/6] staging: greybus: audio: Maintain jack list within GB Audio module
As per the current implementation for GB codec driver, a jack list is
maintained for each module. And it expects the list to be populated by
the snd_soc_jack structure which would require modifications in
mainstream code.
However, this is not a necessary requirement and the list can be easily
maintained within gbaudio_module_info as well. This patch provides the
relevant changes for the same.
Signed-off-by: Vaibhav Agarwal
---
drivers/staging/greybus/audio_codec.c | 76 ++
drivers/staging/greybus/audio_codec.h | 10 +++-
drivers/staging/greybus/audio_module.c | 20 ---
3 files changed, 60 insertions(+), 46 deletions(-)
diff --git a/drivers/staging/greybus/audio_codec.c
b/drivers/staging/greybus/audio_codec.c
index ebf8484f0ae7..a2ee587e5a79 100644
--- a/drivers/staging/greybus/audio_codec.c
+++ b/drivers/staging/greybus/audio_codec.c
@@ -712,7 +712,7 @@ static int gbaudio_init_jack(struct gbaudio_module_info
*module,
struct snd_soc_card *card)
{
int ret;
-
+ struct gbaudio_jack *gba_jack, *n;
struct snd_soc_jack *jack;
struct snd_soc_jack_pin *headset, *button;
@@ -728,7 +728,8 @@ static int gbaudio_init_jack(struct gbaudio_module_info
*module,
headset->pin = module->jack_name;
headset->mask = module->jack_mask;
- jack = >headset_jack;
+ gba_jack = >headset;
+ jack = _jack->jack;
ret = snd_soc_card_jack_new(card, module->jack_name, module->jack_mask,
jack, headset, 1);
@@ -737,6 +738,9 @@ static int gbaudio_init_jack(struct gbaudio_module_info
*module,
return ret;
}
+ /* Add to module's jack list */
+ list_add(_jack->list, >jack_list);
+
if (!module->button_mask)
return 0;
@@ -745,20 +749,24 @@ static int gbaudio_init_jack(struct gbaudio_module_info
*module,
button = devm_kzalloc(module->dev, sizeof(*headset), GFP_KERNEL);
if (!button) {
ret = -ENOMEM;
- goto free_headset;
+ goto free_jack;
}
button->pin = module->button_name;
button->mask = module->button_mask;
- jack = >button_jack;
+ gba_jack = >button;
+ jack = _jack->jack;
ret = snd_soc_card_jack_new(card, module->button_name,
module->button_mask, jack, button, 1);
if (ret) {
dev_err(module->dev, "Failed to create button jack\n");
- goto free_headset;
+ goto free_jack;
}
+ /* Add to module's jack list */
+ list_add(_jack->list, >jack_list);
+
/*
* Currently, max 4 buttons are supported with following key mapping
* BTN_0 = KEY_MEDIA
@@ -768,58 +776,55 @@ static int gbaudio_init_jack(struct gbaudio_module_info
*module,
*/
if (module->button_mask & SND_JACK_BTN_0) {
- ret = snd_jack_set_key(module->button_jack.jack, SND_JACK_BTN_0,
+ ret = snd_jack_set_key(jack->jack, SND_JACK_BTN_0,
KEY_MEDIA);
if (ret) {
dev_err(module->dev, "Failed to set BTN_0\n");
- goto free_button;
+ goto free_jack;
}
}
if (module->button_mask & SND_JACK_BTN_1) {
- ret = snd_jack_set_key(module->button_jack.jack, SND_JACK_BTN_1,
+ ret = snd_jack_set_key(jack->jack, SND_JACK_BTN_1,
KEY_VOICECOMMAND);
if (ret) {
dev_err(module->dev, "Failed to set BTN_1\n");
- goto free_button;
+ goto free_jack;
}
}
if (module->button_mask & SND_JACK_BTN_2) {
- ret = snd_jack_set_key(module->button_jack.jack, SND_JACK_BTN_2,
+ ret = snd_jack_set_key(jack->jack, SND_JACK_BTN_2,
KEY_VOLUMEUP);
if (ret) {
dev_err(module->dev, "Failed to set BTN_2\n");
- goto free_button;
+ goto free_jack;
}
}
if (module->button_mask & SND_JACK_BTN_3) {
- ret = snd_jack_set_key(module->button_jack.jack, SND_JACK_BTN_3,
+ ret = snd_jack_set_key(jack->jack, SND_JACK_BTN_3,
KEY_VOLUMEDOWN);
if (ret) {
dev_err(module->dev, "Failed to set BTN_0\n");
- goto free_button;
+ goto free_jack;
}
}
/* FIXME
* verify if this is really required
set_bit(INPUT_PROP_NO_DUMMY_RELEASE,
- module->button_jack.jack->input_dev->propbit);
+
[RESEND PATCH v1 3/6] staging: greybus: audio: Resolve compilation errors for GB codec module
Due to dependencies on ASoC framework changes, GB dummy codec module
compilation is currently disabled. This patch updates codec driver as
per the latest ASoC APIs.
Signed-off-by: Vaibhav Agarwal
---
drivers/staging/greybus/audio_codec.c | 87 +--
drivers/staging/greybus/audio_codec.h | 2 +-
2 files changed, 44 insertions(+), 45 deletions(-)
diff --git a/drivers/staging/greybus/audio_codec.c
b/drivers/staging/greybus/audio_codec.c
index a2ee587e5a79..bbd072acda5c 100644
--- a/drivers/staging/greybus/audio_codec.c
+++ b/drivers/staging/greybus/audio_codec.c
@@ -832,7 +832,7 @@ static int gbaudio_init_jack(struct gbaudio_module_info
*module,
int gbaudio_register_module(struct gbaudio_module_info *module)
{
int ret;
- struct snd_soc_codec *codec;
+ struct snd_soc_component *component;
struct snd_card *card;
struct gbaudio_jack *gba_jack = NULL;
struct snd_soc_jack *jack = NULL;
@@ -842,8 +842,8 @@ int gbaudio_register_module(struct gbaudio_module_info
*module)
return -EAGAIN;
}
- codec = gbcodec->codec;
- card = codec->card->snd_card;
+ component = gbcodec->component;
+ card = component->card->snd_card;
down_write(>controls_rwsem);
@@ -862,19 +862,20 @@ int gbaudio_register_module(struct gbaudio_module_info
*module)
}
if (module->dapm_widgets)
- snd_soc_dapm_new_controls(>dapm, module->dapm_widgets,
+ snd_soc_dapm_new_controls(>dapm,
+ module->dapm_widgets,
module->num_dapm_widgets);
if (module->controls)
- snd_soc_add_codec_controls(codec, module->controls,
- module->num_controls);
+ snd_soc_add_component_controls(component, module->controls,
+ module->num_controls);
if (module->dapm_routes)
- snd_soc_dapm_add_routes(>dapm, module->dapm_routes,
+ snd_soc_dapm_add_routes(>dapm, module->dapm_routes,
module->num_dapm_routes);
/* card already instantiated, create widgets here only */
- if (codec->card->instantiated) {
- snd_soc_dapm_link_component_dai_widgets(codec->card,
- >dapm);
+ if (component->card->instantiated) {
+ snd_soc_dapm_link_component_dai_widgets(component->card,
+ >dapm);
#ifdef CONFIG_SND_JACK
/*
* register jack devices for this module
@@ -882,7 +883,7 @@ int gbaudio_register_module(struct gbaudio_module_info
*module)
*/
list_for_each_entry(gba_jack, >jack_list, list) {
jack = _jack->jack;
- snd_device_register(codec->card->snd_card,
+ snd_device_register(component->card->snd_card,
jack->jack);
}
#endif
@@ -892,9 +893,9 @@ int gbaudio_register_module(struct gbaudio_module_info
*module)
list_add(>list, >module_list);
mutex_unlock(>lock);
- if (codec->card->instantiated)
- ret = snd_soc_dapm_new_widgets(>dapm);
- dev_dbg(codec->dev, "Registered %s module\n", module->name);
+ if (component->card->instantiated)
+ ret = snd_soc_dapm_new_widgets(component->card);
+ dev_dbg(component->dev, "Registered %s module\n", module->name);
up_write(>controls_rwsem);
return ret;
@@ -965,19 +966,19 @@ static void gbaudio_codec_cleanup(struct
gbaudio_module_info *module)
void gbaudio_unregister_module(struct gbaudio_module_info *module)
{
- struct snd_soc_codec *codec = gbcodec->codec;
- struct snd_card *card = codec->card->snd_card;
+ struct snd_soc_component *component = gbcodec->component;
+ struct snd_card *card = component->card->snd_card;
struct gbaudio_jack *gba_jack, *n;
struct snd_soc_jack *jack;
int mask;
- dev_dbg(codec->dev, "Unregister %s module\n", module->name);
+ dev_dbg(component->dev, "Unregister %s module\n", module->name);
down_write(>controls_rwsem);
mutex_lock(>lock);
gbaudio_codec_cleanup(module);
list_del(>list);
- dev_dbg(codec->dev, "Process Unregister %s module\n", module->name);
+ dev_dbg(component->dev, "Process Unregister %s module\n", module->name);
mutex_unlock(>lock);
#ifdef CONFIG_SND_JACK
@@ -994,99 +995,97 @@ void gbaudio_unregister_module(struct gbaudio_module_info
*module)
dev_dbg(module->dev, "Report %s removal\n",
jack->jack->id);
snd_soc_jack_report(jack, 0, mask);
-
[RESEND PATCH v1 1/6] staging: greybus: audio: Update snd_jack FW usage as per new APIs
snd_soc_jack APIs are modified in recent kernel versions. This patch
updates the codec driver to resolve the compilation errors related to
jack framework.
Signed-off-by: Vaibhav Agarwal
---
drivers/staging/greybus/audio_codec.c | 59 +--
1 file changed, 47 insertions(+), 12 deletions(-)
diff --git a/drivers/staging/greybus/audio_codec.c
b/drivers/staging/greybus/audio_codec.c
index 08746c85dea6..ebf8484f0ae7 100644
--- a/drivers/staging/greybus/audio_codec.c
+++ b/drivers/staging/greybus/audio_codec.c
@@ -709,17 +709,29 @@ static struct snd_soc_dai_driver gbaudio_dai[] = {
};
static int gbaudio_init_jack(struct gbaudio_module_info *module,
-struct snd_soc_codec *codec)
+struct snd_soc_card *card)
{
int ret;
+ struct snd_soc_jack *jack;
+ struct snd_soc_jack_pin *headset, *button;
+
if (!module->jack_mask)
return 0;
snprintf(module->jack_name, NAME_SIZE, "GB %d Headset Jack",
module->dev_id);
- ret = snd_soc_jack_new(codec, module->jack_name, module->jack_mask,
- >headset_jack);
+
+ headset = devm_kzalloc(module->dev, sizeof(*headset), GFP_KERNEL);
+ if (!headset)
+ return -ENOMEM;
+
+ headset->pin = module->jack_name;
+ headset->mask = module->jack_mask;
+ jack = >headset_jack;
+
+ ret = snd_soc_card_jack_new(card, module->jack_name, module->jack_mask,
+ jack, headset, 1);
if (ret) {
dev_err(module->dev, "Failed to create new jack\n");
return ret;
@@ -730,11 +742,21 @@ static int gbaudio_init_jack(struct gbaudio_module_info
*module,
snprintf(module->button_name, NAME_SIZE, "GB %d Button Jack",
module->dev_id);
- ret = snd_soc_jack_new(codec, module->button_name, module->button_mask,
- >button_jack);
+ button = devm_kzalloc(module->dev, sizeof(*headset), GFP_KERNEL);
+ if (!button) {
+ ret = -ENOMEM;
+ goto free_headset;
+ }
+
+ button->pin = module->button_name;
+ button->mask = module->button_mask;
+ jack = >button_jack;
+
+ ret = snd_soc_card_jack_new(card, module->button_name,
+ module->button_mask, jack, button, 1);
if (ret) {
dev_err(module->dev, "Failed to create button jack\n");
- return ret;
+ goto free_headset;
}
/*
@@ -750,7 +772,7 @@ static int gbaudio_init_jack(struct gbaudio_module_info
*module,
KEY_MEDIA);
if (ret) {
dev_err(module->dev, "Failed to set BTN_0\n");
- return ret;
+ goto free_button;
}
}
@@ -759,7 +781,7 @@ static int gbaudio_init_jack(struct gbaudio_module_info
*module,
KEY_VOICECOMMAND);
if (ret) {
dev_err(module->dev, "Failed to set BTN_1\n");
- return ret;
+ goto free_button;
}
}
@@ -768,7 +790,7 @@ static int gbaudio_init_jack(struct gbaudio_module_info
*module,
KEY_VOLUMEUP);
if (ret) {
dev_err(module->dev, "Failed to set BTN_2\n");
- return ret;
+ goto free_button;
}
}
@@ -777,7 +799,7 @@ static int gbaudio_init_jack(struct gbaudio_module_info
*module,
KEY_VOLUMEDOWN);
if (ret) {
dev_err(module->dev, "Failed to set BTN_0\n");
- return ret;
+ goto free_button;
}
}
@@ -788,6 +810,18 @@ static int gbaudio_init_jack(struct gbaudio_module_info
*module,
*/
return 0;
+
+free_button:
+ jack = >button_jack;
+ snd_device_free(card->snd_card, jack->jack);
+ list_del(>list);
+
+free_headset:
+ jack = >headset_jack;
+ snd_device_free(card->snd_card, jack->jack);
+ list_del(>list);
+
+ return ret;
}
int gbaudio_register_module(struct gbaudio_module_info *module)
@@ -815,7 +849,7 @@ int gbaudio_register_module(struct gbaudio_module_info
*module)
return -EINVAL;
}
- ret = gbaudio_init_jack(module, codec);
+ ret = gbaudio_init_jack(module, component->card);
if (ret) {
up_write(>controls_rwsem);
return ret;
@@ -942,7 +976,8 @@ void gbaudio_unregister_module(struct gbaudio_module_info
*module)
#ifdef CONFIG_SND_JACK
/* free jack devices for this module from codec->jack_list */
-
[RESEND PATCH v1 0/6] Enable Greybus Audio codec driver
[REQUEST] This patch series intends to "Enable Greybus Audio codec driver" existing in the staging tree. I have shared the original patch series with Greybus-Dev mailing list and as per the suggestion from Alexandre, I'm also interested to push Greybus Audio to sound soc tree. Thus, now I'm resending it to ASoc maintainers for review. Following is the top level SW design for GB Codec driver and GB Audio modules. +--+ +-->+GBA Module 1 | | +--+ +---+ || | || Greybus | +--+ | SND SOC| Audio+-->+GBA Module 2 | | Framework | Codec| +--+ || Driver | || | +---+ +--+ +-->+GBA Module N | +--+ Patch 5 contains the changes to provide helper APIs to link DAPM DAI widgets for the module added and remove/free component controls for the module removed dynamically. Eventually, I propose to extend snd_soc_xxx APIs for this purpose. Kindly share your inputs. [COVER LETTER] The existing GB Audio codec driver is dependent on MSM8994 Audio driver. During the development stage, this depdency was configured due to various changes involved in MSM Audio driver to enable addtional codec card and some of the changes proposed in mainline ASoC framework. However, these are not the real dependencies and some of them can be easily removed. The folowing patch series includes the changes to resolve unnecessary depedencies and make the codec driver functional with the latest kernel. Patch 1,2: Incudes jack framework related changes. Patch 3,4,5: Resolves compilation error observed with the latest kernel and also provides helper APIs required to allow dynamic addition/removal of modules. Patch 6: Finally provides config options and related Makefile changes to enable GB Codec driver. Thanks to Alexandre for raising the headsup [1] and motivating me to provide the necessary changes. [1] https://lore.kernel.org/lkml/20200507212912.599433-1-alexandre.bell...@bootlin.com/ Vaibhav Agarwal (6): staging: greybus: audio: Update snd_jack FW usage as per new APIs staging: greybus: audio: Maintain jack list within GB Audio module staging: greybus: audio: Resolve compilation errors for GB codec module staging: greybus: audio: Resolve compilation error in topology parser staging: greybus: audio: Add helper APIs for dynamic audio modules staging: greybus: audio: Enable GB codec, audio module compilation. drivers/staging/greybus/Kconfig | 14 +- drivers/staging/greybus/Makefile | 6 +- drivers/staging/greybus/audio_codec.c| 187 + drivers/staging/greybus/audio_codec.h| 12 +- drivers/staging/greybus/audio_helper.c | 197 +++ drivers/staging/greybus/audio_helper.h | 17 ++ drivers/staging/greybus/audio_module.c | 20 +-- drivers/staging/greybus/audio_topology.c | 130 +++ 8 files changed, 427 insertions(+), 156 deletions(-) create mode 100644 drivers/staging/greybus/audio_helper.c create mode 100644 drivers/staging/greybus/audio_helper.h base-commit: ae73e7784871ebe2c43da619b4a1e2c9ff81508d -- 2.26.2
[PATCH] MAINTAINERS: rectify entry in ARM SMC WATCHDOG DRIVER
Commit 5c24a28b4eb8 ("dt-bindings: watchdog: Add ARM smc wdt for mt8173
watchdog") added the new ARM SMC WATCHDOG DRIVER entry in MAINTAINERS, but
slipped in a minor mistake.
Luckily, ./scripts/get_maintainer.pl --self-test=patterns complains:
warning: no file matches F: devicetree/bindings/watchdog/arm-smc-wdt.yaml
Update file entry to intended file location.
Signed-off-by: Lukas Bulwahn
---
Julius, Evan, please ack.
Wim, please pick this minor patch into your -next tree.
applies cleanly on next-20200529
MAINTAINERS | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index b045b70e54df..dcfb09700b96 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1489,7 +1489,7 @@ ARM SMC WATCHDOG DRIVER
M: Julius Werner
R: Evan Benn
S: Maintained
-F: devicetree/bindings/watchdog/arm-smc-wdt.yaml
+F: Documentation/devicetree/bindings/watchdog/arm-smc-wdt.yaml
F: drivers/watchdog/arm_smc_wdt.c
ARM SMMU DRIVERS
--
2.17.1
[PATCH] spi: sprd: call pm_runtime_put if pm_runtime_get_sync fails
Call to pm_runtime_get_sync increments counter even in case of
failure leading to incorrect ref count.
Call pm_runtime_put_noidle if pm_runtime_get_sync fails.
Signed-off-by: Navid Emamdoost
---
drivers/spi/spi-sprd.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/spi/spi-sprd.c b/drivers/spi/spi-sprd.c
index 6678f1cbc566..860032af4b98 100644
--- a/drivers/spi/spi-sprd.c
+++ b/drivers/spi/spi-sprd.c
@@ -1018,6 +1018,7 @@ static int sprd_spi_remove(struct platform_device *pdev)
ret = pm_runtime_get_sync(ss->dev);
if (ret < 0) {
dev_err(ss->dev, "failed to resume SPI controller\n");
+ pm_runtime_put_noidle(>dev);
return ret;
}
--
2.17.1
Re: [PATCH v5 0/2] add SW BOOST support for CPPC
On 30-05-20, 10:08, Xiongfeng Wang wrote: > ACPI spec 6.2 section 8.4.7.1 provide the following two CPC registers. > > "Highest performance is the absolute maximum performance an individual > processor may reach, assuming ideal conditions. This performance level > may not be sustainable for long durations, and may only be achievable if > other platform components are in a specific state; for example, it may > require other processors be in an idle state. > > Nominal Performance is the maximum sustained performance level of the > processor, assuming ideal operating conditions. In absence of an > external constraint (power, thermal, etc.) this is the performance level > the platform is expected to be able to maintain continuously. All > processors are expected to be able to sustain their nominal performance > state simultaneously." > > We can use Highest Performance as the max performance in boost mode and > Nomial Performance as the max performance in non-boost mode. If the > Highest Performance is greater than the Nominal Performance, we assume > SW BOOST is supported. > > Changelog: > > v4 -> v5: > add 'cpu_hotplug_lock' before calling '.set_boost' > v3 -> v4: > run 'boost_set_msr_each' for each CPU in the policy rather than > each CPU in the system for 'acpi-cpufreq' > add 'Suggested-by' > > Xiongfeng Wang (2): > cpufreq: change '.set_boost' to act on only one policy > CPPC: add support for SW BOOST > > drivers/cpufreq/acpi-cpufreq.c | 14 ++- > drivers/cpufreq/cppc_cpufreq.c | 39 +++-- > drivers/cpufreq/cpufreq.c | 57 > +++--- > include/linux/cpufreq.h| 2 +- > 4 files changed, 77 insertions(+), 35 deletions(-) Acked-by: Viresh Kumar -- viresh
Re: [PATCH 5/6] vdpa: introduce virtio pci driver
On Fri, May 29, 2020 at 04:03:02PM +0800, Jason Wang wrote: > Note that since virtio specification does not support get/restore > virtqueue state. So we can not use this driver for VM. This can be > addressed by extending the virtio specification. Looks like exactly the kind of hardware limitation VDPA is supposed to paper over within guest. So I suggest we use this as a litmus test, and find ways for VDPA to handle this without spec changes. -- MST
Re: [sched/fair] 0b0695f2b3: phoronix-test-suite.compress-gzip.0.seconds 19.8% regression
On Fri, May 29, 2020 at 07:26:01PM +0200, Vincent Guittot wrote: > On Mon, 25 May 2020 at 10:02, Vincent Guittot > wrote: > > > > On Thu, 21 May 2020 at 10:28, Oliver Sang wrote: > > > > > > On Wed, May 20, 2020 at 03:04:48PM +0200, Vincent Guittot wrote: > > > > On Thu, 14 May 2020 at 19:09, Vincent Guittot > > > > wrote: > > > > > > > > > > Hi Oliver, > > > > > > > > > > On Thu, 14 May 2020 at 16:05, kernel test robot > > > > > wrote: > > > > > > > > > > > > Hi Vincent Guittot, > > > > > > > > > > > > Below report FYI. > > > > > > Last year, we actually reported an improvement "[sched/fair] > > > > > > 0b0695f2b3: > > > > > > vm-scalability.median 3.1% improvement" on link [1]. > > > > > > but now we found the regression on pts.compress-gzip. > > > > > > This seems align with what showed in "[v4,00/10] sched/fair: rework > > > > > > the CFS > > > > > > load balance" (link [2]), where showed the reworked load balance > > > > > > could have > > > > > > both positive and negative effect for different test suites. > > > > > > > > > > We have tried to run all possible use cases but it's impossible to > > > > > covers all so there were a possibility that one that is not covered, > > > > > would regressed. > > > > > > > > > > > And also from link [3], the patch set risks regressions. > > > > > > > > > > > > We also confirmed this regression on another platform > > > > > > (Intel(R) Core(TM) i7-8700 CPU @ 3.20GHz with 8G memory), > > > > > > below is the data (lower is better). > > > > > > v5.44.1 > > > > > > fcf0553db6f4c79387864f6e4ab4a891601f395e4.01 > > > > > > 0b0695f2b34a4afa3f6e9aa1ff0e5336d8dad9124.89 > > > > > > v5.55.18 > > > > > > v5.64.62 > > > > > > v5.7-rc24.53 > > > > > > v5.7-rc34.59 > > > > > > > > > > > > It seems there are some recovery on latest kernels, but not fully > > > > > > back. > > > > > > We were just wondering whether you could share some lights the > > > > > > further works > > > > > > on the load balance after patch set [2] which could cause the > > > > > > performance > > > > > > change? > > > > > > And whether you have plan to refine the load balance algorithm > > > > > > further? > > > > > > > > > > I'm going to have a look at your regression to understand what is > > > > > going wrong and how it can be fixed > > > > > > > > I have run the benchmark on my local setups to try to reproduce the > > > > regression and I don't see the regression. But my setups are different > > > > from your so it might be a problem specific to yours > > > > > > Hi Vincent, which OS are you using? We found the regression on Clear OS, > > > but it cannot reproduce on Debian. > > > On > > > https://www.phoronix.com/scan.php?page=article=mac-win-linux2018=5 > > > it was mentioned that - > > > Gzip compression is much faster out-of-the-box on Clear Linux due to it > > > exploiting > > > multi-threading capabilities compared to the other operating systems Gzip > > > support. > > > > I'm using Debian, I haven't noticed it was only on Clear OS. > > I'm going to look at it. Could you send me traces in the meantime ? > > I run more tests to understand the problem. Even if Clear Linux uses > multithreading, the system is not overloaded and there is a > significant amount of idle time. This means that we use the has_spare > capacity path that spreads tasks on the system. At least that is what > I have seen in the KVM image. Beside this, I think that I have been > able to reproduce the problem on my platform with debian using pigz > instead of gzip for the compress-gzip-1.2.0 test. On my platform, I > can see a difference when I enable all CPU idle states whereas there > is no performance difference when only the shallowest idle state is > enabled. > > The new load balance rework is more efficient at spreading tasks on > the system and one side effect could be that there is more idle time > between tasks wake up on each CPU. As a result, CPUs have to wake up > from a deeper idle state. This could explain the +54% increase of C6 > usage that is reported. Is it possible to get All C-state statistics > ? Hi Vincent, sorry for late. I selected the turbostat while running compress-gzip on Clear OS, as attached. Besides v5.4 and v5.7-rc7, I got the data for v5.5 and v5.7, too. Not sure it's enough since you said "All C-state statistics". Hope it could be useful and if you want more data, please let us know. Again, I collect these data on our "Intel(R) Core(TM) i7-8700 CPU @ 3.20GHz with 8G memory" platform. for each release, I ran test twice to assure the results consistent. phoronix-test-suite.compress-gzip.0.seconds release run1run2 v5.44.374.37 v5.55.375.46 v5.7-rc74.824.85 v5.74.864.83 > > Could you run the test after disabling deep idle states like C6 and > above and check what is the difference between v5.7-rc7 and v5.4 ? thanks for suggestion, will collect this data later. > comparing
Re: [PATCH] hw_breakpoint: Fix build warnings with clang
Le 02/06/2020 à 06:12, Ravi Bangoria a écrit : kbuild test robot reported few build warnings with hw_breakpoint code when compiled with clang[1]. Fix those. [1]: https://lore.kernel.org/linuxppc-dev/202005192233.oi9cjrta%25...@intel.com/ Reported-by: kbuild test robot Signed-off-by: Ravi Bangoria --- Note: Prepared on top of powerpc/next. arch/powerpc/include/asm/hw_breakpoint.h | 3 --- include/linux/hw_breakpoint.h| 4 2 files changed, 4 insertions(+), 3 deletions(-) diff --git a/arch/powerpc/include/asm/hw_breakpoint.h b/arch/powerpc/include/asm/hw_breakpoint.h index f42a55eb77d2..cb424799da0d 100644 --- a/arch/powerpc/include/asm/hw_breakpoint.h +++ b/arch/powerpc/include/asm/hw_breakpoint.h @@ -70,9 +70,6 @@ extern int hw_breakpoint_exceptions_notify(struct notifier_block *unused, unsigned long val, void *data); int arch_install_hw_breakpoint(struct perf_event *bp); void arch_uninstall_hw_breakpoint(struct perf_event *bp); -int arch_reserve_bp_slot(struct perf_event *bp); -void arch_release_bp_slot(struct perf_event *bp); -void arch_unregister_hw_breakpoint(struct perf_event *bp); void hw_breakpoint_pmu_read(struct perf_event *bp); extern void flush_ptrace_hw_breakpoint(struct task_struct *tsk); diff --git a/include/linux/hw_breakpoint.h b/include/linux/hw_breakpoint.h index 6058c3844a76..521481f0d320 100644 --- a/include/linux/hw_breakpoint.h +++ b/include/linux/hw_breakpoint.h @@ -80,6 +80,10 @@ extern int dbg_reserve_bp_slot(struct perf_event *bp); extern int dbg_release_bp_slot(struct perf_event *bp); extern int reserve_bp_slot(struct perf_event *bp); extern void release_bp_slot(struct perf_event *bp); +extern int hw_breakpoint_weight(struct perf_event *bp); +extern int arch_reserve_bp_slot(struct perf_event *bp); +extern void arch_release_bp_slot(struct perf_event *bp); +extern void arch_unregister_hw_breakpoint(struct perf_event *bp); Please no new 'extern'. In the old days 'extern' keyword was used, but new code shall not introduce new unnecessary usage of 'extern' keyword. See report from Checkpatch below: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description (prefer a maximum 75 chars per line) #9: [1]: https://lore.kernel.org/linuxppc-dev/202005192233.oi9cjrta%25...@intel.com/ CHECK:AVOID_EXTERNS: extern prototypes should be avoided in .h files #40: FILE: include/linux/hw_breakpoint.h:83: +extern int hw_breakpoint_weight(struct perf_event *bp); CHECK:AVOID_EXTERNS: extern prototypes should be avoided in .h files #41: FILE: include/linux/hw_breakpoint.h:84: +extern int arch_reserve_bp_slot(struct perf_event *bp); CHECK:AVOID_EXTERNS: extern prototypes should be avoided in .h files #42: FILE: include/linux/hw_breakpoint.h:85: +extern void arch_release_bp_slot(struct perf_event *bp); CHECK:AVOID_EXTERNS: extern prototypes should be avoided in .h files #43: FILE: include/linux/hw_breakpoint.h:86: +extern void arch_unregister_hw_breakpoint(struct perf_event *bp); total: 0 errors, 1 warnings, 4 checks, 19 lines checked NOTE: For some of the reported defects, checkpatch may be able to mechanically convert to the typical style using --fix or --fix-inplace. the.patch has style problems, please review. NOTE: Ignored message types: ARCH_INCLUDE_LINUX BIT_MACRO COMPARISON_TO_NULL DT_SPLIT_BINDING_PATCH EMAIL_SUBJECT FILE_PATH_CHANGES GLOBAL_INITIALISERS LINE_SPACING MULTIPLE_ASSIGNMENTS NOTE: If any of the errors are false positives, please report them to the maintainer, see CHECKPATCH in MAINTAINERS. Christophe
RE: [PATCH] driver core: platform: expose numa_node to users in sysfs
> >
> > Platform devices are NUMA? That's crazy, and feels like a total abuse
> > of platform devices and drivers that really should belong on a "real"
> > bus.
>
> I am not sure if it is an abuse of platform device. But smmu is a platform
> device,
> drivers/iommu/arm-smmu-v3.c is a platform driver.
> In a typical ARM server, there are maybe multiple SMMU devices which can
> support
> IO virtual address and page tables for other devices on PCI-like busses.
> Each different SMMU device might be close to different NUMA node. There is
> really a hardware topology.
>
> If you have multiple CPU packages in a NUMA server, some platform devices
> might
> Belong to CPU0, some other might belong to CPU1.
Those devices are populated by acpi_iort for an ARM server:
drivers/acpi/arm64/iort.c:
static const struct iort_dev_config iort_arm_smmu_v3_cfg __initconst = {
.name = "arm-smmu-v3",
.dev_dma_configure = arm_smmu_v3_dma_configure,
.dev_count_resources = arm_smmu_v3_count_resources,
.dev_init_resources = arm_smmu_v3_init_resources,
.dev_set_proximity = arm_smmu_v3_set_proximity,
};
void __init acpi_iort_init(void)
{
acpi_status status;
status = acpi_get_table(ACPI_SIG_IORT, 0, _table);
...
iort_check_id_count_workaround(iort_table);
iort_init_platform_devices();
}
static void __init iort_init_platform_devices(void)
{
...
for (i = 0; i < iort->node_count; i++) {
if (iort_node >= iort_end) {
pr_err("iort node pointer overflows, bad table\n");
return;
}
iort_enable_acs(iort_node);
ops = iort_get_dev_cfg(iort_node);
if (ops) {
fwnode = acpi_alloc_fwnode_static();
if (!fwnode)
return;
iort_set_fwnode(iort_node, fwnode);
ret = iort_add_platform_device(iort_node, ops);
if (ret) {
iort_delete_fwnode(iort_node);
acpi_free_fwnode_static(fwnode);
return;
}
}
...
}
...
}
NUMA node is got from ACPI:
static int __init arm_smmu_v3_set_proximity(struct device *dev,
struct acpi_iort_node *node)
{
struct acpi_iort_smmu_v3 *smmu;
smmu = (struct acpi_iort_smmu_v3 *)node->node_data;
if (smmu->flags & ACPI_IORT_SMMU_V3_PXM_VALID) {
int dev_node = acpi_map_pxm_to_node(smmu->pxm);
...
set_dev_node(dev, dev_node);
...
}
return 0;
}
Barry
Re: [PATCH 5/6] vdpa: introduce virtio pci driver
On Fri, May 29, 2020 at 04:03:02PM +0800, Jason Wang wrote:
> +static void vp_vdpa_set_vq_ready(struct vdpa_device *vdpa,
> + u16 qid, bool ready)
> +{
> + struct vp_vdpa *vp_vdpa = vdpa_to_vp(vdpa);
> +
> + vp_iowrite16(qid, _vdpa->common->queue_select);
> + vp_iowrite16(ready, _vdpa->common->queue_enable);
> +}
> +
Looks like this needs to check and just skip the write if
ready == 0, right? Of course vdpa core then insists on calling
vp_vdpa_get_vq_ready which will warn. Maybe just drop the
check from core, move it to drivers which need it?
...
> +static const struct pci_device_id vp_vdpa_id_table[] = {
> + { PCI_DEVICE(PCI_VENDOR_ID_REDHAT_QUMRANET, PCI_ANY_ID) },
> + { 0 }
> +};
This looks like it'll create a mess with either virtio pci
or vdpa being loaded at random. Maybe just don't specify
any IDs for now. Down the road we could get a
distinct vendor ID or a range of device IDs for this.
> +MODULE_DEVICE_TABLE(pci, vp_vdpa_id_table);
> +
> +static struct pci_driver vp_vdpa_driver = {
> + .name = "vp-vdpa",
> + .id_table = vp_vdpa_id_table,
> + .probe = vp_vdpa_probe,
> + .remove = vp_vdpa_remove,
> +};
> +
> +module_pci_driver(vp_vdpa_driver);
> +
> +MODULE_AUTHOR("Jason Wang ");
> +MODULE_DESCRIPTION("vp-vdpa");
> +MODULE_LICENSE("GPL");
> +MODULE_VERSION("1");
> --
> 2.20.1
Re: [RFC] Restrict the untrusted devices, to bind to only a set of "whitelisted" drivers
On Mon, Jun 01, 2020 at 06:25:42PM -0500, Bjorn Helgaas wrote:
> [+cc Greg, linux-kernel for wider exposure]
Thanks for the cc:, missed this...
>
> On Tue, May 26, 2020 at 09:30:08AM -0700, Rajat Jain wrote:
> > On Thu, May 14, 2020 at 7:18 PM Rajat Jain wrote:
> > > On Thu, May 14, 2020 at 12:13 PM Raj, Ashok wrote:
> > > > On Wed, May 13, 2020 at 02:26:18PM -0700, Rajat Jain wrote:
> > > > > On Wed, May 13, 2020 at 8:19 AM Bjorn Helgaas
> > > > > wrote:
> > > > > > On Fri, May 01, 2020 at 04:07:10PM -0700, Rajat Jain wrote:
> > > > > > > Hi,
> > > > > > >
> > > > > > > Currently, the PCI subsystem marks the PCI devices as
> > > > > > > "untrusted", if
> > > > > > > the firmware asks it to:
> > > > > > >
> > > > > > > 617654aae50e ("PCI / ACPI: Identify untrusted PCI devices")
> > > > > > > 9cb30a71acd4 ("PCI: OF: Support "external-facing" property")
> > > > > > >
> > > > > > > An "untrusted" device indicates a (likely external facing) device
> > > > > > > that
> > > > > > > may be malicious, and can trigger DMA attacks on the system. It
> > > > > > > may
> > > > > > > also try to exploit any vulnerabilities exposed by the driver,
> > > > > > > that
> > > > > > > may allow it to read/write unintended addresses in the host (e.g.
> > > > > > > if
> > > > > > > DMA buffers for the device, share memory pages with other driver
> > > > > > > data
> > > > > > > structures or code etc).
> > > > > > >
> > > > > > > High Level proposal
> > > > > > > ===
> > > > > > > Currently, the "untrusted" device property is used as a hint to
> > > > > > > enable
> > > > > > > IOMMU restrictions (on Intel), disable ATS (on ARM) etc. We'd
> > > > > > > like to
> > > > > > > go a step further, and allow the administrator to build a list of
> > > > > > > whitelisted drivers for these "untrusted" devices. This whitelist
> > > > > > > of
> > > > > > > drivers are the ones that he trusts enough to have little or no
> > > > > > > vulnerabilities. (He may have built this list of whitelisted
> > > > > > > drivers
> > > > > > > by a combination of code analysis of drivers, or by extensive
> > > > > > > testing
> > > > > > > using PCIe fuzzing etc). We propose that the administrator be
> > > > > > > allowed
> > > > > > > to specify this list of whitelisted drivers to the kernel, and
> > > > > > > the PCI
> > > > > > > subsystem to impose this behavior:
> > > > > > >
> > > > > > > 1) The "untrusted" devices can bind to only "whitelisted drivers".
> > > > > > > 2) The other devices (i.e. dev->untrusted=0) can bind to any
> > > > > > > driver.
> > > > > > >
> > > > > > > Of course this behavior is to be imposed only if such a whitelist
> > > > > > > is
> > > > > > > provided by the administrator.
> >
> > I haven't heard much on this proposal after the initial inputs (to
> > which I responded). Essentially, I agree that IO-MMU and ACS
> > restrictions need to be put in plcase. But I think we need this
> > additionally. Does this look acceptable to you? I wanted to start
> > spinning out the patches, but wanted to see if there are any pending
> > comments or concerns.
>
> I think it makes sense to code this up and see what it would look
> like. The bare minimum seems like a driver "bind-to-external-devices"
> bit that's visible in sysfs plus something in the driver probe path
> that checks it. Neither is inherently PCI-specific, but maybe the
> right place will become obvious when implementing it.
>
> I'm still not 100% sure the device "external/untrusted" bit is the
> right thing to check. If you don't trust a driver enough to expose it
> to an external device, is it reasonable to trust it for internal
> devices? It seems like one could attack the driver of even an
> internal device like a NIC by controlling the data fed to it.
>
> The existing use of "external/untrusted" for IOMMU protection is
> different. There we're acknowledging that the *device* itself is
> unknown and we need to protect ourselves from malicious DMA.
>
> Here we're concerned about a *driver* that's completely under our
> control. If we don't trust the driver, we could (a) fix the problems
> in the driver, (b) change the driver so it handles external/untrusted
> devices differently, or (c) not ship the driver at all.
>
> I'm also not sure about the administrative details of this. Certain
> versions of the driver may be trusted while others are untrusted.
> That would all have to be managed in userspace, so it's not really our
> problem, but it sounds like a hassle. Putting the information in the
> driver itself would reduce that.
What about taking what we have today for USB devices/drivers where we
have different levels of "authorized"? There's no reason that could not
just move to the driver core and be available for all devices/drivers as
that model has proven to work really well over time.
See the "authorized" sysfs file documentation in
Documentation/ABI/testing/sysfs-bus-usb for some details. Lots of
userspace
drivers/ptp/ptp_ines.c:837:34: warning: unused variable 'ines_ptp_ctrl_of_match'
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: f359287765c04711ff54fbd11645271d8e5ff763
commit: bad1eaa6ac312ffd7aa46dd5a4d9843b824aa023 ptp: Add a driver for InES
time stamping IP core.
date: 5 months ago
config: x86_64-randconfig-r036-20200602 (attached as .config)
compiler: clang version 11.0.0 (https://github.com/llvm/llvm-project
2388a096e7865c043e83ece4e26654bd3d1a20d5)
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# install x86_64 cross compiling tool for clang build
# apt-get install binutils-x86-64-linux-gnu
git checkout bad1eaa6ac312ffd7aa46dd5a4d9843b824aa023
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=x86_64
If you fix the issue, kindly add following tag as appropriate
Reported-by: kbuild test robot
All warnings (new ones prefixed by >>, old ones prefixed by <<):
drivers/ptp/ptp_ines.c:481:37: warning: format specifies type 'unsigned char'
but the argument has type 'int' [-Wformat]
tag_to_msgtype(ts->tag & 0x7), *msgtype & 0xf);
^~
include/linux/device.h:1784:39: note: expanded from macro 'dev_dbg'
dynamic_dev_dbg(dev, dev_fmt(fmt), ##__VA_ARGS__)
~~~ ^~~
include/linux/dynamic_debug.h:158:19: note: expanded from macro
'dynamic_dev_dbg'
dev, fmt, ##__VA_ARGS__)
~~~^~~
include/linux/dynamic_debug.h:143:56: note: expanded from macro
'_dynamic_func_call'
__dynamic_func_call(__UNIQUE_ID(ddebug), fmt, func, ##__VA_ARGS__)
^~~
include/linux/dynamic_debug.h:125:15: note: expanded from macro
'__dynamic_func_call'
func(, ##__VA_ARGS__);
^~~
drivers/ptp/ptp_ines.c:491:19: warning: format specifies type 'unsigned short'
but the argument has type 'int' [-Wformat]
ts->portnum, ntohs(*portn));
^
include/linux/device.h:1784:39: note: expanded from macro 'dev_dbg'
dynamic_dev_dbg(dev, dev_fmt(fmt), ##__VA_ARGS__)
~~~ ^~~
include/linux/dynamic_debug.h:158:19: note: expanded from macro
'dynamic_dev_dbg'
dev, fmt, ##__VA_ARGS__)
~~~^~~
include/linux/dynamic_debug.h:143:56: note: expanded from macro
'_dynamic_func_call'
__dynamic_func_call(__UNIQUE_ID(ddebug), fmt, func, ##__VA_ARGS__)
^~~
note: (skipping 2 expansions in backtrace; use -fmacro-backtrace-limit=0 to see
all)
include/linux/byteorder/generic.h:137:21: note: expanded from macro '___ntohs'
#define ___ntohs(x) __be16_to_cpu(x)
^~~~
include/uapi/linux/byteorder/little_endian.h:42:26: note: expanded from macro
'__be16_to_cpu'
#define __be16_to_cpu(x) __swab16((__force __u16)(__be16)(x))
^~~~
include/uapi/linux/swab.h:104:2: note: expanded from macro '__swab16'
(__builtin_constant_p((__u16)(x)) ?
^
drivers/ptp/ptp_ines.c:496:17: warning: format specifies type 'unsigned short'
but the argument has type 'int' [-Wformat]
ts->seqid, ntohs(*seqid));
^
include/linux/device.h:1784:39: note: expanded from macro 'dev_dbg'
dynamic_dev_dbg(dev, dev_fmt(fmt), ##__VA_ARGS__)
~~~ ^~~
include/linux/dynamic_debug.h:158:19: note: expanded from macro
'dynamic_dev_dbg'
dev, fmt, ##__VA_ARGS__)
~~~^~~
include/linux/dynamic_debug.h:143:56: note: expanded from macro
'_dynamic_func_call'
__dynamic_func_call(__UNIQUE_ID(ddebug), fmt, func, ##__VA_ARGS__)
^~~
note: (skipping 2 expansions in backtrace; use -fmacro-backtrace-limit=0 to see
all)
include/linux/byteorder/generic.h:137:21: note: expanded from macro '___ntohs'
#define ___ntohs(x) __be16_to_cpu(x)
^~~~
include/uapi/linux/byteorder/little_endian.h:42:26: note: expanded from macro
'__be16_to_cpu'
#define __be16_to_cpu(x) __swab16((__force __u16)(__be16)(x))
^~~~
include/uapi/linux/swab.h:104:2: note: expanded from macro '__swab16'
(__builtin_constant_p((__u16)(x)) ?
^
>> drivers/ptp/ptp_ines.c:837:34: warning: unused variable
>> 'ines_ptp_ctrl_of_match' [-Wunused-const-variable]
static const struct of_device_id ines_ptp_ctrl_of_match[] = {
^
4 warnings generated.
vim +/ines_ptp_ctrl_of_match +837 drivers/ptp/ptp_ines.c
836
> 837 static const struct of_device_id ines_ptp_ctrl_of_match[] = {
838 { .compatible = "ines,ptp-ctrl" },
839 { }
840 };
841
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
.config.gz
Description: application/gzip
memory leak in exfat_parse_param
I report a bug (in linux-5.7.0-rc7) found by syzkaller. kernel config: https://github.com/butterflyhack/syzkaller-fuzz/blob/master/config-v5.7.0-rc7 and can reproduce. A param->string held by exfat_mount_options. BUG: memory leak unreferenced object 0x88801972e090 (size 8): comm "syz-executor.2", pid 16298, jiffies 4295172466 (age 14.060s) hex dump (first 8 bytes): 6b 6f 69 38 2d 75 00 00 koi8-u.. backtrace: [<5bfe35d6>] kstrdup+0x36/0x70 mm/util.c:60 [<18ed3277>] exfat_parse_param+0x160/0x5e0 fs/exfat/super.c:276 [<7680462b>] vfs_parse_fs_param+0x2b4/0x610 fs/fs_context.c:147 [<97c027f2>] vfs_parse_fs_string+0xe6/0x150 fs/fs_context.c:191 [<371bf78f>] generic_parse_monolithic+0x16f/0x1f0 fs/fs_context.c:231 [<5ce5eb1b>] do_new_mount fs/namespace.c:2812 [inline] [<5ce5eb1b>] do_mount+0x12bb/0x1b30 fs/namespace.c:3141 [] __do_sys_mount fs/namespace.c:3350 [inline] [ ] __se_sys_mount fs/namespace.c:3327 [inline] [ ] __x64_sys_mount+0x18f/0x230 fs/namespace.c:3327 [<3b024e98>] do_syscall_64+0xf6/0x7d0 arch/x86/entry/common.c:295 [ ] entry_SYSCALL_64_after_hwframe+0x49/0xb3
Re: [PATCH 1/6] vhost: allow device that does not depend on vhost worker
On Fri, May 29, 2020 at 04:02:58PM +0800, Jason Wang wrote:
> diff --git a/drivers/vhost/vhost.c b/drivers/vhost/vhost.c
> index d450e16c5c25..70105e045768 100644
> --- a/drivers/vhost/vhost.c
> +++ b/drivers/vhost/vhost.c
> @@ -166,11 +166,16 @@ static int vhost_poll_wakeup(wait_queue_entry_t *wait,
> unsigned mode, int sync,
>void *key)
> {
> struct vhost_poll *poll = container_of(wait, struct vhost_poll, wait);
> + struct vhost_work *work = >work;
>
> if (!(key_to_poll(key) & poll->mask))
> return 0;
>
> - vhost_poll_queue(poll);
> + if (!poll->dev->use_worker)
> + work->fn(work);
> + else
> + vhost_poll_queue(poll);
> +
> return 0;
> }
>
So a wakeup function wakes up eventfd directly.
What if user supplies e.g. the same eventfd as ioeventfd?
Won't this cause infinite loops?
--
MST
Re: iommu: Improve exception handling in iommu_group_alloc()
>> * I suggest to avoid the specification of duplicate function calls. >> Will it be helpful to add a few jump targets? >> >> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/coding-style.rst?id=3d77e6a8804abcc0504c904bd6e5cdf3a5cf8162#n455 > > I don't think it is helpful or readable to add some jump targets here, > since the exception handling is very simple here. Do you disagree to the application of the Linux coding style then for the recommended exception handling? Regards, Markus
Re: [PATCH] powerpc/nvram: Replace kmalloc with kzalloc in the error message
>>> Please just remove the message instead, it's a tiny allocation that's >>> unlikely to ever fail, and the caller will print an error anyway. >> >> How do you think about to take another look at a previous update suggestion >> like the following? >> >> powerpc/nvram: Delete three error messages for a failed memory allocation >> https://patchwork.ozlabs.org/project/linuxppc-dev/patch/00845261-8528-d011-d3b8-e9355a231...@users.sourceforge.net/ >> https://lore.kernel.org/linuxppc-dev/00845261-8528-d011-d3b8-e9355a231...@users.sourceforge.net/ >> https://lore.kernel.org/patchwork/patch/752720/ >> https://lkml.org/lkml/2017/1/19/537 > > That deleted the messages from nvram_scan_partitions(), but neither of > the callers of nvram_scan_paritions() check its return value or print > anything if it fails. So removing those messages would make those > failures silent which is not what we want. * How do you think about information like the following? https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/coding-style.rst?id=f359287765c04711ff54fbd11645271d8e5ff763#n883 “… These generic allocation functions all emit a stack dump on failure when used without __GFP_NOWARN so there is no use in emitting an additional failure message when NULL is returned. …” * Would you like to clarify software development concerns around the Linux allocation failure report any more? Regards, Markus
[PATCH v2] kexec: Do not verify the signature without the lockdown or mandatory signature
Signature verification is an important security feature, to protect
system from being attacked with a kernel of unknown origin. Kexec
rebooting is a way to replace the running kernel, hence need be
secured carefully.
In the current code of handling signature verification of kexec kernel,
the logic is very twisted. It mixes signature verification, IMA signature
appraising and kexec lockdown.
If there is no KEXEC_SIG_FORCE, kexec kernel image doesn't have one of
signature, the supported crypto, and key, we don't think this is wrong,
Unless kexec lockdown is executed. IMA is considered as another kind of
signature appraising method.
If kexec kernel image has signature/crypto/key, it has to go through the
signature verification and pass. Otherwise it's seen as verification
failure, and won't be loaded.
Seems kexec kernel image with an unqualified signature is even worse than
those w/o signature at all, this sounds very unreasonable. E.g. If people
get a unsigned kernel to load, or a kernel signed with expired key, which
one is more dangerous?
So, here, let's simplify the logic to improve code readability. If the
KEXEC_SIG_FORCE enabled or kexec lockdown enabled, signature verification
is mandated. Otherwise, we lift the bar for any kernel image.
Signed-off-by: Lianbo Jiang
---
Changes since v1:
[1] Modify the log level(suggested by Jiri Bohac)
kernel/kexec_file.c | 34 ++
1 file changed, 6 insertions(+), 28 deletions(-)
diff --git a/kernel/kexec_file.c b/kernel/kexec_file.c
index faa74d5f6941..fae496958a68 100644
--- a/kernel/kexec_file.c
+++ b/kernel/kexec_file.c
@@ -181,34 +181,19 @@ void kimage_file_post_load_cleanup(struct kimage *image)
static int
kimage_validate_signature(struct kimage *image)
{
- const char *reason;
int ret;
ret = arch_kexec_kernel_verify_sig(image, image->kernel_buf,
image->kernel_buf_len);
- switch (ret) {
- case 0:
- break;
+ if (ret) {
- /* Certain verification errors are non-fatal if we're not
-* checking errors, provided we aren't mandating that there
-* must be a valid signature.
-*/
- case -ENODATA:
- reason = "kexec of unsigned image";
- goto decide;
- case -ENOPKG:
- reason = "kexec of image with unsupported crypto";
- goto decide;
- case -ENOKEY:
- reason = "kexec of image with unavailable key";
- decide:
if (IS_ENABLED(CONFIG_KEXEC_SIG_FORCE)) {
- pr_notice("%s rejected\n", reason);
+ pr_notice("Enforced kernel signature verification
failed (%d).\n", ret);
return ret;
}
- /* If IMA is guaranteed to appraise a signature on the kexec
+ /*
+* If IMA is guaranteed to appraise a signature on the kexec
* image, permit it even if the kernel is otherwise locked
* down.
*/
@@ -216,17 +201,10 @@ kimage_validate_signature(struct kimage *image)
security_locked_down(LOCKDOWN_KEXEC))
return -EPERM;
- return 0;
-
- /* All other errors are fatal, including nomem, unparseable
-* signatures and signature check failures - even if signatures
-* aren't required.
-*/
- default:
- pr_notice("kernel signature verification failed (%d).\n", ret);
+ pr_debug("kernel signature verification failed (%d).\n", ret);
}
- return ret;
+ return 0;
}
#endif
--
2.17.1
Re: linux-sh for-next reactivation
Hi Rich, On Mon, 1 Jun 2020 23:11:39 -0400 Rich Felker wrote: > > Could you reactivate linux-next pull from my arch/sh for-next branch? > It's where it was before, at: > > git://git.libc.org/linux-sh for-next > > and has newly accepted patches ready. I already have an SH tree from git://git.sourceforge.jp/gitroot/uclinux-h8/linux.git#sh-next . Should I do anything with that one? It currently contains: $ git log --oneline origin/master..sh/sh-next a193018e5290 (sh/sh-next) sh: add missing EXPORT_SYMBOL() for __delay 1d5fd6c33b04 sh: add missing DECLARE_EXPORT() for __ashiftrt_r4_xx d70f1e3d5dbd Merge remote-tracking branch 'origin/master' into sh-next baf58858e8b6 sh: prefer __section from compiler_attributes.h 8619b5a9035a sh: Drop -Werror from kernel Makefile 3a3a78124693 sh: kernel: disassemble: Mark expected switch fall-throughs fb8f77490f55 sh: kernel: hw_breakpoint: Fix missing break in switch statement cd10afbc932d sh: remove unneeded uapi asm-generic wrappers cbfc6edb6a4a sh: use __builtin_constant_p() directly instead of IS_IMMEDIATE() -- Cheers, Stephen Rothwell pgpJcDCj71o29.pgp Description: OpenPGP digital signature
[PATCH v2] driver core: platform: need consistent spacing around '-'
Fix the below checkpatch issue: ERROR: need consistent spacing around '-' (ctx:WxV) FILE: drivers/base/platform.c:1008: + len = acpi_device_modalias(dev, buf, PAGE_SIZE -1); ^ Signed-off-by: Barry Song --- -v2: specify a description of the patch in the email body drivers/base/platform.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/base/platform.c b/drivers/base/platform.c index b27d0f6c18c9..ab9408182a0d 100644 --- a/drivers/base/platform.c +++ b/drivers/base/platform.c @@ -1005,7 +1005,7 @@ static ssize_t modalias_show(struct device *dev, struct device_attribute *a, if (len != -ENODEV) return len; - len = acpi_device_modalias(dev, buf, PAGE_SIZE -1); + len = acpi_device_modalias(dev, buf, PAGE_SIZE - 1); if (len != -ENODEV) return len; -- 2.23.0
Re: [PATCH 4/6] vhost_vdpa: support doorbell mapping via mmap
On Tue, Jun 02, 2020 at 03:22:49AM +0800, kbuild test robot wrote:
> Hi Jason,
>
> I love your patch! Yet something to improve:
>
> [auto build test ERROR on vhost/linux-next]
> [also build test ERROR on linus/master v5.7 next-20200529]
> [if your patch is applied to the wrong git tree, please drop us a note to help
> improve the system. BTW, we also suggest to use '--base' option to specify the
> base tree in git format-patch, please see
> https://stackoverflow.com/a/37406982]
>
> url:
> https://github.com/0day-ci/linux/commits/Jason-Wang/vDPA-doorbell-mapping/20200531-070834
> base: https://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost.git
> linux-next
> config: m68k-randconfig-r011-20200601 (attached as .config)
> compiler: m68k-linux-gcc (GCC) 9.3.0
> reproduce (this is a W=1 build):
> wget
> https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
> ~/bin/make.cross
> chmod +x ~/bin/make.cross
> # save the attached .config to linux build tree
> COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross
> ARCH=m68k
>
> If you fix the issue, kindly add following tag as appropriate
> Reported-by: kbuild test robot
>
> All errors (new ones prefixed by >>, old ones prefixed by <<):
>
> drivers/vhost/vdpa.c: In function 'vhost_vdpa_fault':
> >> drivers/vhost/vdpa.c:754:22: error: implicit declaration of function
> >> 'pgprot_noncached' [-Werror=implicit-function-declaration]
> 754 | vma->vm_page_prot = pgprot_noncached(vma->vm_page_prot);
> | ^~~~
> >> drivers/vhost/vdpa.c:754:22: error: incompatible types when assigning to
> >> type 'pgprot_t' {aka 'struct '} from type 'int'
> cc1: some warnings being treated as errors
>
> vim +/pgprot_noncached +754 drivers/vhost/vdpa.c
>
>742
>743static vm_fault_t vhost_vdpa_fault(struct vm_fault *vmf)
>744{
>745struct vhost_vdpa *v = vmf->vma->vm_file->private_data;
>746struct vdpa_device *vdpa = v->vdpa;
>747const struct vdpa_config_ops *ops = vdpa->config;
>748struct vdpa_notification_area notify;
>749struct vm_area_struct *vma = vmf->vma;
>750u16 index = vma->vm_pgoff;
>751
>752notify = ops->get_vq_notification(vdpa, index);
>753
> > 754vma->vm_page_prot = pgprot_noncached(vma->vm_page_prot);
>755if (remap_pfn_range(vma, vmf->address & PAGE_MASK,
>756notify.addr >> PAGE_SHIFT,
> PAGE_SIZE,
>757vma->vm_page_prot))
>758return VM_FAULT_SIGBUS;
>759
>760return VM_FAULT_NOPAGE;
>761}
>762
Yes well, all this remapping clearly has no chance to work
on systems without CONFIG_MMU.
> ---
> 0-DAY CI Kernel Test Service, Intel Corporation
> https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
[PATCH] spi: tegra114: missing put on pm_runtime_get_sync failure
the call to pm_runtime_get_sync increments the counter even
in case of failure leading to incorrect ref count.
Call pm_runtime_put if pm_runtime_get_sync fails.
Signed-off-by: Navid Emamdoost
---
drivers/spi/spi-tegra114.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/spi/spi-tegra114.c b/drivers/spi/spi-tegra114.c
index 83edabdb41ad..dccd2ac1a975 100644
--- a/drivers/spi/spi-tegra114.c
+++ b/drivers/spi/spi-tegra114.c
@@ -974,6 +974,7 @@ static int tegra_spi_setup(struct spi_device *spi)
dev_err(tspi->dev, "pm runtime failed, e = %d\n", ret);
if (cdata)
tegra_spi_cleanup(spi);
+ pm_runtime_put(tspi->dev);
return ret;
}
@@ -1398,6 +1399,7 @@ static int tegra_spi_probe(struct platform_device *pdev)
ret = pm_runtime_get_sync(>dev);
if (ret < 0) {
dev_err(>dev, "pm runtime get failed, e = %d\n", ret);
+ pm_runtime_put(>dev);
goto exit_pm_disable;
}
@@ -1479,6 +1481,7 @@ static int tegra_spi_resume(struct device *dev)
ret = pm_runtime_get_sync(dev);
if (ret < 0) {
dev_err(dev, "pm runtime failed, e = %d\n", ret);
+ pm_runtime_put(dev);
return ret;
}
tegra_spi_writel(tspi, tspi->command1_reg, SPI_COMMAND1);
--
2.17.1
include/linux/compiler.h:199:9: sparse: sparse: context imbalance in 'alua_rtpg' - different lock contexts for basic block
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: f359287765c04711ff54fbd11645271d8e5ff763
commit: fb041bb7c0a918b95c6889fc965cdc4a75b4c0ca locking/refcount: Consolidate
implementations of refcount_t
date: 6 months ago
config: ia64-randconfig-s032-20200602 (attached as .config)
compiler: ia64-linux-gcc (GCC) 9.3.0
reproduce:
# apt-get install sparse
# sparse version: v0.6.1-243-gc100a7ab-dirty
git checkout fb041bb7c0a918b95c6889fc965cdc4a75b4c0ca
# save the attached .config to linux build tree
make W=1 C=1 ARCH=ia64 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__'
If you fix the issue, kindly add following tag as appropriate
Reported-by: kbuild test robot
sparse warnings: (new ones prefixed by >>)
>> include/linux/compiler.h:199:9: sparse: sparse: context imbalance in
>> 'alua_rtpg' - different lock contexts for basic block
vim +/alua_rtpg +199 include/linux/compiler.h
d976441f44bc5d4 Andrey Ryabinin 2015-10-19 195
d976441f44bc5d4 Andrey Ryabinin 2015-10-19 196 static __always_inline
d976441f44bc5d4 Andrey Ryabinin 2015-10-19 197 void
__read_once_size(const volatile void *p, void *res, int size)
230fa253df6352a Christian Borntraeger 2014-11-25 198 {
d976441f44bc5d4 Andrey Ryabinin 2015-10-19 @199 __READ_ONCE_SIZE;
230fa253df6352a Christian Borntraeger 2014-11-25 200 }
d976441f44bc5d4 Andrey Ryabinin 2015-10-19 201
:: The code at line 199 was first introduced by commit
:: d976441f44bc5d48635d081d277aa76556ffbf8b compiler, atomics, kasan:
Provide READ_ONCE_NOCHECK()
:: TO: Andrey Ryabinin
:: CC: Ingo Molnar
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
.config.gz
Description: application/gzip
linux-next: manual merge of the kvm tree with the tip tree
Hi all,
Today's linux-next merge of the kvm tree got a conflict in:
arch/x86/kernel/kvm.c
between commit:
a707ae1a9bbb ("x86/entry: Switch page fault exception to IDTENTRY_RAW")
from the tip tree and commit:
68fd66f100d1 ("KVM: x86: extend struct kvm_vcpu_pv_apf_data with token info")
from the kvm tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc arch/x86/kernel/kvm.c
index 07dc47359c4f,d6f22a3a1f7d..
--- a/arch/x86/kernel/kvm.c
+++ b/arch/x86/kernel/kvm.c
@@@ -217,23 -218,23 +217,23 @@@ again
}
EXPORT_SYMBOL_GPL(kvm_async_pf_task_wake);
- u32 noinstr kvm_read_and_reset_pf_reason(void)
-u32 kvm_read_and_reset_apf_flags(void)
++u32 noinstr kvm_read_and_reset_apf_flags(void)
{
- u32 reason = 0;
+ u32 flags = 0;
if (__this_cpu_read(apf_reason.enabled)) {
- reason = __this_cpu_read(apf_reason.reason);
- __this_cpu_write(apf_reason.reason, 0);
+ flags = __this_cpu_read(apf_reason.flags);
+ __this_cpu_write(apf_reason.flags, 0);
}
- return reason;
+ return flags;
}
- EXPORT_SYMBOL_GPL(kvm_read_and_reset_pf_reason);
+ EXPORT_SYMBOL_GPL(kvm_read_and_reset_apf_flags);
-NOKPROBE_SYMBOL(kvm_read_and_reset_apf_flags);
-bool __kvm_handle_async_pf(struct pt_regs *regs, u32 token)
+noinstr bool __kvm_handle_async_pf(struct pt_regs *regs, u32 token)
{
- u32 reason = kvm_read_and_reset_pf_reason();
+ u32 reason = kvm_read_and_reset_apf_flags();
+ bool rcu_exit;
switch (reason) {
case KVM_PV_REASON_PAGE_NOT_PRESENT:
pgpJaAZeMtAQQ.pgp
Description: OpenPGP digital signature
RE: [PATCH 2/4] firmware: imx: add resource management api
> Subject: RE: [PATCH 2/4] firmware: imx: add resource management api > > > From: Peng Fan > > Sent: Monday, June 1, 2020 8:40 PM > > > > > > > From: Peng Fan > > > > Sent: Friday, April 24, 2020 9:12 AM > > > > > > > > > > > From: Peng Fan > > > > > > Sent: Thursday, April 23, 2020 6:57 PM > > > > > > > > From: Peng Fan > > > > > > > > Sent: Thursday, April 23, 2020 3:00 PM > > > > > > > > > > > > > > > > Add resource management API, when we have multiple > > > > > > > > partition running together, resources not owned to current > > > > > > > > partition should not be > > > > > used. > > > > > > > > > > > > > > > > Reviewed-by: Leonard Crestez > > > > > > > > Signed-off-by: Peng Fan > > > > > > > > > > > > > > Right now I'm still not quite understand if we really need this. > > > > > > > As current resource is bound to power domains, if it's not > > > > > > > owned by one specific SW execution environment, power on > > > > > > > will also > > fail. > > > > > > > Can you clarify if any exceptions? > > > > > > > > > > > > There will be lots of failures when boot Linux domu if no check. > > > > > > > > > > > > > > > > What kind of features did you mean? > > > > > Could you clarify a bit more? I'd like to understand this issue > > > > > better. > > > > > > > > When supporting hypervisor with dual Linux running, 1st Linux and > > > > the 2nd Linux will have their own dedicated resources. > > > > > > > > If no resource check, that means 1st/2nd Linux will register all > > > > the resources, then both will see fail logs when register > > > > resources not owned to > > > itself. > > > > > > > > Same to partitioned m4 case. > > > > > > > > Would it be better without the failure log? > > > > > > > > > > Is it power up failure? > > > If yes, it's expected because we actually use power up to check if > > > resources are owned by this partition. It functions the same as > > > calling resource check API. > > > That's current design. > > > > > > Or it's other failures? Log? > > Sorry for long late reply. > > > > Part of my XEN DomU log, there are lots of failure log. I think better > > not have such logs by add a resource own check. > > Those error logs are intended. > Resource owner check actually behaves the same as power up. If resource is not owned, it will not register the power domain. Without resource own check, it will continue register the power domain and hook it into genpd list. I prefer we not expose the power domain not owned to current partition and keep the err msg for people to easy see where it goes wrong. Regards, Peng. > So not quite necessary to add a double check. > If we're concerning about the error log, we can change it to dev_dbg(). > > BTW, as resource management will be needed by seco drivers later, So I will > continue to review the patch. > > Regards > Aisheng > > > > > [2.034774] imx6q-pcie 5f00.pcie:IO 0x6ff8..0x6ff8 -> > > 0x > > [2.034801] imx6q-pcie 5f00.pcie: MEM 0x6000..0x6fef > -> > > 0x6000 > > [2.035072] sdhc1: failed to power up resource 249 ret -13 > > [2.035619] sdhc2: failed to power up resource 250 ret -13 > > [2.036126] enet0: failed to power up resource 251 ret -13 > > [2.036584] enet1: failed to power up resource 252 ret -13 > > [2.037040] mlb0: failed to power up resource 253 ret -13 > > [2.037495] nand: failed to power up resource 265 ret -13 > > [2.037951] nand: failed to power up resource 265 ret -13 > > [2.038416] pwm0: failed to power up resource 191 ret -13 > > [2.038868] pwm1: failed to power up resource 192 ret -13 > > [2.039320] pwm2: failed to power up resource 193 ret -13 > > [2.039786] pwm3: failed to power up resource 194 ret -13 > > [2.040239] pwm4: failed to power up resource 195 ret -13 > > [2.040692] pwm5: failed to power up resource 196 ret -13 > > [2.041142] pwm6: failed to power up resource 197 ret -13 > > [2.041596] pwm7: failed to power up resource 198 ret -13 > > [2.042073] amix: failed to power up resource 458 ret -13 > > [2.042558] lpspi0: failed to power up resource 53 ret -13 > > [2.043033] lpspi1: failed to power up resource 54 ret -13 > > [2.043501] lpspi2: failed to power up resource 55 ret -13 > > [2.043992] lpspi3: failed to power up resource 56 ret -13 > > [2.044460] lpuart0: failed to power up resource 57 ret -13 > > [2.044935] lpuart2: failed to power up resource 59 ret -13 > > [2.045409] lpuart3: failed to power up resource 60 ret -13 > > [2.055014] sim0: failed to power up resource 62 ret -13 > > [2.055510] adc0: failed to power up resource 101 ret -13 > > [2.056467] lpi2c0: failed to power up resource 96 ret -13 > > [2.056946] lpi2c1: failed to power up resource 97 ret -13 > > [2.057424] lpi2c2: failed to power up resource 98 ret -13 > > [2.057898] lpi2c3: failed to power up resource 99 ret -13 > > [2.058371] can0: failed
Re: [PATCH] mm/vmstat: Add events for PMD based THP migration without split
On 2020-06-01 21:20, Anshuman Khandual wrote: ... also important: maybe this patch should also be tracking other causes of THP PMD migration failure, in order to get a truer accounting of the situation. I hope one of the experts here can weigh in on that... Is there any other failure reasons which are only specific to THP migration. Else, adding stats about generic migration failure reasons will just blur the overall understanding about THP migration successes and failure cases that results in splitting. Thinking about that: we do have PGMIGRATE_SUCCESS and PGMIGRATE_FAIL, so I suppose comparing those numbers with the new THP_PMD_MIGRATION_SUCCESS and THP_PMD_MIGRATION_FAILURE events should cover it. However, the fact that this is under discussion hints at the need for a bit of documentation help. What do you think about adding some notes about all of this to, say, Documentation/vm/page_migration.rst ? thanks, -- John Hubbard NVIDIA
RE: [PATCH] driver core: platform: expose numa_node to users in sysfs
> -Original Message-
> From: Greg KH [mailto:gre...@linuxfoundation.org]
> Sent: Tuesday, June 2, 2020 4:24 PM
> To: Song Bao Hua (Barry Song)
> Cc: raf...@kernel.org; io...@lists.linux-foundation.org;
> linux-arm-ker...@lists.infradead.org; linux-kernel@vger.kernel.org; Linuxarm
> ; Zengtao (B) ; Robin
> Murphy
> Subject: Re: [PATCH] driver core: platform: expose numa_node to users in sysfs
>
> On Tue, Jun 02, 2020 at 03:01:39PM +1200, Barry Song wrote:
> > For some platform devices like iommu, particually ARM smmu, users may
> > care about the numa locality. for example, if threads and drivers run
> > near iommu, they may get much better performance on dma_unmap_sg.
> > For other platform devices, users may still want to know the hardware
> > topology.
> >
> > Cc: Prime Zeng
> > Cc: Robin Murphy
> > Signed-off-by: Barry Song
> > ---
> > drivers/base/platform.c | 26 +-
> > 1 file changed, 25 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/base/platform.c b/drivers/base/platform.c
> > index b27d0f6c18c9..7794b9a38d82 100644
> > --- a/drivers/base/platform.c
> > +++ b/drivers/base/platform.c
> > @@ -1062,13 +1062,37 @@ static ssize_t driver_override_show(struct
> device *dev,
> > }
> > static DEVICE_ATTR_RW(driver_override);
> >
> > +static ssize_t numa_node_show(struct device *dev,
> > + struct device_attribute *attr, char *buf)
> > +{
> > + return sprintf(buf, "%d\n", dev_to_node(dev));
> > +}
> > +static DEVICE_ATTR_RO(numa_node);
> > +
> > +static umode_t platform_dev_attrs_visible(struct kobject *kobj, struct
> attribute *a,
> > + int n)
> > +{
> > + struct device *dev = container_of(kobj, typeof(*dev), kobj);
> > +
> > + if (a == _attr_numa_node.attr &&
> > + dev_to_node(dev) == NUMA_NO_NODE)
> > + return 0;
> > +
> > + return a->mode;
> > +}
> >
> > static struct attribute *platform_dev_attrs[] = {
> > _attr_modalias.attr,
> > + _attr_numa_node.attr,
> > _attr_driver_override.attr,
> > NULL,
> > };
> > -ATTRIBUTE_GROUPS(platform_dev);
> > +
> > +static struct attribute_group platform_dev_group = {
> > + .attrs = platform_dev_attrs,
> > + .is_visible = platform_dev_attrs_visible,
> > +};
> > +__ATTRIBUTE_GROUPS(platform_dev);
> >
> > static int platform_uevent(struct device *dev, struct kobj_uevent_env *env)
> > {
>
> Platform devices are NUMA? That's crazy, and feels like a total abuse
> of platform devices and drivers that really should belong on a "real"
> bus.
I am not sure if it is an abuse of platform device. But smmu is a platform
device,
drivers/iommu/arm-smmu-v3.c is a platform driver.
In a typical ARM server, there are maybe multiple SMMU devices which can support
IO virtual address and page tables for other devices on PCI-like busses.
Each different SMMU device might be close to different NUMA node. There is
really a hardware topology.
If you have multiple CPU packages in a NUMA server, some platform devices might
Belong to CPU0, some other might belong to CPU1.
-barry
>
> What drivers in the kernel today have this issue?
>
> thanks,
>
> greg k-h
linux-next: manual merge of the irqchip tree with the tip tree
Hi all,
Today's linux-next merge of the irqchip tree got a conflict in:
drivers/irqchip/Kconfig
between commit:
d77aeb5d403d ("irqchip: Fix "Loongson HyperTransport Vector support" driver
build on all non-MIPS platforms")
from the tip tree and commit:
4a786cc36028 ("irqchip/loongson-htvec: Don't compile when COMPILE_TEST is
selected")
from the irqchip tree.
I fixed it up (I just used the latter) 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
pgp0N7HCofwOe.pgp
Description: OpenPGP digital signature
[PATCH] spi: tegra20-sflash: call pm_runtime_put in case of pm_runtime_get failure
The counter is incremented via pm_runtime_get even in failure case.
To correct the counter call pm_runtime_put in case of failure, too.
Signed-off-by: Navid Emamdoost
---
drivers/spi/spi-tegra20-sflash.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/spi/spi-tegra20-sflash.c b/drivers/spi/spi-tegra20-sflash.c
index 514429379206..33c34f9c2021 100644
--- a/drivers/spi/spi-tegra20-sflash.c
+++ b/drivers/spi/spi-tegra20-sflash.c
@@ -552,6 +552,7 @@ static int tegra_sflash_resume(struct device *dev)
ret = pm_runtime_get_sync(dev);
if (ret < 0) {
+ pm_runtime_put(dev);
dev_err(dev, "pm runtime failed, e = %d\n", ret);
return ret;
}
--
2.17.1
Re: [LKP] Re: 28307d938f ("percpu: make pcpu_alloc() aware of current gfp .."): BUG: kernel reboot-without-warning in boot stage
Hi Filipe, LKP checked blow dmesg as the indicator in this problem [0.144174] RAMDISK: [mem 0x7fa2e000-0x7fff] [0.144559] ACPI: Early table checksum verification disabled [0.144985] ACPI: RSDP 0x000F5850 14 (v00 BOCHS ) [0.145424] ACPI: RSDT 0xBFFE15C9 30 (v01 BOCHS BXPCRSDT 0001 BXPC 0001) [0.146051] ACPI: FACP 0xBFFE149D 74 (v01 BOCHS BXPCFACP 0001 BXPC 0001) BUG: kernel reboot-without-warning in boot stage And i have reproduced it with script in attachment. this issue is gone when i reverted this commit 28307d938f Please note that - i reproduced it with kernel compiled by gcc-5 - i failed to reproduce it in kernel compiled by gcc-7 so far :~/1787$ ./reproduce.sh obj/arch/x86/boot/bzImage qemu-system-x86_64 -enable-kvm -cpu Haswell,+smep,+smap -kernel obj/arch/x86/boot/bzImage -m 8192 -smp 2 -device e1000,netdev=net0 -netdev user,id=net0,hostfwd=tcp::32032-:22 -boot order=nc -no-reboot -watchdog i6300esb -watchdog-action debug -rtc base=localtime -serial stdio -display none -monitor null -append root=/dev/ram0 hung_task_panic=1 debug apic=debug sysrq_always_enabled rcupdate.rcu_cpu_stall_timeout=100 net.ifnames=0 printk.devkmsg=on panic=-1 softlockup_panic=1 nmi_watchdog=panic oops=panic load_ramdisk=2 prompt_ramdisk=0 drbd.minor_count=8 systemd.log_level=err ignore_loglevel console=tty0 earlyprintk=ttyS0,115200 console=ttyS0,115200 vga=normal rw rcuperf.shutdown=0 watchdog_thresh=60 early console in setup code Wrong EFI loader signature. early console in extract_kernel input_data: 0x06f752d8 input_len: 0x0130dd3c output: 0x0100 output_len: 0x07200a48 kernel_total_size: 0x06826000 needed_size: 0x0740 trampoline_32bit: 0x0009d000 Decompressing Linux... Parsing ELF... done. Booting the kernel. [ 0.00] Linux version 5.7.0-rc4-00168-g28307d938fb2 (lizhijian@shao2-debian) (gcc version 5.5.0 20171010 (Debian 5.5.0-12), GNU ld (GNU Binutils for Debian) 2.34) #2 SMP PREEMPT Tue Jun 2 11:23:59 CST 2020 [ 0.00] Command line: root=/dev/ram0 hung_task_panic=1 debug apic=debug sysrq_always_enabled rcupdate.rcu_cpu_stall_timeout=100 net.ifnames=0 printk.devkmsg=on panic=-1 softlockup_panic=1 nmi_watchdog=panic oops=panic load_ramdisk=2 prompt_ramdisk=0 drbd.minor_count=8 systemd.log_level=err ignore_loglevel console=tty0 earlyprintk=ttyS0,115200 console=ttyS0,115200 vga=normal rw rcuperf.shutdown=0 watchdog_thresh=60 [ 0.00] x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point registers' [ 0.00] x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers' [ 0.00] x86/fpu: Supporting XSAVE feature 0x004: 'AVX registers' [ 0.00] x86/fpu: xstate_offset[2]: 576, xstate_sizes[2]: 256 [ 0.00] x86/fpu: Enabled xstate features 0x7, context size is 832 bytes, using 'standard' format. [ 0.00] BIOS-provided physical RAM map: [ 0.00] BIOS-e820: [mem 0x-0x0009fbff] usable [ 0.00] BIOS-e820: [mem 0x0009fc00-0x0009] reserved [ 0.00] BIOS-e820: [mem 0x000f-0x000f] reserved [ 0.00] BIOS-e820: [mem 0x0010-0xbffd] usable [ 0.00] BIOS-e820: [mem 0xbffe-0xbfff] reserved [ 0.00] BIOS-e820: [mem 0xfeffc000-0xfeff] reserved [ 0.00] BIOS-e820: [mem 0xfffc-0x] reserved [ 0.00] BIOS-e820: [mem 0x0001-0x00023fff] usable [ 0.00] printk: debug: ignoring loglevel setting. [ 0.00] printk: bootconsole [earlyser0] enabled [ 0.00] NX (Execute Disable) protection: active [ 0.00] SMBIOS 2.8 present. [ 0.00] DMI: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014 [ 0.00] Hypervisor detected: KVM [ 0.00] kvm-clock: Using msrs 4b564d01 and 4b564d00 [ 0.02] kvm-clock: cpu 0, msr 7601001, primary cpu clock [ 0.02] kvm-clock: using sched offset of 2661499940 cycles [ 0.000603] clocksource: kvm-clock: mask: 0x max_cycles: 0x1cd42e4dffb, max_idle_ns: 881590591483 ns [ 0.002261] tsc: Detected 3407.998 MHz processor [ 0.005351] e820: update [mem 0x-0x0fff] usable ==> reserved [ 0.005986] e820: remove [mem 0x000a-0x000f] usable [ 0.006535] last_pfn = 0x24 max_arch_pfn = 0x4 [ 0.007091] MTRR default type: write-back [ 0.007477] MTRR fixed ranges enabled: [ 0.007845] 0-9 write-back [ 0.008191] A-B uncachable [ 0.008536] C-F write-protect [ 0.008906] MTRR variable ranges enabled: [ 0.009293] 0 base 00C000 mask FFC000 uncachable [ 0.009818] 1 disabled [ 0.010064] 2 disabled [ 0.010314] 3 disabled [ 0.010561] 4 disabled [ 0.010822] 5 disabled [ 0.011072] 6
[PATCH] spi: spi-ti-qspi: call pm_runtime_put on pm_runtime_get failure
The counter is incremented via pm_runtime_get even in failure case.
To correct the counter call pm_runtime_put in case of failure, too.
Signed-off-by: Navid Emamdoost
---
drivers/spi/spi-ti-qspi.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/spi/spi-ti-qspi.c b/drivers/spi/spi-ti-qspi.c
index 366a3e5cca6b..dfb811c5ef76 100644
--- a/drivers/spi/spi-ti-qspi.c
+++ b/drivers/spi/spi-ti-qspi.c
@@ -174,6 +174,7 @@ static int ti_qspi_setup(struct spi_device *spi)
ret = pm_runtime_get_sync(qspi->dev);
if (ret < 0) {
+ pm_runtime_put_autosuspend(qspi->dev);
dev_err(qspi->dev, "pm_runtime_get_sync() failed\n");
return ret;
}
--
2.17.1
Re: [PATCH] media: rkvdec: Fix H264 scaling list order
Hi Jonas,
Thanks a lot for the fix! Indeed it fixes
a few bitstream that had artifacts :)
On Fri, 2020-05-22 at 20:21 +, Jonas Karlman wrote:
> The Rockchip Video Decoder driver is expecting that the values in a
> scaling list are in zig-zag order and applies the inverse scanning process
> to get the values in matrix order.
>
> Commit 0b0393d59eb4 ("media: uapi: h264: clarify expected
> scaling_list_4x4/8x8 order") clarified that the values in the scaling list
> should already be in matrix order.
>
> Fix this by removing the reordering and change to use two memcpy.
>
> Fixes: cd33c830448b ("media: rkvdec: Add the rkvdec driver")
> Signed-off-by: Jonas Karlman
> ---
> drivers/staging/media/rkvdec/rkvdec-h264.c | 70 +++---
> 1 file changed, 22 insertions(+), 48 deletions(-)
>
> diff --git a/drivers/staging/media/rkvdec/rkvdec-h264.c
> b/drivers/staging/media/rkvdec/rkvdec-h264.c
> index cd4980d06be7..2719f0c66a4a 100644
> --- a/drivers/staging/media/rkvdec/rkvdec-h264.c
> +++ b/drivers/staging/media/rkvdec/rkvdec-h264.c
> @@ -18,11 +18,16 @@
> /* Size with u32 units. */
> #define RKV_CABAC_INIT_BUFFER_SIZE (3680 + 128)
> #define RKV_RPS_SIZE ((128 + 128) / 4)
> -#define RKV_SCALING_LIST_SIZE(6 * 16 + 6 * 64 + 128)
> #define RKV_ERROR_INFO_SIZE (256 * 144 * 4)
>
> #define RKVDEC_NUM_REFLIST 3
>
> +struct rkvdec_scaling_matrix {
How about we call this rkvdec_scaling_list
or even rkvdec_h264_scaling_list?
It'll make code more readable and easier to grep.
> + u8 scaling_list_4x4[6][16];
> + u8 scaling_list_8x8[6][64];
> + u8 padding[128];
Oops, something is wrong here, maybe some
mistake when porting code around.
Rockchip MPP defines the scaling list size as:
#define RKV_SCALING_LIST_SIZE (6*16 + 2*64 + 128)
Consistently with the fact that 4:4:4 sampling
is not supported (chroma_format_idc == 3),
only the first two scaling matrices are used.
Moreover, given all these buffers are specified separately
(see below), I bet not even the 128 padding bytes
are needed.
> +};
> +
> struct rkvdec_sps_pps_packet {
> u32 info[8];
> };
> @@ -86,7 +91,7 @@ struct rkvdec_ps_field {
> /* Data structure describing auxiliary buffer format. */
> struct rkvdec_h264_priv_tbl {
> s8 cabac_table[4][464][2];
As can be seen, all these buffers can be allocated
independently, which perhaps could reduce the
pressure on the DMA allocator.
> - u8 scaling_list[RKV_SCALING_LIST_SIZE];
> + struct rkvdec_scaling_matrix scaling_list;
> u32 rps[RKV_RPS_SIZE];
> struct rkvdec_sps_pps_packet param_set[256];
> u8 err_info[RKV_ERROR_INFO_SIZE];
In particular, I wonder if the error info stuff
is really required.
I guess we'll want to merge a simple fix,
so no need to address any of these questions
for now.
With the struct rkvdec_scaling_matrix rename:
Reviewed-by: Ezequiel Garcia
Thanks,
Ezequiel
> @@ -785,56 +790,25 @@ static void assemble_hw_rps(struct rkvdec_ctx *ctx,
> }
> }
>
> -/*
> - * NOTE: The values in a scaling list are in zig-zag order, apply inverse
> - * scanning process to get the values in matrix order.
> - */
> -static const u32 zig_zag_4x4[16] = {
> - 0, 1, 4, 8, 5, 2, 3, 6, 9, 12, 13, 10, 7, 11, 14, 15
> -};
> -
> -static const u32 zig_zag_8x8[64] = {
> - 0, 1, 8, 16, 9, 2, 3, 10, 17, 24, 32, 25, 18, 11, 4, 5,
> - 12, 19, 26, 33, 40, 48, 41, 34, 27, 20, 13, 6, 7, 14, 21, 28,
> - 35, 42, 49, 56, 57, 50, 43, 36, 29, 22, 15, 23, 30, 37, 44, 51,
> - 58, 59, 52, 45, 38, 31, 39, 46, 53, 60, 61, 54, 47, 55, 62, 63
> -};
> -
> -static void reorder_scaling_list(struct rkvdec_ctx *ctx,
> - struct rkvdec_h264_run *run)
> +static void assemble_hw_scaling_list(struct rkvdec_ctx *ctx,
> + struct rkvdec_h264_run *run)
> {
> const struct v4l2_ctrl_h264_scaling_matrix *scaling =
> run->scaling_matrix;
> - const size_t num_list_4x4 = ARRAY_SIZE(scaling->scaling_list_4x4);
> - const size_t list_len_4x4 = ARRAY_SIZE(scaling->scaling_list_4x4[0]);
> - const size_t num_list_8x8 = ARRAY_SIZE(scaling->scaling_list_8x8);
> - const size_t list_len_8x8 = ARRAY_SIZE(scaling->scaling_list_8x8[0]);
> struct rkvdec_h264_ctx *h264_ctx = ctx->priv;
> struct rkvdec_h264_priv_tbl *tbl = h264_ctx->priv_tbl.cpu;
> - u8 *dst = tbl->scaling_list;
> - const u8 *src;
> - int i, j;
> -
> - BUILD_BUG_ON(ARRAY_SIZE(zig_zag_4x4) != list_len_4x4);
> - BUILD_BUG_ON(ARRAY_SIZE(zig_zag_8x8) != list_len_8x8);
> - BUILD_BUG_ON(ARRAY_SIZE(tbl->scaling_list) <
> - num_list_4x4 * list_len_4x4 +
> - num_list_8x8 * list_len_8x8);
> -
> - src = >scaling_list_4x4[0][0];
> - for (i = 0; i < num_list_4x4; ++i) {
> - for (j = 0; j < list_len_4x4; ++j)
> - dst[zig_zag_4x4[j]] = src[j];
> -
Re: [PATCH] driver core: platform: need consistent spacing around '-'
On Tue, Jun 02, 2020 at 03:47:17PM +1200, Barry Song wrote: > Signed-off-by: Barry Song > --- > drivers/base/platform.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/base/platform.c b/drivers/base/platform.c > index b27d0f6c18c9..ab9408182a0d 100644 > --- a/drivers/base/platform.c > +++ b/drivers/base/platform.c > @@ -1005,7 +1005,7 @@ static ssize_t modalias_show(struct device *dev, struct > device_attribute *a, > if (len != -ENODEV) > return len; > > - len = acpi_device_modalias(dev, buf, PAGE_SIZE -1); > + len = acpi_device_modalias(dev, buf, PAGE_SIZE - 1); > if (len != -ENODEV) > return len; > > -- > 2.23.0 > > Hi, This is the friendly patch-bot of Greg Kroah-Hartman. You have sent him a patch that has triggered this response. He used to manually respond to these common problems, but in order to save his sanity (he kept writing the same thing over and over, yet to different people), I was created. Hopefully you will not take offence and will fix the problem in your patch and resubmit it so that it can be accepted into the Linux kernel tree. You are receiving this message because of the following common error(s) as indicated below: - You did not specify a description of why the patch is needed, or possibly, any description at all, in the email body. Please read the section entitled "The canonical patch format" in the kernel file, Documentation/SubmittingPatches for what is needed in order to properly describe the change. If you wish to discuss this problem further, or you have questions about how to resolve this issue, please feel free to respond to this email and Greg will reply once he has dug out from the pending patches received from other developers. thanks, greg k-h's patch email bot
[PATCH 1/2] perf tools: check libasan and libubsan in Makefile.config
When build perf with ASan or UBSan, if libasan or libubsan can not find, the feature-glibc is 0 and there exists the following error log which is wrong, because we can find gnu/libc-version.h in /usr/include, glibc-devel is also installed. [yangtiezhu@linux perf]$ make DEBUG=1 EXTRA_CFLAGS='-fno-omit-frame-pointer -fsanitize=address' BUILD: Doing 'make -j4' parallel build HOSTCC fixdep.o HOSTLD fixdep-in.o LINK fixdep :1:0: warning: -fsanitize=address and -fsanitize=kernel-address are not supported for this target :1:0: warning: -fsanitize=address not supported for this target Auto-detecting system features: ... dwarf: [ OFF ] ...dwarf_getlocations: [ OFF ] ... glibc: [ OFF ] ... gtk2: [ OFF ] ... libaudit: [ OFF ] ...libbfd: [ OFF ] ...libcap: [ OFF ] ...libelf: [ OFF ] ... libnuma: [ OFF ] ...numa_num_possible_cpus: [ OFF ] ... libperl: [ OFF ] ... libpython: [ OFF ] ... libcrypto: [ OFF ] ... libunwind: [ OFF ] ...libdw-dwarf-unwind: [ OFF ] ... zlib: [ OFF ] ... lzma: [ OFF ] ... get_cpuid: [ OFF ] ... bpf: [ OFF ] ...libaio: [ OFF ] ... libzstd: [ OFF ] ...disassembler-four-args: [ OFF ] Makefile.config:393: *** No gnu/libc-version.h found, please install glibc-dev[el]. Stop. Makefile.perf:224: recipe for target 'sub-make' failed make[1]: *** [sub-make] Error 2 Makefile:69: recipe for target 'all' failed make: *** [all] Error 2 [yangtiezhu@linux perf]$ ls /usr/include/gnu/libc-version.h /usr/include/gnu/libc-version.h After install libasan and libubsan, the feature-glibc is 1 and the build process is success, so the cause is related with libasan or libubsan, we should check them and print an error log to reflect the reality. Signed-off-by: Tiezhu Yang --- tools/perf/Makefile.config | 6 ++ 1 file changed, 6 insertions(+) diff --git a/tools/perf/Makefile.config b/tools/perf/Makefile.config index 12a8204..b699d21 100644 --- a/tools/perf/Makefile.config +++ b/tools/perf/Makefile.config @@ -387,6 +387,12 @@ else NO_LIBBPF := 1 NO_JVMTI := 1 else + ifneq ($(shell ldconfig -p | grep libasan >/dev/null 2>&1; echo $$?), 0) +msg := $(error No libasan found, please install libasan); + endif + ifneq ($(shell ldconfig -p | grep libubsan >/dev/null 2>&1; echo $$?), 0) +msg := $(error No libubsan found, please install libubsan); + endif ifneq ($(filter s% -static%,$(LDFLAGS),),) msg := $(error No static glibc found, please install glibc-static); else -- 2.1.0
Re: [PATCH] driver core: platform: expose numa_node to users in sysfs
On Tue, Jun 02, 2020 at 03:01:39PM +1200, Barry Song wrote:
> For some platform devices like iommu, particually ARM smmu, users may
> care about the numa locality. for example, if threads and drivers run
> near iommu, they may get much better performance on dma_unmap_sg.
> For other platform devices, users may still want to know the hardware
> topology.
>
> Cc: Prime Zeng
> Cc: Robin Murphy
> Signed-off-by: Barry Song
> ---
> drivers/base/platform.c | 26 +-
> 1 file changed, 25 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/base/platform.c b/drivers/base/platform.c
> index b27d0f6c18c9..7794b9a38d82 100644
> --- a/drivers/base/platform.c
> +++ b/drivers/base/platform.c
> @@ -1062,13 +1062,37 @@ static ssize_t driver_override_show(struct device
> *dev,
> }
> static DEVICE_ATTR_RW(driver_override);
>
> +static ssize_t numa_node_show(struct device *dev,
> + struct device_attribute *attr, char *buf)
> +{
> + return sprintf(buf, "%d\n", dev_to_node(dev));
> +}
> +static DEVICE_ATTR_RO(numa_node);
> +
> +static umode_t platform_dev_attrs_visible(struct kobject *kobj, struct
> attribute *a,
> + int n)
> +{
> + struct device *dev = container_of(kobj, typeof(*dev), kobj);
> +
> + if (a == _attr_numa_node.attr &&
> + dev_to_node(dev) == NUMA_NO_NODE)
> + return 0;
> +
> + return a->mode;
> +}
>
> static struct attribute *platform_dev_attrs[] = {
> _attr_modalias.attr,
> + _attr_numa_node.attr,
> _attr_driver_override.attr,
> NULL,
> };
> -ATTRIBUTE_GROUPS(platform_dev);
> +
> +static struct attribute_group platform_dev_group = {
> + .attrs = platform_dev_attrs,
> + .is_visible = platform_dev_attrs_visible,
> +};
> +__ATTRIBUTE_GROUPS(platform_dev);
>
> static int platform_uevent(struct device *dev, struct kobj_uevent_env *env)
> {
Also you forgot a new entry in Documentation/ABI/ :(
Re: [PATCH] driver core: platform: expose numa_node to users in sysfs
On Tue, Jun 02, 2020 at 03:01:39PM +1200, Barry Song wrote:
> For some platform devices like iommu, particually ARM smmu, users may
> care about the numa locality. for example, if threads and drivers run
> near iommu, they may get much better performance on dma_unmap_sg.
> For other platform devices, users may still want to know the hardware
> topology.
>
> Cc: Prime Zeng
> Cc: Robin Murphy
> Signed-off-by: Barry Song
> ---
> drivers/base/platform.c | 26 +-
> 1 file changed, 25 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/base/platform.c b/drivers/base/platform.c
> index b27d0f6c18c9..7794b9a38d82 100644
> --- a/drivers/base/platform.c
> +++ b/drivers/base/platform.c
> @@ -1062,13 +1062,37 @@ static ssize_t driver_override_show(struct device
> *dev,
> }
> static DEVICE_ATTR_RW(driver_override);
>
> +static ssize_t numa_node_show(struct device *dev,
> + struct device_attribute *attr, char *buf)
> +{
> + return sprintf(buf, "%d\n", dev_to_node(dev));
> +}
> +static DEVICE_ATTR_RO(numa_node);
> +
> +static umode_t platform_dev_attrs_visible(struct kobject *kobj, struct
> attribute *a,
> + int n)
> +{
> + struct device *dev = container_of(kobj, typeof(*dev), kobj);
> +
> + if (a == _attr_numa_node.attr &&
> + dev_to_node(dev) == NUMA_NO_NODE)
> + return 0;
> +
> + return a->mode;
> +}
>
> static struct attribute *platform_dev_attrs[] = {
> _attr_modalias.attr,
> + _attr_numa_node.attr,
> _attr_driver_override.attr,
> NULL,
> };
> -ATTRIBUTE_GROUPS(platform_dev);
> +
> +static struct attribute_group platform_dev_group = {
> + .attrs = platform_dev_attrs,
> + .is_visible = platform_dev_attrs_visible,
> +};
> +__ATTRIBUTE_GROUPS(platform_dev);
>
> static int platform_uevent(struct device *dev, struct kobj_uevent_env *env)
> {
Platform devices are NUMA? That's crazy, and feels like a total abuse
of platform devices and drivers that really should belong on a "real"
bus.
What drivers in the kernel today have this issue?
thanks,
greg k-h
Re: [PATCH net-next] af-packet: new flag to indicate all csums are good
On 01-06-2020 23:45, David Miller wrote: > From: Victor Julien > Date: Mon, 1 Jun 2020 22:49:37 +0200 > >> @@ -472,6 +472,12 @@ TP_STATUS_CSUM_VALIDThis flag indicates that at >> least the transport >> validated on the kernel side. If the flag is not set >> then we are free to check the checksum by ourselves >> provided that TP_STATUS_CSUMNOTREADY is also not set. >> +TP_STATUS_CSUM_UNNECESSARY This flag indicates that the driver validated >> all >> +the packets csums. If it is not set it might be that >> +the driver doesn't support this, or that one of the >> +layers csums is bad. TP_STATUS_CSUM_VALID may still >> +be set if the transport layer csum is correct or >> +if the driver supports only this mode. >> == >> === > ^ > > I think you need to reformat these dividers. > Yes of course. Think I'll have to reformat the whole table then, at least for `rst2pdf` to accept it. Alternatively I can try to come up with a shorter name for the flag, but I'm not really coming up with anything so far. -- - Victor Julien http://www.inliniac.net/ PGP: http://www.inliniac.net/victorjulien.asc -
Re: [PATCH 2/2] vhost: convert get_user_pages() --> pin_user_pages()
On Fri, May 29, 2020 at 04:43:09PM -0700, John Hubbard wrote: > This code was using get_user_pages*(), in approximately a "Case 5" > scenario (accessing the data within a page), using the categorization > from [1]. That means that it's time to convert the get_user_pages*() + > put_page() calls to pin_user_pages*() + unpin_user_pages() calls. > > There is some helpful background in [2]: basically, this is a small > part of fixing a long-standing disconnect between pinning pages, and > file systems' use of those pages. > > [1] Documentation/core-api/pin_user_pages.rst > > [2] "Explicit pinning of user-space pages": > https://lwn.net/Articles/807108/ > > Cc: Michael S. Tsirkin > Cc: Jason Wang > Cc: k...@vger.kernel.org > Cc: virtualizat...@lists.linux-foundation.org > Cc: net...@vger.kernel.org > Signed-off-by: John Hubbard Acked-by: Michael S. Tsirkin > --- > drivers/vhost/vhost.c | 5 ++--- > 1 file changed, 2 insertions(+), 3 deletions(-) > > diff --git a/drivers/vhost/vhost.c b/drivers/vhost/vhost.c > index 21a59b598ed8..596132a96cd5 100644 > --- a/drivers/vhost/vhost.c > +++ b/drivers/vhost/vhost.c > @@ -1762,15 +1762,14 @@ static int set_bit_to_user(int nr, void __user *addr) > int bit = nr + (log % PAGE_SIZE) * 8; > int r; > > - r = get_user_pages_fast(log, 1, FOLL_WRITE, ); > + r = pin_user_pages_fast(log, 1, FOLL_WRITE, ); > if (r < 0) > return r; > BUG_ON(r != 1); > base = kmap_atomic(page); > set_bit(bit, base); > kunmap_atomic(base); > - set_page_dirty_lock(page); > - put_page(page); > + unpin_user_pages_dirty_lock(, 1, true); > return 0; > } > > -- > 2.26.2
Re: [PATCH] mm/vmstat: Add events for PMD based THP migration without split
On 06/02/2020 08:50 AM, John Hubbard wrote: > On 2020-06-01 09:57, Daniel Jordan wrote: >> Hi Anshuman, >> >> On Fri, May 22, 2020 at 09:04:04AM +0530, Anshuman Khandual wrote: >>> This adds the following two new VM events which will help in validating PMD >>> based THP migration without split. Statistics reported through these events >>> will help in performance debugging. >>> >>> 1. THP_PMD_MIGRATION_SUCCESS >>> 2. THP_PMD_MIGRATION_FAILURE >> >> The names suggest a binary event similar to the existing >> pgmigrate_success/fail, but FAILURE only tracks one kind of migration error, >> and then only when the thp is successfully split, so shouldn't it be called >> SPLIT instead? >> > > So the full description of the situation, which we're trying to compress into > a shorter name, is "THP pmd migration failure, due to successfully splitting > the THP". From that, the beginning part is the real point here, while the last > part is less important. In other words, the users of these events are people > who are trying to quantify THP migrations, and these events are particularly > relevant for that. The "THP migration failed" is more important here than > the reason that it failed. Or so I believe so far. Absolutely, these events really help in quantifying THP migration successes or their failures that involve splitting. > > So I still think that the names are really quite good, but your point is Agreed. > also important: maybe this patch should also be tracking other causes > of THP PMD migration failure, in order to get a truer accounting of the > situation. Is there any other failure reasons which are only specific to THP migration. Else, adding stats about generic migration failure reasons will just blur the overall understanding about THP migration successes and failure cases that results in splitting.
[PATCH 2/2] perf tools: Remove some duplicated includes
There exists some duplicated includes in tools/perf, remove them. Signed-off-by: Tiezhu Yang --- tools/perf/builtin-report.c | 1 - tools/perf/util/annotate.c | 1 - tools/perf/util/auxtrace.c | 1 - tools/perf/util/config.c| 1 - tools/perf/util/session.c | 1 - 5 files changed, 5 deletions(-) diff --git a/tools/perf/builtin-report.c b/tools/perf/builtin-report.c index ba63390..5425a2c 100644 --- a/tools/perf/builtin-report.c +++ b/tools/perf/builtin-report.c @@ -47,7 +47,6 @@ #include "util/time-utils.h" #include "util/auxtrace.h" #include "util/units.h" -#include "util/branch.h" #include "util/util.h" // perf_tip() #include "ui/ui.h" #include "ui/progress.h" diff --git a/tools/perf/util/annotate.c b/tools/perf/util/annotate.c index d828c2d..76bfb4a 100644 --- a/tools/perf/util/annotate.c +++ b/tools/perf/util/annotate.c @@ -41,7 +41,6 @@ #include #include #include -#include #include #include diff --git a/tools/perf/util/auxtrace.c b/tools/perf/util/auxtrace.c index 749487a..94a8f4f 100644 --- a/tools/perf/util/auxtrace.c +++ b/tools/perf/util/auxtrace.c @@ -55,7 +55,6 @@ #include "util/mmap.h" #include -#include #include "symbol/kallsyms.h" #include diff --git a/tools/perf/util/config.c b/tools/perf/util/config.c index ef38eba..64f14a5 100644 --- a/tools/perf/util/config.c +++ b/tools/perf/util/config.c @@ -20,7 +20,6 @@ #include "build-id.h" #include "debug.h" #include "config.h" -#include "debug.h" #include #include #include diff --git a/tools/perf/util/session.c b/tools/perf/util/session.c index c11d89e..5550e26e 100644 --- a/tools/perf/util/session.c +++ b/tools/perf/util/session.c @@ -33,7 +33,6 @@ #include "../perf.h" #include "arch/common.h" #include -#include #ifdef HAVE_ZSTD_SUPPORT static int perf_session__process_compressed_event(struct perf_session *session, -- 2.1.0
Re: [PATCH] mm/compaction: avoid VM_BUG_ON(PageSlab()) in page_mapcount()
On Mon, 1 Jun 2020 21:05:25 -0700 (PDT) Hugh Dickins wrote:
> Andrew, I've noticed that this buggy
> mm-compaction-avoid-vm_bug_onpageslab-in-page_mapcount.patch
> was still in Friday's mmotm 2020-05-29-16-09, despite its replacement
> 6988f31d558a ("mm: remove VM_BUG_ON(PageSlab()) from page_mapcount()")
> getting into 5.7, thanks to your "incoming" to Linus on that day.
Thanks, gone.
Re: [PATCH v2 2/9] vfio/fsl-mc: Scan DPRC objects on vfio-fsl-mc driver bind
On Fri, 8 May 2020 10:20:32 +0300
Diana Craciun wrote:
> The DPRC (Data Path Resource Container) device is a bus device and has
> child devices attached to it. When the vfio-fsl-mc driver is probed
> the DPRC is scanned and the child devices discovered and initialized.
>
> Signed-off-by: Bharat Bhushan
> Signed-off-by: Diana Craciun
> ---
> drivers/vfio/fsl-mc/vfio_fsl_mc.c | 106 ++
> drivers/vfio/fsl-mc/vfio_fsl_mc_private.h | 1 +
> 2 files changed, 107 insertions(+)
>
> diff --git a/drivers/vfio/fsl-mc/vfio_fsl_mc.c
> b/drivers/vfio/fsl-mc/vfio_fsl_mc.c
> index 8b53c2a25b32..ea301ba81225 100644
> --- a/drivers/vfio/fsl-mc/vfio_fsl_mc.c
> +++ b/drivers/vfio/fsl-mc/vfio_fsl_mc.c
> @@ -15,6 +15,8 @@
>
> #include "vfio_fsl_mc_private.h"
>
> +static struct fsl_mc_driver vfio_fsl_mc_driver;
> +
> static int vfio_fsl_mc_open(void *device_data)
> {
> if (!try_module_get(THIS_MODULE))
> @@ -84,6 +86,69 @@ static const struct vfio_device_ops vfio_fsl_mc_ops = {
> .mmap = vfio_fsl_mc_mmap,
> };
>
> +static int vfio_fsl_mc_bus_notifier(struct notifier_block *nb,
> + unsigned long action, void *data)
> +{
> + struct vfio_fsl_mc_device *vdev = container_of(nb,
> + struct vfio_fsl_mc_device, nb);
> + struct device *dev = data;
> + struct fsl_mc_device *mc_dev = to_fsl_mc_device(dev);
> + struct fsl_mc_device *mc_cont = to_fsl_mc_device(mc_dev->dev.parent);
> +
> + if (action == BUS_NOTIFY_ADD_DEVICE &&
> + vdev->mc_dev == mc_cont) {
> + mc_dev->driver_override = kasprintf(GFP_KERNEL, "%s",
> + vfio_fsl_mc_ops.name);
> + dev_info(dev, "Setting driver override for device in dprc %s\n",
> + dev_name(_cont->dev));
> + } else if (action == BUS_NOTIFY_BOUND_DRIVER &&
> + vdev->mc_dev == mc_cont) {
> + struct fsl_mc_driver *mc_drv = to_fsl_mc_driver(dev->driver);
> +
> + if (mc_drv && mc_drv != _fsl_mc_driver)
> + dev_warn(dev, "Object %s bound to driver %s while DPRC
> bound to vfio-fsl-mc\n",
> + dev_name(dev), mc_drv->driver.name);
> + }
> +
> + return 0;
> +}
> +
> +static int vfio_fsl_mc_init_device(struct vfio_fsl_mc_device *vdev)
> +{
> + struct fsl_mc_device *mc_dev = vdev->mc_dev;
> + int ret = 0;
> +
> + /* Non-dprc devices share mc_io from parent */
> + if (!is_fsl_mc_bus_dprc(mc_dev)) {
> + struct fsl_mc_device *mc_cont =
> to_fsl_mc_device(mc_dev->dev.parent);
> +
> + mc_dev->mc_io = mc_cont->mc_io;
> + return 0;
> + }
> +
> + vdev->nb.notifier_call = vfio_fsl_mc_bus_notifier;
> + ret = bus_register_notifier(_mc_bus_type, >nb);
> + if (ret)
> + return ret;
> +
> + /* open DPRC, allocate a MC portal */
> + ret = dprc_setup(mc_dev);
> + if (ret < 0) {
> + dev_err(_dev->dev, "Failed to setup DPRC (error = %d)\n",
> ret);
> + bus_unregister_notifier(_mc_bus_type, >nb);
> + return ret;
> + }
> +
> + ret = dprc_scan_container(mc_dev, false);
> + if (ret < 0) {
> + dev_err(_dev->dev, "Container scanning failed: %d\n", ret);
> + bus_unregister_notifier(_mc_bus_type, >nb);
> + dprc_cleanup(mc_dev);
> + }
> +
> + return 0;
The last error branch falls through, did you intend to return 'ret'
here to capture that? Also, nit, ret doesn't need to be initialized.
> +}
> +
> static int vfio_fsl_mc_probe(struct fsl_mc_device *mc_dev)
> {
> struct iommu_group *group;
> @@ -112,9 +177,42 @@ static int vfio_fsl_mc_probe(struct fsl_mc_device
> *mc_dev)
> return ret;
> }
>
> + ret = vfio_fsl_mc_init_device(vdev);
> + if (ret) {
> + vfio_iommu_group_put(group, dev);
> + return ret;
> + }
The error condition value is a bit inconsistent between
vfio_fs_mc_init_device() and here, <0 vs !0. Thanks,
Alex
> +
> return ret;
> }
>
> +static int vfio_fsl_mc_device_remove(struct device *dev, void *data)
> +{
> + struct fsl_mc_device *mc_dev;
> +
> + WARN_ON(!dev);
> + mc_dev = to_fsl_mc_device(dev);
> + if (WARN_ON(!mc_dev))
> + return -ENODEV;
> +
> + kfree(mc_dev->driver_override);
> + mc_dev->driver_override = NULL;
> +
> + /*
> + * The device-specific remove callback will get invoked by device_del()
> + */
> + device_del(_dev->dev);
> + put_device(_dev->dev);
> +
> + return 0;
> +}
> +
> +static void vfio_fsl_mc_cleanup_dprc(struct fsl_mc_device *mc_dev)
> +{
> + device_for_each_child(_dev->dev, NULL, vfio_fsl_mc_device_remove);
> + dprc_cleanup(mc_dev);
> +}
> +
> static int vfio_fsl_mc_remove(struct fsl_mc_device *mc_dev)
> {
> struct
[PATCH] hw_breakpoint: Fix build warnings with clang
kbuild test robot reported few build warnings with hw_breakpoint code when compiled with clang[1]. Fix those. [1]: https://lore.kernel.org/linuxppc-dev/202005192233.oi9cjrta%25...@intel.com/ Reported-by: kbuild test robot Signed-off-by: Ravi Bangoria --- Note: Prepared on top of powerpc/next. arch/powerpc/include/asm/hw_breakpoint.h | 3 --- include/linux/hw_breakpoint.h| 4 2 files changed, 4 insertions(+), 3 deletions(-) diff --git a/arch/powerpc/include/asm/hw_breakpoint.h b/arch/powerpc/include/asm/hw_breakpoint.h index f42a55eb77d2..cb424799da0d 100644 --- a/arch/powerpc/include/asm/hw_breakpoint.h +++ b/arch/powerpc/include/asm/hw_breakpoint.h @@ -70,9 +70,6 @@ extern int hw_breakpoint_exceptions_notify(struct notifier_block *unused, unsigned long val, void *data); int arch_install_hw_breakpoint(struct perf_event *bp); void arch_uninstall_hw_breakpoint(struct perf_event *bp); -int arch_reserve_bp_slot(struct perf_event *bp); -void arch_release_bp_slot(struct perf_event *bp); -void arch_unregister_hw_breakpoint(struct perf_event *bp); void hw_breakpoint_pmu_read(struct perf_event *bp); extern void flush_ptrace_hw_breakpoint(struct task_struct *tsk); diff --git a/include/linux/hw_breakpoint.h b/include/linux/hw_breakpoint.h index 6058c3844a76..521481f0d320 100644 --- a/include/linux/hw_breakpoint.h +++ b/include/linux/hw_breakpoint.h @@ -80,6 +80,10 @@ extern int dbg_reserve_bp_slot(struct perf_event *bp); extern int dbg_release_bp_slot(struct perf_event *bp); extern int reserve_bp_slot(struct perf_event *bp); extern void release_bp_slot(struct perf_event *bp); +extern int hw_breakpoint_weight(struct perf_event *bp); +extern int arch_reserve_bp_slot(struct perf_event *bp); +extern void arch_release_bp_slot(struct perf_event *bp); +extern void arch_unregister_hw_breakpoint(struct perf_event *bp); extern void flush_ptrace_hw_breakpoint(struct task_struct *tsk); -- 2.26.2
Re: [PATCH v2 4/9] vfio/fsl-mc: Implement VFIO_DEVICE_GET_REGION_INFO ioctl call
On Fri, 8 May 2020 10:20:34 +0300
Diana Craciun wrote:
> Expose to userspace information about the memory regions.
>
> Signed-off-by: Bharat Bhushan
> Signed-off-by: Diana Craciun
> ---
> drivers/vfio/fsl-mc/vfio_fsl_mc.c | 77 ++-
> drivers/vfio/fsl-mc/vfio_fsl_mc_private.h | 19 ++
> 2 files changed, 95 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/vfio/fsl-mc/vfio_fsl_mc.c
> b/drivers/vfio/fsl-mc/vfio_fsl_mc.c
> index 8a4d3203b176..c162fa27c02c 100644
> --- a/drivers/vfio/fsl-mc/vfio_fsl_mc.c
> +++ b/drivers/vfio/fsl-mc/vfio_fsl_mc.c
> @@ -17,16 +17,72 @@
>
> static struct fsl_mc_driver vfio_fsl_mc_driver;
>
> +static int vfio_fsl_mc_regions_init(struct vfio_fsl_mc_device *vdev)
> +{
> + struct fsl_mc_device *mc_dev = vdev->mc_dev;
> + int count = mc_dev->obj_desc.region_count;
> + int i;
> +
> + vdev->regions = kcalloc(count, sizeof(struct vfio_fsl_mc_region),
> + GFP_KERNEL);
> + if (!vdev->regions)
> + return -ENOMEM;
> +
> + for (i = 0; i < count; i++) {
> + struct resource *res = _dev->regions[i];
> +
> + vdev->regions[i].addr = res->start;
> + vdev->regions[i].size = PAGE_ALIGN((resource_size(res)));
Why do we need this page alignment to resource_size()? It makes me
worry that we're actually giving the user access to an extended size
that might overlap another device or to MMIO that's not backed by any
device and might trigger a fault when accessed. In vfio-pci we make
some effort to reserve resources when we want to allow mmap of sub-page
ranges. Thanks,
Alex
> + vdev->regions[i].flags = 0;
> + }
> +
> + vdev->num_regions = mc_dev->obj_desc.region_count;
> + return 0;
> +}
> +
> +static void vfio_fsl_mc_regions_cleanup(struct vfio_fsl_mc_device *vdev)
> +{
> + vdev->num_regions = 0;
> + kfree(vdev->regions);
> +}
> +
> static int vfio_fsl_mc_open(void *device_data)
> {
> + struct vfio_fsl_mc_device *vdev = device_data;
> + int ret;
> +
> if (!try_module_get(THIS_MODULE))
> return -ENODEV;
>
> + mutex_lock(>driver_lock);
> + if (!vdev->refcnt) {
> + ret = vfio_fsl_mc_regions_init(vdev);
> + if (ret)
> + goto err_reg_init;
> + }
> + vdev->refcnt++;
> +
> + mutex_unlock(>driver_lock);
> +
> return 0;
> +
> +err_reg_init:
> + mutex_unlock(>driver_lock);
> + module_put(THIS_MODULE);
> + return ret;
> }
>
> static void vfio_fsl_mc_release(void *device_data)
> {
> + struct vfio_fsl_mc_device *vdev = device_data;
> +
> + mutex_lock(>driver_lock);
> +
> + if (!(--vdev->refcnt))
> + vfio_fsl_mc_regions_cleanup(vdev);
> +
> + mutex_unlock(>driver_lock);
> +
> module_put(THIS_MODULE);
> }
>
> @@ -59,7 +115,25 @@ static long vfio_fsl_mc_ioctl(void *device_data, unsigned
> int cmd,
> }
> case VFIO_DEVICE_GET_REGION_INFO:
> {
> - return -ENOTTY;
> + struct vfio_region_info info;
> +
> + minsz = offsetofend(struct vfio_region_info, offset);
> +
> + if (copy_from_user(, (void __user *)arg, minsz))
> + return -EFAULT;
> +
> + if (info.argsz < minsz)
> + return -EINVAL;
> +
> + if (info.index >= vdev->num_regions)
> + return -EINVAL;
> +
> + /* map offset to the physical address */
> + info.offset = VFIO_FSL_MC_INDEX_TO_OFFSET(info.index);
> + info.size = vdev->regions[info.index].size;
> + info.flags = vdev->regions[info.index].flags;
> +
> + return copy_to_user((void __user *)arg, , minsz);
> }
> case VFIO_DEVICE_GET_IRQ_INFO:
> {
> @@ -201,6 +275,7 @@ static int vfio_fsl_mc_probe(struct fsl_mc_device *mc_dev)
> vfio_iommu_group_put(group, dev);
> return ret;
> }
> + mutex_init(>driver_lock);
>
> return ret;
> }
> diff --git a/drivers/vfio/fsl-mc/vfio_fsl_mc_private.h
> b/drivers/vfio/fsl-mc/vfio_fsl_mc_private.h
> index 37d61eaa58c8..818dfd3df4db 100644
> --- a/drivers/vfio/fsl-mc/vfio_fsl_mc_private.h
> +++ b/drivers/vfio/fsl-mc/vfio_fsl_mc_private.h
> @@ -7,9 +7,28 @@
> #ifndef VFIO_FSL_MC_PRIVATE_H
> #define VFIO_FSL_MC_PRIVATE_H
>
> +#define VFIO_FSL_MC_OFFSET_SHIFT40
> +#define VFIO_FSL_MC_OFFSET_MASK (((u64)(1) << VFIO_FSL_MC_OFFSET_SHIFT) - 1)
> +
> +#define VFIO_FSL_MC_OFFSET_TO_INDEX(off) ((off) >> VFIO_FSL_MC_OFFSET_SHIFT)
> +
> +#define VFIO_FSL_MC_INDEX_TO_OFFSET(index) \
> + ((u64)(index) << VFIO_FSL_MC_OFFSET_SHIFT)
> +
> +struct vfio_fsl_mc_region {
> + u32 flags;
> + u32 type;
> + u64 addr;
> + resource_size_t size;
> +};
> +
> struct vfio_fsl_mc_device {
> struct
Re: [PATCH v2 5/9] vfio/fsl-mc: Allow userspace to MMAP fsl-mc device MMIO regions
On Fri, 8 May 2020 10:20:35 +0300
Diana Craciun wrote:
> Allow userspace to mmap device regions for direct access of
> fsl-mc devices.
>
> Signed-off-by: Bharat Bhushan
> Signed-off-by: Diana Craciun
> ---
> drivers/vfio/fsl-mc/vfio_fsl_mc.c | 60 ++-
> drivers/vfio/fsl-mc/vfio_fsl_mc_private.h | 2 +
> 2 files changed, 60 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/vfio/fsl-mc/vfio_fsl_mc.c
> b/drivers/vfio/fsl-mc/vfio_fsl_mc.c
> index c162fa27c02c..a92c6c97c29a 100644
> --- a/drivers/vfio/fsl-mc/vfio_fsl_mc.c
> +++ b/drivers/vfio/fsl-mc/vfio_fsl_mc.c
> @@ -33,7 +33,11 @@ static int vfio_fsl_mc_regions_init(struct
> vfio_fsl_mc_device *vdev)
>
> vdev->regions[i].addr = res->start;
> vdev->regions[i].size = PAGE_ALIGN((resource_size(res)));
> - vdev->regions[i].flags = 0;
> + vdev->regions[i].flags = VFIO_REGION_INFO_FLAG_MMAP;
> + vdev->regions[i].flags |= VFIO_REGION_INFO_FLAG_READ;
> + if (!(mc_dev->regions[i].flags & IORESOURCE_READONLY))
> + vdev->regions[i].flags |= VFIO_REGION_INFO_FLAG_WRITE;
I'm a little confused that we advertise read and write here, but it's
only relative to the mmap and even later in the series where we add
read and write callback support, it's only for the dprc and dpmcp
devices. Doesn't this leave dpaa2 accelerator devices with only mmap
access? vfio doesn't really have a way to specify that a device only
has mmap access and the read/write interfaces can be quite useful when
debugging or tracing.
> + vdev->regions[i].type = mc_dev->regions[i].flags &
> IORESOURCE_BITS;
> }
>
> vdev->num_regions = mc_dev->obj_desc.region_count;
> @@ -164,9 +168,61 @@ static ssize_t vfio_fsl_mc_write(void *device_data,
> const char __user *buf,
> return -EINVAL;
> }
>
> +static int vfio_fsl_mc_mmap_mmio(struct vfio_fsl_mc_region region,
> + struct vm_area_struct *vma)
> +{
> + u64 size = vma->vm_end - vma->vm_start;
> + u64 pgoff, base;
> +
> + pgoff = vma->vm_pgoff &
> + ((1U << (VFIO_FSL_MC_OFFSET_SHIFT - PAGE_SHIFT)) - 1);
> + base = pgoff << PAGE_SHIFT;
> +
> + if (region.size < PAGE_SIZE || base + size > region.size)
We've already aligned region.size up to PAGE_SIZE, so that test can't
be true. Whether it was a good idea to do that alignment, I'm not so
sure.
> + return -EINVAL;
> +
> + if (!(region.type & VFIO_DPRC_REGION_CACHEABLE))
> + vma->vm_page_prot = pgprot_noncached(vma->vm_page_prot);
> +
> + vma->vm_pgoff = (region.addr >> PAGE_SHIFT) + pgoff;
> +
> + return remap_pfn_range(vma, vma->vm_start, vma->vm_pgoff,
> +size, vma->vm_page_prot);
> +}
> +
> static int vfio_fsl_mc_mmap(void *device_data, struct vm_area_struct *vma)
> {
> - return -EINVAL;
> + struct vfio_fsl_mc_device *vdev = device_data;
> + struct fsl_mc_device *mc_dev = vdev->mc_dev;
> + int index;
> +
> + index = vma->vm_pgoff >> (VFIO_FSL_MC_OFFSET_SHIFT - PAGE_SHIFT);
> +
> + if (vma->vm_end < vma->vm_start)
> + return -EINVAL;
> + if (vma->vm_start & ~PAGE_MASK)
> + return -EINVAL;
> + if (vma->vm_end & ~PAGE_MASK)
> + return -EINVAL;
> + if (!(vma->vm_flags & VM_SHARED))
> + return -EINVAL;
> + if (index >= vdev->num_regions)
> + return -EINVAL;
> +
> + if (!(vdev->regions[index].flags & VFIO_REGION_INFO_FLAG_MMAP))
> + return -EINVAL;
> +
> + if (!(vdev->regions[index].flags & VFIO_REGION_INFO_FLAG_READ)
> + && (vma->vm_flags & VM_READ))
> + return -EINVAL;
> +
> + if (!(vdev->regions[index].flags & VFIO_REGION_INFO_FLAG_WRITE)
> + && (vma->vm_flags & VM_WRITE))
> + return -EINVAL;
> +
> + vma->vm_private_data = mc_dev;
> +
> + return vfio_fsl_mc_mmap_mmio(vdev->regions[index], vma);
> }
>
> static const struct vfio_device_ops vfio_fsl_mc_ops = {
> diff --git a/drivers/vfio/fsl-mc/vfio_fsl_mc_private.h
> b/drivers/vfio/fsl-mc/vfio_fsl_mc_private.h
> index 818dfd3df4db..89d2e2a602d8 100644
> --- a/drivers/vfio/fsl-mc/vfio_fsl_mc_private.h
> +++ b/drivers/vfio/fsl-mc/vfio_fsl_mc_private.h
> @@ -15,6 +15,8 @@
> #define VFIO_FSL_MC_INDEX_TO_OFFSET(index) \
> ((u64)(index) << VFIO_FSL_MC_OFFSET_SHIFT)
>
> +#define VFIO_DPRC_REGION_CACHEABLE 0x0001
There appears to be some sort of magic mapping of this to bus specific
bits in the IORESOURCE_BITS range. If the bus specific bits get
shifted we'll be subtly broken here. Can't we use the bus #define so
that we can't get out of sync? Thanks,
Alex
> +
> struct vfio_fsl_mc_region {
> u32 flags;
> u32 type;
Re: [PATCH net-next] mlx5: Restore err assignment in mlx5_mdev_init
On Sun, May 31, 2020 at 12:58:10PM +0300, Leon Romanovsky wrote:
> On Fri, May 29, 2020 at 10:54:48PM -0700, Nathan Chancellor wrote:
> > Clang warns:
> >
> > drivers/net/ethernet/mellanox/mlx5/core/main.c:1278:6: warning: variable
> > 'err' is used uninitialized whenever 'if' condition is true
> > [-Wsometimes-uninitialized]
> > if (!priv->dbg_root) {
> > ^~~
> > drivers/net/ethernet/mellanox/mlx5/core/main.c:1303:9: note:
> > uninitialized use occurs here
> > return err;
> >^~~
> > drivers/net/ethernet/mellanox/mlx5/core/main.c:1278:2: note: remove the
> > 'if' if its condition is always false
> > if (!priv->dbg_root) {
> > ^~
> > drivers/net/ethernet/mellanox/mlx5/core/main.c:1259:9: note: initialize
> > the variable 'err' to silence this warning
> > int err;
> >^
> > = 0
> > 1 warning generated.
> >
> > This path previously returned -ENOMEM, restore that error code so that
> > it is not uninitialized.
> >
> > Fixes: 810cbb25549b ("net/mlx5: Add missing mutex destroy")
> > Link: https://github.com/ClangBuiltLinux/linux/issues/1042
> > Signed-off-by: Nathan Chancellor
> > ---
> > drivers/net/ethernet/mellanox/mlx5/core/main.c | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/drivers/net/ethernet/mellanox/mlx5/core/main.c
> > b/drivers/net/ethernet/mellanox/mlx5/core/main.c
> > index df46b1fce3a7..ac68445fde2d 100644
> > --- a/drivers/net/ethernet/mellanox/mlx5/core/main.c
> > +++ b/drivers/net/ethernet/mellanox/mlx5/core/main.c
> > @@ -1277,6 +1277,7 @@ static int mlx5_mdev_init(struct mlx5_core_dev *dev,
> > int profile_idx)
> > mlx5_debugfs_root);
> > if (!priv->dbg_root) {
> > dev_err(dev->device, "mlx5_core: error, Cannot create debugfs
> > dir, aborting\n");
> > + err = -ENOMEM;
> > goto err_dbg_root;
> ^^ this is wrong.
> Failure to create debugfs should never fail the driver.
Fair enough, could you guys deal with this then to make sure it gets
fixed properly? It appears to be introduced in 11f3b84d7068 ("net/mlx5:
Split mdev init and pci init").
> > }
> >
> >
> > base-commit: c0cc73b79123e67b212bd537a7af88e52c9fbeac
> > --
> > 2.27.0.rc0
> >
Re: [PATCH] mm/compaction: avoid VM_BUG_ON(PageSlab()) in page_mapcount()
On Sat, 23 May 2020, Hugh Dickins wrote:
> On Wed, 13 May 2020, Konstantin Khlebnikov wrote:
>
> > Function isolate_migratepages_block() runs some checks out of lru_lock
> > when choose pages for migration. After checking PageLRU() it checks extra
> > page references by comparing page_count() and page_mapcount(). Between
> > these two checks page could be removed from lru, freed and taken by slab.
> >
> > As a result this race triggers VM_BUG_ON(PageSlab()) in page_mapcount().
> > Race window is tiny. For certain workload this happens around once a year.
>
> Around once a year, that was my guess too. I have no record of us ever
> hitting this, but yes it could happen when you have CONFIG_DEBUG_VM=y
> (which I too like to run with, but would not recommend for users).
>
> >
> >
> > page:ea0105ca9380 count:1 mapcount:0 mapping:88ff7712c180
> > index:0x0 compound_mapcount: 0
> > flags: 0x5008100(slab|head)
> > raw: 05008100 dead0100 dead0200 88ff7712c180
> > raw: 80200020 0001
> > page dumped because: VM_BUG_ON_PAGE(PageSlab(page))
> > [ cut here ]
> > kernel BUG at ./include/linux/mm.h:628!
> > invalid opcode: [#1] SMP NOPTI
> > CPU: 77 PID: 504 Comm: kcompactd1 Tainted: GW 4.19.109-27
> > #1
> > Hardware name: Yandex T175-N41-Y3N/MY81-EX0-Y3N, BIOS R05 06/20/2019
> > RIP: 0010:isolate_migratepages_block+0x986/0x9b0
> >
> >
> > To fix just opencode page_mapcount() in racy check for 0-order case and
> > recheck carefully under lru_lock when page cannot escape from lru.
> >
> > Also add checking extra references for file pages and swap cache.
> >
> > Signed-off-by: Konstantin Khlebnikov
> > Fixes: 119d6d59dcc0 ("mm, compaction: avoid isolating pinned pages")
>
> Not really, that commit was correct at the time it went in.
>
> > Fixes: 1d148e218a0d ("mm: add VM_BUG_ON_PAGE() to page_mapcount()")
>
> Exactly, that commit was well-intentioned, but did not allow for this
> (admittedly very exceptional) usage. How many developers actually
> make the mistake of applying page_mapcount() to their slab pages?
> None, I expect. That VM_BUG_ON_PAGE() is there for documentation,
> and could just be replaced by a comment - and Linus would be happy
> with that.
>
> > ---
> > mm/compaction.c | 17 +
> > 1 file changed, 13 insertions(+), 4 deletions(-)
> >
> > diff --git a/mm/compaction.c b/mm/compaction.c
> > index 46f0fcc93081..91bb87fd9420 100644
> > --- a/mm/compaction.c
> > +++ b/mm/compaction.c
> > @@ -935,12 +935,16 @@ isolate_migratepages_block(struct compact_control
> > *cc, unsigned long low_pfn,
> > }
> >
> > /*
> > -* Migration will fail if an anonymous page is pinned in memory,
> > +* Migration will fail if an page is pinned in memory,
> > * so avoid taking lru_lock and isolating it unnecessarily in an
> > -* admittedly racy check.
> > +* admittedly racy check simplest case for 0-order pages.
> > +*
> > +* Open code page_mapcount() to avoid VM_BUG_ON(PageSlab(page)).
>
> But open coding page_mapcount() is not all that you did. You have
> (understandably) chosen to avoid calling page_mapping(page), but...
>
> > +* Page could have extra reference from mapping or swap cache.
> > */
> > - if (!page_mapping(page) &&
> > - page_count(page) > page_mapcount(page))
> > + if (!PageCompound(page) &&
> > + page_count(page) > atomic_read(>_mapcount) + 1 +
> > + (!PageAnon(page) || PageSwapCache(page)))
> > goto isolate_fail;
>
> Isn't that test going to send all the file cache pages with buffer heads
> in page->private, off to isolate_fail when they're actually great
> candidates for migration?
>
> Given that the actual bug spotted was with the VM_BUG_ON_PAGE(PageSlab),
> and nobody has reported any crash from the use of page_mapping() there
> (and we only need the test to be right most of the time: all of this
> knowingly racy, as you explain in other mail): I'd go for just replacing
> the VM_BUG_ON_PAGE in page_mapcount() by a comment about this case.
>
> But if you think developers are really in danger of coding page_mapcount()
> on their slab pages, then you could add a _page_mapcount() to linux/mm.h,
> which omits the VM_BUG_ON_PAGE, for use here only.
>
> Then we wouldn't have to think so hard about the counting above!
>
> >
> > /*
> > @@ -975,6 +979,11 @@ isolate_migratepages_block(struct compact_control *cc,
> > unsigned long low_pfn,
> > low_pfn += compound_nr(page) - 1;
> > goto isolate_fail;
> > }
> > +
> > + /* Recheck page extra references under lock */
> > + if
[PATCH 7/7] powerpc/watchpoint: Remove 512 byte boundary
Power10 has removed 512 bytes boundary from match criteria. i.e. The match
range can be 512 bytes unaligned as well.
Signed-off-by: Ravi Bangoria
---
arch/powerpc/kernel/hw_breakpoint.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/kernel/hw_breakpoint.c
b/arch/powerpc/kernel/hw_breakpoint.c
index daf0e1da..270e655108f4 100644
--- a/arch/powerpc/kernel/hw_breakpoint.c
+++ b/arch/powerpc/kernel/hw_breakpoint.c
@@ -418,8 +418,9 @@ static int hw_breakpoint_validate_len(struct
arch_hw_breakpoint *hw)
if (dawr_enabled()) {
max_len = DAWR_MAX_LEN;
- /* DAWR region can't cross 512 bytes boundary */
- if (ALIGN(start_addr, SZ_512M) != ALIGN(end_addr - 1, SZ_512M))
+ /* DAWR region can't cross 512 bytes boundary on p8 and p9 */
+ if (!cpu_has_feature(CPU_FTR_ARCH_31) &&
+ (ALIGN(start_addr, SZ_512M) != ALIGN(end_addr - 1,
SZ_512M)))
return -EINVAL;
} else if (IS_ENABLED(CONFIG_PPC_8xx)) {
/* 8xx can setup a range without limitation */
--
2.26.2
Re: [PATCH v4 3/4] mm/util.c: remove the VM_WARN_ONCE for vm_committed_as underflow check
> On Jun 1, 2020, at 11:37 PM, Feng Tang wrote: > > I re-run the same benchmark with v5.7 and 5.7+remove_warning kernels, > the overall performance change is trivial (which is expected) > > 1330147+0.1%1331032will-it-scale.72.processes > > But the perf stats of "self" shows big change for __vm_enough_memory() > > 0.27-0.30.00pp.self.__vm_enough_memory > > I post the full compare result in the end. I don’t really see what that means exactly, but I suppose the warning is there for so long and no one seems notice much trouble (or benefit) because of it, so I think you will probably need to come up with a proper justification to explain why it is a trouble now, and how your patchset suddenly start to trigger the warning as well as why it is no better way but to suffer this debuggability regression (probably tiny but still).
[PATCH 6/7] powerpc/watchpoint: Return available watchpoints dynamically
So far Book3S Powerpc supported only one watchpoint. But Power10 is
introducing 2nd DAWR. Enable 2nd DAWR support for Power10. Availability
of 2nd DAWR will depend on CPU_FTR_DAWR1.
Signed-off-by: Ravi Bangoria
---
arch/powerpc/include/asm/cputable.h | 4 +++-
arch/powerpc/include/asm/hw_breakpoint.h | 5 +++--
2 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/include/asm/cputable.h
b/arch/powerpc/include/asm/cputable.h
index 3445c86e1f6f..f110f70a11bf 100644
--- a/arch/powerpc/include/asm/cputable.h
+++ b/arch/powerpc/include/asm/cputable.h
@@ -633,7 +633,9 @@ enum {
* Maximum number of hw breakpoint supported on powerpc. Number of
* breakpoints supported by actual hw might be less than this.
*/
-#define HBP_NUM_MAX1
+#define HBP_NUM_MAX2
+#define HBP_NUM_P7_TO_P9 1
+#define HBP_NUM_P102
#endif /* !__ASSEMBLY__ */
diff --git a/arch/powerpc/include/asm/hw_breakpoint.h
b/arch/powerpc/include/asm/hw_breakpoint.h
index f42a55eb77d2..0365a137d6e8 100644
--- a/arch/powerpc/include/asm/hw_breakpoint.h
+++ b/arch/powerpc/include/asm/hw_breakpoint.h
@@ -5,10 +5,11 @@
* Copyright 2010, IBM Corporation.
* Author: K.Prasad
*/
-
#ifndef _PPC_BOOK3S_64_HW_BREAKPOINT_H
#define _PPC_BOOK3S_64_HW_BREAKPOINT_H
+#include
+
#ifdef __KERNEL__
struct arch_hw_breakpoint {
unsigned long address;
@@ -46,7 +47,7 @@ struct arch_hw_breakpoint {
static inline int nr_wp_slots(void)
{
- return HBP_NUM_MAX;
+ return cpu_has_feature(CPU_FTR_DAWR1) ? HBP_NUM_P10 : HBP_NUM_P7_TO_P9;
}
#ifdef CONFIG_HAVE_HW_BREAKPOINT
--
2.26.2
[PATCH 5/7] powerpc/watchpoint: Guest support for 2nd DAWR hcall
2nd DAWR can be set/unset using H_SET_MODE hcall with resource value 5.
Enable powervm guest support with that. This has no effect on kvm guest
because kvm will return error if guest does hcall with resource value 5.
Signed-off-by: Ravi Bangoria
---
arch/powerpc/include/asm/hvcall.h | 1 +
arch/powerpc/include/asm/machdep.h| 2 +-
arch/powerpc/include/asm/plpar_wrappers.h | 5 +
arch/powerpc/kernel/dawr.c| 2 +-
arch/powerpc/platforms/pseries/setup.c| 7 +--
5 files changed, 13 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/include/asm/hvcall.h
b/arch/powerpc/include/asm/hvcall.h
index a7f6f1aeda6b..3f170b9496a1 100644
--- a/arch/powerpc/include/asm/hvcall.h
+++ b/arch/powerpc/include/asm/hvcall.h
@@ -357,6 +357,7 @@
#define H_SET_MODE_RESOURCE_SET_DAWR0 2
#define H_SET_MODE_RESOURCE_ADDR_TRANS_MODE3
#define H_SET_MODE_RESOURCE_LE 4
+#define H_SET_MODE_RESOURCE_SET_DAWR1 5
/* Values for argument to H_SIGNAL_SYS_RESET */
#define H_SIGNAL_SYS_RESET_ALL -1
diff --git a/arch/powerpc/include/asm/machdep.h
b/arch/powerpc/include/asm/machdep.h
index 7bcb6a39..a90b892f0bfe 100644
--- a/arch/powerpc/include/asm/machdep.h
+++ b/arch/powerpc/include/asm/machdep.h
@@ -131,7 +131,7 @@ struct machdep_calls {
unsigned long dabrx);
/* Set DAWR for this platform, leave empty for default implementation */
- int (*set_dawr)(unsigned long dawr,
+ int (*set_dawr)(int nr, unsigned long dawr,
unsigned long dawrx);
#ifdef CONFIG_PPC32/* XXX for now */
diff --git a/arch/powerpc/include/asm/plpar_wrappers.h
b/arch/powerpc/include/asm/plpar_wrappers.h
index 93eb133d572c..d7a1acc83593 100644
--- a/arch/powerpc/include/asm/plpar_wrappers.h
+++ b/arch/powerpc/include/asm/plpar_wrappers.h
@@ -315,6 +315,11 @@ static inline long plpar_set_watchpoint0(unsigned long
dawr0, unsigned long dawr
return plpar_set_mode(0, H_SET_MODE_RESOURCE_SET_DAWR0, dawr0, dawrx0);
}
+static inline long plpar_set_watchpoint1(unsigned long dawr1, unsigned long
dawrx1)
+{
+ return plpar_set_mode(0, H_SET_MODE_RESOURCE_SET_DAWR1, dawr1, dawrx1);
+}
+
static inline long plpar_signal_sys_reset(long cpu)
{
return plpar_hcall_norets(H_SIGNAL_SYS_RESET, cpu);
diff --git a/arch/powerpc/kernel/dawr.c b/arch/powerpc/kernel/dawr.c
index 500f52fa4711..cdc2dccb987d 100644
--- a/arch/powerpc/kernel/dawr.c
+++ b/arch/powerpc/kernel/dawr.c
@@ -37,7 +37,7 @@ int set_dawr(int nr, struct arch_hw_breakpoint *brk)
dawrx |= (mrd & 0x3f) << (63 - 53);
if (ppc_md.set_dawr)
- return ppc_md.set_dawr(dawr, dawrx);
+ return ppc_md.set_dawr(nr, dawr, dawrx);
if (nr == 0) {
mtspr(SPRN_DAWR0, dawr);
diff --git a/arch/powerpc/platforms/pseries/setup.c
b/arch/powerpc/platforms/pseries/setup.c
index 64d18f4bf093..b001cde1a2d7 100644
--- a/arch/powerpc/platforms/pseries/setup.c
+++ b/arch/powerpc/platforms/pseries/setup.c
@@ -832,12 +832,15 @@ static int pseries_set_xdabr(unsigned long dabr, unsigned
long dabrx)
return plpar_hcall_norets(H_SET_XDABR, dabr, dabrx);
}
-static int pseries_set_dawr(unsigned long dawr, unsigned long dawrx)
+static int pseries_set_dawr(int nr, unsigned long dawr, unsigned long dawrx)
{
/* PAPR says we can't set HYP */
dawrx &= ~DAWRX_HYP;
- return plpar_set_watchpoint0(dawr, dawrx);
+ if (nr == 0)
+ return plpar_set_watchpoint0(dawr, dawrx);
+ else
+ return plpar_set_watchpoint1(dawr, dawrx);
}
#define CMO_CHARACTERISTICS_TOKEN 44
--
2.26.2
[PATCH 4/7] powerpc/watchpoint: Rename current H_SET_MODE DAWR macro
Current H_SET_MODE hcall macro name for setting/resetting DAWR0 is
H_SET_MODE_RESOURCE_SET_DAWR. Add suffix 0 to macro name as well.
Signed-off-by: Ravi Bangoria
---
arch/powerpc/include/asm/hvcall.h | 2 +-
arch/powerpc/include/asm/plpar_wrappers.h | 2 +-
arch/powerpc/kvm/book3s_hv.c | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/include/asm/hvcall.h
b/arch/powerpc/include/asm/hvcall.h
index e90c073e437e..a7f6f1aeda6b 100644
--- a/arch/powerpc/include/asm/hvcall.h
+++ b/arch/powerpc/include/asm/hvcall.h
@@ -354,7 +354,7 @@
/* Values for 2nd argument to H_SET_MODE */
#define H_SET_MODE_RESOURCE_SET_CIABR 1
-#define H_SET_MODE_RESOURCE_SET_DAWR 2
+#define H_SET_MODE_RESOURCE_SET_DAWR0 2
#define H_SET_MODE_RESOURCE_ADDR_TRANS_MODE3
#define H_SET_MODE_RESOURCE_LE 4
diff --git a/arch/powerpc/include/asm/plpar_wrappers.h
b/arch/powerpc/include/asm/plpar_wrappers.h
index 4497c8afb573..93eb133d572c 100644
--- a/arch/powerpc/include/asm/plpar_wrappers.h
+++ b/arch/powerpc/include/asm/plpar_wrappers.h
@@ -312,7 +312,7 @@ static inline long plpar_set_ciabr(unsigned long ciabr)
static inline long plpar_set_watchpoint0(unsigned long dawr0, unsigned long
dawrx0)
{
- return plpar_set_mode(0, H_SET_MODE_RESOURCE_SET_DAWR, dawr0, dawrx0);
+ return plpar_set_mode(0, H_SET_MODE_RESOURCE_SET_DAWR0, dawr0, dawrx0);
}
static inline long plpar_signal_sys_reset(long cpu)
diff --git a/arch/powerpc/kvm/book3s_hv.c b/arch/powerpc/kvm/book3s_hv.c
index a0cf17597838..26820b7bd75c 100644
--- a/arch/powerpc/kvm/book3s_hv.c
+++ b/arch/powerpc/kvm/book3s_hv.c
@@ -766,7 +766,7 @@ static int kvmppc_h_set_mode(struct kvm_vcpu *vcpu,
unsigned long mflags,
return H_P3;
vcpu->arch.ciabr = value1;
return H_SUCCESS;
- case H_SET_MODE_RESOURCE_SET_DAWR:
+ case H_SET_MODE_RESOURCE_SET_DAWR0:
if (!kvmppc_power8_compatible(vcpu))
return H_P2;
if (!ppc_breakpoint_available())
--
2.26.2
[PATCH 2/7] powerpc/dt_cpu_ftrs: Add feature for 2nd DAWR
Add new device-tree feature for 2nd DAWR. If this feature is present,
2nd DAWR is supported, otherwise not.
Signed-off-by: Ravi Bangoria
---
arch/powerpc/include/asm/cputable.h | 7 +--
arch/powerpc/kernel/dt_cpu_ftrs.c | 7 +++
2 files changed, 12 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/include/asm/cputable.h
b/arch/powerpc/include/asm/cputable.h
index e506d429b1af..3445c86e1f6f 100644
--- a/arch/powerpc/include/asm/cputable.h
+++ b/arch/powerpc/include/asm/cputable.h
@@ -214,6 +214,7 @@ static inline void cpu_feature_keys_init(void) { }
#define CPU_FTR_P9_TLBIE_ERAT_BUG LONG_ASM_CONST(0x0001)
#define CPU_FTR_P9_RADIX_PREFETCH_BUG LONG_ASM_CONST(0x0002)
#define CPU_FTR_ARCH_31
LONG_ASM_CONST(0x0004)
+#define CPU_FTR_DAWR1 LONG_ASM_CONST(0x0008)
#ifndef __ASSEMBLY__
@@ -497,14 +498,16 @@ static inline void cpu_feature_keys_init(void) { }
#define CPU_FTRS_POSSIBLE \
(CPU_FTRS_POWER7 | CPU_FTRS_POWER8E | CPU_FTRS_POWER8 | \
CPU_FTR_ALTIVEC_COMP | CPU_FTR_VSX_COMP | CPU_FTRS_POWER9 | \
-CPU_FTRS_POWER9_DD2_1 | CPU_FTRS_POWER9_DD2_2 | CPU_FTRS_POWER10)
+CPU_FTRS_POWER9_DD2_1 | CPU_FTRS_POWER9_DD2_2 | CPU_FTRS_POWER10 |
\
+CPU_FTR_DAWR1)
#else
#define CPU_FTRS_POSSIBLE \
(CPU_FTRS_PPC970 | CPU_FTRS_POWER5 | \
CPU_FTRS_POWER6 | CPU_FTRS_POWER7 | CPU_FTRS_POWER8E | \
CPU_FTRS_POWER8 | CPU_FTRS_CELL | CPU_FTRS_PA6T | \
CPU_FTR_VSX_COMP | CPU_FTR_ALTIVEC_COMP | CPU_FTRS_POWER9 | \
-CPU_FTRS_POWER9_DD2_1 | CPU_FTRS_POWER9_DD2_2 | CPU_FTRS_POWER10)
+CPU_FTRS_POWER9_DD2_1 | CPU_FTRS_POWER9_DD2_2 | CPU_FTRS_POWER10 |
\
+CPU_FTR_DAWR1)
#endif /* CONFIG_CPU_LITTLE_ENDIAN */
#endif
#else
diff --git a/arch/powerpc/kernel/dt_cpu_ftrs.c
b/arch/powerpc/kernel/dt_cpu_ftrs.c
index 0a41fce34165..c1c63c6724ea 100644
--- a/arch/powerpc/kernel/dt_cpu_ftrs.c
+++ b/arch/powerpc/kernel/dt_cpu_ftrs.c
@@ -568,6 +568,12 @@ static int __init feat_enable_mma(struct dt_cpu_feature *f)
return 1;
}
+static int __init feat_enable_dawr1(struct dt_cpu_feature *f)
+{
+ cur_cpu_spec->cpu_features |= CPU_FTR_DAWR1;
+ return 1;
+}
+
struct dt_cpu_feature_match {
const char *name;
int (*enable)(struct dt_cpu_feature *f);
@@ -643,6 +649,7 @@ static struct dt_cpu_feature_match __initdata
{"wait-v3", feat_enable, 0},
{"prefix-instructions", feat_enable, 0},
{"matrix-multiply-assist", feat_enable_mma, 0},
+ {"dawr1", feat_enable_dawr1, 0},
};
static bool __initdata using_dt_cpu_ftrs;
--
2.26.2
[PATCH 3/7] powerpc/watchpoint: Set CPU_FTR_DAWR1 based on pa-features bit
bit 0 of byte 64 in pa-features property indicates availability of 2nd
DAWR registers. i.e. If this bit is set, 2nd DAWR is present, otherwise
not. Host generally uses "cpu-features", which masks "pa-features". But
"cpu-features" are still not used for guests and thus this change is
mostly applicable for guests only.
Signed-off-by: Ravi Bangoria
---
arch/powerpc/kernel/prom.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/powerpc/kernel/prom.c b/arch/powerpc/kernel/prom.c
index 1dcf0e214a22..6de59de579f7 100644
--- a/arch/powerpc/kernel/prom.c
+++ b/arch/powerpc/kernel/prom.c
@@ -175,6 +175,8 @@ static struct ibm_pa_feature {
*/
{ .pabyte = 22, .pabit = 0, .cpu_features = CPU_FTR_TM_COMP,
.cpu_user_ftrs2 = PPC_FEATURE2_HTM_COMP | PPC_FEATURE2_HTM_NOSC_COMP
},
+
+ { .pabyte = 64, .pabit = 0, .cpu_features = CPU_FTR_DAWR1 },
};
static void __init scan_features(unsigned long node, const unsigned char *ftrs,
--
2.26.2
[PATCH 0/7] powerpc/watchpoint: Enable 2nd DAWR on baremetal and powervm
Last series[1] was to add basic infrastructure support for more than one watchpoint on Book3S powerpc. This series actually enables the 2nd DAWR for baremetal and powervm. Kvm guest is still not supported. This series depends on Alistair's "Base support for POWER10"[2] series. [1]: https://lore.kernel.org/linuxppc-dev/20200514111741.97993-1-ravi.bango...@linux.ibm.com/ [2]: https://lore.kernel.org/linuxppc-dev/20200521014341.29095-1-alist...@popple.id.au Ravi Bangoria (7): powerpc/watchpoint: Enable watchpoint functionality on power10 guest powerpc/dt_cpu_ftrs: Add feature for 2nd DAWR powerpc/watchpoint: Set CPU_FTR_DAWR1 based on pa-features bit powerpc/watchpoint: Rename current H_SET_MODE DAWR macro powerpc/watchpoint: Guest support for 2nd DAWR hcall powerpc/watchpoint: Return available watchpoints dynamically powerpc/watchpoint: Remove 512 byte boundary arch/powerpc/include/asm/cputable.h | 13 + arch/powerpc/include/asm/hvcall.h | 3 ++- arch/powerpc/include/asm/hw_breakpoint.h | 5 +++-- arch/powerpc/include/asm/machdep.h| 2 +- arch/powerpc/include/asm/plpar_wrappers.h | 7 ++- arch/powerpc/kernel/dawr.c| 2 +- arch/powerpc/kernel/dt_cpu_ftrs.c | 7 +++ arch/powerpc/kernel/hw_breakpoint.c | 5 +++-- arch/powerpc/kernel/prom.c| 2 ++ arch/powerpc/kvm/book3s_hv.c | 2 +- arch/powerpc/platforms/pseries/setup.c| 7 +-- 11 files changed, 40 insertions(+), 15 deletions(-) -- 2.26.2
[PATCH 1/7] powerpc/watchpoint: Enable watchpoint functionality on power10 guest
CPU_FTR_DAWR is by default enabled for host via CPU_FTRS_DT_CPU_BASE
(controlled by CONFIG_PPC_DT_CPU_FTRS). But cpu-features device-tree
node is not PAPR compatible and thus not yet used by kvm or pHyp
guests. Enable watchpoint functionality on power10 guest (both kvm
and powervm) by adding CPU_FTR_DAWR to CPU_FTRS_POWER10. Note that
this change does not enable 2nd DAWR support yet.
Signed-off-by: Ravi Bangoria
---
arch/powerpc/include/asm/cputable.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/include/asm/cputable.h
b/arch/powerpc/include/asm/cputable.h
index bac2252c839e..e506d429b1af 100644
--- a/arch/powerpc/include/asm/cputable.h
+++ b/arch/powerpc/include/asm/cputable.h
@@ -478,7 +478,7 @@ static inline void cpu_feature_keys_init(void) { }
CPU_FTR_CFAR | CPU_FTR_HVMODE | CPU_FTR_VMX_COPY | \
CPU_FTR_DBELL | CPU_FTR_HAS_PPR | CPU_FTR_ARCH_207S | \
CPU_FTR_TM_COMP | CPU_FTR_ARCH_300 | CPU_FTR_PKEY | \
- CPU_FTR_ARCH_31)
+ CPU_FTR_ARCH_31 | CPU_FTR_DAWR)
#define CPU_FTRS_CELL (CPU_FTR_LWSYNC | \
CPU_FTR_PPCAS_ARCH_V2 | CPU_FTR_CTRL | \
CPU_FTR_ALTIVEC_COMP | CPU_FTR_MMCRA | CPU_FTR_SMT | \
--
2.26.2
[PATCH] Revert "drm/msm/dpu: add support for clk and bw scaling for display"
From: Rob Clark
This is causing multiple armv7 missing do_div() errors, so lets drop it
for now.
This reverts commit 04d9044f6c577948609c03b4e33b8fbc8b87c4b1.
Cc: Kalyan Thota
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c | 106 +++---
.../gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c| 5 +-
.../gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h| 4 -
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 37 +-
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h | 4 -
drivers/gpu/drm/msm/disp/dpu1/dpu_mdss.c | 9 +-
drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 82 --
drivers/gpu/drm/msm/disp/dpu1/dpu_plane.h | 4 -
8 files changed, 23 insertions(+), 228 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c
index 9697abcbec3f..7c230f719ad3 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c
@@ -29,73 +29,6 @@ enum dpu_perf_mode {
DPU_PERF_MODE_MAX
};
-/**
- * @_dpu_core_perf_calc_bw() - to calculate BW per crtc
- * @kms - pointer to the dpu_kms
- * @crtc - pointer to a crtc
- * Return: returns aggregated BW for all planes in crtc.
- */
-static u64 _dpu_core_perf_calc_bw(struct dpu_kms *kms,
- struct drm_crtc *crtc)
-{
- struct drm_plane *plane;
- struct dpu_plane_state *pstate;
- u64 crtc_plane_bw = 0;
- u32 bw_factor;
-
- drm_atomic_crtc_for_each_plane(plane, crtc) {
- pstate = to_dpu_plane_state(plane->state);
-
- if (!pstate)
- continue;
-
- crtc_plane_bw += pstate->plane_fetch_bw;
- }
-
- bw_factor = kms->catalog->perf.bw_inefficiency_factor;
- if (bw_factor)
- crtc_plane_bw = mult_frac(crtc_plane_bw, bw_factor, 100);
-
- return crtc_plane_bw;
-}
-
-/**
- * _dpu_core_perf_calc_clk() - to calculate clock per crtc
- * @kms - pointer to the dpu_kms
- * @crtc - pointer to a crtc
- * @state - pointer to a crtc state
- * Return: returns max clk for all planes in crtc.
- */
-static u64 _dpu_core_perf_calc_clk(struct dpu_kms *kms,
- struct drm_crtc *crtc, struct drm_crtc_state *state)
-{
- struct drm_plane *plane;
- struct dpu_plane_state *pstate;
- struct drm_display_mode *mode;
- u64 crtc_clk;
- u32 clk_factor;
-
- mode = >adjusted_mode;
-
- crtc_clk = mode->vtotal * mode->hdisplay * drm_mode_vrefresh(mode);
-
- drm_atomic_crtc_for_each_plane(plane, crtc) {
- pstate = to_dpu_plane_state(plane->state);
-
- if (!pstate)
- continue;
-
- crtc_clk = max(pstate->plane_clk, crtc_clk);
- }
-
- clk_factor = kms->catalog->perf.clk_inefficiency_factor;
- if (clk_factor)
- crtc_clk = mult_frac(crtc_clk, clk_factor, 100);
-
- return crtc_clk;
-}
-
-
static struct dpu_kms *_dpu_crtc_get_kms(struct drm_crtc *crtc)
{
struct msm_drm_private *priv;
@@ -118,7 +51,12 @@ static void _dpu_core_perf_calc_crtc(struct dpu_kms *kms,
dpu_cstate = to_dpu_crtc_state(state);
memset(perf, 0, sizeof(struct dpu_core_perf_params));
- if (kms->perf.perf_tune.mode == DPU_PERF_MODE_MINIMUM) {
+ if (!dpu_cstate->bw_control) {
+ perf->bw_ctl = kms->catalog->perf.max_bw_high *
+ 1000ULL;
+ perf->max_per_pipe_ib = perf->bw_ctl;
+ perf->core_clk_rate = kms->perf.max_core_clk_rate;
+ } else if (kms->perf.perf_tune.mode == DPU_PERF_MODE_MINIMUM) {
perf->bw_ctl = 0;
perf->max_per_pipe_ib = 0;
perf->core_clk_rate = 0;
@@ -126,10 +64,6 @@ static void _dpu_core_perf_calc_crtc(struct dpu_kms *kms,
perf->bw_ctl = kms->perf.fix_core_ab_vote;
perf->max_per_pipe_ib = kms->perf.fix_core_ib_vote;
perf->core_clk_rate = kms->perf.fix_core_clk_rate;
- } else {
- perf->bw_ctl = _dpu_core_perf_calc_bw(kms, crtc);
- perf->max_per_pipe_ib = kms->catalog->perf.min_dram_ib;
- perf->core_clk_rate = _dpu_core_perf_calc_clk(kms, crtc, state);
}
DPU_DEBUG(
@@ -181,7 +115,11 @@ int dpu_core_perf_crtc_check(struct drm_crtc *crtc,
DPU_DEBUG("crtc:%d bw:%llu ctrl:%d\n",
tmp_crtc->base.id, tmp_cstate->new_perf.bw_ctl,
tmp_cstate->bw_control);
-
+ /*
+* For bw check only use the bw if the
+* atomic property has been already set
+*/
+ if (tmp_cstate->bw_control)
bw_sum_of_intfs += tmp_cstate->new_perf.bw_ctl;
}
@@ -193,7 +131,9 @@ int
[PATCH v10] mfd: mt6360: add pmic mt6360 driver
From: Gene Chen Add MFD driver for mt6360 pmic chip include Battery Charger/ USB_PD/Flash, LED/RGB and LED/LDO/Buck Signed-off-by: Gene Chen Signed-off-by: Lee Jones --- drivers/mfd/Kconfig| 12 ++ drivers/mfd/Makefile | 1 + drivers/mfd/mt6360-core.c | 424 + include/linux/mfd/mt6360.h | 240 + 4 files changed, 677 insertions(+) create mode 100644 drivers/mfd/mt6360-core.c create mode 100644 include/linux/mfd/mt6360.h changelogs between v1 & v2 - include missing header file changelogs between v2 & v3 - add changelogs changelogs between v3 & v4 - fix Kconfig description - replace mt6360_pmu_info with mt6360_pmu_data - replace probe with probe_new - remove unnecessary irq_chip variable - remove annotation - replace MT6360_MFD_CELL with OF_MFD_CELL changelogs between v4 & v5 - remove unnecessary parse dt function - use devm_i2c_new_dummy_device - add base-commit message changelogs between v5 & v6 - review return value - remove i2c id_table - use GPL license v2 changelogs between v6 & v7 - add author description - replace MT6360_REGMAP_IRQ_REG by REGMAP_IRQ_REG_LINE - remove mt6360-private.h changelogs between v7 & v8 - fix kbuild auto reboot by include interrupt header changelogs between v8 & v9 - fix GPL license out of date - add commit message about Acked-for-MFD-by changelogs between v9 & v10 - fix duplicate define of kbuild test reboot initializer-overrides - sync commit message format diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig index 0a59249..3f8a0a0 100644 --- a/drivers/mfd/Kconfig +++ b/drivers/mfd/Kconfig @@ -870,6 +870,18 @@ config MFD_MAX8998 additional drivers must be enabled in order to use the functionality of the device. +config MFD_MT6360 + tristate "Mediatek MT6360 SubPMIC" + select MFD_CORE + select REGMAP_I2C + select REGMAP_IRQ + depends on I2C + help + Say Y here to enable MT6360 PMU/PMIC/LDO functional support. + PMU part includes Charger, Flashlight, RGB LED + PMIC part includes 2-channel BUCKs and 2-channel LDOs + LDO part includes 4-channel LDOs + config MFD_MT6397 tristate "MediaTek MT6397 PMIC Support" select MFD_CORE diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile index f935d10..01fa149 100644 --- a/drivers/mfd/Makefile +++ b/drivers/mfd/Makefile @@ -239,6 +239,7 @@ obj-$(CONFIG_INTEL_SOC_PMIC)+= intel-soc-pmic.o obj-$(CONFIG_INTEL_SOC_PMIC_BXTWC) += intel_soc_pmic_bxtwc.o obj-$(CONFIG_INTEL_SOC_PMIC_CHTWC) += intel_soc_pmic_chtwc.o obj-$(CONFIG_INTEL_SOC_PMIC_CHTDC_TI) += intel_soc_pmic_chtdc_ti.o +obj-$(CONFIG_MFD_MT6360) += mt6360-core.o mt6397-objs:= mt6397-core.o mt6397-irq.o obj-$(CONFIG_MFD_MT6397) += mt6397.o obj-$(CONFIG_INTEL_SOC_PMIC_MRFLD) += intel_soc_pmic_mrfld.o diff --git a/drivers/mfd/mt6360-core.c b/drivers/mfd/mt6360-core.c new file mode 100644 index 000..db8cdf5 --- /dev/null +++ b/drivers/mfd/mt6360-core.c @@ -0,0 +1,424 @@ +// SPDX-License-Identifier: GPL-2.0 +/* + * Copyright (c) 2020 MediaTek Inc. + * + * Author: Gene Chen + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include + +/* reg 0 -> 0 ~ 7 */ +#define MT6360_CHG_TREG_EVT(4) +#define MT6360_CHG_AICR_EVT(5) +#define MT6360_CHG_MIVR_EVT(6) +#define MT6360_PWR_RDY_EVT (7) +/* REG 1 -> 8 ~ 15 */ +#define MT6360_CHG_BATSYSUV_EVT(9) +#define MT6360_FLED_CHG_VINOVP_EVT (11) +#define MT6360_CHG_VSYSUV_EVT (12) +#define MT6360_CHG_VSYSOV_EVT (13) +#define MT6360_CHG_VBATOV_EVT (14) +#define MT6360_CHG_VBUSOV_EVT (15) +/* REG 2 -> 16 ~ 23 */ +/* REG 3 -> 24 ~ 31 */ +#define MT6360_WD_PMU_DET (25) +#define MT6360_WD_PMU_DONE (26) +#define MT6360_CHG_TMRI(27) +#define MT6360_CHG_ADPBADI (29) +#define MT6360_CHG_RVPI(30) +#define MT6360_OTPI(31) +/* REG 4 -> 32 ~ 39 */ +#define MT6360_CHG_AICCMEASL (32) +#define MT6360_CHGDET_DONEI(34) +#define MT6360_WDTMRI (35) +#define MT6360_SSFINISHI (36) +#define MT6360_CHG_RECHGI (37) +#define MT6360_CHG_TERMI (38) +#define MT6360_CHG_IEOCI (39) +/* REG 5 -> 40 ~ 47 */ +#define MT6360_PUMPX_DONEI (40) +#define MT6360_BAT_OVP_ADC_EVT (41) +#define MT6360_TYPEC_OTP_EVT (42) +#define MT6360_ADC_WAKEUP_EVT (43) +#define MT6360_ADC_DONEI (44) +#define MT6360_BST_BATUVI (45) +#define MT6360_BST_VBUSOVI (46) +#define MT6360_BST_OLPI(47) +/* REG 6 -> 48 ~ 55 */ +#define MT6360_ATTACH_I(48) +#define MT6360_DETACH_I
Re: [PATCH v2 2/2] crypto: virtio: Fix use-after-free in virtio_crypto_skcipher_finalize_req()
On 2020/5/31 17:21, Michael S. Tsirkin wrote:
> On Tue, May 26, 2020 at 02:11:37PM +, Sasha Levin wrote:
>> <20200123101000.GB24255@Red>
>> References: <20200526031956.1897-3-longpe...@huawei.com>
>> <20200123101000.GB24255@Red>
>>
>> Hi
>>
>> [This is an automated email]
>>
>> This commit has been processed because it contains a "Fixes:" tag
>> fixing commit: dbaf0624ffa5 ("crypto: add virtio-crypto driver").
>>
>> The bot has tested the following trees: v5.6.14, v5.4.42, v4.19.124,
>> v4.14.181.
>>
>> v5.6.14: Build OK!
>> v5.4.42: Failed to apply! Possible dependencies:
>> eee1d6fca0a0 ("crypto: virtio - switch to skcipher API")
>>
>> v4.19.124: Failed to apply! Possible dependencies:
>> eee1d6fca0a0 ("crypto: virtio - switch to skcipher API")
>>
>> v4.14.181: Failed to apply! Possible dependencies:
>> 500e6807ce93 ("crypto: virtio - implement missing support for output
>> IVs")
>> 67189375bb3a ("crypto: virtio - convert to new crypto engine API")
>> d0d859bb87ac ("crypto: virtio - Register an algo only if it's supported")
>> e02b8b43f55a ("crypto: virtio - pr_err() strings should end with
>> newlines")
>> eee1d6fca0a0 ("crypto: virtio - switch to skcipher API")
>>
>>
>> NOTE: The patch will not be queued to stable trees until it is upstream.
>>
>> How should we proceed with this patch?
>
> Mike could you comment on backporting?
>
Hi Michael,
I will send V3, so I will resolve these conflicts later. :)
>> --
>> Thanks
>> Sasha
>
> .
>
---
Regards,
Longpeng(Mike)
drivers/staging/netlogic/xlr_net.c:832:20: error: assignment to expression with array type
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: 3d77e6a8804abcc0504c904bd6e5cdf3a5cf8162
commit: 3c1bcc8614db10803f1f57ef0295363917448cb2 net: ethernet: Convert phydev
advertize and supported from u32 to link mode
config: mips-randconfig-r016-20200601 (attached as .config)
compiler: mips-linux-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout 3c1bcc8614db10803f1f57ef0295363917448cb2
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross
ARCH=mips
If you fix the issue, kindly add following tag as appropriate
Reported-by: kbuild test robot
All errors (new ones prefixed by >>, old ones prefixed by <<):
drivers/staging/netlogic/xlr_net.c: In function 'xlr_gmac_link_adjust':
drivers/staging/netlogic/xlr_net.c:801:6: warning: variable 'intreg' set but
not used [-Wunused-but-set-variable]
801 | u32 intreg;
| ^~
drivers/staging/netlogic/xlr_net.c: In function 'xlr_mii_probe':
>> drivers/staging/netlogic/xlr_net.c:832:20: error: assignment to expression
>> with array type
832 | phydev->supported &= (ADVERTISED_10baseT_Full
|^~
drivers/staging/netlogic/xlr_net.c:840:22: error: assignment to expression with
array type
840 | phydev->advertising = phydev->supported;
| ^
#
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=3c1bcc8614db10803f1f57ef0295363917448cb2
git remote add linus
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
git remote update linus
git checkout 3c1bcc8614db10803f1f57ef0295363917448cb2
vim +832 drivers/staging/netlogic/xlr_net.c
6f98b1a250cb60 Ganesan Ramalingam 2013-03-06 796
6f98b1a250cb60 Ganesan Ramalingam 2013-03-06 797 static void
xlr_gmac_link_adjust(struct net_device *ndev)
6f98b1a250cb60 Ganesan Ramalingam 2013-03-06 798 {
6f98b1a250cb60 Ganesan Ramalingam 2013-03-06 799 struct xlr_net_priv
*priv = netdev_priv(ndev);
3fe01e2406ead2 Andrew Lunn2016-01-11 800 struct phy_device
*phydev = xlr_get_phydev(priv);
6f98b1a250cb60 Ganesan Ramalingam 2013-03-06 @801 u32 intreg;
6f98b1a250cb60 Ganesan Ramalingam 2013-03-06 802
6f98b1a250cb60 Ganesan Ramalingam 2013-03-06 803 intreg =
xlr_nae_rdreg(priv->base_addr, R_INTREG);
6f98b1a250cb60 Ganesan Ramalingam 2013-03-06 804 if (phydev->link) {
6f98b1a250cb60 Ganesan Ramalingam 2013-03-06 805 if
(phydev->speed != priv->phy_speed) {
6f98b1a250cb60 Ganesan Ramalingam 2013-03-06 806
xlr_set_gmac_speed(priv);
f8397bc69095f6 Ganesan Ramalingam 2014-08-21 807
pr_info("gmac%d : Link up\n", priv->port_id);
6f98b1a250cb60 Ganesan Ramalingam 2013-03-06 808 }
6f98b1a250cb60 Ganesan Ramalingam 2013-03-06 809 } else {
6f98b1a250cb60 Ganesan Ramalingam 2013-03-06 810
xlr_set_gmac_speed(priv);
f8397bc69095f6 Ganesan Ramalingam 2014-08-21 811 pr_info("gmac%d
: Link down\n", priv->port_id);
6f98b1a250cb60 Ganesan Ramalingam 2013-03-06 812 }
6f98b1a250cb60 Ganesan Ramalingam 2013-03-06 813 }
6f98b1a250cb60 Ganesan Ramalingam 2013-03-06 814
6f98b1a250cb60 Ganesan Ramalingam 2013-03-06 815 static int
xlr_mii_probe(struct xlr_net_priv *priv)
6f98b1a250cb60 Ganesan Ramalingam 2013-03-06 816 {
3fe01e2406ead2 Andrew Lunn2016-01-11 817 struct phy_device
*phydev = xlr_get_phydev(priv);
6f98b1a250cb60 Ganesan Ramalingam 2013-03-06 818
6f98b1a250cb60 Ganesan Ramalingam 2013-03-06 819 if (!phydev) {
6f98b1a250cb60 Ganesan Ramalingam 2013-03-06 820 pr_err("no PHY
found on phy_addr %d\n", priv->phy_addr);
6f98b1a250cb60 Ganesan Ramalingam 2013-03-06 821 return -ENODEV;
6f98b1a250cb60 Ganesan Ramalingam 2013-03-06 822 }
6f98b1a250cb60 Ganesan Ramalingam 2013-03-06 823
6f98b1a250cb60 Ganesan Ramalingam 2013-03-06 824 /* Attach MAC to PHY */
84eff6d194df44 Andrew Lunn2016-01-06 825 phydev =
phy_connect(priv->ndev, phydev_name(phydev),
968b4e6bd3b00c Sandhya Bankar 2016-03-19 826
xlr_gmac_link_adjust, priv->nd->phy_interface);
6f98b1a250cb60 Ganesan Ramalingam 2013-03-06 827
6f98b1a250cb60 Ganesan Ramalingam 2013-03-06 828 if (IS_ERR(phydev)) {
6f98b1a250cb60 Ganesan Ramalingam 2013-03-06 829 pr_err("could
not attach PHY\n");
6f98b1a250cb60 Ganesan Ramalingam 2013-03-06 830 return
PTR_ERR(phydev);
6f98b1a250cb60 Ganesan Ramalingam 2013-03-06 831 }
6f98b1a250cb60 Ganesan Ramalingam 2013-03-06
drivers/gpu/drm/drm_gem_shmem_helper.c:540:22: error: incompatible types when assigning to type 'pgprot_t' {aka 'struct '} from type 'int'
Hi Gerd,
FYI, the error/warning still remains.
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: 3d77e6a8804abcc0504c904bd6e5cdf3a5cf8162
commit: 0be895893607fb3447478d6e33dfb60644195a09 drm/shmem: switch shmem helper
to _gem_object_funcs.mmap
config: m68k-randconfig-r033-20200601 (attached as .config)
compiler: m68k-linux-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout 0be895893607fb3447478d6e33dfb60644195a09
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross
ARCH=m68k
If you fix the issue, kindly add following tag as appropriate
Reported-by: kbuild test robot
All errors (new ones prefixed by >>, old ones prefixed by <<):
drivers/gpu/drm/drm_gem_shmem_helper.c: In function 'drm_gem_shmem_vmap_locked':
drivers/gpu/drm/drm_gem_shmem_helper.c:261:17: error: implicit declaration of
function 'pgprot_writecombine' [-Werror=implicit-function-declaration]
261 | VM_MAP, pgprot_writecombine(PAGE_KERNEL));
| ^~~
drivers/gpu/drm/drm_gem_shmem_helper.c:261:17: error: incompatible type for
argument 4 of 'vmap'
261 | VM_MAP, pgprot_writecombine(PAGE_KERNEL));
| ^~~~
| |
| int
In file included from include/asm-generic/io.h:887,
from arch/m68k/include/asm/io.h:11,
from arch/m68k/include/asm/pgtable_no.h:14,
from arch/m68k/include/asm/pgtable.h:3,
from include/linux/mm.h:99,
from include/linux/scatterlist.h:8,
from include/linux/dma-buf.h:18,
from drivers/gpu/drm/drm_gem_shmem_helper.c:6:
include/linux/vmalloc.h:119:14: note: expected 'pgprot_t' {aka 'struct
'} but argument is of type 'int'
119 | extern void *vmap(struct page **pages, unsigned int count,
| ^~~~
drivers/gpu/drm/drm_gem_shmem_helper.c: In function 'drm_gem_shmem_mmap':
<< from drivers/gpu/drm/drm_gem_shmem_helper.c:6:
>> drivers/gpu/drm/drm_gem_shmem_helper.c:540:22: error: incompatible types
>> when assigning to type 'pgprot_t' {aka 'struct '} from type 'int'
540 | vma->vm_page_prot = pgprot_writecombine(vm_get_page_prot(vma->vm_flags));
| ^~~
cc1: some warnings being treated as errors
#
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=0be895893607fb3447478d6e33dfb60644195a09
git remote add linus
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
git remote update linus
git checkout 0be895893607fb3447478d6e33dfb60644195a09
vim +540 drivers/gpu/drm/drm_gem_shmem_helper.c
2194a63a818db7 Noralf Trønnes 2019-03-12 513
2194a63a818db7 Noralf Trønnes 2019-03-12 514 /**
2194a63a818db7 Noralf Trønnes 2019-03-12 515 * drm_gem_shmem_mmap -
Memory-map a shmem GEM object
0be895893607fb Gerd Hoffmann 2019-10-16 516 * @obj: gem object
2194a63a818db7 Noralf Trønnes 2019-03-12 517 * @vma: VMA for the area to be
mapped
2194a63a818db7 Noralf Trønnes 2019-03-12 518 *
2194a63a818db7 Noralf Trønnes 2019-03-12 519 * This function implements an
augmented version of the GEM DRM file mmap
2194a63a818db7 Noralf Trønnes 2019-03-12 520 * operation for shmem objects.
Drivers which employ the shmem helpers should
0be895893607fb Gerd Hoffmann 2019-10-16 521 * use this function as their
_gem_object_funcs.mmap handler.
2194a63a818db7 Noralf Trønnes 2019-03-12 522 *
2194a63a818db7 Noralf Trønnes 2019-03-12 523 * Returns:
2194a63a818db7 Noralf Trønnes 2019-03-12 524 * 0 on success or a negative
error code on failure.
2194a63a818db7 Noralf Trønnes 2019-03-12 525 */
0be895893607fb Gerd Hoffmann 2019-10-16 526 int drm_gem_shmem_mmap(struct
drm_gem_object *obj, struct vm_area_struct *vma)
2194a63a818db7 Noralf Trønnes 2019-03-12 527 {
2194a63a818db7 Noralf Trønnes 2019-03-12 528 struct drm_gem_shmem_object
*shmem;
2194a63a818db7 Noralf Trønnes 2019-03-12 529 int ret;
2194a63a818db7 Noralf Trønnes 2019-03-12 530
0be895893607fb Gerd Hoffmann 2019-10-16 531 shmem =
to_drm_gem_shmem_obj(obj);
2194a63a818db7 Noralf Trønnes 2019-03-12 532
2194a63a818db7 Noralf Trønnes 2019-03-12 533 ret =
drm_gem_shmem_get_pages(shmem);
2194a63a818db7 Noralf Trønnes 2019-03-12 534 if (ret) {
2194a63a818db7 Noralf Trønnes 2019-03-12 535 drm_gem_vm_close(vma);
2194a63a818db7 Noralf Trønnes 2019-03-12 536 return ret;
2194a63a818db7 Noralf Trønnes 2019-03-12 537 }
2194a63a818db7 Noralf Trønnes 2019-03-12 538
0be895893607fb Gerd Hoffmann 2019-10-16 539 vma->vm_flags |= VM_IO |
VM_MIXEDMAP | VM_DONTEXPAND | VM_DONTDUMP;
0be895893607fb Gerd Hoffmann 2019-10-16 @540 vma->vm_page_prot =
pgprot_writecombine(vm_get_page_prot(vma->vm_flags));
0be895
