netdev - Re: [RFC 10/11] net: example acpize xgmac

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20200523184835.GB1551@shell.armlinux.org.uk>
Date:   Sat, 23 May 2020 19:48:35 +0100
From:   Russell King - ARM Linux admin <linux@...linux.org.uk>
To:     Jeremy Linton <jeremy.linton@....com>
Cc:     netdev@...r.kernel.org, davem@...emloft.net, andrew@...n.ch,
        f.fainelli@...il.com, hkallweit1@...il.com,
        madalin.bucur@....nxp.com, calvin.johnson@....nxp.com,
        linux-kernel@...r.kernel.org
Subject: Re: [RFC 10/11] net: example acpize xgmac_mdio

On Fri, May 22, 2020 at 04:30:58PM -0500, Jeremy Linton wrote:
> Signed-off-by: Jeremy Linton <jeremy.linton@....com>
> ---
>  drivers/net/ethernet/freescale/xgmac_mdio.c | 27 +++++++++++++--------
>  1 file changed, 17 insertions(+), 10 deletions(-)
> 
> diff --git a/drivers/net/ethernet/freescale/xgmac_mdio.c b/drivers/net/ethernet/freescale/xgmac_mdio.c
> index c82c85ef5fb3..96ee3bd89983 100644
> --- a/drivers/net/ethernet/freescale/xgmac_mdio.c
> +++ b/drivers/net/ethernet/freescale/xgmac_mdio.c
> @@ -245,14 +245,14 @@ static int xgmac_mdio_probe(struct platform_device *pdev)
>  {
>  	struct device_node *np = pdev->dev.of_node;
>  	struct mii_bus *bus;
> -	struct resource res;
> +	struct resource *res;
>  	struct mdio_fsl_priv *priv;
>  	int ret;
>  
> -	ret = of_address_to_resource(np, 0, &res);
> -	if (ret) {
> +	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> +	if (!res) {
>  		dev_err(&pdev->dev, "could not obtain address\n");
> -		return ret;
> +		return -EINVAL;
>  	}
>  
>  	bus = mdiobus_alloc_size(sizeof(struct mdio_fsl_priv));
> @@ -263,21 +263,21 @@ static int xgmac_mdio_probe(struct platform_device *pdev)
>  	bus->read = xgmac_mdio_read;
>  	bus->write = xgmac_mdio_write;
>  	bus->parent = &pdev->dev;
> -	snprintf(bus->id, MII_BUS_ID_SIZE, "%llx", (unsigned long long)res.start);
> +	snprintf(bus->id, MII_BUS_ID_SIZE, "%llx", (unsigned long long)res->start);
>  
>  	/* Set the PHY base address */
>  	priv = bus->priv;
> -	priv->mdio_base = of_iomap(np, 0);
> +	priv->mdio_base = devm_platform_ioremap_resource(pdev, 0);
>  	if (!priv->mdio_base) {

I think you need to pay greater attention to the return value of
functions - this is one such case, where
devm_platform_ioremap_resource() does not return NULL on failure.
It uses devm_ioremap_resource(), which is documented in lib/devres.c
to return an error-pointer on failure.

>  		ret = -ENOMEM;
>  		goto err_ioremap;
>  	}
>  
> -	priv->is_little_endian = of_property_read_bool(pdev->dev.of_node,
> -						       "little-endian");
> +	priv->is_little_endian = device_property_read_bool(&pdev->dev,
> +							   "little-endian");
>  
> -	priv->has_a011043 = of_property_read_bool(pdev->dev.of_node,
> -						  "fsl,erratum-a011043");
> +	priv->has_a011043 = device_property_read_bool(&pdev->dev,
> +						      "fsl,erratum-a011043");
>  
>  	ret = of_mdiobus_register(bus, np);
>  	if (ret) {
> @@ -320,10 +320,17 @@ static const struct of_device_id xgmac_mdio_match[] = {
>  };
>  MODULE_DEVICE_TABLE(of, xgmac_mdio_match);
>  
> +static const struct acpi_device_id xgmac_acpi_match[] = {
> +	{ "NXP0006", (kernel_ulong_t)NULL },
> +	{ },
> +};
> +MODULE_DEVICE_TABLE(acpi, xgmac_acpi_match);
> +
>  static struct platform_driver xgmac_mdio_driver = {
>  	.driver = {
>  		.name = "fsl-fman_xmdio",
>  		.of_match_table = xgmac_mdio_match,
> +		.acpi_match_table = xgmac_acpi_match,
>  	},
>  	.probe = xgmac_mdio_probe,
>  	.remove = xgmac_mdio_remove,
> -- 
> 2.26.2
> 
> 

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC for 0.8m (est. 1762m) line in suburbia: sync at 13.1Mbps down 424kbps up