Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Tue, 18 Apr 2023 21:38:57 +0200
From:   Luke Koch <lu.ale.koch@gmail.com>
To:     Greg KH <gregkh@linuxfoundation.org>
Cc:     error27@gmail.com, linux-staging@lists.linux.dev,
        linux-kernel@vger.kernel.org
Subject: Re: [PATCH v3] staging: wlan-ng: replace rate macros
Message-ID: <ZD7x0VWFedQSvA2P@kernelhacking.kernelhacking.example.com>
References: <ZD6OqBOp1ezQDgMu@kernelhacking.kernelhacking.example.com>
 <2023041809-wildfowl-winter-be08@gregkh>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <2023041809-wildfowl-winter-be08@gregkh>
Precedence: bulk

On Tue, Apr 18, 2023 at 03:04:06PM +0200, Greg KH wrote:
> This patch implies that these structures are set but never actually read
> from, so why are they present at all?  Is this a structure that is on
> the wire/air or used somewhere else as an api to hardware?

I never looked that far as I was naively trying to just fix the
checkpatch warning. They seem to be part of MAC frames coming from the
hardware.

> I tried to unwind things in the driver, but couldn't figure it out, what
> happens if you just delete these fields, does the driver still work
> properly?

It compiles without issue when deleting these structs, but almost
certainly breaks the driver since it changes what the resulting message
looks like in memory. I assume the caller of the function uses the message for
something - otherwise setting all the message parameters wouldn't make any sense
at all - and changing the message like this would cause major problems.

The structs seem necessary, but changing how they are accessed to using
arrays shouldn't introduce any issues as resulting values as well as addresses
in relation to the message struct will be unchanged.

Best regards,

Luke Koch