linux-kernel - Re: [RFC PATCHv2 1/4] drivers/otp: add initial support for OTP memory

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:	Sat, 26 Mar 2011 00:02:19 +0100
From:	Arnd Bergmann <arnd@...db.de>
To:	Jamie Iles <jamie@...ieiles.com>
Cc:	Mike Frysinger <vapier@...too.org>, linux-kernel@...r.kernel.org,
	gregkh@...e.de
Subject: Re: [RFC PATCHv2 1/4] drivers/otp: add initial support for OTP memory

On Friday 25 March 2011 23:52:20 Jamie Iles wrote:
> That's what I intended but I guess it isn't that clear from the code.  
> Perhaps instead of:
> 
>         mutex_lock();
>         region->ops->ioctl();
>         mutex_unlock();
> 
> if I change it to:
> 
>         mutex_lock();
>         switch (cmd) {
>         default:
>                 region->ops->ioctl();
>         }
>         mutex_unlock();
> 
> then that's a bit clearer.  If there's stuff common across different OTP 
> implementations then we can add it to the region ops and decode it here 
> and if not fall back to the specific implementation.

This will make it a lot harder to support compat_ioctl as well.
Just drop the ->ioctl callback into the driver and make one
callback per command. Any command that could be reused on
another driver will then be defined in the common header file
already and just work on new drivers.

If you are tempted to add commands that cannot possibly work
on other hardware, that is usually a good indication that this
command should not be added, or should be generalized in some way.

	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/