Sure I don't have major objections against your patch (though who is
formally mpc512x maintainer to ack it ?),
Grant is maintainer for MPC5xxx.
--
Pengutronix e.K. | Wolfram Sang|
Industrial Linux Solutions | http://www.pengutronix.de/
On Mon, Nov 2, 2009 at 7:22 AM, Wolfram Sang w.s...@pengutronix.de wrote:
Sure I don't have major objections against your patch (though who is
formally mpc512x maintainer to ack it ?),
Grant is maintainer for MPC5xxx.
Is this patch intended for mainline? I've received so many 5121
patches
Is this patch intended for mainline? I've received so many 5121
Yes, my branch is based on linus-git as of today. The CAN driver addition was
just posted to socketcan-devel. It is also independent of the denx-patches[1]
and will later be send to netdev, too.
[1] Of course, the FEC patches are
On Fri, Oct 30, 2009 at 10:53 AM, Wolfram Sang w.s...@pengutronix.de wrote:
+ bool id_matched = !id;
+ bool dev_matched = !dev;
[...]
+ dev_matched = true;
+ if (id strcmp(id, p-name) == 0)
+ id_matched = true;
Using
Hi Grant,
On Mon, 2 Nov 2009 10:48:58 -0700 Grant Likely grant.lik...@secretlab.ca
wrote:
Using bool/true/false doesn't seem to be a common pattern in the
kernel. Anyone know what the winds of prevailing opinion are
regarding 'bool' in kernel code?
Its a good thing.
--
Cheers,
Stephen
On Mon, Nov 2, 2009 at 4:10 PM, Stephen Rothwell s...@canb.auug.org.au wrote:
Hi Grant,
On Mon, 2 Nov 2009 10:48:58 -0700 Grant Likely grant.lik...@secretlab.ca
wrote:
Using bool/true/false doesn't seem to be a common pattern in the
kernel. Anyone know what the winds of prevailing opinion
Hello Ben,
Have you considered switching to my proposed device-tree based clock
reprentation ?
You mean this one?
http://patchwork.ozlabs.org/patch/31551/
Sorry, I have missed it up to now :(
While I think (after one glimpse) this moves things into the right direction,
my priority at the
On Sat, 2009-10-31 at 14:01 +0100, Wolfram Sang wrote:
Hello Ben,
Have you considered switching to my proposed device-tree based clock
reprentation ?
You mean this one?
http://patchwork.ozlabs.org/patch/31551/
Sorry, I have missed it up to now :(
While I think (after one
The matching logic returns a clock even if only the dev-part matches. This is
wrong as devices may utilize more than one clock, so the wrong clock may be
returned due to dev being not unique (noticed while working on the CAN driver).
The proposed new method will:
- require the id field (as _this_
On Fri, Oct 30, 2009 at 10:17:14AM +0100, Wolfram Sang wrote:
The matching logic returns a clock even if only the dev-part matches. This is
wrong as devices may utilize more than one clock, so the wrong clock may be
returned due to dev being not unique (noticed while working on the CAN
On Fri, Oct 30, 2009 at 10:54:14AM +, Mark Brown wrote:
On Fri, Oct 30, 2009 at 10:17:14AM +0100, Wolfram Sang wrote:
The matching logic returns a clock even if only the dev-part matches. This
is
wrong as devices may utilize more than one clock, so the wrong clock may be
returned due
The current matching logic returns a clock even if only one out of two
arguments matches. This is wrong as devices may utilize more than one clock, so
only the first clock out of those is returned if the dev-match alone is
considered sufficent (noticed while working on the CAN driver). The
On Fri, 2009-10-30 at 10:17 +0100, Wolfram Sang wrote:
The matching logic returns a clock even if only the dev-part matches. This is
wrong as devices may utilize more than one clock, so the wrong clock may be
returned due to dev being not unique (noticed while working on the CAN
driver).
The
13 matches
Mail list logo
