* Re: [PATCH net-next v7 12/12] net: airoha: add phylink support
From: Benjamin Larsson @ 2026-06-15 16:07 UTC (permalink / raw)
To: Christian Marangi, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Simon Horman, Jonathan Corbet, Shuah Khan,
Lorenzo Bianconi, Heiner Kallweit, Russell King, Saravana Kannan,
Philipp Zabel, Nathan Chancellor, Nick Desaulniers, Bill Wendling,
Justin Stitt, netdev, devicetree, linux-kernel, linux-doc,
linux-arm-kernel, linux-mediatek, llvm
In-Reply-To: <20260615122950.22281-13-ansuelsmth@gmail.com>
Hi.
On 15/06/2026 14:29, Christian Marangi wrote:
> Add phylink support for each GDM port. For GDM1 add the internal interface
> mode as the only supported mode. For GDM2/3/4 add the required
> configuration of the PCS to make the external PHY or attached SFP cage
> work.
>
> These needs to be defined in the GDM port node using the pcs-handle
> property.
>
> Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
> ---
> drivers/net/ethernet/airoha/Kconfig | 1 +
> drivers/net/ethernet/airoha/airoha_eth.c | 161 +++++++++++++++++++++-
> drivers/net/ethernet/airoha/airoha_eth.h | 3 +
> drivers/net/ethernet/airoha/airoha_regs.h | 12 ++
> 4 files changed, 176 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/ethernet/airoha/Kconfig b/drivers/net/ethernet/airoha/Kconfig
> index ad3ce501e7a5..38dcc76e5998 100644
> --- a/drivers/net/ethernet/airoha/Kconfig
> +++ b/drivers/net/ethernet/airoha/Kconfig
> @@ -20,6 +20,7 @@ config NET_AIROHA
> depends on NET_DSA || !NET_DSA
> select NET_AIROHA_NPU
> select PAGE_POOL
> + select PHYLINK
> help
> This driver supports the gigabit ethernet MACs in the
> Airoha SoC family.
> diff --git a/drivers/net/ethernet/airoha/airoha_eth.c b/drivers/net/ethernet/airoha/airoha_eth.c
> index 5f1a118875fb..9a42fb991bd7 100644
> --- a/drivers/net/ethernet/airoha/airoha_eth.c
> +++ b/drivers/net/ethernet/airoha/airoha_eth.c
> @@ -8,6 +8,7 @@
> #include <linux/of_reserved_mem.h>
> #include <linux/platform_device.h>
> #include <linux/tcp.h>
> +#include <linux/pcs/pcs.h>
> #include <linux/u64_stats_sync.h>
> #include <net/dst_metadata.h>
> #include <net/page_pool/helpers.h>
> @@ -1810,6 +1811,14 @@ static int airoha_dev_open(struct net_device *netdev)
> u32 cur_len, pse_port = FE_PSE_PORT_PPE1;
> struct airoha_qdma *qdma = dev->qdma;
>
> + err = phylink_of_phy_connect(dev->phylink, netdev->dev.of_node, 0);
> + if (err) {
> + netdev_err(netdev, "could not attach PHY: %d\n", err);
> + return err;
> + }
> +
> + phylink_start(dev->phylink);
> +
> netif_tx_start_all_queues(netdev);
> err = airoha_set_vip_for_gdm_port(dev, true);
> if (err)
> @@ -1907,6 +1916,9 @@ static int airoha_dev_stop(struct net_device *netdev)
> }
> }
>
> + phylink_stop(dev->phylink);
> + phylink_disconnect_phy(dev->phylink);
> +
> return 0;
> }
>
> @@ -3168,6 +3180,151 @@ bool airoha_is_valid_gdm_dev(struct airoha_eth *eth,
> return false;
> }
>
> +/* Nothing to do in MAC, everything is handled in PCS */
> +static void airoha_mac_config(struct phylink_config *config, unsigned int mode,
> + const struct phylink_link_state *state)
> +{
> +}
> +
> +static void airoha_mac_link_up(struct phylink_config *config, struct phy_device *phy,
> + unsigned int mode, phy_interface_t interface,
> + int speed, int duplex, bool tx_pause, bool rx_pause)
> +{
> + struct airoha_gdm_dev *dev = container_of(config, struct airoha_gdm_dev,
> + phylink_config);
> + struct airoha_gdm_port *port = dev->port;
> + struct airoha_eth *eth = dev->eth;
> + u32 frag_size_tx, frag_size_rx;
> + u32 mask, val;
> +
> + /* TX/RX frag is configured only for GDM4 */
> + if (port->id != AIROHA_GDM4_IDX)
> + return;
> +
> + switch (speed) {
> + case SPEED_10000:
> + case SPEED_5000:
> + frag_size_tx = 8;
> + frag_size_rx = 8;
> + break;
> + case SPEED_2500:
> + frag_size_tx = 2;
> + frag_size_rx = 1;
> + break;
> + default:
> + frag_size_tx = 1;
> + frag_size_rx = 0;
> + }
> +
> + /* Configure TX/RX frag based on speed */
> + if (dev->nbq == 1) {
> + mask = GDMA4_SGMII1_TX_FRAG_SIZE_MASK;
Can the naming be consistently GDM4 without the A?
MvH
Benjamin Larsson
^ permalink raw reply
* Re: [RFC V2 3/3] mm: Replace pgtable entry prints with new format
From: David Hildenbrand (Arm) @ 2026-06-15 16:01 UTC (permalink / raw)
To: Hugh Dickins
Cc: Anshuman Khandual, linux-mm, Andy Shevchenko, Rasmus Villemoes,
Sergey Senozhatsky, Petr Mladek, Steven Rostedt, Jonathan Corbet,
Andrew Morton, linux-kernel, linux-doc, Lorenzo Stoakes
In-Reply-To: <4a416383-62f5-1716-8e04-a2ee1f89a864@google.com>
On 6/12/26 23:26, Hugh Dickins wrote:
> On Fri, 12 Jun 2026, David Hildenbrand (Arm) wrote:
> ...
>>
>> After some off-list discussion, I wonder if we can make our life easier.
>>
>> I think, even with your patch, there is still the case:
>>
>> pr_alert("BUG: Bad page map in process %s %s:%08llx", current->comm,
>> pgtable_level_to_str(level), entry);
>>
>> Where we cast all entries to an "unsigned long" in the callers. We'd have to rework all
>> that for 128bit entries either way (passing them in some struct instead).
>>
>> I really just extended what we used to do here in print_bad_pte() before commit ec63a44011d.
>>
>> Maybe we should just drop the "print the involved page table entries" thing?
>>
>> I mean, we do have the actual page, and we do have the address in the address space, which
>> we all print.
>>
>> Not sure if the actual page table entries are that relevant?
>
> The page table entry is BUGgily Bad: we want to see what it looks like
> (sometimes, a sequence of bad page map entries may even show up as ASCII).
But is printing raw page table entries really what we want? I guess to detect
"random corruption" it might help sometimes.
And do we really need information about the full page table walk, or is the last
level good enough?
--
Cheers,
David
^ permalink raw reply
* Re: [PATCH] MAINTAINERS: Fix regex for kdoc
From: Randy Dunlap @ 2026-06-15 15:56 UTC (permalink / raw)
To: Matthew Wilcox (Oracle), Jonathan Corbet
Cc: Mauro Carvalho Chehab, Shuah Khan, linux-doc
In-Reply-To: <20260615154057.2156589-1-willy@infradead.org>
On 6/15/26 8:40 AM, Matthew Wilcox (Oracle) wrote:
> The trailing '*' means "all files in this directory, but not
> subdirectories" which excluded tools/lib/python/kdoc/. This is surely
> not intended.
>
> Signed-off-by: Matthew Wilcox (Oracle) <willy@infradead.org>
> ---
> MAINTAINERS | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 0d94420eae3d..999957a3e0ca 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -7653,7 +7653,7 @@ S: Maintained
> P: Documentation/doc-guide/maintainer-profile.rst
> T: git git://git.lwn.net/linux.git docs-next
> F: Documentation/
> -F: tools/lib/python/*
> +F: tools/lib/python/
> F: tools/docs/
> F: tools/net/ynl/pyynl/lib/doc_generator.py
> X: Documentation/ABI/
Acked-by: Randy Dunlap <rdunlap@infradead.org>
Thanks.
--
~Randy
^ permalink raw reply
* Re: [PATCH] kdoc_parser: Move __acquires and friends to function_xforms
From: Randy Dunlap @ 2026-06-15 15:52 UTC (permalink / raw)
To: Matthew Wilcox (Oracle), Jonathan Corbet
Cc: Mauro Carvalho Chehab, Shuah Khan, linux-doc
In-Reply-To: <20260615153340.2154110-1-willy@infradead.org>
On 6/15/26 8:33 AM, Matthew Wilcox (Oracle) wrote:
> These were originally added to "Transforms for structs and unions"
> which led to warnings like:
>
> ./include/linux/kref.h:94: WARNING: Invalid C declaration: Expected end of definition. [error at 92]
> int kref_put_lock (struct kref *kref, void (*release)(struct kref *kref), spinlock_t *lock) __cond_acquires(true# lock)
>
> and the documentation was a little messed up as a result. They should
> have been added to "Transforms for function prototypes" since they are
> not valid decorations for unions or structs.
>
> Fixes: 85c2a51357f7 ("docs: kdoc_parser: move nested match transforms to xforms_lists.py")
> Signed-off-by: Matthew Wilcox (Oracle) <willy@infradead.org>
I hope that this same patch is in docs-next:
https://lore.kernel.org/all/20260505221548.163751-1-rdunlap@infradead.org/
Jon replied with "Applied".
> ---
> tools/lib/python/kdoc/xforms_lists.py | 20 ++++++++++----------
> 1 file changed, 10 insertions(+), 10 deletions(-)
>
> diff --git a/tools/lib/python/kdoc/xforms_lists.py b/tools/lib/python/kdoc/xforms_lists.py
> index f6ea9efb11ae..150fbc90f085 100644
> --- a/tools/lib/python/kdoc/xforms_lists.py
> +++ b/tools/lib/python/kdoc/xforms_lists.py
> @@ -48,16 +48,6 @@ class CTransforms:
> (CMatch("DEFINE_DMA_UNMAP_ADDR"), r"dma_addr_t \1"),
> (CMatch("DEFINE_DMA_UNMAP_LEN"), r"__u32 \1"),
> (CMatch("VIRTIO_DECLARE_FEATURES"), r"union { u64 \1; u64 \1_array[VIRTIO_FEATURES_U64S]; }"),
> - (CMatch("__cond_acquires"), ""),
> - (CMatch("__cond_releases"), ""),
> - (CMatch("__acquires"), ""),
> - (CMatch("__releases"), ""),
> - (CMatch("__must_hold"), ""),
> - (CMatch("__must_not_hold"), ""),
> - (CMatch("__must_hold_shared"), ""),
> - (CMatch("__cond_acquires_shared"), ""),
> - (CMatch("__acquires_shared"), ""),
> - (CMatch("__releases_shared"), ""),
> (CMatch("__attribute__"), ""),
>
> #
> @@ -98,6 +88,16 @@ class CTransforms:
> (CMatch("__diagnose_as"), ""),
> (CMatch("DECL_BUCKET_PARAMS"), r"\1, \2"),
> (CMatch("__no_context_analysis"), ""),
> + (CMatch("__cond_acquires"), ""),
> + (CMatch("__cond_releases"), ""),
> + (CMatch("__acquires"), ""),
> + (CMatch("__releases"), ""),
> + (CMatch("__must_hold"), ""),
> + (CMatch("__must_not_hold"), ""),
> + (CMatch("__must_hold_shared"), ""),
> + (CMatch("__cond_acquires_shared"), ""),
> + (CMatch("__acquires_shared"), ""),
> + (CMatch("__releases_shared"), ""),
> (CMatch("__attribute_const__"), ""),
> (CMatch("__attribute__"), ""),
>
--
~Randy
^ permalink raw reply
* Re: [PATCH] docs/mm: describe current criteria for enabling split page table lock for PTE tables
From: David Hildenbrand (Arm) @ 2026-06-15 15:47 UTC (permalink / raw)
To: Mike Rapoport, Ethan Nelson-Moore
Cc: Lorenzo Stoakes, Liam R. Howlett, Vlastimil Babka,
Suren Baghdasaryan, Michal Hocko, Shuah Khan, linux-mm, linux-doc,
Andrew Morton, Jonathan Corbet
In-Reply-To: <ai5w--zzNaUHuQ6S@kernel.org>
On 6/14/26 11:14, Mike Rapoport wrote:
> On Sat, Jun 13, 2026 at 03:14:47PM -0700, Ethan Nelson-Moore wrote:
>> The mm documentation regarding split page table lock for PTE tables
>> refers to the CONFIG_SPLIT_PTLOCK_CPUS config option, which was
>> superseded by CONFIG_SPLIT_PTE_PTLOCKS in commit 394290cba966 ("mm:
>> turn USE_SPLIT_PTE_PTLOCKS / USE_SPLIT_PTE_PTLOCKS into Kconfig
>> options"). Update the documentation to refer to the current option and
>> document the situations in which this feature is not supported.
>>
>> Discovered while searching for CONFIG_* symbols referenced in the
>> kernel but not defined in any Kconfig file.
>>
>> Signed-off-by: Ethan Nelson-Moore <enelsonmoore@gmail.com>
>> ---
>> Documentation/mm/split_page_table_lock.rst | 9 ++++++---
>> 1 file changed, 6 insertions(+), 3 deletions(-)
>>
>> diff --git a/Documentation/mm/split_page_table_lock.rst b/Documentation/mm/split_page_table_lock.rst
>> index cc3cd46abd1b..c9d16024543b 100644
>> --- a/Documentation/mm/split_page_table_lock.rst
>> +++ b/Documentation/mm/split_page_table_lock.rst
>> @@ -37,9 +37,12 @@ There are helpers to lock/unlock a table and other accessor functions:
>> - pmd_lockptr()
>> returns pointer to PMD table lock;
>>
>> -Split page table lock for PTE tables is enabled compile-time if
>> -CONFIG_SPLIT_PTLOCK_CPUS (usually 4) is less or equal to NR_CPUS.
>> -If split lock is disabled, all tables are guarded by mm->page_table_lock.
>> +Split page table lock for PTE tables is enabled compile-time (via
>> +CONFIG_SPLIT_PTE_PTLOCKS) if NR_CPUS is greater than or equal to 4 and an
>> +MMU is being used. However, it is not supported on ARM processors with
>> +virtually indexed, physically tagged caches, PA-RISC processors older than
>> +the PA-8000, or 32-bit SPARC processors. If split lock is disabled, all
>
> "it is not supported on some architectures" would be enough IMO.
Yeah, we can keep this short.
--
Cheers,
David
^ permalink raw reply
* [PATCH] MAINTAINERS: Fix regex for kdoc
From: Matthew Wilcox (Oracle) @ 2026-06-15 15:40 UTC (permalink / raw)
To: Jonathan Corbet
Cc: Matthew Wilcox (Oracle), Mauro Carvalho Chehab, Shuah Khan,
linux-doc
The trailing '*' means "all files in this directory, but not
subdirectories" which excluded tools/lib/python/kdoc/. This is surely
not intended.
Signed-off-by: Matthew Wilcox (Oracle) <willy@infradead.org>
---
MAINTAINERS | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 0d94420eae3d..999957a3e0ca 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -7653,7 +7653,7 @@ S: Maintained
P: Documentation/doc-guide/maintainer-profile.rst
T: git git://git.lwn.net/linux.git docs-next
F: Documentation/
-F: tools/lib/python/*
+F: tools/lib/python/
F: tools/docs/
F: tools/net/ynl/pyynl/lib/doc_generator.py
X: Documentation/ABI/
--
2.47.3
^ permalink raw reply related
* [PATCH] kdoc_parser: Move __acquires and friends to function_xforms
From: Matthew Wilcox (Oracle) @ 2026-06-15 15:33 UTC (permalink / raw)
To: Jonathan Corbet
Cc: Matthew Wilcox (Oracle), Mauro Carvalho Chehab, Shuah Khan,
linux-doc
These were originally added to "Transforms for structs and unions"
which led to warnings like:
./include/linux/kref.h:94: WARNING: Invalid C declaration: Expected end of definition. [error at 92]
int kref_put_lock (struct kref *kref, void (*release)(struct kref *kref), spinlock_t *lock) __cond_acquires(true# lock)
and the documentation was a little messed up as a result. They should
have been added to "Transforms for function prototypes" since they are
not valid decorations for unions or structs.
Fixes: 85c2a51357f7 ("docs: kdoc_parser: move nested match transforms to xforms_lists.py")
Signed-off-by: Matthew Wilcox (Oracle) <willy@infradead.org>
---
tools/lib/python/kdoc/xforms_lists.py | 20 ++++++++++----------
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/tools/lib/python/kdoc/xforms_lists.py b/tools/lib/python/kdoc/xforms_lists.py
index f6ea9efb11ae..150fbc90f085 100644
--- a/tools/lib/python/kdoc/xforms_lists.py
+++ b/tools/lib/python/kdoc/xforms_lists.py
@@ -48,16 +48,6 @@ class CTransforms:
(CMatch("DEFINE_DMA_UNMAP_ADDR"), r"dma_addr_t \1"),
(CMatch("DEFINE_DMA_UNMAP_LEN"), r"__u32 \1"),
(CMatch("VIRTIO_DECLARE_FEATURES"), r"union { u64 \1; u64 \1_array[VIRTIO_FEATURES_U64S]; }"),
- (CMatch("__cond_acquires"), ""),
- (CMatch("__cond_releases"), ""),
- (CMatch("__acquires"), ""),
- (CMatch("__releases"), ""),
- (CMatch("__must_hold"), ""),
- (CMatch("__must_not_hold"), ""),
- (CMatch("__must_hold_shared"), ""),
- (CMatch("__cond_acquires_shared"), ""),
- (CMatch("__acquires_shared"), ""),
- (CMatch("__releases_shared"), ""),
(CMatch("__attribute__"), ""),
#
@@ -98,6 +88,16 @@ class CTransforms:
(CMatch("__diagnose_as"), ""),
(CMatch("DECL_BUCKET_PARAMS"), r"\1, \2"),
(CMatch("__no_context_analysis"), ""),
+ (CMatch("__cond_acquires"), ""),
+ (CMatch("__cond_releases"), ""),
+ (CMatch("__acquires"), ""),
+ (CMatch("__releases"), ""),
+ (CMatch("__must_hold"), ""),
+ (CMatch("__must_not_hold"), ""),
+ (CMatch("__must_hold_shared"), ""),
+ (CMatch("__cond_acquires_shared"), ""),
+ (CMatch("__acquires_shared"), ""),
+ (CMatch("__releases_shared"), ""),
(CMatch("__attribute_const__"), ""),
(CMatch("__attribute__"), ""),
--
2.47.3
^ permalink raw reply related
* Re: [PATCH v3] Documentation/process: Add Researcher Guidelines
From: Andy Shevchenko @ 2026-06-15 15:02 UTC (permalink / raw)
To: Jonathan Corbet
Cc: Dan Carpenter, Kees Cook, Greg Kroah-Hartman, Stefano Zacchiroli,
Steven Rostedt, Laura Abbott, Julia Lawall, Wenwen Wang,
Gustavo A . R . Silva, Thorsten Leemhuis, linux-kernel, linux-doc,
linux-hardening, Dawei Feng
In-Reply-To: <875x3j3l5x.fsf@trenco.lwn.net>
On Mon, Jun 15, 2026 at 08:58:34AM -0600, Jonathan Corbet wrote:
> Andy Shevchenko <andriy.shevchenko@intel.com> writes:
> > On Thu, May 28, 2026 at 01:34:34PM +0300, Dan Carpenter wrote:
> >> On Fri, Mar 04, 2022 at 10:14:18AM -0800, Kees Cook wrote:
...
> >> > + x86_64 and arm64 defconfig builds with CONFIG_FOO_BAR=y using GCC
> >> > + 11.2 show no new warnings, and LeakMagic no longer warns about this
> >> > + code path. As we don't have a FooBar device to test with, no runtime
> >> > + testing was able to be performed.
> >>
> >> People have started sending commit messages in this exact template and
> >> normally I would ask them resend with the meta commentary from this
> >> paragraph below the --- cut off line.
> >>
> >> Do we really want this "Compile tested only" stuff in the permanent git
> >> log?
> >
> > +1 here, can we rather avoid flooding commit messages with the meta, that
> > anyways is available in lore.kernel.org archives?
>
> Perhaps somebody should send a patch correcting the wording to how they
> think it should be...?
Perhaps Dan as native speaker can do it better or others who were involved in
this?
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v3] Documentation/process: Add Researcher Guidelines
From: Jonathan Corbet @ 2026-06-15 14:58 UTC (permalink / raw)
To: Andy Shevchenko, Dan Carpenter
Cc: Kees Cook, Greg Kroah-Hartman, Stefano Zacchiroli, Steven Rostedt,
Laura Abbott, Julia Lawall, Wenwen Wang, Gustavo A . R . Silva,
Thorsten Leemhuis, linux-kernel, linux-doc, linux-hardening,
Dawei Feng
In-Reply-To: <ajACprp9UJp2JSJM@black.igk.intel.com>
Andy Shevchenko <andriy.shevchenko@intel.com> writes:
> On Thu, May 28, 2026 at 01:34:34PM +0300, Dan Carpenter wrote:
>> On Fri, Mar 04, 2022 at 10:14:18AM -0800, Kees Cook wrote:
>
> ...
>
>> > + x86_64 and arm64 defconfig builds with CONFIG_FOO_BAR=y using GCC
>> > + 11.2 show no new warnings, and LeakMagic no longer warns about this
>> > + code path. As we don't have a FooBar device to test with, no runtime
>> > + testing was able to be performed.
>>
>> People have started sending commit messages in this exact template and
>> normally I would ask them resend with the meta commentary from this
>> paragraph below the --- cut off line.
>>
>> Do we really want this "Compile tested only" stuff in the permanent git
>> log?
>
> +1 here, can we rather avoid flooding commit messages with the meta, that
> anyways is available in lore.kernel.org archives?
Perhaps somebody should send a patch correcting the wording to how they
think it should be...?
Thanks,
jon
^ permalink raw reply
* Re: [PATCH net-next v7 05/12] net: phylink: support late PCS provider attach
From: Maxime Chevallier @ 2026-06-15 14:44 UTC (permalink / raw)
To: Christian Marangi
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Simon Horman, Jonathan Corbet, Shuah Khan, Lorenzo Bianconi,
Heiner Kallweit, Russell King, Saravana Kannan, Philipp Zabel,
Nathan Chancellor, Nick Desaulniers, Bill Wendling, Justin Stitt,
netdev, devicetree, linux-kernel, linux-doc, linux-arm-kernel,
linux-mediatek, llvm
In-Reply-To: <6a300da0.d5af3cef.1ca29d.19c4@mx.google.com>
On 6/15/26 16:35, Christian Marangi wrote:
> On Mon, Jun 15, 2026 at 04:29:04PM +0200, Maxime Chevallier wrote:
>>
>>
>> On 6/15/26 16:10, Christian Marangi wrote:
>>> On Mon, Jun 15, 2026 at 04:07:03PM +0200, Maxime Chevallier wrote:
>>>> Hi Christian,
>>>>
>>>> On 6/15/26 14:29, Christian Marangi wrote:
>>>>> Add support for late PCS provider attachment to a phylink instance.
>>>>> This works by creating a global notifier for the PCS provider and
>>>>> making each phylink instance that makes use of fwnode subscribe to
>>>>> this notifier.
>>>>>
>>>>> The PCS notifier will emit the event FWNODE_PCS_PROVIDER_ADD every time
>>>>> a new PCS provider is added.
>>>>>
>>>>> phylink will then react to this event and will call the new function
>>>>> fwnode_phylink_pcs_get_from_fwnode() that will check if the PCS fwnode
>>>>> provided by the event is present in the pcs-handle property of the
>>>>> phylink instance.
>>>>>
>>>>> If a related PCS is found, then such PCS is added to the phylink
>>>>> instance PCS list.
>>>>>
>>>>> Then we link the PCS to the phylink instance and we refresh the supported
>>>>> interfaces of the phylink instance.
>>>>>
>>>>> Finally we check if we are in a major_config_failed scenario and trigger
>>>>> an interface reconfiguration in the next phylink resolve.
>>>>>
>>>>> In the example scenario where the link was previously torn down due to
>>>>> removal of PCS, the link will be established again as the PCS came back
>>>>> and is now available to phylink.
>>>>>
>>>>> Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
>>>>> ---
>>>>
>>>> [...]
>>>>
>>>>> @@ -2151,6 +2204,10 @@ void phylink_destroy(struct phylink *pl)
>>>>> if (pl->link_gpio)
>>>>> gpiod_put(pl->link_gpio);
>>>>>
>>>>> + /* Unregister notifier for late PCS attach */
>>>>> + if (pl->fwnode_pcs_nb.notifier_call)
>>>>> + unregister_fwnode_pcs_notifier(&pl->fwnode_pcs_nb);
>>>>
>>>> I wanted to try this out, but I get :
>>>>
>>>> drivers/net/phy/phylink.c:2218:17: error: implicit declaration of function ‘unregister_fwnode_pcs_notifier’; did you mean ‘register_fwnode_pcs_notifier’? [-Werror=implicit-function-declaration]
>>>> 2218 | unregister_fwnode_pcs_notifier(&pl->fwnode_pcs_nb);
>>>> | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>>> | register_fwnode_pcs_notifier
>>>>
>>>> I guess you either need to stub this, or there's a missing Kconfig
>>>> dependency somewhere
>>>>
>>>
>>> Hi yes if you want toi test just enable CONFIG_FWNODE_PCS. I forgot to add
>>> the static declaration for unregister_fwnode_pcs_notifier.
>>
>> I'll give it a go with this yeah, I have a few devices here I'd like to
>> try this on.
>>
>> Can you CC me for the next rounds ?
>>
>
> Sure, if you can would be good to check also the other commit if everything
> is logically correct.
Absolutely, I'm planning on doing this :) This is quite the series though,
I'll try to give it some deeper look in the upcoming days, I expect net-next
to close soon anyways, so that's as good as it gets for reviewing this :)
Also, it's probably a good idea to have Sean in CC as well, I know a few people
interested in the Xilinx PCS his series brought, hopefully he can follow-up on
this series with the other new PCS drivers.
>
> BTW by checking test from patchwork I can see also another fix is needed if
> you want to test this revision.
>
> phylink_create()
>
> -if (config->num_possible_pcs && pl->mac_ops->mac_select_pcs) {
> +if (config->num_possible_pcs && mac_ops->mac_select_pcs) {
Ack, I'll test it with this change, thanks :)
Maxime
>
> Aside from these change I expect the current legacy code to be not
> affected by these change.
I'll probably have things to say about this "legacy" naming :)
Thanks for driving this work forwards anyway, that's
>
^ permalink raw reply
* Re: [PATCH net-next v7 05/12] net: phylink: support late PCS provider attach
From: Christian Marangi @ 2026-06-15 14:35 UTC (permalink / raw)
To: Maxime Chevallier
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Simon Horman, Jonathan Corbet, Shuah Khan, Lorenzo Bianconi,
Heiner Kallweit, Russell King, Saravana Kannan, Philipp Zabel,
Nathan Chancellor, Nick Desaulniers, Bill Wendling, Justin Stitt,
netdev, devicetree, linux-kernel, linux-doc, linux-arm-kernel,
linux-mediatek, llvm
In-Reply-To: <7702ac09-75fd-49de-8ad2-fceaa122b627@bootlin.com>
On Mon, Jun 15, 2026 at 04:29:04PM +0200, Maxime Chevallier wrote:
>
>
> On 6/15/26 16:10, Christian Marangi wrote:
> > On Mon, Jun 15, 2026 at 04:07:03PM +0200, Maxime Chevallier wrote:
> >> Hi Christian,
> >>
> >> On 6/15/26 14:29, Christian Marangi wrote:
> >>> Add support for late PCS provider attachment to a phylink instance.
> >>> This works by creating a global notifier for the PCS provider and
> >>> making each phylink instance that makes use of fwnode subscribe to
> >>> this notifier.
> >>>
> >>> The PCS notifier will emit the event FWNODE_PCS_PROVIDER_ADD every time
> >>> a new PCS provider is added.
> >>>
> >>> phylink will then react to this event and will call the new function
> >>> fwnode_phylink_pcs_get_from_fwnode() that will check if the PCS fwnode
> >>> provided by the event is present in the pcs-handle property of the
> >>> phylink instance.
> >>>
> >>> If a related PCS is found, then such PCS is added to the phylink
> >>> instance PCS list.
> >>>
> >>> Then we link the PCS to the phylink instance and we refresh the supported
> >>> interfaces of the phylink instance.
> >>>
> >>> Finally we check if we are in a major_config_failed scenario and trigger
> >>> an interface reconfiguration in the next phylink resolve.
> >>>
> >>> In the example scenario where the link was previously torn down due to
> >>> removal of PCS, the link will be established again as the PCS came back
> >>> and is now available to phylink.
> >>>
> >>> Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
> >>> ---
> >>
> >> [...]
> >>
> >>> @@ -2151,6 +2204,10 @@ void phylink_destroy(struct phylink *pl)
> >>> if (pl->link_gpio)
> >>> gpiod_put(pl->link_gpio);
> >>>
> >>> + /* Unregister notifier for late PCS attach */
> >>> + if (pl->fwnode_pcs_nb.notifier_call)
> >>> + unregister_fwnode_pcs_notifier(&pl->fwnode_pcs_nb);
> >>
> >> I wanted to try this out, but I get :
> >>
> >> drivers/net/phy/phylink.c:2218:17: error: implicit declaration of function ‘unregister_fwnode_pcs_notifier’; did you mean ‘register_fwnode_pcs_notifier’? [-Werror=implicit-function-declaration]
> >> 2218 | unregister_fwnode_pcs_notifier(&pl->fwnode_pcs_nb);
> >> | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> >> | register_fwnode_pcs_notifier
> >>
> >> I guess you either need to stub this, or there's a missing Kconfig
> >> dependency somewhere
> >>
> >
> > Hi yes if you want toi test just enable CONFIG_FWNODE_PCS. I forgot to add
> > the static declaration for unregister_fwnode_pcs_notifier.
>
> I'll give it a go with this yeah, I have a few devices here I'd like to
> try this on.
>
> Can you CC me for the next rounds ?
>
Sure, if you can would be good to check also the other commit if everything
is logically correct.
BTW by checking test from patchwork I can see also another fix is needed if
you want to test this revision.
phylink_create()
-if (config->num_possible_pcs && pl->mac_ops->mac_select_pcs) {
+if (config->num_possible_pcs && mac_ops->mac_select_pcs) {
Aside from these change I expect the current legacy code to be not
affected by these change.
--
Ansuel
^ permalink raw reply
* Re: [PATCH net-next v7 05/12] net: phylink: support late PCS provider attach
From: Maxime Chevallier @ 2026-06-15 14:29 UTC (permalink / raw)
To: Christian Marangi
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Simon Horman, Jonathan Corbet, Shuah Khan, Lorenzo Bianconi,
Heiner Kallweit, Russell King, Saravana Kannan, Philipp Zabel,
Nathan Chancellor, Nick Desaulniers, Bill Wendling, Justin Stitt,
netdev, devicetree, linux-kernel, linux-doc, linux-arm-kernel,
linux-mediatek, llvm
In-Reply-To: <6a3007ce.73de60af.3a056d.d903@mx.google.com>
On 6/15/26 16:10, Christian Marangi wrote:
> On Mon, Jun 15, 2026 at 04:07:03PM +0200, Maxime Chevallier wrote:
>> Hi Christian,
>>
>> On 6/15/26 14:29, Christian Marangi wrote:
>>> Add support for late PCS provider attachment to a phylink instance.
>>> This works by creating a global notifier for the PCS provider and
>>> making each phylink instance that makes use of fwnode subscribe to
>>> this notifier.
>>>
>>> The PCS notifier will emit the event FWNODE_PCS_PROVIDER_ADD every time
>>> a new PCS provider is added.
>>>
>>> phylink will then react to this event and will call the new function
>>> fwnode_phylink_pcs_get_from_fwnode() that will check if the PCS fwnode
>>> provided by the event is present in the pcs-handle property of the
>>> phylink instance.
>>>
>>> If a related PCS is found, then such PCS is added to the phylink
>>> instance PCS list.
>>>
>>> Then we link the PCS to the phylink instance and we refresh the supported
>>> interfaces of the phylink instance.
>>>
>>> Finally we check if we are in a major_config_failed scenario and trigger
>>> an interface reconfiguration in the next phylink resolve.
>>>
>>> In the example scenario where the link was previously torn down due to
>>> removal of PCS, the link will be established again as the PCS came back
>>> and is now available to phylink.
>>>
>>> Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
>>> ---
>>
>> [...]
>>
>>> @@ -2151,6 +2204,10 @@ void phylink_destroy(struct phylink *pl)
>>> if (pl->link_gpio)
>>> gpiod_put(pl->link_gpio);
>>>
>>> + /* Unregister notifier for late PCS attach */
>>> + if (pl->fwnode_pcs_nb.notifier_call)
>>> + unregister_fwnode_pcs_notifier(&pl->fwnode_pcs_nb);
>>
>> I wanted to try this out, but I get :
>>
>> drivers/net/phy/phylink.c:2218:17: error: implicit declaration of function ‘unregister_fwnode_pcs_notifier’; did you mean ‘register_fwnode_pcs_notifier’? [-Werror=implicit-function-declaration]
>> 2218 | unregister_fwnode_pcs_notifier(&pl->fwnode_pcs_nb);
>> | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>> | register_fwnode_pcs_notifier
>>
>> I guess you either need to stub this, or there's a missing Kconfig
>> dependency somewhere
>>
>
> Hi yes if you want toi test just enable CONFIG_FWNODE_PCS. I forgot to add
> the static declaration for unregister_fwnode_pcs_notifier.
I'll give it a go with this yeah, I have a few devices here I'd like to
try this on.
Can you CC me for the next rounds ?
Maxime
>
^ permalink raw reply
* Re: [PATCH net-next v5 12/15] onsemi: s2500: Add driver support for TS2500 MAC-PHY
From: Julian Braha @ 2026-06-15 14:27 UTC (permalink / raw)
To: Selvamani.Rajagopal, Andrew Lunn, Piergiorgio Beruto,
Heiner Kallweit, Russell King, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Andrew Lunn, Parthiban Veerasooran,
Richard Cochran, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Simon Horman, Jonathan Corbet, Shuah Khan
Cc: netdev, linux-kernel, devicetree, linux-doc, Jerry Ray
In-Reply-To: <20260614-s2500-mac-phy-support-v5-12-89874b72f725@onsemi.com>
Hi Selvamani,
On 6/14/26 18:00, Selvamani Rajagopal via B4 Relay wrote:
> diff --git a/drivers/net/ethernet/onsemi/Kconfig b/drivers/net/ethernet/onsemi/Kconfig
> new file mode 100644
> index 000000000000..8d72194151ea
> --- /dev/null
> +++ b/drivers/net/ethernet/onsemi/Kconfig
> @@ -0,0 +1,21 @@
> +# SPDX-License-Identifier: GPL-2.0-only
> +#
> +# onsemi network device configuration
> +#
> +
> +config NET_VENDOR_ONSEMI
> + bool "onsemi network devices"
> + help
> + If you have a network card belonging to this class, say Y.
> +
> + Note that the answer to this question doesn't directly affect the
> + kernel: saying N will just cause the configurator to skip all
> + the questions about onsemi ethernet devices. If you say Y, you
> + will be asked for your specific card in the following questions.
> +
> +if NET_VENDOR_ONSEMI
> +
> +source "drivers/net/ethernet/onsemi/s2500/Kconfig"
> +
> +endif # NET_VENDOR_ONSEMI
When you put the 'if NET_VENDOR_ONSEMI' around the 'source', you're
making it a dependency on every config option in that sourced Kconfig.
> diff --git a/drivers/net/ethernet/onsemi/s2500/Kconfig b/drivers/net/ethernet/onsemi/s2500/Kconfig
> new file mode 100644
> index 000000000000..f2e8d5d1429d
> --- /dev/null
> +++ b/drivers/net/ethernet/onsemi/s2500/Kconfig
> @@ -0,0 +1,21 @@
> +# SPDX-License-Identifier: GPL-2.0-only
> +#
> +# onsemi S2500 Driver Support
> +#
> +
> +if NET_VENDOR_ONSEMI
> +
> +config S2500_MACPHY
> + tristate "S2500 support"
> + depends on SPI
> + select NCN26000_PHY
> + select OA_TC6
> + help
> + Support for the onsemi TS2500 MACPHY Ethernet chip.
> + It works under the framework that conform to OPEN Alliance
> + 10BASE-T1x Serial Interface specification.
> +
> + To compile this driver as a module, choose M here. The module will be
> + called s2500.
> +
> +endif # NET_VENDOR_ONSEMI
Which means that when you add 'if NET_VENDOR_ONSEMI' again inside the
sourced Kconfig, it's a duplicate dependency.
I think putting the if-endif in either place is fine, but it's redundant
to do it twice. You could maybe consider using a comment for the second
instance instead.
- Julian Braha
^ permalink raw reply
* Re: [PATCH net-next v7 01/12] net: phylink: keep and use MAC supported_interfaces in phylink struct
From: Christian Marangi @ 2026-06-15 14:18 UTC (permalink / raw)
To: Maxime Chevallier
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Simon Horman, Jonathan Corbet, Shuah Khan, Lorenzo Bianconi,
Heiner Kallweit, Russell King, Saravana Kannan, Philipp Zabel,
Nathan Chancellor, Nick Desaulniers, Bill Wendling, Justin Stitt,
netdev, devicetree, linux-kernel, linux-doc, linux-arm-kernel,
linux-mediatek, llvm
In-Reply-To: <371a1df7-084c-4431-bd00-0045298e3212@bootlin.com>
On Mon, Jun 15, 2026 at 03:33:34PM +0200, Maxime Chevallier wrote:
> Hello Christian,
>
> On 6/15/26 14:29, Christian Marangi wrote:
> > Add in phylink struct a copy of supported_interfaces from phylink_config
> > and make use of that instead of relying on phylink_config value.
> >
> > This in preparation for support of PCS handling internally to phylink
> > where a PCS can be removed or added after the phylink is created and we
> > need both a reference of the supported_interfaces value from
> > phylink_config and an internal value that can be updated with the new
> > PCS info.
> >
> > Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
> > ---
> > drivers/net/phy/phylink.c | 22 +++++++++++++++-------
> > 1 file changed, 15 insertions(+), 7 deletions(-)
> >
> > diff --git a/drivers/net/phy/phylink.c b/drivers/net/phy/phylink.c
> > index 087ac63f9193..4d59c0dd78db 100644
> > --- a/drivers/net/phy/phylink.c
> > +++ b/drivers/net/phy/phylink.c
> > @@ -60,6 +60,11 @@ struct phylink {
> > /* The link configuration settings */
> > struct phylink_link_state link_config;
> >
> > + /* What interface are supported by the current link.
> > + * Can change on removal or addition of new PCS.
> > + */
> > + DECLARE_PHY_INTERFACE_MASK(supported_interfaces);
>
> Can you clarify a bit what you mean here ? Is that the combination of the
> interfaces the MAC supports AND the currently in-use PCS ?
>
Combination of interface the MAC supports and the currently attached PCS
(not the current one in use)
The fact that it can change is due to the fact that PCS can be attached
later and supported_interfaces can be updated accordingly.
--
Ansuel
^ permalink raw reply
* Re: [PATCH net-next v7 02/12] net: phylink: introduce internal phylink PCS handling
From: Christian Marangi @ 2026-06-15 14:17 UTC (permalink / raw)
To: Maxime Chevallier
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Simon Horman, Jonathan Corbet, Shuah Khan, Lorenzo Bianconi,
Heiner Kallweit, Russell King, Saravana Kannan, Philipp Zabel,
Nathan Chancellor, Nick Desaulniers, Bill Wendling, Justin Stitt,
netdev, devicetree, linux-kernel, linux-doc, linux-arm-kernel,
linux-mediatek, llvm
In-Reply-To: <3bbacda3-4225-4536-a4b4-3aa31a47a3aa@bootlin.com>
On Mon, Jun 15, 2026 at 03:31:20PM +0200, Maxime Chevallier wrote:
> Hi Christian,
>
> On 6/15/26 14:29, Christian Marangi wrote:
> > Introduce internal handling of PCS for phylink. This is an alternative
> > way to .mac_select_pcs that moves the selection logic of the PCS entirely
> > to phylink with the usage of the supported_interface value in the PCS
> > struct.
> >
> > MAC should now provide a callback to fill the available PCS in
> > phylink_config in .fill_available_pcs and fill the .num_possible_pcs with
> > the number of elements in the array. MAC should also define a new bitmap,
> > pcs_interfaces, in phylink_config to define for what interface mode a
> > dedicated PCS is required.
> >
> > On phylink_create(), an array of PCS pointer is allocated of size
> > .num_possible_pcs from phylink_config and .fill_available_pcs from
> > phylink_config is called passing as args the just allocated array and
> > the number of possible element in it.
> >
> > MAC will fill this passed array with all the available PCS.
> >
> > This array is then parsed and a linked list of PCS is created based on
> > the allocated PCS array filled by MAC via .fill_available_pcs().
> >
> > Every PCS in phylink PCS list gets then linked to the phylink instance
> > by setting the phylink value in phylink_pcs struct to the phylink instance.
> > Also the supported_interface value in phylink struct is updated with
> > the new supported_interface from the provided PCS.
> >
> > On phylink_destroy(), every PCS in phylink PCS list is unlinked from the
> > phylink instance by setting the phylink value in phylink_pcs struct to NULL
> > and removed from the PCS list.
> >
> > phylink_validate_mac_and_pcs(), phylink_major_config() and
> > phylink_inband_caps() are updated to support this new implementation
> > with the PCS list stored in phylink.
> >
> > They will make use of phylink_validate_pcs_interface() that will loop
> > for every PCS in the phylink PCS available list and find one that supports
> > the passed interface.
> >
> > phylink_validate_pcs_interface() applies the same logic of .mac_select_pcs
> > where if a supported_interface value is not set for the PCS struct, then
> > it's assumed every interface is supported.
> >
> > A MAC is required to implement either a .mac_select_pcs or make use of
> > the PCS list implementation. Implementing both will result in a fail
> > on phylink_create().
> >
> > A MAC defining .num_possible_pcs in phylink_config MUST also define a
> > .fill_available_pcs or phylink_create() will fail with an negative error.
> >
> > phylink value in phylink_pcs struct with this implementation is used to
> > track from PCS side when it's attached to a phylink instance. PCS driver
> > will make use of this information to correctly detach from a phylink
> > instance if needed.
> >
> > phylink_pcs_change() is also changed to verify that the PCS that triggered
> > a link change is the one that is currently used by the phylink instance.
> >
> > The .mac_select_pcs implementation is not changed but it's expected that
> > every MAC driver migrates to the new implementation to later deprecate
> > and remove .mac_select_pcs.
> >
> > Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
> > ---
>
> [...]
>
> > @@ -1872,10 +1993,28 @@ struct phylink *phylink_create(struct phylink_config *config,
> > mutex_init(&pl->phydev_mutex);
> > mutex_init(&pl->state_mutex);
> > INIT_WORK(&pl->resolve, phylink_resolve);
> > + INIT_LIST_HEAD(&pl->pcs_list);
> > +
> > + /* Fill the PCS list with available PCS from phylink config */
> > + ret = phylink_fill_available_pcs(pl, config);
> > + if (ret < 0) {
> > + kfree(pl);
> > + return ERR_PTR(ret);
> > + }
> > +
> > + /* Link available PCS to phylink */
> > + list_for_each_entry(pcs, &pl->pcs_list, list)
> > + pcs->phylink = pl;
> >
> > phy_interface_copy(pl->supported_interfaces,
> > config->supported_interfaces);
> >
> > + /* Update supported interfaces */
> > + list_for_each_entry(pcs, &pl->pcs_list, list)
> > + phy_interface_or(pl->supported_interfaces,
> > + pl->supported_interfaces,
> > + pcs->supported_interfaces);
> > +
>
> I'm not entirely sure about that, we may need to restrict the supported_interfaces
> from the MAC.
>
> As an example, take mvpp2. We have 2 PCSs, one for BaseX/SGMII, one for BaseR. But
> if we don't have a comphy (generic PHY) device, then we can't use all the
> combination of modes our PCSs can provide :
>
> https://elixir.bootlin.com/linux/v7.1-rc7/source/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c#L7074
>
> These aren't external PCS IPs, but from what I understand you'd like to
> handle these the same way as purely external PCSs, right ?
>
> I'd say the MAC driver utltimately has the knowledge of all possible interfaces.
>
> The way I see it, it's probably safer to let the MAC give a wide range of interfaces,
> and filter that down with what the PCSs can provide (i.e. turn that or into an and,
> while handling the case where the pcs supported interfaces is empty).
>
> What do you think ?
>
The idea is that supported_interface is a mask of every possible interface
from MAC and PCS. Then it's phylink_validate_mac_and_pcs that actually use
that mask and validates it on both MAC and PCS.
This is why the OR was used instead of AND. The idea is to have the PCS as
external standalone entry (even if they are internal to the MAC). So each
entry should have they own set of supported mask.
The previous patch and this try to address this problem where phylink is
actually clueless of what is actually supported exactly because it's has
been given MAC too much freedom of modelling limitation internally.
I feel limitation should be handled by their dedicated function with
.pcs_validate and .mac_get_caps.
Just my idea on this, if needed it's totally ok to simplify this and let
MAC entirely handle the mask. (but I feel the current idea of phylink code
was to have a generic mask in supported_interfaces and then verify MAC and
PCS in phylink_validate_mac_and_pcs())
But by thinking on it more, following your case of mvpp2, with this new
PCS:
- You need a PCS for the .get_state.
- And such PCS will have the supported interface set 1000baseX and
2500BaseX (as that is what is actually supported in HW)
Either some magic is done in .pcs_validate to deny changing the interface
that was initially configured or this gets limited at the
supported_interface configured by the MAC.
I need to check if this might be problematic for the other driver where
this is being used on OpenWrt but maybe changing the logic to an AND might
be sensible for these kind of case.
(for the other it shouldn't change anything)
--
Ansuel
^ permalink raw reply
* Re: [PATCH net-next v7 05/12] net: phylink: support late PCS provider attach
From: Christian Marangi @ 2026-06-15 14:10 UTC (permalink / raw)
To: Maxime Chevallier
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Simon Horman, Jonathan Corbet, Shuah Khan, Lorenzo Bianconi,
Heiner Kallweit, Russell King, Saravana Kannan, Philipp Zabel,
Nathan Chancellor, Nick Desaulniers, Bill Wendling, Justin Stitt,
netdev, devicetree, linux-kernel, linux-doc, linux-arm-kernel,
linux-mediatek, llvm
In-Reply-To: <867a39de-ccc2-4dcf-be24-ab2542d20ab6@bootlin.com>
On Mon, Jun 15, 2026 at 04:07:03PM +0200, Maxime Chevallier wrote:
> Hi Christian,
>
> On 6/15/26 14:29, Christian Marangi wrote:
> > Add support for late PCS provider attachment to a phylink instance.
> > This works by creating a global notifier for the PCS provider and
> > making each phylink instance that makes use of fwnode subscribe to
> > this notifier.
> >
> > The PCS notifier will emit the event FWNODE_PCS_PROVIDER_ADD every time
> > a new PCS provider is added.
> >
> > phylink will then react to this event and will call the new function
> > fwnode_phylink_pcs_get_from_fwnode() that will check if the PCS fwnode
> > provided by the event is present in the pcs-handle property of the
> > phylink instance.
> >
> > If a related PCS is found, then such PCS is added to the phylink
> > instance PCS list.
> >
> > Then we link the PCS to the phylink instance and we refresh the supported
> > interfaces of the phylink instance.
> >
> > Finally we check if we are in a major_config_failed scenario and trigger
> > an interface reconfiguration in the next phylink resolve.
> >
> > In the example scenario where the link was previously torn down due to
> > removal of PCS, the link will be established again as the PCS came back
> > and is now available to phylink.
> >
> > Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
> > ---
>
> [...]
>
> > @@ -2151,6 +2204,10 @@ void phylink_destroy(struct phylink *pl)
> > if (pl->link_gpio)
> > gpiod_put(pl->link_gpio);
> >
> > + /* Unregister notifier for late PCS attach */
> > + if (pl->fwnode_pcs_nb.notifier_call)
> > + unregister_fwnode_pcs_notifier(&pl->fwnode_pcs_nb);
>
> I wanted to try this out, but I get :
>
> drivers/net/phy/phylink.c:2218:17: error: implicit declaration of function ‘unregister_fwnode_pcs_notifier’; did you mean ‘register_fwnode_pcs_notifier’? [-Werror=implicit-function-declaration]
> 2218 | unregister_fwnode_pcs_notifier(&pl->fwnode_pcs_nb);
> | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> | register_fwnode_pcs_notifier
>
> I guess you either need to stub this, or there's a missing Kconfig
> dependency somewhere
>
Hi yes if you want toi test just enable CONFIG_FWNODE_PCS. I forgot to add
the static declaration for unregister_fwnode_pcs_notifier.
--
Ansuel
^ permalink raw reply
* Re: [PATCH net-next v7 05/12] net: phylink: support late PCS provider attach
From: Maxime Chevallier @ 2026-06-15 14:07 UTC (permalink / raw)
To: Christian Marangi, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Simon Horman, Jonathan Corbet, Shuah Khan,
Lorenzo Bianconi, Heiner Kallweit, Russell King, Saravana Kannan,
Philipp Zabel, Nathan Chancellor, Nick Desaulniers, Bill Wendling,
Justin Stitt, netdev, devicetree, linux-kernel, linux-doc,
linux-arm-kernel, linux-mediatek, llvm
In-Reply-To: <20260615122950.22281-6-ansuelsmth@gmail.com>
Hi Christian,
On 6/15/26 14:29, Christian Marangi wrote:
> Add support for late PCS provider attachment to a phylink instance.
> This works by creating a global notifier for the PCS provider and
> making each phylink instance that makes use of fwnode subscribe to
> this notifier.
>
> The PCS notifier will emit the event FWNODE_PCS_PROVIDER_ADD every time
> a new PCS provider is added.
>
> phylink will then react to this event and will call the new function
> fwnode_phylink_pcs_get_from_fwnode() that will check if the PCS fwnode
> provided by the event is present in the pcs-handle property of the
> phylink instance.
>
> If a related PCS is found, then such PCS is added to the phylink
> instance PCS list.
>
> Then we link the PCS to the phylink instance and we refresh the supported
> interfaces of the phylink instance.
>
> Finally we check if we are in a major_config_failed scenario and trigger
> an interface reconfiguration in the next phylink resolve.
>
> In the example scenario where the link was previously torn down due to
> removal of PCS, the link will be established again as the PCS came back
> and is now available to phylink.
>
> Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
> ---
[...]
> @@ -2151,6 +2204,10 @@ void phylink_destroy(struct phylink *pl)
> if (pl->link_gpio)
> gpiod_put(pl->link_gpio);
>
> + /* Unregister notifier for late PCS attach */
> + if (pl->fwnode_pcs_nb.notifier_call)
> + unregister_fwnode_pcs_notifier(&pl->fwnode_pcs_nb);
I wanted to try this out, but I get :
drivers/net/phy/phylink.c:2218:17: error: implicit declaration of function ‘unregister_fwnode_pcs_notifier’; did you mean ‘register_fwnode_pcs_notifier’? [-Werror=implicit-function-declaration]
2218 | unregister_fwnode_pcs_notifier(&pl->fwnode_pcs_nb);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| register_fwnode_pcs_notifier
I guess you either need to stub this, or there's a missing Kconfig
dependency somewhere
Maxime
^ permalink raw reply
* Re: [PATCH v3] Documentation/process: Add Researcher Guidelines
From: Andy Shevchenko @ 2026-06-15 13:48 UTC (permalink / raw)
To: Dan Carpenter
Cc: Kees Cook, Jonathan Corbet, Greg Kroah-Hartman,
Stefano Zacchiroli, Steven Rostedt, Laura Abbott, Julia Lawall,
Wenwen Wang, Gustavo A . R . Silva, Thorsten Leemhuis,
linux-kernel, linux-doc, linux-hardening, Dawei Feng
In-Reply-To: <ahgaOigklcDCYvRp@stanley.mountain>
On Thu, May 28, 2026 at 01:34:34PM +0300, Dan Carpenter wrote:
> On Fri, Mar 04, 2022 at 10:14:18AM -0800, Kees Cook wrote:
...
> > + x86_64 and arm64 defconfig builds with CONFIG_FOO_BAR=y using GCC
> > + 11.2 show no new warnings, and LeakMagic no longer warns about this
> > + code path. As we don't have a FooBar device to test with, no runtime
> > + testing was able to be performed.
>
> People have started sending commit messages in this exact template and
> normally I would ask them resend with the meta commentary from this
> paragraph below the --- cut off line.
>
> Do we really want this "Compile tested only" stuff in the permanent git
> log?
+1 here, can we rather avoid flooding commit messages with the meta, that
anyways is available in lore.kernel.org archives?
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH 0/3] mm/zram: route block swap I/O through swap_ops
From: Jianyue Wu @ 2026-06-15 13:34 UTC (permalink / raw)
To: Barry Song
Cc: Andrew Morton, Christoph Hellwig, Chris Li, Baoquan He, Nhat Pham,
Kairui Song, Kemeng Shi, Youngjun Park, Minchan Kim,
Sergey Senozhatsky, Jens Axboe, Matthew Wilcox (Oracle), Jan Kara,
linux-mm, linux-kernel, linux-block, linux-doc
In-Reply-To: <CAGsJ_4yqy3ZnXirSZD0X_1b5qDnyoMLuuSS4mHRcip+CPpvQdg@mail.gmail.com>
On Mon, Jun 15, 2026 at 5:14 PM Barry Song <baohua@kernel.org> wrote:
>
> On Sun, Jun 14, 2026 at 11:35 PM Jianyue Wu <wujianyue000@gmail.com> wrote:
> >
> > This series builds on Christoph Hellwig's swap batching rework that
> > moves block swap onto struct swap_iocb and per-backend struct
> > swap_ops handlers [1]. Christoph's patches unify batching for
> > ordinary block devices and swap files. zram still needs a custom
> > path because swap slots map to compressed pages, not disk sectors.
> >
> > The first patch adds swap_register_block_ops() so a block driver can
> > install custom submit_read/submit_write handlers when swapon targets
> > its block device. The default swap_bdev_ops path is unchanged for
> > devices that do not register.
> >
> > The second patch registers zram_swap_ops at module init. On write,
> > the swap core still batches folios into a swap_iocb. zram maps each
> > folio to a slot index and stores it through zram_write_page() instead
> > of building one bio per page. Read handling keeps slot_lock and
> > mark_slot_accessed() in one critical section. Writeback-enabled zram
> > falls back to swap_bdev_submit_read() for ZRAM_WB slots.
> >
> > The third patch moves slot_free_notify into swap_ops next to the
> > other zram swap callbacks, and documents the locking contract for
> > that hook.
> >
> > Applied on top of Christoph Hellwig's "better block swap batching and
> > a different take on swap_ops" series [1].
>
> Nice. I think it's better to mark it as RFC at this stage.
>
> By the way, besides the architectural refinements, have
> you also observed any noticeable performance improvements?
>
> >
> > [1] https://lore.kernel.org/linux-mm/?q=better+block+swap+batching
>
> Best Regards
> Barry
Hello Barry,
Thanks for the feedback:) I will mark the next revision as RFC.
I ran some local measurements on a zram swap workload.
Without a backing device (zspool-only swap read path), the swap_ops
path looks slightly better on average and median latency, while p99 is
roughly flat:
avg 1,750 ns vs 1,812 ns
p50 1,273 ns vs 1,504 ns
p99 6,318 ns vs 6,198 ns
With writeback/backing device enabled, the numbers are much noisier
(bd_reads per sample and cold-fault ratio varied a lot between runs),
so I would not read too much into them. Directionally, the swap_ops
path looked faster on avg/p50/p99 in the runs I captured, but I need
more controlled repeats before claiming a real win:
avg 39 µs vs 77 µs
p50 4.5 µs vs 90 µs
p99 116 µs vs 210 µs
bd_reads/sample 0.37 vs 0.75
cold-fault samples 62.5% vs 100%
So far I would describe the gain as modest for the common zspool case,
maybe because doesn't have merge benefit like bio side.
With the main motivation still being architectural fit (put zram
swap semantics under swap_ops) rather than a large performance jump.
Thanks,
Jianyue
^ permalink raw reply
* Re: [PATCH net-next v7 01/12] net: phylink: keep and use MAC supported_interfaces in phylink struct
From: Maxime Chevallier @ 2026-06-15 13:33 UTC (permalink / raw)
To: Christian Marangi, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Simon Horman, Jonathan Corbet, Shuah Khan,
Lorenzo Bianconi, Heiner Kallweit, Russell King, Saravana Kannan,
Philipp Zabel, Nathan Chancellor, Nick Desaulniers, Bill Wendling,
Justin Stitt, netdev, devicetree, linux-kernel, linux-doc,
linux-arm-kernel, linux-mediatek, llvm
In-Reply-To: <20260615122950.22281-2-ansuelsmth@gmail.com>
Hello Christian,
On 6/15/26 14:29, Christian Marangi wrote:
> Add in phylink struct a copy of supported_interfaces from phylink_config
> and make use of that instead of relying on phylink_config value.
>
> This in preparation for support of PCS handling internally to phylink
> where a PCS can be removed or added after the phylink is created and we
> need both a reference of the supported_interfaces value from
> phylink_config and an internal value that can be updated with the new
> PCS info.
>
> Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
> ---
> drivers/net/phy/phylink.c | 22 +++++++++++++++-------
> 1 file changed, 15 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/net/phy/phylink.c b/drivers/net/phy/phylink.c
> index 087ac63f9193..4d59c0dd78db 100644
> --- a/drivers/net/phy/phylink.c
> +++ b/drivers/net/phy/phylink.c
> @@ -60,6 +60,11 @@ struct phylink {
> /* The link configuration settings */
> struct phylink_link_state link_config;
>
> + /* What interface are supported by the current link.
> + * Can change on removal or addition of new PCS.
> + */
> + DECLARE_PHY_INTERFACE_MASK(supported_interfaces);
Can you clarify a bit what you mean here ? Is that the combination of the
interfaces the MAC supports AND the currently in-use PCS ?
Maxime
^ permalink raw reply
* Re: [PATCH net-next v7 02/12] net: phylink: introduce internal phylink PCS handling
From: Maxime Chevallier @ 2026-06-15 13:31 UTC (permalink / raw)
To: Christian Marangi, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Simon Horman, Jonathan Corbet, Shuah Khan,
Lorenzo Bianconi, Heiner Kallweit, Russell King, Saravana Kannan,
Philipp Zabel, Nathan Chancellor, Nick Desaulniers, Bill Wendling,
Justin Stitt, netdev, devicetree, linux-kernel, linux-doc,
linux-arm-kernel, linux-mediatek, llvm
In-Reply-To: <20260615122950.22281-3-ansuelsmth@gmail.com>
Hi Christian,
On 6/15/26 14:29, Christian Marangi wrote:
> Introduce internal handling of PCS for phylink. This is an alternative
> way to .mac_select_pcs that moves the selection logic of the PCS entirely
> to phylink with the usage of the supported_interface value in the PCS
> struct.
>
> MAC should now provide a callback to fill the available PCS in
> phylink_config in .fill_available_pcs and fill the .num_possible_pcs with
> the number of elements in the array. MAC should also define a new bitmap,
> pcs_interfaces, in phylink_config to define for what interface mode a
> dedicated PCS is required.
>
> On phylink_create(), an array of PCS pointer is allocated of size
> .num_possible_pcs from phylink_config and .fill_available_pcs from
> phylink_config is called passing as args the just allocated array and
> the number of possible element in it.
>
> MAC will fill this passed array with all the available PCS.
>
> This array is then parsed and a linked list of PCS is created based on
> the allocated PCS array filled by MAC via .fill_available_pcs().
>
> Every PCS in phylink PCS list gets then linked to the phylink instance
> by setting the phylink value in phylink_pcs struct to the phylink instance.
> Also the supported_interface value in phylink struct is updated with
> the new supported_interface from the provided PCS.
>
> On phylink_destroy(), every PCS in phylink PCS list is unlinked from the
> phylink instance by setting the phylink value in phylink_pcs struct to NULL
> and removed from the PCS list.
>
> phylink_validate_mac_and_pcs(), phylink_major_config() and
> phylink_inband_caps() are updated to support this new implementation
> with the PCS list stored in phylink.
>
> They will make use of phylink_validate_pcs_interface() that will loop
> for every PCS in the phylink PCS available list and find one that supports
> the passed interface.
>
> phylink_validate_pcs_interface() applies the same logic of .mac_select_pcs
> where if a supported_interface value is not set for the PCS struct, then
> it's assumed every interface is supported.
>
> A MAC is required to implement either a .mac_select_pcs or make use of
> the PCS list implementation. Implementing both will result in a fail
> on phylink_create().
>
> A MAC defining .num_possible_pcs in phylink_config MUST also define a
> .fill_available_pcs or phylink_create() will fail with an negative error.
>
> phylink value in phylink_pcs struct with this implementation is used to
> track from PCS side when it's attached to a phylink instance. PCS driver
> will make use of this information to correctly detach from a phylink
> instance if needed.
>
> phylink_pcs_change() is also changed to verify that the PCS that triggered
> a link change is the one that is currently used by the phylink instance.
>
> The .mac_select_pcs implementation is not changed but it's expected that
> every MAC driver migrates to the new implementation to later deprecate
> and remove .mac_select_pcs.
>
> Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
> ---
[...]
> @@ -1872,10 +1993,28 @@ struct phylink *phylink_create(struct phylink_config *config,
> mutex_init(&pl->phydev_mutex);
> mutex_init(&pl->state_mutex);
> INIT_WORK(&pl->resolve, phylink_resolve);
> + INIT_LIST_HEAD(&pl->pcs_list);
> +
> + /* Fill the PCS list with available PCS from phylink config */
> + ret = phylink_fill_available_pcs(pl, config);
> + if (ret < 0) {
> + kfree(pl);
> + return ERR_PTR(ret);
> + }
> +
> + /* Link available PCS to phylink */
> + list_for_each_entry(pcs, &pl->pcs_list, list)
> + pcs->phylink = pl;
>
> phy_interface_copy(pl->supported_interfaces,
> config->supported_interfaces);
>
> + /* Update supported interfaces */
> + list_for_each_entry(pcs, &pl->pcs_list, list)
> + phy_interface_or(pl->supported_interfaces,
> + pl->supported_interfaces,
> + pcs->supported_interfaces);
> +
I'm not entirely sure about that, we may need to restrict the supported_interfaces
from the MAC.
As an example, take mvpp2. We have 2 PCSs, one for BaseX/SGMII, one for BaseR. But
if we don't have a comphy (generic PHY) device, then we can't use all the
combination of modes our PCSs can provide :
https://elixir.bootlin.com/linux/v7.1-rc7/source/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c#L7074
These aren't external PCS IPs, but from what I understand you'd like to
handle these the same way as purely external PCSs, right ?
I'd say the MAC driver utltimately has the knowledge of all possible interfaces.
The way I see it, it's probably safer to let the MAC give a wide range of interfaces,
and filter that down with what the PCSs can provide (i.e. turn that or into an and,
while handling the case where the pcs supported interfaces is empty).
What do you think ?
Maxime
^ permalink raw reply
* Re: [PATCH 2/3] mm/zram: handle swap read/write via swap_ops
From: Jianyue Wu @ 2026-06-15 13:19 UTC (permalink / raw)
To: YoungJun Park
Cc: Andrew Morton, Christoph Hellwig, Chris Li, Baoquan He, Nhat Pham,
Barry Song, Kairui Song, Kemeng Shi, Minchan Kim,
Sergey Senozhatsky, Jens Axboe, Matthew Wilcox (Oracle), Jan Kara,
linux-mm, linux-kernel, linux-block, linux-doc
In-Reply-To: <ai+eG9sFYTn/vTq5@yjaykim-PowerEdge-T330>
On Mon, Jun 15, 2026 at 2:39 PM YoungJun Park <youngjun.park@lge.com> wrote:
>
> On Sun, Jun 14, 2026 at 11:35:30PM +0800, Jianyue Wu wrote:
>
> Hello!
>
> > +static void zram_swap_submit_read(struct swap_io_ctx *ctx)
> > +{
> > + struct zram *zram = ctx->sis->bdev->bd_disk->private_data;
>
> A passing thought. accessing `zram` here is too indirect. We might
> need a `private_data` in the swap device struct someday?
>
> (And If there is a real value like some swap-side only private data really needed.)
>
> > + struct swap_iocb *sio = ctx->sio;
> > + int nr = swap_iocb_nr_folios(sio);
> > + bool failed = false;
> > + int i, j;
> > + /*
> > + * read_from_zspool() and mark_slot_accessed() must run
> > + * under the same slot_lock. zram_read_page() unlocks
> > + * before returning, which leaves a window where
> > + * writeback can pick an idle slot we just read.
> > + */
>
> Regarding the comment about the "window" where writeback can pick an
> idle slot. I think this reasoning is a bit of a gray area. Writeback
> could just as easily pick the slot right before entering this routine,
> so the race condition seems fundamentally the same.
>
> Isn't the actual justification here to separate the non-backend logic
> and ensure mark_slot_accessed() is called under the lock, given that
> zram_read_page() can call the backend device?
>
> If the "window" mentioned in the comment is indeed a valid issue, then
> zram_read_page() has the exact same problem and needs to be fixed as
> well?
>
> If not, IMHO I suggest revising or removing this comment to clarify
> the true(?) intention. :)
>
> > + slot_lock(zram, idx);
> > + ret = read_from_zspool(zram, page, idx);
> > + if (!ret)
> > + mark_slot_accessed(zram, idx);
> > + slot_unlock(zram, idx);
>
Hello Youngjun,
Agree. Walking ctx->sis->bdev->bd_disk->private_data
from every swap_ops callback is too indirect. I will add an opaque
private_data field to struct swap_info_struct, set it from
->swap_activate() when the swap area is set up, and clear it on
swapoff. The zram callbacks will then use ctx->sis->private_data directly.
You are right. The writeback "window" reasoning was overstated.
Writeback could already have picked the slot before we enter the swap
read path, we have ZRAM_PP_SLOT to ensure it.
0. // condition 1 write pick the slot before the lock.
1. lock → read_from_zspool → unlock
2. // condition 2 write pick the slot inside the lock.
3. lock → mark_slot_accessed() → unlock // clear ZRAM_IDLE and ZRAM_PP_SLOT flag
I think simply removing this comment is good.
Thanks,
Jianyue
^ permalink raw reply
* [PATCH v3 3/3] Documentation: f2fs: document encrypted inline data
From: LiaoYuanhong-vivo @ 2026-06-15 12:55 UTC (permalink / raw)
To: Jaegeuk Kim, Chao Yu, Jonathan Corbet, Shuah Khan,
open list:F2FS FILE SYSTEM, open list, open list:DOCUMENTATION
Cc: LiaoYuanhong-vivo
In-Reply-To: <20260615125517.362294-1-liaoyuanhong@vivo.com>
Document the F2FS encrypted_inline_data feature, including the on-disk
feature requirement, the CONFIG_F2FS_FS_ENCRYPTED_INLINE_DATA dependency,
how inline payloads are encrypted and decrypted, and the truncate behavior.
Also document the supported key combinations. Files using filesystem-layer
encryption reuse the normal software transform. Inlinecrypt is supported
for v2 IV_INO_LBLK_64/32 policies, including hardware-wrapped key
configurations supported by fscrypt. Per-file inlinecrypt keys and
DIRECT_KEY policies are not supported for encrypted inline data.
List encrypted_inline_data in the supported F2FS feature sysfs
documentation.
Signed-off-by: LiaoYuanhong-vivo <liaoyuanhong@vivo.com>
---
Changes in v3:
- Update the documented key support matrix.
Documentation/ABI/testing/sysfs-fs-f2fs | 5 +++--
Documentation/filesystems/f2fs.rst | 30 +++++++++++++++++++++++++
2 files changed, 33 insertions(+), 2 deletions(-)
diff --git a/Documentation/ABI/testing/sysfs-fs-f2fs b/Documentation/ABI/testing/sysfs-fs-f2fs
index 27d5e88facbe..dad483fb2fc1 100644
--- a/Documentation/ABI/testing/sysfs-fs-f2fs
+++ b/Documentation/ABI/testing/sysfs-fs-f2fs
@@ -258,7 +258,8 @@ Description: Expand /sys/fs/f2fs/<disk>/features to meet sysfs rule.
encryption, block_zoned (aka blkzoned), extra_attr,
project_quota (aka projquota), inode_checksum,
flexible_inline_xattr, quota_ino, inode_crtime, lost_found,
- verity, sb_checksum, casefold, readonly, compression.
+ verity, sb_checksum, casefold, readonly, compression,
+ encrypted_inline_data.
Note that, pin_file is moved into /sys/fs/f2fs/features/.
What: /sys/fs/f2fs/features/
@@ -271,7 +272,7 @@ Description: Shows all enabled kernel features.
inode_crtime, lost_found, verity, sb_checksum,
casefold, readonly, compression, test_dummy_encryption_v2,
atomic_write, pin_file, encrypted_casefold, linear_lookup,
- fserror.
+ fserror, encrypted_inline_data.
What: /sys/fs/f2fs/<disk>/inject_rate
Date: May 2016
diff --git a/Documentation/filesystems/f2fs.rst b/Documentation/filesystems/f2fs.rst
index 5bc37a1c4e51..651e84e8dd98 100644
--- a/Documentation/filesystems/f2fs.rst
+++ b/Documentation/filesystems/f2fs.rst
@@ -420,6 +420,36 @@ lookup_mode=%s Control the directory lookup behavior for casefolded
================== ========================================
======================== ============================================================
+Encrypted inline data
+=====================
+
+F2FS normally disables inline data for encrypted regular files, since inline
+data is stored inside the inode block and does not pass through the regular
+block I/O path. When a filesystem is formatted with the encrypted_inline_data
+feature, encrypted regular files may keep small file contents in the inode
+block. The inline payload is encrypted with fscrypt contents-key semantics
+before it is written to the inode, and it is decrypted back to page-cache
+plaintext when it is read.
+
+This feature requires the encrypt feature on disk and kernel support for
+CONFIG_F2FS_FS_ENCRYPTED_INLINE_DATA. It is intended to be used together with
+the inline_data mount option. Files using filesystem-layer encryption reuse the
+normal software contents-key transform. When the normal encrypted file
+contents path uses blk-crypto, encrypted inline data is supported for v2
+IV_INO_LBLK_64/32 policies, including hardware-wrapped key configurations
+supported by fscrypt. Per-file inlinecrypt keys and DIRECT_KEY policies are
+not supported for encrypted inline data.
+
+Encrypted inline data is stored in fscrypt contents-aligned units. Therefore,
+the maximum plaintext size that can stay inline may be slightly smaller than the
+ordinary inline data capacity. If an encrypted inline-data file is truncated
+from a non-zero offset, F2FS first converts the inline payload to normal data
+blocks and then applies the truncate operation.
+
+Recovery copies inline payloads as on-disk bytes. Encryption and decryption are
+performed only when moving data between the inode inline area and page-cache
+plaintext.
+
Debugfs Entries
===============
--
2.34.1
^ permalink raw reply related
* [PATCH v3 0/3] f2fs: support encrypted inline data
From: LiaoYuanhong-vivo @ 2026-06-15 12:55 UTC (permalink / raw)
To: Jaegeuk Kim, Chao Yu, Jonathan Corbet, Shuah Khan, Eric Biggers,
Theodore Y. Ts'o, open list:F2FS FILE SYSTEM, open list,
open list:DOCUMENTATION,
open list:FSCRYPT: FILE SYSTEM LEVEL ENCRYPTION SUPPORT
Cc: LiaoYuanhong-vivo
F2FS currently disables inline data for encrypted regular files because the
inline payload is stored in the inode block and does not go through the
regular bio-based fscrypt path. This wastes space for small encrypted
files on Android devices using F2FS inlinecrypt.
This series adds an encrypted_inline_data on-disk feature for F2FS.
With this feature enabled, encrypted regular files may keep small contents
in the inode block. The inline payload is encrypted before being stored in
the inode and decrypted back into page-cache plaintext on read.
The fscrypt changes are scoped to filesystem-managed data-unit crypto.
F2FS first asks fscrypt whether the inode's key/policy supports this path.
It prepares the software transform only when encrypted inline payloads are
read or written. Inlinecrypt support is limited to v2 IV_INO_LBLK_64 and
IV_INO_LBLK_32 policies, including the hardware-wrapped key configurations
supported by fscrypt. Per-file inlinecrypt keys and DIRECT_KEY policies
are not supported for encrypted inline data.
The basic encrypted inline-data tests pass. The test creates encrypted
small files and verifies that they retain inline data. It also checks
normal read/write correctness and confirms from the raw inode block that
the inline payload does not contain plaintext.
Changes in v3:
- Support fscrypt's v2 IV_INO_LBLK_64/32 hardware-wrapped key
configurations.
- Drop DIRECT_KEY support for encrypted inline data.
- Refresh comments and documentation for the updated key support matrix.
LiaoYuanhong-vivo (3):
fscrypt: prepare software keys for filesystem-managed data units
f2fs: support encrypted inline data
Documentation: f2fs: document encrypted inline data
Documentation/ABI/testing/sysfs-fs-f2fs | 5 +-
Documentation/filesystems/f2fs.rst | 30 ++++
fs/crypto/crypto.c | 47 +++++++
fs/crypto/fscrypt_private.h | 3 +-
fs/crypto/keysetup.c | 174 ++++++++++++++++++++++++
fs/f2fs/Kconfig | 14 ++
fs/f2fs/data.c | 8 +-
fs/f2fs/f2fs.h | 37 ++++-
fs/f2fs/file.c | 24 +++-
fs/f2fs/inline.c | 134 ++++++++++++++++--
fs/f2fs/super.c | 12 ++
fs/f2fs/sysfs.c | 8 ++
include/linux/fscrypt.h | 24 ++++
13 files changed, 497 insertions(+), 23 deletions(-)
--
2.34.1
^ permalink raw reply
* Re: [PATCH 1/3] mm/page_io: let block drivers register custom swap I/O ops
From: Jianyue Wu @ 2026-06-15 12:49 UTC (permalink / raw)
To: YoungJun Park
Cc: Andrew Morton, Christoph Hellwig, Chris Li, Baoquan He, Nhat Pham,
Barry Song, Kairui Song, Kemeng Shi, Minchan Kim,
Sergey Senozhatsky, Jens Axboe, Matthew Wilcox (Oracle), Jan Kara,
linux-mm, linux-kernel, linux-block, linux-doc
In-Reply-To: <ai9abo7GwMl+g43G@yjaykim-PowerEdge-T330>
On 6/15/2026 9:50 AM, YoungJun Park wrote:
> On Sun, Jun 14, 2026 at 11:35:29PM +0800, Jianyue Wu wrote:
>
> ...
>
> Hello Jianyue.
>
> Currently, the patch commit log indicates only a single custom swap
> registration is supported. Shouldn't we allow multiple block drivers to
> register their custom ops simultaneously from the beginning?
>
>> int shmem_writeout(struct swap_io_ctx *ctx, struct folio *folio,
>> struct list_head *folio_list);
>> diff --git a/mm/swapfile.c b/mm/swapfile.c
>> index 284eebc40a70..ebdc96092961 100644
>> --- a/mm/swapfile.c
>> +++ b/mm/swapfile.c
>> @@ -2849,6 +2849,10 @@ static int setup_swap_extents(struct swap_info_struct *sis,
>> sis->ops = &swap_bdev_ops;
>>
>> if (S_ISBLK(inode->i_mode)) {
>> + const struct swap_ops *block_ops = lookup_swap_block_ops(sis);
>
> Also, just a personal thought on this part.
>
> Instead of using `block_device_fops` as a lookup key, what if we handle
> this similarly to how filesystems use the `a_ops->swap_activate` callback?
>
> We could add a `swap_activate` callback directly into
> struct block_device_operations (zram's zram_devops). This way, the
> block device itself can set up and replace the swap `ops` directly without
> needing a separate registration/lookup mechanism.
>
> What are your thoughts on this approach?
>
> Thanks,
> Youngjun Park
>
Hello Youngjun,
On multiple registrations:
Previously I was also a bit hesitate about this. Exactly, better to
support multiple block driver directly, I'll update it.
On swap_activate:
That's a very good idea, to use swap_activate callback, it is much
cleaner, I like this approach:) setup_swap_extents() would call it for
S_ISBLK swap targets, and the driver would install sis->ops at swapon
time. When the callback is NULL, the core can fall back to
swap_bdev_activate() and swap_bdev_ops. That removes the separate global
registration/lookup mechanism entirely, and multiple block drivers are
supported naturally because each device carries its own ops table.
Thanks,
Jianyue
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox