[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <5525B588.3020407@suse.de>
Date: Thu, 09 Apr 2015 01:11:04 +0200
From: Alexander Graf <agraf@...e.de>
To: "J. German Rivera" <German.Rivera@...escale.com>,
gregkh@...uxfoundation.org, arnd@...db.de,
devel@...verdev.osuosl.org, linux-kernel@...r.kernel.org
CC: stuart.yoder@...escale.com, Kim.Phillips@...escale.com,
scottwood@...escale.com, bhamciu1@...escale.com,
R89243@...escale.com, bhupesh.sharma@...escale.com,
nir.erez@...escale.com, richard.schmitt@...escale.com
Subject: Re: [PATCH 6/6] staging: fsl-mc: Changed version matching rules for
MC object drivers
On 03/27/2015 10:01 PM, J. German Rivera wrote:
> Before this change, we were requiring a complete version match (major and
> minor version numbers) between MC objects and corresponding drivers, to
> allow MC objects to be bound to their drivers. We realized that a mismatch
> in minor version numbers should be tolerated, as long as the major version
> numbers match. This allows the driver to decide what to do in the minor
> version mismatch case. For example, a driver may decide to run with
> downgraded functionality if the MC firmware object has older minor version
> number than the driver. Also, a driver with older minor version than the
> MC firmware object may decide to run even though it cannot use newer
> functionality of the MC object.
>
> As part of this change, the dpmng Flib version was also updated
> to match the latest MC firmware version.
>
> Signed-off-by: J. German Rivera <German.Rivera@...escale.com>
I think this is a step into the right direction, but you really don't
want to match only when the minor equals. Usually you'd like something like
if (cur_minor > max_minor) {
dev_warn("Unknown version %d.%d of fsl-mc detected. Please update
your kernel if you encounter problems.")
}
but always assume that cur_minor < max_minor works. In cases where the
protocol did change between minors, add code to support the older minors
as well.
Alex
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists