From: Jiri Slaby <jirislaby@gmail.com>
To: Nick Kossifidis <mickflemm@gmail.com>
Cc: ath5k-devel@lists.ath5k.org, linux-wireless@vger.kernel.org,
linville@tuxdriver.com, mcgrof@gmail.com, me@bobcopeland.com,
nbd@openwrt.org
Subject: Re: [ath5k-devel] [PATCH] ath5k: Add debug code for EEPROM
Date: Sat, 10 Jan 2009 15:35:31 +0100 [thread overview]
Message-ID: <4968B233.5050401@gmail.com> (raw)
In-Reply-To: <40f31dec0901091637u70ad5c97g3915d5b2b8726e88@mail.gmail.com>
Nick Kossifidis napsal(a):
> Hello Jiri and thanks a lot for the review ;-)
>
> 2009/1/4 Jiri Slaby <jirislaby@gmail.com>:
>>> +/* debugfs: EEPROM stuff */
>>> +
>>> +/* EEPROM Header (common) */
>>> +static ssize_t read_file_eeprom_header(struct file *file, char __user *user_buf,
>>> + size_t count, loff_t *ppos)
>>> +{
>>> +
>>> + struct ath5k_softc *sc = file->private_data;
>>> + struct ath5k_hw *ah = sc->ah;
>>> + struct ath5k_eeprom_info ee = ah->ah_capabilities.cap_eeprom;
>>> + char buf[2000];
>> Please don't use that much memory from stack. 2k is way too much. Note that
>> you use yet another bunch of stack (next 3k here on 64-bit) by
>> ath5k_eeprom_info and 32-bit x86 can still be configured with 4k stacks.
>>
>> Convert both of them to dynamically allocated buffers.
>>
>
> Why dynamically allocated buffers (can you point out some docs on
> these please ?) ? The length of each file (what we print) is standard.
> I understand that we use too much stack here but we can work this out
> eg. by using a pointer to ath5k_eeprom_info or something like that.
Yes, no problem in changing it to a pointer. Anyway the buf should be
kmalloc'ed anyway.
> I
> checked out user_buffer btw and it's 4K, sometimes it's not much for
> calibration data (eg. on RF5111 that we have 10 points per pd gain
> curve or RF2413+ that we can have multiple pd gain curves per
> channel).
I don't understand here. user_buf is sized by userspace application. E.g.
cat on my system requests user_buf of size 1K. simple_read_from_buffer()
takes care about multiple invocations of fops.read function by looking at
ppos parameter and filling user_buf by correct contents (some offset in from
param). BTW as a side-effect, it is possible, that the user will get
different info in these split reads.
>> dtto
>>
>
> What does dtto mean ?
Oops, as I checked right now, this shortcut is commonly used only in czech.
It should be detto or ditto (and it means "the same as above"), sorry for
the confusion.
prev parent reply other threads:[~2009-01-10 14:35 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-01-04 17:32 [PATCH] ath5k: Add debug code for EEPROM Nick Kossifidis
2009-01-04 19:31 ` Jiri Slaby
2009-01-10 0:37 ` [ath5k-devel] " Nick Kossifidis
2009-01-10 6:28 ` Kalle Valo
2009-01-10 14:35 ` Jiri Slaby [this message]
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=4968B233.5050401@gmail.com \
--to=jirislaby@gmail.com \
--cc=ath5k-devel@lists.ath5k.org \
--cc=linux-wireless@vger.kernel.org \
--cc=linville@tuxdriver.com \
--cc=mcgrof@gmail.com \
--cc=me@bobcopeland.com \
--cc=mickflemm@gmail.com \
--cc=nbd@openwrt.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;
as well as URLs for NNTP newsgroup(s).