[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20171130.122917.542712364953497229.davem@davemloft.net>
Date: Thu, 30 Nov 2017 12:29:17 -0500 (EST)
From: David Miller <davem@...emloft.net>
To: jassisinghbrar@...il.com
Cc: netdev@...r.kernel.org, devicetree@...r.kernel.org,
arnd.bergmann@...aro.org, ard.biesheuvel@...aro.org,
robh+dt@...nel.org, mark.rutland@....com,
jaswinder.singh@...aro.org
Subject: Re: [PATCH 2/3] net: socionext: Add Synquacer NetSec driver
From: jassisinghbrar@...il.com
Date: Thu, 30 Nov 2017 21:43:16 +0530
> + priv->eeprom_base = devm_memremap(&pdev->dev, eeprom_res->start,
> + resource_size(eeprom_res),
> + MEMREMAP_WT);
> + if (!priv->eeprom_base) {
> + dev_err(&pdev->dev, "devm_memremap() failed for EEPROM\n");
> + ret = -ENXIO;
> + goto free_ndev;
> + }
dev_memremap() is implemented via memremap() which for MEMREMAP_WT is
in turn implemented using ioremap_wt() which returns an "__iomem"
pointer.
The memremap() function talks about __iomem being about side effects.
That's not really the full story. The __iomem annotation is also
about whether a special accessor is necessary to "dereference" the
pointer. On sparc64, for example, the ioremap_*() functions return a
physical address not a virtual one. So you cannot directly
dereference pointers that are returned from the ioremap*() interfaces.
You'll also need to mark priv->eeprom_base as "__iomem".
devm_memremap() returns a straight "void *" without the __iomem
annotation, and this is wrong then ioremap_*() is used.
Powered by blists - more mailing lists