| 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
| ||
|
Message-ID: <7228146.FsqiNq1Vpj@wuerfel>
Date: Thu, 17 Jul 2014 12:17 +0200
From: Arnd Bergmann <arnd@...db.de>
To: Greg KH <greg@...ah.com>
Cc: Stephen Boyd <sboyd@...eaurora.org>, linux-kernel@...r.kernel.org,
linux-mmc@...r.kernel.org,
"linux-arm-msm@...r.kernel.org" <linux-arm-msm@...r.kernel.org>,
Alexander Kolesnikov <akolesni@...eaurora.org>,
Konstantin Dorfman <kdorfman@...eaurora.org>
Subject: Re: char interface to sdio, chdio.c
On Wednesday 16 July 2014 22:33:47 Greg KH wrote:
> + mmc: Char SDIO Device Driver
A few comments on the ioctl interface, since I suppose we'll have
to live with that once it gets merged.
> +Interface
> +=========
> +The Char SDIO Device Driver has two char device interfaces:
> + - Control Interface;
> + - Function Interface.
> +
> +Char SDIO Device Driver Control Interface consists of:
> + - open() - device node is /dev/csdio0;
> + - close()
> + - ioctl() - the following options are available:
> + - CSDIO_IOC_ENABLE_HIGHSPEED_MODE;
> + - CSDIO_IOC_SET_DATA_TRANSFER_CLOCKS;
> + - CSDIO_IOC_ENABLE_ISR;
> + - CSDIO_IOC_DISABLE_ISR.
The documentation doesn't match the code.:
CSDIO_IOC_GET/SET_VDD are implemented in the control device,
not the function device, and that is probably a good idea.
CSDIO_IOC_ENABLE_HIGHSPEED_MODE is not implemented
at all. CSDIO_IOC_ENABLE_ISR seems redundant with what
the CSDIO_IOC_{DIS,}CONNECT_ISR functions do, but I could be
wrong here.
The sysfs interface may actually be more appropriate than the
control node, if I was to pick one of the two.
> +Char SDIO Device Driver Function Interface consists of:
> + - open() - device node is /dev/csdiofX, where X is Function Id;
> + - close()
> + - read() - send CMD53 read;
> + - write() - send CMD53 write;
> + - ioctl() - the following options are available:
> + - CSDIO_IOC_SET_OP_CODE - 0 fixed adrress, 1 autoincrement.
> + - CSDIO_IOC_FUNCTION_SET_BLOCK_SIZE;
> + - CSDIO_IOC_SET_BLOCK_MODE - 0 byte mode, 1 block mode;
> + - CSDIO_IOC_CMD52 - execute CMD52, receives the
> + following structure as a parameter:
> + struct csdio_cmd52_ctrl_t {
> + uint32_t m_write; // 0 - read, 1 -write
> + uint32_t m_address;
> + uint32_t m_data; // data to write or read data
> + uint32_t m_ret; // command execution status
> + }__attribute__ ((packed));
> + - CSDIO_IOC_CMD53 - setup CMD53 data transfer, receives the
> + following structure as a parameter:
> + struct csdio_cmd53_ctrl_t {
> + uint32_t m_block_mode;
> + uint32_t m_op_code;
> + uint32_t m_address;
> + }__attribute__ ((packed));
> + - CSDIO_IOC_CONNECT_ISR;
> + - CSDIO_IOC_DISCONNECT_ISR;
> + - CSDIO_IOC_GET_VDD;
> + - CSDIO_IOC_SET_VDD.
> +
> +Additionally, user space application can use fcntl system call with
> +parameters F_SETOWN and F_SETFL in order to set an asynchronous
> +callback for SDIO interrupt.
The read/write API seems very strange. SDIO has multiple ways of
passing data between OS and device using CMD52 and CMD53, and they
are all done differently here:
- A one-byte read or write uses a single CSDIO_IOC_CMD52 ioctl.
This could be done using pread/pwrite with length '1' rather than
an ioctl, if we want to.
- a byte-addressed multi-byte read/write needs to first 'seek' using
CSDIO_IOC_CMD53 or and then transfer using read() or write().
- a block-addressed read/write is similar, but the number of bytes
copied to/from user space is now multiplied with the block size (!).
The block size needs to be set using both CSDIO_IOC_SET_BLOCK_MODE
and CSDIO_IOC_CMD53, using the same value.
- to do a multi-byte read/write at a constant address rather than
a block copy, CSDIO_IOC_CMD53 needs to set at least one bit (not
necessarily the one used in the actual command) in m_op_code.
I guess all of this could be done using pread/pwrite, using the
loff_t value to encode the m_address in the lower bits and the
mode (single-byte, multi-byte, multi-byte auto-increment,
block, block auto-increment) in some of the upper bits.
Alternatively, the read/write functions could be removed completely
and everything be done in the ioctls, but in a more consistent
way.
> +
> +#define CSDIO_IOC_MAGIC 'm'
> +
> +#define CSDIO_IOC_ENABLE_HIGHSPEED_MODE _IO(CSDIO_IOC_MAGIC, 0)
> +#define CSDIO_IOC_SET_DATA_TRANSFER_CLOCKS _IO(CSDIO_IOC_MAGIC, 1)
> +#define CSDIO_IOC_SET_OP_CODE _IO(CSDIO_IOC_MAGIC, 2)
> +#define CSDIO_IOC_FUNCTION_SET_BLOCK_SIZE _IO(CSDIO_IOC_MAGIC, 3)
> +#define CSDIO_IOC_SET_BLOCK_MODE _IO(CSDIO_IOC_MAGIC, 4)
> +#define CSDIO_IOC_CONNECT_ISR _IO(CSDIO_IOC_MAGIC, 5)
> +#define CSDIO_IOC_DISCONNECT_ISR _IO(CSDIO_IOC_MAGIC, 6)
> +#define CSDIO_IOC_CMD52 _IO(CSDIO_IOC_MAGIC, 7)
> +#define CSDIO_IOC_CMD53 _IO(CSDIO_IOC_MAGIC, 8)
> +#define CSDIO_IOC_ENABLE_ISR _IO(CSDIO_IOC_MAGIC, 9)
> +#define CSDIO_IOC_DISABLE_ISR _IO(CSDIO_IOC_MAGIC, 10)
> +#define CSDIO_IOC_SET_VDD _IO(CSDIO_IOC_MAGIC, 11)
> +#define CSDIO_IOC_GET_VDD _IO(CSDIO_IOC_MAGIC, 12)
> +
> +#define CSDIO_IOC_MAXNR 12
The command codes above should use _IOR or _IOW where appropriate to
encode the size of the transferred data.
> +
> +struct csdio_cmd53_ctrl_t {
> + uint32_t m_block_mode; /* data tran. byte(0)/block(1) mode */
> + uint32_t m_op_code; /* address auto increment flag */
> + uint32_t m_address;
> +} __attribute__ ((packed));
> +
> +struct csdio_cmd52_ctrl_t {
> + uint32_t m_write;
> + uint32_t m_address;
> + uint32_t m_data;
> + uint32_t m_ret;
> +} __attribute__ ((packed));
The packing is not necessary here, but at least all of these are
compatible between 32 and 64 bit, so enabling compat mode is a one-line
change and requires no conversion.
Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists