This series only make several funcitons return bool to improve
readability, no other funcitonal changes.
Yaowei Bai (5):
drivers/mtd: mtd_is_partition can be boolean
drivers/mtd: cfi_interleave_supported can be boolean
drivers/mtd: map_bankwidth_supported can be boolean
drivers/mtd: mtd_nand_has_bch can be boolean
drivers/mtd/nand: nand_opcode_8bits can be boolean
drivers/mtd/mtdpart.c | 6 +++---
include/linux/mtd/cfi.h | 6 +++---
include/linux/mtd/map.h | 6 +++---
include/linux/mtd/nand.h | 6 +++---
include/linux/mtd/nand_bch.h | 4 ++--
include/linux/mtd/partitions.h | 2 +-
6 files changed, 15 insertions(+), 15 deletions(-)
--
1.9.1
This patch makes mtd_is_partition return bool to improve
readability due to this particular function only using either
one or zero as its return value.
No functional change.
Signed-off-by: Yaowei Bai <[email protected]>
---
drivers/mtd/mtdpart.c | 6 +++---
include/linux/mtd/partitions.h | 2 +-
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/mtd/mtdpart.c b/drivers/mtd/mtdpart.c
index 10bf304..1aae1f4 100644
--- a/drivers/mtd/mtdpart.c
+++ b/drivers/mtd/mtdpart.c
@@ -829,15 +829,15 @@ void mtd_part_parser_cleanup(struct mtd_partitions *parts)
}
}
-int mtd_is_partition(const struct mtd_info *mtd)
+bool mtd_is_partition(const struct mtd_info *mtd)
{
struct mtd_part *part;
- int ispart = 0;
+ bool ispart = false;
mutex_lock(&mtd_partitions_mutex);
list_for_each_entry(part, &mtd_partitions, list)
if (&part->mtd == mtd) {
- ispart = 1;
+ ispart = true;
break;
}
mutex_unlock(&mtd_partitions_mutex);
diff --git a/include/linux/mtd/partitions.h b/include/linux/mtd/partitions.h
index 70736e1..042f3be 100644
--- a/include/linux/mtd/partitions.h
+++ b/include/linux/mtd/partitions.h
@@ -96,7 +96,7 @@ extern void deregister_mtd_parser(struct mtd_part_parser *parser);
module_driver(__mtd_part_parser, register_mtd_parser, \
deregister_mtd_parser)
-int mtd_is_partition(const struct mtd_info *mtd);
+bool mtd_is_partition(const struct mtd_info *mtd);
int mtd_add_partition(struct mtd_info *master, const char *name,
long long offset, long long length);
int mtd_del_partition(struct mtd_info *master, int partno);
--
1.9.1
This patch makes mtd_nand_has_bch return bool to improve readability
due to this particular function only using either one or zero as its return
value.
No functional change.
Signed-off-by: Yaowei Bai <[email protected]>
---
include/linux/mtd/nand_bch.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/include/linux/mtd/nand_bch.h b/include/linux/mtd/nand_bch.h
index fb0bc34..8778c79 100644
--- a/include/linux/mtd/nand_bch.h
+++ b/include/linux/mtd/nand_bch.h
@@ -16,7 +16,7 @@ struct nand_bch_control;
#if defined(CONFIG_MTD_NAND_ECC_BCH)
-static inline int mtd_nand_has_bch(void) { return 1; }
+static inline bool mtd_nand_has_bch(void) { return true; }
/*
* Calculate BCH ecc code
@@ -42,7 +42,7 @@ void nand_bch_free(struct nand_bch_control *nbc);
#else /* !CONFIG_MTD_NAND_ECC_BCH */
-static inline int mtd_nand_has_bch(void) { return 0; }
+static inline bool mtd_nand_has_bch(void) { return false; }
static inline int
nand_bch_calculate_ecc(struct mtd_info *mtd, const u_char *dat,
--
1.9.1
This patch makes nand_opcode_8bits return bool due to this
particular function only using either one or zero as its return
value.
No functional change.
Signed-off-by: Yaowei Bai <[email protected]>
---
include/linux/mtd/nand.h | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/include/linux/mtd/nand.h b/include/linux/mtd/nand.h
index bdd68e2..dd79eae 100644
--- a/include/linux/mtd/nand.h
+++ b/include/linux/mtd/nand.h
@@ -989,18 +989,18 @@ static inline bool nand_is_slc(struct nand_chip *chip)
* Check if the opcode's address should be sent only on the lower 8 bits
* @command: opcode to check
*/
-static inline int nand_opcode_8bits(unsigned int command)
+static inline bool nand_opcode_8bits(unsigned int command)
{
switch (command) {
case NAND_CMD_READID:
case NAND_CMD_PARAM:
case NAND_CMD_GET_FEATURES:
case NAND_CMD_SET_FEATURES:
- return 1;
+ return true;
default:
break;
}
- return 0;
+ return false;
}
/* return the supported JEDEC features. */
--
1.9.1
This patch makes map_bankwidth_supported return bool due to this
particular function only using either one or zero as its return
value.
No functional change.
Signed-off-by: Yaowei Bai <[email protected]>
---
include/linux/mtd/map.h | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/include/linux/mtd/map.h b/include/linux/mtd/map.h
index 58f3ba7..130a1b3 100644
--- a/include/linux/mtd/map.h
+++ b/include/linux/mtd/map.h
@@ -155,7 +155,7 @@ static inline int map_bankwidth(void *map)
#define MAX_MAP_BANKWIDTH 1
#endif
-static inline int map_bankwidth_supported(int w)
+static inline bool map_bankwidth_supported(int w)
{
switch (w) {
#ifdef CONFIG_MTD_MAP_BANK_WIDTH_1
@@ -176,10 +176,10 @@ static inline int map_bankwidth_supported(int w)
#ifdef CONFIG_MTD_MAP_BANK_WIDTH_32
case 32:
#endif
- return 1;
+ return true;
default:
- return 0;
+ return false;
}
}
--
1.9.1
This patch makes cfi_interleave_supported return bool due to this
particular function only using either one or zero as its return
value.
No functional change.
Signed-off-by: Yaowei Bai <[email protected]>
---
include/linux/mtd/cfi.h | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/include/linux/mtd/cfi.h b/include/linux/mtd/cfi.h
index 9b57a9b..68323bc 100644
--- a/include/linux/mtd/cfi.h
+++ b/include/linux/mtd/cfi.h
@@ -81,7 +81,7 @@ static inline int cfi_interleave(void *cfi)
}
#endif
-static inline int cfi_interleave_supported(int i)
+static inline bool cfi_interleave_supported(int i)
{
switch (i) {
#ifdef CONFIG_MTD_CFI_I1
@@ -96,10 +96,10 @@ static inline int cfi_interleave_supported(int i)
#ifdef CONFIG_MTD_CFI_I8
case 8:
#endif
- return 1;
+ return true;
default:
- return 0;
+ return false;
}
}
--
1.9.1
ccing: Brian and Richard
Hi Yao,
Is that really necessary? I am not sure how much benefit we can
achieve from this change.
Could you explain more?
Yang
On 03/25/2016 10:41 AM, Yaowei Bai wrote:
> This series only make several funcitons return bool to improve
> readability, no other funcitonal changes.
>
> Yaowei Bai (5):
> drivers/mtd: mtd_is_partition can be boolean
> drivers/mtd: cfi_interleave_supported can be boolean
> drivers/mtd: map_bankwidth_supported can be boolean
> drivers/mtd: mtd_nand_has_bch can be boolean
> drivers/mtd/nand: nand_opcode_8bits can be boolean
>
> drivers/mtd/mtdpart.c | 6 +++---
> include/linux/mtd/cfi.h | 6 +++---
> include/linux/mtd/map.h | 6 +++---
> include/linux/mtd/nand.h | 6 +++---
> include/linux/mtd/nand_bch.h | 4 ++--
> include/linux/mtd/partitions.h | 2 +-
> 6 files changed, 15 insertions(+), 15 deletions(-)
>
On Fri, Mar 25, 2016 at 10:54:51AM +0800, Dongsheng Yang wrote:
> ccing: Brian and Richard
>
> Hi Yao,
> Is that really necessary? I am not sure how much benefit we can
> achieve from this change.
> Could you explain more?
Yes, according to these functions' name, a boolean return value is more
suitable and matchable.
Also personally think this change maybe benfit function's return value
storage in the stack when called on certain architectures.
>
> Yang
>
> On 03/25/2016 10:41 AM, Yaowei Bai wrote:
> >This series only make several funcitons return bool to improve
> >readability, no other funcitonal changes.
> >
> >Yaowei Bai (5):
> > drivers/mtd: mtd_is_partition can be boolean
> > drivers/mtd: cfi_interleave_supported can be boolean
> > drivers/mtd: map_bankwidth_supported can be boolean
> > drivers/mtd: mtd_nand_has_bch can be boolean
> > drivers/mtd/nand: nand_opcode_8bits can be boolean
> >
> > drivers/mtd/mtdpart.c | 6 +++---
> > include/linux/mtd/cfi.h | 6 +++---
> > include/linux/mtd/map.h | 6 +++---
> > include/linux/mtd/nand.h | 6 +++---
> > include/linux/mtd/nand_bch.h | 4 ++--
> > include/linux/mtd/partitions.h | 2 +-
> > 6 files changed, 15 insertions(+), 15 deletions(-)
> >
>
Hi Yao,
On Fri, 25 Mar 2016 14:31:53 +0800
Yaowei Bai <[email protected]> wrote:
> On Fri, Mar 25, 2016 at 10:54:51AM +0800, Dongsheng Yang wrote:
> > ccing: Brian and Richard
> >
> > Hi Yao,
> > Is that really necessary? I am not sure how much benefit we can
> > achieve from this change.
> > Could you explain more?
>
> Yes, according to these functions' name, a boolean return value is more
> suitable and matchable.
>
> Also personally think this change maybe benfit function's return value
> storage in the stack when called on certain architectures.
At least be honest, and say this is for your patchcount statistics :P.
I'm fine taking the NAND related ones, but please, next time find
something more useful to submit.
Best Regards,
Boris
>
> >
> > Yang
> >
> > On 03/25/2016 10:41 AM, Yaowei Bai wrote:
> > >This series only make several funcitons return bool to improve
> > >readability, no other funcitonal changes.
> > >
> > >Yaowei Bai (5):
> > > drivers/mtd: mtd_is_partition can be boolean
> > > drivers/mtd: cfi_interleave_supported can be boolean
> > > drivers/mtd: map_bankwidth_supported can be boolean
> > > drivers/mtd: mtd_nand_has_bch can be boolean
> > > drivers/mtd/nand: nand_opcode_8bits can be boolean
> > >
> > > drivers/mtd/mtdpart.c | 6 +++---
> > > include/linux/mtd/cfi.h | 6 +++---
> > > include/linux/mtd/map.h | 6 +++---
> > > include/linux/mtd/nand.h | 6 +++---
> > > include/linux/mtd/nand_bch.h | 4 ++--
> > > include/linux/mtd/partitions.h | 2 +-
> > > 6 files changed, 15 insertions(+), 15 deletions(-)
> > >
> >
>
>
--
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
Am 25.03.2016 um 07:31 schrieb Yaowei Bai:
> On Fri, Mar 25, 2016 at 10:54:51AM +0800, Dongsheng Yang wrote:
>> ccing: Brian and Richard
>>
>> Hi Yao,
>> Is that really necessary? I am not sure how much benefit we can
>> achieve from this change.
>> Could you explain more?
>
> Yes, according to these functions' name, a boolean return value is more
> suitable and matchable.
>
> Also personally think this change maybe benfit function's return value
> storage in the stack when called on certain architectures.
On which archs? And what exactly is the benefit?
I agree that bool might be a better choice for new functions
but here you're touching existing and working(!) code.
The only outcome is git history pollution that makes git blame
less efficient.
Thanks,
//richard
On Fri, Mar 25, 2016 at 08:57:59AM +0100, Richard Weinberger wrote:
> Am 25.03.2016 um 07:31 schrieb Yaowei Bai:
> > On Fri, Mar 25, 2016 at 10:54:51AM +0800, Dongsheng Yang wrote:
> >> ccing: Brian and Richard
> >>
> >> Hi Yao,
> >> Is that really necessary? I am not sure how much benefit we can
> >> achieve from this change.
> >> Could you explain more?
> >
> > Yes, according to these functions' name, a boolean return value is more
> > suitable and matchable.
> >
> > Also personally think this change maybe benfit function's return value
> > storage in the stack when called on certain architectures.
>
> On which archs? And what exactly is the benefit?
> I agree that bool might be a better choice for new functions
> but here you're touching existing and working(!) code.
> The only outcome is git history pollution that makes git blame
> less efficient.
Working code doesn't mean perfect code. :-)
I still think this's a helpful change even though it's small, but
you make the decision to merge or drop it.
>
> Thanks,
> //richard
>
On Fri, Mar 25, 2016 at 08:51:55AM +0100, Boris Brezillon wrote:
> Hi Yao,
>
> On Fri, 25 Mar 2016 14:31:53 +0800
> Yaowei Bai <[email protected]> wrote:
>
> > On Fri, Mar 25, 2016 at 10:54:51AM +0800, Dongsheng Yang wrote:
> > > ccing: Brian and Richard
> > >
> > > Hi Yao,
> > > Is that really necessary? I am not sure how much benefit we can
> > > achieve from this change.
> > > Could you explain more?
> >
> > Yes, according to these functions' name, a boolean return value is more
> > suitable and matchable.
> >
> > Also personally think this change maybe benfit function's return value
> > storage in the stack when called on certain architectures.
>
> At least be honest, and say this is for your patchcount statistics :P.
> I'm fine taking the NAND related ones, but please, next time find
> something more useful to submit.
That's very nice of you, thanks.
>
> Best Regards,
>
> Boris
>
> >
> > >
> > > Yang
> > >
> > > On 03/25/2016 10:41 AM, Yaowei Bai wrote:
> > > >This series only make several funcitons return bool to improve
> > > >readability, no other funcitonal changes.
> > > >
> > > >Yaowei Bai (5):
> > > > drivers/mtd: mtd_is_partition can be boolean
> > > > drivers/mtd: cfi_interleave_supported can be boolean
> > > > drivers/mtd: map_bankwidth_supported can be boolean
> > > > drivers/mtd: mtd_nand_has_bch can be boolean
> > > > drivers/mtd/nand: nand_opcode_8bits can be boolean
> > > >
> > > > drivers/mtd/mtdpart.c | 6 +++---
> > > > include/linux/mtd/cfi.h | 6 +++---
> > > > include/linux/mtd/map.h | 6 +++---
> > > > include/linux/mtd/nand.h | 6 +++---
> > > > include/linux/mtd/nand_bch.h | 4 ++--
> > > > include/linux/mtd/partitions.h | 2 +-
> > > > 6 files changed, 15 insertions(+), 15 deletions(-)
> > > >
> > >
> >
> >
>
>
>
> --
> Boris Brezillon, Free Electrons
> Embedded Linux and Kernel engineering
> http://free-electrons.com
On Fri, 25 Mar 2016 08:57:59 +0100
Richard Weinberger <[email protected]> wrote:
> Am 25.03.2016 um 07:31 schrieb Yaowei Bai:
> > On Fri, Mar 25, 2016 at 10:54:51AM +0800, Dongsheng Yang wrote:
> >> ccing: Brian and Richard
> >>
> >> Hi Yao,
> >> Is that really necessary? I am not sure how much benefit we can
> >> achieve from this change.
> >> Could you explain more?
> >
> > Yes, according to these functions' name, a boolean return value is more
> > suitable and matchable.
> >
> > Also personally think this change maybe benfit function's return value
> > storage in the stack when called on certain architectures.
>
> On which archs? And what exactly is the benefit?
> I agree that bool might be a better choice for new functions
> but here you're touching existing and working(!) code.
> The only outcome is git history pollution that makes git blame
> less efficient.
Indeed, you raised a good point. Having useless changes pollute git
blame output may be problematic. Not sure I want to apply those patches
anymore :-/.
Anyway, Yao, I'm sure you can find other usefull things to contribute.
--
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
On Fri, Mar 25, 2016 at 09:58:21AM +0100, Boris Brezillon wrote:
> On Fri, 25 Mar 2016 08:57:59 +0100
> Richard Weinberger <[email protected]> wrote:
>
> > Am 25.03.2016 um 07:31 schrieb Yaowei Bai:
> > > On Fri, Mar 25, 2016 at 10:54:51AM +0800, Dongsheng Yang wrote:
> > >> ccing: Brian and Richard
> > >>
> > >> Hi Yao,
> > >> Is that really necessary? I am not sure how much benefit we can
> > >> achieve from this change.
> > >> Could you explain more?
> > >
> > > Yes, according to these functions' name, a boolean return value is more
> > > suitable and matchable.
> > >
> > > Also personally think this change maybe benfit function's return value
> > > storage in the stack when called on certain architectures.
> >
> > On which archs? And what exactly is the benefit?
> > I agree that bool might be a better choice for new functions
> > but here you're touching existing and working(!) code.
> > The only outcome is git history pollution that makes git blame
> > less efficient.
>
> Indeed, you raised a good point. Having useless changes pollute git
> blame output may be problematic. Not sure I want to apply those patches
> anymore :-/.
>
> Anyway, Yao, I'm sure you can find other usefull things to contribute.
OK, thanks for reviewing.
>
> --
> Boris Brezillon, Free Electrons
> Embedded Linux and Kernel engineering
> http://free-electrons.com