devm_ioremap() in a sysfs show method
Dear all, I'm trying to create a simple sysfs node that prints the content of a register. The code looks like this static ssize_t my_read_reg(struct device *pdev, struct device_attribute *attr, char *buf) { u32 __iomem *reg; reg = devm_ioremap(pdev, 0x581018C4, 4); return scnprintf(buf, PAGE_SIZE, "0x%02x\n", ioread8(reg)); } Is it ok to use devm_ioremap() on the device that I get here? If so, may I assume that devm_ioremap() re-uses an existing mapping and it's ok to call it for each sysfs access? The physical address that I pass to devm_ioremap() is not page-aligned. This seems to work on arm. Is there a recommended (i.e. more portable) way of doing this? Should I map a larger area and use PAGE_ALIGN()? Thanks for your feedback, Martin
I've just had another look at this. Thus wrote Martin Kaiser (lists@kaiser.cx):
static ssize_t my_read_reg(struct device *pdev, struct device_attribute *attr, char *buf) { u32 __iomem *reg;
reg = devm_ioremap(pdev, 0x581018C4, 4); return scnprintf(buf, PAGE_SIZE, "0x%02x\n", ioread8(reg)); }
Is it ok to use devm_ioremap() on the device that I get here? If so, may I assume that devm_ioremap() re-uses an existing mapping and it's ok to call it for each sysfs access?
Using devm_ioremap() seems a bad idea. I get a different virtual address in reg for each call to the read method. Also, using dev_info() or similar debug prints on the device would crash my kernel. [ 19.802171] [<c01aa494>] (dev_driver_string+0x0/0x4c) from [<c01aa60c>] (__dev_printk+0x44/0x7c) [ 19.811011] [<c01aa5c8>] (__dev_printk+0x0/0x7c) from [<c01aa6cc>] (dev_info+0x44/0x50) [ 19.819117] r6:d388f1a0 r5:d3afd000 r4:d48f68d4 [ 19.823840] [<c01aa688>] (dev_info+0x0/0x50) from [<c0013c6c>] (my_read_reg+0x3c/0x64) It seems the device that's passed to the read method has some limitations. In my setup, I created a kobject with NULL parent and called sysfs_create_group() to attach my nodes to the kobject. I'd appreciate any hints that help me understand what's going on behind the scenes. Thanks, Martin
participants (1)
-
Martin Kaiser