Revision tags: v6.6.30, v6.6.29, v6.6.28, v6.6.27 |
|
#
cfd75804 |
| 10-Apr-2024 |
Noah Loomans <noah@noahloomans.com> |
platform/chrome: cros_ec_uart: properly fix race condition
commit 5e700b384ec13f5bcac9855cb28fcc674f1d3593 upstream.
The cros_ec_uart_probe() function calls devm_serdev_device_open() before it call
platform/chrome: cros_ec_uart: properly fix race condition
commit 5e700b384ec13f5bcac9855cb28fcc674f1d3593 upstream.
The cros_ec_uart_probe() function calls devm_serdev_device_open() before it calls serdev_device_set_client_ops(). This can trigger a NULL pointer dereference:
BUG: kernel NULL pointer dereference, address: 0000000000000000 ... Call Trace: <TASK> ... ? ttyport_receive_buf
A simplified version of crashing code is as follows:
static inline size_t serdev_controller_receive_buf(struct serdev_controller *ctrl, const u8 *data, size_t count) { struct serdev_device *serdev = ctrl->serdev;
if (!serdev || !serdev->ops->receive_buf) // CRASH! return 0;
return serdev->ops->receive_buf(serdev, data, count); }
It assumes that if SERPORT_ACTIVE is set and serdev exists, serdev->ops will also exist. This conflicts with the existing cros_ec_uart_probe() logic, as it first calls devm_serdev_device_open() (which sets SERPORT_ACTIVE), and only later sets serdev->ops via serdev_device_set_client_ops().
Commit 01f95d42b8f4 ("platform/chrome: cros_ec_uart: fix race condition") attempted to fix a similar race condition, but while doing so, made the window of error for this race condition to happen much wider.
Attempt to fix the race condition again, making sure we fully setup before calling devm_serdev_device_open().
Fixes: 01f95d42b8f4 ("platform/chrome: cros_ec_uart: fix race condition") Cc: stable@vger.kernel.org Signed-off-by: Noah Loomans <noah@noahloomans.com> Reviewed-by: Guenter Roeck <groeck@chromium.org> Link: https://lore.kernel.org/r/20240410182618.169042-2-noah@noahloomans.com Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
Revision tags: v6.6.30, v6.6.29, v6.6.28, v6.6.27 |
|
#
cfd75804 |
| 10-Apr-2024 |
Noah Loomans <noah@noahloomans.com> |
platform/chrome: cros_ec_uart: properly fix race condition
commit 5e700b384ec13f5bcac9855cb28fcc674f1d3593 upstream.
The cros_ec_uart_probe() function calls devm_serdev_device_open() before it call
platform/chrome: cros_ec_uart: properly fix race condition
commit 5e700b384ec13f5bcac9855cb28fcc674f1d3593 upstream.
The cros_ec_uart_probe() function calls devm_serdev_device_open() before it calls serdev_device_set_client_ops(). This can trigger a NULL pointer dereference:
BUG: kernel NULL pointer dereference, address: 0000000000000000 ... Call Trace: <TASK> ... ? ttyport_receive_buf
A simplified version of crashing code is as follows:
static inline size_t serdev_controller_receive_buf(struct serdev_controller *ctrl, const u8 *data, size_t count) { struct serdev_device *serdev = ctrl->serdev;
if (!serdev || !serdev->ops->receive_buf) // CRASH! return 0;
return serdev->ops->receive_buf(serdev, data, count); }
It assumes that if SERPORT_ACTIVE is set and serdev exists, serdev->ops will also exist. This conflicts with the existing cros_ec_uart_probe() logic, as it first calls devm_serdev_device_open() (which sets SERPORT_ACTIVE), and only later sets serdev->ops via serdev_device_set_client_ops().
Commit 01f95d42b8f4 ("platform/chrome: cros_ec_uart: fix race condition") attempted to fix a similar race condition, but while doing so, made the window of error for this race condition to happen much wider.
Attempt to fix the race condition again, making sure we fully setup before calling devm_serdev_device_open().
Fixes: 01f95d42b8f4 ("platform/chrome: cros_ec_uart: fix race condition") Cc: stable@vger.kernel.org Signed-off-by: Noah Loomans <noah@noahloomans.com> Reviewed-by: Guenter Roeck <groeck@chromium.org> Link: https://lore.kernel.org/r/20240410182618.169042-2-noah@noahloomans.com Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
Revision tags: v6.6.30, v6.6.29, v6.6.28, v6.6.27 |
|
#
cfd75804 |
| 10-Apr-2024 |
Noah Loomans <noah@noahloomans.com> |
platform/chrome: cros_ec_uart: properly fix race condition
commit 5e700b384ec13f5bcac9855cb28fcc674f1d3593 upstream.
The cros_ec_uart_probe() function calls devm_serdev_device_open() before it call
platform/chrome: cros_ec_uart: properly fix race condition
commit 5e700b384ec13f5bcac9855cb28fcc674f1d3593 upstream.
The cros_ec_uart_probe() function calls devm_serdev_device_open() before it calls serdev_device_set_client_ops(). This can trigger a NULL pointer dereference:
BUG: kernel NULL pointer dereference, address: 0000000000000000 ... Call Trace: <TASK> ... ? ttyport_receive_buf
A simplified version of crashing code is as follows:
static inline size_t serdev_controller_receive_buf(struct serdev_controller *ctrl, const u8 *data, size_t count) { struct serdev_device *serdev = ctrl->serdev;
if (!serdev || !serdev->ops->receive_buf) // CRASH! return 0;
return serdev->ops->receive_buf(serdev, data, count); }
It assumes that if SERPORT_ACTIVE is set and serdev exists, serdev->ops will also exist. This conflicts with the existing cros_ec_uart_probe() logic, as it first calls devm_serdev_device_open() (which sets SERPORT_ACTIVE), and only later sets serdev->ops via serdev_device_set_client_ops().
Commit 01f95d42b8f4 ("platform/chrome: cros_ec_uart: fix race condition") attempted to fix a similar race condition, but while doing so, made the window of error for this race condition to happen much wider.
Attempt to fix the race condition again, making sure we fully setup before calling devm_serdev_device_open().
Fixes: 01f95d42b8f4 ("platform/chrome: cros_ec_uart: fix race condition") Cc: stable@vger.kernel.org Signed-off-by: Noah Loomans <noah@noahloomans.com> Reviewed-by: Guenter Roeck <groeck@chromium.org> Link: https://lore.kernel.org/r/20240410182618.169042-2-noah@noahloomans.com Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
Revision tags: v6.6.30, v6.6.29, v6.6.28, v6.6.27 |
|
#
cfd75804 |
| 10-Apr-2024 |
Noah Loomans <noah@noahloomans.com> |
platform/chrome: cros_ec_uart: properly fix race condition
commit 5e700b384ec13f5bcac9855cb28fcc674f1d3593 upstream.
The cros_ec_uart_probe() function calls devm_serdev_device_open() before it call
platform/chrome: cros_ec_uart: properly fix race condition
commit 5e700b384ec13f5bcac9855cb28fcc674f1d3593 upstream.
The cros_ec_uart_probe() function calls devm_serdev_device_open() before it calls serdev_device_set_client_ops(). This can trigger a NULL pointer dereference:
BUG: kernel NULL pointer dereference, address: 0000000000000000 ... Call Trace: <TASK> ... ? ttyport_receive_buf
A simplified version of crashing code is as follows:
static inline size_t serdev_controller_receive_buf(struct serdev_controller *ctrl, const u8 *data, size_t count) { struct serdev_device *serdev = ctrl->serdev;
if (!serdev || !serdev->ops->receive_buf) // CRASH! return 0;
return serdev->ops->receive_buf(serdev, data, count); }
It assumes that if SERPORT_ACTIVE is set and serdev exists, serdev->ops will also exist. This conflicts with the existing cros_ec_uart_probe() logic, as it first calls devm_serdev_device_open() (which sets SERPORT_ACTIVE), and only later sets serdev->ops via serdev_device_set_client_ops().
Commit 01f95d42b8f4 ("platform/chrome: cros_ec_uart: fix race condition") attempted to fix a similar race condition, but while doing so, made the window of error for this race condition to happen much wider.
Attempt to fix the race condition again, making sure we fully setup before calling devm_serdev_device_open().
Fixes: 01f95d42b8f4 ("platform/chrome: cros_ec_uart: fix race condition") Cc: stable@vger.kernel.org Signed-off-by: Noah Loomans <noah@noahloomans.com> Reviewed-by: Guenter Roeck <groeck@chromium.org> Link: https://lore.kernel.org/r/20240410182618.169042-2-noah@noahloomans.com Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
Revision tags: v6.6.30, v6.6.29, v6.6.28, v6.6.27 |
|
#
cfd75804 |
| 10-Apr-2024 |
Noah Loomans <noah@noahloomans.com> |
platform/chrome: cros_ec_uart: properly fix race condition
commit 5e700b384ec13f5bcac9855cb28fcc674f1d3593 upstream.
The cros_ec_uart_probe() function calls devm_serdev_device_open() before it call
platform/chrome: cros_ec_uart: properly fix race condition
commit 5e700b384ec13f5bcac9855cb28fcc674f1d3593 upstream.
The cros_ec_uart_probe() function calls devm_serdev_device_open() before it calls serdev_device_set_client_ops(). This can trigger a NULL pointer dereference:
BUG: kernel NULL pointer dereference, address: 0000000000000000 ... Call Trace: <TASK> ... ? ttyport_receive_buf
A simplified version of crashing code is as follows:
static inline size_t serdev_controller_receive_buf(struct serdev_controller *ctrl, const u8 *data, size_t count) { struct serdev_device *serdev = ctrl->serdev;
if (!serdev || !serdev->ops->receive_buf) // CRASH! return 0;
return serdev->ops->receive_buf(serdev, data, count); }
It assumes that if SERPORT_ACTIVE is set and serdev exists, serdev->ops will also exist. This conflicts with the existing cros_ec_uart_probe() logic, as it first calls devm_serdev_device_open() (which sets SERPORT_ACTIVE), and only later sets serdev->ops via serdev_device_set_client_ops().
Commit 01f95d42b8f4 ("platform/chrome: cros_ec_uart: fix race condition") attempted to fix a similar race condition, but while doing so, made the window of error for this race condition to happen much wider.
Attempt to fix the race condition again, making sure we fully setup before calling devm_serdev_device_open().
Fixes: 01f95d42b8f4 ("platform/chrome: cros_ec_uart: fix race condition") Cc: stable@vger.kernel.org Signed-off-by: Noah Loomans <noah@noahloomans.com> Reviewed-by: Guenter Roeck <groeck@chromium.org> Link: https://lore.kernel.org/r/20240410182618.169042-2-noah@noahloomans.com Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
Revision tags: v6.6.30, v6.6.29, v6.6.28, v6.6.27 |
|
#
cfd75804 |
| 10-Apr-2024 |
Noah Loomans <noah@noahloomans.com> |
platform/chrome: cros_ec_uart: properly fix race condition
commit 5e700b384ec13f5bcac9855cb28fcc674f1d3593 upstream.
The cros_ec_uart_probe() function calls devm_serdev_device_open() before it call
platform/chrome: cros_ec_uart: properly fix race condition
commit 5e700b384ec13f5bcac9855cb28fcc674f1d3593 upstream.
The cros_ec_uart_probe() function calls devm_serdev_device_open() before it calls serdev_device_set_client_ops(). This can trigger a NULL pointer dereference:
BUG: kernel NULL pointer dereference, address: 0000000000000000 ... Call Trace: <TASK> ... ? ttyport_receive_buf
A simplified version of crashing code is as follows:
static inline size_t serdev_controller_receive_buf(struct serdev_controller *ctrl, const u8 *data, size_t count) { struct serdev_device *serdev = ctrl->serdev;
if (!serdev || !serdev->ops->receive_buf) // CRASH! return 0;
return serdev->ops->receive_buf(serdev, data, count); }
It assumes that if SERPORT_ACTIVE is set and serdev exists, serdev->ops will also exist. This conflicts with the existing cros_ec_uart_probe() logic, as it first calls devm_serdev_device_open() (which sets SERPORT_ACTIVE), and only later sets serdev->ops via serdev_device_set_client_ops().
Commit 01f95d42b8f4 ("platform/chrome: cros_ec_uart: fix race condition") attempted to fix a similar race condition, but while doing so, made the window of error for this race condition to happen much wider.
Attempt to fix the race condition again, making sure we fully setup before calling devm_serdev_device_open().
Fixes: 01f95d42b8f4 ("platform/chrome: cros_ec_uart: fix race condition") Cc: stable@vger.kernel.org Signed-off-by: Noah Loomans <noah@noahloomans.com> Reviewed-by: Guenter Roeck <groeck@chromium.org> Link: https://lore.kernel.org/r/20240410182618.169042-2-noah@noahloomans.com Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
Revision tags: v6.6.30, v6.6.29, v6.6.28, v6.6.27 |
|
#
cfd75804 |
| 10-Apr-2024 |
Noah Loomans <noah@noahloomans.com> |
platform/chrome: cros_ec_uart: properly fix race condition
commit 5e700b384ec13f5bcac9855cb28fcc674f1d3593 upstream.
The cros_ec_uart_probe() function calls devm_serdev_device_open() before it call
platform/chrome: cros_ec_uart: properly fix race condition
commit 5e700b384ec13f5bcac9855cb28fcc674f1d3593 upstream.
The cros_ec_uart_probe() function calls devm_serdev_device_open() before it calls serdev_device_set_client_ops(). This can trigger a NULL pointer dereference:
BUG: kernel NULL pointer dereference, address: 0000000000000000 ... Call Trace: <TASK> ... ? ttyport_receive_buf
A simplified version of crashing code is as follows:
static inline size_t serdev_controller_receive_buf(struct serdev_controller *ctrl, const u8 *data, size_t count) { struct serdev_device *serdev = ctrl->serdev;
if (!serdev || !serdev->ops->receive_buf) // CRASH! return 0;
return serdev->ops->receive_buf(serdev, data, count); }
It assumes that if SERPORT_ACTIVE is set and serdev exists, serdev->ops will also exist. This conflicts with the existing cros_ec_uart_probe() logic, as it first calls devm_serdev_device_open() (which sets SERPORT_ACTIVE), and only later sets serdev->ops via serdev_device_set_client_ops().
Commit 01f95d42b8f4 ("platform/chrome: cros_ec_uart: fix race condition") attempted to fix a similar race condition, but while doing so, made the window of error for this race condition to happen much wider.
Attempt to fix the race condition again, making sure we fully setup before calling devm_serdev_device_open().
Fixes: 01f95d42b8f4 ("platform/chrome: cros_ec_uart: fix race condition") Cc: stable@vger.kernel.org Signed-off-by: Noah Loomans <noah@noahloomans.com> Reviewed-by: Guenter Roeck <groeck@chromium.org> Link: https://lore.kernel.org/r/20240410182618.169042-2-noah@noahloomans.com Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
Revision tags: v6.6.30, v6.6.29, v6.6.28, v6.6.27 |
|
#
cfd75804 |
| 10-Apr-2024 |
Noah Loomans <noah@noahloomans.com> |
platform/chrome: cros_ec_uart: properly fix race condition
commit 5e700b384ec13f5bcac9855cb28fcc674f1d3593 upstream.
The cros_ec_uart_probe() function calls devm_serdev_device_open() before it call
platform/chrome: cros_ec_uart: properly fix race condition
commit 5e700b384ec13f5bcac9855cb28fcc674f1d3593 upstream.
The cros_ec_uart_probe() function calls devm_serdev_device_open() before it calls serdev_device_set_client_ops(). This can trigger a NULL pointer dereference:
BUG: kernel NULL pointer dereference, address: 0000000000000000 ... Call Trace: <TASK> ... ? ttyport_receive_buf
A simplified version of crashing code is as follows:
static inline size_t serdev_controller_receive_buf(struct serdev_controller *ctrl, const u8 *data, size_t count) { struct serdev_device *serdev = ctrl->serdev;
if (!serdev || !serdev->ops->receive_buf) // CRASH! return 0;
return serdev->ops->receive_buf(serdev, data, count); }
It assumes that if SERPORT_ACTIVE is set and serdev exists, serdev->ops will also exist. This conflicts with the existing cros_ec_uart_probe() logic, as it first calls devm_serdev_device_open() (which sets SERPORT_ACTIVE), and only later sets serdev->ops via serdev_device_set_client_ops().
Commit 01f95d42b8f4 ("platform/chrome: cros_ec_uart: fix race condition") attempted to fix a similar race condition, but while doing so, made the window of error for this race condition to happen much wider.
Attempt to fix the race condition again, making sure we fully setup before calling devm_serdev_device_open().
Fixes: 01f95d42b8f4 ("platform/chrome: cros_ec_uart: fix race condition") Cc: stable@vger.kernel.org Signed-off-by: Noah Loomans <noah@noahloomans.com> Reviewed-by: Guenter Roeck <groeck@chromium.org> Link: https://lore.kernel.org/r/20240410182618.169042-2-noah@noahloomans.com Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
Revision tags: v6.6.30, v6.6.29, v6.6.28, v6.6.27 |
|
#
cfd75804 |
| 10-Apr-2024 |
Noah Loomans <noah@noahloomans.com> |
platform/chrome: cros_ec_uart: properly fix race condition
commit 5e700b384ec13f5bcac9855cb28fcc674f1d3593 upstream.
The cros_ec_uart_probe() function calls devm_serdev_device_open() before it call
platform/chrome: cros_ec_uart: properly fix race condition
commit 5e700b384ec13f5bcac9855cb28fcc674f1d3593 upstream.
The cros_ec_uart_probe() function calls devm_serdev_device_open() before it calls serdev_device_set_client_ops(). This can trigger a NULL pointer dereference:
BUG: kernel NULL pointer dereference, address: 0000000000000000 ... Call Trace: <TASK> ... ? ttyport_receive_buf
A simplified version of crashing code is as follows:
static inline size_t serdev_controller_receive_buf(struct serdev_controller *ctrl, const u8 *data, size_t count) { struct serdev_device *serdev = ctrl->serdev;
if (!serdev || !serdev->ops->receive_buf) // CRASH! return 0;
return serdev->ops->receive_buf(serdev, data, count); }
It assumes that if SERPORT_ACTIVE is set and serdev exists, serdev->ops will also exist. This conflicts with the existing cros_ec_uart_probe() logic, as it first calls devm_serdev_device_open() (which sets SERPORT_ACTIVE), and only later sets serdev->ops via serdev_device_set_client_ops().
Commit 01f95d42b8f4 ("platform/chrome: cros_ec_uart: fix race condition") attempted to fix a similar race condition, but while doing so, made the window of error for this race condition to happen much wider.
Attempt to fix the race condition again, making sure we fully setup before calling devm_serdev_device_open().
Fixes: 01f95d42b8f4 ("platform/chrome: cros_ec_uart: fix race condition") Cc: stable@vger.kernel.org Signed-off-by: Noah Loomans <noah@noahloomans.com> Reviewed-by: Guenter Roeck <groeck@chromium.org> Link: https://lore.kernel.org/r/20240410182618.169042-2-noah@noahloomans.com Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
Revision tags: v6.6.30, v6.6.29, v6.6.28, v6.6.27 |
|
#
cfd75804 |
| 10-Apr-2024 |
Noah Loomans <noah@noahloomans.com> |
platform/chrome: cros_ec_uart: properly fix race condition
commit 5e700b384ec13f5bcac9855cb28fcc674f1d3593 upstream.
The cros_ec_uart_probe() function calls devm_serdev_device_open() before it call
platform/chrome: cros_ec_uart: properly fix race condition
commit 5e700b384ec13f5bcac9855cb28fcc674f1d3593 upstream.
The cros_ec_uart_probe() function calls devm_serdev_device_open() before it calls serdev_device_set_client_ops(). This can trigger a NULL pointer dereference:
BUG: kernel NULL pointer dereference, address: 0000000000000000 ... Call Trace: <TASK> ... ? ttyport_receive_buf
A simplified version of crashing code is as follows:
static inline size_t serdev_controller_receive_buf(struct serdev_controller *ctrl, const u8 *data, size_t count) { struct serdev_device *serdev = ctrl->serdev;
if (!serdev || !serdev->ops->receive_buf) // CRASH! return 0;
return serdev->ops->receive_buf(serdev, data, count); }
It assumes that if SERPORT_ACTIVE is set and serdev exists, serdev->ops will also exist. This conflicts with the existing cros_ec_uart_probe() logic, as it first calls devm_serdev_device_open() (which sets SERPORT_ACTIVE), and only later sets serdev->ops via serdev_device_set_client_ops().
Commit 01f95d42b8f4 ("platform/chrome: cros_ec_uart: fix race condition") attempted to fix a similar race condition, but while doing so, made the window of error for this race condition to happen much wider.
Attempt to fix the race condition again, making sure we fully setup before calling devm_serdev_device_open().
Fixes: 01f95d42b8f4 ("platform/chrome: cros_ec_uart: fix race condition") Cc: stable@vger.kernel.org Signed-off-by: Noah Loomans <noah@noahloomans.com> Reviewed-by: Guenter Roeck <groeck@chromium.org> Link: https://lore.kernel.org/r/20240410182618.169042-2-noah@noahloomans.com Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
Revision tags: v6.6.26, v6.6.25, v6.6.24, v6.6.23, v6.6.16, v6.6.15, v6.6.14, v6.6.13, v6.6.12, v6.6.11, v6.6.10, v6.6.9, v6.6.8, v6.6.7, v6.6.6, v6.6.5, v6.6.4, v6.6.3, v6.6.2, v6.5.11, v6.6.1, v6.5.10, v6.6, v6.5.9, v6.5.8, v6.5.7, v6.5.6, v6.5.5, v6.5.4, v6.5.3, v6.5.2, v6.1.51, v6.5.1, v6.1.50, v6.5, v6.1.49, v6.1.48, v6.1.46, v6.1.45, v6.1.44, v6.1.43, v6.1.42, v6.1.41, v6.1.40, v6.1.39, v6.1.38, v6.1.37, v6.1.36, v6.4, v6.1.35, v6.1.34, v6.1.33, v6.1.32, v6.1.31, v6.1.30, v6.1.29, v6.1.28, v6.1.27, v6.1.26, v6.3, v6.1.25, v6.1.24, v6.1.23, v6.1.22, v6.1.21, v6.1.20, v6.1.19, v6.1.18, v6.1.17, v6.1.16, v6.1.15, v6.1.14, v6.1.13, v6.2, v6.1.12, v6.1.11, v6.1.10, v6.1.9, v6.1.8, v6.1.7, v6.1.6, v6.1.5, v6.0.19 |
|
#
8bb233b2 |
| 09-Jan-2023 |
Tzung-Bi Shih <tzungbi@kernel.org> |
platform/chrome: cros_ec_uart: fix negative type promoted to high
serdev_device_write_buf() returns negative numbers on errors. When the return value compares to unsigned integer `len`, it promotes
platform/chrome: cros_ec_uart: fix negative type promoted to high
serdev_device_write_buf() returns negative numbers on errors. When the return value compares to unsigned integer `len`, it promotes to quite large positive number.
Fix it.
Fixes: 04a8bdd135cc ("platform/chrome: cros_ec_uart: Add transport layer") Reported-by: Dan Carpenter <error27@gmail.com> Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org> Reviewed-by: Dan Carpenter <dan.carpenter@oracle.com> Reviewed-by: Benson Leung <bleung@chromium.org> Link: https://lore.kernel.org/r/20230109081554.3792547-1-tzungbi@kernel.org
show more ...
|
Revision tags: v6.0.18, v6.1.4, v6.1.3, v6.0.17, v6.1.2, v6.0.16 |
|
#
01f95d42 |
| 29-Dec-2022 |
Robert Zieba <robertzieba@google.com> |
platform/chrome: cros_ec_uart: fix race condition
serdev_device_set_client_ops() is called before `ec_dev` is fully initialized. This can result in cros_ec_uart_rx_bytes() being called while `ec_de
platform/chrome: cros_ec_uart: fix race condition
serdev_device_set_client_ops() is called before `ec_dev` is fully initialized. This can result in cros_ec_uart_rx_bytes() being called while `ec_dev` is still not initialized, resulting in a kernel panic.
Call serdev_device_set_client_ops() after `ec_dev` is initialized.
Fixes: 04a8bdd135cc ("platform/chrome: cros_ec_uart: Add transport layer") Signed-off-by: Robert Zieba <robertzieba@google.com> [tzungbi: modified commit message and fixed context conflict.] Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org> Reviewed-by: Guenter Roeck <groeck@chromium.org> Link: https://lore.kernel.org/r/20221229094738.2304044-1-tzungbi@kernel.org
show more ...
|
#
f9bce00f |
| 27-Dec-2022 |
Bhanu Prakash Maiya <bhanumaiya@chromium.org> |
platform/chrome: cros_ec_uart: Add DT enumeration support
Existing firmware uses the "PRP0001" _HID and an associated compatible string to enumerate the cros_ec_uart.
Add DT enumeration support for
platform/chrome: cros_ec_uart: Add DT enumeration support
Existing firmware uses the "PRP0001" _HID and an associated compatible string to enumerate the cros_ec_uart.
Add DT enumeration support for already shipped firmware.
Signed-off-by: Bhanu Prakash Maiya <bhanumaiya@chromium.org> Co-developed-by: Mark Hasemeyer <markhas@chromium.org> Signed-off-by: Mark Hasemeyer <markhas@chromium.org> Reviewed-by: Prashant Malani <pmalani@chromium.org> Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org> Link: https://lore.kernel.org/r/20221227123212.v13.3.Ie23c217d69ff25d7354db942613f143bbc8ef891@changeid
show more ...
|
#
04a8bdd1 |
| 27-Dec-2022 |
Bhanu Prakash Maiya <bhanumaiya@chromium.org> |
platform/chrome: cros_ec_uart: Add transport layer
This patch does following: 1. Adds a new cros-ec-uart driver. This driver can send EC requests on UART and process response packets received on
platform/chrome: cros_ec_uart: Add transport layer
This patch does following: 1. Adds a new cros-ec-uart driver. This driver can send EC requests on UART and process response packets received on UART transport. 2. Once probed, this driver will initialize the serdev device based on the underlying information in the ACPI resource. After serdev device properties are set, this driver will register itself cros-ec. 3. High level driver can use this implementation to talk to ChromeOS Embedded Controller device in case it supports UART as transport. 4. When cros-ec driver initiates a request packet, outgoing message is processed in buffer and sent via serdev. Once bytes are sent, driver enables a wait_queue. 5. Since ChromeOS EC device sends response asynchronously, AP's TTY driver accumulates response bytes and calls the registered callback. TTY driver can send multiple callback for bytes ranging from 1 to MAX bytes supported by EC device. 6. Driver waits for EC_MSG_DEADLINE_MS to collect and process received bytes. It wakes wait_queue if expected bytes are received or else wait_queue timeout. Based on the error condition, driver returns data_len or error to cros_ec.
Signed-off-by: Bhanu Prakash Maiya <bhanumaiya@chromium.org> Co-developed-by: Mark Hasemeyer <markhas@chromium.org> Signed-off-by: Mark Hasemeyer <markhas@chromium.org> Reviewed-by: Prashant Malani <pmalani@chromium.org> Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org> Link: https://lore.kernel.org/r/20221227123212.v13.1.If7926fcbad397bc6990dd725690229bed403948c@changeid
show more ...
|