[PW_SID:1088067] Split Generic PHY consumer and provider#1853
Closed
linux-riscv-bot wants to merge 28 commits into
Closed
[PW_SID:1088067] Split Generic PHY consumer and provider#1853linux-riscv-bot wants to merge 28 commits into
linux-riscv-bot wants to merge 28 commits into
Conversation
It appears that libahci.c, ahci.c as well as the ahci_brcm, ahci_ceva and ahci_qoriq drivers are using runtime PM operations without including <linux/pm_runtime.h>. This header is somehow being indirectly provided by <linux/phy/phy.h>, which would like to drop it (none of the functions it exports need it). Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Acked-by: Damien Le Moal <dlemoal@kernel.org> Signed-off-by: Linux RISC-V bot <linux.riscv.bot@gmail.com>
The tegra as well as a few dwc PCI controller drivers uses PM runtime operations without including the required <linux/pm_runtime.h> header. Similarly, pcie-rockchip-host, pcie-starfive as well as a few dwc PCI controllers use the regulator consumer API without including <linux/regulator/consumer.h>. pcie-spacemit-k1.c uses of_get_next_available_child() and of_node_put() without including <linux/of.h>. It seems these function prototypes were indirectly provided by <linux/phy/phy.h>, mostly by mistake (none of the functions it exports need it). Before the PHY header can drop the unnecessary includes, make sure the PCI controller drivers include what they use. Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Acked-by: Bjorn Helgaas <bhelgaas@google.com> Signed-off-by: Linux RISC-V bot <linux.riscv.bot@gmail.com>
The chipidea ci_hdrc_imx driver uses regulator consumer API like regulator_enable() but does not include <linux/regulator/consumer.h>. The core USB HCD driver calls invalidate_kernel_vmap_range() and flush_kernel_vmap_range(), but does not include <linux/highmem.h>. The DWC3 gadget driver calls: - device_property_present() - device_property_count_u8() - device_property_read_u8_array() but does not include <linux/property.h> Similarly, dwc3-imx uses device_property_read_bool() without including <linux/property.h>. The dwc3-generic-plat driver uses of_device_get_match_data() but does not include <linux/of.h>. In all these cases, the necessary includes were still provided somehow, directly or indirectly, through <linux/phy/phy.h>. I found the following command to be quite helpful in figuring out the include chain: $ make KCFLAGS="-H" drivers/usb/dwc3/dwc3-imx.o Since <linux/phy/phy.h> wants to drop the unnecessary includes, fill in the required headers to avoid any breakage. Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Acked-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com> # dwc3 Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Linux RISC-V bot <linux.riscv.bot@gmail.com>
Multiple DRM bridge drivers use runtime PM operations without including the proper header, instead relying on transitive inclusion by <linux/phy/phy.h>. The PHY subsystem wants to get rid of headers it provides for no reason, so modify these drivers to include what they need directly. Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by: Linux RISC-V bot <linux.riscv.bot@gmail.com>
It appears that the phy-mapphone-mdm6600, phy-qcom-snps-femto-v2, phy-rcar-gen3-pcie, r8a779f0-ether-serdes and phy-rockchip-typec drivers call runtime PM operations without including the proper header. This was provided by <linux/phy/phy.h> but no function exported by this header directly needs it. So we need to drop it from there, and fix up drivers that used to depend on that. Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> # renesas Reviewed-by: André Draszik <andre.draszik@linaro.org> # google Signed-off-by: Linux RISC-V bot <linux.riscv.bot@gmail.com>
This driver relies on a transitive inclusion of the PHY API header through the USB headers. Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Reviewed-by: Yixun Lan <dlan@kernel.org> Signed-off-by: Linux RISC-V bot <linux.riscv.bot@gmail.com>
This file is calling of_property_read_u32() without including the proper header for it. It is provided by <linux/phy/phy.h>, which wants to get rid of it. Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Acked-by: Daniel Machon <daniel.machon@microchip.com> Signed-off-by: Linux RISC-V bot <linux.riscv.bot@gmail.com>
This is practically a full revert of commit 7a4db65 ("PCI: dra7xx: Create functional dependency between PCIe and PHY") and a partial revert of the device link pieces from commits dfb8053 ("PCI: cadence: Add generic PHY support to host and EP drivers") 4922923 ("PCI: keystone: Cleanup PHY handling") The trouble with these commits is that they dereference fields inside struct phy from a consumer driver, which will become no longer possible. Since commit 987351e ("phy: core: Add consumer device link support") from 2019, the PHY core also adds a device link to order PHY provider and consumer suspend/resume operations. All reverted commits are from 2017-2018, and what they do should actually be redundant now. Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Acked-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Manivannan Sadhasivam <mani@kernel.org> Signed-off-by: Linux RISC-V bot <linux.riscv.bot@gmail.com>
The Exynos host controller driver is clearly a PHY consumer (gets the ufs->phy using devm_phy_get()), but pokes into the guts of struct phy to get the generic_phy->power_count. The UFS core (specifically ufshcd_link_startup()) may call the variant operation exynos_ufs_pre_link() -> exynos_ufs_phy_init() multiple times if the link startup fails and needs to be retried. However ufs-exynos shouldn't be doing what it's doing, i.e. looking at the generic_phy->power_count, because in the general sense of the API, a single Generic PHY may have multiple consumers. If ufs-exynos looks at generic_phy->power_count, there's no guarantee that this ufs-exynos instance is the one who previously bumped that power count. So it may be powering down the PHY on behalf of another consumer. The correct way in which this should be handled is ufs-exynos should *remember* whether it has initialized and powered up the PHY before, and power it down during link retries. Not rely on the power_count (which, btw, on the writer side is modified under &phy->mutex, but on the reader side is accessed unlocked). This is a discouraged pattern even if here it doesn't cause functional problems. Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Reviewed-by: Bart Van Assche <bvanassche@acm.org> Acked-by: Alim Akhtar <alim.akhtar@samsung.com> Tested-by: Alim Akhtar <alim.akhtar@samsung.com> Reviewed-by: Martin K. Petersen <martin.petersen@oracle.com> Reviewed-by: Peter Griffin <peter.griffin@linaro.org> Signed-off-by: Linux RISC-V bot <linux.riscv.bot@gmail.com>
PHY consumer drivers should not look at the phy->power_count (a PHY
internal field), because in the general case there might also be other
consumers who have called phy_power_on() too, so the fact that the
power_count is non-zero does not mean that we did.
Moreover, struct phy will become opaque soon, so the qcom UFS driver
will not be able to apply this pattern anymore.
By all accounts, the need for ufs_qcom_power_up_sequence() to call
phy_power_off() prior to phy_init() denotes a skewed state of affairs.
(1) The Generic PHY API warns if phy_power_on() is called prior to
phy_init() - which ufs-qcom.c does, from ufs_qcom_setup_clocks().
The UFS controller driver hides its tracks by dropping the power
count prior to phy_init(), and that API violation goes undetected.
(2) phy_calibrate(), as implemented by the phy-qcom-qmp-ufs.c provider,
only works once after power on. Next time it will time out. And
since ufs_qcom_hce_enable_notify() -> ufs_qcom_power_up_sequence()
is called in a retry loop by the UFS core, the PHY power would
normally be on, hence the phy_power_off() call to ensure the
consistent state during phy_calibrate().
The above constitute improper Generic PHY API use, *but* fixing that
requires delicate surgery and I'm only here to stop this PHY consumer
from using fields it's not supposed to.
Once this discussion is settled, I will also address the above issues as
follow-ups:
https://lore.kernel.org/linux-phy/20260327112858.r5lpqygtvsane2vf@skbuf/
Until then, we can reimplement the logic in this driver in a
bug-compatible way, by keeping parallel track of just the UFS
controller's calls to phy_power_on() and phy_power_off().
Note that phy_power_off() shouldn't return an error in general and
doesn't return an error in the particular case of the phy-qcom-qmp-ufs.c
provider. So I've removed the one handling of phy_power_off() errors
from ufs_qcom_setup_clocks().
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Signed-off-by: Linux RISC-V bot <linux.riscv.bot@gmail.com>
This driver uses devm_request_irq() without including <linux/interrupt.h>
by itself, which would lead to build failures if the headers providing
this transitively were to stop providing it.
On aarch64, we can see, using KCFLAGS='-H' make drivers/ufs/host/ufs-qcom.o,
that the inclusion path is:
drivers/ufs/host/ufs-qcom.c
-> include/linux/acpi.h
-> arch/arm64/include/asm/acpi.h
-> include/linux/efi.h
-> include/linux/rtc.h
-> include/linux/interrupt.h
Whereas on armv7, the situation is quite different. This architecture
has no CONFIG_ACPI symbol, and therefore on it, <linux/acpi.h> does not
include <asm/acpi.h>, and <linux/interrupt.h> is not provided that way.
It is provided, however, through this "fallback" path:
drivers/ufs/host/ufs-qcom.c
-> include/linux/phy/phy.h
-> include/linux/regulator/consumer.h
-> include/linux/suspend.h
-> include/linux/swap.h
-> include/linux/memcontrol.h
-> include/linux/writeback.h
-> include/linux/interrupt.h
The point is that <linux/phy/phy.h> will stop providing
<linux/regulator/consumer.h>, and this would break the transitive
include chain on armv7.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Reviewed-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Linux RISC-V bot <linux.riscv.bot@gmail.com>
The dw_hdmi-rockchip driver validates pixel clock rates against the HDMI PHY's internal clock provider on certain SoCs like RK3328. This is currently achieved by dereferencing hdmi->phy->dev.of_node to obtain the provider node, which violates the Generic PHY API's encapsulation (the goal is for struct phy to be an opaque pointer with a hidden definition, to be interacted with only using API functions or NULL pointer checks, for the case where optional variants of phy_get() did not find a PHY). Refactor dw_hdmi_rockchip_bind() to perform a manual phandle lookup on the "hdmi" PHY index within the controller's DT node. This provides a parallel path to the clock provider's OF node without relying on the internal structure of the struct phy handle. Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Reviewed-by: Heiko Stueber <heiko@sntech.de> Signed-off-by: Linux RISC-V bot <linux.riscv.bot@gmail.com>
A piece of context which seems relevant here is that the USB subsystem is transitioning from struct usb_phy to struct phy (belonging to the Generic PHY subsystem). Commit 1a229d8 ("Revert "usb: phy: add usb phy notify port status API"") seems to confirm that this is the case. In the transition process, some PHY provider drivers register themselves as both Generic PHY and USB PHY in an attempt to bridge the API gap. Such is the case with drivers/phy/tegra/xusb.c, accessed here by the Tegra USB host driver. This USB host expects the PHY device behind the Generic PHY to also be a USB PHY, and calls devm_usb_get_phy_by_node(phy->dev.of_node). The Generic PHY exposes no API to get the OF node from a PHY device, so the Tegra USB host driver gets it directly. However, "struct phy" will be made an opaque pointer, to avoid misuse, so this will no longer be possible. Considering the fact that the Generic PHY/USB PHY duality is a transitional state, I am deliberately not planning to make the life of this driver any easier by providing a helper to get to the OF node somehow. Instead, implement a parallel lookup path through which the Tegra USB host driver can continue to get to the OF node provided by the padctl component, using the 'phys' phandle. Secondly (minor issue) the driver uses the phy->dev.of_node again to print using dev_dbg() that a "remote wake" was detected. Just print the index at which the PHY appears inside the driver's tegra->phys[] array instead. Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by: Linux RISC-V bot <linux.riscv.bot@gmail.com>
In a somewhat similar situation as the Tegra USB host controller driver, the Tegra XUDC driver for USB gadget mode needs to get to a struct usb_phy that sits behind the same OF node as the Generic PHY. It does that directly, which will no longer be possible. The PHY provider is also the xusb padctl driver. The rework here is also to implement a parallel OF node lookup path based on the "phys" phandle and the #phy-cells of the padctl provider. Some further notes: - create a local "usbphy" variable to hold the devm_usb_get_phy_by_node() output. This makes the error checks more obvious (avoids keeping an error-encoded pointer in xudc->usbphy[i] even temporarily). - the "if (IS_ERR(utmi_phy)) .. else if (utmi_phy) .. else if (!utmi_phy)" pattern can be simplified, considering that neither the IS_ERR() nor the NULL case continue execution in the current block. Therefore, we can move the case where the "utmi_phy" is a valid pointer outside the "if" checks, and this reduces the code indentation level. Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by: Linux RISC-V bot <linux.riscv.bot@gmail.com>
The major goal is to hide the contents of struct phy from consumer drivers. The idea with "phy-props.h" is that both consumers and providers make use of some data types. So both headers include "phy-props.h". Some slight points of contention. 1. phy_set_bus_width(): Vinod explains that despite the current caller situation (9 providers, 1 consumer), it is a consumer API function. The use case is that the controller (for example UFS) may have limitations and should set the expected lanes to be used and width on those lanes. A number of Generic PHYs can support multiple lanes and multiple width so this is way for controller telling I am using this configuration. 2. phy-provider.h should go to include/linux/phy/ or to drivers/phy/? We do have 3 PHY providers outside of drivers/phy/: drivers/media/platform/sunxi/sun8i-a83t-mipi-csi2/sun8i_a83t_dphy.c drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c drivers/pinctrl/tegra/pinctrl-tegra-xusb.c but the practice is not encouraged, and with time, these should be moved to the subsystem. This is not something that I can do now. 3. We can no longer tolerate static inline helpers. Allowing these would make it impossible to hide the struct phy definition from consumers. I've made phy_get_mode(), phy_get_bus_width(), phy_set_bus_width() exported symbols in drivers/phy/phy-core.c. 4. This is not a change without side effects. In the transition we are no longer providing <linux/pm_runtime.h> at all, and <linux/regulator/consumer.h> to PHY consumer drivers. However, the in-tree dependencies should all have been resolved. Also, the movement of phy-provider.h to drivers/phy/ is at least "interesting" for out of tree PHY provider drivers (this header is not deployed by make headers_install). However, it seems to be what Vinod is looking to see. For temporary compatibility, keep including the provider header. This will be removed when abuses are all gotten rid of. Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Signed-off-by: Linux RISC-V bot <linux.riscv.bot@gmail.com>
The PHY API has an optional "get" which returns NULL, so it needs to accept that NULL coming back in. Most PHY functions do this, only the formerly static inline attribute dereferences did not. Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by: Linux RISC-V bot <linux.riscv.bot@gmail.com>
Consumer drivers shouldn't dereference struct phy, not even to get to its attributes. We have phy_get_bus_width() as a precedent for getting the bus_width attribute, so let's add phy_get_max_link_rate() and use it in DRM and CAN drivers. In CAN drivers, the transceiver is acquired through devm_phy_optional_get() and NULL is given by the API as a non-error case, so the PHY API should also tolerate NULL coming back to it. This means we can further simplify the call sites that test for the NULL quality of the transceiver. Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Acked-by: Markus Schneider-Pargmann <msp@baylibre.com> # m_can Acked-by: Geert Uytterhoeven <geert+renesas@glider.be> # rcar_canfd Signed-off-by: Linux RISC-V bot <linux.riscv.bot@gmail.com>
The Rockchip DSI controller is a PHY consumer driver, which is also a PHY provider (calls devm_phy_create()) that lives out of drivers/phy/. According to Vinod, this is discouraged, although it would be difficult for me to address a proper movement here. Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by: Linux RISC-V bot <linux.riscv.bot@gmail.com>
The Cadence MHDP8546 DP bridge driver gets the PHY bus_width attribute (holding number of lanes) directly, but doing this will no longer be possible after the definition of struct phy is hidden from consumers. Use the phy_get_bus_width() API function designed specifically for consumers. Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by: Linux RISC-V bot <linux.riscv.bot@gmail.com>
The introduction commit 576d196 ("media: sunxi: Add support for the A83T MIPI CSI-2 controller") says: This implementation splits the protocol and D-PHY registers and uses the PHY framework internally. The D-PHY is not registered as a standalone PHY driver since it cannot be used with any other controller. However, this does not matter, and is not the only instance of tight PHY provider <-> consumer pairing. According to Vinod Koul, having PHY provider drivers outside of drivers/phy/ is discouraged, although it would be difficult for me to address a proper movement here. So just include the private provider API header from drivers/phy/ and leave a FIXME in place. Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Acked-by: Chen-Yu Tsai <wens@kernel.org> Signed-off-by: Linux RISC-V bot <linux.riscv.bot@gmail.com>
As a PHY consumer driver, the Renesas rswitch dereferences internal fields of struct phy, something which shouldn't be done, as that is going to be made an opaque pointer. It is quite clearly visible that the driver is tightly coupled with the drivers/phy/renesas/r8a779f0-ether-serdes.c, which puts heavy pressure on the Generic PHY subsystem. This was discussed before here: https://lore.kernel.org/linux-phy/20260211194541.cdmibrpfn6ej6e74@skbuf/ but to summarize, it is generally expected that when a Generic PHY function is called, it takes effect immediately. When this doesn't happen, the PHY provider driver must change its implementation rather than the consumer be made to work around it. PHY providers which rely on a hardcoded call sequence in the consumer are just lazy and wrong. The most obvious example is commit 5cb6309 ("net: renesas: rswitch: Add phy_power_{on,off}() calling"). Problem description: - Ethernet PHYs may change phydev->interface. When this happens, the SerDes must learn of the new phydev->interface using phy_set_mode_ext(). - drivers/phy/renesas/r8a779f0-ether-serdes.c implements phy_set_mode_ext(), but this only caches the mode and submode into channel->phy_interface and applies this to hardware during phy_power_on(). The commit author decided to work around this at the consumer site, by power cycling the PHY for the configuration to take effect. This had a worse implication from an API perspective in subsequent commit 053f13f ("rswitch: Fix imbalance phy_power_off() calling"). It was observed that phy_power_on() and phy_power_off() calls need to be balanced, and so, the consumer decided to start looking at the struct phy :: power_count (the technical reason why I'm making this change). This is also wrong from an API perspective because - a consumer should only care about its own vote on the PHY power state. If this is a multi-port submode like QSGMII, a single phy_power_off() call will not actually turn the PHY off (nor should it). - the power_count is written under the &phy->mutex, but read unlocked here. The rswitch and r8a779f0-ether-serdes drivers both need to be completely rethought in terms of Generic PHY API call sequence. There is no quick fix to apply. Just include the PHY provider API along with the consumer one, to keep working as before when struct phy will be made an opaque pointer to normal PHY consumers. But this is a bad offender (and it's not even a provider) so add a FIXME. Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Linux RISC-V bot <linux.riscv.bot@gmail.com>
The tegra-xusb pinctrl driver is also a PHY provider (calls devm_phy_create() for PCIe and SATA). However, according to Vinod Koul, having PHY provider drivers outside of drivers/phy/ is discouraged, although it would be difficult for me to address a proper movement here. Include the private provider API header from drivers/phy/, but leave a FIXME in place. It will have to be moved, eventually. Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Reviewed-by: Linus Walleij <linusw@kernel.org> Signed-off-by: Linux RISC-V bot <linux.riscv.bot@gmail.com>
This file uses dev_fwnode() without including the proper header for it,
relying on transitive header inclusion from:
drivers/power/supply/cpcap-charger.c
- include/linux/phy/omap_usb.h
- include/linux/usb/phy_companion.h
- include/linux/usb/otg.h
- include/linux/phy/phy.h
- drivers/phy/phy-provider.h
- include/linux/of.h
- include/linux/property.h
With the future removal of drivers/phy/phy-provider.h from
include/linux/phy/phy.h, this transitive inclusion would break.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Acked-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Signed-off-by: Linux RISC-V bot <linux.riscv.bot@gmail.com>
The majority of PHY drivers are PHY providers (obviously). Some are providers *and* consumers (phy-meson-axg-mipi-dphy, phy-meson-axg-pcie). These are the Amlogic AXG SoCs, which split the physical layer into two chained PHYs: the digital layer and the analog layer. The DSI or PCIe controller interacts only with the digital PHY, presumably for simplicity. The rest of PHY drivers which include <linux/phy/phy.h> do so because they call phy_set_bus_width(), a consumer function. Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Acked-by: Chen-Yu Tsai <wens@kernel.org> # allwinner Signed-off-by: Linux RISC-V bot <linux.riscv.bot@gmail.com>
The majority of PHY drivers are PHY providers (obviously). Some are chained PHY provider+consumer (phy-qcom-m31-eusb2.c, phy-exynos5-usbdrd.c). Others include <linux/phy/phy.h> because they call consumer functions such as phy_pm_runtime_get() - phy-mapphone-mdm6600.c. See commit 2ad2af0 ("phy: mapphone-mdm6600: Improve phy related runtime PM calls") for the story behind that. My understanding is it's a pragmatic shortcut, but it doesn't bother much. Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> #phy/qualcomm Acked-by: Shawn Lin <shawn.lin@rock-chips.com> Signed-off-by: Linux RISC-V bot <linux.riscv.bot@gmail.com>
Now that all consumers have been updated to no longer dereference fields inside struct phy, we can hide its definition altogether from public view. Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Signed-off-by: Linux RISC-V bot <linux.riscv.bot@gmail.com>
Some pragmatic shortcuts are being taken by PHY consumer driver authors, which put a burden on the framework. A lot of these can be caught during review. Make sure the linux-phy list is copied on as many keywords that regexes can reasonably catch. Some considerations that led to this solution and not a simpler one: - Consumers may be located anywhere, and their file naming provides no indication whatsoever that they are PHY API consumers. - The network PHY API has similarly sounding API: phy_start(), phy_connect(), etc. Similarly, matching on "phy" would hit phys_addr_t, "cryptography", etc. - The header files themselves need attention to avoid matching on include/linux/phy.h (network PHY), include/linux/usb/phy.h, drivers/net/vendor/device/phy.h, etc. - At least for a transitional period, I suppose developers will still try to add PHY providers outside the subsystem (which is discouraged). So I used \b to try to match on actual word boundaries and I went for listing all markers of PHY API use as they may appear in patch contexts. Bit rot is a valid concern. I will add a test to the build automation that newly introduced struct and function names in include/linux/phy.h, include/linux/phy-props.h and drivers/phy/phy-provider.h are matched by the MAINTAINERS entry K: patterns. The keyword patterns were written with great help from Joe Perches <joe@perches.com>. Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by: Linux RISC-V bot <linux.riscv.bot@gmail.com>
Author
|
Patch 1: "[v7,phy-next,01/27] ata: add <linux/pm_runtime.h> where missing" |
Author
|
Patch 1: "[v7,phy-next,01/27] ata: add <linux/pm_runtime.h> where missing" |
Author
|
Patch 25: "[v7,phy-next,25/27] phy: include PHY provider header (2/2)" |
Author
|
Patch 25: "[v7,phy-next,25/27] phy: include PHY provider header (2/2)" |
Author
|
Patch 25: "[v7,phy-next,25/27] phy: include PHY provider header (2/2)" |
Author
|
Patch 25: "[v7,phy-next,25/27] phy: include PHY provider header (2/2)" |
Author
|
Patch 26: "[v7,phy-next,26/27] phy: remove temporary provider compatibility from consumer header" |
Author
|
Patch 26: "[v7,phy-next,26/27] phy: remove temporary provider compatibility from consumer header" |
Author
|
Patch 26: "[v7,phy-next,26/27] phy: remove temporary provider compatibility from consumer header" |
Author
|
Patch 26: "[v7,phy-next,26/27] phy: remove temporary provider compatibility from consumer header" |
Author
|
Patch 26: "[v7,phy-next,26/27] phy: remove temporary provider compatibility from consumer header" |
Author
|
Patch 26: "[v7,phy-next,26/27] phy: remove temporary provider compatibility from consumer header" |
Author
|
Patch 26: "[v7,phy-next,26/27] phy: remove temporary provider compatibility from consumer header" |
Author
|
Patch 26: "[v7,phy-next,26/27] phy: remove temporary provider compatibility from consumer header" |
Author
|
Patch 26: "[v7,phy-next,26/27] phy: remove temporary provider compatibility from consumer header" |
Author
|
Patch 26: "[v7,phy-next,26/27] phy: remove temporary provider compatibility from consumer header" |
Author
|
Patch 26: "[v7,phy-next,26/27] phy: remove temporary provider compatibility from consumer header" |
Author
|
Patch 26: "[v7,phy-next,26/27] phy: remove temporary provider compatibility from consumer header" |
Author
|
Patch 27: "[v7,phy-next,27/27] MAINTAINERS: add regexes for linux-phy" |
Author
|
Patch 27: "[v7,phy-next,27/27] MAINTAINERS: add regexes for linux-phy" |
Author
|
Patch 27: "[v7,phy-next,27/27] MAINTAINERS: add regexes for linux-phy" |
Author
|
Patch 27: "[v7,phy-next,27/27] MAINTAINERS: add regexes for linux-phy" |
Author
|
Patch 27: "[v7,phy-next,27/27] MAINTAINERS: add regexes for linux-phy" |
Author
|
Patch 27: "[v7,phy-next,27/27] MAINTAINERS: add regexes for linux-phy" |
Author
|
Patch 27: "[v7,phy-next,27/27] MAINTAINERS: add regexes for linux-phy" |
Author
|
Patch 27: "[v7,phy-next,27/27] MAINTAINERS: add regexes for linux-phy" |
Author
|
Patch 27: "[v7,phy-next,27/27] MAINTAINERS: add regexes for linux-phy" |
Author
|
Patch 27: "[v7,phy-next,27/27] MAINTAINERS: add regexes for linux-phy" |
Author
|
Patch 27: "[v7,phy-next,27/27] MAINTAINERS: add regexes for linux-phy" |
Author
|
Patch 27: "[v7,phy-next,27/27] MAINTAINERS: add regexes for linux-phy" |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
PR for series 1088067 applied to workflow__riscv__fixes
Name: Split Generic PHY consumer and provider
URL: https://patchwork.kernel.org/project/linux-riscv/list/?series=1088067
Version: 7