History log of /openbmc/linux/drivers/platform/chrome/cros_ec_uart.c (Results 1 – 14 of 14)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
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 ...