Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider: - [Medium] The patch replaces direct access to `phy->attrs.bus_width` with a consumer API to prepare for `struct phy` becoming opaque, but fails to replace the direct access to `phy->attrs.max_link_rate` just a few lines below. --
--- Patch [2]: [PATCH v9 2/2] drm: bridge: cdns-mhdp8546: use consumer API for getting PHY bus width --- commit ecf7ebc5abfe88e7d5e12ae439973da7de3f9c25 Author: Vladimir Oltean <[email protected]> drm: bridge: cdns-mhdp8546: use consumer API for getting PHY bus width This commit updates the driver to use the phy_get_bus_width() API instead of directly accessing phy->attrs.bus_width. This is being done because the definition of struct phy will soon be hidden from consumers. > diff --git a/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c > b/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c > index c99151fdaf03d..796c64cb18e77 100644 > --- a/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c > +++ b/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c > @@ -1300,7 +1300,7 @@ static void cdns_mhdp_fill_host_caps(struct > cdns_mhdp_device *mhdp) > > /* Get source capabilities based on PHY attributes */ > > - mhdp->host.lanes_cnt = mhdp->phy->attrs.bus_width; > + mhdp->host.lanes_cnt = phy_get_bus_width(mhdp->phy); > if (!mhdp->host.lanes_cnt) > mhdp->host.lanes_cnt = 4; > [Severity: Medium] Since the goal is to stop accessing the phy attributes directly because struct phy will be hidden, does this also need to replace the access to max_link_rate just a few lines down? In cdns_mhdp_fill_host_caps(): mhdp->host.lanes_cnt = phy_get_bus_width(mhdp->phy); if (!mhdp->host.lanes_cnt) mhdp->host.lanes_cnt = 4; link_rate = mhdp->phy->attrs.max_link_rate; If struct phy becomes opaque, won't this remaining direct access to max_link_rate still cause a build failure? -- Sashiko AI review ยท https://sashiko.dev/#/patchset/[email protected]?part=2
