netdev - Re: ixp4xx_hss MAX_CHAN

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <m3tz9wsmut.fsf@maximus.localdomain>
Date:	Tue, 25 Nov 2008 00:52:42 +0100
From:	Krzysztof Halasa <khc@...waw.pl>
To:	Miguel Ángel Álvarez <gotzoncabanes@...il.com>
Cc:	netdev@...r.kernel.org, linux-arm-kernel@...ts.arm.linux.org.uk
Subject: Re: ixp4xx_hss MAX_CHAN_DEVICES

"Miguel Ángel Álvarez" <gotzoncabanes@...il.com> writes:

> I am not quite sure about this. If we do not set the clock_rate as
> part of the "physical_mode"... where should it be set? As a separate
> variable?

I think so. In most cases the external clock will be used anyway.

> Is this what you are stating? a separate variable for clock_rate in
> the platform structure?
>
>>> +static const struct physical_modes phmodes[] = {
>>> +     {IXP4XX_HSS_T1, 193, 1544000, CLK42X_SPEED_1544KHZ},
>>> +     {IXP4XX_HSS_E1, 256, 2048000, CLK42X_SPEED_2048KHZ},
>>> +     {IXP4XX_HSS_2_E1, 512, 4096000, CLK42X_SPEED_4096KHZ},
>>> +     {IXP4XX_HSS_4_E1, 1024, 8192000, CLK42X_SPEED_8192KHZ},
>>> +     {0, 256, 2048000, CLK42X_SPEED_2048KHZ}
>>> +};

No. The HSS driver already has code for the clock rate. Unfortunately
it doesn't yet know how to set the register.

There is IMHO one thing missing from the platform struct: the
physical mode, aka topology; a single integer. Possible values:
a) direct connection to HSS, b) HSS connected to a 4 * E1 MVIP framer,
c) 4 * T1 MVIP, d+) other similar variants (perhaps 2 * E1, 2 * T1).

>> T1 and E1 are the same WRT hardware connection to the port.
>>
> I have done the difference for the clock_rates and the needing of a
> framing bit in the case of T1.

Sure, but: clock rate is independent anyway, and the framing bit can be
requested by using 193 bits of frame (IIRC this is how the code
currently works but I'd have to check for sure).

> OK. Thanks... However... shouldn't they be the same value... I mean...
> It could be possible to have a device for each channel in the frame,
> not? So, for example if I had 128 channels (4*E1), it could be
> required to deal with 128 devices, not? (In channelized mode).

Sure (though I don't know how efficient would that be).

The truth is the HSS channelized code is quite experimental. It works,
and I actually use it, but I haven't yet decided about the API and
this is why it isn't still upstream.

HDLC HSS code is IMHO stable and could be submitted upstream, I will
do it sometime.

> Sure... Let me re-do the question. Do you know how MVIP is set if I
> detect it is needed? And... good idea with the registering of four
> devices.

The platform code should provide the "mode" (aka topology) = "4 * E1".
There is nothing to detect. The driver has to handle 4E1, that's all.
-- 
Krzysztof Halasa
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html