All of lore.kernel.org
 help / color / mirror / Atom feed
From: Larry Finger <Larry.Finger@lwfinger.net>
To: Greg KH <greg@kroah.com>
Cc: linux-kernel@vger.kernel.org,
	John W Linville <linville@tuxdriver.com>,
	bernhard@schiffner-limbach.de
Subject: Re: [PATCH] rtl8187se staging: Fix compilation warnings and procfs directory leak
Date: Sun, 19 Apr 2009 09:50:40 -0500	[thread overview]
Message-ID: <49EB3A40.10307@lwfinger.net> (raw)
In-Reply-To: <20090419053851.GA25290@kroah.com>

Greg KH wrote:
> On Sat, Apr 18, 2009 at 09:09:08PM -0500, Larry Finger wrote:
>> Please incorporate this patch in wireless/staging as soon as is possible.
>> I'm not sure what the rules are concerning such changes.
> 
> I take stuff through my staging tree, it has nothing to do with the
> wireless tree.

That was a slip of the keyboard.

>> I have a number of patches that clean up the vendor code; however, I think
>> I will hold them for the moment as they do not change the function of this
>> driver and only improve the readability.
> 
> Why wait?

The only reason is that I'm hoping that the port will allow the staging driver
to be deleted. If you want the bigger changes now, I would be happy to oblige.
FYI, the bigger patches will change 14 files with a total of 233 insertions and
1930 deletions.

>> -#define RTL8180_MODULE_NAME "rtl8180"
>> +#define RTL8180_MODULE_NAME "r8180"
> 
> Why change the name?

I want to distinguish this one from the mainline driver for the RTL8180/RTL8185
that uses the name "rtl8180". Perhaps rtl8187se would have been better; however,
that is the name I will use for the new mainline driver.

>> --- linux-2.6.orig/drivers/staging/rtl8187se/r8180_core.c
>> +++ linux-2.6/drivers/staging/rtl8187se/r8180_core.c
>> @@ -640,11 +640,9 @@ void rtl8180_proc_init_one(struct net_de
>>  {
>>  	struct proc_dir_entry *e;
>>  	struct r8180_priv *priv = (struct r8180_priv *)ieee80211_priv(dev);
>> -	priv->dir_dev = create_proc_entry(dev->name,
>> -					  S_IFDIR | S_IRUGO | S_IXUGO,
>> -					  rtl8180_proc);
>> +	priv->dir_dev = rtl8180_proc;
>>  	if (!priv->dir_dev) {
>> -		DMESGE("Unable to initialize /proc/net/rtl8180/%s\n",
>> +		DMESGE("Unable to initialize /proc/net/r8180/%s\n",
>>  		      dev->name);
>>  		return;
>>  	}
> 
> So put the files in the root proc dir?

Sure, if you think that would be better. The problem that I am fixing is that
the vendor code put the files in /proc/net/rtl8180/wlan0/XXX and then failed to
delete the wlan0 directory. I wanted to make the minimum changes for it to work
correctly.

>> @@ -1736,17 +1727,7 @@ short alloc_tx_desc_ring(struct net_devi
>>  		 * descriptor's buffer must be 256 byte aligned
>>  		 * we shouldn't be here, since we set DMA mask !
>>  		 */
>> -		DMESGW("Fixing TX alignment");
>> -		desc = (u32*)((u8*)desc + 256);
>> -#if (defined(CONFIG_HIGHMEM64G) || defined(CONFIG_64BIT_PHYS_ADDR))
>> -		desc = (u32*)((u64)desc &~ 0xff);
>> -		dma_desc = (dma_addr_t)((u8*)dma_desc + 256);
>> -		dma_desc = (dma_addr_t)((u64)dma_desc &~ 0xff);
>> -#else
>> -		desc = (u32*)((u32)desc &~ 0xff);
>> -		dma_desc = (dma_addr_t)((u8*)dma_desc + 256);
>> -		dma_desc = (dma_addr_t)((u32)dma_desc &~ 0xff);
>> -#endif
>> +		WARN(1, "DMA buffer is not aligned\n");
>>  	}
>>  	tmp=desc;
>>  	for (i=0;i<count;i++)
> 
> What replaces this logic?  Is it not needed anymore?

AFAIK, it was only needed if the kernel's DMA memory allocation failed. As we
know, that code is now perfect ;), I thought that a simple kernel warning would
be sufficient. Besides, I'm not smart enough to get the old code to compile
without warnings on x86_64 architecture. I'm not sure about i386 machines. So
far in testing, the warning has not triggered.

Larry


      reply	other threads:[~2009-04-19 14:51 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-04-19  2:09 [PATCH] rtl8187se staging: Fix compilation warnings and procfs directory leak Larry Finger
2009-04-19  5:38 ` Greg KH
2009-04-19 14:50   ` Larry Finger [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=49EB3A40.10307@lwfinger.net \
    --to=larry.finger@lwfinger.net \
    --cc=bernhard@schiffner-limbach.de \
    --cc=greg@kroah.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linville@tuxdriver.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.