->status isn't STATUS_WRITE_IN_PROGRESS
but also I2C_SLAVE_STOP been reported when a STOP condition is received.
Signed-off-by: Michael Wu
---
drivers/i2c/busses/i2c-designware-slave.c | 45 +--
1 file changed, 18 insertions(+), 27 deletions(-)
diff --git a/driver
called once in an ISR and take
its returned state for all later handlings.
Signed-off-by: Michael Wu
Acked-by: Jarkko Nikula
---
drivers/i2c/busses/i2c-designware-slave.c | 7 +--
1 file changed, 1 insertion(+), 6 deletions(-)
diff --git a/drivers/i2c/busses/i2c-designware-slave.c
b/drivers
should be called only once in an ISR and take the returned stat to handle
those occurred events. The ISR handling has to be adjusted to conform event
reporting described in Documentation/i2c/slave-interface.rst.
Michael Wu (2):
i2c: designware: call i2c_dw_read_clear_intrbits_slave() once
called once in an ISR and take
its returned state for all later handlings.
Signed-off-by: Michael Wu
---
Change in v3:
- revert deleted braces of 'else' branch in v2
Change in v2:
- revert moving I2C_SLAVE_WRITE_REQUESTED reporting in v1
drivers/i2c/busses/i2c-designware-slave.c | 7
called once in an ISR and take
its returned state for all later handlings.
Signed-off-by: Michael Wu
---
Changes in v2:
- revert moving I2C_SLAVE_WRITE_REQUESTED reporting
drivers/i2c/busses/i2c-designware-slave.c | 10 ++
1 file changed, 2 insertions(+), 8 deletions(-)
diff --git a
imes. Calling i2c_dw_read_clear_intrbits_slave() once in one ISR and take
the returned stat for later handling is the solution.
Signed-off-by: Michael Wu
---
drivers/i2c/busses/i2c-designware-slave.c | 16 +---
1 file changed, 5 insertions(+), 11 deletions(-)
diff --git a/drivers/i2c/busses/i2c-designware-slave.c
imes. Calling i2c_dw_read_clear_intrbits_slave() once in one ISR and take
the returned stat for later handling is the solution.
Signed-off-by: Michael Wu
---
drivers/i2c/busses/i2c-designware-slave.c | 16 +---
1 file changed, 5 insertions(+), 11 deletions(-)
diff --git a/drivers/i2c/busses/i2c-designware-slave.c
solve the omitted
I2C_SLAVE_STOP in case 2.
Signed-off-by: Michael Wu
---
drivers/i2c/busses/i2c-designware-slave.c | 73 ---
1 file changed, 39 insertions(+), 34 deletions(-)
diff --git a/drivers/i2c/busses/i2c-designware-slave.c
b/drivers/i2c/busses/i2c-designware-slave.c
i
be done because IC_INTR_STOP_DET was
cleared in t5.
In order to resolve these problems, i2c_dw_read_clear_intrbits_slave()
should be called only one time in ISR and take the returned stat to handle
those occurred events.
Signed-off-by: Michael Wu
---
drivers/i2c/b
_REQUEST_ACTIVE_LOW;
req.eventflags = GPIOEVENT_REQUEST_FALLING_EDGE;
At the result, there are no any events caught when the button is pushed.
By the way, button releasing will emit a "falling" event. The timing of
"falling" catching is not expected.
Cc: sta...@vg
o any
modification except to configuring GPIOHANDLE_REQUEST_ACTIVE_LOW.
Signed-off-by: Michael Wu
---
drivers/gpio/gpiolib.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
index e013d417a936..b98466a05091 100644
--- a/drivers
On Monday 03 December 2007 05:50:38 Cyrill Gorcunov wrote:
> This patch does fix missed mutex unlock. Please see it attached.
> (Can't send it as a plain text patch - have only IE based mail access)
>
> Cyrill
Acked-by: Michael Wu <[EMAIL PROTECTED]>
Thanks,
-Mic
|name| is no longer valid. Next time this
field is dereferenced (count_matching_names, in this case), we crash.
The following patch fixes the issue but there's probably a better way.
-Michael Wu
---
diff --git a/include/linux/lockdep.h b/include/linux/lockdep.h
index 4c4d236..2aa0d35 10064
onally I find the whole approach used by this driver for types of
> registers (which are really USB register numbers) utterly perverse...
>
The same register offsets are used in the PCI driver since version 1 usb
devices are really just the PCI device with a usb->pci bridge chip attached.
-
ers can
> depend on, deciding that existing functionality is a bug is, well,
> impolite.
>
No, it's absolutely a bug. It just so happens that some drivers incorrectly
allowed it.
-Michael Wu
pgp88tOEHFma3.pgp
Description: PGP signature
pace. As Arjan suggests, there's then the intermediate state of
> "disable as much as possible while still providing scanning and link
> detection".
>
In order to scan, we need to have the radio on and we need to be able to send
and receive. What are you gonna turn off?
-
or such a design.
>
The ADM8211 would be a good test too. So far, the main thing I see missing
from the 802.11 code is software scanning/authentication/association. Is all
of that being moved to userspace? I prefer having a little bit of that in the
kernel so minimal managed, adhoc, and WEP feature
17 matches
Mail list logo
