From: Manuel Estrada Sainz <ranty@ranty.pantax.net>
To: Andrew Morton <akpm@osdl.org>,
LKML <linux-kernel@vger.kernel.org>,
Dmitry Torokhov <dtor_core@ameritech.net>,
jt@hpl.hp.com, Simon Kelley <simon@thekelleys.org.uk>
Subject: [PATCH] request_firmware(): fixes and polishing.
Date: Wed, 25 Feb 2004 02:34:48 +0100 [thread overview]
Message-ID: <10776728882704@kroah.com> (raw)
In-Reply-To: Manuel Estrada Sainz <ranty@debian.org>
Hi,
Please apply.
Dmitry Torokhov has been criticizing my code for some days (Thanks Dmitry),
and here is the result. It should be ready for -mm tree.
Simon Kelly tested the patch series and reported improvement with some
problems he was having.
On Fri, 06 Feb 2004 07:52:31 +0000, Simon Kelley wrote:
> I'm seeing problems when request_firmware() is called from the open()
> routine of the atmel driver if that is called as a result of process
> which was started from /sbin/hotplug.
Each patch starts with a changelog, but I'll write a full changelog
here for the casual reader:
- 01_request_firmware-misc-fix.diff
- use vfree to free vmalloc memory.
- Make sure fw_setup_class_device sets *class_dev_p to NULL in
all case of error.
- Fix error handling in firmware_class_init.
- 02_request_firmware-misc-polish.diff
- Take advantage of strlcpy.
- Extra error logging.
- Use struct coping instead of memcpy.
- Put all aborting code in a single place, and fully abort if
fw_realloc_buffer fails.
- Abort on unexpected 'loading' values.
- 03_request_firmware-state-tracking.diff
- Make an status bitmap instead of using independent boolean
variables. It will make things nicer later when new issues
need to be tracked.
- 04_request_firmware-propper-release-1.diff
- release 'struct firmware_priv' from class_dev->release.
- 05_request_firmware-propper-release-2.diff
- Remove races related to the handling and release of 'struct
firmware'
- 06_request_firmware-rearrange.diff
- Refactor fw_setup_class_device for readability and
maintainability.
- 07_request_firmware-dont-remove-attr.diff
- Don't remove attributes, they should be gone automatically.
Have a nice day
Manuel
next parent reply other threads:[~2004-02-25 1:35 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <ranty@debian.org>
2004-02-25 1:34 ` Manuel Estrada Sainz [this message]
2004-02-25 1:34 ` [PATCH] request_firmware(): fixes and polishing Manuel Estrada Sainz
2004-02-25 1:34 ` Manuel Estrada Sainz
2004-02-25 1:34 ` Manuel Estrada Sainz
2004-02-25 1:34 ` Manuel Estrada Sainz
2004-02-25 1:34 ` Manuel Estrada Sainz
2004-02-25 1:34 ` Manuel Estrada Sainz
2004-02-25 1:34 ` Manuel Estrada Sainz
2004-02-25 19:47 ` Jean Tourrilhes
2004-02-25 23:40 ` Manuel Estrada Sainz
2004-02-29 6:30 ` Dmitry Torokhov
2004-02-29 6:32 ` [PATCH 1/2] Pin firmware module (was Re: [PATCH] request_firmware(): fixes and polishing.) Dmitry Torokhov
2004-02-29 6:34 ` [PATCH 2/2] Delay firmware hotplug event " Dmitry Torokhov
2004-01-07 1:23 [PATCH] request_firmware(): fixes and polishing Manuel Estrada Sainz
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=10776728882704@kroah.com \
--to=ranty@ranty.pantax.net \
--cc=akpm@osdl.org \
--cc=dtor_core@ameritech.net \
--cc=jt@hpl.hp.com \
--cc=linux-kernel@vger.kernel.org \
--cc=simon@thekelleys.org.uk \
/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