mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Masayuki Ohtake" <masa-korg@dsn.okisemi.com>
To: "Jiri Slaby" <jslaby@suse.cz>
Cc: "Randy Dunlap" <randy.dunlap@oracle.com>,
	"Ralf Baechle" <ralf@linux-mips.org>,
	"ML netdev" <netdev@vger.kernel.org>,
	"MeeGo" <meego-dev@meego.com>, "Maxime Bizon" <mbizon@freebox.fr>,
	"LKML" <linux-kernel@vger.kernel.org>,
	"Kristoffer Glembo" <kristoffer@gaisler.com>,
	"John Linn" <john.linn@xilinx.com>,
	"Joe Perches" <joe@perches.com>,
	"Greg Rose" <gregory.v.rose@intel.com>,
	"David S. Miller" <davem@davemloft.net>,
	"Wang, Yong Y" <yong.y.wang@intel.com>,
	"Wang, Qi" <qi.wang@intel.com>,
	"Toshiharu Okada" <okada533@dsn.okisemi.com>,
	"Tomoya Morinaga" <morinaga526@dsn.okisemi.com>,
	"Takahiro Shimizu" <shimizu394@dsn.okisemi.com>,
	"Intel OTC" <joel.clark@intel.com>,
	"Foster, Margie" <margie.foster@intel.com>,
	"Andrew" <andrew.chih.howe.khor@intel.com>
Subject: Re: [PATCH] Gigabit Ethernet driver of Topcliff PCH
Date: Thu, 9 Sep 2010 22:38:06 +0900	[thread overview]
Message-ID: <002501cb5024$5a5e3800$66f8800a@maildom.okisemi.com> (raw)
In-Reply-To: <4C879AAB.6000905@suse.cz>

Hi Jiri

Thank you for your answer

On: Wed, 08 Sep 2010 16:16:11 +0200,: Jiri Slaby wrote:
> >>> + u32 TX_DMA_ST;
> >>> + u32 reserve7[2];
> >>> + u32 WOL_ST;
> >>> + u32 WOL_CTRL;
> >>> + u32 WOL_ADDR_MASK;
> >>> +};
> >>
> >> Shouldn't that be packed? As it is full of u32, probably not, but
> >> consider this comment when thinking about all structures you have here.
> >
> > [masa]
> > packed?
> > I am sorry, I can not understand.
> > Please let me know details.
>
> attribute((packed)). It ensures that compiler won't add gaps in there
> for better alignment. As I wrote I'm not sure whether you need them at
> all, since you use u32 here which are aligned naturally. But bear this
> in mind while defining the rest of your structures which are transferred
> from/to the HW.

[masa]
I understood.
"__attribute ((packed))" is added

    u32 WOL_ST;
    u32 WOL_CTRL;
    u32 WOL_ADDR_MASK;
} __attribute ((packed));


> >>> + rxdr->count = max(ring->rx_pending, (u32) PCH_GBE_MIN_RXD);
> >>> + rxdr->count = min(rxdr->count, (u32) PCH_GBE_MAX_RXD);
> >>
> >> clamp()
> >> And why you need the cast?
> >
> > [masa]
> > Since warning appears at the time of a make.
>
> OK, then you have type error which you should fix instead. Perhaps
> define the constnts with U suffix?

[masa]
I will modify like Stephen's comment
rxdr->count = clamp_val(ring->rx_pending, PCH_GBE_MIN_RXD, PCH_GBE_MAX_RXD);


> >>> + /* wait busy */
> >>> + while ((ioread32(&hw->reg->ADDR_MASK) & PCH_GBE_BUSY))
> >>> + cpu_relax();
> >>
> >> There should be probably some time limit. Nobody trusts hardware.
> >
> > [masa]
> > How should it modify?
>
> Similarly to other busy waiting code you have in other places. Some
> udelay with a loop bound.

[masa]
I understood.
This will be modified.


> >>> + if (unlikely(skb->len > (adapter->hw.mac.max_frame_size - 4))) {
> >>> + pr_err("Transfer length Error: skb len: %d > max: %d\n",
> >>> +        skb->len, adapter->hw.mac.max_frame_size);
> >>> + dev_kfree_skb_any(skb);
> >>> + adapter->stats.tx_length_errors++;
> >>> + return NETDEV_TX_BUSY;
> >>
> >> Not nice. ndev layer will reuse the freed skb now.
> >
> > [masa]
> > How should it modify?
>
> Remove dev_kfree_skb_any(skb) to not free the skb so that ndev layer can
> requeue the buffer.

[masa]
"dev_kfree_skb_any(skb)" is removed.


> >>> +#ifdef CONFIG_PM
> >>> + /* Implement our own version of pci_save_state(pdev) because pci-
> >>> + * express adapters have 256-byte config spaces. */
> >>> + retval = pci_save_state(pdev);
> >>
> >> But PCIe saves all caps, why you need this?
> >
> > [masa]
> > I can not understand.
> > Please let me know details.
>
> What exactly do you need the state of pcie for? The core should do it
> fine on its own...

[masa]
Since a config space needs to be stored, pci_save_state() is used.


> >>> + if (!dma_set_mask(&pdev->dev, DMA_BIT_MASK(64))
> >>> + && !dma_set_coherent_mask(&pdev->dev, DMA_BIT_MASK(64))) {
> >>> + ;
> >>> + } else {
> >>
> >> You should invert the logic. And use pci_ variants.
> >
> > [masa]
> > This will be modified like
> > if (dma_set_mask(&pdev->dev, DMA_BIT_MASK(64))
> >  || dma_set_coherent_mask(&pdev->dev, DMA_BIT_MASK(64))) {
> >
> > What is pci_ variants?
>
> No, don't use them, they used to be pci specific intended for dma
> setting/mapping but are deprecated now which I didn't realize.

[masa]
I use "pci_set_dma_mask" and "pci_set_coherent_mask".
This will be modified like below
OK?

> >>> + mmio_start = pci_resource_start(pdev, PCH_GBE_PCI_BAR);
> >>> + mmio_len = pci_resource_len(pdev, PCH_GBE_PCI_BAR);
> >>> + adapter->hw.reg = ioremap_nocache(mmio_start, mmio_len);
> >>
> >> pci_ioremap_bar()
> >>
> >> Anyway you should not use ioread/iowrite* on an ioremapped space. It is
> >> intended for iomapped space (pci_iomap) and is slower.
> >
> > [masa]
> > This will be modified like
> > pci_iomap(pdev, PCH_GBE_PCI_BAR, 0) is used.
>
> If you don't mind one extra branching in each read/write, then OK :).
> Here you know it's MMIO space I think, so pci_ioremap_map+readl/writel
> would be more appropriate and faster. But it's your call.

[masa]
I use "pci_ioremap_bar()"

Thanks Ohtake



  parent reply	other threads:[~2010-09-09 13:39 UTC|newest]

Thread overview: 43+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-09-03 14:09 Masayuki Ohtake
2010-09-03 16:35 ` Jiri Slaby
2010-09-07  1:13   ` Masayuki Ohtake
2010-09-08 13:52   ` Masayuki Ohtake
2010-09-08 14:16     ` Jiri Slaby
2010-09-08 14:54       ` Stephen Hemminger
2010-09-08 14:55       ` Stephen Hemminger
2010-09-09 13:37         ` Masayuki Ohtake
2010-09-09 13:38       ` Masayuki Ohtake [this message]
2010-09-03 20:00 ` Joe Perches
2010-09-07  2:42 ` Masayuki Ohtake
2010-09-08 20:36   ` David Miller
2010-09-15 12:19     ` Masayuki Ohtake
  -- strict thread matches above, loose matches on Subject: below --
2010-08-26  9:56 Masayuki Ohtake
2010-08-26 10:28 ` Sam Ravnborg
2010-08-26 12:47   ` Masayuki Ohtake
2010-08-26 14:44 ` Joe Perches
2010-08-26 15:34 ` Stephen Hemminger
2010-08-26 15:40 ` Stephen Hemminger
2010-08-26 15:41 ` Stephen Hemminger
2010-08-26 15:42 ` Stephen Hemminger
2010-08-26 15:43 ` Stephen Hemminger
2010-08-26 15:45 ` Stephen Hemminger
2010-08-26 15:47 ` Stephen Hemminger
2010-08-26 15:57 ` Stephen Hemminger
2010-08-26 16:05 ` Stephen Hemminger
2010-08-26 16:16   ` Joe Perches
2010-08-26 16:29     ` Stephen Hemminger
2010-08-26 17:02       ` Joe Perches
2010-08-31 14:15 ` Masayuki Ohtake
2010-08-31 14:51   ` Eric Dumazet
2010-09-02 12:39     ` Masayuki Ohtake
2010-09-02 13:40       ` Eric Dumazet
2010-09-02 15:10         ` Stephen Hemminger
2010-09-03 13:32           ` Masayuki Ohtake
2010-09-03 13:43             ` Eric Dumazet
2010-09-03 14:11               ` Masayuki Ohtake
2010-08-31 15:08   ` Randy Dunlap
2010-08-31 16:10   ` Joe Perches
2010-09-03  2:23   ` FUJITA Tomonori
2010-09-07  1:13     ` Masayuki Ohtake
2010-09-07  3:21       ` FUJITA Tomonori
2010-09-07  4:06         ` Masayuki Ohtake

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='002501cb5024$5a5e3800$66f8800a@maildom.okisemi.com' \
    --to=masa-korg@dsn.okisemi.com \
    --cc=andrew.chih.howe.khor@intel.com \
    --cc=davem@davemloft.net \
    --cc=gregory.v.rose@intel.com \
    --cc=joe@perches.com \
    --cc=joel.clark@intel.com \
    --cc=john.linn@xilinx.com \
    --cc=jslaby@suse.cz \
    --cc=kristoffer@gaisler.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=margie.foster@intel.com \
    --cc=mbizon@freebox.fr \
    --cc=meego-dev@meego.com \
    --cc=morinaga526@dsn.okisemi.com \
    --cc=netdev@vger.kernel.org \
    --cc=okada533@dsn.okisemi.com \
    --cc=qi.wang@intel.com \
    --cc=ralf@linux-mips.org \
    --cc=randy.dunlap@oracle.com \
    --cc=shimizu394@dsn.okisemi.com \
    --cc=yong.y.wang@intel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

Powered by JetHome