All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dan Carpenter <dan.carpenter@oracle.com>
To: "Petr Štetiar" <ynezz@true.cz>
Cc: netdev@vger.kernel.org, devicetree@vger.kernel.org,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	devel@driverdev.osuosl.org, Andrew Lunn <andrew@lunn.ch>,
	Florian Fainelli <f.fainelli@gmail.com>,
	Maxime Ripard <maxime.ripard@bootlin.com>,
	linux-kernel@vger.kernel.org,
	Srinivas Kandagatla <srinivas.kandagatla@linaro.org>,
	Frank Rowand <frowand.list@gmail.com>,
	Heiner Kallweit <hkallweit1@gmail.com>
Subject: Re: [PATCH v3 08/10] staging: octeon-ethernet: support of_get_mac_address new ERR_PTR error
Date: Fri, 3 May 2019 13:34:56 +0300	[thread overview]
Message-ID: <20190503103456.GF2269@kadam> (raw)
In-Reply-To: <1556870168-26864-9-git-send-email-ynezz@true.cz>

On Fri, May 03, 2019 at 09:56:05AM +0200, Petr Štetiar wrote:
> There was NVMEM support added to of_get_mac_address, so it could now
> return NULL and ERR_PTR encoded error values, so we need to adjust all
> current users of of_get_mac_address to this new fact.

Which commit added NVMEM support?  It hasn't hit net-next or linux-next
yet...  Very strange.

Why would of_get_mac_address() return a mix of NULL and error pointers?
In that situation, then NULL is a special kind of success like when you
request feature and the feature works but it's disabled by the user.  We
don't want to treat it as an error but we still can't return a pointer
to a feature we don't have...  It's hard for me to imagine how that
makes sense for getting a mac address.

At the very least, this patch needs a Fixes tag.

regards,
dan carpenter


WARNING: multiple messages have this Message-ID (diff)
From: Dan Carpenter <dan.carpenter@oracle.com>
To: "Petr Štetiar" <ynezz@true.cz>
Cc: devel@driverdev.osuosl.org, Andrew Lunn <andrew@lunn.ch>,
	Florian Fainelli <f.fainelli@gmail.com>,
	devicetree@vger.kernel.org,
	Maxime Ripard <maxime.ripard@bootlin.com>,
	netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
	Srinivas Kandagatla <srinivas.kandagatla@linaro.org>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Frank Rowand <frowand.list@gmail.com>,
	Heiner Kallweit <hkallweit1@gmail.com>
Subject: Re: [PATCH v3 08/10] staging: octeon-ethernet: support of_get_mac_address new ERR_PTR error
Date: Fri, 3 May 2019 13:34:56 +0300	[thread overview]
Message-ID: <20190503103456.GF2269@kadam> (raw)
In-Reply-To: <1556870168-26864-9-git-send-email-ynezz@true.cz>

On Fri, May 03, 2019 at 09:56:05AM +0200, Petr Štetiar wrote:
> There was NVMEM support added to of_get_mac_address, so it could now
> return NULL and ERR_PTR encoded error values, so we need to adjust all
> current users of of_get_mac_address to this new fact.

Which commit added NVMEM support?  It hasn't hit net-next or linux-next
yet...  Very strange.

Why would of_get_mac_address() return a mix of NULL and error pointers?
In that situation, then NULL is a special kind of success like when you
request feature and the feature works but it's disabled by the user.  We
don't want to treat it as an error but we still can't return a pointer
to a feature we don't have...  It's hard for me to imagine how that
makes sense for getting a mac address.

At the very least, this patch needs a Fixes tag.

regards,
dan carpenter

_______________________________________________
devel mailing list
devel@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

  reply	other threads:[~2019-05-03 10:37 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-05-03  7:55 [PATCH v3 00/10] of_net: Add NVMEM support to of_get_mac_address Petr Štetiar
2019-05-03  7:55 ` Petr Štetiar
2019-05-03  7:55 ` [PATCH v3 01/10] of_net: add " Petr Štetiar
2019-05-03  8:44   ` Sergei Shtylyov
2019-05-03  9:15     ` Petr Štetiar
2019-05-03  9:36       ` Maxime Ripard
2019-05-03 12:05       ` Andrew Lunn
2019-05-03  7:55 ` [PATCH v3 02/10] dt-bindings: doc: reflect new NVMEM of_get_mac_address behaviour Petr Štetiar
2019-05-03  7:55   ` Petr Štetiar
2019-05-03  7:55   ` Petr Štetiar
2019-05-03  7:56 ` [PATCH v3 03/10] net: macb: support of_get_mac_address new ERR_PTR error Petr Štetiar
2019-05-03  7:56 ` [PATCH v3 04/10] net: davinci: " Petr Štetiar
2019-05-03  7:56 ` [PATCH v3 05/10] net: ethernet: " Petr Štetiar
2019-05-03  7:56   ` Petr Štetiar
2019-05-03  7:56   ` Petr Štetiar
2019-05-03  7:56 ` [PATCH v3 06/10] net: usb: " Petr Štetiar
2019-05-03  7:56   ` [v3,06/10] " Petr Štetiar
2019-05-03  7:56 ` [PATCH v3 07/10] net: wireless: " Petr Štetiar
2019-05-03  7:56   ` Petr Štetiar
2019-05-03  7:56 ` [PATCH v3 08/10] staging: octeon-ethernet: " Petr Štetiar
2019-05-03 10:34   ` Dan Carpenter [this message]
2019-05-03 10:34     ` Dan Carpenter
2019-05-03 19:07     ` Petr Štetiar
2019-05-03 19:07       ` Petr Štetiar
2019-05-03 19:40       ` Dan Carpenter
2019-05-03 19:40         ` Dan Carpenter
2019-05-03  7:56 ` [PATCH v3 09/10] ARM: Kirkwood: " Petr Štetiar
2019-05-03  7:56   ` Petr Štetiar
2019-05-03  7:56 ` [PATCH v3 10/10] powerpc: tsi108: " Petr Štetiar
2019-05-03  7:56   ` Petr Štetiar

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=20190503103456.GF2269@kadam \
    --to=dan.carpenter@oracle.com \
    --cc=andrew@lunn.ch \
    --cc=devel@driverdev.osuosl.org \
    --cc=devicetree@vger.kernel.org \
    --cc=f.fainelli@gmail.com \
    --cc=frowand.list@gmail.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=hkallweit1@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=maxime.ripard@bootlin.com \
    --cc=netdev@vger.kernel.org \
    --cc=srinivas.kandagatla@linaro.org \
    --cc=ynezz@true.cz \
    /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.