drivers/net/ethernet/smsc/smc91x.h
Source file repositories/reference/linux-study-clean/drivers/net/ethernet/smsc/smc91x.h
File Facts
- System
- Linux kernel
- Corpus path
drivers/net/ethernet/smsc/smc91x.h- Extension
.h- Size
- 32195 bytes
- Lines
- 1089
- Domain
- Driver Families
- Bucket
- drivers/net
- Inferred role
- Driver Families: implementation source
- Status
- source 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.
- Touches IRQ or DMA behavior; this matters for the representative real-device path.
- Defines or uses C structs; map object ownership, embedded links, reference counts, and lock ownership.
Dependency Surface
linux/dmaengine.hlinux/smc91x.hasm/mach-types.hlinux/dma-mapping.h
Detected Declarations
struct smc_localfunction _SMC_outw_align4function IS_BUILTINfunction mcf_outswfunction smc_pxa_dma_inpumpfunction smc_pxa_dma_inslfunction smc_pxa_dma_insw
Annotated Snippet
struct smc_local {
/*
* If I have to wait until memory is available to send a
* packet, I will store the skbuff here, until I get the
* desired memory. Then, I'll send it out and free it.
*/
struct sk_buff *pending_tx_skb;
struct tasklet_struct tx_task;
struct gpio_desc *power_gpio;
struct gpio_desc *reset_gpio;
/* version/revision of the SMC91x chip */
int version;
/* Contains the current active transmission mode */
int tcr_cur_mode;
/* Contains the current active receive mode */
int rcr_cur_mode;
/* Contains the current active receive/phy mode */
int rpc_cur_mode;
int ctl_rfduplx;
int ctl_rspeed;
u32 msg_enable;
u32 phy_type;
struct mii_if_info mii;
/* work queue */
struct work_struct phy_configure;
struct net_device *dev;
int work_pending;
spinlock_t lock;
#ifdef CONFIG_ARCH_PXA
/* DMA needs the physical address of the chip */
u_long physaddr;
struct device *device;
#endif
struct dma_chan *dma_chan;
void __iomem *base;
void __iomem *datacs;
/* the low address lines on some platforms aren't connected... */
int io_shift;
/* on some platforms a u16 write must be 4-bytes aligned */
bool half_word_align4;
struct smc91x_platdata cfg;
};
#define SMC_8BIT(p) ((p)->cfg.flags & SMC91X_USE_8BIT)
#define SMC_16BIT(p) ((p)->cfg.flags & SMC91X_USE_16BIT)
#define SMC_32BIT(p) ((p)->cfg.flags & SMC91X_USE_32BIT)
#ifdef CONFIG_ARCH_PXA
/*
* Let's use the DMA engine on the XScale PXA2xx for RX packets. This is
* always happening in irq context so no need to worry about races. TX is
* different and probably not worth it for that reason, and not as critical
* as RX which can overrun memory and lose packets.
*/
#include <linux/dma-mapping.h>
#ifdef SMC_insl
#undef SMC_insl
#define SMC_insl(a, r, p, l) \
smc_pxa_dma_insl(a, lp, r, dev->dma, p, l)
static inline void
smc_pxa_dma_inpump(struct smc_local *lp, u_char *buf, int len)
{
dma_addr_t dmabuf;
struct dma_async_tx_descriptor *tx;
dma_cookie_t cookie;
enum dma_status status;
struct dma_tx_state state;
dmabuf = dma_map_single(lp->device, buf, len, DMA_FROM_DEVICE);
tx = dmaengine_prep_slave_single(lp->dma_chan, dmabuf, len,
DMA_DEV_TO_MEM, 0);
if (tx) {
cookie = dmaengine_submit(tx);
dma_async_issue_pending(lp->dma_chan);
do {
status = dmaengine_tx_status(lp->dma_chan, cookie,
&state);
cpu_relax();
Annotation
- Immediate include surface: `linux/dmaengine.h`, `linux/smc91x.h`, `asm/mach-types.h`, `linux/dma-mapping.h`.
- Detected declarations: `struct smc_local`, `function _SMC_outw_align4`, `function IS_BUILTIN`, `function mcf_outsw`, `function smc_pxa_dma_inpump`, `function smc_pxa_dma_insl`, `function smc_pxa_dma_insw`.
- Atlas domain: Driver Families / drivers/net.
- Implementation status: source implementation candidate.
- 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.