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
Attachment:
signature.asc
Description: PGP signature
