Re: [PATCH 5/6] staging: pi433: Rename enum dataMode in rf69_enum.h

[Marcus Wolf]

Am 04.12.2017 um 21:56 schrieb Dan Carpenter:

On Mon, Dec 04, 2017 at 09:31:06PM +0200, Marcus Wolf wrote:

Then it might be, that DATAMODUL_MODE_PACKET might need an other value.


That's future code so we can delete that sentence for now.


With the rule above, you are absolutely right. But we now spend time, to
remove an currently non necessary feature ("double layer"), which will take
time to re-introduce as soon, as someone wants to support a second chip.
Isn't that double-work and a thus a pitty?



It is what it is...  In the kernel we insist all code have a user right
now when it's merged.  Unused code or future code is deleted.  We hate
abstraction layers.  Everyone argues that their abstraction layer is
different and good but kernel devs instinctively hate abstraction.

To be honest, in the kernel we do do a lot of work twice.  I made people
redo 9 quite large patches for this pi4333 driver today.  And they're
probably going end up conflicting and have to be redone again...  :/
That does suck.  I don't know what to do about it.

In my view it helps that people sending patches don't ever have to worry
about future code and we can focus on what exists now.  Greg will never
reject code for "future reasons" unless the future is almost right away
like tomorrow or maybe the next day.

regards,
dan carpenter



Hi Dan,

I am self employed and controling two small companies. For me it is very 
important to do efficient work - otherwise the 24 hours of a day are too 
short to get my work done, even if I include the night.


The goal of most projects (my own, as well as my customers) is very 
clear, but normaly you are not able to reach it in one pass. Therefore 
projects are split up in parts and try to release parts, to be on market 
earlier.
No one would accept, if I would optimise a software for a current 
release in a way, that I close doors for the final goal.


So I agree: We can't change the rules and have to take them as they are.

But if I read your lines, it's shaking me. I observed this sending the 
patch over and over again and it realy bugs me. Not beacause it might be 
boring, mainly because for me it feels like a huge waste of time - time 
I simply don't have.
Same applies to removing stuff, when I already now, (at least for my 
products) I will need it in future.


Maybe controlling a straup, developing fancy new products, the market 
likes to have (and in a time, the market is accepting you to present 
them) and contributing to the kernel need that different kind of mind 
set, that it's dam hard to do both at the same time.


Cheers,
Marcus

Re: [PATCH 5/6] staging: pi433: Rename enum dataMode in rf69_enum.h

[Marcus Wolf]

Am 04.12.2017 um 21:56 schrieb Dan Carpenter:

On Mon, Dec 04, 2017 at 09:31:06PM +0200, Marcus Wolf wrote:

Then it might be, that DATAMODUL_MODE_PACKET might need an other value.


That's future code so we can delete that sentence for now.


With the rule above, you are absolutely right. But we now spend time, to
remove an currently non necessary feature ("double layer"), which will take
time to re-introduce as soon, as someone wants to support a second chip.
Isn't that double-work and a thus a pitty?



It is what it is...  In the kernel we insist all code have a user right
now when it's merged.  Unused code or future code is deleted.  We hate
abstraction layers.  Everyone argues that their abstraction layer is
different and good but kernel devs instinctively hate abstraction.

To be honest, in the kernel we do do a lot of work twice.  I made people
redo 9 quite large patches for this pi4333 driver today.  And they're
probably going end up conflicting and have to be redone again...  :/
That does suck.  I don't know what to do about it.

In my view it helps that people sending patches don't ever have to worry
about future code and we can focus on what exists now.  Greg will never
reject code for "future reasons" unless the future is almost right away
like tomorrow or maybe the next day.

regards,
dan carpenter



Hi Dan,

I am self employed and controling two small companies. For me it is very 
important to do efficient work - otherwise the 24 hours of a day are too 
short to get my work done, even if I include the night.


The goal of most projects (my own, as well as my customers) is very 
clear, but normaly you are not able to reach it in one pass. Therefore 
projects are split up in parts and try to release parts, to be on market 
earlier.
No one would accept, if I would optimise a software for a current 
release in a way, that I close doors for the final goal.


So I agree: We can't change the rules and have to take them as they are.

But if I read your lines, it's shaking me. I observed this sending the 
patch over and over again and it realy bugs me. Not beacause it might be 
boring, mainly because for me it feels like a huge waste of time - time 
I simply don't have.
Same applies to removing stuff, when I already now, (at least for my 
products) I will need it in future.


Maybe controlling a straup, developing fancy new products, the market 
likes to have (and in a time, the market is accepting you to present 
them) and contributing to the kernel need that different kind of mind 
set, that it's dam hard to do both at the same time.


Cheers,
Marcus

Re: [PATCH 5/6] staging: pi433: Rename enum dataMode in rf69_enum.h

[Dan Carpenter]

On Mon, Dec 04, 2017 at 09:31:06PM +0200, Marcus Wolf wrote:
> > > Then it might be, that DATAMODUL_MODE_PACKET might need an other value.
> > 
> > That's future code so we can delete that sentence for now.
> 
> With the rule above, you are absolutely right. But we now spend time, to
> remove an currently non necessary feature ("double layer"), which will take
> time to re-introduce as soon, as someone wants to support a second chip.
> Isn't that double-work and a thus a pitty?
> 

It is what it is...  In the kernel we insist all code have a user right
now when it's merged.  Unused code or future code is deleted.  We hate
abstraction layers.  Everyone argues that their abstraction layer is
different and good but kernel devs instinctively hate abstraction.

To be honest, in the kernel we do do a lot of work twice.  I made people
redo 9 quite large patches for this pi4333 driver today.  And they're
probably going end up conflicting and have to be redone again...  :/
That does suck.  I don't know what to do about it.

In my view it helps that people sending patches don't ever have to worry
about future code and we can focus on what exists now.  Greg will never
reject code for "future reasons" unless the future is almost right away
like tomorrow or maybe the next day.

regards,
dan carpenter

Re: [PATCH 5/6] staging: pi433: Rename enum dataMode in rf69_enum.h

[Dan Carpenter]

On Mon, Dec 04, 2017 at 09:31:06PM +0200, Marcus Wolf wrote:
> > > Then it might be, that DATAMODUL_MODE_PACKET might need an other value.
> > 
> > That's future code so we can delete that sentence for now.
> 
> With the rule above, you are absolutely right. But we now spend time, to
> remove an currently non necessary feature ("double layer"), which will take
> time to re-introduce as soon, as someone wants to support a second chip.
> Isn't that double-work and a thus a pitty?
> 

It is what it is...  In the kernel we insist all code have a user right
now when it's merged.  Unused code or future code is deleted.  We hate
abstraction layers.  Everyone argues that their abstraction layer is
different and good but kernel devs instinctively hate abstraction.

To be honest, in the kernel we do do a lot of work twice.  I made people
redo 9 quite large patches for this pi4333 driver today.  And they're
probably going end up conflicting and have to be redone again...  :/
That does suck.  I don't know what to do about it.

In my view it helps that people sending patches don't ever have to worry
about future code and we can focus on what exists now.  Greg will never
reject code for "future reasons" unless the future is almost right away
like tomorrow or maybe the next day.

regards,
dan carpenter

Re: [PATCH 5/6] staging: pi433: Rename enum dataMode in rf69_enum.h

[Marcus Wolf]

Second there might be the idea of supporting different chips in the future
(I already thought about).


Linux style is never to write code for the future.


Ok. I didn't know.
To be honest, I already started writing code, also supporting the rf12 
some time ago, thus programming a rfxx.c, but never finished, due to 
lack of time.

For getting stuff started, I need to focus on rf69 and pi433.

A few monthes ago, Hope RF (the producer of those chips) proposed me a 
new chip (can't remember the number - maybe 95), that also supports 
loraWan. Seems like there will be even more interesting chips coming up, 
that could be controlled with a similar interface implementation.



Then it might be, that DATAMODUL_MODE_PACKET might need an other value.


That's future code so we can delete that sentence for now.


With the rule above, you are absolutely right. But we now spend time, to 
remove an currently non necessary feature ("double layer"), which will 
take time to re-introduce as soon, as someone wants to support a second 
chip.

Isn't that double-work and a thus a pitty?

Cheers,
Marcus

Re: [PATCH 5/6] staging: pi433: Rename enum dataMode in rf69_enum.h

[Marcus Wolf]

Second there might be the idea of supporting different chips in the future
(I already thought about).


Linux style is never to write code for the future.


Ok. I didn't know.
To be honest, I already started writing code, also supporting the rf12 
some time ago, thus programming a rfxx.c, but never finished, due to 
lack of time.

For getting stuff started, I need to focus on rf69 and pi433.

A few monthes ago, Hope RF (the producer of those chips) proposed me a 
new chip (can't remember the number - maybe 95), that also supports 
loraWan. Seems like there will be even more interesting chips coming up, 
that could be controlled with a similar interface implementation.



Then it might be, that DATAMODUL_MODE_PACKET might need an other value.


That's future code so we can delete that sentence for now.


With the rule above, you are absolutely right. But we now spend time, to 
remove an currently non necessary feature ("double layer"), which will 
take time to re-introduce as soon, as someone wants to support a second 
chip.

Isn't that double-work and a thus a pitty?

Cheers,
Marcus

Re: [PATCH 5/6] staging: pi433: Rename enum dataMode in rf69_enum.h

[Dan Carpenter]

On Mon, Dec 04, 2017 at 09:12:52PM +0200, Marcus Wolf wrote:
> 
> 
> Am 04.12.2017 um 12:24 schrieb Dan Carpenter:
> > On Sun, Dec 03, 2017 at 04:17:25PM +0100, Simon Sandström wrote:
> > > Renames enum dataMode and its values packet, continuous, continuousNoSync
> > > to enum data_mode and PACKET, CONTINUOUS, CONTINUOUS_NO_SYNC. Fixes
> > > checkpatch.pl warnings: "Avoid CamelCase: , ".
> > 
> > These names are too generic.  Delete them.  Use DATAMODUL_MODE_PACKET
> > and friends directly.
> > 
> > int rf69_set_data_mode(struct spi_device *spi, u8 val)
> > {
> > return WRITE_REG(REG_DATAMODUL, (READ_REG(REG_DATAMODUL) & 
> > ~MASK_DATAMODUL_MODE) | val);
> > }
> > 
> > Only DATAMODUL_MODE_PACKET is ever used.  There is no need to validate
> > the parameters.
> > 
> > regards,
> > dan carpenter
> > 
> 
> Hi Dan, hi Simon,
> 
> like I wrote a few days ago to Marcin Ciupak, I see two disadvantages in
> doing so.
> 
> If you want to go that way, you - as far as I believe - need to alter the
> values in rf69_enum.h, so they carry the corresponding values from
> rf69_reg.h. To avoid confusion, you will need to remove the values from
> rf69_reg.h.
> But then you have to keep track of two files (enum.h and reg.h), if you want
> to further develop register access stuff. I would prefer to keep all
> chip/register related values at the same place.

In my mind we were just deleting one of these not keeping them in sync.

> 
> Second there might be the idea of supporting different chips in the future
> (I already thought about).

Linux style is never to write code for the future.


> Then it might be, that DATAMODUL_MODE_PACKET might need an other value.

That's future code so we can delete that sentence for now.

> Therefore, I introduced the "double layer" - enums as labels for the user
> space and defines, containing the values, for the register access.

No.  We don't do abstraction layers.

regards,
dan carpenter

Re: [PATCH 5/6] staging: pi433: Rename enum dataMode in rf69_enum.h

[Dan Carpenter]

On Mon, Dec 04, 2017 at 09:12:52PM +0200, Marcus Wolf wrote:
> 
> 
> Am 04.12.2017 um 12:24 schrieb Dan Carpenter:
> > On Sun, Dec 03, 2017 at 04:17:25PM +0100, Simon Sandström wrote:
> > > Renames enum dataMode and its values packet, continuous, continuousNoSync
> > > to enum data_mode and PACKET, CONTINUOUS, CONTINUOUS_NO_SYNC. Fixes
> > > checkpatch.pl warnings: "Avoid CamelCase: , ".
> > 
> > These names are too generic.  Delete them.  Use DATAMODUL_MODE_PACKET
> > and friends directly.
> > 
> > int rf69_set_data_mode(struct spi_device *spi, u8 val)
> > {
> > return WRITE_REG(REG_DATAMODUL, (READ_REG(REG_DATAMODUL) & 
> > ~MASK_DATAMODUL_MODE) | val);
> > }
> > 
> > Only DATAMODUL_MODE_PACKET is ever used.  There is no need to validate
> > the parameters.
> > 
> > regards,
> > dan carpenter
> > 
> 
> Hi Dan, hi Simon,
> 
> like I wrote a few days ago to Marcin Ciupak, I see two disadvantages in
> doing so.
> 
> If you want to go that way, you - as far as I believe - need to alter the
> values in rf69_enum.h, so they carry the corresponding values from
> rf69_reg.h. To avoid confusion, you will need to remove the values from
> rf69_reg.h.
> But then you have to keep track of two files (enum.h and reg.h), if you want
> to further develop register access stuff. I would prefer to keep all
> chip/register related values at the same place.

In my mind we were just deleting one of these not keeping them in sync.

> 
> Second there might be the idea of supporting different chips in the future
> (I already thought about).

Linux style is never to write code for the future.


> Then it might be, that DATAMODUL_MODE_PACKET might need an other value.

That's future code so we can delete that sentence for now.

> Therefore, I introduced the "double layer" - enums as labels for the user
> space and defines, containing the values, for the register access.

No.  We don't do abstraction layers.

regards,
dan carpenter

Re: [PATCH 5/6] staging: pi433: Rename enum dataMode in rf69_enum.h

[Marcus Wolf]

Am 04.12.2017 um 12:24 schrieb Dan Carpenter:

On Sun, Dec 03, 2017 at 04:17:25PM +0100, Simon Sandström wrote:

Renames enum dataMode and its values packet, continuous, continuousNoSync
to enum data_mode and PACKET, CONTINUOUS, CONTINUOUS_NO_SYNC. Fixes
checkpatch.pl warnings: "Avoid CamelCase: , ".


These names are too generic.  Delete them.  Use DATAMODUL_MODE_PACKET
and friends directly.

int rf69_set_data_mode(struct spi_device *spi, u8 val)
{
return WRITE_REG(REG_DATAMODUL, (READ_REG(REG_DATAMODUL) & 
~MASK_DATAMODUL_MODE) | val);
}

Only DATAMODUL_MODE_PACKET is ever used.  There is no need to validate
the parameters.

regards,
dan carpenter



Hi Dan, hi Simon,

like I wrote a few days ago to Marcin Ciupak, I see two disadvantages in 
doing so.


If you want to go that way, you - as far as I believe - need to alter 
the values in rf69_enum.h, so they carry the corresponding values from 
rf69_reg.h. To avoid confusion, you will need to remove the values from 
rf69_reg.h.
But then you have to keep track of two files (enum.h and reg.h), if you 
want to further develop register access stuff. I would prefer to keep 
all chip/register related values at the same place.


Second there might be the idea of supporting different chips in the 
future (I already thought about).

Then it might be, that DATAMODUL_MODE_PACKET might need an other value.
Therefore, I introduced the "double layer" - enums as labels for the 
user space and defines, containing the values, for the register access.


For closer details, pls. see my long answer to Marcin.

I am not sure, whether simplification of the code like proposed is more 
important, then the disadvatages, I mentioned.


Cheers,

Marcus

Re: [PATCH 5/6] staging: pi433: Rename enum dataMode in rf69_enum.h

[Marcus Wolf]

Am 04.12.2017 um 12:24 schrieb Dan Carpenter:

On Sun, Dec 03, 2017 at 04:17:25PM +0100, Simon Sandström wrote:

Renames enum dataMode and its values packet, continuous, continuousNoSync
to enum data_mode and PACKET, CONTINUOUS, CONTINUOUS_NO_SYNC. Fixes
checkpatch.pl warnings: "Avoid CamelCase: , ".


These names are too generic.  Delete them.  Use DATAMODUL_MODE_PACKET
and friends directly.

int rf69_set_data_mode(struct spi_device *spi, u8 val)
{
return WRITE_REG(REG_DATAMODUL, (READ_REG(REG_DATAMODUL) & 
~MASK_DATAMODUL_MODE) | val);
}

Only DATAMODUL_MODE_PACKET is ever used.  There is no need to validate
the parameters.

regards,
dan carpenter



Hi Dan, hi Simon,

like I wrote a few days ago to Marcin Ciupak, I see two disadvantages in 
doing so.


If you want to go that way, you - as far as I believe - need to alter 
the values in rf69_enum.h, so they carry the corresponding values from 
rf69_reg.h. To avoid confusion, you will need to remove the values from 
rf69_reg.h.
But then you have to keep track of two files (enum.h and reg.h), if you 
want to further develop register access stuff. I would prefer to keep 
all chip/register related values at the same place.


Second there might be the idea of supporting different chips in the 
future (I already thought about).

Then it might be, that DATAMODUL_MODE_PACKET might need an other value.
Therefore, I introduced the "double layer" - enums as labels for the 
user space and defines, containing the values, for the register access.


For closer details, pls. see my long answer to Marcin.

I am not sure, whether simplification of the code like proposed is more 
important, then the disadvatages, I mentioned.


Cheers,

Marcus

Re: [PATCH 5/6] staging: pi433: Rename enum dataMode in rf69_enum.h

[Dan Carpenter]

On Sun, Dec 03, 2017 at 04:17:25PM +0100, Simon Sandström wrote:
> Renames enum dataMode and its values packet, continuous, continuousNoSync
> to enum data_mode and PACKET, CONTINUOUS, CONTINUOUS_NO_SYNC. Fixes
> checkpatch.pl warnings: "Avoid CamelCase: , ".

These names are too generic.  Delete them.  Use DATAMODUL_MODE_PACKET
and friends directly.

int rf69_set_data_mode(struct spi_device *spi, u8 val)
{
return WRITE_REG(REG_DATAMODUL, (READ_REG(REG_DATAMODUL) & 
~MASK_DATAMODUL_MODE) | val);
}

Only DATAMODUL_MODE_PACKET is ever used.  There is no need to validate
the parameters.

regards,
dan carpenter

Re: [PATCH 5/6] staging: pi433: Rename enum dataMode in rf69_enum.h

[Dan Carpenter]

On Sun, Dec 03, 2017 at 04:17:25PM +0100, Simon Sandström wrote:
> Renames enum dataMode and its values packet, continuous, continuousNoSync
> to enum data_mode and PACKET, CONTINUOUS, CONTINUOUS_NO_SYNC. Fixes
> checkpatch.pl warnings: "Avoid CamelCase: , ".

These names are too generic.  Delete them.  Use DATAMODUL_MODE_PACKET
and friends directly.

int rf69_set_data_mode(struct spi_device *spi, u8 val)
{
return WRITE_REG(REG_DATAMODUL, (READ_REG(REG_DATAMODUL) & 
~MASK_DATAMODUL_MODE) | val);
}

Only DATAMODUL_MODE_PACKET is ever used.  There is no need to validate
the parameters.

regards,
dan carpenter

[PATCH 5/6] staging: pi433: Rename enum dataMode in rf69_enum.h

[Simon Sandström]

Renames enum dataMode and its values packet, continuous, continuousNoSync
to enum data_mode and PACKET, CONTINUOUS, CONTINUOUS_NO_SYNC. Fixes
checkpatch.pl warnings: "Avoid CamelCase: , ".

Signed-off-by: Simon Sandström 
---
 drivers/staging/pi433/pi433_if.c  |  2 +-
 drivers/staging/pi433/rf69.c  | 10 +-
 drivers/staging/pi433/rf69.h  |  2 +-
 drivers/staging/pi433/rf69_enum.h |  8 
 4 files changed, 11 insertions(+), 11 deletions(-)

diff --git a/drivers/staging/pi433/pi433_if.c b/drivers/staging/pi433/pi433_if.c
index 4f6830f369e9..e7a730d312c5 100644
--- a/drivers/staging/pi433/pi433_if.c
+++ b/drivers/staging/pi433/pi433_if.c
@@ -1090,7 +1090,7 @@ static int pi433_probe(struct spi_device *spi)
 
/* setup the radio module */
SET_CHECKED(rf69_set_mode   (spi, standby));
-   SET_CHECKED(rf69_set_data_mode  (spi, packet));
+   SET_CHECKED(rf69_set_data_mode  (spi, PACKET));
SET_CHECKED(rf69_set_amplifier_0(spi, OPTION_ON));
SET_CHECKED(rf69_set_amplifier_1(spi, OPTION_OFF));
SET_CHECKED(rf69_set_amplifier_2(spi, OPTION_OFF));
diff --git a/drivers/staging/pi433/rf69.c b/drivers/staging/pi433/rf69.c
index ebb3ddd1a957..cf833ac23c06 100644
--- a/drivers/staging/pi433/rf69.c
+++ b/drivers/staging/pi433/rf69.c
@@ -61,16 +61,16 @@ int rf69_set_mode(struct spi_device *spi, enum mode mode)
 
 }
 
-int rf69_set_data_mode(struct spi_device *spi, enum dataMode dataMode)
+int rf69_set_data_mode(struct spi_device *spi, enum data_mode data_mode)
 {
#ifdef DEBUG
dev_dbg(>dev, "set: data mode");
#endif
 
-   switch (dataMode) {
-   case packet:return WRITE_REG(REG_DATAMODUL, 
(READ_REG(REG_DATAMODUL) & ~MASK_DATAMODUL_MODE) | DATAMODUL_MODE_PACKET);
-   case continuous:return WRITE_REG(REG_DATAMODUL, 
(READ_REG(REG_DATAMODUL) & ~MASK_DATAMODUL_MODE) | DATAMODUL_MODE_CONTINUOUS);
-   case continuousNoSync:  return WRITE_REG(REG_DATAMODUL, 
(READ_REG(REG_DATAMODUL) & ~MASK_DATAMODUL_MODE) | 
DATAMODUL_MODE_CONTINUOUS_NOSYNC);
+   switch (data_mode) {
+   case PACKET: return WRITE_REG(REG_DATAMODUL, 
(READ_REG(REG_DATAMODUL) & ~MASK_DATAMODUL_MODE) | DATAMODUL_MODE_PACKET);
+   case CONTINUOUS: return WRITE_REG(REG_DATAMODUL, 
(READ_REG(REG_DATAMODUL) & ~MASK_DATAMODUL_MODE) | DATAMODUL_MODE_CONTINUOUS);
+   case CONTINUOUS_NO_SYNC: return WRITE_REG(REG_DATAMODUL, 
(READ_REG(REG_DATAMODUL) & ~MASK_DATAMODUL_MODE) | 
DATAMODUL_MODE_CONTINUOUS_NOSYNC);
default:
dev_dbg(>dev, "set: illegal input param");
return -EINVAL;
diff --git a/drivers/staging/pi433/rf69.h b/drivers/staging/pi433/rf69.h
index 12c2e106785e..090743716326 100644
--- a/drivers/staging/pi433/rf69.h
+++ b/drivers/staging/pi433/rf69.h
@@ -26,7 +26,7 @@
 #define FIFO_THRESHOLD 15  /* in byte */
 
 int rf69_set_mode(struct spi_device *spi, enum mode mode);
-int rf69_set_data_mode(struct spi_device *spi, enum dataMode dataMode);
+int rf69_set_data_mode(struct spi_device *spi, enum data_mode data_mode);
 int rf69_set_modulation(struct spi_device *spi, enum modulation modulation);
 enum modulation rf69_get_modulation(struct spi_device *spi);
 int rf69_set_modulation_shaping(struct spi_device *spi, enum modShaping 
modShaping);
diff --git a/drivers/staging/pi433/rf69_enum.h 
b/drivers/staging/pi433/rf69_enum.h
index 5247e9269de9..a55528a72f47 100644
--- a/drivers/staging/pi433/rf69_enum.h
+++ b/drivers/staging/pi433/rf69_enum.h
@@ -31,10 +31,10 @@ enum mode {
receive
 };
 
-enum dataMode {
-   packet,
-   continuous,
-   continuousNoSync
+enum data_mode {
+   PACKET,
+   CONTINUOUS,
+   CONTINUOUS_NO_SYNC,
 };
 
 enum modulation {
-- 
2.11.0

[PATCH 5/6] staging: pi433: Rename enum dataMode in rf69_enum.h

[Simon Sandström]

Renames enum dataMode and its values packet, continuous, continuousNoSync
to enum data_mode and PACKET, CONTINUOUS, CONTINUOUS_NO_SYNC. Fixes
checkpatch.pl warnings: "Avoid CamelCase: , ".

Signed-off-by: Simon Sandström 
---
 drivers/staging/pi433/pi433_if.c  |  2 +-
 drivers/staging/pi433/rf69.c  | 10 +-
 drivers/staging/pi433/rf69.h  |  2 +-
 drivers/staging/pi433/rf69_enum.h |  8 
 4 files changed, 11 insertions(+), 11 deletions(-)

diff --git a/drivers/staging/pi433/pi433_if.c b/drivers/staging/pi433/pi433_if.c
index 4f6830f369e9..e7a730d312c5 100644
--- a/drivers/staging/pi433/pi433_if.c
+++ b/drivers/staging/pi433/pi433_if.c
@@ -1090,7 +1090,7 @@ static int pi433_probe(struct spi_device *spi)
 
/* setup the radio module */
SET_CHECKED(rf69_set_mode   (spi, standby));
-   SET_CHECKED(rf69_set_data_mode  (spi, packet));
+   SET_CHECKED(rf69_set_data_mode  (spi, PACKET));
SET_CHECKED(rf69_set_amplifier_0(spi, OPTION_ON));
SET_CHECKED(rf69_set_amplifier_1(spi, OPTION_OFF));
SET_CHECKED(rf69_set_amplifier_2(spi, OPTION_OFF));
diff --git a/drivers/staging/pi433/rf69.c b/drivers/staging/pi433/rf69.c
index ebb3ddd1a957..cf833ac23c06 100644
--- a/drivers/staging/pi433/rf69.c
+++ b/drivers/staging/pi433/rf69.c
@@ -61,16 +61,16 @@ int rf69_set_mode(struct spi_device *spi, enum mode mode)
 
 }
 
-int rf69_set_data_mode(struct spi_device *spi, enum dataMode dataMode)
+int rf69_set_data_mode(struct spi_device *spi, enum data_mode data_mode)
 {
#ifdef DEBUG
dev_dbg(>dev, "set: data mode");
#endif
 
-   switch (dataMode) {
-   case packet:return WRITE_REG(REG_DATAMODUL, 
(READ_REG(REG_DATAMODUL) & ~MASK_DATAMODUL_MODE) | DATAMODUL_MODE_PACKET);
-   case continuous:return WRITE_REG(REG_DATAMODUL, 
(READ_REG(REG_DATAMODUL) & ~MASK_DATAMODUL_MODE) | DATAMODUL_MODE_CONTINUOUS);
-   case continuousNoSync:  return WRITE_REG(REG_DATAMODUL, 
(READ_REG(REG_DATAMODUL) & ~MASK_DATAMODUL_MODE) | 
DATAMODUL_MODE_CONTINUOUS_NOSYNC);
+   switch (data_mode) {
+   case PACKET: return WRITE_REG(REG_DATAMODUL, 
(READ_REG(REG_DATAMODUL) & ~MASK_DATAMODUL_MODE) | DATAMODUL_MODE_PACKET);
+   case CONTINUOUS: return WRITE_REG(REG_DATAMODUL, 
(READ_REG(REG_DATAMODUL) & ~MASK_DATAMODUL_MODE) | DATAMODUL_MODE_CONTINUOUS);
+   case CONTINUOUS_NO_SYNC: return WRITE_REG(REG_DATAMODUL, 
(READ_REG(REG_DATAMODUL) & ~MASK_DATAMODUL_MODE) | 
DATAMODUL_MODE_CONTINUOUS_NOSYNC);
default:
dev_dbg(>dev, "set: illegal input param");
return -EINVAL;
diff --git a/drivers/staging/pi433/rf69.h b/drivers/staging/pi433/rf69.h
index 12c2e106785e..090743716326 100644
--- a/drivers/staging/pi433/rf69.h
+++ b/drivers/staging/pi433/rf69.h
@@ -26,7 +26,7 @@
 #define FIFO_THRESHOLD 15  /* in byte */
 
 int rf69_set_mode(struct spi_device *spi, enum mode mode);
-int rf69_set_data_mode(struct spi_device *spi, enum dataMode dataMode);
+int rf69_set_data_mode(struct spi_device *spi, enum data_mode data_mode);
 int rf69_set_modulation(struct spi_device *spi, enum modulation modulation);
 enum modulation rf69_get_modulation(struct spi_device *spi);
 int rf69_set_modulation_shaping(struct spi_device *spi, enum modShaping 
modShaping);
diff --git a/drivers/staging/pi433/rf69_enum.h 
b/drivers/staging/pi433/rf69_enum.h
index 5247e9269de9..a55528a72f47 100644
--- a/drivers/staging/pi433/rf69_enum.h
+++ b/drivers/staging/pi433/rf69_enum.h
@@ -31,10 +31,10 @@ enum mode {
receive
 };
 
-enum dataMode {
-   packet,
-   continuous,
-   continuousNoSync
+enum data_mode {
+   PACKET,
+   CONTINUOUS,
+   CONTINUOUS_NO_SYNC,
 };
 
 enum modulation {
-- 
2.11.0