lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Tue, 29 Apr 2014 08:51:26 +0200 From: Stefan Wahren <stefan.wahren@...e.com> To: Arnd Bergmann <arnd@...db.de> CC: davem@...emloft.net, robh+dt@...nel.org, pawel.moll@....com, mark.rutland@....com, ijc+devicetree@...lion.org.uk, galak@...eaurora.org, f.fainelli@...il.com, netdev@...r.kernel.org, devicetree@...r.kernel.org Subject: Re: [PATCH RFC 2/2] net: qualcomm: new Ethernet over SPI driver for QCA7000 Hi, Am 28.04.2014 22:09, schrieb Arnd Bergmann: > On Monday 28 April 2014 19:54:57 Stefan Wahren wrote: >> +/* Dumps the contents of all SPI slave registers. */ >> +static int >> +qcaspi_regs_dump(struct seq_file *s, void *what) >> +{ >> + struct reg { >> + char *name; >> + u32 address; >> + }; >> + >> + static struct reg regs[] = { >> + { "SPI_REG_BFR_SIZE", SPI_REG_BFR_SIZE }, >> + { "SPI_REG_WRBUF_SPC_AVA", SPI_REG_WRBUF_SPC_AVA }, >> + { "SPI_REG_RDBUF_BYTE_AVA", SPI_REG_RDBUF_BYTE_AVA }, >> + { "SPI_REG_SPI_CONFIG", SPI_REG_SPI_CONFIG }, >> + { "SPI_REG_SPI_STATUS", SPI_REG_SPI_STATUS }, >> + { "SPI_REG_INTR_CAUSE", SPI_REG_INTR_CAUSE }, >> + { "SPI_REG_INTR_ENABLE", SPI_REG_INTR_ENABLE }, >> + { "SPI_REG_RDBUF_WATERMARK", SPI_REG_RDBUF_WATERMARK }, >> + { "SPI_REG_WRBUF_WATERMARK", SPI_REG_WRBUF_WATERMARK }, >> + { "SPI_REG_SIGNATURE", SPI_REG_SIGNATURE }, >> + { "SPI_REG_ACTION_CTRL", SPI_REG_ACTION_CTRL } >> + }; >> + >> + struct qcaspi *qca = s->private; >> + int i; >> + >> + for (i = 0; i < (sizeof(regs) / sizeof(struct reg)); i++) { >> + u16 value; >> + >> + qcaspi_read_register(qca, regs[i].address, &value); >> + seq_printf(s, "%-25s(0x%04x): 0x%04x\n", >> + regs[i].name, regs[i].address, value); >> + } >> + >> + return 0; >> +} > Shouldn't these just come through ethtool --register-dump ? yes, that's right. But from my point of view this have 2 disadvantages: - the interface to ethtool needs to be maintained (i'm not sure if i have all debug information) - the target platform needs ethtool > >> +static irqreturn_t >> +qcaspi_intr_handler(int irq, void *data) >> +{ >> + struct qcaspi *qca = (struct qcaspi *) data; >> + qca->intr_req++; >> + if (qca->spi_thread && >> + qca->spi_thread->state != TASK_RUNNING) >> + wake_up_process(qca->spi_thread); >> + >> + return IRQ_HANDLED; >> +} > What is the advantage of using your own thread mechanism for receiving > data instead of the normal NAPI method? > > Arnd > This mechanism comes from Qualcomm and was originally designed for Kernel 2.6.35. I never talked to them. Currently i don't know how to port this driver to NAPI. It sounds to me, that's a lot of work and i need more knowledge. Is there a porting guide for NAPI? Does this mean the current state of the driver should better go to staging? Kind regards, Stefan -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists