From: Vladimir Zapolskiy <vladimir_zapolskiy@mentor.com>
To: Philipp Zabel <p.zabel@pengutronix.de>
Cc: "Heiko Stübner" <heiko@sntech.de>,
"Arnd Bergmann" <arnd@arndb.de>,
"Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v3 3/9] misc: sram: use phys_addr_t instead of u32 for physical address
Date: Tue, 19 May 2015 15:30:06 +0300 [thread overview]
Message-ID: <555B2CCE.50306@mentor.com> (raw)
In-Reply-To: <1432031917.15181.20.camel@pengutronix.de>
Hi Philipp,
thank you for review.
On 19.05.2015 13:38, Philipp Zabel wrote:
> Hi Vladimir,
>
> Am Montag, den 18.05.2015, 22:08 +0300 schrieb Vladimir Zapolskiy:
>> To avoid any problems on non 32-bit platforms get and store memory
>> addresses under phys_addr_t type.
>>
>> Signed-off-by: Vladimir Zapolskiy <vladimir_zapolskiy@mentor.com>
>> ---
>> Changes from v1 to v2:
>> - report size of SRAM in decimal format '%zu' instead of '%zx'
>> - replacement of denominator '1024' to SZ_1K requires explicit
>> include of linux/sizes.h on some platforms, keep it as a number
>>
>> drivers/misc/sram.c | 26 +++++++++++++++-----------
>> 1 file changed, 15 insertions(+), 11 deletions(-)
>>
>> diff --git a/drivers/misc/sram.c b/drivers/misc/sram.c
>> index 999684a..b7a3a24 100644
>> --- a/drivers/misc/sram.c
>> +++ b/drivers/misc/sram.c
>> @@ -41,8 +41,8 @@ struct sram_dev {
>>
>> struct sram_reserve {
>> struct list_head list;
>> - u32 start;
>> - u32 size;
>> + phys_addr_t start;
>> + size_t size;
>> };
>>
>> static int sram_reserve_cmp(void *priv, struct list_head *a,
>> @@ -60,7 +60,8 @@ static int sram_probe(struct platform_device *pdev)
>> struct sram_dev *sram;
>> struct resource *res;
>> struct device_node *np = pdev->dev.of_node, *child;
>> - unsigned long size, cur_start, cur_size;
>> + phys_addr_t cur_start;
>> + size_t size, cur_size;
>> struct sram_reserve *rblocks, *block;
>> struct list_head reserve_list;
>> unsigned int nblocks;
>> @@ -138,9 +139,9 @@ static int sram_probe(struct platform_device *pdev)
>> block->size = resource_size(&child_res);
>> list_add_tail(&block->list, &reserve_list);
>>
>> - dev_dbg(&pdev->dev, "found reserved block 0x%x-0x%x\n",
>> - block->start,
>> - block->start + block->size);
>> + dev_dbg(&pdev->dev, "found reserved block 0x%llx-0x%llx\n",
>> + (unsigned long long)block->start,
>
> Now that block->start is of type phys_addr_t, is there a reason not to
> use %pa ?
the only reason why I decided not to use %pa in the change is because
the value should be passed over a pointer then.
For instance right here it is possible to change '"0x%llx", (unsigned
long long)block->start' to '"%pa", &block->start', however some lines
below the same trick can not be done for '(unsigned long long)cur_start
+ cur_size' value. Among alternatives to introduce a local variable, use
mixed "0x%llx" and "%pa" or use unified "0x%llx" I selected the latter one.
>> + (unsigned long long)block->start + block->size);
>
> phys_addr_t end = block->start + block->size;
>
> dev_dbg(&pdev->dev, "found reserved block 0x%pa-0x%pa\n",
> &block->start, &end);
>
>> block++;
>> }
>> @@ -158,8 +159,9 @@ static int sram_probe(struct platform_device *pdev)
>> /* can only happen if sections overlap */
>> if (block->start < cur_start) {
>> dev_err(&pdev->dev,
>> - "block at 0x%x starts after current offset 0x%lx\n",
>> - block->start, cur_start);
>> + "block at 0x%llx starts after current offset 0x%llx\n",
>> + (unsigned long long)block->start,
>> + (unsigned long long)cur_start);
>
> dev_err(&pdev->dev,
> "block at 0x%pa starts after current offset 0x%pa\n",
> &block->start, &cur_start);
>
>> ret = -EINVAL;
>> goto err_chunks;
>> }
>> @@ -177,8 +179,9 @@ static int sram_probe(struct platform_device *pdev)
>> */
>> cur_size = block->start - cur_start;
>>
>> - dev_dbg(&pdev->dev, "adding chunk 0x%lx-0x%lx\n",
>> - cur_start, cur_start + cur_size);
>> + dev_dbg(&pdev->dev, "adding chunk 0x%llx-0x%llx\n",
>> + (unsigned long long)cur_start,
>> + (unsigned long long)cur_start + cur_size);
>
> dev_dbg(&pdev->dev, "adding chunk 0x%pa-0x%pa\n",
> &cur_start, &block->start);
>
>> ret = gen_pool_add_virt(sram->pool,
>> (unsigned long)virt_base + cur_start,
>> res->start + cur_start, cur_size, -1);
>> @@ -193,7 +196,8 @@ static int sram_probe(struct platform_device *pdev)
>>
>> platform_set_drvdata(pdev, sram);
>>
>> - dev_dbg(&pdev->dev, "SRAM pool: %ld KiB @ 0x%p\n", size / 1024, virt_base);
>> + dev_dbg(&pdev->dev, "SRAM pool: %zu KiB @ 0x%p\n",
>> + size / 1024, virt_base);
>>
>> return 0;
>
> regards
> Philipp
>
--
With best wishes,
Vladimir
next prev parent reply other threads:[~2015-05-19 12:30 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-05-18 19:08 [PATCH v3 0/9] misc: sram: minor fixes and clean up Vladimir Zapolskiy
2015-05-18 19:08 ` [PATCH v3 1/9] misc: sram: fix enabled clock leak on error path Vladimir Zapolskiy
2015-05-19 10:41 ` Philipp Zabel
2015-05-19 13:11 ` Vladimir Zapolskiy
2015-05-20 11:30 ` Philipp Zabel
2015-05-24 20:12 ` Vladimir Zapolskiy
2015-05-26 8:54 ` Philipp Zabel
2015-05-29 11:31 ` Vladimir Zapolskiy
2015-05-29 15:38 ` Philipp Zabel
2015-05-18 19:08 ` [PATCH v3 2/9] misc: sram: fix device node reference leak on error Vladimir Zapolskiy
2015-05-18 19:08 ` [PATCH v3 3/9] misc: sram: use phys_addr_t instead of u32 for physical address Vladimir Zapolskiy
2015-05-19 10:38 ` Philipp Zabel
2015-05-19 12:30 ` Vladimir Zapolskiy [this message]
2015-05-18 19:08 ` [PATCH v3 4/9] misc: sram: bump error message level on unclean driver unbinding Vladimir Zapolskiy
2015-05-18 19:08 ` [PATCH v3 5/9] misc: sram: report correct SRAM pool size Vladimir Zapolskiy
2015-05-18 19:08 ` [PATCH v3 6/9] misc: sram: add private struct device and virt_base members Vladimir Zapolskiy
2015-05-18 19:08 ` [PATCH v3 7/9] misc: sram: simplify probe error path Vladimir Zapolskiy
2015-05-18 19:08 ` [PATCH v3 8/9] misc: sram: move reserved block logic out of probe function Vladimir Zapolskiy
2015-05-18 19:08 ` [PATCH v3 9/9] misc: sram: sort and clean up included headers Vladimir Zapolskiy
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=555B2CCE.50306@mentor.com \
--to=vladimir_zapolskiy@mentor.com \
--cc=arnd@arndb.de \
--cc=gregkh@linuxfoundation.org \
--cc=heiko@sntech.de \
--cc=linux-kernel@vger.kernel.org \
--cc=p.zabel@pengutronix.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.