On 13/03/23 21:16, Eric DeVolder wrote:
On 3/12/23 13:11, Sourabh Jain wrote:
Due to CPU/Memory hotplug events the system resources changes. A similar
change should reflect in the loaded kdump kernel image that describes
the state of the CPU and memory of the running kernel.
If the kdump ke
On 13/03/23 21:55, Laurent Dufour wrote:
On 12/03/2023 19:11:51, Sourabh Jain wrote:
A new member "fdt_index" is added to the kimage_arch struct to hold
the index of the FDT (Flattened Device Tree) segment from the kexec
the segment array.
fdt_index will provide direct access to the FDT segme
> -Original Message-
> From: Rob Herring
> Sent: 2023年3月10日 22:47
> To: Wolfgang Grandegger ; Marc Kleine-Budde
> ; David S. Miller ; Eric
> Dumazet ; Jakub Kicinski ; Paolo
> Abeni ; Nicolas Ferre ;
> Claudiu Beznea ; Wei Fang
> ; Shenwei Wang ; Clark Wang
> ; dl-linux-imx ; Claudiu
> Man
On 13/03/23 21:48, Laurent Dufour wrote:
On 12/03/2023 19:11:49, Sourabh Jain wrote:
Move update_cpus_node and get_crash_memory_ranges functions from
kexec/file_load.c to kexec/core_64.c to make these functions usable
file_load_64.c
by other kexec compoenets.
comp
Hello Eric,
On 13/03/23 21:12, Eric DeVolder wrote:
On 3/12/23 13:11, Sourabh Jain wrote:
The Problem:
Post hotplug/DLPAR events the capture kernel holds stale information
about the
system. Dump collection with stale capture kernel might end up in
dump capture
failure or an in
Hi,
I tested this patch on an existing laptop which uses SPI with a GPIO
Chipselect,
(HP EliteBook 860 G9), and I get the error:
[2.671655] pxa2xx-spi pxa2xx-spi.2: chipselect 1 already in use
[2.671711] spi_master spi0: error -EBUSY: failed to add SPI device
CSC3551:00 from ACPI
[2.6
On Mon, 06 Mar 2023 22:50:54 +0530, Amit Kumar Mahapatra wrote:
> This patch is in the continuation to the discussions which happened on
> 'commit f89504300e94 ("spi: Stacked/parallel memories bindings")' for
> adding dt-binding support for stacked/parallel memories.
>
> This patch series updated
On Mon, Mar 13, 2023 at 9:53 AM Leonard, Niall wrote:
> > Niall are you sending a v3 of this patch soon?
> > Include Sean on the reviewer list!
> I never got around to working on the V3 patch. The hold up for me was
> the changes to the bindings.
> I'm now wondering if I should wait on Sean's pa
On Mon, Mar 13, 2023 at 11:02:34PM +0100, Michal Suchánek wrote:
> On Mon, Mar 13, 2023 at 10:53:34PM +0100, Andrea Righi wrote:
> > On Mon, Mar 13, 2023 at 10:48:53PM +0100, Michal Suchánek wrote:
> > > Hello,
> > >
> > > On Mon, Mar 13, 2023 at 09:32:16PM +0100, Andrea Righi wrote:
> > > > On We
On Mon, Mar 13, 2023 at 10:53:34PM +0100, Andrea Righi wrote:
> On Mon, Mar 13, 2023 at 10:48:53PM +0100, Michal Suchánek wrote:
> > Hello,
> >
> > On Mon, Mar 13, 2023 at 09:32:16PM +0100, Andrea Righi wrote:
> > > On Wed, Jan 11, 2023 at 04:11:51PM +, Gary Guo wrote:
> > > > Currently modver
On Mon, Mar 13, 2023 at 10:48:53PM +0100, Michal Suchánek wrote:
> Hello,
>
> On Mon, Mar 13, 2023 at 09:32:16PM +0100, Andrea Righi wrote:
> > On Wed, Jan 11, 2023 at 04:11:51PM +, Gary Guo wrote:
> > > Currently modversion uses a fixed size array of size (64 - sizeof(long))
> > > to store sy
Hello,
On Mon, Mar 13, 2023 at 09:32:16PM +0100, Andrea Righi wrote:
> On Wed, Jan 11, 2023 at 04:11:51PM +, Gary Guo wrote:
> > Currently modversion uses a fixed size array of size (64 - sizeof(long))
> > to store symbol names, thus placing a hard limit on length of symbols.
> > Rust symbols
On Mon, Mar 13, 2023 at 5:12 PM Sean Anderson wrote:
> This is a generic binding for simple MMIO GPIO controllers. Although we
> have a single driver for these controllers, they were previously spread
> over several files. Consolidate them. The register descriptions are
> adapted from the comment
On Wed, Jan 11, 2023 at 04:11:51PM +, Gary Guo wrote:
> Currently modversion uses a fixed size array of size (64 - sizeof(long))
> to store symbol names, thus placing a hard limit on length of symbols.
> Rust symbols (which encodes crate and module names) can be quite a bit
> longer. The length
Direct access to the struct bus_type dev_root pointer is going away soon
so replace that with a call to bus_get_dev_root() instead, which is what
it is there for.
Cc: Michael Ellerman
Cc: Nicholas Piggin
Cc: Christophe Leroy
Cc: Greg Kroah-Hartman
Cc: linuxppc-dev@lists.ozlabs.org
Signed-off-b
Direct access to the struct bus_type dev_root pointer is going away soon
so replace that with a call to bus_get_dev_root() instead, which is what
it is there for.
Cc: Michael Ellerman
Cc: Nicholas Piggin
Cc: Christophe Leroy
Cc: Wolfram Sang
Cc: Joel Stanley
Cc: Liang He
Cc: Greg Kroah-Hartm
Direct access to the struct bus_type dev_root pointer is going away soon
so replace that with a call to bus_get_dev_root() instead, which is what
it is there for.
Cc: Michael Ellerman
Cc: Nicholas Piggin
Cc: Christophe Leroy
Cc: Greg Kroah-Hartman
Cc: linuxppc-dev@lists.ozlabs.org
Signed-off-b
Direct access to the struct bus_type dev_root pointer is going away soon
so replace that with a call to bus_get_dev_root() instead, which is what
it is there for.
Cc: Michael Ellerman
Cc: Nicholas Piggin
Cc: Christophe Leroy
Cc: David Hildenbrand
Cc: Andrew Morton
Cc: linuxppc-dev@lists.ozlab
On 12/03/2023 19:11:51, Sourabh Jain wrote:
> A new member "fdt_index" is added to the kimage_arch struct to hold
> the index of the FDT (Flattened Device Tree) segment from the kexec
> the segment array.
>
> fdt_index will provide direct access to the FDT segment in the kexec
> segment array afte
On 12/03/2023 19:11:49, Sourabh Jain wrote:
> Move update_cpus_node and get_crash_memory_ranges functions from
> kexec/file_load.c to kexec/core_64.c to make these functions usable
file_load_64.c
> by other kexec compoenets.
components
>
> Later in the series, these functi
The internal PCSs are not always accessible during boot (such as if the
serdes has deselected the appropriate link mode). Give them appropriate
compatible strings so they don't automatically (fail to) probe as
genphys.
Signed-off-by: Sean Anderson
---
(no changes since v8)
Changes in v8:
- New
This adds serdes support to the LS1088ARDB. I have tested the QSGMII
ports as well as the two 10G ports. The SFP slot is now fully supported,
instead of being modeled as a fixed-link.
Linux hangs around when the serdes is initialized if the si5341 is
enabled with the in-tree driver, so I have mode
This adds appropriate descriptions for the macs which use the SerDes. The
156.25MHz fixed clock is a crystal. The 100MHz clocks (there are
actually 3) come from a Renesas 6V49205B at address 69 on i2c0. There is
no driver for this device (and as far as I know all you can do with the
100MHz clocks i
The next few patches will break ethernet if the serdes is not enabled,
so enable the serdes driver by default on Layerscape.
Signed-off-by: Sean Anderson
---
(no changes since v10)
Changes in v10:
- New
drivers/phy/freescale/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/
This adds support for the Lynx 10G "SerDes" devices found on various NXP
QorIQ SoCs. There may be up to four SerDes devices on each SoC, each
supporting up to eight lanes. Protocol support for each SerDes is highly
heterogeneous, with each SoC typically having a totally different
selection of suppo
This adds nodes for the SerDes devices. They are disabled by default
to prevent any breakage on existing boards.
Signed-off-by: Sean Anderson
---
(no changes since v10)
Changes in v10:
- Move serdes bindings to SoC dtsi
- Add support for all (ethernet) serdes modes
- Refer to "nodes" instead of
This adds support for the PLLs found in Lynx 10G "SerDes" devices found on
various NXP QorIQ SoCs. There are two PLLs in each SerDes. This driver has
been split from the main PHY driver to allow for better review, even though
these PLLs are not present anywhere else besides the SerDes. An auxiliary
This adds nodes for the SerDes devices. They are disabled by default
to prevent any breakage on existing boards.
Signed-off-by: Sean Anderson
---
(no changes since v10)
Changes in v10:
- Move serdes bindings to SoC dtsi
- Add support for all (ethernet) serdes modes
- Refer to "nodes" instead of
This adds some modes necessary for Lynx 10G support. 2500BASE-X, also
known as 2.5G SGMII, is 1000BASE-X/SGMII overclocked to 3.125 GHz, with
autonegotiation disabled. 10GBASE-R, also known as XFI, is the protocol
spoken between the PMA and PMD ethernet layers for 10GBASE-T and
10GBASE-S/L/E. It is
NXP has a "QIXIS" FPGA on several of their reference design boards. On
the LS1088ARDB there are several registers which control GPIOs. These
can be modeled with the MMIO GPIO driver.
Signed-off-by: Sean Anderson
Reviewed-by: Rob Herring
---
(no changes since v10)
Changes in v10:
- New
.../de
This is a generic binding for simple MMIO GPIO controllers. Although we
have a single driver for these controllers, they were previously spread
over several files. Consolidate them. The register descriptions are
adapted from the comments in the source. There is no set order for the
registers, so I
This adds a binding for the SerDes module found on QorIQ processors.
Each phy is a subnode of the top-level device, possibly supporting
multiple lanes and protocols. This "thick" #phy-cells is used due to
allow for better organization of parameters. Note that the particular
parameters necessary to
This adds support for the Lynx 10G SerDes found on the QorIQ T-series
and Layerscape series. Due to limited time and hardware, only support
for the LS1046ARDB and LS1088ARDB is added in this initial series.
This series is ready for review by the phy maintainers. I have addressed
all known feedback
This adds ids for the Lynx 10g SerDes's internal PLLs. These may be used
with assigned-clock* to specify a particular frequency to use. For
example, to set the second PLL (at offset 0x20)'s frequency, use
LYNX10G_PLLa(1). These are for use only in the device tree, and are not
otherwise used by the
On 3/11/2023 12:41 AM, Uwe Kleine-König wrote:
Hello,
many bus remove functions return an integer which is a historic
misdesign that makes driver authors assume that there is some kind of
error handling in the upper layers. This is wrong however and returning
and error code only yields an err
On 3/12/23 13:11, Sourabh Jain wrote:
Due to CPU/Memory hotplug events the system resources changes. A similar
change should reflect in the loaded kdump kernel image that describes
the state of the CPU and memory of the running kernel.
If the kdump kernel image is not updated after the CPU or
On 3/12/23 13:11, Sourabh Jain wrote:
The Problem:
Post hotplug/DLPAR events the capture kernel holds stale information about the
system. Dump collection with stale capture kernel might end up in dump capture
failure or an inaccurate dump collection.
Existing solution:
==
On Mon, Mar 13, 2023 at 11:36:44AM +0100, Uwe Kleine-König wrote:
> Hello,
>
> this patch set converts the platform drivers below
> drivers/net/ethernet/freescale to the .remove_new() callback. Compared to the
> traditional .remove() this one returns void. This is a good thing because the
> driver
On 09/03/2023 09:16, Linus Walleij wrote:
> *External Message* - Use caution before opening links or attachments
>
> On Tue, Mar 7, 2023 at 4:35 PM Sean Anderson wrote:
>> On 3/7/23 03:42, Krzysztof Kozlowski wrote:
>
>>> https://urldefense.com/v3/__https://lore.kernel.org/all/20230126-gpio-mmio
On 3/13/23 04:53, Leonard, Niall wrote:
> [You don't often get email from niall.leon...@ncr.com. Learn why this is
> important at https://aka.ms/LearnAboutSenderIdentification ]
>
> On 09/03/2023 09:16, Linus Walleij wrote:
>> *External Message* - Use caution before opening links or attachments
>
On Fri, Mar 10, 2023 at 11:41:22PM +0100, Uwe Kleine-König wrote:
> Hello,
>
> many bus remove functions return an integer which is a historic
> misdesign that makes driver authors assume that there is some kind of
> error handling in the upper layers. This is wrong however and returning
> and err
I'm triggering the following bug when booting my qemu powerpc VM:
event-sources: Unable to request interrupt 23 for /event-sources/hot-plug-events
WARNING: CPU: 0 PID: 1 at arch/powerpc/platforms/pseries/event_sources.c:26
request_event_sources_irqs+0xbc/0xf0
Modules linked in:
CPU: 0 PID: 1 Comm
Il 10/03/23 15:47, Rob Herring ha scritto:
It is preferred to use typed property access functions (i.e.
of_property_read_ functions) rather than low-level
of_get_property/of_find_property functions for reading properties. As
part of this, convert of_get_property/of_find_property calls to the
rece
> -Original Message-
> From: Uwe Kleine-König
> Sent: 13 March 2023 12:37
> To: Madalin Bucur ; David S. Miller
> ; Eric Dumazet ; Jakub Kicinski
> ; Paolo Abeni ; Russell King
> ; Wei Fang ; Wolfram Sang
> ; Chris Packham ; Andy
> Shevchenko ; Damien Le Moal
> ; Christophe Leroy
> ; Micha
Hello,
this patch set converts the platform drivers below
drivers/net/ethernet/freescale to the .remove_new() callback. Compared to the
traditional .remove() this one returns void. This is a good thing because the
driver core (mostly) ignores the return value and still removes the device
binding.
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is (mostly) ignored
and this typically results in resource leaks. To improve here there is a
quest to
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is (mostly) ignored
and this typically results in resource leaks. To improve here there is a
quest to
On 10/03/2023 at 15:47, Rob Herring wrote:
EXTERNAL EMAIL: Do not click links or open attachments unless you know the
content is safe
It is preferred to use typed property access functions (i.e.
of_property_read_ functions) rather than low-level
of_get_property/of_find_property functions for re
Hi,
On Fri, 10 Mar 2023 at 18:37, Amit Kumar Mahapatra
wrote:
>
> For supporting multiple CS the SPI device need to be aware of all the CS
> values. So, the "chip_select" member in the spi_device structure is now an
> array that holds all the CS values.
>
> spi_device structure now has a "cs_inde
49 matches
Mail list logo
