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
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Wed, 20 Aug 2014 21:53:00 +0200
From:	Arnd Bergmann <arnd@...db.de>
To:	Daniel Baluta <daniel.baluta@...el.com>
Cc:	gregkh@...uxfoundation.org, linux-usb@...r.kernel.org,
	wsa@...-dreams.de, linux-i2c@...r.kernel.org,
	linus.walleij@...aro.org, gnurou@...il.com,
	linux-gpio@...r.kernel.org, pratyush.anand@...com,
	pebolle@...cali.nl, stern@...land.harvard.edu,
	octavian.purdila@...el.com, matthew@...systems.ca,
	linux-kernel@...r.kernel.org, laurentiu.palcu@...el.com,
	jdelvare@...e.de, sjg@...omium.org
Subject: Re: [PATCH 1/3] usb: add support for Diolan DLN-2 devices

On Wednesday 20 August 2014, Daniel Baluta wrote:
> From: Octavian Purdila <octavian.purdila@...el.com>
> 
> This patch implements the USB part of the Diolan USB-I2C/SPI/GPIO
> Master Adapter DLN-2. Details about the device can be found here:
> 
> https://www.diolan.com/i2c/i2c_interface.html.
> 
> Information about the USB protocol can be found in the Programmer's
> Reference Manual [1], see section 1.7.
> 
> Because the hardware has a single transmit endpoint and a single
> receive endpoint the communication between the various DLN2 drivers
> and the hardware will be muxed/demuxed by this driver.
> 
> The functional DLN2 drivers (i2c, GPIO, etc.) will have to register
> themselves as DLN2 modules in order to send or receive data.
> 
> Each DLN2 module will be identified by the handle field within the DLN2
> message header. If a DLN2 module issues multiple commands in parallel
> they will be identified by the echo counter field in the message header.
> 
> The DLN2 modules can use the dln2_transfer() function to issue a
> command and wait for its response. They can also use an asynchronous
> mode of operation, in which case a receive callback function is going
> to be notified when messages for a specific handle are received.
> 
> Because the hardware reserves handle 0 for GPIO events, the driver
> also reserves handle 0. It will be allocated to a DLN2 module only if
> it is explicitly requested.
> 
> [1] https://www.diolan.com/downloads/dln-api-manual.pdf
> 
> Signed-off-by: Octavian Purdila <octavian.purdila@...el.com>

After a very brief review of the driver, I think this would be better
handled as an MFD driver in drivers/mfd that creates child devices and
has the high-level drivers get registered as platform_driver.

	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

Powered by Openwall GNU/*/Linux Powered by OpenVZ