Hi Andrew,
First of all, thanks for taking the time to look at the code so
extensively.
On 3/3/24 18:29, Andrew Lunn wrote:
>> +enum {
>> + AIR_PHY_LED_DUR_BLINK_32M,
>> + AIR_PHY_LED_DUR_BLINK_64M,
>> + AIR_PHY_LED_DUR_BLINK_128M,
>> + AIR_PHY_LED_DUR_BLINK_256M,
>> + AIR_PHY_LED_DUR_BLINK_512M,
>> + AIR_PHY_LED_DUR_BLINK_1024M,
>
> DUR meaning duration? It has a blinks on for a little over a
> kilometre? So a wave length of a little over 2 kilometres, or a
> frequency of around 0.0005Hz :-)
It is the M for milliseconds. I can add a comment to clarify this.
If you set to 1024M, it will blink with a period of a roughly 1 second.
>> +static int __air_buckpbus_reg_write(struct phy_device *phydev,
>> + u32 pbus_address, u32 pbus_data,
>> + bool set_mode)
>> +{
>> + int ret;
>> +
>> + if (set_mode) {
>> + ret = __phy_write(phydev, AIR_BPBUS_MODE,
>> + AIR_BPBUS_MODE_ADDR_FIXED);
>> + if (ret < 0)
>> + return ret;
>> + }
>
> What does set_mode mean?
I use this boolean to prevent writing the same value twice to the
AIR_BPBUS_MODE register, when doing an atomic modify operation. The
AIR_BPBUS_MODE is already set in the read operation, so it does not
need to be set again to the same value at the write operation.
Sadly, the address registers for read and write are different, so
I could not optimize the modify operation any more.
>> +static int en8811h_load_firmware(struct phy_device *phydev)
>> +{
>> + struct device *dev = &phydev->mdio.dev;
>> + const struct firmware *fw1, *fw2;
>> + int ret;
>> +
>> + ret = request_firmware_direct(&fw1, EN8811H_MD32_DM, dev);
>> + if (ret < 0)
>> + return ret;
>> +
>> + ret = request_firmware_direct(&fw2, EN8811H_MD32_DSP, dev);
>> + if (ret < 0)
>> + goto en8811h_load_firmware_rel1;
>> +
>
> How big are these firmwares? This will map the entire contents into
> memory. There is an alternative interface which allows you to get the
> firmware in chunks. I the firmware is big, just getting 4K at a time
> might be better, especially if this is an OpenWRT class device.
The file sizes are 131072 and 16384 bytes. If you think this is too big,
I could look into using the alternative interface.
>> +static int en8811h_restart_host(struct phy_device *phydev)
>> +{
>> + int ret;
>> +
>> + ret = air_buckpbus_reg_write(phydev, EN8811H_FW_CTRL_1,
>> + EN8811H_FW_CTRL_1_START);
>> + if (ret < 0)
>> + return ret;
>> +
>> + return air_buckpbus_reg_write(phydev, EN8811H_FW_CTRL_1,
>> + EN8811H_FW_CTRL_1_FINISH);
>> +}
>
> What is host in this context?
This is the EN8811H internal host to the PHY.
> Vendors do like making LED control unique. I've not seen any other MAC
> or PHY where you can blink for activity at a given speed. You cannot
> have 10 and 100 at the same time, so why are there different bits for
> them?
>
> I _think_ this can be simplified
> ...
> Does this work?
I started out with that, but the hardware can do more. It allows
for a setup as described:
100M link up triggers led0, only led0 blinking on traffic
1000M link up triggers led1, only led1 blinking on traffic
2500M link up triggers led0 and led1, both blinking on traffic
#define AIR_DEFAULT_TRIGGER_LED0 (BIT(TRIGGER_NETDEV_LINK_2500) | \
BIT(TRIGGER_NETDEV_LINK_100) | \
BIT(TRIGGER_NETDEV_RX) | \
BIT(TRIGGER_NETDEV_TX))
#define AIR_DEFAULT_TRIGGER_LED1 (BIT(TRIGGER_NETDEV_LINK_2500) | \
BIT(TRIGGER_NETDEV_LINK_1000) | \
BIT(TRIGGER_NETDEV_RX) | \
BIT(TRIGGER_NETDEV_TX))
With the simpler code and just the slightest traffic, both leds
are blinking and no way to read the speed anymore from the leds.
So I modified it to make the most use of the possibilities of the
EN881H hardware. The EN8811H can then be used with a standard 2-led
rj45 socket.
