Message-ID: <65f0ed39-4c2f-4cea-b488-2a8ba6fdbeff@linaro.org>
Date: Tue, 2 Apr 2024 12:04:07 +0200
From: Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
To: "Russell King (Oracle)" <linux@...linux.org.uk>
Cc: Suzuki K Poulose <suzuki.poulose@....com>,
 Mike Leach <mike.leach@...aro.org>, James Clark <james.clark@....com>,
 Alexander Shishkin <alexander.shishkin@...ux.intel.com>,
 Maxime Coquelin <mcoquelin.stm32@...il.com>,
 Alexandre Torgue <alexandre.torgue@...s.st.com>,
 Linus Walleij <linus.walleij@...aro.org>, Andi Shyti
 <andi.shyti@...nel.org>, Olivia Mackall <olivia@...enic.com>,
 Herbert Xu <herbert@...dor.apana.org.au>, Vinod Koul <vkoul@...nel.org>,
 Dmitry Torokhov <dmitry.torokhov@...il.com>,
 Miquel Raynal <miquel.raynal@...tlin.com>,
 Michal Simek <michal.simek@....com>, Eric Auger <eric.auger@...hat.com>,
 Alex Williamson <alex.williamson@...hat.com>, linux-kernel@...r.kernel.org,
 coresight@...ts.linaro.org, linux-arm-kernel@...ts.infradead.org,
 linux-stm32@...md-mailman.stormreply.com, linux-i2c@...r.kernel.org,
 linux-crypto@...r.kernel.org, dmaengine@...r.kernel.org,
 linux-input@...r.kernel.org, kvm@...r.kernel.org
Subject: Re: [PATCH 00/19] amba: store owner from modules with
 amba_driver_register()

On 02/04/2024 11:57, Russell King (Oracle) wrote:
> On Tue, Apr 02, 2024 at 11:48:08AM +0200, Krzysztof Kozlowski wrote:
>> On 02/04/2024 10:56, Russell King (Oracle) wrote:
>>> On Sat, Mar 30, 2024 at 01:18:30PM +0100, Krzysztof Kozlowski wrote:
>>>> On 26/03/2024 21:23, Krzysztof Kozlowski wrote:
>>>>> Merging
>>>>> =======
>>>>> All further patches depend on the first amba patch, therefore please ack
>>>>> and this should go via one tree.
>>>>>
>>>>> Description
>>>>> ===========
>>>>> Modules registering driver with amba_driver_register() often forget to
>>>>> set .owner field.
>>>>>
>>>>> Solve the problem by moving this task away from the drivers to the core
>>>>> amba bus code, just like we did for platform_driver in commit
>>>>> 9447057eaff8 ("platform_device: use a macro instead of
>>>>> platform_driver_register").
>>>>>
>>>>> Best regards,
>>>>
>>>> I tried to submit this series to Russell patch tracker and failed. This
>>>> is ridiculous. It's 2024 and instead of normal process, like every other
>>>> maintainer, so b4 or Patchwork, we have some unusable system rejecting
>>>> standard patches.
>>>
>>> Sorry but no. Stop being offensive.
>>>
>>>> First, it depends some weird, duplicated signed-off-by's.
>>>
>>> Eh? There is no such logic in there.
>>
>> In the web system there is - read the error message I pasted. It wants
>> another SoB from the unrelated email account, the one used purely for
>> registering in some web system, not the one used for code handling.
> 
> So you're disagreeing with the author of this system. Of course you
> know best, you know the code behind it. I have only one word for
> that kind of attitude: idiotic.

I pasted you the error which the system reported to me.

> 
>>>> Second it > submitting patch-by-patch, all with clicking on some web
>>>> (!!!) interface.
>>>
>>> Again, no it doesn't, and you're just throwing crap out because you
>>> failed. Unlike most of the "normal" processes, the patch system allows
>>> you to submit both by *email* and also by *web* for those cases where
>>
>> The email one requires additional steps, so this is unnecessary work
>> confusing submitters. I submit dozens or hundreds of patches every
>> release cycle. That's the only subsystem which is odd to use.
> 
> Lots of people use it without issue. People even send patches to the
> mailing list copied to the patch system.
> 

I will try that.


>>> the emails get screwed up by ones company mail server. That's why the
>>> web interface exists - to give people *flexibility*.
>>
>> No, they are not. None of my emails are screwed by my company system.
> 
> So why are you using the web interface?
> 
>>> Why does it want the kernel version? Because when we were running 2.4
>>> and 2.5 kernel versions in parallel, it was important to know which
>>> tree the patch was being submitted for. It has continued to be required
>>
>> Which is absolutely ridiculous now. Expecting submitters to adhere to
>> some rule for 20 year old kernel is not reasonable.
> 
> You aren't listening to me, so it's pointless discussing this further.
> You have a bee in your bonet and you want to make it a huge issue

Well, all my comments were about the actual topic - patch submission
process made for ARM subsystem by you. Your replies include comments
about me and what do I have in my bonet.

You brought no argument for keeping the kernel-version-header
requirement nowadays, yet you call me of not working constructively. I
brought that argument - it is redundant and it is an obstacle for the
contributor.

> rather than work constructively. Sorry but no, I'm not going to continue
> this confrontational exchange.
> 
> You clearly don't want to understand anything.

I understood a lot, although I did not answer under every point "I
understand this part, I disagree here".

Best regards,
Krzysztof

Powered by blists - more mailing lists