struct device is declared at 133rd line.
The declaration here is unnecessary. Remove it.
Signed-off-by: Wan Jiabing <[email protected]>
---
include/linux/libnvdimm.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/include/linux/libnvdimm.h b/include/linux/libnvdimm.h
index 01f251b6e36c..89b69e645ac7 100644
--- a/include/linux/libnvdimm.h
+++ b/include/linux/libnvdimm.h
@@ -141,7 +141,6 @@ static inline void __iomem *devm_nvdimm_ioremap(struct device *dev,
struct nvdimm_bus;
struct module;
-struct device;
struct nd_blk_region;
struct nd_blk_region_desc {
int (*enable)(struct nvdimm_bus *nvdimm_bus, struct device *dev);
--
2.25.1
On Mon, Apr 19, 2021 at 07:27:25PM +0800, Wan Jiabing wrote:
> struct device is declared at 133rd line.
> The declaration here is unnecessary. Remove it.
>
> Signed-off-by: Wan Jiabing <[email protected]>
> ---
> include/linux/libnvdimm.h | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/include/linux/libnvdimm.h b/include/linux/libnvdimm.h
> index 01f251b6e36c..89b69e645ac7 100644
> --- a/include/linux/libnvdimm.h
> +++ b/include/linux/libnvdimm.h
> @@ -141,7 +141,6 @@ static inline void __iomem *devm_nvdimm_ioremap(struct device *dev,
>
> struct nvdimm_bus;
> struct module;
> -struct device;
> struct nd_blk_region;
What is the coding style preference for pre-declarations like this? Should
they be placed at the top of the file?
The patch is reasonable but if the intent is to declare right before use for
clarity, both devm_nvdimm_memremap() and nd_blk_region_desc() use struct
device. So perhaps this duplicate is on purpose?
Ira
> struct nd_blk_region_desc {
> int (*enable)(struct nvdimm_bus *nvdimm_bus, struct device *dev);
> --
> 2.25.1
>
>On Mon, Apr 19, 2021 at 07:27:25PM +0800, Wan Jiabing wrote:>> struct device is declared at 133rd line.
>> The declaration here is unnecessary. Remove it.
>>
>> Signed-off-by: Wan Jiabing <[email protected]>
>> ---
>> include/linux/libnvdimm.h | 1 -
>> 1 file changed, 1 deletion(-)
>>
>> diff --git a/include/linux/libnvdimm.h b/include/linux/libnvdimm.h
>> index 01f251b6e36c..89b69e645ac7 100644
>> --- a/include/linux/libnvdimm.h
>> +++ b/include/linux/libnvdimm.h
>> @@ -141,7 +141,6 @@ static inline void __iomem *devm_nvdimm_ioremap(struct device *dev,
>>
>> struct nvdimm_bus;
>> struct module;
>> -struct device;
>> struct nd_blk_region;
>
>What is the coding style preference for pre-declarations like this? Should
>they be placed at the top of the file?
>
>The patch is reasonable but if the intent is to declare right before use for
>clarity, both devm_nvdimm_memremap() and nd_blk_region_desc() use struct
>device. So perhaps this duplicate is on purpose?
>
>Ira
OK, my script just catch this duplicate.
And I will report the duplicate if there is no MACRO dependence.
But I hadn't thought of whether the duplicate is a prompt on purpose.
Sorry.
Thanks for your reply.
Wan Jiabing
>> struct nd_blk_region_desc {
>> int (*enable)(struct nvdimm_bus *nvdimm_bus, struct device *dev);
>> --
>> 2.25.1
>>
Hi Ira,
Ira Weiny <[email protected]> writes:
> On Mon, Apr 19, 2021 at 07:27:25PM +0800, Wan Jiabing wrote:
>> struct device is declared at 133rd line.
>> The declaration here is unnecessary. Remove it.
>>
>> Signed-off-by: Wan Jiabing <[email protected]>
>> ---
>> include/linux/libnvdimm.h | 1 -
>> 1 file changed, 1 deletion(-)
>>
>> diff --git a/include/linux/libnvdimm.h b/include/linux/libnvdimm.h
>> index 01f251b6e36c..89b69e645ac7 100644
>> --- a/include/linux/libnvdimm.h
>> +++ b/include/linux/libnvdimm.h
>> @@ -141,7 +141,6 @@ static inline void __iomem *devm_nvdimm_ioremap(struct device *dev,
>>
>> struct nvdimm_bus;
>> struct module;
>> -struct device;
>> struct nd_blk_region;
>
> What is the coding style preference for pre-declarations like this? Should
> they be placed at the top of the file?
>
> The patch is reasonable but if the intent is to declare right before use for
> clarity, both devm_nvdimm_memremap() and nd_blk_region_desc() use struct
> device. So perhaps this duplicate is on purpose?
There are other struct device usage much later in the file, which doesn't have
any pre-declarations for struct device. So I assume this might not be on
purpose :-)
On a side note, types.h can also be removed, since it's already included in
kernel.h.
Santosh
>
> Ira
>
>> struct nd_blk_region_desc {
>> int (*enable)(struct nvdimm_bus *nvdimm_bus, struct device *dev);
>> --
>> 2.25.1
>>
> _______________________________________________
> Linux-nvdimm mailing list -- [email protected]
> To unsubscribe send an email to [email protected]
On Tue, Apr 20, 2021 at 6:39 AM Santosh Sivaraj <[email protected]> wrote:
>
> Hi Ira,
>
> Ira Weiny <[email protected]> writes:
>
> > On Mon, Apr 19, 2021 at 07:27:25PM +0800, Wan Jiabing wrote:
> >> struct device is declared at 133rd line.
> >> The declaration here is unnecessary. Remove it.
> >>
> >> Signed-off-by: Wan Jiabing <[email protected]>
> >> ---
> >> include/linux/libnvdimm.h | 1 -
> >> 1 file changed, 1 deletion(-)
> >>
> >> diff --git a/include/linux/libnvdimm.h b/include/linux/libnvdimm.h
> >> index 01f251b6e36c..89b69e645ac7 100644
> >> --- a/include/linux/libnvdimm.h
> >> +++ b/include/linux/libnvdimm.h
> >> @@ -141,7 +141,6 @@ static inline void __iomem *devm_nvdimm_ioremap(struct device *dev,
> >>
> >> struct nvdimm_bus;
> >> struct module;
> >> -struct device;
> >> struct nd_blk_region;
> >
> > What is the coding style preference for pre-declarations like this? Should
> > they be placed at the top of the file?
> >
> > The patch is reasonable but if the intent is to declare right before use for
> > clarity, both devm_nvdimm_memremap() and nd_blk_region_desc() use struct
> > device. So perhaps this duplicate is on purpose?
>
> There are other struct device usage much later in the file, which doesn't have
> any pre-declarations for struct device. So I assume this might not be on
> purpose :-)
Yeah, I believe it was just code movement and the duplicate was
inadvertently introduced. Patch looks ok to me.
>
> On a side note, types.h can also be removed, since it's already included in
> kernel.h.
That I don't necessarily agree with, it just makes future header
reworks more fraught for not much benefit.