linux-kernel - Re: [Kernel-discuss] Re: [RFC, PATCH 0/4] SoC base drivers

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]

Message-ID: <136343903.20070502163906@gmail.com>
Date:	Wed, 2 May 2007 16:39:06 +0300
From:	Paul Sokolovsky <pmiscml@...il.com>
To:	Dmitry Krivoschekov <dmitry.krivoschekov@...il.com>
CC:	ian <spyro@....com>, kernel-discuss@...dhelds.org,
	<linux-kernel@...r.kernel.org>,
	<linux-arm-kernel@...ts.arm.linux.org.uk>
Subject: Re: [Kernel-discuss] Re: [RFC, PATCH 0/4] SoC base drivers

Hello Dmitry,

Wednesday, May 2, 2007, 12:17:33 AM, you wrote:

> Hello Paul,

> Paul Sokolovsky wrote:
>>> ASIC-related code (I mean core) forms additional platform layer, so I
>>> suggest
>>> adding ASIC helpers to generic platform code i.e. drivers/platform.c, but
>>> ASIC drivers to drivers/asic/ directory.
>>
>>         There problem here is the same - our target chips are not
>> just ASICs. 

> You say they are chips so they are integrated circuits (ICs), they
> are designed to solve some specific needs, so they are
> application-specific ICs, i.e. ASICs, what's the problem?

        The issue is that in this case functional organization what's
important, not thing like (original) design purpose/method, expressed in
vague terms like ASIC. A "passive" (from CPU point of view) chip of
30-50 gates dealing with clock/control signals destribution is of
course ASIC too, but has nothing to do with chips in question.

>> It just happens that the one we start with called such,
>> but we have different ones too. 

> Interesting what are they?
> Power management ICs? Power management + audio
> + touchscreen + ADC + USB transceiver + UART + whatever
> all such chips may be considered as ASICs.

        "May" is a keyword here. They may be considered SoCs too, as
they share one important trait with them: multiple devices of
different functions in one package. I'd of course love idea of calling
any chip but CPU and memory an ASIC, but that doesn't correspond with
reality. As an example, ICH, etc chipsets are of course ASICs, but I
personally never heard them called such, and I'm sure few listeners
would be confused, if someone called them such.

>> It's still important that they contain
>> blocks with different functionality, and drivers we propose deal with
>> basic, common functionality of chips. 

> That different functionality blocks will be handled by appropriate
> device drivers, and in general the drivers should not depend on
> a particular ASIC but use common ASIC API.
> But "common functionality" drivers are ASIC-specific.

>> Now that it was pointed out that
>> there's place in the tree for such drivers, it would be not wise to
>> try to create another one.
>>
>>
>>

> Perhaps, so.  Actually, MFD  (multi functional device) doesn't
> imply a platform-level device but ASIC seems does.

        That's also a subject of interpretation for specific
chip/driver. Proposed soc-core is actually a helper, not a strict API
to follow. We just found that many our drivers do common things, so
factored out functionality for easier reuse. It of course can be
extended given the need (but yes, so far all our MFD chips and their
subdevices are treated as platform devices).


        But back from ontology to specific ideas of patch
restructuring. Given a need to distinguish discussed chips' handling
model from "generic" MFDs (like ones already in drivers/mfd/), and the
fact that Ian Molton, author of soc-core.*, likes ASIC designator, this
warrants rename of it to asic-core.*, I guess. All it still goes to
drivers/mfd/ to not create more stuff than needed.

        As for driver headers, they apparently go to include/linux/ .
That's of course keeps being out of hand, but small guy's way to
a solution is apparently to accelerate that. When number of files in
include/linux/ will hit 1K, I guess core maintainers will notice
that something's wrong and find a global solution. (One good idea is to
separate driver-specific headers from global and subsystem ones, but
all that is out of scope for this discussion...).



> Thanks,
> Dmitry




-- 
Best regards,
 Paul                            mailto:pmiscml@...il.com

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