i2c/pxa: remove unused macro

Cc Eric Miao <[email protected]>

Commit

beea494 ([ARM] Remove EEPROM slave emulation from i2c-pxa driver.)

removed all uses of eedbg, so the definition can go, too.

Signed-off-by Uwe Kleine-K?nig <[email protected]>

Cc Jean Delvare <[email protected]>

Cc Ben Dooks <[email protected]>

Cc Russell King <[email protected]>

Cc Eric Miao <[email protected]>

Cc Roel Kluin <[email protected]>

Commit

beea494 ([ARM] Remove EEPROM slave emulation from i2c-pxa driver.)

removed all uses of eedbg, so the definition can go, too.

Commit

beea494 ([ARM] Remove EEPROM slave emulation from i2c-pxa driver.)

removed all uses of eedbg, so the definition can go, too.

Hi Jean,

Quoted 5 lines · Uwe Kleine-K?nig

Commit

beea494 ([ARM] Remove EEPROM slave emulation from i2c-pxa driver.)

removed all uses of eedbg, so the definition can go, too.

do you have comments to my patches? I think they should go in via your tree.

Quoted 5 lines · Uwe Kleine-K?nig

Hi Jean,

Quoted 2 lines · Uwe Kleine-K?nig

Commit

Quoted 5 lines

Quoted 3 lines

beea494 ([ARM] Remove EEPROM slave emulation from i2c-pxa driver.)

removed all uses of eedbg, so the definition can go, too.

do you have comments to my patches? I think they should go in via your tree.

I think you should read MAINTAINERS again.

Hi Jean,

Quoted 9 lines · Jean Delvare

Quoted 8 lines · Uwe Kleine-K?nig

Hi Jean,

Quoted 5 lines · Uwe Kleine-K?nig

Commit

beea494 ([ARM] Remove EEPROM slave emulation from i2c-pxa driver.)

removed all uses of eedbg, so the definition can go, too.

Quoted 4 lines

Quoted 2 lines

do you have comments to my patches? I think they should go in via your tree.

I think you should read MAINTAINERS again.

Ah, so the maintainer is Ben Dooks, but the tree seems to be your's.

So I assume you take it when Ben give's his S-o-b or Ben has write access to the tree?

Quoted 8 lines · Uwe Kleine-K?nig

Quoted 5 lines · Jean Delvare

Quoted 2 lines · Uwe Kleine-K?nig

do you have comments to my patches? I think they should go in via your tree.

I think you should read MAINTAINERS again.

Ah, so the maintainer is Ben Dooks, but the tree seems to be your's.

Quoted 2 lines

So I assume you take it when Ben give's his S-o-b or Ben has write access to the tree?

No. I have my tree, Ben has its own. Ben's isn't listed in MAINTAINERS, thus the confusion.

Ben, can you please add your tree to MAINTAINERS to make things clearer for contributors?

Quoted 18 lines · Uwe Kleine-K?nig

Hi Jean,

Quoted 6 lines · Jean Delvare

Quoted 5 lines · Uwe Kleine-K?nig

Hi Jean,

Quoted 2 lines · Uwe Kleine-K?nig

Commit

Quoted 7 lines

Quoted 5 lines

Quoted 3 lines

beea494 ([ARM] Remove EEPROM slave emulation from i2c-pxa driver.)

removed all uses of eedbg, so the definition can go, too.

do you have comments to my patches? I think they should go in via your tree.

I think you should read MAINTAINERS again.

Ah, so the maintainer is Ben Dooks, but the tree seems to be your's.

Quoted 2 lines

So I assume you take it when Ben give's his S-o-b or Ben has write access to the tree?

No. I have my tree, Ben has its own. Ben's isn't listed in MAINTAINERS, thus the confusion.

Ben, can you please add your tree to MAINTAINERS to make things clearer for contributors?

Quoted 2 lines

Ben, can you please add your tree to MAINTAINERS to make things clearer for contributors?

In the meantime I have three i2c patches without any feedback by you. As Jean is convinced that you are responsible to take them can you please have a look and comment?

My patches are also available via git at

	git://git.pengutronix.de/git/ukl/linux-2.6.git next/i2c

Shortlog and diffstat can be found below.

Best regards
Uwe

Uwe Kleine-K?nig (2):
i2c/pxa: remove unused macro
i2c-imx: call ioremap only after request_mem_region

Wolfram Sang (1):
i2c/pxa: only define 'blue_murder'-function if DEBUG is #defined

Commit

beea494 ([ARM] Remove EEPROM slave emulation from i2c-pxa driver.)

removed all uses of eedbg, so the definition can go, too.

Signed-off-by Uwe Kleine-K?nig <[email protected]>

Acked-by Russell King <[email protected]>

Cc Eric Miao <[email protected]>

Cc Roel Kluin <[email protected]>

Acked-by Pavel Machek <[email protected]>

---
 drivers/i2c/busses/i2c-pxa.c |    2 --
 1 files changed, 0 insertions(+), 2 deletions(-)

drivers/i2c/busses/i2c-pxa.c +0 -2

index 7647a20..b3c6c9d 100644
@@ -216,8 +216,6 @@ static void i2c_pxa_show_state(struct pxa_i2c *i2c, int lno, const char *fname)
 #define decode_ICR(val) do { } while (0)
 #endif
 
-#define eedbg(lvl, x...) do { if ((lvl) < 1) { printk(KERN_DEBUG "" x); } } while(0)
-
 static void i2c_pxa_master_complete(struct pxa_i2c *i2c, int ret);
 static irqreturn_t i2c_pxa_handler(int this_irq, void *dev_id);
 

Signature · 1 line

1.6.6.2

Hi Ben,

Quoted 4 lines · Uwe Kleine-K?nig

Commit

beea494 ([ARM] Remove EEPROM slave emulation from i2c-pxa driver.)

Quoted 7 lines

removed all uses of eedbg, so the definition can go, too.

Signed-off-by Uwe Kleine-K?nig <[email protected]>

Acked-by Russell King <[email protected]>

Cc Eric Miao <[email protected]>

Cc Roel Kluin <[email protected]>

Acked-by Pavel Machek <[email protected]>

ping

From: Wolfram Sang <[email protected]>

This talkative function is also called on timeouts. As timeouts can happen on regular writes to EEPROMs (no error case), this creates false positives. Giving lots of details is interesting only for developers anyhow, so just use the function if DEBUG is #defined.

Quoted 6 lines · Uwe Kleine-K?nig

From: Wolfram Sang <[email protected]>

This talkative function is also called on timeouts. As timeouts can happen on regular writes to EEPROMs (no error case), this creates false positives. Giving lots of details is interesting only for developers anyhow, so just use the function if DEBUG is #defined.

Are you sure this is safe? If you time out the write before it completes, how do you know if the write was successful?

I don't think this is "no error code" nor "false positive". If the timeout is too short for your EEPROMs, then the timeout needs to be increased.

Quoted 6 lines · Uwe Kleine-K?nig

From: Wolfram Sang <[email protected]>

This talkative function is also called on timeouts. As timeouts can happen on regular writes to EEPROMs (no error case), this creates false positives. Giving lots of details is interesting only for developers anyhow, so just use the function if DEBUG is #defined.

Are you sure this is safe? If you time out the write before it completes, how do you know if the write was successful?

I don't think this is "no error code" nor "false positive". If the timeout is too short for your EEPROMs, then the timeout needs to be increased.

Sorry to bump this old thread, it dropped off my todo-list :(

Quoted 8 lines · Russell King - ARM Linux

Quoted 6 lines · Uwe Kleine-K?nig

From: Wolfram Sang <[email protected]>

This talkative function is also called on timeouts. As timeouts can happen on regular writes to EEPROMs (no error case), this creates false positives. Giving lots of details is interesting only for developers anyhow, so just use the function if DEBUG is #defined.

Quoted 5 lines

Are you sure this is safe? If you time out the write before it completes, how do you know if the write was successful?

I don't think this is "no error code" nor "false positive". If the timeout is too short for your EEPROMs, then the timeout needs to be increased.

I am sure this is safe because we have retries. The eeprom driver first tries to write data without a delay, because EEPROMs often have buffers. Once the buffers are full, the chip will not answer to the next write request which will result in a timeout for this write request. This is expected, so it will be retried after some delay. Something like -EBUSY. Only if another "outer" timeout passed after some retries, then we have a problem and this should be user visible. But the timeout for the write request is nothing exceptional and the user doesn't need to be informed about it, especially not in this detail. This is what the patch is addressing.

Quoted 9 lines

I am sure this is safe because we have retries. The eeprom driver first tries to write data without a delay, because EEPROMs often have buffers. Once the buffers are full, the chip will not answer to the next write request which will result in a timeout for this write request. This is expected, so it will be retried after some delay. Something like -EBUSY. Only if another "outer" timeout passed after some retries, then we have a problem and this should be user visible. But the timeout for the write request is nothing exceptional and the user doesn't need to be informed about it, especially not in this detail. This is what the patch is addressing.

And what if it's not an EEPROM that you're talking to?

Quoted 11 lines

Quoted 9 lines

I am sure this is safe because we have retries. The eeprom driver first tries to write data without a delay, because EEPROMs often have buffers. Once the buffers are full, the chip will not answer to the next write request which will result in a timeout for this write request. This is expected, so it will be retried after some delay. Something like -EBUSY. Only if another "outer" timeout passed after some retries, then we have a problem and this should be user visible. But the timeout for the write request is nothing exceptional and the user doesn't need to be informed about it, especially not in this detail. This is what the patch is addressing.

And what if it's not an EEPROM that you're talking to?

That's up to the corresponding driver. The driver is still notified via the return value how many i2c-messages could be transmitted. If this is not equal to what the driver intended, then it can decide to retry or notify the user. And that is the apropriate level. Doing all this printout at the bus-driver level is only interesting for developers. Users are frightened by the "timeout" in their logs although everything might be as expected. A bus driver can't know.

Signed-off-by Uwe Kleine-K?nig <[email protected]>

Acked-by Jean Delvare <[email protected]>

---
 MAINTAINERS |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

MAINTAINERS +0 -0

index 2533fc4..a3c936c 100644

Quoted 6 lines · Uwe Kleine-K?nig

Signed-off-by Uwe Kleine-K?nig <[email protected]>

Acked-by Jean Delvare <[email protected]>

---
 MAINTAINERS |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

MAINTAINERS M: "Ben Dooks (embedded platforms)" <[email protected]> · line 2629

Quoted 9 lines

MAINTAINERS +1 -0

index 2533fc4..a3c936c 100644
@@ -2626,6 +2626,7 @@ M:	"Ben Dooks (embedded platforms)" <[email protected]>
 L:	linux-i2c at vger.kernel.org
 W:	http://i2c.wiki.kernel.org/
 T:	quilt kernel.org/pub/linux/kernel/people/jdelvare/linux-2.6/jdelvare-i2c/
+T:	git git://git.fluff.org/bjdooks/linux.git

This is wrong. This is the same tree which I pull ARM stuff from, so it needs qualifying with a branch name.

Quoted 7 lines · Russell King - ARM Linux

Quoted 6 lines · Uwe Kleine-K?nig

Signed-off-by Uwe Kleine-K?nig <[email protected]>

Acked-by Jean Delvare <[email protected]>

---
 MAINTAINERS |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

Quoted 12 lines

MAINTAINERS M: "Ben Dooks (embedded platforms)" <[email protected]> · line 2629

Quoted 9 lines

MAINTAINERS +1 -0

index 2533fc4..a3c936c 100644
@@ -2626,6 +2626,7 @@ M:	"Ben Dooks (embedded platforms)" <[email protected]>
 L:	linux-i2c at vger.kernel.org
 W:	http://i2c.wiki.kernel.org/
 T:	quilt kernel.org/pub/linux/kernel/people/jdelvare/linux-2.6/jdelvare-i2c/
+T:	git git://git.fluff.org/bjdooks/linux.git

This is wrong. This is the same tree which I pull ARM stuff from, so it needs qualifying with a branch name.

$(git ls-remote git://git.fluff.org/bjdooks/linux.git) suggests two candidates:

for-linus/i2c
next-i2c

And I think for now this is only parsed by humans and everbody should be able to notice that e.g. "next-s3c" doesn't contain i2c patches in the presence of the two above branches.

So unless there is a syntax to specify more than one branch I suggest to keep it as is. Or should we only list next-i2c? Ben, what do you think?

(Maybe we can just make it:

T: git git://git.fluff.org/bjdooks/linux.git for-linus/i2c
T: git git://git.fluff.org/bjdooks/linux.git next-i2c

but this is a bit too much IMHO. (Who volunteers to list all branches of tip in MAINTAINERS? ;-))

Best regards
Uwe

Signed-off-by Uwe Kleine-K?nig <[email protected]>

Acked-by Jean Delvare <[email protected]>

---
 MAINTAINERS |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

MAINTAINERS +1 -0

index f520dd0..a01745b 100644
@@ -2658,6 +2658,7 @@ M:	"Ben Dooks (embedded platforms)" <[email protected]>
 L:	linux-i2c at vger.kernel.org
 W:	http://i2c.wiki.kernel.org/
 T:	quilt kernel.org/pub/linux/kernel/people/jdelvare/linux-2.6/jdelvare-i2c/
+T:	git git://git.fluff.org/bjdooks/linux.git next-i2c
 S:	Maintained
 F:	Documentation/i2c/
 F:	drivers/i2c/

Signature · 1 line

1.7.0

From: Wolfram Sang <[email protected]>

This talkative function is also called on timeouts. As timeouts can happen on regular writes to EEPROMs (no error case), this creates false positives. ?Giving lots of details is interesting only for developers anyhow, so just use the function if DEBUG is #defined.

Commit

beea494 ([ARM] Remove EEPROM slave emulation from i2c-pxa driver.)

Quoted 3 lines · Uwe Kleine-K?nig

Commit

beea494 ([ARM] Remove EEPROM slave emulation from i2c-pxa driver.)

Oh great. Some people may remember the LX code that I submitted to the mailing list a while back. Removing the slave emulation buggers that platform up. I do intend to submit that once the issue of where the PCON support should be located is resolved - which is still pending.

Please revert this change, thanks.

Quoted 11 lines · Russell King

Quoted 3 lines · Uwe Kleine-K?nig

Commit

beea494 ([ARM] Remove EEPROM slave emulation from i2c-pxa driver.)

Oh great. Some people may remember the LX code that I submitted to the mailing list a while back. Removing the slave emulation buggers that platform up. I do intend to submit that once the issue of where the PCON support should be located is resolved - which is still pending.

Quoted 1 line

Please revert this change, thanks.

Would you like it reverted in the next merge window, or when the LX code is actually added?

I'll NAK any changes to remove the eedbg() for the moment.

Quoted 3 lines · Uwe Kleine-K?nig

Commit

beea494 ([ARM] Remove EEPROM slave emulation from i2c-pxa driver.)

Oh great. Some people may remember the LX code that I submitted to the mailing list a while back. Removing the slave emulation buggers that platform up. I do intend to submit that once the issue of where the PCON support should be located is resolved - which is still pending.

Please revert this change, thanks.

Commit

beea494 ([ARM] Remove EEPROM slave emulation from i2c-pxa driver.)

removed all uses of eedbg, so the definition can go, too.