* linux-next: build failure after merge of the driver-core tree
@ 2010-03-17 4:41 Stephen Rothwell
2010-03-17 7:21 ` Neil Brown
0 siblings, 1 reply; 181+ messages in thread
From: Stephen Rothwell @ 2010-03-17 4:41 UTC (permalink / raw)
To: Greg KH; +Cc: linux-next, linux-kernel, Sage Weil, NeilBrown
Hi Greg,
After merging the driver-core tree, today's linux-next build (x86_64
allmodconfig) failed like this:
fs/ceph/msgpool.c: In function 'ceph_msgpool_put':
fs/ceph/msgpool.c:173: error: implicit declaration of function 'kref_set'
Caused by commit 10c5d9fdc9ba89606b34f01cbe6ea287abba7395 ("kref: remove
kref_set") from the driver-core tree interacting with commit
c2e552e76e2c6907ca50cd9a4b747a2e2e8c615e ("ceph: use kref for ceph_msg")
from the ceph tree.
I applied the following patch for today (which may not be correct):
[Sage, if this patch is correct, it should be applied to the ceph tree.]
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Wed, 17 Mar 2010 15:35:22 +1100
Subject: [PATCH] ceph: update for removal of kref_set
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
fs/ceph/msgpool.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/fs/ceph/msgpool.c b/fs/ceph/msgpool.c
index ca3b44a..030297f 100644
--- a/fs/ceph/msgpool.c
+++ b/fs/ceph/msgpool.c
@@ -170,7 +170,7 @@ void ceph_msgpool_put(struct ceph_msgpool *pool, struct ceph_msg *msg)
msg->front.iov_len = pool->front_len;
msg->hdr.front_len = cpu_to_le32(pool->front_len);
- kref_set(&msg->kref, 1); /* retake a single ref */
+ kref_init(&msg->kref); /* retake a single ref */
list_add(&msg->list_head, &pool->msgs);
pool->num++;
dout("msgpool_put %p reclaim %p, now %d/%d\n", pool, msg,
--
1.7.0
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
^ permalink raw reply related [flat|nested] 181+ messages in thread
* Re: linux-next: build failure after merge of the driver-core tree
2010-03-17 4:41 linux-next: build failure after merge of the driver-core tree Stephen Rothwell
@ 2010-03-17 7:21 ` Neil Brown
2010-03-17 15:51 ` Sage Weil
0 siblings, 1 reply; 181+ messages in thread
From: Neil Brown @ 2010-03-17 7:21 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: Greg KH, linux-next, linux-kernel, Sage Weil
On Wed, 17 Mar 2010 15:41:45 +1100
Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> Hi Greg,
>
> After merging the driver-core tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
>
> fs/ceph/msgpool.c: In function 'ceph_msgpool_put':
> fs/ceph/msgpool.c:173: error: implicit declaration of function 'kref_set'
>
> Caused by commit 10c5d9fdc9ba89606b34f01cbe6ea287abba7395 ("kref: remove
> kref_set") from the driver-core tree interacting with commit
> c2e552e76e2c6907ca50cd9a4b747a2e2e8c615e ("ceph: use kref for ceph_msg")
> from the ceph tree.
>
> I applied the following patch for today (which may not be correct):
I would say this is correct.
The msg has seen it's last_put and is being placed in the pool of
free messages, so it needs to be in the same state that ceph_msg_new
(called in __fill_msgpool) leaves it in.
ceph_msg_new used kref_init, so ceph_msgpool_put should use kref_init too to
match.
It is a pity that this code cannot use mempool_t....
What if mempool_t were changed to only re-alloc the vector of pointers when
it grew, or when it shrank to less than 1/2 it's current size. Would that
reduce the frequency of allocations enough for you to be comfortable with it?
i.e. always make the vector a power-of-2 size (which is what is probably
allocated anyway) while the pool size might be less.
??
NeilBrown
>
> [Sage, if this patch is correct, it should be applied to the ceph tree.]
>
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Wed, 17 Mar 2010 15:35:22 +1100
> Subject: [PATCH] ceph: update for removal of kref_set
>
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> ---
> fs/ceph/msgpool.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/fs/ceph/msgpool.c b/fs/ceph/msgpool.c
> index ca3b44a..030297f 100644
> --- a/fs/ceph/msgpool.c
> +++ b/fs/ceph/msgpool.c
> @@ -170,7 +170,7 @@ void ceph_msgpool_put(struct ceph_msgpool *pool, struct ceph_msg *msg)
> msg->front.iov_len = pool->front_len;
> msg->hdr.front_len = cpu_to_le32(pool->front_len);
>
> - kref_set(&msg->kref, 1); /* retake a single ref */
> + kref_init(&msg->kref); /* retake a single ref */
> list_add(&msg->list_head, &pool->msgs);
> pool->num++;
> dout("msgpool_put %p reclaim %p, now %d/%d\n", pool, msg,
^ permalink raw reply [flat|nested] 181+ messages in thread
* Re: linux-next: build failure after merge of the driver-core tree
2010-03-17 7:21 ` Neil Brown
@ 2010-03-17 15:51 ` Sage Weil
2010-03-17 22:30 ` Stephen Rothwell
2010-03-24 1:37 ` Neil Brown
0 siblings, 2 replies; 181+ messages in thread
From: Sage Weil @ 2010-03-17 15:51 UTC (permalink / raw)
To: Neil Brown; +Cc: Stephen Rothwell, Greg KH, linux-next, linux-kernel
On Wed, 17 Mar 2010, Neil Brown wrote:
> On Wed, 17 Mar 2010 15:41:45 +1100
> Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> > Hi Greg,
> >
> > After merging the driver-core tree, today's linux-next build (x86_64
> > allmodconfig) failed like this:
> >
> > fs/ceph/msgpool.c: In function 'ceph_msgpool_put':
> > fs/ceph/msgpool.c:173: error: implicit declaration of function 'kref_set'
> >
> > Caused by commit 10c5d9fdc9ba89606b34f01cbe6ea287abba7395 ("kref: remove
> > kref_set") from the driver-core tree interacting with commit
> > c2e552e76e2c6907ca50cd9a4b747a2e2e8c615e ("ceph: use kref for ceph_msg")
> > from the ceph tree.
> >
> > I applied the following patch for today (which may not be correct):
>
> I would say this is correct.
Yeah, the fix is good, thanks Stephen! I'll add it to my tree shortly.
> It is a pity that this code cannot use mempool_t....
> What if mempool_t were changed to only re-alloc the vector of pointers when
> it grew, or when it shrank to less than 1/2 it's current size. Would that
> reduce the frequency of allocations enough for you to be comfortable with it?
> i.e. always make the vector a power-of-2 size (which is what is probably
> allocated anyway) while the pool size might be less.
> ??
That would improve the situation, but still mean potentially large
allocations (the pools can grow pretty big) that aren't strictly
necessary. I can imagine a more modular mempool_t with an ops vector for
adding/removing from the pool to cope with situations like this, but I'm
not sure it's worth the effort?
sage
^ permalink raw reply [flat|nested] 181+ messages in thread
* Re: linux-next: build failure after merge of the driver-core tree
2010-03-17 15:51 ` Sage Weil
@ 2010-03-17 22:30 ` Stephen Rothwell
2010-03-24 1:37 ` Neil Brown
1 sibling, 0 replies; 181+ messages in thread
From: Stephen Rothwell @ 2010-03-17 22:30 UTC (permalink / raw)
To: Sage Weil; +Cc: Neil Brown, Greg KH, linux-next, linux-kernel
[-- Attachment #1: Type: text/plain, Size: 392 bytes --]
Hi guys,
On Wed, 17 Mar 2010 08:51:49 -0700 (PDT) Sage Weil <sage@newdream.net> wrote:
>
> On Wed, 17 Mar 2010, Neil Brown wrote:
>
> > I would say this is correct.
>
> Yeah, the fix is good, thanks Stephen! I'll add it to my tree shortly.
Thanks for the confirmation.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply [flat|nested] 181+ messages in thread
* Re: linux-next: build failure after merge of the driver-core tree
2010-03-17 15:51 ` Sage Weil
2010-03-17 22:30 ` Stephen Rothwell
@ 2010-03-24 1:37 ` Neil Brown
2010-03-24 14:54 ` Sage Weil
1 sibling, 1 reply; 181+ messages in thread
From: Neil Brown @ 2010-03-24 1:37 UTC (permalink / raw)
To: Sage Weil; +Cc: Stephen Rothwell, Greg KH, linux-next, linux-kernel
On Wed, 17 Mar 2010 08:51:49 -0700 (PDT)
Sage Weil <sage@newdream.net> wrote:
> > It is a pity that this code cannot use mempool_t....
> > What if mempool_t were changed to only re-alloc the vector of pointers when
> > it grew, or when it shrank to less than 1/2 it's current size. Would that
> > reduce the frequency of allocations enough for you to be comfortable with it?
> > i.e. always make the vector a power-of-2 size (which is what is probably
> > allocated anyway) while the pool size might be less.
> > ??
>
> That would improve the situation, but still mean potentially large
> allocations (the pools can grow pretty big) that aren't strictly
> necessary. I can imagine a more modular mempool_t with an ops vector for
> adding/removing from the pool to cope with situations like this, but I'm
> not sure it's worth the effort?
How big?
mempools (and equivalents) should just be large enough to get you through a
tight spot. The working assumption is that they will not normally be used.
So 2 or 3 should normally be plenty.
(looks at code)
The only time you resize a ceph_mempool is in ceph_monc_do_statfs
where you increment it, perform a synchronous statfs call on the
network, then decrement the size of the mempool.
How many concurrent statfs calls does it even make sense to make.
I'm probably missing something obvious, but wouldn't it make sense to
put that all under a mutex so there was only ever one outstanding statfs (per
filesystem) - or maybe under a counting semaphore to allow some small number,
and make sure to prime the mempool to cover that number.
Then you would never resize a mempool at all.
I notice that all other mempools that ceph uses are sensibly quite small and
stay that way.
NeilBrown
^ permalink raw reply [flat|nested] 181+ messages in thread
* Re: linux-next: build failure after merge of the driver-core tree
2010-03-24 1:37 ` Neil Brown
@ 2010-03-24 14:54 ` Sage Weil
0 siblings, 0 replies; 181+ messages in thread
From: Sage Weil @ 2010-03-24 14:54 UTC (permalink / raw)
To: Neil Brown; +Cc: Stephen Rothwell, Greg KH, linux-next, linux-kernel
On Wed, 24 Mar 2010, Neil Brown wrote:
> Sage Weil <sage@newdream.net> wrote:
> > > It is a pity that this code cannot use mempool_t....
> > > What if mempool_t were changed to only re-alloc the vector of pointers when
> > > it grew, or when it shrank to less than 1/2 it's current size. Would that
> > > reduce the frequency of allocations enough for you to be comfortable with it?
> > > i.e. always make the vector a power-of-2 size (which is what is probably
> > > allocated anyway) while the pool size might be less.
> > > ??
> >
> > That would improve the situation, but still mean potentially large
> > allocations (the pools can grow pretty big) that aren't strictly
> > necessary. I can imagine a more modular mempool_t with an ops vector for
> > adding/removing from the pool to cope with situations like this, but I'm
> > not sure it's worth the effort?
>
> How big?
> mempools (and equivalents) should just be large enough to get you through a
> tight spot. The working assumption is that they will not normally be used.
> So 2 or 3 should normally be plenty.
>
> (looks at code)
>
> The only time you resize a ceph_mempool is in ceph_monc_do_statfs
> where you increment it, perform a synchronous statfs call on the
> network, then decrement the size of the mempool.
> How many concurrent statfs calls does it even make sense to make.
> I'm probably missing something obvious, but wouldn't it make sense to
> put that all under a mutex so there was only ever one outstanding statfs (per
> filesystem) - or maybe under a counting semaphore to allow some small number,
> and make sure to prime the mempool to cover that number.
> Then you would never resize a mempool at all.
You're right. In fact, after reviewing the code again, it looks like
_none_ of the msgpools (current or planned) needs to get large anymore.
A protocol change a month or two back made it possible to allocate space
for the reply along with the request, which means the only remaining use
for the pools is for low memory writeout and the handful of messages we
might receive from servers without asking for them. (There used to be
more of the msgpool resizing going on for other types of requests, but
it's been mostly fixed up.)
I'll work on cleaning up the request/reply instances to avoid pools
altogether. The remaining pools should be small enough to use the
standard mempool_t.
Thanks for looking into this!
sage
^ permalink raw reply [flat|nested] 181+ messages in thread
* Re: linux-next: build failure after merge of the driver-core tree
2023-08-15 15:21 ` Greg KH
@ 2023-08-16 7:39 ` Maxime Ripard
0 siblings, 0 replies; 181+ messages in thread
From: Maxime Ripard @ 2023-08-16 7:39 UTC (permalink / raw)
To: Greg KH
Cc: Stephen Rothwell, Linux Kernel Mailing List, Linux Next Mailing List
[-- Attachment #1: Type: text/plain, Size: 957 bytes --]
Hi Greg
On Tue, Aug 15, 2023 at 05:21:35PM +0200, Greg KH wrote:
> On Tue, Aug 15, 2023 at 05:24:54PM +1000, Stephen Rothwell wrote:
> > Hi all,
> >
> > After merging the driver-core tree, today's linux-next build (x86_64
> > allmodconfig) failed like this:
> >
> > ERROR: modpost: missing MODULE_LICENSE() in drivers/base/test/root-device-test.o
> > ERROR: modpost: missing MODULE_LICENSE() in drivers/base/test/platform-device-test.o
> >
> > Caused by commits
> >
> > 06188bc80ccb ("drivers: base: Add basic devm tests for root devices")
> > b4cc44301b9d ("drivers: base: Add basic devm tests for platform devices")
> >
> > I have used the driver-core tree from next-20230809 for today.
>
> Ick, obviously no one tested these somehow :(
kunit compiles those tests builtin by default
> Maxime, can you send me a fix, or I can just revert the changes for now
> and wait for a new series?
I just sent fixes
Maxime
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply [flat|nested] 181+ messages in thread
* Re: linux-next: build failure after merge of the driver-core tree
2023-08-15 7:24 Stephen Rothwell
@ 2023-08-15 15:21 ` Greg KH
2023-08-16 7:39 ` Maxime Ripard
0 siblings, 1 reply; 181+ messages in thread
From: Greg KH @ 2023-08-15 15:21 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Maxime Ripard, Linux Kernel Mailing List, Linux Next Mailing List
On Tue, Aug 15, 2023 at 05:24:54PM +1000, Stephen Rothwell wrote:
> Hi all,
>
> After merging the driver-core tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
>
> ERROR: modpost: missing MODULE_LICENSE() in drivers/base/test/root-device-test.o
> ERROR: modpost: missing MODULE_LICENSE() in drivers/base/test/platform-device-test.o
>
> Caused by commits
>
> 06188bc80ccb ("drivers: base: Add basic devm tests for root devices")
> b4cc44301b9d ("drivers: base: Add basic devm tests for platform devices")
>
> I have used the driver-core tree from next-20230809 for today.
Ick, obviously no one tested these somehow :(
Maxime, can you send me a fix, or I can just revert the changes for now
and wait for a new series?
thanks,
greg k-h
^ permalink raw reply [flat|nested] 181+ messages in thread
* linux-next: build failure after merge of the driver-core tree
@ 2023-08-15 7:24 Stephen Rothwell
2023-08-15 15:21 ` Greg KH
0 siblings, 1 reply; 181+ messages in thread
From: Stephen Rothwell @ 2023-08-15 7:24 UTC (permalink / raw)
To: Greg KH
Cc: Greg Kroah-Hartman, Maxime Ripard, Linux Kernel Mailing List,
Linux Next Mailing List
[-- Attachment #1: Type: text/plain, Size: 557 bytes --]
Hi all,
After merging the driver-core tree, today's linux-next build (x86_64
allmodconfig) failed like this:
ERROR: modpost: missing MODULE_LICENSE() in drivers/base/test/root-device-test.o
ERROR: modpost: missing MODULE_LICENSE() in drivers/base/test/platform-device-test.o
Caused by commits
06188bc80ccb ("drivers: base: Add basic devm tests for root devices")
b4cc44301b9d ("drivers: base: Add basic devm tests for platform devices")
I have used the driver-core tree from next-20230809 for today.
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 181+ messages in thread
* Re: linux-next: build failure after merge of the driver-core tree
2023-04-11 18:47 ` Daniel Vetter
@ 2023-04-12 6:11 ` Greg KH
0 siblings, 0 replies; 181+ messages in thread
From: Greg KH @ 2023-04-12 6:11 UTC (permalink / raw)
To: Jeffrey Hugo, Stephen Rothwell, Oded Gabbay,
Linux Kernel Mailing List, DRI, Pranjal Ramajor Asha Kanojiya,
Linux Next Mailing List, Jacek Lawrynowicz, Dave Airlie,
Manivannan Sadhasivam
On Tue, Apr 11, 2023 at 08:47:10PM +0200, Daniel Vetter wrote:
> On Tue, Apr 11, 2023 at 12:37:23PM -0600, Jeffrey Hugo wrote:
> > On 4/11/2023 12:21 PM, Daniel Vetter wrote:
> > > On Tue, Apr 11, 2023 at 11:18:29AM -0600, Jeffrey Hugo wrote:
> > > > On 4/11/2023 10:31 AM, Daniel Vetter wrote:
> > > > > On Tue, Apr 11, 2023 at 09:29:27AM -0600, Jeffrey Hugo wrote:
> > > > > > On 4/11/2023 9:26 AM, Jeffrey Hugo wrote:
> > > > > > > On 4/11/2023 9:13 AM, Greg KH wrote:
> > > > > > > > On Tue, Apr 11, 2023 at 09:08:39AM -0600, Jeffrey Hugo wrote:
> > > > > > > > > On 4/11/2023 9:01 AM, Daniel Vetter wrote:
> > > > > > > > > > On Tue, Apr 11, 2023 at 12:40:28PM +0200, Greg KH wrote:
> > > > > > > > > > > On Tue, Apr 11, 2023 at 11:55:20AM +0200, Daniel Vetter wrote:
> > > > > > > > > > > > On Tue, Apr 11, 2023 at 02:38:12PM +1000, Stephen Rothwell wrote:
> > > > > > > > > > > > > Hi all,
> > > > > > > > > > > > >
> > > > > > > > > > > > > After merging the driver-core tree, today's linux-next build (x86_64
> > > > > > > > > > > > > allmodconfig) failed like this:
> > > > > > > > > > > > >
> > > > > > > > > > > > > In file included from include/linux/linkage.h:7,
> > > > > > > > > > > > > from include/linux/kernel.h:17,
> > > > > > > > > > > > > from drivers/accel/qaic/mhi_qaic_ctrl.c:4:
> > > > > > > > > > > > > drivers/accel/qaic/mhi_qaic_ctrl.c: In function
> > > > > > > > > > > > > 'mhi_qaic_ctrl_init':
> > > > > > > > > > > > > include/linux/export.h:27:22: error: passing
> > > > > > > > > > > > > argument 1 of 'class_create' from incompatible
> > > > > > > > > > > > > pointer type
> > > > > > > > > > > > > [-Werror=incompatible-pointer-types]
> > > > > > > > > > > > > 27 | #define THIS_MODULE (&__this_module)
> > > > > > > > > > > > > | ~^~~~~~~~~~~~~~~
> > > > > > > > > > > > > | |
> > > > > > > > > > > > > | struct module *
> > > > > > > > > > > > > drivers/accel/qaic/mhi_qaic_ctrl.c:544:38: note:
> > > > > > > > > > > > > in expansion of macro 'THIS_MODULE'
> > > > > > > > > > > > > 544 | mqc_dev_class =
> > > > > > > > > > > > > class_create(THIS_MODULE,
> > > > > > > > > > > > > MHI_QAIC_CTRL_DRIVER_NAME);
> > > > > > > > > > > > > | ^~~~~~~~~~~
> > > > > > > > > > > > > In file included from include/linux/device.h:31,
> > > > > > > > > > > > > from include/linux/mhi.h:9,
> > > > > > > > > > > > > from drivers/accel/qaic/mhi_qaic_ctrl.c:5:
> > > > > > > > > > > > > include/linux/device/class.h:229:54: note:
> > > > > > > > > > > > > expected 'const char *' but argument is of type
> > > > > > > > > > > > > 'struct module *'
> > > > > > > > > > > > > 229 | struct class * __must_check
> > > > > > > > > > > > > class_create(const char *name);
> > > > > > > > > > > > > | ~~~~~~~~~~~~^~~~
> > > > > > > > > > > > > drivers/accel/qaic/mhi_qaic_ctrl.c:544:25:
> > > > > > > > > > > > > error: too many arguments to function
> > > > > > > > > > > > > 'class_create'
> > > > > > > > > > > > > 544 | mqc_dev_class =
> > > > > > > > > > > > > class_create(THIS_MODULE,
> > > > > > > > > > > > > MHI_QAIC_CTRL_DRIVER_NAME);
> > > > > > > > > > > > > | ^~~~~~~~~~~~
> > > > > > > > > > > > > include/linux/device/class.h:229:29: note: declared here
> > > > > > > > > > > > > 229 | struct class * __must_check
> > > > > > > > > > > > > class_create(const char *name);
> > > > > > > > > > > > > | ^~~~~~~~~~~~
> > > > > > > > > > > > >
> > > > > > > > > > > > > Caused by commit
> > > > > > > > > > > > >
> > > > > > > > > > > > > 1aaba11da9aa ("driver core: class: remove
> > > > > > > > > > > > > module * from class_create()")
> > > > > > > > > > > > >
> > > > > > > > > > > > > interacting with commit
> > > > > > > > > > > > >
> > > > > > > > > > > > > 566fc96198b4 ("accel/qaic: Add mhi_qaic_cntl")
> > > > > > > > > > > > >
> > > > > > > > > > > > > from the drm tree.
> > > > > > > > > > > > >
> > > > > > > > > > > > > I have applied the following merge fix patch for today.
> > > > > > > > > > > > >
> > > > > > > > > > > > > From: Stephen Rothwell <sfr@canb.auug.org.au>
> > > > > > > > > > > > > Date: Tue, 11 Apr 2023 14:16:57 +1000
> > > > > > > > > > > > > Subject: [PATCH] fixup for "driver core: class:
> > > > > > > > > > > > > remove module * from class_create()"
> > > > > > > > > > > > >
> > > > > > > > > > > > > interacting with "accel/qaic: Add mhi_qaic_cntl"
> > > > > > > > > > > > >
> > > > > > > > > > > > > Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> > > > > > > > > > > >
> > > > > > > > > > > > Thanks for the fixup. Since Dave is out I've made a
> > > > > > > > > > > > note about this in my
> > > > > > > > > > > > handover mail so it won't get lost in the drm-next
> > > > > > > > > > > > merge window pull. I
> > > > > > > > > > > > don't think we need any other coordination than
> > > > > > > > > > > > mention it in each pull to
> > > > > > > > > > > > Linus, topic tree seems overkill for this. Plus there's no way I can
> > > > > > > > > > > > untangle the drm tree anyway :-).
> > > > > > > > > > >
> > > > > > > > > > > Want me to submit a patch for the drm tree that moves this to use
> > > > > > > > > > > class_register() instead, which will make the
> > > > > > > > > > > merge/build issue go away
> > > > > > > > > > > for you? That's my long-term goal here anyway, so converting this new
> > > > > > > > > > > code to this api today would be something I have to do eventually :)
> > > > > > > > > >
> > > > > > > > > > We kinda closed drm-next for feature work mostly already (just pulling
> > > > > > > > > > stuff in from subtrees), so won't really help for this merge window.
> > > > > > > > > >
> > > > > > > > > > For everything else I think this is up to Oded, I had no
> > > > > > > > > > idea qaic needed
> > > > > > > > > > it's entire own dev class and I don't want to dig into this
> > > > > > > > > > for the risk I
> > > > > > > > > > might freak out :-)
> > > > > > > > > >
> > > > > > > > > > Adding Oded.
> > > > > > > > > >
> > > > > > > > > > Cheers, Daniel
> > > > > > > > >
> > > > > > > > > Sorry for the mess.
> > > > > > > > >
> > > > > > > > > I made a note to update to class_register() once my drm-misc access is
> > > > > > > > > sorted out. Looks like we'll address the conflict in the merge
> > > > > > > > > window, and
> > > > > > > > > catch the update to the new API in the following release.
> > > > > > > >
> > > > > > > > Wait, I think the large question is, "why does this need a separate
> > > > > > > > class"? Why are you not using the accel char device and class? That is
> > > > > > > > what everything under accel/ should be using, otherwise why put it in
> > > > > > > > there?
> > > > > > > >
> > > > > > > > And what exactly are you using that class for? Just device nodes? If
> > > > > > > > so, how many?
> > > > > > > >
> > > > > > > > thanks,
> > > > > > > >
> > > > > > > > greg k-h
> > > > > > >
> > > > > > >
> > > > > > > Remember MHI_UCI that then evolved into the WWAN subsystem? I pointed
> > > > > > > out at the time that AIC100/QAIC would need the same functionality.
> > > > > > > You/Jakub told myself/Mani/Loic that a combined implementation is not
> > > > > > > acceptable, and every area needs to implement their own version of
> > > > > > > MHI_UCI.
> > > > > > >
> > > > > > > We took the WWAN subsystem and simplified it to meet our needs.
> > > > > > >
> > > > > > > The functionality is QAIC specific, so wedging it into the Accel node
> > > > > > > seems to be a poor fit as it would subject Habana and iVPU to the same.
> > > > > >
> > > > > > Also, I forgot to mention. QAIC is sharing userspace components with WWAN,
> > > > > > so we really cannot diverge from what WWAN has done and define a new API
> > > > > > through the Accel node.
> > > > >
> > > > > So there is an accel/drm_device in the qaic driver, but there's also this
> > > > > different class thing, which I don't get.
> > > > >
> > > > > And yeah if that's an entirely orthogonal thing then I guess that should
> > > > > be in a different driver/subsystem, all supported with the aux bus to
> > > > > multiplex the underlying device.
> > > > >
> > > > > I haven't found any explanation for what MHI is (or any of the other
> > > > > acrynoms), so I'm entirely lost.
> > > >
> > > > MHI is documented at Documentation/mhi/
> > > > It is also referenced in the QAIC documentation - Documentation/accel/qaic/
> > > >
> > > > It stands for "Modem Host Interface" (arguably a bad name now, but you can
> > > > guess where it came from). It is a Qualcomm hardware block and associated
> > > > software protocol that provides logical channels over a hardware link. Most
> > > > commonly used for PCIe.
> > > >
> > > > Pretty much any modern Qualcomm PCIe device implements it. 4G modems, 5G
> > > > modems, Wifi adapters, AIC100, etc. Instead of talking "PCIe", the host
> > > > talks "MHI" to the devices in most cases.
> > > >
> > > > The core implementation for MHI exists in drivers/bus/mhi
> > > >
> > > > MHI_UCI is the MHI Userspace Character Interface. It looked like most buses
> > > > (eg USB) provide some direct device access to userspace. MHI_UCI was
> > > > formulated along those same lines - provide direct userspace access to a
> > > > whitelist of channels. Qualcomm provides some fairly extensive userspace
> > > > utilities, and various communities have developed open source alternatives
> > > > using this mechanism.
> > > >
> > > > MHI_UCI was proposed to the community as the common driver (misc device) for
> > > > all of the MHI devices. The Net folks came along, saw that it was used for
> > > > 4G/5G modems (Wireless Wide Area Network devices or WWAN) and decided that
> > > > they would not tolerate a common implementation. They NACK'd MHI_UCI and
> > > > required that a WWAN specific subsystem be developed which would only
> > > > service WWAN devices. The Net folks decreed that other subsystems which
> > > > needed the same functionality need to have their own copy of the
> > > > implementation.
> > > >
> > > > QAIC devices expose Sahara (a boot time protocol) which has an existing
> > > > userspace that is also used with Modems, although it looks like WWAN doesn't
> > > > currently support those generations of products today. QAIC devices also
> > > > support DIAG, which is currently supported in WWAN. The intent was to add
> > > > the QAIC support for DIAG at a later time since it is not required for the
> > > > bare minimum viable driver.
> > > >
> > > > So, QAIC devices support the same services, would use the same userspace,
> > > > but can't use a common implementation because Jakub(net) doesn't want to
> > > > share and convinced Greg to go along. I'm not interested in pushing a cross
> > > > tree fight (arguably already did that with MHI_UCI). If neither Greg nor
> > > > Net will accept a common implementation that accelerators can use (QAIC),
> > > > then the only place I can fit this is in the Accel area.
> > > >
> > > > Using aux bus seems to make little difference if QAIC is the only consumer
> > > > of this. I'm willing to refactor the implementation with some feedback and
> > > > guidence, but the uAPI seems set in stone due to the existing userspace and
> > > > WWAN (char devs with open/close/read/write/poll).
> > >
> > > Ok, so MHI _is_ the bus. Thanks for the explainer, I should have searched
> > > a bit more in Documentation/
> > >
> > > > What would make you less unhappy?
> > >
> > > The MHI generic userspace driver interface needs to be in drivers/bus/mhi,
> > > not in a random driver. I think we should revert 566fc96198b4
> > > ("accel/qaic: Add mhi_qaic_cntl") and re-land that through Greg's tree (or
> > > wherever mhi patches go to). This of course assuming that the accel
> > > userspace on top of the accel/drm_device does work stand-alone, and it's
> > > just the tooling and other userspace that needs MHI_UCI. If we end with a
> > > non-functional stack due to that, then I guess the entire driver is a bit
> > > up for questions, because at least the accel runtime is supposed to just
> > > run on top of the accel devnode and nothing else. Otherwise container
> > > stuff gets really bad, among a lot of other things.
> > >
> >
> > Looping in the MHI maintainer for your proposal.
> >
> > The accel userspace can work without MHI_UCI.
> >
> > The revert will be non-trivial so I'll look at posting that tomorrow.
>
> Yeah if the full revert is invasive then could we just do a minimal one
> that drops the various register_chrdev/class_create/device_create calls?
> That avoids the conflict plus makes sure no uabi is registers for the
> MHI_UCI. Anything else we can sort out later.
That sounds reasonable to me, thanks!
greg k-h
^ permalink raw reply [flat|nested] 181+ messages in thread
* Re: linux-next: build failure after merge of the driver-core tree
2023-04-11 18:37 ` Jeffrey Hugo
@ 2023-04-11 18:47 ` Daniel Vetter
2023-04-12 6:11 ` Greg KH
0 siblings, 1 reply; 181+ messages in thread
From: Daniel Vetter @ 2023-04-11 18:47 UTC (permalink / raw)
To: Jeffrey Hugo
Cc: Greg KH, Stephen Rothwell, Oded Gabbay,
Linux Kernel Mailing List, DRI, Pranjal Ramajor Asha Kanojiya,
Linux Next Mailing List, Jacek Lawrynowicz, Dave Airlie,
Manivannan Sadhasivam
On Tue, Apr 11, 2023 at 12:37:23PM -0600, Jeffrey Hugo wrote:
> On 4/11/2023 12:21 PM, Daniel Vetter wrote:
> > On Tue, Apr 11, 2023 at 11:18:29AM -0600, Jeffrey Hugo wrote:
> > > On 4/11/2023 10:31 AM, Daniel Vetter wrote:
> > > > On Tue, Apr 11, 2023 at 09:29:27AM -0600, Jeffrey Hugo wrote:
> > > > > On 4/11/2023 9:26 AM, Jeffrey Hugo wrote:
> > > > > > On 4/11/2023 9:13 AM, Greg KH wrote:
> > > > > > > On Tue, Apr 11, 2023 at 09:08:39AM -0600, Jeffrey Hugo wrote:
> > > > > > > > On 4/11/2023 9:01 AM, Daniel Vetter wrote:
> > > > > > > > > On Tue, Apr 11, 2023 at 12:40:28PM +0200, Greg KH wrote:
> > > > > > > > > > On Tue, Apr 11, 2023 at 11:55:20AM +0200, Daniel Vetter wrote:
> > > > > > > > > > > On Tue, Apr 11, 2023 at 02:38:12PM +1000, Stephen Rothwell wrote:
> > > > > > > > > > > > Hi all,
> > > > > > > > > > > >
> > > > > > > > > > > > After merging the driver-core tree, today's linux-next build (x86_64
> > > > > > > > > > > > allmodconfig) failed like this:
> > > > > > > > > > > >
> > > > > > > > > > > > In file included from include/linux/linkage.h:7,
> > > > > > > > > > > > from include/linux/kernel.h:17,
> > > > > > > > > > > > from drivers/accel/qaic/mhi_qaic_ctrl.c:4:
> > > > > > > > > > > > drivers/accel/qaic/mhi_qaic_ctrl.c: In function
> > > > > > > > > > > > 'mhi_qaic_ctrl_init':
> > > > > > > > > > > > include/linux/export.h:27:22: error: passing
> > > > > > > > > > > > argument 1 of 'class_create' from incompatible
> > > > > > > > > > > > pointer type
> > > > > > > > > > > > [-Werror=incompatible-pointer-types]
> > > > > > > > > > > > 27 | #define THIS_MODULE (&__this_module)
> > > > > > > > > > > > | ~^~~~~~~~~~~~~~~
> > > > > > > > > > > > | |
> > > > > > > > > > > > | struct module *
> > > > > > > > > > > > drivers/accel/qaic/mhi_qaic_ctrl.c:544:38: note:
> > > > > > > > > > > > in expansion of macro 'THIS_MODULE'
> > > > > > > > > > > > 544 | mqc_dev_class =
> > > > > > > > > > > > class_create(THIS_MODULE,
> > > > > > > > > > > > MHI_QAIC_CTRL_DRIVER_NAME);
> > > > > > > > > > > > | ^~~~~~~~~~~
> > > > > > > > > > > > In file included from include/linux/device.h:31,
> > > > > > > > > > > > from include/linux/mhi.h:9,
> > > > > > > > > > > > from drivers/accel/qaic/mhi_qaic_ctrl.c:5:
> > > > > > > > > > > > include/linux/device/class.h:229:54: note:
> > > > > > > > > > > > expected 'const char *' but argument is of type
> > > > > > > > > > > > 'struct module *'
> > > > > > > > > > > > 229 | struct class * __must_check
> > > > > > > > > > > > class_create(const char *name);
> > > > > > > > > > > > | ~~~~~~~~~~~~^~~~
> > > > > > > > > > > > drivers/accel/qaic/mhi_qaic_ctrl.c:544:25:
> > > > > > > > > > > > error: too many arguments to function
> > > > > > > > > > > > 'class_create'
> > > > > > > > > > > > 544 | mqc_dev_class =
> > > > > > > > > > > > class_create(THIS_MODULE,
> > > > > > > > > > > > MHI_QAIC_CTRL_DRIVER_NAME);
> > > > > > > > > > > > | ^~~~~~~~~~~~
> > > > > > > > > > > > include/linux/device/class.h:229:29: note: declared here
> > > > > > > > > > > > 229 | struct class * __must_check
> > > > > > > > > > > > class_create(const char *name);
> > > > > > > > > > > > | ^~~~~~~~~~~~
> > > > > > > > > > > >
> > > > > > > > > > > > Caused by commit
> > > > > > > > > > > >
> > > > > > > > > > > > 1aaba11da9aa ("driver core: class: remove
> > > > > > > > > > > > module * from class_create()")
> > > > > > > > > > > >
> > > > > > > > > > > > interacting with commit
> > > > > > > > > > > >
> > > > > > > > > > > > 566fc96198b4 ("accel/qaic: Add mhi_qaic_cntl")
> > > > > > > > > > > >
> > > > > > > > > > > > from the drm tree.
> > > > > > > > > > > >
> > > > > > > > > > > > I have applied the following merge fix patch for today.
> > > > > > > > > > > >
> > > > > > > > > > > > From: Stephen Rothwell <sfr@canb.auug.org.au>
> > > > > > > > > > > > Date: Tue, 11 Apr 2023 14:16:57 +1000
> > > > > > > > > > > > Subject: [PATCH] fixup for "driver core: class:
> > > > > > > > > > > > remove module * from class_create()"
> > > > > > > > > > > >
> > > > > > > > > > > > interacting with "accel/qaic: Add mhi_qaic_cntl"
> > > > > > > > > > > >
> > > > > > > > > > > > Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> > > > > > > > > > >
> > > > > > > > > > > Thanks for the fixup. Since Dave is out I've made a
> > > > > > > > > > > note about this in my
> > > > > > > > > > > handover mail so it won't get lost in the drm-next
> > > > > > > > > > > merge window pull. I
> > > > > > > > > > > don't think we need any other coordination than
> > > > > > > > > > > mention it in each pull to
> > > > > > > > > > > Linus, topic tree seems overkill for this. Plus there's no way I can
> > > > > > > > > > > untangle the drm tree anyway :-).
> > > > > > > > > >
> > > > > > > > > > Want me to submit a patch for the drm tree that moves this to use
> > > > > > > > > > class_register() instead, which will make the
> > > > > > > > > > merge/build issue go away
> > > > > > > > > > for you? That's my long-term goal here anyway, so converting this new
> > > > > > > > > > code to this api today would be something I have to do eventually :)
> > > > > > > > >
> > > > > > > > > We kinda closed drm-next for feature work mostly already (just pulling
> > > > > > > > > stuff in from subtrees), so won't really help for this merge window.
> > > > > > > > >
> > > > > > > > > For everything else I think this is up to Oded, I had no
> > > > > > > > > idea qaic needed
> > > > > > > > > it's entire own dev class and I don't want to dig into this
> > > > > > > > > for the risk I
> > > > > > > > > might freak out :-)
> > > > > > > > >
> > > > > > > > > Adding Oded.
> > > > > > > > >
> > > > > > > > > Cheers, Daniel
> > > > > > > >
> > > > > > > > Sorry for the mess.
> > > > > > > >
> > > > > > > > I made a note to update to class_register() once my drm-misc access is
> > > > > > > > sorted out. Looks like we'll address the conflict in the merge
> > > > > > > > window, and
> > > > > > > > catch the update to the new API in the following release.
> > > > > > >
> > > > > > > Wait, I think the large question is, "why does this need a separate
> > > > > > > class"? Why are you not using the accel char device and class? That is
> > > > > > > what everything under accel/ should be using, otherwise why put it in
> > > > > > > there?
> > > > > > >
> > > > > > > And what exactly are you using that class for? Just device nodes? If
> > > > > > > so, how many?
> > > > > > >
> > > > > > > thanks,
> > > > > > >
> > > > > > > greg k-h
> > > > > >
> > > > > >
> > > > > > Remember MHI_UCI that then evolved into the WWAN subsystem? I pointed
> > > > > > out at the time that AIC100/QAIC would need the same functionality.
> > > > > > You/Jakub told myself/Mani/Loic that a combined implementation is not
> > > > > > acceptable, and every area needs to implement their own version of
> > > > > > MHI_UCI.
> > > > > >
> > > > > > We took the WWAN subsystem and simplified it to meet our needs.
> > > > > >
> > > > > > The functionality is QAIC specific, so wedging it into the Accel node
> > > > > > seems to be a poor fit as it would subject Habana and iVPU to the same.
> > > > >
> > > > > Also, I forgot to mention. QAIC is sharing userspace components with WWAN,
> > > > > so we really cannot diverge from what WWAN has done and define a new API
> > > > > through the Accel node.
> > > >
> > > > So there is an accel/drm_device in the qaic driver, but there's also this
> > > > different class thing, which I don't get.
> > > >
> > > > And yeah if that's an entirely orthogonal thing then I guess that should
> > > > be in a different driver/subsystem, all supported with the aux bus to
> > > > multiplex the underlying device.
> > > >
> > > > I haven't found any explanation for what MHI is (or any of the other
> > > > acrynoms), so I'm entirely lost.
> > >
> > > MHI is documented at Documentation/mhi/
> > > It is also referenced in the QAIC documentation - Documentation/accel/qaic/
> > >
> > > It stands for "Modem Host Interface" (arguably a bad name now, but you can
> > > guess where it came from). It is a Qualcomm hardware block and associated
> > > software protocol that provides logical channels over a hardware link. Most
> > > commonly used for PCIe.
> > >
> > > Pretty much any modern Qualcomm PCIe device implements it. 4G modems, 5G
> > > modems, Wifi adapters, AIC100, etc. Instead of talking "PCIe", the host
> > > talks "MHI" to the devices in most cases.
> > >
> > > The core implementation for MHI exists in drivers/bus/mhi
> > >
> > > MHI_UCI is the MHI Userspace Character Interface. It looked like most buses
> > > (eg USB) provide some direct device access to userspace. MHI_UCI was
> > > formulated along those same lines - provide direct userspace access to a
> > > whitelist of channels. Qualcomm provides some fairly extensive userspace
> > > utilities, and various communities have developed open source alternatives
> > > using this mechanism.
> > >
> > > MHI_UCI was proposed to the community as the common driver (misc device) for
> > > all of the MHI devices. The Net folks came along, saw that it was used for
> > > 4G/5G modems (Wireless Wide Area Network devices or WWAN) and decided that
> > > they would not tolerate a common implementation. They NACK'd MHI_UCI and
> > > required that a WWAN specific subsystem be developed which would only
> > > service WWAN devices. The Net folks decreed that other subsystems which
> > > needed the same functionality need to have their own copy of the
> > > implementation.
> > >
> > > QAIC devices expose Sahara (a boot time protocol) which has an existing
> > > userspace that is also used with Modems, although it looks like WWAN doesn't
> > > currently support those generations of products today. QAIC devices also
> > > support DIAG, which is currently supported in WWAN. The intent was to add
> > > the QAIC support for DIAG at a later time since it is not required for the
> > > bare minimum viable driver.
> > >
> > > So, QAIC devices support the same services, would use the same userspace,
> > > but can't use a common implementation because Jakub(net) doesn't want to
> > > share and convinced Greg to go along. I'm not interested in pushing a cross
> > > tree fight (arguably already did that with MHI_UCI). If neither Greg nor
> > > Net will accept a common implementation that accelerators can use (QAIC),
> > > then the only place I can fit this is in the Accel area.
> > >
> > > Using aux bus seems to make little difference if QAIC is the only consumer
> > > of this. I'm willing to refactor the implementation with some feedback and
> > > guidence, but the uAPI seems set in stone due to the existing userspace and
> > > WWAN (char devs with open/close/read/write/poll).
> >
> > Ok, so MHI _is_ the bus. Thanks for the explainer, I should have searched
> > a bit more in Documentation/
> >
> > > What would make you less unhappy?
> >
> > The MHI generic userspace driver interface needs to be in drivers/bus/mhi,
> > not in a random driver. I think we should revert 566fc96198b4
> > ("accel/qaic: Add mhi_qaic_cntl") and re-land that through Greg's tree (or
> > wherever mhi patches go to). This of course assuming that the accel
> > userspace on top of the accel/drm_device does work stand-alone, and it's
> > just the tooling and other userspace that needs MHI_UCI. If we end with a
> > non-functional stack due to that, then I guess the entire driver is a bit
> > up for questions, because at least the accel runtime is supposed to just
> > run on top of the accel devnode and nothing else. Otherwise container
> > stuff gets really bad, among a lot of other things.
> >
>
> Looping in the MHI maintainer for your proposal.
>
> The accel userspace can work without MHI_UCI.
>
> The revert will be non-trivial so I'll look at posting that tomorrow.
Yeah if the full revert is invasive then could we just do a minimal one
that drops the various register_chrdev/class_create/device_create calls?
That avoids the conflict plus makes sure no uabi is registers for the
MHI_UCI. Anything else we can sort out later.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
^ permalink raw reply [flat|nested] 181+ messages in thread
* Re: linux-next: build failure after merge of the driver-core tree
2023-04-11 18:21 ` Daniel Vetter
@ 2023-04-11 18:37 ` Jeffrey Hugo
2023-04-11 18:47 ` Daniel Vetter
0 siblings, 1 reply; 181+ messages in thread
From: Jeffrey Hugo @ 2023-04-11 18:37 UTC (permalink / raw)
To: Greg KH, Stephen Rothwell, Oded Gabbay,
Linux Kernel Mailing List, DRI, Pranjal Ramajor Asha Kanojiya,
Linux Next Mailing List, Jacek Lawrynowicz, Dave Airlie,
Manivannan Sadhasivam
On 4/11/2023 12:21 PM, Daniel Vetter wrote:
> On Tue, Apr 11, 2023 at 11:18:29AM -0600, Jeffrey Hugo wrote:
>> On 4/11/2023 10:31 AM, Daniel Vetter wrote:
>>> On Tue, Apr 11, 2023 at 09:29:27AM -0600, Jeffrey Hugo wrote:
>>>> On 4/11/2023 9:26 AM, Jeffrey Hugo wrote:
>>>>> On 4/11/2023 9:13 AM, Greg KH wrote:
>>>>>> On Tue, Apr 11, 2023 at 09:08:39AM -0600, Jeffrey Hugo wrote:
>>>>>>> On 4/11/2023 9:01 AM, Daniel Vetter wrote:
>>>>>>>> On Tue, Apr 11, 2023 at 12:40:28PM +0200, Greg KH wrote:
>>>>>>>>> On Tue, Apr 11, 2023 at 11:55:20AM +0200, Daniel Vetter wrote:
>>>>>>>>>> On Tue, Apr 11, 2023 at 02:38:12PM +1000, Stephen Rothwell wrote:
>>>>>>>>>>> Hi all,
>>>>>>>>>>>
>>>>>>>>>>> After merging the driver-core tree, today's linux-next build (x86_64
>>>>>>>>>>> allmodconfig) failed like this:
>>>>>>>>>>>
>>>>>>>>>>> In file included from include/linux/linkage.h:7,
>>>>>>>>>>> from include/linux/kernel.h:17,
>>>>>>>>>>> from drivers/accel/qaic/mhi_qaic_ctrl.c:4:
>>>>>>>>>>> drivers/accel/qaic/mhi_qaic_ctrl.c: In function
>>>>>>>>>>> 'mhi_qaic_ctrl_init':
>>>>>>>>>>> include/linux/export.h:27:22: error: passing
>>>>>>>>>>> argument 1 of 'class_create' from incompatible
>>>>>>>>>>> pointer type
>>>>>>>>>>> [-Werror=incompatible-pointer-types]
>>>>>>>>>>> 27 | #define THIS_MODULE (&__this_module)
>>>>>>>>>>> | ~^~~~~~~~~~~~~~~
>>>>>>>>>>> | |
>>>>>>>>>>> | struct module *
>>>>>>>>>>> drivers/accel/qaic/mhi_qaic_ctrl.c:544:38: note:
>>>>>>>>>>> in expansion of macro 'THIS_MODULE'
>>>>>>>>>>> 544 | mqc_dev_class =
>>>>>>>>>>> class_create(THIS_MODULE,
>>>>>>>>>>> MHI_QAIC_CTRL_DRIVER_NAME);
>>>>>>>>>>> | ^~~~~~~~~~~
>>>>>>>>>>> In file included from include/linux/device.h:31,
>>>>>>>>>>> from include/linux/mhi.h:9,
>>>>>>>>>>> from drivers/accel/qaic/mhi_qaic_ctrl.c:5:
>>>>>>>>>>> include/linux/device/class.h:229:54: note:
>>>>>>>>>>> expected 'const char *' but argument is of type
>>>>>>>>>>> 'struct module *'
>>>>>>>>>>> 229 | struct class * __must_check
>>>>>>>>>>> class_create(const char *name);
>>>>>>>>>>> | ~~~~~~~~~~~~^~~~
>>>>>>>>>>> drivers/accel/qaic/mhi_qaic_ctrl.c:544:25:
>>>>>>>>>>> error: too many arguments to function
>>>>>>>>>>> 'class_create'
>>>>>>>>>>> 544 | mqc_dev_class =
>>>>>>>>>>> class_create(THIS_MODULE,
>>>>>>>>>>> MHI_QAIC_CTRL_DRIVER_NAME);
>>>>>>>>>>> | ^~~~~~~~~~~~
>>>>>>>>>>> include/linux/device/class.h:229:29: note: declared here
>>>>>>>>>>> 229 | struct class * __must_check
>>>>>>>>>>> class_create(const char *name);
>>>>>>>>>>> | ^~~~~~~~~~~~
>>>>>>>>>>>
>>>>>>>>>>> Caused by commit
>>>>>>>>>>>
>>>>>>>>>>> 1aaba11da9aa ("driver core: class: remove
>>>>>>>>>>> module * from class_create()")
>>>>>>>>>>>
>>>>>>>>>>> interacting with commit
>>>>>>>>>>>
>>>>>>>>>>> 566fc96198b4 ("accel/qaic: Add mhi_qaic_cntl")
>>>>>>>>>>>
>>>>>>>>>>> from the drm tree.
>>>>>>>>>>>
>>>>>>>>>>> I have applied the following merge fix patch for today.
>>>>>>>>>>>
>>>>>>>>>>> From: Stephen Rothwell <sfr@canb.auug.org.au>
>>>>>>>>>>> Date: Tue, 11 Apr 2023 14:16:57 +1000
>>>>>>>>>>> Subject: [PATCH] fixup for "driver core: class:
>>>>>>>>>>> remove module * from class_create()"
>>>>>>>>>>>
>>>>>>>>>>> interacting with "accel/qaic: Add mhi_qaic_cntl"
>>>>>>>>>>>
>>>>>>>>>>> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
>>>>>>>>>>
>>>>>>>>>> Thanks for the fixup. Since Dave is out I've made a
>>>>>>>>>> note about this in my
>>>>>>>>>> handover mail so it won't get lost in the drm-next
>>>>>>>>>> merge window pull. I
>>>>>>>>>> don't think we need any other coordination than
>>>>>>>>>> mention it in each pull to
>>>>>>>>>> Linus, topic tree seems overkill for this. Plus there's no way I can
>>>>>>>>>> untangle the drm tree anyway :-).
>>>>>>>>>
>>>>>>>>> Want me to submit a patch for the drm tree that moves this to use
>>>>>>>>> class_register() instead, which will make the
>>>>>>>>> merge/build issue go away
>>>>>>>>> for you? That's my long-term goal here anyway, so converting this new
>>>>>>>>> code to this api today would be something I have to do eventually :)
>>>>>>>>
>>>>>>>> We kinda closed drm-next for feature work mostly already (just pulling
>>>>>>>> stuff in from subtrees), so won't really help for this merge window.
>>>>>>>>
>>>>>>>> For everything else I think this is up to Oded, I had no
>>>>>>>> idea qaic needed
>>>>>>>> it's entire own dev class and I don't want to dig into this
>>>>>>>> for the risk I
>>>>>>>> might freak out :-)
>>>>>>>>
>>>>>>>> Adding Oded.
>>>>>>>>
>>>>>>>> Cheers, Daniel
>>>>>>>
>>>>>>> Sorry for the mess.
>>>>>>>
>>>>>>> I made a note to update to class_register() once my drm-misc access is
>>>>>>> sorted out. Looks like we'll address the conflict in the merge
>>>>>>> window, and
>>>>>>> catch the update to the new API in the following release.
>>>>>>
>>>>>> Wait, I think the large question is, "why does this need a separate
>>>>>> class"? Why are you not using the accel char device and class? That is
>>>>>> what everything under accel/ should be using, otherwise why put it in
>>>>>> there?
>>>>>>
>>>>>> And what exactly are you using that class for? Just device nodes? If
>>>>>> so, how many?
>>>>>>
>>>>>> thanks,
>>>>>>
>>>>>> greg k-h
>>>>>
>>>>>
>>>>> Remember MHI_UCI that then evolved into the WWAN subsystem? I pointed
>>>>> out at the time that AIC100/QAIC would need the same functionality.
>>>>> You/Jakub told myself/Mani/Loic that a combined implementation is not
>>>>> acceptable, and every area needs to implement their own version of
>>>>> MHI_UCI.
>>>>>
>>>>> We took the WWAN subsystem and simplified it to meet our needs.
>>>>>
>>>>> The functionality is QAIC specific, so wedging it into the Accel node
>>>>> seems to be a poor fit as it would subject Habana and iVPU to the same.
>>>>
>>>> Also, I forgot to mention. QAIC is sharing userspace components with WWAN,
>>>> so we really cannot diverge from what WWAN has done and define a new API
>>>> through the Accel node.
>>>
>>> So there is an accel/drm_device in the qaic driver, but there's also this
>>> different class thing, which I don't get.
>>>
>>> And yeah if that's an entirely orthogonal thing then I guess that should
>>> be in a different driver/subsystem, all supported with the aux bus to
>>> multiplex the underlying device.
>>>
>>> I haven't found any explanation for what MHI is (or any of the other
>>> acrynoms), so I'm entirely lost.
>>
>> MHI is documented at Documentation/mhi/
>> It is also referenced in the QAIC documentation - Documentation/accel/qaic/
>>
>> It stands for "Modem Host Interface" (arguably a bad name now, but you can
>> guess where it came from). It is a Qualcomm hardware block and associated
>> software protocol that provides logical channels over a hardware link. Most
>> commonly used for PCIe.
>>
>> Pretty much any modern Qualcomm PCIe device implements it. 4G modems, 5G
>> modems, Wifi adapters, AIC100, etc. Instead of talking "PCIe", the host
>> talks "MHI" to the devices in most cases.
>>
>> The core implementation for MHI exists in drivers/bus/mhi
>>
>> MHI_UCI is the MHI Userspace Character Interface. It looked like most buses
>> (eg USB) provide some direct device access to userspace. MHI_UCI was
>> formulated along those same lines - provide direct userspace access to a
>> whitelist of channels. Qualcomm provides some fairly extensive userspace
>> utilities, and various communities have developed open source alternatives
>> using this mechanism.
>>
>> MHI_UCI was proposed to the community as the common driver (misc device) for
>> all of the MHI devices. The Net folks came along, saw that it was used for
>> 4G/5G modems (Wireless Wide Area Network devices or WWAN) and decided that
>> they would not tolerate a common implementation. They NACK'd MHI_UCI and
>> required that a WWAN specific subsystem be developed which would only
>> service WWAN devices. The Net folks decreed that other subsystems which
>> needed the same functionality need to have their own copy of the
>> implementation.
>>
>> QAIC devices expose Sahara (a boot time protocol) which has an existing
>> userspace that is also used with Modems, although it looks like WWAN doesn't
>> currently support those generations of products today. QAIC devices also
>> support DIAG, which is currently supported in WWAN. The intent was to add
>> the QAIC support for DIAG at a later time since it is not required for the
>> bare minimum viable driver.
>>
>> So, QAIC devices support the same services, would use the same userspace,
>> but can't use a common implementation because Jakub(net) doesn't want to
>> share and convinced Greg to go along. I'm not interested in pushing a cross
>> tree fight (arguably already did that with MHI_UCI). If neither Greg nor
>> Net will accept a common implementation that accelerators can use (QAIC),
>> then the only place I can fit this is in the Accel area.
>>
>> Using aux bus seems to make little difference if QAIC is the only consumer
>> of this. I'm willing to refactor the implementation with some feedback and
>> guidence, but the uAPI seems set in stone due to the existing userspace and
>> WWAN (char devs with open/close/read/write/poll).
>
> Ok, so MHI _is_ the bus. Thanks for the explainer, I should have searched
> a bit more in Documentation/
>
>> What would make you less unhappy?
>
> The MHI generic userspace driver interface needs to be in drivers/bus/mhi,
> not in a random driver. I think we should revert 566fc96198b4
> ("accel/qaic: Add mhi_qaic_cntl") and re-land that through Greg's tree (or
> wherever mhi patches go to). This of course assuming that the accel
> userspace on top of the accel/drm_device does work stand-alone, and it's
> just the tooling and other userspace that needs MHI_UCI. If we end with a
> non-functional stack due to that, then I guess the entire driver is a bit
> up for questions, because at least the accel runtime is supposed to just
> run on top of the accel devnode and nothing else. Otherwise container
> stuff gets really bad, among a lot of other things.
>
Looping in the MHI maintainer for your proposal.
The accel userspace can work without MHI_UCI.
The revert will be non-trivial so I'll look at posting that tomorrow.
-Jeff
^ permalink raw reply [flat|nested] 181+ messages in thread
* Re: linux-next: build failure after merge of the driver-core tree
2023-04-11 17:18 ` Jeffrey Hugo
@ 2023-04-11 18:21 ` Daniel Vetter
2023-04-11 18:37 ` Jeffrey Hugo
0 siblings, 1 reply; 181+ messages in thread
From: Daniel Vetter @ 2023-04-11 18:21 UTC (permalink / raw)
To: Jeffrey Hugo
Cc: Greg KH, Stephen Rothwell, Oded Gabbay,
Linux Kernel Mailing List, DRI, Pranjal Ramajor Asha Kanojiya,
Linux Next Mailing List, Jacek Lawrynowicz, Dave Airlie
On Tue, Apr 11, 2023 at 11:18:29AM -0600, Jeffrey Hugo wrote:
> On 4/11/2023 10:31 AM, Daniel Vetter wrote:
> > On Tue, Apr 11, 2023 at 09:29:27AM -0600, Jeffrey Hugo wrote:
> > > On 4/11/2023 9:26 AM, Jeffrey Hugo wrote:
> > > > On 4/11/2023 9:13 AM, Greg KH wrote:
> > > > > On Tue, Apr 11, 2023 at 09:08:39AM -0600, Jeffrey Hugo wrote:
> > > > > > On 4/11/2023 9:01 AM, Daniel Vetter wrote:
> > > > > > > On Tue, Apr 11, 2023 at 12:40:28PM +0200, Greg KH wrote:
> > > > > > > > On Tue, Apr 11, 2023 at 11:55:20AM +0200, Daniel Vetter wrote:
> > > > > > > > > On Tue, Apr 11, 2023 at 02:38:12PM +1000, Stephen Rothwell wrote:
> > > > > > > > > > Hi all,
> > > > > > > > > >
> > > > > > > > > > After merging the driver-core tree, today's linux-next build (x86_64
> > > > > > > > > > allmodconfig) failed like this:
> > > > > > > > > >
> > > > > > > > > > In file included from include/linux/linkage.h:7,
> > > > > > > > > > from include/linux/kernel.h:17,
> > > > > > > > > > from drivers/accel/qaic/mhi_qaic_ctrl.c:4:
> > > > > > > > > > drivers/accel/qaic/mhi_qaic_ctrl.c: In function
> > > > > > > > > > 'mhi_qaic_ctrl_init':
> > > > > > > > > > include/linux/export.h:27:22: error: passing
> > > > > > > > > > argument 1 of 'class_create' from incompatible
> > > > > > > > > > pointer type
> > > > > > > > > > [-Werror=incompatible-pointer-types]
> > > > > > > > > > 27 | #define THIS_MODULE (&__this_module)
> > > > > > > > > > | ~^~~~~~~~~~~~~~~
> > > > > > > > > > | |
> > > > > > > > > > | struct module *
> > > > > > > > > > drivers/accel/qaic/mhi_qaic_ctrl.c:544:38: note:
> > > > > > > > > > in expansion of macro 'THIS_MODULE'
> > > > > > > > > > 544 | mqc_dev_class =
> > > > > > > > > > class_create(THIS_MODULE,
> > > > > > > > > > MHI_QAIC_CTRL_DRIVER_NAME);
> > > > > > > > > > | ^~~~~~~~~~~
> > > > > > > > > > In file included from include/linux/device.h:31,
> > > > > > > > > > from include/linux/mhi.h:9,
> > > > > > > > > > from drivers/accel/qaic/mhi_qaic_ctrl.c:5:
> > > > > > > > > > include/linux/device/class.h:229:54: note:
> > > > > > > > > > expected 'const char *' but argument is of type
> > > > > > > > > > 'struct module *'
> > > > > > > > > > 229 | struct class * __must_check
> > > > > > > > > > class_create(const char *name);
> > > > > > > > > > | ~~~~~~~~~~~~^~~~
> > > > > > > > > > drivers/accel/qaic/mhi_qaic_ctrl.c:544:25:
> > > > > > > > > > error: too many arguments to function
> > > > > > > > > > 'class_create'
> > > > > > > > > > 544 | mqc_dev_class =
> > > > > > > > > > class_create(THIS_MODULE,
> > > > > > > > > > MHI_QAIC_CTRL_DRIVER_NAME);
> > > > > > > > > > | ^~~~~~~~~~~~
> > > > > > > > > > include/linux/device/class.h:229:29: note: declared here
> > > > > > > > > > 229 | struct class * __must_check
> > > > > > > > > > class_create(const char *name);
> > > > > > > > > > | ^~~~~~~~~~~~
> > > > > > > > > >
> > > > > > > > > > Caused by commit
> > > > > > > > > >
> > > > > > > > > > 1aaba11da9aa ("driver core: class: remove
> > > > > > > > > > module * from class_create()")
> > > > > > > > > >
> > > > > > > > > > interacting with commit
> > > > > > > > > >
> > > > > > > > > > 566fc96198b4 ("accel/qaic: Add mhi_qaic_cntl")
> > > > > > > > > >
> > > > > > > > > > from the drm tree.
> > > > > > > > > >
> > > > > > > > > > I have applied the following merge fix patch for today.
> > > > > > > > > >
> > > > > > > > > > From: Stephen Rothwell <sfr@canb.auug.org.au>
> > > > > > > > > > Date: Tue, 11 Apr 2023 14:16:57 +1000
> > > > > > > > > > Subject: [PATCH] fixup for "driver core: class:
> > > > > > > > > > remove module * from class_create()"
> > > > > > > > > >
> > > > > > > > > > interacting with "accel/qaic: Add mhi_qaic_cntl"
> > > > > > > > > >
> > > > > > > > > > Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> > > > > > > > >
> > > > > > > > > Thanks for the fixup. Since Dave is out I've made a
> > > > > > > > > note about this in my
> > > > > > > > > handover mail so it won't get lost in the drm-next
> > > > > > > > > merge window pull. I
> > > > > > > > > don't think we need any other coordination than
> > > > > > > > > mention it in each pull to
> > > > > > > > > Linus, topic tree seems overkill for this. Plus there's no way I can
> > > > > > > > > untangle the drm tree anyway :-).
> > > > > > > >
> > > > > > > > Want me to submit a patch for the drm tree that moves this to use
> > > > > > > > class_register() instead, which will make the
> > > > > > > > merge/build issue go away
> > > > > > > > for you? That's my long-term goal here anyway, so converting this new
> > > > > > > > code to this api today would be something I have to do eventually :)
> > > > > > >
> > > > > > > We kinda closed drm-next for feature work mostly already (just pulling
> > > > > > > stuff in from subtrees), so won't really help for this merge window.
> > > > > > >
> > > > > > > For everything else I think this is up to Oded, I had no
> > > > > > > idea qaic needed
> > > > > > > it's entire own dev class and I don't want to dig into this
> > > > > > > for the risk I
> > > > > > > might freak out :-)
> > > > > > >
> > > > > > > Adding Oded.
> > > > > > >
> > > > > > > Cheers, Daniel
> > > > > >
> > > > > > Sorry for the mess.
> > > > > >
> > > > > > I made a note to update to class_register() once my drm-misc access is
> > > > > > sorted out. Looks like we'll address the conflict in the merge
> > > > > > window, and
> > > > > > catch the update to the new API in the following release.
> > > > >
> > > > > Wait, I think the large question is, "why does this need a separate
> > > > > class"? Why are you not using the accel char device and class? That is
> > > > > what everything under accel/ should be using, otherwise why put it in
> > > > > there?
> > > > >
> > > > > And what exactly are you using that class for? Just device nodes? If
> > > > > so, how many?
> > > > >
> > > > > thanks,
> > > > >
> > > > > greg k-h
> > > >
> > > >
> > > > Remember MHI_UCI that then evolved into the WWAN subsystem? I pointed
> > > > out at the time that AIC100/QAIC would need the same functionality.
> > > > You/Jakub told myself/Mani/Loic that a combined implementation is not
> > > > acceptable, and every area needs to implement their own version of
> > > > MHI_UCI.
> > > >
> > > > We took the WWAN subsystem and simplified it to meet our needs.
> > > >
> > > > The functionality is QAIC specific, so wedging it into the Accel node
> > > > seems to be a poor fit as it would subject Habana and iVPU to the same.
> > >
> > > Also, I forgot to mention. QAIC is sharing userspace components with WWAN,
> > > so we really cannot diverge from what WWAN has done and define a new API
> > > through the Accel node.
> >
> > So there is an accel/drm_device in the qaic driver, but there's also this
> > different class thing, which I don't get.
> >
> > And yeah if that's an entirely orthogonal thing then I guess that should
> > be in a different driver/subsystem, all supported with the aux bus to
> > multiplex the underlying device.
> >
> > I haven't found any explanation for what MHI is (or any of the other
> > acrynoms), so I'm entirely lost.
>
> MHI is documented at Documentation/mhi/
> It is also referenced in the QAIC documentation - Documentation/accel/qaic/
>
> It stands for "Modem Host Interface" (arguably a bad name now, but you can
> guess where it came from). It is a Qualcomm hardware block and associated
> software protocol that provides logical channels over a hardware link. Most
> commonly used for PCIe.
>
> Pretty much any modern Qualcomm PCIe device implements it. 4G modems, 5G
> modems, Wifi adapters, AIC100, etc. Instead of talking "PCIe", the host
> talks "MHI" to the devices in most cases.
>
> The core implementation for MHI exists in drivers/bus/mhi
>
> MHI_UCI is the MHI Userspace Character Interface. It looked like most buses
> (eg USB) provide some direct device access to userspace. MHI_UCI was
> formulated along those same lines - provide direct userspace access to a
> whitelist of channels. Qualcomm provides some fairly extensive userspace
> utilities, and various communities have developed open source alternatives
> using this mechanism.
>
> MHI_UCI was proposed to the community as the common driver (misc device) for
> all of the MHI devices. The Net folks came along, saw that it was used for
> 4G/5G modems (Wireless Wide Area Network devices or WWAN) and decided that
> they would not tolerate a common implementation. They NACK'd MHI_UCI and
> required that a WWAN specific subsystem be developed which would only
> service WWAN devices. The Net folks decreed that other subsystems which
> needed the same functionality need to have their own copy of the
> implementation.
>
> QAIC devices expose Sahara (a boot time protocol) which has an existing
> userspace that is also used with Modems, although it looks like WWAN doesn't
> currently support those generations of products today. QAIC devices also
> support DIAG, which is currently supported in WWAN. The intent was to add
> the QAIC support for DIAG at a later time since it is not required for the
> bare minimum viable driver.
>
> So, QAIC devices support the same services, would use the same userspace,
> but can't use a common implementation because Jakub(net) doesn't want to
> share and convinced Greg to go along. I'm not interested in pushing a cross
> tree fight (arguably already did that with MHI_UCI). If neither Greg nor
> Net will accept a common implementation that accelerators can use (QAIC),
> then the only place I can fit this is in the Accel area.
>
> Using aux bus seems to make little difference if QAIC is the only consumer
> of this. I'm willing to refactor the implementation with some feedback and
> guidence, but the uAPI seems set in stone due to the existing userspace and
> WWAN (char devs with open/close/read/write/poll).
Ok, so MHI _is_ the bus. Thanks for the explainer, I should have searched
a bit more in Documentation/
> What would make you less unhappy?
The MHI generic userspace driver interface needs to be in drivers/bus/mhi,
not in a random driver. I think we should revert 566fc96198b4
("accel/qaic: Add mhi_qaic_cntl") and re-land that through Greg's tree (or
wherever mhi patches go to). This of course assuming that the accel
userspace on top of the accel/drm_device does work stand-alone, and it's
just the tooling and other userspace that needs MHI_UCI. If we end with a
non-functional stack due to that, then I guess the entire driver is a bit
up for questions, because at least the accel runtime is supposed to just
run on top of the accel devnode and nothing else. Otherwise container
stuff gets really bad, among a lot of other things.
Cheers, Daniel
>
> > -Daniel
> >
> > >
> > > >
> > > > We need (eventually) 128 device nodes. We have systems with 32 QAIC
> > > > devices, and each QAIC device uses 4 device nodes (32 * 4 = 128). WWAN
> > > > subsystem would be similar. Looks like each 5G modem is 6 nodes per
> > > > device, so if you had 22 5G modems on a system, you'd have 132 device
> > > > nodes. I'm not aware of any such system, but it could exist.
> > > >
> > > > -Jeff
> > >
> >
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
^ permalink raw reply [flat|nested] 181+ messages in thread
* Re: linux-next: build failure after merge of the driver-core tree
2023-04-11 16:31 ` Daniel Vetter
@ 2023-04-11 17:18 ` Jeffrey Hugo
2023-04-11 18:21 ` Daniel Vetter
0 siblings, 1 reply; 181+ messages in thread
From: Jeffrey Hugo @ 2023-04-11 17:18 UTC (permalink / raw)
To: Greg KH, Stephen Rothwell, Oded Gabbay,
Linux Kernel Mailing List, DRI, Pranjal Ramajor Asha Kanojiya,
Linux Next Mailing List, Jacek Lawrynowicz, Dave Airlie
On 4/11/2023 10:31 AM, Daniel Vetter wrote:
> On Tue, Apr 11, 2023 at 09:29:27AM -0600, Jeffrey Hugo wrote:
>> On 4/11/2023 9:26 AM, Jeffrey Hugo wrote:
>>> On 4/11/2023 9:13 AM, Greg KH wrote:
>>>> On Tue, Apr 11, 2023 at 09:08:39AM -0600, Jeffrey Hugo wrote:
>>>>> On 4/11/2023 9:01 AM, Daniel Vetter wrote:
>>>>>> On Tue, Apr 11, 2023 at 12:40:28PM +0200, Greg KH wrote:
>>>>>>> On Tue, Apr 11, 2023 at 11:55:20AM +0200, Daniel Vetter wrote:
>>>>>>>> On Tue, Apr 11, 2023 at 02:38:12PM +1000, Stephen Rothwell wrote:
>>>>>>>>> Hi all,
>>>>>>>>>
>>>>>>>>> After merging the driver-core tree, today's linux-next build (x86_64
>>>>>>>>> allmodconfig) failed like this:
>>>>>>>>>
>>>>>>>>> In file included from include/linux/linkage.h:7,
>>>>>>>>> from include/linux/kernel.h:17,
>>>>>>>>> from drivers/accel/qaic/mhi_qaic_ctrl.c:4:
>>>>>>>>> drivers/accel/qaic/mhi_qaic_ctrl.c: In function
>>>>>>>>> 'mhi_qaic_ctrl_init':
>>>>>>>>> include/linux/export.h:27:22: error: passing
>>>>>>>>> argument 1 of 'class_create' from incompatible
>>>>>>>>> pointer type
>>>>>>>>> [-Werror=incompatible-pointer-types]
>>>>>>>>> 27 | #define THIS_MODULE (&__this_module)
>>>>>>>>> | ~^~~~~~~~~~~~~~~
>>>>>>>>> | |
>>>>>>>>> | struct module *
>>>>>>>>> drivers/accel/qaic/mhi_qaic_ctrl.c:544:38: note:
>>>>>>>>> in expansion of macro 'THIS_MODULE'
>>>>>>>>> 544 | mqc_dev_class =
>>>>>>>>> class_create(THIS_MODULE,
>>>>>>>>> MHI_QAIC_CTRL_DRIVER_NAME);
>>>>>>>>> | ^~~~~~~~~~~
>>>>>>>>> In file included from include/linux/device.h:31,
>>>>>>>>> from include/linux/mhi.h:9,
>>>>>>>>> from drivers/accel/qaic/mhi_qaic_ctrl.c:5:
>>>>>>>>> include/linux/device/class.h:229:54: note:
>>>>>>>>> expected 'const char *' but argument is of type
>>>>>>>>> 'struct module *'
>>>>>>>>> 229 | struct class * __must_check
>>>>>>>>> class_create(const char *name);
>>>>>>>>> | ~~~~~~~~~~~~^~~~
>>>>>>>>> drivers/accel/qaic/mhi_qaic_ctrl.c:544:25:
>>>>>>>>> error: too many arguments to function
>>>>>>>>> 'class_create'
>>>>>>>>> 544 | mqc_dev_class =
>>>>>>>>> class_create(THIS_MODULE,
>>>>>>>>> MHI_QAIC_CTRL_DRIVER_NAME);
>>>>>>>>> | ^~~~~~~~~~~~
>>>>>>>>> include/linux/device/class.h:229:29: note: declared here
>>>>>>>>> 229 | struct class * __must_check
>>>>>>>>> class_create(const char *name);
>>>>>>>>> | ^~~~~~~~~~~~
>>>>>>>>>
>>>>>>>>> Caused by commit
>>>>>>>>>
>>>>>>>>> 1aaba11da9aa ("driver core: class: remove
>>>>>>>>> module * from class_create()")
>>>>>>>>>
>>>>>>>>> interacting with commit
>>>>>>>>>
>>>>>>>>> 566fc96198b4 ("accel/qaic: Add mhi_qaic_cntl")
>>>>>>>>>
>>>>>>>>> from the drm tree.
>>>>>>>>>
>>>>>>>>> I have applied the following merge fix patch for today.
>>>>>>>>>
>>>>>>>>> From: Stephen Rothwell <sfr@canb.auug.org.au>
>>>>>>>>> Date: Tue, 11 Apr 2023 14:16:57 +1000
>>>>>>>>> Subject: [PATCH] fixup for "driver core: class:
>>>>>>>>> remove module * from class_create()"
>>>>>>>>>
>>>>>>>>> interacting with "accel/qaic: Add mhi_qaic_cntl"
>>>>>>>>>
>>>>>>>>> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
>>>>>>>>
>>>>>>>> Thanks for the fixup. Since Dave is out I've made a
>>>>>>>> note about this in my
>>>>>>>> handover mail so it won't get lost in the drm-next
>>>>>>>> merge window pull. I
>>>>>>>> don't think we need any other coordination than
>>>>>>>> mention it in each pull to
>>>>>>>> Linus, topic tree seems overkill for this. Plus there's no way I can
>>>>>>>> untangle the drm tree anyway :-).
>>>>>>>
>>>>>>> Want me to submit a patch for the drm tree that moves this to use
>>>>>>> class_register() instead, which will make the
>>>>>>> merge/build issue go away
>>>>>>> for you? That's my long-term goal here anyway, so converting this new
>>>>>>> code to this api today would be something I have to do eventually :)
>>>>>>
>>>>>> We kinda closed drm-next for feature work mostly already (just pulling
>>>>>> stuff in from subtrees), so won't really help for this merge window.
>>>>>>
>>>>>> For everything else I think this is up to Oded, I had no
>>>>>> idea qaic needed
>>>>>> it's entire own dev class and I don't want to dig into this
>>>>>> for the risk I
>>>>>> might freak out :-)
>>>>>>
>>>>>> Adding Oded.
>>>>>>
>>>>>> Cheers, Daniel
>>>>>
>>>>> Sorry for the mess.
>>>>>
>>>>> I made a note to update to class_register() once my drm-misc access is
>>>>> sorted out. Looks like we'll address the conflict in the merge
>>>>> window, and
>>>>> catch the update to the new API in the following release.
>>>>
>>>> Wait, I think the large question is, "why does this need a separate
>>>> class"? Why are you not using the accel char device and class? That is
>>>> what everything under accel/ should be using, otherwise why put it in
>>>> there?
>>>>
>>>> And what exactly are you using that class for? Just device nodes? If
>>>> so, how many?
>>>>
>>>> thanks,
>>>>
>>>> greg k-h
>>>
>>>
>>> Remember MHI_UCI that then evolved into the WWAN subsystem? I pointed
>>> out at the time that AIC100/QAIC would need the same functionality.
>>> You/Jakub told myself/Mani/Loic that a combined implementation is not
>>> acceptable, and every area needs to implement their own version of
>>> MHI_UCI.
>>>
>>> We took the WWAN subsystem and simplified it to meet our needs.
>>>
>>> The functionality is QAIC specific, so wedging it into the Accel node
>>> seems to be a poor fit as it would subject Habana and iVPU to the same.
>>
>> Also, I forgot to mention. QAIC is sharing userspace components with WWAN,
>> so we really cannot diverge from what WWAN has done and define a new API
>> through the Accel node.
>
> So there is an accel/drm_device in the qaic driver, but there's also this
> different class thing, which I don't get.
>
> And yeah if that's an entirely orthogonal thing then I guess that should
> be in a different driver/subsystem, all supported with the aux bus to
> multiplex the underlying device.
>
> I haven't found any explanation for what MHI is (or any of the other
> acrynoms), so I'm entirely lost.
MHI is documented at Documentation/mhi/
It is also referenced in the QAIC documentation - Documentation/accel/qaic/
It stands for "Modem Host Interface" (arguably a bad name now, but you
can guess where it came from). It is a Qualcomm hardware block and
associated software protocol that provides logical channels over a
hardware link. Most commonly used for PCIe.
Pretty much any modern Qualcomm PCIe device implements it. 4G modems,
5G modems, Wifi adapters, AIC100, etc. Instead of talking "PCIe", the
host talks "MHI" to the devices in most cases.
The core implementation for MHI exists in drivers/bus/mhi
MHI_UCI is the MHI Userspace Character Interface. It looked like most
buses (eg USB) provide some direct device access to userspace. MHI_UCI
was formulated along those same lines - provide direct userspace access
to a whitelist of channels. Qualcomm provides some fairly extensive
userspace utilities, and various communities have developed open source
alternatives using this mechanism.
MHI_UCI was proposed to the community as the common driver (misc device)
for all of the MHI devices. The Net folks came along, saw that it was
used for 4G/5G modems (Wireless Wide Area Network devices or WWAN) and
decided that they would not tolerate a common implementation. They
NACK'd MHI_UCI and required that a WWAN specific subsystem be developed
which would only service WWAN devices. The Net folks decreed that other
subsystems which needed the same functionality need to have their own
copy of the implementation.
QAIC devices expose Sahara (a boot time protocol) which has an existing
userspace that is also used with Modems, although it looks like WWAN
doesn't currently support those generations of products today. QAIC
devices also support DIAG, which is currently supported in WWAN. The
intent was to add the QAIC support for DIAG at a later time since it is
not required for the bare minimum viable driver.
So, QAIC devices support the same services, would use the same
userspace, but can't use a common implementation because Jakub(net)
doesn't want to share and convinced Greg to go along. I'm not
interested in pushing a cross tree fight (arguably already did that with
MHI_UCI). If neither Greg nor Net will accept a common implementation
that accelerators can use (QAIC), then the only place I can fit this is
in the Accel area.
Using aux bus seems to make little difference if QAIC is the only
consumer of this. I'm willing to refactor the implementation with some
feedback and guidence, but the uAPI seems set in stone due to the
existing userspace and WWAN (char devs with open/close/read/write/poll).
What would make you less unhappy?
> -Daniel
>
>>
>>>
>>> We need (eventually) 128 device nodes. We have systems with 32 QAIC
>>> devices, and each QAIC device uses 4 device nodes (32 * 4 = 128). WWAN
>>> subsystem would be similar. Looks like each 5G modem is 6 nodes per
>>> device, so if you had 22 5G modems on a system, you'd have 132 device
>>> nodes. I'm not aware of any such system, but it could exist.
>>>
>>> -Jeff
>>
>
^ permalink raw reply [flat|nested] 181+ messages in thread
* Re: linux-next: build failure after merge of the driver-core tree
2023-04-11 15:29 ` Jeffrey Hugo
@ 2023-04-11 16:31 ` Daniel Vetter
2023-04-11 17:18 ` Jeffrey Hugo
0 siblings, 1 reply; 181+ messages in thread
From: Daniel Vetter @ 2023-04-11 16:31 UTC (permalink / raw)
To: Jeffrey Hugo
Cc: Greg KH, Stephen Rothwell, Oded Gabbay,
Linux Kernel Mailing List, DRI, Pranjal Ramajor Asha Kanojiya,
Linux Next Mailing List, Jacek Lawrynowicz, Dave Airlie
On Tue, Apr 11, 2023 at 09:29:27AM -0600, Jeffrey Hugo wrote:
> On 4/11/2023 9:26 AM, Jeffrey Hugo wrote:
> > On 4/11/2023 9:13 AM, Greg KH wrote:
> > > On Tue, Apr 11, 2023 at 09:08:39AM -0600, Jeffrey Hugo wrote:
> > > > On 4/11/2023 9:01 AM, Daniel Vetter wrote:
> > > > > On Tue, Apr 11, 2023 at 12:40:28PM +0200, Greg KH wrote:
> > > > > > On Tue, Apr 11, 2023 at 11:55:20AM +0200, Daniel Vetter wrote:
> > > > > > > On Tue, Apr 11, 2023 at 02:38:12PM +1000, Stephen Rothwell wrote:
> > > > > > > > Hi all,
> > > > > > > >
> > > > > > > > After merging the driver-core tree, today's linux-next build (x86_64
> > > > > > > > allmodconfig) failed like this:
> > > > > > > >
> > > > > > > > In file included from include/linux/linkage.h:7,
> > > > > > > > from include/linux/kernel.h:17,
> > > > > > > > from drivers/accel/qaic/mhi_qaic_ctrl.c:4:
> > > > > > > > drivers/accel/qaic/mhi_qaic_ctrl.c: In function
> > > > > > > > 'mhi_qaic_ctrl_init':
> > > > > > > > include/linux/export.h:27:22: error: passing
> > > > > > > > argument 1 of 'class_create' from incompatible
> > > > > > > > pointer type
> > > > > > > > [-Werror=incompatible-pointer-types]
> > > > > > > > 27 | #define THIS_MODULE (&__this_module)
> > > > > > > > | ~^~~~~~~~~~~~~~~
> > > > > > > > | |
> > > > > > > > | struct module *
> > > > > > > > drivers/accel/qaic/mhi_qaic_ctrl.c:544:38: note:
> > > > > > > > in expansion of macro 'THIS_MODULE'
> > > > > > > > 544 | mqc_dev_class =
> > > > > > > > class_create(THIS_MODULE,
> > > > > > > > MHI_QAIC_CTRL_DRIVER_NAME);
> > > > > > > > | ^~~~~~~~~~~
> > > > > > > > In file included from include/linux/device.h:31,
> > > > > > > > from include/linux/mhi.h:9,
> > > > > > > > from drivers/accel/qaic/mhi_qaic_ctrl.c:5:
> > > > > > > > include/linux/device/class.h:229:54: note:
> > > > > > > > expected 'const char *' but argument is of type
> > > > > > > > 'struct module *'
> > > > > > > > 229 | struct class * __must_check
> > > > > > > > class_create(const char *name);
> > > > > > > > | ~~~~~~~~~~~~^~~~
> > > > > > > > drivers/accel/qaic/mhi_qaic_ctrl.c:544:25:
> > > > > > > > error: too many arguments to function
> > > > > > > > 'class_create'
> > > > > > > > 544 | mqc_dev_class =
> > > > > > > > class_create(THIS_MODULE,
> > > > > > > > MHI_QAIC_CTRL_DRIVER_NAME);
> > > > > > > > | ^~~~~~~~~~~~
> > > > > > > > include/linux/device/class.h:229:29: note: declared here
> > > > > > > > 229 | struct class * __must_check
> > > > > > > > class_create(const char *name);
> > > > > > > > | ^~~~~~~~~~~~
> > > > > > > >
> > > > > > > > Caused by commit
> > > > > > > >
> > > > > > > > 1aaba11da9aa ("driver core: class: remove
> > > > > > > > module * from class_create()")
> > > > > > > >
> > > > > > > > interacting with commit
> > > > > > > >
> > > > > > > > 566fc96198b4 ("accel/qaic: Add mhi_qaic_cntl")
> > > > > > > >
> > > > > > > > from the drm tree.
> > > > > > > >
> > > > > > > > I have applied the following merge fix patch for today.
> > > > > > > >
> > > > > > > > From: Stephen Rothwell <sfr@canb.auug.org.au>
> > > > > > > > Date: Tue, 11 Apr 2023 14:16:57 +1000
> > > > > > > > Subject: [PATCH] fixup for "driver core: class:
> > > > > > > > remove module * from class_create()"
> > > > > > > >
> > > > > > > > interacting with "accel/qaic: Add mhi_qaic_cntl"
> > > > > > > >
> > > > > > > > Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> > > > > > >
> > > > > > > Thanks for the fixup. Since Dave is out I've made a
> > > > > > > note about this in my
> > > > > > > handover mail so it won't get lost in the drm-next
> > > > > > > merge window pull. I
> > > > > > > don't think we need any other coordination than
> > > > > > > mention it in each pull to
> > > > > > > Linus, topic tree seems overkill for this. Plus there's no way I can
> > > > > > > untangle the drm tree anyway :-).
> > > > > >
> > > > > > Want me to submit a patch for the drm tree that moves this to use
> > > > > > class_register() instead, which will make the
> > > > > > merge/build issue go away
> > > > > > for you? That's my long-term goal here anyway, so converting this new
> > > > > > code to this api today would be something I have to do eventually :)
> > > > >
> > > > > We kinda closed drm-next for feature work mostly already (just pulling
> > > > > stuff in from subtrees), so won't really help for this merge window.
> > > > >
> > > > > For everything else I think this is up to Oded, I had no
> > > > > idea qaic needed
> > > > > it's entire own dev class and I don't want to dig into this
> > > > > for the risk I
> > > > > might freak out :-)
> > > > >
> > > > > Adding Oded.
> > > > >
> > > > > Cheers, Daniel
> > > >
> > > > Sorry for the mess.
> > > >
> > > > I made a note to update to class_register() once my drm-misc access is
> > > > sorted out. Looks like we'll address the conflict in the merge
> > > > window, and
> > > > catch the update to the new API in the following release.
> > >
> > > Wait, I think the large question is, "why does this need a separate
> > > class"? Why are you not using the accel char device and class? That is
> > > what everything under accel/ should be using, otherwise why put it in
> > > there?
> > >
> > > And what exactly are you using that class for? Just device nodes? If
> > > so, how many?
> > >
> > > thanks,
> > >
> > > greg k-h
> >
> >
> > Remember MHI_UCI that then evolved into the WWAN subsystem? I pointed
> > out at the time that AIC100/QAIC would need the same functionality.
> > You/Jakub told myself/Mani/Loic that a combined implementation is not
> > acceptable, and every area needs to implement their own version of
> > MHI_UCI.
> >
> > We took the WWAN subsystem and simplified it to meet our needs.
> >
> > The functionality is QAIC specific, so wedging it into the Accel node
> > seems to be a poor fit as it would subject Habana and iVPU to the same.
>
> Also, I forgot to mention. QAIC is sharing userspace components with WWAN,
> so we really cannot diverge from what WWAN has done and define a new API
> through the Accel node.
So there is an accel/drm_device in the qaic driver, but there's also this
different class thing, which I don't get.
And yeah if that's an entirely orthogonal thing then I guess that should
be in a different driver/subsystem, all supported with the aux bus to
multiplex the underlying device.
I haven't found any explanation for what MHI is (or any of the other
acrynoms), so I'm entirely lost.
-Daniel
>
> >
> > We need (eventually) 128 device nodes. We have systems with 32 QAIC
> > devices, and each QAIC device uses 4 device nodes (32 * 4 = 128). WWAN
> > subsystem would be similar. Looks like each 5G modem is 6 nodes per
> > device, so if you had 22 5G modems on a system, you'd have 132 device
> > nodes. I'm not aware of any such system, but it could exist.
> >
> > -Jeff
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
^ permalink raw reply [flat|nested] 181+ messages in thread
* Re: linux-next: build failure after merge of the driver-core tree
2023-04-11 15:26 ` Jeffrey Hugo
@ 2023-04-11 15:29 ` Jeffrey Hugo
2023-04-11 16:31 ` Daniel Vetter
0 siblings, 1 reply; 181+ messages in thread
From: Jeffrey Hugo @ 2023-04-11 15:29 UTC (permalink / raw)
To: Greg KH
Cc: Oded Gabbay, Stephen Rothwell, Dave Airlie,
Linux Kernel Mailing List, DRI, Pranjal Ramajor Asha Kanojiya,
Linux Next Mailing List, Jacek Lawrynowicz
On 4/11/2023 9:26 AM, Jeffrey Hugo wrote:
> On 4/11/2023 9:13 AM, Greg KH wrote:
>> On Tue, Apr 11, 2023 at 09:08:39AM -0600, Jeffrey Hugo wrote:
>>> On 4/11/2023 9:01 AM, Daniel Vetter wrote:
>>>> On Tue, Apr 11, 2023 at 12:40:28PM +0200, Greg KH wrote:
>>>>> On Tue, Apr 11, 2023 at 11:55:20AM +0200, Daniel Vetter wrote:
>>>>>> On Tue, Apr 11, 2023 at 02:38:12PM +1000, Stephen Rothwell wrote:
>>>>>>> Hi all,
>>>>>>>
>>>>>>> After merging the driver-core tree, today's linux-next build (x86_64
>>>>>>> allmodconfig) failed like this:
>>>>>>>
>>>>>>> In file included from include/linux/linkage.h:7,
>>>>>>> from include/linux/kernel.h:17,
>>>>>>> from drivers/accel/qaic/mhi_qaic_ctrl.c:4:
>>>>>>> drivers/accel/qaic/mhi_qaic_ctrl.c: In function
>>>>>>> 'mhi_qaic_ctrl_init':
>>>>>>> include/linux/export.h:27:22: error: passing argument 1 of
>>>>>>> 'class_create' from incompatible pointer type
>>>>>>> [-Werror=incompatible-pointer-types]
>>>>>>> 27 | #define THIS_MODULE (&__this_module)
>>>>>>> | ~^~~~~~~~~~~~~~~
>>>>>>> | |
>>>>>>> | struct module *
>>>>>>> drivers/accel/qaic/mhi_qaic_ctrl.c:544:38: note: in expansion of
>>>>>>> macro 'THIS_MODULE'
>>>>>>> 544 | mqc_dev_class = class_create(THIS_MODULE,
>>>>>>> MHI_QAIC_CTRL_DRIVER_NAME);
>>>>>>> | ^~~~~~~~~~~
>>>>>>> In file included from include/linux/device.h:31,
>>>>>>> from include/linux/mhi.h:9,
>>>>>>> from drivers/accel/qaic/mhi_qaic_ctrl.c:5:
>>>>>>> include/linux/device/class.h:229:54: note: expected 'const char
>>>>>>> *' but argument is of type 'struct module *'
>>>>>>> 229 | struct class * __must_check class_create(const char
>>>>>>> *name);
>>>>>>> | ~~~~~~~~~~~~^~~~
>>>>>>> drivers/accel/qaic/mhi_qaic_ctrl.c:544:25: error: too many
>>>>>>> arguments to function 'class_create'
>>>>>>> 544 | mqc_dev_class = class_create(THIS_MODULE,
>>>>>>> MHI_QAIC_CTRL_DRIVER_NAME);
>>>>>>> | ^~~~~~~~~~~~
>>>>>>> include/linux/device/class.h:229:29: note: declared here
>>>>>>> 229 | struct class * __must_check class_create(const char
>>>>>>> *name);
>>>>>>> | ^~~~~~~~~~~~
>>>>>>>
>>>>>>> Caused by commit
>>>>>>>
>>>>>>> 1aaba11da9aa ("driver core: class: remove module * from
>>>>>>> class_create()")
>>>>>>>
>>>>>>> interacting with commit
>>>>>>>
>>>>>>> 566fc96198b4 ("accel/qaic: Add mhi_qaic_cntl")
>>>>>>>
>>>>>>> from the drm tree.
>>>>>>>
>>>>>>> I have applied the following merge fix patch for today.
>>>>>>>
>>>>>>> From: Stephen Rothwell <sfr@canb.auug.org.au>
>>>>>>> Date: Tue, 11 Apr 2023 14:16:57 +1000
>>>>>>> Subject: [PATCH] fixup for "driver core: class: remove module *
>>>>>>> from class_create()"
>>>>>>>
>>>>>>> interacting with "accel/qaic: Add mhi_qaic_cntl"
>>>>>>>
>>>>>>> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
>>>>>>
>>>>>> Thanks for the fixup. Since Dave is out I've made a note about
>>>>>> this in my
>>>>>> handover mail so it won't get lost in the drm-next merge window
>>>>>> pull. I
>>>>>> don't think we need any other coordination than mention it in each
>>>>>> pull to
>>>>>> Linus, topic tree seems overkill for this. Plus there's no way I can
>>>>>> untangle the drm tree anyway :-).
>>>>>
>>>>> Want me to submit a patch for the drm tree that moves this to use
>>>>> class_register() instead, which will make the merge/build issue go
>>>>> away
>>>>> for you? That's my long-term goal here anyway, so converting this new
>>>>> code to this api today would be something I have to do eventually :)
>>>>
>>>> We kinda closed drm-next for feature work mostly already (just pulling
>>>> stuff in from subtrees), so won't really help for this merge window.
>>>>
>>>> For everything else I think this is up to Oded, I had no idea qaic
>>>> needed
>>>> it's entire own dev class and I don't want to dig into this for the
>>>> risk I
>>>> might freak out :-)
>>>>
>>>> Adding Oded.
>>>>
>>>> Cheers, Daniel
>>>
>>> Sorry for the mess.
>>>
>>> I made a note to update to class_register() once my drm-misc access is
>>> sorted out. Looks like we'll address the conflict in the merge
>>> window, and
>>> catch the update to the new API in the following release.
>>
>> Wait, I think the large question is, "why does this need a separate
>> class"? Why are you not using the accel char device and class? That is
>> what everything under accel/ should be using, otherwise why put it in
>> there?
>>
>> And what exactly are you using that class for? Just device nodes? If
>> so, how many?
>>
>> thanks,
>>
>> greg k-h
>
>
> Remember MHI_UCI that then evolved into the WWAN subsystem? I pointed
> out at the time that AIC100/QAIC would need the same functionality.
> You/Jakub told myself/Mani/Loic that a combined implementation is not
> acceptable, and every area needs to implement their own version of MHI_UCI.
>
> We took the WWAN subsystem and simplified it to meet our needs.
>
> The functionality is QAIC specific, so wedging it into the Accel node
> seems to be a poor fit as it would subject Habana and iVPU to the same.
Also, I forgot to mention. QAIC is sharing userspace components with
WWAN, so we really cannot diverge from what WWAN has done and define a
new API through the Accel node.
>
> We need (eventually) 128 device nodes. We have systems with 32 QAIC
> devices, and each QAIC device uses 4 device nodes (32 * 4 = 128). WWAN
> subsystem would be similar. Looks like each 5G modem is 6 nodes per
> device, so if you had 22 5G modems on a system, you'd have 132 device
> nodes. I'm not aware of any such system, but it could exist.
>
> -Jeff
^ permalink raw reply [flat|nested] 181+ messages in thread
* Re: linux-next: build failure after merge of the driver-core tree
2023-04-11 15:13 ` Greg KH
@ 2023-04-11 15:26 ` Jeffrey Hugo
2023-04-11 15:29 ` Jeffrey Hugo
0 siblings, 1 reply; 181+ messages in thread
From: Jeffrey Hugo @ 2023-04-11 15:26 UTC (permalink / raw)
To: Greg KH
Cc: Oded Gabbay, Stephen Rothwell, Dave Airlie,
Linux Kernel Mailing List, DRI, Pranjal Ramajor Asha Kanojiya,
Linux Next Mailing List, Jacek Lawrynowicz
On 4/11/2023 9:13 AM, Greg KH wrote:
> On Tue, Apr 11, 2023 at 09:08:39AM -0600, Jeffrey Hugo wrote:
>> On 4/11/2023 9:01 AM, Daniel Vetter wrote:
>>> On Tue, Apr 11, 2023 at 12:40:28PM +0200, Greg KH wrote:
>>>> On Tue, Apr 11, 2023 at 11:55:20AM +0200, Daniel Vetter wrote:
>>>>> On Tue, Apr 11, 2023 at 02:38:12PM +1000, Stephen Rothwell wrote:
>>>>>> Hi all,
>>>>>>
>>>>>> After merging the driver-core tree, today's linux-next build (x86_64
>>>>>> allmodconfig) failed like this:
>>>>>>
>>>>>> In file included from include/linux/linkage.h:7,
>>>>>> from include/linux/kernel.h:17,
>>>>>> from drivers/accel/qaic/mhi_qaic_ctrl.c:4:
>>>>>> drivers/accel/qaic/mhi_qaic_ctrl.c: In function 'mhi_qaic_ctrl_init':
>>>>>> include/linux/export.h:27:22: error: passing argument 1 of 'class_create' from incompatible pointer type [-Werror=incompatible-pointer-types]
>>>>>> 27 | #define THIS_MODULE (&__this_module)
>>>>>> | ~^~~~~~~~~~~~~~~
>>>>>> | |
>>>>>> | struct module *
>>>>>> drivers/accel/qaic/mhi_qaic_ctrl.c:544:38: note: in expansion of macro 'THIS_MODULE'
>>>>>> 544 | mqc_dev_class = class_create(THIS_MODULE, MHI_QAIC_CTRL_DRIVER_NAME);
>>>>>> | ^~~~~~~~~~~
>>>>>> In file included from include/linux/device.h:31,
>>>>>> from include/linux/mhi.h:9,
>>>>>> from drivers/accel/qaic/mhi_qaic_ctrl.c:5:
>>>>>> include/linux/device/class.h:229:54: note: expected 'const char *' but argument is of type 'struct module *'
>>>>>> 229 | struct class * __must_check class_create(const char *name);
>>>>>> | ~~~~~~~~~~~~^~~~
>>>>>> drivers/accel/qaic/mhi_qaic_ctrl.c:544:25: error: too many arguments to function 'class_create'
>>>>>> 544 | mqc_dev_class = class_create(THIS_MODULE, MHI_QAIC_CTRL_DRIVER_NAME);
>>>>>> | ^~~~~~~~~~~~
>>>>>> include/linux/device/class.h:229:29: note: declared here
>>>>>> 229 | struct class * __must_check class_create(const char *name);
>>>>>> | ^~~~~~~~~~~~
>>>>>>
>>>>>> Caused by commit
>>>>>>
>>>>>> 1aaba11da9aa ("driver core: class: remove module * from class_create()")
>>>>>>
>>>>>> interacting with commit
>>>>>>
>>>>>> 566fc96198b4 ("accel/qaic: Add mhi_qaic_cntl")
>>>>>>
>>>>>> from the drm tree.
>>>>>>
>>>>>> I have applied the following merge fix patch for today.
>>>>>>
>>>>>> From: Stephen Rothwell <sfr@canb.auug.org.au>
>>>>>> Date: Tue, 11 Apr 2023 14:16:57 +1000
>>>>>> Subject: [PATCH] fixup for "driver core: class: remove module * from class_create()"
>>>>>>
>>>>>> interacting with "accel/qaic: Add mhi_qaic_cntl"
>>>>>>
>>>>>> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
>>>>>
>>>>> Thanks for the fixup. Since Dave is out I've made a note about this in my
>>>>> handover mail so it won't get lost in the drm-next merge window pull. I
>>>>> don't think we need any other coordination than mention it in each pull to
>>>>> Linus, topic tree seems overkill for this. Plus there's no way I can
>>>>> untangle the drm tree anyway :-).
>>>>
>>>> Want me to submit a patch for the drm tree that moves this to use
>>>> class_register() instead, which will make the merge/build issue go away
>>>> for you? That's my long-term goal here anyway, so converting this new
>>>> code to this api today would be something I have to do eventually :)
>>>
>>> We kinda closed drm-next for feature work mostly already (just pulling
>>> stuff in from subtrees), so won't really help for this merge window.
>>>
>>> For everything else I think this is up to Oded, I had no idea qaic needed
>>> it's entire own dev class and I don't want to dig into this for the risk I
>>> might freak out :-)
>>>
>>> Adding Oded.
>>>
>>> Cheers, Daniel
>>
>> Sorry for the mess.
>>
>> I made a note to update to class_register() once my drm-misc access is
>> sorted out. Looks like we'll address the conflict in the merge window, and
>> catch the update to the new API in the following release.
>
> Wait, I think the large question is, "why does this need a separate
> class"? Why are you not using the accel char device and class? That is
> what everything under accel/ should be using, otherwise why put it in
> there?
>
> And what exactly are you using that class for? Just device nodes? If
> so, how many?
>
> thanks,
>
> greg k-h
Remember MHI_UCI that then evolved into the WWAN subsystem? I pointed
out at the time that AIC100/QAIC would need the same functionality.
You/Jakub told myself/Mani/Loic that a combined implementation is not
acceptable, and every area needs to implement their own version of MHI_UCI.
We took the WWAN subsystem and simplified it to meet our needs.
The functionality is QAIC specific, so wedging it into the Accel node
seems to be a poor fit as it would subject Habana and iVPU to the same.
We need (eventually) 128 device nodes. We have systems with 32 QAIC
devices, and each QAIC device uses 4 device nodes (32 * 4 = 128). WWAN
subsystem would be similar. Looks like each 5G modem is 6 nodes per
device, so if you had 22 5G modems on a system, you'd have 132 device
nodes. I'm not aware of any such system, but it could exist.
-Jeff
^ permalink raw reply [flat|nested] 181+ messages in thread
* Re: linux-next: build failure after merge of the driver-core tree
2023-04-11 15:08 ` Jeffrey Hugo
@ 2023-04-11 15:13 ` Greg KH
2023-04-11 15:26 ` Jeffrey Hugo
0 siblings, 1 reply; 181+ messages in thread
From: Greg KH @ 2023-04-11 15:13 UTC (permalink / raw)
To: Jeffrey Hugo
Cc: Oded Gabbay, Stephen Rothwell, Dave Airlie,
Linux Kernel Mailing List, DRI, Pranjal Ramajor Asha Kanojiya,
Linux Next Mailing List, Jacek Lawrynowicz
On Tue, Apr 11, 2023 at 09:08:39AM -0600, Jeffrey Hugo wrote:
> On 4/11/2023 9:01 AM, Daniel Vetter wrote:
> > On Tue, Apr 11, 2023 at 12:40:28PM +0200, Greg KH wrote:
> > > On Tue, Apr 11, 2023 at 11:55:20AM +0200, Daniel Vetter wrote:
> > > > On Tue, Apr 11, 2023 at 02:38:12PM +1000, Stephen Rothwell wrote:
> > > > > Hi all,
> > > > >
> > > > > After merging the driver-core tree, today's linux-next build (x86_64
> > > > > allmodconfig) failed like this:
> > > > >
> > > > > In file included from include/linux/linkage.h:7,
> > > > > from include/linux/kernel.h:17,
> > > > > from drivers/accel/qaic/mhi_qaic_ctrl.c:4:
> > > > > drivers/accel/qaic/mhi_qaic_ctrl.c: In function 'mhi_qaic_ctrl_init':
> > > > > include/linux/export.h:27:22: error: passing argument 1 of 'class_create' from incompatible pointer type [-Werror=incompatible-pointer-types]
> > > > > 27 | #define THIS_MODULE (&__this_module)
> > > > > | ~^~~~~~~~~~~~~~~
> > > > > | |
> > > > > | struct module *
> > > > > drivers/accel/qaic/mhi_qaic_ctrl.c:544:38: note: in expansion of macro 'THIS_MODULE'
> > > > > 544 | mqc_dev_class = class_create(THIS_MODULE, MHI_QAIC_CTRL_DRIVER_NAME);
> > > > > | ^~~~~~~~~~~
> > > > > In file included from include/linux/device.h:31,
> > > > > from include/linux/mhi.h:9,
> > > > > from drivers/accel/qaic/mhi_qaic_ctrl.c:5:
> > > > > include/linux/device/class.h:229:54: note: expected 'const char *' but argument is of type 'struct module *'
> > > > > 229 | struct class * __must_check class_create(const char *name);
> > > > > | ~~~~~~~~~~~~^~~~
> > > > > drivers/accel/qaic/mhi_qaic_ctrl.c:544:25: error: too many arguments to function 'class_create'
> > > > > 544 | mqc_dev_class = class_create(THIS_MODULE, MHI_QAIC_CTRL_DRIVER_NAME);
> > > > > | ^~~~~~~~~~~~
> > > > > include/linux/device/class.h:229:29: note: declared here
> > > > > 229 | struct class * __must_check class_create(const char *name);
> > > > > | ^~~~~~~~~~~~
> > > > >
> > > > > Caused by commit
> > > > >
> > > > > 1aaba11da9aa ("driver core: class: remove module * from class_create()")
> > > > >
> > > > > interacting with commit
> > > > >
> > > > > 566fc96198b4 ("accel/qaic: Add mhi_qaic_cntl")
> > > > >
> > > > > from the drm tree.
> > > > >
> > > > > I have applied the following merge fix patch for today.
> > > > >
> > > > > From: Stephen Rothwell <sfr@canb.auug.org.au>
> > > > > Date: Tue, 11 Apr 2023 14:16:57 +1000
> > > > > Subject: [PATCH] fixup for "driver core: class: remove module * from class_create()"
> > > > >
> > > > > interacting with "accel/qaic: Add mhi_qaic_cntl"
> > > > >
> > > > > Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> > > >
> > > > Thanks for the fixup. Since Dave is out I've made a note about this in my
> > > > handover mail so it won't get lost in the drm-next merge window pull. I
> > > > don't think we need any other coordination than mention it in each pull to
> > > > Linus, topic tree seems overkill for this. Plus there's no way I can
> > > > untangle the drm tree anyway :-).
> > >
> > > Want me to submit a patch for the drm tree that moves this to use
> > > class_register() instead, which will make the merge/build issue go away
> > > for you? That's my long-term goal here anyway, so converting this new
> > > code to this api today would be something I have to do eventually :)
> >
> > We kinda closed drm-next for feature work mostly already (just pulling
> > stuff in from subtrees), so won't really help for this merge window.
> >
> > For everything else I think this is up to Oded, I had no idea qaic needed
> > it's entire own dev class and I don't want to dig into this for the risk I
> > might freak out :-)
> >
> > Adding Oded.
> >
> > Cheers, Daniel
>
> Sorry for the mess.
>
> I made a note to update to class_register() once my drm-misc access is
> sorted out. Looks like we'll address the conflict in the merge window, and
> catch the update to the new API in the following release.
Wait, I think the large question is, "why does this need a separate
class"? Why are you not using the accel char device and class? That is
what everything under accel/ should be using, otherwise why put it in
there?
And what exactly are you using that class for? Just device nodes? If
so, how many?
thanks,
greg k-h
^ permalink raw reply [flat|nested] 181+ messages in thread
* Re: linux-next: build failure after merge of the driver-core tree
2023-04-11 15:01 ` Daniel Vetter
@ 2023-04-11 15:08 ` Jeffrey Hugo
2023-04-11 15:13 ` Greg KH
0 siblings, 1 reply; 181+ messages in thread
From: Jeffrey Hugo @ 2023-04-11 15:08 UTC (permalink / raw)
To: Greg KH, Oded Gabbay, Stephen Rothwell, Dave Airlie,
Linux Kernel Mailing List, DRI, Pranjal Ramajor Asha Kanojiya,
Linux Next Mailing List, Jacek Lawrynowicz
On 4/11/2023 9:01 AM, Daniel Vetter wrote:
> On Tue, Apr 11, 2023 at 12:40:28PM +0200, Greg KH wrote:
>> On Tue, Apr 11, 2023 at 11:55:20AM +0200, Daniel Vetter wrote:
>>> On Tue, Apr 11, 2023 at 02:38:12PM +1000, Stephen Rothwell wrote:
>>>> Hi all,
>>>>
>>>> After merging the driver-core tree, today's linux-next build (x86_64
>>>> allmodconfig) failed like this:
>>>>
>>>> In file included from include/linux/linkage.h:7,
>>>> from include/linux/kernel.h:17,
>>>> from drivers/accel/qaic/mhi_qaic_ctrl.c:4:
>>>> drivers/accel/qaic/mhi_qaic_ctrl.c: In function 'mhi_qaic_ctrl_init':
>>>> include/linux/export.h:27:22: error: passing argument 1 of 'class_create' from incompatible pointer type [-Werror=incompatible-pointer-types]
>>>> 27 | #define THIS_MODULE (&__this_module)
>>>> | ~^~~~~~~~~~~~~~~
>>>> | |
>>>> | struct module *
>>>> drivers/accel/qaic/mhi_qaic_ctrl.c:544:38: note: in expansion of macro 'THIS_MODULE'
>>>> 544 | mqc_dev_class = class_create(THIS_MODULE, MHI_QAIC_CTRL_DRIVER_NAME);
>>>> | ^~~~~~~~~~~
>>>> In file included from include/linux/device.h:31,
>>>> from include/linux/mhi.h:9,
>>>> from drivers/accel/qaic/mhi_qaic_ctrl.c:5:
>>>> include/linux/device/class.h:229:54: note: expected 'const char *' but argument is of type 'struct module *'
>>>> 229 | struct class * __must_check class_create(const char *name);
>>>> | ~~~~~~~~~~~~^~~~
>>>> drivers/accel/qaic/mhi_qaic_ctrl.c:544:25: error: too many arguments to function 'class_create'
>>>> 544 | mqc_dev_class = class_create(THIS_MODULE, MHI_QAIC_CTRL_DRIVER_NAME);
>>>> | ^~~~~~~~~~~~
>>>> include/linux/device/class.h:229:29: note: declared here
>>>> 229 | struct class * __must_check class_create(const char *name);
>>>> | ^~~~~~~~~~~~
>>>>
>>>> Caused by commit
>>>>
>>>> 1aaba11da9aa ("driver core: class: remove module * from class_create()")
>>>>
>>>> interacting with commit
>>>>
>>>> 566fc96198b4 ("accel/qaic: Add mhi_qaic_cntl")
>>>>
>>>> from the drm tree.
>>>>
>>>> I have applied the following merge fix patch for today.
>>>>
>>>> From: Stephen Rothwell <sfr@canb.auug.org.au>
>>>> Date: Tue, 11 Apr 2023 14:16:57 +1000
>>>> Subject: [PATCH] fixup for "driver core: class: remove module * from class_create()"
>>>>
>>>> interacting with "accel/qaic: Add mhi_qaic_cntl"
>>>>
>>>> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
>>>
>>> Thanks for the fixup. Since Dave is out I've made a note about this in my
>>> handover mail so it won't get lost in the drm-next merge window pull. I
>>> don't think we need any other coordination than mention it in each pull to
>>> Linus, topic tree seems overkill for this. Plus there's no way I can
>>> untangle the drm tree anyway :-).
>>
>> Want me to submit a patch for the drm tree that moves this to use
>> class_register() instead, which will make the merge/build issue go away
>> for you? That's my long-term goal here anyway, so converting this new
>> code to this api today would be something I have to do eventually :)
>
> We kinda closed drm-next for feature work mostly already (just pulling
> stuff in from subtrees), so won't really help for this merge window.
>
> For everything else I think this is up to Oded, I had no idea qaic needed
> it's entire own dev class and I don't want to dig into this for the risk I
> might freak out :-)
>
> Adding Oded.
>
> Cheers, Daniel
Sorry for the mess.
I made a note to update to class_register() once my drm-misc access is
sorted out. Looks like we'll address the conflict in the merge window,
and catch the update to the new API in the following release.
-Jeff
^ permalink raw reply [flat|nested] 181+ messages in thread
* Re: linux-next: build failure after merge of the driver-core tree
2023-04-11 10:40 ` Greg KH
@ 2023-04-11 15:01 ` Daniel Vetter
2023-04-11 15:08 ` Jeffrey Hugo
0 siblings, 1 reply; 181+ messages in thread
From: Daniel Vetter @ 2023-04-11 15:01 UTC (permalink / raw)
To: Greg KH, Oded Gabbay
Cc: Stephen Rothwell, Dave Airlie, Jeffrey Hugo,
Linux Kernel Mailing List, DRI, Pranjal Ramajor Asha Kanojiya,
Linux Next Mailing List, Jacek Lawrynowicz, Oded Gabbay
On Tue, Apr 11, 2023 at 12:40:28PM +0200, Greg KH wrote:
> On Tue, Apr 11, 2023 at 11:55:20AM +0200, Daniel Vetter wrote:
> > On Tue, Apr 11, 2023 at 02:38:12PM +1000, Stephen Rothwell wrote:
> > > Hi all,
> > >
> > > After merging the driver-core tree, today's linux-next build (x86_64
> > > allmodconfig) failed like this:
> > >
> > > In file included from include/linux/linkage.h:7,
> > > from include/linux/kernel.h:17,
> > > from drivers/accel/qaic/mhi_qaic_ctrl.c:4:
> > > drivers/accel/qaic/mhi_qaic_ctrl.c: In function 'mhi_qaic_ctrl_init':
> > > include/linux/export.h:27:22: error: passing argument 1 of 'class_create' from incompatible pointer type [-Werror=incompatible-pointer-types]
> > > 27 | #define THIS_MODULE (&__this_module)
> > > | ~^~~~~~~~~~~~~~~
> > > | |
> > > | struct module *
> > > drivers/accel/qaic/mhi_qaic_ctrl.c:544:38: note: in expansion of macro 'THIS_MODULE'
> > > 544 | mqc_dev_class = class_create(THIS_MODULE, MHI_QAIC_CTRL_DRIVER_NAME);
> > > | ^~~~~~~~~~~
> > > In file included from include/linux/device.h:31,
> > > from include/linux/mhi.h:9,
> > > from drivers/accel/qaic/mhi_qaic_ctrl.c:5:
> > > include/linux/device/class.h:229:54: note: expected 'const char *' but argument is of type 'struct module *'
> > > 229 | struct class * __must_check class_create(const char *name);
> > > | ~~~~~~~~~~~~^~~~
> > > drivers/accel/qaic/mhi_qaic_ctrl.c:544:25: error: too many arguments to function 'class_create'
> > > 544 | mqc_dev_class = class_create(THIS_MODULE, MHI_QAIC_CTRL_DRIVER_NAME);
> > > | ^~~~~~~~~~~~
> > > include/linux/device/class.h:229:29: note: declared here
> > > 229 | struct class * __must_check class_create(const char *name);
> > > | ^~~~~~~~~~~~
> > >
> > > Caused by commit
> > >
> > > 1aaba11da9aa ("driver core: class: remove module * from class_create()")
> > >
> > > interacting with commit
> > >
> > > 566fc96198b4 ("accel/qaic: Add mhi_qaic_cntl")
> > >
> > > from the drm tree.
> > >
> > > I have applied the following merge fix patch for today.
> > >
> > > From: Stephen Rothwell <sfr@canb.auug.org.au>
> > > Date: Tue, 11 Apr 2023 14:16:57 +1000
> > > Subject: [PATCH] fixup for "driver core: class: remove module * from class_create()"
> > >
> > > interacting with "accel/qaic: Add mhi_qaic_cntl"
> > >
> > > Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> >
> > Thanks for the fixup. Since Dave is out I've made a note about this in my
> > handover mail so it won't get lost in the drm-next merge window pull. I
> > don't think we need any other coordination than mention it in each pull to
> > Linus, topic tree seems overkill for this. Plus there's no way I can
> > untangle the drm tree anyway :-).
>
> Want me to submit a patch for the drm tree that moves this to use
> class_register() instead, which will make the merge/build issue go away
> for you? That's my long-term goal here anyway, so converting this new
> code to this api today would be something I have to do eventually :)
We kinda closed drm-next for feature work mostly already (just pulling
stuff in from subtrees), so won't really help for this merge window.
For everything else I think this is up to Oded, I had no idea qaic needed
it's entire own dev class and I don't want to dig into this for the risk I
might freak out :-)
Adding Oded.
Cheers, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
^ permalink raw reply [flat|nested] 181+ messages in thread
* Re: linux-next: build failure after merge of the driver-core tree
2023-04-11 9:55 ` Daniel Vetter
@ 2023-04-11 10:40 ` Greg KH
2023-04-11 15:01 ` Daniel Vetter
0 siblings, 1 reply; 181+ messages in thread
From: Greg KH @ 2023-04-11 10:40 UTC (permalink / raw)
To: Stephen Rothwell, Dave Airlie, Jeffrey Hugo,
Linux Kernel Mailing List, DRI, Pranjal Ramajor Asha Kanojiya,
Linux Next Mailing List, Jacek Lawrynowicz
On Tue, Apr 11, 2023 at 11:55:20AM +0200, Daniel Vetter wrote:
> On Tue, Apr 11, 2023 at 02:38:12PM +1000, Stephen Rothwell wrote:
> > Hi all,
> >
> > After merging the driver-core tree, today's linux-next build (x86_64
> > allmodconfig) failed like this:
> >
> > In file included from include/linux/linkage.h:7,
> > from include/linux/kernel.h:17,
> > from drivers/accel/qaic/mhi_qaic_ctrl.c:4:
> > drivers/accel/qaic/mhi_qaic_ctrl.c: In function 'mhi_qaic_ctrl_init':
> > include/linux/export.h:27:22: error: passing argument 1 of 'class_create' from incompatible pointer type [-Werror=incompatible-pointer-types]
> > 27 | #define THIS_MODULE (&__this_module)
> > | ~^~~~~~~~~~~~~~~
> > | |
> > | struct module *
> > drivers/accel/qaic/mhi_qaic_ctrl.c:544:38: note: in expansion of macro 'THIS_MODULE'
> > 544 | mqc_dev_class = class_create(THIS_MODULE, MHI_QAIC_CTRL_DRIVER_NAME);
> > | ^~~~~~~~~~~
> > In file included from include/linux/device.h:31,
> > from include/linux/mhi.h:9,
> > from drivers/accel/qaic/mhi_qaic_ctrl.c:5:
> > include/linux/device/class.h:229:54: note: expected 'const char *' but argument is of type 'struct module *'
> > 229 | struct class * __must_check class_create(const char *name);
> > | ~~~~~~~~~~~~^~~~
> > drivers/accel/qaic/mhi_qaic_ctrl.c:544:25: error: too many arguments to function 'class_create'
> > 544 | mqc_dev_class = class_create(THIS_MODULE, MHI_QAIC_CTRL_DRIVER_NAME);
> > | ^~~~~~~~~~~~
> > include/linux/device/class.h:229:29: note: declared here
> > 229 | struct class * __must_check class_create(const char *name);
> > | ^~~~~~~~~~~~
> >
> > Caused by commit
> >
> > 1aaba11da9aa ("driver core: class: remove module * from class_create()")
> >
> > interacting with commit
> >
> > 566fc96198b4 ("accel/qaic: Add mhi_qaic_cntl")
> >
> > from the drm tree.
> >
> > I have applied the following merge fix patch for today.
> >
> > From: Stephen Rothwell <sfr@canb.auug.org.au>
> > Date: Tue, 11 Apr 2023 14:16:57 +1000
> > Subject: [PATCH] fixup for "driver core: class: remove module * from class_create()"
> >
> > interacting with "accel/qaic: Add mhi_qaic_cntl"
> >
> > Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
>
> Thanks for the fixup. Since Dave is out I've made a note about this in my
> handover mail so it won't get lost in the drm-next merge window pull. I
> don't think we need any other coordination than mention it in each pull to
> Linus, topic tree seems overkill for this. Plus there's no way I can
> untangle the drm tree anyway :-).
Want me to submit a patch for the drm tree that moves this to use
class_register() instead, which will make the merge/build issue go away
for you? That's my long-term goal here anyway, so converting this new
code to this api today would be something I have to do eventually :)
thanks,
greg k-h
^ permalink raw reply [flat|nested] 181+ messages in thread
* Re: linux-next: build failure after merge of the driver-core tree
2023-04-11 4:38 Stephen Rothwell
@ 2023-04-11 9:55 ` Daniel Vetter
2023-04-11 10:40 ` Greg KH
0 siblings, 1 reply; 181+ messages in thread
From: Daniel Vetter @ 2023-04-11 9:55 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Greg KH, Dave Airlie, Jeffrey Hugo, Linux Kernel Mailing List,
DRI, Pranjal Ramajor Asha Kanojiya, Linux Next Mailing List,
Jacek Lawrynowicz
On Tue, Apr 11, 2023 at 02:38:12PM +1000, Stephen Rothwell wrote:
> Hi all,
>
> After merging the driver-core tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
>
> In file included from include/linux/linkage.h:7,
> from include/linux/kernel.h:17,
> from drivers/accel/qaic/mhi_qaic_ctrl.c:4:
> drivers/accel/qaic/mhi_qaic_ctrl.c: In function 'mhi_qaic_ctrl_init':
> include/linux/export.h:27:22: error: passing argument 1 of 'class_create' from incompatible pointer type [-Werror=incompatible-pointer-types]
> 27 | #define THIS_MODULE (&__this_module)
> | ~^~~~~~~~~~~~~~~
> | |
> | struct module *
> drivers/accel/qaic/mhi_qaic_ctrl.c:544:38: note: in expansion of macro 'THIS_MODULE'
> 544 | mqc_dev_class = class_create(THIS_MODULE, MHI_QAIC_CTRL_DRIVER_NAME);
> | ^~~~~~~~~~~
> In file included from include/linux/device.h:31,
> from include/linux/mhi.h:9,
> from drivers/accel/qaic/mhi_qaic_ctrl.c:5:
> include/linux/device/class.h:229:54: note: expected 'const char *' but argument is of type 'struct module *'
> 229 | struct class * __must_check class_create(const char *name);
> | ~~~~~~~~~~~~^~~~
> drivers/accel/qaic/mhi_qaic_ctrl.c:544:25: error: too many arguments to function 'class_create'
> 544 | mqc_dev_class = class_create(THIS_MODULE, MHI_QAIC_CTRL_DRIVER_NAME);
> | ^~~~~~~~~~~~
> include/linux/device/class.h:229:29: note: declared here
> 229 | struct class * __must_check class_create(const char *name);
> | ^~~~~~~~~~~~
>
> Caused by commit
>
> 1aaba11da9aa ("driver core: class: remove module * from class_create()")
>
> interacting with commit
>
> 566fc96198b4 ("accel/qaic: Add mhi_qaic_cntl")
>
> from the drm tree.
>
> I have applied the following merge fix patch for today.
>
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Tue, 11 Apr 2023 14:16:57 +1000
> Subject: [PATCH] fixup for "driver core: class: remove module * from class_create()"
>
> interacting with "accel/qaic: Add mhi_qaic_cntl"
>
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
Thanks for the fixup. Since Dave is out I've made a note about this in my
handover mail so it won't get lost in the drm-next merge window pull. I
don't think we need any other coordination than mention it in each pull to
Linus, topic tree seems overkill for this. Plus there's no way I can
untangle the drm tree anyway :-).
-Daniel
> ---
> drivers/accel/qaic/mhi_qaic_ctrl.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/accel/qaic/mhi_qaic_ctrl.c b/drivers/accel/qaic/mhi_qaic_ctrl.c
> index 0c7e571f1f12..96db1580c72d 100644
> --- a/drivers/accel/qaic/mhi_qaic_ctrl.c
> +++ b/drivers/accel/qaic/mhi_qaic_ctrl.c
> @@ -541,7 +541,7 @@ int mhi_qaic_ctrl_init(void)
> return ret;
>
> mqc_dev_major = ret;
> - mqc_dev_class = class_create(THIS_MODULE, MHI_QAIC_CTRL_DRIVER_NAME);
> + mqc_dev_class = class_create(MHI_QAIC_CTRL_DRIVER_NAME);
> if (IS_ERR(mqc_dev_class)) {
> ret = PTR_ERR(mqc_dev_class);
> goto unregister_chrdev;
> --
> 2.39.2
>
> --
> Cheers,
> Stephen Rothwell
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
^ permalink raw reply [flat|nested] 181+ messages in thread
* linux-next: build failure after merge of the driver-core tree
@ 2023-04-11 4:38 Stephen Rothwell
2023-04-11 9:55 ` Daniel Vetter
0 siblings, 1 reply; 181+ messages in thread
From: Stephen Rothwell @ 2023-04-11 4:38 UTC (permalink / raw)
To: Greg KH, Dave Airlie
Cc: Jacek Lawrynowicz, Jeffrey Hugo, Pranjal Ramajor Asha Kanojiya,
DRI, Linux Kernel Mailing List, Linux Next Mailing List
[-- Attachment #1: Type: text/plain, Size: 2921 bytes --]
Hi all,
After merging the driver-core tree, today's linux-next build (x86_64
allmodconfig) failed like this:
In file included from include/linux/linkage.h:7,
from include/linux/kernel.h:17,
from drivers/accel/qaic/mhi_qaic_ctrl.c:4:
drivers/accel/qaic/mhi_qaic_ctrl.c: In function 'mhi_qaic_ctrl_init':
include/linux/export.h:27:22: error: passing argument 1 of 'class_create' from incompatible pointer type [-Werror=incompatible-pointer-types]
27 | #define THIS_MODULE (&__this_module)
| ~^~~~~~~~~~~~~~~
| |
| struct module *
drivers/accel/qaic/mhi_qaic_ctrl.c:544:38: note: in expansion of macro 'THIS_MODULE'
544 | mqc_dev_class = class_create(THIS_MODULE, MHI_QAIC_CTRL_DRIVER_NAME);
| ^~~~~~~~~~~
In file included from include/linux/device.h:31,
from include/linux/mhi.h:9,
from drivers/accel/qaic/mhi_qaic_ctrl.c:5:
include/linux/device/class.h:229:54: note: expected 'const char *' but argument is of type 'struct module *'
229 | struct class * __must_check class_create(const char *name);
| ~~~~~~~~~~~~^~~~
drivers/accel/qaic/mhi_qaic_ctrl.c:544:25: error: too many arguments to function 'class_create'
544 | mqc_dev_class = class_create(THIS_MODULE, MHI_QAIC_CTRL_DRIVER_NAME);
| ^~~~~~~~~~~~
include/linux/device/class.h:229:29: note: declared here
229 | struct class * __must_check class_create(const char *name);
| ^~~~~~~~~~~~
Caused by commit
1aaba11da9aa ("driver core: class: remove module * from class_create()")
interacting with commit
566fc96198b4 ("accel/qaic: Add mhi_qaic_cntl")
from the drm tree.
I have applied the following merge fix patch for today.
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Tue, 11 Apr 2023 14:16:57 +1000
Subject: [PATCH] fixup for "driver core: class: remove module * from class_create()"
interacting with "accel/qaic: Add mhi_qaic_cntl"
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
drivers/accel/qaic/mhi_qaic_ctrl.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/accel/qaic/mhi_qaic_ctrl.c b/drivers/accel/qaic/mhi_qaic_ctrl.c
index 0c7e571f1f12..96db1580c72d 100644
--- a/drivers/accel/qaic/mhi_qaic_ctrl.c
+++ b/drivers/accel/qaic/mhi_qaic_ctrl.c
@@ -541,7 +541,7 @@ int mhi_qaic_ctrl_init(void)
return ret;
mqc_dev_major = ret;
- mqc_dev_class = class_create(THIS_MODULE, MHI_QAIC_CTRL_DRIVER_NAME);
+ mqc_dev_class = class_create(MHI_QAIC_CTRL_DRIVER_NAME);
if (IS_ERR(mqc_dev_class)) {
ret = PTR_ERR(mqc_dev_class);
goto unregister_chrdev;
--
2.39.2
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply related [flat|nested] 181+ messages in thread
* Re: linux-next: build failure after merge of the driver-core tree
2023-03-27 9:15 ` Greg KH
@ 2023-03-27 15:09 ` Vasily Gorbik
0 siblings, 0 replies; 181+ messages in thread
From: Vasily Gorbik @ 2023-03-27 15:09 UTC (permalink / raw)
To: Greg KH
Cc: Stephen Rothwell, Heiko Carstens, Christian Borntraeger,
Harald Freudenberger, Linux Kernel Mailing List,
Linux Next Mailing List
On Mon, Mar 27, 2023 at 11:15:16AM +0200, Greg KH wrote:
> On Mon, Mar 27, 2023 at 07:22:15PM +1100, Stephen Rothwell wrote:
> > Hi All,
> >
> > On Mon, 27 Mar 2023 09:33:42 +0200 Greg KH <greg@kroah.com> wrote:
> > >
> > > Patch is correct, thank you.
> >
> > Thanks for checking.
> >
> > > s390 developers, if you have a persistent tag/branch, I can suck this
> > > into the driver core tree and apply this fixup there so that you don't
> > > have to deal with any merge issues for 6.4-rc1 if you want. Or I can
> > > provide one for you if you need/want that instead. Or we can just leave
> > > it alone and deal with it during the 6.4-rc1 merge window, your choice.
> >
> > Or (it being pretty trivial) you could both just let Linus know when
> > you send your merge requests ...
>
> True, that works for me!
Sounds good for s390 as well, thank you!
^ permalink raw reply [flat|nested] 181+ messages in thread
* Re: linux-next: build failure after merge of the driver-core tree
2023-03-27 8:22 ` Stephen Rothwell
@ 2023-03-27 9:15 ` Greg KH
2023-03-27 15:09 ` Vasily Gorbik
0 siblings, 1 reply; 181+ messages in thread
From: Greg KH @ 2023-03-27 9:15 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Heiko Carstens, Vasily Gorbik, Christian Borntraeger,
Harald Freudenberger, Linux Kernel Mailing List,
Linux Next Mailing List
On Mon, Mar 27, 2023 at 07:22:15PM +1100, Stephen Rothwell wrote:
> Hi All,
>
> On Mon, 27 Mar 2023 09:33:42 +0200 Greg KH <greg@kroah.com> wrote:
> >
> > Patch is correct, thank you.
>
> Thanks for checking.
>
> > s390 developers, if you have a persistent tag/branch, I can suck this
> > into the driver core tree and apply this fixup there so that you don't
> > have to deal with any merge issues for 6.4-rc1 if you want. Or I can
> > provide one for you if you need/want that instead. Or we can just leave
> > it alone and deal with it during the 6.4-rc1 merge window, your choice.
>
> Or (it being pretty trivial) you could both just let Linus know when
> you send your merge requests ...
True, that works for me!
^ permalink raw reply [flat|nested] 181+ messages in thread
* Re: linux-next: build failure after merge of the driver-core tree
2023-03-27 7:33 ` Greg KH
@ 2023-03-27 8:22 ` Stephen Rothwell
2023-03-27 9:15 ` Greg KH
0 siblings, 1 reply; 181+ messages in thread
From: Stephen Rothwell @ 2023-03-27 8:22 UTC (permalink / raw)
To: Greg KH
Cc: Heiko Carstens, Vasily Gorbik, Christian Borntraeger,
Harald Freudenberger, Linux Kernel Mailing List,
Linux Next Mailing List
[-- Attachment #1: Type: text/plain, Size: 651 bytes --]
Hi All,
On Mon, 27 Mar 2023 09:33:42 +0200 Greg KH <greg@kroah.com> wrote:
>
> Patch is correct, thank you.
Thanks for checking.
> s390 developers, if you have a persistent tag/branch, I can suck this
> into the driver core tree and apply this fixup there so that you don't
> have to deal with any merge issues for 6.4-rc1 if you want. Or I can
> provide one for you if you need/want that instead. Or we can just leave
> it alone and deal with it during the 6.4-rc1 merge window, your choice.
Or (it being pretty trivial) you could both just let Linus know when
you send your merge requests ...
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 181+ messages in thread
* Re: linux-next: build failure after merge of the driver-core tree
2023-03-27 4:46 Stephen Rothwell
@ 2023-03-27 7:33 ` Greg KH
2023-03-27 8:22 ` Stephen Rothwell
0 siblings, 1 reply; 181+ messages in thread
From: Greg KH @ 2023-03-27 7:33 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Heiko Carstens, Vasily Gorbik, Christian Borntraeger,
Harald Freudenberger, Linux Kernel Mailing List,
Linux Next Mailing List
On Mon, Mar 27, 2023 at 03:46:55PM +1100, Stephen Rothwell wrote:
> Hi all,
>
> After merging the driver-core tree, today's linux-next build
> (s390-defconfig) failed like this:
>
> drivers/s390/crypto/ap_bus.c:1596:20: error: initialization of 'ssize_t (*)(const struct bus_type *, char *)' {aka 'long int (*)(const struct bus_type *, char *)'} from incompatible pointer type 'ssize_t (*)(struct bus_type *, char *)' {aka 'long int (*)(struct bus_type *, char *)'} [-Werror=incompatible-pointer-types]
>
> (reported here: http://kisskb.ellerman.id.au/kisskb/buildresult/14902509/)
>
> Caused by commit
>
> 75cff725d956 ("driver core: bus: mark the struct bus_type for sysfs callbacks as constant")
>
> interacting with commit
>
> d7b1813af6a5 ("s390/ap: introduce new AP bus sysfs attribute features")
>
> from the s390 tree.
>
> I will apply the following (currently untested) merge fix up patch from
> tomorrow:
>
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Mon, 27 Mar 2023 15:42:41 +1100
> Subject: [PATCH] fixup for "driver core: bus: mark the struct bus_type for sysfs callbacks as constant"
>
> interacting with "s390/ap: introduce new AP bus sysfs attribute features"
>
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> ---
> drivers/s390/crypto/ap_bus.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/s390/crypto/ap_bus.c b/drivers/s390/crypto/ap_bus.c
> index 85bb0de15e76..8d6b9a52bf3c 100644
> --- a/drivers/s390/crypto/ap_bus.c
> +++ b/drivers/s390/crypto/ap_bus.c
> @@ -1570,7 +1570,7 @@ static ssize_t bindings_show(const struct bus_type *bus, char *buf)
>
> static BUS_ATTR_RO(bindings);
>
> -static ssize_t features_show(struct bus_type *bus, char *buf)
> +static ssize_t features_show(const struct bus_type *bus, char *buf)
Patch is correct, thank you.
s390 developers, if you have a persistent tag/branch, I can suck this
into the driver core tree and apply this fixup there so that you don't
have to deal with any merge issues for 6.4-rc1 if you want. Or I can
provide one for you if you need/want that instead. Or we can just leave
it alone and deal with it during the 6.4-rc1 merge window, your choice.
thanks,
greg k-h
^ permalink raw reply [flat|nested] 181+ messages in thread
* linux-next: build failure after merge of the driver-core tree
@ 2023-03-27 4:46 Stephen Rothwell
2023-03-27 7:33 ` Greg KH
0 siblings, 1 reply; 181+ messages in thread
From: Stephen Rothwell @ 2023-03-27 4:46 UTC (permalink / raw)
To: Greg KH, Heiko Carstens, Vasily Gorbik, Christian Borntraeger
Cc: Harald Freudenberger, Greg Kroah-Hartman,
Linux Kernel Mailing List, Linux Next Mailing List
[-- Attachment #1: Type: text/plain, Size: 1780 bytes --]
Hi all,
After merging the driver-core tree, today's linux-next build
(s390-defconfig) failed like this:
drivers/s390/crypto/ap_bus.c:1596:20: error: initialization of 'ssize_t (*)(const struct bus_type *, char *)' {aka 'long int (*)(const struct bus_type *, char *)'} from incompatible pointer type 'ssize_t (*)(struct bus_type *, char *)' {aka 'long int (*)(struct bus_type *, char *)'} [-Werror=incompatible-pointer-types]
(reported here: http://kisskb.ellerman.id.au/kisskb/buildresult/14902509/)
Caused by commit
75cff725d956 ("driver core: bus: mark the struct bus_type for sysfs callbacks as constant")
interacting with commit
d7b1813af6a5 ("s390/ap: introduce new AP bus sysfs attribute features")
from the s390 tree.
I will apply the following (currently untested) merge fix up patch from
tomorrow:
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Mon, 27 Mar 2023 15:42:41 +1100
Subject: [PATCH] fixup for "driver core: bus: mark the struct bus_type for sysfs callbacks as constant"
interacting with "s390/ap: introduce new AP bus sysfs attribute features"
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
drivers/s390/crypto/ap_bus.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/s390/crypto/ap_bus.c b/drivers/s390/crypto/ap_bus.c
index 85bb0de15e76..8d6b9a52bf3c 100644
--- a/drivers/s390/crypto/ap_bus.c
+++ b/drivers/s390/crypto/ap_bus.c
@@ -1570,7 +1570,7 @@ static ssize_t bindings_show(const struct bus_type *bus, char *buf)
static BUS_ATTR_RO(bindings);
-static ssize_t features_show(struct bus_type *bus, char *buf)
+static ssize_t features_show(const struct bus_type *bus, char *buf)
{
int n = 0;
--
2.39.2
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply related [flat|nested] 181+ messages in thread
* Re: linux-next: build failure after merge of the driver-core tree
2023-01-30 16:01 ` Greg KH
@ 2023-01-30 16:23 ` Geert Uytterhoeven
0 siblings, 0 replies; 181+ messages in thread
From: Geert Uytterhoeven @ 2023-01-30 16:23 UTC (permalink / raw)
To: Greg KH
Cc: Stephen Rothwell, Linux Kernel Mailing List, Linux Next Mailing List
Hi Greg,
On Mon, Jan 30, 2023 at 5:08 PM Greg KH <greg@kroah.com> wrote:
> On Mon, Jan 30, 2023 at 03:28:18PM +1100, Stephen Rothwell wrote:
> > After merging the driver-core tree, today's linux-next build (powerpc
> > ppc64_defconfig) failed like this:
> >
> > arch/powerpc/platforms/ps3/system-bus.c:472:19: error: initialization of 'int (*)(const struct device *, struct kobj_uevent_env *)' from incompatible pointer type 'int (*)(struct device *, struct kobj_uevent_env *)' [-Werror=incompatible-pointer-types]
> > 472 | .uevent = ps3_system_bus_uevent,
> > | ^~~~~~~~~~~~~~~~~~~~~
> > arch/powerpc/platforms/ps3/system-bus.c:472:19: note: (near initialization for 'ps3_system_bus_type.uevent')
> > arch/powerpc/platforms/pseries/ibmebus.c:436:22: error: initialization of 'int (*)(const struct device *, struct kobj_uevent_env *)' from incompatible pointer type 'int (*)(struct device *, struct kobj_uevent_env *)' [-Werror=incompatible-pointer-types]
> > 436 | .uevent = ibmebus_bus_modalias,
> > | ^~~~~~~~~~~~~~~~~~~~
> > arch/powerpc/platforms/pseries/ibmebus.c:436:22: note: (near initialization for 'ibmebus_bus_type.uevent')
> >
> > Caused by commit
> >
> > 2a81ada32f0e ("driver core: make struct bus_type.uevent() take a const *")
>
> Ick, 0-day didn't catch this, which is odd, it must not build those
> arches :(
It does, but the bot seems to have some issues, as I didn't receive
any reports for a few days.
Last report of a ps3_defconfig build is 5 days old...
etje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply [flat|nested] 181+ messages in thread
* Re: linux-next: build failure after merge of the driver-core tree
2023-01-30 4:28 Stephen Rothwell
@ 2023-01-30 16:01 ` Greg KH
2023-01-30 16:23 ` Geert Uytterhoeven
0 siblings, 1 reply; 181+ messages in thread
From: Greg KH @ 2023-01-30 16:01 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: Linux Kernel Mailing List, Linux Next Mailing List
On Mon, Jan 30, 2023 at 03:28:18PM +1100, Stephen Rothwell wrote:
> Hi all,
>
> After merging the driver-core tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
>
> arch/powerpc/platforms/ps3/system-bus.c:472:19: error: initialization of 'int (*)(const struct device *, struct kobj_uevent_env *)' from incompatible pointer type 'int (*)(struct device *, struct kobj_uevent_env *)' [-Werror=incompatible-pointer-types]
> 472 | .uevent = ps3_system_bus_uevent,
> | ^~~~~~~~~~~~~~~~~~~~~
> arch/powerpc/platforms/ps3/system-bus.c:472:19: note: (near initialization for 'ps3_system_bus_type.uevent')
> arch/powerpc/platforms/pseries/ibmebus.c:436:22: error: initialization of 'int (*)(const struct device *, struct kobj_uevent_env *)' from incompatible pointer type 'int (*)(struct device *, struct kobj_uevent_env *)' [-Werror=incompatible-pointer-types]
> 436 | .uevent = ibmebus_bus_modalias,
> | ^~~~~~~~~~~~~~~~~~~~
> arch/powerpc/platforms/pseries/ibmebus.c:436:22: note: (near initialization for 'ibmebus_bus_type.uevent')
>
> Caused by commit
>
> 2a81ada32f0e ("driver core: make struct bus_type.uevent() take a const *")
>
> I have applied the following merge fix patch.
>
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Mon, 30 Jan 2023 14:31:49 +1100
> Subject: [PATCH] driver core: fixup for "driver core: make struct bus_type.uevent() take a const *"
>
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> ---
> arch/powerpc/include/asm/ps3.h | 2 +-
> arch/powerpc/platforms/ps3/system-bus.c | 2 +-
> arch/powerpc/platforms/pseries/ibmebus.c | 2 +-
> 3 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/arch/powerpc/include/asm/ps3.h b/arch/powerpc/include/asm/ps3.h
> index d503dbd7856c..a5f36546a052 100644
> --- a/arch/powerpc/include/asm/ps3.h
> +++ b/arch/powerpc/include/asm/ps3.h
> @@ -396,7 +396,7 @@ static inline struct ps3_system_bus_driver *ps3_drv_to_system_bus_drv(
> return container_of(_drv, struct ps3_system_bus_driver, core);
> }
> static inline struct ps3_system_bus_device *ps3_dev_to_system_bus_dev(
> - struct device *_dev)
> + const struct device *_dev)
> {
> return container_of(_dev, struct ps3_system_bus_device, core);
> }
> diff --git a/arch/powerpc/platforms/ps3/system-bus.c b/arch/powerpc/platforms/ps3/system-bus.c
> index 38a7e02295c8..d6b5f5ecd515 100644
> --- a/arch/powerpc/platforms/ps3/system-bus.c
> +++ b/arch/powerpc/platforms/ps3/system-bus.c
> @@ -439,7 +439,7 @@ static void ps3_system_bus_shutdown(struct device *_dev)
> dev_dbg(&dev->core, " <- %s:%d\n", __func__, __LINE__);
> }
>
> -static int ps3_system_bus_uevent(struct device *_dev, struct kobj_uevent_env *env)
> +static int ps3_system_bus_uevent(const struct device *_dev, struct kobj_uevent_env *env)
> {
> struct ps3_system_bus_device *dev = ps3_dev_to_system_bus_dev(_dev);
>
> diff --git a/arch/powerpc/platforms/pseries/ibmebus.c b/arch/powerpc/platforms/pseries/ibmebus.c
> index 58b798a0e879..bb9c18682783 100644
> --- a/arch/powerpc/platforms/pseries/ibmebus.c
> +++ b/arch/powerpc/platforms/pseries/ibmebus.c
> @@ -426,7 +426,7 @@ static struct attribute *ibmebus_bus_device_attrs[] = {
> };
> ATTRIBUTE_GROUPS(ibmebus_bus_device);
>
> -static int ibmebus_bus_modalias(struct device *dev, struct kobj_uevent_env *env)
> +static int ibmebus_bus_modalias(const struct device *dev, struct kobj_uevent_env *env)
> {
> return of_device_uevent_modalias(dev, env);
> }
> --
> 2.35.1
>
Ick, 0-day didn't catch this, which is odd, it must not build those
arches :(
I'll go queue this up now, thanks for the fix!
greg k-h
^ permalink raw reply [flat|nested] 181+ messages in thread
* linux-next: build failure after merge of the driver-core tree
@ 2023-01-30 4:28 Stephen Rothwell
2023-01-30 16:01 ` Greg KH
0 siblings, 1 reply; 181+ messages in thread
From: Stephen Rothwell @ 2023-01-30 4:28 UTC (permalink / raw)
To: Greg KH; +Cc: Linux Kernel Mailing List, Linux Next Mailing List
[-- Attachment #1: Type: text/plain, Size: 3475 bytes --]
Hi all,
After merging the driver-core tree, today's linux-next build (powerpc
ppc64_defconfig) failed like this:
arch/powerpc/platforms/ps3/system-bus.c:472:19: error: initialization of 'int (*)(const struct device *, struct kobj_uevent_env *)' from incompatible pointer type 'int (*)(struct device *, struct kobj_uevent_env *)' [-Werror=incompatible-pointer-types]
472 | .uevent = ps3_system_bus_uevent,
| ^~~~~~~~~~~~~~~~~~~~~
arch/powerpc/platforms/ps3/system-bus.c:472:19: note: (near initialization for 'ps3_system_bus_type.uevent')
arch/powerpc/platforms/pseries/ibmebus.c:436:22: error: initialization of 'int (*)(const struct device *, struct kobj_uevent_env *)' from incompatible pointer type 'int (*)(struct device *, struct kobj_uevent_env *)' [-Werror=incompatible-pointer-types]
436 | .uevent = ibmebus_bus_modalias,
| ^~~~~~~~~~~~~~~~~~~~
arch/powerpc/platforms/pseries/ibmebus.c:436:22: note: (near initialization for 'ibmebus_bus_type.uevent')
Caused by commit
2a81ada32f0e ("driver core: make struct bus_type.uevent() take a const *")
I have applied the following merge fix patch.
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Mon, 30 Jan 2023 14:31:49 +1100
Subject: [PATCH] driver core: fixup for "driver core: make struct bus_type.uevent() take a const *"
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
arch/powerpc/include/asm/ps3.h | 2 +-
arch/powerpc/platforms/ps3/system-bus.c | 2 +-
arch/powerpc/platforms/pseries/ibmebus.c | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/include/asm/ps3.h b/arch/powerpc/include/asm/ps3.h
index d503dbd7856c..a5f36546a052 100644
--- a/arch/powerpc/include/asm/ps3.h
+++ b/arch/powerpc/include/asm/ps3.h
@@ -396,7 +396,7 @@ static inline struct ps3_system_bus_driver *ps3_drv_to_system_bus_drv(
return container_of(_drv, struct ps3_system_bus_driver, core);
}
static inline struct ps3_system_bus_device *ps3_dev_to_system_bus_dev(
- struct device *_dev)
+ const struct device *_dev)
{
return container_of(_dev, struct ps3_system_bus_device, core);
}
diff --git a/arch/powerpc/platforms/ps3/system-bus.c b/arch/powerpc/platforms/ps3/system-bus.c
index 38a7e02295c8..d6b5f5ecd515 100644
--- a/arch/powerpc/platforms/ps3/system-bus.c
+++ b/arch/powerpc/platforms/ps3/system-bus.c
@@ -439,7 +439,7 @@ static void ps3_system_bus_shutdown(struct device *_dev)
dev_dbg(&dev->core, " <- %s:%d\n", __func__, __LINE__);
}
-static int ps3_system_bus_uevent(struct device *_dev, struct kobj_uevent_env *env)
+static int ps3_system_bus_uevent(const struct device *_dev, struct kobj_uevent_env *env)
{
struct ps3_system_bus_device *dev = ps3_dev_to_system_bus_dev(_dev);
diff --git a/arch/powerpc/platforms/pseries/ibmebus.c b/arch/powerpc/platforms/pseries/ibmebus.c
index 58b798a0e879..bb9c18682783 100644
--- a/arch/powerpc/platforms/pseries/ibmebus.c
+++ b/arch/powerpc/platforms/pseries/ibmebus.c
@@ -426,7 +426,7 @@ static struct attribute *ibmebus_bus_device_attrs[] = {
};
ATTRIBUTE_GROUPS(ibmebus_bus_device);
-static int ibmebus_bus_modalias(struct device *dev, struct kobj_uevent_env *env)
+static int ibmebus_bus_modalias(const struct device *dev, struct kobj_uevent_env *env)
{
return of_device_uevent_modalias(dev, env);
}
--
2.35.1
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply related [flat|nested] 181+ messages in thread
* linux-next: build failure after merge of the driver-core tree
@ 2022-12-01 2:18 Stephen Rothwell
0 siblings, 0 replies; 181+ messages in thread
From: Stephen Rothwell @ 2022-12-01 2:18 UTC (permalink / raw)
To: Greg KH, Dave Airlie
Cc: DRI, Oded Gabbay, Linux Kernel Mailing List, Linux Next Mailing List
[-- Attachment #1: Type: text/plain, Size: 1764 bytes --]
Hi all,
After merging the driver-core tree, today's linux-next build (x86_64
allmodconfig) failed like this:
drivers/gpu/drm/../../accel/drm_accel.c: In function 'accel_sysfs_init':
drivers/gpu/drm/../../accel/drm_accel.c:41:30: error: assignment to 'char * (*)(const struct device *, umode_t *)' {aka 'char * (*)(const struct device *, short unsigned int *)'} from incompatible pointer type 'char * (*)(struct device *, umode_t *)' {aka 'char * (*)(struct device *, short unsigned int *)'} [-Werror=incompatible-pointer-types]
41 | accel_class->devnode = accel_devnode;
| ^
Caused by commit
ff62b8e6588f ("driver core: make struct class.devnode() take a const *")
interacting with commit
8bf4889762a8 ("drivers/accel: define kconfig and register a new major")
from the drm tree.
I have applied the following merge resolution patch.
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Thu, 1 Dec 2022 13:08:06 +1100
Subject: [PATCH] fix up for "drivers/accel: define kconfig and register a new major"
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
drivers/accel/drm_accel.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/accel/drm_accel.c b/drivers/accel/drm_accel.c
index a5ee84a4017a..1b69824286fd 100644
--- a/drivers/accel/drm_accel.c
+++ b/drivers/accel/drm_accel.c
@@ -27,7 +27,7 @@ static struct device_type accel_sysfs_device_minor = {
.name = "accel_minor"
};
-static char *accel_devnode(struct device *dev, umode_t *mode)
+static char *accel_devnode(const struct device *dev, umode_t *mode)
{
return kasprintf(GFP_KERNEL, "accel/%s", dev_name(dev));
}
--
2.35.1
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply related [flat|nested] 181+ messages in thread
* Re: linux-next: build failure after merge of the driver-core tree
2022-11-30 1:38 Stephen Rothwell
@ 2022-11-30 12:01 ` Greg KH
0 siblings, 0 replies; 181+ messages in thread
From: Greg KH @ 2022-11-30 12:01 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: Linux Kernel Mailing List, Linux Next Mailing List
On Wed, Nov 30, 2022 at 12:38:51PM +1100, Stephen Rothwell wrote:
> Hi all,
>
> After merging the driver-core tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
>
> drivers/scsi/cxlflash/main.c: In function 'cxlflash_class_init':
> drivers/scsi/cxlflash/main.c:3890:33: error: assignment to 'char * (*)(const struct device *, umode_t *)' {aka 'char * (*)(const struct device *, short unsigned int *)'} from incompatible pointer type 'char * (*)(struct device *, umode_t *)' {aka 'char * (*)(struct device *, short unsigned int *)'} [-Werror=incompatible-pointer-types]
> 3890 | cxlflash_class->devnode = cxlflash_devnode;
> | ^
>
> Caused by commit
>
> ff62b8e6588f ("driver core: make struct class.devnode() take a const *")
>
> I have applied the following patch for today (please add it to your tree).
>
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Wed, 30 Nov 2022 12:13:00 +1100
> Subject: [PATCH] driver core: fix up missed scsi/cxlflash class.devnode() conversion.
>
> Fixes: ff62b8e6588f ("driver core: make struct class.devnode() take a const *")
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> ---
> drivers/scsi/cxlflash/main.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/scsi/cxlflash/main.c b/drivers/scsi/cxlflash/main.c
> index cd1324ec742d..395b00b942f7 100644
> --- a/drivers/scsi/cxlflash/main.c
> +++ b/drivers/scsi/cxlflash/main.c
> @@ -3857,7 +3857,7 @@ static void cxlflash_pci_resume(struct pci_dev *pdev)
> *
> * Return: Allocated string describing the devtmpfs structure.
> */
> -static char *cxlflash_devnode(struct device *dev, umode_t *mode)
> +static char *cxlflash_devnode(const struct device *dev, umode_t *mode)
> {
> return kasprintf(GFP_KERNEL, "cxlflash/%s", dev_name(dev));
> }
> --
> 2.35.1
>
> I also added the following (found using
> git grep '(struct device\s*\*[^,]*,\s*umode_t[^,]*)'
> - please also add this):
>
Both now queued up, thanks.
greg k-h
^ permalink raw reply [flat|nested] 181+ messages in thread
* linux-next: build failure after merge of the driver-core tree
@ 2022-11-30 1:38 Stephen Rothwell
2022-11-30 12:01 ` Greg KH
0 siblings, 1 reply; 181+ messages in thread
From: Stephen Rothwell @ 2022-11-30 1:38 UTC (permalink / raw)
To: Greg KH; +Cc: Linux Kernel Mailing List, Linux Next Mailing List
[-- Attachment #1: Type: text/plain, Size: 2941 bytes --]
Hi all,
After merging the driver-core tree, today's linux-next build (powerpc
ppc64_defconfig) failed like this:
drivers/scsi/cxlflash/main.c: In function 'cxlflash_class_init':
drivers/scsi/cxlflash/main.c:3890:33: error: assignment to 'char * (*)(const struct device *, umode_t *)' {aka 'char * (*)(const struct device *, short unsigned int *)'} from incompatible pointer type 'char * (*)(struct device *, umode_t *)' {aka 'char * (*)(struct device *, short unsigned int *)'} [-Werror=incompatible-pointer-types]
3890 | cxlflash_class->devnode = cxlflash_devnode;
| ^
Caused by commit
ff62b8e6588f ("driver core: make struct class.devnode() take a const *")
I have applied the following patch for today (please add it to your tree).
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Wed, 30 Nov 2022 12:13:00 +1100
Subject: [PATCH] driver core: fix up missed scsi/cxlflash class.devnode() conversion.
Fixes: ff62b8e6588f ("driver core: make struct class.devnode() take a const *")
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
drivers/scsi/cxlflash/main.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/scsi/cxlflash/main.c b/drivers/scsi/cxlflash/main.c
index cd1324ec742d..395b00b942f7 100644
--- a/drivers/scsi/cxlflash/main.c
+++ b/drivers/scsi/cxlflash/main.c
@@ -3857,7 +3857,7 @@ static void cxlflash_pci_resume(struct pci_dev *pdev)
*
* Return: Allocated string describing the devtmpfs structure.
*/
-static char *cxlflash_devnode(struct device *dev, umode_t *mode)
+static char *cxlflash_devnode(const struct device *dev, umode_t *mode)
{
return kasprintf(GFP_KERNEL, "cxlflash/%s", dev_name(dev));
}
--
2.35.1
I also added the following (found using
git grep '(struct device\s*\*[^,]*,\s*umode_t[^,]*)'
- please also add this):
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Wed, 30 Nov 2022 12:32:57 +1100
Subject: [PATCH] driver core: fix up missed drivers/s390/char/hmcdrv_dev.c class.devnode() conversion.
Fixes: ff62b8e6588f ("driver core: make struct class.devnode() take a const *")
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
drivers/s390/char/hmcdrv_dev.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/s390/char/hmcdrv_dev.c b/drivers/s390/char/hmcdrv_dev.c
index 20e9cd542e03..cb8fdf057eca 100644
--- a/drivers/s390/char/hmcdrv_dev.c
+++ b/drivers/s390/char/hmcdrv_dev.c
@@ -90,7 +90,7 @@ static dev_t hmcdrv_dev_no; /* device number (major/minor) */
*
* Return: recommended device file name in /dev
*/
-static char *hmcdrv_dev_name(struct device *dev, umode_t *mode)
+static char *hmcdrv_dev_name(const struct device *dev, umode_t *mode)
{
char *nodename = NULL;
const char *devname = dev_name(dev); /* kernel device name */
--
2.35.1
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply related [flat|nested] 181+ messages in thread
* Re: linux-next: build failure after merge of the driver-core tree
2022-11-28 19:46 ` Stephen Rothwell
@ 2022-11-29 8:28 ` Greg KH
0 siblings, 0 replies; 181+ messages in thread
From: Greg KH @ 2022-11-29 8:28 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: Linux Kernel Mailing List, Linux Next Mailing List
On Tue, Nov 29, 2022 at 06:46:05AM +1100, Stephen Rothwell wrote:
> Hi Greg,
>
> On Mon, 28 Nov 2022 17:22:52 +0100 Greg KH <greg@kroah.com> wrote:
> >
> > Odd, why is 0-day not triggering on any of these in my tree? Anyway,
> > I'll go fix it up, thanks...
>
> Does 0-day do powerpc builds?
I thought it did, based on other problems I have had reported. I'll go
queue this fix up now.
thanks,
greg k-h
^ permalink raw reply [flat|nested] 181+ messages in thread
* Re: linux-next: build failure after merge of the driver-core tree
2022-11-28 16:22 ` Greg KH
@ 2022-11-28 19:46 ` Stephen Rothwell
2022-11-29 8:28 ` Greg KH
0 siblings, 1 reply; 181+ messages in thread
From: Stephen Rothwell @ 2022-11-28 19:46 UTC (permalink / raw)
To: Greg KH; +Cc: Linux Kernel Mailing List, Linux Next Mailing List
[-- Attachment #1: Type: text/plain, Size: 256 bytes --]
Hi Greg,
On Mon, 28 Nov 2022 17:22:52 +0100 Greg KH <greg@kroah.com> wrote:
>
> Odd, why is 0-day not triggering on any of these in my tree? Anyway,
> I'll go fix it up, thanks...
Does 0-day do powerpc builds?
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 181+ messages in thread
* Re: linux-next: build failure after merge of the driver-core tree
2022-11-28 12:44 ` Stephen Rothwell
2022-11-28 16:22 ` Greg KH
@ 2022-11-28 17:35 ` Greg KH
1 sibling, 0 replies; 181+ messages in thread
From: Greg KH @ 2022-11-28 17:35 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: Linux Kernel Mailing List, Linux Next Mailing List
On Mon, Nov 28, 2022 at 11:44:08PM +1100, Stephen Rothwell wrote:
> Hi Greg,
>
> On Mon, 28 Nov 2022 12:50:03 +0100 Greg KH <greg@kroah.com> wrote:
> >
> > On Mon, Nov 28, 2022 at 01:36:00PM +1100, Stephen Rothwell wrote:
> > >
> > > After merging the driver-core tree, today's linux-next build (powerpc
> > > ppc64_defconfig) failed like this:
> > >
> > > arch/powerpc/platforms/book3s/vas-api.c: In function 'vas_register_coproc_api':
> > > arch/powerpc/platforms/book3s/vas-api.c:590:38: error: assignment to 'char * (*)(const struct device *, umode_t *)' {aka 'char * (*)(const struct device *, short unsigned int *)'} from incompatible pointer type 'char * (*)(struct device *, umode_t *)' {aka 'char * (*)(struct device *, short unsigned int *)'} [-Werror=incompatible-pointer-types]
> > > 590 | coproc_device.class->devnode = coproc_devnode;
> > > | ^
> > > drivers/misc/cxl/file.c: In function 'cxl_file_init':
> > > drivers/misc/cxl/file.c:687:28: error: assignment to 'char * (*)(const struct device *, umode_t *)' {aka 'char * (*)(const struct device *, short unsigned int *)'} from incompatible pointer type 'char * (*)(struct device *, umode_t *)' {aka 'char * (*)(struct device *, short unsigned int *)'} [-Werror=incompatible-pointer-types]
> > > 687 | cxl_class->devnode = cxl_devnode;
> > > | ^
> > >
> > > Caused by commit
> > >
> > > ff62b8e6588f ("driver core: make struct class.devnode() take a const *")
> > >
> > > I have used the driver-core tree from next-20221125 for today.
> >
> > Hm, how do we resolve problems like this where an api changes in my
> > branch but needs to be updated in another branch that is not in Linus's
> > tree yet?
>
> That is not the case here:
>
> $ git show ff62b8e6588f:arch/powerpc/platforms/book3s/vas-api.c | grep coproc_devnode
> static char *coproc_devnode(struct device *dev, umode_t *mode)
> coproc_device.class->devnode = coproc_devnode;
> $ git show ff62b8e6588f:drivers/misc/cxl/file.c | grep cxl_devnode
> static char *cxl_devnode(struct device *dev, umode_t *mode)
> cxl_class->devnode = cxl_devnode;
>
> You just need to add a commit to your tree that updates the missed cases.
Ok, patch sent out, let's see if 0-day objects...
thanks,
greg k-h
^ permalink raw reply [flat|nested] 181+ messages in thread
* Re: linux-next: build failure after merge of the driver-core tree
2022-11-28 12:44 ` Stephen Rothwell
@ 2022-11-28 16:22 ` Greg KH
2022-11-28 19:46 ` Stephen Rothwell
2022-11-28 17:35 ` Greg KH
1 sibling, 1 reply; 181+ messages in thread
From: Greg KH @ 2022-11-28 16:22 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: Linux Kernel Mailing List, Linux Next Mailing List
On Mon, Nov 28, 2022 at 11:44:08PM +1100, Stephen Rothwell wrote:
> Hi Greg,
>
> On Mon, 28 Nov 2022 12:50:03 +0100 Greg KH <greg@kroah.com> wrote:
> >
> > On Mon, Nov 28, 2022 at 01:36:00PM +1100, Stephen Rothwell wrote:
> > >
> > > After merging the driver-core tree, today's linux-next build (powerpc
> > > ppc64_defconfig) failed like this:
> > >
> > > arch/powerpc/platforms/book3s/vas-api.c: In function 'vas_register_coproc_api':
> > > arch/powerpc/platforms/book3s/vas-api.c:590:38: error: assignment to 'char * (*)(const struct device *, umode_t *)' {aka 'char * (*)(const struct device *, short unsigned int *)'} from incompatible pointer type 'char * (*)(struct device *, umode_t *)' {aka 'char * (*)(struct device *, short unsigned int *)'} [-Werror=incompatible-pointer-types]
> > > 590 | coproc_device.class->devnode = coproc_devnode;
> > > | ^
> > > drivers/misc/cxl/file.c: In function 'cxl_file_init':
> > > drivers/misc/cxl/file.c:687:28: error: assignment to 'char * (*)(const struct device *, umode_t *)' {aka 'char * (*)(const struct device *, short unsigned int *)'} from incompatible pointer type 'char * (*)(struct device *, umode_t *)' {aka 'char * (*)(struct device *, short unsigned int *)'} [-Werror=incompatible-pointer-types]
> > > 687 | cxl_class->devnode = cxl_devnode;
> > > | ^
> > >
> > > Caused by commit
> > >
> > > ff62b8e6588f ("driver core: make struct class.devnode() take a const *")
> > >
> > > I have used the driver-core tree from next-20221125 for today.
> >
> > Hm, how do we resolve problems like this where an api changes in my
> > branch but needs to be updated in another branch that is not in Linus's
> > tree yet?
>
> That is not the case here:
>
> $ git show ff62b8e6588f:arch/powerpc/platforms/book3s/vas-api.c | grep coproc_devnode
> static char *coproc_devnode(struct device *dev, umode_t *mode)
> coproc_device.class->devnode = coproc_devnode;
> $ git show ff62b8e6588f:drivers/misc/cxl/file.c | grep cxl_devnode
> static char *cxl_devnode(struct device *dev, umode_t *mode)
> cxl_class->devnode = cxl_devnode;
>
> You just need to add a commit to your tree that updates the missed cases.
Odd, why is 0-day not triggering on any of these in my tree? Anyway,
I'll go fix it up, thanks...
greg k-h
^ permalink raw reply [flat|nested] 181+ messages in thread
* Re: linux-next: build failure after merge of the driver-core tree
2022-11-28 11:50 ` Greg KH
@ 2022-11-28 12:44 ` Stephen Rothwell
2022-11-28 16:22 ` Greg KH
2022-11-28 17:35 ` Greg KH
0 siblings, 2 replies; 181+ messages in thread
From: Stephen Rothwell @ 2022-11-28 12:44 UTC (permalink / raw)
To: Greg KH; +Cc: Linux Kernel Mailing List, Linux Next Mailing List
[-- Attachment #1: Type: text/plain, Size: 2187 bytes --]
Hi Greg,
On Mon, 28 Nov 2022 12:50:03 +0100 Greg KH <greg@kroah.com> wrote:
>
> On Mon, Nov 28, 2022 at 01:36:00PM +1100, Stephen Rothwell wrote:
> >
> > After merging the driver-core tree, today's linux-next build (powerpc
> > ppc64_defconfig) failed like this:
> >
> > arch/powerpc/platforms/book3s/vas-api.c: In function 'vas_register_coproc_api':
> > arch/powerpc/platforms/book3s/vas-api.c:590:38: error: assignment to 'char * (*)(const struct device *, umode_t *)' {aka 'char * (*)(const struct device *, short unsigned int *)'} from incompatible pointer type 'char * (*)(struct device *, umode_t *)' {aka 'char * (*)(struct device *, short unsigned int *)'} [-Werror=incompatible-pointer-types]
> > 590 | coproc_device.class->devnode = coproc_devnode;
> > | ^
> > drivers/misc/cxl/file.c: In function 'cxl_file_init':
> > drivers/misc/cxl/file.c:687:28: error: assignment to 'char * (*)(const struct device *, umode_t *)' {aka 'char * (*)(const struct device *, short unsigned int *)'} from incompatible pointer type 'char * (*)(struct device *, umode_t *)' {aka 'char * (*)(struct device *, short unsigned int *)'} [-Werror=incompatible-pointer-types]
> > 687 | cxl_class->devnode = cxl_devnode;
> > | ^
> >
> > Caused by commit
> >
> > ff62b8e6588f ("driver core: make struct class.devnode() take a const *")
> >
> > I have used the driver-core tree from next-20221125 for today.
>
> Hm, how do we resolve problems like this where an api changes in my
> branch but needs to be updated in another branch that is not in Linus's
> tree yet?
That is not the case here:
$ git show ff62b8e6588f:arch/powerpc/platforms/book3s/vas-api.c | grep coproc_devnode
static char *coproc_devnode(struct device *dev, umode_t *mode)
coproc_device.class->devnode = coproc_devnode;
$ git show ff62b8e6588f:drivers/misc/cxl/file.c | grep cxl_devnode
static char *cxl_devnode(struct device *dev, umode_t *mode)
cxl_class->devnode = cxl_devnode;
You just need to add a commit to your tree that updates the missed cases.
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 181+ messages in thread
* Re: linux-next: build failure after merge of the driver-core tree
2022-11-28 2:36 Stephen Rothwell
@ 2022-11-28 11:50 ` Greg KH
2022-11-28 12:44 ` Stephen Rothwell
0 siblings, 1 reply; 181+ messages in thread
From: Greg KH @ 2022-11-28 11:50 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: Linux Kernel Mailing List, Linux Next Mailing List
On Mon, Nov 28, 2022 at 01:36:00PM +1100, Stephen Rothwell wrote:
> Hi all,
>
> After merging the driver-core tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
>
> arch/powerpc/platforms/book3s/vas-api.c: In function 'vas_register_coproc_api':
> arch/powerpc/platforms/book3s/vas-api.c:590:38: error: assignment to 'char * (*)(const struct device *, umode_t *)' {aka 'char * (*)(const struct device *, short unsigned int *)'} from incompatible pointer type 'char * (*)(struct device *, umode_t *)' {aka 'char * (*)(struct device *, short unsigned int *)'} [-Werror=incompatible-pointer-types]
> 590 | coproc_device.class->devnode = coproc_devnode;
> | ^
> drivers/misc/cxl/file.c: In function 'cxl_file_init':
> drivers/misc/cxl/file.c:687:28: error: assignment to 'char * (*)(const struct device *, umode_t *)' {aka 'char * (*)(const struct device *, short unsigned int *)'} from incompatible pointer type 'char * (*)(struct device *, umode_t *)' {aka 'char * (*)(struct device *, short unsigned int *)'} [-Werror=incompatible-pointer-types]
> 687 | cxl_class->devnode = cxl_devnode;
> | ^
>
> Caused by commit
>
> ff62b8e6588f ("driver core: make struct class.devnode() take a const *")
>
> I have used the driver-core tree from next-20221125 for today.
Hm, how do we resolve problems like this where an api changes in my
branch but needs to be updated in another branch that is not in Linus's
tree yet?
Want me to make a patch for this for you to apply after the driver-core
merge?
thanks,
greg k-h
^ permalink raw reply [flat|nested] 181+ messages in thread
* linux-next: build failure after merge of the driver-core tree
@ 2022-11-28 2:36 Stephen Rothwell
2022-11-28 11:50 ` Greg KH
0 siblings, 1 reply; 181+ messages in thread
From: Stephen Rothwell @ 2022-11-28 2:36 UTC (permalink / raw)
To: Greg KH; +Cc: Linux Kernel Mailing List, Linux Next Mailing List
[-- Attachment #1: Type: text/plain, Size: 1339 bytes --]
Hi all,
After merging the driver-core tree, today's linux-next build (powerpc
ppc64_defconfig) failed like this:
arch/powerpc/platforms/book3s/vas-api.c: In function 'vas_register_coproc_api':
arch/powerpc/platforms/book3s/vas-api.c:590:38: error: assignment to 'char * (*)(const struct device *, umode_t *)' {aka 'char * (*)(const struct device *, short unsigned int *)'} from incompatible pointer type 'char * (*)(struct device *, umode_t *)' {aka 'char * (*)(struct device *, short unsigned int *)'} [-Werror=incompatible-pointer-types]
590 | coproc_device.class->devnode = coproc_devnode;
| ^
drivers/misc/cxl/file.c: In function 'cxl_file_init':
drivers/misc/cxl/file.c:687:28: error: assignment to 'char * (*)(const struct device *, umode_t *)' {aka 'char * (*)(const struct device *, short unsigned int *)'} from incompatible pointer type 'char * (*)(struct device *, umode_t *)' {aka 'char * (*)(struct device *, short unsigned int *)'} [-Werror=incompatible-pointer-types]
687 | cxl_class->devnode = cxl_devnode;
| ^
Caused by commit
ff62b8e6588f ("driver core: make struct class.devnode() take a const *")
I have used the driver-core tree from next-20221125 for today.
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 181+ messages in thread
* Re: linux-next: build failure after merge of the driver-core tree
2022-11-14 8:46 ` Andy Shevchenko
@ 2022-11-14 8:59 ` Greg KH
0 siblings, 0 replies; 181+ messages in thread
From: Greg KH @ 2022-11-14 8:59 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Stephen Rothwell, Linux Kernel Mailing List, Linux Next Mailing List
On Mon, Nov 14, 2022 at 10:46:02AM +0200, Andy Shevchenko wrote:
> On Mon, Nov 14, 2022 at 03:12:35PM +1100, Stephen Rothwell wrote:
> > Hi all,
> >
> > After merging the driver-core tree, today's linux-next build (arm
> > multi_v7_defconfig) failed like this:
> >
> > drivers/mfd/vexpress-sysreg.c:64:51: error: initializer element is not constant
> > 64 | .resources = (struct resource []) {
> > | ^
> > drivers/mfd/vexpress-sysreg.c:64:51: note: (near initialization for 'vexpress_sysreg_cells[0]')
> > drivers/mfd/vexpress-sysreg.c:73:51: error: initializer element is not constant
> > 73 | .resources = (struct resource []) {
> > | ^
> > drivers/mfd/vexpress-sysreg.c:73:51: note: (near initialization for 'vexpress_sysreg_cells[1]')
> > drivers/mfd/vexpress-sysreg.c:82:51: error: initializer element is not constant
> > 82 | .resources = (struct resource []) {
> > | ^
> > drivers/mfd/vexpress-sysreg.c:82:51: note: (near initialization for 'vexpress_sysreg_cells[2]')
> > drivers/mfd/vexpress-sysreg.c:90:51: error: initializer element is not constant
> > 90 | .resources = (struct resource []) {
> > | ^
> > drivers/mfd/vexpress-sysreg.c:90:51: note: (near initialization for 'vexpress_sysreg_cells[3]')
> >
> > Caused (probably) by commit
> >
> > 52c4d11f1dce ("resource: Convert DEFINE_RES_NAMED() to be compound literal")
> >
> > I have used the driver-core tree from next-20221111 for today.
>
> Fix is available here:
> https://lore.kernel.org/lkml/20221113191027.2327-1-andriy.shevchenko@linux.intel.com/
Thanks, I'll pick that up now.
greg k-h
^ permalink raw reply [flat|nested] 181+ messages in thread
* Re: linux-next: build failure after merge of the driver-core tree
2022-11-14 4:12 Stephen Rothwell
@ 2022-11-14 8:46 ` Andy Shevchenko
2022-11-14 8:59 ` Greg KH
0 siblings, 1 reply; 181+ messages in thread
From: Andy Shevchenko @ 2022-11-14 8:46 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Greg KH, Linux Kernel Mailing List, Linux Next Mailing List
On Mon, Nov 14, 2022 at 03:12:35PM +1100, Stephen Rothwell wrote:
> Hi all,
>
> After merging the driver-core tree, today's linux-next build (arm
> multi_v7_defconfig) failed like this:
>
> drivers/mfd/vexpress-sysreg.c:64:51: error: initializer element is not constant
> 64 | .resources = (struct resource []) {
> | ^
> drivers/mfd/vexpress-sysreg.c:64:51: note: (near initialization for 'vexpress_sysreg_cells[0]')
> drivers/mfd/vexpress-sysreg.c:73:51: error: initializer element is not constant
> 73 | .resources = (struct resource []) {
> | ^
> drivers/mfd/vexpress-sysreg.c:73:51: note: (near initialization for 'vexpress_sysreg_cells[1]')
> drivers/mfd/vexpress-sysreg.c:82:51: error: initializer element is not constant
> 82 | .resources = (struct resource []) {
> | ^
> drivers/mfd/vexpress-sysreg.c:82:51: note: (near initialization for 'vexpress_sysreg_cells[2]')
> drivers/mfd/vexpress-sysreg.c:90:51: error: initializer element is not constant
> 90 | .resources = (struct resource []) {
> | ^
> drivers/mfd/vexpress-sysreg.c:90:51: note: (near initialization for 'vexpress_sysreg_cells[3]')
>
> Caused (probably) by commit
>
> 52c4d11f1dce ("resource: Convert DEFINE_RES_NAMED() to be compound literal")
>
> I have used the driver-core tree from next-20221111 for today.
Fix is available here:
https://lore.kernel.org/lkml/20221113191027.2327-1-andriy.shevchenko@linux.intel.com/
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply [flat|nested] 181+ messages in thread
* linux-next: build failure after merge of the driver-core tree
@ 2022-11-14 4:12 Stephen Rothwell
2022-11-14 8:46 ` Andy Shevchenko
0 siblings, 1 reply; 181+ messages in thread
From: Stephen Rothwell @ 2022-11-14 4:12 UTC (permalink / raw)
To: Greg KH
Cc: Andy Shevchenko, Linux Kernel Mailing List, Linux Next Mailing List
[-- Attachment #1: Type: text/plain, Size: 1532 bytes --]
Hi all,
After merging the driver-core tree, today's linux-next build (arm
multi_v7_defconfig) failed like this:
drivers/mfd/vexpress-sysreg.c:64:51: error: initializer element is not constant
64 | .resources = (struct resource []) {
| ^
drivers/mfd/vexpress-sysreg.c:64:51: note: (near initialization for 'vexpress_sysreg_cells[0]')
drivers/mfd/vexpress-sysreg.c:73:51: error: initializer element is not constant
73 | .resources = (struct resource []) {
| ^
drivers/mfd/vexpress-sysreg.c:73:51: note: (near initialization for 'vexpress_sysreg_cells[1]')
drivers/mfd/vexpress-sysreg.c:82:51: error: initializer element is not constant
82 | .resources = (struct resource []) {
| ^
drivers/mfd/vexpress-sysreg.c:82:51: note: (near initialization for 'vexpress_sysreg_cells[2]')
drivers/mfd/vexpress-sysreg.c:90:51: error: initializer element is not constant
90 | .resources = (struct resource []) {
| ^
drivers/mfd/vexpress-sysreg.c:90:51: note: (near initialization for 'vexpress_sysreg_cells[3]')
Caused (probably) by commit
52c4d11f1dce ("resource: Convert DEFINE_RES_NAMED() to be compound literal")
I have used the driver-core tree from next-20221111 for today.
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 181+ messages in thread
* Re: linux-next: build failure after merge of the driver-core tree
2021-08-10 12:13 ` Geert Uytterhoeven
@ 2021-08-12 20:51 ` Doug Anderson
0 siblings, 0 replies; 181+ messages in thread
From: Doug Anderson @ 2021-08-12 20:51 UTC (permalink / raw)
To: Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann
Cc: Uwe Kleine-König, Stephen Rothwell, Greg KH, Dave Airlie,
DRI, Greg Kroah-Hartman, Linux Kernel Mailing List,
Linux Next Mailing List, Geert Uytterhoeven
Hi,
On Tue, Aug 10, 2021 at 5:13 AM Geert Uytterhoeven <geert@linux-m68k.org> wrote:
>
> On Fri, Jul 23, 2021 at 7:35 AM Uwe Kleine-König
> <u.kleine-koenig@pengutronix.de> wrote:
> > On Fri, Jul 23, 2021 at 03:09:44PM +1000, Stephen Rothwell wrote:
> > > After merging the driver-core tree, today's linux-next build (arm
> > > multi_v7_defconfig) failed like this:
> > >
> > > drivers/gpu/drm/drm_dp_aux_bus.c:106:13: error: initialization of 'void (*)(struct device *)' from incompatible pointer type 'int (*)(struct device *)' [-Werror=incompatible-pointer-types]
> > > 106 | .remove = dp_aux_ep_remove,
> > > | ^~~~~~~~~~~~~~~~
> > > drivers/gpu/drm/drm_dp_aux_bus.c:106:13: note: (near initialization for 'dp_aux_bus_type.remove')
> > >
> > > Caused by commit
> > >
> > > aeb33699fc2c ("drm: Introduce the DP AUX bus")
> > >
> > > from the drm tree interacting with commit
> > >
> > > fc7a6209d571 ("bus: Make remove callback return void")
> > >
> > > from the driver-core tree.
> > >
> > > I applied the following merge fix patch.
> > >
> > > From: Stephen Rothwell <sfr@canb.auug.org.au>
> > > Date: Fri, 23 Jul 2021 14:58:25 +1000
> > > Subject: [PATCH] fix for "drm: Introduce the DP AUX bus"
> > >
> > > interaction with "bus: Make remove callback return void"
> > >
> > > Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> > > ---
> > > drivers/gpu/drm/drm_dp_aux_bus.c | 5 +----
> > > 1 file changed, 1 insertion(+), 4 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/drm_dp_aux_bus.c b/drivers/gpu/drm/drm_dp_aux_bus.c
> > > index e49a70f3691b..298ea7a49591 100644
> > > --- a/drivers/gpu/drm/drm_dp_aux_bus.c
> > > +++ b/drivers/gpu/drm/drm_dp_aux_bus.c
> > > @@ -67,9 +67,8 @@ static int dp_aux_ep_probe(struct device *dev)
> > > *
> > > * Calls through to the endpoint driver remove.
> > > *
> > > - * Return: 0 if no error or negative error code.
> > > */
> > > -static int dp_aux_ep_remove(struct device *dev)
> > > +static void dp_aux_ep_remove(struct device *dev)
> > > {
> > > struct dp_aux_ep_driver *aux_ep_drv = to_dp_aux_ep_drv(dev->driver);
> > > struct dp_aux_ep_device *aux_ep = to_dp_aux_ep_dev(dev);
> > > @@ -77,8 +76,6 @@ static int dp_aux_ep_remove(struct device *dev)
> > > if (aux_ep_drv->remove)
> > > aux_ep_drv->remove(aux_ep);
> > > dev_pm_domain_detach(dev, true);
> > > -
> > > - return 0;
> > > }
> >
> > This looks right.
> >
> > Greg provided a tag containing fc7a6209d571 ("bus: Make remove callback
> > return void") at
> >
> > git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core.git tags/bus_remove_return_void-5.15
> >
> > (see https://lore.kernel.org/lkml/YPkwQwf0dUKnGA7L@kroah.com).
> >
> > It would be great if this could be merged into the drm tree with the
> > above diff squashed into the merge commit.
>
> +1.
I looked at trying to do this but I think it's beyond the scope of
privileges that I'm granted as a drm_misc committer (not a drm_misc
maintainer). Adding the official maintainers [1].
Maarten/Maxime/Thomas would this be something you could do?
[1] https://drm.pages.freedesktop.org/maintainer-tools/repositories.html
-Doug
^ permalink raw reply [flat|nested] 181+ messages in thread
* Re: linux-next: build failure after merge of the driver-core tree
2021-07-23 5:34 ` Uwe Kleine-König
@ 2021-08-10 12:13 ` Geert Uytterhoeven
2021-08-12 20:51 ` Doug Anderson
0 siblings, 1 reply; 181+ messages in thread
From: Geert Uytterhoeven @ 2021-08-10 12:13 UTC (permalink / raw)
To: Uwe Kleine-König
Cc: Stephen Rothwell, Greg KH, Dave Airlie, DRI, Greg Kroah-Hartman,
Douglas Anderson, Linux Kernel Mailing List,
Linux Next Mailing List
On Fri, Jul 23, 2021 at 7:35 AM Uwe Kleine-König
<u.kleine-koenig@pengutronix.de> wrote:
> On Fri, Jul 23, 2021 at 03:09:44PM +1000, Stephen Rothwell wrote:
> > After merging the driver-core tree, today's linux-next build (arm
> > multi_v7_defconfig) failed like this:
> >
> > drivers/gpu/drm/drm_dp_aux_bus.c:106:13: error: initialization of 'void (*)(struct device *)' from incompatible pointer type 'int (*)(struct device *)' [-Werror=incompatible-pointer-types]
> > 106 | .remove = dp_aux_ep_remove,
> > | ^~~~~~~~~~~~~~~~
> > drivers/gpu/drm/drm_dp_aux_bus.c:106:13: note: (near initialization for 'dp_aux_bus_type.remove')
> >
> > Caused by commit
> >
> > aeb33699fc2c ("drm: Introduce the DP AUX bus")
> >
> > from the drm tree interacting with commit
> >
> > fc7a6209d571 ("bus: Make remove callback return void")
> >
> > from the driver-core tree.
> >
> > I applied the following merge fix patch.
> >
> > From: Stephen Rothwell <sfr@canb.auug.org.au>
> > Date: Fri, 23 Jul 2021 14:58:25 +1000
> > Subject: [PATCH] fix for "drm: Introduce the DP AUX bus"
> >
> > interaction with "bus: Make remove callback return void"
> >
> > Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> > ---
> > drivers/gpu/drm/drm_dp_aux_bus.c | 5 +----
> > 1 file changed, 1 insertion(+), 4 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_dp_aux_bus.c b/drivers/gpu/drm/drm_dp_aux_bus.c
> > index e49a70f3691b..298ea7a49591 100644
> > --- a/drivers/gpu/drm/drm_dp_aux_bus.c
> > +++ b/drivers/gpu/drm/drm_dp_aux_bus.c
> > @@ -67,9 +67,8 @@ static int dp_aux_ep_probe(struct device *dev)
> > *
> > * Calls through to the endpoint driver remove.
> > *
> > - * Return: 0 if no error or negative error code.
> > */
> > -static int dp_aux_ep_remove(struct device *dev)
> > +static void dp_aux_ep_remove(struct device *dev)
> > {
> > struct dp_aux_ep_driver *aux_ep_drv = to_dp_aux_ep_drv(dev->driver);
> > struct dp_aux_ep_device *aux_ep = to_dp_aux_ep_dev(dev);
> > @@ -77,8 +76,6 @@ static int dp_aux_ep_remove(struct device *dev)
> > if (aux_ep_drv->remove)
> > aux_ep_drv->remove(aux_ep);
> > dev_pm_domain_detach(dev, true);
> > -
> > - return 0;
> > }
>
> This looks right.
>
> Greg provided a tag containing fc7a6209d571 ("bus: Make remove callback
> return void") at
>
> git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core.git tags/bus_remove_return_void-5.15
>
> (see https://lore.kernel.org/lkml/YPkwQwf0dUKnGA7L@kroah.com).
>
> It would be great if this could be merged into the drm tree with the
> above diff squashed into the merge commit.
+1.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply [flat|nested] 181+ messages in thread
* Re: linux-next: build failure after merge of the driver-core tree
2021-07-23 5:09 Stephen Rothwell
@ 2021-07-23 5:34 ` Uwe Kleine-König
2021-08-10 12:13 ` Geert Uytterhoeven
0 siblings, 1 reply; 181+ messages in thread
From: Uwe Kleine-König @ 2021-07-23 5:34 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Greg KH, Dave Airlie, DRI, Greg Kroah-Hartman, Douglas Anderson,
Linux Kernel Mailing List, Linux Next Mailing List
[-- Attachment #1: Type: text/plain, Size: 2683 bytes --]
Hello Stephen,
On Fri, Jul 23, 2021 at 03:09:44PM +1000, Stephen Rothwell wrote:
> Hi all,
>
> After merging the driver-core tree, today's linux-next build (arm
> multi_v7_defconfig) failed like this:
>
> drivers/gpu/drm/drm_dp_aux_bus.c:106:13: error: initialization of 'void (*)(struct device *)' from incompatible pointer type 'int (*)(struct device *)' [-Werror=incompatible-pointer-types]
> 106 | .remove = dp_aux_ep_remove,
> | ^~~~~~~~~~~~~~~~
> drivers/gpu/drm/drm_dp_aux_bus.c:106:13: note: (near initialization for 'dp_aux_bus_type.remove')
>
> Caused by commit
>
> aeb33699fc2c ("drm: Introduce the DP AUX bus")
>
> from the drm tree interacting with commit
>
> fc7a6209d571 ("bus: Make remove callback return void")
>
> from the driver-core tree.
>
> I applied the following merge fix patch.
>
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Fri, 23 Jul 2021 14:58:25 +1000
> Subject: [PATCH] fix for "drm: Introduce the DP AUX bus"
>
> interaction with "bus: Make remove callback return void"
>
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> ---
> drivers/gpu/drm/drm_dp_aux_bus.c | 5 +----
> 1 file changed, 1 insertion(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_dp_aux_bus.c b/drivers/gpu/drm/drm_dp_aux_bus.c
> index e49a70f3691b..298ea7a49591 100644
> --- a/drivers/gpu/drm/drm_dp_aux_bus.c
> +++ b/drivers/gpu/drm/drm_dp_aux_bus.c
> @@ -67,9 +67,8 @@ static int dp_aux_ep_probe(struct device *dev)
> *
> * Calls through to the endpoint driver remove.
> *
> - * Return: 0 if no error or negative error code.
> */
> -static int dp_aux_ep_remove(struct device *dev)
> +static void dp_aux_ep_remove(struct device *dev)
> {
> struct dp_aux_ep_driver *aux_ep_drv = to_dp_aux_ep_drv(dev->driver);
> struct dp_aux_ep_device *aux_ep = to_dp_aux_ep_dev(dev);
> @@ -77,8 +76,6 @@ static int dp_aux_ep_remove(struct device *dev)
> if (aux_ep_drv->remove)
> aux_ep_drv->remove(aux_ep);
> dev_pm_domain_detach(dev, true);
> -
> - return 0;
> }
This looks right.
Greg provided a tag containing fc7a6209d571 ("bus: Make remove callback
return void") at
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core.git tags/bus_remove_return_void-5.15
(see https://lore.kernel.org/lkml/YPkwQwf0dUKnGA7L@kroah.com).
It would be great if this could be merged into the drm tree with the
above diff squashed into the merge commit.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | https://www.pengutronix.de/ |
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 181+ messages in thread
* linux-next: build failure after merge of the driver-core tree
@ 2021-07-23 5:09 Stephen Rothwell
2021-07-23 5:34 ` Uwe Kleine-König
0 siblings, 1 reply; 181+ messages in thread
From: Stephen Rothwell @ 2021-07-23 5:09 UTC (permalink / raw)
To: Greg KH, Dave Airlie, DRI
Cc: Greg Kroah-Hartman, Uwe Kleine-König, Douglas Anderson,
Linux Kernel Mailing List, Linux Next Mailing List
[-- Attachment #1: Type: text/plain, Size: 1962 bytes --]
Hi all,
After merging the driver-core tree, today's linux-next build (arm
multi_v7_defconfig) failed like this:
drivers/gpu/drm/drm_dp_aux_bus.c:106:13: error: initialization of 'void (*)(struct device *)' from incompatible pointer type 'int (*)(struct device *)' [-Werror=incompatible-pointer-types]
106 | .remove = dp_aux_ep_remove,
| ^~~~~~~~~~~~~~~~
drivers/gpu/drm/drm_dp_aux_bus.c:106:13: note: (near initialization for 'dp_aux_bus_type.remove')
Caused by commit
aeb33699fc2c ("drm: Introduce the DP AUX bus")
from the drm tree interacting with commit
fc7a6209d571 ("bus: Make remove callback return void")
from the driver-core tree.
I applied the following merge fix patch.
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Fri, 23 Jul 2021 14:58:25 +1000
Subject: [PATCH] fix for "drm: Introduce the DP AUX bus"
interaction with "bus: Make remove callback return void"
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
drivers/gpu/drm/drm_dp_aux_bus.c | 5 +----
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/drm_dp_aux_bus.c b/drivers/gpu/drm/drm_dp_aux_bus.c
index e49a70f3691b..298ea7a49591 100644
--- a/drivers/gpu/drm/drm_dp_aux_bus.c
+++ b/drivers/gpu/drm/drm_dp_aux_bus.c
@@ -67,9 +67,8 @@ static int dp_aux_ep_probe(struct device *dev)
*
* Calls through to the endpoint driver remove.
*
- * Return: 0 if no error or negative error code.
*/
-static int dp_aux_ep_remove(struct device *dev)
+static void dp_aux_ep_remove(struct device *dev)
{
struct dp_aux_ep_driver *aux_ep_drv = to_dp_aux_ep_drv(dev->driver);
struct dp_aux_ep_device *aux_ep = to_dp_aux_ep_dev(dev);
@@ -77,8 +76,6 @@ static int dp_aux_ep_remove(struct device *dev)
if (aux_ep_drv->remove)
aux_ep_drv->remove(aux_ep);
dev_pm_domain_detach(dev, true);
-
- return 0;
}
/**
--
2.30.2
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply related [flat|nested] 181+ messages in thread
* Re: linux-next: build failure after merge of the driver-core tree
2021-02-10 20:43 ` Saravana Kannan
@ 2021-02-10 20:59 ` Rob Herring
0 siblings, 0 replies; 181+ messages in thread
From: Rob Herring @ 2021-02-10 20:59 UTC (permalink / raw)
To: Saravana Kannan
Cc: Greg KH, Stephen Rothwell, Linux Kernel Mailing List,
Linux Next Mailing List
On Wed, Feb 10, 2021 at 2:44 PM Saravana Kannan <saravanak@google.com> wrote:
>
> On Wed, Feb 10, 2021 at 12:15 PM Rob Herring <robh+dt@kernel.org> wrote:
> >
> > On Wed, Feb 10, 2021 at 1:17 PM Saravana Kannan <saravanak@google.com> wrote:
> > >
> > > On Wed, Feb 10, 2021 at 11:06 AM Saravana Kannan <saravanak@google.com> wrote:
> > > >
> > > > On Wed, Feb 10, 2021 at 10:18 AM Greg KH <greg@kroah.com> wrote:
> > > > >
> > > > > On Wed, Feb 10, 2021 at 09:47:20PM +1100, Stephen Rothwell wrote:
> > > > > > Hi all,
> > > > > >
> > > > > > After merging the driver-core tree, today's linux-next build (sparc64
> > > > > > defconfig) failed like this:
> > > > > >
> > > > > > drivers/of/property.o: In function `parse_interrupts':
> > > > > > property.c:(.text+0x14e0): undefined reference to `of_irq_parse_one'
> > > > > >
> > > > > > Caused by commit
> > > > > >
> > > > > > f265f06af194 ("of: property: Fix fw_devlink handling of interrupts/interrupts-extended")
> > > > > >
> > > > > > CONFIG_OF_IRQ depends on !SPARC so of_irq_parse_one() needs a stub.
> >
> > It's always Sparc!
> >
> > > > > > I have added the following patch for today.
> > > > > >
> > > > > > From: Stephen Rothwell <sfr@canb.auug.org.au>
> > > > > > Date: Wed, 10 Feb 2021 21:27:56 +1100
> > > > > > Subject: [PATCH] of: irq: make a stub for of_irq_parse_one()
> > > > > >
> > > > > > Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> > > > > > ---
> > > > > > include/linux/of_irq.h | 9 +++++++--
> > > > > > 1 file changed, 7 insertions(+), 2 deletions(-)
> > > >
> > > > Thanks Stephen!
> > >
> > > Actually the stub needs to return an error. 0 indicates it found the interrupt.
> >
> > I have a slight preference if you could add an 'if
> > (!IS_ENABLED(CONFIG_OF_IRQ))' at the caller instead.
> >
> > If you grep of_irq_parse_one, you'll see there's only a few users
> > which means it's on my hit list to make it private. Stub functions
> > give the impression 'use everywhere'.
>
> I already sent out a fix :(
Okay, it's fine. I misread Greg's mail.
> Will that check optimize out the code and not cause build errors? If
> so, I can send out a patch later.
Yes, it will not trigger link errors. You could still get compile
errors if say a struct member is ifdef'ed out.
Rob
^ permalink raw reply [flat|nested] 181+ messages in thread
* Re: linux-next: build failure after merge of the driver-core tree
2021-02-10 20:14 ` Rob Herring
@ 2021-02-10 20:43 ` Saravana Kannan
2021-02-10 20:59 ` Rob Herring
0 siblings, 1 reply; 181+ messages in thread
From: Saravana Kannan @ 2021-02-10 20:43 UTC (permalink / raw)
To: Rob Herring
Cc: Greg KH, Stephen Rothwell, Linux Kernel Mailing List,
Linux Next Mailing List
On Wed, Feb 10, 2021 at 12:15 PM Rob Herring <robh+dt@kernel.org> wrote:
>
> On Wed, Feb 10, 2021 at 1:17 PM Saravana Kannan <saravanak@google.com> wrote:
> >
> > On Wed, Feb 10, 2021 at 11:06 AM Saravana Kannan <saravanak@google.com> wrote:
> > >
> > > On Wed, Feb 10, 2021 at 10:18 AM Greg KH <greg@kroah.com> wrote:
> > > >
> > > > On Wed, Feb 10, 2021 at 09:47:20PM +1100, Stephen Rothwell wrote:
> > > > > Hi all,
> > > > >
> > > > > After merging the driver-core tree, today's linux-next build (sparc64
> > > > > defconfig) failed like this:
> > > > >
> > > > > drivers/of/property.o: In function `parse_interrupts':
> > > > > property.c:(.text+0x14e0): undefined reference to `of_irq_parse_one'
> > > > >
> > > > > Caused by commit
> > > > >
> > > > > f265f06af194 ("of: property: Fix fw_devlink handling of interrupts/interrupts-extended")
> > > > >
> > > > > CONFIG_OF_IRQ depends on !SPARC so of_irq_parse_one() needs a stub.
>
> It's always Sparc!
>
> > > > > I have added the following patch for today.
> > > > >
> > > > > From: Stephen Rothwell <sfr@canb.auug.org.au>
> > > > > Date: Wed, 10 Feb 2021 21:27:56 +1100
> > > > > Subject: [PATCH] of: irq: make a stub for of_irq_parse_one()
> > > > >
> > > > > Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> > > > > ---
> > > > > include/linux/of_irq.h | 9 +++++++--
> > > > > 1 file changed, 7 insertions(+), 2 deletions(-)
> > >
> > > Thanks Stephen!
> >
> > Actually the stub needs to return an error. 0 indicates it found the interrupt.
>
> I have a slight preference if you could add an 'if
> (!IS_ENABLED(CONFIG_OF_IRQ))' at the caller instead.
>
> If you grep of_irq_parse_one, you'll see there's only a few users
> which means it's on my hit list to make it private. Stub functions
> give the impression 'use everywhere'.
I already sent out a fix :(
Will that check optimize out the code and not cause build errors? If
so, I can send out a patch later.
-Saravana
^ permalink raw reply [flat|nested] 181+ messages in thread
* Re: linux-next: build failure after merge of the driver-core tree
2021-02-10 19:17 ` Saravana Kannan
2021-02-10 19:36 ` Greg KH
@ 2021-02-10 20:14 ` Rob Herring
2021-02-10 20:43 ` Saravana Kannan
1 sibling, 1 reply; 181+ messages in thread
From: Rob Herring @ 2021-02-10 20:14 UTC (permalink / raw)
To: Saravana Kannan
Cc: Greg KH, Stephen Rothwell, Linux Kernel Mailing List,
Linux Next Mailing List
On Wed, Feb 10, 2021 at 1:17 PM Saravana Kannan <saravanak@google.com> wrote:
>
> On Wed, Feb 10, 2021 at 11:06 AM Saravana Kannan <saravanak@google.com> wrote:
> >
> > On Wed, Feb 10, 2021 at 10:18 AM Greg KH <greg@kroah.com> wrote:
> > >
> > > On Wed, Feb 10, 2021 at 09:47:20PM +1100, Stephen Rothwell wrote:
> > > > Hi all,
> > > >
> > > > After merging the driver-core tree, today's linux-next build (sparc64
> > > > defconfig) failed like this:
> > > >
> > > > drivers/of/property.o: In function `parse_interrupts':
> > > > property.c:(.text+0x14e0): undefined reference to `of_irq_parse_one'
> > > >
> > > > Caused by commit
> > > >
> > > > f265f06af194 ("of: property: Fix fw_devlink handling of interrupts/interrupts-extended")
> > > >
> > > > CONFIG_OF_IRQ depends on !SPARC so of_irq_parse_one() needs a stub.
It's always Sparc!
> > > > I have added the following patch for today.
> > > >
> > > > From: Stephen Rothwell <sfr@canb.auug.org.au>
> > > > Date: Wed, 10 Feb 2021 21:27:56 +1100
> > > > Subject: [PATCH] of: irq: make a stub for of_irq_parse_one()
> > > >
> > > > Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> > > > ---
> > > > include/linux/of_irq.h | 9 +++++++--
> > > > 1 file changed, 7 insertions(+), 2 deletions(-)
> >
> > Thanks Stephen!
>
> Actually the stub needs to return an error. 0 indicates it found the interrupt.
I have a slight preference if you could add an 'if
(!IS_ENABLED(CONFIG_OF_IRQ))' at the caller instead.
If you grep of_irq_parse_one, you'll see there's only a few users
which means it's on my hit list to make it private. Stub functions
give the impression 'use everywhere'.
Rob
^ permalink raw reply [flat|nested] 181+ messages in thread
* Re: linux-next: build failure after merge of the driver-core tree
2021-02-10 19:17 ` Saravana Kannan
@ 2021-02-10 19:36 ` Greg KH
2021-02-10 20:14 ` Rob Herring
1 sibling, 0 replies; 181+ messages in thread
From: Greg KH @ 2021-02-10 19:36 UTC (permalink / raw)
To: Saravana Kannan
Cc: Rob Herring, Stephen Rothwell, Linux Kernel Mailing List,
Linux Next Mailing List
On Wed, Feb 10, 2021 at 11:17:16AM -0800, Saravana Kannan wrote:
> On Wed, Feb 10, 2021 at 11:06 AM Saravana Kannan <saravanak@google.com> wrote:
> >
> > On Wed, Feb 10, 2021 at 10:18 AM Greg KH <greg@kroah.com> wrote:
> > >
> > > On Wed, Feb 10, 2021 at 09:47:20PM +1100, Stephen Rothwell wrote:
> > > > Hi all,
> > > >
> > > > After merging the driver-core tree, today's linux-next build (sparc64
> > > > defconfig) failed like this:
> > > >
> > > > drivers/of/property.o: In function `parse_interrupts':
> > > > property.c:(.text+0x14e0): undefined reference to `of_irq_parse_one'
> > > >
> > > > Caused by commit
> > > >
> > > > f265f06af194 ("of: property: Fix fw_devlink handling of interrupts/interrupts-extended")
> > > >
> > > > CONFIG_OF_IRQ depends on !SPARC so of_irq_parse_one() needs a stub.
> > > > I have added the following patch for today.
> > > >
> > > > From: Stephen Rothwell <sfr@canb.auug.org.au>
> > > > Date: Wed, 10 Feb 2021 21:27:56 +1100
> > > > Subject: [PATCH] of: irq: make a stub for of_irq_parse_one()
> > > >
> > > > Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> > > > ---
> > > > include/linux/of_irq.h | 9 +++++++--
> > > > 1 file changed, 7 insertions(+), 2 deletions(-)
> >
> > Thanks Stephen!
>
> Actually the stub needs to return an error. 0 indicates it found the interrupt.
Can you send a fix-up patch for this? This is now in my tree :(
thanks,
greg k-h
^ permalink raw reply [flat|nested] 181+ messages in thread
* Re: linux-next: build failure after merge of the driver-core tree
2021-02-10 19:06 ` Saravana Kannan
@ 2021-02-10 19:17 ` Saravana Kannan
2021-02-10 19:36 ` Greg KH
2021-02-10 20:14 ` Rob Herring
0 siblings, 2 replies; 181+ messages in thread
From: Saravana Kannan @ 2021-02-10 19:17 UTC (permalink / raw)
To: Greg KH, Rob Herring
Cc: Stephen Rothwell, Linux Kernel Mailing List, Linux Next Mailing List
On Wed, Feb 10, 2021 at 11:06 AM Saravana Kannan <saravanak@google.com> wrote:
>
> On Wed, Feb 10, 2021 at 10:18 AM Greg KH <greg@kroah.com> wrote:
> >
> > On Wed, Feb 10, 2021 at 09:47:20PM +1100, Stephen Rothwell wrote:
> > > Hi all,
> > >
> > > After merging the driver-core tree, today's linux-next build (sparc64
> > > defconfig) failed like this:
> > >
> > > drivers/of/property.o: In function `parse_interrupts':
> > > property.c:(.text+0x14e0): undefined reference to `of_irq_parse_one'
> > >
> > > Caused by commit
> > >
> > > f265f06af194 ("of: property: Fix fw_devlink handling of interrupts/interrupts-extended")
> > >
> > > CONFIG_OF_IRQ depends on !SPARC so of_irq_parse_one() needs a stub.
> > > I have added the following patch for today.
> > >
> > > From: Stephen Rothwell <sfr@canb.auug.org.au>
> > > Date: Wed, 10 Feb 2021 21:27:56 +1100
> > > Subject: [PATCH] of: irq: make a stub for of_irq_parse_one()
> > >
> > > Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> > > ---
> > > include/linux/of_irq.h | 9 +++++++--
> > > 1 file changed, 7 insertions(+), 2 deletions(-)
>
> Thanks Stephen!
Actually the stub needs to return an error. 0 indicates it found the interrupt.
-Saravana
^ permalink raw reply [flat|nested] 181+ messages in thread
* Re: linux-next: build failure after merge of the driver-core tree
2021-02-10 18:18 ` Greg KH
@ 2021-02-10 19:06 ` Saravana Kannan
2021-02-10 19:17 ` Saravana Kannan
0 siblings, 1 reply; 181+ messages in thread
From: Saravana Kannan @ 2021-02-10 19:06 UTC (permalink / raw)
To: Greg KH, Rob Herring
Cc: Stephen Rothwell, Linux Kernel Mailing List, Linux Next Mailing List
On Wed, Feb 10, 2021 at 10:18 AM Greg KH <greg@kroah.com> wrote:
>
> On Wed, Feb 10, 2021 at 09:47:20PM +1100, Stephen Rothwell wrote:
> > Hi all,
> >
> > After merging the driver-core tree, today's linux-next build (sparc64
> > defconfig) failed like this:
> >
> > drivers/of/property.o: In function `parse_interrupts':
> > property.c:(.text+0x14e0): undefined reference to `of_irq_parse_one'
> >
> > Caused by commit
> >
> > f265f06af194 ("of: property: Fix fw_devlink handling of interrupts/interrupts-extended")
> >
> > CONFIG_OF_IRQ depends on !SPARC so of_irq_parse_one() needs a stub.
> > I have added the following patch for today.
> >
> > From: Stephen Rothwell <sfr@canb.auug.org.au>
> > Date: Wed, 10 Feb 2021 21:27:56 +1100
> > Subject: [PATCH] of: irq: make a stub for of_irq_parse_one()
> >
> > Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> > ---
> > include/linux/of_irq.h | 9 +++++++--
> > 1 file changed, 7 insertions(+), 2 deletions(-)
Thanks Stephen!
-Saravana
>
> Thanks for this, I'll go queue it up now.
>
> greg k-h
^ permalink raw reply [flat|nested] 181+ messages in thread
* Re: linux-next: build failure after merge of the driver-core tree
2021-02-10 10:47 Stephen Rothwell
@ 2021-02-10 18:18 ` Greg KH
2021-02-10 19:06 ` Saravana Kannan
0 siblings, 1 reply; 181+ messages in thread
From: Greg KH @ 2021-02-10 18:18 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Saravana Kannan, Linux Kernel Mailing List, Linux Next Mailing List
On Wed, Feb 10, 2021 at 09:47:20PM +1100, Stephen Rothwell wrote:
> Hi all,
>
> After merging the driver-core tree, today's linux-next build (sparc64
> defconfig) failed like this:
>
> drivers/of/property.o: In function `parse_interrupts':
> property.c:(.text+0x14e0): undefined reference to `of_irq_parse_one'
>
> Caused by commit
>
> f265f06af194 ("of: property: Fix fw_devlink handling of interrupts/interrupts-extended")
>
> CONFIG_OF_IRQ depends on !SPARC so of_irq_parse_one() needs a stub.
> I have added the following patch for today.
>
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Wed, 10 Feb 2021 21:27:56 +1100
> Subject: [PATCH] of: irq: make a stub for of_irq_parse_one()
>
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> ---
> include/linux/of_irq.h | 9 +++++++--
> 1 file changed, 7 insertions(+), 2 deletions(-)
Thanks for this, I'll go queue it up now.
greg k-h
^ permalink raw reply [flat|nested] 181+ messages in thread
* linux-next: build failure after merge of the driver-core tree
@ 2021-02-10 10:47 Stephen Rothwell
2021-02-10 18:18 ` Greg KH
0 siblings, 1 reply; 181+ messages in thread
From: Stephen Rothwell @ 2021-02-10 10:47 UTC (permalink / raw)
To: Greg KH
Cc: Greg Kroah-Hartman, Saravana Kannan, Linux Kernel Mailing List,
Linux Next Mailing List
[-- Attachment #1: Type: text/plain, Size: 2450 bytes --]
Hi all,
After merging the driver-core tree, today's linux-next build (sparc64
defconfig) failed like this:
drivers/of/property.o: In function `parse_interrupts':
property.c:(.text+0x14e0): undefined reference to `of_irq_parse_one'
Caused by commit
f265f06af194 ("of: property: Fix fw_devlink handling of interrupts/interrupts-extended")
CONFIG_OF_IRQ depends on !SPARC so of_irq_parse_one() needs a stub.
I have added the following patch for today.
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Wed, 10 Feb 2021 21:27:56 +1100
Subject: [PATCH] of: irq: make a stub for of_irq_parse_one()
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
include/linux/of_irq.h | 9 +++++++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/include/linux/of_irq.h b/include/linux/of_irq.h
index e8b78139f78c..f898d838d201 100644
--- a/include/linux/of_irq.h
+++ b/include/linux/of_irq.h
@@ -33,8 +33,6 @@ static inline int of_irq_parse_oldworld(struct device_node *device, int index,
#endif /* CONFIG_PPC32 && CONFIG_PPC_PMAC */
extern int of_irq_parse_raw(const __be32 *addr, struct of_phandle_args *out_irq);
-extern int of_irq_parse_one(struct device_node *device, int index,
- struct of_phandle_args *out_irq);
extern unsigned int irq_create_of_mapping(struct of_phandle_args *irq_data);
extern int of_irq_to_resource(struct device_node *dev, int index,
struct resource *r);
@@ -42,6 +40,8 @@ extern int of_irq_to_resource(struct device_node *dev, int index,
extern void of_irq_init(const struct of_device_id *matches);
#ifdef CONFIG_OF_IRQ
+extern int of_irq_parse_one(struct device_node *device, int index,
+ struct of_phandle_args *out_irq);
extern int of_irq_count(struct device_node *dev);
extern int of_irq_get(struct device_node *dev, int index);
extern int of_irq_get_byname(struct device_node *dev, const char *name);
@@ -57,6 +57,11 @@ extern struct irq_domain *of_msi_map_get_device_domain(struct device *dev,
extern void of_msi_configure(struct device *dev, struct device_node *np);
u32 of_msi_map_id(struct device *dev, struct device_node *msi_np, u32 id_in);
#else
+static inline int of_irq_parse_one(struct device_node *device, int index,
+ struct of_phandle_args *out_irq)
+{
+ return 0;
+}
static inline int of_irq_count(struct device_node *dev)
{
return 0;
--
2.30.0
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply related [flat|nested] 181+ messages in thread
* Re: linux-next: build failure after merge of the driver-core tree
2020-09-09 7:21 ` Greg KH
@ 2020-09-09 21:47 ` Kees Cook
0 siblings, 0 replies; 181+ messages in thread
From: Kees Cook @ 2020-09-09 21:47 UTC (permalink / raw)
To: Greg KH
Cc: Stephen Rothwell, Linux Next Mailing List, Linux Kernel Mailing List
On Wed, Sep 09, 2020 at 09:21:05AM +0200, Greg KH wrote:
> On Wed, Sep 09, 2020 at 03:47:09PM +1000, Stephen Rothwell wrote:
> > Hi all,
> >
> > After merging the driver-core tree, today's linux-next build (x86_64
> > allmodconfig) failed like this:
> >
> > lib/test_firmware.c: In function 'trigger_request_platform_store':
> > lib/test_firmware.c:517:35: error: 'efi_embedded_fw_list' undeclared (first use in this function); did you mean 'efi_embedded_fw_desc'?
> > 517 | list_add(&efi_embedded_fw.list, &efi_embedded_fw_list);
> > | ^~~~~~~~~~~~~~~~~~~~
> > | efi_embedded_fw_desc
> > lib/test_firmware.c:517:35: note: each undeclared identifier is reported only once for each function it appears in
> > lib/test_firmware.c:518:34: error: 'efi_embedded_fw_checked' undeclared (first use in this function); did you mean 'saved_efi_embedded_fw_checked'?
> > 518 | saved_efi_embedded_fw_checked = efi_embedded_fw_checked;
> > | ^~~~~~~~~~~~~~~~~~~~~~~
> > | saved_efi_embedded_fw_checked
> >
> > Caused by commit
> >
> > 18efb2f9e897 ("test_firmware: Test platform fw loading on non-EFI systems")
>
> {sigh}
>
> I'll go revert this, sorry about that.
>
> Kees, can you fix up this whole series and resend it again? I'm
> dropping it from my trees now...
Oh ew, I will check the configs. I wonder what went wrong with this...
sorry for the noise!
--
Kees Cook
^ permalink raw reply [flat|nested] 181+ messages in thread
* Re: linux-next: build failure after merge of the driver-core tree
2020-09-09 5:47 Stephen Rothwell
2020-09-09 7:21 ` Greg KH
@ 2020-09-09 7:28 ` Greg KH
1 sibling, 0 replies; 181+ messages in thread
From: Greg KH @ 2020-09-09 7:28 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Kees Cook, Linux Next Mailing List, Linux Kernel Mailing List
On Wed, Sep 09, 2020 at 03:47:09PM +1000, Stephen Rothwell wrote:
> Hi all,
>
> After merging the driver-core tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
>
> lib/test_firmware.c: In function 'trigger_request_platform_store':
> lib/test_firmware.c:517:35: error: 'efi_embedded_fw_list' undeclared (first use in this function); did you mean 'efi_embedded_fw_desc'?
> 517 | list_add(&efi_embedded_fw.list, &efi_embedded_fw_list);
> | ^~~~~~~~~~~~~~~~~~~~
> | efi_embedded_fw_desc
> lib/test_firmware.c:517:35: note: each undeclared identifier is reported only once for each function it appears in
> lib/test_firmware.c:518:34: error: 'efi_embedded_fw_checked' undeclared (first use in this function); did you mean 'saved_efi_embedded_fw_checked'?
> 518 | saved_efi_embedded_fw_checked = efi_embedded_fw_checked;
> | ^~~~~~~~~~~~~~~~~~~~~~~
> | saved_efi_embedded_fw_checked
>
> Caused by commit
>
> 18efb2f9e897 ("test_firmware: Test platform fw loading on non-EFI systems")
>
> I have reverted that commit for today.
Now reverted in my tree too, thanks.
greg k-h
^ permalink raw reply [flat|nested] 181+ messages in thread
* Re: linux-next: build failure after merge of the driver-core tree
2020-09-09 5:47 Stephen Rothwell
@ 2020-09-09 7:21 ` Greg KH
2020-09-09 21:47 ` Kees Cook
2020-09-09 7:28 ` Greg KH
1 sibling, 1 reply; 181+ messages in thread
From: Greg KH @ 2020-09-09 7:21 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Kees Cook, Linux Next Mailing List, Linux Kernel Mailing List
On Wed, Sep 09, 2020 at 03:47:09PM +1000, Stephen Rothwell wrote:
> Hi all,
>
> After merging the driver-core tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
>
> lib/test_firmware.c: In function 'trigger_request_platform_store':
> lib/test_firmware.c:517:35: error: 'efi_embedded_fw_list' undeclared (first use in this function); did you mean 'efi_embedded_fw_desc'?
> 517 | list_add(&efi_embedded_fw.list, &efi_embedded_fw_list);
> | ^~~~~~~~~~~~~~~~~~~~
> | efi_embedded_fw_desc
> lib/test_firmware.c:517:35: note: each undeclared identifier is reported only once for each function it appears in
> lib/test_firmware.c:518:34: error: 'efi_embedded_fw_checked' undeclared (first use in this function); did you mean 'saved_efi_embedded_fw_checked'?
> 518 | saved_efi_embedded_fw_checked = efi_embedded_fw_checked;
> | ^~~~~~~~~~~~~~~~~~~~~~~
> | saved_efi_embedded_fw_checked
>
> Caused by commit
>
> 18efb2f9e897 ("test_firmware: Test platform fw loading on non-EFI systems")
{sigh}
I'll go revert this, sorry about that.
Kees, can you fix up this whole series and resend it again? I'm
dropping it from my trees now...
thanks,
greg k-h
^ permalink raw reply [flat|nested] 181+ messages in thread
* linux-next: build failure after merge of the driver-core tree
@ 2020-09-09 5:47 Stephen Rothwell
2020-09-09 7:21 ` Greg KH
2020-09-09 7:28 ` Greg KH
0 siblings, 2 replies; 181+ messages in thread
From: Stephen Rothwell @ 2020-09-09 5:47 UTC (permalink / raw)
To: Greg KH; +Cc: Kees Cook, Linux Next Mailing List, Linux Kernel Mailing List
[-- Attachment #1: Type: text/plain, Size: 1162 bytes --]
Hi all,
After merging the driver-core tree, today's linux-next build (x86_64
allmodconfig) failed like this:
lib/test_firmware.c: In function 'trigger_request_platform_store':
lib/test_firmware.c:517:35: error: 'efi_embedded_fw_list' undeclared (first use in this function); did you mean 'efi_embedded_fw_desc'?
517 | list_add(&efi_embedded_fw.list, &efi_embedded_fw_list);
| ^~~~~~~~~~~~~~~~~~~~
| efi_embedded_fw_desc
lib/test_firmware.c:517:35: note: each undeclared identifier is reported only once for each function it appears in
lib/test_firmware.c:518:34: error: 'efi_embedded_fw_checked' undeclared (first use in this function); did you mean 'saved_efi_embedded_fw_checked'?
518 | saved_efi_embedded_fw_checked = efi_embedded_fw_checked;
| ^~~~~~~~~~~~~~~~~~~~~~~
| saved_efi_embedded_fw_checked
Caused by commit
18efb2f9e897 ("test_firmware: Test platform fw loading on non-EFI systems")
I have reverted that commit for today.
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 181+ messages in thread
* Re: linux-next: build failure after merge of the driver-core tree
2020-07-27 10:17 ` Greg KH
@ 2020-07-28 19:53 ` Kees Cook
0 siblings, 0 replies; 181+ messages in thread
From: Kees Cook @ 2020-07-28 19:53 UTC (permalink / raw)
To: Greg KH
Cc: Stephen Rothwell, Linux Next Mailing List,
Linux Kernel Mailing List, Scott Branden
On Mon, Jul 27, 2020 at 12:17:38PM +0200, Greg KH wrote:
> On Mon, Jul 27, 2020 at 04:55:39PM +1000, Stephen Rothwell wrote:
> > Hi all,
> >
> > After merging the driver-core tree, today's linux-next build (x86_64
> > allmodconfig) failed like this:
> >
> > In file included from include/linux/dmi.h:5,
> > from drivers/firmware/efi/embedded-firmware.c:8:
> > drivers/firmware/efi/embedded-firmware.c:25:38: error: static declaration of 'efi_embedded_fw_list' follows non-static declaration
> > 25 | EFI_EMBEDDED_FW_VISIBILITY LIST_HEAD(efi_embedded_fw_list);
> > | ^~~~~~~~~~~~~~~~~~~~
> > include/linux/list.h:24:19: note: in definition of macro 'LIST_HEAD'
> > 24 | struct list_head name = LIST_HEAD_INIT(name)
> > | ^~~~
> > In file included from drivers/firmware/efi/embedded-firmware.c:17:
> > drivers/firmware/efi/embedded-firmware.h:16:25: note: previous declaration of 'efi_embedded_fw_list' was here
> > 16 | extern struct list_head efi_embedded_fw_list;
> > | ^~~~~~~~~~~~~~~~~~~~
> > drivers/firmware/efi/embedded-firmware.c:26:33: error: static declaration of 'efi_embedded_fw_checked' follows non-static declaration
> > 26 | EFI_EMBEDDED_FW_VISIBILITY bool efi_embedded_fw_checked;
> > | ^~~~~~~~~~~~~~~~~~~~~~~
> > In file included from drivers/firmware/efi/embedded-firmware.c:17:
> > drivers/firmware/efi/embedded-firmware.h:17:13: note: previous declaration of 'efi_embedded_fw_checked' was here
> > 17 | extern bool efi_embedded_fw_checked;
> > | ^~~~~~~~~~~~~~~~~~~~~~~
> >
> > Caused by commit
> >
> > 2d38dbf89a06 ("test_firmware: Test platform fw loading on non-EFI systems")
> >
> > CONFIG_TEST_FIRMWARE=m for this build.
> >
> > I have used the driver-core tree from next-20200724 for today.
>
> Thanks, I've reverted this from my tree now.
Ugh, my mistake; sorry for the hassle! I will get this corrected and
re-sent.
--
Kees Cook
^ permalink raw reply [flat|nested] 181+ messages in thread
* Re: linux-next: build failure after merge of the driver-core tree
2020-07-27 6:55 Stephen Rothwell
@ 2020-07-27 10:17 ` Greg KH
2020-07-28 19:53 ` Kees Cook
0 siblings, 1 reply; 181+ messages in thread
From: Greg KH @ 2020-07-27 10:17 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Linux Next Mailing List, Linux Kernel Mailing List, Kees Cook,
Scott Branden
On Mon, Jul 27, 2020 at 04:55:39PM +1000, Stephen Rothwell wrote:
> Hi all,
>
> After merging the driver-core tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
>
> In file included from include/linux/dmi.h:5,
> from drivers/firmware/efi/embedded-firmware.c:8:
> drivers/firmware/efi/embedded-firmware.c:25:38: error: static declaration of 'efi_embedded_fw_list' follows non-static declaration
> 25 | EFI_EMBEDDED_FW_VISIBILITY LIST_HEAD(efi_embedded_fw_list);
> | ^~~~~~~~~~~~~~~~~~~~
> include/linux/list.h:24:19: note: in definition of macro 'LIST_HEAD'
> 24 | struct list_head name = LIST_HEAD_INIT(name)
> | ^~~~
> In file included from drivers/firmware/efi/embedded-firmware.c:17:
> drivers/firmware/efi/embedded-firmware.h:16:25: note: previous declaration of 'efi_embedded_fw_list' was here
> 16 | extern struct list_head efi_embedded_fw_list;
> | ^~~~~~~~~~~~~~~~~~~~
> drivers/firmware/efi/embedded-firmware.c:26:33: error: static declaration of 'efi_embedded_fw_checked' follows non-static declaration
> 26 | EFI_EMBEDDED_FW_VISIBILITY bool efi_embedded_fw_checked;
> | ^~~~~~~~~~~~~~~~~~~~~~~
> In file included from drivers/firmware/efi/embedded-firmware.c:17:
> drivers/firmware/efi/embedded-firmware.h:17:13: note: previous declaration of 'efi_embedded_fw_checked' was here
> 17 | extern bool efi_embedded_fw_checked;
> | ^~~~~~~~~~~~~~~~~~~~~~~
>
> Caused by commit
>
> 2d38dbf89a06 ("test_firmware: Test platform fw loading on non-EFI systems")
>
> CONFIG_TEST_FIRMWARE=m for this build.
>
> I have used the driver-core tree from next-20200724 for today.
Thanks, I've reverted this from my tree now.
greg k-h
^ permalink raw reply [flat|nested] 181+ messages in thread
* linux-next: build failure after merge of the driver-core tree
@ 2020-07-27 6:55 Stephen Rothwell
2020-07-27 10:17 ` Greg KH
0 siblings, 1 reply; 181+ messages in thread
From: Stephen Rothwell @ 2020-07-27 6:55 UTC (permalink / raw)
To: Greg KH
Cc: Linux Next Mailing List, Linux Kernel Mailing List, Kees Cook,
Scott Branden
[-- Attachment #1: Type: text/plain, Size: 1724 bytes --]
Hi all,
After merging the driver-core tree, today's linux-next build (x86_64
allmodconfig) failed like this:
In file included from include/linux/dmi.h:5,
from drivers/firmware/efi/embedded-firmware.c:8:
drivers/firmware/efi/embedded-firmware.c:25:38: error: static declaration of 'efi_embedded_fw_list' follows non-static declaration
25 | EFI_EMBEDDED_FW_VISIBILITY LIST_HEAD(efi_embedded_fw_list);
| ^~~~~~~~~~~~~~~~~~~~
include/linux/list.h:24:19: note: in definition of macro 'LIST_HEAD'
24 | struct list_head name = LIST_HEAD_INIT(name)
| ^~~~
In file included from drivers/firmware/efi/embedded-firmware.c:17:
drivers/firmware/efi/embedded-firmware.h:16:25: note: previous declaration of 'efi_embedded_fw_list' was here
16 | extern struct list_head efi_embedded_fw_list;
| ^~~~~~~~~~~~~~~~~~~~
drivers/firmware/efi/embedded-firmware.c:26:33: error: static declaration of 'efi_embedded_fw_checked' follows non-static declaration
26 | EFI_EMBEDDED_FW_VISIBILITY bool efi_embedded_fw_checked;
| ^~~~~~~~~~~~~~~~~~~~~~~
In file included from drivers/firmware/efi/embedded-firmware.c:17:
drivers/firmware/efi/embedded-firmware.h:17:13: note: previous declaration of 'efi_embedded_fw_checked' was here
17 | extern bool efi_embedded_fw_checked;
| ^~~~~~~~~~~~~~~~~~~~~~~
Caused by commit
2d38dbf89a06 ("test_firmware: Test platform fw loading on non-EFI systems")
CONFIG_TEST_FIRMWARE=m for this build.
I have used the driver-core tree from next-20200724 for today.
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 181+ messages in thread
* Re: linux-next: build failure after merge of the driver-core tree
2019-09-18 19:03 ` Linus Torvalds
2019-09-18 19:07 ` Greg KH
@ 2019-09-18 21:55 ` Mark Brown
1 sibling, 0 replies; 181+ messages in thread
From: Mark Brown @ 2019-09-18 21:55 UTC (permalink / raw)
To: Linus Torvalds
Cc: Greg KH, Suzuki K Poulose, Wolfram Sang, Mika Westerberg,
linux-i2c, Linux Next Mailing List, Linux Kernel Mailing List
[-- Attachment #1: Type: text/plain, Size: 1819 bytes --]
On Wed, Sep 18, 2019 at 12:03:17PM -0700, Linus Torvalds wrote:
> On Wed, Sep 18, 2019 at 11:53 AM Greg KH <gregkh@linuxfoundation.org> wrote:
> > On Wed, Sep 18, 2019 at 06:09:52PM +0100, Mark Brown wrote:
> > > After merging the driver-core tree, today's linux-next build
> > > for arm64 allmodconfig failed like this:
> > Wait, I thought Linus said this fixup was now resolved. What went
> > wrong?
> I think this is purely a linux-next build failure.
> I do full allmodconfig builds between each merge I do, and what
> happened is that as part of the LED merge, I removed the
> no-longer-used 'i2c_acpi_find_match_adapter()' to resolve that build
> warning.
> Then linux-next presumably merged my tree with the driver-core tree,
> and that re-instated the use of i2c_acpi_find_match_adapter() - which
> was now gone.
> But when *I* merged the driver-core tree, I did the merge fixup
> correctly to actually re-instate not only the use, but also re-instate
> the removed function that now had a use again.
Yes, that's exactly what happened - it's purely an issue when Greg's
tree is merged automatically, I was reporting the same thing you fixed
up. If the initial build of your tree had been broken I'd have been
complaining much more loudy and much earlier!
> > Linus, should I submit a fix for this?
> My tree should be fine, and I really think this is just a temporary
> linux-next effect from the above. I think linux-next only handled the
> actual syntactic conflicts, not the semantic conflict of "function had
> been removed to avoid build error from previous merge, and needed to
> be brought back"
Right, git just sees the code moving about and got confused. Since
you've merged both trees now tomorrow's -next won't do anything for
driver-core and the automation will handle everything fine.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 181+ messages in thread
* Re: linux-next: build failure after merge of the driver-core tree
2019-09-18 19:07 ` Greg KH
@ 2019-09-18 20:56 ` Suzuki K Poulose
0 siblings, 0 replies; 181+ messages in thread
From: Suzuki K Poulose @ 2019-09-18 20:56 UTC (permalink / raw)
To: gregkh, torvalds
Cc: broonie, wsa, mika.westerberg, linux-i2c, linux-next, linux-kernel
On 09/18/2019 08:07 PM, Greg KH wrote:
> On Wed, Sep 18, 2019 at 12:03:17PM -0700, Linus Torvalds wrote:
>> On Wed, Sep 18, 2019 at 11:53 AM Greg KH <gregkh@linuxfoundation.org> wrote:
>>>
>>> On Wed, Sep 18, 2019 at 06:09:52PM +0100, Mark Brown wrote:
>>>>
>>>> After merging the driver-core tree, today's linux-next build
>>>> for arm64 allmodconfig failed like this:
>>>
>>> Wait, I thought Linus said this fixup was now resolved. What went
>>> wrong?
>>
>> I think this is purely a linux-next build failure.
>>
>> I do full allmodconfig builds between each merge I do, and what
>> happened is that as part of the LED merge, I removed the
>> no-longer-used 'i2c_acpi_find_match_adapter()' to resolve that build
>> warning.
>>
>> Then linux-next presumably merged my tree with the driver-core tree,
>> and that re-instated the use of i2c_acpi_find_match_adapter() - which
>> was now gone.
>>
>> But when *I* merged the driver-core tree, I did the merge fixup
>> correctly to actually re-instate not only the use, but also re-instate
>> the removed function that now had a use again.
>>
>>> Linus, should I submit a fix for this?
>>
>> My tree should be fine, and I really think this is just a temporary
>> linux-next effect from the above. I think linux-next only handled the
>> actual syntactic conflicts, not the semantic conflict of "function had
>> been removed to avoid build error from previous merge, and needed to
>> be brought back"
>>
>> Knock wood.
>
> I looked at your merge of the driver core tree, and see that the
> "missing" function is now back.
>
> And I did a test build here and all works for me, so I think this is ok,
> thanks for the fixup.
>
> greg k-h
>
Thanks for the fixup ! Apologies for the inconvenience
Suzuki
^ permalink raw reply [flat|nested] 181+ messages in thread
* Re: linux-next: build failure after merge of the driver-core tree
2019-09-18 19:03 ` Linus Torvalds
@ 2019-09-18 19:07 ` Greg KH
2019-09-18 20:56 ` Suzuki K Poulose
2019-09-18 21:55 ` Mark Brown
1 sibling, 1 reply; 181+ messages in thread
From: Greg KH @ 2019-09-18 19:07 UTC (permalink / raw)
To: Linus Torvalds
Cc: Mark Brown, Suzuki K Poulose, Wolfram Sang, Mika Westerberg,
linux-i2c, Linux Next Mailing List, Linux Kernel Mailing List
On Wed, Sep 18, 2019 at 12:03:17PM -0700, Linus Torvalds wrote:
> On Wed, Sep 18, 2019 at 11:53 AM Greg KH <gregkh@linuxfoundation.org> wrote:
> >
> > On Wed, Sep 18, 2019 at 06:09:52PM +0100, Mark Brown wrote:
> > >
> > > After merging the driver-core tree, today's linux-next build
> > > for arm64 allmodconfig failed like this:
> >
> > Wait, I thought Linus said this fixup was now resolved. What went
> > wrong?
>
> I think this is purely a linux-next build failure.
>
> I do full allmodconfig builds between each merge I do, and what
> happened is that as part of the LED merge, I removed the
> no-longer-used 'i2c_acpi_find_match_adapter()' to resolve that build
> warning.
>
> Then linux-next presumably merged my tree with the driver-core tree,
> and that re-instated the use of i2c_acpi_find_match_adapter() - which
> was now gone.
>
> But when *I* merged the driver-core tree, I did the merge fixup
> correctly to actually re-instate not only the use, but also re-instate
> the removed function that now had a use again.
>
> > Linus, should I submit a fix for this?
>
> My tree should be fine, and I really think this is just a temporary
> linux-next effect from the above. I think linux-next only handled the
> actual syntactic conflicts, not the semantic conflict of "function had
> been removed to avoid build error from previous merge, and needed to
> be brought back"
>
> Knock wood.
I looked at your merge of the driver core tree, and see that the
"missing" function is now back.
And I did a test build here and all works for me, so I think this is ok,
thanks for the fixup.
greg k-h
^ permalink raw reply [flat|nested] 181+ messages in thread
* Re: linux-next: build failure after merge of the driver-core tree
2019-09-18 18:52 ` Greg KH
@ 2019-09-18 19:03 ` Linus Torvalds
2019-09-18 19:07 ` Greg KH
2019-09-18 21:55 ` Mark Brown
0 siblings, 2 replies; 181+ messages in thread
From: Linus Torvalds @ 2019-09-18 19:03 UTC (permalink / raw)
To: Greg KH
Cc: Mark Brown, Suzuki K Poulose, Wolfram Sang, Mika Westerberg,
linux-i2c, Linux Next Mailing List, Linux Kernel Mailing List
On Wed, Sep 18, 2019 at 11:53 AM Greg KH <gregkh@linuxfoundation.org> wrote:
>
> On Wed, Sep 18, 2019 at 06:09:52PM +0100, Mark Brown wrote:
> >
> > After merging the driver-core tree, today's linux-next build
> > for arm64 allmodconfig failed like this:
>
> Wait, I thought Linus said this fixup was now resolved. What went
> wrong?
I think this is purely a linux-next build failure.
I do full allmodconfig builds between each merge I do, and what
happened is that as part of the LED merge, I removed the
no-longer-used 'i2c_acpi_find_match_adapter()' to resolve that build
warning.
Then linux-next presumably merged my tree with the driver-core tree,
and that re-instated the use of i2c_acpi_find_match_adapter() - which
was now gone.
But when *I* merged the driver-core tree, I did the merge fixup
correctly to actually re-instate not only the use, but also re-instate
the removed function that now had a use again.
> Linus, should I submit a fix for this?
My tree should be fine, and I really think this is just a temporary
linux-next effect from the above. I think linux-next only handled the
actual syntactic conflicts, not the semantic conflict of "function had
been removed to avoid build error from previous merge, and needed to
be brought back"
Knock wood.
Linus
^ permalink raw reply [flat|nested] 181+ messages in thread
* Re: linux-next: build failure after merge of the driver-core tree
2019-09-18 17:09 Mark Brown
@ 2019-09-18 18:52 ` Greg KH
2019-09-18 19:03 ` Linus Torvalds
0 siblings, 1 reply; 181+ messages in thread
From: Greg KH @ 2019-09-18 18:52 UTC (permalink / raw)
To: Linus Torvalds, Mark Brown
Cc: Suzuki K Poulose, Wolfram Sang, Mika Westerberg, linux-i2c,
Linux Next Mailing List, Linux Kernel Mailing List
On Wed, Sep 18, 2019 at 06:09:52PM +0100, Mark Brown wrote:
> Hi all,
>
> After merging the driver-core tree, today's linux-next build
> for arm64 allmodconfig failed like this:
>
> /home/broonie/next/next/drivers/i2c/i2c-core-acpi.c: In function 'i2c_acpi_find_adapter_by_handle':
> /home/broonie/next/next/drivers/i2c/i2c-core-acpi.c:352:10: error: 'i2c_acpi_find_match_adapter' undeclared (first use in this function); did you mean 'i2c_acpi_find_bus_speed'?
> i2c_acpi_find_match_adapter);
> ^~~~~~~~~~~~~~~~~~~~~~~~~~~
> i2c_acpi_find_bus_speed
> /home/broonie/next/next/drivers/i2c/i2c-core-acpi.c:352:10: note: each undeclared identifier is reported only once for each function it appears in
>
> Caused by commit
>
> 644bf600889554210 ("i2c: Revert incorrect conversion to use generic helper")
>
> In yesterday's -next that function existed but it appears to have been
> removed in Linus' tree as part of the merge:
>
> 4feaab05dc1eda3 ("Merge tag 'leds-for-5.4-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/j.anaszewski/linux-leds")
>
> by the commit
>
> 00500147cbd3fc5 ("drivers: Introduce device lookup variants by ACPI_COMPANION device")
>
> (ie, the commit that the failing commit was trying to revert.) I
> suspect this is confusion caused by things going into Linus' tree in
> different orders. I've fixed this up by re-adding the function.
Wait, I thought Linus said this fixup was now resolved. What went
wrong?
Linus, should I submit a fix for this?
thanks,
greg k-h
^ permalink raw reply [flat|nested] 181+ messages in thread
* linux-next: build failure after merge of the driver-core tree
@ 2019-09-18 17:09 Mark Brown
2019-09-18 18:52 ` Greg KH
0 siblings, 1 reply; 181+ messages in thread
From: Mark Brown @ 2019-09-18 17:09 UTC (permalink / raw)
To: Greg KH, Suzuki K Poulose, Wolfram Sang, Mika Westerberg
Cc: linux-i2c, Linux Next Mailing List, Linux Kernel Mailing List
[-- Attachment #1: Type: text/plain, Size: 1295 bytes --]
Hi all,
After merging the driver-core tree, today's linux-next build
for arm64 allmodconfig failed like this:
/home/broonie/next/next/drivers/i2c/i2c-core-acpi.c: In function 'i2c_acpi_find_adapter_by_handle':
/home/broonie/next/next/drivers/i2c/i2c-core-acpi.c:352:10: error: 'i2c_acpi_find_match_adapter' undeclared (first use in this function); did you mean 'i2c_acpi_find_bus_speed'?
i2c_acpi_find_match_adapter);
^~~~~~~~~~~~~~~~~~~~~~~~~~~
i2c_acpi_find_bus_speed
/home/broonie/next/next/drivers/i2c/i2c-core-acpi.c:352:10: note: each undeclared identifier is reported only once for each function it appears in
Caused by commit
644bf600889554210 ("i2c: Revert incorrect conversion to use generic helper")
In yesterday's -next that function existed but it appears to have been
removed in Linus' tree as part of the merge:
4feaab05dc1eda3 ("Merge tag 'leds-for-5.4-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/j.anaszewski/linux-leds")
by the commit
00500147cbd3fc5 ("drivers: Introduce device lookup variants by ACPI_COMPANION device")
(ie, the commit that the failing commit was trying to revert.) I
suspect this is confusion caused by things going into Linus' tree in
different orders. I've fixed this up by re-adding the function.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 181+ messages in thread
* Re: linux-next: build failure after merge of the driver-core tree
2019-08-29 7:35 Stephen Rothwell
@ 2019-08-29 10:10 ` Greg KH
0 siblings, 0 replies; 181+ messages in thread
From: Greg KH @ 2019-08-29 10:10 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Linux Next Mailing List, Linux Kernel Mailing List,
Thierry Reding, Stephen Boyd, Guenter Roeck,
Bartlomiej Zolnierkiewicz
On Thu, Aug 29, 2019 at 05:35:15PM +1000, Stephen Rothwell wrote:
> Hi all,
>
> After merging the driver-core tree, today's linux-next build (arm
> multi_v7_defconfig) failed like this:
>
> ERROR: "platform_get_irq_optional" [drivers/hwmon/pwm-fan.ko] undefined!
>
> Caused by commit
>
> 6e7e5c7fbc1c ("hwmon: pwm-fan: Use platform_get_irq_optional()")
>
> [ or maybe commit
>
> 8973ea47901c ("driver core: platform: Introduce platform_get_irq_optional()")
> ]
>
> I have added the following patch for today.
>
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Thu, 29 Aug 2019 17:26:34 +1000
> Subject: [PATCH] driver core: platform: export platform_get_irq_optional
>
> Fixes: 6e7e5c7fbc1c ("hwmon: pwm-fan: Use platform_get_irq_optional()")
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> ---
> drivers/base/platform.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/base/platform.c b/drivers/base/platform.c
> index 0dda6ade50fd..11c6e56ccc22 100644
> --- a/drivers/base/platform.c
> +++ b/drivers/base/platform.c
> @@ -213,6 +213,7 @@ int platform_get_irq_optional(struct platform_device *dev, unsigned int num)
> {
> return __platform_get_irq(dev, num);
> }
> +EXPORT_SYMBOL_GPL(platform_get_irq_optional);
I just got this same patch right before you sent this, so I've queued it
up, thanks.
greg k-h
^ permalink raw reply [flat|nested] 181+ messages in thread
* linux-next: build failure after merge of the driver-core tree
@ 2019-08-29 7:35 Stephen Rothwell
2019-08-29 10:10 ` Greg KH
0 siblings, 1 reply; 181+ messages in thread
From: Stephen Rothwell @ 2019-08-29 7:35 UTC (permalink / raw)
To: Greg KH
Cc: Linux Next Mailing List, Linux Kernel Mailing List,
Thierry Reding, Stephen Boyd, Guenter Roeck,
Bartlomiej Zolnierkiewicz
[-- Attachment #1: Type: text/plain, Size: 1293 bytes --]
Hi all,
After merging the driver-core tree, today's linux-next build (arm
multi_v7_defconfig) failed like this:
ERROR: "platform_get_irq_optional" [drivers/hwmon/pwm-fan.ko] undefined!
Caused by commit
6e7e5c7fbc1c ("hwmon: pwm-fan: Use platform_get_irq_optional()")
[ or maybe commit
8973ea47901c ("driver core: platform: Introduce platform_get_irq_optional()")
]
I have added the following patch for today.
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Thu, 29 Aug 2019 17:26:34 +1000
Subject: [PATCH] driver core: platform: export platform_get_irq_optional
Fixes: 6e7e5c7fbc1c ("hwmon: pwm-fan: Use platform_get_irq_optional()")
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
drivers/base/platform.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/base/platform.c b/drivers/base/platform.c
index 0dda6ade50fd..11c6e56ccc22 100644
--- a/drivers/base/platform.c
+++ b/drivers/base/platform.c
@@ -213,6 +213,7 @@ int platform_get_irq_optional(struct platform_device *dev, unsigned int num)
{
return __platform_get_irq(dev, num);
}
+EXPORT_SYMBOL_GPL(platform_get_irq_optional);
/**
* platform_irq_count - Count the number of IRQs a platform device uses
--
2.20.1
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply related [flat|nested] 181+ messages in thread
* Re: linux-next: build failure after merge of the driver-core tree
2019-02-01 2:41 Stephen Rothwell
@ 2019-02-01 14:18 ` Greg KH
0 siblings, 0 replies; 181+ messages in thread
From: Greg KH @ 2019-02-01 14:18 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Linux Next Mailing List, Linux Kernel Mailing List, Richard Gong
On Fri, Feb 01, 2019 at 01:41:46PM +1100, Stephen Rothwell wrote:
> Hi Greg,
>
> After merging the driver-core tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
>
> ERROR: "__arm_smccc_hvc" [drivers/firmware/stratix10-svc.ko] undefined!
> ERROR: "__arm_smccc_smc" [drivers/firmware/stratix10-svc.ko] undefined!
>
> Exposed by commit
>
> 095ff29d2b88 ("firmware: intel_stratix10_service: add hardware dependency")
>
> I have added the following partial revert for today:
>
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Fri, 1 Feb 2019 13:37:59 +1100
> Subject: [PATCH] firmware: intel_stratix10_service: remove COMPILE_TEST
>
> This does not build yet ...
>
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> ---
> drivers/firmware/Kconfig | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/firmware/Kconfig b/drivers/firmware/Kconfig
> index 7e5491aed5c8..cac16c4b0df3 100644
> --- a/drivers/firmware/Kconfig
> +++ b/drivers/firmware/Kconfig
> @@ -218,7 +218,7 @@ config FW_CFG_SYSFS_CMDLINE
>
> config INTEL_STRATIX10_SERVICE
> tristate "Intel Stratix10 Service Layer"
> - depends on (ARCH_STRATIX10 && HAVE_ARM_SMCCC) || COMPILE_TEST
> + depends on ARCH_STRATIX10 && HAVE_ARM_SMCCC
> default n
> help
> Intel Stratix10 service layer runs at privileged exception level,
> --
> 2.20.1
>
> --
> Cheers,
> Stephen Rothwell
Thanks, I've added this to my tree now.
greg k-h
^ permalink raw reply [flat|nested] 181+ messages in thread
* linux-next: build failure after merge of the driver-core tree
@ 2019-02-01 2:41 Stephen Rothwell
2019-02-01 14:18 ` Greg KH
0 siblings, 1 reply; 181+ messages in thread
From: Stephen Rothwell @ 2019-02-01 2:41 UTC (permalink / raw)
To: Greg KH; +Cc: Linux Next Mailing List, Linux Kernel Mailing List, Richard Gong
[-- Attachment #1: Type: text/plain, Size: 1310 bytes --]
Hi Greg,
After merging the driver-core tree, today's linux-next build (x86_64
allmodconfig) failed like this:
ERROR: "__arm_smccc_hvc" [drivers/firmware/stratix10-svc.ko] undefined!
ERROR: "__arm_smccc_smc" [drivers/firmware/stratix10-svc.ko] undefined!
Exposed by commit
095ff29d2b88 ("firmware: intel_stratix10_service: add hardware dependency")
I have added the following partial revert for today:
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Fri, 1 Feb 2019 13:37:59 +1100
Subject: [PATCH] firmware: intel_stratix10_service: remove COMPILE_TEST
This does not build yet ...
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
drivers/firmware/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/firmware/Kconfig b/drivers/firmware/Kconfig
index 7e5491aed5c8..cac16c4b0df3 100644
--- a/drivers/firmware/Kconfig
+++ b/drivers/firmware/Kconfig
@@ -218,7 +218,7 @@ config FW_CFG_SYSFS_CMDLINE
config INTEL_STRATIX10_SERVICE
tristate "Intel Stratix10 Service Layer"
- depends on (ARCH_STRATIX10 && HAVE_ARM_SMCCC) || COMPILE_TEST
+ depends on ARCH_STRATIX10 && HAVE_ARM_SMCCC
default n
help
Intel Stratix10 service layer runs at privileged exception level,
--
2.20.1
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply related [flat|nested] 181+ messages in thread
* Re: linux-next: build failure after merge of the driver-core tree
2017-06-13 6:20 ` Greg KH
2017-06-13 6:25 ` Stephen Rothwell
@ 2017-06-13 6:30 ` Sergey Senozhatsky
1 sibling, 0 replies; 181+ messages in thread
From: Sergey Senozhatsky @ 2017-06-13 6:30 UTC (permalink / raw)
To: Greg KH
Cc: Stephen Rothwell, Linux-Next Mailing List,
Linux Kernel Mailing List, Sergey Senozhatsky
On (06/13/17 08:20), Greg KH wrote:
> On Tue, Jun 13, 2017 at 04:04:18PM +1000, Stephen Rothwell wrote:
> > Hi Greg,
> >
> > After merging the driver-core tree, today's linux-next build (x86_64
> > allmodconfig) failed like this:
> >
> > drivers/block/zram/zram_drv.c:1296:28: error: expected ')' before numeric constant
> > static CLASS_ATTR(hot_add, 0400, hot_add_show, NULL);
> > ^
> > drivers/block/zram/zram_drv.c:1330:3: error: 'class_attr_hot_add' undeclared here (not in a function)
> > &class_attr_hot_add.attr,
> > ^
> > drivers/block/zram/zram_drv.c:1282:16: warning: 'hot_add_show' defined but not used [-Wunused-function]
> > static ssize_t hot_add_show(struct class *class,
> > ^
> >
> > Caused by commit
> >
> > 27104a53d02e ("zram: use class_groups instead of class_attrs")
> >
> > I have reverted that commit for today (and commit
> >
> > ecbaa83ee84c ("driver core: remove class_attrs from struct class")
> >
> > temporarily so the the tree will build).
>
> Crap I missed one. I'll go fix that up now so this should work for
> tomorrows linux-next, thanks for letting me know.
>
> Odd that 0-day isn't giving me any failed build reports :(
how did I miss that... I was pretty sure I compile-tested
the patch before I replied... odd... sorry!
thanks for the report, Stephen.
-ss
^ permalink raw reply [flat|nested] 181+ messages in thread
* Re: linux-next: build failure after merge of the driver-core tree
2017-06-13 6:20 ` Greg KH
@ 2017-06-13 6:25 ` Stephen Rothwell
2017-06-13 6:30 ` Sergey Senozhatsky
1 sibling, 0 replies; 181+ messages in thread
From: Stephen Rothwell @ 2017-06-13 6:25 UTC (permalink / raw)
To: Greg KH
Cc: Linux-Next Mailing List, Linux Kernel Mailing List, Sergey Senozhatsky
Hi Greg,
On Tue, 13 Jun 2017 08:20:48 +0200 Greg KH <greg@kroah.com> wrote:
>
> Odd that 0-day isn't giving me any failed build reports :(
Yeah, I wonder if 0-day is doing x86_64 allmodconfig builds regularly ...
--
Cheers,
Stephen Rothwell
^ permalink raw reply [flat|nested] 181+ messages in thread
* Re: linux-next: build failure after merge of the driver-core tree
2017-06-13 6:04 Stephen Rothwell
@ 2017-06-13 6:20 ` Greg KH
2017-06-13 6:25 ` Stephen Rothwell
2017-06-13 6:30 ` Sergey Senozhatsky
0 siblings, 2 replies; 181+ messages in thread
From: Greg KH @ 2017-06-13 6:20 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Linux-Next Mailing List, Linux Kernel Mailing List, Sergey Senozhatsky
On Tue, Jun 13, 2017 at 04:04:18PM +1000, Stephen Rothwell wrote:
> Hi Greg,
>
> After merging the driver-core tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
>
> drivers/block/zram/zram_drv.c:1296:28: error: expected ')' before numeric constant
> static CLASS_ATTR(hot_add, 0400, hot_add_show, NULL);
> ^
> drivers/block/zram/zram_drv.c:1330:3: error: 'class_attr_hot_add' undeclared here (not in a function)
> &class_attr_hot_add.attr,
> ^
> drivers/block/zram/zram_drv.c:1282:16: warning: 'hot_add_show' defined but not used [-Wunused-function]
> static ssize_t hot_add_show(struct class *class,
> ^
>
> Caused by commit
>
> 27104a53d02e ("zram: use class_groups instead of class_attrs")
>
> I have reverted that commit for today (and commit
>
> ecbaa83ee84c ("driver core: remove class_attrs from struct class")
>
> temporarily so the the tree will build).
Crap I missed one. I'll go fix that up now so this should work for
tomorrows linux-next, thanks for letting me know.
Odd that 0-day isn't giving me any failed build reports :(
thanks,
greg k-h
^ permalink raw reply [flat|nested] 181+ messages in thread
* linux-next: build failure after merge of the driver-core tree
@ 2017-06-13 6:04 Stephen Rothwell
2017-06-13 6:20 ` Greg KH
0 siblings, 1 reply; 181+ messages in thread
From: Stephen Rothwell @ 2017-06-13 6:04 UTC (permalink / raw)
To: Greg KH
Cc: Linux-Next Mailing List, Linux Kernel Mailing List, Sergey Senozhatsky
Hi Greg,
After merging the driver-core tree, today's linux-next build (x86_64
allmodconfig) failed like this:
drivers/block/zram/zram_drv.c:1296:28: error: expected ')' before numeric constant
static CLASS_ATTR(hot_add, 0400, hot_add_show, NULL);
^
drivers/block/zram/zram_drv.c:1330:3: error: 'class_attr_hot_add' undeclared here (not in a function)
&class_attr_hot_add.attr,
^
drivers/block/zram/zram_drv.c:1282:16: warning: 'hot_add_show' defined but not used [-Wunused-function]
static ssize_t hot_add_show(struct class *class,
^
Caused by commit
27104a53d02e ("zram: use class_groups instead of class_attrs")
I have reverted that commit for today (and commit
ecbaa83ee84c ("driver core: remove class_attrs from struct class")
temporarily so the the tree will build).
--
Cheers,
Stephen Rothwell
^ permalink raw reply [flat|nested] 181+ messages in thread
* Re: linux-next: build failure after merge of the driver-core tree
2016-05-02 11:40 ` William Breathitt Gray
@ 2016-05-02 14:47 ` Greg KH
0 siblings, 0 replies; 181+ messages in thread
From: Greg KH @ 2016-05-02 14:47 UTC (permalink / raw)
To: William Breathitt Gray
Cc: Stephen Rothwell, linux-next, linux-kernel, Ingo Molnar
On Mon, May 02, 2016 at 07:40:47AM -0400, William Breathitt Gray wrote:
> On Mon, May 02, 2016 at 03:42:58PM +1000, Stephen Rothwell wrote:
> >Hi Greg,
> >
> >After merging the driver-core tree, today's linux-next build (x86_64
> >allmodconfig) failed like this:
> >
> >In file included from include/uapi/linux/stddef.h:1:0,
> > from include/linux/stddef.h:4,
> > from include/uapi/linux/posix_types.h:4,
> > from include/uapi/linux/types.h:13,
> > from include/linux/types.h:5,
> > from include/linux/list.h:4,
> > from include/linux/module.h:9,
> > from arch/x86/mm/extable.c:1:
> >arch/x86/mm/extable.c: In function 'fixup_exception':
> >arch/x86/mm/extable.c:102:15: error: implicit declaration of function 'SEGMENT_IS_PNP_CODE' [-Werror=implicit-function-declaration]
> > if (unlikely(SEGMENT_IS_PNP_CODE(regs->cs))) {
> > ^
> >drivers/pnp/pnpbios/bioscalls.c:106:34: error: 'PNP_TS1' und
> >eclared (first use in this function)
> > Q2_SET_SEL(smp_processor_id(), PNP_TS1, ts1_base, ts1_size);
> > ^
> >drivers/pnp/pnpbios/bioscalls.c:108:34: error: 'PNP_TS2' undeclared (first use in this function)
> > Q2_SET_SEL(smp_processor_id(), PNP_TS2, ts2_base, ts2_size);
> > ^
> >drivers/pnp/pnpbios/bioscalls.c:133:13: error: 'PNP_CS32' undeclared (first use in this function)
> > "i"(PNP_CS32), "i"(0)
> > ^
> >
> >and on ...
> >
> >Somehow caused by commit
> >
> > 8ac0fba2da41 ("isa: Decouple X86_32 dependency from the ISA Kconfig option")
> >
> >I don't easily see why it causes the problem, but reverting it makes the
> >build work. I also cannot rule out interaction with some other tree.
> >
> >I have reverted that commit for today.
> >
> >--
> >Cheers,
> >Stephen Rothwell
>
> The PnP errors are due to an overly broad Kconfig dependency list, and
> are resolved with the following patch:
> <https://lkml.org/lkml/2016/5/1/100>. This patch should be applied first
> to prevent the PnP build for X86_64, when the X86_32 dependency is
> decoupled from the ISA Kconfig option in this current patch.
You didn't tell me that when I applied the above patch :(
I'll go apply the pnp patch now, but really, please be more careful with
dependancies next time.
greg k-h
^ permalink raw reply [flat|nested] 181+ messages in thread
* Re: linux-next: build failure after merge of the driver-core tree
2016-05-02 5:42 Stephen Rothwell
@ 2016-05-02 11:40 ` William Breathitt Gray
2016-05-02 14:47 ` Greg KH
0 siblings, 1 reply; 181+ messages in thread
From: William Breathitt Gray @ 2016-05-02 11:40 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: Greg KH, linux-next, linux-kernel, Ingo Molnar
On Mon, May 02, 2016 at 03:42:58PM +1000, Stephen Rothwell wrote:
>Hi Greg,
>
>After merging the driver-core tree, today's linux-next build (x86_64
>allmodconfig) failed like this:
>
>In file included from include/uapi/linux/stddef.h:1:0,
> from include/linux/stddef.h:4,
> from include/uapi/linux/posix_types.h:4,
> from include/uapi/linux/types.h:13,
> from include/linux/types.h:5,
> from include/linux/list.h:4,
> from include/linux/module.h:9,
> from arch/x86/mm/extable.c:1:
>arch/x86/mm/extable.c: In function 'fixup_exception':
>arch/x86/mm/extable.c:102:15: error: implicit declaration of function 'SEGMENT_IS_PNP_CODE' [-Werror=implicit-function-declaration]
> if (unlikely(SEGMENT_IS_PNP_CODE(regs->cs))) {
> ^
>drivers/pnp/pnpbios/bioscalls.c:106:34: error: 'PNP_TS1' und
>eclared (first use in this function)
> Q2_SET_SEL(smp_processor_id(), PNP_TS1, ts1_base, ts1_size);
> ^
>drivers/pnp/pnpbios/bioscalls.c:108:34: error: 'PNP_TS2' undeclared (first use in this function)
> Q2_SET_SEL(smp_processor_id(), PNP_TS2, ts2_base, ts2_size);
> ^
>drivers/pnp/pnpbios/bioscalls.c:133:13: error: 'PNP_CS32' undeclared (first use in this function)
> "i"(PNP_CS32), "i"(0)
> ^
>
>and on ...
>
>Somehow caused by commit
>
> 8ac0fba2da41 ("isa: Decouple X86_32 dependency from the ISA Kconfig option")
>
>I don't easily see why it causes the problem, but reverting it makes the
>build work. I also cannot rule out interaction with some other tree.
>
>I have reverted that commit for today.
>
>--
>Cheers,
>Stephen Rothwell
The PnP errors are due to an overly broad Kconfig dependency list, and
are resolved with the following patch:
<https://lkml.org/lkml/2016/5/1/100>. This patch should be applied first
to prevent the PnP build for X86_64, when the X86_32 dependency is
decoupled from the ISA Kconfig option in this current patch.
See <https://lkml.org/lkml/2016/4/11/421> for the history behind these
two patches.
William Breathitt Gray
^ permalink raw reply [flat|nested] 181+ messages in thread
* linux-next: build failure after merge of the driver-core tree
@ 2016-05-02 5:42 Stephen Rothwell
2016-05-02 11:40 ` William Breathitt Gray
0 siblings, 1 reply; 181+ messages in thread
From: Stephen Rothwell @ 2016-05-02 5:42 UTC (permalink / raw)
To: Greg KH; +Cc: linux-next, linux-kernel, William Breathitt Gray, Ingo Molnar
Hi Greg,
After merging the driver-core tree, today's linux-next build (x86_64
allmodconfig) failed like this:
In file included from include/uapi/linux/stddef.h:1:0,
from include/linux/stddef.h:4,
from include/uapi/linux/posix_types.h:4,
from include/uapi/linux/types.h:13,
from include/linux/types.h:5,
from include/linux/list.h:4,
from include/linux/module.h:9,
from arch/x86/mm/extable.c:1:
arch/x86/mm/extable.c: In function 'fixup_exception':
arch/x86/mm/extable.c:102:15: error: implicit declaration of function 'SEGMENT_IS_PNP_CODE' [-Werror=implicit-function-declaration]
if (unlikely(SEGMENT_IS_PNP_CODE(regs->cs))) {
^
drivers/pnp/pnpbios/bioscalls.c:106:34: error: 'PNP_TS1' und
eclared (first use in this function)
Q2_SET_SEL(smp_processor_id(), PNP_TS1, ts1_base, ts1_size);
^
drivers/pnp/pnpbios/bioscalls.c:108:34: error: 'PNP_TS2' undeclared (first use in this function)
Q2_SET_SEL(smp_processor_id(), PNP_TS2, ts2_base, ts2_size);
^
drivers/pnp/pnpbios/bioscalls.c:133:13: error: 'PNP_CS32' undeclared (first use in this function)
"i"(PNP_CS32), "i"(0)
^
and on ...
Somehow caused by commit
8ac0fba2da41 ("isa: Decouple X86_32 dependency from the ISA Kconfig option")
I don't easily see why it causes the problem, but reverting it makes the
build work. I also cannot rule out interaction with some other tree.
I have reverted that commit for today.
--
Cheers,
Stephen Rothwell
^ permalink raw reply [flat|nested] 181+ messages in thread
* linux-next: build failure after merge of the driver-core tree
@ 2015-05-21 7:52 Stephen Rothwell
0 siblings, 0 replies; 181+ messages in thread
From: Stephen Rothwell @ 2015-05-21 7:52 UTC (permalink / raw)
To: Greg KH; +Cc: linux-next, linux-kernel, Luis R. Rodriguez, Dmitry Torokhov
[-- Attachment #1: Type: text/plain, Size: 1330 bytes --]
Hi Greg,
After merging the driver-core tree, today's linux-next build (powerpc
allnoconfig) failed like this:
drivers/base/dd.c: In function 'driver_allows_async_probing':
drivers/base/dd.c:430:31: error: dereferencing pointer to incomplete type
if (drv->owner && drv->owner->async_probe_requested)
^
Caused by commit f2411da74698 ("driver-core: add driver module
asynchronous probe support").
I have applied the following fix patch for today:
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Thu, 21 May 2015 17:44:10 +1000
Subject: [PATCH] driver-core: add driver module asynchronous probe support fix
struct module is not defined if CONFIG_MODULES is not set.
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
drivers/base/dd.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/base/dd.c b/drivers/base/dd.c
index 39292535c74e..12e120ddbc34 100644
--- a/drivers/base/dd.c
+++ b/drivers/base/dd.c
@@ -427,8 +427,10 @@ bool driver_allows_async_probing(struct device_driver *drv)
return false;
default:
+#ifdef CONFIG_MODULES
if (drv->owner && drv->owner->async_probe_requested)
return true;
+#endif
return false;
}
--
2.1.4
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply related [flat|nested] 181+ messages in thread
* linux-next: build failure after merge of the driver-core tree
@ 2014-12-01 7:49 Stephen Rothwell
0 siblings, 0 replies; 181+ messages in thread
From: Stephen Rothwell @ 2014-12-01 7:49 UTC (permalink / raw)
To: Greg KH; +Cc: linux-next, linux-kernel
[-- Attachment #1: Type: text/plain, Size: 1461 bytes --]
Hi Greg,
After merging the driver-core tree, today's linux-next build (arm
multi_v7_defconfig) failed like this:
fs/debugfs/file.c:797:16: error: conflicting types for 'debugfs_create_devm_seqfile'
struct dentry *debugfs_create_devm_seqfile(struct device *dev, const char *name,
^
In file included from fs/debugfs/file.c:21:0:
include/linux/debugfs.h:102:16: note: previous declaration of 'debugfs_create_devm_seqfile' was here
struct dentry *debugfs_create_devm_seqfile(struct device *dev, const char *name,
^
Caused by commit 98210b7f73f1 ("debugfs: add helper function to create
device related seq_file") but I am not sure how ... it seems to be
related to the warning I reported earlier as the following patch fixes
it (and the warnings).
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Mon, 1 Dec 2014 18:42:52 +1100
Subject: [PATCH] debugfs: predeclare struct device
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
include/linux/debugfs.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/include/linux/debugfs.h b/include/linux/debugfs.h
index d145287c0e44..37b17d95d648 100644
--- a/include/linux/debugfs.h
+++ b/include/linux/debugfs.h
@@ -21,6 +21,7 @@
#include <linux/types.h>
struct file_operations;
+struct device;
struct debugfs_blob_wrapper {
void *data;
--
2.1.3
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply related [flat|nested] 181+ messages in thread
* Re: linux-next: build failure after merge of the driver-core tree
2014-05-28 8:03 Stephen Rothwell
@ 2014-05-28 9:30 ` Jean Delvare
0 siblings, 0 replies; 181+ messages in thread
From: Jean Delvare @ 2014-05-28 9:30 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: Greg KH, linux-next, linux-kernel
Hi Stephen, Greg,
Le Wednesday 28 May 2014 à 18:03 +1000, Stephen Rothwell a écrit :
> Hi Greg,
>
> After merging the driver-core tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
>
> drivers/crypto/nx/nx-842.c: In function 'nx842_probe':
> drivers/crypto/nx/nx-842.c:1200:6: error: void value not ignored as it ought to be
> if (dev_set_drvdata(&viodev->dev, rcu_dereference(devdata))) {
> ^
>
> Caused by commit 2c1f1ff0f0d9 ("driver core: dev_set_drvdata returns
> void"). Grep is better than hope :-)
Oops, that would be my fault, sorry. I did grep for such cases but my
grep command must have been poor, I only caught 2 of the 3 cases in the
kernel tree. And make allmodconfig didn't help as the driver is
ppc64-specific.
I'll send a fix-up patch immediately, sorry for the trouble.
--
Jean Delvare
SUSE L3 Support
^ permalink raw reply [flat|nested] 181+ messages in thread
* linux-next: build failure after merge of the driver-core tree
@ 2014-05-28 8:03 Stephen Rothwell
2014-05-28 9:30 ` Jean Delvare
0 siblings, 1 reply; 181+ messages in thread
From: Stephen Rothwell @ 2014-05-28 8:03 UTC (permalink / raw)
To: Greg KH, Jean Delvare; +Cc: linux-next, linux-kernel
[-- Attachment #1: Type: text/plain, Size: 587 bytes --]
Hi Greg,
After merging the driver-core tree, today's linux-next build (powerpc
ppc64_defconfig) failed like this:
drivers/crypto/nx/nx-842.c: In function 'nx842_probe':
drivers/crypto/nx/nx-842.c:1200:6: error: void value not ignored as it ought to be
if (dev_set_drvdata(&viodev->dev, rcu_dereference(devdata))) {
^
Caused by commit 2c1f1ff0f0d9 ("driver core: dev_set_drvdata returns
void"). Grep is better than hope :-)
I have used the driver-core tree from next-20140527 for today.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 181+ messages in thread
* Re: linux-next: build failure after merge of the driver-core tree
2014-03-18 0:22 ` Benjamin Herrenschmidt
@ 2014-03-18 15:58 ` Tejun Heo
0 siblings, 0 replies; 181+ messages in thread
From: Tejun Heo @ 2014-03-18 15:58 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Greg KH, Stephen Rothwell, Mark Brown, Stewart Smith, linux-next,
linux-kernel
Hello, Ben.
On Tue, Mar 18, 2014 at 11:22:26AM +1100, Benjamin Herrenschmidt wrote:
> On Mon, 2014-03-17 at 18:21 -0400, Tejun Heo wrote:
> > So, looked at the failed code. The only necessary change seems to be
> > calling device_remove_file_self() in dump_ack_store() and then doing
> > kobject_put() directly afterwards, which would have been completely
> > fine as a merge fix patch.
>
> Ok. Since there's no merge error, I'll have to tell Linus explicitly to
> apply it during the merge. I've never done that before but I suppose
> it's doable.
Yeah, that should be fine. For the next tree, including the fix patch
in a temp branch and pulling that into your for-next branch should
work fine.
> Sorry I don't understand. Reverting the removal until after -rc1 (or
> later in the merge window) is the easiest path from my perspective and
> ensure no bisection breakage but whatever Linus prefers works here.
Merge fix doesn't cause any bisection issue either (because it *is* a
merge problem after all). It could be just my personal preference but
I'd handle this one as merge fix. If we rever the removal of the
interface, we'll probably need to mark it deprecated too as people
tend to fork off their devel branches before or at rc1.
> I don't think it's a drastic action or anything like that. It can
> trivially be re-applied once the merge window has settled. But I'm happy
> to also just send Linus a "apply this as a merge fixup" patch if he's
> happy with the method (as I said, I've never done that before on
> something that doesn't have an actual merge conflict to begin with)
Sure, either should work.
Thanks.
--
tejun
^ permalink raw reply [flat|nested] 181+ messages in thread
* Re: linux-next: build failure after merge of the driver-core tree
2014-03-17 22:21 ` Tejun Heo
2014-03-18 0:07 ` Stewart Smith
@ 2014-03-18 0:22 ` Benjamin Herrenschmidt
2014-03-18 15:58 ` Tejun Heo
1 sibling, 1 reply; 181+ messages in thread
From: Benjamin Herrenschmidt @ 2014-03-18 0:22 UTC (permalink / raw)
To: Tejun Heo
Cc: Greg KH, Stephen Rothwell, Mark Brown, Stewart Smith, linux-next,
linux-kernel
On Mon, 2014-03-17 at 18:21 -0400, Tejun Heo wrote:
> So, looked at the failed code. The only necessary change seems to be
> calling device_remove_file_self() in dump_ack_store() and then doing
> kobject_put() directly afterwards, which would have been completely
> fine as a merge fix patch.
Ok. Since there's no merge error, I'll have to tell Linus explicitly to
apply it during the merge. I've never done that before but I suppose
it's doable.
> Just to be clear, I'm not necessarily against reverting the removal of
> the API. The removal was based on the speculation that this isn't
> likely to cause trouble. The speculation was perfectly reasonable but
> being a speculation it failed, so we take actions to remedy that and
> we *do* want to do things that way. Reverting the removal can sure be
> one choice but the way that choice is being made here seems completely
> wrong to me. There's no technical evaluation whatsoever. I'd really
> hate to work in an environment where taking active trade off is
> discouraged replaced with blind policy enforcement.
Sorry I don't understand. Reverting the removal until after -rc1 (or
later in the merge window) is the easiest path from my perspective and
ensure no bisection breakage but whatever Linus prefers works here.
I don't think it's a drastic action or anything like that. It can
trivially be re-applied once the merge window has settled. But I'm happy
to also just send Linus a "apply this as a merge fixup" patch if he's
happy with the method (as I said, I've never done that before on
something that doesn't have an actual merge conflict to begin with)
Cheers,
Ben.
^ permalink raw reply [flat|nested] 181+ messages in thread
* Re: linux-next: build failure after merge of the driver-core tree
2014-03-17 21:56 ` Greg KH
2014-03-17 22:05 ` Tejun Heo
2014-03-18 0:00 ` Stewart Smith
@ 2014-03-18 0:16 ` Benjamin Herrenschmidt
2 siblings, 0 replies; 181+ messages in thread
From: Benjamin Herrenschmidt @ 2014-03-18 0:16 UTC (permalink / raw)
To: Greg KH
Cc: Stephen Rothwell, Mark Brown, Stewart Smith, Tejun Heo,
linux-next, linux-kernel
[-- Attachment #1: Type: text/plain, Size: 1432 bytes --]
On Mon, 2014-03-17 at 14:56 -0700, Greg KH wrote:
> No you can't, sorry.
>
> And this seems like a huge abuse of sysfs, you better be using binary
> sysfs files for your log data...
>
> Do you have a pointer to where you document this sysfs api in
> Documentation/ABI/ ?
Yes, the patch adds the documentation along with the facility, I've
attached the doc file to this email.
This is a wrapper on top of firmware interfaces, in a way we are
following ACPI precedent of exposing a bunch of things via sysfs, which
also happen to be a simple and very convenient way of doing it.
The log itself is a binary attribute in PEL format (or SEL when we
support that), we have a userspace parser.
> > Now regarding the practicals of sorting out our trees, Stephen suggested
> > that rather than doing anything on my side (heh, I like that !), you
> > should revert the last patch of the series, the one removing the old
> > API, in your tree.
> >
> > It can then be re-applied later around rc1.
>
> I'll look to see if we can do that, let me dig it up out of my tree...
Thanks. That's how Stephen is fixing it up in -next at the moment.
Cheers,
Ben.
> thanks,
>
> greg k-h
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
[-- Attachment #2: sysfs-firmware-opal-elog --]
[-- Type: text/plain, Size: 2207 bytes --]
What: /sys/firmware/opal/elog
Date: Feb 2014
Contact: Stewart Smith <stewart@linux.vnet.ibm.com>
Description:
This directory exposes error log entries retrieved
through the OPAL firmware interface.
Each error log is identified by a unique ID and will
exist until explicitly acknowledged to firmware.
Each log entry has a directory in /sys/firmware/opal/elog.
Log entries may be purged by the service processor
before retrieved by firmware or retrieved/acknowledged by
Linux if there is no room for more log entries.
In the event that Linux has retrieved the log entries
but not explicitly acknowledged them to firmware and
the service processor needs more room for log entries,
the only remaining copy of a log message may be in
Linux.
Typically, a user space daemon will monitor for new
entries, read them out and acknowledge them.
The service processor may be able to store more log
entries than firmware can, so after you acknowledge
an event from Linux you may instantly get another one
from the queue that was generated some time in the past.
The raw log format is a binary format. We currently
do not parse this at all in kernel, leaving it up to
user space to solve the problem. In future, we may
do more parsing in kernel and add more files to make
it easier for simple user space processes to extract
more information.
For each log entry (directory), there are the following
files:
id: An ASCII representation of the ID of the
error log, in hex - e.g. "0x01".
type: An ASCII representation of the type id and
description of the type of error log.
Currently just "0x00 PEL" - platform error log.
In the future there may be additional types.
raw: A read-only binary file that can be read
to get the raw log entry. These are
<16kb, often just hundreds of bytes and
"average" 2kb.
acknowledge: Writing 'ack' to this file will acknowledge
the error log to firmware (and in turn
the service processor, if applicable).
Shortly after acknowledging it, the log
entry will be removed from sysfs.
Reading this file will list the supported
operations (curently just acknowledge).
^ permalink raw reply [flat|nested] 181+ messages in thread
* Re: linux-next: build failure after merge of the driver-core tree
2014-03-17 22:21 ` Tejun Heo
@ 2014-03-18 0:07 ` Stewart Smith
2014-03-18 0:22 ` Benjamin Herrenschmidt
1 sibling, 0 replies; 181+ messages in thread
From: Stewart Smith @ 2014-03-18 0:07 UTC (permalink / raw)
To: Tejun Heo, Greg KH
Cc: Benjamin Herrenschmidt, Stephen Rothwell, Mark Brown, linux-next,
linux-kernel
Tejun Heo <tj@kernel.org> writes:
> On Mon, Mar 17, 2014 at 06:05:54PM -0400, Tejun Heo wrote:
>> I think this is being blown out of proportion. It was a rarely used
>> API and converting to the new one is mostly trivial which can be
>
> So, looked at the failed code. The only necessary change seems to be
> calling device_remove_file_self() in dump_ack_store() and then doing
> kobject_put() directly afterwards, which would have been completely
> fine as a merge fix patch.
I had a quick look too and this seems correct (at least if my reading on
howto use sysfs APIs is correct).
I'm happy to post a patch somewhere - I guess it's easiest if the
removal waits for one linus merge things cycle and then I can get fix
and removal in? I'm not too fussed.
> Just to be clear, I'm not necessarily against reverting the removal of
> the API. The removal was based on the speculation that this isn't
> likely to cause trouble. The speculation was perfectly reasonable but
> being a speculation it failed, so we take actions to remedy that and
> we *do* want to do things that way. Reverting the removal can sure be
> one choice but the way that choice is being made here seems completely
> wrong to me. There's no technical evaluation whatsoever. I'd really
> hate to work in an environment where taking active trade off is
> discouraged replaced with blind policy enforcement.
I use an API and it changes/disappears - it's a gift I have :)
^ permalink raw reply [flat|nested] 181+ messages in thread
* Re: linux-next: build failure after merge of the driver-core tree
2014-03-17 21:56 ` Greg KH
2014-03-17 22:05 ` Tejun Heo
@ 2014-03-18 0:00 ` Stewart Smith
2014-03-18 0:16 ` Benjamin Herrenschmidt
2 siblings, 0 replies; 181+ messages in thread
From: Stewart Smith @ 2014-03-18 0:00 UTC (permalink / raw)
To: Greg KH, Benjamin Herrenschmidt
Cc: Stephen Rothwell, Mark Brown, Tejun Heo, linux-next, linux-kernel
Greg KH <greg@kroah.com> writes:
> On Tue, Mar 18, 2014 at 07:33:30AM +1100, Benjamin Herrenschmidt wrote:
>> On Mon, 2014-03-17 at 11:33 -0700, Greg KH wrote:
>>
>> > There were only 3 (or 4), users of this api, and no new ones had been
>> > added in _years_, it's a very obscure thing, and odds are, it wouldn't
>> > ever be added again, especially as it was just removed entirely not
>> > being needed anymore. And I'd argue, it's something that you shouldn't
>> > have even been doing in the first place, so why a new user of it was
>> > added now is quite strange to me.
>>
>> Actually that's a good question. Is there a better way for us than to
>> use this API ? Essentially we use that because it's our understanding
>> that it is what is needed for a sysfs file that can remove its parent
>> directory from within a write() op.
>>
>> We followed the driver "remove" implementation as an example.
>>
>> The reason the opal elog and dump patches use it is that those two
>> patches add sysfs interface that represent the error logs (and platform
>> dumps but you can treat the latter as some kind of special case of error
>> logs) from the service processor in sysfs.
>>
>> So for each log we create a dir (kobject) which we populate with a few
>> things like the log unique ID, raw data, etc.... and a file that can be
>> used to "ack" the log with the service processor.
>>
>> The latter has the effect of removing it. This is done by the collection
>> daemon after it has confirmed that the error log has been stored to disk
>> and properly flushed.
>>
>> Is there a better interface ? Can we implement for example unlink() on
>> the kobject itself ? IE. Do the ack by essentially having userspace rm
>> the directory ? :-)
>
> No you can't, sorry.
>
> And this seems like a huge abuse of sysfs, you better be using binary
> sysfs files for your log data...
We are. It's a binary format we get from the service processor that we
then parse in userspace.
Seeing as each of these log entries is a separate thing that can be
retrieved and acknowledged to the service processor, it seemed fitting
to have each of them exposed to userspace so that policy can be dictated
there (acking them removes them from FSP and we have use cases for
peeking at them)
If there's a better way, I'd be interested in hearing it - it appeared
to be relatively good fit for sysfs (no sysadmin overhead, busybox has
enough utility to semi-meaningfully poke at it).
> Do you have a pointer to where you document this sysfs api in
> Documentation/ABI/ ?
Yes:
- Documentation/ABI/stable/sysfs-firmware-opal-dump
- Documentation/ABI/stable/sysfs-firmware-opal-elog
>> Now regarding the practicals of sorting out our trees, Stephen suggested
>> that rather than doing anything on my side (heh, I like that !), you
>> should revert the last patch of the series, the one removing the old
>> API, in your tree.
>>
>> It can then be re-applied later around rc1.
>
> I'll look to see if we can do that, let me dig it up out of my tree...
Thanks. The new API looks like it should work fine for us, I'll be sure
to covert my API usage and let you know.
^ permalink raw reply [flat|nested] 181+ messages in thread
* Re: linux-next: build failure after merge of the driver-core tree
2014-03-17 22:05 ` Tejun Heo
@ 2014-03-17 22:21 ` Tejun Heo
2014-03-18 0:07 ` Stewart Smith
2014-03-18 0:22 ` Benjamin Herrenschmidt
0 siblings, 2 replies; 181+ messages in thread
From: Tejun Heo @ 2014-03-17 22:21 UTC (permalink / raw)
To: Greg KH
Cc: Benjamin Herrenschmidt, Stephen Rothwell, Mark Brown,
Stewart Smith, linux-next, linux-kernel
On Mon, Mar 17, 2014 at 06:05:54PM -0400, Tejun Heo wrote:
> I think this is being blown out of proportion. It was a rarely used
> API and converting to the new one is mostly trivial which can be
So, looked at the failed code. The only necessary change seems to be
calling device_remove_file_self() in dump_ack_store() and then doing
kobject_put() directly afterwards, which would have been completely
fine as a merge fix patch.
Just to be clear, I'm not necessarily against reverting the removal of
the API. The removal was based on the speculation that this isn't
likely to cause trouble. The speculation was perfectly reasonable but
being a speculation it failed, so we take actions to remedy that and
we *do* want to do things that way. Reverting the removal can sure be
one choice but the way that choice is being made here seems completely
wrong to me. There's no technical evaluation whatsoever. I'd really
hate to work in an environment where taking active trade off is
discouraged replaced with blind policy enforcement.
Thanks.
--
tejun
^ permalink raw reply [flat|nested] 181+ messages in thread
* Re: linux-next: build failure after merge of the driver-core tree
2014-03-17 21:56 ` Greg KH
@ 2014-03-17 22:05 ` Tejun Heo
2014-03-17 22:21 ` Tejun Heo
2014-03-18 0:00 ` Stewart Smith
2014-03-18 0:16 ` Benjamin Herrenschmidt
2 siblings, 1 reply; 181+ messages in thread
From: Tejun Heo @ 2014-03-17 22:05 UTC (permalink / raw)
To: Greg KH
Cc: Benjamin Herrenschmidt, Stephen Rothwell, Mark Brown,
Stewart Smith, linux-next, linux-kernel
Hello,
On Mon, Mar 17, 2014 at 02:56:19PM -0700, Greg KH wrote:
> > Now regarding the practicals of sorting out our trees, Stephen suggested
> > that rather than doing anything on my side (heh, I like that !), you
> > should revert the last patch of the series, the one removing the old
> > API, in your tree.
> >
> > It can then be re-applied later around rc1.
>
> I'll look to see if we can do that, let me dig it up out of my tree...
I think this is being blown out of proportion. It was a rarely used
API and converting to the new one is mostly trivial which can be
easily done as a merge fix, which is what it is. Seriously, following
protocols is beneficial upto certain point but we don't want DMV level
beaurocracy in handling patches and there's something wrong when the
first questions for merge conflict in devel branches which comes up
are not "what's this change and what would it take to resolve it?" but
those of strict adherences to protocol.
Can we please take a step back and look at what we're doing? This was
a change of API which was used very obscure and haven't seen new users
for years. It is well within the scope of normal (and efficient)
patch routing to route it directly without separate staging release.
It sure developed a conflict but there's nothing wrong to that. We
don't even want to try to eliminate all the conflicts. That'd be a
lot of extra effort for no actual gain and simply a stupid trade-off.
This is a merge conflict well with in the scope of what we can expect
to happen with distributed development and this whole thing works as
well as it does only because we can make *sensible* trade offs not
only in code itself but also in how we resolve conflicts among
different branches.
Thanks.
--
tejun
^ permalink raw reply [flat|nested] 181+ messages in thread
* Re: linux-next: build failure after merge of the driver-core tree
2014-03-17 20:33 ` Benjamin Herrenschmidt
@ 2014-03-17 21:56 ` Greg KH
2014-03-17 22:05 ` Tejun Heo
` (2 more replies)
0 siblings, 3 replies; 181+ messages in thread
From: Greg KH @ 2014-03-17 21:56 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Stephen Rothwell, Mark Brown, Stewart Smith, Tejun Heo,
linux-next, linux-kernel
On Tue, Mar 18, 2014 at 07:33:30AM +1100, Benjamin Herrenschmidt wrote:
> On Mon, 2014-03-17 at 11:33 -0700, Greg KH wrote:
>
> > There were only 3 (or 4), users of this api, and no new ones had been
> > added in _years_, it's a very obscure thing, and odds are, it wouldn't
> > ever be added again, especially as it was just removed entirely not
> > being needed anymore. And I'd argue, it's something that you shouldn't
> > have even been doing in the first place, so why a new user of it was
> > added now is quite strange to me.
>
> Actually that's a good question. Is there a better way for us than to
> use this API ? Essentially we use that because it's our understanding
> that it is what is needed for a sysfs file that can remove its parent
> directory from within a write() op.
>
> We followed the driver "remove" implementation as an example.
>
> The reason the opal elog and dump patches use it is that those two
> patches add sysfs interface that represent the error logs (and platform
> dumps but you can treat the latter as some kind of special case of error
> logs) from the service processor in sysfs.
>
> So for each log we create a dir (kobject) which we populate with a few
> things like the log unique ID, raw data, etc.... and a file that can be
> used to "ack" the log with the service processor.
>
> The latter has the effect of removing it. This is done by the collection
> daemon after it has confirmed that the error log has been stored to disk
> and properly flushed.
>
> Is there a better interface ? Can we implement for example unlink() on
> the kobject itself ? IE. Do the ack by essentially having userspace rm
> the directory ? :-)
No you can't, sorry.
And this seems like a huge abuse of sysfs, you better be using binary
sysfs files for your log data...
Do you have a pointer to where you document this sysfs api in
Documentation/ABI/ ?
> Now regarding the practicals of sorting out our trees, Stephen suggested
> that rather than doing anything on my side (heh, I like that !), you
> should revert the last patch of the series, the one removing the old
> API, in your tree.
>
> It can then be re-applied later around rc1.
I'll look to see if we can do that, let me dig it up out of my tree...
thanks,
greg k-h
^ permalink raw reply [flat|nested] 181+ messages in thread
* Re: linux-next: build failure after merge of the driver-core tree
2014-03-17 18:33 ` Greg KH
@ 2014-03-17 20:33 ` Benjamin Herrenschmidt
2014-03-17 21:56 ` Greg KH
0 siblings, 1 reply; 181+ messages in thread
From: Benjamin Herrenschmidt @ 2014-03-17 20:33 UTC (permalink / raw)
To: Greg KH
Cc: Stephen Rothwell, Mark Brown, Stewart Smith, Tejun Heo,
linux-next, linux-kernel
On Mon, 2014-03-17 at 11:33 -0700, Greg KH wrote:
> There were only 3 (or 4), users of this api, and no new ones had been
> added in _years_, it's a very obscure thing, and odds are, it wouldn't
> ever be added again, especially as it was just removed entirely not
> being needed anymore. And I'd argue, it's something that you shouldn't
> have even been doing in the first place, so why a new user of it was
> added now is quite strange to me.
Actually that's a good question. Is there a better way for us than to
use this API ? Essentially we use that because it's our understanding
that it is what is needed for a sysfs file that can remove its parent
directory from within a write() op.
We followed the driver "remove" implementation as an example.
The reason the opal elog and dump patches use it is that those two
patches add sysfs interface that represent the error logs (and platform
dumps but you can treat the latter as some kind of special case of error
logs) from the service processor in sysfs.
So for each log we create a dir (kobject) which we populate with a few
things like the log unique ID, raw data, etc.... and a file that can be
used to "ack" the log with the service processor.
The latter has the effect of removing it. This is done by the collection
daemon after it has confirmed that the error log has been stored to disk
and properly flushed.
Is there a better interface ? Can we implement for example unlink() on
the kobject itself ? IE. Do the ack by essentially having userspace rm
the directory ? :-)
Now regarding the practicals of sorting out our trees, Stephen suggested
that rather than doing anything on my side (heh, I like that !), you
should revert the last patch of the series, the one removing the old
API, in your tree.
It can then be re-applied later around rc1.
Cheers,
Ben.
^ permalink raw reply [flat|nested] 181+ messages in thread
* Re: linux-next: build failure after merge of the driver-core tree
2014-03-16 23:16 ` Stephen Rothwell
@ 2014-03-17 18:36 ` Greg KH
0 siblings, 0 replies; 181+ messages in thread
From: Greg KH @ 2014-03-17 18:36 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Benjamin Herrenschmidt, Tejun Heo, Mark Brown, Stewart Smith,
linux-next, linux-kernel, Linus
On Mon, Mar 17, 2014 at 10:16:21AM +1100, Stephen Rothwell wrote:
> Hi Greg,
>
> On Sat, 15 Mar 2014 05:29:42 +0000 Greg KH <greg@kroah.com> wrote:
> >
> > On Sat, Mar 15, 2014 at 01:57:29PM +1100, Benjamin Herrenschmidt wrote:
> > >
> > > It's messy. Stephen really doesn't like if we pull each other trees like
> > > that unless they are topic branches. He also doesn't like when we keep
> > > pulling Linus in.
> >
> > I only pull Linus in after a -rc in which I have merged patches with him
> > for that "topic". Otherwise I end up with merge issues, and for testing
> > reasons, I want those fixes from Linus and from me, in order to keep
> > people from hitting the same already-fixes issues.
>
> Maybe you should consider instead just merging the branch you asked
> Linus' to merge instead of back merging his whole -rc ... especially when
> the merge commit message is usually just something like "We want those
> fixes here for testing and development" which doesn't actually tell us
> anything very useful.
>
> Your trees always have lots of back merges of Linus' tree in them and I
> don't know why Linus has not complained about it before now (or at least
> explained to you why we normally don't do that).
No, I don't like merging at "unknown" points in the tree, I only merge
back at the -rc point as that is a "known good" version of Linus's tree.
And I only do the merge if I have patches that have been accepted in
Linus's tree for that tree (usb, staging, tty, etc.) as almost always,
if I don't, I get merge issues (as you find out all the time), and those
bugfixes that go into Linus's tree, I want them in the -next branch as
well so that the developers running those branches don't have the
problems that those fixes resolved.
> > Just take my tree, it's not a big deal,
>
> Except, of course, you are completely discounting any testing that Ben
> has done on his tree that could be invalidated and/or complicated by
> pulling in so much more of Linus' tree at this point of the cycle. And
> it complicates the git history even more than just your trees already do.
If Ben's testing is somehow "invalidated" by moving to a newer -rc
release, then when would that testing have ever happened? -rc merges
should always be safe to do, otherwise you probably have problems in
your code that Linus will later run into when you ask him to pull for
-rc1.
thanks,
greg k-h
^ permalink raw reply [flat|nested] 181+ messages in thread
* Re: linux-next: build failure after merge of the driver-core tree
2014-03-16 23:16 ` Stephen Rothwell
@ 2014-03-17 18:33 ` Greg KH
2014-03-17 20:33 ` Benjamin Herrenschmidt
0 siblings, 1 reply; 181+ messages in thread
From: Greg KH @ 2014-03-17 18:33 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Mark Brown, Stewart Smith, Benjamin Herrenschmidt, Tejun Heo,
linux-next, linux-kernel
On Mon, Mar 17, 2014 at 10:16:11AM +1100, Stephen Rothwell wrote:
> Hi Greg,
>
> On Tue, 11 Mar 2014 18:50:21 -0700 Greg KH <greg@kroah.com> wrote:
> >
> > On Wed, Mar 12, 2014 at 12:51:52AM +0000, Mark Brown wrote:
> > >
> > > After merging the driver-core tree, today's linux-next build ()
> > > failed like this on a PowerPC defconfig:
> > >
> > > HEAD is now at ceb98e684dec Merge remote-tracking branch 'driver-core/driver-core-next'
> > > GEN /home/broonie/next/powerpc_ppc64_defconfig/Makefile
> > > #
> > > # configuration written to .config
> > > #
> > > /home/broonie/next/next/arch/powerpc/platforms/powernv/opal-elog.c: In function 'elog_ack_store':
> > > /home/broonie/next/next/arch/powerpc/platforms/powernv/opal-elog.c:84:2: error: implicit declaration of function 'sysfs_schedule_callback' [-Werror=implicit-function-declaration]
> > > sysfs_schedule_callback(&elog_obj->kobj, delay_release_kobj,
> > > ^
> > > cc1: all warnings being treated as errors
> > > make[3]: *** [arch/powerpc/platforms/powernv/opal-elog.o] Error 1
> > > make[3]: *** Waiting for unfinished jobs....
> > > /home/broonie/next/next/arch/powerpc/platforms/powernv/opal-dump.c: In function 'dump_ack_store':
> > > /home/broonie/next/next/arch/powerpc/platforms/powernv/opal-dump.c:100:2: error: implicit declaration of function 'sysfs_schedule_callback' [-Werror=implicit-function-declaration]
> > > sysfs_schedule_callback(&dump_obj->kobj, delay_release_kobj,
> > > ^
> > > cc1: all warnings being treated as errors
> > >
> > > due to an interaction between d1ba277e7988908 (sysfs, driver-core: remove unused {sysfs|device}_schedule_callback_owner()) and 774fea1a38c6a5a8 (powerpc/powernv: Read OPAL error log and export it through sysfs) from the PowerPC tree.
> > >
> > > I reverted 774fea1a38c6a5a8 for today.
> >
> > Sounds like the powerpc tree also needs to stop using this function :)
>
> So, explain to us in detail why the old interface could not be maintained
> for a release, please. I thought we had become a bit more sophisticated
> about changing core APIs i.e. introduce the new API - fix up all the
> users - keep the old one around if possible for a release (or beyond
> -rc1) to catch the new users.
>
> It may be that there is a good reason not to so this in this case, but it
> is not explained as far as I can see.
There were only 3 (or 4), users of this api, and no new ones had been
added in _years_, it's a very obscure thing, and odds are, it wouldn't
ever be added again, especially as it was just removed entirely not
being needed anymore. And I'd argue, it's something that you shouldn't
have even been doing in the first place, so why a new user of it was
added now is quite strange to me.
thanks,
greg k-h
^ permalink raw reply [flat|nested] 181+ messages in thread
* Re: linux-next: build failure after merge of the driver-core tree
2014-03-12 0:51 Mark Brown
2014-03-12 1:50 ` Greg KH
@ 2014-03-17 8:28 ` Stephen Rothwell
1 sibling, 0 replies; 181+ messages in thread
From: Stephen Rothwell @ 2014-03-17 8:28 UTC (permalink / raw)
To: Greg KH
Cc: Mark Brown, Stewart Smith, Benjamin Herrenschmidt, Tejun Heo,
linux-next, linux-kernel
[-- Attachment #1: Type: text/plain, Size: 1846 bytes --]
Hi all,
On Wed, 12 Mar 2014 00:51:52 +0000 Mark Brown <broonie@kernel.org> wrote:
>
> After merging the driver-core tree, today's linux-next build ()
> failed like this on a PowerPC defconfig:
>
> HEAD is now at ceb98e684dec Merge remote-tracking branch 'driver-core/driver-core-next'
> GEN /home/broonie/next/powerpc_ppc64_defconfig/Makefile
> #
> # configuration written to .config
> #
> /home/broonie/next/next/arch/powerpc/platforms/powernv/opal-elog.c: In function 'elog_ack_store':
> /home/broonie/next/next/arch/powerpc/platforms/powernv/opal-elog.c:84:2: error: implicit declaration of function 'sysfs_schedule_callback' [-Werror=implicit-function-declaration]
> sysfs_schedule_callback(&elog_obj->kobj, delay_release_kobj,
> ^
> cc1: all warnings being treated as errors
> make[3]: *** [arch/powerpc/platforms/powernv/opal-elog.o] Error 1
> make[3]: *** Waiting for unfinished jobs....
> /home/broonie/next/next/arch/powerpc/platforms/powernv/opal-dump.c: In function 'dump_ack_store':
> /home/broonie/next/next/arch/powerpc/platforms/powernv/opal-dump.c:100:2: error: implicit declaration of function 'sysfs_schedule_callback' [-Werror=implicit-function-declaration]
> sysfs_schedule_callback(&dump_obj->kobj, delay_release_kobj,
> ^
> cc1: all warnings being treated as errors
>
> due to an interaction between d1ba277e7988908 (sysfs, driver-core: remove unused {sysfs|device}_schedule_callback_owner()) and 774fea1a38c6a5a8 (powerpc/powernv: Read OPAL error log and export it through sysfs) from the PowerPC tree.
>
> I reverted 774fea1a38c6a5a8 for today.
I instead reverted commit d1ba277e7988908 (sysfs, driver-core: remove
unused {sysfs|device}_schedule_callback_owner()). I hope that will work
as well.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 181+ messages in thread
* Re: linux-next: build failure after merge of the driver-core tree
2014-03-15 5:29 ` Greg KH
2014-03-15 7:14 ` Benjamin Herrenschmidt
@ 2014-03-16 23:16 ` Stephen Rothwell
2014-03-17 18:36 ` Greg KH
1 sibling, 1 reply; 181+ messages in thread
From: Stephen Rothwell @ 2014-03-16 23:16 UTC (permalink / raw)
To: Greg KH
Cc: Benjamin Herrenschmidt, Tejun Heo, Mark Brown, Stewart Smith,
linux-next, linux-kernel, Linus
[-- Attachment #1: Type: text/plain, Size: 1644 bytes --]
Hi Greg,
On Sat, 15 Mar 2014 05:29:42 +0000 Greg KH <greg@kroah.com> wrote:
>
> On Sat, Mar 15, 2014 at 01:57:29PM +1100, Benjamin Herrenschmidt wrote:
> >
> > It's messy. Stephen really doesn't like if we pull each other trees like
> > that unless they are topic branches. He also doesn't like when we keep
> > pulling Linus in.
>
> I only pull Linus in after a -rc in which I have merged patches with him
> for that "topic". Otherwise I end up with merge issues, and for testing
> reasons, I want those fixes from Linus and from me, in order to keep
> people from hitting the same already-fixes issues.
Maybe you should consider instead just merging the branch you asked
Linus' to merge instead of back merging his whole -rc ... especially when
the merge commit message is usually just something like "We want those
fixes here for testing and development" which doesn't actually tell us
anything very useful.
Your trees always have lots of back merges of Linus' tree in them and I
don't know why Linus has not complained about it before now (or at least
explained to you why we normally don't do that).
> Just take my tree, it's not a big deal,
Except, of course, you are completely discounting any testing that Ben
has done on his tree that could be invalidated and/or complicated by
pulling in so much more of Linus' tree at this point of the cycle. And
it complicates the git history even more than just your trees already do.
/me is a bit cross after such a nice holiday in HobbitLand and may need
to take deep breath :-(
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 181+ messages in thread
* Re: linux-next: build failure after merge of the driver-core tree
2014-03-12 1:50 ` Greg KH
2014-03-12 3:55 ` Benjamin Herrenschmidt
@ 2014-03-16 23:16 ` Stephen Rothwell
2014-03-17 18:33 ` Greg KH
1 sibling, 1 reply; 181+ messages in thread
From: Stephen Rothwell @ 2014-03-16 23:16 UTC (permalink / raw)
To: Greg KH
Cc: Mark Brown, Stewart Smith, Benjamin Herrenschmidt, Tejun Heo,
linux-next, linux-kernel
[-- Attachment #1: Type: text/plain, Size: 2824 bytes --]
Hi Greg,
On Tue, 11 Mar 2014 18:50:21 -0700 Greg KH <greg@kroah.com> wrote:
>
> On Wed, Mar 12, 2014 at 12:51:52AM +0000, Mark Brown wrote:
> >
> > After merging the driver-core tree, today's linux-next build ()
> > failed like this on a PowerPC defconfig:
> >
> > HEAD is now at ceb98e684dec Merge remote-tracking branch 'driver-core/driver-core-next'
> > GEN /home/broonie/next/powerpc_ppc64_defconfig/Makefile
> > #
> > # configuration written to .config
> > #
> > /home/broonie/next/next/arch/powerpc/platforms/powernv/opal-elog.c: In function 'elog_ack_store':
> > /home/broonie/next/next/arch/powerpc/platforms/powernv/opal-elog.c:84:2: error: implicit declaration of function 'sysfs_schedule_callback' [-Werror=implicit-function-declaration]
> > sysfs_schedule_callback(&elog_obj->kobj, delay_release_kobj,
> > ^
> > cc1: all warnings being treated as errors
> > make[3]: *** [arch/powerpc/platforms/powernv/opal-elog.o] Error 1
> > make[3]: *** Waiting for unfinished jobs....
> > /home/broonie/next/next/arch/powerpc/platforms/powernv/opal-dump.c: In function 'dump_ack_store':
> > /home/broonie/next/next/arch/powerpc/platforms/powernv/opal-dump.c:100:2: error: implicit declaration of function 'sysfs_schedule_callback' [-Werror=implicit-function-declaration]
> > sysfs_schedule_callback(&dump_obj->kobj, delay_release_kobj,
> > ^
> > cc1: all warnings being treated as errors
> >
> > due to an interaction between d1ba277e7988908 (sysfs, driver-core: remove unused {sysfs|device}_schedule_callback_owner()) and 774fea1a38c6a5a8 (powerpc/powernv: Read OPAL error log and export it through sysfs) from the PowerPC tree.
> >
> > I reverted 774fea1a38c6a5a8 for today.
>
> Sounds like the powerpc tree also needs to stop using this function :)
So, explain to us in detail why the old interface could not be maintained
for a release, please. I thought we had become a bit more sophisticated
about changing core APIs i.e. introduce the new API - fix up all the
users - keep the old one around if possible for a release (or beyond
-rc1) to catch the new users.
It may be that there is a good reason not to so this in this case, but it
is not explained as far as I can see.
Alternatively, it looks as though there may be a fairly trivial transform
from using the old interface to using the new one which could be applied
as part of the merge of these two trees (in linux-next and then in Linus'
tree during the merge window). Maybe you or Tejun should have explained
that and provided a prototype for the merge fix up.
Greg, you are doing core infrastructure changes in your trees - you need
to consider that new usages may be introduced while those changes are
ongoing.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 181+ messages in thread
* Re: linux-next: build failure after merge of the driver-core tree
2014-03-15 5:29 ` Greg KH
@ 2014-03-15 7:14 ` Benjamin Herrenschmidt
2014-03-16 23:16 ` Stephen Rothwell
1 sibling, 0 replies; 181+ messages in thread
From: Benjamin Herrenschmidt @ 2014-03-15 7:14 UTC (permalink / raw)
To: Greg KH; +Cc: Tejun Heo, Mark Brown, Stewart Smith, linux-next, linux-kernel
On Sat, 2014-03-15 at 05:29 +0000, Greg KH wrote:
> Just take my tree, it's not a big deal, I'll merge first with Linus if
> you want and then everything is simple.
Yup, I'll do that. Thanks.
Cheers,
Ben.
^ permalink raw reply [flat|nested] 181+ messages in thread
* Re: linux-next: build failure after merge of the driver-core tree
2014-03-15 2:57 ` Benjamin Herrenschmidt
@ 2014-03-15 5:29 ` Greg KH
2014-03-15 7:14 ` Benjamin Herrenschmidt
2014-03-16 23:16 ` Stephen Rothwell
0 siblings, 2 replies; 181+ messages in thread
From: Greg KH @ 2014-03-15 5:29 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Tejun Heo, Mark Brown, Stewart Smith, linux-next, linux-kernel
On Sat, Mar 15, 2014 at 01:57:29PM +1100, Benjamin Herrenschmidt wrote:
> On Sat, 2014-03-15 at 00:03 +0000, Greg KH wrote:
> > On Fri, Mar 14, 2014 at 09:14:55AM +1100, Benjamin Herrenschmidt wrote:
> > > On Thu, 2014-03-13 at 11:37 +1100, Benjamin Herrenschmidt wrote:
> > > > On Wed, 2014-03-12 at 16:21 -0400, Tejun Heo wrote:
> > > > > It's a series of rather complex patches. I really don't think
> > > > > duplicating them is a good idea. We can either resurrect the old API
> > > > > to kill it again or set up a merge branch which I don't think is too
> > > > > unusual in situations like this.
> > > >
> > > > Right, a topic branch that gets merged in both driver-core-next and
> > > > powerpc-next.
> > >
> > > Just want to make sure we agree ... ie, the offending commit is already
> > > in powerpc-next on my side and I can't really back it out (I could
> > > revert it though).
> >
> > You can pull in driver-core-next into your tree if you want, it's not
> > going to be reverted, and will be sent to Linus for 3.15-rc1, so you can
> > base your work on it and fix up the api usage in your tree that way.
>
> It's messy. Stephen really doesn't like if we pull each other trees like
> that unless they are topic branches. He also doesn't like when we keep
> pulling Linus in.
I only pull Linus in after a -rc in which I have merged patches with him
for that "topic". Otherwise I end up with merge issues, and for testing
reasons, I want those fixes from Linus and from me, in order to keep
people from hitting the same already-fixes issues.
> For example I purposefully kept powerpc -next on top of rc2. You seem to
> regularly merge subsequent rc's into driver-core-next. So by pulling
> your tree I would bring a whole lot of stuff on top of mine, which is
> fine by git but makes histories more complicated and annoys Stephen.
>
> I might still do it this time around, because the other solution for me
> is revert + re-apply with fixups on top of a separate branch itself
> derived from driver-core-next and send multiple pull requests to Linus,
> and that's messy too. The question is which one is more :-)
Just take my tree, it's not a big deal, I'll merge first with Linus if
you want and then everything is simple.
thanks,
greg k-h-
^ permalink raw reply [flat|nested] 181+ messages in thread
* Re: linux-next: build failure after merge of the driver-core tree
2014-03-15 0:03 ` Greg KH
@ 2014-03-15 2:57 ` Benjamin Herrenschmidt
2014-03-15 5:29 ` Greg KH
0 siblings, 1 reply; 181+ messages in thread
From: Benjamin Herrenschmidt @ 2014-03-15 2:57 UTC (permalink / raw)
To: Greg KH; +Cc: Tejun Heo, Mark Brown, Stewart Smith, linux-next, linux-kernel
On Sat, 2014-03-15 at 00:03 +0000, Greg KH wrote:
> On Fri, Mar 14, 2014 at 09:14:55AM +1100, Benjamin Herrenschmidt wrote:
> > On Thu, 2014-03-13 at 11:37 +1100, Benjamin Herrenschmidt wrote:
> > > On Wed, 2014-03-12 at 16:21 -0400, Tejun Heo wrote:
> > > > It's a series of rather complex patches. I really don't think
> > > > duplicating them is a good idea. We can either resurrect the old API
> > > > to kill it again or set up a merge branch which I don't think is too
> > > > unusual in situations like this.
> > >
> > > Right, a topic branch that gets merged in both driver-core-next and
> > > powerpc-next.
> >
> > Just want to make sure we agree ... ie, the offending commit is already
> > in powerpc-next on my side and I can't really back it out (I could
> > revert it though).
>
> You can pull in driver-core-next into your tree if you want, it's not
> going to be reverted, and will be sent to Linus for 3.15-rc1, so you can
> base your work on it and fix up the api usage in your tree that way.
It's messy. Stephen really doesn't like if we pull each other trees like
that unless they are topic branches. He also doesn't like when we keep
pulling Linus in.
For example I purposefully kept powerpc -next on top of rc2. You seem to
regularly merge subsequent rc's into driver-core-next. So by pulling
your tree I would bring a whole lot of stuff on top of mine, which is
fine by git but makes histories more complicated and annoys Stephen.
I might still do it this time around, because the other solution for me
is revert + re-apply with fixups on top of a separate branch itself
derived from driver-core-next and send multiple pull requests to Linus,
and that's messy too. The question is which one is more :-)
Cheers,
Ben.
> thanks,
>
> greg k-h
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [flat|nested] 181+ messages in thread
* Re: linux-next: build failure after merge of the driver-core tree
2014-03-13 22:14 ` Benjamin Herrenschmidt
2014-03-14 13:00 ` Tejun Heo
@ 2014-03-15 0:03 ` Greg KH
2014-03-15 2:57 ` Benjamin Herrenschmidt
1 sibling, 1 reply; 181+ messages in thread
From: Greg KH @ 2014-03-15 0:03 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Tejun Heo, Mark Brown, Stewart Smith, linux-next, linux-kernel
On Fri, Mar 14, 2014 at 09:14:55AM +1100, Benjamin Herrenschmidt wrote:
> On Thu, 2014-03-13 at 11:37 +1100, Benjamin Herrenschmidt wrote:
> > On Wed, 2014-03-12 at 16:21 -0400, Tejun Heo wrote:
> > > It's a series of rather complex patches. I really don't think
> > > duplicating them is a good idea. We can either resurrect the old API
> > > to kill it again or set up a merge branch which I don't think is too
> > > unusual in situations like this.
> >
> > Right, a topic branch that gets merged in both driver-core-next and
> > powerpc-next.
>
> Just want to make sure we agree ... ie, the offending commit is already
> in powerpc-next on my side and I can't really back it out (I could
> revert it though).
You can pull in driver-core-next into your tree if you want, it's not
going to be reverted, and will be sent to Linus for 3.15-rc1, so you can
base your work on it and fix up the api usage in your tree that way.
thanks,
greg k-h
^ permalink raw reply [flat|nested] 181+ messages in thread
* Re: linux-next: build failure after merge of the driver-core tree
2014-03-13 22:14 ` Benjamin Herrenschmidt
@ 2014-03-14 13:00 ` Tejun Heo
2014-03-15 0:03 ` Greg KH
1 sibling, 0 replies; 181+ messages in thread
From: Tejun Heo @ 2014-03-14 13:00 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Mark Brown, Greg KH, Stewart Smith, linux-next, linux-kernel
Hello,
On Fri, Mar 14, 2014 at 09:14:55AM +1100, Benjamin Herrenschmidt wrote:
> On Thu, 2014-03-13 at 11:37 +1100, Benjamin Herrenschmidt wrote:
> > On Wed, 2014-03-12 at 16:21 -0400, Tejun Heo wrote:
> > > It's a series of rather complex patches. I really don't think
> > > duplicating them is a good idea. We can either resurrect the old API
> > > to kill it again or set up a merge branch which I don't think is too
> > > unusual in situations like this.
> >
> > Right, a topic branch that gets merged in both driver-core-next and
> > powerpc-next.
>
> Just want to make sure we agree ... ie, the offending commit is already
> in powerpc-next on my side and I can't really back it out (I could
> revert it though).
Hmmm... reverting may be an option too but I don't think fixing it
retroactively in a new branch should be okay too.
Thanks.
--
tejun
^ permalink raw reply [flat|nested] 181+ messages in thread
* Re: linux-next: build failure after merge of the driver-core tree
2014-03-13 0:37 ` Benjamin Herrenschmidt
@ 2014-03-13 22:14 ` Benjamin Herrenschmidt
2014-03-14 13:00 ` Tejun Heo
2014-03-15 0:03 ` Greg KH
0 siblings, 2 replies; 181+ messages in thread
From: Benjamin Herrenschmidt @ 2014-03-13 22:14 UTC (permalink / raw)
To: Tejun Heo; +Cc: Mark Brown, Greg KH, Stewart Smith, linux-next, linux-kernel
On Thu, 2014-03-13 at 11:37 +1100, Benjamin Herrenschmidt wrote:
> On Wed, 2014-03-12 at 16:21 -0400, Tejun Heo wrote:
> > It's a series of rather complex patches. I really don't think
> > duplicating them is a good idea. We can either resurrect the old API
> > to kill it again or set up a merge branch which I don't think is too
> > unusual in situations like this.
>
> Right, a topic branch that gets merged in both driver-core-next and
> powerpc-next.
Just want to make sure we agree ... ie, the offending commit is already
in powerpc-next on my side and I can't really back it out (I could
revert it though).
Cheers,
Ben.
^ permalink raw reply [flat|nested] 181+ messages in thread
* Re: linux-next: build failure after merge of the driver-core tree
2014-03-12 20:21 ` Tejun Heo
@ 2014-03-13 0:37 ` Benjamin Herrenschmidt
2014-03-13 22:14 ` Benjamin Herrenschmidt
0 siblings, 1 reply; 181+ messages in thread
From: Benjamin Herrenschmidt @ 2014-03-13 0:37 UTC (permalink / raw)
To: Tejun Heo; +Cc: Mark Brown, Greg KH, Stewart Smith, linux-next, linux-kernel
On Wed, 2014-03-12 at 16:21 -0400, Tejun Heo wrote:
> It's a series of rather complex patches. I really don't think
> duplicating them is a good idea. We can either resurrect the old API
> to kill it again or set up a merge branch which I don't think is too
> unusual in situations like this.
Right, a topic branch that gets merged in both driver-core-next and
powerpc-next.
Cheers,
Ben.
^ permalink raw reply [flat|nested] 181+ messages in thread
* Re: linux-next: build failure after merge of the driver-core tree
2014-03-12 20:14 ` Benjamin Herrenschmidt
@ 2014-03-12 20:21 ` Tejun Heo
2014-03-13 0:37 ` Benjamin Herrenschmidt
0 siblings, 1 reply; 181+ messages in thread
From: Tejun Heo @ 2014-03-12 20:21 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Mark Brown, Greg KH, Stewart Smith, linux-next, linux-kernel
Hello,
On Thu, Mar 13, 2014 at 07:14:52AM +1100, Benjamin Herrenschmidt wrote:
> It's generally consider bad taste to pull entire trees into each
> other :-) I know Stephen isn't fan of it...
I wouldn't say it's considered "generally" bad taste. For one-off
changes, maybe. This was a rather large restructuring of the whole
thing, so actually duplicating all the rather significant commits
would be a lot worse.
> I'd rather have just that series (or even better, just the patches
> introducing the new function) in a topic branch, itself pulled into
> both driver-core-next and my tree.
>
> Can you produce that ? (I need a non-rebase guarantee though).
It's a series of rather complex patches. I really don't think
duplicating them is a good idea. We can either resurrect the old API
to kill it again or set up a merge branch which I don't think is too
unusual in situations like this.
Thanks.
--
tejun
^ permalink raw reply [flat|nested] 181+ messages in thread
* Re: linux-next: build failure after merge of the driver-core tree
2014-03-12 20:02 ` Tejun Heo
@ 2014-03-12 20:14 ` Benjamin Herrenschmidt
2014-03-12 20:21 ` Tejun Heo
0 siblings, 1 reply; 181+ messages in thread
From: Benjamin Herrenschmidt @ 2014-03-12 20:14 UTC (permalink / raw)
To: Tejun Heo; +Cc: Mark Brown, Greg KH, Stewart Smith, linux-next, linux-kernel
On Wed, 2014-03-12 at 16:02 -0400, Tejun Heo wrote:
> On Thu, Mar 13, 2014 at 06:59:56AM +1100, Benjamin Herrenschmidt wrote:
> > Either that or I can put a copy of the patch that introduces the new
> > function in my tree as long as it's a single patch. The resulting
> > conflict should resolve trivially and Linus should be fine if
> > appropriate explanations are provided (though I would have preferred
> > pulling in a topic branch).
>
> An alternative that I personally prefer to resolve conflicts like this
> is to pull driver-core-next into the broken tree and resolve it there.
> It's highly likely that the pending changes are gonna be included in
> the next merge window. If contaminating the merge history is a
> concern, it can live in a separate branch which is pulled into
> for-next.
It's generally consider bad taste to pull entire trees into each
other :-) I know Stephen isn't fan of it...
I'd rather have just that series (or even better, just the patches
introducing the new function) in a topic branch, itself pulled into
both driver-core-next and my tree.
Can you produce that ? (I need a non-rebase guarantee though).
Cheers,
Ben.
^ permalink raw reply [flat|nested] 181+ messages in thread
* Re: linux-next: build failure after merge of the driver-core tree
2014-03-12 19:59 ` Benjamin Herrenschmidt
@ 2014-03-12 20:02 ` Tejun Heo
2014-03-12 20:14 ` Benjamin Herrenschmidt
0 siblings, 1 reply; 181+ messages in thread
From: Tejun Heo @ 2014-03-12 20:02 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Mark Brown, Greg KH, Stewart Smith, linux-next, linux-kernel
On Thu, Mar 13, 2014 at 06:59:56AM +1100, Benjamin Herrenschmidt wrote:
> Either that or I can put a copy of the patch that introduces the new
> function in my tree as long as it's a single patch. The resulting
> conflict should resolve trivially and Linus should be fine if
> appropriate explanations are provided (though I would have preferred
> pulling in a topic branch).
An alternative that I personally prefer to resolve conflicts like this
is to pull driver-core-next into the broken tree and resolve it there.
It's highly likely that the pending changes are gonna be included in
the next merge window. If contaminating the merge history is a
concern, it can live in a separate branch which is pulled into
for-next.
Thanks.
--
tejun
^ permalink raw reply [flat|nested] 181+ messages in thread
* Re: linux-next: build failure after merge of the driver-core tree
2014-03-12 11:37 ` Mark Brown
@ 2014-03-12 19:59 ` Benjamin Herrenschmidt
2014-03-12 20:02 ` Tejun Heo
0 siblings, 1 reply; 181+ messages in thread
From: Benjamin Herrenschmidt @ 2014-03-12 19:59 UTC (permalink / raw)
To: Mark Brown; +Cc: Greg KH, Stewart Smith, Tejun Heo, linux-next, linux-kernel
On Wed, 2014-03-12 at 11:37 +0000, Mark Brown wrote:
> On Wed, Mar 12, 2014 at 02:55:41PM +1100, Benjamin Herrenschmidt wrote:
>
> > How do you suggest we proceed ? I can't add a fix to powerpc-next to use
> > the new function since it doesn't exist upstream yet. I would have to
> > pull drivers-core-next in which I really don't want to do....
>
> > Can the removal of the function be delayed to -rc1 so we can properly
> > do the fixup ? Or do you have the introduction of the new function in
> > a topic branch I can pull in without the rest of drivers-core-next ?
>
> The delay would have been my first suggestion - otherwise I'd not be
> surprised to see this coming up again. Perhaps change to tagging the
> APIs as deprecated for now (so any futher new users get flagged up)
> would help.
Either that or I can put a copy of the patch that introduces the new
function in my tree as long as it's a single patch. The resulting
conflict should resolve trivially and Linus should be fine if
appropriate explanations are provided (though I would have preferred
pulling in a topic branch).
Greg, how do you want to proceed ?
Cheers,
Ben.
^ permalink raw reply [flat|nested] 181+ messages in thread
* Re: linux-next: build failure after merge of the driver-core tree
2014-03-12 3:55 ` Benjamin Herrenschmidt
@ 2014-03-12 11:37 ` Mark Brown
2014-03-12 19:59 ` Benjamin Herrenschmidt
0 siblings, 1 reply; 181+ messages in thread
From: Mark Brown @ 2014-03-12 11:37 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Greg KH, Stewart Smith, Tejun Heo, linux-next, linux-kernel
[-- Attachment #1: Type: text/plain, Size: 720 bytes --]
On Wed, Mar 12, 2014 at 02:55:41PM +1100, Benjamin Herrenschmidt wrote:
> How do you suggest we proceed ? I can't add a fix to powerpc-next to use
> the new function since it doesn't exist upstream yet. I would have to
> pull drivers-core-next in which I really don't want to do....
> Can the removal of the function be delayed to -rc1 so we can properly
> do the fixup ? Or do you have the introduction of the new function in
> a topic branch I can pull in without the rest of drivers-core-next ?
The delay would have been my first suggestion - otherwise I'd not be
surprised to see this coming up again. Perhaps change to tagging the
APIs as deprecated for now (so any futher new users get flagged up)
would help.
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 181+ messages in thread
* Re: linux-next: build failure after merge of the driver-core tree
2014-03-12 1:50 ` Greg KH
@ 2014-03-12 3:55 ` Benjamin Herrenschmidt
2014-03-12 11:37 ` Mark Brown
2014-03-16 23:16 ` Stephen Rothwell
1 sibling, 1 reply; 181+ messages in thread
From: Benjamin Herrenschmidt @ 2014-03-12 3:55 UTC (permalink / raw)
To: Greg KH; +Cc: Mark Brown, Stewart Smith, Tejun Heo, linux-next, linux-kernel
On Tue, 2014-03-11 at 18:50 -0700, Greg KH wrote:
> On Wed, Mar 12, 2014 at 12:51:52AM +0000, Mark Brown wrote:
> > Hi Greg,
> >
> > After merging the driver-core tree, today's linux-next build ()
> > failed like this on a PowerPC defconfig:
> >
> > HEAD is now at ceb98e684dec Merge remote-tracking branch 'driver-core/driver-core-next'
> > GEN /home/broonie/next/powerpc_ppc64_defconfig/Makefile
> > #
> > # configuration written to .config
> > #
> > /home/broonie/next/next/arch/powerpc/platforms/powernv/opal-elog.c: In function 'elog_ack_store':
> > /home/broonie/next/next/arch/powerpc/platforms/powernv/opal-elog.c:84:2: error: implicit declaration of function 'sysfs_schedule_callback' [-Werror=implicit-function-declaration]
> > sysfs_schedule_callback(&elog_obj->kobj, delay_release_kobj,
> > ^
> > cc1: all warnings being treated as errors
> > make[3]: *** [arch/powerpc/platforms/powernv/opal-elog.o] Error 1
> > make[3]: *** Waiting for unfinished jobs....
> > /home/broonie/next/next/arch/powerpc/platforms/powernv/opal-dump.c: In function 'dump_ack_store':
> > /home/broonie/next/next/arch/powerpc/platforms/powernv/opal-dump.c:100:2: error: implicit declaration of function 'sysfs_schedule_callback' [-Werror=implicit-function-declaration]
> > sysfs_schedule_callback(&dump_obj->kobj, delay_release_kobj,
> > ^
> > cc1: all warnings being treated as errors
> >
> > due to an interaction between d1ba277e7988908 (sysfs, driver-core: remove unused {sysfs|device}_schedule_callback_owner()) and 774fea1a38c6a5a8 (powerpc/powernv: Read OPAL error log and export it through sysfs) from the PowerPC tree.
> >
> > I reverted 774fea1a38c6a5a8 for today.
>
> Sounds like the powerpc tree also needs to stop using this function :)
powerpc -next is a never-rebase branch, so we are somewhat stuffed here.
How do you suggest we proceed ? I can't add a fix to powerpc-next to use
the new function since it doesn't exist upstream yet. I would have to
pull drivers-core-next in which I really don't want to do....
Can the removal of the function be delayed to -rc1 so we can properly
do the fixup ? Or do you have the introduction of the new function in
a topic branch I can pull in without the rest of drivers-core-next ?
Cheers,
Ben.
^ permalink raw reply [flat|nested] 181+ messages in thread
* Re: linux-next: build failure after merge of the driver-core tree
2014-03-12 0:51 Mark Brown
@ 2014-03-12 1:50 ` Greg KH
2014-03-12 3:55 ` Benjamin Herrenschmidt
2014-03-16 23:16 ` Stephen Rothwell
2014-03-17 8:28 ` Stephen Rothwell
1 sibling, 2 replies; 181+ messages in thread
From: Greg KH @ 2014-03-12 1:50 UTC (permalink / raw)
To: Mark Brown
Cc: Stewart Smith, Benjamin Herrenschmidt, Tejun Heo, linux-next,
linux-kernel
On Wed, Mar 12, 2014 at 12:51:52AM +0000, Mark Brown wrote:
> Hi Greg,
>
> After merging the driver-core tree, today's linux-next build ()
> failed like this on a PowerPC defconfig:
>
> HEAD is now at ceb98e684dec Merge remote-tracking branch 'driver-core/driver-core-next'
> GEN /home/broonie/next/powerpc_ppc64_defconfig/Makefile
> #
> # configuration written to .config
> #
> /home/broonie/next/next/arch/powerpc/platforms/powernv/opal-elog.c: In function 'elog_ack_store':
> /home/broonie/next/next/arch/powerpc/platforms/powernv/opal-elog.c:84:2: error: implicit declaration of function 'sysfs_schedule_callback' [-Werror=implicit-function-declaration]
> sysfs_schedule_callback(&elog_obj->kobj, delay_release_kobj,
> ^
> cc1: all warnings being treated as errors
> make[3]: *** [arch/powerpc/platforms/powernv/opal-elog.o] Error 1
> make[3]: *** Waiting for unfinished jobs....
> /home/broonie/next/next/arch/powerpc/platforms/powernv/opal-dump.c: In function 'dump_ack_store':
> /home/broonie/next/next/arch/powerpc/platforms/powernv/opal-dump.c:100:2: error: implicit declaration of function 'sysfs_schedule_callback' [-Werror=implicit-function-declaration]
> sysfs_schedule_callback(&dump_obj->kobj, delay_release_kobj,
> ^
> cc1: all warnings being treated as errors
>
> due to an interaction between d1ba277e7988908 (sysfs, driver-core: remove unused {sysfs|device}_schedule_callback_owner()) and 774fea1a38c6a5a8 (powerpc/powernv: Read OPAL error log and export it through sysfs) from the PowerPC tree.
>
> I reverted 774fea1a38c6a5a8 for today.
Sounds like the powerpc tree also needs to stop using this function :)
thanks,
greg k-h
^ permalink raw reply [flat|nested] 181+ messages in thread
* linux-next: build failure after merge of the driver-core tree
@ 2014-03-12 0:51 Mark Brown
2014-03-12 1:50 ` Greg KH
2014-03-17 8:28 ` Stephen Rothwell
0 siblings, 2 replies; 181+ messages in thread
From: Mark Brown @ 2014-03-12 0:51 UTC (permalink / raw)
To: Greg KH, Stewart Smith, Benjamin Herrenschmidt, Tejun Heo
Cc: linux-next, linux-kernel
[-- Attachment #1: Type: text/plain, Size: 1490 bytes --]
Hi Greg,
After merging the driver-core tree, today's linux-next build ()
failed like this on a PowerPC defconfig:
HEAD is now at ceb98e684dec Merge remote-tracking branch 'driver-core/driver-core-next'
GEN /home/broonie/next/powerpc_ppc64_defconfig/Makefile
#
# configuration written to .config
#
/home/broonie/next/next/arch/powerpc/platforms/powernv/opal-elog.c: In function 'elog_ack_store':
/home/broonie/next/next/arch/powerpc/platforms/powernv/opal-elog.c:84:2: error: implicit declaration of function 'sysfs_schedule_callback' [-Werror=implicit-function-declaration]
sysfs_schedule_callback(&elog_obj->kobj, delay_release_kobj,
^
cc1: all warnings being treated as errors
make[3]: *** [arch/powerpc/platforms/powernv/opal-elog.o] Error 1
make[3]: *** Waiting for unfinished jobs....
/home/broonie/next/next/arch/powerpc/platforms/powernv/opal-dump.c: In function 'dump_ack_store':
/home/broonie/next/next/arch/powerpc/platforms/powernv/opal-dump.c:100:2: error: implicit declaration of function 'sysfs_schedule_callback' [-Werror=implicit-function-declaration]
sysfs_schedule_callback(&dump_obj->kobj, delay_release_kobj,
^
cc1: all warnings being treated as errors
due to an interaction between d1ba277e7988908 (sysfs, driver-core: remove unused {sysfs|device}_schedule_callback_owner()) and 774fea1a38c6a5a8 (powerpc/powernv: Read OPAL error log and export it through sysfs) from the PowerPC tree.
I reverted 774fea1a38c6a5a8 for today.
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 181+ messages in thread
* Re: linux-next: build failure after merge of the driver-core tree
2013-08-22 5:39 Stephen Rothwell
@ 2013-08-22 15:36 ` Greg KH
0 siblings, 0 replies; 181+ messages in thread
From: Greg KH @ 2013-08-22 15:36 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linux-next, linux-kernel
On Thu, Aug 22, 2013 at 03:39:42PM +1000, Stephen Rothwell wrote:
> Hi Greg,
>
> After merging the driver-core tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
>
> In file included from include/linux/kobject.h:21:0,
> from include/linux/module.h:16,
> from drivers/acpi/bgrt.c:11:
> drivers/acpi/bgrt.c: In function 'bgrt_init':
> drivers/acpi/bgrt.c:89:23: error: 'image_attr' undeclared (first use in this function)
> sysfs_bin_attr_init(&image_attr);
> ^
> include/linux/sysfs.h:53:3: note: in definition of macro 'sysfs_attr_init'
> (attr)->key = &__key; \
> ^
> drivers/acpi/bgrt.c:89:2: note: in expansion of macro 'sysfs_bin_attr_init'
> sysfs_bin_attr_init(&image_attr);
> ^
> drivers/acpi/bgrt.c:89:23: note: each undeclared identifier is reported only once for each function it appears in
> sysfs_bin_attr_init(&image_attr);
> ^
> include/linux/sysfs.h:53:3: note: in definition of macro 'sysfs_attr_init'
> (attr)->key = &__key; \
> ^
> drivers/acpi/bgrt.c:89:2: note: in expansion of macro 'sysfs_bin_attr_init'
> sysfs_bin_attr_init(&image_attr);
> ^
>
> Presumably caused by commit 65f44679580d ("ACPI: bgrt: take advantage of
> binary sysfs groups").
It's as if I never even built the patch I submitted, I have no idea what
happened here, sorry about that.
I've now fixed it up, it should be fine for the next linux-next release.
thanks,
greg k-h
^ permalink raw reply [flat|nested] 181+ messages in thread
* linux-next: build failure after merge of the driver-core tree
@ 2013-08-22 5:39 Stephen Rothwell
2013-08-22 15:36 ` Greg KH
0 siblings, 1 reply; 181+ messages in thread
From: Stephen Rothwell @ 2013-08-22 5:39 UTC (permalink / raw)
To: Greg KH; +Cc: linux-next, linux-kernel
[-- Attachment #1: Type: text/plain, Size: 1343 bytes --]
Hi Greg,
After merging the driver-core tree, today's linux-next build (x86_64
allmodconfig) failed like this:
In file included from include/linux/kobject.h:21:0,
from include/linux/module.h:16,
from drivers/acpi/bgrt.c:11:
drivers/acpi/bgrt.c: In function 'bgrt_init':
drivers/acpi/bgrt.c:89:23: error: 'image_attr' undeclared (first use in this function)
sysfs_bin_attr_init(&image_attr);
^
include/linux/sysfs.h:53:3: note: in definition of macro 'sysfs_attr_init'
(attr)->key = &__key; \
^
drivers/acpi/bgrt.c:89:2: note: in expansion of macro 'sysfs_bin_attr_init'
sysfs_bin_attr_init(&image_attr);
^
drivers/acpi/bgrt.c:89:23: note: each undeclared identifier is reported only once for each function it appears in
sysfs_bin_attr_init(&image_attr);
^
include/linux/sysfs.h:53:3: note: in definition of macro 'sysfs_attr_init'
(attr)->key = &__key; \
^
drivers/acpi/bgrt.c:89:2: note: in expansion of macro 'sysfs_bin_attr_init'
sysfs_bin_attr_init(&image_attr);
^
Presumably caused by commit 65f44679580d ("ACPI: bgrt: take advantage of
binary sysfs groups").
I have used the driver-core tree from next-20130821 for today.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 181+ messages in thread
* RE: linux-next: build failure after merge of the driver-core tree
2013-01-18 4:13 ` Greg KH
@ 2013-01-18 14:14 ` Kondratiev, Vladimir
0 siblings, 0 replies; 181+ messages in thread
From: Kondratiev, Vladimir @ 2013-01-18 14:14 UTC (permalink / raw)
To: Greg KH, Stephen Rothwell
Cc: linux-next, linux-kernel, qca_vkondrat, Jason Baron, John W. Linville
On Fri, Jan 18, 2013 at 01:29:04PM +1100, Stephen Rothwell wrote:
> Hi Greg,
>
> After merging the driver-core tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
>
> In file included from drivers/net/wireless/ath/wil6210/wil6210.h:24:0,
> from drivers/net/wireless/ath/wil6210/main.c:26:
> drivers/net/wireless/ath/wil6210/dbg_hexdump.h:21:0: error: "print_hex_dump_bytes" redefined [-Werror]
> include/linux/printk.h:322:0: note: this is the location of the previous definition
>
> Caused by commit 7a555613eb77 ("dynamic_debug: dynamic hex dump")
> interacting with commit 2be7d22f0625 ("wireless: add new wil6210 802.11ad
> 60GHz driver") that was added to Linus' tree in the last few days.
>
> I have applied the following merge fix patch for today:
>
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Fri, 18 Jan 2013 13:24:32 +1100
> Subject: [PATCH] wireless: remove conflicting version of print_hex_dump_bytes
>
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
Thanks, I've merged 3.9-rc4 into my tree and applied this patch to fix
the build breakage.
greg k-h
Sorry for the mess; this conflicting file should disappear after the other commit,
"dynamic_debug: dynamic hex dump", merged. It was intended as temporal replacement.
Patch by Stephen Rothwell is just fine in the mean time.
Unfortunately, this catches me on my way to the airport, going for 1 week ski vacation.
I'll submit patch to remove
drivers/net/wireless/ath/wil6210/dbg_hexdump.h
and s/wil_print_hex_dump_debug/print_hex_dump_debug/ for the rest of the wil6210 driver.
Thanks, Vladimir.
^ permalink raw reply [flat|nested] 181+ messages in thread
* Re: linux-next: build failure after merge of the driver-core tree
2013-01-18 2:29 Stephen Rothwell
@ 2013-01-18 4:13 ` Greg KH
2013-01-18 14:14 ` Kondratiev, Vladimir
0 siblings, 1 reply; 181+ messages in thread
From: Greg KH @ 2013-01-18 4:13 UTC (permalink / raw)
To: Stephen Rothwell
Cc: linux-next, linux-kernel, Vladimir Kondratiev, Jason Baron,
John W. Linville
On Fri, Jan 18, 2013 at 01:29:04PM +1100, Stephen Rothwell wrote:
> Hi Greg,
>
> After merging the driver-core tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
>
> In file included from drivers/net/wireless/ath/wil6210/wil6210.h:24:0,
> from drivers/net/wireless/ath/wil6210/main.c:26:
> drivers/net/wireless/ath/wil6210/dbg_hexdump.h:21:0: error: "print_hex_dump_bytes" redefined [-Werror]
> include/linux/printk.h:322:0: note: this is the location of the previous definition
>
> Caused by commit 7a555613eb77 ("dynamic_debug: dynamic hex dump")
> interacting with commit 2be7d22f0625 ("wireless: add new wil6210 802.11ad
> 60GHz driver") that was added to Linus' tree in the last few days.
>
> I have applied the following merge fix patch for today:
>
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Fri, 18 Jan 2013 13:24:32 +1100
> Subject: [PATCH] wireless: remove conflicting version of print_hex_dump_bytes
>
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
Thanks, I've merged 3.9-rc4 into my tree and applied this patch to fix
the build breakage.
greg k-h
^ permalink raw reply [flat|nested] 181+ messages in thread
* linux-next: build failure after merge of the driver-core tree
@ 2013-01-18 2:29 Stephen Rothwell
2013-01-18 4:13 ` Greg KH
0 siblings, 1 reply; 181+ messages in thread
From: Stephen Rothwell @ 2013-01-18 2:29 UTC (permalink / raw)
To: Greg KH
Cc: linux-next, linux-kernel, Vladimir Kondratiev, Jason Baron,
John W. Linville
[-- Attachment #1: Type: text/plain, Size: 2635 bytes --]
Hi Greg,
After merging the driver-core tree, today's linux-next build (x86_64
allmodconfig) failed like this:
In file included from drivers/net/wireless/ath/wil6210/wil6210.h:24:0,
from drivers/net/wireless/ath/wil6210/main.c:26:
drivers/net/wireless/ath/wil6210/dbg_hexdump.h:21:0: error: "print_hex_dump_bytes" redefined [-Werror]
include/linux/printk.h:322:0: note: this is the location of the previous definition
Caused by commit 7a555613eb77 ("dynamic_debug: dynamic hex dump")
interacting with commit 2be7d22f0625 ("wireless: add new wil6210 802.11ad
60GHz driver") that was added to Linus' tree in the last few days.
I have applied the following merge fix patch for today:
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Fri, 18 Jan 2013 13:24:32 +1100
Subject: [PATCH] wireless: remove conflicting version of print_hex_dump_bytes
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
drivers/net/wireless/ath/wil6210/dbg_hexdump.h | 18 ++++--------------
1 file changed, 4 insertions(+), 14 deletions(-)
diff --git a/drivers/net/wireless/ath/wil6210/dbg_hexdump.h b/drivers/net/wireless/ath/wil6210/dbg_hexdump.h
index 6a315ba..e5712f0 100644
--- a/drivers/net/wireless/ath/wil6210/dbg_hexdump.h
+++ b/drivers/net/wireless/ath/wil6210/dbg_hexdump.h
@@ -1,25 +1,15 @@
#ifndef WIL_DBG_HEXDUMP_H_
#define WIL_DBG_HEXDUMP_H_
-#if defined(CONFIG_DYNAMIC_DEBUG)
-#define wil_dynamic_hex_dump(prefix_str, prefix_type, rowsize, \
- groupsize, buf, len, ascii) \
-do { \
- DEFINE_DYNAMIC_DEBUG_METADATA(descriptor, \
- __builtin_constant_p(prefix_str) ? prefix_str : "hexdump");\
- if (unlikely(descriptor.flags & _DPRINTK_FLAGS_PRINT)) \
- print_hex_dump(KERN_DEBUG, prefix_str, \
- prefix_type, rowsize, groupsize, \
- buf, len, ascii); \
-} while (0)
+#include <linux/printk.h>
+#include <linux/dynamic_debug.h>
+#if defined(CONFIG_DYNAMIC_DEBUG)
#define wil_print_hex_dump_debug(prefix_str, prefix_type, rowsize, \
groupsize, buf, len, ascii) \
- wil_dynamic_hex_dump(prefix_str, prefix_type, rowsize, \
+ dynamic_hex_dump(prefix_str, prefix_type, rowsize, \
groupsize, buf, len, ascii)
-#define print_hex_dump_bytes(prefix_str, prefix_type, buf, len) \
- wil_dynamic_hex_dump(prefix_str, prefix_type, 16, 1, buf, len, true)
#else /* defined(CONFIG_DYNAMIC_DEBUG) */
#define wil_print_hex_dump_debug(prefix_str, prefix_type, rowsize, \
groupsize, buf, len, ascii) \
--
1.7.10.280.gaa39
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply related [flat|nested] 181+ messages in thread
* Re: linux-next: build failure after merge of the driver-core tree
2012-08-17 4:01 Stephen Rothwell
@ 2012-08-17 13:25 ` Greg KH
0 siblings, 0 replies; 181+ messages in thread
From: Greg KH @ 2012-08-17 13:25 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linux-next, linux-kernel, Ming Lei
On Fri, Aug 17, 2012 at 02:01:23PM +1000, Stephen Rothwell wrote:
> Hi Greg,
>
> After merging the driver-core tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
>
> ERROR: "device_pm_lock" [drivers/base/firmware_class.ko] undefined!
> ERROR: "dpm_list" [drivers/base/firmware_class.ko] undefined!
> ERROR: "device_pm_unlock" [drivers/base/firmware_class.ko] undefined!
>
> Caused by commit 37276a51f803 ("firmware: introduce
> device_cache/uncache_fw_images").
Thanks, known bug, Ming is working on resolving the issue.
greg k-h
^ permalink raw reply [flat|nested] 181+ messages in thread
* linux-next: build failure after merge of the driver-core tree
@ 2012-08-17 4:01 Stephen Rothwell
2012-08-17 13:25 ` Greg KH
0 siblings, 1 reply; 181+ messages in thread
From: Stephen Rothwell @ 2012-08-17 4:01 UTC (permalink / raw)
To: Greg KH; +Cc: linux-next, linux-kernel, Ming Lei
[-- Attachment #1: Type: text/plain, Size: 548 bytes --]
Hi Greg,
After merging the driver-core tree, today's linux-next build (x86_64
allmodconfig) failed like this:
ERROR: "device_pm_lock" [drivers/base/firmware_class.ko] undefined!
ERROR: "dpm_list" [drivers/base/firmware_class.ko] undefined!
ERROR: "device_pm_unlock" [drivers/base/firmware_class.ko] undefined!
Caused by commit 37276a51f803 ("firmware: introduce
device_cache/uncache_fw_images").
I have used the driver-core tree from next-20120816 for today.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 181+ messages in thread
* Re: linux-next: build failure after merge of the driver-core tree
2012-07-10 11:14 ` Stephen Rothwell
@ 2012-07-10 21:10 ` Linus Walleij
0 siblings, 0 replies; 181+ messages in thread
From: Linus Walleij @ 2012-07-10 21:10 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Mark Brown, Greg KH, linux-next, linux-kernel, Axel Lin,
Grant Likely, Andrew Morton, Stephen Warren
On Tue, Jul 10, 2012 at 1:14 PM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> Linus (Walleij), Stephen, Grant, can someone please send this patch to
> Linus (Torvalds)?
I sent it by pill request a few minutes ago.
Ironically my pull request was postponed two days for the sole reason of
getting some rotation of the patches in linux-next...
Yours,
Linus Walleij
^ permalink raw reply [flat|nested] 181+ messages in thread
* Re: linux-next: build failure after merge of the driver-core tree
2012-07-10 9:03 ` Mark Brown
@ 2012-07-10 11:14 ` Stephen Rothwell
2012-07-10 21:10 ` Linus Walleij
0 siblings, 1 reply; 181+ messages in thread
From: Stephen Rothwell @ 2012-07-10 11:14 UTC (permalink / raw)
To: Mark Brown
Cc: Greg KH, linux-next, linux-kernel, Axel Lin, Grant Likely,
Linus Walleij, Andrew Morton, Stephen Warren
[-- Attachment #1: Type: text/plain, Size: 924 bytes --]
Hi Mark,
On Tue, 10 Jul 2012 10:03:25 +0100 Mark Brown <broonie@opensource.wolfsonmicro.com> wrote:
>
> On Tue, Jul 10, 2012 at 03:32:10PM +1000, Stephen Rothwell wrote:
>
> > Caused by commit 01eaf2458773 ("extcon: Convert extcon_gpio to
> > devm_gpio_request_one"). devm_gpio_request_one is not currently exported
> > to modules.
>
> A patch for this has been in -next for most of this release cycle and
> really should've been sent to Linus by now - this issue is cropping up
> an awful lot and there's further patches not getting applied due to the
> dependency on this.
>
> I *think* the patch is sitting in Andrew's tree at the minute.
Its actually in the gpio-lw tree (more cc's added). It was in Andrew's
tree before that.
Linus (Walleij), Stephen, Grant, can someone please send this patch to
Linus (Torvalds)?
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 181+ messages in thread
* Re: linux-next: build failure after merge of the driver-core tree
2012-07-10 5:32 Stephen Rothwell
@ 2012-07-10 9:03 ` Mark Brown
2012-07-10 11:14 ` Stephen Rothwell
0 siblings, 1 reply; 181+ messages in thread
From: Mark Brown @ 2012-07-10 9:03 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Greg KH, linux-next, linux-kernel, Axel Lin, Grant Likely, Linus Walleij
[-- Attachment #1: Type: text/plain, Size: 520 bytes --]
On Tue, Jul 10, 2012 at 03:32:10PM +1000, Stephen Rothwell wrote:
> Caused by commit 01eaf2458773 ("extcon: Convert extcon_gpio to
> devm_gpio_request_one"). devm_gpio_request_one is not currently exported
> to modules.
A patch for this has been in -next for most of this release cycle and
really should've been sent to Linus by now - this issue is cropping up
an awful lot and there's further patches not getting applied due to the
dependency on this.
I *think* the patch is sitting in Andrew's tree at the minute.
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 181+ messages in thread
* linux-next: build failure after merge of the driver-core tree
@ 2012-07-10 5:32 Stephen Rothwell
2012-07-10 9:03 ` Mark Brown
0 siblings, 1 reply; 181+ messages in thread
From: Stephen Rothwell @ 2012-07-10 5:32 UTC (permalink / raw)
To: Greg KH
Cc: linux-next, linux-kernel, Mark Brown, Axel Lin, Grant Likely,
Linus Walleij
[-- Attachment #1: Type: text/plain, Size: 1445 bytes --]
Hi Greg,
After merging the driver-core tree, today's linux-next build (x86_64
allmodconfig) failed like this:
ERROR: "devm_gpio_request_one" [drivers/extcon/extcon-arizona.ko] undefined!
Caused by commit 01eaf2458773 ("extcon: Convert extcon_gpio to
devm_gpio_request_one"). devm_gpio_request_one is not currently exported
to modules.
This has not been seen earlier because CONFIG_MFD_ARIZONA only got added
today :-(
I have added the following merge fix patch for today:
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Tue, 10 Jul 2012 15:25:14 +1000
Subject: [PATCH] extcon: extcon-arizone can not be built as a module for now
fixes this build error:
ERROR: "devm_gpio_request_one" [drivers/extcon/extcon-arizona.ko] undefined!
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
drivers/extcon/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/extcon/Kconfig b/drivers/extcon/Kconfig
index dbd96af..a2071e4 100644
--- a/drivers/extcon/Kconfig
+++ b/drivers/extcon/Kconfig
@@ -30,7 +30,7 @@ config EXTCON_MAX8997
detector and switch.
config EXTCON_ARIZONA
- tristate "Wolfson Arizona EXTCON support"
+ bool "Wolfson Arizona EXTCON support"
depends on MFD_ARIZONA
help
Say Y here to enable support for external accessory detection
--
1.7.10.280.gaa39
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply related [flat|nested] 181+ messages in thread
* Re: linux-next: build failure after merge of the driver-core tree
2012-05-01 4:59 Stephen Rothwell
2012-05-01 7:05 ` Bart Van Assche
@ 2012-05-01 13:45 ` Greg KH
1 sibling, 0 replies; 181+ messages in thread
From: Greg KH @ 2012-05-01 13:45 UTC (permalink / raw)
To: Stephen Rothwell
Cc: linux-next, linux-kernel, Bart Van Assche, Jim Cromie, Roland Dreier
On Tue, May 01, 2012 at 02:59:22PM +1000, Stephen Rothwell wrote:
> Hi Greg,
>
> After merging the driver-core tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
>
> In file included from include/linux/kernel.h:23:0,
> from include/linux/cache.h:4,
> from include/linux/time.h:7,
> from include/linux/stat.h:60,
> from include/linux/module.h:10,
> from drivers/infiniband/ulp/srp/ib_srp.c:35:
> include/linux/dynamic_debug.h: In function 'ddebug_dyndbg_module_param_cb':
> include/linux/dynamic_debug.h:112:3: error: expected ')' before 'PFX'
>
> Caused by commit b48420c1d301 ("dynamic_debug: make dynamic-debug work
> for module initialization") interacting with commit e0bda7d8c33e
> ("IB/srp: Use pr_fmt() and pr_err()/pr_warn()") from Linus' tree (added
> before v3.4-rc1).
>
> I have used the driver-core tree from next-20120430 for today.
Thanks, but this is a driver-core tree problem, not an IB tree problem,
so should you should have dropped my tree :)
I've applied a patch to the driver-core tree that should solve this
issue now, thanks for letting us know.
greg k-h
^ permalink raw reply [flat|nested] 181+ messages in thread
* Re: linux-next: build failure after merge of the driver-core tree
2012-05-01 4:59 Stephen Rothwell
@ 2012-05-01 7:05 ` Bart Van Assche
2012-05-01 13:45 ` Greg KH
1 sibling, 0 replies; 181+ messages in thread
From: Bart Van Assche @ 2012-05-01 7:05 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Greg KH, linux-next, linux-kernel, Jim Cromie, Roland Dreier
On 05/01/12 04:59, Stephen Rothwell wrote:
> After merging the driver-core tree, today's linux-next build
> (powerpc ppc64_defconfig) failed like this:
>
> In file included from include/linux/kernel.h:23:0, from
> include/linux/cache.h:4, from include/linux/time.h:7, from
> include/linux/stat.h:60, from include/linux/module.h:10, from
> drivers/infiniband/ulp/srp/ib_srp.c:35:
> include/linux/dynamic_debug.h: In function
> 'ddebug_dyndbg_module_param_cb':
> include/linux/dynamic_debug.h:112:3: error: expected ')' before
> 'PFX'
>
> Caused by commit b48420c1d301 ("dynamic_debug: make dynamic-debug
> work for module initialization") interacting with commit
> e0bda7d8c33e ("IB/srp: Use pr_fmt() and pr_err()/pr_warn()") from
> Linus' tree (added before v3.4-rc1).
>
> I have used the driver-core tree from next-20120430 for today.
This reveals that the pr_warn() statement in that dynamic_debug patch
uses the pr_fmt() macro of the module from which it has been included
(e.g. ib_srp) instead that of the dynamic debug module itself. That
looks incorrect to me. How about moving the definition of
ddebug_dyndbg_module_param_cb() from include/linux/dynamic_debug.h
into lib/dynamic_debug.c ?
Bart.
^ permalink raw reply [flat|nested] 181+ messages in thread
* linux-next: build failure after merge of the driver-core tree
@ 2012-05-01 4:59 Stephen Rothwell
2012-05-01 7:05 ` Bart Van Assche
2012-05-01 13:45 ` Greg KH
0 siblings, 2 replies; 181+ messages in thread
From: Stephen Rothwell @ 2012-05-01 4:59 UTC (permalink / raw)
To: Greg KH
Cc: linux-next, linux-kernel, Bart Van Assche, Jim Cromie, Roland Dreier
[-- Attachment #1: Type: text/plain, Size: 947 bytes --]
Hi Greg,
After merging the driver-core tree, today's linux-next build (powerpc
ppc64_defconfig) failed like this:
In file included from include/linux/kernel.h:23:0,
from include/linux/cache.h:4,
from include/linux/time.h:7,
from include/linux/stat.h:60,
from include/linux/module.h:10,
from drivers/infiniband/ulp/srp/ib_srp.c:35:
include/linux/dynamic_debug.h: In function 'ddebug_dyndbg_module_param_cb':
include/linux/dynamic_debug.h:112:3: error: expected ')' before 'PFX'
Caused by commit b48420c1d301 ("dynamic_debug: make dynamic-debug work
for module initialization") interacting with commit e0bda7d8c33e
("IB/srp: Use pr_fmt() and pr_err()/pr_warn()") from Linus' tree (added
before v3.4-rc1).
I have used the driver-core tree from next-20120430 for today.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 181+ messages in thread
* Re: linux-next: build failure after merge of the driver-core tree
2012-04-19 4:48 Stephen Rothwell
2012-04-19 20:07 ` Greg KH
@ 2012-04-20 2:19 ` Greg KH
1 sibling, 0 replies; 181+ messages in thread
From: Greg KH @ 2012-04-20 2:19 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linux-next, linux-kernel, Hannes Reinecke
On Thu, Apr 19, 2012 at 02:48:15PM +1000, Stephen Rothwell wrote:
> Hi Greg,
>
> After merging the driver-core tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
>
> lib/klist.c: In function 'klist_iter_init_node':
> lib/klist.c:287:4: error: too few arguments to function 'kref_put'
> include/linux/kref.h:92:19: note: declared here
>
> Caused by commit a15d49fd3094 ("driver core: check start node in
> klist_iter_init_node"). That really hasn't been build tested, has it?
>
> I have used the driver-core tree from next-20120418 for today.
Ok, that was just totally obviously broken, I have no idea how that
passed my testing, as it just failed right now. So I've reverted it.
Hannes, care to fix this up and resend when it works?
thanks,
greg k-h
^ permalink raw reply [flat|nested] 181+ messages in thread
* Re: linux-next: build failure after merge of the driver-core tree
2012-04-19 4:48 Stephen Rothwell
@ 2012-04-19 20:07 ` Greg KH
2012-04-20 2:19 ` Greg KH
1 sibling, 0 replies; 181+ messages in thread
From: Greg KH @ 2012-04-19 20:07 UTC (permalink / raw)
To: Stephen Rothwell, Hannes Reinecke; +Cc: linux-next, linux-kernel
On Thu, Apr 19, 2012 at 02:48:15PM +1000, Stephen Rothwell wrote:
> Hi Greg,
>
> After merging the driver-core tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
>
> lib/klist.c: In function 'klist_iter_init_node':
> lib/klist.c:287:4: error: too few arguments to function 'kref_put'
> include/linux/kref.h:92:19: note: declared here
>
> Caused by commit a15d49fd3094 ("driver core: check start node in
> klist_iter_init_node"). That really hasn't been build tested, has it?
>
> I have used the driver-core tree from next-20120418 for today.
Ick. Hannes, care to send me a fix for this?
thanks,
greg k-h
^ permalink raw reply [flat|nested] 181+ messages in thread
* linux-next: build failure after merge of the driver-core tree
@ 2012-04-19 4:48 Stephen Rothwell
2012-04-19 20:07 ` Greg KH
2012-04-20 2:19 ` Greg KH
0 siblings, 2 replies; 181+ messages in thread
From: Stephen Rothwell @ 2012-04-19 4:48 UTC (permalink / raw)
To: Greg KH; +Cc: linux-next, linux-kernel, Hannes Reinecke
[-- Attachment #1: Type: text/plain, Size: 601 bytes --]
Hi Greg,
After merging the driver-core tree, today's linux-next build (powerpc
ppc64_defconfig) failed like this:
lib/klist.c: In function 'klist_iter_init_node':
lib/klist.c:287:4: error: too few arguments to function 'kref_put'
include/linux/kref.h:92:19: note: declared here
Caused by commit a15d49fd3094 ("driver core: check start node in
klist_iter_init_node"). That really hasn't been build tested, has it?
I have used the driver-core tree from next-20120418 for today.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 181+ messages in thread
* Re: linux-next: build failure after merge of the driver-core tree
2012-01-27 2:59 Stephen Rothwell
2012-01-27 15:24 ` Alan Stern
@ 2012-01-27 22:36 ` Greg KH
1 sibling, 0 replies; 181+ messages in thread
From: Greg KH @ 2012-01-27 22:36 UTC (permalink / raw)
To: Stephen Rothwell
Cc: linux-next, linux-kernel, Alan Stern, David S. Miller,
Konrad Rzeszutek Wilk, Michael Buesch, Joerg Roedel
On Fri, Jan 27, 2012 at 01:59:12PM +1100, Stephen Rothwell wrote:
> Hi Greg,
>
> After merging the driver-core tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
>
> drivers/pci/xen-pcifront.c: In function 'pcifront_common_process':
> drivers/pci/xen-pcifront.c:596:6: error: used struct type value where scalar is required
>
> Caused by commit f3ff9247088a ("Remove useless get_driver()/put_driver()
> calls").
>
> Please build test this stuff ...
Sorry, I do build test this, but I didn't have Xen enabled in that
.config as I never run Xen :)
I'll queue up Alan's patch so all should be good now.
thanks,
greg k-h
^ permalink raw reply [flat|nested] 181+ messages in thread
* Re: linux-next: build failure after merge of the driver-core tree
2012-01-27 2:59 Stephen Rothwell
@ 2012-01-27 15:24 ` Alan Stern
2012-01-27 22:36 ` Greg KH
1 sibling, 0 replies; 181+ messages in thread
From: Alan Stern @ 2012-01-27 15:24 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Greg KH, linux-next, Kernel development list, David S. Miller,
Konrad Rzeszutek Wilk, Michael Buesch, Joerg Roedel
On Fri, 27 Jan 2012, Stephen Rothwell wrote:
> Hi Greg,
>
> After merging the driver-core tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
>
> drivers/pci/xen-pcifront.c: In function 'pcifront_common_process':
> drivers/pci/xen-pcifront.c:596:6: error: used struct type value where scalar is required
>
> Caused by commit f3ff9247088a ("Remove useless get_driver()/put_driver()
> calls").
>
> Please build test this stuff ...
>
> I have used the driver-core tree from next-20120125 for today.
Sorry about the mistake. I don't always build-test everything because
it's not easy to do it on my system. Anyway, the patch below will
fix the problem.
Alan Stern
-----------------------------------------------------------------
Subject: [PATCH] PCI/XEN: Fix bug introduced by a recent change
This patch (as1516) fixes a bug introduced during the removal of
put_driver() and get_driver() from drivers/pci/xen-pcifront.c.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
---
drivers/pci/xen-pcifront.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: usb-3.3/drivers/pci/xen-pcifront.c
===================================================================
--- usb-3.3.orig/drivers/pci/xen-pcifront.c
+++ usb-3.3/drivers/pci/xen-pcifront.c
@@ -593,7 +593,7 @@ static pci_ers_result_t pcifront_common_
}
pdrv = pcidev->driver;
- if (pdrv->driver) {
+ if (pdrv) {
if (pdrv->err_handler && pdrv->err_handler->error_detected) {
dev_dbg(&pcidev->dev,
"trying to call AER service\n");
^ permalink raw reply [flat|nested] 181+ messages in thread
* linux-next: build failure after merge of the driver-core tree
@ 2012-01-27 2:59 Stephen Rothwell
2012-01-27 15:24 ` Alan Stern
2012-01-27 22:36 ` Greg KH
0 siblings, 2 replies; 181+ messages in thread
From: Stephen Rothwell @ 2012-01-27 2:59 UTC (permalink / raw)
To: Greg KH
Cc: linux-next, linux-kernel, Alan Stern, David S. Miller,
Konrad Rzeszutek Wilk, Michael Buesch, Joerg Roedel
[-- Attachment #1: Type: text/plain, Size: 535 bytes --]
Hi Greg,
After merging the driver-core tree, today's linux-next build (x86_64
allmodconfig) failed like this:
drivers/pci/xen-pcifront.c: In function 'pcifront_common_process':
drivers/pci/xen-pcifront.c:596:6: error: used struct type value where scalar is required
Caused by commit f3ff9247088a ("Remove useless get_driver()/put_driver()
calls").
Please build test this stuff ...
I have used the driver-core tree from next-20120125 for today.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 181+ messages in thread
* Re: linux-next: build failure after merge of the driver-core tree
2012-01-05 6:28 Stephen Rothwell
@ 2012-01-05 23:20 ` Greg KH
0 siblings, 0 replies; 181+ messages in thread
From: Greg KH @ 2012-01-05 23:20 UTC (permalink / raw)
To: Stephen Rothwell
Cc: linux-next, linux-kernel, Srivatsa S. Bhat, Borislav Petkov,
Jan Beulich, Kay Sievers
On Thu, Jan 05, 2012 at 05:28:56PM +1100, Stephen Rothwell wrote:
> Hi Greg,
>
> After merging the driver-core tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
>
> arch/x86/kernel/microcode_core.c: In function 'microcode_init':
> arch/x86/kernel/microcode_core.c:557:2: error: implicit declaration of function 'sysdev_driver_unregister' [-Werror=implicit-function-declaration]
> arch/x86/kernel/microcode_core.c:557:28: error: 'cpu_sysdev_class' undeclared (first use in this function)
> arch/x86/kernel/microcode_core.c:557:47: error: 'mc_sysdev_driver' undeclared (first use in this function)
>
> Caused by commit 8a25a2fd126c ("cpu: convert 'cpu' and 'machinecheck'
> sysdev_class to a regular subsystem") interacting with commit
> bd399063976c ("x86, microcode: Fix the failure path of microcode update
> driver init code") which was added to Linux' tree in v3.2-rc5,
>
> I have applied the following merge fix patch:
Thanks, this looks good, and I'll queue it up when push these to Linus.
greg k-h
^ permalink raw reply [flat|nested] 181+ messages in thread
* linux-next: build failure after merge of the driver-core tree
@ 2012-01-05 6:28 Stephen Rothwell
2012-01-05 23:20 ` Greg KH
0 siblings, 1 reply; 181+ messages in thread
From: Stephen Rothwell @ 2012-01-05 6:28 UTC (permalink / raw)
To: Greg KH
Cc: linux-next, linux-kernel, Srivatsa S. Bhat, Borislav Petkov,
Jan Beulich, Kay Sievers
[-- Attachment #1: Type: text/plain, Size: 2170 bytes --]
Hi Greg,
After merging the driver-core tree, today's linux-next build (x86_64
allmodconfig) failed like this:
arch/x86/kernel/microcode_core.c: In function 'microcode_init':
arch/x86/kernel/microcode_core.c:557:2: error: implicit declaration of function 'sysdev_driver_unregister' [-Werror=implicit-function-declaration]
arch/x86/kernel/microcode_core.c:557:28: error: 'cpu_sysdev_class' undeclared (first use in this function)
arch/x86/kernel/microcode_core.c:557:47: error: 'mc_sysdev_driver' undeclared (first use in this function)
Caused by commit 8a25a2fd126c ("cpu: convert 'cpu' and 'machinecheck'
sysdev_class to a regular subsystem") interacting with commit
bd399063976c ("x86, microcode: Fix the failure path of microcode update
driver init code") which was added to Linux' tree in v3.2-rc5,
I have applied the following merge fix patch:
From e4aefaed98c4462d5d5d71099756606b547e7364 Mon Sep 17 00:00:00 2001
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Thu, 5 Jan 2012 17:26:14 +1100
Subject: [PATCH] cpu: fix up for sysdev removal
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
arch/x86/kernel/microcode_core.c | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/x86/kernel/microcode_core.c b/arch/x86/kernel/microcode_core.c
index ef127e54..fb34a56 100644
--- a/arch/x86/kernel/microcode_core.c
+++ b/arch/x86/kernel/microcode_core.c
@@ -540,7 +540,7 @@ static int __init microcode_init(void)
error = microcode_dev_init();
if (error)
- goto out_sysdev_driver;
+ goto out_driver;
register_syscore_ops(&mc_syscore_ops);
register_hotcpu_notifier(&mc_cpu_notifier);
@@ -550,11 +550,11 @@ static int __init microcode_init(void)
return 0;
-out_sysdev_driver:
+out_driver:
get_online_cpus();
mutex_lock(µcode_mutex);
- sysdev_driver_unregister(&cpu_sysdev_class, &mc_sysdev_driver);
+ subsys_interface_unregister(&mc_cpu_interface);
mutex_unlock(µcode_mutex);
put_online_cpus();
--
1.7.8.197.g73c6b
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply related [flat|nested] 181+ messages in thread
* Re: linux-next: build failure after merge of the driver-core tree
2012-01-05 0:01 ` Kay Sievers
2012-01-05 0:17 ` Stephen Rothwell
@ 2012-01-05 0:57 ` Josh Triplett
1 sibling, 0 replies; 181+ messages in thread
From: Josh Triplett @ 2012-01-05 0:57 UTC (permalink / raw)
To: Kay Sievers; +Cc: Stephen Rothwell, Greg KH, linux-next, linux-kernel
On Thu, Jan 05, 2012 at 01:01:51AM +0100, Kay Sievers wrote:
> On Thu, Jan 5, 2012 at 00:48, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> > Kay, Greg, any hints would be nice. The tip tree commit is adding this:
> >
> > bool cpu_is_hotpluggable(unsigned cpu)
> > {
> > struct sys_device *dev = get_cpu_sysdev(cpu);
> > return dev && container_of(dev, struct cpu, sysdev)->hotpluggable;
> > }
> >
> > and, of course, all the sys_device stuff has now gone ...
> >
> > So is this correct?
> >
> > bool cpu_is_hotpluggable(unsigned cpu)
> > {
> > struct device *dev = get_cpu_device(cpu);
> > return dev && container_of(dev, struct cpu, dev)->hotpluggable;
> > }
>
> Yes, that look like the right pattern.
>
> Stephen, thanks a lot for your help here, it's very much appreciated.
Definitely, thanks for fixing up cpu_is_hotpluggable for this change.
- Josh Triplett
^ permalink raw reply [flat|nested] 181+ messages in thread
* Re: linux-next: build failure after merge of the driver-core tree
2012-01-05 0:01 ` Kay Sievers
@ 2012-01-05 0:17 ` Stephen Rothwell
2012-01-05 0:57 ` Josh Triplett
1 sibling, 0 replies; 181+ messages in thread
From: Stephen Rothwell @ 2012-01-05 0:17 UTC (permalink / raw)
To: Kay Sievers; +Cc: Greg KH, linux-next, linux-kernel, Josh Triplett
[-- Attachment #1: Type: text/plain, Size: 388 bytes --]
Hi Kay,
On Thu, 5 Jan 2012 01:01:51 +0100 Kay Sievers <kay.sievers@vrfy.org> wrote:
>
> Yes, that look like the right pattern.
Good, thanks.
> Stephen, thanks a lot for your help here, it's very much appreciated.
> I know we cause a lot of trouble every other year. :)
Its how I justify myself :-)
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 181+ messages in thread
* Re: linux-next: build failure after merge of the driver-core tree
2012-01-04 23:48 ` Stephen Rothwell
@ 2012-01-05 0:01 ` Kay Sievers
2012-01-05 0:17 ` Stephen Rothwell
2012-01-05 0:57 ` Josh Triplett
0 siblings, 2 replies; 181+ messages in thread
From: Kay Sievers @ 2012-01-05 0:01 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: Greg KH, linux-next, linux-kernel, Josh Triplett
On Thu, Jan 5, 2012 at 00:48, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> Kay, Greg, any hints would be nice. The tip tree commit is adding this:
>
> bool cpu_is_hotpluggable(unsigned cpu)
> {
> struct sys_device *dev = get_cpu_sysdev(cpu);
> return dev && container_of(dev, struct cpu, sysdev)->hotpluggable;
> }
>
> and, of course, all the sys_device stuff has now gone ...
>
> So is this correct?
>
> bool cpu_is_hotpluggable(unsigned cpu)
> {
> struct device *dev = get_cpu_device(cpu);
> return dev && container_of(dev, struct cpu, dev)->hotpluggable;
> }
Yes, that look like the right pattern.
Stephen, thanks a lot for your help here, it's very much appreciated.
I know we cause a lot of trouble every other year. :)
Thanks,
Kay
^ permalink raw reply [flat|nested] 181+ messages in thread
* Re: linux-next: build failure after merge of the driver-core tree
2012-01-04 23:07 ` Greg KH
@ 2012-01-04 23:48 ` Stephen Rothwell
2012-01-05 0:01 ` Kay Sievers
0 siblings, 1 reply; 181+ messages in thread
From: Stephen Rothwell @ 2012-01-04 23:48 UTC (permalink / raw)
To: Greg KH; +Cc: linux-next, linux-kernel, Josh Triplett, Kay Sievers
[-- Attachment #1: Type: text/plain, Size: 1853 bytes --]
Hi Greg,
On Wed, 4 Jan 2012 15:07:20 -0800 Greg KH <greg@kroah.com> wrote:
>
> Ok, I'll take off the warn_unused_result flag for device_create_file for
> now, which should solve this, and your other build problems with the
> driver-core tree.
Yes, I think that is it.
> > drivers/base/cpu.c: In function 'cpu_is_hotpluggable':
> > drivers/base/cpu.c:272:9: error: implicit declaration of function 'get_cpu_sysdev' [-Werror=implicit-function-declaration]
> > drivers/base/cpu.c:272:27: warning: initialization makes pointer from integer without a cast [enabled by default]
> > drivers/base/cpu.c:273:16: error: 'struct cpu' has no member named 'sysdev'
> > drivers/base/cpu.c:273:16: warning: initialization from incompatible pointer type [enabled by default]
> > drivers/base/cpu.c:273:16: error: 'struct cpu' has no member named 'sysdev'
> > drivers/base/cpu.c:274:1: warning: control reaches end of non-void function [-Wreturn-type]
> >
> > Caused by the above commit interacting with commit 2987557f52b9
> > ("driver-core/cpu: Expose hotpluggability to the rest of the kernel")
> > from the tip tree. This is will fix up in the merge commit next time.
>
> Yeah, nothing I can do here about this, sorry.
Kay, Greg, any hints would be nice. The tip tree commit is adding this:
bool cpu_is_hotpluggable(unsigned cpu)
{
struct sys_device *dev = get_cpu_sysdev(cpu);
return dev && container_of(dev, struct cpu, sysdev)->hotpluggable;
}
and, of course, all the sys_device stuff has now gone ...
So is this correct?
bool cpu_is_hotpluggable(unsigned cpu)
{
struct device *dev = get_cpu_device(cpu);
return dev && container_of(dev, struct cpu, dev)->hotpluggable;
}
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 181+ messages in thread
* Re: linux-next: build failure after merge of the driver-core tree
2012-01-04 22:03 ` Kay Sievers
@ 2012-01-04 23:13 ` Greg KH
0 siblings, 0 replies; 181+ messages in thread
From: Greg KH @ 2012-01-04 23:13 UTC (permalink / raw)
To: Kay Sievers; +Cc: Stephen Rothwell, linux-next, linux-kernel, Josh Triplett
On Wed, Jan 04, 2012 at 11:03:54PM +0100, Kay Sievers wrote:
> On Wed, Jan 4, 2012 at 01:31, Greg KH <greg@kroah.com> wrote:
> > On Wed, Jan 04, 2012 at 01:07:52AM +0100, Kay Sievers wrote:
> >> On Tue, Jan 3, 2012 at 17:21, Greg KH <greg@kroah.com> wrote:
> >> > On Wed, Dec 28, 2011 at 05:45:18PM +1100, Stephen Rothwell wrote:
> >> >> Because of the powerpc problems above, I have used the driver-core tree
> >> >> from next-20111222 for today.
> >> >
> >> > Sorry about all of the problems, we tried to fix everything we could,
> >> > but your merges and cross-builds found stuff we missed :(
> >> >
> >> > Kay, care to send me patches to fix this, and all of the other
> >> > linux-next-reported problems to me so we can get this resolved this
> >> > week?
> >>
> >> I rather don't want to add error checking to stuff that doesn't do it
> >> today. The sysdev stuff never had that forced checks, but the normal
> >> device stuff has.
> >
> > That's fine.
> >
> >> I think the force return value check is really a pretty misguided idea
> >> in general, and it's up to the caller to do these checks and handle
> >> rollbacks, not the driver core, I think.
> >>
> >> Can't we just remove that forced check?
> >
> > Probably, if it fixes these warning-is-an-error problems. There were
> > other issues with linux-next that were build issues, not just this one
> > from what I recall, that kept Stephen from including the tree in
> > linux-next. I can bounce them to you if you missed them.
>
> Oh, I thought that was all: "I fixed it up (see below) and can carry
> the fix as necessary" material.
>
> I might have missed some stuff, I don't see any others. Care to check
> yours and let me know?
Ok, I think you are right, I've pushed the "remove __must_check" patch
to driver-core-next and hopefully it should all be good now.
thanks,
greg k-h
^ permalink raw reply [flat|nested] 181+ messages in thread
* Re: linux-next: build failure after merge of the driver-core tree
2011-12-28 6:45 Stephen Rothwell
2012-01-03 16:21 ` Greg KH
@ 2012-01-04 23:07 ` Greg KH
2012-01-04 23:48 ` Stephen Rothwell
1 sibling, 1 reply; 181+ messages in thread
From: Greg KH @ 2012-01-04 23:07 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linux-next, linux-kernel, Josh Triplett, Kay Sievers
On Wed, Dec 28, 2011 at 05:45:18PM +1100, Stephen Rothwell wrote:
> Hi Greg,
>
> After merging the driver-core tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
>
> arch/powerpc/platforms/cell/spu_base.c: In function 'spu_add_dev_attr':
> arch/powerpc/platforms/cell/spu_base.c:533:21: error: ignoring return value of 'device_create_file', declared with attribute warn_unused_result [-Werror=unused-result]
> cc1: all warnings being treated as errors
> arch/powerpc/kernel/sysfs.c: In function 'topology_init':
> arch/powerpc/kernel/sysfs.c:658:22: error: ignoring return value of 'device_create_file', declared with attribute warn_unused_result [-Werror=unused-result]
> arch/powerpc/kernel/sysfs.c: In function 'register_cpu_online':
> arch/powerpc/kernel/sysfs.c:346:21: error: ignoring return value of 'device_create_file', declared with attribute warn_unused_result [-Werror=unused-result]
> arch/powerpc/kernel/sysfs.c:380:21: error: ignoring return value of 'device_create_file', declared with attribute warn_unused_result [-Werror=unused-result]
> arch/powerpc/kernel/sysfs.c:384:22: error: ignoring return value of 'device_create_file', declared with attribute warn_unused_result [-Werror=unused-result]
> arch/powerpc/kernel/sysfs.c:388:21: error: ignoring return value of 'device_create_file', declared with attribute warn_unused_result [-Werror=unused-result]
> arch/powerpc/kernel/sysfs.c:391:21: error: ignoring return value of 'device_create_file', declared with attribute warn_unused_result [-Werror=unused-result]
> arch/powerpc/kernel/sysfs.c:394:21: error: ignoring return value of 'device_create_file', declared with attribute warn_unused_result [-Werror=unused-result]
> arch/powerpc/kernel/sysfs.c:397:21: error: ignoring return value of 'device_create_file', declared with attribute warn_unused_result [-Werror=unused-result]
> arch/powerpc/kernel/sysfs.c:400:21: error: ignoring return value of 'device_create_file', declared with attribute warn_unused_result [-Werror=unused-result]
> arch/powerpc/kernel/sysfs.c: In function 'cpu_add_dev_attr':
> arch/powerpc/kernel/sysfs.c:532:21: error: ignoring return value of 'device_create_file', declared with attribute warn_unused_result [-Werror=unused-result]
> cc1: all warnings being treated as errors
>
> Caused by commit 8a25a2fd126c ("cpu: convert 'cpu' and 'machinecheck'
> sysdev_class to a regular subsystem"). Powerpc builds parts of
> arch/powerpc with -Werror.
Ok, I'll take off the warn_unused_result flag for device_create_file for
now, which should solve this, and your other build problems with the
driver-core tree.
> drivers/base/cpu.c: In function 'cpu_is_hotpluggable':
> drivers/base/cpu.c:272:9: error: implicit declaration of function 'get_cpu_sysdev' [-Werror=implicit-function-declaration]
> drivers/base/cpu.c:272:27: warning: initialization makes pointer from integer without a cast [enabled by default]
> drivers/base/cpu.c:273:16: error: 'struct cpu' has no member named 'sysdev'
> drivers/base/cpu.c:273:16: warning: initialization from incompatible pointer type [enabled by default]
> drivers/base/cpu.c:273:16: error: 'struct cpu' has no member named 'sysdev'
> drivers/base/cpu.c:274:1: warning: control reaches end of non-void function [-Wreturn-type]
>
> Caused by the above commit interacting with commit 2987557f52b9
> ("driver-core/cpu: Expose hotpluggability to the rest of the kernel")
> from the tip tree. This is will fix up in the merge commit next time.
Yeah, nothing I can do here about this, sorry.
So this should fix the build problems in the driver-core-next branch for
linux-next.
thanks,
greg k-h
^ permalink raw reply [flat|nested] 181+ messages in thread
* Re: linux-next: build failure after merge of the driver-core tree
2012-01-04 0:31 ` Greg KH
@ 2012-01-04 22:03 ` Kay Sievers
2012-01-04 23:13 ` Greg KH
0 siblings, 1 reply; 181+ messages in thread
From: Kay Sievers @ 2012-01-04 22:03 UTC (permalink / raw)
To: Greg KH; +Cc: Stephen Rothwell, linux-next, linux-kernel, Josh Triplett
On Wed, Jan 4, 2012 at 01:31, Greg KH <greg@kroah.com> wrote:
> On Wed, Jan 04, 2012 at 01:07:52AM +0100, Kay Sievers wrote:
>> On Tue, Jan 3, 2012 at 17:21, Greg KH <greg@kroah.com> wrote:
>> > On Wed, Dec 28, 2011 at 05:45:18PM +1100, Stephen Rothwell wrote:
>> >> Because of the powerpc problems above, I have used the driver-core tree
>> >> from next-20111222 for today.
>> >
>> > Sorry about all of the problems, we tried to fix everything we could,
>> > but your merges and cross-builds found stuff we missed :(
>> >
>> > Kay, care to send me patches to fix this, and all of the other
>> > linux-next-reported problems to me so we can get this resolved this
>> > week?
>>
>> I rather don't want to add error checking to stuff that doesn't do it
>> today. The sysdev stuff never had that forced checks, but the normal
>> device stuff has.
>
> That's fine.
>
>> I think the force return value check is really a pretty misguided idea
>> in general, and it's up to the caller to do these checks and handle
>> rollbacks, not the driver core, I think.
>>
>> Can't we just remove that forced check?
>
> Probably, if it fixes these warning-is-an-error problems. There were
> other issues with linux-next that were build issues, not just this one
> from what I recall, that kept Stephen from including the tree in
> linux-next. I can bounce them to you if you missed them.
Oh, I thought that was all: "I fixed it up (see below) and can carry
the fix as necessary" material.
I might have missed some stuff, I don't see any others. Care to check
yours and let me know?
Thanks and sorry,
Kay
^ permalink raw reply [flat|nested] 181+ messages in thread
* Re: linux-next: build failure after merge of the driver-core tree
2012-01-04 0:07 ` Kay Sievers
@ 2012-01-04 0:31 ` Greg KH
2012-01-04 22:03 ` Kay Sievers
0 siblings, 1 reply; 181+ messages in thread
From: Greg KH @ 2012-01-04 0:31 UTC (permalink / raw)
To: Kay Sievers; +Cc: Stephen Rothwell, linux-next, linux-kernel, Josh Triplett
On Wed, Jan 04, 2012 at 01:07:52AM +0100, Kay Sievers wrote:
> On Tue, Jan 3, 2012 at 17:21, Greg KH <greg@kroah.com> wrote:
> > On Wed, Dec 28, 2011 at 05:45:18PM +1100, Stephen Rothwell wrote:
> >> Because of the powerpc problems above, I have used the driver-core tree
> >> from next-20111222 for today.
> >
> > Sorry about all of the problems, we tried to fix everything we could,
> > but your merges and cross-builds found stuff we missed :(
> >
> > Kay, care to send me patches to fix this, and all of the other
> > linux-next-reported problems to me so we can get this resolved this
> > week?
>
> I rather don't want to add error checking to stuff that doesn't do it
> today. The sysdev stuff never had that forced checks, but the normal
> device stuff has.
That's fine.
> I think the force return value check is really a pretty misguided idea
> in general, and it's up to the caller to do these checks and handle
> rollbacks, not the driver core, I think.
>
> Can't we just remove that forced check?
Probably, if it fixes these warning-is-an-error problems. There were
other issues with linux-next that were build issues, not just this one
from what I recall, that kept Stephen from including the tree in
linux-next. I can bounce them to you if you missed them.
thanks,
greg k-h
^ permalink raw reply [flat|nested] 181+ messages in thread
* Re: linux-next: build failure after merge of the driver-core tree
2012-01-03 16:21 ` Greg KH
@ 2012-01-04 0:07 ` Kay Sievers
2012-01-04 0:31 ` Greg KH
0 siblings, 1 reply; 181+ messages in thread
From: Kay Sievers @ 2012-01-04 0:07 UTC (permalink / raw)
To: Greg KH; +Cc: Stephen Rothwell, linux-next, linux-kernel, Josh Triplett
On Tue, Jan 3, 2012 at 17:21, Greg KH <greg@kroah.com> wrote:
> On Wed, Dec 28, 2011 at 05:45:18PM +1100, Stephen Rothwell wrote:
>> Because of the powerpc problems above, I have used the driver-core tree
>> from next-20111222 for today.
>
> Sorry about all of the problems, we tried to fix everything we could,
> but your merges and cross-builds found stuff we missed :(
>
> Kay, care to send me patches to fix this, and all of the other
> linux-next-reported problems to me so we can get this resolved this
> week?
I rather don't want to add error checking to stuff that doesn't do it
today. The sysdev stuff never had that forced checks, but the normal
device stuff has.
I think the force return value check is really a pretty misguided idea
in general, and it's up to the caller to do these checks and handle
rollbacks, not the driver core, I think.
Can't we just remove that forced check?
Kay
^ permalink raw reply [flat|nested] 181+ messages in thread
* Re: linux-next: build failure after merge of the driver-core tree
2011-12-28 6:45 Stephen Rothwell
@ 2012-01-03 16:21 ` Greg KH
2012-01-04 0:07 ` Kay Sievers
2012-01-04 23:07 ` Greg KH
1 sibling, 1 reply; 181+ messages in thread
From: Greg KH @ 2012-01-03 16:21 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linux-next, linux-kernel, Josh Triplett, Kay Sievers
On Wed, Dec 28, 2011 at 05:45:18PM +1100, Stephen Rothwell wrote:
> Because of the powerpc problems above, I have used the driver-core tree
> from next-20111222 for today.
Sorry about all of the problems, we tried to fix everything we could,
but your merges and cross-builds found stuff we missed :(
Kay, care to send me patches to fix this, and all of the other
linux-next-reported problems to me so we can get this resolved this
week?
thanks,
greg k-h
^ permalink raw reply [flat|nested] 181+ messages in thread
* linux-next: build failure after merge of the driver-core tree
@ 2011-12-28 6:45 Stephen Rothwell
2012-01-03 16:21 ` Greg KH
2012-01-04 23:07 ` Greg KH
0 siblings, 2 replies; 181+ messages in thread
From: Stephen Rothwell @ 2011-12-28 6:45 UTC (permalink / raw)
To: Greg KH; +Cc: linux-next, linux-kernel, Josh Triplett, Kay Sievers
[-- Attachment #1: Type: text/plain, Size: 3733 bytes --]
Hi Greg,
After merging the driver-core tree, today's linux-next build (powerpc
ppc64_defconfig) failed like this:
arch/powerpc/platforms/cell/spu_base.c: In function 'spu_add_dev_attr':
arch/powerpc/platforms/cell/spu_base.c:533:21: error: ignoring return value of 'device_create_file', declared with attribute warn_unused_result [-Werror=unused-result]
cc1: all warnings being treated as errors
arch/powerpc/kernel/sysfs.c: In function 'topology_init':
arch/powerpc/kernel/sysfs.c:658:22: error: ignoring return value of 'device_create_file', declared with attribute warn_unused_result [-Werror=unused-result]
arch/powerpc/kernel/sysfs.c: In function 'register_cpu_online':
arch/powerpc/kernel/sysfs.c:346:21: error: ignoring return value of 'device_create_file', declared with attribute warn_unused_result [-Werror=unused-result]
arch/powerpc/kernel/sysfs.c:380:21: error: ignoring return value of 'device_create_file', declared with attribute warn_unused_result [-Werror=unused-result]
arch/powerpc/kernel/sysfs.c:384:22: error: ignoring return value of 'device_create_file', declared with attribute warn_unused_result [-Werror=unused-result]
arch/powerpc/kernel/sysfs.c:388:21: error: ignoring return value of 'device_create_file', declared with attribute warn_unused_result [-Werror=unused-result]
arch/powerpc/kernel/sysfs.c:391:21: error: ignoring return value of 'device_create_file', declared with attribute warn_unused_result [-Werror=unused-result]
arch/powerpc/kernel/sysfs.c:394:21: error: ignoring return value of 'device_create_file', declared with attribute warn_unused_result [-Werror=unused-result]
arch/powerpc/kernel/sysfs.c:397:21: error: ignoring return value of 'device_create_file', declared with attribute warn_unused_result [-Werror=unused-result]
arch/powerpc/kernel/sysfs.c:400:21: error: ignoring return value of 'device_create_file', declared with attribute warn_unused_result [-Werror=unused-result]
arch/powerpc/kernel/sysfs.c: In function 'cpu_add_dev_attr':
arch/powerpc/kernel/sysfs.c:532:21: error: ignoring return value of 'device_create_file', declared with attribute warn_unused_result [-Werror=unused-result]
cc1: all warnings being treated as errors
Caused by commit 8a25a2fd126c ("cpu: convert 'cpu' and 'machinecheck'
sysdev_class to a regular subsystem"). Powerpc builds parts of
arch/powerpc with -Werror.
drivers/base/cpu.c: In function 'cpu_is_hotpluggable':
drivers/base/cpu.c:272:9: error: implicit declaration of function 'get_cpu_sysdev' [-Werror=implicit-function-declaration]
drivers/base/cpu.c:272:27: warning: initialization makes pointer from integer without a cast [enabled by default]
drivers/base/cpu.c:273:16: error: 'struct cpu' has no member named 'sysdev'
drivers/base/cpu.c:273:16: warning: initialization from incompatible pointer type [enabled by default]
drivers/base/cpu.c:273:16: error: 'struct cpu' has no member named 'sysdev'
drivers/base/cpu.c:274:1: warning: control reaches end of non-void function [-Wreturn-type]
Caused by the above commit interacting with commit 2987557f52b9
("driver-core/cpu: Expose hotpluggability to the rest of the kernel")
from the tip tree. This is will fix up in the merge commit next time.
drivers/base/cpu.c: In function 'register_cpu_control':
drivers/base/cpu.c:66:20: warning: ignoring return value of 'device_create_file', declared with attribute warn_unused_result [-Wunused-result]
cc1: some warnings being treated as errors
Caused by the above commit.
Because of the powerpc problems above, I have used the driver-core tree
from next-20111222 for today.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 181+ messages in thread
* Re: linux-next: build failure after merge of the driver-core tree
2011-12-15 10:10 ` Kay Sievers
@ 2011-12-15 19:09 ` Greg KH
0 siblings, 0 replies; 181+ messages in thread
From: Greg KH @ 2011-12-15 19:09 UTC (permalink / raw)
To: Kay Sievers; +Cc: Stephen Rothwell, linux-next, linux-kernel
On Thu, Dec 15, 2011 at 11:10:26AM +0100, Kay Sievers wrote:
> On Thu, Dec 15, 2011 at 08:21, Greg KH <greg@kroah.com> wrote:
> > On Thu, Dec 15, 2011 at 05:37:54PM +1100, Stephen Rothwell wrote:
> >> After merging the driver-core tree, today's linux-next build (x86_64
> >> allmodconfig) failed like this:
> >>
> >> drivers/xen/xen-selfballoon.c:305:36: error: expected ')' before '(' token
> >> drivers/xen/xen-selfballoon.c:327:42: error: expected ')' before '(' token
> >> drivers/xen/xen-selfballoon.c:349:48: error: expected ')' before '(' token
> >>
> >> etc ...
> >>
> >> [Along with many warnings like:
> >>
> >> drivers/xen/xen-selfballoon.c:284:8: warning: 'struct device_attribute' declared inside parameter list [enabled by default]
> >> ]
> >>
> >> Presumably caused by commit drivers/xen/xen-selfballoon.c ("xen-balloon:
> >> convert sysdev_class to a regular subsystem").
> >
> > Ick, Kay, can you make a fix-up patch?
> >
> > And here I thought I built xen in my test kernel, crap, sorry about
> > that.
>
> It seems it's a compiler version issue, or similar. I'm unable to
> reproduce it here, allmodconfig and the Xen part gets through without
> any problems.
>
> I guess we both have very recent systems again. :)
>
> I expect adding a device.h include will fix it. I'll send you a patch.
Yeah, that fixed it (I was able to duplicate this on my laptop, odd that
my build machine didn't show it.)
Now pushed out to my tree.
thanks,
greg k-h
^ permalink raw reply [flat|nested] 181+ messages in thread
* Re: linux-next: build failure after merge of the driver-core tree
2011-12-15 7:21 ` Greg KH
@ 2011-12-15 10:10 ` Kay Sievers
2011-12-15 19:09 ` Greg KH
0 siblings, 1 reply; 181+ messages in thread
From: Kay Sievers @ 2011-12-15 10:10 UTC (permalink / raw)
To: Greg KH; +Cc: Stephen Rothwell, linux-next, linux-kernel
On Thu, Dec 15, 2011 at 08:21, Greg KH <greg@kroah.com> wrote:
> On Thu, Dec 15, 2011 at 05:37:54PM +1100, Stephen Rothwell wrote:
>> After merging the driver-core tree, today's linux-next build (x86_64
>> allmodconfig) failed like this:
>>
>> drivers/xen/xen-selfballoon.c:305:36: error: expected ')' before '(' token
>> drivers/xen/xen-selfballoon.c:327:42: error: expected ')' before '(' token
>> drivers/xen/xen-selfballoon.c:349:48: error: expected ')' before '(' token
>>
>> etc ...
>>
>> [Along with many warnings like:
>>
>> drivers/xen/xen-selfballoon.c:284:8: warning: 'struct device_attribute' declared inside parameter list [enabled by default]
>> ]
>>
>> Presumably caused by commit drivers/xen/xen-selfballoon.c ("xen-balloon:
>> convert sysdev_class to a regular subsystem").
>
> Ick, Kay, can you make a fix-up patch?
>
> And here I thought I built xen in my test kernel, crap, sorry about
> that.
It seems it's a compiler version issue, or similar. I'm unable to
reproduce it here, allmodconfig and the Xen part gets through without
any problems.
I guess we both have very recent systems again. :)
I expect adding a device.h include will fix it. I'll send you a patch.
Thanks,
Kay
^ permalink raw reply [flat|nested] 181+ messages in thread
* Re: linux-next: build failure after merge of the driver-core tree
2011-12-15 6:37 Stephen Rothwell
@ 2011-12-15 7:21 ` Greg KH
2011-12-15 10:10 ` Kay Sievers
0 siblings, 1 reply; 181+ messages in thread
From: Greg KH @ 2011-12-15 7:21 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linux-next, linux-kernel, Kay Sievers
On Thu, Dec 15, 2011 at 05:37:54PM +1100, Stephen Rothwell wrote:
> Hi Greg,
>
> After merging the driver-core tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
>
> drivers/xen/xen-selfballoon.c:305:36: error: expected ')' before '(' token
> drivers/xen/xen-selfballoon.c:327:42: error: expected ')' before '(' token
> drivers/xen/xen-selfballoon.c:349:48: error: expected ')' before '(' token
>
> etc ...
>
> [Along with many warnings like:
>
> drivers/xen/xen-selfballoon.c:284:8: warning: 'struct device_attribute' declared inside parameter list [enabled by default]
> ]
>
> Presumably caused by commit drivers/xen/xen-selfballoon.c ("xen-balloon:
> convert sysdev_class to a regular subsystem").
Ick, Kay, can you make a fix-up patch?
And here I thought I built xen in my test kernel, crap, sorry about
that.
greg k-h
^ permalink raw reply [flat|nested] 181+ messages in thread
* linux-next: build failure after merge of the driver-core tree
@ 2011-12-15 6:37 Stephen Rothwell
2011-12-15 7:21 ` Greg KH
0 siblings, 1 reply; 181+ messages in thread
From: Stephen Rothwell @ 2011-12-15 6:37 UTC (permalink / raw)
To: Greg KH; +Cc: linux-next, linux-kernel, Kay Sievers
[-- Attachment #1: Type: text/plain, Size: 818 bytes --]
Hi Greg,
After merging the driver-core tree, today's linux-next build (x86_64
allmodconfig) failed like this:
drivers/xen/xen-selfballoon.c:305:36: error: expected ')' before '(' token
drivers/xen/xen-selfballoon.c:327:42: error: expected ')' before '(' token
drivers/xen/xen-selfballoon.c:349:48: error: expected ')' before '(' token
etc ...
[Along with many warnings like:
drivers/xen/xen-selfballoon.c:284:8: warning: 'struct device_attribute' declared inside parameter list [enabled by default]
]
Presumably caused by commit drivers/xen/xen-selfballoon.c ("xen-balloon:
convert sysdev_class to a regular subsystem").
I have used the driver-core tree from next-20111213 for today.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 181+ messages in thread
* Re: linux-next: build failure after merge of the driver-core tree
2011-12-14 17:01 ` Greg KH
@ 2011-12-14 19:24 ` Greg KH
0 siblings, 0 replies; 181+ messages in thread
From: Greg KH @ 2011-12-14 19:24 UTC (permalink / raw)
To: Peter Zijlstra
Cc: Stephen Rothwell, linux-next, linux-kernel, Alexey Dobriyan,
Andrew Morton
On Wed, Dec 14, 2011 at 09:01:44AM -0800, Greg KH wrote:
> On Wed, Dec 14, 2011 at 04:13:05PM +0100, Peter Zijlstra wrote:
> > On Wed, 2011-12-14 at 07:03 -0800, Greg KH wrote:
> >
> > > I'll remove the use of kfree in the WARN_ON(), which should solve this
> > > problem.
> >
> > The alternative is that we introduce something like CONFIG_KREF_DEBUG
> > and out-of-line the functions in that case while also adding more debug
> > checks. Alexey recently proposed a refcnt.h thing that almost does what
> > kref does but has different debug checks.
>
> That might be nice to have, but the kfree check was there to catch
> people who were trying to be "tricky", and they will not be running with
> that debug option enabled.
>
> I'll just remove it, and rely on the documentation and public
> humiliation instead of kernel warnings to try to enforce this rule.
> It's worked pretty good so far with the kobject rules :)
Here's the patch I just applied to the driver-core-next tree, which
should resolve this build problem.
>From 6261ddee70174372d6a75601f40719b7a5392f3f Mon Sep 17 00:00:00 2001
From: Greg Kroah-Hartman <gregkh@suse.de>
Date: Wed, 14 Dec 2011 11:19:07 -0800
Subject: kref: fix up the kfree build problems
It turns out that some memory allocators use kobjects, which use krefs,
and kref.h was wanting to figure out the address of kfree(), which ended
up in a loop.
kfree was only being needed for a warning to tell the caller that they
were doing something stupid. Now we just move that warning into the
comments for the functions, which results in a bit more fun as everyone
enjoys digging for people to mock at times of boredom.
So, remove the dependancy of slab.h on kref.h, and fix up the other
include file as well (we really only need bug.h and atomic.h, not
types.h).
Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Alexey Dobriyan <adobriyan@gmail.com>
Cc: Eric Dumazet <eric.dumazet@gmail.com>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Oliver Neukum <oneukum@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
include/linux/kref.h | 15 ++++++++++-----
1 files changed, 10 insertions(+), 5 deletions(-)
diff --git a/include/linux/kref.h b/include/linux/kref.h
index d66c88a..abc0120 100644
--- a/include/linux/kref.h
+++ b/include/linux/kref.h
@@ -15,8 +15,8 @@
#ifndef _KREF_H_
#define _KREF_H_
-#include <linux/types.h>
-#include <linux/slab.h>
+#include <linux/bug.h>
+#include <linux/atomic.h>
struct kref {
atomic_t refcount;
@@ -48,7 +48,10 @@ static inline void kref_get(struct kref *kref)
* @release: pointer to the function that will clean up the object when the
* last reference to the object is released.
* This pointer is required, and it is not acceptable to pass kfree
- * in as this function.
+ * in as this function. If the caller does pass kfree to this
+ * function, you will be publicly mocked mercilessly by the kref
+ * maintainer, and anyone else who happens to notice it. You have
+ * been warned.
*
* Subtract @count from the refcount, and if 0, call release().
* Return 1 if the object was removed, otherwise return 0. Beware, if this
@@ -60,7 +63,6 @@ static inline int kref_sub(struct kref *kref, unsigned int count,
void (*release)(struct kref *kref))
{
WARN_ON(release == NULL);
- WARN_ON(release == (void (*)(struct kref *))kfree);
if (atomic_sub_and_test((int) count, &kref->refcount)) {
release(kref);
@@ -75,7 +77,10 @@ static inline int kref_sub(struct kref *kref, unsigned int count,
* @release: pointer to the function that will clean up the object when the
* last reference to the object is released.
* This pointer is required, and it is not acceptable to pass kfree
- * in as this function.
+ * in as this function. If the caller does pass kfree to this
+ * function, you will be publicly mocked mercilessly by the kref
+ * maintainer, and anyone else who happens to notice it. You have
+ * been warned.
*
* Decrement the refcount, and if 0, call release().
* Return 1 if the object was removed, otherwise return 0. Beware, if this
--
1.7.7.3
^ permalink raw reply related [flat|nested] 181+ messages in thread
* Re: linux-next: build failure after merge of the driver-core tree
2011-12-14 15:13 ` Peter Zijlstra
@ 2011-12-14 17:01 ` Greg KH
2011-12-14 19:24 ` Greg KH
0 siblings, 1 reply; 181+ messages in thread
From: Greg KH @ 2011-12-14 17:01 UTC (permalink / raw)
To: Peter Zijlstra
Cc: Stephen Rothwell, linux-next, linux-kernel, Alexey Dobriyan,
Andrew Morton
On Wed, Dec 14, 2011 at 04:13:05PM +0100, Peter Zijlstra wrote:
> On Wed, 2011-12-14 at 07:03 -0800, Greg KH wrote:
>
> > I'll remove the use of kfree in the WARN_ON(), which should solve this
> > problem.
>
> The alternative is that we introduce something like CONFIG_KREF_DEBUG
> and out-of-line the functions in that case while also adding more debug
> checks. Alexey recently proposed a refcnt.h thing that almost does what
> kref does but has different debug checks.
That might be nice to have, but the kfree check was there to catch
people who were trying to be "tricky", and they will not be running with
that debug option enabled.
I'll just remove it, and rely on the documentation and public
humiliation instead of kernel warnings to try to enforce this rule.
It's worked pretty good so far with the kobject rules :)
thanks,
greg k-h
^ permalink raw reply [flat|nested] 181+ messages in thread
* Re: linux-next: build failure after merge of the driver-core tree
2011-12-14 15:03 ` Greg KH
@ 2011-12-14 15:13 ` Peter Zijlstra
2011-12-14 17:01 ` Greg KH
0 siblings, 1 reply; 181+ messages in thread
From: Peter Zijlstra @ 2011-12-14 15:13 UTC (permalink / raw)
To: Greg KH
Cc: Stephen Rothwell, linux-next, linux-kernel, Alexey Dobriyan,
Andrew Morton
On Wed, 2011-12-14 at 07:03 -0800, Greg KH wrote:
> I'll remove the use of kfree in the WARN_ON(), which should solve this
> problem.
The alternative is that we introduce something like CONFIG_KREF_DEBUG
and out-of-line the functions in that case while also adding more debug
checks. Alexey recently proposed a refcnt.h thing that almost does what
kref does but has different debug checks.
^ permalink raw reply [flat|nested] 181+ messages in thread
* Re: linux-next: build failure after merge of the driver-core tree
2011-12-14 9:24 ` Peter Zijlstra
@ 2011-12-14 15:03 ` Greg KH
2011-12-14 15:13 ` Peter Zijlstra
0 siblings, 1 reply; 181+ messages in thread
From: Greg KH @ 2011-12-14 15:03 UTC (permalink / raw)
To: Peter Zijlstra; +Cc: Stephen Rothwell, linux-next, linux-kernel
On Wed, Dec 14, 2011 at 10:24:57AM +0100, Peter Zijlstra wrote:
> On Wed, 2011-12-14 at 15:48 +1100, Stephen Rothwell wrote:
> > Hi Greg,
> >
> > After merging the driver-core tree, today's linux-next build
> > (powerpc_ppc64_defconfig) failed like this:
> >
> > In file included from include/linux/slab.h:185:0,
> > from include/linux/kref.h:19,
> > from include/linux/kobject.h:24,
> > from include/linux/sysdev.h:24,
> > from include/linux/node.h:17,
> > from include/linux/swap.h:10,
> > from include/linux/suspend.h:4,
> > from arch/powerpc/kernel/asm-offsets.c:24:
> > include/linux/slub_def.h:100:17: error: field 'kobj' has incomplete type
> >
> > Caused by commit 4af679cd7cbb ("kref: Inline all functions") ... we now
> > have kref.h -> slab.h -> slub_def.h -> kobject.h -> kref.h when
> > CONFIG_SLUB is set.
>
> Egads, that's nasty..
>
> The nicest thing I can come up with is something like the below, but its
> not all that nice at all :/
I'll remove the use of kfree in the WARN_ON(), which should solve this
problem.
greg k-h
^ permalink raw reply [flat|nested] 181+ messages in thread
* Re: linux-next: build failure after merge of the driver-core tree
2011-12-14 4:48 Stephen Rothwell
@ 2011-12-14 9:24 ` Peter Zijlstra
2011-12-14 15:03 ` Greg KH
0 siblings, 1 reply; 181+ messages in thread
From: Peter Zijlstra @ 2011-12-14 9:24 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: Greg KH, linux-next, linux-kernel
On Wed, 2011-12-14 at 15:48 +1100, Stephen Rothwell wrote:
> Hi Greg,
>
> After merging the driver-core tree, today's linux-next build
> (powerpc_ppc64_defconfig) failed like this:
>
> In file included from include/linux/slab.h:185:0,
> from include/linux/kref.h:19,
> from include/linux/kobject.h:24,
> from include/linux/sysdev.h:24,
> from include/linux/node.h:17,
> from include/linux/swap.h:10,
> from include/linux/suspend.h:4,
> from arch/powerpc/kernel/asm-offsets.c:24:
> include/linux/slub_def.h:100:17: error: field 'kobj' has incomplete type
>
> Caused by commit 4af679cd7cbb ("kref: Inline all functions") ... we now
> have kref.h -> slab.h -> slub_def.h -> kobject.h -> kref.h when
> CONFIG_SLUB is set.
Egads, that's nasty..
The nicest thing I can come up with is something like the below, but its
not all that nice at all :/
---
--- a/include/linux/kref.h
+++ b/include/linux/kref.h
@@ -16,7 +16,8 @@
#define _KREF_H_
#include <linux/types.h>
-#include <linux/slab.h>
+
+extern void kfree(const void *);
struct kref {
atomic_t refcount;
^ permalink raw reply [flat|nested] 181+ messages in thread
* linux-next: build failure after merge of the driver-core tree
@ 2011-12-14 4:48 Stephen Rothwell
2011-12-14 9:24 ` Peter Zijlstra
0 siblings, 1 reply; 181+ messages in thread
From: Stephen Rothwell @ 2011-12-14 4:48 UTC (permalink / raw)
To: Greg KH; +Cc: linux-next, linux-kernel, Peter Zijlstra
[-- Attachment #1: Type: text/plain, Size: 903 bytes --]
Hi Greg,
After merging the driver-core tree, today's linux-next build
(powerpc_ppc64_defconfig) failed like this:
In file included from include/linux/slab.h:185:0,
from include/linux/kref.h:19,
from include/linux/kobject.h:24,
from include/linux/sysdev.h:24,
from include/linux/node.h:17,
from include/linux/swap.h:10,
from include/linux/suspend.h:4,
from arch/powerpc/kernel/asm-offsets.c:24:
include/linux/slub_def.h:100:17: error: field 'kobj' has incomplete type
Caused by commit 4af679cd7cbb ("kref: Inline all functions") ... we now
have kref.h -> slab.h -> slub_def.h -> kobject.h -> kref.h when
CONFIG_SLUB is set.
I have used the driver-core tree from next-20111213 for today.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 181+ messages in thread
* linux-next: build failure after merge of the driver-core tree
@ 2011-11-21 1:57 Stephen Rothwell
0 siblings, 0 replies; 181+ messages in thread
From: Stephen Rothwell @ 2011-11-21 1:57 UTC (permalink / raw)
To: Greg KH; +Cc: linux-next, linux-kernel, Alessandro Rubini
[-- Attachment #1: Type: text/plain, Size: 598 bytes --]
Hi Greg,
After merging the driver-core tree, today's linux-next build (powerpc
ppc64_defconfig) failed like this:
fs/debugfs/file.c: In function 'debugfs_print_regs32':
fs/debugfs/file.c:560:7: error: implicit declaration of function 'readl' [-Werror=implicit-function-declaration]
Caused by commit 1a087c6ad975 ("debugfs: add tools to printk 32-bit
registers"). To use readl(), linux/io.h should be included.
I have used the driver-core tree from next-20111118 for today.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 181+ messages in thread
* Re: linux-next: build failure after merge of the driver-core tree
2010-08-04 4:25 Stephen Rothwell
2010-08-04 4:44 ` Guenter Roeck
2010-08-04 15:52 ` Greg KH
@ 2010-08-04 21:24 ` Jesse Barnes
2 siblings, 0 replies; 181+ messages in thread
From: Jesse Barnes @ 2010-08-04 21:24 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Greg KH, linux-next, linux-kernel, Narendra K, Jordan Hargrave,
Guenter Roeck
On Wed, 4 Aug 2010 14:25:31 +1000
Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> Hi Greg,
>
> After merging the driver-core tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
>
> drivers/pci/pci-label.c:100: error: unknown field 'owner' specified in initializer
> drivers/pci/pci-label.c:100: warning: initialization from incompatible pointer type
> drivers/pci/pci-label.c:105: error: unknown field 'owner' specified in initializer
> drivers/pci/pci-label.c:105: warning: initialization from incompatible pointer type
>
> Caused by commit 60cc62ad579afa0eb5bded82e08dd0617d461d52 ("sysfs: Remove
> owner field from sysfs struct attribute") interacting with commit
> 911e1c9b05a8e3559a7aa89083930700a0b9e7ee ("PCI: export SMBIOS provided
> firmware instance and label to sysfs") from the pci tree.
>
> I applied the following merge fix patch (Jesse, this patch can already be
> applied to the pci tree without problems):
>
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Wed, 4 Aug 2010 14:21:42 +1000
> Subject: [PATCH] pci: update for owner removal from struct device_attribute
>
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
Applied, thanks.
--
Jesse Barnes, Intel Open Source Technology Center
^ permalink raw reply [flat|nested] 181+ messages in thread
* Re: linux-next: build failure after merge of the driver-core tree
2010-08-04 4:25 Stephen Rothwell
2010-08-04 4:44 ` Guenter Roeck
@ 2010-08-04 15:52 ` Greg KH
2010-08-04 21:24 ` Jesse Barnes
2 siblings, 0 replies; 181+ messages in thread
From: Greg KH @ 2010-08-04 15:52 UTC (permalink / raw)
To: Stephen Rothwell
Cc: linux-next, linux-kernel, Narendra K, Jordan Hargrave,
Jesse Barnes, Guenter Roeck
On Wed, Aug 04, 2010 at 02:25:31PM +1000, Stephen Rothwell wrote:
> Hi Greg,
>
> After merging the driver-core tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
>
> drivers/pci/pci-label.c:100: error: unknown field 'owner' specified in initializer
> drivers/pci/pci-label.c:100: warning: initialization from incompatible pointer type
> drivers/pci/pci-label.c:105: error: unknown field 'owner' specified in initializer
> drivers/pci/pci-label.c:105: warning: initialization from incompatible pointer type
>
> Caused by commit 60cc62ad579afa0eb5bded82e08dd0617d461d52 ("sysfs: Remove
> owner field from sysfs struct attribute") interacting with commit
> 911e1c9b05a8e3559a7aa89083930700a0b9e7ee ("PCI: export SMBIOS provided
> firmware instance and label to sysfs") from the pci tree.
>
> I applied the following merge fix patch (Jesse, this patch can already be
> applied to the pci tree without problems):
Thanks, your fix looks correct, that field is now gone.
greg k-h
^ permalink raw reply [flat|nested] 181+ messages in thread
* Re: linux-next: build failure after merge of the driver-core tree
2010-08-04 4:25 Stephen Rothwell
@ 2010-08-04 4:44 ` Guenter Roeck
2010-08-04 15:52 ` Greg KH
2010-08-04 21:24 ` Jesse Barnes
2 siblings, 0 replies; 181+ messages in thread
From: Guenter Roeck @ 2010-08-04 4:44 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Greg KH, linux-next, linux-kernel, Narendra K, Jordan Hargrave,
Jesse Barnes
On Wed, Aug 04, 2010 at 12:25:31AM -0400, Stephen Rothwell wrote:
> Hi Greg,
>
> After merging the driver-core tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
>
> drivers/pci/pci-label.c:100: error: unknown field 'owner' specified in initializer
> drivers/pci/pci-label.c:100: warning: initialization from incompatible pointer type
> drivers/pci/pci-label.c:105: error: unknown field 'owner' specified in initializer
> drivers/pci/pci-label.c:105: warning: initialization from incompatible pointer type
>
> Caused by commit 60cc62ad579afa0eb5bded82e08dd0617d461d52 ("sysfs: Remove
> owner field from sysfs struct attribute") interacting with commit
> 911e1c9b05a8e3559a7aa89083930700a0b9e7ee ("PCI: export SMBIOS provided
> firmware instance and label to sysfs") from the pci tree.
>
> I applied the following merge fix patch (Jesse, this patch can already be
> applied to the pci tree without problems):
>
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Wed, 4 Aug 2010 14:21:42 +1000
> Subject: [PATCH] pci: update for owner removal from struct device_attribute
>
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
Acked-by: Guenter Roeck <guenter.roeck@ericsson.com>
Sorry for the trouble. Looks like I missed that by a day.
Guenter
> ---
> drivers/pci/pci-label.c | 4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/pci/pci-label.c b/drivers/pci/pci-label.c
> index 111500e..90c0a72 100644
> --- a/drivers/pci/pci-label.c
> +++ b/drivers/pci/pci-label.c
> @@ -97,12 +97,12 @@ smbiosinstance_show(struct device *dev,
> }
>
> static struct device_attribute smbios_attr_label = {
> - .attr = {.name = "label", .mode = 0444, .owner = THIS_MODULE},
> + .attr = {.name = "label", .mode = 0444},
> .show = smbioslabel_show,
> };
>
> static struct device_attribute smbios_attr_instance = {
> - .attr = {.name = "index", .mode = 0444, .owner = THIS_MODULE},
> + .attr = {.name = "index", .mode = 0444},
> .show = smbiosinstance_show,
> };
>
> --
> 1.7.1
>
> --
> Cheers,
> Stephen Rothwell sfr@canb.auug.org.au
> http://www.canb.auug.org.au/~sfr/
^ permalink raw reply [flat|nested] 181+ messages in thread
* linux-next: build failure after merge of the driver-core tree
@ 2010-08-04 4:25 Stephen Rothwell
2010-08-04 4:44 ` Guenter Roeck
` (2 more replies)
0 siblings, 3 replies; 181+ messages in thread
From: Stephen Rothwell @ 2010-08-04 4:25 UTC (permalink / raw)
To: Greg KH
Cc: linux-next, linux-kernel, Narendra K, Jordan Hargrave,
Jesse Barnes, Guenter Roeck
Hi Greg,
After merging the driver-core tree, today's linux-next build (x86_64
allmodconfig) failed like this:
drivers/pci/pci-label.c:100: error: unknown field 'owner' specified in initializer
drivers/pci/pci-label.c:100: warning: initialization from incompatible pointer type
drivers/pci/pci-label.c:105: error: unknown field 'owner' specified in initializer
drivers/pci/pci-label.c:105: warning: initialization from incompatible pointer type
Caused by commit 60cc62ad579afa0eb5bded82e08dd0617d461d52 ("sysfs: Remove
owner field from sysfs struct attribute") interacting with commit
911e1c9b05a8e3559a7aa89083930700a0b9e7ee ("PCI: export SMBIOS provided
firmware instance and label to sysfs") from the pci tree.
I applied the following merge fix patch (Jesse, this patch can already be
applied to the pci tree without problems):
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Wed, 4 Aug 2010 14:21:42 +1000
Subject: [PATCH] pci: update for owner removal from struct device_attribute
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
drivers/pci/pci-label.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/pci/pci-label.c b/drivers/pci/pci-label.c
index 111500e..90c0a72 100644
--- a/drivers/pci/pci-label.c
+++ b/drivers/pci/pci-label.c
@@ -97,12 +97,12 @@ smbiosinstance_show(struct device *dev,
}
static struct device_attribute smbios_attr_label = {
- .attr = {.name = "label", .mode = 0444, .owner = THIS_MODULE},
+ .attr = {.name = "label", .mode = 0444},
.show = smbioslabel_show,
};
static struct device_attribute smbios_attr_instance = {
- .attr = {.name = "index", .mode = 0444, .owner = THIS_MODULE},
+ .attr = {.name = "index", .mode = 0444},
.show = smbiosinstance_show,
};
--
1.7.1
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
^ permalink raw reply related [flat|nested] 181+ messages in thread
* Re: linux-next: build failure after merge of the driver-core tree
2010-05-18 21:25 ` Greg KH
@ 2010-05-18 21:59 ` Eric W. Biederman
0 siblings, 0 replies; 181+ messages in thread
From: Eric W. Biederman @ 2010-05-18 21:59 UTC (permalink / raw)
To: Greg KH; +Cc: Stephen Rothwell, linux-next, linux-kernel, Al Viro
Greg KH <greg@kroah.com> writes:
> On Tue, May 18, 2010 at 12:58:33PM -0700, Eric W. Biederman wrote:
>>
>> Greg this fixes the conflict with the vfs tree we see in linux-next.
>
> Thanks, I can apply this to my tree right now, right?
Yes it is safe to apply to your tree right now. Apologies if that
wasn't clear.
Eric
^ permalink raw reply [flat|nested] 181+ messages in thread
* Re: linux-next: build failure after merge of the driver-core tree
2010-05-18 19:58 ` Eric W. Biederman
@ 2010-05-18 21:25 ` Greg KH
2010-05-18 21:59 ` Eric W. Biederman
0 siblings, 1 reply; 181+ messages in thread
From: Greg KH @ 2010-05-18 21:25 UTC (permalink / raw)
To: Eric W. Biederman; +Cc: Stephen Rothwell, linux-next, linux-kernel, Al Viro
On Tue, May 18, 2010 at 12:58:33PM -0700, Eric W. Biederman wrote:
>
> Greg this fixes the conflict with the vfs tree we see in linux-next.
Thanks, I can apply this to my tree right now, right?
greg k-h
^ permalink raw reply [flat|nested] 181+ messages in thread
* Re: linux-next: build failure after merge of the driver-core tree
2010-05-18 21:06 ` Chris Wright
@ 2010-05-18 21:24 ` Greg KH
0 siblings, 0 replies; 181+ messages in thread
From: Greg KH @ 2010-05-18 21:24 UTC (permalink / raw)
To: Chris Wright; +Cc: Stephen Rothwell, linux-next, linux-kernel
On Tue, May 18, 2010 at 02:06:07PM -0700, Chris Wright wrote:
> * Greg KH (greg@kroah.com) wrote:
> > On Tue, May 18, 2010 at 04:44:09PM +1000, Stephen Rothwell wrote:
> > > Hi Greg,
> > >
> > > After merging the driver-core tree, today's linux-next build (powerpc
> > > ppc64_defconfig) failed like this:
> > >
> > > cc1: warnings being treated as errors
> > > In file included from include/linux/kobject.h:21,
> > > from include/linux/device.h:17,
> > > from arch/powerpc/lib/devres.c:10:
> > > include/linux/sysfs.h:97: error: 'struct file' declared inside parameter list
> > > include/linux/sysfs.h:97: error: its scope is only this definition or declaration, which is probably not what you want
> > > include/linux/sysfs.h:99: error: 'struct file' declared inside parameter list
> > > include/linux/sysfs.h:101: error: 'struct file' declared inside parameter list
> > >
> > > and many more (arch/powerpc is built with -Werror (as do some other
> > > architectures)) and lots of similar warnings ...
> > >
> > > Caused by commit f8e898186196a22756b50b908ecd92123265f8a2 ("sysfs: add
> > > struct file* to bin_attr callbacks"). See Rule 1 in
> > > Documentation/SubmitChecklist. The header file probably just needs
> > > "struct file;" added in the right place.
> > >
> > > I have reverted that commit for today (and commit
> > > 44e425ab9f887ec6d3a7a4481f3b0c99f120de19 ("pci: check caps from sysfs
> > > file open to read device dependent config space") that depends on it).
> >
> > Ick.
> >
> > Chris, care to send a patch to resolve this?
>
> Would you prefer incremental to fold in, or respin? It's just this
> one-liner fwd declaration as Stephen mentioned.
Incremental to fold in is easier. That way there's no build error in
the tree.
thanks,
greg k-h
^ permalink raw reply [flat|nested] 181+ messages in thread
* Re: linux-next: build failure after merge of the driver-core tree
2010-05-18 14:02 ` Greg KH
2010-05-18 14:04 ` Chris Wright
@ 2010-05-18 21:06 ` Chris Wright
2010-05-18 21:24 ` Greg KH
1 sibling, 1 reply; 181+ messages in thread
From: Chris Wright @ 2010-05-18 21:06 UTC (permalink / raw)
To: Greg KH; +Cc: Stephen Rothwell, Chris Wright, linux-next, linux-kernel
* Greg KH (greg@kroah.com) wrote:
> On Tue, May 18, 2010 at 04:44:09PM +1000, Stephen Rothwell wrote:
> > Hi Greg,
> >
> > After merging the driver-core tree, today's linux-next build (powerpc
> > ppc64_defconfig) failed like this:
> >
> > cc1: warnings being treated as errors
> > In file included from include/linux/kobject.h:21,
> > from include/linux/device.h:17,
> > from arch/powerpc/lib/devres.c:10:
> > include/linux/sysfs.h:97: error: 'struct file' declared inside parameter list
> > include/linux/sysfs.h:97: error: its scope is only this definition or declaration, which is probably not what you want
> > include/linux/sysfs.h:99: error: 'struct file' declared inside parameter list
> > include/linux/sysfs.h:101: error: 'struct file' declared inside parameter list
> >
> > and many more (arch/powerpc is built with -Werror (as do some other
> > architectures)) and lots of similar warnings ...
> >
> > Caused by commit f8e898186196a22756b50b908ecd92123265f8a2 ("sysfs: add
> > struct file* to bin_attr callbacks"). See Rule 1 in
> > Documentation/SubmitChecklist. The header file probably just needs
> > "struct file;" added in the right place.
> >
> > I have reverted that commit for today (and commit
> > 44e425ab9f887ec6d3a7a4481f3b0c99f120de19 ("pci: check caps from sysfs
> > file open to read device dependent config space") that depends on it).
>
> Ick.
>
> Chris, care to send a patch to resolve this?
Would you prefer incremental to fold in, or respin? It's just this
one-liner fwd declaration as Stephen mentioned.
thanks,
-chris
^ permalink raw reply [flat|nested] 181+ messages in thread
* Re: linux-next: build failure after merge of the driver-core tree
2010-05-18 6:45 Stephen Rothwell
2010-05-18 7:00 ` Eric W. Biederman
@ 2010-05-18 19:58 ` Eric W. Biederman
2010-05-18 21:25 ` Greg KH
1 sibling, 1 reply; 181+ messages in thread
From: Eric W. Biederman @ 2010-05-18 19:58 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: Greg KH, linux-next, linux-kernel, Al Viro
Greg this fixes the conflict with the vfs tree we see in linux-next.
Al I will be happy to work with you to rework this hunk of code in the
next cycle so you can kill sb_lock. It is just too late in the cycle
to be making more than the minimal change necessary.
Eric
From: Eric W. Biederman <ebiederm@aristanetworks.com>
Date: Tue, 18 May 2010 12:24:26 -0700
Subject: [PATCH] sysfs: Remove usage of S_BIAS to avoid merge conflict with the vfs tree
In Al's latest vfs tree the code is reworked and S_BIAS has been removed.
It turns out that checking to see if a super block is in the
middle of an unmount in sysfs_exit_ns is unnecessary because we
remove the super_block from the s_supers/s_instances list before
struct sysfs_super_info pointed to by sb->s_fs_info is freed.
For now just delete the unnecessary check to see if a superblock is in the
middle of an unmount, it isn't necessary with or without Al's changes
and it just causes a needless conflict.
Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: Eric W. Biederman <ebiederm@aristanetworks.com>
---
fs/sysfs/mount.c | 11 ++++++++---
1 files changed, 8 insertions(+), 3 deletions(-)
diff --git a/fs/sysfs/mount.c b/fs/sysfs/mount.c
index bbba090..74f0529 100644
--- a/fs/sysfs/mount.c
+++ b/fs/sysfs/mount.c
@@ -144,6 +144,9 @@ static void sysfs_kill_sb(struct super_block *sb)
{
struct sysfs_super_info *info = sysfs_info(sb);
+ /* Remove the superblock from fs_supers/s_instances
+ * so we can't find it, before freeing sysfs_super_info.
+ */
kill_anon_super(sb);
kfree(info);
}
@@ -162,9 +165,11 @@ void sysfs_exit_ns(enum kobj_ns_type type, const void *ns)
spin_lock(&sb_lock);
list_for_each_entry(sb, &sysfs_fs_type.fs_supers, s_instances) {
struct sysfs_super_info *info = sysfs_info(sb);
- /* Ignore superblocks that are in the process of unmounting */
- if (sb->s_count <= S_BIAS)
- continue;
+ /*
+ * If we see a superblock on the fs_supers/s_instances
+ * list the unmount has not completed and sb->s_fs_info
+ * points to a valid struct sysfs_super_info.
+ */
/* Ignore superblocks with the wrong ns */
if (info->ns[type] != ns)
continue;
--
1.6.6.1
^ permalink raw reply related [flat|nested] 181+ messages in thread
* Re: linux-next: build failure after merge of the driver-core tree
2010-05-18 10:35 ` Eric W. Biederman
@ 2010-05-18 15:02 ` Al Viro
0 siblings, 0 replies; 181+ messages in thread
From: Al Viro @ 2010-05-18 15:02 UTC (permalink / raw)
To: Eric W. Biederman; +Cc: Stephen Rothwell, Greg KH, linux-next, linux-kernel
On Tue, May 18, 2010 at 03:35:10AM -0700, Eric W. Biederman wrote:
> Thanks.
>
> I will cook up a proper incremental patch after I get some sleep. Stephen
> it appears those two lines you have commented out are actually unnecessary.
>
> We have
> deactivate_super
> kill_sb aka sysfs_kill_sb
> kill_anon_super
> generic_shutdown_super
> sb_lock
> list_del(sb->s_instances)
> sb_unlock
> kfree(info)
>
> Nothing generic stomps on s_fs_info.
>
> Which means that if I find a superblock on sb->s_instances sb->s_fs_info
> still points to a valid sysfs_super_info.
Except that sb_lock is going away next cycle. There are very few users left
outside of fs/super.c and I'd much prefer it to become static.
^ permalink raw reply [flat|nested] 181+ messages in thread
* Re: linux-next: build failure after merge of the driver-core tree
2010-05-18 14:02 ` Greg KH
@ 2010-05-18 14:04 ` Chris Wright
2010-05-18 21:06 ` Chris Wright
1 sibling, 0 replies; 181+ messages in thread
From: Chris Wright @ 2010-05-18 14:04 UTC (permalink / raw)
To: Greg KH; +Cc: Stephen Rothwell, Chris Wright, linux-next, linux-kernel
* Greg KH (greg@kroah.com) wrote:
> On Tue, May 18, 2010 at 04:44:09PM +1000, Stephen Rothwell wrote:
> > Hi Greg,
> >
> > After merging the driver-core tree, today's linux-next build (powerpc
> > ppc64_defconfig) failed like this:
> >
> > cc1: warnings being treated as errors
> > In file included from include/linux/kobject.h:21,
> > from include/linux/device.h:17,
> > from arch/powerpc/lib/devres.c:10:
> > include/linux/sysfs.h:97: error: 'struct file' declared inside parameter list
> > include/linux/sysfs.h:97: error: its scope is only this definition or declaration, which is probably not what you want
> > include/linux/sysfs.h:99: error: 'struct file' declared inside parameter list
> > include/linux/sysfs.h:101: error: 'struct file' declared inside parameter list
> >
> > and many more (arch/powerpc is built with -Werror (as do some other
> > architectures)) and lots of similar warnings ...
> >
> > Caused by commit f8e898186196a22756b50b908ecd92123265f8a2 ("sysfs: add
> > struct file* to bin_attr callbacks"). See Rule 1 in
> > Documentation/SubmitChecklist. The header file probably just needs
> > "struct file;" added in the right place.
> >
> > I have reverted that commit for today (and commit
> > 44e425ab9f887ec6d3a7a4481f3b0c99f120de19 ("pci: check caps from sysfs
> > file open to read device dependent config space") that depends on it).
>
> Ick.
>
> Chris, care to send a patch to resolve this?
Yeah, I'll see where the header is missing.
thanks,
-chris
^ permalink raw reply [flat|nested] 181+ messages in thread
* Re: linux-next: build failure after merge of the driver-core tree
2010-05-18 6:44 Stephen Rothwell
@ 2010-05-18 14:02 ` Greg KH
2010-05-18 14:04 ` Chris Wright
2010-05-18 21:06 ` Chris Wright
0 siblings, 2 replies; 181+ messages in thread
From: Greg KH @ 2010-05-18 14:02 UTC (permalink / raw)
To: Stephen Rothwell, Chris Wright; +Cc: linux-next, linux-kernel
On Tue, May 18, 2010 at 04:44:09PM +1000, Stephen Rothwell wrote:
> Hi Greg,
>
> After merging the driver-core tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
>
> cc1: warnings being treated as errors
> In file included from include/linux/kobject.h:21,
> from include/linux/device.h:17,
> from arch/powerpc/lib/devres.c:10:
> include/linux/sysfs.h:97: error: 'struct file' declared inside parameter list
> include/linux/sysfs.h:97: error: its scope is only this definition or declaration, which is probably not what you want
> include/linux/sysfs.h:99: error: 'struct file' declared inside parameter list
> include/linux/sysfs.h:101: error: 'struct file' declared inside parameter list
>
> and many more (arch/powerpc is built with -Werror (as do some other
> architectures)) and lots of similar warnings ...
>
> Caused by commit f8e898186196a22756b50b908ecd92123265f8a2 ("sysfs: add
> struct file* to bin_attr callbacks"). See Rule 1 in
> Documentation/SubmitChecklist. The header file probably just needs
> "struct file;" added in the right place.
>
> I have reverted that commit for today (and commit
> 44e425ab9f887ec6d3a7a4481f3b0c99f120de19 ("pci: check caps from sysfs
> file open to read device dependent config space") that depends on it).
Ick.
Chris, care to send a patch to resolve this?
thanks,
greg k-h
^ permalink raw reply [flat|nested] 181+ messages in thread
* Re: linux-next: build failure after merge of the driver-core tree
2010-05-18 7:54 ` Stephen Rothwell
@ 2010-05-18 10:35 ` Eric W. Biederman
2010-05-18 15:02 ` Al Viro
0 siblings, 1 reply; 181+ messages in thread
From: Eric W. Biederman @ 2010-05-18 10:35 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: Greg KH, linux-next, linux-kernel, Al Viro
Stephen Rothwell <sfr@canb.auug.org.au> writes:
> Hi Eric,
>
> On Tue, 18 May 2010 00:00:01 -0700 ebiederm@xmission.com (Eric W. Biederman) wrote:
>>
>> Stephen what is the easiest way to get a copy of Al's tree so I can take
>> a look to see what needs to happen?
>
> It is here:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs-2.6.git#for-next
>
> [The latest list of trees included in linux-next can always be found here:
> http://git.kernel.org/?p=linux/kernel/git/next/linux-next.git;a=blob;f=Next/Trees]
Thanks.
I will cook up a proper incremental patch after I get some sleep. Stephen
it appears those two lines you have commented out are actually unnecessary.
We have
deactivate_super
kill_sb aka sysfs_kill_sb
kill_anon_super
generic_shutdown_super
sb_lock
list_del(sb->s_instances)
sb_unlock
kfree(info)
Nothing generic stomps on s_fs_info.
Which means that if I find a superblock on sb->s_instances sb->s_fs_info
still points to a valid sysfs_super_info.
As as for the race Al mentions between sysfs_exit_ns and
sysfs_readdir, I looked and a small race has crept in. The primary
prevention of problems is that all matching sysfs_dirents for that
namespace are required to be removed before sysfs_exit_ns is called.
What remains is the tiniest of races where a namespace structure is
freed and a new namespace structure of the same type is allocated at
the same address and sysfs_dirents for it are created, all during the
a single kernel readdir operation. Possible with slabs, and
copy_to_user triggering a page fault. Still the worst case is that we
tell userspace some name that it wasn't supposed to see on that mount
point. From a userspace point of view this seems to fall under a
readdir implementations license to return some odd things if the
directory is changing during the readdir call. Overall we do preserve
the property of returning everything that is in the directory between
opendir and the time readdir his the end of file.
Eric
^ permalink raw reply [flat|nested] 181+ messages in thread
* Re: linux-next: build failure after merge of the driver-core tree
2010-05-18 7:00 ` Eric W. Biederman
2010-05-18 7:48 ` Al Viro
@ 2010-05-18 7:54 ` Stephen Rothwell
2010-05-18 10:35 ` Eric W. Biederman
1 sibling, 1 reply; 181+ messages in thread
From: Stephen Rothwell @ 2010-05-18 7:54 UTC (permalink / raw)
To: Eric W. Biederman; +Cc: Greg KH, linux-next, linux-kernel, Al Viro
[-- Attachment #1: Type: text/plain, Size: 576 bytes --]
Hi Eric,
On Tue, 18 May 2010 00:00:01 -0700 ebiederm@xmission.com (Eric W. Biederman) wrote:
>
> Stephen what is the easiest way to get a copy of Al's tree so I can take
> a look to see what needs to happen?
It is here:
git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs-2.6.git#for-next
[The latest list of trees included in linux-next can always be found here:
http://git.kernel.org/?p=linux/kernel/git/next/linux-next.git;a=blob;f=Next/Trees]
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply [flat|nested] 181+ messages in thread
* Re: linux-next: build failure after merge of the driver-core tree
2010-05-18 7:00 ` Eric W. Biederman
@ 2010-05-18 7:48 ` Al Viro
2010-05-18 7:54 ` Stephen Rothwell
1 sibling, 0 replies; 181+ messages in thread
From: Al Viro @ 2010-05-18 7:48 UTC (permalink / raw)
To: Eric W. Biederman; +Cc: Stephen Rothwell, Greg KH, linux-next, linux-kernel
On Tue, May 18, 2010 at 12:00:01AM -0700, Eric W. Biederman wrote:
> Stephen Rothwell <sfr@canb.auug.org.au> writes:
>
> > Hi Greg,
> >
> > After merging the driver-core tree, today's linux-next build (powerpc
> > ppc64_defconfig) failed like this:
> >
> > fs/sysfs/mount.c: In function 'sysfs_exit_ns':
> > fs/sysfs/mount.c:160: error: 'S_BIAS' undeclared (first use in this function)
> >
> > Caused by commit c80e63f000aa7cf73a430b2cb57dbbb91554a847 ("sysfs:
> > Implement sysfs tagged directory support") from the driver-core tree
> > interacting with commit f3ffc7acb6a6ebec0a9e660d9211ed048d7e90f5 ("get
> > rid of S_BIAS") from the vfs tree.
> >
> > I don't know how to fix this, so I just commented the code out for now
> > (see below). Please someone supply a correct fix.
> >
> > [Al, I notice that the "get rid of S_BIAS" patch has an author date of
> > March 22 - it would have been nice if it had been in linux-next during
> > the last two months so that we could have had a fix for this some time
> > ago.]
>
> Stephen what is the easiest way to get a copy of Al's tree so I can take
> a look to see what needs to happen?
What needs to happen is the end of s_instances abuse in there. If you
do something to all your sysfs_super_info instances, put those into a
list of its own. What seems to be done there is blind "slap NULL at
that member in all those structures, no matter what might be going on".
Since the only thing you apparently care about is that sb->s_fs_info won't
disappear under you...
I really wonder what you intend to happen with readdir/sysfs_exit_ns races,
but that's a separate question. Note that there you drop all locks many
times (and don't get me started on the amount of contention in sysfs), you
have no protection against old info->ns[...] contents getting stale, AFAICS.
^ permalink raw reply [flat|nested] 181+ messages in thread
* Re: linux-next: build failure after merge of the driver-core tree
2010-05-18 6:45 Stephen Rothwell
@ 2010-05-18 7:00 ` Eric W. Biederman
2010-05-18 7:48 ` Al Viro
2010-05-18 7:54 ` Stephen Rothwell
2010-05-18 19:58 ` Eric W. Biederman
1 sibling, 2 replies; 181+ messages in thread
From: Eric W. Biederman @ 2010-05-18 7:00 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: Greg KH, linux-next, linux-kernel, Al Viro
Stephen Rothwell <sfr@canb.auug.org.au> writes:
> Hi Greg,
>
> After merging the driver-core tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
>
> fs/sysfs/mount.c: In function 'sysfs_exit_ns':
> fs/sysfs/mount.c:160: error: 'S_BIAS' undeclared (first use in this function)
>
> Caused by commit c80e63f000aa7cf73a430b2cb57dbbb91554a847 ("sysfs:
> Implement sysfs tagged directory support") from the driver-core tree
> interacting with commit f3ffc7acb6a6ebec0a9e660d9211ed048d7e90f5 ("get
> rid of S_BIAS") from the vfs tree.
>
> I don't know how to fix this, so I just commented the code out for now
> (see below). Please someone supply a correct fix.
>
> [Al, I notice that the "get rid of S_BIAS" patch has an author date of
> March 22 - it would have been nice if it had been in linux-next during
> the last two months so that we could have had a fix for this some time
> ago.]
Stephen what is the easiest way to get a copy of Al's tree so I can take
a look to see what needs to happen?
Eric
^ permalink raw reply [flat|nested] 181+ messages in thread
* linux-next: build failure after merge of the driver-core tree
@ 2010-05-18 6:45 Stephen Rothwell
2010-05-18 7:00 ` Eric W. Biederman
2010-05-18 19:58 ` Eric W. Biederman
0 siblings, 2 replies; 181+ messages in thread
From: Stephen Rothwell @ 2010-05-18 6:45 UTC (permalink / raw)
To: Greg KH; +Cc: linux-next, linux-kernel, Eric W. Biederman, Al Viro
Hi Greg,
After merging the driver-core tree, today's linux-next build (powerpc
ppc64_defconfig) failed like this:
fs/sysfs/mount.c: In function 'sysfs_exit_ns':
fs/sysfs/mount.c:160: error: 'S_BIAS' undeclared (first use in this function)
Caused by commit c80e63f000aa7cf73a430b2cb57dbbb91554a847 ("sysfs:
Implement sysfs tagged directory support") from the driver-core tree
interacting with commit f3ffc7acb6a6ebec0a9e660d9211ed048d7e90f5 ("get
rid of S_BIAS") from the vfs tree.
I don't know how to fix this, so I just commented the code out for now
(see below). Please someone supply a correct fix.
[Al, I notice that the "get rid of S_BIAS" patch has an author date of
March 22 - it would have been nice if it had been in linux-next during
the last two months so that we could have had a fix for this some time
ago.]
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Tue, 18 May 2010 16:36:22 +1000
Subject: [PATCH] sysfs: fix for S_BIAS going away
Not a real fix, but it lets the code build.
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
fs/sysfs/mount.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/fs/sysfs/mount.c b/fs/sysfs/mount.c
index 1afa32b..49258e1 100644
--- a/fs/sysfs/mount.c
+++ b/fs/sysfs/mount.c
@@ -150,22 +150,22 @@ static struct file_system_type sysfs_fs_type = {
void sysfs_exit_ns(enum kobj_ns_type type, const void *ns)
{
struct super_block *sb;
mutex_lock(&sysfs_mutex);
spin_lock(&sb_lock);
list_for_each_entry(sb, &sysfs_fs_type.fs_supers, s_instances) {
struct sysfs_super_info *info = sysfs_info(sb);
/* Ignore superblocks that are in the process of unmounting */
- if (sb->s_count <= S_BIAS)
- continue;
+// if (sb->s_count <= S_BIAS)
+// continue;
/* Ignore superblocks with the wrong ns */
if (info->ns[type] != ns)
continue;
info->ns[type] = NULL;
}
spin_unlock(&sb_lock);
mutex_unlock(&sysfs_mutex);
}
int __init sysfs_init(void)
--
1.7.1
^ permalink raw reply related [flat|nested] 181+ messages in thread
* linux-next: build failure after merge of the driver-core tree
@ 2010-05-18 6:44 Stephen Rothwell
2010-05-18 14:02 ` Greg KH
0 siblings, 1 reply; 181+ messages in thread
From: Stephen Rothwell @ 2010-05-18 6:44 UTC (permalink / raw)
To: Greg KH; +Cc: linux-next, linux-kernel, Chris Wright
[-- Attachment #1: Type: text/plain, Size: 1336 bytes --]
Hi Greg,
After merging the driver-core tree, today's linux-next build (powerpc
ppc64_defconfig) failed like this:
cc1: warnings being treated as errors
In file included from include/linux/kobject.h:21,
from include/linux/device.h:17,
from arch/powerpc/lib/devres.c:10:
include/linux/sysfs.h:97: error: 'struct file' declared inside parameter list
include/linux/sysfs.h:97: error: its scope is only this definition or declaration, which is probably not what you want
include/linux/sysfs.h:99: error: 'struct file' declared inside parameter list
include/linux/sysfs.h:101: error: 'struct file' declared inside parameter list
and many more (arch/powerpc is built with -Werror (as do some other
architectures)) and lots of similar warnings ...
Caused by commit f8e898186196a22756b50b908ecd92123265f8a2 ("sysfs: add
struct file* to bin_attr callbacks"). See Rule 1 in
Documentation/SubmitChecklist. The header file probably just needs
"struct file;" added in the right place.
I have reverted that commit for today (and commit
44e425ab9f887ec6d3a7a4481f3b0c99f120de19 ("pci: check caps from sysfs
file open to read device dependent config space") that depends on it).
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply [flat|nested] 181+ messages in thread
* Re: linux-next: build failure after merge of the driver-core tree
2010-03-03 6:14 Stephen Rothwell
@ 2010-03-03 6:31 ` Stephen Rothwell
0 siblings, 0 replies; 181+ messages in thread
From: Stephen Rothwell @ 2010-03-03 6:31 UTC (permalink / raw)
To: Greg KH
Cc: linux-next, linux-kernel, Johannes Berg, John W. Linville,
Thomas Gleixner
[-- Attachment #1: Type: text/plain, Size: 410 bytes --]
Hi all,
On Wed, 3 Mar 2010 17:14:32 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> John, Johannes, device_lock/unlock() already exist in Linus' tree, so you
> should be able to apply this to the wireless tree already.
This is not correct, sorry. I was thinking of something else.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply [flat|nested] 181+ messages in thread
* linux-next: build failure after merge of the driver-core tree
@ 2010-03-03 6:14 Stephen Rothwell
2010-03-03 6:31 ` Stephen Rothwell
0 siblings, 1 reply; 181+ messages in thread
From: Stephen Rothwell @ 2010-03-03 6:14 UTC (permalink / raw)
To: Greg KH
Cc: linux-next, linux-kernel, Johannes Berg, John W. Linville,
Thomas Gleixner
Hi Greg,
After merging the driver-core tree, today's linux-next build (x86_64 allmodconfig)
failed like this:
drivers/net/wireless/ath/ar9170/usb.c: In function 'ar9170_usb_firmware_failed':
drivers/net/wireless/ath/ar9170/usb.c:729: error: 'struct device' has no member named 'sem'
drivers/net/wireless/ath/ar9170/usb.c:732: error: 'struct device' has no member named 'sem'
Caused by commit 535765179fd4e8af26b69d2240d7ec33702a370a ("ar9170: load
firmware asynchronously") from the wireless tree interacting with
commitf989226577d096eb9ebbf95da1d0e8303ecc660c ("drivers/base: Convert
dev->sem to mutex") from the driver-core tree.
I applied the following patch for today.
John, Johannes, device_lock/unlock() already exist in Linus' tree, so you
should be able to apply this to the wireless tree already.
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Wed, 3 Mar 2010 17:08:11 +1100
Subject: [PATCH] ar9170: fix for driver-core ABI change
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
drivers/net/wireless/ath/ar9170/usb.c | 5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/ath/ar9170/usb.c b/drivers/net/wireless/ath/ar9170/usb.c
index 4e30197..7fc1034 100644
--- a/drivers/net/wireless/ath/ar9170/usb.c
+++ b/drivers/net/wireless/ath/ar9170/usb.c
@@ -41,6 +41,7 @@
#include <linux/usb.h>
#include <linux/firmware.h>
#include <linux/etherdevice.h>
+#include <linux/mutex.h>
#include <net/mac80211.h>
#include "ar9170.h"
#include "cmd.h"
@@ -726,10 +727,10 @@ static void ar9170_usb_firmware_failed(struct ar9170_usb *aru)
/* unbind anything failed */
if (parent)
- down(&parent->sem);
+ device_lock(parent);
device_release_driver(&aru->udev->dev);
if (parent)
- up(&parent->sem);
+ device_unlock(parent);
}
static void ar9170_usb_firmware_finish(const struct firmware *fw, void *context)
--
1.7.0
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
^ permalink raw reply related [flat|nested] 181+ messages in thread
* Re: linux-next: build failure after merge of the driver-core tree
2010-02-17 4:56 ` Greg KH
@ 2010-02-18 4:27 ` Greg KH
0 siblings, 0 replies; 181+ messages in thread
From: Greg KH @ 2010-02-18 4:27 UTC (permalink / raw)
To: Jean Delvare; +Cc: Stephen Rothwell, linux-next, linux-kernel, Thomas Gleixner
On Tue, Feb 16, 2010 at 08:56:16PM -0800, Greg KH wrote:
> On Tue, Feb 16, 2010 at 10:01:00AM +0100, Jean Delvare wrote:
> > Hi Stephen,
> >
> > On Tue, 16 Feb 2010 17:39:26 +1100, Stephen Rothwell wrote:
> > > After merging the driver-core tree, today's linux-next build (x86_64
> > > allmodconfig) failed like this:
> > >
> > > drivers/i2c/i2c-smbus.c:58: error: 'struct device' has no member named 'sem'
> > > drivers/i2c/i2c-smbus.c:66: error: 'struct device' has no member named 'sem'
> > >
> > > Caused by commit 0819a881db29059d113fc5f019f7c489dea5937d from the
> > > driver-core tree interacting with commit
> > > 38f1e8aedf0a238d56fbcd3660fc140b50dbc89a ("i2c: Add SMBus alert support")
> > > from the i2c tree.
> > >
> > > I have applied the following patch for today and will use it as a merge
> > > fixup for the driver-core tree while necessary.
> >
> > Thanks for the heads up and the fix. Greg, is there an API I am
> > supposed to use instead of accessing the device's semaphore/mutex
> > directly?
>
> I will create a device_lock() and device_unlock() api to solve this
> problem. That will fix the issue for when we try to change this from a
> semaphore to a mutex (like the patch in linux-next does), but we need to
> revert it due to lockdep issues that are being reported incorrectly.
>
> For now, your code is fine, I'll change over your code in the .34 tree
> when the new api goes in. I'll also drop this mutex patch in a day as
> well, because of the problems it has caused.
The functions are now in my tree, I'll fix up your code in the .34 merge
period.
thanks,
greg k-h
^ permalink raw reply [flat|nested] 181+ messages in thread
* Re: linux-next: build failure after merge of the driver-core tree
2010-02-16 9:01 ` Jean Delvare
@ 2010-02-17 4:56 ` Greg KH
2010-02-18 4:27 ` Greg KH
0 siblings, 1 reply; 181+ messages in thread
From: Greg KH @ 2010-02-17 4:56 UTC (permalink / raw)
To: Jean Delvare; +Cc: Stephen Rothwell, linux-next, linux-kernel, Thomas Gleixner
On Tue, Feb 16, 2010 at 10:01:00AM +0100, Jean Delvare wrote:
> Hi Stephen,
>
> On Tue, 16 Feb 2010 17:39:26 +1100, Stephen Rothwell wrote:
> > After merging the driver-core tree, today's linux-next build (x86_64
> > allmodconfig) failed like this:
> >
> > drivers/i2c/i2c-smbus.c:58: error: 'struct device' has no member named 'sem'
> > drivers/i2c/i2c-smbus.c:66: error: 'struct device' has no member named 'sem'
> >
> > Caused by commit 0819a881db29059d113fc5f019f7c489dea5937d from the
> > driver-core tree interacting with commit
> > 38f1e8aedf0a238d56fbcd3660fc140b50dbc89a ("i2c: Add SMBus alert support")
> > from the i2c tree.
> >
> > I have applied the following patch for today and will use it as a merge
> > fixup for the driver-core tree while necessary.
>
> Thanks for the heads up and the fix. Greg, is there an API I am
> supposed to use instead of accessing the device's semaphore/mutex
> directly?
I will create a device_lock() and device_unlock() api to solve this
problem. That will fix the issue for when we try to change this from a
semaphore to a mutex (like the patch in linux-next does), but we need to
revert it due to lockdep issues that are being reported incorrectly.
For now, your code is fine, I'll change over your code in the .34 tree
when the new api goes in. I'll also drop this mutex patch in a day as
well, because of the problems it has caused.
thanks,
greg k-h
^ permalink raw reply [flat|nested] 181+ messages in thread
* Re: linux-next: build failure after merge of the driver-core tree
2010-02-16 6:39 Stephen Rothwell
@ 2010-02-16 9:01 ` Jean Delvare
2010-02-17 4:56 ` Greg KH
0 siblings, 1 reply; 181+ messages in thread
From: Jean Delvare @ 2010-02-16 9:01 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: Greg KH, linux-next, linux-kernel, Thomas Gleixner
Hi Stephen,
On Tue, 16 Feb 2010 17:39:26 +1100, Stephen Rothwell wrote:
> After merging the driver-core tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
>
> drivers/i2c/i2c-smbus.c:58: error: 'struct device' has no member named 'sem'
> drivers/i2c/i2c-smbus.c:66: error: 'struct device' has no member named 'sem'
>
> Caused by commit 0819a881db29059d113fc5f019f7c489dea5937d from the
> driver-core tree interacting with commit
> 38f1e8aedf0a238d56fbcd3660fc140b50dbc89a ("i2c: Add SMBus alert support")
> from the i2c tree.
>
> I have applied the following patch for today and will use it as a merge
> fixup for the driver-core tree while necessary.
Thanks for the heads up and the fix. Greg, is there an API I am
supposed to use instead of accessing the device's semaphore/mutex
directly?
--
Jean Delvare
^ permalink raw reply [flat|nested] 181+ messages in thread
* linux-next: build failure after merge of the driver-core tree
@ 2010-02-16 6:39 Stephen Rothwell
2010-02-16 9:01 ` Jean Delvare
0 siblings, 1 reply; 181+ messages in thread
From: Stephen Rothwell @ 2010-02-16 6:39 UTC (permalink / raw)
To: Greg KH; +Cc: linux-next, linux-kernel, Thomas Gleixner, Jean Delvare
Hi Greg,
After merging the driver-core tree, today's linux-next build (x86_64
allmodconfig) failed like this:
drivers/i2c/i2c-smbus.c:58: error: 'struct device' has no member named 'sem'
drivers/i2c/i2c-smbus.c:66: error: 'struct device' has no member named 'sem'
Caused by commit 0819a881db29059d113fc5f019f7c489dea5937d from the
driver-core tree interacting with commit
38f1e8aedf0a238d56fbcd3660fc140b50dbc89a ("i2c: Add SMBus alert support")
from the i2c tree.
I have applied the following patch for today and will use it as a merge
fixup for the driver-core tree while necessary.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Tue, 16 Feb 2010 17:28:56 +1100
Subject: [PATCH] i2c: update for semaphore to mutex conversion of devices
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
drivers/i2c/i2c-smbus.c | 5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/i2c/i2c-smbus.c b/drivers/i2c/i2c-smbus.c
index 333527c..52aa775 100644
--- a/drivers/i2c/i2c-smbus.c
+++ b/drivers/i2c/i2c-smbus.c
@@ -27,6 +27,7 @@
#include <linux/workqueue.h>
#include <linux/i2c.h>
#include <linux/i2c-smbus.h>
+#include <linux/mutex.h>
struct i2c_smbus_alert {
unsigned int alert_edge_triggered:1;
@@ -55,7 +56,7 @@ static int smbus_do_alert(struct device *dev, void *addrp)
* Drivers should either disable alerts, or provide at least
* a minimal handler. Lock so client->driver won't change.
*/
- down(&dev->sem);
+ mutex_lock(&dev->mutex);
if (client->driver) {
if (client->driver->alert)
client->driver->alert(client, data->flag);
@@ -63,7 +64,7 @@ static int smbus_do_alert(struct device *dev, void *addrp)
dev_warn(&client->dev, "no driver alert()!\n");
} else
dev_dbg(&client->dev, "alert with no driver\n");
- up(&dev->sem);
+ mutex_unlock(&dev->mutex);
/* Stop iterating after we find the device */
return -EBUSY;
--
1.6.6.2
^ permalink raw reply related [flat|nested] 181+ messages in thread
end of thread, other threads:[~2023-08-16 7:40 UTC | newest]
Thread overview: 181+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2010-03-17 4:41 linux-next: build failure after merge of the driver-core tree Stephen Rothwell
2010-03-17 7:21 ` Neil Brown
2010-03-17 15:51 ` Sage Weil
2010-03-17 22:30 ` Stephen Rothwell
2010-03-24 1:37 ` Neil Brown
2010-03-24 14:54 ` Sage Weil
-- strict thread matches above, loose matches on Subject: below --
2023-08-15 7:24 Stephen Rothwell
2023-08-15 15:21 ` Greg KH
2023-08-16 7:39 ` Maxime Ripard
2023-04-11 4:38 Stephen Rothwell
2023-04-11 9:55 ` Daniel Vetter
2023-04-11 10:40 ` Greg KH
2023-04-11 15:01 ` Daniel Vetter
2023-04-11 15:08 ` Jeffrey Hugo
2023-04-11 15:13 ` Greg KH
2023-04-11 15:26 ` Jeffrey Hugo
2023-04-11 15:29 ` Jeffrey Hugo
2023-04-11 16:31 ` Daniel Vetter
2023-04-11 17:18 ` Jeffrey Hugo
2023-04-11 18:21 ` Daniel Vetter
2023-04-11 18:37 ` Jeffrey Hugo
2023-04-11 18:47 ` Daniel Vetter
2023-04-12 6:11 ` Greg KH
2023-03-27 4:46 Stephen Rothwell
2023-03-27 7:33 ` Greg KH
2023-03-27 8:22 ` Stephen Rothwell
2023-03-27 9:15 ` Greg KH
2023-03-27 15:09 ` Vasily Gorbik
2023-01-30 4:28 Stephen Rothwell
2023-01-30 16:01 ` Greg KH
2023-01-30 16:23 ` Geert Uytterhoeven
2022-12-01 2:18 Stephen Rothwell
2022-11-30 1:38 Stephen Rothwell
2022-11-30 12:01 ` Greg KH
2022-11-28 2:36 Stephen Rothwell
2022-11-28 11:50 ` Greg KH
2022-11-28 12:44 ` Stephen Rothwell
2022-11-28 16:22 ` Greg KH
2022-11-28 19:46 ` Stephen Rothwell
2022-11-29 8:28 ` Greg KH
2022-11-28 17:35 ` Greg KH
2022-11-14 4:12 Stephen Rothwell
2022-11-14 8:46 ` Andy Shevchenko
2022-11-14 8:59 ` Greg KH
2021-07-23 5:09 Stephen Rothwell
2021-07-23 5:34 ` Uwe Kleine-König
2021-08-10 12:13 ` Geert Uytterhoeven
2021-08-12 20:51 ` Doug Anderson
2021-02-10 10:47 Stephen Rothwell
2021-02-10 18:18 ` Greg KH
2021-02-10 19:06 ` Saravana Kannan
2021-02-10 19:17 ` Saravana Kannan
2021-02-10 19:36 ` Greg KH
2021-02-10 20:14 ` Rob Herring
2021-02-10 20:43 ` Saravana Kannan
2021-02-10 20:59 ` Rob Herring
2020-09-09 5:47 Stephen Rothwell
2020-09-09 7:21 ` Greg KH
2020-09-09 21:47 ` Kees Cook
2020-09-09 7:28 ` Greg KH
2020-07-27 6:55 Stephen Rothwell
2020-07-27 10:17 ` Greg KH
2020-07-28 19:53 ` Kees Cook
2019-09-18 17:09 Mark Brown
2019-09-18 18:52 ` Greg KH
2019-09-18 19:03 ` Linus Torvalds
2019-09-18 19:07 ` Greg KH
2019-09-18 20:56 ` Suzuki K Poulose
2019-09-18 21:55 ` Mark Brown
2019-08-29 7:35 Stephen Rothwell
2019-08-29 10:10 ` Greg KH
2019-02-01 2:41 Stephen Rothwell
2019-02-01 14:18 ` Greg KH
2017-06-13 6:04 Stephen Rothwell
2017-06-13 6:20 ` Greg KH
2017-06-13 6:25 ` Stephen Rothwell
2017-06-13 6:30 ` Sergey Senozhatsky
2016-05-02 5:42 Stephen Rothwell
2016-05-02 11:40 ` William Breathitt Gray
2016-05-02 14:47 ` Greg KH
2015-05-21 7:52 Stephen Rothwell
2014-12-01 7:49 Stephen Rothwell
2014-05-28 8:03 Stephen Rothwell
2014-05-28 9:30 ` Jean Delvare
2014-03-12 0:51 Mark Brown
2014-03-12 1:50 ` Greg KH
2014-03-12 3:55 ` Benjamin Herrenschmidt
2014-03-12 11:37 ` Mark Brown
2014-03-12 19:59 ` Benjamin Herrenschmidt
2014-03-12 20:02 ` Tejun Heo
2014-03-12 20:14 ` Benjamin Herrenschmidt
2014-03-12 20:21 ` Tejun Heo
2014-03-13 0:37 ` Benjamin Herrenschmidt
2014-03-13 22:14 ` Benjamin Herrenschmidt
2014-03-14 13:00 ` Tejun Heo
2014-03-15 0:03 ` Greg KH
2014-03-15 2:57 ` Benjamin Herrenschmidt
2014-03-15 5:29 ` Greg KH
2014-03-15 7:14 ` Benjamin Herrenschmidt
2014-03-16 23:16 ` Stephen Rothwell
2014-03-17 18:36 ` Greg KH
2014-03-16 23:16 ` Stephen Rothwell
2014-03-17 18:33 ` Greg KH
2014-03-17 20:33 ` Benjamin Herrenschmidt
2014-03-17 21:56 ` Greg KH
2014-03-17 22:05 ` Tejun Heo
2014-03-17 22:21 ` Tejun Heo
2014-03-18 0:07 ` Stewart Smith
2014-03-18 0:22 ` Benjamin Herrenschmidt
2014-03-18 15:58 ` Tejun Heo
2014-03-18 0:00 ` Stewart Smith
2014-03-18 0:16 ` Benjamin Herrenschmidt
2014-03-17 8:28 ` Stephen Rothwell
2013-08-22 5:39 Stephen Rothwell
2013-08-22 15:36 ` Greg KH
2013-01-18 2:29 Stephen Rothwell
2013-01-18 4:13 ` Greg KH
2013-01-18 14:14 ` Kondratiev, Vladimir
2012-08-17 4:01 Stephen Rothwell
2012-08-17 13:25 ` Greg KH
2012-07-10 5:32 Stephen Rothwell
2012-07-10 9:03 ` Mark Brown
2012-07-10 11:14 ` Stephen Rothwell
2012-07-10 21:10 ` Linus Walleij
2012-05-01 4:59 Stephen Rothwell
2012-05-01 7:05 ` Bart Van Assche
2012-05-01 13:45 ` Greg KH
2012-04-19 4:48 Stephen Rothwell
2012-04-19 20:07 ` Greg KH
2012-04-20 2:19 ` Greg KH
2012-01-27 2:59 Stephen Rothwell
2012-01-27 15:24 ` Alan Stern
2012-01-27 22:36 ` Greg KH
2012-01-05 6:28 Stephen Rothwell
2012-01-05 23:20 ` Greg KH
2011-12-28 6:45 Stephen Rothwell
2012-01-03 16:21 ` Greg KH
2012-01-04 0:07 ` Kay Sievers
2012-01-04 0:31 ` Greg KH
2012-01-04 22:03 ` Kay Sievers
2012-01-04 23:13 ` Greg KH
2012-01-04 23:07 ` Greg KH
2012-01-04 23:48 ` Stephen Rothwell
2012-01-05 0:01 ` Kay Sievers
2012-01-05 0:17 ` Stephen Rothwell
2012-01-05 0:57 ` Josh Triplett
2011-12-15 6:37 Stephen Rothwell
2011-12-15 7:21 ` Greg KH
2011-12-15 10:10 ` Kay Sievers
2011-12-15 19:09 ` Greg KH
2011-12-14 4:48 Stephen Rothwell
2011-12-14 9:24 ` Peter Zijlstra
2011-12-14 15:03 ` Greg KH
2011-12-14 15:13 ` Peter Zijlstra
2011-12-14 17:01 ` Greg KH
2011-12-14 19:24 ` Greg KH
2011-11-21 1:57 Stephen Rothwell
2010-08-04 4:25 Stephen Rothwell
2010-08-04 4:44 ` Guenter Roeck
2010-08-04 15:52 ` Greg KH
2010-08-04 21:24 ` Jesse Barnes
2010-05-18 6:45 Stephen Rothwell
2010-05-18 7:00 ` Eric W. Biederman
2010-05-18 7:48 ` Al Viro
2010-05-18 7:54 ` Stephen Rothwell
2010-05-18 10:35 ` Eric W. Biederman
2010-05-18 15:02 ` Al Viro
2010-05-18 19:58 ` Eric W. Biederman
2010-05-18 21:25 ` Greg KH
2010-05-18 21:59 ` Eric W. Biederman
2010-05-18 6:44 Stephen Rothwell
2010-05-18 14:02 ` Greg KH
2010-05-18 14:04 ` Chris Wright
2010-05-18 21:06 ` Chris Wright
2010-05-18 21:24 ` Greg KH
2010-03-03 6:14 Stephen Rothwell
2010-03-03 6:31 ` Stephen Rothwell
2010-02-16 6:39 Stephen Rothwell
2010-02-16 9:01 ` Jean Delvare
2010-02-17 4:56 ` Greg KH
2010-02-18 4:27 ` Greg KH
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).