netdev - Re: [PATCH v3 2/8] net: dsa: Add DSA driver for Hirschmann Hellcreek switches

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: <87eenv14bt.fsf@kurt>
Date:   Tue, 25 Aug 2020 11:07:34 +0200
From:   Kurt Kanzenbach <kurt@...utronix.de>
To:     Andrew Lunn <andrew@...n.ch>
Cc:     Vivien Didelot <vivien.didelot@...il.com>,
        Florian Fainelli <f.fainelli@...il.com>,
        "David S. Miller" <davem@...emloft.net>,
        Jakub Kicinski <kuba@...nel.org>, netdev@...r.kernel.org,
        Rob Herring <robh+dt@...nel.org>, devicetree@...r.kernel.org,
        Sebastian Andrzej Siewior <bigeasy@...utronix.de>,
        Richard Cochran <richardcochran@...il.com>,
        Kamil Alkhouri <kamil.alkhouri@...offenburg.de>,
        ilias.apalodimas@...aro.org, Vladimir Oltean <olteanv@...il.com>
Subject: Re: [PATCH v3 2/8] net: dsa: Add DSA driver for Hirschmann Hellcreek switches

On Tue Aug 25 2020, Andrew Lunn wrote:
[snip]
>>  
>>  source "drivers/net/dsa/sja1105/Kconfig"
>>  
>> +source "drivers/net/dsa/hirschmann/Kconfig"
>> +
>>  config NET_DSA_QCA8K
>>  	tristate "Qualcomm Atheros QCA8K Ethernet switch family support"
>>  	depends on NET_DSA
>
> Hi Kurt
>
> The DSA entries are sorted into alphabetic order based on what you see
> in make menuconfig. As such, "Hirschmann Hellcreek TSN Switch support"
> fits in between "DSA mock-up Ethernet switch chip support" and "Lantiq
> / Intel GSWIP"

Yes, of course. I've only sorted the entries in the previous patch...

>
>> diff --git a/drivers/net/dsa/Makefile b/drivers/net/dsa/Makefile
>> index 4a943ccc2ca4..a707ccc3a940 100644
>> --- a/drivers/net/dsa/Makefile
>> +++ b/drivers/net/dsa/Makefile
>> @@ -23,3 +23,4 @@ obj-y				+= mv88e6xxx/
>>  obj-y				+= ocelot/
>>  obj-y				+= qca/
>>  obj-y				+= sja1105/
>> +obj-y				+= hirschmann/
>
> This file is also sorted. 
>
>> +static int hellcreek_detect(struct hellcreek *hellcreek)
>> +{
>> +	u16 id, rel_low, rel_high, date_low, date_high, tgd_ver;
>> +	u8 tgd_maj, tgd_min;
>> +	u32 rel, date;
>> +
>> +	id	  = hellcreek_read(hellcreek, HR_MODID_C);
>> +	rel_low	  = hellcreek_read(hellcreek, HR_REL_L_C);
>> +	rel_high  = hellcreek_read(hellcreek, HR_REL_H_C);
>> +	date_low  = hellcreek_read(hellcreek, HR_BLD_L_C);
>> +	date_high = hellcreek_read(hellcreek, HR_BLD_H_C);
>> +	tgd_ver   = hellcreek_read(hellcreek, TR_TGDVER);
>> +
>> +	if (id != HELLCREEK_MODULE_ID)
>> +		return -ENODEV;
>
> Are there other Hellcreek devices? I'm just wondering if we should
> have a specific compatible for 0x4c30 as well as the more generic 
> "hirschmann,hellcreek".

Yes, there will be different revisions of the Hellcreek devices. This ID
is really device specific. A lot of features of this switch are
configured in the VHDL code. For instance the MAC settings (100 or 1000
Mbit/s).

I've discussed this with the HW engineer from Hirschmann. He suggested
to keep this check here, as the driver is currently specific for the
that device. We have to make sure that the driver matches the hardware.

My plan was to extend this when I have access to other revisions. There
will be a SPI variant as well. But, I didn't want to implement it without the
ability to test it.

>
>> +static void hellcreek_get_ethtool_stats(struct dsa_switch *ds, int port,
>> +					uint64_t *data)
>> +{
>> +	struct hellcreek *hellcreek = ds->priv;
>> +	struct hellcreek_port *hellcreek_port;
>> +	unsigned long flags;
>> +	int i;
>> +
>> +	hellcreek_port = &hellcreek->ports[port];
>> +
>> +	spin_lock_irqsave(&hellcreek->reg_lock, flags);
>> +	for (i = 0; i < ARRAY_SIZE(hellcreek_counter); ++i) {
>> +		const struct hellcreek_counter *counter = &hellcreek_counter[i];
>> +		u8 offset = counter->offset + port * 64;
>> +		u16 high, low;
>> +		u64 value = 0;
>> +
>> +		hellcreek_select_counter(hellcreek, offset);
>> +
>> +		/* The registers are locked internally by selecting the
>> +		 * counter. So low and high can be read without reading high
>> +		 * again.
>> +		 */
>
> Is there any locking/snapshot of all the counters at once? Most
> devices have support for that, so you can compare counters against
> each other.

No, there is not.

Thanks,
Kurt

Download attachment "signature.asc" of type "application/pgp-signature" (833 bytes)