All of lore.kernel.org
 help / color / mirror / Atom feed
From: Shunqian Zheng <shunqian.zheng@gmail.com>
To: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>,
	Stefan Wahren <stefan.wahren@i2se.com>
Cc: mark.rutland@arm.com, devicetree@vger.kernel.org,
	linux@arm.linux.org.uk, heiko@sntech.de, pawel.moll@arm.com,
	ijc+devicetree@hellion.org.uk, linus.walleij@linaro.org,
	linux-kernel@vger.kernel.org, linux-rockchip@lists.infradead.org,
	robh+dt@kernel.org, galak@codeaurora.org, matthias.bgg@gmail.com,
	Maxime Ripard <maxime.ripard@free-electrons.com>,
	jay.xu@rock-chips.com, linux-arm-kernel@lists.infradead.org,
	Caesar Wang <wxt@rock-chips.com>
Subject: Re: [PATCH v2 0/3] Add the efuse driver on rockchip platform
Date: Thu, 06 Aug 2015 09:10:00 +0800	[thread overview]
Message-ID: <55C2B3E8.2070000@gmail.com> (raw)
In-Reply-To: <55C0E42E.3060509@linaro.org>



On 2015年08月05日 00:11, Srinivas Kandagatla wrote:
> Hi Shunqian,
>
> Sorry for delay in reply, I was on Holidays..
>
> Thanks for testing.
>
> On 31/07/15 10:27, Shunqian Zheng wrote:
>>
>> 1. Without the following diff, `hexdump
>> /sys/bus/nvmem/devices/rockchip-efuse0/nvmem` is wrong with "INVALID
>> ARGUMENT":
>>
>> +++ b/drivers/nvmem/core.c
>> @@ -67,7 +67,7 @@ static ssize_t bin_attr_nvmem_read(struct file *filp,
>> struct kobject *kobj,
>>          int rc;
>>
>>          /* Stop the user from reading */
>> -       if (pos > nvmem->size)
>> +       if (pos > nvmem->size - 1)
>>                  return 0;
>
> Yes, this should have been something like this
> -       if (pos > nvmem->size)
> +       if (pos >= nvmem->size)
>                 return 0;
>
> We can send a fix on top of v9 once its merged.
>
>>
>>          if (pos + count > nvmem->size)
>>
>> RK3288-efuse has  32 x 8bit regs, in dts "reg = <0xffb40000 0x20>;"
>> Here is the message dump from nvmem_device:
>> [    2.158314] nvmem:
>> [    2.158314]           name (null)
>> [    2.158314]           stride 1
>> [    2.158314]           word_size 1
>> [    2.158314]           ncells 0
>> [    2.158314]           id 0
>> [    2.158314]           users 0
>> [    2.158314]           size 32
>> [    2.158314]           read_only 0
>>
>> Do you think there is a leak or I'm messing up ?
>>
>> 2. About the read operation, eFuse data can be read during device
>> probe() and cached, OR,
>>      read from eFuse when needed every time. I prefer the second one but
>> then, the clock of eFuse may be
>>      gated. So before/after reading I have to enable/disable clk like :
>>            devm_clk_get(dev, "hclk_efuse256");
>>      The trouble is I can't find a way to get the "dev" hander in :
>>            static int rockchip_efuse_read(void *context, const void
>> *reg, size_t reg_size, void *val, size_t val_size)
>>      I am appreciated if you can give some advice.
>
>
> May be you should use regmap_init_mmio_clk() instead of 
> regmap_init_mmio() it will take care of clks.
Thank you for you reply.
Although the regmap_init_mmio_clk() and it's series interface deal with 
the clks, but
MMIO uses its own regmap_bus{}, while the eFuse of RK3X need special 
read/write
callback functions.

I still can't find a good way to resolve this. Can you help?

Shunqian
>
>>      Or, do you think it's reasonable to add hooks before/after read in
>> nvmem/core.c like :
>>            +       before_read(dev, ...);
>>                     rc = regmap_raw_read(nvmem->regmap, pos, buf, 
>> count);
>>            +       after_read(dev, ...);
>>
>
>
>> 3. In the /sys/bus/nvmem/devices/rockchip-efuse0/, there are files:
>>           /sys/devices/platform/ffb40000.efuse/rockchip-efuse0 # ls
>>           nvmem      of_node    power      subsystem  uevent
>>      Do you have a plan to add the nvmem consumers to /sys/ in nvmem
>> framework?
> yes, Am waiting for the framework to be merged, I have plans to add 
> this feature.
>
>>      For example,  in dts defined the "cpu_leakage":
>>          efuse: efuse@ffb40000 {
>>                  compatible = "rockchip,rk3x-efuse";
>>                  reg = <0xffb40000 0x20>;
>>                  #address-cells = <1>;
>>                  #size-cells = <1>;
>>                  clocks = <&cru PCLK_EFUSE256>;
>>                  clock-names = "pclk_efuse_256";
>>
>>                  cpu_leakage: cpu_leakage {
>>                          reg = <0x17 0x1>;
>>                  };
>>          };
>>     Then nvmem exposes the "cpu_leakage" file in /sys which can be
>> read/write.
>
> --srini

WARNING: multiple messages have this Message-ID (diff)
From: shunqian.zheng@gmail.com (Shunqian Zheng)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v2 0/3] Add the efuse driver on rockchip platform
Date: Thu, 06 Aug 2015 09:10:00 +0800	[thread overview]
Message-ID: <55C2B3E8.2070000@gmail.com> (raw)
In-Reply-To: <55C0E42E.3060509@linaro.org>



On 2015?08?05? 00:11, Srinivas Kandagatla wrote:
> Hi Shunqian,
>
> Sorry for delay in reply, I was on Holidays..
>
> Thanks for testing.
>
> On 31/07/15 10:27, Shunqian Zheng wrote:
>>
>> 1. Without the following diff, `hexdump
>> /sys/bus/nvmem/devices/rockchip-efuse0/nvmem` is wrong with "INVALID
>> ARGUMENT":
>>
>> +++ b/drivers/nvmem/core.c
>> @@ -67,7 +67,7 @@ static ssize_t bin_attr_nvmem_read(struct file *filp,
>> struct kobject *kobj,
>>          int rc;
>>
>>          /* Stop the user from reading */
>> -       if (pos > nvmem->size)
>> +       if (pos > nvmem->size - 1)
>>                  return 0;
>
> Yes, this should have been something like this
> -       if (pos > nvmem->size)
> +       if (pos >= nvmem->size)
>                 return 0;
>
> We can send a fix on top of v9 once its merged.
>
>>
>>          if (pos + count > nvmem->size)
>>
>> RK3288-efuse has  32 x 8bit regs, in dts "reg = <0xffb40000 0x20>;"
>> Here is the message dump from nvmem_device:
>> [    2.158314] nvmem:
>> [    2.158314]           name (null)
>> [    2.158314]           stride 1
>> [    2.158314]           word_size 1
>> [    2.158314]           ncells 0
>> [    2.158314]           id 0
>> [    2.158314]           users 0
>> [    2.158314]           size 32
>> [    2.158314]           read_only 0
>>
>> Do you think there is a leak or I'm messing up ?
>>
>> 2. About the read operation, eFuse data can be read during device
>> probe() and cached, OR,
>>      read from eFuse when needed every time. I prefer the second one but
>> then, the clock of eFuse may be
>>      gated. So before/after reading I have to enable/disable clk like :
>>            devm_clk_get(dev, "hclk_efuse256");
>>      The trouble is I can't find a way to get the "dev" hander in :
>>            static int rockchip_efuse_read(void *context, const void
>> *reg, size_t reg_size, void *val, size_t val_size)
>>      I am appreciated if you can give some advice.
>
>
> May be you should use regmap_init_mmio_clk() instead of 
> regmap_init_mmio() it will take care of clks.
Thank you for you reply.
Although the regmap_init_mmio_clk() and it's series interface deal with 
the clks, but
MMIO uses its own regmap_bus{}, while the eFuse of RK3X need special 
read/write
callback functions.

I still can't find a good way to resolve this. Can you help?

Shunqian
>
>>      Or, do you think it's reasonable to add hooks before/after read in
>> nvmem/core.c like :
>>            +       before_read(dev, ...);
>>                     rc = regmap_raw_read(nvmem->regmap, pos, buf, 
>> count);
>>            +       after_read(dev, ...);
>>
>
>
>> 3. In the /sys/bus/nvmem/devices/rockchip-efuse0/, there are files:
>>           /sys/devices/platform/ffb40000.efuse/rockchip-efuse0 # ls
>>           nvmem      of_node    power      subsystem  uevent
>>      Do you have a plan to add the nvmem consumers to /sys/ in nvmem
>> framework?
> yes, Am waiting for the framework to be merged, I have plans to add 
> this feature.
>
>>      For example,  in dts defined the "cpu_leakage":
>>          efuse: efuse at ffb40000 {
>>                  compatible = "rockchip,rk3x-efuse";
>>                  reg = <0xffb40000 0x20>;
>>                  #address-cells = <1>;
>>                  #size-cells = <1>;
>>                  clocks = <&cru PCLK_EFUSE256>;
>>                  clock-names = "pclk_efuse_256";
>>
>>                  cpu_leakage: cpu_leakage {
>>                          reg = <0x17 0x1>;
>>                  };
>>          };
>>     Then nvmem exposes the "cpu_leakage" file in /sys which can be
>> read/write.
>
> --srini

  reply	other threads:[~2015-08-06  1:10 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-06-16  7:27 [PATCH v2 0/3] Add the efuse driver on rockchip platform Caesar Wang
2015-06-16  7:27 ` Caesar Wang
2015-06-16  7:27 ` Caesar Wang
2015-06-16  7:27 ` [PATCH v2 1/3] soc/rockchip: Add efuse bindings for Rockchip SoC efuse driver Caesar Wang
2015-06-16  7:27   ` Caesar Wang
2015-06-16  7:27 ` [PATCH v2 2/3] soc/rockchip: efuse: Add Rockchip SoC efuse support Caesar Wang
2015-06-16  7:27   ` Caesar Wang
2015-06-16  7:27 ` [PATCH v2 3/3] ARM: dts: Add RK3288 efuse node Caesar Wang
2015-06-16  7:27   ` Caesar Wang
2015-06-16  8:52 ` [PATCH v2 0/3] Add the efuse driver on rockchip platform Stefan Wahren
2015-06-16  8:52   ` Stefan Wahren
2015-06-16  9:21   ` Srinivas Kandagatla
2015-06-16  9:21     ` Srinivas Kandagatla
2015-06-16 10:06     ` Caesar Wang
2015-06-16 10:06       ` Caesar Wang
     [not found]       ` <557FF50C.10809-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
2015-06-16 10:54         ` Srinivas Kandagatla
2015-06-16 10:54           ` Srinivas Kandagatla
2015-06-16 10:54           ` Srinivas Kandagatla
     [not found]           ` <55800070.5030509-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
2015-06-18  7:05             ` Stefan Wahren
2015-06-18  7:05               ` Stefan Wahren
2015-06-18  7:05               ` Stefan Wahren
2015-06-18  8:29               ` Srinivas Kandagatla
2015-06-18  8:29                 ` Srinivas Kandagatla
     [not found]                 ` <5582816B.5020208-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
2015-06-18  9:08                   ` Caesar Wang
2015-06-18  9:08                     ` Caesar Wang
2015-06-18  9:08                     ` Caesar Wang
2015-07-31  9:27                 ` Shunqian Zheng
2015-07-31  9:27                   ` Shunqian Zheng
2015-08-04 16:11                   ` Srinivas Kandagatla
2015-08-04 16:11                     ` Srinivas Kandagatla
2015-08-06  1:10                     ` Shunqian Zheng [this message]
2015-08-06  1:10                       ` Shunqian Zheng

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=55C2B3E8.2070000@gmail.com \
    --to=shunqian.zheng@gmail.com \
    --cc=devicetree@vger.kernel.org \
    --cc=galak@codeaurora.org \
    --cc=heiko@sntech.de \
    --cc=ijc+devicetree@hellion.org.uk \
    --cc=jay.xu@rock-chips.com \
    --cc=linus.walleij@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-rockchip@lists.infradead.org \
    --cc=linux@arm.linux.org.uk \
    --cc=mark.rutland@arm.com \
    --cc=matthias.bgg@gmail.com \
    --cc=maxime.ripard@free-electrons.com \
    --cc=pawel.moll@arm.com \
    --cc=robh+dt@kernel.org \
    --cc=srinivas.kandagatla@linaro.org \
    --cc=stefan.wahren@i2se.com \
    --cc=wxt@rock-chips.com \
    /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.