The dwc2 driver has everything we need to run
in ACPI mode except for the ACPI module device table
boilerplate. With that added and identified as "BCM2848",
an id in use by other OSs for this device, the dw2
controller on the BCM2711 will work.
Signed-off-by: Jeremy Linton
---
driver
ges
v1->v2: Fix the kernel_ulong_t/set_parms() function typecasting
warning by explicitly doing the type cast.
Jeremy Linton (1):
usb: dwc2: Enable RPi in ACPI mode
drivers/usb/dwc2/core.h | 2 ++
drivers/usb/dwc2/params.c | 18 +-
drivers/usb/dwc2/platform.
The dwc2 driver has everything we need to run
in ACPI mode except for the ACPI module device table
boilerplate. With that added and identified as "BCM2848",
an id in use by other OSs for this device, the dw2
controller on the BCM2711 will work.
Signed-off-by: Jeremy Linton
---
driver
Hi,
On 3/2/21 5:56 AM, Sasha Levin wrote:
From: Jeremy Linton
[ Upstream commit 4f9833d3ec8da34861cd0680b00c73e653877eb9 ]
The RPi4 has an Arasan controller it carries over from the RPi3 and a newer
eMMC2 controller. Because of a couple of quirks, it seems wiser to bind
these controllers
Hi,
On 2/25/21 3:30 AM, Lorenzo Pieralisi wrote:
On Thu, Feb 18, 2021 at 12:43:30PM -0500, Jon Masters wrote:
Hi Bjorn, all,
On Thu, Jan 28, 2021 at 6:31 PM Bjorn Helgaas wrote:
On Tue, Jan 26, 2021 at 10:46:04AM -0600, Jeremy Linton wrote:
> Does that mean its open sea
Hi,
On 1/26/21 4:54 PM, Will Deacon wrote:
On Tue, Jan 26, 2021 at 10:46:04AM -0600, Jeremy Linton wrote:
On 1/22/21 1:48 PM, Will Deacon wrote:
This isn't like the usual fragmentation problems, where firmware swoops in
to save the day; CPU onlining, spectre mitigations, early entropy etc
Hi,
On 1/22/21 1:48 PM, Will Deacon wrote:
Hi Lorenzo,
On Fri, Jan 08, 2021 at 10:32:16AM +, Lorenzo Pieralisi wrote:
On Thu, Jan 07, 2021 at 04:05:48PM -0500, Jon Masters wrote:
On 1/7/21 1:14 PM, Will Deacon wrote:
On Mon, Jan 04, 2021 at 10:57:35PM -0600, Jeremy Linton wrote:
Given
gainst the ACPI table.
Adjust some function naming, and log messages.
Jeremy Linton (1):
arm64: PCI: Enable SMC conduit
arch/arm64/kernel/pci.c | 111 ++
include/linux/arm-smccc.h | 29 ++
2 files changed, 140 insertions(+)
--
2.26.2
Firmware Interface:
https://developer.arm.com/documentation/den0115/latest
Signed-off-by: Jeremy Linton
---
arch/arm64/kernel/pci.c | 111 ++
include/linux/arm-smccc.h | 29 ++
2 files changed, 140 insertions(+)
diff --git a/arch/arm64/kernel/pci.c b/arch
Hi,
On 1/13/21 4:40 PM, Jeremy Linton wrote:
Given that most arm64 platforms' PCI implementations need quirks
to deal with problematic config accesses, this is a good place
to apply a firmware abstraction. The ARM PCI Configuration Space
Access Firmware Interface specification details
the older Arasan and
BRCME88C describes the newer eMMC2. The older
Arasan is reusing an existing ACPI _HID used
by other OSs booting these tables on the RPi.
With this change, Linux is capable of utilizing the
SD card slot, and the wifi when booted with
UEFI+ACPI on the rpi4.
Signed-off-by: Jeremy
The rpi4 can be booted on Linux using ACPI, this set
adds the ACPI bindings to allow it to utilize the Arasan
and eMMC2 controllers.
v1->v2: Fix a build warning when !ACPI
Some comment/change log tweaks
Jeremy Linton (1):
mmc: sdhci-iproc: Add ACPI bindings for the rpi
drivers/
PM, Jeremy Linton wrote:
Given that most arm64 platforms' PCI implementations need quirks
to deal with problematic config accesses, this is a good place
to apply a firmware abstraction. The ARM PCI Configuration Space
Access Firmware Interface specification details a standard SMC
conduit desig
Firmware Interface:
https://developer.arm.com/documentation/den0115/latest
Signed-off-by: Jeremy Linton
---
arch/arm64/kernel/pci.c | 109 ++
include/linux/arm-smccc.h | 29 ++
2 files changed, 138 insertions(+)
diff --git a/arch/arm64/kernel/pci.c b/arch
Hi,
On 1/12/21 10:16 AM, Vidya Sagar wrote:
On 1/5/2021 10:27 AM, Jeremy Linton wrote:
External email: Use caution opening links or attachments
Given that most arm64 platform's PCI implementations needs quirks
to deal with problematic config accesses, this is a good place to
apply
Hi,
On 1/11/21 6:23 AM, Stefan Wahren wrote:
Hi,
Am 11.01.21 um 04:39 schrieb Jeremy Linton:
Hi,
On 1/9/21 5:07 AM, Stefan Wahren wrote:
Hi Jeremy,
+add Nicolas
Am 08.01.21 um 22:13 schrieb Jeremy Linton:
The rpi4 has a Arasan controller it carries over
from the rpi3, and a newer eMMC2
Hi,
On 1/9/21 5:07 AM, Stefan Wahren wrote:
Hi Jeremy,
+add Nicolas
Am 08.01.21 um 22:13 schrieb Jeremy Linton:
The rpi4 has a Arasan controller it carries over
from the rpi3, and a newer eMMC2 controller.
Because of a couple "quirks" it seems wiser to bind
these controllers t
submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url:
https://github.com/0day-ci/linux/commits/Jeremy-Linton/mmc-sdhci-iproc-Add-ACPI-bindings-for-the-rpi4/20210109-051645
base: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds
se BCM2847 for the older Arasan and BRCME88C
for the newer eMMC2.
With this change linux is capable of utilizing the
SD card slot, and the wifi on this platform
with linux.
Signed-off-by: Jeremy Linton
---
drivers/mmc/host/sdhci-iproc.c | 14 ++
1 file changed, 14 insertions(+)
diff --git
Hi,
On 1/7/21 11:36 AM, Rob Herring wrote:
On Thu, Jan 7, 2021 at 9:24 AM Jeremy Linton wrote:
Hi,
On 1/7/21 9:28 AM, Rob Herring wrote:
On Mon, Jan 4, 2021 at 9:57 PM Jeremy Linton wrote:
Given that most arm64 platform's PCI implementations needs quirks
to deal with problematic config
Hi,
On 1/7/21 12:14 PM, Will Deacon wrote:
On Mon, Jan 04, 2021 at 10:57:35PM -0600, Jeremy Linton wrote:
Given that most arm64 platform's PCI implementations needs quirks
to deal with problematic config accesses, this is a good place to
apply a firmware abstraction. The ARM PCI SMMCCC spec
Hi,
On 1/7/21 9:28 AM, Rob Herring wrote:
On Mon, Jan 4, 2021 at 9:57 PM Jeremy Linton wrote:
Given that most arm64 platform's PCI implementations needs quirks
to deal with problematic config accesses, this is a good place to
apply a firmware abstraction. The ARM PCI SMMCCC spec details
@
https://developer.arm.com/documentation/den0115/latest
Signed-off-by: Jeremy Linton
---
arch/arm64/kernel/pci.c | 87 +++
include/linux/arm-smccc.h | 26
2 files changed, 113 insertions(+)
diff --git a/arch/arm64/kernel/pci.c b/arch/arm64
Since we only need a single u64 the _array form is
unnecessarily. Use device_property_read_u64 instead.
Signed-off-by: Jeremy Linton
---
drivers/mmc/host/sdhci.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index
Hi,
On 11/24/20 8:51 AM, Adrian Hunter wrote:
On 24/11/20 4:25 pm, Ulf Hansson wrote:
On Sat, 21 Nov 2020 at 00:39, Jeremy Linton wrote:
The device_* calls were added a few years ago to abstract
DT/ACPI/fwnode firmware interfaces. Lets convert the two
sdhci caps fields to use the generic
.
Signed-off-by: Jeremy Linton
---
drivers/mmc/host/sdhci.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index 592a55a34b58..feba64fbde16 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
Hi,
On 11/5/20 6:55 AM, Ionela Voinescu wrote:
The cppc_cpudata per-cpu storage was inefficient (1) additional to causing
functional issues (2) when CPUs are hotplugged out, due to per-cpu data
being improperly initialised.
(1) The amount of information needed for CPPC performance control in
Hi,
On 11/4/20 9:20 AM, Mark Rutland wrote:
On Wed, Nov 04, 2020 at 11:55:57AM +0200, Topi Miettinen wrote:
On 4.11.2020 11.29, Florian Weimer wrote:
* Will Deacon:
Is there real value in this seccomp filter if it only looks at mprotect(),
or was it just implemented because it's easy to do
Hi,
On 11/4/20 4:50 AM, Mark Brown wrote:
On Tue, Nov 03, 2020 at 11:41:42PM -0600, Jeremy Linton wrote:
On 11/3/20 11:34 AM, Mark Brown wrote:
Given that there were still some ongoing discussions on a more robust
kernel interface here and there seem to be a few concerns with this
series
Hi,
On 11/3/20 11:34 AM, Mark Brown wrote:
On Tue, Nov 03, 2020 at 10:25:37AM +, Szabolcs Nagy wrote:
Re-mmap executable segments instead of mprotecting them in
case mprotect is seccomp filtered.
For the kernel mapped main executable we don't have the fd
for re-mmap so linux needs to
Hi,
On 10/26/20 12:52 PM, Dave Martin wrote:
On Mon, Oct 26, 2020 at 04:57:55PM +, Szabolcs Nagy via Libc-alpha wrote:
The 10/26/2020 16:24, Dave Martin via Libc-alpha wrote:
Unrolling this discussion a bit, this problem comes from a few sources:
1) systemd is trying to implement a
, with Ard's IORT patch. Nothing seems to have regressed.
Thanks,
Tested-by: Jeremy Linton
---
Changes since v3:
- Drop patch adding define in dma-mapping
- Address small review changes
- Update Ard's patch
- Add new patch removing examples from mmzone.h
Changes since v2:
- Introduce
On 10/8/20 2:43 PM, Ard Biesheuvel wrote:
(+ Lorenzo)
On Thu, 8 Oct 2020 at 12:14, Catalin Marinas wrote:
On Thu, Oct 08, 2020 at 12:05:25PM +0200, Nicolas Saenz Julienne wrote:
On Fri, 2020-10-02 at 12:55 +0100, Catalin Marinas wrote:
On Thu, Oct 01, 2020 at 07:31:19PM +0200, Nicolas
cryptomgr_test+0x38/0x60
Fixes: 0e89640b640d ("crypto: arm64 - Use modern annotations for assembly
functions")
Signed-off-by: Jeremy Linton
---
arch/arm64/crypto/aes-neonbs-core.S | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/crypto/aes-neonbs-core.S
b/
wrote:
On Mon, Oct 05, 2020 at 10:48:54PM -0500, Jeremy Linton wrote:
The AES code uses a 'br x7' as part of a function called by
a macro. That branch needs a bti_j as a target. This results
in a panic as seen below. Instead of trying to replace the branch
target with a bti_jc, lets replace
test_skcipher+0xbc/0x120
alg_test_skcipher+0xa0/0x1b0
alg_test+0x3dc/0x47c
cryptomgr_test+0x38/0x60
Fixes: commit 0e89640b640d ("crypto: arm64 - Use modern annotations for
assembly functions")
Signed-off-by: Jeremy Linton
---
arch/arm64/crypto/aes-neonbs-core.S | 6 +++---
1 fi
Hi,
On 10/5/20 2:59 PM, Mark Brown wrote:
On Mon, Oct 05, 2020 at 01:18:04PM -0500, Jeremy Linton wrote:
The AES code uses a 'br x7' as part of a function called by
a macro, that ends up needing a BTI_J as a target. Lets
define SYN_CODE_START_LOCAL() for this and replace
Hi,
On 10/5/20 1:54 PM, Ard Biesheuvel wrote:
On Mon, 5 Oct 2020 at 20:18, Jeremy Linton wrote:
The AES code uses a 'br x7' as part of a function called by
a macro, that ends up needing a BTI_J as a target.
Could we instead just drop the tail call, i.e, replace it with a ret
and do a 'bl
Signed-off-by: Jeremy Linton
---
arch/arm64/crypto/aes-neonbs-core.S | 8
arch/arm64/include/asm/linkage.h| 6 +-
2 files changed, 9 insertions(+), 5 deletions(-)
diff --git a/arch/arm64/crypto/aes-neonbs-core.S
b/arch/arm64/crypto/aes-neonbs-core.S
index b357164379f6..76de87ee8
a WARN_ON, which can be easily
triggered by the user on certain platforms, like :
I've tested it on 5.8 with "coresight: fix offset by one error in
counting ports" on the N1SDP and i'm getting traces, and not seeing any
further WARN's.
Thanks for looking into this!
Tested-by: Jer
further issue, but its unrelated to this.
So,
Tested-by: Jeremy Linton
also, might as well:
Reviewed-by: Jeremy Linton
On 8/13/20 5:04 AM, Mian Yousaf Kaukab wrote:
Since port-numbers start from 0, add 1 to port-number to get the port
count.
Fix following crash when Coresight is enabled on ACPI
Hi,
I have merged this to a 5.8 tree along with "dma-pool: Only allocate
from CMA when in the same memory zone" and tested it in various ACPI/DT
combinations, particularly on the RPI4. It seems to be working fine.
So thanks for your time and effort clearing this up!
Tested-
Hi,
I have merged this to a 5.8 tree along with "dma-pool: Fix atomic pool
selection" and tested it in various ACPI/DT combinations, particularly
on the RPI4. It seems to be working fine.
So thanks for your time and effort clearing this up!
tested-by: Jeremy Linton
On 7/10/
accessible memory while having the
flexibility of using dma_pool_kernel for the non constrained ones.
With the follow-on patch "dma-pool: Do not allocate pool memory from
CMA" everything seems to be working fine now.
tested-by: Jeremy Linton
Thanks for fixing this!
Fixes: c84dc6e6
o map to gfp
mask")
Reported-by: Jeremy Linton
Signed-off-by: Nicolas Saenz Julienne
---
With this patch and
https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg2226971.html
the machine appears to be working fine with/without CMA and in both
DT/ACPI mode.
The JBOD/etc I
Hi,
On 7/8/20 5:35 AM, Nicolas Saenz Julienne wrote:
Hi Jim,
On Tue, 2020-07-07 at 17:08 -0500, Jeremy Linton wrote:
Hi,
I spun this up on my 8G model using the PFTF firmware from:
https://github.com/pftf/RPi4/releases
Which allows me to switch between ACPI/DT on the machine. In DT mode
accessible memory while having the
flexibility of using dma_pool_kernel for the non constrained ones.
Fixes: c84dc6e68a1d ("dma-pool: add additional coherent pools to map to gfp
mask")
Reported-by: Jeremy Linton
Suggested-by: Robin Murphy
Signed-off-by: Nicolas Saenz Julienne
---
Hi,
Using 5.8rc3:
The rpi4 has a 3G dev->bus_dma_limit on its XHCI controller. With a usb3
hub, plus a few devices plugged in, randomly devices will fail
operations. This appears to because xhci_alloc_container_ctx() is
getting buffers > 3G via dma_pool_zalloc().
Tracking that down, it
of problem in the future.
But either way, this change looks fine too.
Reviewed-by: Jeremy Linton
Thanks,
Link: https://lore.kernel.org/lkml/20200521100952.GA5360@willie-the-truck/
Cc: sta...@vger.kernel.org
Reported-by: Will Deacon
Suggested-by: Ard Biesheuvel
Signed-off-by: Nick
Hi,
On 5/25/20 6:12 PM, Andrew Lunn wrote:
arch/powerpc/boot/dts/fsl/t4240rdb.dts: compatible = "ethernet-phy-id13e5.1002";
arch/powerpc/boot/dts/fsl/t4240rdb.dts: compatible = "ethernet-phy-id13e5.1002";
arch/powerpc/boot/dts/fsl/t4240rdb.dts: compatible = "ethernet-phy-id13e5.1002";
Hi,
On 5/25/20 6:33 PM, Russell King - ARM Linux admin wrote:
On Mon, May 25, 2020 at 06:22:19PM -0500, Jeremy Linton wrote:
On 5/25/20 6:09 PM, Russell King - ARM Linux admin wrote:
On Mon, May 25, 2020 at 05:22:07PM -0500, Jeremy Linton wrote:
On 5/25/20 5:01 PM, Russell King - ARM Linux
On 5/25/20 6:09 PM, Russell King - ARM Linux admin wrote:
On Mon, May 25, 2020 at 05:22:07PM -0500, Jeremy Linton wrote:
On 5/25/20 5:01 PM, Russell King - ARM Linux admin wrote:
On Mon, May 25, 2020 at 04:51:16PM -0500, Jeremy Linton wrote:
Hi,
On 5/25/20 5:06 AM, Russell King - ARM Linux
Hi,
On 5/25/20 5:01 PM, Russell King - ARM Linux admin wrote:
On Mon, May 25, 2020 at 04:51:16PM -0500, Jeremy Linton wrote:
Hi,
On 5/25/20 5:06 AM, Russell King - ARM Linux admin wrote:
On Sun, May 24, 2020 at 10:34:13PM -0500, Jeremy Linton wrote:
Hi,
On 5/23/20 1:37 PM, Russell King
On 5/25/20 5:01 PM, Russell King - ARM Linux admin wrote:
On Mon, May 25, 2020 at 04:51:16PM -0500, Jeremy Linton wrote:
Hi,
On 5/25/20 5:06 AM, Russell King - ARM Linux admin wrote:
On Sun, May 24, 2020 at 10:34:13PM -0500, Jeremy Linton wrote:
Hi,
On 5/23/20 1:37 PM, Russell King - ARM
Hi,
On 5/25/20 5:06 PM, Andrew Lunn wrote:
Yes, we know even for the NXP reference hardware, one of the phy's doesn't
probe out correctly because it doesn't respond to the ieee defined
registers. I think at this point, there really isn't anything we can do
about that unless we involve the
Hi,
On 5/25/20 3:25 AM, Russell King - ARM Linux admin wrote:
On Sun, May 24, 2020 at 11:28:52PM -0500, Jeremy Linton wrote:
Hi,
On 5/24/20 9:44 AM, Andrew Lunn wrote:
+++ b/include/linux/phy.h
@@ -275,6 +275,11 @@ struct mii_bus {
int reset_delay_us;
/* RESET GPIO descriptor
Hi,
On 5/25/20 4:07 PM, Russell King - ARM Linux admin wrote:
On Mon, May 25, 2020 at 04:02:13PM -0500, Jeremy Linton wrote:
So, I think you're going to have to add a work-around to ignore bit 0,
which brings up the question whether this is worth it or not.
It does ignore bit 0, it gets
Hi,
On 5/25/20 5:06 AM, Russell King - ARM Linux admin wrote:
On Sun, May 24, 2020 at 10:34:13PM -0500, Jeremy Linton wrote:
Hi,
On 5/23/20 1:37 PM, Russell King - ARM Linux admin wrote:
On Fri, May 22, 2020 at 04:30:52PM -0500, Jeremy Linton wrote:
Until this point, we have been sanitizing
Hi,
On 5/25/20 4:45 AM, Russell King - ARM Linux admin wrote:
On Sun, May 24, 2020 at 09:46:55PM -0500, Jeremy Linton wrote:
Hi,
Thanks for taking a look at this.
On 5/23/20 1:20 PM, Russell King - ARM Linux admin wrote:
On Fri, May 22, 2020 at 04:30:49PM -0500, Jeremy Linton wrote:
C45
Hi,
On 5/24/20 9:44 AM, Andrew Lunn wrote:
+++ b/include/linux/phy.h
@@ -275,6 +275,11 @@ struct mii_bus {
int reset_delay_us;
/* RESET GPIO descriptor pointer */
struct gpio_desc *reset_gpiod;
+ /* bus capabilities, used for probing */
+ enum {
+
Hi,
On 5/23/20 1:44 PM, Russell King - ARM Linux admin wrote:
On Fri, May 22, 2020 at 04:30:55PM -0500, Jeremy Linton wrote:
MMD's in the device list sometimes return 0 for their id.
When that happens lets reset the id back to 0xfff so
that we don't get a stub device created
Hi,
On 5/23/20 1:37 PM, Russell King - ARM Linux admin wrote:
On Fri, May 22, 2020 at 04:30:52PM -0500, Jeremy Linton wrote:
Until this point, we have been sanitizing the c22
regs presence bit out of all the MMD device lists.
This is incorrect as it causes the 0x checks
to incorrectly
Hi,
On 5/23/20 1:36 PM, Russell King - ARM Linux admin wrote:
On Fri, May 22, 2020 at 04:30:50PM -0500, Jeremy Linton wrote:
Since we are already checking for *devs == 0 after
the loop terminates, we can add a mostly F's check
as well. With that change we can simplify the return/break
sequence
Hi,
Thanks for taking a look at this.
On 5/23/20 1:20 PM, Russell King - ARM Linux admin wrote:
On Fri, May 22, 2020 at 04:30:49PM -0500, Jeremy Linton wrote:
C45 devices are to return 0 for registers they haven't
implemented. This means in theory we can terminate the
device search loop
Hi,
On 5/23/20 3:01 PM, Russell King - ARM Linux admin wrote:
On Sat, May 23, 2020 at 09:51:31PM +0200, Andrew Lunn wrote:
static int get_phy_c45_ids(struct mii_bus *bus, int addr, u32 *phy_id,
struct phy_c45_device_ids *c45_ids) {
- int phy_reg;
- int
Hi,
On 5/23/20 10:28 AM, Andrew Lunn wrote:
On Fri, May 22, 2020 at 04:30:51PM -0500, Jeremy Linton wrote:
Lets factor out the phy id logic, and make it generic
so that it can be used for c22 and c45.
Signed-off-by: Jeremy Linton
---
drivers/net/phy/phy_device.c | 65
Hi,
Thanks for taking a look at this!
On 5/23/20 10:28 AM, Andrew Lunn wrote:
On Fri, May 22, 2020 at 04:30:51PM -0500, Jeremy Linton wrote:
Lets factor out the phy id logic, and make it generic
so that it can be used for c22 and c45.
Signed-off-by: Jeremy Linton
---
drivers/net/phy
at this location and we should
be accessing it using c22.
Signed-off-by: Jeremy Linton
---
drivers/net/phy/phy_device.c | 16 +---
1 file changed, 13 insertions(+), 3 deletions(-)
diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c
index f0761fa5e40b..2d677490ecab 100644
Since we know the xgmac hardware always has a c45
complaint bus, lets try scanning for c45 capable
phys first. If we fail to find any, then it with
fall back to c22 automatically.
Signed-off-by: Jeremy Linton
---
drivers/net/ethernet/freescale/xgmac_mdio.c | 1 +
1 file changed, 1 insertion
Lets factor out the phy id logic, and make it generic
so that it can be used for c22 and c45.
Signed-off-by: Jeremy Linton
---
drivers/net/phy/phy_device.c | 65 +++-
1 file changed, 35 insertions(+), 30 deletions(-)
diff --git a/drivers/net/phy/phy_device.c b
at the bottom.
Signed-off-by: Jeremy Linton
---
drivers/net/phy/phy_device.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c
index ac2784192472..245899b58a7d 100644
--- a/drivers/net/phy/phy_device.c
+++ b/drivers/net/phy
, we don't really have a good way to match
them, and since it hasn't been working I think its perfectly
reasonable at this point to expect phy's to implement enough
of the standard that we can detect them and attach a phy
specific driver.
Signed-off-by: Jeremy Linton
---
drivers/net/phy/phy_de
.
Or we just ignore it and accept that the probe logic as it
stands potentially creates bogus phy devices, to avoid the
case where an actual phy exists but isn't responding correctly.
Signed-off-by: Jeremy Linton
---
drivers/net/phy/phy_device.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion
0x) we are just going to ignore anything
that doesn't look like a valid return.
Signed-off-by: Jeremy Linton
---
drivers/net/phy/phy_device.c | 8 +++-
include/linux/phy.h | 2 +-
2 files changed, 4 insertions(+), 6 deletions(-)
diff --git a/drivers/net/phy/phy_device.c b/drivers
.
At the moment its a yes/no option, but in the future
it may be useful to extend this to c45 only policy, or
add additional classes and policies.
Signed-off-by: Jeremy Linton
---
drivers/net/phy/mdio_bus.c | 9 +++--
include/linux/phy.h| 5 +
2 files changed, 12 insertions(+), 2
Default initializing the phy_id to "invalid" allows
us to avoid setting it on the error returns.
Signed-off-by: Jeremy Linton
---
drivers/net/phy/phy_device.c | 10 --
1 file changed, 4 insertions(+), 6 deletions(-)
diff --git a/drivers/net/phy/phy_device.c b/drive
fully compliant MDIO/PHY
combinations or are we ok with extra stub devices? The 3rd to last
set is just using the C45_FIRST flag for it.
What have I missed?
Jeremy Linton (11):
net: phy: Don't report success if devices weren't found
net: phy: Simplify MMD device list termination
net: p
-by: Jeremy Linton
---
drivers/net/phy/phy_device.c | 15 +++
1 file changed, 7 insertions(+), 8 deletions(-)
diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c
index 245899b58a7d..7746c07b97fe 100644
--- a/drivers/net/phy/phy_device.c
+++ b/drivers/net/phy/phy_device.c
Signed-off-by: Jeremy Linton
---
drivers/net/ethernet/freescale/xgmac_mdio.c | 27 +
1 file changed, 17 insertions(+), 10 deletions(-)
diff --git a/drivers/net/ethernet/freescale/xgmac_mdio.c
b/drivers/net/ethernet/freescale/xgmac_mdio.c
index c82c85ef5fb3..96ee3bd89983
Hi,
On 5/14/20 12:00 PM, Jeremy Linton wrote:
The commit "disregard Clause 22 registers present bit..." clears
the low bit of the devices_in_package data which is being used
in get_phy_c45_ids() to determine if a phy/register is responding
correctly. That check is against 0x1FFF,
Hi,
On 5/14/20 2:59 PM, Heiner Kallweit wrote:
On 14.05.2020 19:00, Jeremy Linton wrote:
The commit "disregard Clause 22 registers present bit..." clears
the low bit of the devices_in_package data which is being used
in get_phy_c45_ids() to determine if a phy/register is responding
("net: phy: disregard "Clause 22 registers present" bit in
get_phy_c45_devs_in_pkg")
Cc: Heiner Kallweit
Signed-off-by: Jeremy Linton
---
drivers/net/phy/phy_device.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/phy/phy_device.c b/driv
-by: Jeremy Linton
I'm testing it now...
Thanks,
On 5/14/20 6:27 AM, Greg Kroah-Hartman wrote:
In commit 2bef9aed6f0e ("usb: usbfs: correct kernel->user page attribute
mismatch") we switched from always calling remap_pfn_range() to call
dma_mmap_coherent() to handle issues
On 5/14/20 2:46 AM, Greg KH wrote:
On Thu, May 14, 2020 at 08:31:58AM +0200, Christoph Hellwig wrote:
On Thu, May 14, 2020 at 08:27:50AM +0200, Greg KH wrote:
On Thu, May 14, 2020 at 08:14:17AM +0200, Christoph Hellwig wrote:
Guys, can you please start formal thread on this? I have no
idea
On 5/14/20 6:14 AM, Christoph Hellwig wrote:
On Thu, May 14, 2020 at 06:10:03AM -0500, Jeremy Linton wrote:
I only need to look at the commit for 3 seconds to tell you that it is
completely buggy. While using dma_mmap_coherent is fundamentally the
right thing and absolutely required
Hi,
On 5/14/20 1:31 AM, Christoph Hellwig wrote:
On Thu, May 14, 2020 at 08:27:50AM +0200, Greg KH wrote:
On Thu, May 14, 2020 at 08:14:17AM +0200, Christoph Hellwig wrote:
Guys, can you please start formal thread on this? I have no
idea where this came from and what the rationale is. Btw,
://syzkaller.appspot.com/x/repro.c?x=119f378810
The bug was bisected to:
commit 2bef9aed6f0e22391c8d4570749b1acc9bc3981e
Author: Jeremy Linton
Date: Mon May 4 20:13:48 2020 +
usb: usbfs: correct kernel->user page attribute mismatch
bisection log: https://syzkaller.appspot.com/x/bisect.tx
On 5/8/20 6:42 PM, Andrew Lunn wrote:
On Fri, May 08, 2020 at 05:48:33PM -0500, Jeremy Linton wrote:
Hi,
On 5/8/20 3:27 PM, Andrew Lunn wrote:
There is a very small number of devices where the vendor messed up,
and did not put valid contents in the ID registers. In such cases, we
can read
Hi,
On 5/8/20 3:27 PM, Andrew Lunn wrote:
There is a very small number of devices where the vendor messed up,
and did not put valid contents in the ID registers. In such cases, we
can read the IDs from device tree. These are then used in exactly the
same way as if they were read from the
Hi,
On 5/8/20 1:13 PM, Andrew Lunn wrote:
It does have a numeric version defined for EISA types. OTOH I suspect that
your right. If there were a "PHY\VEN_ID_" definition, it may not
be ideal to parse it. Instead the normal ACPI model of exactly matching the
complete string in the phy
Hi,
On 5/7/20 12:27 PM, Andy Shevchenko wrote:
On Thu, May 7, 2020 at 4:26 PM Jeremy Linton wrote:
On 5/5/20 8:29 AM, Calvin Johnson wrote:
+ if (sscanf(cp, "ethernet-phy-id%4x.%4x",
+, ) == 2) {
+ *phy_id = ((upper &
Hi,
On 5/5/20 8:29 AM, Calvin Johnson wrote:
Extract phy_id from compatible string. This will be used by
fwnode_mdiobus_register_phy() to create phy device using the
phy_id.
Signed-off-by: Calvin Johnson
---
Changes in v3: None
Changes in v2: None
drivers/net/phy/phy_device.c | 21
cache/etc attributes will then be correctly set in
userspace to match the kernel mapping.
Signed-off-by: Jeremy Linton
---
v1->v2:
Update commit message and change to dma_mmap_coherent()
from dma_mmap_attr(,,,0) which are the same.
drivers/usb/core/devio.c | 5 ++---
1 file chan
Hi,
On 5/4/20 2:13 AM, Greg KH wrote:
On Fri, May 01, 2020 at 10:47:22AM -0500, Jeremy Linton wrote:
Hi,
Thanks for taking a look at this.
On 5/1/20 2:05 AM, Greg KH wrote:
On Thu, Apr 30, 2020 at 04:19:22PM -0500, Jeremy Linton wrote:
On arm64, and possibly other architectures, requesting
Hi,
Thanks for taking a look at this.
On 5/1/20 2:05 AM, Greg KH wrote:
On Thu, Apr 30, 2020 at 04:19:22PM -0500, Jeremy Linton wrote:
On arm64, and possibly other architectures, requesting
IO coherent memory may return Normal-NC if the underlying
hardware isn't coherent. If these pages
the
kernel and userspace.
Signed-off-by: Jeremy Linton
---
drivers/usb/core/devio.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/core/devio.c b/drivers/usb/core/devio.c
index 6833c918abce..1e7458dd6e5d 100644
--- a/drivers/usb/core/devio.c
+++ b/drivers
Hi,
On 10/11/19 8:54 AM, Mark Rutland wrote:
On Fri, Oct 11, 2019 at 02:33:43PM +0100, Marc Zyngier wrote:
On Fri, 11 Oct 2019 11:50:11 +0100
Mark Rutland wrote:
Hi,
On Fri, Oct 11, 2019 at 11:19:00AM +0530, Sai Prakash Ranjan wrote:
On latest QCOM SoCs like SM8150 and SC7180 with
Hi,
First thanks for posting this!
I ran this on our DAWN platform and it does what it says. Its a pretty
reasonable start, but I get -1's in the command row rather than "dd" (or
similar) and this also results in [unknown] for the shared object and
most userspace addresses. This is quite
Hi,
On 6/19/19 4:15 AM, John Garry wrote:
On 18/06/2019 22:28, Jeremy Linton wrote:
Hi,
On 6/18/19 12:23 PM, John Garry wrote:
On 18/06/2019 15:40, Valentin Schneider wrote:
On 18/06/2019 15:21, Jeremy Linton wrote:
[...]
+ * Return: -ENOENT if the PPTT doesn't exist, the CPU cannot
need to add a bit of extra code to verify the table revision,
and the next node's state in the traversal. Since we want to
avoid function pointers here, lets just special case
the IDENTICAL flag.
Tested-by: Hanjun Gou
Reviewed-by: Sudeep Holla
Signed-off-by: Jeremy Linton
---
drivers/acpi
1 - 100 of 828 matches
Mail list logo
