[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <D93A58B3-7AE5-4352-A727-730A854B675A@intel.com>
Date: Thu, 9 Jan 2014 18:18:50 +0000
From: "Rustad, Mark D" <mark.d.rustad@...el.com>
To: Scott Feldman <sfeldma@...il.com>
CC: "Brown, Aaron F" <aaron.f.brown@...el.com>,
David Miller <davem@...emloft.net>,
Netdev <netdev@...r.kernel.org>,
"gospo@...hat.com" <gospo@...hat.com>,
"sassmann@...hat.com" <sassmann@...hat.com>
Subject: Re: [net-next 2/7] ixgbe: Indicate removal state explicitly
On Jan 9, 2014, at 9:27 AM, Rustad, Mark D <mark.d.rustad@...el.com> wrote:
> On Jan 8, 2014, at 12:35 AM, Scott Feldman <sfeldma@...il.com> wrote:
>
>> On Jan 7, 2014, at 11:40 PM, Aaron Brown <aaron.f.brown@...el.com> wrote:
>>
>>> From: Mark Rustad <mark.d.rustad@...el.com>
>>>
>>> diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_common.h b/drivers/net/ethernet/intel/ixgbe/ixgbe_common.h
>>> index 5e157ac..480c5c1 100644
>>> --- a/drivers/net/ethernet/intel/ixgbe/ixgbe_common.h
>>> +++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_common.h
>>> @@ -124,6 +124,11 @@ s32 ixgbe_reset_pipeline_82599(struct ixgbe_hw *hw);
>>> s32 ixgbe_get_thermal_sensor_data_generic(struct ixgbe_hw *hw);
>>> s32 ixgbe_init_thermal_sensor_thresh_generic(struct ixgbe_hw *hw);
>>>
>>> +#define IXGBE_FAILED_READ_REG 0xffffffffU
>>> +
>>> +void ixgbe_check_remove(struct ixgbe_hw *hw, u32 reg);
>>> +#define IXGBE_REMOVED(a) unlikely(!(a))
>>
>> IXGBE_REMOVED seems pretty closely tied to hw->hw_addr, but the macro turns any input into !input. Maybe an inline that takes a *hw?
>
> An earlier version had two different inputs, but not any more. I will change it to take a hw parameter. Good suggestion.
Actually, I responded too quickly. Although my comment on there previously having been two different inputs was true, that isn't the real reason for this form. The reason is that the check needs to be done on the value retrieved by ACCESS_ONCE - the address that will be used for the access. If the parameter were hw, then a separate dereference could occur, which is definitely not wanted.
One could argue that the macro should just be eliminated and the expansion put everywhere, but I feel that the code is much clearer with the macro. Unless there is another suggestion, I think this should stay as it is in this series.
--
Mark Rustad, Networking Division, Intel Corporation
Download attachment "signature.asc" of type "application/pgp-signature" (842 bytes)
Powered by blists - more mailing lists