Linux Framebuffer Layer development
 help / color / mirror / Atom feed
From: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
To: Helge Deller <deller@gmx.de>, Dan Carpenter <dan.carpenter@linaro.org>
Cc: linux-kernel@vger.kernel.org, kernel-janitors@vger.kernel.org,
	linux-fbdev@vger.kernel.org, dri-devel@lists.freedesktop.org
Subject: Re: [PATCH] fbdev/hpfb: Fix an error handling path in hpfb_dio_probe()
Date: Mon, 29 Jul 2024 22:30:33 +0200	[thread overview]
Message-ID: <aa9fd67e-3498-4152-abbd-3f2f40b0e294@wanadoo.fr> (raw)
In-Reply-To: <9dbb2b52-4fc9-4bbf-a6a2-ab6ec32adb8f@gmx.de>

Le 29/07/2024 à 22:09, Helge Deller a écrit :
> On 7/29/24 17:59, Dan Carpenter wrote:
>> On Mon, Jul 29, 2024 at 10:13:17AM +0200, Helge Deller wrote:
>>> On 7/28/24 20:29, Christophe JAILLET wrote:
>>>> If an error occurs after request_mem_region(), a corresponding
>>>> release_mem_region() should be called, as already done in the remove
>>>> function.
>>>
>>> True.
>>>
>>>> Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
>>>
>>> I think we can drop this "Fixes" tag, as it gives no real info.
>>
>> If we're backporting patches then these tags really are useful.  As
>> I've been doing more and more backporting, I've come to believe this
>> more firmly.
> 
> Sure, "Fixes" tags are useful, but only if they really refer
> to another patch which introduced the specific issue.
> 
> But the tag 1da177e4c3f4 ("Linux-2.6.12-rc2") isn't useful, as it's
> just the initial git commit. It has no relation to why release_mem_region()
> might have been initially missed. See:

I agree that the description of this specific tag is not useful by itself.

But at least it means: should it be backported, it can be done up to 
there. (and sometimes LWN gives some statistics on how long it took to 
fix an "issue", should it be considered as such)

Without it, it is not easy to guess in which branch the patch is meaningful.

I'll sent a v2 with your suggested minimal change, but I'll keep the 
Fixes tag.


Up to you to remove it or not, and to add a <stable@kernel.org> or a 
<stable+noautosel@kernel.org> or none of them.

Any solution is fine with me.


> 
>   commit 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 (tag: v2.6.12-rc2)
> Author: Linus Torvalds <torvalds@ppc970.osdl.org>
> Date:   Sat Apr 16 15:20:36 2005 -0700
> 
>      Linux-2.6.12-rc2
> 
>      Initial git repository build. I'm not bothering with the full history,
>      even though we have it. We can create a separate "historical" git
>      archive of that later if we want to, and in the meantime it's about
>      3.2GB when imported into git - space that would just make the early
>      git days unnecessarily complicated, when we don't have a lot of good
>      infrastructure for it.
> 
> Helge
> 
> 

On:

 > HP300 are old HP machines with an m68k CPU.
 > Not sure if someone still has such a machine 🙂

so it really was the one I found on wikipedia, LoL!

So, another way to "fix" the issue is maybe to deprecate the driver or 
everything related to this old architecture?

No strong opinion about it.

CJ

  reply	other threads:[~2024-07-29 20:30 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-07-28 18:29 [PATCH] fbdev/hpfb: Fix an error handling path in hpfb_dio_probe() Christophe JAILLET
2024-07-29  8:13 ` Helge Deller
2024-07-29 15:59   ` Dan Carpenter
2024-07-29 20:09     ` Helge Deller
2024-07-29 20:30       ` Christophe JAILLET [this message]
2024-07-29 21:35       ` Dan Carpenter

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=aa9fd67e-3498-4152-abbd-3f2f40b0e294@wanadoo.fr \
    --to=christophe.jaillet@wanadoo.fr \
    --cc=dan.carpenter@linaro.org \
    --cc=deller@gmx.de \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=kernel-janitors@vger.kernel.org \
    --cc=linux-fbdev@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox