Re: [PATCH v9 2/6] powerpc/crash: introduce a new config option CRASH_HOTPLUG
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 kernel image is not updated after the CPU or Memory hotplug events and it tries to collect the dump with the stale system resource data this might lead to dump collection failure or an inaccurate dump collection. The current method to keep the kdump kernel up to date is by triggering reload (i.e unload and load) the entire kdump kernel image whenever a CPU or Memory hotplug event is observed by udev in the userspace. Reloading the complete kdump kernel image is an expensive task. It can be easily avoided by doing the in-kernel updates to specific kdump kernel image components which are responsible for describing CPU and Memory resources of the running kernel to the kdump kernel. The kernel changes related to in-kernel update to the kdump kernel image on CPU/Memory hotplug events are kept under the CRASH_HOTPLUG config option. Later in the series, a powerpc crash hotplug handler is introduced to update the kdump kernel image on CPU/Memory hotplug events. This arch specific handler is trigger from a generic crash handler that registers with the CPU and memory notifiers. The CRASH_HOTPLUG config option is enabled by default. Signed-off-by: Sourabh Jain --- arch/powerpc/Kconfig | 12 1 file changed, 12 insertions(+) diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig index a6c4407d3ec83..2f45b3f5175cb 100644 --- a/arch/powerpc/Kconfig +++ b/arch/powerpc/Kconfig @@ -681,6 +681,18 @@ config CRASH_DUMP The same kernel binary can be used as production kernel and dump capture kernel. +config CRASH_HOTPLUG + bool "Update crash capture system on CPU/Memory hotplug event" Fwiw, online/offline changes also flow through this infrastructure... eric Yes I will update the CONFIG summary and commit message to convey the same. Thanks for the review. Thanks, Sourabh Jain
Re: [PATCH v9 3/6] powerpc/crash: add a new member to the kimage_arch struct
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 segment in the kexec
segment array after the kdump kernel is loaded.
The new attribute will be used in the arch crash hotplug handler
(added in upcoming patches) on every CPU and memory hotplug event.
The fdt_index is populated for both kexec_load and kexec_file_load
case.
Signed-off-by: Sourabh Jain
---
arch/powerpc/include/asm/kexec.h | 5 +
arch/powerpc/kexec/core_64.c | 31 +++
2 files changed, 36 insertions(+)
diff --git a/arch/powerpc/include/asm/kexec.h b/arch/powerpc/include/asm/kexec.h
index 8090ad7d97d9d..348eb96e8ca67 100644
--- a/arch/powerpc/include/asm/kexec.h
+++ b/arch/powerpc/include/asm/kexec.h
@@ -103,6 +103,8 @@ void kexec_copy_flush(struct kimage *image);
struct crash_mem;
int update_cpus_node(void *fdt);
int get_crash_memory_ranges(struct crash_mem **mem_ranges);
+int machine_kexec_post_load(struct kimage *image);
+#define machine_kexec_post_load machine_kexec_post_load
Minor comment, when CONFIG_CRASH_HOTPLUG is not set the function is simply
returning 0, why not defining it has an inline in that case?
We can, but if the initialization of fdt_index is taken care during the
allocation
of kimage struct, I will move the fdt_index discovery logic to arch crash
hotplug handler. More on fdt_index initialization in the next comment.
#endif
#if defined(CONFIG_CRASH_DUMP) && defined(CONFIG_PPC_RTAS)
@@ -118,6 +120,9 @@ extern const struct kexec_file_ops kexec_elf64_ops;
struct kimage_arch {
struct crash_mem *exclude_ranges;
+#if defined(CONFIG_CRASH_HOTPLUG)
+ int fdt_index;
+#endif
unsigned long backup_start;
void *backup_buf;
void *fdt;
diff --git a/arch/powerpc/kexec/core_64.c b/arch/powerpc/kexec/core_64.c
index 0b292f93a74cc..531486c973988 100644
--- a/arch/powerpc/kexec/core_64.c
+++ b/arch/powerpc/kexec/core_64.c
@@ -77,6 +77,37 @@ int machine_kexec_prepare(struct kimage *image)
return 0;
}
+int machine_kexec_post_load(struct kimage *kimage)
+{
+#if defined(CONFIG_CRASH_HOTPLUG)
+ int i;
+ void *ptr;
+ unsigned long mem;
+
+ /* Mark fdt_index invalid */
+ kimage->arch.fdt_index = -1;
Why is that not done in the series introducing the generic
crash hotplug update, in do_kimage_alloc_init() ?
do_kimage_alloc_init is a generic function where as fdt_index is a ppc
specific
attribute. If fdt_index is initialized in do_kimage_alloc_init then
other architectures
will have build issues.
This way there is a guarantee that the field will not be used while set by
default to 0.
I agree that until the kernel hits the machine_kexec_post_load function
on the
kdump kernel load path there is no way to identify the fdt_index is holding
a valid index or not.
Since there is no consumer of kimage's fdt_index attribute from the
point of its
allocation to until it is initialized, we don't have any impact of
fdt_index holding
value 0 (which is not valid) for sometime.
But still we can do few things to allow fdt_index attribute consumers to
check
the sanity of fdt_index.
1. Introduce arch specific function call to initialize kimage_arch
struct (basically fdt_index for now).
and call it inside do_kimage_alloc_init and initialize the fdt_index
with -1 there.
2. Add another attribute in kimage_arch struct to indicate the sanity of the
fdt_index attribute. For example fdt_index_valid, if this holds zero then
the fdt_index holds invalid index. (looks inefficient to me)
Not sure is it worth doing but please let me know your opinion.
Thanks,
Sourabh Jain
RE: [PATCH] net: Use of_property_read_bool() for boolean properties
> -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 > Manoil ; Giuseppe Cavallaro > ; Alexandre Torgue ; > Jose Abreu ; Shawn Guo ; > Sascha Hauer ; Pengutronix Kernel Team > ; Fabio Estevam ; Maxime > Coquelin ; Grygorii Strashko > ; Francois Romieu ; Michal > Simek ; Qiang Zhao ; Kalle > Valo ; Samuel Mendoza-Jonas > Cc: devicet...@vger.kernel.org; linux-...@vger.kernel.org; > net...@vger.kernel.org; linux-ker...@vger.kernel.org; > linux-st...@st-md-mailman.stormreply.com; > linux-arm-ker...@lists.infradead.org; linux-o...@vger.kernel.org; > linuxppc-dev@lists.ozlabs.org; linux-wirel...@vger.kernel.org > Subject: [PATCH] net: Use of_property_read_bool() for boolean properties > > 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. > Convert reading boolean properties to to of_property_read_bool(). > > Signed-off-by: Rob Herring > --- > drivers/net/ethernet/freescale/fec_main.c | 2 +- Reviewed-by: Wei Fang
Re: [PATCH v9 1/6] powerpc/kexec: turn some static helper functions public
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. components] Thanks for points it out. I will fix them in next version. Later in the series, these functions are utilized to do in-kernel update to kexec segments on CPU/Memory hotplug events for both kexec_load and kexec_file_load syscalls. No functional change intended. FWIW, despite the 2 minor typos above, Reviewed-by: Laurent Dufour Thanks for the review Laurent. - Sourabh Jain
Re: [PATCH v9 0/6] PowerPC: in kernel handling of CPU hotplug events for crash kernel
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 inaccurate dump collection.
Existing solution:
==
The existing solution to keep the capture kernel up-to-date by
monitoring
hotplug event via udev rule and trigger a full capture kernel reload for
every hotplug event.
Shortcomings:
- Leaves a window where kernel crash might not lead to a successful dump
collection.
- Reloading all kexec components for each hotplug is inefficient.
- udev rules are prone to races if hotplug events are frequent.
More about issues with an existing solution is posted here:
- https://lkml.org/lkml/2020/12/14/532
-
https://lists.ozlabs.org/pipermail/linuxppc-dev/2022-February/240254.html
Proposed Solution:
==
Instead of reloading all kexec segments on hotplug event, this patch
series
focuses on updating only the relevant kexec segment. Once the kexec
segments
are loaded in the kernel reserved area then an arch-specific hotplug
handler
will update the relevant kexec segment based on hotplug event type.
Series Dependecies
==
This patch series implements the crash hotplug handler on PowerPC.
The generic
crash hotplug update is introduced by
https://lkml.org/lkml/2023/3/6/1358 patch
series.
Git tree for testing:
=
The below git tree has this patch series applied on top of dependent
patch
series.
https://github.com/sourabhjains/linux/tree/in-kernel-crash-update-v9
To realise the feature the kdump udev rules must be disabled for
CPU/Memory
hotplug events. Comment out the below line in kdump udev rule file:
RHEL: /usr/lib/udev/rules.d/98-kexec.rules
#SUBSYSTEM=="cpu", ACTION=="online", GOTO="kdump_reload_cpu"
#SUBSYSTEM=="memory", ACTION=="online", GOTO="kdump_reload_mem"
#SUBSYSTEM=="memory", ACTION=="offline", GOTO="kdump_reload_mem"
SLES: /usr/lib/kdump/70-kdump.rules
#SUBSYSTEM=="memory", ACTION=="add|remove", GOTO="kdump_try_restart"
#SUBSYSTEM=="cpu", ACTION=="online", GOTO="kdump_try_restart"
Sourabh,
The above seems to contradict what I anticipate to be udev rules
changes once the base series is accepted. Specifically I'm suggesting
the following:
- Prevent udev from updating kdump crash kernel on hot un/plug changes.
Add the following as the first lines to the RHEL udev rule file
/usr/lib/udev/rules.d/98-kexec.rules:
# The kernel handles updates to crash elfcorehdr for cpu and memory
changes
SUBSYSTEM=="cpu", ATTRS{crash_hotplug}=="1", GOTO="kdump_reload_end"
SUBSYSTEM=="memory", ATTRS{crash_hotplug}=="1",
GOTO="kdump_reload_end"
With this changeset applied, the two rules evaluate to false for
cpu and memory change events and thus skip the userspace
unload-then-reload of kdump.
The above additions allow distros to deploy the udev rule immediately
and work properly even if the base patchset isn't yet merged, or down
the road, enabled/configured.
Am I missing something such that your recommendation is different than
mine? ]
It is just for the test I have been suggesting to disable the udev
rules, but your udev rules changes is the way forward.
I will use the above changes to control kdump service reload.
Note: only kexec_file_load syscall will work. For kexec_load minor
changes are required in kexec tool.
Will this be the same/similar change as I have posted, or do you
envision something different?
I think the generic changes will be same. I might need to add some
PowerPC specific changes to
make sure elfcorehdr and FDT kexec segment should have additional buffer
space to accommodate
additional memory ranges.
Thanks for the suggestion, I will align the PowerPC kexec tool changes
with your changes.
- Souarbh
RE: [PATCH V6 09/15] spi: Add stacked and parallel memories support in SPI core
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.690903] Serial bus multi instantiate pseudo device driver: probe of CSC3551:00 failed with error -16 Please don't merge this until we have fully investigated. Thanks, Stefan Binding > -Original Message- > From: Amit Kumar Mahapatra > Sent: 10 March 2023 17:32 > To: broo...@kernel.org; miquel.ray...@bootlin.com; rich...@nod.at; > vigne...@ti.com; ji...@kernel.org; tudor.amba...@microchip.com; > praty...@kernel.org; sanju.me...@amd.com; chin- > ting_...@aspeedtech.com; c...@kaod.org; kdasu.k...@gmail.com; > f.faine...@gmail.com; r...@broadcom.com; sbran...@broadcom.com; > eaja...@linux.ibm.com; olte...@gmail.com; han...@nxp.com; > john.ga...@huawei.com; shawn...@kernel.org; > s.ha...@pengutronix.de; narmstr...@baylibre.com; > khil...@baylibre.com; matthias@gmail.com; > haibo.c...@nxp.com; linus.wall...@linaro.org; dan...@zonque.org; > haojian.zhu...@gmail.com; robert.jarz...@free.fr; > agr...@kernel.org; bjorn.anders...@linaro.org; he...@sntech.de; > krzysztof.kozlow...@linaro.org; a...@etezian.org; > mcoquelin.st...@gmail.com; alexandre.tor...@foss.st.com; > w...@csie.org; jernej.skra...@gmail.com; sam...@sholland.org; > masahisa.koj...@linaro.org; jaswinder.si...@linaro.org; > rost...@goodmis.org; mi...@redhat.com; > l.stelm...@samsung.com; da...@davemloft.net; > eduma...@google.com; k...@kernel.org; pab...@redhat.com; > alex.ar...@gmail.com; ste...@datenfreihafen.org; kv...@kernel.org; > james.schul...@cirrus.com; david.rho...@cirrus.com; > tanur...@opensource.cirrus.com; r...@opensource.cirrus.com; > pe...@perex.cz; ti...@suse.com; npig...@gmail.com; > christophe.le...@csgroup.eu; m...@ellerman.id.au; > o...@buserror.net; win...@126.com; yangyingli...@huawei.com; > william.zh...@broadcom.com; kursad.o...@broadcom.com; > jonas.gor...@gmail.com; anand.g...@broadcom.com; > ra...@milecki.pl > Cc: g...@amd.com; linux-...@vger.kernel.org; linux- > ker...@vger.kernel.org; j...@jms.id.au; and...@aj.id.au; > radu_nicolae.pi...@upb.ro; nicolas.fe...@microchip.com; > alexandre.bell...@bootlin.com; claudiu.bez...@microchip.com; bcm- > kernel-feedback-l...@broadcom.com; fancer.lan...@gmail.com; > ker...@pengutronix.de; feste...@gmail.com; linux-...@nxp.com; > jbru...@baylibre.com; martin.blumensti...@googlemail.com; > avifishma...@gmail.com; tmaimo...@gmail.com; > tali.per...@gmail.com; vent...@google.com; yu...@google.com; > benjaminf...@google.com; yogeshgaur...@gmail.com; > konrad.dyb...@somainline.org; alim.akh...@samsung.com; > ldewan...@nvidia.com; thierry.red...@gmail.com; > jonath...@nvidia.com; michal.si...@amd.com; linux- > asp...@lists.ozlabs.org; open...@lists.ozlabs.org; linux-arm- > ker...@lists.infradead.org; linux-rpi-ker...@lists.infradead.org; linux- > amlo...@lists.infradead.org; linux-media...@lists.infradead.org; linux- > arm-...@vger.kernel.org; linux-rockc...@lists.infradead.org; linux- > samsung-...@vger.kernel.org; linux-stm32@st-md- > mailman.stormreply.com; linux-su...@lists.linux.dev; linux- > te...@vger.kernel.org; net...@vger.kernel.org; linux- > w...@vger.kernel.org; libertas-...@lists.infradead.org; linux- > wirel...@vger.kernel.org; linux-...@lists.infradead.org; > l...@metafoo.de; michael.henner...@analog.com; linux- > i...@vger.kernel.org; mich...@walle.cc; pal...@dabbelt.com; linux- > ri...@lists.infradead.org; alsa-de...@alsa-project.org; > patc...@opensource.cirrus.com; linuxppc-dev@lists.ozlabs.org; > amitrkcian2...@gmail.com; amit.kumar-mahapa...@amd.com > Subject: [PATCH V6 09/15] spi: Add stacked and parallel memories > support in SPI core > > 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_index_mask" member. This acts as > an > index to the chip_select array. If nth bit of spi->cs_index_mask is set > then the driver would assert spi->chip_select[n]. > > In parallel mode all the chip selects are asserted/de-asserted > simultaneously and each byte of data is stored in both devices, the > even > bits in one, the odd bits in the other. The split is automatically handled > by the GQSPI controller. The GQSPI controller supports a maximum of > two > flashes connected in parallel mode. A "multi-cs-cap" flag is added in > the > spi controntroller data, through ctlr->multi-cs-cap the spi core will > make > sure that the controller is capable of handling multiple chip selects at > once. > > For supporting multiple CS via GPIO the cs_gpiod member of the > spi_device > structure is now an array that holds the gpio descriptor for each > chipselect. > > Multi CS support using GPIO is not tested
Re: (subset) [PATCH V5 00/15] spi: Add support for stacked/parallel memories
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 the spi-nor, spi core and the spi drivers
> to add stacked and parallel memories support.
>
> [...]
Applied to
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git for-next
Thanks!
[01/15] spi: Replace all spi->chip_select and spi->cs_gpiod references with
function call
commit: 9e264f3f85a56cc109cc2d6010a48aa89d5c1ff1
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
Re: [PATCH v10 03/13] dt-bindings: Convert gpio-mmio to yaml
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 patch being accepted and > then I could re-submit the driver changes. > What's the consensus ? Sean picked it up for shepherding, it looks very good, as soon as the DT maintainers give it a nod Bartosz can merge it. Yours, Linus Walleij
Re: [PATCH] modpost: support arbitrary symbol length in modversion
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 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 limit in kallsyms is increased to 512 for this
> > > > > reason.
> > > > >
> > > > > It's a waste of space to simply expand the fixed array size to 512 in
> > > > > modversion info entries. I therefore make it variably sized, with
> > > > > offset
> > > > > to the next entry indicated by the initial "next" field.
> > > > >
> > > > > In addition to supporting longer-than-56/60 byte symbols, this patch
> > > > > also
> > > > > reduce the size for short symbols by getting rid of excessive 0
> > > > > paddings.
> > > > > There are still some zero paddings to ensure "next" and "crc" fields
> > > > > are
> > > > > properly aligned.
> > > > >
> > > > > This patch does have a tiny drawback that it makes ".mod.c" files
> > > > > generated
> > > > > a bit less easy to read, as code like
> > > > >
> > > > > "\x08\x00\x00\x00\x78\x56\x34\x12"
> > > > > "symbol\0\0"
> > > > >
> > > > > is generated as opposed to
> > > > >
> > > > > { 0x12345678, "symbol" },
> > > > >
> > > > > because the structure is now variable-length. But hopefully nobody
> > > > > reads
> > > > > the generated file :)
> > > > >
> > > > > Link: b8a94bfb3395 ("kallsyms: increase maximum kernel symbol length
> > > > > to 512")
> > > > > Link: https://github.com/Rust-for-Linux/linux/pull/379
> > > > >
> > > > > Signed-off-by: Gary Guo
> > > >
> > > > Is there any newer version of this patch?
> > > >
> > > > I'm doing some tests with it, but I'm getting boot failures on ppc64
> > > > with this applied (at boot kernel is spitting out lots of oops'es and
> > > > unfortunately it's really hard to copy paste or just read them from the
> > > > console).
> > >
> > > Are you using the ELF ABI v1 or v2?
> > >
> > > v1 may have some additional issues when it comes to these symbol tables.
> > >
> > > Thanks
> > >
> > > Michal
> >
> > I have CONFIG_PPC64_ELF_ABI_V2=y in my .config, so I guess I'm using v2.
> >
> > BTW, the issue seems to be in dedotify_versions(), as a silly test I
> > tried to comment out this function completely to be a no-op and now my
> > system boots fine (but I guess I'm probably breaking something else).
>
> Probably not. You should not have the extra leading dot on ABI v2. So if
> dedotify does something that means something generates and then expects
> back symbols with a leading dot, and this workaround for ABI v1 breaks
> that. Or maybe it is called when it shouldn't.
Hm.. I'll add some debugging to this function to see what happens exactly.
-Andrea
Re: [PATCH] modpost: support arbitrary symbol length in modversion
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 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 limit in kallsyms is increased to 512 for this
> > > > reason.
> > > >
> > > > It's a waste of space to simply expand the fixed array size to 512 in
> > > > modversion info entries. I therefore make it variably sized, with offset
> > > > to the next entry indicated by the initial "next" field.
> > > >
> > > > In addition to supporting longer-than-56/60 byte symbols, this patch
> > > > also
> > > > reduce the size for short symbols by getting rid of excessive 0
> > > > paddings.
> > > > There are still some zero paddings to ensure "next" and "crc" fields are
> > > > properly aligned.
> > > >
> > > > This patch does have a tiny drawback that it makes ".mod.c" files
> > > > generated
> > > > a bit less easy to read, as code like
> > > >
> > > > "\x08\x00\x00\x00\x78\x56\x34\x12"
> > > > "symbol\0\0"
> > > >
> > > > is generated as opposed to
> > > >
> > > > { 0x12345678, "symbol" },
> > > >
> > > > because the structure is now variable-length. But hopefully nobody reads
> > > > the generated file :)
> > > >
> > > > Link: b8a94bfb3395 ("kallsyms: increase maximum kernel symbol length to
> > > > 512")
> > > > Link: https://github.com/Rust-for-Linux/linux/pull/379
> > > >
> > > > Signed-off-by: Gary Guo
> > >
> > > Is there any newer version of this patch?
> > >
> > > I'm doing some tests with it, but I'm getting boot failures on ppc64
> > > with this applied (at boot kernel is spitting out lots of oops'es and
> > > unfortunately it's really hard to copy paste or just read them from the
> > > console).
> >
> > Are you using the ELF ABI v1 or v2?
> >
> > v1 may have some additional issues when it comes to these symbol tables.
> >
> > Thanks
> >
> > Michal
>
> I have CONFIG_PPC64_ELF_ABI_V2=y in my .config, so I guess I'm using v2.
>
> BTW, the issue seems to be in dedotify_versions(), as a silly test I
> tried to comment out this function completely to be a no-op and now my
> system boots fine (but I guess I'm probably breaking something else).
Probably not. You should not have the extra leading dot on ABI v2. So if
dedotify does something that means something generates and then expects
back symbols with a leading dot, and this workaround for ABI v1 breaks
that. Or maybe it is called when it shouldn't.
Thanks
Michal
Re: [PATCH] modpost: support arbitrary symbol length in modversion
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 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 limit in kallsyms is increased to 512 for this reason.
> > >
> > > It's a waste of space to simply expand the fixed array size to 512 in
> > > modversion info entries. I therefore make it variably sized, with offset
> > > to the next entry indicated by the initial "next" field.
> > >
> > > In addition to supporting longer-than-56/60 byte symbols, this patch also
> > > reduce the size for short symbols by getting rid of excessive 0 paddings.
> > > There are still some zero paddings to ensure "next" and "crc" fields are
> > > properly aligned.
> > >
> > > This patch does have a tiny drawback that it makes ".mod.c" files
> > > generated
> > > a bit less easy to read, as code like
> > >
> > > "\x08\x00\x00\x00\x78\x56\x34\x12"
> > > "symbol\0\0"
> > >
> > > is generated as opposed to
> > >
> > > { 0x12345678, "symbol" },
> > >
> > > because the structure is now variable-length. But hopefully nobody reads
> > > the generated file :)
> > >
> > > Link: b8a94bfb3395 ("kallsyms: increase maximum kernel symbol length to
> > > 512")
> > > Link: https://github.com/Rust-for-Linux/linux/pull/379
> > >
> > > Signed-off-by: Gary Guo
> >
> > Is there any newer version of this patch?
> >
> > I'm doing some tests with it, but I'm getting boot failures on ppc64
> > with this applied (at boot kernel is spitting out lots of oops'es and
> > unfortunately it's really hard to copy paste or just read them from the
> > console).
>
> Are you using the ELF ABI v1 or v2?
>
> v1 may have some additional issues when it comes to these symbol tables.
>
> Thanks
>
> Michal
I have CONFIG_PPC64_ELF_ABI_V2=y in my .config, so I guess I'm using v2.
BTW, the issue seems to be in dedotify_versions(), as a silly test I
tried to comment out this function completely to be a no-op and now my
system boots fine (but I guess I'm probably breaking something else).
Thanks,
-Andrea
Re: [PATCH] modpost: support arbitrary symbol length in modversion
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 (which encodes crate and module names) can be quite a bit
> > longer. The length limit in kallsyms is increased to 512 for this reason.
> >
> > It's a waste of space to simply expand the fixed array size to 512 in
> > modversion info entries. I therefore make it variably sized, with offset
> > to the next entry indicated by the initial "next" field.
> >
> > In addition to supporting longer-than-56/60 byte symbols, this patch also
> > reduce the size for short symbols by getting rid of excessive 0 paddings.
> > There are still some zero paddings to ensure "next" and "crc" fields are
> > properly aligned.
> >
> > This patch does have a tiny drawback that it makes ".mod.c" files generated
> > a bit less easy to read, as code like
> >
> > "\x08\x00\x00\x00\x78\x56\x34\x12"
> > "symbol\0\0"
> >
> > is generated as opposed to
> >
> > { 0x12345678, "symbol" },
> >
> > because the structure is now variable-length. But hopefully nobody reads
> > the generated file :)
> >
> > Link: b8a94bfb3395 ("kallsyms: increase maximum kernel symbol length to
> > 512")
> > Link: https://github.com/Rust-for-Linux/linux/pull/379
> >
> > Signed-off-by: Gary Guo
>
> Is there any newer version of this patch?
>
> I'm doing some tests with it, but I'm getting boot failures on ppc64
> with this applied (at boot kernel is spitting out lots of oops'es and
> unfortunately it's really hard to copy paste or just read them from the
> console).
Are you using the ELF ABI v1 or v2?
v1 may have some additional issues when it comes to these symbol tables.
Thanks
Michal
Re: [PATCH v11 03/13] dt-bindings: Convert gpio-mmio to yaml
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 comments in the source. There is no set order for the > registers, so I have not specified one. > > Rename brcm,bcm6345-gpio to brcm,bcm63xx-gpio to reflect that bcm6345 > has moved. > > Signed-off-by: Sean Anderson > Reviewed-by: Linus Walleij > --- > Linus or Bartosz, feel free to pick this up as the rest of this series > may not be merged any time soon. I think Bartosz will pick this as soon as the DT maintainers ACK it. Yours, Linus Walleij
Re: [PATCH] modpost: support arbitrary symbol length in modversion
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 limit in kallsyms is increased to 512 for this reason.
>
> It's a waste of space to simply expand the fixed array size to 512 in
> modversion info entries. I therefore make it variably sized, with offset
> to the next entry indicated by the initial "next" field.
>
> In addition to supporting longer-than-56/60 byte symbols, this patch also
> reduce the size for short symbols by getting rid of excessive 0 paddings.
> There are still some zero paddings to ensure "next" and "crc" fields are
> properly aligned.
>
> This patch does have a tiny drawback that it makes ".mod.c" files generated
> a bit less easy to read, as code like
>
> "\x08\x00\x00\x00\x78\x56\x34\x12"
> "symbol\0\0"
>
> is generated as opposed to
>
> { 0x12345678, "symbol" },
>
> because the structure is now variable-length. But hopefully nobody reads
> the generated file :)
>
> Link: b8a94bfb3395 ("kallsyms: increase maximum kernel symbol length to 512")
> Link: https://github.com/Rust-for-Linux/linux/pull/379
>
> Signed-off-by: Gary Guo
Is there any newer version of this patch?
I'm doing some tests with it, but I'm getting boot failures on ppc64
with this applied (at boot kernel is spitting out lots of oops'es and
unfortunately it's really hard to copy paste or just read them from the
console).
Thanks,
-Andrea
[PATCH 15/36] powerpc/fsl: move to use bus_get_dev_root()
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-by: Greg Kroah-Hartman
---
Note, this is a patch that is a prepatory cleanup as part of a larger
series of patches that is working on resolving some old driver core
design mistakes. It will build and apply cleanly on top of 6.3-rc2 on
its own, but I'd prefer if I could take it through my driver-core tree
so that the driver core changes can be taken through there for 6.4-rc1.
arch/powerpc/sysdev/fsl_mpic_timer_wakeup.c | 19 +++
1 file changed, 15 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/sysdev/fsl_mpic_timer_wakeup.c
b/arch/powerpc/sysdev/fsl_mpic_timer_wakeup.c
index c2baa283e624..147b5d8bb904 100644
--- a/arch/powerpc/sysdev/fsl_mpic_timer_wakeup.c
+++ b/arch/powerpc/sysdev/fsl_mpic_timer_wakeup.c
@@ -116,6 +116,7 @@ static struct device_attribute mpic_attributes =
__ATTR(timer_wakeup, 0644,
static int __init fsl_wakeup_sys_init(void)
{
+ struct device *dev_root;
int ret;
fsl_wakeup = kzalloc(sizeof(struct fsl_mpic_timer_wakeup), GFP_KERNEL);
@@ -124,16 +125,26 @@ static int __init fsl_wakeup_sys_init(void)
INIT_WORK(_wakeup->free_work, fsl_free_resource);
- ret = device_create_file(mpic_subsys.dev_root, _attributes);
- if (ret)
- kfree(fsl_wakeup);
+ dev_root = bus_get_dev_root(_subsys);
+ if (dev_root) {
+ ret = device_create_file(dev_root, _attributes);
+ put_device(dev_root);
+ if (ret)
+ kfree(fsl_wakeup);
+ }
return ret;
}
static void __exit fsl_wakeup_sys_exit(void)
{
- device_remove_file(mpic_subsys.dev_root, _attributes);
+ struct device *dev_root;
+
+ dev_root = bus_get_dev_root(_subsys);
+ if (dev_root) {
+ device_remove_file(dev_root, _attributes);
+ put_device(dev_root);
+ }
mutex_lock(_lock);
--
2.39.2
[PATCH 13/36] powerpc/powernv: move to use bus_get_dev_root()
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-Hartman
Cc: Julia Lawall
Cc: linuxppc-dev@lists.ozlabs.org
Signed-off-by: Greg Kroah-Hartman
---
Note, this is a patch that is a prepatory cleanup as part of a larger
series of patches that is working on resolving some old driver core
design mistakes. It will build and apply cleanly on top of 6.3-rc2 on
its own, but I'd prefer if I could take it through my driver-core tree
so that the driver core changes can be taken through there for 6.4-rc1.
arch/powerpc/platforms/powernv/idle.c| 9 +++--
arch/powerpc/platforms/powernv/subcore.c | 10 --
2 files changed, 15 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/platforms/powernv/idle.c
b/arch/powerpc/platforms/powernv/idle.c
index 841cb7f31f4f..6dfe8d611164 100644
--- a/arch/powerpc/platforms/powernv/idle.c
+++ b/arch/powerpc/platforms/powernv/idle.c
@@ -1464,14 +1464,19 @@ static int __init pnv_init_idle_states(void)
power7_fastsleep_workaround_entry = false;
power7_fastsleep_workaround_exit = false;
} else {
+ struct device *dev_root;
/*
* OPAL_PM_SLEEP_ENABLED_ER1 is set. It indicates that
* workaround is needed to use fastsleep. Provide sysfs
* control to choose how this workaround has to be
* applied.
*/
- device_create_file(cpu_subsys.dev_root,
- _attr_fastsleep_workaround_applyonce);
+ dev_root = bus_get_dev_root(_subsys);
+ if (dev_root) {
+ device_create_file(dev_root,
+
_attr_fastsleep_workaround_applyonce);
+ put_device(dev_root);
+ }
}
update_subcore_sibling_mask();
diff --git a/arch/powerpc/platforms/powernv/subcore.c
b/arch/powerpc/platforms/powernv/subcore.c
index 7e98b00ea2e8..428532a69762 100644
--- a/arch/powerpc/platforms/powernv/subcore.c
+++ b/arch/powerpc/platforms/powernv/subcore.c
@@ -415,7 +415,9 @@ static DEVICE_ATTR(subcores_per_core, 0644,
static int subcore_init(void)
{
+ struct device *dev_root;
unsigned pvr_ver;
+ int rc = 0;
pvr_ver = PVR_VER(mfspr(SPRN_PVR));
@@ -435,7 +437,11 @@ static int subcore_init(void)
set_subcores_per_core(1);
- return device_create_file(cpu_subsys.dev_root,
- _attr_subcores_per_core);
+ dev_root = bus_get_dev_root(_subsys);
+ if (dev_root) {
+ rc = device_create_file(dev_root, _attr_subcores_per_core);
+ put_device(dev_root);
+ }
+ return rc;
}
machine_device_initcall(powernv, subcore_init);
--
2.39.2
[PATCH 14/36] powerpc/pseries: move to use bus_get_dev_root()
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-by: Greg Kroah-Hartman
---
Note, this is a patch that is a prepatory cleanup as part of a larger
series of patches that is working on resolving some old driver core
design mistakes. It will build and apply cleanly on top of 6.3-rc2 on
its own, but I'd prefer if I could take it through my driver-core tree
so that the driver core changes can be taken through there for 6.4-rc1.
.../platforms/pseries/pseries_energy.c| 28 +++
arch/powerpc/platforms/pseries/suspend.c | 10 +--
2 files changed, 25 insertions(+), 13 deletions(-)
diff --git a/arch/powerpc/platforms/pseries/pseries_energy.c
b/arch/powerpc/platforms/pseries/pseries_energy.c
index 09e98d301db0..2c661b798235 100644
--- a/arch/powerpc/platforms/pseries/pseries_energy.c
+++ b/arch/powerpc/platforms/pseries/pseries_energy.c
@@ -300,20 +300,22 @@ static struct device_attribute
attr_percpu_deactivate_hint =
static int __init pseries_energy_init(void)
{
int cpu, err;
- struct device *cpu_dev;
+ struct device *cpu_dev, *dev_root;
if (!firmware_has_feature(FW_FEATURE_BEST_ENERGY))
return 0; /* H_BEST_ENERGY hcall not supported */
/* Create the sysfs files */
- err = device_create_file(cpu_subsys.dev_root,
- _cpu_activate_hint_list);
- if (!err)
- err = device_create_file(cpu_subsys.dev_root,
- _cpu_deactivate_hint_list);
+ dev_root = bus_get_dev_root(_subsys);
+ if (dev_root) {
+ err = device_create_file(dev_root,
_cpu_activate_hint_list);
+ if (!err)
+ err = device_create_file(dev_root,
_cpu_deactivate_hint_list);
+ put_device(dev_root);
+ if (err)
+ return err;
+ }
- if (err)
- return err;
for_each_possible_cpu(cpu) {
cpu_dev = get_cpu_device(cpu);
err = device_create_file(cpu_dev,
@@ -337,14 +339,18 @@ static int __init pseries_energy_init(void)
static void __exit pseries_energy_cleanup(void)
{
int cpu;
- struct device *cpu_dev;
+ struct device *cpu_dev, *dev_root;
if (!sysfs_entries)
return;
/* Remove the sysfs files */
- device_remove_file(cpu_subsys.dev_root, _cpu_activate_hint_list);
- device_remove_file(cpu_subsys.dev_root, _cpu_deactivate_hint_list);
+ dev_root = bus_get_dev_root(_subsys);
+ if (dev_root) {
+ device_remove_file(dev_root, _cpu_activate_hint_list);
+ device_remove_file(dev_root, _cpu_deactivate_hint_list);
+ put_device(dev_root);
+ }
for_each_possible_cpu(cpu) {
cpu_dev = get_cpu_device(cpu);
diff --git a/arch/powerpc/platforms/pseries/suspend.c
b/arch/powerpc/platforms/pseries/suspend.c
index 1b902cbf85c5..5c43435472cc 100644
--- a/arch/powerpc/platforms/pseries/suspend.c
+++ b/arch/powerpc/platforms/pseries/suspend.c
@@ -143,6 +143,7 @@ static const struct platform_suspend_ops
pseries_suspend_ops = {
**/
static int pseries_suspend_sysfs_register(struct device *dev)
{
+ struct device *dev_root;
int rc;
if ((rc = subsys_system_register(_subsys, NULL)))
@@ -151,8 +152,13 @@ static int pseries_suspend_sysfs_register(struct device
*dev)
dev->id = 0;
dev->bus = _subsys;
- if ((rc = device_create_file(suspend_subsys.dev_root,
_attr_hibernate)))
- goto subsys_unregister;
+ dev_root = bus_get_dev_root(_subsys);
+ if (dev_root) {
+ rc = device_create_file(dev_root, _attr_hibernate);
+ put_device(dev_root);
+ if (rc)
+ goto subsys_unregister;
+ }
return 0;
--
2.39.2
[PATCH 12/36] powerpc/sysfs: move to use bus_get_dev_root()
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.ozlabs.org
Signed-off-by: Greg Kroah-Hartman
---
Note, this is a patch that is a prepatory cleanup as part of a larger
series of patches that is working on resolving some old driver core
design mistakes. It will build and apply cleanly on top of 6.3-rc2 on
its own, but I'd prefer if I could take it through my driver-core tree
so that the driver core changes can be taken through there for 6.4-rc1.
arch/powerpc/kernel/sysfs.c | 14 --
1 file changed, 12 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/kernel/sysfs.c b/arch/powerpc/kernel/sysfs.c
index ef9a61718940..0f39a6b84132 100644
--- a/arch/powerpc/kernel/sysfs.c
+++ b/arch/powerpc/kernel/sysfs.c
@@ -217,13 +217,18 @@ static DEVICE_ATTR(dscr_default, 0600,
static void __init sysfs_create_dscr_default(void)
{
if (cpu_has_feature(CPU_FTR_DSCR)) {
+ struct device *dev_root;
int cpu;
dscr_default = spr_default_dscr;
for_each_possible_cpu(cpu)
paca_ptrs[cpu]->dscr_default = dscr_default;
- device_create_file(cpu_subsys.dev_root, _attr_dscr_default);
+ dev_root = bus_get_dev_root(_subsys);
+ if (dev_root) {
+ device_create_file(dev_root, _attr_dscr_default);
+ put_device(dev_root);
+ }
}
}
#endif /* CONFIG_PPC64 */
@@ -746,7 +751,12 @@ static DEVICE_ATTR(svm, 0444, show_svm, NULL);
static void __init create_svm_file(void)
{
- device_create_file(cpu_subsys.dev_root, _attr_svm);
+ struct device *dev_root = bus_get_dev_root(_subsys);
+
+ if (dev_root) {
+ device_create_file(dev_root, _attr_svm);
+ put_device(dev_root);
+ }
}
#else
static void __init create_svm_file(void)
--
2.39.2
Re: [PATCH v9 3/6] powerpc/crash: add a new member to the kimage_arch struct
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 after the kdump kernel is loaded.
>
> The new attribute will be used in the arch crash hotplug handler
> (added in upcoming patches) on every CPU and memory hotplug event.
>
> The fdt_index is populated for both kexec_load and kexec_file_load
> case.
>
> Signed-off-by: Sourabh Jain
> ---
> arch/powerpc/include/asm/kexec.h | 5 +
> arch/powerpc/kexec/core_64.c | 31 +++
> 2 files changed, 36 insertions(+)
>
> diff --git a/arch/powerpc/include/asm/kexec.h
> b/arch/powerpc/include/asm/kexec.h
> index 8090ad7d97d9d..348eb96e8ca67 100644
> --- a/arch/powerpc/include/asm/kexec.h
> +++ b/arch/powerpc/include/asm/kexec.h
> @@ -103,6 +103,8 @@ void kexec_copy_flush(struct kimage *image);
> struct crash_mem;
> int update_cpus_node(void *fdt);
> int get_crash_memory_ranges(struct crash_mem **mem_ranges);
> +int machine_kexec_post_load(struct kimage *image);
> +#define machine_kexec_post_load machine_kexec_post_load
Minor comment, when CONFIG_CRASH_HOTPLUG is not set the function is simply
returning 0, why not defining it has an inline in that case?
> #endif
>
> #if defined(CONFIG_CRASH_DUMP) && defined(CONFIG_PPC_RTAS)
> @@ -118,6 +120,9 @@ extern const struct kexec_file_ops kexec_elf64_ops;
> struct kimage_arch {
> struct crash_mem *exclude_ranges;
>
> +#if defined(CONFIG_CRASH_HOTPLUG)
> + int fdt_index;
> +#endif
> unsigned long backup_start;
> void *backup_buf;
> void *fdt;
> diff --git a/arch/powerpc/kexec/core_64.c b/arch/powerpc/kexec/core_64.c
> index 0b292f93a74cc..531486c973988 100644
> --- a/arch/powerpc/kexec/core_64.c
> +++ b/arch/powerpc/kexec/core_64.c
> @@ -77,6 +77,37 @@ int machine_kexec_prepare(struct kimage *image)
> return 0;
> }
>
> +int machine_kexec_post_load(struct kimage *kimage)
> +{
> +#if defined(CONFIG_CRASH_HOTPLUG)
> + int i;
> + void *ptr;
> + unsigned long mem;
> +
> + /* Mark fdt_index invalid */
> + kimage->arch.fdt_index = -1;
Why is that not done in the series introducing the generic
crash hotplug update, in do_kimage_alloc_init() ?
This way there is a guarantee that the field will not be used while set by
default to 0.
> +
> + /* fdt_index remains invalid if it is not a crash kernel load */
> + if (kimage->type != KEXEC_TYPE_CRASH)
> + return 0;
> + /*
> + * Find the FDT segment index in kexec segment array and
> + * assign it to kimage's member fdt_index to enable direct
> + * access to FDT segment later on.
> + */
> + for (i = 0; i < kimage->nr_segments; i++) {
> + mem = kimage->segment[i].mem;
> + ptr = __va(mem);
> +
> + if (ptr && fdt_magic(ptr) == FDT_MAGIC) {
> + kimage->arch.fdt_index = i;
> + break;
> + }
> + }
> +#endif
> + return 0;
> +}
> +
> /* Called during kexec sequence with MMU off */
> static notrace void copy_segments(unsigned long ind)
> {
Re: [PATCH v9 1/6] powerpc/kexec: turn some static helper functions public
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 functions are utilized to do in-kernel update to
> kexec segments on CPU/Memory hotplug events for both kexec_load and
> kexec_file_load syscalls.
>
> No functional change intended.
>
FWIW, despite the 2 minor typos above,
Reviewed-by: Laurent Dufour
> Signed-off-by: Sourabh Jain
> ---
> arch/powerpc/include/asm/kexec.h | 6 ++
> arch/powerpc/kexec/core_64.c | 166 ++
> arch/powerpc/kexec/file_load_64.c | 162 -
> 3 files changed, 172 insertions(+), 162 deletions(-)
>
> diff --git a/arch/powerpc/include/asm/kexec.h
> b/arch/powerpc/include/asm/kexec.h
> index a1ddba01e7d13..8090ad7d97d9d 100644
> --- a/arch/powerpc/include/asm/kexec.h
> +++ b/arch/powerpc/include/asm/kexec.h
> @@ -99,6 +99,12 @@ void relocate_new_kernel(unsigned long indirection_page,
> unsigned long reboot_co
>
> void kexec_copy_flush(struct kimage *image);
>
> +#ifdef CONFIG_PPC64
> +struct crash_mem;
> +int update_cpus_node(void *fdt);
> +int get_crash_memory_ranges(struct crash_mem **mem_ranges);
> +#endif
> +
> #if defined(CONFIG_CRASH_DUMP) && defined(CONFIG_PPC_RTAS)
> void crash_free_reserved_phys_range(unsigned long begin, unsigned long end);
> #define crash_free_reserved_phys_range crash_free_reserved_phys_range
> diff --git a/arch/powerpc/kexec/core_64.c b/arch/powerpc/kexec/core_64.c
> index a79e28c91e2be..0b292f93a74cc 100644
> --- a/arch/powerpc/kexec/core_64.c
> +++ b/arch/powerpc/kexec/core_64.c
> @@ -17,6 +17,8 @@
> #include
> #include
> #include
> +#include
> +#include
>
> #include
> #include
> @@ -30,6 +32,8 @@
> #include
> #include
> #include
> +#include
> +#include
>
> int machine_kexec_prepare(struct kimage *image)
> {
> @@ -377,6 +381,168 @@ void default_machine_kexec(struct kimage *image)
> /* NOTREACHED */
> }
>
> +/**
> + * get_crash_memory_ranges - Get crash memory ranges. This list includes
> + * first/crashing kernel's memory regions that
> + * would be exported via an elfcore.
> + * @mem_ranges: Range list to add the memory ranges to.
> + *
> + * Returns 0 on success, negative errno on error.
> + */
> +int get_crash_memory_ranges(struct crash_mem **mem_ranges)
> +{
> + phys_addr_t base, end;
> + struct crash_mem *tmem;
> + u64 i;
> + int ret;
> +
> + for_each_mem_range(i, , ) {
> + u64 size = end - base;
> +
> + /* Skip backup memory region, which needs a separate entry */
> + if (base == BACKUP_SRC_START) {
> + if (size > BACKUP_SRC_SIZE) {
> + base = BACKUP_SRC_END + 1;
> + size -= BACKUP_SRC_SIZE;
> + } else
> + continue;
> + }
> +
> + ret = add_mem_range(mem_ranges, base, size);
> + if (ret)
> + goto out;
> +
> + /* Try merging adjacent ranges before reallocation attempt */
> + if ((*mem_ranges)->nr_ranges == (*mem_ranges)->max_nr_ranges)
> + sort_memory_ranges(*mem_ranges, true);
> + }
> +
> + /* Reallocate memory ranges if there is no space to split ranges */
> + tmem = *mem_ranges;
> + if (tmem && (tmem->nr_ranges == tmem->max_nr_ranges)) {
> + tmem = realloc_mem_ranges(mem_ranges);
> + if (!tmem)
> + goto out;
> + }
> +
> + /* Exclude crashkernel region */
> + ret = crash_exclude_mem_range(tmem, crashk_res.start, crashk_res.end);
> + if (ret)
> + goto out;
> +
> + /*
> + * FIXME: For now, stay in parity with kexec-tools but if RTAS/OPAL
> + *regions are exported to save their context at the time of
> + *crash, they should actually be backed up just like the
> + *first 64K bytes of memory.
> + */
> + ret = add_rtas_mem_range(mem_ranges);
> + if (ret)
> + goto out;
> +
> + ret = add_opal_mem_range(mem_ranges);
> + if (ret)
> + goto out;
> +
> + /* create a separate program header for the backup region */
> + ret = add_mem_range(mem_ranges, BACKUP_SRC_START, BACKUP_SRC_SIZE);
> + if (ret)
> + goto out;
> +
> + sort_memory_ranges(*mem_ranges, false);
> +out:
> + if (ret)
> + pr_err("Failed to setup crash memory ranges\n");
> + return ret;
> +}
> +
> +/**
> + * add_node_props - Reads node properties from device node structure and add
> + * them to fdt.
> + * @fdt:Flattened device tree of the kernel
> + *
[PATCH v11 12/13] arm64: dts: ls1088a: Prevent PCSs from probing as phys
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
.../arm64/boot/dts/freescale/fsl-ls1088a.dtsi | 30 ---
1 file changed, 20 insertions(+), 10 deletions(-)
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi
b/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi
index 59b401daad4d..bbc714f84577 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi
@@ -932,7 +932,8 @@ pcs_mdio1: mdio@8c07000 {
#size-cells = <0>;
status = "disabled";
- pcs1: ethernet-phy@0 {
+ pcs1: ethernet-pcs@0 {
+ compatible = "fsl,lynx-pcs";
reg = <0>;
};
};
@@ -945,7 +946,8 @@ pcs_mdio2: mdio@8c0b000 {
#size-cells = <0>;
status = "disabled";
- pcs2: ethernet-phy@0 {
+ pcs2: ethernet-pcs@0 {
+ compatible = "fsl,lynx-pcs";
reg = <0>;
};
};
@@ -958,19 +960,23 @@ pcs_mdio3: mdio@8c0f000 {
#size-cells = <0>;
status = "disabled";
- pcs3_0: ethernet-phy@0 {
+ pcs3_0: ethernet-pcs@0 {
+ compatible = "fsl,lynx-pcs";
reg = <0>;
};
- pcs3_1: ethernet-phy@1 {
+ pcs3_1: ethernet-pcs@1 {
+ compatible = "fsl,lynx-pcs";
reg = <1>;
};
- pcs3_2: ethernet-phy@2 {
+ pcs3_2: ethernet-pcs@2 {
+ compatible = "fsl,lynx-pcs";
reg = <2>;
};
- pcs3_3: ethernet-phy@3 {
+ pcs3_3: ethernet-pcs@3 {
+ compatible = "fsl,lynx-pcs";
reg = <3>;
};
};
@@ -983,19 +989,23 @@ pcs_mdio7: mdio@8c1f000 {
#size-cells = <0>;
status = "disabled";
- pcs7_0: ethernet-phy@0 {
+ pcs7_0: ethernet-pcs@0 {
+ compatible = "fsl,lynx-pcs";
reg = <0>;
};
- pcs7_1: ethernet-phy@1 {
+ pcs7_1: ethernet-pcs@1 {
+ compatible = "fsl,lynx-pcs";
reg = <1>;
};
- pcs7_2: ethernet-phy@2 {
+ pcs7_2: ethernet-pcs@2 {
+ compatible = "fsl,lynx-pcs";
reg = <2>;
};
- pcs7_3: ethernet-phy@3 {
+ pcs7_3: ethernet-pcs@3 {
+ compatible = "fsl,lynx-pcs";
reg = <3>;
};
};
--
2.35.1.1320.gc452695387.dirty
[PATCH v11 13/13] arm64: dts: ls1088ardb: Add serdes descriptions
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 modeled it as a two fixed
clocks instead. There are a few registers in the QIXIS FPGA which
control the SFP GPIOs; I have modeled them as discrete GPIO controllers
for now. I never saw the AQR105 interrupt fire; not sure what was going
on, but I have removed it to force polling.
To enable serdes support, the DPC needs to set the macs to
MAC_LINK_TYPE_BACKPLANE. All MACs using the same QSGMII should be
converted at once. Additionally, in order to change interface types, the
MC firmware must support DPAA2_MAC_FEATURE_PROTOCOL_CHANGE.
Signed-off-by: Sean Anderson
---
(no changes since v10)
Changes in v10:
- Move serdes bindings to SoC dtsi
- Use "descriptions" instead of "bindings"
- Don't use /clocks
- Add missing gpio-controller properties
Changes in v9:
- Add fsl,unused-lanes-reserved to allow a gradual transition, depending
on the mac link type.
- Remove unused clocks
- Fix some phy mode node names
- phy-type -> fsl,phy
Changes in v8:
- Rename serdes phy handles like the LS1046A
- Add SFP slot binding
- Fix incorrect lane ordering (it's backwards on the LS1088A just like it is in
the LS1046A).
- Fix duplicated lane 2 (it should have been lane 3).
- Fix incorrectly-documented value for XFI1.
- Remove interrupt for aquantia phy. It never fired for whatever reason,
preventing the link from coming up.
- Add GPIOs for QIXIS FPGA.
- Enable MAC1 PCS
- Remove si5341 binding
Changes in v4:
- Convert to new bindings
.../boot/dts/freescale/fsl-ls1088a-rdb.dts| 82 ++-
1 file changed, 80 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1088a-rdb.dts
b/arch/arm64/boot/dts/freescale/fsl-ls1088a-rdb.dts
index ee8e932628d1..ede537b644e8 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1088a-rdb.dts
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1088a-rdb.dts
@@ -10,17 +10,55 @@
/dts-v1/;
+#include
+
#include "fsl-ls1088a.dtsi"
/ {
model = "LS1088A RDB Board";
compatible = "fsl,ls1088a-rdb", "fsl,ls1088a";
+
+ clk_100mhz: clock-100mhz {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <1>;
+ };
+
+ clk_156mhz: clock-156mhz {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <15625>;
+ };
+
+ sfp_slot: sfp {
+ compatible = "sff,sfp";
+ i2c-bus = <_i2c>;
+ los-gpios = <_stat 5 GPIO_ACTIVE_HIGH>;
+ tx-fault-gpios = <_stat 4 GPIO_ACTIVE_HIGH>;
+ tx-disable-gpios = < 4 GPIO_ACTIVE_HIGH>;
+ };
+};
+
+ {
+ clocks = <_100mhz>, <_156mhz>;
+ clock-names = "ref0", "ref1";
+ fsl,unused-lanes-reserved;
+ status = "okay";
+};
+
+ {
+ managed = "in-band-status";
+ pcs-handle = <>;
+ phys = <_C>;
+ sfp = <_slot>;
};
{
phy-handle = <_aquantia_phy>;
phy-connection-type = "10gbase-r";
+ managed = "in-band-status";
pcs-handle = <>;
+ phys = <_D>;
};
{
@@ -28,6 +66,7 @@ {
phy-connection-type = "qsgmii";
managed = "in-band-status";
pcs-handle = <_0>;
+ phys = <_A>;
};
{
@@ -35,6 +74,7 @@ {
phy-connection-type = "qsgmii";
managed = "in-band-status";
pcs-handle = <_1>;
+ phys = <_A>;
};
{
@@ -42,6 +82,7 @@ {
phy-connection-type = "qsgmii";
managed = "in-band-status";
pcs-handle = <_2>;
+ phys = <_A>;
};
{
@@ -49,6 +90,7 @@ {
phy-connection-type = "qsgmii";
managed = "in-band-status";
pcs-handle = <_3>;
+ phys = <_A>;
};
{
@@ -56,6 +98,7 @@ {
phy-connection-type = "qsgmii";
managed = "in-band-status";
pcs-handle = <_0>;
+ phys = <_B>;
};
{
@@ -63,6 +106,7 @@ {
phy-connection-type = "qsgmii";
managed = "in-band-status";
pcs-handle = <_1>;
+ phys = <_B>;
};
{
@@ -70,6 +114,7 @@ {
phy-connection-type = "qsgmii";
managed = "in-band-status";
pcs-handle = <_2>;
+ phys = <_B>;
};
{
@@ -77,6 +122,7 @@ {
phy-connection-type = "qsgmii";
managed = "in-band-status";
pcs-handle = <_3>;
+ phys = <_B>;
};
{
@@ -128,7 +174,6 @@ {
mdio2_aquantia_phy: ethernet-phy@0 {
compatible = "ethernet-phy-ieee802.3-c45";
- interrupts-extended = < 2 IRQ_TYPE_LEVEL_LOW>;
reg = <0x0>;
};
};
@@ -171,6 +216,12 @@ rtc@51 {
interrupts-extended = < 0
IRQ_TYPE_LEVEL_LOW>;
[PATCH v11 10/13] arm64: dts: ls1046ardb: Add serdes descriptions
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 is gate them), so I have chosen to model it as a single
fixed clock.
Note: the SerDes1 lane numbering for the LS1046A is *reversed*.
This means that Lane A (what the driver thinks is lane 0) uses pins
SD1_TX3_P/N.
Signed-off-by: Sean Anderson
---
(no changes since v10)
Changes in v10:
- Move serdes descriptions to SoC dtsi
- Don't use /clocks
- Use "descriptions" instead of "bindings"
- Split off defconfig change into separate patch
Changes in v9:
- Fix name of phy mode node
- phy-type -> fsl,phy
Changes in v8:
- Rename serdes phy handles to use _A, _B, etc. instead of _0, _1, etc.
This should help remind readers that the numbering corresponds to the
physical layout of the registers, and not the lane (pin) number.
Changes in v6:
- XGI.9 -> XFI.9
Changes in v4:
- Convert to new bindings
.../boot/dts/freescale/fsl-ls1046a-rdb.dts| 26 +++
1 file changed, 26 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1046a-rdb.dts
b/arch/arm64/boot/dts/freescale/fsl-ls1046a-rdb.dts
index 07f6cc6e354a..0d6dcfd1630a 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1046a-rdb.dts
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1046a-rdb.dts
@@ -26,6 +26,24 @@ aliases {
chosen {
stdout-path = "serial0:115200n8";
};
+
+ clk_100mhz: clock-100mhz {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <1>;
+ };
+
+ clk_156mhz: clock-156mhz {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <15625>;
+ };
+};
+
+ {
+ clocks = <_100mhz>, <_156mhz>;
+ clock-names = "ref0", "ref1";
+ status = "okay";
};
{
@@ -140,21 +158,29 @@ ethernet@e6000 {
ethernet@e8000 {
phy-handle = <_phy1>;
phy-connection-type = "sgmii";
+ phys = <_B>;
+ phy-names = "serdes";
};
ethernet@ea000 {
phy-handle = <_phy2>;
phy-connection-type = "sgmii";
+ phys = <_A>;
+ phy-names = "serdes";
};
ethernet@f { /* 10GEC1 */
phy-handle = <_phy>;
phy-connection-type = "xgmii";
+ phys = <_D>;
+ phy-names = "serdes";
};
ethernet@f2000 { /* 10GEC2 */
phy-connection-type = "10gbase-r";
managed = "in-band-status";
+ phys = <_C>;
+ phy-names = "serdes";
};
mdio@fc000 {
--
2.35.1.1320.gc452695387.dirty
[PATCH v11 08/13] phy: lynx10g: Enable by default on Layerscape
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/phy/freescale/Kconfig b/drivers/phy/freescale/Kconfig index 6bebe00f5889..b396162dc859 100644 --- a/drivers/phy/freescale/Kconfig +++ b/drivers/phy/freescale/Kconfig @@ -54,6 +54,7 @@ config PHY_FSL_LYNX_10G depends on ARCH_LAYERSCAPE || PPC || COMPILE_TEST select GENERIC_PHY select REGMAP_MMIO + default y if ARCH_LAYERSCAPE help This adds support for the Lynx "SerDes" devices found on various QorIQ SoCs. There may be up to four SerDes devices on each SoC, and each -- 2.35.1.1320.gc452695387.dirty
[PATCH v11 07/13] phy: fsl: Add Lynx 10G SerDes driver
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 supported protocols for each lane. Additionally, the SerDes devices on each SoC also have differing support. One SerDes will typically support Ethernet on most lanes, while the other will typically support PCIe on most lanes. There is wide hardware support for this SerDes. It is present on QorIQ T-Series and Layerscape processors. Because each SoC typically has specific instructions and exceptions for its SerDes, I have limited the initial scope of this module to just the LS1046A and LS1088A. Additionally, I have only added support for Ethernet protocols. There is not a great need for dynamic reconfiguration for other protocols (except perhaps for M.2 cards), so support for them may never be added. Nevertheless, I have tried to provide an obvious path for adding support for other SoCs as well as other protocols. SATA just needs support for configuring LNmSSCR0. PCIe may need to configure the equalization registers. It also uses multiple lanes. I have tried to write the driver with multi-lane support in mind, so there should not need to be any large changes. Although there are 6 protocols supported, I have only tested SGMII and XFI. The rest have been implemented as described in the datasheet. Most of these protocols should work "as-is", but 10GBASE-KR will need PCS support for link training. Unlike some other phys where e.g. PCIe x4 will use 4 separate phys all configured for PCIe, this driver uses one phy configured to use 4 lanes. This is because while the individual lanes may be configured individually, the protocol selection acts on all lanes at once. Additionally, the order which lanes should be configured in is specified by the datasheet. To coordinate this, lanes are reserved in phy_init, and released in phy_exit. This driver was written with reference to the LS1046A reference manual. However, it was informed by reference manuals for all processors with mEMACs, especially the T4240 (which appears to have a "maxed-out" configuration). The earlier P-series processors appear to be similar, but have a different overall register layout (using "banks" instead of separate SerDes). Perhaps this those use a "5G Lynx SerDes." Signed-off-by: Sean Anderson --- (no changes since v10) Changes in v10: - Fix debugging print with incorrect error variable Changes in v9: - Split off clock "driver" into its own patch to allow for better review. - Add ability to defer lane initialization to phy_init. This allows for easier transitioning between firmware-managed serdes and Linux- managed serdes, as the consumer (such as dpaa2, which knows what the firmware is doing) has the last say on who gets control. - phy-type -> fsl,phy Changes in v8: - Remove unused variable from lynx_ls_mode_init Changes in v7: - Break out call order into generic documentation - Refuse to switch "major" protocols - Update Kconfig to reflect restrictions - Remove set/clear of "pcs reset" bit, since it doesn't seem to fix anything. Changes in v6: - Update MAINTAINERS to include new files - Include bitfield.h and slab.h to allow compilation on non-arm64 arches. - Depend on COMMON_CLK and either layerscape/ppc Changes in v5: - Remove references to PHY_INTERFACE_MODE_1000BASEKX to allow this series to be applied directly to linux/master. - Add fsl,lynx-10g.h to MAINTAINERS Changes in v4: - Rework all debug statements to remove use of __func__. Additional information has been provided as necessary. - Consider alternative parent rates in round_rate and not in set_rate. Trying to modify out parent's rate in set_rate will deadlock. - Explicitly perform a stop/reset sequence in set_rate. This way we always ensure that the PLL is properly stopped. - Set the power-down bit when disabling the PLL. We can do this now that enable/disable aren't abused during the set rate sequence. - Fix typos in QSGMII_OFFSET and XFI_OFFSET - Rename LNmTECR0_TEQ_TYPE_PRE to LNmTECR0_TEQ_TYPE_POST to better reflect its function (adding post-cursor equalization). - Use of_clk_hw_onecell_get instead of a custom function. - Return struct clks from lynx_clks_init instead of embedding lynx_clk in lynx_priv. - Rework PCCR helper functions; T-series SoCs differ from Layerscape SoCs primarily in the layout and offset of the PCCRs. This will help bring a cleaner abstraction layer. The caps have been removed, since this handles the only current usage. - Convert to use new binding format. As a result of this, we no longer need to have protocols for PCIe or SATA. Additionally, modes now live in lynx_group instead of lynx_priv. - Remove teq from lynx_proto_params, since it can be determined from preq_ratio/postq_ratio. - Fix an early return from
[PATCH v11 11/13] arm64: dts: ls1088a: Add serdes nodes
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 "bindings"
- Move compatible/reg first
Changes in v4:
- Convert to new bindings
Changes in v3:
- New
.../arm64/boot/dts/freescale/fsl-ls1088a.dtsi | 126 ++
1 file changed, 126 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi
b/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi
index e5fb137ac02b..59b401daad4d 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi
@@ -9,6 +9,7 @@
*/
#include
#include
+#include
#include
/ {
@@ -238,6 +239,131 @@ reset: syscon@1e6 {
reg = <0x0 0x1e6 0x0 0x1>;
};
+ serdes1: serdes@1ea {
+ compatible = "fsl,ls1088a-serdes", "fsl,lynx-10g";
+ reg = <0x0 0x1ea 0x0 0x2000>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ #clock-cells = <1>;
+ status = "disabled";
+
+ /*
+* XXX: Lane A uses pins SD1_RX3_P/N! That is, the lane
+* numbers and pin numbers are _reversed_.
+*/
+ serdes1_A: phy@0 {
+ #phy-cells = <0>;
+ reg = <0>;
+
+ /* SG3 */
+ sgmii-0 {
+ fsl,pccr = <0x8>;
+ fsl,index = <0>;
+ fsl,cfg = <0x1>;
+ fsl,type = ;
+ };
+
+ /* QSGb */
+ qsgmii-0 {
+ fsl,pccr = <0x9>;
+ fsl,index = <0>;
+ fsl,cfg = <0x1>;
+ fsl,type = ;
+ };
+ };
+
+ serdes1_B: phy@1 {
+ #phy-cells = <0>;
+ reg = <1>;
+
+ /* SG7 */
+ sgmii-1 {
+ fsl,pccr = <0x8>;
+ fsl,index = <1>;
+ fsl,cfg = <0x1>;
+ fsl,type = ;
+ };
+
+ /* QSGa */
+ qsgmii-1 {
+ fsl,pccr = <0x9>;
+ fsl,index = <1>;
+ fsl,cfg = <0x1>;
+ fsl,type = ;
+ };
+
+ /* TODO: PCIe1 */
+ };
+
+ serdes1_C: phy@2 {
+ #phy-cells = <0>;
+ reg = <2>;
+
+ /* SG1 */
+ sgmii-2 {
+ fsl,pccr = <0x8>;
+ fsl,index = <2>;
+ fsl,cfg = <0x1>;
+ fsl,type = ;
+ };
+
+ /*
+* XFI1
+* Table 23-1 and section 23.5.16.4 disagree;
+* this reflects the table.
+*
+* fsl,cfg is documented as 1, but it is set to
+* 2 by the RCW! This is the same as the
+* LS1046A.
+*/
+ xfi-0 {
+ fsl,pccr = <0xb>;
+ fsl,index = <0>;
+ fsl,cfg = <0x2>;
+ fsl,type = ;
+ };
+ };
+
+ serdes1_D: phy@3 {
+ #phy-cells = <0>;
+ reg = <3>;
+
+ /* SG2 */
+ sgmii-3 {
+ fsl,pccr = <0x8>;
+ fsl,index = <3>;
+ fsl,cfg = <0x1>;
+
[PATCH v11 06/13] clk: Add Lynx 10G SerDes PLL driver
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 device is not used as it offers no benefits over a function call (and there is no need to have a separate device). The PLLs are modeled as clocks proper to let us take advantage of the existing clock infrastructure. I have not given the same treatment to the per-lane clocks because they need to be programmed in-concert with the rest of the lane settings. One tricky thing is that the VCO (PLL) rate exceeds 2^32 (maxing out at around 5GHz). This will be a problem on 32-bit platforms, since clock rates are stored as unsigned longs. To work around this, the pll clock rate is generally treated in units of kHz. The PLLs are configured rather interestingly. Instead of the usual direct programming of the appropriate divisors, the input and output clock rates are selected directly. Generally, the only restriction is that the input and output must be integer multiples of each other. This suggests some kind of internal look-up table. The datasheets generally list out the supported combinations explicitly, and not all input/output combinations are documented. I'm not sure if this is due to lack of support, or due to an oversight. If this becomes an issue, then some combinations can be blacklisted (or whitelisted). This may also be necessary for other SoCs which have more stringent clock requirements. Signed-off-by: Sean Anderson --- (no changes since v10) Changes in v10: - Remove unnecessary inclusion of clk.h - Don't gate clocks in compatibility mode Changes in v9: - Convert some u32s to unsigned long to match arguments - Switch from round_rate to determine_rate - Drop explicit reference to reference clock - Use .parent_names when requesting parents - Use devm_clk_hw_get_clk to pass clocks back to serdes - Fix indentation - Split off from following patch to allow for better review MAINTAINERS| 7 + drivers/clk/Makefile | 1 + drivers/clk/clk-fsl-lynx-10g.c | 510 + drivers/phy/freescale/Kconfig | 6 + include/linux/phy/lynx-10g.h | 16 ++ 5 files changed, 540 insertions(+) create mode 100644 drivers/clk/clk-fsl-lynx-10g.c create mode 100644 include/linux/phy/lynx-10g.h diff --git a/MAINTAINERS b/MAINTAINERS index 8d5bc223f305..1098ad283eb6 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -12202,6 +12202,13 @@ S: Maintained W: http://linux-test-project.github.io/ T: git https://github.com/linux-test-project/ltp.git +LYNX 10G SERDES DRIVER +M: Sean Anderson +S: Maintained +F: drivers/clk/clk-fsl-lynx-10g.c +F: include/dt-bindings/clock/fsl,lynx-10g.h +F: include/linux/phy/lynx-10g.h + LYNX 28G SERDES PHY DRIVER M: Ioana Ciornei L: net...@vger.kernel.org diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile index e3ca0d058a25..eebed69f6c58 100644 --- a/drivers/clk/Makefile +++ b/drivers/clk/Makefile @@ -33,6 +33,7 @@ obj-$(CONFIG_ARCH_SPARX5) += clk-sparx5.o obj-$(CONFIG_COMMON_CLK_EN7523)+= clk-en7523.o obj-$(CONFIG_COMMON_CLK_FIXED_MMIO)+= clk-fixed-mmio.o obj-$(CONFIG_COMMON_CLK_FSL_FLEXSPI) += clk-fsl-flexspi.o +obj-$(CONFIG_PHY_FSL_LYNX_10G) += clk-fsl-lynx-10g.o obj-$(CONFIG_COMMON_CLK_FSL_SAI) += clk-fsl-sai.o obj-$(CONFIG_COMMON_CLK_GEMINI)+= clk-gemini.o obj-$(CONFIG_COMMON_CLK_ASPEED)+= clk-aspeed.o diff --git a/drivers/clk/clk-fsl-lynx-10g.c b/drivers/clk/clk-fsl-lynx-10g.c new file mode 100644 index ..78357303b578 --- /dev/null +++ b/drivers/clk/clk-fsl-lynx-10g.c @@ -0,0 +1,510 @@ +// SPDX-License-Identifier: GPL-2.0 +/* + * Copyright (C) 2022 Sean Anderson + * + * This file contains the implementation for the PLLs found on Lynx 10G phys. + * + * XXX: The VCO rate of the PLLs can exceed ~4GHz, which is the maximum rate + * expressable in an unsigned long. To work around this, rates are specified in + * kHz. This is as if there was a division by 1000 in the PLL. + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#define PLL_STRIDE 0x20 +#define PLLa(a, off) ((a) * PLL_STRIDE + (off)) +#define PLLaRSTCTL(a) PLLa(a, 0x00) +#define PLLaCR0(a) PLLa(a, 0x04) + +#define PLLaRSTCTL_RSTREQ BIT(31) +#define PLLaRSTCTL_RST_DONEBIT(30) +#define PLLaRSTCTL_RST_ERR BIT(29) +#define PLLaRSTCTL_PLLRST_BBIT(7) +#define PLLaRSTCTL_SDRST_B BIT(6) +#define PLLaRSTCTL_SDENBIT(5) + +#define PLLaRSTCTL_ENABLE_SET (PLLaRSTCTL_RST_DONE | PLLaRSTCTL_PLLRST_B | \ +PLLaRSTCTL_SDRST_B | PLLaRSTCTL_SDEN) +#define PLLaRSTCTL_ENABLE_MASK (PLLaRSTCTL_ENABLE_SET |
[PATCH v11 09/13] arm64: dts: ls1046a: Add serdes nodes
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 "bindings"
- Move compatible/reg first
Changes in v4:
- Convert to new bindings
Changes in v3:
- Describe modes in device tree
Changes in v2:
- Use one phy cell for SerDes1, since no lanes can be grouped
- Disable SerDes by default to prevent breaking boards inadvertently.
.../arm64/boot/dts/freescale/fsl-ls1046a.dtsi | 111 ++
1 file changed, 111 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi
b/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi
index a01e3cfec77f..f6361fafaef7 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi
@@ -12,6 +12,7 @@
#include
#include
#include
+#include
/ {
compatible = "fsl,ls1046a";
@@ -424,6 +425,116 @@ sfp: efuse@1e8 {
clock-names = "sfp";
};
+ serdes1: serdes@1ea {
+ compatible = "fsl,ls1046a-serdes", "fsl,lynx-10g";
+ reg = <0x0 0x1ea 0x0 0x2000>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ #clock-cells = <1>;
+ status = "disabled";
+
+ /*
+* XXX: Lane A uses pins SD1_RX3_P/N! That is, the lane
+* numbers and pin numbers are _reversed_. In addition,
+* the PCCR documentation is _inconsistent_ in its
+* usage of these terms!
+*
+* PCCR "Lane 0" refers to...
+* =
+*0 Lane A
+*2 Lane A
+*8 Lane A
+*9 Lane A
+*B Lane D!
+*/
+ serdes1_A: phy@0 {
+ #phy-cells = <0>;
+ reg = <0>;
+
+ /* SGMII.6 */
+ sgmii-0 {
+ fsl,pccr = <0x8>;
+ fsl,index = <0>;
+ fsl,cfg = <0x1>;
+ fsl,type = ;
+ };
+ };
+
+ serdes1_B: phy@1 {
+ #phy-cells = <0>;
+ reg = <1>;
+
+ /* SGMII.5 */
+ sgmii-1 {
+ fsl,pccr = <0x8>;
+ fsl,index = <1>;
+ fsl,cfg = <0x1>;
+ fsl,type = ;
+ };
+
+ /* QSGMII.6,5,10,1 */
+ qsgmii-1 {
+ fsl,pccr = <0x9>;
+ fsl,index = <1>;
+ fsl,cfg = <0x1>;
+ fsl,type = ;
+ };
+
+ /* TODO: PCIe.1 */
+ };
+
+ serdes1_C: phy@2 {
+ #phy-cells = <0>;
+ reg = <2>;
+
+ /* SGMII.10 */
+ sgmii-2 {
+ fsl,pccr = <0x8>;
+ fsl,index = <2>;
+ fsl,cfg = <0x1>;
+ fsl,type = ;
+ };
+
+ /* XFI.10 */
+ xfi-0 {
+ fsl,pccr = <0xb>;
+ fsl,index = <0>;
+ fsl,cfg = <0x2>;
+ fsl,type = ;
+ };
+ };
+
+ serdes1_D: phy@3 {
+ #phy-cells = <0>;
+ reg = <3>;
+
+ /* SGMII.9 */
+ sgmii-3 {
+ fsl,pccr = <0x8>;
+ fsl,index = <3>;
+ fsl,cfg = <0x1>;
+ fsl,type = ;
+ };
+
+
[PATCH v11 01/13] dt-bindings: phy: Add 2500BASE-X and 10GBASE-R
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 typically used to communicate directly with SFP+ modules, or with 10GBASE-T phys. Signed-off-by: Sean Anderson Acked-by: Rob Herring --- PR increasing phy-type maximum [1]. If this commit could be applied sooner rather than later, I'd appreciate it. This should help avoid another respin if someone else adds another phy type. [1] https://github.com/devicetree-org/dt-schema/pull/85 (no changes since v6) Changes in v6: - Bump PHY_TYPE_2500BASEX to 13, since PHY_TYPE_USXGMII was added in the meantime Changes in v4: - New include/dt-bindings/phy/phy.h | 2 ++ 1 file changed, 2 insertions(+) diff --git a/include/dt-bindings/phy/phy.h b/include/dt-bindings/phy/phy.h index 6b901b342348..5b2b674d8d25 100644 --- a/include/dt-bindings/phy/phy.h +++ b/include/dt-bindings/phy/phy.h @@ -23,5 +23,7 @@ #define PHY_TYPE_DPHY 10 #define PHY_TYPE_CPHY 11 #define PHY_TYPE_USXGMII 12 +#define PHY_TYPE_2500BASEX 13 +#define PHY_TYPE_10GBASER 14 #endif /* _DT_BINDINGS_PHY */ -- 2.35.1.1320.gc452695387.dirty
[PATCH v11 04/13] dt-bindings: gpio-mmio: Add compatible for QIXIS
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 .../devicetree/bindings/gpio/gpio-mmio.yaml| 14 ++ 1 file changed, 10 insertions(+), 4 deletions(-) diff --git a/Documentation/devicetree/bindings/gpio/gpio-mmio.yaml b/Documentation/devicetree/bindings/gpio/gpio-mmio.yaml index 10a93a92ed78..67975a464c59 100644 --- a/Documentation/devicetree/bindings/gpio/gpio-mmio.yaml +++ b/Documentation/devicetree/bindings/gpio/gpio-mmio.yaml @@ -20,10 +20,16 @@ properties: big-endian: true compatible: -enum: - - brcm,bcm6345-gpio # Broadcom BCM6345 GPIO controller - - wd,mbl-gpio # Western Digital MyBook Live memory-mapped GPIO controller - - ni,169445-nand-gpio # National Instruments 169445 GPIO NAND controller +oneOf: + - enum: + - brcm,bcm6345-gpio # Broadcom BCM6345 GPIO controller + - wd,mbl-gpio # Western Digital MyBook Live memory-mapped GPIO controller + - ni,169445-nand-gpio # National Instruments 169445 GPIO NAND controller + - items: + - enum: + - fsl,fpga-qixis-los-stat + - fsl,fpga-qixis-brdcfg9 + - const: ni,169445-nand-gpio '#gpio-cells': const: 2 -- 2.35.1.1320.gc452695387.dirty
[PATCH v11 03/13] dt-bindings: Convert gpio-mmio to yaml
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 have not specified one.
Rename brcm,bcm6345-gpio to brcm,bcm63xx-gpio to reflect that bcm6345
has moved.
Signed-off-by: Sean Anderson
Reviewed-by: Linus Walleij
---
Linus or Bartosz, feel free to pick this up as the rest of this series
may not be merged any time soon.
Changes in v11:
- Keep empty (or almost-empty) properties on a single line
- Don't use | unnecessarily
- Use gpio as the node name for examples
- Rename brcm,bcm6345-gpio.yaml to brcm,bcm63xx-gpio.yaml
Changes in v10:
- New
...m6345-gpio.yaml => brcm,bcm63xx-gpio.yaml} | 16 +--
.../devicetree/bindings/gpio/gpio-mmio.yaml | 134 ++
.../bindings/gpio/ni,169445-nand-gpio.txt | 38 -
.../devicetree/bindings/gpio/wd,mbl-gpio.txt | 38 -
4 files changed, 135 insertions(+), 91 deletions(-)
rename Documentation/devicetree/bindings/gpio/{brcm,bcm6345-gpio.yaml =>
brcm,bcm63xx-gpio.yaml} (78%)
create mode 100644 Documentation/devicetree/bindings/gpio/gpio-mmio.yaml
delete mode 100644
Documentation/devicetree/bindings/gpio/ni,169445-nand-gpio.txt
delete mode 100644 Documentation/devicetree/bindings/gpio/wd,mbl-gpio.txt
diff --git a/Documentation/devicetree/bindings/gpio/brcm,bcm6345-gpio.yaml
b/Documentation/devicetree/bindings/gpio/brcm,bcm63xx-gpio.yaml
similarity index 78%
rename from Documentation/devicetree/bindings/gpio/brcm,bcm6345-gpio.yaml
rename to Documentation/devicetree/bindings/gpio/brcm,bcm63xx-gpio.yaml
index 4d69f79df859..e11f4af49c52 100644
--- a/Documentation/devicetree/bindings/gpio/brcm,bcm6345-gpio.yaml
+++ b/Documentation/devicetree/bindings/gpio/brcm,bcm63xx-gpio.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/gpio/brcm,bcm6345-gpio.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Broadcom BCM6345 GPIO controller
+title: Broadcom BCM63xx GPIO controller
maintainers:
- Álvaro Fernández Rojas
@@ -18,8 +18,6 @@ description: |+
BCM6338 have 8-bit data and dirout registers, where GPIO state can be read
and/or written, and the direction changed from input to output.
- BCM6345 have 16-bit data and dirout registers, where GPIO state can be read
- and/or written, and the direction changed from input to output.
BCM6318, BCM6328, BCM6358, BCM6362, BCM6368 and BCM63268 have 32-bit data
and dirout registers, where GPIO state can be read and/or written, and the
direction changed from input to output.
@@ -29,7 +27,6 @@ properties:
enum:
- brcm,bcm6318-gpio
- brcm,bcm6328-gpio
- - brcm,bcm6345-gpio
- brcm,bcm6358-gpio
- brcm,bcm6362-gpio
- brcm,bcm6368-gpio
@@ -63,17 +60,6 @@ required:
additionalProperties: false
examples:
- - |
-gpio@fffe0406 {
- compatible = "brcm,bcm6345-gpio";
- reg-names = "dirout", "dat";
- reg = <0xfffe0406 2>, <0xfffe040a 2>;
- native-endian;
-
- gpio-controller;
- #gpio-cells = <2>;
-};
-
- |
gpio@0 {
compatible = "brcm,bcm63268-gpio";
diff --git a/Documentation/devicetree/bindings/gpio/gpio-mmio.yaml
b/Documentation/devicetree/bindings/gpio/gpio-mmio.yaml
new file mode 100644
index ..10a93a92ed78
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpio/gpio-mmio.yaml
@@ -0,0 +1,134 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/gpio/gpio-mmio.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Generic MMIO GPIO
+
+maintainers:
+ - Linus Walleij
+ - Bartosz Golaszewski
+
+description:
+ Some simple GPIO controllers may consist of a single data register or a pair
+ of set/clear-bit registers. Such controllers are common for glue logic in
+ FPGAs or ASICs. Commonly, these controllers are accessed over memory-mapped
+ NAND-style parallel busses.
+
+properties:
+ big-endian: true
+
+ compatible:
+enum:
+ - brcm,bcm6345-gpio # Broadcom BCM6345 GPIO controller
+ - wd,mbl-gpio # Western Digital MyBook Live memory-mapped GPIO controller
+ - ni,169445-nand-gpio # National Instruments 169445 GPIO NAND controller
+
+ '#gpio-cells':
+const: 2
+
+ gpio-controller:
+true
+
+ reg:
+minItems: 1
+description:
+ A list of registers in the controller. The width of each register is
+ determined by its size. All registers must have the same width. The
number
+ of GPIOs is set by the width, with bit 0 corresponding to GPIO 0.
+items:
+ - description:
+ Register to READ the value of the GPIO lines. If GPIO line is high,
+ the bit will be set. If the GPIO line is low, the bit will be
cleared.
+ This register may also be used to drive GPIOs if
[PATCH v11 02/13] dt-bindings: phy: Add Lynx 10G phy binding
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 select a protocol-controller/lane combination vary across different SoCs, and even within different SerDes on the same SoC. The driver is designed to be able to completely reconfigure lanes at runtime. Generally, the phy consumer can select the appropriate protocol using set_mode. There are two PLLs, each of which can be used as the master clock for each lane. Each PLL has its own reference. For the moment they are required, because it simplifies the driver implementation. Absent reference clocks can be modeled by a fixed-clock with a rate of 0. Signed-off-by: Sean Anderson Reviewed-by: Rob Herring --- (no changes since v9) Changes in v9: - Add fsl,unused-lanes-reserved to allow for a gradual transition between firmware and Linux control of the SerDes - Change phy-type back to fsl,type, as I was getting the error '#phy-cells' is a dependency of 'phy-type' Changes in v7: - Use double quotes everywhere in yaml Changes in v6: - fsl,type -> phy-type Changes in v4: - Use subnodes to describe lane configuration, instead of describing PCCRs. This is the same style used by phy-cadence-sierra et al. Changes in v3: - Manually expand yaml references - Add mode configuration to device tree Changes in v2: - Rename to fsl,lynx-10g.yaml - Refer to the device in the documentation, rather than the binding - Move compatible first - Document phy cells in the description - Allow a value of 1 for phy-cells. This allows for compatibility with the similar (but according to Ioana Ciornei different enough) lynx-28g binding. - Remove minItems - Use list for clock-names - Fix example binding having too many cells in regs - Add #clock-cells. This will allow using assigned-clocks* to configure the PLLs. - Document the structure of the compatible strings .../devicetree/bindings/phy/fsl,lynx-10g.yaml | 248 ++ 1 file changed, 248 insertions(+) create mode 100644 Documentation/devicetree/bindings/phy/fsl,lynx-10g.yaml diff --git a/Documentation/devicetree/bindings/phy/fsl,lynx-10g.yaml b/Documentation/devicetree/bindings/phy/fsl,lynx-10g.yaml new file mode 100644 index ..7c364f7de85c --- /dev/null +++ b/Documentation/devicetree/bindings/phy/fsl,lynx-10g.yaml @@ -0,0 +1,248 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/phy/fsl,lynx-10g.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: NXP Lynx 10G SerDes + +maintainers: + - Sean Anderson + +description: | + These Lynx "SerDes" devices are found in NXP's QorIQ line of processors. The + SerDes provides up to eight lanes. Each lane may be configured individually, + or may be combined with adjacent lanes for a multi-lane protocol. The SerDes + supports a variety of protocols, including up to 10G Ethernet, PCIe, SATA, and + others. The specific protocols supported for each lane depend on the + particular SoC. + +properties: + compatible: +items: + - enum: + - fsl,ls1046a-serdes + - fsl,ls1088a-serdes + - const: fsl,lynx-10g + + "#address-cells": +const: 1 + + "#size-cells": +const: 0 + + "#clock-cells": +const: 1 +description: | + The cell contains an ID as described in dt-bindings/clock/fsl,lynx-10g.h. + Note that when assigning a rate to a PLL, the PLL's rate is divided by + 1000 to avoid overflow. A rate of 500 corresponds to 5GHz. + + clocks: +maxItems: 2 +description: | + Clock for each PLL reference clock input. + + clock-names: +minItems: 2 +maxItems: 2 +items: + enum: +- ref0 +- ref1 + + fsl,unused-lanes-reserved: +$ref: /schemas/types.yaml#/definitions/flag +description: | + Unused lanes are reserved for firmware use, and should not be disabled. + Normally, groups containing unused lanes may be reconfigured or disabled + to save power. However, when this property is present, unused lanes will + not be touched until they are used by another driver. This allows + migrating from firmware control of lanes to driver control. + + Lanes not present in any group will never be modified, regardless of the + presence of this property. + + reg: +maxItems: 1 + +patternProperties: + "^phy@": +type: object + +description: | + A contiguous group of lanes which will be configured together. Each group + corresponds to one phy device. Lanes not described by any group will be + left as-is. + +properties: + "#phy-cells": +const: 0 + + reg: +minItems: 1 +maxItems: 8 +description: + The lanes in the group. These
[PATCH v11 00/13] phy: Add support for Lynx 10G SerDes
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 and there are no outstanding issues. Major reconfiguration of baud rate (e.g. 1G->10G) does not work. From my testing, SerDes register settings appear identical. The issue appears to be between the PCS and the MAC. The link itself comes up at both ends, and a mac loopback succeeds. However, a PCS loopback results in dropped packets. Perhaps there is some undocumented register in the PCS? I suspect this driver is around 95% complete, but I don't have the documentation to make it work completely. At the very least it is useful for two cases: - Although this is untested, it should support 2.5G SGMII as well as 1000BASE-KX. The latter needs MAC and PCS support, but the former should work out of the box. - It allows for clock configurations not supported by the RCW. This is very useful if you want to use e.g. SRDS_PRTCL_S1=0x and =0x1133 on the same board. This is because the former setting will use PLL1 as the 1G reference, but the latter will use PLL1 as the 10G reference. Because we can reconfigure the PLLs, it is possible to always use PLL1 as the 1G reference. Changes in v11: - Keep empty (or almost-empty) properties on a single line - Don't use | unnecessarily - Use gpio as the node name for examples - Rename brcm,bcm6345-gpio.yaml to brcm,bcm63xx-gpio.yaml Changes in v10: - Convert gpio-mmio to yaml - Add compatible for QIXIS - Remove unnecessary inclusion of clk.h - Don't gate clocks in compatibility mode - Fix debugging print with incorrect error variable - Move serdes bindings to SoC dtsi - Add support for all (ethernet) serdes modes - Refer to "nodes" instead of "bindings" - Move compatible/reg first Changes in v9: - Add fsl,unused-lanes-reserved to allow for a gradual transition between firmware and Linux control of the SerDes - Change phy-type back to fsl,type, as I was getting the error '#phy-cells' is a dependency of 'phy-type' - Convert some u32s to unsigned long to match arguments - Switch from round_rate to determine_rate - Drop explicit reference to reference clock - Use .parent_names when requesting parents - Use devm_clk_hw_get_clk to pass clocks back to serdes - Fix indentation - Split off clock "driver" into its own patch to allow for better review. - Add ability to defer lane initialization to phy_init. This allows for easier transitioning between firmware-managed serdes and Linux- managed serdes, as the consumer (such as dpaa2, which knows what the firmware is doing) has the last say on who gets control. - Fix name of phy mode node - Add fsl,unused-lanes-reserved to allow a gradual transition, depending on the mac link type. - Remove unused clocks - Fix some phy mode node names Changes in v8: - Remove unused variable from lynx_ls_mode_init - Rename serdes phy handles to use _A, _B, etc. instead of _0, _1, etc. This should help remind readers that the numbering corresponds to the physical layout of the registers, and not the lane (pin) number. - Prevent PCSs from probing as phys - Rename serdes phy handles like the LS1046A - Add SFP slot binding - Fix incorrect lane ordering (it's backwards on the LS1088A just like it is in the LS1046A). - Fix duplicated lane 2 (it should have been lane 3). - Fix incorrectly-documented value for XFI1. - Remove interrupt for aquantia phy. It never fired for whatever reason, preventing the link from coming up. - Add GPIOs for QIXIS FPGA. - Enable MAC1 PCS - Remove si5341 binding Changes in v7: - Use double quotes everywhere in yaml - Break out call order into generic documentation - Refuse to switch "major" protocols - Update Kconfig to reflect restrictions - Remove set/clear of "pcs reset" bit, since it doesn't seem to fix anything. Changes in v6: - Bump PHY_TYPE_2500BASEX to 13, since PHY_TYPE_USXGMII was added in the meantime - fsl,type -> phy-type - frequence -> frequency - Update MAINTAINERS to include new files - Include bitfield.h and slab.h to allow compilation on non-arm64 arches. - Depend on COMMON_CLK and either layerscape/ppc - XGI.9 -> XFI.9 Changes in v5: - Update commit description - Dual id header - Remove references to PHY_INTERFACE_MODE_1000BASEKX to allow this series to be applied directly to linux/master. - Add fsl,lynx-10g.h to MAINTAINERS Changes in v4: - Add 2500BASE-X and 10GBASE-R phy types - Use subnodes to describe lane configuration, instead of describing PCCRs. This is the same style used by phy-cadence-sierra et al. - Add ids for Lynx 10g PLLs - Rework all debug statements to remove use of __func__. Additional information has been provided as necessary. - Consider alternative parent rates in round_rate and not in set_rate. Trying to modify out parent's rate in
[PATCH v11 05/13] dt-bindings: clock: Add ids for Lynx 10g PLLs
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 driver. Signed-off-by: Sean Anderson Acked-by: Rob Herring --- (no changes since v6) Changes in v6: - frequence -> frequency Changes in v5: - Update commit description - Dual id header Changes in v4: - New include/dt-bindings/clock/fsl,lynx-10g.h | 14 ++ 1 file changed, 14 insertions(+) create mode 100644 include/dt-bindings/clock/fsl,lynx-10g.h diff --git a/include/dt-bindings/clock/fsl,lynx-10g.h b/include/dt-bindings/clock/fsl,lynx-10g.h new file mode 100644 index ..15362ae85304 --- /dev/null +++ b/include/dt-bindings/clock/fsl,lynx-10g.h @@ -0,0 +1,14 @@ +/* SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause */ +/* + * Copyright (C) 2022 Sean Anderson + */ + +#ifndef __DT_BINDINGS_CLK_LYNX_10G_H +#define __DT_BINDINGS_CLK_LYNX_10G_H + +#define LYNX10G_CLKS_PER_PLL 2 + +#define LYNX10G_PLLa(a)((a) * LYNX10G_CLKS_PER_PLL) +#define LYNX10G_PLLa_EX_DLY(a) ((a) * LYNX10G_CLKS_PER_PLL + 1) + +#endif /* __DT_BINDINGS_CLK_LYNX_10G_H */ -- 2.35.1.1320.gc452695387.dirty
Re: [PATCH 0/6] bus: fsl-mc: Make remove function return void
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 error message. This series improves the fsl-mc bus by changing the remove callback to return no value instead. As a preparation all drivers are changed to return zero before so that they don't trigger the error message. Best regards Uwe Uwe Kleine-König (6): bus: fsl-mc: Only warn once about errors on device unbind bus: fsl-mc: dprc: Push down error message from fsl_mc_driver_remove() bus: fsl-mc: fsl-mc-allocator: Drop if block with always wrong condition bus: fsl-mc: fsl-mc-allocator: Improve error reporting soc: fsl: dpio: Suppress duplicated error reporting on device remove bus: fsl-mc: Make remove function return void Thanks for the series, Uwe. Did a quick boot test with ACPI, so: Reviewed-by: Laurentiu Tudor Tested-by: Laurentiu Tudor
Re: [PATCH v9 2/6] powerpc/crash: introduce a new config option CRASH_HOTPLUG
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 Memory hotplug events and it tries to collect the dump with the stale system resource data this might lead to dump collection failure or an inaccurate dump collection. The current method to keep the kdump kernel up to date is by triggering reload (i.e unload and load) the entire kdump kernel image whenever a CPU or Memory hotplug event is observed by udev in the userspace. Reloading the complete kdump kernel image is an expensive task. It can be easily avoided by doing the in-kernel updates to specific kdump kernel image components which are responsible for describing CPU and Memory resources of the running kernel to the kdump kernel. The kernel changes related to in-kernel update to the kdump kernel image on CPU/Memory hotplug events are kept under the CRASH_HOTPLUG config option. Later in the series, a powerpc crash hotplug handler is introduced to update the kdump kernel image on CPU/Memory hotplug events. This arch specific handler is trigger from a generic crash handler that registers with the CPU and memory notifiers. The CRASH_HOTPLUG config option is enabled by default. Signed-off-by: Sourabh Jain --- arch/powerpc/Kconfig | 12 1 file changed, 12 insertions(+) diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig index a6c4407d3ec83..2f45b3f5175cb 100644 --- a/arch/powerpc/Kconfig +++ b/arch/powerpc/Kconfig @@ -681,6 +681,18 @@ config CRASH_DUMP The same kernel binary can be used as production kernel and dump capture kernel. +config CRASH_HOTPLUG + bool "Update crash capture system on CPU/Memory hotplug event" Fwiw, online/offline changes also flow through this infrastructure... eric + default y + depends on CRASH_DUMP && (HOTPLUG_CPU || MEMORY_HOTPLUG) + help + In kernel update to relevant kexec segments due to change + in the system configuration, rather reloading all the kexec + segments again from userspace by monitoring CPU/Memory + hotplug events in the userspace using udev. + + If unsure, say N. + config FA_DUMP bool "Firmware-assisted dump" depends on PPC64 && (PPC_RTAS || PPC_POWERNV)
Re: [PATCH v9 0/6] PowerPC: in kernel handling of CPU hotplug events for crash kernel
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:
==
The existing solution to keep the capture kernel up-to-date by monitoring
hotplug event via udev rule and trigger a full capture kernel reload for
every hotplug event.
Shortcomings:
- Leaves a window where kernel crash might not lead to a successful dump
collection.
- Reloading all kexec components for each hotplug is inefficient.
- udev rules are prone to races if hotplug events are frequent.
More about issues with an existing solution is posted here:
- https://lkml.org/lkml/2020/12/14/532
- https://lists.ozlabs.org/pipermail/linuxppc-dev/2022-February/240254.html
Proposed Solution:
==
Instead of reloading all kexec segments on hotplug event, this patch series
focuses on updating only the relevant kexec segment. Once the kexec segments
are loaded in the kernel reserved area then an arch-specific hotplug handler
will update the relevant kexec segment based on hotplug event type.
Series Dependecies
==
This patch series implements the crash hotplug handler on PowerPC. The generic
crash hotplug update is introduced by https://lkml.org/lkml/2023/3/6/1358 patch
series.
Git tree for testing:
=
The below git tree has this patch series applied on top of dependent patch
series.
https://github.com/sourabhjains/linux/tree/in-kernel-crash-update-v9
To realise the feature the kdump udev rules must be disabled for CPU/Memory
hotplug events. Comment out the below line in kdump udev rule file:
RHEL: /usr/lib/udev/rules.d/98-kexec.rules
#SUBSYSTEM=="cpu", ACTION=="online", GOTO="kdump_reload_cpu"
#SUBSYSTEM=="memory", ACTION=="online", GOTO="kdump_reload_mem"
#SUBSYSTEM=="memory", ACTION=="offline", GOTO="kdump_reload_mem"
SLES: /usr/lib/kdump/70-kdump.rules
#SUBSYSTEM=="memory", ACTION=="add|remove", GOTO="kdump_try_restart"
#SUBSYSTEM=="cpu", ACTION=="online", GOTO="kdump_try_restart"
Sourabh,
The above seems to contradict what I anticipate to be udev rules changes once the base series is
accepted. Specifically I'm suggesting the following:
- Prevent udev from updating kdump crash kernel on hot un/plug changes.
Add the following as the first lines to the RHEL udev rule file
/usr/lib/udev/rules.d/98-kexec.rules:
# The kernel handles updates to crash elfcorehdr for cpu and memory changes
SUBSYSTEM=="cpu", ATTRS{crash_hotplug}=="1", GOTO="kdump_reload_end"
SUBSYSTEM=="memory", ATTRS{crash_hotplug}=="1", GOTO="kdump_reload_end"
With this changeset applied, the two rules evaluate to false for
cpu and memory change events and thus skip the userspace
unload-then-reload of kdump.
The above additions allow distros to deploy the udev rule immediately and work properly even if the
base patchset isn't yet merged, or down the road, enabled/configured.
Am I missing something such that your recommendation is different than mine?
Note: only kexec_file_load syscall will work. For kexec_load minor
changes are required in kexec tool.
Will this be the same/similar change as I have posted, or do you envision
something different?
Thanks,
eric
---
Changelog:
v9:
- Removed patch to prepare elfcorehdr crash notes for possible CPUs.
The patch is moved to generic patch series that introduces generic
infrastructure for in kernel crash update.
- Removed patch to pass the hotplug action type to the arch crash
hotplug handler function. The generic patch series has introduced
the hotplug action type in kimage struct.
- Add detail commit message for better understanding.
v8:
- Restrict fdt_index initialization to machine_kexec_post_load
it work for both kexec_load and kexec_file_load.[3/8] Laurent Dufour
- Updated the logic to find the number of offline core. [6/8]
- Changed the logic to find the elfcore program header to accommodate
future memory ranges due memory hotplug events. [8/8]
v7
- added a new config to configure this feature
- pass hotplug action type to arch specific handler
v6
- Added crash memory hotplug support
v5:
- Replace COFNIG_CRASH_HOTPLUG with CONFIG_HOTPLUG_CPU.
- Move fdt segment identification for kexec_load case to load path
instead of crash hotplug handler
- Keep new attribute defined under kimage_arch to track FDT segment
under CONFIG_HOTPLUG_CPU config.
v4:
- Update the logic to find the additional space needed for hotadd CPUs post
kexec load. Refer "[RFC v4 PATCH 4/5] powerpc/crash hp: add crash hotplug
support for kexec_file_load" patch to know more about the change.
- Fix a couple of typo.
- Replace pr_err to
Re: [PATCH net-next 0/9] net: freescale: Convert to platform remove callback returning void
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 core (mostly) ignores the return value and still removes the device > binding. This is part of a bigger effort to convert all 2000+ platform > drivers to this new callback to eventually change .remove() itself to > return void. > > The first two patches here are preparation, the following patches > actually convert the drivers. > > Best regards > Uwe > For entire series: Reviewed-by: Michal Kubiak > Uwe Kleine-König (9): > net: dpaa: Improve error reporting > net: fec: Don't return early on error in .remove() > net: dpaa: Convert to platform remove callback returning void > net: fec: Convert to platform remove callback returning void > net: fman: Convert to platform remove callback returning void > net: fs_enet: Convert to platform remove callback returning void > net: fsl_pq_mdio: Convert to platform remove callback returning void > net: gianfar: Convert to platform remove callback returning void > net: ucc_geth: Convert to platform remove callback returning void > > drivers/net/ethernet/freescale/dpaa/dpaa_eth.c| 8 > drivers/net/ethernet/freescale/fec_main.c | 11 --- > drivers/net/ethernet/freescale/fec_mpc52xx.c | 6 ++ > drivers/net/ethernet/freescale/fec_mpc52xx_phy.c | 6 ++ > drivers/net/ethernet/freescale/fman/mac.c | 5 ++--- > drivers/net/ethernet/freescale/fs_enet/fs_enet-main.c | 5 ++--- > drivers/net/ethernet/freescale/fs_enet/mii-bitbang.c | 6 ++ > drivers/net/ethernet/freescale/fs_enet/mii-fec.c | 6 ++ > drivers/net/ethernet/freescale/fsl_pq_mdio.c | 6 ++ > drivers/net/ethernet/freescale/gianfar.c | 6 ++ > drivers/net/ethernet/freescale/ucc_geth.c | 6 ++ > 11 files changed, 26 insertions(+), 45 deletions(-) > > base-commit: fe15c26ee26efa11741a7b632e9f23b01aca4cc6 > -- > 2.39.1 >
Re: [PATCH v10 03/13] dt-bindings: Convert gpio-mmio to yaml
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-fix-v2-1-38397aace...@ncr.com/__;!!In4Qlw!uQKGkt7dO5TA-561XcuPNoqyti_AogqJ0cV3ymFZNob-Q1-Z1xmcOv_22JBP5xO-OIemaCZ1VY37nWLIe1AXyOkieg$ >> >> Thanks for linking to that. >> >> I believe this patch should be applied instead of that one because >> >> - It documents all the registers, which were previously only documented >>in the driver >> - It handles the endianness properties. >> - It consolidates the various descriptions of this binding into one >>schema. > > Niall are you sending a v3 of this patch soon? > Include Sean on the reviewer list! > > Yours, > Linus Walleij 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 patch being accepted and then I could re-submit the driver changes. What's the consensus ? Regards, Niall.
Re: [PATCH v10 03/13] dt-bindings: Convert gpio-mmio to yaml
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 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-fix-v2-1-38397aace...@ncr.com/__;!!In4Qlw!uQKGkt7dO5TA-561XcuPNoqyti_AogqJ0cV3ymFZNob-Q1-Z1xmcOv_22JBP5xO-OIemaCZ1VY37nWLIe1AXyOkieg$ >>> >>> Thanks for linking to that. >>> >>> I believe this patch should be applied instead of that one because >>> >>> - It documents all the registers, which were previously only documented >>>in the driver >>> - It handles the endianness properties. >>> - It consolidates the various descriptions of this binding into one >>>schema. >> >> Niall are you sending a v3 of this patch soon? >> Include Sean on the reviewer list! >> >> Yours, >> Linus Walleij > 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 patch being accepted and > then I could re-submit the driver changes. > What's the consensus ? I am going to submit v11 later today. However, the phy subsystem maintainer refuses to review the phy patches until all the other patches are ready. Therefore, I suspect v11 may not be the last revision of this series. If the GPIO folks want to pick v11 of this patch separately, I think that would help accelerate the process. --Sean
Re: [PATCH 0/6] bus: fsl-mc: Make remove function return void
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 error code only yields an error message. > > This series improves the fsl-mc bus by changing the remove callback to > return no value instead. As a preparation all drivers are changed to > return zero before so that they don't trigger the error message. > > Best regards > Uwe > > Uwe Kleine-König (6): > bus: fsl-mc: Only warn once about errors on device unbind > bus: fsl-mc: dprc: Push down error message from fsl_mc_driver_remove() > bus: fsl-mc: fsl-mc-allocator: Drop if block with always wrong > condition > bus: fsl-mc: fsl-mc-allocator: Improve error reporting > soc: fsl: dpio: Suppress duplicated error reporting on device remove > bus: fsl-mc: Make remove function return void > Reviewed-by: Ioana Ciornei Tested-by: Ioana Ciornei # sanity checks
boot regression on ppc64 with linux 6.2
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: swapper/0 Tainted: GW 6.2.2-kc #1
Hardware name: IBM pSeries (emulated by qemu) POWER9 (raw) 0x4e1200 0xf05
of:SLOF,HEAD pSeries
NIP: c2022eec LR: c2022ee8 CTR:
REGS: c3483910 TRAP: 0700 Tainted: GW (6.2.2-kc)
MSR: 82029033 CR: 24483200 XER:
CFAR: c0180838 IRQMASK: 0
GPR00: c2022ee8 c3483bb0 c1a5ce00 0050
GPR04: c2437d78 c2437e28 0001 0001
GPR08: c2437d00 0001 44483200
GPR12: c272 c0012758
GPR16:
GPR20:
GPR24: c20033fc cccd c00e07f0
GPR28: c0db0520 c000fff92ac0 0017
NIP [c2022eec] request_event_sources_irqs+0xbc/0xf0
LR [c2022ee8] request_event_sources_irqs+0xb8/0xf0
Call Trace:
[c3483bb0] [c2022ee8] request_event_sources_irqs+0xb8/0xf0
(unreliable)
[c3483c40] [c2022fa0]
__machine_initcall_pseries_init_ras_hotplug_IRQ+0x80/0xb0
[c3483c70] [c00121b8] do_one_initcall+0x98/0x300
[c3483d50] [c2004b28] kernel_init_freeable+0x2ec/0x370
[c3483df0] [c0012780] kernel_init+0x30/0x190
[c3483e50] [c000cf5c] ret_from_kernel_thread+0x5c/0x64
--- interrupt: 0 at 0x0
I did a bisect it and it seems that the offending commit is:
baa49d81a94b ("powerpc/pseries: hvcall stack frame overhead")
Reverting that and also dfecd06bc552 ("powerpc: remove
STACK_FRAME_OVERHEAD"), because we need to re-introduce
STACK_FRAME_OVERHEAD, seems to fix everything.
-Andrea
Re: [PATCH] PCI: Use of_property_present() for testing DT property presence
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 recently added of_property_present() helper when we just want to test for presence of a property and nothing more. Signed-off-by: Rob Herring Reviewed-by: AngeloGioacchino Del Regno # pcie-mediatek
RE: [PATCH net-next 0/9] net: freescale: Convert to platform remove callback returning void
> -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 > ; Michael Ellerman ; > Mark Brown ; Marc Kleine-Budde ; > Pantelis Antoniou ; Claudiu Manoil > ; Leo Li > Cc: net...@vger.kernel.org; ker...@pengutronix.de; Shenwei Wang > ; Clark Wang ; dl-linux-imx > ; linuxppc-dev@lists.ozlabs.org > Subject: [PATCH net-next 0/9] net: freescale: Convert to platform remove > callback returning void > > 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. This is part of a bigger effort to convert all 2000+ platform > drivers to this new callback to eventually change .remove() itself to > return void. > > The first two patches here are preparation, the following patches > actually convert the drivers. > > Best regards > Uwe > > Uwe Kleine-König (9): > net: dpaa: Improve error reporting > net: fec: Don't return early on error in .remove() > net: dpaa: Convert to platform remove callback returning void > net: fec: Convert to platform remove callback returning void > net: fman: Convert to platform remove callback returning void > net: fs_enet: Convert to platform remove callback returning void > net: fsl_pq_mdio: Convert to platform remove callback returning void > net: gianfar: Convert to platform remove callback returning void > net: ucc_geth: Convert to platform remove callback returning void > > drivers/net/ethernet/freescale/dpaa/dpaa_eth.c| 8 > drivers/net/ethernet/freescale/fec_main.c | 11 --- > drivers/net/ethernet/freescale/fec_mpc52xx.c | 6 ++ > drivers/net/ethernet/freescale/fec_mpc52xx_phy.c | 6 ++ > drivers/net/ethernet/freescale/fman/mac.c | 5 ++--- > drivers/net/ethernet/freescale/fs_enet/fs_enet-main.c | 5 ++--- > drivers/net/ethernet/freescale/fs_enet/mii-bitbang.c | 6 ++ > drivers/net/ethernet/freescale/fs_enet/mii-fec.c | 6 ++ > drivers/net/ethernet/freescale/fsl_pq_mdio.c | 6 ++ > drivers/net/ethernet/freescale/gianfar.c | 6 ++ > drivers/net/ethernet/freescale/ucc_geth.c | 6 ++ > 11 files changed, 26 insertions(+), 45 deletions(-) > > base-commit: fe15c26ee26efa11741a7b632e9f23b01aca4cc6 > -- > 2.39.1 For the FMan and DPAA drivers, Acked-by: Madalin Bucur
[PATCH net-next 0/9] net: freescale: Convert to platform remove callback returning void
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. This is part of a bigger effort to convert all 2000+ platform drivers to this new callback to eventually change .remove() itself to return void. The first two patches here are preparation, the following patches actually convert the drivers. Best regards Uwe Uwe Kleine-König (9): net: dpaa: Improve error reporting net: fec: Don't return early on error in .remove() net: dpaa: Convert to platform remove callback returning void net: fec: Convert to platform remove callback returning void net: fman: Convert to platform remove callback returning void net: fs_enet: Convert to platform remove callback returning void net: fsl_pq_mdio: Convert to platform remove callback returning void net: gianfar: Convert to platform remove callback returning void net: ucc_geth: Convert to platform remove callback returning void drivers/net/ethernet/freescale/dpaa/dpaa_eth.c| 8 drivers/net/ethernet/freescale/fec_main.c | 11 --- drivers/net/ethernet/freescale/fec_mpc52xx.c | 6 ++ drivers/net/ethernet/freescale/fec_mpc52xx_phy.c | 6 ++ drivers/net/ethernet/freescale/fman/mac.c | 5 ++--- drivers/net/ethernet/freescale/fs_enet/fs_enet-main.c | 5 ++--- drivers/net/ethernet/freescale/fs_enet/mii-bitbang.c | 6 ++ drivers/net/ethernet/freescale/fs_enet/mii-fec.c | 6 ++ drivers/net/ethernet/freescale/fsl_pq_mdio.c | 6 ++ drivers/net/ethernet/freescale/gianfar.c | 6 ++ drivers/net/ethernet/freescale/ucc_geth.c | 6 ++ 11 files changed, 26 insertions(+), 45 deletions(-) base-commit: fe15c26ee26efa11741a7b632e9f23b01aca4cc6 -- 2.39.1
[PATCH net-next 9/9] net: ucc_geth: Convert to platform remove callback returning void
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 make the remove callback return void. In the first step of this
quest all drivers are converted to .remove_new() which already returns
void.
Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.
Signed-off-by: Uwe Kleine-König
---
drivers/net/ethernet/freescale/ucc_geth.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/freescale/ucc_geth.c
b/drivers/net/ethernet/freescale/ucc_geth.c
index 7a4cb4f07c32..2b3a15f24e7c 100644
--- a/drivers/net/ethernet/freescale/ucc_geth.c
+++ b/drivers/net/ethernet/freescale/ucc_geth.c
@@ -3753,7 +3753,7 @@ static int ucc_geth_probe(struct platform_device* ofdev)
return err;
}
-static int ucc_geth_remove(struct platform_device* ofdev)
+static void ucc_geth_remove(struct platform_device* ofdev)
{
struct net_device *dev = platform_get_drvdata(ofdev);
struct ucc_geth_private *ugeth = netdev_priv(dev);
@@ -3767,8 +3767,6 @@ static int ucc_geth_remove(struct platform_device* ofdev)
of_node_put(ugeth->ug_info->phy_node);
kfree(ugeth->ug_info);
free_netdev(dev);
-
- return 0;
}
static const struct of_device_id ucc_geth_match[] = {
@@ -3787,7 +3785,7 @@ static struct platform_driver ucc_geth_driver = {
.of_match_table = ucc_geth_match,
},
.probe = ucc_geth_probe,
- .remove = ucc_geth_remove,
+ .remove_new = ucc_geth_remove,
.suspend= ucc_geth_suspend,
.resume = ucc_geth_resume,
};
--
2.39.1
[PATCH net-next 6/9] net: fs_enet: Convert to platform remove callback returning void
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 make the remove callback return void. In the first step of this
quest all drivers are converted to .remove_new() which already returns
void.
Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.
Signed-off-by: Uwe Kleine-König
---
drivers/net/ethernet/freescale/fs_enet/fs_enet-main.c | 5 ++---
drivers/net/ethernet/freescale/fs_enet/mii-bitbang.c | 6 ++
drivers/net/ethernet/freescale/fs_enet/mii-fec.c | 6 ++
3 files changed, 6 insertions(+), 11 deletions(-)
diff --git a/drivers/net/ethernet/freescale/fs_enet/fs_enet-main.c
b/drivers/net/ethernet/freescale/fs_enet/fs_enet-main.c
index 8844a9a04fcf..f9f5b28cc72e 100644
--- a/drivers/net/ethernet/freescale/fs_enet/fs_enet-main.c
+++ b/drivers/net/ethernet/freescale/fs_enet/fs_enet-main.c
@@ -1051,7 +1051,7 @@ static int fs_enet_probe(struct platform_device *ofdev)
return ret;
}
-static int fs_enet_remove(struct platform_device *ofdev)
+static void fs_enet_remove(struct platform_device *ofdev)
{
struct net_device *ndev = platform_get_drvdata(ofdev);
struct fs_enet_private *fep = netdev_priv(ndev);
@@ -1066,7 +1066,6 @@ static int fs_enet_remove(struct platform_device *ofdev)
if (of_phy_is_fixed_link(ofdev->dev.of_node))
of_phy_deregister_fixed_link(ofdev->dev.of_node);
free_netdev(ndev);
- return 0;
}
static const struct of_device_id fs_enet_match[] = {
@@ -1113,7 +1112,7 @@ static struct platform_driver fs_enet_driver = {
.of_match_table = fs_enet_match,
},
.probe = fs_enet_probe,
- .remove = fs_enet_remove,
+ .remove_new = fs_enet_remove,
};
#ifdef CONFIG_NET_POLL_CONTROLLER
diff --git a/drivers/net/ethernet/freescale/fs_enet/mii-bitbang.c
b/drivers/net/ethernet/freescale/fs_enet/mii-bitbang.c
index 21de56345503..91a69fc2f7c2 100644
--- a/drivers/net/ethernet/freescale/fs_enet/mii-bitbang.c
+++ b/drivers/net/ethernet/freescale/fs_enet/mii-bitbang.c
@@ -192,7 +192,7 @@ static int fs_enet_mdio_probe(struct platform_device *ofdev)
return ret;
}
-static int fs_enet_mdio_remove(struct platform_device *ofdev)
+static void fs_enet_mdio_remove(struct platform_device *ofdev)
{
struct mii_bus *bus = platform_get_drvdata(ofdev);
struct bb_info *bitbang = bus->priv;
@@ -201,8 +201,6 @@ static int fs_enet_mdio_remove(struct platform_device
*ofdev)
free_mdio_bitbang(bus);
iounmap(bitbang->dir);
kfree(bitbang);
-
- return 0;
}
static const struct of_device_id fs_enet_mdio_bb_match[] = {
@@ -219,7 +217,7 @@ static struct platform_driver fs_enet_bb_mdio_driver = {
.of_match_table = fs_enet_mdio_bb_match,
},
.probe = fs_enet_mdio_probe,
- .remove = fs_enet_mdio_remove,
+ .remove_new = fs_enet_mdio_remove,
};
module_platform_driver(fs_enet_bb_mdio_driver);
diff --git a/drivers/net/ethernet/freescale/fs_enet/mii-fec.c
b/drivers/net/ethernet/freescale/fs_enet/mii-fec.c
index d37d7a19a759..94bd76c6cf9e 100644
--- a/drivers/net/ethernet/freescale/fs_enet/mii-fec.c
+++ b/drivers/net/ethernet/freescale/fs_enet/mii-fec.c
@@ -187,7 +187,7 @@ static int fs_enet_mdio_probe(struct platform_device *ofdev)
return ret;
}
-static int fs_enet_mdio_remove(struct platform_device *ofdev)
+static void fs_enet_mdio_remove(struct platform_device *ofdev)
{
struct mii_bus *bus = platform_get_drvdata(ofdev);
struct fec_info *fec = bus->priv;
@@ -196,8 +196,6 @@ static int fs_enet_mdio_remove(struct platform_device
*ofdev)
iounmap(fec->fecp);
kfree(fec);
mdiobus_free(bus);
-
- return 0;
}
static const struct of_device_id fs_enet_mdio_fec_match[] = {
@@ -220,7 +218,7 @@ static struct platform_driver fs_enet_fec_mdio_driver = {
.of_match_table = fs_enet_mdio_fec_match,
},
.probe = fs_enet_mdio_probe,
- .remove = fs_enet_mdio_remove,
+ .remove_new = fs_enet_mdio_remove,
};
module_platform_driver(fs_enet_fec_mdio_driver);
--
2.39.1
Re: [PATCH] net: Use of_property_read_bool() for boolean properties
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 reading properties. Convert reading boolean properties to to of_property_read_bool(). Signed-off-by: Rob Herring --- drivers/net/can/cc770/cc770_platform.c | 12 ++-- drivers/net/ethernet/cadence/macb_main.c| 2 +- Acked-by: Nicolas Ferre drivers/net/ethernet/davicom/dm9000.c | 4 ++-- [..] --- a/drivers/net/ethernet/cadence/macb_main.c +++ b/drivers/net/ethernet/cadence/macb_main.c @@ -4990,7 +4990,7 @@ static int macb_probe(struct platform_device *pdev) bp->jumbo_max_len = macb_config->jumbo_max_len; bp->wol = 0; - if (of_get_property(np, "magic-packet", NULL)) + if (of_property_read_bool(np, "magic-packet")) bp->wol |= MACB_WOL_HAS_MAGIC_PACKET; device_set_wakeup_capable(>dev, bp->wol & MACB_WOL_HAS_MAGIC_PACKET); [..] -- Nicolas Ferre
Re: [PATCH V6 09/15] spi: Add stacked and parallel memories support in SPI core
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_index_mask" member. This acts as an
> index to the chip_select array. If nth bit of spi->cs_index_mask is set
> then the driver would assert spi->chip_select[n].
>
> In parallel mode all the chip selects are asserted/de-asserted
> simultaneously and each byte of data is stored in both devices, the even
> bits in one, the odd bits in the other. The split is automatically handled
> by the GQSPI controller. The GQSPI controller supports a maximum of two
> flashes connected in parallel mode. A "multi-cs-cap" flag is added in the
> spi controntroller data, through ctlr->multi-cs-cap the spi core will make
> sure that the controller is capable of handling multiple chip selects at
> once.
>
> For supporting multiple CS via GPIO the cs_gpiod member of the spi_device
> structure is now an array that holds the gpio descriptor for each
> chipselect.
>
> Multi CS support using GPIO is not tested due to unavailability of
> necessary hardware setup.
Can you pinmux your SPI controller's (cs) pins as GPIO? If so, you
should be able use that for testing.
>
> Signed-off-by: Amit Kumar Mahapatra
> ---
> drivers/spi/spi.c | 225 +++-
> include/linux/spi/spi.h | 34 --
> 2 files changed, 182 insertions(+), 77 deletions(-)
>
> diff --git a/drivers/spi/spi.c b/drivers/spi/spi.c
> index c725b4bab7af..742bd688381c 100644
> --- a/drivers/spi/spi.c
> +++ b/drivers/spi/spi.c
> @@ -612,10 +612,17 @@ static int spi_dev_check(struct device *dev, void *data)
> {
> struct spi_device *spi = to_spi_device(dev);
> struct spi_device *new_spi = data;
> -
> - if (spi->controller == new_spi->controller &&
> - spi_get_chipselect(spi, 0) == spi_get_chipselect(new_spi, 0))
> - return -EBUSY;
> + int idx, nw_idx;
> +
> + if (spi->controller == new_spi->controller) {
> + for (idx = 0; idx < SPI_CS_CNT_MAX; idx++) {
> + for (nw_idx = 0; nw_idx < SPI_CS_CNT_MAX; nw_idx++) {
> + if (spi_get_chipselect(spi, idx) ==
> + spi_get_chipselect(new_spi, nw_idx))
> + return -EBUSY;
> + }
> + }
AFAICT unused chip selects are initialized to 0, so all single chip
select devices would have it as their second one. This will then cause
this check to reject every single chip select device after the first
one. So you first need to make sure to only compare valid chip
selects.
So the loop condition should be something along idx <
spi_get_num_chipselect(), not idx < SPI_CS_CNT_MAX.
> + }
> return 0;
> }
>
> @@ -629,7 +636,7 @@ static int __spi_add_device(struct spi_device *spi)
> {
> struct spi_controller *ctlr = spi->controller;
> struct device *dev = ctlr->dev.parent;
> - int status;
> + int status, idx;
>
> /*
> * We need to make sure there's no other device with this
> @@ -638,8 +645,7 @@ static int __spi_add_device(struct spi_device *spi)
> */
> status = bus_for_each_dev(_bus_type, NULL, spi, spi_dev_check);
> if (status) {
> - dev_err(dev, "chipselect %d already in use\n",
> - spi_get_chipselect(spi, 0));
> + dev_err(dev, "chipselect %d already in use\n",
> spi_get_chipselect(spi, 0));
The message might be misleading for multi cs devices where the first
one is free, but the second one is already in use.
So maybe move this error message into spi_dev_check(), where you have
that information available. You then even have the chance to state
what is using the CS then, but that might be something for a different
patch.
> return status;
> }
>
> @@ -649,8 +655,10 @@ static int __spi_add_device(struct spi_device *spi)
> return -ENODEV;
> }
>
> - if (ctlr->cs_gpiods)
> - spi_set_csgpiod(spi, 0,
> ctlr->cs_gpiods[spi_get_chipselect(spi, 0)]);
> + if (ctlr->cs_gpiods) {
> + for (idx = 0; idx < SPI_CS_CNT_MAX; idx++)
> + spi_set_csgpiod(spi, idx,
> ctlr->cs_gpiods[spi_get_chipselect(spi, idx)]);
> + }
>
> /*
> * Drivers may modify this initial i/o setup, but will
> @@ -690,13 +698,15 @@ int spi_add_device(struct spi_device *spi)
> {
> struct spi_controller *ctlr = spi->controller;
> struct device *dev = ctlr->dev.parent;
> - int status;
> + int status, idx;
>
> - /* Chipselects are numbered 0..max; validate. */
> - if (spi_get_chipselect(spi, 0) >= ctlr->num_chipselect) {
> -
Re: [PATCH] net: Use of_property_read_bool() for boolean properties
Rob Herring writes: > 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. > Convert reading boolean properties to to of_property_read_bool(). > > Signed-off-by: Rob Herring > --- > drivers/net/can/cc770/cc770_platform.c | 12 ++-- > drivers/net/ethernet/cadence/macb_main.c| 2 +- > drivers/net/ethernet/davicom/dm9000.c | 4 ++-- > drivers/net/ethernet/freescale/fec_main.c | 2 +- > drivers/net/ethernet/freescale/fec_mpc52xx.c| 2 +- > drivers/net/ethernet/freescale/gianfar.c| 4 ++-- > drivers/net/ethernet/ibm/emac/core.c| 8 > drivers/net/ethernet/ibm/emac/rgmii.c | 2 +- > drivers/net/ethernet/stmicro/stmmac/dwmac-imx.c | 3 +-- > drivers/net/ethernet/sun/niu.c | 2 +- > drivers/net/ethernet/ti/cpsw-phy-sel.c | 3 +-- > drivers/net/ethernet/ti/netcp_ethss.c | 8 +++- > drivers/net/ethernet/via/via-velocity.c | 3 +-- > drivers/net/ethernet/xilinx/ll_temac_main.c | 9 - > drivers/net/wan/fsl_ucc_hdlc.c | 11 +++ > drivers/net/wireless/ti/wlcore/spi.c| 3 +-- > net/ncsi/ncsi-manage.c | 4 ++-- > 17 files changed, 35 insertions(+), 47 deletions(-) For wireless: Acked-by: Kalle Valo -- https://patchwork.kernel.org/project/linux-wireless/list/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
