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] [day] [month] [year] [list]
Date:	Mon, 04 May 2015 11:14:26 +0200
From:	Jean Delvare <jdelvare@...e.de>
To:	Sudip Mukherjee <sudipm.mukherjee@...il.com>
Cc:	Greg KH <gregkh@...uxfoundation.org>,
	Dan Carpenter <dan.carpenter@...cle.com>,
	One Thousand Gnomes <gnomes@...rguk.ukuu.org.uk>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH v4 WIP 2/4] i2c-parport: modify driver to use new
 parport device model

Le Monday 04 May 2015 à 12:54 +0530, Sudip Mukherjee a écrit :
> Thanks. This explained many of the doubts I was having. And I have one
> more doubt and I need some suggestion for it too.
> This current version of the code will register devices like :
> If i register i2c-parport0 with parport0 then the sys tree will be:
> 		sys
> 	 ________|____________
> 		| 
> 	     parport
> 	 _____|_______    
>          |           |
>      parport0   i2c-parport0
> 	|
>    i2c-parport0
> 
> so basically it registers as a subdevice of parport0 and also a device
> in the bus. And this is the reason why i needed the device_type.
> But i think it is wrong. I think it should have been just:
> 		sys
> 	 ________|____________
> 		| 
> 	     parport
> 	 _____|_______    
> 	      |          
> 	 parport0   
>             |
>       i2c-parport0
> 
> so, which one is actually correct?

This was a surprise for me at first too, but the former is correct.
i2c-parport0 appears below parport0 as a directory because it is a child
of it. And both parport0 and i2c-parport0 appear as _links_
under /sys/bus/parport/devices because they are respectively a provider
device and a consumer device of the parport bus type.

As a note, i2c-parport.0 might be a better name (bus ID, actually), for
several reasons. It makes things more readable if a device name ends
with digits (not the case here, but could happen, this is rather
frequent.) It looks more like platform device names, and consistency is
always nice to have. And it avoids the confusion between "parport0"
where 0 is the parallel port number and i2c-"parport0" where 0 is the
instance number of the i2c-parport device - it may be connected to
parport0 but it's only by chance and it may well be connected to another
parallel port.

-- 
Jean Delvare
SUSE L3 Support

--
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