This small series introduce support for 2-lanes mode for Airoha AN7581
SoC. This is needed for correctly functionality of Eagle WiFi Card
normally attached to this SoC that require a 2-line PCIe card to
correctly work (and give the proper performance)

The first 2 patch address a limitation of the PCIe implementation
where the PERSTOUT reset were indirectly asserted and deasserted
all at the same time (for all the 3 PCIe card) with PCIe
enable and disable.
The 2 patch address this and introduce correct reset to control
reset line for the relevant PCIe line.

The last 2 patch add additional logic and support to assert
and deassert the PERSTOUT and also apply the required configuration
for 2-lanes mode.

2-lanes mode is implemented in DT by adding the required property
and by defining the "num-lanes" to 2.

Changes v5:
- Address formal comments from Bjorn
- Drop clk patch (handled in separate series)
- Add reference to clk changes
Changes v4:
- Improve DT split patch (drop unneeded property)
- Handle power_down PERSTOUT
Changes v3:
- Add Ack from Krzysztof
- Improve commit description of PCIe patch
- Use pcie->num_lanes instead of possible uninit variable num_lanes
Changes v2:
- Address typo regs -> reg in Documentation
- Address typo lan -> lane in Documentation
- Apply a suggested fix from Airoha for PCIe MUX configuration
  before PHY init
- Parse secondary reg in probe
- Add missing reset_status handling for inverted bits
- Move SCU to local handling in power_up
- Add check for max num-lanes for EN7581

Christian Marangi (2):
  dt-bindings: PCI: mediatek-gen3: Split Airoha schema and document
    2-lanes
  PCI: mediatek-gen3: Add 2-lanes mode support for Airoha AN7581

 .../bindings/pci/airoha,en7581-pcie.yaml      | 244 ++++++++++++++++++
 .../bindings/pci/mediatek-pcie-gen3.yaml      |  77 +-----
 drivers/pci/controller/pcie-mediatek-gen3.c   | 106 ++++++--
 3 files changed, 338 insertions(+), 89 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/pci/airoha,en7581-pcie.yaml

-- 
2.53.0

On Thu, Aug 06, 2026 at 06:53:30PM +0200, Christian Marangi wrote:
> This small series introduce support for 2-lanes mode for Airoha AN7581
> SoC. This is needed for correctly functionality of Eagle WiFi Card
> normally attached to this SoC that require a 2-line PCIe card to
> correctly work (and give the proper performance)
> ...

> Christian Marangi (2):
>   dt-bindings: PCI: mediatek-gen3: Split Airoha schema and document
>     2-lanes

This is applied on pci/controller/mediatek-gen3:
https://git.kernel.org/cgit/linux/kernel/git/pci/pci.git/commit/?id=39f758dc5fbd
("dt-bindings: PCI: mediatek-gen3: Split Airoha schema and document
2-lanes")

Just a heads-up that it conflicts with Chen-Yu's patch on
pci/dt-binding:
https://git.kernel.org/cgit/linux/kernel/git/pci/pci.git/commit/?id=7e38b7b0e0e5
("dt-bindings: PCI: mediatek-gen3: Allow memory-region for restricted
DMA buffer")

https://git.kernel.org/cgit/linux/kernel/git/pci/pci.git/commit/?id=f281334a4e82
is the resolution; let me know if I did it wrong.

On Fri, Aug 14, 2026 at 05:36:38PM -0500, Bjorn Helgaas wrote:
> On Thu, Aug 06, 2026 at 06:53:30PM +0200, Christian Marangi wrote:
> > This small series introduce support for 2-lanes mode for Airoha AN7581
> > SoC. This is needed for correctly functionality of Eagle WiFi Card
> > normally attached to this SoC that require a 2-line PCIe card to
> > correctly work (and give the proper performance)
> > ...
> 
> > Christian Marangi (2):
> >   dt-bindings: PCI: mediatek-gen3: Split Airoha schema and document
> >     2-lanes
> 
> This is applied on pci/controller/mediatek-gen3:
> https://git.kernel.org/cgit/linux/kernel/git/pci/pci.git/commit/?id=39f758dc5fbd
> ("dt-bindings: PCI: mediatek-gen3: Split Airoha schema and document
> 2-lanes")

As reported by 0-day, this introduces a bunch of warnings and I don't 
see any .dts fixes (plus the need for fixes indicates a ABI change).

This should be dropped if dts changes aren't going in in the same cycle.

Rob

On Fri, Aug 21, 2026 at 03:36:39PM -0500, Rob Herring wrote:
> On Fri, Aug 14, 2026 at 05:36:38PM -0500, Bjorn Helgaas wrote:
> > On Thu, Aug 06, 2026 at 06:53:30PM +0200, Christian Marangi wrote:
> > > This small series introduce support for 2-lanes mode for Airoha AN7581
> > > SoC. This is needed for correctly functionality of Eagle WiFi Card
> > > normally attached to this SoC that require a 2-line PCIe card to
> > > correctly work (and give the proper performance)
> > > ...
> > 
> > > Christian Marangi (2):
> > >   dt-bindings: PCI: mediatek-gen3: Split Airoha schema and document
> > >     2-lanes
> > 
> > This is applied on pci/controller/mediatek-gen3:
> > https://git.kernel.org/cgit/linux/kernel/git/pci/pci.git/commit/?id=39f758dc5fbd
> > ("dt-bindings: PCI: mediatek-gen3: Split Airoha schema and document
> > 2-lanes")
> 
> As reported by 0-day, this introduces a bunch of warnings and I don't 
> see any .dts fixes (plus the need for fixes indicates a ABI change).
> 
> This should be dropped if dts changes aren't going in in the same cycle.

I dropped pci/controller/mediatek-gen3 for now; we can address this
for v7.4:

  26c53c644350 ("PCI: mediatek-gen3: Add 2-lane mode support for Airoha AN7581")
  39f758dc5fbd ("dt-bindings: PCI: mediatek-gen3: Split Airoha schema and document 2-lanes")

On Thu, 06 Aug 2026 18:53:30 +0200, Christian Marangi wrote:
> This small series introduce support for 2-lanes mode for Airoha AN7581
> SoC. This is needed for correctly functionality of Eagle WiFi Card
> normally attached to this SoC that require a 2-line PCIe card to
> correctly work (and give the proper performance)
> 
> The first 2 patch address a limitation of the PCIe implementation
> where the PERSTOUT reset were indirectly asserted and deasserted
> all at the same time (for all the 3 PCIe card) with PCIe
> enable and disable.
> The 2 patch address this and introduce correct reset to control
> reset line for the relevant PCIe line.
> 
> [...]

Applied, thanks!

[1/2] dt-bindings: PCI: mediatek-gen3: Split Airoha schema and document 2-lanes
      commit: c48c637255625f23bbeabbe63dc2d6a4b70c680a
[2/2] PCI: mediatek-gen3: Add 2-lanes mode support for Airoha AN7581
      commit: 8d076be9a10c68f7fac5d6a180bff19053b91dca

Best regards,
-- 
மணிவண்ணன் சதாசிவம்

On Fri, Aug 7, 2026 at 12:53 AM Christian Marangi <ansuelsmth@gmail.com> wrote:
> This small series introduce support for 2-lanes mode for Airoha AN7581

Just a nitpick, but I would probably name this something else, like
"cross-controller lane-bonding mode" or "lane stealing"? PCIe already
has 2x lanes as a standard feature, so this naming is a bit confusing.
It's not like dual-LVDS display in which LVDS is only a single lane.


ChenYu

> SoC. This is needed for correctly functionality of Eagle WiFi Card
> normally attached to this SoC that require a 2-line PCIe card to
> correctly work (and give the proper performance)
>
> The first 2 patch address a limitation of the PCIe implementation
> where the PERSTOUT reset were indirectly asserted and deasserted
> all at the same time (for all the 3 PCIe card) with PCIe
> enable and disable.
> The 2 patch address this and introduce correct reset to control
> reset line for the relevant PCIe line.
>
> The last 2 patch add additional logic and support to assert
> and deassert the PERSTOUT and also apply the required configuration
> for 2-lanes mode.
>
> 2-lanes mode is implemented in DT by adding the required property
> and by defining the "num-lanes" to 2.
>
> Changes v5:
> - Address formal comments from Bjorn
> - Drop clk patch (handled in separate series)
> - Add reference to clk changes
> Changes v4:
> - Improve DT split patch (drop unneeded property)
> - Handle power_down PERSTOUT
> Changes v3:
> - Add Ack from Krzysztof
> - Improve commit description of PCIe patch
> - Use pcie->num_lanes instead of possible uninit variable num_lanes
> Changes v2:
> - Address typo regs -> reg in Documentation
> - Address typo lan -> lane in Documentation
> - Apply a suggested fix from Airoha for PCIe MUX configuration
>   before PHY init
> - Parse secondary reg in probe
> - Add missing reset_status handling for inverted bits
> - Move SCU to local handling in power_up
> - Add check for max num-lanes for EN7581
>
> Christian Marangi (2):
>   dt-bindings: PCI: mediatek-gen3: Split Airoha schema and document
>     2-lanes
>   PCI: mediatek-gen3: Add 2-lanes mode support for Airoha AN7581
>
>  .../bindings/pci/airoha,en7581-pcie.yaml      | 244 ++++++++++++++++++
>  .../bindings/pci/mediatek-pcie-gen3.yaml      |  77 +-----
>  drivers/pci/controller/pcie-mediatek-gen3.c   | 106 ++++++--
>  3 files changed, 338 insertions(+), 89 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/pci/airoha,en7581-pcie.yaml
>
> --
> 2.53.0
>
>

On Fri, Aug 07, 2026 at 11:24:09AM +0800, Chen-Yu Tsai wrote:
> On Fri, Aug 7, 2026 at 12:53 AM Christian Marangi <ansuelsmth@gmail.com> wrote:
> > This small series introduce support for 2-lanes mode for Airoha AN7581
> 
> Just a nitpick, but I would probably name this something else, like
> "cross-controller lane-bonding mode" or "lane stealing"? PCIe already
> has 2x lanes as a standard feature, so this naming is a bit confusing.
> It's not like dual-LVDS display in which LVDS is only a single lane.

I suggested the "2-lane" and "x2" terminology because I assumed the
result is what the PCIe spec would describe as a "x2 Link" consisting
of two Lanes. 

If that's not the case, maybe "cross-controller lane-bonding mode" or
"lane stealing" would be more accurate, but I don't know what those
mean, so if we use them I would also like to know what the result
looks like in standard PCIe terms.

> > SoC. This is needed for correctly functionality of Eagle WiFi Card
> > normally attached to this SoC that require a 2-line PCIe card to
> > correctly work (and give the proper performance)
> >
> > The first 2 patch address a limitation of the PCIe implementation
> > where the PERSTOUT reset were indirectly asserted and deasserted
> > all at the same time (for all the 3 PCIe card) with PCIe
> > enable and disable.
> > The 2 patch address this and introduce correct reset to control
> > reset line for the relevant PCIe line.
> >
> > The last 2 patch add additional logic and support to assert
> > and deassert the PERSTOUT and also apply the required configuration
> > for 2-lanes mode.
> >
> > 2-lanes mode is implemented in DT by adding the required property
> > and by defining the "num-lanes" to 2.

On Fri, Aug 7, 2026 at 11:21 PM Bjorn Helgaas <helgaas@kernel.org> wrote:
>
> On Fri, Aug 07, 2026 at 11:24:09AM +0800, Chen-Yu Tsai wrote:
> > On Fri, Aug 7, 2026 at 12:53 AM Christian Marangi <ansuelsmth@gmail.com> wrote:
> > > This small series introduce support for 2-lanes mode for Airoha AN7581
> >
> > Just a nitpick, but I would probably name this something else, like
> > "cross-controller lane-bonding mode" or "lane stealing"? PCIe already
> > has 2x lanes as a standard feature, so this naming is a bit confusing.
> > It's not like dual-LVDS display in which LVDS is only a single lane.
>
> I suggested the "2-lane" and "x2" terminology because I assumed the
> result is what the PCIe spec would describe as a "x2 Link" consisting
> of two Lanes.
>
> If that's not the case, maybe "cross-controller lane-bonding mode" or
> "lane stealing" would be more accurate, but I don't know what those
> mean, so if we use them I would also like to know what the result
> looks like in standard PCIe terms.

Benjamin pointed out later in the thread that it is just bifurcation.

I would assume "PCIe bifurcation" is a standard term, so maybe we could
call this "Support un-bifurcated 2-lane operation"?

On the implementation side, having to reach into the second PCIe controller
is a bit messy :(


ChenYu

> > > SoC. This is needed for correctly functionality of Eagle WiFi Card
> > > normally attached to this SoC that require a 2-line PCIe card to
> > > correctly work (and give the proper performance)
> > >
> > > The first 2 patch address a limitation of the PCIe implementation
> > > where the PERSTOUT reset were indirectly asserted and deasserted
> > > all at the same time (for all the 3 PCIe card) with PCIe
> > > enable and disable.
> > > The 2 patch address this and introduce correct reset to control
> > > reset line for the relevant PCIe line.
> > >
> > > The last 2 patch add additional logic and support to assert
> > > and deassert the PERSTOUT and also apply the required configuration
> > > for 2-lanes mode.
> > >
> > > 2-lanes mode is implemented in DT by adding the required property
> > > and by defining the "num-lanes" to 2.

Il giorno lun 10 ago 2026 alle ore 12:33 Chen-Yu Tsai
<wenst@chromium.org> ha scritto:
>
> On Fri, Aug 7, 2026 at 11:21 PM Bjorn Helgaas <helgaas@kernel.org> wrote:
> >
> > On Fri, Aug 07, 2026 at 11:24:09AM +0800, Chen-Yu Tsai wrote:
> > > On Fri, Aug 7, 2026 at 12:53 AM Christian Marangi <ansuelsmth@gmail.com> wrote:
> > > > This small series introduce support for 2-lanes mode for Airoha AN7581
> > >
> > > Just a nitpick, but I would probably name this something else, like
> > > "cross-controller lane-bonding mode" or "lane stealing"? PCIe already
> > > has 2x lanes as a standard feature, so this naming is a bit confusing.
> > > It's not like dual-LVDS display in which LVDS is only a single lane.
> >
> > I suggested the "2-lane" and "x2" terminology because I assumed the
> > result is what the PCIe spec would describe as a "x2 Link" consisting
> > of two Lanes.
> >
> > If that's not the case, maybe "cross-controller lane-bonding mode" or
> > "lane stealing" would be more accurate, but I don't know what those
> > mean, so if we use them I would also like to know what the result
> > looks like in standard PCIe terms.
>
> Benjamin pointed out later in the thread that it is just bifurcation.
>

Yes but as me, you, Benjamin and Bjorn people who weren't there with the HW
team at times the SoC was created, and given how the internal documentation
these are just assumption and observation... Everyone can be correct and wrong.

> I would assume "PCIe bifurcation" is a standard term, so maybe we could
> call this "Support un-bifurcated 2-lane operation"?
>

And how coming from PCIe bifurcation to un-bifurcated 2-lane operation keeps
the standard meaning?

This terms is equally custom as the previous "cross-controller
lane-bonding mode"
and "lane stealing"

I want to be honest... I'm not following why we are trying in every
way possible to find
a standard meaning for an highly integrated PCIe controller for a vendor SoC.
It's not like there are devices shipped with PCIe slot where you can
insert whatever
card you want. (there is only a single RFB board but that is really to
debug stuff and
develop)

The SoC is designed to have WiFi cards attached and only a subset of them.
And some of them require 2 lanes mode to work with this special configuration.

Even the DT bindings are not that specific to the details... at the
end of the day
everything is modelled as simple as "num-lanes = <2>;"

And that is effectively what the HW gets configured to. If then a
robbery is done
internally to the HW to get the second lane with probably some criminal act and
some murder then those are just details. But unless we have a correct police
report on that (Documentation) we can't assume someone got shot in the
process.
(sorry for the joke around the stealing thing)

> On the implementation side, having to reach into the second PCIe controller
> is a bit messy :(
>

I can assure you vendor hide all kind of bad stuff behind single register...
It's just Airoha that loves to expose godzillion registers and configure
everything clearly... Something that most of the time is better than hiding
everything behind ATF with SCM commands (or even configure stuff
in bootloader from HW strap)

A bonding solution where 2 controllers are configured and then bonded might
also be problematic as for 2 lanes mode the configuration needs to be done
in the same time segment. (and that would introduce lots of complexity in
both DT and driver for the sake of just having an additional reset and
an additional reg)

Aside from these 2 point... I'm open to any kind of naming and change
but it seems sad to me to delay this feature for these details that would
only affect the commit description and nothing else... This is currently needed
for Eagle WiFi card to correctly works... With the current code it works but
sometimes it doesn't as the reset and configuration phase is not well defined.
This series fix exactly that to have stable functionality (tested on OpenWrt
from at least half a year)

> > > > SoC. This is needed for correctly functionality of Eagle WiFi Card
> > > > normally attached to this SoC that require a 2-line PCIe card to
> > > > correctly work (and give the proper performance)
> > > >
> > > > The first 2 patch address a limitation of the PCIe implementation
> > > > where the PERSTOUT reset were indirectly asserted and deasserted
> > > > all at the same time (for all the 3 PCIe card) with PCIe
> > > > enable and disable.
> > > > The 2 patch address this and introduce correct reset to control
> > > > reset line for the relevant PCIe line.
> > > >
> > > > The last 2 patch add additional logic and support to assert
> > > > and deassert the PERSTOUT and also apply the required configuration
> > > > for 2-lanes mode.
> > > >
> > > > 2-lanes mode is implemented in DT by adding the required property
> > > > and by defining the "num-lanes" to 2.

On Mon, Aug 10, 2026 at 6:55 PM Christian Marangi (Ansuel)
<ansuelsmth@gmail.com> wrote:
>
> Il giorno lun 10 ago 2026 alle ore 12:33 Chen-Yu Tsai
> <wenst@chromium.org> ha scritto:
> >
> > On Fri, Aug 7, 2026 at 11:21 PM Bjorn Helgaas <helgaas@kernel.org> wrote:
> > >
> > > On Fri, Aug 07, 2026 at 11:24:09AM +0800, Chen-Yu Tsai wrote:
> > > > On Fri, Aug 7, 2026 at 12:53 AM Christian Marangi <ansuelsmth@gmail.com> wrote:
> > > > > This small series introduce support for 2-lanes mode for Airoha AN7581
> > > >
> > > > Just a nitpick, but I would probably name this something else, like
> > > > "cross-controller lane-bonding mode" or "lane stealing"? PCIe already
> > > > has 2x lanes as a standard feature, so this naming is a bit confusing.
> > > > It's not like dual-LVDS display in which LVDS is only a single lane.
> > >
> > > I suggested the "2-lane" and "x2" terminology because I assumed the
> > > result is what the PCIe spec would describe as a "x2 Link" consisting
> > > of two Lanes.
> > >
> > > If that's not the case, maybe "cross-controller lane-bonding mode" or
> > > "lane stealing" would be more accurate, but I don't know what those
> > > mean, so if we use them I would also like to know what the result
> > > looks like in standard PCIe terms.
> >
> > Benjamin pointed out later in the thread that it is just bifurcation.
> >
>
> Yes but as me, you, Benjamin and Bjorn people who weren't there with the HW
> team at times the SoC was created, and given how the internal documentation
> these are just assumption and observation... Everyone can be correct and wrong.
>
> > I would assume "PCIe bifurcation" is a standard term, so maybe we could
> > call this "Support un-bifurcated 2-lane operation"?
> >
>
> And how coming from PCIe bifurcation to un-bifurcated 2-lane operation keeps
> the standard meaning?
>
> This terms is equally custom as the previous "cross-controller
> lane-bonding mode"
> and "lane stealing"
>
> I want to be honest... I'm not following why we are trying in every
> way possible to find
> a standard meaning for an highly integrated PCIe controller for a vendor SoC.
> It's not like there are devices shipped with PCIe slot where you can
> insert whatever
> card you want. (there is only a single RFB board but that is really to
> debug stuff and
> develop)
>
> The SoC is designed to have WiFi cards attached and only a subset of them.
> And some of them require 2 lanes mode to work with this special configuration.
>
> Even the DT bindings are not that specific to the details... at the
> end of the day
> everything is modelled as simple as "num-lanes = <2>;"
>
> And that is effectively what the HW gets configured to. If then a
> robbery is done
> internally to the HW to get the second lane with probably some criminal act and
> some murder then those are just details. But unless we have a correct police
> report on that (Documentation) we can't assume someone got shot in the
> process.
> (sorry for the joke around the stealing thing)
>
> > On the implementation side, having to reach into the second PCIe controller
> > is a bit messy :(
> >
>
> I can assure you vendor hide all kind of bad stuff behind single register...
> It's just Airoha that loves to expose godzillion registers and configure
> everything clearly... Something that most of the time is better than hiding
> everything behind ATF with SCM commands (or even configure stuff
> in bootloader from HW strap)
>
> A bonding solution where 2 controllers are configured and then bonded might
> also be problematic as for 2 lanes mode the configuration needs to be done
> in the same time segment. (and that would introduce lots of complexity in
> both DT and driver for the sake of just having an additional reset and
> an additional reg)
>
> Aside from these 2 point... I'm open to any kind of naming and change
> but it seems sad to me to delay this feature for these details that would
> only affect the commit description and nothing else... This is currently needed
> for Eagle WiFi card to correctly works... With the current code it works but
> sometimes it doesn't as the reset and configuration phase is not well defined.
> This series fix exactly that to have stable functionality (tested on OpenWrt
> from at least half a year)

It was not my intention to block this. Having worked on other MediaTek
SoCs on which the PCIe gen4 controller, supported by the same driver,
can do up to 2 lanes natively, the subject of the cover letter was a bit
confusing for me.

Now that you've explained it, everything is clear.

> > > > > SoC. This is needed for correctly functionality of Eagle WiFi Card
> > > > > normally attached to this SoC that require a 2-line PCIe card to
> > > > > correctly work (and give the proper performance)
> > > > >
> > > > > The first 2 patch address a limitation of the PCIe implementation
> > > > > where the PERSTOUT reset were indirectly asserted and deasserted
> > > > > all at the same time (for all the 3 PCIe card) with PCIe
> > > > > enable and disable.
> > > > > The 2 patch address this and introduce correct reset to control
> > > > > reset line for the relevant PCIe line.
> > > > >
> > > > > The last 2 patch add additional logic and support to assert
> > > > > and deassert the PERSTOUT and also apply the required configuration
> > > > > for 2-lanes mode.
> > > > >
> > > > > 2-lanes mode is implemented in DT by adding the required property
> > > > > and by defining the "num-lanes" to 2.

Hi.

On 10/08/2026 12:55, Christian Marangi (Ansuel) wrote:
> Il giorno lun 10 ago 2026 alle ore 12:33 Chen-Yu Tsai
> <wenst@chromium.org> ha scritto:
>>
>> On Fri, Aug 7, 2026 at 11:21 PM Bjorn Helgaas <helgaas@kernel.org> wrote:
>>>
>>> On Fri, Aug 07, 2026 at 11:24:09AM +0800, Chen-Yu Tsai wrote:
>>>> On Fri, Aug 7, 2026 at 12:53 AM Christian Marangi <ansuelsmth@gmail.com> wrote:
>>>>> This small series introduce support for 2-lanes mode for Airoha AN7581
>>>>
>>>> Just a nitpick, but I would probably name this something else, like
>>>> "cross-controller lane-bonding mode" or "lane stealing"? PCIe already
>>>> has 2x lanes as a standard feature, so this naming is a bit confusing.
>>>> It's not like dual-LVDS display in which LVDS is only a single lane.
>>>
>>> I suggested the "2-lane" and "x2" terminology because I assumed the
>>> result is what the PCIe spec would describe as a "x2 Link" consisting
>>> of two Lanes.
>>>
>>> If that's not the case, maybe "cross-controller lane-bonding mode" or
>>> "lane stealing" would be more accurate, but I don't know what those
>>> mean, so if we use them I would also like to know what the result
>>> looks like in standard PCIe terms.
>>
>> Benjamin pointed out later in the thread that it is just bifurcation.
>>
> 
> Yes but as me, you, Benjamin and Bjorn people who weren't there with the HW
> team at times the SoC was created, and given how the internal documentation
> these are just assumption and observation... Everyone can be correct and wrong.
> 
>> I would assume "PCIe bifurcation" is a standard term, so maybe we could
>> call this "Support un-bifurcated 2-lane operation"?
>>
> 
> And how coming from PCIe bifurcation to un-bifurcated 2-lane operation keeps
> the standard meaning?
> 
> This terms is equally custom as the previous "cross-controller
> lane-bonding mode"
> and "lane stealing"
> 
> I want to be honest... I'm not following why we are trying in every
> way possible to find
> a standard meaning for an highly integrated PCIe controller for a vendor SoC.
> It's not like there are devices shipped with PCIe slot where you can
> insert whatever
> card you want. (there is only a single RFB board but that is really to
> debug stuff and
> develop)
> 
> The SoC is designed to have WiFi cards attached and only a subset of them.
> And some of them require 2 lanes mode to work with this special configuration.
> 
> Even the DT bindings are not that specific to the details... at the
> end of the day
> everything is modelled as simple as "num-lanes = <2>;"
> 
Hi, I agree with Christian here. The property num-lanes will be able to 
describe all possible pcie configurations of the AN7581 and AN7563 SoCs 
(the AN7563 is using the same pci controller if I understand things 
correctly). Adding more properties will not make it less complex.

MvH
Benjamin Larsson

Il giorno ven 7 ago 2026 alle ore 17:21 Bjorn Helgaas
<helgaas@kernel.org> ha scritto:
>
> On Fri, Aug 07, 2026 at 11:24:09AM +0800, Chen-Yu Tsai wrote:
> > On Fri, Aug 7, 2026 at 12:53 AM Christian Marangi <ansuelsmth@gmail.com> wrote:
> > > This small series introduce support for 2-lanes mode for Airoha AN7581
> >
> > Just a nitpick, but I would probably name this something else, like
> > "cross-controller lane-bonding mode" or "lane stealing"? PCIe already
> > has 2x lanes as a standard feature, so this naming is a bit confusing.
> > It's not like dual-LVDS display in which LVDS is only a single lane.
>
> I suggested the "2-lane" and "x2" terminology because I assumed the
> result is what the PCIe spec would describe as a "x2 Link" consisting
> of two Lanes.
>
> If that's not the case, maybe "cross-controller lane-bonding mode" or
> "lane stealing" would be more accurate, but I don't know what those
> mean, so if we use them I would also like to know what the result
> looks like in standard PCIe terms.
>

Mhhh I don't really like the term lane stealing. Also cross-controller
lane-bonding
might be a first. Even if correct it would complicate identification
of the feature
that at the end of the day configures the HW to provide a 2 lanes PCIe.

Consider that in such mode, the other PCIe controller gets disabled (this is
handled in DT) so it's effectively enabling the standard PCIe 2x lanes
and apply the HW configuration for it.

> > > SoC. This is needed for correctly functionality of Eagle WiFi Card
> > > normally attached to this SoC that require a 2-line PCIe card to
> > > correctly work (and give the proper performance)
> > >
> > > The first 2 patch address a limitation of the PCIe implementation
> > > where the PERSTOUT reset were indirectly asserted and deasserted
> > > all at the same time (for all the 3 PCIe card) with PCIe
> > > enable and disable.
> > > The 2 patch address this and introduce correct reset to control
> > > reset line for the relevant PCIe line.
> > >
> > > The last 2 patch add additional logic and support to assert
> > > and deassert the PERSTOUT and also apply the required configuration
> > > for 2-lanes mode.
> > >
> > > 2-lanes mode is implemented in DT by adding the required property
> > > and by defining the "num-lanes" to 2.

On 09/08/2026 14:12, Christian Marangi (Ansuel) wrote:
> Il giorno ven 7 ago 2026 alle ore 17:21 Bjorn Helgaas
> <helgaas@kernel.org> ha scritto:
>>
>> On Fri, Aug 07, 2026 at 11:24:09AM +0800, Chen-Yu Tsai wrote:
>>> On Fri, Aug 7, 2026 at 12:53 AM Christian Marangi <ansuelsmth@gmail.com> wrote:
>>>> This small series introduce support for 2-lanes mode for Airoha AN7581
>>>
>>> Just a nitpick, but I would probably name this something else, like
>>> "cross-controller lane-bonding mode" or "lane stealing"? PCIe already
>>> has 2x lanes as a standard feature, so this naming is a bit confusing.
>>> It's not like dual-LVDS display in which LVDS is only a single lane.
>>
>> I suggested the "2-lane" and "x2" terminology because I assumed the
>> result is what the PCIe spec would describe as a "x2 Link" consisting
>> of two Lanes.
>>
>> If that's not the case, maybe "cross-controller lane-bonding mode" or
>> "lane stealing" would be more accurate, but I don't know what those
>> mean, so if we use them I would also like to know what the result
>> looks like in standard PCIe terms.
>>
> 
> Mhhh I don't really like the term lane stealing. Also cross-controller
> lane-bonding
> might be a first. Even if correct it would complicate identification
> of the feature
> that at the end of the day configures the HW to provide a 2 lanes PCIe.
> 
> Consider that in such mode, the other PCIe controller gets disabled (this is
> handled in DT) so it's effectively enabling the standard PCIe 2x lanes
> and apply the HW configuration for it.
> 
>>>> SoC. This is needed for correctly functionality of Eagle WiFi Card
>>>> normally attached to this SoC that require a 2-line PCIe card to
>>>> correctly work (and give the proper performance)
>>>>
>>>> The first 2 patch address a limitation of the PCIe implementation
>>>> where the PERSTOUT reset were indirectly asserted and deasserted
>>>> all at the same time (for all the 3 PCIe card) with PCIe
>>>> enable and disable.
>>>> The 2 patch address this and introduce correct reset to control
>>>> reset line for the relevant PCIe line.
>>>>
>>>> The last 2 patch add additional logic and support to assert
>>>> and deassert the PERSTOUT and also apply the required configuration
>>>> for 2-lanes mode.
>>>>
>>>> 2-lanes mode is implemented in DT by adding the required property
>>>> and by defining the "num-lanes" to 2.
> 

Hi. Isnt this just pcie bifurcation?

Logically bifurcation would need to be disabled when using 2 lanes in 
one slot and enabled when 2 lanes are split between 2 pcie slots.

But I'm not really sure what value a bifurcation property would add. 
Isnt the current schema enough?

The mt7987 will need the same logic as it can also bifurcate one pcie slot.

MvH
Benjamin Larsson

Il giorno dom 9 ago 2026 alle ore 16:08 Benjamin Larsson
<benjamin.larsson@genexis.eu> ha scritto:
>
> On 09/08/2026 14:12, Christian Marangi (Ansuel) wrote:
> > Il giorno ven 7 ago 2026 alle ore 17:21 Bjorn Helgaas
> > <helgaas@kernel.org> ha scritto:
> >>
> >> On Fri, Aug 07, 2026 at 11:24:09AM +0800, Chen-Yu Tsai wrote:
> >>> On Fri, Aug 7, 2026 at 12:53 AM Christian Marangi <ansuelsmth@gmail.com> wrote:
> >>>> This small series introduce support for 2-lanes mode for Airoha AN7581
> >>>
> >>> Just a nitpick, but I would probably name this something else, like
> >>> "cross-controller lane-bonding mode" or "lane stealing"? PCIe already
> >>> has 2x lanes as a standard feature, so this naming is a bit confusing.
> >>> It's not like dual-LVDS display in which LVDS is only a single lane.
> >>
> >> I suggested the "2-lane" and "x2" terminology because I assumed the
> >> result is what the PCIe spec would describe as a "x2 Link" consisting
> >> of two Lanes.
> >>
> >> If that's not the case, maybe "cross-controller lane-bonding mode" or
> >> "lane stealing" would be more accurate, but I don't know what those
> >> mean, so if we use them I would also like to know what the result
> >> looks like in standard PCIe terms.
> >>
> >
> > Mhhh I don't really like the term lane stealing. Also cross-controller
> > lane-bonding
> > might be a first. Even if correct it would complicate identification
> > of the feature
> > that at the end of the day configures the HW to provide a 2 lanes PCIe.
> >
> > Consider that in such mode, the other PCIe controller gets disabled (this is
> > handled in DT) so it's effectively enabling the standard PCIe 2x lanes
> > and apply the HW configuration for it.
> >
> >>>> SoC. This is needed for correctly functionality of Eagle WiFi Card
> >>>> normally attached to this SoC that require a 2-line PCIe card to
> >>>> correctly work (and give the proper performance)
> >>>>
> >>>> The first 2 patch address a limitation of the PCIe implementation
> >>>> where the PERSTOUT reset were indirectly asserted and deasserted
> >>>> all at the same time (for all the 3 PCIe card) with PCIe
> >>>> enable and disable.
> >>>> The 2 patch address this and introduce correct reset to control
> >>>> reset line for the relevant PCIe line.
> >>>>
> >>>> The last 2 patch add additional logic and support to assert
> >>>> and deassert the PERSTOUT and also apply the required configuration
> >>>> for 2-lanes mode.
> >>>>
> >>>> 2-lanes mode is implemented in DT by adding the required property
> >>>> and by defining the "num-lanes" to 2.
> >
>
> Hi. Isnt this just pcie bifurcation?
>
> Logically bifurcation would need to be disabled when using 2 lanes in
> one slot and enabled when 2 lanes are split between 2 pcie slots.
>
> But I'm not really sure what value a bifurcation property would add.
> Isnt the current schema enough?
>
> The mt7987 will need the same logic as it can also bifurcate one pcie slot.
>

The documentation is not so kind on these kind of details... and no register
for bifurcation... maybe it's the mux one? But the mux settings comes from
reverse as in documentation that SCU register is a good 7:0 bits of
data value...

On 09/08/2026 16:14, Christian Marangi (Ansuel) wrote:
> Il giorno dom 9 ago 2026 alle ore 16:08 Benjamin Larsson
> <benjamin.larsson@genexis.eu> ha scritto:
>>
>> On 09/08/2026 14:12, Christian Marangi (Ansuel) wrote:
>>> Il giorno ven 7 ago 2026 alle ore 17:21 Bjorn Helgaas
>>> <helgaas@kernel.org> ha scritto:
>>>>
>>>> On Fri, Aug 07, 2026 at 11:24:09AM +0800, Chen-Yu Tsai wrote:
>>>>> On Fri, Aug 7, 2026 at 12:53 AM Christian Marangi <ansuelsmth@gmail.com> wrote:
>>>>>> This small series introduce support for 2-lanes mode for Airoha AN7581
>>>>>
>>>>> Just a nitpick, but I would probably name this something else, like
>>>>> "cross-controller lane-bonding mode" or "lane stealing"? PCIe already
>>>>> has 2x lanes as a standard feature, so this naming is a bit confusing.
>>>>> It's not like dual-LVDS display in which LVDS is only a single lane.
>>>>
>>>> I suggested the "2-lane" and "x2" terminology because I assumed the
>>>> result is what the PCIe spec would describe as a "x2 Link" consisting
>>>> of two Lanes.
>>>>
>>>> If that's not the case, maybe "cross-controller lane-bonding mode" or
>>>> "lane stealing" would be more accurate, but I don't know what those
>>>> mean, so if we use them I would also like to know what the result
>>>> looks like in standard PCIe terms.
>>>>
>>>
>>> Mhhh I don't really like the term lane stealing. Also cross-controller
>>> lane-bonding
>>> might be a first. Even if correct it would complicate identification
>>> of the feature
>>> that at the end of the day configures the HW to provide a 2 lanes PCIe.
>>>
>>> Consider that in such mode, the other PCIe controller gets disabled (this is
>>> handled in DT) so it's effectively enabling the standard PCIe 2x lanes
>>> and apply the HW configuration for it.
>>>
>>>>>> SoC. This is needed for correctly functionality of Eagle WiFi Card
>>>>>> normally attached to this SoC that require a 2-line PCIe card to
>>>>>> correctly work (and give the proper performance)
>>>>>>
>>>>>> The first 2 patch address a limitation of the PCIe implementation
>>>>>> where the PERSTOUT reset were indirectly asserted and deasserted
>>>>>> all at the same time (for all the 3 PCIe card) with PCIe
>>>>>> enable and disable.
>>>>>> The 2 patch address this and introduce correct reset to control
>>>>>> reset line for the relevant PCIe line.
>>>>>>
>>>>>> The last 2 patch add additional logic and support to assert
>>>>>> and deassert the PERSTOUT and also apply the required configuration
>>>>>> for 2-lanes mode.
>>>>>>
>>>>>> 2-lanes mode is implemented in DT by adding the required property
>>>>>> and by defining the "num-lanes" to 2.
>>>
>>
>> Hi. Isnt this just pcie bifurcation?
>>
>> Logically bifurcation would need to be disabled when using 2 lanes in
>> one slot and enabled when 2 lanes are split between 2 pcie slots.
>>
>> But I'm not really sure what value a bifurcation property would add.
>> Isnt the current schema enough?
>>
>> The mt7987 will need the same logic as it can also bifurcate one pcie slot.
>>
> 
> The documentation is not so kind on these kind of details... and no register
> for bifurcation... maybe it's the mux one? But the mux settings comes from
> reverse as in documentation that SCU register is a good 7:0 bits of
> data value...

Hi, yeah I think the SCU documentation is wrong for the AN7581. At least 
for the W1700k v1 device SoC version. It works without the SCU PCIC bit 
set there IIRC.

https://forum.openwrt.org/t/quantum-fiber-w1700k-support/222776/280

The vendor driver has this:
https://github.com/merbanan/airoha_pcie/blob/main/airoha_pcie/en7581/pcie-ecnt-phy_7581.c#L1671

Maybe this is the only bit that control the bifurcation?

MvH
Benjamin Larsson