On Wed, 2015-01-28 at 17:18 +0100, Arnd Bergmann wrote:
> The qcom ufs phy support is split into three separate loadable
> modules, however none of the interfaces are exported, resulting
> in a link error:
>
> ERROR: "ufs_qcom_phy_power_off" [drivers/phy/phy-qcom-ufs-qmp-20nm.ko] undefined!
> ERROR: "ufs_qcom_phy_power_on" [drivers/phy/phy-qcom-ufs-qmp-20nm.ko] undefined!
> ERROR: "ufs_qcom_phy_exit" [drivers/phy/phy-qcom-ufs-qmp-20nm.ko] undefined!
> ERROR: "ufs_qcom_phy_generic_probe" [drivers/phy/phy-qcom-ufs-qmp-20nm.ko] undefined!
> ERROR: "ufs_qcom_phy_init_vregulators" [drivers/phy/phy-qcom-ufs-qmp-20nm.ko] undefined!
> ERROR: "ufs_qcom_phy_init_clks" [drivers/phy/phy-qcom-ufs-qmp-20nm.ko] undefined!
> ERROR: "ufs_qcom_phy_calibrate" [drivers/phy/phy-qcom-ufs-qmp-20nm.ko] undefined!
> ERROR: "ufs_qcom_phy_remove" [drivers/phy/phy-qcom-ufs-qmp-20nm.ko] undefined!
> ERROR: "get_ufs_qcom_phy" [drivers/phy/phy-qcom-ufs-qmp-20nm.ko] undefined!
> ERROR: "ufs_qcom_phy_power_off" [drivers/phy/phy-qcom-ufs-qmp-14nm.ko] undefined!
> ERROR: "ufs_qcom_phy_power_on" [drivers/phy/phy-qcom-ufs-qmp-14nm.ko] undefined!
> ERROR: "ufs_qcom_phy_exit" [drivers/phy/phy-qcom-ufs-qmp-14nm.ko] undefined!
> ERROR: "ufs_qcom_phy_generic_probe" [drivers/phy/phy-qcom-ufs-qmp-14nm.ko] undefined!
> ERROR: "ufs_qcom_phy_init_vregulators" [drivers/phy/phy-qcom-ufs-qmp-14nm.ko] undefined!
> ERROR: "ufs_qcom_phy_init_clks" [drivers/phy/phy-qcom-ufs-qmp-14nm.ko] undefined!
> ERROR: "ufs_qcom_phy_calibrate" [drivers/phy/phy-qcom-ufs-qmp-14nm.ko] undefined!
> ERROR: "ufs_qcom_phy_remove" [drivers/phy/phy-qcom-ufs-qmp-14nm.ko] undefined!
> ERROR: "get_ufs_qcom_phy" [drivers/phy/phy-qcom-ufs-qmp-14nm.ko] undefined!
>
> This exports all of the symbols that are provided by the base library
> module and used by the two driver modules.
>
> Signed-off-by: Arnd Bergmann <[email protected]>
> Fixes: adaafaa393ef ("phy: qcom-ufs: add support for QUALCOMM Technologies UFS PHY drivers")
> ---
Cc added for linux-scsi, since this is the origin of the problem. How
important is bisectability in this? It won't affect any non-embedded
user, since most don't build with UFS, so I can go either way on folding
or just applying as an extra patch.
James
> The broken patch is currently in the scsi tree, so if the phy maintainer
> thinks that my fix is correct, it should go there too.
>
> An alternative approach would be to link all three phy-qcom-ufs source
> files into a single module.
>
> drivers/phy/phy-qcom-ufs.c | 21 +++++++++++++++++++++
> 1 file changed, 21 insertions(+)
>
> diff --git a/drivers/phy/phy-qcom-ufs.c b/drivers/phy/phy-qcom-ufs.c
> index 44ee983d57fe..c8f8c2dac18c 100644
> --- a/drivers/phy/phy-qcom-ufs.c
> +++ b/drivers/phy/phy-qcom-ufs.c
> @@ -73,6 +73,7 @@ int ufs_qcom_phy_calibrate(struct ufs_qcom_phy *ufs_qcom_phy,
> out:
> return ret;
> }
> +EXPORT_SYMBOL_GPL(ufs_qcom_phy_calibrate);
>
> struct phy *ufs_qcom_phy_generic_probe(struct platform_device *pdev,
> struct ufs_qcom_phy *common_cfg,
> @@ -110,6 +111,7 @@ struct phy *ufs_qcom_phy_generic_probe(struct platform_device *pdev,
> out:
> return generic_phy;
> }
> +EXPORT_SYMBOL_GPL(ufs_qcom_phy_generic_probe);
>
> /*
> * This assumes the embedded phy structure inside generic_phy is of type
> @@ -121,6 +123,7 @@ struct ufs_qcom_phy *get_ufs_qcom_phy(struct phy *generic_phy)
> {
> return (struct ufs_qcom_phy *)phy_get_drvdata(generic_phy);
> }
> +EXPORT_SYMBOL_GPL(get_ufs_qcom_phy);
>
> static
> int ufs_qcom_phy_base_init(struct platform_device *pdev,
> @@ -228,6 +231,7 @@ ufs_qcom_phy_init_clks(struct phy *generic_phy,
> out:
> return err;
> }
> +EXPORT_SYMBOL_GPL(ufs_qcom_phy_init_clks);
>
> int
> ufs_qcom_phy_init_vregulators(struct phy *generic_phy,
> @@ -252,6 +256,7 @@ ufs_qcom_phy_init_vregulators(struct phy *generic_phy,
> out:
> return err;
> }
> +EXPORT_SYMBOL_GPL(ufs_qcom_phy_init_vregulators);
>
> static int __ufs_qcom_phy_init_vreg(struct phy *phy,
> struct ufs_qcom_phy_vreg *vreg, const char *name, bool optional)
> @@ -443,6 +448,7 @@ out_disable_src:
> out:
> return ret;
> }
> +EXPORT_SYMBOL_GPL(ufs_qcom_phy_enable_ref_clk);
>
> static
> int ufs_qcom_phy_disable_vreg(struct phy *phy,
> @@ -485,6 +491,7 @@ void ufs_qcom_phy_disable_ref_clk(struct phy *generic_phy)
> phy->is_ref_clk_enabled = false;
> }
> }
> +EXPORT_SYMBOL_GPL(ufs_qcom_phy_disable_ref_clk);
>
> #define UFS_REF_CLK_EN (1 << 5)
>
> @@ -523,16 +530,19 @@ static void ufs_qcom_phy_dev_ref_clk_ctrl(struct phy *generic_phy, bool enable)
> phy->is_dev_ref_clk_enabled = enable;
> }
> }
> +EXPORT_SYMBOL_GPL(ufs_qcom_phy_dev_ref_clk_ctrl);
>
> void ufs_qcom_phy_enable_dev_ref_clk(struct phy *generic_phy)
> {
> ufs_qcom_phy_dev_ref_clk_ctrl(generic_phy, true);
> }
> +EXPORT_SYMBOL_GPL(ufs_qcom_phy_enable_dev_ref_clk);
>
> void ufs_qcom_phy_disable_dev_ref_clk(struct phy *generic_phy)
> {
> ufs_qcom_phy_dev_ref_clk_ctrl(generic_phy, false);
> }
> +EXPORT_SYMBOL_GPL(ufs_qcom_phy_disable_dev_ref_clk);
>
> /* Turn ON M-PHY RMMI interface clocks */
> int ufs_qcom_phy_enable_iface_clk(struct phy *generic_phy)
> @@ -561,6 +571,7 @@ int ufs_qcom_phy_enable_iface_clk(struct phy *generic_phy)
> out:
> return ret;
> }
> +EXPORT_SYMBOL_GPL(ufs_qcom_phy_enable_iface_clk);
>
> /* Turn OFF M-PHY RMMI interface clocks */
> void ufs_qcom_phy_disable_iface_clk(struct phy *generic_phy)
> @@ -573,6 +584,7 @@ void ufs_qcom_phy_disable_iface_clk(struct phy *generic_phy)
> phy->is_iface_clk_enabled = false;
> }
> }
> +EXPORT_SYMBOL_GPL(ufs_qcom_phy_disable_iface_clk);
>
> int ufs_qcom_phy_start_serdes(struct phy *generic_phy)
> {
> @@ -589,6 +601,7 @@ int ufs_qcom_phy_start_serdes(struct phy *generic_phy)
>
> return ret;
> }
> +EXPORT_SYMBOL_GPL(ufs_qcom_phy_start_serdes);
>
> int ufs_qcom_phy_set_tx_lane_enable(struct phy *generic_phy, u32 tx_lanes)
> {
> @@ -606,6 +619,7 @@ int ufs_qcom_phy_set_tx_lane_enable(struct phy *generic_phy, u32 tx_lanes)
>
> return ret;
> }
> +EXPORT_SYMBOL_GPL(ufs_qcom_phy_set_tx_lane_enable);
>
> void ufs_qcom_phy_save_controller_version(struct phy *generic_phy,
> u8 major, u16 minor, u16 step)
> @@ -616,6 +630,7 @@ void ufs_qcom_phy_save_controller_version(struct phy *generic_phy,
> ufs_qcom_phy->host_ctrl_rev_minor = minor;
> ufs_qcom_phy->host_ctrl_rev_step = step;
> }
> +EXPORT_SYMBOL_GPL(ufs_qcom_phy_save_controller_version);
>
> int ufs_qcom_phy_calibrate_phy(struct phy *generic_phy, bool is_rate_B)
> {
> @@ -636,6 +651,7 @@ int ufs_qcom_phy_calibrate_phy(struct phy *generic_phy, bool is_rate_B)
>
> return ret;
> }
> +EXPORT_SYMBOL_GPL(ufs_qcom_phy_calibrate_phy);
>
> int ufs_qcom_phy_remove(struct phy *generic_phy,
> struct ufs_qcom_phy *ufs_qcom_phy)
> @@ -647,6 +663,7 @@ int ufs_qcom_phy_remove(struct phy *generic_phy,
>
> return 0;
> }
> +EXPORT_SYMBOL_GPL(ufs_qcom_phy_remove);
>
> int ufs_qcom_phy_exit(struct phy *generic_phy)
> {
> @@ -657,6 +674,7 @@ int ufs_qcom_phy_exit(struct phy *generic_phy)
>
> return 0;
> }
> +EXPORT_SYMBOL_GPL(ufs_qcom_phy_exit);
>
> int ufs_qcom_phy_is_pcs_ready(struct phy *generic_phy)
> {
> @@ -671,6 +689,7 @@ int ufs_qcom_phy_is_pcs_ready(struct phy *generic_phy)
> return ufs_qcom_phy->phy_spec_ops->
> is_physical_coding_sublayer_ready(ufs_qcom_phy);
> }
> +EXPORT_SYMBOL_GPL(ufs_qcom_phy_is_pcs_ready);
>
> int ufs_qcom_phy_power_on(struct phy *generic_phy)
> {
> @@ -725,6 +744,7 @@ out_disable_phy:
> out:
> return err;
> }
> +EXPORT_SYMBOL_GPL(ufs_qcom_phy_power_on);
>
> int ufs_qcom_phy_power_off(struct phy *generic_phy)
> {
> @@ -743,3 +763,4 @@ int ufs_qcom_phy_power_off(struct phy *generic_phy)
>
> return 0;
> }
> +EXPORT_SYMBOL_GPL(ufs_qcom_phy_power_off);
>
????{.n?+???????+%?????ݶ??w??{.n?+????{??G?????{ay? ʇڙ?,j??f???h?????????z_??(?階?ݢj"???m??????G????????????&???~???iO???z??v?^?m???? ????????I?
On Mon, Feb 02, 2015 at 03:30:27PM +0000, James Bottomley wrote:
> Cc added for linux-scsi, since this is the origin of the problem. How
> important is bisectability in this? It won't affect any non-embedded
> user, since most don't build with UFS, so I can go either way on folding
> or just applying as an extra patch.
The CRYPTO_DEV_QCOM_ICE symbol was never defined in the scsi trees, and
would have needed something else from linux-next to even compile. So I
don't think the revert is a problem at all, and I'll add it to the
scsi-for-3.20 branch ASAP.
On Mon, 2015-02-02 at 17:26 +0100, [email protected] wrote:
> On Mon, Feb 02, 2015 at 03:30:27PM +0000, James Bottomley wrote:
> > Cc added for linux-scsi, since this is the origin of the problem. How
> > important is bisectability in this? It won't affect any non-embedded
> > user, since most don't build with UFS, so I can go either way on folding
> > or just applying as an extra patch.
>
> The CRYPTO_DEV_QCOM_ICE symbol was never defined in the scsi trees, and
> would have needed something else from linux-next to even compile. So I
> don't think the revert is a problem at all, and I'll add it to the
> scsi-for-3.20 branch ASAP.
Actually, on the revert of
scsi: ufs-qcom-ice: add Inline Crypto Engine (ICE) support for UFS
Which isn't what this problem is (the exports still need adding), since
it's only in the misc tree, let's just drop the patches rather than
doing an add and revert.
James
????{.n?+???????+%?????ݶ??w??{.n?+????{??G?????{ay? ʇڙ?,j??f???h?????????z_??(?階?ݢj"???m??????G????????????&???~???iO???z??v?^?m???? ????????I?