Re: [Qemu-devel] [PATCH arm-devs v1 08/13] net/cadence_gem: Implement SAR (de)activation

[Peter Crosthwaite]

On Mon, Dec 2, 2013 at 10:23 PM, Peter Maydell <address@hidden> wrote:
> On 2 December 2013 07:13, Peter Crosthwaite
> <address@hidden> wrote:
>> The Specific address registers can be enabled or disabled by software.
>> QEMU was assuming they where always enabled. Implement the
>
> "were"
>

Fixed

>> disable/enable feature. SARs are disabled by writing to the lower half
>> register. They are re-enabled by then writing the upper half.
>>
>> Reported-by: Deepika Dhamija <address@hidden>
>> Signed-off-by: Peter Crosthwaite <address@hidden>
>> ---
>>
>>  hw/net/cadence_gem.c | 20 +++++++++++++++++++-
>>  1 file changed, 19 insertions(+), 1 deletion(-)
>>
>> diff --git a/hw/net/cadence_gem.c b/hw/net/cadence_gem.c
>> index 6f11d6a..c6eb9ab 100644
>> --- a/hw/net/cadence_gem.c
>> +++ b/hw/net/cadence_gem.c
>> @@ -382,6 +382,7 @@ typedef struct GemState {
>>
>>      unsigned rx_desc[2];
>>
>> +    bool sar_active[4];
>
> This state needs to be added to the VMState struct as well.
>

Done.

>>  } GemState;
>>
>>  /* The broadcast MAC address: 0xFFFFFFFFFFFF */
>> @@ -603,7 +604,7 @@ static int gem_mac_address_filter(GemState *s, const 
>> uint8_t *packet)
>>      /* Check all 4 specific addresses */
>>      gem_spaddr = (uint8_t *)&(s->regs[GEM_SPADDR1LO]);
>>      for (i = 3; i >= 0; i--) {
>> -        if (!memcmp(packet, gem_spaddr + 8 * i, 6)) {
>> +        if (s->sar_active[i] && !memcmp(packet, gem_spaddr + 8 * i, 6)) {
>>              return GEM_RX_SAR_ACCEPT + i;
>>          }
>>      }
>> @@ -985,6 +986,7 @@ static void gem_phy_reset(GemState *s)
>>
>>  static void gem_reset(DeviceState *d)
>>  {
>> +    int i;
>>      GemState *s = GEM(d);
>>
>>      DB_PRINT("\n");
>> @@ -1004,6 +1006,10 @@ static void gem_reset(DeviceState *d)
>>      s->regs[GEM_DESCONF5] = 0x002f2145;
>>      s->regs[GEM_DESCONF6] = 0x00000200;
>>
>> +    for (i = 0; i < 4; ++i) {
>
> "i++" is more idiomatic for C.
>
> Otherwise looks good.
>

Fixed, although I do see both used quite liberally. I'll use foo++
when local coding style doesn't contradict.

Regards,
Peter

> thanks
> -- PMM
>