drivers/net/can/usb/peak_usb/pcan_usb_core.c
Source file repositories/reference/linux-study-clean/drivers/net/can/usb/peak_usb/pcan_usb_core.c
File Facts
- System
- Linux kernel
- Corpus path
drivers/net/can/usb/peak_usb/pcan_usb_core.c- Extension
.c- Size
- 28452 bytes
- Lines
- 1154
- Domain
- Driver Families
- Bucket
- drivers/net
- Inferred role
- Driver Families: operation-table or driver-model contract
- Status
- pattern implementation candidate
Why This File Exists
Repeatable hardware-adapter layer. Deep compatibility for every driver is out of scope; this atlas records patterns, probe lifecycles, bus glue, IRQ/DMA usage, and links back to core abstractions.
- Repeatable hardware-adapter layer. Deep compatibility for every driver is out of scope; this atlas records patterns, probe lifecycles, bus glue, IRQ/DMA usage, and links back to core abstractions.
- Defines an operation table; this is where Linux turns generic core objects into subsystem-specific behavior.
- Uses kernel synchronization; read lock ordering, sleepability, and interrupt context assumptions before translating.
- Touches IRQ or DMA behavior; this matters for the representative real-device path.
- Allocates kernel memory; connect allocation flags and lifetime to context constraints.
- Defines or uses C structs; map object ownership, embedded links, reference counts, and lock ownership.
Dependency Surface
linux/device.hlinux/ethtool.hlinux/init.hlinux/module.hlinux/netdevice.hlinux/signal.hlinux/slab.hlinux/sysfs.hlinux/usb.hlinux/can.hlinux/can/dev.hlinux/can/error.hpcan_usb_core.h
Detected Declarations
function can_channel_id_showfunction pcan_dump_memfunction peak_usb_init_time_reffunction peak_usb_update_ts_nowfunction peak_usb_set_ts_nowfunction peak_usb_get_ts_timefunction wrapsfunction timefunction peak_usb_netif_rx_64function peak_usb_read_bulk_callbackfunction peak_usb_write_bulk_callbackfunction peak_usb_ndo_start_xmitfunction peak_usb_startfunction peak_usb_ndo_openfunction peak_usb_unlink_all_urbsfunction peak_usb_ndo_stopfunction peak_usb_restart_completefunction peak_usb_async_completefunction devicefunction peak_usb_set_modefunction peak_usb_set_bittimingfunction peak_usb_set_data_bittimingfunction peak_hwtstamp_getfunction peak_hwtstamp_setfunction peak_usb_get_eeprom_lenfunction peak_usb_get_eepromfunction peak_usb_set_eepromfunction pcan_get_ts_infofunction peak_usb_create_devfunction peak_usb_disconnectfunction peak_usb_probefunction peak_usb_initfunction peak_usb_do_device_exitfunction peak_usb_exitmodule init peak_usb_init
Annotated Snippet
static const struct net_device_ops peak_usb_netdev_ops = {
.ndo_open = peak_usb_ndo_open,
.ndo_stop = peak_usb_ndo_stop,
.ndo_start_xmit = peak_usb_ndo_start_xmit,
.ndo_hwtstamp_get = peak_hwtstamp_get,
.ndo_hwtstamp_set = peak_hwtstamp_set,
};
/* CAN-USB devices generally handle 32-bit CAN channel IDs.
* In case one doesn't, then it have to overload this function.
*/
int peak_usb_get_eeprom_len(struct net_device *netdev)
{
return sizeof(u32);
}
/* Every CAN-USB device exports the dev_get_can_channel_id() operation. It is used
* here to fill the data buffer with the user defined CAN channel ID.
*/
int peak_usb_get_eeprom(struct net_device *netdev,
struct ethtool_eeprom *eeprom, u8 *data)
{
struct peak_usb_device *dev = netdev_priv(netdev);
u32 ch_id;
__le32 ch_id_le;
int err;
err = dev->adapter->dev_get_can_channel_id(dev, &ch_id);
if (err)
return err;
/* ethtool operates on individual bytes. The byte order of the CAN
* channel id in memory depends on the kernel architecture. We
* convert the CAN channel id back to the native byte order of the PEAK
* device itself to ensure that the order is consistent for all
* host architectures.
*/
ch_id_le = cpu_to_le32(ch_id);
memcpy(data, (u8 *)&ch_id_le + eeprom->offset, eeprom->len);
/* update cached value */
dev->can_channel_id = ch_id;
return err;
}
/* Every CAN-USB device exports the dev_get_can_channel_id()/dev_set_can_channel_id()
* operations. They are used here to set the new user defined CAN channel ID.
*/
int peak_usb_set_eeprom(struct net_device *netdev,
struct ethtool_eeprom *eeprom, u8 *data)
{
struct peak_usb_device *dev = netdev_priv(netdev);
u32 ch_id;
__le32 ch_id_le;
int err;
/* first, read the current user defined CAN channel ID */
err = dev->adapter->dev_get_can_channel_id(dev, &ch_id);
if (err) {
netdev_err(netdev, "Failed to init CAN channel id (err %d)\n", err);
return err;
}
/* do update the value with user given bytes.
* ethtool operates on individual bytes. The byte order of the CAN
* channel ID in memory depends on the kernel architecture. We
* convert the CAN channel ID back to the native byte order of the PEAK
* device itself to ensure that the order is consistent for all
* host architectures.
*/
ch_id_le = cpu_to_le32(ch_id);
memcpy((u8 *)&ch_id_le + eeprom->offset, data, eeprom->len);
ch_id = le32_to_cpu(ch_id_le);
/* flash the new value now */
err = dev->adapter->dev_set_can_channel_id(dev, ch_id);
if (err) {
netdev_err(netdev, "Failed to write new CAN channel id (err %d)\n",
err);
return err;
}
/* update cached value with the new one */
dev->can_channel_id = ch_id;
return 0;
}
int pcan_get_ts_info(struct net_device *dev, struct kernel_ethtool_ts_info *info)
{
Annotation
- Immediate include surface: `linux/device.h`, `linux/ethtool.h`, `linux/init.h`, `linux/module.h`, `linux/netdevice.h`, `linux/signal.h`, `linux/slab.h`, `linux/sysfs.h`.
- Detected declarations: `function can_channel_id_show`, `function pcan_dump_mem`, `function peak_usb_init_time_ref`, `function peak_usb_update_ts_now`, `function peak_usb_set_ts_now`, `function peak_usb_get_ts_time`, `function wraps`, `function time`, `function peak_usb_netif_rx_64`, `function peak_usb_read_bulk_callback`.
- Atlas domain: Driver Families / drivers/net.
- Implementation status: pattern implementation candidate.
- Synchronization appears in or near this file; preserve lock ordering, sleepability, and interrupt-context constraints.
- IRQ or DMA behavior appears here, which is relevant to the selected PCIe/NVMe device path.
Implementation Notes
- This generated page is the file-by-file coverage layer; curated subsystem chapters should link here when they synthesize a multi-file control flow.
- Core OS pages should be promoted from atlas-only to deep-reviewed when they explain data structures, invariants, locking, lifecycle, and C implementation snippets.
- Driver-family pages are intentionally pattern-oriented unless they are part of the selected PCIe/NVMe representative device path.