Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Date:   Fri, 7 Aug 2020 11:31:46 +0200
From:   Jean Delvare <jdelvare@suse.de>
To:     Bartosz Golaszewski <brgl@bgdev.pl>
Cc:     LKML <linux-kernel@vger.kernel.org>,
        Linux I2C <linux-i2c@vger.kernel.org>,
        Bartosz Golaszewski <bgolaszewski@baylibre.com>,
        Arnd Bergmann <arnd@arndb.de>,
        Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Subject: Re: VAIO EEPROM support in at24
Message-ID: <20200807113146.7557c18b@endymion>
In-Reply-To: <20200805163655.6cfa6e17@endymion>
References: <20200317151409.7940926c@endymion>
        <CAMRc=Mdoh5Sk3iS_CO4+++SG2jJOy1qrG4q2zOzbeYYMdJR0VA@mail.gmail.com>
        <20200805163655.6cfa6e17@endymion>
Organization: SUSE Linux
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Wed, 5 Aug 2020 16:36:55 +0200, Jean Delvare wrote:
> 1* Do we actually need to use a struct resource? With the current
>    requirements, that looks overkill to me. We really only need the
>    start and end offsets of the masked area (or start and length). Or
>    do you plan to ever support multiple masked ranges, and
>    resource.child would be used to daisy-chain these ranges? Personally
>    I would wait until the need exists.

Dang, turns out that the need already exists. I just found that the
eeprom driver masks *2* areas of the Sony VAIO EEPROMs. I should know
because I'm the one who made that change but that was 13 years ago and
my memory doesn't go that far back.

I'll think of a way to support that. Still not a big fan of
daisy-chained resource structs though. Maybe a generic post-processing
callback function would do... I'll give that a try.

-- 
Jean Delvare
SUSE L3 Support