mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Nicolas Ferre <nicolas.ferre@microchip.com>
To: Harini Katakam <harinik@xilinx.com>
Cc: <linux-arm-kernel@lists.infradead.org>, <netdev@vger.kernel.org>,
	"Claudiu Beznea" <claudiu.beznea@microchip.com>,
	Harini Katakam <harini.katakam@xilinx.com>,
	<linux-kernel@vger.kernel.org>,
	"David S. Miller" <davem@davemloft.net>,
	Alexandre Belloni <alexandre.belloni@bootlin.com>,
	Rafal Ozieblo <rafalo@cadence.com>, <sergio.prado@e-labworks.com>,
	<antoine.tenart@bootlin.com>,
	Florian Fainelli <f.fainelli@gmail.com>, <linux@armlinux.org.uk>,
	Andrew Lunn <andrew@lunn.ch>,
	Michal Simek <michal.simek@xilinx.com>
Subject: Re: [RFC PATCH 0/3] net: macb: Wake-on-Lan magic packet fixes
Date: Mon, 6 Apr 2020 16:25:47 +0200	[thread overview]
Message-ID: <9e2ab6cd-526d-f1b5-4bd0-4a8f80d9dd8f@microchip.com> (raw)
In-Reply-To: <CAFcVECLkPxN0nk=jr9AxJoV3i1jHBoY4s3yeodHDO2uOZspQPg@mail.gmail.com>

Hi Harini,

On 03/04/2020 at 15:36, Harini Katakam wrote:
> Hi Nicolas,
> 
> On Fri, Apr 3, 2020 at 6:45 PM <nicolas.ferre@microchip.com> wrote:
>>
>> From: Nicolas Ferre <nicolas.ferre@microchip.com>
>>
>> Hi,
>> Here are some of my early patches in order to fix WoL magic-packet on the
>> current macb driver.
>> Addition of this feature to GEM types of IPs is yet to come. I would like to
>> have your feedback on these little patches first so that I can continue
>> investigating the addition of GEM WoL magic-packet.
>>
>> Harini, I know that you have patches for GEM in order to integrate WoL ARP
>> mode [1]. I'll try to integrate some of your work but would need that this feature
>> is better integrated in current code. For instance, the choice of "magic
>> packet" or "ARP" should be done by ethtool options and DT properties. For
>> matching with mainline users, MACB and GEM code must co-exist.
> 
> Agree. I'll try to test this series and get back to you next week.
> 
>> The use of dumb buffers for RX seems also fairly platform specific and we would
>> need to think more about it.
> 
> I know that the IP versions from r1p10 have a mechanism to disable DMA queues
> (bit 0 of the queue pointer register) which is cleaner. But for
> earlier IP versions,

Which IP name are you referring to? GEM, GEM-GXL? What is the value of 
register 0xFC then?

> I remember discussing with Cadence and there is no way to keep RX
> enabled for WOL
> with RX DMA disabled. I'm afraid that means there should be a bare
> minimum memory
> region with a dummy descriptor if you do not want to process the
> packets. That memory
> should also be accessible while the rest of the system is powered
> down. Please let me

Very interesting information Harini, thanks a lot for having shared it.

My GEM IP has 0xFC at value: 0x00020203. But I don't see a way to keep 
DMA queues disabled by using the famous bit that you mention above.

> know if you think of any other solution.

I'm trying all this right now. I keep you posted.

Thanks and best regards,
   Nicolas


-- 
Nicolas Ferre

  reply	other threads:[~2020-04-06 14:25 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-03 13:14 nicolas.ferre
2020-04-03 13:14 ` [RFC PATCH 1/3] net: macb: fix wakeup test in runtime suspend/resume routines nicolas.ferre
2020-04-03 13:14 ` [RFC PATCH 2/3] net: macb: mark device wake capable when "magic-packet" property present nicolas.ferre
2020-04-03 13:14 ` [RFC PATCH 3/3] net: macb: fix macb_get/set_wol() when moving to phylink nicolas.ferre
2020-04-03 13:36 ` [RFC PATCH 0/3] net: macb: Wake-on-Lan magic packet fixes Harini Katakam
2020-04-06 14:25   ` Nicolas Ferre [this message]
2020-04-06 14:52     ` Harini Katakam

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=9e2ab6cd-526d-f1b5-4bd0-4a8f80d9dd8f@microchip.com \
    --to=nicolas.ferre@microchip.com \
    --cc=alexandre.belloni@bootlin.com \
    --cc=andrew@lunn.ch \
    --cc=antoine.tenart@bootlin.com \
    --cc=claudiu.beznea@microchip.com \
    --cc=davem@davemloft.net \
    --cc=f.fainelli@gmail.com \
    --cc=harini.katakam@xilinx.com \
    --cc=harinik@xilinx.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@armlinux.org.uk \
    --cc=michal.simek@xilinx.com \
    --cc=netdev@vger.kernel.org \
    --cc=rafalo@cadence.com \
    --cc=sergio.prado@e-labworks.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

all inboxes | Powered by JetHome®