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;
Message-ID: <917abc36-ee08-6f1e-2bf5-a657b022c912@linaro.org>
Date:   Tue, 20 Sep 2022 11:16:18 -0500
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101
 Thunderbird/91.11.0
Subject: Re: [PATCH net v2] net: ipa: properly limit modem routing table use
Content-Language: en-US
To:     Jakub Kicinski <kuba@kernel.org>
Cc:     davem@davemloft.net, edumazet@google.com, pabeni@redhat.com,
        mka@chromium.org, evgreen@chromium.org, bjorn.andersson@linaro.org,
        quic_cpratapa@quicinc.com, quic_avuyyuru@quicinc.com,
        quic_jponduru@quicinc.com, quic_subashab@quicinc.com,
        elder@kernel.org, netdev@vger.kernel.org,
        linux-arm-msm@vger.kernel.org, linux-kernel@vger.kernel.org
References: <20220913204602.1803004-1-elder@linaro.org>
 <20220920081400.0cbe44ff@kernel.org>
From:   Alex Elder <elder@linaro.org>
In-Reply-To: <20220920081400.0cbe44ff@kernel.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk

On 9/20/22 10:14 AM, Jakub Kicinski wrote:
>> v2: Update the element info arrays defining the modified QMI message
>>      so it uses the ipa_mem_bounds_ei structure rather than the
>>      ipa_mem_array_ei structure.  The message format is identical,
>>      but the code was incorrect without that change.
> Unclear to me why, ipa_mem_bounds_ei and ipa_mem_array_ei seem
> identical, other than s/end/count/. Overall the patch feels
> a touch too verbose for a fix, makes it harder to grasp the key
> functional change IMHO. I could be misunderstanding but please
> keep the goal of making fixes small and crisp in mind for the future.

I see you've already accepted the patch, and I appreciate that.

The verbosity was because it was maybe a subtle difference
and I failed to be more concise describing it.

Over the wire, the ipa_mem_bounds and ipa_mem_array *look*
identical (both are a pair of 32-bit unsigned values).

But they are *semantically* different.  The "array" is a
base offset and number of entries.  The "bounds" specifies
the start and last offset (one less than the number of
entries).

So the type has changed to try to make the distinction
clearer.  I realize neither the compiler nor the QMI
implementation will distinguish it, but the hope is that
the human reader can derive some value from it.

I don't want to be any more verbose, so I'll leave it at
that.

					-Alex