linux-kernel - RE: [PATCH] mfd: ab8500-gpadc Add new GPADC driver

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: <F45880696056844FA6A73F415B568C6953738FAC5D@EXDCVYMBSTM006.EQ1STM.local>
Date:	Mon, 24 Jan 2011 04:37:08 +0100
From:	Arun MURTHY <arun.murthy@...ricsson.com>
To:	Mattias WALLIN <mattias.wallin@...ricsson.com>
Cc:	"sameo@...ux.intel.com" <sameo@...ux.intel.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Linus WALLEIJ <linus.walleij@...ricsson.com>,
	Srinidhi KASAGAR <srinidhi.kasagar@...ricsson.com>
Subject: RE: [PATCH] mfd: ab8500-gpadc Add new GPADC driver

> > Henceforth in order to secure the usage of GPADC, and in order to
> > restrict it to only EM and AUDIO sub-module, the gpadc device struct
> > was added to ab8500 struct. Also that the exported function
> > ab8500_gpadc_convert has an argument struct ab8500_gpadc, which can
> > be obtained be dereferencing the struct ab8500. This is possible only
> > with the ab8500 and its clients, thereby securing the usage to
> > battery driver and audio acc detect.
> Yes and I would like to remove this restriction and have a simpler more
> open api.
> First I don't like that users needs to do a lot of pointer
> dereferencing in their call like ab8500_gpadc_convert(dev->parent-
> >ab8500->gpadc, USB_CHARGER) (an example).

It's very much simple. All clients of ab500 will have a pointer to the
struct ab8500. Pointer to GPADC struct is an element in ab8500.
Hence it is something like  ab8500_gpadc_convert(di->ab8500->gpadc,
BAT_CTRL); I don't find anything complicated in this.

> I prefer a get function that returns a handle that should be used as
> first argument in the convert calls.
> It also makes sense if this driver will be extended to use more
> channels.

This is not possible. This is the limitation/the feature of the hardware.
It's not the software that limits the channel.
In the GPADC hardware, there are dedicated channel and also dedicatedly
allocated to the clients which are nothing but the battery parameters(
voltage, current, battery resistance, ac voltage, usb voltage) and the
audio acc. Apart from these no other peripheral or channel can use this.
It's not the restriction because of this implementation, but are the features
supported by the GPPDC hardware. Even if implemented considering your
comments, none other apart from the above mentioned can use(No extra
channels can be added and the existing channel are already hardwired hence
can't be modified/changed)  

> Second this driver will be used by for example accessories which likely
> will be called by 3 party drivers
This is not at all the 3rd part driver. Acc is part of audio block which
is a module in AB8500. Hence Audio will be a client of ab8500 mfd.

> and to make their life easier I don't want to force them to this
> ab8500-core dependency.
Its not that software is forcing or limiting the use to only ab8500
clients, but it's more the hardware feature.
Please refer the ab8500 datasheet for further details.

> I agree however that the users must be in above list and most of them
> are ab8500 devices already.
In that case there comes no instance where others apart from the ab8500
clients using this drivers.

Thanks and Regards,
Arun R Murthy
-------------
--
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/