All of lore.kernel.org
 help / color / mirror / Atom feed
From: "John W. Linville" <linville@tuxdriver.com>
To: Kalle Valo <kvalo@adurom.com>
Cc: Bing Zhao <bzhao@marvell.com>,
	linux-wireless@vger.kernel.org,
	Amitkumar Karwar <akarwar@marvell.com>,
	Avinash Patil <patila@marvell.com>,
	Maithili Hinge <maithili@marvell.com>,
	Xinming Hu <huxm@marvell.com>
Subject: Re: [PATCH 2/5] mwifiex: add firmware dump feature for PCIe
Date: Thu, 24 Apr 2014 21:37:57 -0400	[thread overview]
Message-ID: <20140425013756.GA3410@tuxdriver.com> (raw)
In-Reply-To: <87a9bb5c2c.fsf@purkki.adurom.net>

On Thu, Apr 24, 2014 at 12:08:59PM +0300, Kalle Valo wrote:
> Bing Zhao <bzhao@marvell.com> writes:
> 
> > From: Amitkumar Karwar <akarwar@marvell.com>
> >
> > Firmware dump feature is added for PCIe based chipsets.
> > Separate file will be created at /var/log/fw_dump_*
> > for each memory segment.
> >
> > Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
> > Signed-off-by: Bing Zhao <bzhao@marvell.com>
> 
> Sorry for commenting so late, I was on holidays and then got lagged
> behind with email.
> 
> > +			memset(filename, 0, sizeof(filename));
> > +			memcpy(filename, name_prefix, strlen(name_prefix));
> > +			strcat(filename, entry->mem_name);
> > +			do_gettimeofday(&t);
> > +			entry->file_mem = filp_open(filename, O_CREAT | O_RDWR,
> > +						    0644);
> > +			if (IS_ERR(entry->file_mem)) {
> > +				dev_info(adapter->dev,
> > +					 "Create %s file failed at %s, opening another dir /tmp\n",
> > +					 entry->mem_name, filename);
> > +				memset(filename, 0, sizeof(filename));
> > +				sprintf(filename, "%s%s", "/tmp/fw_dump_",
> > +					entry->mem_name);
> > +				entry->file_mem =
> > +					filp_open(filename,
> > +						  O_CREAT | O_RDWR, 0644);
> > +			}
> > +			if (!IS_ERR(entry->file_mem)) {
> > +				dev_info(adapter->dev,
> > +					 "Start to save the output : %u.%06u, please wait...\n",
> > +					 (u32)t.tv_sec, (u32)t.tv_usec);
> 
> Like I said in my previous email, IMHO a wireless driver should not save
> any files to the filesystem. For example, I don't see any other uses of
> filp_open() in drivers/net. Ugly hacks like this belong to staging
> drivers, not to proper upstream drivers.

I'm sorry for letting this slip through.  I must have had too much rum or something...

I'm reverting this patch in wireless-next -- drivers should not be
making filesystem calls like that.  Even if you can argue for doing
so somehow, where the file would go would be a policy decision that
should not be encoded in the driver.

John
-- 
John W. Linville		Someday the world will need a hero, and you
linville@tuxdriver.com			might be all we have.  Be ready.

  reply	other threads:[~2014-04-25  1:45 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-04-17 18:46 [PATCH 1/5] mwifiex: add fw_dump debugfs file Bing Zhao
2014-04-17 18:47 ` [PATCH 2/5] mwifiex: add firmware dump feature for PCIe Bing Zhao
2014-04-24  9:08   ` Kalle Valo
2014-04-25  1:37     ` John W. Linville [this message]
2014-04-25  3:35       ` Bing Zhao
2014-04-25  8:09         ` Johannes Berg
2014-04-30  7:41           ` Kalle Valo
2014-04-30  8:29             ` Johannes Berg
2014-04-30 13:22               ` John W. Linville
2014-04-30 16:14                 ` Kalle Valo
2014-05-05 12:57                   ` Johannes Berg
2014-05-05 14:19                     ` Amitkumar Karwar
2014-05-05 15:04                       ` Johannes Berg
2014-05-05 15:49                         ` Amitkumar Karwar
2014-04-30 16:13               ` Kalle Valo
2014-05-05 12:58                 ` Johannes Berg
2014-04-17 18:47 ` [PATCH 3/5] mwifiex: increase tx/rx AMPDU window sizes for STA 11n mode Bing Zhao
2014-04-17 18:47 ` [PATCH 4/5] mwifiex: increase tx/rx AMPDU window sizes for STA 11ac mode Bing Zhao
2014-04-17 18:47 ` [PATCH 5/5] mwifiex: enable aggregation for TID 6 and 7 streams Bing Zhao

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=20140425013756.GA3410@tuxdriver.com \
    --to=linville@tuxdriver.com \
    --cc=akarwar@marvell.com \
    --cc=bzhao@marvell.com \
    --cc=huxm@marvell.com \
    --cc=kvalo@adurom.com \
    --cc=linux-wireless@vger.kernel.org \
    --cc=maithili@marvell.com \
    --cc=patila@marvell.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.