From: Stephen Warren <swarren@wwwdotorg.org>
To: Peter De Schrijver <pdeschrijver@nvidia.com>
Cc: linux-arm-kernel@lists.infradead.org,
linux-tegra@vger.kernel.org, linux-kernel@vger.kernel.org,
Rob Landley <rob@landley.net>,
Thierry Reding <thierry.reding@gmail.com>,
Grant Likely <grant.likely@linaro.org>,
Rob Herring <robh+dt@kernel.org>,
Danny Huang <dahuang@nvidia.com>,
linux-doc@vger.kernel.org, devicetree@vger.kernel.org
Subject: Re: [PATCH v2 2/6] misc: fuse: Add efuse driver for Tegra
Date: Mon, 06 Jan 2014 13:32:24 -0700 [thread overview]
Message-ID: <52CB12D8.7000203@wwwdotorg.org> (raw)
In-Reply-To: <1387891931-9854-3-git-send-email-pdeschrijver@nvidia.com>
On 12/24/2013 06:32 AM, Peter De Schrijver wrote:
> Implement fuse driver for Tegra20, Tegra30, Tegra114 and Tegra124.
> diff --git a/drivers/misc/fuse/Kconfig b/drivers/misc/fuse/Kconfig
> +config FUSE_TEGRA
> + tristate "Tegra fuse supprt"
> + depends on ARCH_TEGRA && SYSFS
Since (I think) the Tegra-specific APIs this uses are stubbed if they
can't build, perhaps this should depend on "|| COMPILE_TEST" too?
> + help
> + This drivers provides read-only to the e-fuses in Tegra chips.
> + Parsing of the data is left to userspace.
> +
> + This driver can also be built as a module. If so, the module
> + will be called tegra_efuse.
> +endmenu
I'd expect a blank line before "endmenu" since there's one at the start
of the menu contents.
> diff --git a/drivers/misc/fuse/tegra/Makefile b/drivers/misc/fuse/tegra/Makefile
> +obj-y += fuse-tegra.o
> +obj-y += fuse-tegra30.o
> +obj-$(CONFIG_ARCH_TEGRA_2x_SOC) += fuse-tegra20.o
> +obj-$(CONFIG_ARCH_TEGRA_2x_SOC) += tegra20_speedo.o
> +obj-$(CONFIG_ARCH_TEGRA_3x_SOC) += tegra30_speedo.o
> +obj-$(CONFIG_ARCH_TEGRA_114_SOC) += tegra114_speedo.o
> +obj-$(CONFIG_ARCH_TEGRA_124_SOC) += tegra124_speedo.o
> diff --git a/drivers/misc/fuse/tegra/fuse-tegra20.c b/drivers/misc/fuse/tegra/fuse-tegra20.c
> +static int fuse_size;
I don't think that's used.
> +static u32 tegra20_fuse_readl(const unsigned int offset)
...
> + ret = tegra_apb_readl_using_dma(fuse_phys + FUSE_BEGIN + offset, &val);
Shouldn't this use the generic tegra_apb_readl(), so that it works
irrespective of whether the Tegra20 APB DMA driver is available?
> +static const struct of_device_id tegra20_fuse_of_match[] = {
> + { .compatible = "nvidia,tegra20-efuse" },
> +}
> +
> +MODULE_DEVICE_TABLE(of, tegra20_fuse_of_match);
You'd typically omit that blank line.
> +static int tegra_fuse_probe(struct platform_device *pdev)
> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> + fuse_phys = res->start;
Don't you need to error-check res here?
> + fuse_randomness();
If this is a driver, and particularly if this could be in a module, is
there any guarantee at all that fuse_randomness() gets called early
enough to be useful?>
> + platform_set_drvdata(pdev, NULL);
That seems pointless; if the drvdata isn't used, there's no need to set
it to anything in particular at all.
> + if (tegra_fuse_sysfs(&pdev->dev, FUSE_SIZE, tegra20_fuse_readl,
> + &sku_info))
Here (and also for fuse_randomness()), there's no verb in the function
name. Perhaps use tegra_fuse_create_sysfs() and fuse_add_randomness().
It wouldn't hurt to be consistent and use a tegra20_ prefix on all the
function names too.
> diff --git a/drivers/misc/fuse/tegra/fuse-tegra30.c b/drivers/misc/fuse/tegra/fuse-tegra30.c
> +u32 tegra30_fuse_readl(const unsigned int offset)
> + val = readl_relaxed(fuse_base + FUSE_BEGIN + offset);
If you aren't going to call tegra_apb_readl() here, I wonder if you
shouldn't rename tegra_apb_readl() as tegra20_apb_readl() to make it
obvious that the workaround isn't needed on all chips?
> + clk_disable_unprepare(fuse_clk);
Doesn't the use of readl_**relaxed**() above mean that the
clk_disable_unprepare() could turn off the clock before the fuse read
had completed, and hence hang the system?
> +static int tegra_fuse_probe(struct platform_device *pdev)
> + fuse_randomness();
Here, the same function name is used as in fuse-tegra20.c, which might
make debugging a bit more annoying.
> +MODULE_LICENSE("GPLv2");
s/GPLv2/GPL v2/ Perhaps the same in other files?
> diff --git a/drivers/misc/fuse/tegra/fuse.h b/drivers/misc/fuse/tegra/fuse.h
> +#ifdef CONFIG_ARCH_TEGRA_2x_SOC
> +void tegra20_init_speedo_data(struct tegra_sku_info *sku_info,
> + struct device *dev);
> +bool tegra20_spare_fuse(int bit);
> +#else
> +static inline void tegra20_init_speedo_data(struct tegra_sku_info *sku_info,
> + struct device *dev) {}
> +static inline bool tegra20_spare_fuse(int bit) {}
> +#endif
I suppose it doesn't hurt, but the Tegra20 functions don't need stubs
since they're only called from files that are only compiled for Tegra20.
But, I suppose it's fine to be consistent within this file and provide
stubs anyway.
WARNING: multiple messages have this Message-ID (diff)
From: swarren@wwwdotorg.org (Stephen Warren)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v2 2/6] misc: fuse: Add efuse driver for Tegra
Date: Mon, 06 Jan 2014 13:32:24 -0700 [thread overview]
Message-ID: <52CB12D8.7000203@wwwdotorg.org> (raw)
In-Reply-To: <1387891931-9854-3-git-send-email-pdeschrijver@nvidia.com>
On 12/24/2013 06:32 AM, Peter De Schrijver wrote:
> Implement fuse driver for Tegra20, Tegra30, Tegra114 and Tegra124.
> diff --git a/drivers/misc/fuse/Kconfig b/drivers/misc/fuse/Kconfig
> +config FUSE_TEGRA
> + tristate "Tegra fuse supprt"
> + depends on ARCH_TEGRA && SYSFS
Since (I think) the Tegra-specific APIs this uses are stubbed if they
can't build, perhaps this should depend on "|| COMPILE_TEST" too?
> + help
> + This drivers provides read-only to the e-fuses in Tegra chips.
> + Parsing of the data is left to userspace.
> +
> + This driver can also be built as a module. If so, the module
> + will be called tegra_efuse.
> +endmenu
I'd expect a blank line before "endmenu" since there's one at the start
of the menu contents.
> diff --git a/drivers/misc/fuse/tegra/Makefile b/drivers/misc/fuse/tegra/Makefile
> +obj-y += fuse-tegra.o
> +obj-y += fuse-tegra30.o
> +obj-$(CONFIG_ARCH_TEGRA_2x_SOC) += fuse-tegra20.o
> +obj-$(CONFIG_ARCH_TEGRA_2x_SOC) += tegra20_speedo.o
> +obj-$(CONFIG_ARCH_TEGRA_3x_SOC) += tegra30_speedo.o
> +obj-$(CONFIG_ARCH_TEGRA_114_SOC) += tegra114_speedo.o
> +obj-$(CONFIG_ARCH_TEGRA_124_SOC) += tegra124_speedo.o
> diff --git a/drivers/misc/fuse/tegra/fuse-tegra20.c b/drivers/misc/fuse/tegra/fuse-tegra20.c
> +static int fuse_size;
I don't think that's used.
> +static u32 tegra20_fuse_readl(const unsigned int offset)
...
> + ret = tegra_apb_readl_using_dma(fuse_phys + FUSE_BEGIN + offset, &val);
Shouldn't this use the generic tegra_apb_readl(), so that it works
irrespective of whether the Tegra20 APB DMA driver is available?
> +static const struct of_device_id tegra20_fuse_of_match[] = {
> + { .compatible = "nvidia,tegra20-efuse" },
> +}
> +
> +MODULE_DEVICE_TABLE(of, tegra20_fuse_of_match);
You'd typically omit that blank line.
> +static int tegra_fuse_probe(struct platform_device *pdev)
> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> + fuse_phys = res->start;
Don't you need to error-check res here?
> + fuse_randomness();
If this is a driver, and particularly if this could be in a module, is
there any guarantee at all that fuse_randomness() gets called early
enough to be useful?>
> + platform_set_drvdata(pdev, NULL);
That seems pointless; if the drvdata isn't used, there's no need to set
it to anything in particular at all.
> + if (tegra_fuse_sysfs(&pdev->dev, FUSE_SIZE, tegra20_fuse_readl,
> + &sku_info))
Here (and also for fuse_randomness()), there's no verb in the function
name. Perhaps use tegra_fuse_create_sysfs() and fuse_add_randomness().
It wouldn't hurt to be consistent and use a tegra20_ prefix on all the
function names too.
> diff --git a/drivers/misc/fuse/tegra/fuse-tegra30.c b/drivers/misc/fuse/tegra/fuse-tegra30.c
> +u32 tegra30_fuse_readl(const unsigned int offset)
> + val = readl_relaxed(fuse_base + FUSE_BEGIN + offset);
If you aren't going to call tegra_apb_readl() here, I wonder if you
shouldn't rename tegra_apb_readl() as tegra20_apb_readl() to make it
obvious that the workaround isn't needed on all chips?
> + clk_disable_unprepare(fuse_clk);
Doesn't the use of readl_**relaxed**() above mean that the
clk_disable_unprepare() could turn off the clock before the fuse read
had completed, and hence hang the system?
> +static int tegra_fuse_probe(struct platform_device *pdev)
> + fuse_randomness();
Here, the same function name is used as in fuse-tegra20.c, which might
make debugging a bit more annoying.
> +MODULE_LICENSE("GPLv2");
s/GPLv2/GPL v2/ Perhaps the same in other files?
> diff --git a/drivers/misc/fuse/tegra/fuse.h b/drivers/misc/fuse/tegra/fuse.h
> +#ifdef CONFIG_ARCH_TEGRA_2x_SOC
> +void tegra20_init_speedo_data(struct tegra_sku_info *sku_info,
> + struct device *dev);
> +bool tegra20_spare_fuse(int bit);
> +#else
> +static inline void tegra20_init_speedo_data(struct tegra_sku_info *sku_info,
> + struct device *dev) {}
> +static inline bool tegra20_spare_fuse(int bit) {}
> +#endif
I suppose it doesn't hurt, but the Tegra20 functions don't need stubs
since they're only called from files that are only compiled for Tegra20.
But, I suppose it's fine to be consistent within this file and provide
stubs anyway.
next prev parent reply other threads:[~2014-01-06 20:32 UTC|newest]
Thread overview: 71+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-12-24 13:32 [PATCH v2 0/6] efuse driver for Tegra Peter De Schrijver
2013-12-24 13:32 ` Peter De Schrijver
2013-12-24 13:32 ` Peter De Schrijver
[not found] ` <1387891931-9854-1-git-send-email-pdeschrijver-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2013-12-24 13:32 ` [PATCH v2 1/6] ARM: tegra: export apb dma readl/writel Peter De Schrijver
2013-12-24 13:32 ` Peter De Schrijver
2013-12-24 13:32 ` Peter De Schrijver
[not found] ` <1387891931-9854-2-git-send-email-pdeschrijver-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2014-01-06 20:07 ` Stephen Warren
2014-01-06 20:07 ` Stephen Warren
2014-01-06 20:07 ` Stephen Warren
[not found] ` <52CB0CFE.4070901-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
2014-01-07 12:54 ` Peter De Schrijver
2014-01-07 12:54 ` Peter De Schrijver
2014-01-07 12:54 ` Peter De Schrijver
2013-12-24 13:32 ` [PATCH v2 4/6] ARM: tegra: rework fuse.c Peter De Schrijver
2013-12-24 13:32 ` Peter De Schrijver
2013-12-24 13:32 ` Peter De Schrijver
2014-01-03 11:19 ` Alexandre Courbot
2014-01-03 11:19 ` Alexandre Courbot
2014-01-03 11:19 ` Alexandre Courbot
[not found] ` <1387891931-9854-5-git-send-email-pdeschrijver-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2014-01-06 20:50 ` Stephen Warren
2014-01-06 20:50 ` Stephen Warren
2014-01-06 20:50 ` Stephen Warren
[not found] ` <52CB1722.70306-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
2014-01-07 14:10 ` Peter De Schrijver
2014-01-07 14:10 ` Peter De Schrijver
2014-01-07 14:10 ` Peter De Schrijver
[not found] ` <20140107141004.GF26588-Rysk9IDjsxmJz7etNGeUX8VPkgjIgRvpAL8bYrjMMd8@public.gmane.org>
2014-01-07 20:47 ` Stephen Warren
2014-01-07 20:47 ` Stephen Warren
2014-01-07 20:47 ` Stephen Warren
[not found] ` <52CC67C9.9000704-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
2014-01-08 8:31 ` Peter De Schrijver
2014-01-08 8:31 ` Peter De Schrijver
2014-01-08 8:31 ` Peter De Schrijver
2013-12-24 13:32 ` [PATCH v2 2/6] misc: fuse: Add efuse driver for Tegra Peter De Schrijver
2013-12-24 13:32 ` Peter De Schrijver
2013-12-24 13:32 ` Peter De Schrijver
2014-01-06 20:32 ` Stephen Warren [this message]
2014-01-06 20:32 ` Stephen Warren
[not found] ` <52CB12D8.7000203-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
2014-01-07 14:05 ` Peter De Schrijver
2014-01-07 14:05 ` Peter De Schrijver
2014-01-07 14:05 ` Peter De Schrijver
[not found] ` <20140107140502.GE26588-Rysk9IDjsxmJz7etNGeUX8VPkgjIgRvpAL8bYrjMMd8@public.gmane.org>
2014-01-07 20:41 ` Stephen Warren
2014-01-07 20:41 ` Stephen Warren
2014-01-07 20:41 ` Stephen Warren
2013-12-24 13:32 ` [PATCH v2 3/6] ARM: tegra: Add efuse bindings Peter De Schrijver
2013-12-24 13:32 ` Peter De Schrijver
2013-12-24 13:32 ` Peter De Schrijver
[not found] ` <1387891931-9854-4-git-send-email-pdeschrijver-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2014-01-06 20:40 ` Stephen Warren
2014-01-06 20:40 ` Stephen Warren
2014-01-06 20:40 ` Stephen Warren
[not found] ` <52CB14D3.2060904-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
2014-01-08 13:39 ` Thierry Reding
2014-01-08 13:39 ` Thierry Reding
2014-01-08 13:39 ` Thierry Reding
[not found] ` <20140108133951.GD1592-AwZRO8vwLAwmlAP/+Wk3EA@public.gmane.org>
2014-01-08 18:50 ` Stephen Warren
2014-01-08 18:50 ` Stephen Warren
2014-01-08 18:50 ` Stephen Warren
[not found] ` <52CD9DFB.9010007-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
2014-01-08 20:05 ` Thierry Reding
2014-01-08 20:05 ` Thierry Reding
2014-01-08 20:05 ` Thierry Reding
2014-01-08 20:09 ` Thierry Reding
2014-01-08 20:09 ` Thierry Reding
2014-01-08 20:09 ` Thierry Reding
[not found] ` <20140108200946.GE1298-AwZRO8vwLAwmlAP/+Wk3EA@public.gmane.org>
2014-01-08 22:41 ` Stephen Warren
2014-01-08 22:41 ` Stephen Warren
2014-01-08 22:41 ` Stephen Warren
[not found] ` <52CDD430.3010508-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
2014-01-09 12:40 ` Thierry Reding
2014-01-09 12:40 ` Thierry Reding
2014-01-09 12:40 ` Thierry Reding
2013-12-24 13:32 ` [PATCH v2 5/6] ARM: Tegra: remove speedo files Peter De Schrijver
2013-12-24 13:32 ` Peter De Schrijver
2013-12-24 13:32 ` Peter De Schrijver
2013-12-24 13:32 ` [PATCH v2 6/6] misc: enable fuse drivers Peter De Schrijver
2013-12-24 13:32 ` Peter De Schrijver
2013-12-24 13:32 ` Peter De Schrijver
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=52CB12D8.7000203@wwwdotorg.org \
--to=swarren@wwwdotorg.org \
--cc=dahuang@nvidia.com \
--cc=devicetree@vger.kernel.org \
--cc=grant.likely@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-tegra@vger.kernel.org \
--cc=pdeschrijver@nvidia.com \
--cc=rob@landley.net \
--cc=robh+dt@kernel.org \
--cc=thierry.reding@gmail.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.