From: Krzysztof Halasa <khc@pm.waw.pl>
To: Andrea Shepard <andrea@persephoneslair.org>
Cc: linux-kernel@vger.kernel.org, netdev@vger.kernel.org,
davem@davemloft.net, mmarek@suse.cz, jkosina@suse.cz,
joe@perches.com, justinmattock@gmail.com, gregkh@suse.de,
alan@linux.intel.com, jdmason@kudzu.us
Subject: Re: [03/22] Cyclades PC300 driver: Fix usage of types
Date: Tue, 31 Jan 2012 19:58:29 +0100 [thread overview]
Message-ID: <m3hazb3dii.fsf@intrepid.localdomain> (raw)
In-Reply-To: <20120130024605.GD10262@cronus.persephoneslair.org> (Andrea Shepard's message of "Sun, 29 Jan 2012 18:46:05 -0800")
Hi,
Andrea Shepard <andrea@persephoneslair.org> writes:
> +++ b/drivers/net/wan/hd64572.h
> @@ -172,11 +172,11 @@
>
> /* Block Descriptor Structure */
> typedef struct {
> - unsigned long next; /* pointer to next block descriptor */
> - unsigned long ptbuf; /* buffer pointer */
> - unsigned short len; /* data length */
> - unsigned char status; /* status */
> - unsigned char filler[5]; /* alignment filler (16 bytes) */
> + u32 next; /* pointer to next block descriptor */
> + u32 ptbuf; /* buffer pointer */
> + u16 len; /* data length */
> + u8 status; /* status */
> + u8 filler[5]; /* alignment filler (16 bytes) */
> } pcsca_bd_t;
Perhaps you could just use the following struct which is already in the
file:
/* Block Descriptor Structure */
typedef struct {
u32 cp; /* pointer to next block descriptor */
u32 bp; /* buffer pointer */
u16 len; /* data length */
u8 stat; /* status */
u8 unused; /* pads to 4-byte boundary */
}pkt_desc;
The difference is a different alignment (4 bytes vs 16 bytes) but
I think it's been verified (both docs and real hw) that 32-bit alignment
is ok with these chips.
> +#define cpc_writeb(port, val) {writeb((u8)(val), \
> + (void __iomem *)(port)); mb(); }
> +#define cpc_writew(port, val) {writew((u16)(val), \
> + (void __iomem *)(port)); mb(); }
> +#define cpc_writel(port, val) {writel((u32)(val), \
> + (void __iomem *)(port)); mb(); }
Are these mb() needed? I think write[bwl] and read[bwl] are already
memory barriers.
PCI write posting is a different thing of course and you may need e.g.
a PCI read in some timing-critical parts of the code.
> #else /* __KERNEL__ */
> -#define cpc_writeb(port,val) (*(volatile ucchar *)(port) = (ucchar)(val))
> -#define cpc_writew(port,val) (*(volatile ucshort *)(port) = (ucshort)(val))
> -#define cpc_writel(port,val) (*(volatile uclong *)(port) = (uclong)(val))
> +#define cpc_writeb(port, val) (*(u8 *)(port) = (u8)(val))
> +#define cpc_writew(port, val) (*(u16 *)(port) = (u16)(val))
> +#define cpc_writel(port, val) (*(u32 *)(port) = (u32)(val))
>
> -#define cpc_readb(port) (*(volatile ucchar *)(port))
> -#define cpc_readw(port) (*(volatile ucshort *)(port))
> -#define cpc_readl(port) (*(volatile uclong *)(port))
> +#define cpc_readb(port) (*(u8 *)(port))
> +#define cpc_readw(port) (*(u16 *)(port))
> +#define cpc_readl(port) (*(u32 *)(port))
I'm not sure the kernel headers are a good place for such things.
> void tx_dma_stop(pc300_t * card, int ch)
> {
> - uclong scabase = card->hw.scabase;
> - ucchar drr_ena_bit = 1 << (5 + 2 * ch);
> - ucchar drr_rst_bit = 1 << (1 + 2 * ch);
> + uintptr_t scabase = (uintptr_t)(card->hw.scabase);
> + u8 drr_ena_bit = 1 << (5 + 2 * ch);
> + u8 drr_rst_bit = 1 << (1 + 2 * ch);
uintptr_t? Is it simply an unsigned int *?
--
Krzysztof Halasa
prev parent reply other threads:[~2012-01-31 18:59 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-01-30 2:46 [03/22] Cyclades PC300 driver: Fix usage of types Andrea Shepard
2012-01-31 18:58 ` Krzysztof Halasa [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=m3hazb3dii.fsf@intrepid.localdomain \
--to=khc@pm.waw.pl \
--cc=alan@linux.intel.com \
--cc=andrea@persephoneslair.org \
--cc=davem@davemloft.net \
--cc=gregkh@suse.de \
--cc=jdmason@kudzu.us \
--cc=jkosina@suse.cz \
--cc=joe@perches.com \
--cc=justinmattock@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mmarek@suse.cz \
--cc=netdev@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;
as well as URLs for NNTP newsgroup(s).