All of lore.kernel.org
 help / color / mirror / Atom feed
From: Wolfram Sang <wsa@the-dreams.de>
To: Bjorn Ardo <bjorn.ardo@axis.com>
Cc: "Patrick Williams" <patrick@stwcx.xyz>,
	"Björn Ardö" <bjornar@axis.com>,
	linux-i2c@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/2] i2c: slave-eeprom: initialize empty eeprom properly
Date: Wed, 22 Apr 2020 11:36:42 +0200	[thread overview]
Message-ID: <20200422093642.GA1245@ninjato> (raw)
In-Reply-To: <47891236-f1df-c130-0bce-d114523880cb@axis.com>

[-- Attachment #1: Type: text/plain, Size: 1041 bytes --]


> I did like this now: If device_property_read_string() returns a firmware
> name, I use that, otherwise init to 0xFF. But if it returns a firmware name,
> and for some reason I get an error when trying to load that firmware I will
> not default to 0xFF, but rather fail the probe. The logic in that is that if
> you actively supply a firmware name, you should not silently get 0xFF in
> your eeprom. Does that sound good?

Sounds perfect to me.

> > Yes, that is my idea. You also need to replace checking for an of_node
> > with some equivalent for device properties maybe, but that should be
> > easy to find out.
> 
> It appears to me that those kind of checks are done inside
> device_property_read_string() so I can just remove them and only look at the
> return value of that function.

Even better!

> I have a patch now working on 4.14, will run some tests on it and then try
> to forward-port to latest kernel och see if it works there as well.

Looking forward to it. I will look at it right away then!


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

  reply	other threads:[~2020-04-22  9:36 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-01 16:40 [PATCH 1/2] i2c: slave-eeprom: initialize empty eeprom properly Patrick Williams
2019-10-01 16:40 ` Patrick Williams
2019-10-01 16:40 ` [PATCH 2/2] i2c: slave-eeprom: support additional models Patrick Williams
2019-10-01 16:40   ` Patrick Williams
2020-04-20 16:46   ` Wolfram Sang
2020-04-20 20:23     ` Patrick Williams
2019-10-02  6:20 ` [PATCH 1/2] i2c: slave-eeprom: initialize empty eeprom properly Bjorn Ardo
2020-04-20 16:43   ` Wolfram Sang
2020-04-20 20:24     ` Patrick Williams
2020-04-20 20:31     ` Patrick Williams
2020-04-20 20:53       ` Wolfram Sang
2020-04-21 12:03         ` Bjorn Ardo
2020-04-21 12:16           ` Wolfram Sang
2020-04-22  9:30             ` Bjorn Ardo
2020-04-22  9:36               ` Wolfram Sang [this message]
2020-04-24  9:06                 ` Bjorn Ardo

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=20200422093642.GA1245@ninjato \
    --to=wsa@the-dreams.de \
    --cc=bjorn.ardo@axis.com \
    --cc=bjornar@axis.com \
    --cc=linux-i2c@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=patrick@stwcx.xyz \
    /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.