Currently a syscon entity can be only registered directly through a
platform device that binds to a dedicated syscon driver. However in
certain use cases it is desirable to make a device used with another
driver a syscon interface provider.
For example, certain SoCs (e.g. Exynos) contain system controller
blocks which perform various functions such as power domain control,
CPU power management, low power mode control, but in addition contain
certain IP integration glue, such as various signal masks,
coprocessor power control, etc. In such case, there is a need to have
a dedicated driver for such system controller but also share registers
with other drivers. The latter is where the syscon interface is helpful.
In case of DT based platforms, this patch decouples syscon object from
syscon platform driver, and allows to create syscon objects first time
when it is required by calling of syscon_regmap_lookup_by APIs and keep
a list of such syscon objects along with syscon provider device_nodes
and regmap handles.
For non-DT based platforms, this patch keeps syscon platform driver
structure where is can be probed and such non-DT based drivers can use
syscon_regmap_lookup_by_pdev API and get access to regmap handles.
Once all users of "syscon_regmap_lookup_by_pdev" migrated to DT based,
we can completly remove platform driver of syscon, and keep only helper
functions to get regmap handles.
Suggested-by: Arnd Bergmann <arnd@arndb.de>
Suggested-by: Tomasz Figa <redacted>
Tested-by: Vivek Gautam <redacted>
Signed-off-by: Pankaj Dubey <redacted>
---
V2 of this patchset and related discussion can be found here [1].
Changes since v2:
- Added back platform device support from syscon, with one change that
syscon will not be probed for DT based platform.
- Added back syscon_regmap_lookup_by_pdevname API so that non-DT base
users of syscon will not be broken.
- Removed unwanted change in syscon.h.
- Modified Signed-off-by list, added Suggested-by of Tomasz Figa and
Arnd Bergmann.
- Added Tested-by of Vivek Gautam for testing on Exynos platform.
Changes since v1:
- Removed of_syscon_unregister function.
- Modified of_syscon_register function and it will be used by syscon.c
to create syscon objects whenever required.
- Removed platform device support from syscon.
- Removed syscon_regmap_lookup_by_pdevname API support.
- As there are significant changes w.r.t patchset v1, I am taking over
author for this patchset from Tomasz Figa.
[1]: https://lkml.org/lkml/2014/9/2/299
drivers/mfd/syscon.c | 78 ++++++++++++++++++++++++++++++++++++--------------
1 file changed, 57 insertions(+), 21 deletions(-)
On Wed, Sep 17, 2014 at 12:01:50PM +0530, Pankaj Dubey wrote:
quoted hunk
Currently a syscon entity can be only registered directly through a
platform device that binds to a dedicated syscon driver. However in
certain use cases it is desirable to make a device used with another
driver a syscon interface provider.
For example, certain SoCs (e.g. Exynos) contain system controller
blocks which perform various functions such as power domain control,
CPU power management, low power mode control, but in addition contain
certain IP integration glue, such as various signal masks,
coprocessor power control, etc. In such case, there is a need to have
a dedicated driver for such system controller but also share registers
with other drivers. The latter is where the syscon interface is helpful.
In case of DT based platforms, this patch decouples syscon object from
syscon platform driver, and allows to create syscon objects first time
when it is required by calling of syscon_regmap_lookup_by APIs and keep
a list of such syscon objects along with syscon provider device_nodes
and regmap handles.
For non-DT based platforms, this patch keeps syscon platform driver
structure where is can be probed and such non-DT based drivers can use
syscon_regmap_lookup_by_pdev API and get access to regmap handles.
Once all users of "syscon_regmap_lookup_by_pdev" migrated to DT based,
we can completly remove platform driver of syscon, and keep only helper
functions to get regmap handles.
Suggested-by: Arnd Bergmann <arnd@arndb.de>
Suggested-by: Tomasz Figa <redacted>
Tested-by: Vivek Gautam <redacted>
Signed-off-by: Pankaj Dubey <redacted>
---
V2 of this patchset and related discussion can be found here [1].
Changes since v2:
- Added back platform device support from syscon, with one change that
syscon will not be probed for DT based platform.
- Added back syscon_regmap_lookup_by_pdevname API so that non-DT base
users of syscon will not be broken.
- Removed unwanted change in syscon.h.
- Modified Signed-off-by list, added Suggested-by of Tomasz Figa and
Arnd Bergmann.
- Added Tested-by of Vivek Gautam for testing on Exynos platform.
Changes since v1:
- Removed of_syscon_unregister function.
- Modified of_syscon_register function and it will be used by syscon.c
to create syscon objects whenever required.
- Removed platform device support from syscon.
- Removed syscon_regmap_lookup_by_pdevname API support.
- As there are significant changes w.r.t patchset v1, I am taking over
author for this patchset from Tomasz Figa.
[1]: https://lkml.org/lkml/2014/9/2/299
drivers/mfd/syscon.c | 78 ++++++++++++++++++++++++++++++++++++--------------
1 file changed, 57 insertions(+), 21 deletions(-)
--
1.7.9.5
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel at lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Yes, it is safe, at least we are able to test on Exynos based SoC.
I have tested it with kgene/for-next kernel on Exynos3250.
Also it has been tested on Exynos5250 based Snow board with 3.17-rc5 based
kernel
by Vivek Gautam.
Patch V2 also has been tested by "Borris Brezillon" on AT91 platform.
I just tested on MX6SX SDB board and it seemed crashed at here in
regmap_init
function.
Can you please provide crash log which can give more information about the
crash?
Thanks,
Pankaj Dubey
On Wednesday 17 September 2014, Pankaj Dubey wrote:
---
V2 of this patchset and related discussion can be found here [1].
Changes since v2:
- Added back platform device support from syscon, with one change that
syscon will not be probed for DT based platform.
- Added back syscon_regmap_lookup_by_pdevname API so that non-DT base
users of syscon will not be broken.
- Removed unwanted change in syscon.h.
- Modified Signed-off-by list, added Suggested-by of Tomasz Figa and
Arnd Bergmann.
- Added Tested-by of Vivek Gautam for testing on Exynos platform.
Looks fine. Provided you can figure out the problem that Dong Aisheng
reported, please add my
Acked-by: Arnd Bergmann <arnd@arndb.de>
One minor comment: please avoid doing forward declarations of
local functions. It took me a while to understand what is going on
because I expect all functions to be ordered such that they only get
called by functions below, and don't need this.
Just move of_syscon_register() here directly.
Arnd
+CC: Dong Aisheng
Hi Arnd,
On Wednesday, September 17, 2014, Arnd Bergmann wrote,
quoted
V2 of this patchset and related discussion can be found here [1].
Changes since v2:
- Added back platform device support from syscon, with one change that
syscon will not be probed for DT based platform.
- Added back syscon_regmap_lookup_by_pdevname API so that non-DT base
users of syscon will not be broken.
- Removed unwanted change in syscon.h.
- Modified Signed-off-by list, added Suggested-by of Tomasz Figa and
Arnd Bergmann.
- Added Tested-by of Vivek Gautam for testing on Exynos platform.
Looks fine. Provided you can figure out the problem that Dong Aisheng
reported,
please add my
Acked-by: Arnd Bergmann <arnd@arndb.de>
Thanks.
After he reported I have again done code walk-through of regmap_init_mmio
and
could not see any such fatal error. At the same time I have replied to Dong
Aisheng,
asking for more details and waiting for his reply.
Yes, it is safe, at least we are able to test on Exynos based SoC.
I have tested it with kgene/for-next kernel on Exynos3250.
Also it has been tested on Exynos5250 based Snow board with 3.17-rc5 based
kernel
by Vivek Gautam.
Patch V2 also has been tested by "Borris Brezillon" on AT91 platform.
The kernel i tested was next-20140915 of linux-next.
please see regmap_get_val_endian called in regmap_init function.
static enum regmap_endian regmap_get_val_endian(struct device *dev,
const struct regmap_bus *bus,
const struct regmap_config *config)
{
struct device_node *np = dev->of_node;
enum regmap_endian endian;
...
}
It will crash at the first line of dev->of_node if dev is NULL.
Can you check if you're using the same code as mine?
quoted
I just tested on MX6SX SDB board and it seemed crashed at here in
regmap_init
quoted
function.
Can you please provide crash log which can give more information about the
crash?
On Thu, Sep 18, 2014 at 08:59:32AM +0530, Pankaj Dubey wrote:
+CC: Dong Aisheng
Hi Arnd,
On Wednesday, September 17, 2014, Arnd Bergmann wrote,
quoted
quoted
V2 of this patchset and related discussion can be found here [1].
Changes since v2:
- Added back platform device support from syscon, with one change that
syscon will not be probed for DT based platform.
- Added back syscon_regmap_lookup_by_pdevname API so that non-DT base
users of syscon will not be broken.
- Removed unwanted change in syscon.h.
- Modified Signed-off-by list, added Suggested-by of Tomasz Figa and
Arnd Bergmann.
- Added Tested-by of Vivek Gautam for testing on Exynos platform.
Looks fine. Provided you can figure out the problem that Dong Aisheng
reported,
quoted
please add my
Acked-by: Arnd Bergmann <arnd@arndb.de>
Thanks.
After he reported I have again done code walk-through of regmap_init_mmio
and
could not see any such fatal error. At the same time I have replied to Dong
Aisheng,
asking for more details and waiting for his reply.
I just replied and gave the log.
Regards
Dong Aisheng
Hi,
Adding CC to Xiubo Li, Geert Uytterhoeven and Stephen Warren.
On Thursday, September 18, 2014, Dong Aisheng wrote,
On Wed, Sep 17, 2014 at 04:50:50PM +0530, Pankaj Dubey wrote:
quoted
Hi,
On Wednesday, September 17, 2014, Dong Aisheng Wrote,
quoted
quoted
+ regmap = regmap_init_mmio(NULL, base,
&syscon_regmap_config);
quoted
quoted
Does a NULL device pointer work?
Yes, it is safe, at least we are able to test on Exynos based SoC.
I have tested it with kgene/for-next kernel on Exynos3250.
Also it has been tested on Exynos5250 based Snow board with 3.17-rc5
based kernel by Vivek Gautam.
Patch V2 also has been tested by "Borris Brezillon" on AT91 platform.
The kernel i tested was next-20140915 of linux-next.
please see regmap_get_val_endian called in regmap_init function.
static enum regmap_endian regmap_get_val_endian(struct device *dev,
const struct regmap_bus *bus,
const struct regmap_config
*config) {
struct device_node *np = dev->of_node;
enum regmap_endian endian;
...
}
It will crash at the first line of dev->of_node if dev is NULL.
Can you check if you're using the same code as mine?
No, it's not same.
My bad that I was not using linux-next for testing this patch.
We tested on kgene/for-next where these changes still have not come.
Just now I checked linux-next and found that it will crash at first line of
"regmap_get_val_endian" as there is no check for NULL on dev.
I checked git history of regmap.c file and found recently this file has been
modified
for adding DT endianness binding support. Following are set of patches gone
for this
cf673fb regmap: Split regmap_get_endian() in two functions
5844a8b regmap: Fix handling of volatile registers for format_write() chips
45e1a27 regmap: of_regmap_get_endian() cleanup
ba1b53f regmap: Fix DT endianess parsing logic
d647c19 regmap: add DT endianness binding support.
I think there should have been a check for NULL on "dev" in
"regmap_get_val_endian", so that if dev pointer exist then only it makes
sense to get
endianness property from DT.
I will suggest following fix in regmap.c for this. With following fix I
tested it and it works well
on linux-next also. So if you can confirm following fix is working for you
then I can post this
patch.
--------------------------------------------
Subject: [PATCH] regmap: fix NULL pointer dereference in
regmap_get_val_endian
Recent commits for getting reg endianess causing NULL pointer
dereference if dev is passed NULL in regmap_init_mmio. This patch
fixes this issue, and allows to parse reg endianess only if dev
and dev->of_node exist.
Signed-off-by: Pankaj Dubey <redacted>
---
drivers/base/regmap/regmap.c | 23 ++++++++++++++---------
1 file changed, 14 insertions(+), 9 deletions(-)
device *dev,
if (endian != REGMAP_ENDIAN_DEFAULT)
return endian;
- /* Parse the device's DT node for an endianness specification */
- if (of_property_read_bool(np, "big-endian"))
- endian = REGMAP_ENDIAN_BIG;
- else if (of_property_read_bool(np, "little-endian"))
- endian = REGMAP_ENDIAN_LITTLE;
+ /* If the dev and dev->of_node exist try to get endianness from DT
*/
+ if (dev && dev->of_node) {
+ np = dev->of_node;
- /* If the endianness was specified in DT, use that */
- if (endian != REGMAP_ENDIAN_DEFAULT)
- return endian;
+ /* Parse the device's DT node for an endianness
specification */
+ if (of_property_read_bool(np, "big-endian"))
+ endian = REGMAP_ENDIAN_BIG;
+ else if (of_property_read_bool(np, "little-endian"))
+ endian = REGMAP_ENDIAN_LITTLE;
+
+ /* If the endianness was specified in DT, use that */
+ if (endian != REGMAP_ENDIAN_DEFAULT)
+ return endian;
+ }
/* Retrieve the endianness specification from the bus config */
if (bus && bus->val_format_endian_default)
--
Thanks,
Pankaj Dubey
Hi Pankaj,
One more question:
For example:
regmap_read()
----> _regmap_read()
----> 2112 #ifdef LOG_DEVICE
----> 2113 if (strcmp(dev_name(map->dev), LOG_DEVICE) == 0)
----> 2114 dev_info(map->dev, "%x => %x\n", reg, *val);
----> 2115 #endif
In dev_name(map->dev) will also encounter the same crash core trace like in
regmap_get_val_endian(dev, ...).
Could there be another method, such as using 'dummy dev' instead of 'NULL dev' ?
Just one suggestion.
BRs
Xiubo
quoted hunk
-----Original Message-----
From: Pankaj Dubey [mailto:pankaj.dubey at samsung.com]
Sent: Thursday, September 18, 2014 2:03 PM
To: Dong Aisheng-B29396
Cc: linux-arm-kernel at lists.infradead.org; linux-samsung-soc at vger.kernel.org;
linux-kernel at vger.kernel.org; kgene.kim at samsung.com; linux at arm.linux.org.uk;
arnd at arndb.de; naushad at samsung.com; tomasz.figa at gmail.com; joshi at samsung.com;
thomas.ab at samsung.com; vikas.sajjan at samsung.com; chow.kim at samsung.com;
lee.jones at linaro.org; 'Boris BREZILLON'; Xiubo Li-B47053; 'Geert Uytterhoeven';
'Stephen Warren'
Subject: RE: [PATCH v3] mfd: syscon: Decouple syscon interface from platform
devices
Hi,
Adding CC to Xiubo Li, Geert Uytterhoeven and Stephen Warren.
On Thursday, September 18, 2014, Dong Aisheng wrote,
quoted
On Wed, Sep 17, 2014 at 04:50:50PM +0530, Pankaj Dubey wrote:
quoted
Hi,
On Wednesday, September 17, 2014, Dong Aisheng Wrote,
quoted
quoted
+ regmap = regmap_init_mmio(NULL, base,
&syscon_regmap_config);
quoted
quoted
quoted
Does a NULL device pointer work?
Yes, it is safe, at least we are able to test on Exynos based SoC.
I have tested it with kgene/for-next kernel on Exynos3250.
Also it has been tested on Exynos5250 based Snow board with 3.17-rc5
based kernel by Vivek Gautam.
Patch V2 also has been tested by "Borris Brezillon" on AT91 platform.
The kernel i tested was next-20140915 of linux-next.
please see regmap_get_val_endian called in regmap_init function.
static enum regmap_endian regmap_get_val_endian(struct device *dev,
const struct regmap_bus *bus,
const struct regmap_config
*config) {
quoted
struct device_node *np = dev->of_node;
enum regmap_endian endian;
...
}
It will crash at the first line of dev->of_node if dev is NULL.
Can you check if you're using the same code as mine?
No, it's not same.
My bad that I was not using linux-next for testing this patch.
We tested on kgene/for-next where these changes still have not come.
Just now I checked linux-next and found that it will crash at first line of
"regmap_get_val_endian" as there is no check for NULL on dev.
I checked git history of regmap.c file and found recently this file has been
modified
for adding DT endianness binding support. Following are set of patches gone
for this
cf673fb regmap: Split regmap_get_endian() in two functions
5844a8b regmap: Fix handling of volatile registers for format_write() chips
45e1a27 regmap: of_regmap_get_endian() cleanup
ba1b53f regmap: Fix DT endianess parsing logic
d647c19 regmap: add DT endianness binding support.
I think there should have been a check for NULL on "dev" in
"regmap_get_val_endian", so that if dev pointer exist then only it makes
sense to get
endianness property from DT.
I will suggest following fix in regmap.c for this. With following fix I
tested it and it works well
on linux-next also. So if you can confirm following fix is working for you
then I can post this
patch.
--------------------------------------------
Subject: [PATCH] regmap: fix NULL pointer dereference in
regmap_get_val_endian
Recent commits for getting reg endianess causing NULL pointer
dereference if dev is passed NULL in regmap_init_mmio. This patch
fixes this issue, and allows to parse reg endianess only if dev
and dev->of_node exist.
Signed-off-by: Pankaj Dubey <redacted>
---
drivers/base/regmap/regmap.c | 23 ++++++++++++++---------
1 file changed, 14 insertions(+), 9 deletions(-)
device *dev,
if (endian != REGMAP_ENDIAN_DEFAULT)
return endian;
- /* Parse the device's DT node for an endianness specification */
- if (of_property_read_bool(np, "big-endian"))
- endian = REGMAP_ENDIAN_BIG;
- else if (of_property_read_bool(np, "little-endian"))
- endian = REGMAP_ENDIAN_LITTLE;
+ /* If the dev and dev->of_node exist try to get endianness from DT
*/
+ if (dev && dev->of_node) {
+ np = dev->of_node;
- /* If the endianness was specified in DT, use that */
- if (endian != REGMAP_ENDIAN_DEFAULT)
- return endian;
+ /* Parse the device's DT node for an endianness
specification */
+ if (of_property_read_bool(np, "big-endian"))
+ endian = REGMAP_ENDIAN_BIG;
+ else if (of_property_read_bool(np, "little-endian"))
+ endian = REGMAP_ENDIAN_LITTLE;
+
+ /* If the endianness was specified in DT, use that */
+ if (endian != REGMAP_ENDIAN_DEFAULT)
+ return endian;
+ }
/* Retrieve the endianness specification from the bus config */
if (bus && bus->val_format_endian_default)
--
Thanks,
Pankaj Dubey
please see regmap_get_val_endian called in regmap_init function.
static enum regmap_endian regmap_get_val_endian(struct device *dev,
const struct regmap_bus *bus,
const struct regmap_config
*config) {
quoted
struct device_node *np = dev->of_node;
enum regmap_endian endian;
...
}
It will crash at the first line of dev->of_node if dev is NULL.
Can you check if you're using the same code as mine?
No, it's not same.
My bad that I was not using linux-next for testing this patch.
We tested on kgene/for-next where these changes still have not come.
Just now I checked linux-next and found that it will crash at first line of
"regmap_get_val_endian" as there is no check for NULL on dev.
I checked git history of regmap.c file and found recently this file has been
modified
for adding DT endianness binding support. Following are set of patches gone
for this
cf673fb regmap: Split regmap_get_endian() in two functions
5844a8b regmap: Fix handling of volatile registers for format_write() chips
45e1a27 regmap: of_regmap_get_endian() cleanup
ba1b53f regmap: Fix DT endianess parsing logic
d647c19 regmap: add DT endianness binding support.
I think there should have been a check for NULL on "dev" in
"regmap_get_val_endian", so that if dev pointer exist then only it makes
sense to get
endianness property from DT.
I will suggest following fix in regmap.c for this. With following fix I
tested it and it works well
on linux-next also. So if you can confirm following fix is working for you
then I can post this
patch.
--------------------------------------------
Subject: [PATCH] regmap: fix NULL pointer dereference in
regmap_get_val_endian
Recent commits for getting reg endianess causing NULL pointer
dereference if dev is passed NULL in regmap_init_mmio. This patch
fixes this issue, and allows to parse reg endianess only if dev
and dev->of_node exist.
Another question:
Then the regmap core cannot deal with the following issue:
Like the patch adding the endianness support for syscon:
[PATCH] mfd: syscon: binding: Add syscon endianness support.
So here just register one dummy syscon device is a good choice I do
think.
:)
Thanks,
BRs
Xiubo
device *dev,
if (endian != REGMAP_ENDIAN_DEFAULT)
return endian;
- /* Parse the device's DT node for an endianness specification */
- if (of_property_read_bool(np, "big-endian"))
- endian = REGMAP_ENDIAN_BIG;
- else if (of_property_read_bool(np, "little-endian"))
- endian = REGMAP_ENDIAN_LITTLE;
+ /* If the dev and dev->of_node exist try to get endianness from DT
*/
+ if (dev && dev->of_node) {
+ np = dev->of_node;
- /* If the endianness was specified in DT, use that */
- if (endian != REGMAP_ENDIAN_DEFAULT)
- return endian;
+ /* Parse the device's DT node for an endianness
specification */
+ if (of_property_read_bool(np, "big-endian"))
+ endian = REGMAP_ENDIAN_BIG;
+ else if (of_property_read_bool(np, "little-endian"))
+ endian = REGMAP_ENDIAN_LITTLE;
+
+ /* If the endianness was specified in DT, use that */
+ if (endian != REGMAP_ENDIAN_DEFAULT)
+ return endian;
+ }
/* Retrieve the endianness specification from the bus config */
if (bus && bus->val_format_endian_default)
--
Thanks,
Pankaj Dubey
On Thu, Sep 18, 2014 at 11:33:26AM +0530, Pankaj Dubey wrote:
Hi,
Adding CC to Xiubo Li, Geert Uytterhoeven and Stephen Warren.
On Thursday, September 18, 2014, Dong Aisheng wrote,
quoted
On Wed, Sep 17, 2014 at 04:50:50PM +0530, Pankaj Dubey wrote:
quoted
Hi,
On Wednesday, September 17, 2014, Dong Aisheng Wrote,
quoted
quoted
+ regmap = regmap_init_mmio(NULL, base,
&syscon_regmap_config);
quoted
quoted
quoted
Does a NULL device pointer work?
Yes, it is safe, at least we are able to test on Exynos based SoC.
I have tested it with kgene/for-next kernel on Exynos3250.
Also it has been tested on Exynos5250 based Snow board with 3.17-rc5
based kernel by Vivek Gautam.
Patch V2 also has been tested by "Borris Brezillon" on AT91 platform.
The kernel i tested was next-20140915 of linux-next.
please see regmap_get_val_endian called in regmap_init function.
static enum regmap_endian regmap_get_val_endian(struct device *dev,
const struct regmap_bus *bus,
const struct regmap_config
*config) {
quoted
struct device_node *np = dev->of_node;
enum regmap_endian endian;
...
}
It will crash at the first line of dev->of_node if dev is NULL.
Can you check if you're using the same code as mine?
No, it's not same.
My bad that I was not using linux-next for testing this patch.
We tested on kgene/for-next where these changes still have not come.
Just now I checked linux-next and found that it will crash at first line of
"regmap_get_val_endian" as there is no check for NULL on dev.
I checked git history of regmap.c file and found recently this file has been
modified
for adding DT endianness binding support. Following are set of patches gone
for this
cf673fb regmap: Split regmap_get_endian() in two functions
5844a8b regmap: Fix handling of volatile registers for format_write() chips
45e1a27 regmap: of_regmap_get_endian() cleanup
ba1b53f regmap: Fix DT endianess parsing logic
d647c19 regmap: add DT endianness binding support.
I think there should have been a check for NULL on "dev" in
"regmap_get_val_endian", so that if dev pointer exist then only it makes
sense to get
endianness property from DT.
I will suggest following fix in regmap.c for this. With following fix I
tested it and it works well
on linux-next also. So if you can confirm following fix is working for you
then I can post this
patch.
I tested the patch work.
But as Xiubo pointed in another mail, it may still cause other issues.
Looking at regmap.c, there're still some other places using the device pointer,
e.g. dev_xxx debug information and some tracepoints also take device pointer
as parameter(not sure if it will break if dev is NULL).
Another thing is that if dev is NULL, we may not be able to use regmap debugfs
feature which seems also not as our expected.
Maybe we could consider create device structure for each syscon compatible
device in syscon driver in of_syscon_register in first time which seems to
be reasonable.
Regards
Dong Aisheng
quoted hunk
--------------------------------------------
Subject: [PATCH] regmap: fix NULL pointer dereference in
regmap_get_val_endian
Recent commits for getting reg endianess causing NULL pointer
dereference if dev is passed NULL in regmap_init_mmio. This patch
fixes this issue, and allows to parse reg endianess only if dev
and dev->of_node exist.
Signed-off-by: Pankaj Dubey <redacted>
---
drivers/base/regmap/regmap.c | 23 ++++++++++++++---------
1 file changed, 14 insertions(+), 9 deletions(-)
device *dev,
if (endian != REGMAP_ENDIAN_DEFAULT)
return endian;
- /* Parse the device's DT node for an endianness specification */
- if (of_property_read_bool(np, "big-endian"))
- endian = REGMAP_ENDIAN_BIG;
- else if (of_property_read_bool(np, "little-endian"))
- endian = REGMAP_ENDIAN_LITTLE;
+ /* If the dev and dev->of_node exist try to get endianness from DT
*/
+ if (dev && dev->of_node) {
+ np = dev->of_node;
- /* If the endianness was specified in DT, use that */
- if (endian != REGMAP_ENDIAN_DEFAULT)
- return endian;
+ /* Parse the device's DT node for an endianness
specification */
+ if (of_property_read_bool(np, "big-endian"))
+ endian = REGMAP_ENDIAN_BIG;
+ else if (of_property_read_bool(np, "little-endian"))
+ endian = REGMAP_ENDIAN_LITTLE;
+
+ /* If the endianness was specified in DT, use that */
+ if (endian != REGMAP_ENDIAN_DEFAULT)
+ return endian;
+ }
/* Retrieve the endianness specification from the bus config */
if (bus && bus->val_format_endian_default)
--
Thanks,
Pankaj Dubey
I think there should have been a check for NULL on "dev" in
"regmap_get_val_endian", so that if dev pointer exist then only it makes
sense to get
endianness property from DT.
I will suggest following fix in regmap.c for this. With following fix I
tested it and it works well
on linux-next also. So if you can confirm following fix is working for you
then I can post this
patch.
I tested the patch work.
But as Xiubo pointed in another mail, it may still cause other issues.
Looking at regmap.c, there're still some other places using the device pointer,
e.g. dev_xxx debug information and some tracepoints also take device pointer
as parameter(not sure if it will break if dev is NULL).
Another thing is that if dev is NULL, we may not be able to use regmap debugfs
feature which seems also not as our expected.
Maybe we could consider create device structure for each syscon compatible
device in syscon driver in of_syscon_register in first time which seems to
be reasonable.
Regards
Dong Aisheng
quoted
--------------------------------------------
Subject: [PATCH] regmap: fix NULL pointer dereference in
regmap_get_val_endian
Recent commits for getting reg endianess causing NULL pointer
dereference if dev is passed NULL in regmap_init_mmio. This patch
fixes this issue, and allows to parse reg endianess only if dev
and dev->of_node exist.
Signed-off-by: Pankaj Dubey <redacted>
---
drivers/base/regmap/regmap.c | 23 ++++++++++++++---------
1 file changed, 14 insertions(+), 9 deletions(-)
device *dev,
if (endian != REGMAP_ENDIAN_DEFAULT)
return endian;
- /* Parse the device's DT node for an endianness specification */
- if (of_property_read_bool(np, "big-endian"))
- endian = REGMAP_ENDIAN_BIG;
- else if (of_property_read_bool(np, "little-endian"))
- endian = REGMAP_ENDIAN_LITTLE;
+ /* If the dev and dev->of_node exist try to get endianness from DT
*/
+ if (dev && dev->of_node) {
+ np = dev->of_node;
- /* If the endianness was specified in DT, use that */
- if (endian != REGMAP_ENDIAN_DEFAULT)
- return endian;
+ /* Parse the device's DT node for an endianness
specification */
+ if (of_property_read_bool(np, "big-endian"))
+ endian = REGMAP_ENDIAN_BIG;
+ else if (of_property_read_bool(np, "little-endian"))
+ endian = REGMAP_ENDIAN_LITTLE;
+
+ /* If the endianness was specified in DT, use that */
+ if (endian != REGMAP_ENDIAN_DEFAULT)
+ return endian;
+ }
/* Retrieve the endianness specification from the bus config */
if (bus && bus->val_format_endian_default)
--
Thanks,
Pankaj Dubey
Hi,
On September 18, 2014 1:26, Dong Aisheng wrote
On Thu, Sep 18, 2014 at 11:33:26AM +0530, Pankaj Dubey wrote:
quoted
Hi,
Adding CC to Xiubo Li, Geert Uytterhoeven and Stephen Warren.
On Thursday, September 18, 2014, Dong Aisheng wrote,
quoted
On Wed, Sep 17, 2014 at 04:50:50PM +0530, Pankaj Dubey wrote:
quoted
Hi,
On Wednesday, September 17, 2014, Dong Aisheng Wrote,
quoted
quoted
+ regmap = regmap_init_mmio(NULL, base,
&syscon_regmap_config);
quoted
quoted
quoted
Does a NULL device pointer work?
Yes, it is safe, at least we are able to test on Exynos based SoC.
I have tested it with kgene/for-next kernel on Exynos3250.
Also it has been tested on Exynos5250 based Snow board with
3.17-rc5 based kernel by Vivek Gautam.
Patch V2 also has been tested by "Borris Brezillon" on AT91
platform.
quoted
quoted
quoted
The kernel i tested was next-20140915 of linux-next.
please see regmap_get_val_endian called in regmap_init function.
static enum regmap_endian regmap_get_val_endian(struct device *dev,
const struct regmap_bus *bus,
const struct regmap_config
*config) {
quoted
struct device_node *np = dev->of_node;
enum regmap_endian endian;
...
}
It will crash at the first line of dev->of_node if dev is NULL.
Can you check if you're using the same code as mine?
No, it's not same.
My bad that I was not using linux-next for testing this patch.
We tested on kgene/for-next where these changes still have not come.
Just now I checked linux-next and found that it will crash at first
line of "regmap_get_val_endian" as there is no check for NULL on dev.
I checked git history of regmap.c file and found recently this file
has been modified for adding DT endianness binding support. Following
are set of patches gone for this
cf673fb regmap: Split regmap_get_endian() in two functions 5844a8b
regmap: Fix handling of volatile registers for format_write() chips
45e1a27 regmap: of_regmap_get_endian() cleanup ba1b53f regmap: Fix DT
endianess parsing logic
d647c19 regmap: add DT endianness binding support.
I think there should have been a check for NULL on "dev" in
"regmap_get_val_endian", so that if dev pointer exist then only it
makes sense to get endianness property from DT.
I will suggest following fix in regmap.c for this. With following fix
I tested it and it works well on linux-next also. So if you can
confirm following fix is working for you then I can post this patch.
I tested the patch work.
Thanks for testing. In that case I will post this change, as I feel this
should be
fixed irrespective of my syscon patch.
But as Xiubo pointed in another mail, it may still cause other issues.
Looking at regmap.c, there're still some other places using the device
pointer, e.g.
dev_xxx debug information and some tracepoints also take device pointer as
parameter(not sure if it will break if dev is NULL).
Another thing is that if dev is NULL, we may not be able to use regmap
debugfs
feature which seems also not as our expected.
I would have preferred to check dev for NULL, as it's only at two places and
we could
still have debug prints for NULL dev, as normal pr_info instead of dev_info.
But Xiubo also pointed out that his patch [1] which updates syscon binding
information
will be useless if we pass NULL dev in regmap_init_mmio, which he posted
today,
and it requires dev pointer in "regmap_get_val_endian" function to read DT
property.
[1]: [PATCH] mfd: syscon: binding: Add syscon endianness support
https://lkml.org/lkml/2014/9/18/67
So instead of adding dummy device or creating device structure, I would
prefer to get actual
device pointer corresponding to "np" passed in of_syscon_register function
as shown below:
----
static struct syscon *of_syscon_register(struct device_node *np)
{
+ struct platform_device *pdev;
struct syscon *syscon;
struct regmap *regmap;
void __iomem *base;
device_node *np)
if (!base)
return ERR_PTR(-ENOMEM);
- regmap = regmap_init_mmio(NULL, base, &syscon_regmap_config);
+ pdev = of_find_device_by_node(np);
+ if (!(&pdev->dev))
+ return ERR_PTR(-ENODEV);
+
+ regmap = regmap_init_mmio(&pdev->dev, base, &syscon_regmap_config);
if (IS_ERR(regmap)) {
pr_err("regmap init failed\n");
return ERR_CAST(regmap);
-------
I have tested this in linux-next and it works well. In this way there won't
be any issues of
dereferencing NULL pointer in regmap.c and at the same time, if DT has
{big,little}-endian
optional property in syscon device node, it will be taken care.
So I would wait for Arnd's opinion about above mentioned changes and then
post a new
change after addressing Arnd's minor comment along with this fix in next
revision.
Thanks,
Pankaj Dubey
Maybe we could consider create device structure for each syscon compatible
device in
syscon driver in of_syscon_register in first time which seems to be
reasonable.
Regards
Dong Aisheng
quoted
--------------------------------------------
Subject: [PATCH] regmap: fix NULL pointer dereference in
regmap_get_val_endian
Recent commits for getting reg endianess causing NULL pointer
dereference if dev is passed NULL in regmap_init_mmio. This patch
fixes this issue, and allows to parse reg endianess only if dev and
dev->of_node exist.
Signed-off-by: Pankaj Dubey <redacted>
---
drivers/base/regmap/regmap.c | 23 ++++++++++++++---------
1 file changed, 14 insertions(+), 9 deletions(-)
diff --git a/drivers/base/regmap/regmap.c
b/drivers/base/regmap/regmap.c index f2281af..455a877 100644
- struct device_node *np = dev->of_node;
+ struct device_node *np;
enum regmap_endian endian;
/* Retrieve the endianness specification from the regmap config */
@@ -487,15 +487,20 @@ static enum regmap_endian
regmap_get_val_endian(struct device *dev,
if (endian != REGMAP_ENDIAN_DEFAULT)
return endian;
- /* Parse the device's DT node for an endianness specification */
- if (of_property_read_bool(np, "big-endian"))
- endian = REGMAP_ENDIAN_BIG;
- else if (of_property_read_bool(np, "little-endian"))
- endian = REGMAP_ENDIAN_LITTLE;
+ /* If the dev and dev->of_node exist try to get endianness from DT
*/
+ if (dev && dev->of_node) {
+ np = dev->of_node;
- /* If the endianness was specified in DT, use that */
- if (endian != REGMAP_ENDIAN_DEFAULT)
- return endian;
+ /* Parse the device's DT node for an endianness
specification */
+ if (of_property_read_bool(np, "big-endian"))
+ endian = REGMAP_ENDIAN_BIG;
+ else if (of_property_read_bool(np, "little-endian"))
+ endian = REGMAP_ENDIAN_LITTLE;
+
+ /* If the endianness was specified in DT, use that */
+ if (endian != REGMAP_ENDIAN_DEFAULT)
+ return endian;
+ }
/* Retrieve the endianness specification from the bus config */
if (bus && bus->val_format_endian_default)
--
Thanks,
Pankaj Dubey
Subject: RE: [PATCH v3] mfd: syscon: Decouple syscon interface from
platform
devices
[...]
quoted
quoted
I think there should have been a check for NULL on "dev" in
"regmap_get_val_endian", so that if dev pointer exist then only it
makes sense to get endianness property from DT.
I will suggest following fix in regmap.c for this. With following
fix I tested it and it works well on linux-next also. So if you can
confirm following fix is working for you then I can post this patch.
I tested the patch work.
But as Xiubo pointed in another mail, it may still cause other issues.
Looking at regmap.c, there're still some other places using the device
pointer, e.g. dev_xxx debug information and some tracepoints also take
device pointer as parameter(not sure if it will break if dev is NULL).
Another thing is that if dev is NULL, we may not be able to use regmap
debugfs feature which seems also not as our expected.
Maybe we could consider create device structure for each syscon
compatible device in syscon driver in of_syscon_register in first time
which seems to be reasonable.
Regards
Dong Aisheng
quoted
--------------------------------------------
Subject: [PATCH] regmap: fix NULL pointer dereference in
regmap_get_val_endian
Recent commits for getting reg endianess causing NULL pointer
dereference if dev is passed NULL in regmap_init_mmio. This patch
fixes this issue, and allows to parse reg endianess only if dev and
dev->of_node exist.
Signed-off-by: Pankaj Dubey <redacted>
---
drivers/base/regmap/regmap.c | 23 ++++++++++++++---------
1 file changed, 14 insertions(+), 9 deletions(-)
diff --git a/drivers/base/regmap/regmap.c
b/drivers/base/regmap/regmap.c index f2281af..455a877 100644
enum regmap_endian endian;
/* Retrieve the endianness specification from the regmap config */
@@ -487,15 +487,20 @@ static enum regmap_endian
regmap_get_val_endian(struct device *dev,
if (endian != REGMAP_ENDIAN_DEFAULT)
return endian;
- /* Parse the device's DT node for an endianness specification */
- if (of_property_read_bool(np, "big-endian"))
- endian = REGMAP_ENDIAN_BIG;
- else if (of_property_read_bool(np, "little-endian"))
- endian = REGMAP_ENDIAN_LITTLE;
+ /* If the dev and dev->of_node exist try to get endianness from DT
*/
+ if (dev && dev->of_node) {
+ np = dev->of_node;
- /* If the endianness was specified in DT, use that */
- if (endian != REGMAP_ENDIAN_DEFAULT)
- return endian;
+ /* Parse the device's DT node for an endianness
specification */
+ if (of_property_read_bool(np, "big-endian"))
+ endian = REGMAP_ENDIAN_BIG;
+ else if (of_property_read_bool(np, "little-endian"))
+ endian = REGMAP_ENDIAN_LITTLE;
+
+ /* If the endianness was specified in DT, use that */
+ if (endian != REGMAP_ENDIAN_DEFAULT)
+ return endian;
+ }
/* Retrieve the endianness specification from the bus config */
if (bus && bus->val_format_endian_default)
--
Thanks,
Pankaj Dubey
On Thu, Sep 18, 2014 at 03:06:59PM +0530, Pankaj Dubey wrote:
Hi,
On September 18, 2014 1:26, Dong Aisheng wrote
quoted
On Thu, Sep 18, 2014 at 11:33:26AM +0530, Pankaj Dubey wrote:
quoted
Hi,
Adding CC to Xiubo Li, Geert Uytterhoeven and Stephen Warren.
On Thursday, September 18, 2014, Dong Aisheng wrote,
quoted
On Wed, Sep 17, 2014 at 04:50:50PM +0530, Pankaj Dubey wrote:
quoted
Hi,
On Wednesday, September 17, 2014, Dong Aisheng Wrote,
quoted
quoted
+ regmap = regmap_init_mmio(NULL, base,
&syscon_regmap_config);
quoted
quoted
quoted
Does a NULL device pointer work?
Yes, it is safe, at least we are able to test on Exynos based SoC.
I have tested it with kgene/for-next kernel on Exynos3250.
Also it has been tested on Exynos5250 based Snow board with
3.17-rc5 based kernel by Vivek Gautam.
Patch V2 also has been tested by "Borris Brezillon" on AT91
platform.
quoted
quoted
quoted
quoted
The kernel i tested was next-20140915 of linux-next.
please see regmap_get_val_endian called in regmap_init function.
static enum regmap_endian regmap_get_val_endian(struct device *dev,
const struct regmap_bus *bus,
const struct regmap_config
*config) {
quoted
struct device_node *np = dev->of_node;
enum regmap_endian endian;
...
}
It will crash at the first line of dev->of_node if dev is NULL.
Can you check if you're using the same code as mine?
No, it's not same.
My bad that I was not using linux-next for testing this patch.
We tested on kgene/for-next where these changes still have not come.
Just now I checked linux-next and found that it will crash at first
line of "regmap_get_val_endian" as there is no check for NULL on dev.
I checked git history of regmap.c file and found recently this file
has been modified for adding DT endianness binding support. Following
are set of patches gone for this
cf673fb regmap: Split regmap_get_endian() in two functions 5844a8b
regmap: Fix handling of volatile registers for format_write() chips
45e1a27 regmap: of_regmap_get_endian() cleanup ba1b53f regmap: Fix DT
endianess parsing logic
d647c19 regmap: add DT endianness binding support.
I think there should have been a check for NULL on "dev" in
"regmap_get_val_endian", so that if dev pointer exist then only it
makes sense to get endianness property from DT.
I will suggest following fix in regmap.c for this. With following fix
I tested it and it works well on linux-next also. So if you can
confirm following fix is working for you then I can post this patch.
I tested the patch work.
Thanks for testing. In that case I will post this change, as I feel this
should be
fixed irrespective of my syscon patch.
quoted
But as Xiubo pointed in another mail, it may still cause other issues.
Looking at regmap.c, there're still some other places using the device
pointer, e.g.
quoted
dev_xxx debug information and some tracepoints also take device pointer as
parameter(not sure if it will break if dev is NULL).
Another thing is that if dev is NULL, we may not be able to use regmap
debugfs
quoted
feature which seems also not as our expected.
I would have preferred to check dev for NULL, as it's only at two places and
we could
still have debug prints for NULL dev, as normal pr_info instead of dev_info.
But Xiubo also pointed out that his patch [1] which updates syscon binding
information
will be useless if we pass NULL dev in regmap_init_mmio, which he posted
today,
and it requires dev pointer in "regmap_get_val_endian" function to read DT
property.
[1]: [PATCH] mfd: syscon: binding: Add syscon endianness support
https://lkml.org/lkml/2014/9/18/67
So instead of adding dummy device or creating device structure, I would
prefer to get actual
device pointer corresponding to "np" passed in of_syscon_register function
as shown below:
I wonder this may not work at early stage before the devices are populated
from device tree.
My initial understanding that one important thing for your patch is
to address this issue, isn't it?
Many people have asked for this feature before.
Regards
Dong Aisheng
device_node *np)
if (!base)
return ERR_PTR(-ENOMEM);
- regmap = regmap_init_mmio(NULL, base, &syscon_regmap_config);
+ pdev = of_find_device_by_node(np);
+ if (!(&pdev->dev))
+ return ERR_PTR(-ENODEV);
+
+ regmap = regmap_init_mmio(&pdev->dev, base, &syscon_regmap_config);
if (IS_ERR(regmap)) {
pr_err("regmap init failed\n");
return ERR_CAST(regmap);
-------
I have tested this in linux-next and it works well. In this way there won't
be any issues of
dereferencing NULL pointer in regmap.c and at the same time, if DT has
{big,little}-endian
optional property in syscon device node, it will be taken care.
So I would wait for Arnd's opinion about above mentioned changes and then
post a new
change after addressing Arnd's minor comment along with this fix in next
revision.
Thanks,
Pankaj Dubey
quoted
Maybe we could consider create device structure for each syscon compatible
device in
quoted
syscon driver in of_syscon_register in first time which seems to be
reasonable.
quoted
Regards
Dong Aisheng
quoted
--------------------------------------------
Subject: [PATCH] regmap: fix NULL pointer dereference in
regmap_get_val_endian
Recent commits for getting reg endianess causing NULL pointer
dereference if dev is passed NULL in regmap_init_mmio. This patch
fixes this issue, and allows to parse reg endianess only if dev and
dev->of_node exist.
Signed-off-by: Pankaj Dubey <redacted>
---
drivers/base/regmap/regmap.c | 23 ++++++++++++++---------
1 file changed, 14 insertions(+), 9 deletions(-)
diff --git a/drivers/base/regmap/regmap.c
b/drivers/base/regmap/regmap.c index f2281af..455a877 100644
- struct device_node *np = dev->of_node;
+ struct device_node *np;
enum regmap_endian endian;
/* Retrieve the endianness specification from the regmap config */
@@ -487,15 +487,20 @@ static enum regmap_endian
regmap_get_val_endian(struct device *dev,
if (endian != REGMAP_ENDIAN_DEFAULT)
return endian;
- /* Parse the device's DT node for an endianness specification */
- if (of_property_read_bool(np, "big-endian"))
- endian = REGMAP_ENDIAN_BIG;
- else if (of_property_read_bool(np, "little-endian"))
- endian = REGMAP_ENDIAN_LITTLE;
+ /* If the dev and dev->of_node exist try to get endianness from DT
*/
+ if (dev && dev->of_node) {
+ np = dev->of_node;
- /* If the endianness was specified in DT, use that */
- if (endian != REGMAP_ENDIAN_DEFAULT)
- return endian;
+ /* Parse the device's DT node for an endianness
specification */
+ if (of_property_read_bool(np, "big-endian"))
+ endian = REGMAP_ENDIAN_BIG;
+ else if (of_property_read_bool(np, "little-endian"))
+ endian = REGMAP_ENDIAN_LITTLE;
+
+ /* If the endianness was specified in DT, use that */
+ if (endian != REGMAP_ENDIAN_DEFAULT)
+ return endian;
+ }
/* Retrieve the endianness specification from the bus config */
if (bus && bus->val_format_endian_default)
--
Thanks,
Pankaj Dubey
Thanks for testing. In that case I will post this change, as I feel this
should be
fixed irrespective of my syscon patch.
quoted
But as Xiubo pointed in another mail, it may still cause other issues.
Looking at regmap.c, there're still some other places using the device
pointer, e.g.
quoted
dev_xxx debug information and some tracepoints also take device pointer as
parameter(not sure if it will break if dev is NULL).
Another thing is that if dev is NULL, we may not be able to use regmap
debugfs
quoted
feature which seems also not as our expected.
I would have preferred to check dev for NULL, as it's only at two places and
we could
still have debug prints for NULL dev, as normal pr_info instead of dev_info.
But Xiubo also pointed out that his patch [1] which updates syscon binding
information
will be useless if we pass NULL dev in regmap_init_mmio, which he posted
today,
and it requires dev pointer in "regmap_get_val_endian" function to read DT
property.
[1]: [PATCH] mfd: syscon: binding: Add syscon endianness support
https://lkml.org/lkml/2014/9/18/67
So instead of adding dummy device or creating device structure, I would
prefer to get actual
device pointer corresponding to "np" passed in of_syscon_register function
as shown below:
I wonder this may not work at early stage before the devices are populated
from device tree.
My initial understanding that one important thing for your patch is
to address this issue, isn't it?
Many people have asked for this feature before.
My boot log:
...
of_platform_bus_create() - skipping /chosen, no compatible prop
of_platform_bus_create() - skipping /aliases, no compatible prop
of_platform_bus_create() - skipping /memory, no compatible prop
of_platform_bus_create() - skipping /cpus, no compatible prop
create child: /soc/smmu at 1200000
create child: /soc/smmu at 1280000
create child: /soc/smmu at 1300000
create child: /soc/smmu at 1380000
create child: /soc/interrupt-controller at 1400000
create child: /soc/tzasc at 1500000
of_platform_bus_create() - skipping /soc/tzasc at 1500000, no compatible prop
create child: /soc/ifc at 1530000
create child: /soc/ifc at 1530000/nor at 0,0
create child: /soc/ifc at 1530000/board-control at 2,0
create child: /soc/dcfg at 1ee0000
syscon 1ee0000.dcfg: regmap [mem 0x01ee0000-0x01eeffff] registered
create child: /soc/quadspi at 1550000
create child: /soc/esdhc at 1560000
create child: /soc/scfg at 1570000
create child: /soc/crypto at 1700000
create child: /soc/sfp at 1e80000
of_platform_bus_create() - skipping /soc/sfp at 1e80000, no compatible prop
create child: /soc/snvs at 1e90000
of_platform_bus_create() - skipping /soc/snvs at 1e90000, no compatible prop
create child: /soc/serdes1 at 1ea0000
of_platform_bus_create() - skipping /soc/serdes1 at 1ea0000, no compatible prop
create child: /soc/clocking at 1ee1000
create child: /soc/rcpm at 1ee2000
create child: /soc/dspi at 2100000
create child: /soc/dspi at 2110000
create child: /soc/i2c at 2180000
create child: /soc/i2c at 2190000
create child: /soc/i2c at 21a0000
create child: /soc/serial at 21c0500
create child: /soc/serial at 21c0600
create child: /soc/serial at 21d0500
create child: /soc/serial at 21d0600
create child: /soc/gpio at 2300000
create child: /soc/gpio at 2310000
create child: /soc/gpio at 2320000
create child: /soc/gpio at 2330000
create child: /soc/uqe at 2400000
create child: /soc/uqe at 2400000/qeic at 80
create child: /soc/uqe at 2400000/ucc at 2000
irq: no irq domain found for /soc/uqe at 2400000/qeic at 80 !
create child: /soc/uqe at 2400000/ucc at 2200
irq: no irq domain found for /soc/uqe at 2400000/qeic at 80 !
create child: /soc/uqe at 2400000/muram at 10000
create child: /soc/uqe at 2400000/si at 700
create child: /soc/uqe at 2400000/siram at 1000
create child: /soc/serial at 2950000
create child: /soc/serial at 2960000
create child: /soc/serial at 2970000
create child: /soc/serial at 2980000
create child: /soc/serial at 2990000
create child: /soc/serial at 29a0000
create child: /soc/ftm0_1 at 29d0000
create child: /soc/ftm at 29f0000
of_platform_bus_create() - skipping /soc/ftm at 29f0000, no compatible prop
create child: /soc/ftm at 2a00000
create child: /soc/ftm at 2a10000
of_platform_bus_create() - skipping /soc/ftm at 2a10000, no compatible prop
create child: /soc/ftm at 2a20000
of_platform_bus_create() - skipping /soc/ftm at 2a20000, no compatible prop
create child: /soc/ftm at 2a30000
create child: /soc/ftm at 2a40000
create child: /soc/wdog at 2ad0000
create child: /soc/sai at 2b60000
create child: /soc/edma at 2c00000
create child: /soc/dcu at 2ce0000
create child: /soc/mdio at 2d24000
create child: /soc/ptp_clock at 2d10e00
create child: /soc/ethernet at 2d10000
create child: /soc/ethernet at 2d50000
create child: /soc/ethernet at 2d90000
create child: /soc/usb at 8600000
create child: /soc/usb3 at 3100000
create child: /soc/can at 2a70000
create child: /soc/can at 2a80000
create child: /soc/can at 2a90000
create child: /soc/can at 2aa0000
create child: /soc/pcie at 3400000
create child: /soc/pcie at 3500000
create child: /dcsr at 20000000/dcsr-epu at 0
create child: /dcsr at 20000000/dcsr-gdi at 100000
create child: /dcsr at 20000000/dcsr-dddi at 120000
create child: /dcsr at 20000000/dcsr-dcfg at 220000
create child: /dcsr at 20000000/dcsr-clock at 221000
create child: /dcsr at 20000000/dcsr-rcpm at 222000
create child: /dcsr at 20000000/dcsr-ccp at 225000
create child: /dcsr at 20000000/dcsr-fusectrl at 226000
create child: /dcsr at 20000000/dcsr-dap at 300000
create child: /dcsr at 20000000/dcsr-cstf at 350000
create child: /dcsr at 20000000/dcsr-a7rom at 360000
create child: /dcsr at 20000000/dcsr-a7cpu at 370000
create child: /dcsr at 20000000/dcsr-a7cti at 378000
create child: /dcsr at 20000000/dcsr-etm at 37c000
create child: /dcsr at 20000000/dcsr-hugorom at 3a0000
create child: /dcsr at 20000000/dcsr-etf at 3a1000
create child: /dcsr at 20000000/dcsr-etr at 3a3000
create child: /dcsr at 20000000/dcsr-cti at 3a4000
create child: /dcsr at 20000000/dcsr-atbrepl at 3a8000
create child: /dcsr at 20000000/dcsr-tsgen-ctrl at 3a9000
create child: /dcsr at 20000000/dcsr-tsgen-read at 3aa000
create child: /regulators/regulator at 0
...
As default the Linux will create all the platform device for each DT node, which
Can be found from "drivers/of/platform.c".
So we can get the pdev node using the specified DT node, and feel safe to use
it as Pankaj's patch does.
And also we must make sure that the 'syscon' DT nodes has the compatible prop.
Thanks,
BRs
Xiubo
device_node *np)
if (!base)
return ERR_PTR(-ENOMEM);
- regmap = regmap_init_mmio(NULL, base, &syscon_regmap_config);
+ pdev = of_find_device_by_node(np);
+ if (!(&pdev->dev))
+ return ERR_PTR(-ENODEV);
+
+ regmap = regmap_init_mmio(&pdev->dev, base, &syscon_regmap_config);
if (IS_ERR(regmap)) {
pr_err("regmap init failed\n");
return ERR_CAST(regmap);
-------
I have tested this in linux-next and it works well. In this way there won't
be any issues of
dereferencing NULL pointer in regmap.c and at the same time, if DT has
{big,little}-endian
optional property in syscon device node, it will be taken care.
So I would wait for Arnd's opinion about above mentioned changes and then
post a new
change after addressing Arnd's minor comment along with this fix in next
revision.
Thanks,
Pankaj Dubey
quoted
Maybe we could consider create device structure for each syscon compatible
device in
quoted
syscon driver in of_syscon_register in first time which seems to be
reasonable.
quoted
Regards
Dong Aisheng
quoted
--------------------------------------------
Subject: [PATCH] regmap: fix NULL pointer dereference in
regmap_get_val_endian
Recent commits for getting reg endianess causing NULL pointer
dereference if dev is passed NULL in regmap_init_mmio. This patch
fixes this issue, and allows to parse reg endianess only if dev and
dev->of_node exist.
Signed-off-by: Pankaj Dubey <redacted>
---
drivers/base/regmap/regmap.c | 23 ++++++++++++++---------
1 file changed, 14 insertions(+), 9 deletions(-)
diff --git a/drivers/base/regmap/regmap.c
b/drivers/base/regmap/regmap.c index f2281af..455a877 100644
- struct device_node *np = dev->of_node;
+ struct device_node *np;
enum regmap_endian endian;
/* Retrieve the endianness specification from the regmap config
*/
quoted
quoted
quoted
@@ -487,15 +487,20 @@ static enum regmap_endian
regmap_get_val_endian(struct device *dev,
if (endian != REGMAP_ENDIAN_DEFAULT)
return endian;
- /* Parse the device's DT node for an endianness specification */
- if (of_property_read_bool(np, "big-endian"))
- endian = REGMAP_ENDIAN_BIG;
- else if (of_property_read_bool(np, "little-endian"))
- endian = REGMAP_ENDIAN_LITTLE;
+ /* If the dev and dev->of_node exist try to get endianness from
DT
quoted
quoted
quoted
*/
+ if (dev && dev->of_node) {
+ np = dev->of_node;
- /* If the endianness was specified in DT, use that */
- if (endian != REGMAP_ENDIAN_DEFAULT)
- return endian;
+ /* Parse the device's DT node for an endianness
specification */
+ if (of_property_read_bool(np, "big-endian"))
+ endian = REGMAP_ENDIAN_BIG;
+ else if (of_property_read_bool(np, "little-endian"))
+ endian = REGMAP_ENDIAN_LITTLE;
+
+ /* If the endianness was specified in DT, use that */
+ if (endian != REGMAP_ENDIAN_DEFAULT)
+ return endian;
+ }
/* Retrieve the endianness specification from the bus config */
if (bus && bus->val_format_endian_default)
--
Thanks,
Pankaj Dubey
On Fri, Sep 19, 2014 at 11:38:03AM +0800, Xiubo Li-B47053 wrote:
quoted
quoted
Thanks for testing. In that case I will post this change, as I feel this
should be
fixed irrespective of my syscon patch.
quoted
But as Xiubo pointed in another mail, it may still cause other issues.
Looking at regmap.c, there're still some other places using the device
pointer, e.g.
quoted
dev_xxx debug information and some tracepoints also take device pointer as
parameter(not sure if it will break if dev is NULL).
Another thing is that if dev is NULL, we may not be able to use regmap
debugfs
quoted
feature which seems also not as our expected.
I would have preferred to check dev for NULL, as it's only at two places and
we could
still have debug prints for NULL dev, as normal pr_info instead of dev_info.
But Xiubo also pointed out that his patch [1] which updates syscon binding
information
will be useless if we pass NULL dev in regmap_init_mmio, which he posted
today,
and it requires dev pointer in "regmap_get_val_endian" function to read DT
property.
[1]: [PATCH] mfd: syscon: binding: Add syscon endianness support
https://lkml.org/lkml/2014/9/18/67
So instead of adding dummy device or creating device structure, I would
prefer to get actual
device pointer corresponding to "np" passed in of_syscon_register function
as shown below:
I wonder this may not work at early stage before the devices are populated
from device tree.
My initial understanding that one important thing for your patch is
to address this issue, isn't it?
Many people have asked for this feature before.
My boot log:
...
of_platform_bus_create() - skipping /chosen, no compatible prop
of_platform_bus_create() - skipping /aliases, no compatible prop
of_platform_bus_create() - skipping /memory, no compatible prop
of_platform_bus_create() - skipping /cpus, no compatible prop
create child: /soc/smmu at 1200000
create child: /soc/smmu at 1280000
create child: /soc/smmu at 1300000
create child: /soc/smmu at 1380000
create child: /soc/interrupt-controller at 1400000
create child: /soc/tzasc at 1500000
of_platform_bus_create() - skipping /soc/tzasc at 1500000, no compatible prop
create child: /soc/ifc at 1530000
create child: /soc/ifc at 1530000/nor at 0,0
create child: /soc/ifc at 1530000/board-control at 2,0
create child: /soc/dcfg at 1ee0000
syscon 1ee0000.dcfg: regmap [mem 0x01ee0000-0x01eeffff] registered
create child: /soc/quadspi at 1550000
create child: /soc/esdhc at 1560000
create child: /soc/scfg at 1570000
create child: /soc/crypto at 1700000
create child: /soc/sfp at 1e80000
of_platform_bus_create() - skipping /soc/sfp at 1e80000, no compatible prop
create child: /soc/snvs at 1e90000
of_platform_bus_create() - skipping /soc/snvs at 1e90000, no compatible prop
create child: /soc/serdes1 at 1ea0000
of_platform_bus_create() - skipping /soc/serdes1 at 1ea0000, no compatible prop
create child: /soc/clocking at 1ee1000
create child: /soc/rcpm at 1ee2000
create child: /soc/dspi at 2100000
create child: /soc/dspi at 2110000
create child: /soc/i2c at 2180000
create child: /soc/i2c at 2190000
create child: /soc/i2c at 21a0000
create child: /soc/serial at 21c0500
create child: /soc/serial at 21c0600
create child: /soc/serial at 21d0500
create child: /soc/serial at 21d0600
create child: /soc/gpio at 2300000
create child: /soc/gpio at 2310000
create child: /soc/gpio at 2320000
create child: /soc/gpio at 2330000
create child: /soc/uqe at 2400000
create child: /soc/uqe at 2400000/qeic at 80
create child: /soc/uqe at 2400000/ucc at 2000
irq: no irq domain found for /soc/uqe at 2400000/qeic at 80 !
create child: /soc/uqe at 2400000/ucc at 2200
irq: no irq domain found for /soc/uqe at 2400000/qeic at 80 !
create child: /soc/uqe at 2400000/muram at 10000
create child: /soc/uqe at 2400000/si at 700
create child: /soc/uqe at 2400000/siram at 1000
create child: /soc/serial at 2950000
create child: /soc/serial at 2960000
create child: /soc/serial at 2970000
create child: /soc/serial at 2980000
create child: /soc/serial at 2990000
create child: /soc/serial at 29a0000
create child: /soc/ftm0_1 at 29d0000
create child: /soc/ftm at 29f0000
of_platform_bus_create() - skipping /soc/ftm at 29f0000, no compatible prop
create child: /soc/ftm at 2a00000
create child: /soc/ftm at 2a10000
of_platform_bus_create() - skipping /soc/ftm at 2a10000, no compatible prop
create child: /soc/ftm at 2a20000
of_platform_bus_create() - skipping /soc/ftm at 2a20000, no compatible prop
create child: /soc/ftm at 2a30000
create child: /soc/ftm at 2a40000
create child: /soc/wdog at 2ad0000
create child: /soc/sai at 2b60000
create child: /soc/edma at 2c00000
create child: /soc/dcu at 2ce0000
create child: /soc/mdio at 2d24000
create child: /soc/ptp_clock at 2d10e00
create child: /soc/ethernet at 2d10000
create child: /soc/ethernet at 2d50000
create child: /soc/ethernet at 2d90000
create child: /soc/usb at 8600000
create child: /soc/usb3 at 3100000
create child: /soc/can at 2a70000
create child: /soc/can at 2a80000
create child: /soc/can at 2a90000
create child: /soc/can at 2aa0000
create child: /soc/pcie at 3400000
create child: /soc/pcie at 3500000
create child: /dcsr at 20000000/dcsr-epu at 0
create child: /dcsr at 20000000/dcsr-gdi at 100000
create child: /dcsr at 20000000/dcsr-dddi at 120000
create child: /dcsr at 20000000/dcsr-dcfg at 220000
create child: /dcsr at 20000000/dcsr-clock at 221000
create child: /dcsr at 20000000/dcsr-rcpm at 222000
create child: /dcsr at 20000000/dcsr-ccp at 225000
create child: /dcsr at 20000000/dcsr-fusectrl at 226000
create child: /dcsr at 20000000/dcsr-dap at 300000
create child: /dcsr at 20000000/dcsr-cstf at 350000
create child: /dcsr at 20000000/dcsr-a7rom at 360000
create child: /dcsr at 20000000/dcsr-a7cpu at 370000
create child: /dcsr at 20000000/dcsr-a7cti at 378000
create child: /dcsr at 20000000/dcsr-etm at 37c000
create child: /dcsr at 20000000/dcsr-hugorom at 3a0000
create child: /dcsr at 20000000/dcsr-etf at 3a1000
create child: /dcsr at 20000000/dcsr-etr at 3a3000
create child: /dcsr at 20000000/dcsr-cti at 3a4000
create child: /dcsr at 20000000/dcsr-atbrepl at 3a8000
create child: /dcsr at 20000000/dcsr-tsgen-ctrl at 3a9000
create child: /dcsr at 20000000/dcsr-tsgen-read at 3aa000
create child: /regulators/regulator at 0
...
As default the Linux will create all the platform device for each DT node, which
Can be found from "drivers/of/platform.c".
So we can get the pdev node using the specified DT node, and feel safe to use
it as Pankaj's patch does.
I mean before the devices are populated from device tree.
For example, we usually call of_platform_populate in .init_machine.
Before it, we may not be able to get it's device, isn't it?
Regards
Dong Aisheng
And also we must make sure that the 'syscon' DT nodes has the compatible prop.
Thanks,
BRs
Xiubo
device_node *np)
if (!base)
return ERR_PTR(-ENOMEM);
- regmap = regmap_init_mmio(NULL, base, &syscon_regmap_config);
+ pdev = of_find_device_by_node(np);
+ if (!(&pdev->dev))
+ return ERR_PTR(-ENODEV);
+
+ regmap = regmap_init_mmio(&pdev->dev, base, &syscon_regmap_config);
if (IS_ERR(regmap)) {
pr_err("regmap init failed\n");
return ERR_CAST(regmap);
-------
I have tested this in linux-next and it works well. In this way there won't
be any issues of
dereferencing NULL pointer in regmap.c and at the same time, if DT has
{big,little}-endian
optional property in syscon device node, it will be taken care.
So I would wait for Arnd's opinion about above mentioned changes and then
post a new
change after addressing Arnd's minor comment along with this fix in next
revision.
Thanks,
Pankaj Dubey
quoted
Maybe we could consider create device structure for each syscon compatible
device in
quoted
syscon driver in of_syscon_register in first time which seems to be
reasonable.
quoted
Regards
Dong Aisheng
quoted
--------------------------------------------
Subject: [PATCH] regmap: fix NULL pointer dereference in
regmap_get_val_endian
Recent commits for getting reg endianess causing NULL pointer
dereference if dev is passed NULL in regmap_init_mmio. This patch
fixes this issue, and allows to parse reg endianess only if dev and
dev->of_node exist.
Signed-off-by: Pankaj Dubey <redacted>
---
drivers/base/regmap/regmap.c | 23 ++++++++++++++---------
1 file changed, 14 insertions(+), 9 deletions(-)
diff --git a/drivers/base/regmap/regmap.c
b/drivers/base/regmap/regmap.c index f2281af..455a877 100644
- struct device_node *np = dev->of_node;
+ struct device_node *np;
enum regmap_endian endian;
/* Retrieve the endianness specification from the regmap config
*/
quoted
quoted
quoted
@@ -487,15 +487,20 @@ static enum regmap_endian
regmap_get_val_endian(struct device *dev,
if (endian != REGMAP_ENDIAN_DEFAULT)
return endian;
- /* Parse the device's DT node for an endianness specification */
- if (of_property_read_bool(np, "big-endian"))
- endian = REGMAP_ENDIAN_BIG;
- else if (of_property_read_bool(np, "little-endian"))
- endian = REGMAP_ENDIAN_LITTLE;
+ /* If the dev and dev->of_node exist try to get endianness from
DT
quoted
quoted
quoted
*/
+ if (dev && dev->of_node) {
+ np = dev->of_node;
- /* If the endianness was specified in DT, use that */
- if (endian != REGMAP_ENDIAN_DEFAULT)
- return endian;
+ /* Parse the device's DT node for an endianness
specification */
+ if (of_property_read_bool(np, "big-endian"))
+ endian = REGMAP_ENDIAN_BIG;
+ else if (of_property_read_bool(np, "little-endian"))
+ endian = REGMAP_ENDIAN_LITTLE;
+
+ /* If the endianness was specified in DT, use that */
+ if (endian != REGMAP_ENDIAN_DEFAULT)
+ return endian;
+ }
/* Retrieve the endianness specification from the bus config */
if (bus && bus->val_format_endian_default)
--
Thanks,
Pankaj Dubey
create child: /dcsr at 20000000/dcsr-atbrepl at 3a8000
create child: /dcsr at 20000000/dcsr-tsgen-ctrl at 3a9000
create child: /dcsr at 20000000/dcsr-tsgen-read at 3aa000
create child: /regulators/regulator at 0
...
As default the Linux will create all the platform device for each DT node,
which
quoted
Can be found from "drivers/of/platform.c".
So we can get the pdev node using the specified DT node, and feel safe to
use
quoted
it as Pankaj's patch does.
I mean before the devices are populated from device tree.
For example, we usually call of_platform_populate in .init_machine.
Before it, we may not be able to get it's device, isn't it?
Yes, right.
For this case, we'd better create the pdev or dev manually for the first time
We use it, right ?
Thanks,
BRs
Xiubo
Regards
Dong Aisheng
quoted
And also we must make sure that the 'syscon' DT nodes has the compatible
if (IS_ERR(regmap)) {
pr_err("regmap init failed\n");
return ERR_CAST(regmap);
-------
I have tested this in linux-next and it works well. In this way there
won't
quoted
quoted
quoted
be any issues of
dereferencing NULL pointer in regmap.c and at the same time, if DT has
{big,little}-endian
optional property in syscon device node, it will be taken care.
So I would wait for Arnd's opinion about above mentioned changes and
then
quoted
quoted
quoted
post a new
change after addressing Arnd's minor comment along with this fix in next
revision.
Thanks,
Pankaj Dubey
quoted
Maybe we could consider create device structure for each syscon
compatible
quoted
quoted
quoted
device in
quoted
syscon driver in of_syscon_register in first time which seems to be
reasonable.
quoted
Regards
Dong Aisheng
quoted
--------------------------------------------
Subject: [PATCH] regmap: fix NULL pointer dereference in
regmap_get_val_endian
Recent commits for getting reg endianess causing NULL pointer
dereference if dev is passed NULL in regmap_init_mmio. This patch
fixes this issue, and allows to parse reg endianess only if dev and
dev->of_node exist.
Signed-off-by: Pankaj Dubey <redacted>
---
drivers/base/regmap/regmap.c | 23 ++++++++++++++---------
1 file changed, 14 insertions(+), 9 deletions(-)
diff --git a/drivers/base/regmap/regmap.c
b/drivers/base/regmap/regmap.c index f2281af..455a877 100644
- struct device_node *np = dev->of_node;
+ struct device_node *np;
enum regmap_endian endian;
/* Retrieve the endianness specification from the regmap config
*/
quoted
quoted
quoted
@@ -487,15 +487,20 @@ static enum regmap_endian
regmap_get_val_endian(struct device *dev,
if (endian != REGMAP_ENDIAN_DEFAULT)
return endian;
- /* Parse the device's DT node for an endianness specification */
- if (of_property_read_bool(np, "big-endian"))
- endian = REGMAP_ENDIAN_BIG;
- else if (of_property_read_bool(np, "little-endian"))
- endian = REGMAP_ENDIAN_LITTLE;
+ /* If the dev and dev->of_node exist try to get endianness from
DT
quoted
quoted
quoted
*/
+ if (dev && dev->of_node) {
+ np = dev->of_node;
- /* If the endianness was specified in DT, use that */
- if (endian != REGMAP_ENDIAN_DEFAULT)
- return endian;
+ /* Parse the device's DT node for an endianness
specification */
+ if (of_property_read_bool(np, "big-endian"))
+ endian = REGMAP_ENDIAN_BIG;
+ else if (of_property_read_bool(np, "little-endian"))
+ endian = REGMAP_ENDIAN_LITTLE;
+
+ /* If the endianness was specified in DT, use that */
+ if (endian != REGMAP_ENDIAN_DEFAULT)
+ return endian;
+ }
/* Retrieve the endianness specification from the bus config */
if (bus && bus->val_format_endian_default)
--
Thanks,
Pankaj Dubey
On Fri, Sep 19, 2014 at 01:20:18PM +0800, Xiubo Li-B47053 wrote:
[...]
quoted
quoted
create child: /dcsr at 20000000/dcsr-atbrepl at 3a8000
create child: /dcsr at 20000000/dcsr-tsgen-ctrl at 3a9000
create child: /dcsr at 20000000/dcsr-tsgen-read at 3aa000
create child: /regulators/regulator at 0
...
As default the Linux will create all the platform device for each DT node,
which
quoted
Can be found from "drivers/of/platform.c".
So we can get the pdev node using the specified DT node, and feel safe to
use
quoted
it as Pankaj's patch does.
I mean before the devices are populated from device tree.
For example, we usually call of_platform_populate in .init_machine.
Before it, we may not be able to get it's device, isn't it?
Yes, right.
For this case, we'd better create the pdev or dev manually for the first time
We use it, right ?
Yes, that's my understanding.
Regards
Dong Aisheng
Thanks,
BRs
Xiubo
quoted
Regards
Dong Aisheng
quoted
And also we must make sure that the 'syscon' DT nodes has the compatible
if (IS_ERR(regmap)) {
pr_err("regmap init failed\n");
return ERR_CAST(regmap);
-------
I have tested this in linux-next and it works well. In this way there
won't
quoted
quoted
quoted
be any issues of
dereferencing NULL pointer in regmap.c and at the same time, if DT has
{big,little}-endian
optional property in syscon device node, it will be taken care.
So I would wait for Arnd's opinion about above mentioned changes and
then
quoted
quoted
quoted
post a new
change after addressing Arnd's minor comment along with this fix in next
revision.
Thanks,
Pankaj Dubey
quoted
Maybe we could consider create device structure for each syscon
compatible
quoted
quoted
quoted
device in
quoted
syscon driver in of_syscon_register in first time which seems to be
reasonable.
quoted
Regards
Dong Aisheng
quoted
--------------------------------------------
Subject: [PATCH] regmap: fix NULL pointer dereference in
regmap_get_val_endian
Recent commits for getting reg endianess causing NULL pointer
dereference if dev is passed NULL in regmap_init_mmio. This patch
fixes this issue, and allows to parse reg endianess only if dev and
dev->of_node exist.
Signed-off-by: Pankaj Dubey <redacted>
---
drivers/base/regmap/regmap.c | 23 ++++++++++++++---------
1 file changed, 14 insertions(+), 9 deletions(-)
diff --git a/drivers/base/regmap/regmap.c
b/drivers/base/regmap/regmap.c index f2281af..455a877 100644
- struct device_node *np = dev->of_node;
+ struct device_node *np;
enum regmap_endian endian;
/* Retrieve the endianness specification from the regmap config
*/
quoted
quoted
quoted
@@ -487,15 +487,20 @@ static enum regmap_endian
regmap_get_val_endian(struct device *dev,
if (endian != REGMAP_ENDIAN_DEFAULT)
return endian;
- /* Parse the device's DT node for an endianness specification */
- if (of_property_read_bool(np, "big-endian"))
- endian = REGMAP_ENDIAN_BIG;
- else if (of_property_read_bool(np, "little-endian"))
- endian = REGMAP_ENDIAN_LITTLE;
+ /* If the dev and dev->of_node exist try to get endianness from
DT
quoted
quoted
quoted
*/
+ if (dev && dev->of_node) {
+ np = dev->of_node;
- /* If the endianness was specified in DT, use that */
- if (endian != REGMAP_ENDIAN_DEFAULT)
- return endian;
+ /* Parse the device's DT node for an endianness
specification */
+ if (of_property_read_bool(np, "big-endian"))
+ endian = REGMAP_ENDIAN_BIG;
+ else if (of_property_read_bool(np, "little-endian"))
+ endian = REGMAP_ENDIAN_LITTLE;
+
+ /* If the endianness was specified in DT, use that */
+ if (endian != REGMAP_ENDIAN_DEFAULT)
+ return endian;
+ }
/* Retrieve the endianness specification from the bus config */
if (bus && bus->val_format_endian_default)
--
Thanks,
Pankaj Dubey
Hi Dong and Xiubo,
On Friday, September 19, 2014, Dong Aisheng wrote,
On Fri, Sep 19, 2014 at 01:20:18PM +0800, Xiubo Li-B47053 wrote:
quoted
[...]
quoted
quoted
create child: /dcsr at 20000000/dcsr-atbrepl at 3a8000
create child: /dcsr at 20000000/dcsr-tsgen-ctrl at 3a9000
create child: /dcsr at 20000000/dcsr-tsgen-read at 3aa000
create child: /regulators/regulator at 0
...
As default the Linux will create all the platform device for each
DT node,
which
quoted
Can be found from "drivers/of/platform.c".
So we can get the pdev node using the specified DT node, and feel
safe to
use
quoted
it as Pankaj's patch does.
I mean before the devices are populated from device tree.
For example, we usually call of_platform_populate in .init_machine.
Before it, we may not be able to get it's device, isn't it?
Yes, right.
For this case, we'd better create the pdev or dev manually for the
first time We use it, right ?
Yes, that's my understanding.
Thanks for all your inputs.
First let me clarify that the main purpose of this patch, we introduced this
patch mainly because
if some HW IP is having secondary compatibility as "syscon", syscon driver
was getting probed
and since there can be only on platform_device corresponding to one
device_node, actual driver
corresponding to that HW IP was not getting probed. So we wanted to decouple
syscon from platform
device, and any such driver should be able to become syscon provider. Please
see discussion here [1].
[1]: https://lkml.org/lkml/2014/6/17/331
But while doing so eventually this patch was also able to cover the feature
of early availability of syscon
lookup APIs.
As both of you pointed out that if we use "of_find_device_by_node" and it
won't work for early users
of syscon. I also agree with that, but it just skipped from my mind while
suggesting that approach.
I reconsidered again and made following changes and tested it. Now I am able
to use syscon_lookup_by_xxxxx
APIs, very early (before dt_machine_init) as well as after
of_platform_populate. So please review and if
it is acceptable I will post next version of this patch.
Basic idea is, check for device_node pointer in of_syscon_register, if
device corresponding to that device_node
is already populated and available use "of_find_device_by_node" else create
a dummy platform device and then
use it.
----------
static struct syscon *of_syscon_register(struct device_node *np)
{
+ struct platform_device *pdev = NULL;
struct syscon *syscon;
struct regmap *regmap;
void __iomem *base;
+ struct platform_device dummy_pdev = {
+ .name = "dummy-syscon",
+ .id = -1,
+ };
+
if (!of_device_is_compatible(np, "syscon"))
return ERR_PTR(-EINVAL);
if (IS_ERR(regmap)) {
pr_err("regmap init failed\n");
return ERR_CAST(regmap);
-------
I have tested this in linux-next and it works well. In this
way there
won't
quoted
quoted
quoted
be any issues of
dereferencing NULL pointer in regmap.c and at the same time,
if DT has {big,little}-endian optional property in syscon
device node, it will be taken care.
So I would wait for Arnd's opinion about above mentioned
changes and
then
quoted
quoted
quoted
post a new
change after addressing Arnd's minor comment along with this
fix in next revision.
Thanks,
Pankaj Dubey
quoted
Maybe we could consider create device structure for each
syscon
compatible
quoted
quoted
quoted
device in
quoted
syscon driver in of_syscon_register in first time which
seems to be
reasonable.
quoted
Regards
Dong Aisheng
quoted
--------------------------------------------
Subject: [PATCH] regmap: fix NULL pointer dereference in
regmap_get_val_endian
Recent commits for getting reg endianess causing NULL
pointer dereference if dev is passed NULL in
regmap_init_mmio. This patch fixes this issue, and allows
to parse reg endianess only if dev and
dev->of_node exist.
Signed-off-by: Pankaj Dubey <redacted>
---
drivers/base/regmap/regmap.c | 23 ++++++++++++++-------
--
quoted
quoted
quoted
quoted
quoted
quoted
quoted
1 file changed, 14 insertions(+), 9 deletions(-)
diff --git a/drivers/base/regmap/regmap.c
b/drivers/base/regmap/regmap.c index f2281af..455a877
100644
- struct device_node *np = dev->of_node;
+ struct device_node *np;
enum regmap_endian endian;
/* Retrieve the endianness specification from the
regmap
quoted
quoted
quoted
quoted
quoted
quoted
quoted
config
*/
quoted
quoted
quoted
@@ -487,15 +487,20 @@ static enum regmap_endian
regmap_get_val_endian(struct device *dev,
if (endian != REGMAP_ENDIAN_DEFAULT)
return endian;
- /* Parse the device's DT node for an endianness
specification
*/
quoted
quoted
quoted
quoted
quoted
quoted
quoted
- if (of_property_read_bool(np, "big-endian"))
- endian = REGMAP_ENDIAN_BIG;
- else if (of_property_read_bool(np, "little-endian"))
- endian = REGMAP_ENDIAN_LITTLE;
+ /* If the dev and dev->of_node exist try to get
+endianness from
DT
quoted
quoted
quoted
*/
+ if (dev && dev->of_node) {
+ np = dev->of_node;
- /* If the endianness was specified in DT, use that
*/
quoted
quoted
quoted
quoted
quoted
quoted
quoted
- if (endian != REGMAP_ENDIAN_DEFAULT)
- return endian;
+ /* Parse the device's DT node for an
endianness
quoted
quoted
quoted
quoted
quoted
quoted
quoted
specification */
+ if (of_property_read_bool(np, "big-endian"))
+ endian = REGMAP_ENDIAN_BIG;
+ else if (of_property_read_bool(np,
"little-endian"))
quoted
quoted
quoted
quoted
quoted
quoted
quoted
+ endian = REGMAP_ENDIAN_LITTLE;
+
+ /* If the endianness was specified in DT,
use that */
quoted
quoted
quoted
quoted
quoted
quoted
quoted
+ if (endian != REGMAP_ENDIAN_DEFAULT)
+ return endian;
+ }
/* Retrieve the endianness specification from the
bus config */
quoted
quoted
quoted
quoted
quoted
quoted
quoted
if (bus && bus->val_format_endian_default)
--
Thanks,
Pankaj Dubey