Move offset_uv in struct ada4250_state. This keeps things logically
grouped and reduces holes in the struct.

Signed-off-by: David Lechner <dlechner@baylibre.com>
---
 drivers/iio/amplifiers/ada4250.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/iio/amplifiers/ada4250.c b/drivers/iio/amplifiers/ada4250.c
index c367c53a075b26327a221e0c3a9dc8e788891f32..d20ca410c506226fce7f172632d46b2ebb140a12 100644
--- a/drivers/iio/amplifiers/ada4250.c
+++ b/drivers/iio/amplifiers/ada4250.c
@@ -59,9 +59,9 @@ struct ada4250_state {
 	/* Protect against concurrent accesses to the device and data content */
 	struct mutex		lock;
 	int			avdd_uv;
+	int			offset_uv;
 	u8			bias;
 	u8			gain;
-	int			offset_uv;
 	bool			refbuf_en;
 	__le16			reg_val_16 __aligned(IIO_DMA_MINALIGN);
 };

-- 
2.43.0

On Wed, Jun 11, 2025 at 04:33:04PM -0500, David Lechner wrote:
> Move offset_uv in struct ada4250_state. This keeps things logically
> grouped and reduces holes in the struct.

Can the (smallest part of) the diff for `pahole` runs be added here?

-- 
With Best Regards,
Andy Shevchenko

On 6/12/25 8:04 AM, Andy Shevchenko wrote:
> On Wed, Jun 11, 2025 at 04:33:04PM -0500, David Lechner wrote:
>> Move offset_uv in struct ada4250_state. This keeps things logically
>> grouped and reduces holes in the struct.
> 
> Can the (smallest part of) the diff for `pahole` runs be added here?
> 

Well, I didn't use pahole. I could just tell by looking at it. There
was int followed by two u8 followed by int, so we know there was a 2
byte hole before the last int.

On Thu, Jun 12, 2025 at 6:31 PM David Lechner <dlechner@baylibre.com> wrote:
> On 6/12/25 8:04 AM, Andy Shevchenko wrote:
> > On Wed, Jun 11, 2025 at 04:33:04PM -0500, David Lechner wrote:
> >> Move offset_uv in struct ada4250_state. This keeps things logically
> >> grouped and reduces holes in the struct.
> >
> > Can the (smallest part of) the diff for `pahole` runs be added here?
>
> Well, I didn't use pahole. I could just tell by looking at it. There
> was int followed by two u8 followed by int, so we know there was a 2
> byte hole before the last int.

Yes, but since we have a tool for such cases, why not use it?

-- 
With Best Regards,
Andy Shevchenko

On 6/12/25 1:34 PM, Andy Shevchenko wrote:
> On Thu, Jun 12, 2025 at 6:31 PM David Lechner <dlechner@baylibre.com> wrote:
>> On 6/12/25 8:04 AM, Andy Shevchenko wrote:
>>> On Wed, Jun 11, 2025 at 04:33:04PM -0500, David Lechner wrote:
>>>> Move offset_uv in struct ada4250_state. This keeps things logically
>>>> grouped and reduces holes in the struct.
>>>
>>> Can the (smallest part of) the diff for `pahole` runs be added here?
>>
>> Well, I didn't use pahole. I could just tell by looking at it. There
>> was int followed by two u8 followed by int, so we know there was a 2
>> byte hole before the last int.
> 
> Yes, but since we have a tool for such cases, why not use it?
> 

In cases like this, I don't think the we are getting much value
from it compared to the amount of time it would take me to do it.

On Thu, Jun 12, 2025 at 01:45:16PM -0500, David Lechner wrote:
> On 6/12/25 1:34 PM, Andy Shevchenko wrote:
> > On Thu, Jun 12, 2025 at 6:31 PM David Lechner <dlechner@baylibre.com> wrote:
> >> On 6/12/25 8:04 AM, Andy Shevchenko wrote:
> >>> On Wed, Jun 11, 2025 at 04:33:04PM -0500, David Lechner wrote:
> >>>> Move offset_uv in struct ada4250_state. This keeps things logically
> >>>> grouped and reduces holes in the struct.
> >>>
> >>> Can the (smallest part of) the diff for `pahole` runs be added here?
> >>
> >> Well, I didn't use pahole. I could just tell by looking at it. There
> >> was int followed by two u8 followed by int, so we know there was a 2
> >> byte hole before the last int.
> > 
> > Yes, but since we have a tool for such cases, why not use it?
> 
> In cases like this, I don't think the we are getting much value
> from it compared to the amount of time it would take me to do it.

It helps reviewers to see the difference without checking themselves.
Also, it's not a waste of 15 minutes (that's my experience with pahole
when I started it first time), it's an investment to the future similar
changes by you or others. Believe me, as a reviewer you will find this tool
very helpful.

So, please try it once and then you will know how to do that again much
quicker.

-- 
With Best Regards,
Andy Shevchenko