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]
Message-ID: <4FB10821.4000004@linaro.org>
Date:	Mon, 14 May 2012 21:26:57 +0800
From:	"Ying-Chun Liu (PaulLiu)" <paul.liu@...aro.org>
To:	Shawn Guo <shawn.guo@...escale.com>
CC:	Mark Brown <broonie@...nsource.wolfsonmicro.com>,
	Richard Zhao <richard.zhao@...aro.org>,
	linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
	Richard Zhao <richard.zhao@...escale.com>,
	sameo@...ux.intel.com, shawn.guo@...aro.org
Subject: Re: [PATCH 2/2] mfd: anatop: permit adata be NULL when access register

(2012年05月14日 17:43), Shawn Guo wrote:
> On Mon, May 14, 2012 at 05:01:08PM +0800, Ying-Chun Liu (PaulLiu) wrote:
>> I think what the concern is we probably don't want several
>> non-continuous memory blocks of misc hardwares.
>> If we look into the current registers in anatop, it is really sparse.
>> Several regulators are using non-continuous address and the thermals are
>> also using different addresses. If the addresses are continuous then we
>> don't need the mfd driver.
>>
> I do not quite follow that.  The reason we need mfd driver isn't because
> we do not want to both regulator and thermal drivers to map and access
> the same address on their own which may have synchronization issue?
> 

Not sure about the synchronization issue. But currently thermal driver
in Linaro kernel do map and access the same address on its own now. It
is not a device driver yet and just access the address directly and
work. It seems to me that each different type of misc devices in Anatop
just work alone.

So let's go back to the patch. Why do we need this modification? Anatop
thermal driver can be written as a device driver and don't need this
patch. And we might get benefits when thermal driver written in this
way. Especially some boards do not have a correct fuse data. Any real
use cases of this patch?

Yours Sincerely,
Paul
--
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