On Thu, Jun 11, 2026 at 10:39:38PM +0300, Vladimir Oltean wrote:
> In Layerscape (Arm) and QorIQ (PowerPC) devices, hardware peripherals
> are accessed by the CPU through a portion of the SoC address space
> called CCSR ("Configuration, Control, and Status Registers"). All
> hardware IP blocks have their registers mapped here, and the Device
> Configuration block makes no exception.
>
> However, there exists a secondary range of the address space named DCSR
> ("Debug Control and Status Registers") which, like CCSR, also holds
> registers of hardware IP blocks, except the DCSR contents is hidden in
> all public reference manuals.
>
> The intention of the CCSR/DCSR split, to the best of my knowledge, was
> to place the functionality that is too low level for normal use, and
> which is necessary only for debug, in a completely separate address
> space which can be hidden.
>
> A use case has appeared where networking SerDes lanes need to be
> reconfigured at runtime for a different protocol (example: 10GBase-R to
> SGMII), and the architecture of the SoCs does not normally permit that.
> The Reset Configuration Word (RCW) is a data structure read by the SoC
> preboot loader (PBL) which contains stuff like pinmuxing and SerDes
> protocol mapping for each lane.
>
> The RCW that the PBL has loaded is visible in the DCFG block's normal
> status registers (from CCSR), as read only. Turns out, the RCW is also
> mapped in the DCFG's shadow register map (in DCSR), in a write-only
> form. Writing to the RCW registers from the DCFG's DCSR space to change
> what the PBL has loaded is called "RCW override".
>
> It has been validated that the RCW override procedure is necessary to
> reconfigure the networking data path when a SerDes lane performs a major
> protocol change. It changes some internal muxes which connect the PCS to
> either the 10G MAC or to the 1G MAC.
>
> Defining the DCSR area of the DCFG as a secondary 'reg' array element
> allows operating systems to perform RCW overrides. Since it is
> introduced late in the binding's lifetime, it is optional. It can be
> identified by name, but also by index (first 'reg' is CCSR).
>
> Note that while all SoCs should have a DCFG register block in DCSR, we
> only need to expose it for the SoCs where the RCW override procedure is
> known to be needed and has been validated.
>
> Signed-off-by: Vladimir Oltean <[email protected]>
> ---
> Cc: Conor Dooley <[email protected]>Where did this email come from btw? get_maintainer.pl result should have +dt in it. Reviewed-by: Conor Dooley <[email protected]> pw-bot: not-applicable Cheers, Conor. > Cc: Krzysztof Kozlowski <[email protected]> > Cc: Rob Herring <[email protected]> > Cc: [email protected] > --- > .../bindings/soc/fsl/fsl,layerscape-dcfg.yaml | 15 ++++++++++++++- > 1 file changed, 14 insertions(+), 1 deletion(-) > > diff --git > a/Documentation/devicetree/bindings/soc/fsl/fsl,layerscape-dcfg.yaml > b/Documentation/devicetree/bindings/soc/fsl/fsl,layerscape-dcfg.yaml > index 3fb0534ea597..fc14fd0bf84b 100644 > --- a/Documentation/devicetree/bindings/soc/fsl/fsl,layerscape-dcfg.yaml > +++ b/Documentation/devicetree/bindings/soc/fsl/fsl,layerscape-dcfg.yaml > @@ -36,7 +36,20 @@ properties: > - const: simple-mfd > > reg: > - maxItems: 1 > + minItems: 1 > + items: > + - description: > + Customer-visible DCFG register map from CCSR address space > + (Configuration, Control and Status Registers) > + - description: > + Customer-hidden DCFG register map from DCSR address space > + (Debug Control and Status Registers) > + > + reg-names: > + minItems: 1 > + items: > + - const: dcfg_ccsr > + - const: dcfg_dcsr > > little-endian: true > big-endian: true > -- > 2.34.1 >
signature.asc
Description: PGP signature
