| 5a191431 | 14-Mar-2025 |
Haibo Chen <haibo.chen@nxp.com> |
can: flexcan: disable transceiver during system PM
During system PM, if no wakeup requirement, disable transceiver to save power.
Fixes: 4de349e786a3 ("can: flexcan: fix resume function") Cc: stabl
can: flexcan: disable transceiver during system PM
During system PM, if no wakeup requirement, disable transceiver to save power.
Fixes: 4de349e786a3 ("can: flexcan: fix resume function") Cc: stable@vger.kernel.org Reviewed-by: Frank Li <frank.li@nxp.com> Signed-off-by: Haibo Chen <haibo.chen@nxp.com> Link: https://patch.msgid.link/20250314110145.899179-2-haibo.chen@nxp.com [mkl: add newlines] Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
show more ...
|
| 8503a4b1 | 13-Jan-2025 |
Ciprian Marian Costea <ciprianmarian.costea@oss.nxp.com> |
can: flexcan: add NXP S32G2/S32G3 SoC support
Add device type data for S32G2/S32G3 SoC.
FlexCAN module from S32G2/S32G3 is similar with i.MX SoCs, but interrupt management is different.
On S32G2/S
can: flexcan: add NXP S32G2/S32G3 SoC support
Add device type data for S32G2/S32G3 SoC.
FlexCAN module from S32G2/S32G3 is similar with i.MX SoCs, but interrupt management is different.
On S32G2/S32G3 SoC, there are separate interrupts for state change, bus errors, Mailboxes 0-7 and Mailboxes 8-127 respectively. In order to handle this FlexCAN hardware particularity, first reuse the 'FLEXCAN_QUIRK_NR_IRQ_3' quirk provided by mcf5441x's irq handling support. Secondly, use the newly introduced 'FLEXCAN_QUIRK_SECONDARY_MB_IRQ' quirk which handles the case where two separate mailbox ranges are controlled by independent hardware interrupt lines.
Signed-off-by: Ciprian Marian Costea <ciprianmarian.costea@oss.nxp.com> Link: https://patch.msgid.link/20250113120704.522307-4-ciprianmarian.costea@oss.nxp.com Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
show more ...
|
| 409c188c | 27-Jul-2022 |
Vincent Mailhol <mailhol.vincent@wanadoo.fr> |
can: tree-wide: advertise software timestamping capabilities
Currently, some CAN drivers support hardware timestamping, some do not. But userland has no method to query which features are supported
can: tree-wide: advertise software timestamping capabilities
Currently, some CAN drivers support hardware timestamping, some do not. But userland has no method to query which features are supported (aside maybe of getting RX messages and observe whether or not hardware timestamps stay at zero).
The canonical way for a network driver to advertised what kind of timestamping it supports is to implement ethtool_ops::get_ts_info().
This patch only targets the CAN drivers which *do not* support hardware timestamping. For each of those CAN drivers, implement the get_ts_info() using the generic ethtool_op_get_ts_info().
This way, userland can do:
| $ ethtool --show-time-stamping canX
to confirm the device timestamping capacities.
N.B. the drivers which support hardware timestamping will be migrated in separate patches.
Signed-off-by: Vincent Mailhol <mailhol.vincent@wanadoo.fr> Link: https://lore.kernel.org/all/20220727101641.198847-6-mailhol.vincent@wanadoo.fr [mkl: mscan: add missing mscan_ethtool_ops] Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
show more ...
|