* [PATCH] ARM: at91: remove unnecessary of_platform_default_populate calls
From: Rob Herring @ 2018-06-19 21:40 UTC (permalink / raw)
To: linux-arm-kernel
The DT core will call of_platform_default_populate, so it is not
necessary for machine specific code to call it unless there are custom
match entries, auxdata or parent device. Neither of those apply here, so
remove the call.
Cc: Nicolas Ferre <nicolas.ferre@microchip.com>
Cc: Alexandre Belloni <alexandre.belloni@bootlin.com>
Cc: linux-arm-kernel at lists.infradead.org
Signed-off-by: Rob Herring <robh@kernel.org>
---
arch/arm/mach-at91/at91rm9200.c | 5 -----
arch/arm/mach-at91/at91sam9.c | 5 -----
arch/arm/mach-at91/sama5.c | 5 -----
3 files changed, 15 deletions(-)
diff --git a/arch/arm/mach-at91/at91rm9200.c b/arch/arm/mach-at91/at91rm9200.c
index 656ad409a253..42583261951e 100644
--- a/arch/arm/mach-at91/at91rm9200.c
+++ b/arch/arm/mach-at91/at91rm9200.c
@@ -8,17 +8,12 @@
* Licensed under GPLv2 or later.
*/
-#include <linux/of.h>
-#include <linux/of_platform.h>
-
#include <asm/mach/arch.h>
#include "generic.h"
static void __init at91rm9200_dt_device_init(void)
{
- of_platform_default_populate(NULL, NULL, NULL);
-
at91rm9200_pm_init();
}
diff --git a/arch/arm/mach-at91/at91sam9.c b/arch/arm/mach-at91/at91sam9.c
index 3dbdef4d3cbf..863a0e7ba00f 100644
--- a/arch/arm/mach-at91/at91sam9.c
+++ b/arch/arm/mach-at91/at91sam9.c
@@ -7,9 +7,6 @@
* Licensed under GPLv2 or later.
*/
-#include <linux/of.h>
-#include <linux/of_platform.h>
-
#include <asm/mach/arch.h>
#include <asm/system_misc.h>
@@ -17,8 +14,6 @@
static void __init at91sam9_init(void)
{
- of_platform_default_populate(NULL, NULL, NULL);
-
at91sam9_pm_init();
}
diff --git a/arch/arm/mach-at91/sama5.c b/arch/arm/mach-at91/sama5.c
index 3d0bf95a56ae..e3a84a59db76 100644
--- a/arch/arm/mach-at91/sama5.c
+++ b/arch/arm/mach-at91/sama5.c
@@ -7,9 +7,6 @@
* Licensed under GPLv2 or later.
*/
-#include <linux/of.h>
-#include <linux/of_platform.h>
-
#include <asm/mach/arch.h>
#include <asm/mach/map.h>
#include <asm/system_misc.h>
@@ -18,7 +15,6 @@
static void __init sama5_dt_device_init(void)
{
- of_platform_default_populate(NULL, NULL, NULL);
sama5_pm_init();
}
@@ -47,7 +43,6 @@ MACHINE_END
static void __init sama5d2_init(void)
{
- of_platform_default_populate(NULL, NULL, NULL);
sama5d2_pm_init();
}
--
2.17.1
^ permalink raw reply related
* [PATCH 1/2] IB/hfi1: Try slot reset before secondary bus reset
From: Bjorn Helgaas @ 2018-06-19 21:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1524167784-5911-1-git-send-email-okaya@codeaurora.org>
On Thu, Apr 19, 2018 at 03:56:23PM -0400, Sinan Kaya wrote:
> The infiniband adapter might be connected to a PCI hotplug slot. Performing
> secondary bus reset on a hotplug slot causes PCI link up/down interrupts.
>
> Hotplug driver removes the device from system when a link down interrupt
> is observed and performs re-enumeration when link up interrupt is observed.
>
> This conflicts with what this code is trying to do. Try secondary bus reset
> only if pci_reset_slot() fails/unsupported.
Hi Sinan,
We had a bunch of discussion here but not sure we ever reached a
consensus. It did seem like we'd like to avoid putting hotplug
knowledge in drivers, though. What do you think the path forward is?
> Signed-off-by: Sinan Kaya <okaya@codeaurora.org>
> ---
> drivers/infiniband/hw/hfi1/pcie.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/infiniband/hw/hfi1/pcie.c b/drivers/infiniband/hw/hfi1/pcie.c
> index 83d66e8..75f49e3 100644
> --- a/drivers/infiniband/hw/hfi1/pcie.c
> +++ b/drivers/infiniband/hw/hfi1/pcie.c
> @@ -908,7 +908,8 @@ static int trigger_sbr(struct hfi1_devdata *dd)
> * delay after a reset is required. Per spec requirements,
> * the link is either working or not after that point.
> */
> - pci_reset_bridge_secondary_bus(dev->bus->self);
> + if (pci_reset_slot(dev->slot))
> + pci_reset_bridge_secondary_bus(dev->bus->self);
>
> return 0;
> }
> --
> 2.7.4
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH] efi/fb: Convert PCI bus address to resource if translated by the bridge
From: Bjorn Helgaas @ 2018-06-19 21:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <733101d0-9051-a5a6-ef64-162d8d1e10a1@codeaurora.org>
On Fri, May 18, 2018 at 10:20:29AM -0400, Sinan Kaya wrote:
> On 5/18/2018 6:42 AM, Robin Murphy wrote:
> >
> > FWIW, now that I've actually gone and looked, it appears you could simplify the whole function quite a bit by getting rid of these and just using the new local resource directly, especially since the only actual use of size is an open-coded resource_contains().
>
> Posted V2 a minute ago. I did the simplification on a prior patch in order not to
> mix the issues.
I don't see the V2 on linux-pci, but it sounds like Ard would merge this
anyway. So I'll drop this and you can let me know if there's anything you
need from me.
^ permalink raw reply
* [PATCH v1] ARM: dts: imx51-zii-rdu1: fix touchscreen pinctrl
From: Nick Dyer @ 2018-06-19 22:07 UTC (permalink / raw)
To: linux-arm-kernel
The pinctrl settings were incorrect for the touchscreen interrupt line, causing
an interrupt storm. This change has been tested with both the atmel_mxt_ts and
RMI4 drivers on the RDU1 units.
Signed-off-by: Nick Dyer <nick@shmanahar.org>
---
arch/arm/boot/dts/imx51-zii-rdu1.dts | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/imx51-zii-rdu1.dts b/arch/arm/boot/dts/imx51-zii-rdu1.dts
index df9eca94d812..4d12ba54ba15 100644
--- a/arch/arm/boot/dts/imx51-zii-rdu1.dts
+++ b/arch/arm/boot/dts/imx51-zii-rdu1.dts
@@ -770,8 +770,8 @@
pinctrl_ts: tsgrp {
fsl,pins = <
- MX51_PAD_CSI1_D8__GPIO3_12 0x85
- MX51_PAD_CSI1_D9__GPIO3_13 0x85
+ MX51_PAD_CSI1_D8__GPIO3_12 4
+ MX51_PAD_CSI1_D9__GPIO3_13 (1<<16)
>;
};
--
2.17.1
^ permalink raw reply related
* [PATCH] PCI: Do not enable PASID when End-to-End TLP is not supported
From: Bjorn Helgaas @ 2018-06-19 22:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1526748769-701-1-git-send-email-okaya@codeaurora.org>
On Sat, May 19, 2018 at 12:52:49PM -0400, Sinan Kaya wrote:
> A PCIe endpoint carries the process address space identifier (PASID) in
> the TLP prefix as part of the memory read/write transaction. The address
> information in the TLP is relevant only for a given PASID context.
>
> A translation agent takes PASID value and the address information from the
> TLP to look up the physical address in the system.
>
> If a bridge drops the TLP prefix, the translation agent can resolve the
> address to an incorrect location and cause data corruption. Prevent
> this condition by requiring End-to-End TLP prefix to be supported on the
> entire data path between the endpoint and the root port.
>
> Signed-off-by: Sinan Kaya <okaya@codeaurora.org>
> ---
> drivers/pci/ats.c | 16 ++++++++++++++++
> include/uapi/linux/pci_regs.h | 1 +
> 2 files changed, 17 insertions(+)
>
> diff --git a/drivers/pci/ats.c b/drivers/pci/ats.c
> index 89305b5..0bcded5 100644
> --- a/drivers/pci/ats.c
> +++ b/drivers/pci/ats.c
> @@ -265,7 +265,9 @@ EXPORT_SYMBOL_GPL(pci_reset_pri);
> int pci_enable_pasid(struct pci_dev *pdev, int features)
> {
> u16 control, supported;
> + struct pci_dev *bridge;
> int pos;
> + u32 cap;
>
> if (WARN_ON(pdev->pasid_enabled))
> return -EBUSY;
> @@ -274,6 +276,20 @@ int pci_enable_pasid(struct pci_dev *pdev, int features)
> if (!pos)
> return -EINVAL;
>
> + bridge = pci_upstream_bridge(pdev);
> + while (bridge) {
> + if (!pci_find_capability(bridge, PCI_CAP_ID_EXP))
> + return -EINVAL;
> +
> + if (pcie_capability_read_dword(bridge, PCI_EXP_DEVCAP2, &cap))
> + return -EINVAL;
> +
> + if (!(cap & PCI_EXP_DEVCAP2_E2ETLP))
> + return -EINVAL;
> +
> + bridge = pci_upstream_bridge(bridge);
> + }
Hi Sinan,
Would you consider implementing this in the style of c46fd358070f
("PCI/ASPM: Enable Latency Tolerance Reporting when supported"), i.e.,
add a bit in struct pci_dev so we don't have to search up the tree and
re-lookup the PCIe capability several times for the endpoints of the
hierarchy?
This loop looks much like the one in pci_enable_atomic_ops_to_root()
but doesn't use exactly the same iteration.
Maybe we should someday collect up and combine all the places that
read the capability registers so we don't have to read them multiple
times? Not sure if that would make readability better or worse -- it
would add a second place to look at, while with this patch, everything
is all in one place.
> +
> pci_read_config_word(pdev, pos + PCI_PASID_CAP, &supported);
> supported &= PCI_PASID_CAP_EXEC | PCI_PASID_CAP_PRIV;
>
> diff --git a/include/uapi/linux/pci_regs.h b/include/uapi/linux/pci_regs.h
> index 103ba79..d91dea5 100644
> --- a/include/uapi/linux/pci_regs.h
> +++ b/include/uapi/linux/pci_regs.h
> @@ -634,6 +634,7 @@
> #define PCI_EXP_DEVCAP2_OBFF_MASK 0x000c0000 /* OBFF support mechanism */
> #define PCI_EXP_DEVCAP2_OBFF_MSG 0x00040000 /* New message signaling */
> #define PCI_EXP_DEVCAP2_OBFF_WAKE 0x00080000 /* Re-use WAKE# for OBFF */
> +#define PCI_EXP_DEVCAP2_E2ETLP 0x00200000 /* End-to-End TLP Prefix */
> #define PCI_EXP_DEVCTL2 40 /* Device Control 2 */
> #define PCI_EXP_DEVCTL2_COMP_TIMEOUT 0x000f /* Completion Timeout Value */
> #define PCI_EXP_DEVCTL2_COMP_TMOUT_DIS 0x0010 /* Completion Timeout Disable */
> --
> 2.7.4
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH] efi/fb: Convert PCI bus address to resource if translated by the bridge
From: Sinan Kaya @ 2018-06-19 22:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180619215955.GF33049@bhelgaas-glaptop.roam.corp.google.com>
Hi Bjorn,
On 6/19/2018 5:59 PM, Bjorn Helgaas wrote:
> On Fri, May 18, 2018 at 10:20:29AM -0400, Sinan Kaya wrote:
>> On 5/18/2018 6:42 AM, Robin Murphy wrote:
>>>
>>> FWIW, now that I've actually gone and looked, it appears you could simplify the whole function quite a bit by getting rid of these and just using the new local resource directly, especially since the only actual use of size is an open-coded resource_contains().
>>
>> Posted V2 a minute ago. I did the simplification on a prior patch in order not to
>> mix the issues.
>
> I don't see the V2 on linux-pci, but it sounds like Ard would merge this
> anyway. So I'll drop this and you can let me know if there's anything you
> need from me.
>
It is planned to go through fbdev tree for 4.19.
https://patchwork.kernel.org/patch/10410895/
Feel free to review/ACK.
Sinan
--
Sinan Kaya
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.
^ permalink raw reply
* [PATCH 1/2] IB/hfi1: Try slot reset before secondary bus reset
From: Sinan Kaya @ 2018-06-19 22:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180619214346.GD33049@bhelgaas-glaptop.roam.corp.google.com>
On 6/19/2018 5:43 PM, Bjorn Helgaas wrote:
>> Hotplug driver removes the device from system when a link down interrupt
>> is observed and performs re-enumeration when link up interrupt is observed.
>>
>> This conflicts with what this code is trying to do. Try secondary bus reset
>> only if pci_reset_slot() fails/unsupported.
> Hi Sinan,
>
> We had a bunch of discussion here but not sure we ever reached a
> consensus. It did seem like we'd like to avoid putting hotplug
> knowledge in drivers, though. What do you think the path forward is?
>
There are multiple issues.
We discussed the need for a retrain API on this thread. However, retrain API may
not be enough for this particular usage as the device might need a full link training
sequence following firmware load including a hot reset message. I don't think we can
remove the bus reset usage in this code.
I'd like to start with a small one to address your comment here.
"I think my concern is that knowledge about this reset/link down/hotplug issue is
leaking out and we'll end up with different reset interfaces that may
or may not result in hotplug events. This seems like a confusing API
because it's hard to explain which interface a driver should use."
I'm thinking of removing pci_reset_slot() and pci_try_reset_slot() functions
as an exported API and fold them into pci_reset_bus() and pci_try_reset_bus()
API respectively.
This is what happens when you insert a fatal error to a hotplug slot. See multiple
link up/down messages.
/_#_[__333.699731]_pcieport_0001:00:00.0:_AER:_Uncorrected_(Fatal)_error_received:_id=0000
[ 333.748116] pcieport 0001:00:00.0: PCIe Bus Error: severity=Uncorrected (Fatal), type=Transaction Layer, id
[ 333.816044] pcieport 0001:00:00.0: device [17cb:0404] error status/mask=00040000/00400000
[ 333.871581] pcieport 0001:00:00.0: [18] Malformed TLP (First)
[ 333.914675] pcieport 0001:00:00.0: TLP Header: 40000001 000000ff 00000000 00000000
[ 333.968397] pciehp 0001:00:00.0:pcie004: Slot(2): Link Down
[ 334.043234] iommu: Removing device 0001:01:00.4 from group 0
[ 334.095952] iommu: Removing device 0001:01:00.3 from group 0
[ 334.144644] iommu: Removing device 0001:01:00.2 from group 0
[ 334.194653] iommu: Removing device 0001:01:00.1 from group 0
[ 334.243564] pciehp 0001:00:00.0:pcie004: Slot(2): Link Up
[ 334.282556] iommu: Removing device 0001:01:00.0 from group 0
[ 334.330994] pciehp 0001:00:00.0:pcie004: Slot(2): Link Up event queued; currently getting powered off
[ 334.890587] pciehp 0001:00:00.0:pcie004: Timeout on hotplug command 0x13f1 (issued 282900 msec ago)
[ 335.070190] pciehp 0001:00:00.0:pcie004: Slot(2): Link Down
[ 335.106960] pciehp 0001:00:00.0:pcie004: Slot(2): Link Down event queued; currently getting powered on
[ 335.191119] pcieport 0001:00:00.0: AER: Device recovery failed
[ 346.590153] pciehp 0001:00:00.0:pcie004: Timeout on hotplug command 0x17f1 (issued 10250 msec ago)
As a suggestion:
1. If the device belongs to a slot, do slot reset.
2. Otherwise, do bus reset.
Since Oza's DPC/AER patch to refactor fatal error handling, both hotplug driver
and AER/DPC driver will try removing devices and perform enumeration on link events/AER events.
Perfect environment for race condition without a change.
--
Sinan Kaya
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.
^ permalink raw reply
* [PATCH 0/2] Make badr macro compatible with newer GAS versions
From: Ard Biesheuvel @ 2018-06-19 22:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180619204531.GB28370@roeck-us.net>
On 19 June 2018 at 22:45, Guenter Roeck <linux@roeck-us.net> wrote:
> On Tue, Jun 19, 2018 at 10:34:38PM +0200, Ard Biesheuvel wrote:
>> On 19 June 2018 at 22:32, Guenter Roeck <linux@roeck-us.net> wrote:
>> > On Tue, Jun 19, 2018 at 09:26:31PM +0200, Ard Biesheuvel wrote:
>> >> Work around the mindless and backward incompatible change in GAS that
>> >> prevents us from using a simple addition to set the Thumb bit in local
>> >> symbol references taken using 'adr' instructions (#2)
>> >>
>> >> As a preparatory step, remove badr occurrences in ARM code sequences
>> >> contained in Thumb2 kernels.
>> >>
>> >> Ard Biesheuvel (2):
>> >> ARM: avoid badr macro for switching to Thumb-2 mode
>> >> ARM: assembler: prevent ADR from setting the Thumb bit twice
>> >>
>> >
>> > This doesn't work for images built with a toolchain based on gcc 7.3.0
>> > and binutils 2.28.1. It _does_ work for images built with gcc 7.3.0/
>> > binutils 2.30.
>> >
>>
>> Sigh.
>>
>> So does it fail? Or is the resulting binary broken?
>
> Hard to say. It crashes early in boot, even before earlycon can say
> anything.
>
OK, so even the linker handling is inconsistent.
Working (binutils 2.30)
c0301164 <local_restart>:
c0301164: f8d9 a000 ldr.w sl, [r9]
c0301168: e92d 0030 stmdb sp!, {r4, r5}
c030116c: f01a 0ff0 tst.w sl, #240 ; 0xf0
c0301170: d117 bne.n c03011a2 <__sys_trace>
c0301172: 46ba mov sl, r7
c0301174: f5ba 7fc8 cmp.w sl, #400 ; 0x190
c0301178: bf28 it cs
c030117a: f04f 0a00 movcs.w sl, #0
c030117e: f3af 8014 csdb
c0301182: f2af 1e83 subw lr, pc, #387 ; 0x183
c0301182: R_ARM_THM_ALU_PREL_11_0 .Lsym28
Broken (binutils 2.26)
c0301184 <local_restart>:
c0301184: f8d9 a000 ldr.w sl, [r9]
c0301188: e92d 0030 stmdb sp!, {r4, r5}
c030118c: f01a 0ff0 tst.w sl, #240 ; 0xf0
c0301190: d117 bne.n c03011c2 <__sys_trace>
c0301192: 46ba mov sl, r7
c0301194: f5ba 7fc8 cmp.w sl, #400 ; 0x190
c0301198: bf28 it cs
c030119a: f04f 0a00 movcs.w sl, #0
c030119e: f3af 8014 csdb
c03011a2: f2af 1ea2 subw lr, pc, #418 ; 0x1a2
c03011a2: R_ARM_THM_ALU_PREL_11_0 .Lsym30
Note the even immediate in the subw instruction. So this is another
dead end, unfortunately.
Thanks for testing.
^ permalink raw reply
* [PATCH V2 2/2] efi/fb: Convert PCI bus address to resource if translated by the bridge
From: Bjorn Helgaas @ 2018-06-19 22:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1526653072-7153-2-git-send-email-okaya@codeaurora.org>
Minor subject nit: From the caller's point of view, we must convert a bus
address to a resource *always* (the caller has no knowledge of "whether it
is translated by the host bridge").
On Fri, May 18, 2018 at 10:17:51AM -0400, Sinan Kaya wrote:
> A host bridge is allowed to remap BAR addresses using _TRA attribute in
> _CRS windows.
Also, _TRA/_CRS are ACPI-specific terms and non-ACPI host bridges can
also do the same sort of translation. Another trivial nit.
> pci_bus 0000:00: root bus resource [mem 0x80100100000-0x8011fffffff window] (bus address [0x00100000-0x1fffffff])
> pci 0000:02:00.0: reg 0x10: [mem 0x8011e000000-0x8011effffff]
>
> When a VGA device is behind such a host bridge and the resource is
> translated efifb driver is trying to do ioremap against bus address
> rather than the resource address and is failing to probe.
>
> efifb: probing for efifb
> efifb: cannot reserve video memory at 0x1e000000
> efifb: framebuffer at 0x1e000000, using 1920k, total 1875k
> efifb: mode is 800x600x32, linelength=3200, pages=1
> efifb: scrolling: redraw
> efifb: Truecolor: size=8:8:8:8, shift=24:16:8:0
>
> Use the host bridge offset information to convert bus address to
> resource address in the fixup.
>
> Signed-off-by: Sinan Kaya <okaya@codeaurora.org>
Reviewed-by: Bjorn Helgaas <bhelgaas@google.com>
Thanks a lot for fixing this!
> ---
> drivers/video/fbdev/efifb.c | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/drivers/video/fbdev/efifb.c b/drivers/video/fbdev/efifb.c
> index 6daac8d..429cc85 100644
> --- a/drivers/video/fbdev/efifb.c
> +++ b/drivers/video/fbdev/efifb.c
> @@ -431,6 +431,7 @@ static void efifb_fixup_resources(struct pci_dev *dev)
> .end = screen_info.lfb_base + screen_info.lfb_size - 1,
> .flags = IORESOURCE_MEM,
> };
> + struct pci_bus_region region;
> int i;
>
> if (efifb_pci_dev || screen_info.orig_video_isVGA != VIDEO_TYPE_EFI)
> @@ -442,6 +443,10 @@ static void efifb_fixup_resources(struct pci_dev *dev)
> if (!screen_res.start)
> return;
>
> + region.start = screen_res.start;
> + region.end = screen_res.end;
> + pcibios_bus_to_resource(dev->bus, &screen_res, ®ion);
> +
> for (i = 0; i <= PCI_STD_RESOURCE_END; i++) {
> struct resource *res = &dev->resource[i];
>
> --
> 2.7.4
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH 1/5] net: emaclite: Use __func__ instead of hardcoded name
From: Joe Perches @ 2018-06-19 22:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAHp75VcKuqnUgynqXvACS7zY5=6aRxqymGE1w3Yh8sshehSm2g@mail.gmail.com>
On Wed, 2018-06-20 at 00:36 +0300, Andy Shevchenko wrote:
> On Mon, Jun 18, 2018 at 2:08 PM, Radhey Shyam Pandey
> <radhey.shyam.pandey@xilinx.com> wrote:
> > Switch hardcoded function name with a reference to __func__ making
> > the code more maintainable. Address below checkpatch warning:
> >
> > WARNING: Prefer using '"%s...", __func__' to using 'xemaclite_mdio_read',
> > this function's name, in a string
> > + "xemaclite_mdio_read(phy_id=%i, reg=%x) == %x\n",
> >
> > WARNING: Prefer using '"%s...", __func__' to using 'xemaclite_mdio_write',
> > this function's name, in a string
> > + "xemaclite_mdio_write(phy_id=%i, reg=%x, val=%x)\n",
> >
>
> For dev_dbg() the __func__ should be completely dropped away.
Not really the same.
dev_dbg without CONFIG_DYNAMIC_DEBUG does not have
the ability to prefix __func__.
^ permalink raw reply
* [PATCH 0/2] Make badr macro compatible with newer GAS versions
From: Guenter Roeck @ 2018-06-19 22:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAKv+Gu_zsSxb_8Ej-6QwZOW2X5VfgW0gnjpnHpi62L6nPALoHQ@mail.gmail.com>
On Wed, Jun 20, 2018 at 12:23:56AM +0200, Ard Biesheuvel wrote:
>
> OK, so even the linker handling is inconsistent.
>
> Working (binutils 2.30)
>
> c0301164 <local_restart>:
> c0301164: f8d9 a000 ldr.w sl, [r9]
> c0301168: e92d 0030 stmdb sp!, {r4, r5}
> c030116c: f01a 0ff0 tst.w sl, #240 ; 0xf0
> c0301170: d117 bne.n c03011a2 <__sys_trace>
> c0301172: 46ba mov sl, r7
> c0301174: f5ba 7fc8 cmp.w sl, #400 ; 0x190
> c0301178: bf28 it cs
> c030117a: f04f 0a00 movcs.w sl, #0
> c030117e: f3af 8014 csdb
> c0301182: f2af 1e83 subw lr, pc, #387 ; 0x183
> c0301182: R_ARM_THM_ALU_PREL_11_0 .Lsym28
>
>
> Broken (binutils 2.26)
>
> c0301184 <local_restart>:
> c0301184: f8d9 a000 ldr.w sl, [r9]
> c0301188: e92d 0030 stmdb sp!, {r4, r5}
> c030118c: f01a 0ff0 tst.w sl, #240 ; 0xf0
> c0301190: d117 bne.n c03011c2 <__sys_trace>
> c0301192: 46ba mov sl, r7
> c0301194: f5ba 7fc8 cmp.w sl, #400 ; 0x190
> c0301198: bf28 it cs
> c030119a: f04f 0a00 movcs.w sl, #0
> c030119e: f3af 8014 csdb
> c03011a2: f2af 1ea2 subw lr, pc, #418 ; 0x1a2
> c03011a2: R_ARM_THM_ALU_PREL_11_0 .Lsym30
>
>
> Note the even immediate in the subw instruction. So this is another
> dead end, unfortunately.
>
Looks like someone is trying to make things really difficunt :-(.
I think I'll just stick with binutils 2.28.1. Not optimal, but
at least it works.
Something else: I can boot Cortex-M under qemu (-M mps2-an385). The only problem
I have is this:
/ # kill -1 1
[ 3.806568]
[ 3.806568] Unhandled exception: IPSR = 00000006 LR = fffffffd
[ 3.807221] CPU: 0 PID: 1 Comm: init Not tainted 4.18.0-rc1-00043-gba4dbdedd3ed #42
[ 3.807590] Hardware name: MPS2 (Device Tree Support)
[ 3.808162] PC is at (null)
[ 3.808374] LR is at 0x2170fc37
[ 3.808549] pc : [<00000000>] lr : [<2170fc37>] psr: 60000000
[ 3.808841] sp : 21761b90 ip : 21761f00 fp : 21758c04
[ 3.809118] r10: 00000000 r9 : 00000000 r8 : 00000000
[ 3.809329] r7 : 00000000 r6 : 00000001 r5 : 00000000 r4 : 2175452c
[ 3.809565] r3 : 00000000 r2 : 00000000 r1 : 00000000 r0 : 00000001
[ 3.809791] xPSR: 60000000
[ 3.809926] CPU: 0 PID: 1 Comm: init Not tainted 4.18.0-rc1-00043-gba4dbdedd3ed #42
[ 3.810179] Hardware name: MPS2 (Device Tree Support)
[ 3.811246] [<2100bd8d>] (unwind_backtrace) from [<2100b13b>] (show_stack+0xb/0xc)
[ 3.811656] [<2100b13b>] (show_stack) from [<2100b87b>] (__invalid_entry+0x4b/0x4c)
Everything else seems to work, just sending a signal to init causes it
to blow up. Any idea what might cause this ?
Thanks,
Guenter
^ permalink raw reply
* [PATCH] driver core: add a debugfs entry to show deferred devices
From: Greg Kroah-Hartman @ 2018-06-19 22:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180619205914.21375-1-javierm@redhat.com>
On Tue, Jun 19, 2018 at 10:59:14PM +0200, Javier Martinez Canillas wrote:
> For debugging purposes it may be useful to know what are the devices whose
> probe function was deferred. Add a debugfs entry showing that information.
>
> $ cat /sys/kernel/debug/deferred_devices
> 48070000.i2c:twl at 48:bci
> musb-hdrc.0.auto
> omapdrm.0
>
> Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
>
> ---
>
> Changes since RFC v1:
> - Remove unneeded ret variable from deferred_devs_show()
>
> Changes since RFC v2:
> - Use DEFINE_SHOW_ATTRIBUTE() macro.
> - Don't propagate debugfs_create_file() error.
> - Remove IS_ENABLED(CONFIG_DEBUG_FS) guards.
> - Drop RFC prefix.
>
> drivers/base/dd.c | 22 ++++++++++++++++++++++
> 1 file changed, 22 insertions(+)
>
> diff --git a/drivers/base/dd.c b/drivers/base/dd.c
> index 1435d7281c6..8ec9e3cfbe4 100644
> --- a/drivers/base/dd.c
> +++ b/drivers/base/dd.c
> @@ -16,6 +16,7 @@
> * Copyright (c) 2007-2009 Novell Inc.
> */
>
> +#include <linux/debugfs.h>
> #include <linux/device.h>
> #include <linux/delay.h>
> #include <linux/dma-mapping.h>
> @@ -224,6 +225,24 @@ void device_unblock_probing(void)
> driver_deferred_probe_trigger();
> }
>
> +/*
> + * deferred_devs_show() - Show the devices in the deferred probe pending list.
> + */
> +static int deferred_devs_show(struct seq_file *s, void *data)
> +{
> + struct device_private *curr;
> +
> + mutex_lock(&deferred_probe_mutex);
> +
> + list_for_each_entry(curr, &deferred_probe_pending_list, deferred_probe)
> + seq_printf(s, "%s\n", dev_name(curr->device));
> +
> + mutex_unlock(&deferred_probe_mutex);
> +
> + return 0;
> +}
> +DEFINE_SHOW_ATTRIBUTE(deferred_devs);
> +
> /**
> * deferred_probe_initcall() - Enable probing of deferred devices
> *
> @@ -233,6 +252,9 @@ void device_unblock_probing(void)
> */
> static int deferred_probe_initcall(void)
> {
> + debugfs_create_file("deferred_devices", 0444, NULL, NULL,
> + &deferred_devs_fops);
In the root of debugfs?
Anyway, what about "devices_deferred", to help keep things semi-sane if
we have other driver core debugfs entries?
And you don't remove the file ever?
And what is the use of this file? What can you do with this
information? Who is going to use it? Don't we have other deferred
probe debugging somewhere else?
thanks,
greg k-h
^ permalink raw reply
* [PATCH 0/5] Fixes coding style in xilinx_emaclite.c
From: David Miller @ 2018-06-19 22:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1529322610-27215-1-git-send-email-radhey.shyam.pandey@xilinx.com>
From: Radhey Shyam Pandey <radhey.shyam.pandey@xilinx.com>
Date: Mon, 18 Jun 2018 17:20:05 +0530
> This patchset fixes checkpatch and kernel-doc warnings in
> xilinx emaclite driver. No functional change.
Such cleanups are only appropriate for net-next, which is closed at this
time.
^ permalink raw reply
* [PATCH 1/1] arm64: dts: rockchip: correct voltage selector Firefly-RK3399
From: Heiko Stuebner @ 2018-06-19 23:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <19360053.2ABrQ075F2@phil>
Hi Heinrich,
Am Donnerstag, 14. Juni 2018, 14:55:27 CEST schrieb Heiko Stuebner:
> Am Montag, 4. Juni 2018, 19:15:23 CEST schrieb Heinrich Schuchardt:
> > Without this patch the Firefly-RK3399 board boot process hangs after these
> > lines:
> >
> > fan53555-regulator 0-0040: FAN53555 Option[8] Rev[1] Detected!
> > fan53555-reg: supplied by vcc_sys
> > vcc1v8_s3: supplied by vcc_1v8
> >
> > Blacklisting driver fan53555 allows booting.
> >
> > The device tree uses a value of fcs,suspend-voltage-selector different to
> > any other board.
> >
> > Changing this setting to the usual value is sufficient to enable booting.
> >
> > Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
>
> applied for 4.19.
and dropped again.
Sadly it looks like the patch causes conflicts with at least one firefly
board in a kernelci lab. My own is currently not ready to use, so I cannot
look myself right now.
The issue kernelci people described sounded quite a lot like the one
in your commit message, so my current theory is that the
suspend-voltage-selector must in some form corespond to the
cpu_b_sleep_h gpio setting we're currently not handling at all, which
would therefore depend on how the bootloader sets this up.
Heiko
^ permalink raw reply
* [GIT PULL 1/3] Broadcom devicetree fixes for 4.18
From: Florian Fainelli @ 2018-06-19 23:31 UTC (permalink / raw)
To: linux-arm-kernel
The following changes since commit ce397d215ccd07b8ae3f71db689aedb85d56ab40:
Linux 4.18-rc1 (2018-06-17 08:04:49 +0900)
are available in the git repository at:
https://github.com/Broadcom/stblinux.git tags/arm-soc/for-4.18/devicetree-fixes
for you to fetch changes up to 6cb1628ad3506b315cdddd7676db0ff2af378d28:
ARM: dts: Cygnus: Fix PCIe controller interrupt type (2018-06-18 09:40:36 -0700)
----------------------------------------------------------------
This pull request contains Broadcom ARM-based SoCs Device Tree fixes for
4.18, please pull the following:
- Ray fixes the I2C and PCIe interrupt types for the Cygnus SoC
- Florian fixes the I2C and PCIe interrupts for the Northstar
(BCM5301x), Northstar Plus and Hurricane 2 SoCs
----------------------------------------------------------------
Florian Fainelli (4):
ARM: dts: NSP: Fix i2c controller interrupt type
ARM: dts: NSP: Fix PCIe controllers interrupt types
ARM: dts: HR2: Fix interrupt types for i2c and PCIe
ARM: dts: BCM5301x: Fix i2c controller interrupt type
Ray Jui (2):
ARM: dts: Cygnus: Fix I2C controller interrupt type
ARM: dts: Cygnus: Fix PCIe controller interrupt type
arch/arm/boot/dts/bcm-cygnus.dtsi | 24 ++++++++++++------------
arch/arm/boot/dts/bcm-hr2.dtsi | 24 ++++++++++++------------
arch/arm/boot/dts/bcm-nsp.dtsi | 32 ++++++++++++++++----------------
arch/arm/boot/dts/bcm5301x.dtsi | 2 +-
4 files changed, 41 insertions(+), 41 deletions(-)
^ permalink raw reply
* [GIT PULL 2/3] Broadcom devicetree-arm64 fixes for 4.18
From: Florian Fainelli @ 2018-06-19 23:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180619233104.32173-1-f.fainelli@gmail.com>
The following changes since commit ce397d215ccd07b8ae3f71db689aedb85d56ab40:
Linux 4.18-rc1 (2018-06-17 08:04:49 +0900)
are available in the git repository at:
https://github.com/Broadcom/stblinux.git tags/arm-soc/for-4.18/devicetree-arm64-fixes
for you to fetch changes up to 75af23c4736c5633894ea0baf9bca1cf6b248ca4:
arm64: dts: Stingray: Fix I2C controller interrupt type (2018-06-18 09:47:36 -0700)
----------------------------------------------------------------
This pull request contains Broadcom ARM64-based SoCs Device Tree fixes
for 4.18, please pull the following:
- Scott fixes both the bcm958742k and bcm958742t reference boards to
have the correct eMMC voltage specified
- Ray fixes the I2C and PCIe Device Tree nodes interrupt specifiers for
Northstar 2 and Stingray SoCs.
----------------------------------------------------------------
Ray Jui (3):
arm64: dts: ns2: Fix I2C controller interrupt type
arm64: dts: ns2: Fix PCIe controller interrupt type
arm64: dts: Stingray: Fix I2C controller interrupt type
Scott Branden (2):
arm64: dts: specify 1.8V EMMC capabilities for bcm958742k
arm64: dts: specify 1.8V EMMC capabilities for bcm958742t
arch/arm64/boot/dts/broadcom/northstar2/ns2.dtsi | 8 ++++----
arch/arm64/boot/dts/broadcom/stingray/bcm958742k.dts | 4 ++++
arch/arm64/boot/dts/broadcom/stingray/bcm958742t.dts | 4 ++++
arch/arm64/boot/dts/broadcom/stingray/stingray.dtsi | 4 ++--
4 files changed, 14 insertions(+), 6 deletions(-)
^ permalink raw reply
* [GIT PULL 3/3] Broadcom maintainers-arm64 fixes for 4.18
From: Florian Fainelli @ 2018-06-19 23:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180619233104.32173-1-f.fainelli@gmail.com>
The following changes since commit ce397d215ccd07b8ae3f71db689aedb85d56ab40:
Linux 4.18-rc1 (2018-06-17 08:04:49 +0900)
are available in the git repository at:
https://github.com/Broadcom/stblinux.git tags/arm-soc/for-4.18/maintainers-arm64-fixes
for you to fetch changes up to d64324acdb7052b08b13ffc8c12af232c6a29afd:
MAINTAINERS: Update Broadcom iProc entry with Stingray (2018-06-18 09:28:36 -0700)
----------------------------------------------------------------
This pull request contains Broadcom ARM64-based SoCs MAINTAINERS file
fixes for 4.18, please pull the following:
- Florian fixes the entry for the Northstar2 SoCs which was somehow lost
during a directory move. He also adds an entry for the Stingray SoCs
which was missing from the day files were added
----------------------------------------------------------------
Florian Fainelli (2):
MAINAINTERS: Corrected Broadcom Northstar2 entry
MAINTAINERS: Update Broadcom iProc entry with Stingray
MAINTAINERS | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
^ permalink raw reply
* [PATCH] driver core: add a debugfs entry to show deferred devices
From: Andy Shevchenko @ 2018-06-19 23:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180619225145.GA23389@kroah.com>
On Wed, Jun 20, 2018 at 1:51 AM, Greg Kroah-Hartman
<gregkh@linuxfoundation.org> wrote:
> On Tue, Jun 19, 2018 at 10:59:14PM +0200, Javier Martinez Canillas wrote:
>> For debugging purposes it may be useful to know what are the devices whose
>> probe function was deferred. Add a debugfs entry showing that information.
>>
>> $ cat /sys/kernel/debug/deferred_devices
>> 48070000.i2c:twl at 48:bci
>> musb-hdrc.0.auto
>> omapdrm.0
> And what is the use of this file? What can you do with this
> information? Who is going to use it? Don't we have other deferred
> probe debugging somewhere else?
Indeed.
Javier, have you tried to add 'initcall_debug' to a kernel command
line followed by 'dyndbg="file drivers/base/dd.c +p"'?
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* [PATCH v3 24/27] devicetree: fix a series of wrong file references
From: Chen-Yu Tsai @ 2018-06-20 0:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <bce1b59268ac2d659fd7cb37f89285ef2acc8316.1528990947.git.mchehab+samsung@kernel.org>
On Fri, Jun 15, 2018 at 12:09 AM, Mauro Carvalho Chehab
<mchehab+samsung@kernel.org> wrote:
> As files got renamed, their references broke.
>
> Manually fix a series of broken refs at the DT bindings.
>
> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
> ---
> Documentation/devicetree/bindings/mfd/sun6i-prcm.txt | 2 +-
Acked-by: Chen-Yu Tsai <wens@csie.org>
^ permalink raw reply
* [PATCH 2/5] RFC: eeprom: at24: Allow passing gpiodesc from pdata
From: Andy Shevchenko @ 2018-06-20 0:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180618074556.6944-3-linus.walleij@linaro.org>
On Mon, Jun 18, 2018 at 10:45 AM, Linus Walleij
<linus.walleij@linaro.org> wrote:
> This makes it possible to pass an initialized GPIO descriptor
> to the driver through platform data.
>
> This is useful when we are dealing with EEPROMs on expansion
> boards where the GPIO has to be looked up indirectly using a
> connector abstraction (several systems using the same
> connector) so the machine descriptor tables cannot be used
> to associate the descriptor with the device and we then want
> to pass this descriptor on to the EEPROM driver this way
> instead.
How this descriptor is supposed to be created?
Whenever we probe the device we might add properties to it (consider
how MFD does instansiate them), I guess same way GPIO lookup tables
work. No?
P.S. I really would like to hear a _strong_ argument why it can't be
done using other means like built-in device properties or GPIO lookup
tables (which on my opinion have to work in the similar way at run
time).
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* [PATCH] ASoC: add hp-det-gpio and mic-det-gpio to audio graph card binding
From: Katsuhiro Suzuki @ 2018-06-20 1:59 UTC (permalink / raw)
To: linux-arm-kernel
Add headphone and microphone detection GPIO support to audio graph
card same as supported in simple card.
Signed-off-by: Katsuhiro Suzuki <suzuki.katsuhiro@socionext.com>
---
Documentation/devicetree/bindings/sound/audio-graph-card.txt | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/sound/audio-graph-card.txt b/Documentation/devicetree/bindings/sound/audio-graph-card.txt
index d04ea3b1a1dd..7e63e53a901c 100644
--- a/Documentation/devicetree/bindings/sound/audio-graph-card.txt
+++ b/Documentation/devicetree/bindings/sound/audio-graph-card.txt
@@ -18,6 +18,8 @@ Below are same as Simple-Card.
- bitclock-inversion
- frame-inversion
- mclk-fs
+- hp-det-gpio
+- mic-det-gpio
- dai-tdm-slot-num
- dai-tdm-slot-width
- clocks / system-clock-frequency
--
2.17.1
^ permalink raw reply related
* [GIT PULL] Allwinner clock changes for 4.18
From: Chen-Yu Tsai @ 2018-06-20 2:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAGb2v66MkLLqL=Ei5kMb_CzpgUANpkNN3E52mSHKrZ0L7rXAog@mail.gmail.com>
Hi Stephen,
On Tue, Jun 12, 2018 at 4:38 PM, Chen-Yu Tsai <wens@csie.org> wrote:
> On Tue, Jun 12, 2018 at 4:00 PM, Stephen Boyd <sboyd@kernel.org> wrote:
>> Quoting Chen-Yu Tsai (2018-06-11 00:53:41)
>>> Hi,
>>>
>>> On Mon, Jun 11, 2018 at 10:00 AM, Masahiro Yamada
>>> <yamada.masahiro@socionext.com> wrote:
>>> > Hi Maxime,
>>> >
>>> >
>>> > 2018-05-21 20:59 GMT+09:00 Maxime Ripard <maxime.ripard@bootlin.com>:
>>> >> Hi Mike, Stephen,
>>> >>
>>> >> Please merge the following changes for the next merge window, thanks!
>>> >>
>>> >> Maxime
>>> >>
>>> >> The following changes since commit 60cc43fc888428bb2f18f08997432d426a243338:
>>> >>
>>> >> Linux 4.17-rc1 (2018-04-15 18:24:20 -0700)
>>> >>
>>> >> are available in the Git repository at:
>>> >>
>>> >> https://git.kernel.org/pub/scm/linux/kernel/git/sunxi/linux.git tags/sunxi-clk-for-4.18
>>> >>
>>> >> for you to fetch changes up to 17de4c857b1f74b90967f7e7fd5ff81be61dc044:
>>> >>
>>> >> clk: sunxi-ng: r40: export a regmap to access the GMAC register (2018-05-17 14:02:07 +0800)
>>> >>
>>> >> ----------------------------------------------------------------
>>> >> Allwinner clock changes for 4.18
>>> >>
>>> >> Not a lot of changes for this release, but two quite important features
>>> >> were added: the H6 PRCM clock support, and the needed changes to the R40
>>> >> clock driver to allow for the EMAC to operate.
>>> >>
>>> >> ----------------------------------------------------------------
>>> >> Icenowy Zheng (3):
>>> >> clk: sunxi-ng: add support for H6 PRCM CCU
>>> >> clk: sunxi-ng: r40: rewrite init code to a platform driver
>>> >> clk: sunxi-ng: r40: export a regmap to access the GMAC register
>>> >>
>>> >
>>> >
>>> >
>>> > Why was my patch "clk: sunxi-ng: replace lib-y with obj-y"
>>> > not included in the pull request?
>>> >
>>> >
>>> > You said "I've picked it up"
>>> > https://patchwork.kernel.org/patch/10348031/
>>>
>>> It looks like it was accidentally dropped after a rebase.
>>> Not quite sure what happened there. Maxime?
>>>
>>
>> I can directly pick and send as fix for clk-fixes targeting rc2.
This is a friendly reminder to pick up this patch for -rc2.
> The patch can still be found in the sunxi/for-next branch of the
> sunxi repo on kernel.org:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/sunxi/linux.git/commit/?h=sunxi/for-next&id=d4a1496286b0c29fcace4e10c0047cca7cc79b25
This is still available, but no longer referenced in any branch,
as we've updated our sunxi/for-next branch for 4.19 stuff.
> Or the original on patchwork:
>
> https://patchwork.kernel.org/patch/10348027/
And
Acked-by: Chen-Yu Tsai <wens@csie.org>
if you pick directly from patchwork.
Thanks
ChenYu
^ permalink raw reply
* [PATCH V2] PCI: Enable PASID when End-to-End TLP is supported by all bridges
From: Sinan Kaya @ 2018-06-20 2:14 UTC (permalink / raw)
To: linux-arm-kernel
A PCIe endpoint carries the process address space identifier (PASID) in
the TLP prefix as part of the memory read/write transaction. The address
information in the TLP is relevant only for a given PASID context.
An IOMMU takes PASID value and the address information from the
TLP to look up the physical address in the system.
If a bridge drops the TLP prefix, the translation agent can resolve the
address to an incorrect location and cause data corruption. Prevent
this condition by requiring End-to-End TLP prefix to be supported on the
entire data path between the endpoint and the root port.
Signed-off-by: Sinan Kaya <okaya@codeaurora.org>
---
drivers/pci/ats.c | 9 +++++++++
drivers/pci/probe.c | 17 +++++++++++++++++
include/linux/pci.h | 1 +
include/uapi/linux/pci_regs.h | 1 +
4 files changed, 28 insertions(+)
diff --git a/drivers/pci/ats.c b/drivers/pci/ats.c
index 4923a2a..e1b2e6d 100644
--- a/drivers/pci/ats.c
+++ b/drivers/pci/ats.c
@@ -268,6 +268,7 @@ EXPORT_SYMBOL_GPL(pci_reset_pri);
int pci_enable_pasid(struct pci_dev *pdev, int features)
{
u16 control, supported;
+ struct pci_dev *bridge;
int pos;
if (WARN_ON(pdev->pasid_enabled))
@@ -277,6 +278,14 @@ int pci_enable_pasid(struct pci_dev *pdev, int features)
if (!pos)
return -EINVAL;
+ bridge = pci_upstream_bridge(pdev);
+ while (bridge) {
+ if (!bridge->eetlp_prefix)
+ return -EINVAL;
+
+ bridge = pci_upstream_bridge(bridge);
+ }
+
pci_read_config_word(pdev, pos + PCI_PASID_CAP, &supported);
supported &= PCI_PASID_CAP_EXEC | PCI_PASID_CAP_PRIV;
diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
index ac876e3..a7f7ac1 100644
--- a/drivers/pci/probe.c
+++ b/drivers/pci/probe.c
@@ -2042,6 +2042,22 @@ static void pci_configure_ltr(struct pci_dev *dev)
#endif
}
+static void pci_configure_eetlp_prefix(struct pci_dev *dev)
+{
+#ifdef CONFIG_PCI_PASID
+ u32 cap;
+
+ if (!pci_is_pcie(dev))
+ return;
+
+ pcie_capability_read_dword(dev, PCI_EXP_DEVCAP2, &cap);
+ if (!(cap & PCI_EXP_DEVCAP2_E2ETLP))
+ return;
+
+ dev->eetlp_prefix = 1;
+#endif
+}
+
static void pci_configure_device(struct pci_dev *dev)
{
struct hotplug_params hpp;
@@ -2051,6 +2067,7 @@ static void pci_configure_device(struct pci_dev *dev)
pci_configure_extended_tags(dev, NULL);
pci_configure_relaxed_ordering(dev);
pci_configure_ltr(dev);
+ pci_configure_eetlp_prefix(dev);
memset(&hpp, 0, sizeof(hpp));
ret = pci_get_hp_params(dev, &hpp);
diff --git a/include/linux/pci.h b/include/linux/pci.h
index 340029b..cf88d47 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -350,6 +350,7 @@ struct pci_dev {
unsigned int ltr_path:1; /* Latency Tolerance Reporting
supported from root to here */
#endif
+ unsigned int eetlp_prefix:1; /* End-to-End TLP Prefix */
pci_channel_state_t error_state; /* Current connectivity state */
struct device dev; /* Generic device interface */
diff --git a/include/uapi/linux/pci_regs.h b/include/uapi/linux/pci_regs.h
index 4da87e2..a617ab2 100644
--- a/include/uapi/linux/pci_regs.h
+++ b/include/uapi/linux/pci_regs.h
@@ -636,6 +636,7 @@
#define PCI_EXP_DEVCAP2_OBFF_MASK 0x000c0000 /* OBFF support mechanism */
#define PCI_EXP_DEVCAP2_OBFF_MSG 0x00040000 /* New message signaling */
#define PCI_EXP_DEVCAP2_OBFF_WAKE 0x00080000 /* Re-use WAKE# for OBFF */
+#define PCI_EXP_DEVCAP2_E2ETLP 0x00200000 /* End-to-End TLP Prefix */
#define PCI_EXP_DEVCTL2 40 /* Device Control 2 */
#define PCI_EXP_DEVCTL2_COMP_TIMEOUT 0x000f /* Completion Timeout Value */
#define PCI_EXP_DEVCTL2_COMP_TMOUT_DIS 0x0010 /* Completion Timeout Disable */
--
2.7.4
^ permalink raw reply related
* [PATCH] arm64/mm: Introduce a variable to hold base address of linear region
From: Jin, Yanjiang @ 2018-06-20 2:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACi5LpM2GV-vwcEGeCE20QW0PVmDcKnjz017sYBAwYRfZ24AzA@mail.gmail.com>
Hi James, Bhupesh,
If /proc/kcore always exists in kexec/kdump, I think this issue can be fixed easily. But it requires that Kexec/kdump have to rely on " CONFIG_PROC_KCORE=y".
I am not sure if we can persuade Kexec-tools community to accept this.
Thanks,
Yanjiang
> -----Original Message-----
> From: Bhupesh Sharma [mailto:bhsharma at redhat.com]
> Sent: 2018?6?19? 19:58
> To: James Morse <james.morse@arm.com>
> Cc: Jin, Yanjiang <yanjiang.jin@hxt-semitech.com>; Will Deacon
> <will.deacon@arm.com>; Mark Rutland <mark.rutland@arm.com>; Ard
> Biesheuvel <ard.biesheuvel@linaro.org>; Catalin Marinas
> <catalin.marinas@arm.com>; Kexec Mailing List <kexec@lists.infradead.org>;
> AKASHI Takahiro <takahiro.akashi@linaro.org>; Bhupesh SHARMA
> <bhupesh.linux@gmail.com>; linux-arm-kernel <linux-arm-
> kernel at lists.infradead.org>
> Subject: Re: [PATCH] arm64/mm: Introduce a variable to hold base address of
> linear region
>
> Hi James,
>
> On Tue, Jun 19, 2018 at 4:56 PM, James Morse <james.morse@arm.com> wrote:
> > Hi Bhupesh,
> >
> > On 19/06/18 11:37, Bhupesh Sharma wrote:
> >> On Tue, Jun 19, 2018 at 3:46 PM, James Morse <james.morse@arm.com>
> wrote:
> >>> On 19/06/18 10:57, Jin, Yanjiang wrote:
> >>>>> -----Original Message-----
> >>>>> From: Will Deacon [mailto:will.deacon at arm.com]
> >>>>> Sent: 2018?6?19? 17:41
> >>>>> To: Jin, Yanjiang <yanjiang.jin@hxt-semitech.com>
> >>>>> Cc: James Morse <james.morse@arm.com>; Bhupesh Sharma
> >>>>> <bhsharma@redhat.com>; Mark Rutland <mark.rutland@arm.com>; Ard
> >>>>> Biesheuvel <ard.biesheuvel@linaro.org>; Catalin Marinas
> >>>>> <catalin.marinas@arm.com>; Kexec Mailing List
> >>>>> <kexec@lists.infradead.org>; AKASHI Takahiro
> >>>>> <takahiro.akashi@linaro.org>; Bhupesh SHARMA
> >>>>> <bhupesh.linux@gmail.com>; linux-arm-kernel <linux-arm-
> >>>>> kernel at lists.infradead.org>
> >>>>> Subject: Re: [PATCH] arm64/mm: Introduce a variable to hold base
> >>>>> address of linear region
> >
> >>>>>>>> It is hard to know all above in kexec-tools now. Originally I
> >>>>>>>> planned to read memstart_addr's value from "/dev/mem", but
> >>>>>>>> someone thought not all Kernels enable "/dev/mem", we'd better
> >>>>>>>> find a more generic approach. So we want to get some
> >>>>>>>> suggestions from ARM kernel
> >>>>> community.
> >>>>>>>> Can we export this variable in Kernel side through sysconf() or
> >>>>>>>> other similar methods? Or someone can provide an effect way to
> >>>>>>>> get memstart_addr's value?
> >>>>>>>
> >>>>>>> I thought the suggestion from James was to expose this via an
> >>>>>>> ELF NOTE in kcore and vmcore (or in the header directly if
> >>>>>>> that's possible, but I'm
> >>>>> not sure about it)?
> >>>>>>
> >>>>>> Thanks for your reply firstly. But same as DEVMEM, kcore is not a
> >>>>>> must-have, so we can't depend on it.
> >>>>>
> >>>>> Neither is KEXEC. We can select PROC_KCORE from KEXEC if it helps.
> >>>>>
> >>>>>> On the other hand, phys_to_virt() is called during generating
> >>>>>> vmcore in Kexec-tools, vmcore also can't help this issue.
> >>>>>
> >>>>> I don't understand this part. If you have the vmcore in your hand,
> >>>>> why can't you grok the pv offset from the note and use that in
> phys_to_virt()?
> >>>>
> >>>> It is a chicken-and-egg issue.
> >>>> phys_to virt() is for crashdump setup. To generate vmcore, we must
> >>>> call phys_to_virt(). At this point, no vmcore exists.
> >>>
> >>> Its needed for the parts of the ELF header that kexec-tools
> >>> generates at kdump load time?
> >>>
> >>> So adding this pv_offset to the key=value data
> >>> crash_save_vmcoreinfo_init() saves isn't available early enough?
> >
> >> Yes, one case where it is not actually available early enough for
> >> makedumpfile usage is if we are determining the PT_NOTE contents from
> >> the '/proc/kcore' on a 'live' system
> >
> >> int set_kcore_vmcoreinfo(uint64_t vmcoreinfo_addr, uint64_t
> >> vmcoreinfo_len)
> >>
> >> {
> >>
> >> <snip..>
> >> kvaddr = (ulong)vmcoreinfo_addr + PAGE_OFFSET;
> >>
> >> }
> >
> > You are trying to read the vmcoreinfo through /proc/kcore given
> > knowledge of its physical address.
> >
> > I'm suggesting adding the contents of vmcoreinfo as a PT_NOTE section
> > of /proc/kcore's ELF header. No special knowledge necessary, any
> > elf-parser should be able to dump the values.
> >
> >
> >> Now the problem at hand is to determine the offset at which the
> >> pv_offset (key=value data pair) lies in the '/proc/kcore' (I assume
> >> that when you mentioned above and earlier about adding this pair to
> >> the elfnotes you meant both the vmcoreinfo and 'proc/kcore'), as we
> >> can have 'n' number of PT_LOAD segments.
> >
> > It looks like there is already a NOTE section with core info in there:
> > | # readelf -l /proc/kcore
> > |
> > | Elf file type is CORE (Core file)
> > | Entry point 0x0
> > | There are 16 program headers, starting at offset 64
> > |
> > | Program Headers:
> > | Type Offset VirtAddr PhysAddr
> > | FileSiz MemSiz Flags Align
> > | NOTE 0x00000000000003c0 0x0000000000000000 0x0000000000000000
> > | 0x0000000000001114 0x0000000000000000 0x0
> >
> > I assume we can add more notes without breaking the existing user...
> >
> > (and it looks like there are some broken __pa(kernel symbol) users in there.
>
> Thanks for your inputs.
>
> I am working on fixes on the above lines for kernel and user-space tools (like
> makedumpfile, crash-utility and kexec-tools).
>
> I will post some RFC patches on the same lines (or come back in case I get stuck
> somewhere) shortly.
>
> Thanks,
> Bhupesh
This email is intended only for the named addressee. It may contain information that is confidential/private, legally privileged, or copyright-protected, and you should handle it accordingly. If you are not the intended recipient, you do not have legal rights to retain, copy, or distribute this email or its contents, and should promptly delete the email and all electronic copies in your system; do not retain copies in any media. If you have received this email in error, please notify the sender promptly. Thank you.
^ permalink raw reply
* [PATCH v2] net: ethernet: stmmac: dwmac-rk: Add GMAC support for PX30
From: David Wu @ 2018-06-20 2:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2582999.2hZx6CH9S6@diego>
Hi Heiko,
? 2018?06?14? 16:30, Heiko St?bner ??:
> Am Donnerstag, 14. Juni 2018, 10:14:31 CEST schrieb David Wu:
>> Hi Heiko,
>>
>> ? 2018?06?14? 15:54, Heiko St?bner ??:
>>> I don't see that new clock documented in the dt-binding.
>>> Also, which clock from the clock-controller does this connect to?
>>
>> The clock is the "SCLK_GMAC_RMII" at the clock-controller, which could
>> be set rate by the link speed.
>
> Hmm, while these huge number of clocks are somewhat strange,
> shouldn't it be named something with _rmii instead of _speed then?
Okay, it is better to be named _speed.
>
> Also, I don't see any clk_enable action for that new clock, so you could
> end up with being off?
The new speed is the parent of the clk_tx_rx, to enable/disable
clk_tx_rx, the new clock would be also enabled/disabled.
>
> And someone could convert the driver to use the new clk-bulk APIs [0],
> so the large number of clk_prepare_enable calls would be a bit
> trimmed down.
>
>
> Heiko
>
> [0] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/clk/clk-bulk.c
>
>
>
>
>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox