* Communicating tablet mode status to userspace
From: Daniel Drake @ 2012-10-02 22:27 UTC (permalink / raw)
To: linux-input, linux-hotplug; +Cc: hadess, Carlos Garnacho
Hi,
For the upcoming OLPC touchscreen laptop we're trying to solve the
following problem: we want the on-screen keyboard to only activate
itself when the laptop is "folded over" into tablet mode where the
keyboard is physically obscured.
We already have an ebook mode switch which detects this, and the
driver is upstream. Its an input device that exposes this information
via the SW_TABLET_MODE switch.
The on-screen keyboard runs in the user environment, which means that
its not root - it can't access /dev/input/event nodes directly. X
doesn't treat switches as input devices, so this info is not available
through X.
I'm wondering if anyone has suggestions on the best way to solve this
problem. The most attractive option I have found would be to do
something similar to the accelerometer:
http://git.kernel.org/?p=linux/hotplug/udev.git;a=blob;f=src/accelerometer/accelerometer.c
Modify the kernel input driver to generate a uevent (in addition to
the evdev event) every time the switch state is changed, then write a
udev program to expose this info in a udev property.
The change event would (presumably) trigger libudev's udev_monitor,
which would be used by the on-screen keyboard software (maliit) to
change its behaviour according to the property value.
Does this sound like a sensible plan, would these udev and kernel
changes be acceptable? Or is there a better option that I'm missing?
Thanks
Daniel
^ permalink raw reply
* Re: Communicating tablet mode status to userspace
From: Alan Cox @ 2012-10-02 22:39 UTC (permalink / raw)
To: Daniel Drake; +Cc: linux-input, linux-hotplug, hadess, Carlos Garnacho
In-Reply-To: <CAMLZHHS80_zdmgVtJ87w+fuQGC05yj+EoJt3C_zBC7hkyhnaoQ@mail.gmail.com>
> The change event would (presumably) trigger libudev's udev_monitor,
> which would be used by the on-screen keyboard software (maliit) to
> change its behaviour according to the property value.
>
> Does this sound like a sensible plan, would these udev and kernel
> changes be acceptable? Or is there a better option that I'm missing?
Seems reasonable to me - but remember that a device can be in both tablet
and non tablet modes at once to different users once you have a wireless
display.
ie it's really not "tablet mode" it's "does this particular interface
have a keyboard"
^ permalink raw reply
* Re: Communicating tablet mode status to userspace
From: Dmitry Torokhov @ 2012-10-02 23:36 UTC (permalink / raw)
To: Daniel Drake; +Cc: linux-input, linux-hotplug, hadess, Carlos Garnacho
In-Reply-To: <CAMLZHHS80_zdmgVtJ87w+fuQGC05yj+EoJt3C_zBC7hkyhnaoQ@mail.gmail.com>
On Tue, Oct 02, 2012 at 04:27:07PM -0600, Daniel Drake wrote:
> Hi,
>
> For the upcoming OLPC touchscreen laptop we're trying to solve the
> following problem: we want the on-screen keyboard to only activate
> itself when the laptop is "folded over" into tablet mode where the
> keyboard is physically obscured.
>
> We already have an ebook mode switch which detects this, and the
> driver is upstream. Its an input device that exposes this information
> via the SW_TABLET_MODE switch.
>
> The on-screen keyboard runs in the user environment, which means that
> its not root - it can't access /dev/input/event nodes directly. X
> doesn't treat switches as input devices, so this info is not available
> through X.
>
> I'm wondering if anyone has suggestions on the best way to solve this
> problem. The most attractive option I have found would be to do
> something similar to the accelerometer:
> http://git.kernel.org/?p=linux/hotplug/udev.git;a=blob;f=src/accelerometer/accelerometer.c
>
> Modify the kernel input driver to generate a uevent (in addition to
> the evdev event) every time the switch state is changed, then write a
> udev program to expose this info in a udev property.
>
> The change event would (presumably) trigger libudev's udev_monitor,
> which would be used by the on-screen keyboard software (maliit) to
> change its behaviour according to the property value.
>
> Does this sound like a sensible plan, would these udev and kernel
> changes be acceptable? Or is there a better option that I'm missing?
Why can't you change event device ownership to the local user? Then you
can read and act upon events.
Thanks.
--
Dmitry
^ permalink raw reply
* Re: Communicating tablet mode status to userspace
From: Greg KH @ 2012-10-03 2:58 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: Daniel Drake, linux-input, linux-hotplug, hadess, Carlos Garnacho
In-Reply-To: <20121002233640.GB8542@core.coreip.homeip.net>
On Tue, Oct 02, 2012 at 04:36:41PM -0700, Dmitry Torokhov wrote:
> On Tue, Oct 02, 2012 at 04:27:07PM -0600, Daniel Drake wrote:
> > Hi,
> >
> > For the upcoming OLPC touchscreen laptop we're trying to solve the
> > following problem: we want the on-screen keyboard to only activate
> > itself when the laptop is "folded over" into tablet mode where the
> > keyboard is physically obscured.
> >
> > We already have an ebook mode switch which detects this, and the
> > driver is upstream. Its an input device that exposes this information
> > via the SW_TABLET_MODE switch.
> >
> > The on-screen keyboard runs in the user environment, which means that
> > its not root - it can't access /dev/input/event nodes directly. X
> > doesn't treat switches as input devices, so this info is not available
> > through X.
> >
> > I'm wondering if anyone has suggestions on the best way to solve this
> > problem. The most attractive option I have found would be to do
> > something similar to the accelerometer:
> > http://git.kernel.org/?p=linux/hotplug/udev.git;a=blob;f=src/accelerometer/accelerometer.c
> >
> > Modify the kernel input driver to generate a uevent (in addition to
> > the evdev event) every time the switch state is changed, then write a
> > udev program to expose this info in a udev property.
> >
> > The change event would (presumably) trigger libudev's udev_monitor,
> > which would be used by the on-screen keyboard software (maliit) to
> > change its behaviour according to the property value.
> >
> > Does this sound like a sensible plan, would these udev and kernel
> > changes be acceptable? Or is there a better option that I'm missing?
>
> Why can't you change event device ownership to the local user? Then you
> can read and act upon events.
Yes, that's the best way. Also, you might want to check out the extcon
driver interface, that might provide the api you want for userspace.
greg k-h
^ permalink raw reply
* Re: Communicating tablet mode status to userspace
From: Daniel Drake @ 2012-10-03 14:52 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: linux-input, linux-hotplug, hadess, Carlos Garnacho
In-Reply-To: <20121002233640.GB8542@core.coreip.homeip.net>
On Tue, Oct 2, 2012 at 5:36 PM, Dmitry Torokhov
<dmitry.torokhov@gmail.com> wrote:
> Why can't you change event device ownership to the local user? Then you
> can read and act upon events.
That would work, I guess.
However, it sounds like your suggesting that we add some custom rules
in OLPC's own builds and leave it at that. I'm not sure what
user/group we could use for a generic rule matching this hardware.
The disadvantage here is that it doesn't work as a global solution to
the problem - every embedded distro in the same situation would have
to add a custom rule thing, and "generic distros" would have no such
solution at this time.
Maybe not such a big deal while OLPC is the only user. But I did come
across another request for SW_TABLET_MODE access:
https://bugs.freedesktop.org/show_bug.cgi?idC935
Or would a udev rule making the OLPC switch device (and potentially
similar devices on other platforms in future) world-readable on all
distros be accepted?
Thanks,
Daniel
^ permalink raw reply
* Re: Communicating tablet mode status to userspace
From: Greg KH @ 2012-10-03 15:05 UTC (permalink / raw)
To: Daniel Drake
Cc: Dmitry Torokhov, linux-input, linux-hotplug, hadess,
Carlos Garnacho
In-Reply-To: <CAMLZHHQfGuiK6s_d8ya8FUNiDiGDpgh35VFbHcu-mgCH-=TXVw@mail.gmail.com>
On Wed, Oct 03, 2012 at 08:52:31AM -0600, Daniel Drake wrote:
> On Tue, Oct 2, 2012 at 5:36 PM, Dmitry Torokhov
> <dmitry.torokhov@gmail.com> wrote:
> > Why can't you change event device ownership to the local user? Then you
> > can read and act upon events.
>
> That would work, I guess.
>
> However, it sounds like your suggesting that we add some custom rules
> in OLPC's own builds and leave it at that. I'm not sure what
> user/group we could use for a generic rule matching this hardware.
That shouldn't be a custom rule, other distros bind the keyboard / mouse
to the local user in order to handle the multi-seat situation properly.
That should all be done already in the console-kit logic (or whatever
handles it now.)
Have you looked into that?
greg k-h
^ permalink raw reply
* Re: Communicating tablet mode status to userspace
From: Kay Sievers @ 2012-10-03 15:23 UTC (permalink / raw)
To: Greg KH
Cc: Daniel Drake, Dmitry Torokhov, linux-input, linux-hotplug, hadess,
Carlos Garnacho
In-Reply-To: <20121003150542.GA8460@kroah.com>
On Wed, Oct 3, 2012 at 5:05 PM, Greg KH <greg@kroah.com> wrote:
> On Wed, Oct 03, 2012 at 08:52:31AM -0600, Daniel Drake wrote:
>> On Tue, Oct 2, 2012 at 5:36 PM, Dmitry Torokhov
>> <dmitry.torokhov@gmail.com> wrote:
>> > Why can't you change event device ownership to the local user? Then you
>> > can read and act upon events.
>>
>> That would work, I guess.
>>
>> However, it sounds like your suggesting that we add some custom rules
>> in OLPC's own builds and leave it at that. I'm not sure what
>> user/group we could use for a generic rule matching this hardware.
>
> That shouldn't be a custom rule, other distros bind the keyboard / mouse
> to the local user in order to handle the multi-seat situation properly.
> That should all be done already in the console-kit logic (or whatever
> handles it now.)
>
> Have you looked into that?
The usual model is not uid/gid, it's ACLs dynamically applied for
logged-in users with active sessions:
http://www.freedesktop.org/software/systemd/man/systemd-logind.service.html
http://cgit.freedesktop.org/systemd/systemd/tree/src/login/70-uaccess.rules
Kay
^ permalink raw reply
* Re: Communicating tablet mode status to userspace
From: Daniel Drake @ 2012-10-03 16:04 UTC (permalink / raw)
To: Kay Sievers
Cc: Greg KH, Dmitry Torokhov, linux-input, linux-hotplug, hadess,
Carlos Garnacho
In-Reply-To: <CAPXgP10+ZzLC98VdaQz19413guR-sKLT47iFLbN-mF_isF0n9A@mail.gmail.com>
On Wed, Oct 3, 2012 at 9:23 AM, Kay Sievers <kay@vrfy.org> wrote:
> The usual model is not uid/gid, it's ACLs dynamically applied for
> logged-in users with active sessions:
> http://www.freedesktop.org/software/systemd/man/systemd-logind.service.html
> http://cgit.freedesktop.org/systemd/systemd/tree/src/login/70-uaccess.rules
Thanks, those were the pointers I needed.
I'll work with this approach.
Thanks
Daniel
^ permalink raw reply
* Re: Communicating tablet mode status to userspace
From: Mark Brown @ 2012-10-04 13:35 UTC (permalink / raw)
To: Daniel Drake
Cc: Dmitry Torokhov, linux-input, linux-hotplug, hadess,
Carlos Garnacho
In-Reply-To: <CAMLZHHQfGuiK6s_d8ya8FUNiDiGDpgh35VFbHcu-mgCH-=TXVw@mail.gmail.com>
On Wed, Oct 03, 2012 at 08:52:31AM -0600, Daniel Drake wrote:
> The disadvantage here is that it doesn't work as a global solution to
> the problem - every embedded distro in the same situation would have
> to add a custom rule thing, and "generic distros" would have no such
> solution at this time.
> Maybe not such a big deal while OLPC is the only user. But I did come
> across another request for SW_TABLET_MODE access:
> https://bugs.freedesktop.org/show_bug.cgi?idC935
We went through the same routine with the jack status in ALSA too (which
has for a long time been reported as input events), where we've now
achieved the glorious triumph of three independant userspace ABIs for
reporting the same information.
^ permalink raw reply
* Re: Communicating tablet mode status to userspace
From: Bastien Nocera @ 2012-10-05 15:50 UTC (permalink / raw)
To: Daniel Drake
Cc: Kay Sievers, Greg KH, Dmitry Torokhov, linux-input, linux-hotplug,
Carlos Garnacho
In-Reply-To: <CAMLZHHTnhCjYA8x-=Q9+R3zbjV5ABnQ7D1hYX9qWfQ4Hck9f-Q@mail.gmail.com>
Hey Daniel,
On Wed, 2012-10-03 at 10:04 -0600, Daniel Drake wrote:
> On Wed, Oct 3, 2012 at 9:23 AM, Kay Sievers <kay@vrfy.org> wrote:
> > The usual model is not uid/gid, it's ACLs dynamically applied for
> > logged-in users with active sessions:
> > http://www.freedesktop.org/software/systemd/man/systemd-logind.service.html
> > http://cgit.freedesktop.org/systemd/systemd/tree/src/login/70-uaccess.rules
>
> Thanks, those were the pointers I needed.
> I'll work with this approach.
I think that there's a more generic approach to this, which would also
work with the tablet Thinkpads.
I would export the current "tablet mode" status through sysfs (which is
great if your driver keeps state), and send a uevent when the mode
changes (in addition to sending out that input event).
You'd probably need to tag your device in the udev database so that it
can be found and acted upon by user-space (probably a
gnome-settings-daemon plugin in your case).
Cheers
^ permalink raw reply
* Re: Communicating tablet mode status to userspace
From: Daniel Drake @ 2012-10-05 16:11 UTC (permalink / raw)
To: Bastien Nocera
Cc: Kay Sievers, Greg KH, Dmitry Torokhov, linux-input, linux-hotplug,
Carlos Garnacho
In-Reply-To: <1349452248.11150.6.camel@novo.hadess.net>
On Fri, Oct 5, 2012 at 9:50 AM, Bastien Nocera <hadess@hadess.net> wrote:
> I think that there's a more generic approach to this, which would also
> work with the tablet Thinkpads.
>
> I would export the current "tablet mode" status through sysfs (which is
> great if your driver keeps state), and send a uevent when the mode
> changes (in addition to sending out that input event).
When we tried to add such an attibute in the past, Dmitry rejected it:
http://article.gmane.org/gmane.linux.drivers.platform.x86.devel/1089
Apart from that, what your suggesting doesn't seem very different from
the earlier outcome here. We seem to have reached a generic solution,
where udev would identify input devices that have SW_TABLET_MODE and
make them accessible to the current seat. Then gnome-settings-daemon
can monitor them for evdev events (similar to the udev event
monitoring that would be necessary in your proposal).
Daniel
^ permalink raw reply
* Re: Communicating tablet mode status to userspace
From: Bastien Nocera @ 2012-10-05 16:40 UTC (permalink / raw)
To: Daniel Drake
Cc: Kay Sievers, Greg KH, Dmitry Torokhov, linux-input, linux-hotplug,
Carlos Garnacho
In-Reply-To: <CAMLZHHR8gk_D-zU2Wu819vQeJ4HV2n7RwoW-MUa1pDtkrH+Vdg@mail.gmail.com>
On Fri, 2012-10-05 at 10:11 -0600, Daniel Drake wrote:
> On Fri, Oct 5, 2012 at 9:50 AM, Bastien Nocera <hadess@hadess.net> wrote:
> > I think that there's a more generic approach to this, which would also
> > work with the tablet Thinkpads.
> >
> > I would export the current "tablet mode" status through sysfs (which is
> > great if your driver keeps state), and send a uevent when the mode
> > changes (in addition to sending out that input event).
>
> When we tried to add such an attibute in the past, Dmitry rejected it:
> http://article.gmane.org/gmane.linux.drivers.platform.x86.devel/1089
>
> Apart from that, what your suggesting doesn't seem very different from
> the earlier outcome here. We seem to have reached a generic solution,
> where udev would identify input devices that have SW_TABLET_MODE and
> make them accessible to the current seat. Then gnome-settings-daemon
> can monitor them for evdev events (similar to the udev event
> monitoring that would be necessary in your proposal).
If that's the way we're going, then we probably want to have the
tracking and storage of the state done in:
- a udev property (as I did for the accelerometer stuff)
or
- a system-wide D-Bus daemon (exactly like upower does for the lid
status, but obviously, upower seems like the wrong place to do this).
The udev property is easier to put in place, and if Kay doesn't mind it,
it's probably the route I'd go for. This also has the benefit of
allowing the same interface for the Thinkpads.
Cheers
^ permalink raw reply
* Re: [ANNOUNCE] kmod 10
From: Lucas De Marchi @ 2012-10-08 13:38 UTC (permalink / raw)
To: Jan Engelhardt; +Cc: Lucas De Marchi, linux-modules, LKML, linux-hotplug
In-Reply-To: <alpine.LNX.2.01.1209170427220.6182@nerf07.vanv.qr>
On Sun, Sep 16, 2012 at 11:34 PM, Jan Engelhardt <jengelh@inai.de> wrote:
>
> On Thursday 2012-09-06 21:37, Lucas De Marchi wrote:
>>
>>kmod 10 is out:
>>
>>ftp://ftp.kernel.org/pub/linux/utils/kernel/kmod/kmod-10.tar.xz
>>ftp://ftp.kernel.org/pub/linux/utils/kernel/kmod/kmod-10.tar.sign
>
> make check fails here with glibc-2.15, gcc-4.7, x86_64,
> due to what seems to be duplicated symbols(?):
>
>
> + make check V=1
> Making check in .
> make --no-print-directory testsuite/uname.la testsuite/path.la testsuite/init_module.la testsuite/delete_module.la testsuite/libtestsuite.la testsuite/test-init testsuite/test-testsuite testsuite/test-loaded testsuite/test-modinfo testsuite/test-alias testsuite/test-new-module testsuite/test-modprobe testsuite/test-blacklist testsuite/test-dependencies
> depbase=`echo testsuite/uname.lo | sed 's|[^/]*$|.deps/&|;s|\.lo$||'`;\
> /bin/sh ./libtool --tagà --mode=compile gcc -std=gnu99 -std=gnu99 -DHAVE_CONFIG_H -I. -include ./config.h -I./libkmod -DROOTPREFIX=\"""\" -DSYSCONFDIR=\""/etc"\" -DLIBEXECDIR=\""/usr/lib"\" -I/usr/local/include -pipe -DANOTHER_BRICK_IN_THE -Wall -W -Wextra -Wno-inline -Wvla -Wundef -Wformat=2 -Wlogical-op -Wsign-compare -Wformat-security -Wmissing-include-dirs -Wformat-nonliteral -Wold-style-definition -Wpointer-arith -Winit-self -Wdeclaration-after-statement -Wfloat-equal -Wmissing-prototypes -Wstrict-prototypes -Wredundant-decls -Wmissing-declarations -Wmissing-noreturn -Wshadow -Wendif-labels -Wstrict-aliasing=2 -Wwrite-strings -Wno-long-long -Wno-overlength-strings -Wno-unused-parameter -Wno-missing-field-initializers -Wno-unused-result -Wnested-externs -Wchar-subscripts -Wtype-limits -Wuninitialized -fno-common -fdiagnostics-show-option -fvisibility=hidden -ffunction-sections -fdata-sections -fomit-frame-pointer -fmessage-length=0 -O2 -Wall -D_FORTIFY_SOURCE=2 -
> fstack-protector -funwind-tables -fasynchronous-unwind-tables -g -MT testsuite/uname.lo -MD -MP -MF $depbase.Tpo -c -o testsuite/uname.lo testsuite/uname.c &&\
> mv -f $depbase.Tpo $depbase.Plo
> libtool: compile: gcc -std=gnu99 -std=gnu99 -DHAVE_CONFIG_H -I. -include ./config.h -I./libkmod -DROOTPREFIX=\"\" -DSYSCONFDIR=\"/etc\" -DLIBEXECDIR=\"/usr/lib\" -I/usr/local/include -pipe -DANOTHER_BRICK_IN_THE -Wall -W -Wextra -Wno-inline -Wvla -Wundef -Wformat=2 -Wlogical-op -Wsign-compare -Wformat-security -Wmissing-include-dirs -Wformat-nonliteral -Wold-style-definition -Wpointer-arith -Winit-self -Wdeclaration-after-statement -Wfloat-equal -Wmissing-prototypes -Wstrict-prototypes -Wredundant-decls -Wmissing-declarations -Wmissing-noreturn -Wshadow -Wendif-labels -Wstrict-aliasing=2 -Wwrite-strings -Wno-long-long -Wno-overlength-strings -Wno-unused-parameter -Wno-missing-field-initializers -Wno-unused-result -Wnested-externs -Wchar-subscripts -Wtype-limits -Wuninitialized -fno-common -fdiagnostics-show-option -fvisibility=hidden -ffunction-sections -fdata-sections -fomit-frame-pointer -fmessage-length=0 -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables -fa
> synchronous-unwind-tables -g -MT testsuite/uname.lo -MD -MP -MF testsuite/.deps/uname.Tpo -c testsuite/uname.c -fPIC -DPIC -o testsuite/.libs/uname.o
> cc1: warning: /usr/local/include: No such file or directory [enabled by default]
> /bin/sh ./libtool --tagà --mode=link gcc -std=gnu99 -std=gnu99 -pipe -DANOTHER_BRICK_IN_THE -Wall -W -Wextra -Wno-inline -Wvla -Wundef -Wformat=2 -Wlogical-op -Wsign-compare -Wformat-security -Wmissing-include-dirs -Wformat-nonliteral -Wold-style-definition -Wpointer-arith -Winit-self -Wdeclaration-after-statement -Wfloat-equal -Wmissing-prototypes -Wstrict-prototypes -Wredundant-decls -Wmissing-declarations -Wmissing-noreturn -Wshadow -Wendif-labels -Wstrict-aliasing=2 -Wwrite-strings -Wno-long-long -Wno-overlength-strings -Wno-unused-parameter -Wno-missing-field-initializers -Wno-unused-result -Wnested-externs -Wchar-subscripts -Wtype-limits -Wuninitialized -fno-common -fdiagnostics-show-option -fvisibility=hidden -ffunction-sections -fdata-sections -fomit-frame-pointer -fmessage-length=0 -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables -fasynchronous-unwind-tables -g avoid-version -module -shared -export-dynamic -rpath /nowhere -ldl -o testsuite/uname.
> la testsuite/uname.lo
> libtool: link: gcc -std=gnu99 -shared -fPIC -DPIC testsuite/.libs/uname.o -ldl -O2 -Wl,-soname -Wl,uname.so.0 -o testsuite/.libs/uname.so.0.0.0
> libtool: link: (cd "testsuite/.libs" && rm -f "uname.so.0" && ln -s "uname.so.0.0.0" "uname.so.0")
> libtool: link: (cd "testsuite/.libs" && rm -f "uname.so" && ln -s "uname.so.0.0.0" "uname.so")
> libtool: link: ( cd "testsuite/.libs" && rm -f "uname.la" && ln -s "../uname.la" "uname.la" )
> depbase=`echo testsuite/path.lo | sed 's|[^/]*$|.deps/&|;s|\.lo$||'`;\
> /bin/sh ./libtool --tagà --mode=compile gcc -std=gnu99 -std=gnu99 -DHAVE_CONFIG_H -I. -include ./config.h -I./libkmod -DROOTPREFIX=\"""\" -DSYSCONFDIR=\""/etc"\" -DLIBEXECDIR=\""/usr/lib"\" -I/usr/local/include -pipe -DANOTHER_BRICK_IN_THE -Wall -W -Wextra -Wno-inline -Wvla -Wundef -Wformat=2 -Wlogical-op -Wsign-compare -Wformat-security -Wmissing-include-dirs -Wformat-nonliteral -Wold-style-definition -Wpointer-arith -Winit-self -Wdeclaration-after-statement -Wfloat-equal -Wmissing-prototypes -Wstrict-prototypes -Wredundant-decls -Wmissing-declarations -Wmissing-noreturn -Wshadow -Wendif-labels -Wstrict-aliasing=2 -Wwrite-strings -Wno-long-long -Wno-overlength-strings -Wno-unused-parameter -Wno-missing-field-initializers -Wno-unused-result -Wnested-externs -Wchar-subscripts -Wtype-limits -Wuninitialized -fno-common -fdiagnostics-show-option -fvisibility=hidden -ffunction-sections -fdata-sections -fomit-frame-pointer -fmessage-length=0 -O2 -Wall -D_FORTIFY_SOURCE=2 -
> fstack-protector -funwind-tables -fasynchronous-unwind-tables -g -MT testsuite/path.lo -MD -MP -MF $depbase.Tpo -c -o testsuite/path.lo testsuite/path.c &&\
> mv -f $depbase.Tpo $depbase.Plo
> libtool: compile: gcc -std=gnu99 -std=gnu99 -DHAVE_CONFIG_H -I. -include ./config.h -I./libkmod -DROOTPREFIX=\"\" -DSYSCONFDIR=\"/etc\" -DLIBEXECDIR=\"/usr/lib\" -I/usr/local/include -pipe -DANOTHER_BRICK_IN_THE -Wall -W -Wextra -Wno-inline -Wvla -Wundef -Wformat=2 -Wlogical-op -Wsign-compare -Wformat-security -Wmissing-include-dirs -Wformat-nonliteral -Wold-style-definition -Wpointer-arith -Winit-self -Wdeclaration-after-statement -Wfloat-equal -Wmissing-prototypes -Wstrict-prototypes -Wredundant-decls -Wmissing-declarations -Wmissing-noreturn -Wshadow -Wendif-labels -Wstrict-aliasing=2 -Wwrite-strings -Wno-long-long -Wno-overlength-strings -Wno-unused-parameter -Wno-missing-field-initializers -Wno-unused-result -Wnested-externs -Wchar-subscripts -Wtype-limits -Wuninitialized -fno-common -fdiagnostics-show-option -fvisibility=hidden -ffunction-sections -fdata-sections -fomit-frame-pointer -fmessage-length=0 -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables -fa
> synchronous-unwind-tables -g -MT testsuite/path.lo -MD -MP -MF testsuite/.deps/path.Tpo -c testsuite/path.c -fPIC -DPIC -o testsuite/.libs/path.o
> cc1: warning: /usr/local/include: No such file or directory [enabled by default]
> {standard input}: Assembler messages:
> {standard input}:418: Error: symbol `open64' is already defined
> {standard input}:678: Error: symbol `stat64' is already defined
> {standard input}:758: Error: symbol `lstat64' is already defined
> {standard input}:1234: Error: symbol `__xstat64' is already defined
> {standard input}:1396: Error: symbol `__lxstat64' is already defined
> make[2]: *** [testsuite/path.lo] Error 1
> make[1]: *** [check-am] Error 2
> make: *** [check-recursive] Error 1
> error: Bad exit status from /var/tmp/rpm-tmp.Eq2Axz (%check)
For completeness of ML archives: it's fixed on git:
http://git.kernel.org/?p=utils/kernel/kmod/kmod.git;a=commit;h÷423417778d049b07a3091c3972160be99c9173
Lucas De Marchi
--
To unsubscribe from this list: send the line "unsubscribe linux-hotplug" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [ANNOUNCE] kmod 10
From: Lucas De Marchi @ 2012-10-08 13:41 UTC (permalink / raw)
To: Bruce Dubbs
Cc: Jan Engelhardt, Lucas De Marchi, linux-modules, LKML,
linux-hotplug
In-Reply-To: <505695E3.7040603@gmail.com>
On Mon, Sep 17, 2012 at 12:15 AM, Bruce Dubbs <bruce.dubbs@gmail.com> wrote:
> Jan Engelhardt wrote:
>>
>>
>> On Thursday 2012-09-06 21:37, Lucas De Marchi wrote:
>>>
>>>
>>> kmod 10 is out:
>>>
>>> ftp://ftp.kernel.org/pub/linux/utils/kernel/kmod/kmod-10.tar.xz
>>> ftp://ftp.kernel.org/pub/linux/utils/kernel/kmod/kmod-10.tar.sign
>>
>>
>> make check fails here with glibc-2.15, gcc-4.7, x86_64,
>> due to what seems to be duplicated symbols(?)
>
>
> On my LFS system, glibc-2.16, gcc-4.7.1, x86_64, I do not see these errors:
>
> ./configure --prefix=/usr --bindir=/bin --libdir=/lib \
> --sysconfdir=/etc --with-xz --with-zlib
> make
> make check
>
> =========
> All 9 tests passed
> =========
>
> What is interesting is that if I run the checks again:
>
> make check
>
> I get:
>
> TESTSUITE: running modprobe_softdep_loop, in forked context
> TESTSUITE: ERR: rootfs
> /usr/src/kmod/kmod-10/testsuite/rootfs/test-modprobe/softdep-loop is dirty,
> please run 'make rootfs' before runnning this test
> TESTSUITE: ERR: 'modprobe_softdep_loop' [16407] exited with return code 1
> TESTSUITE: ERR: FAILED: modprobe_softdep_loop
> FAIL: testsuite/test-modprobe
>
> TESTSUITE: running test_insert, in forked context
> TESTSUITE: ERR: rootfs /usr/src/kmod/kmod-10/testsuite/rootfs/test-init/ is
> dirty, please run 'make rootfs' before runnning this test
> TESTSUITE: ERR: 'test_insert' [16373] exited with return code 1
> TESTSUITE: ERR: FAILED: test_insert
> FAIL: testsuite/test-init
>
> =======================
> 2 of 9 tests failed
> Please report to linux-modules@vger.kernel.org
> =======================
>
> 'make rootfs' does not do anything but make distclean && configure && make
> && make check is clean for me.
"make rootfs" was completely wrong, it's fixed now and queued for kmod 11:
http://git.kernel.org/?p=utils/kernel/kmod/kmod.git;a=commit;h„afccb91db106ad81effc88c2851ceddeda06ea
and
http://git.kernel.org/?p=utils/kernel/kmod/kmod.git;a=commit;hÏ814054dd9a1f5240bc684769275e40ab81ba6e
Lucas De Marchi
^ permalink raw reply
* [PATCH] Re: Hardcoded instruction causes certain features to fail on ARM platfrom due to endianness
From: Fei Yang @ 2012-10-15 15:33 UTC (permalink / raw)
To: Mikael Pettersson, linux, lethal, magnus.damm, kgene.kim,
linux-arm-kernel
Cc: linux-hotplug, linux-assembly@vger.kernel.org,
linux-kernel@vger.kernel.org, Yangfei (Felix)
In-Reply-To: <20603.47887.262025.941051@pilspetsen.it.uu.se>
2012/10/15 Mikael Pettersson <mikpe@it.uu.se>:
> Yangfei (Felix) writes:
> > Hi all,
> >
> > I found that hardcoded instruction in inline asm can cause certains certain features fail to work on ARM platform due to endianness.
> > As an example, consider the following code snippet of platform_do_lowpower function from arch/arm/mach-realview/hotplug.c:
> > / *
> > * here's the WFI
> > */
> > asm(".word 0xe320f003\n"
> > :
> > :
> > : "memory", "cc");
> >
> > The instruction generated from this inline asm will not work on big-endian ARM platform, such as ARM BE-8 format. Instead, an exception will be generated.
> >
> > Here the code should be:
> > / *
> > * here's the WFI
> > */
> > asm("WFI\n"
> > :
> > :
> > : "memory", "cc");
> >
> > Seems the kernel doesn't support ARM BE-8 well. I don't know why this problem happens.
> > Can anyone tell me who owns this part? I can prepare a patch then.
> > Thanks.
>
> Questions regarding the ARM kernel should go to the linux-arm-kernel mailing list
> (see the MAINTAINERS file), with an optional cc: to the regular LKML.
>
> BE-8 is, if I recall correctly, ARMv7's broken format where code and data have
> different endianess. GAS supports an ".inst" directive which is like ".word"
> except the data is assumed to be code. This matters for disassembly, and may
> also be required for BE-8.
>
> That is, just s/.word/.inst/g above and report back if that works or not.
> --
> 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/
>
>
Hi Mikael,
Thanks for the reply. I modified the code as suggested and rebuilt the
kernel, cpu-hotplug feature now works on big-endian(BE-8) ARM
platform.
Since the ARM core can be configured by system software to work in
big-endian mode, it's necessary to fix this problem. And here is a
small patch :
diff -urN linux-3.6.2/arch/arm/mach-exynos/hotplug.c
linux/arch/arm/mach-exynos/hotplug.c
--- linux-3.6.2/arch/arm/mach-exynos/hotplug.c 2012-10-13
04:50:59.000000000 +0800
+++ linux/arch/arm/mach-exynos/hotplug.c 2012-10-15 23:05:44.000000000 +0800
@@ -72,7 +72,7 @@
/*
* here's the WFI
*/
- asm(".word 0xe320f003\n"
+ asm(".inst 0xe320f003\n"
:
:
: "memory", "cc");
diff -urN linux-3.6.2/arch/arm/mach-realview/hotplug.c
linux/arch/arm/mach-realview/hotplug.c
--- linux-3.6.2/arch/arm/mach-realview/hotplug.c 2012-10-13
04:50:59.000000000 +0800
+++ linux/arch/arm/mach-realview/hotplug.c 2012-10-15 23:05:00.000000000 +0800
@@ -66,7 +66,7 @@
/*
* here's the WFI
*/
- asm(".word 0xe320f003\n"
+ asm(".inst 0xe320f003\n"
:
:
: "memory", "cc");
diff -urN linux-3.6.2/arch/arm/mach-shmobile/hotplug.c
linux/arch/arm/mach-shmobile/hotplug.c
--- linux-3.6.2/arch/arm/mach-shmobile/hotplug.c 2012-10-13
04:50:59.000000000 +0800
+++ linux/arch/arm/mach-shmobile/hotplug.c 2012-10-15 23:05:25.000000000 +0800
@@ -53,7 +53,7 @@
/*
* here's the WFI
*/
- asm(".word 0xe320f003\n"
+ asm(".inst 0xe320f003\n"
:
:
: "memory", "cc");
^ permalink raw reply
* Re: [PATCH] Re: Hardcoded instruction causes certain features to fail on ARM platfrom due to endiann
From: Dave Martin @ 2012-10-16 12:49 UTC (permalink / raw)
To: Fei Yang
Cc: Mikael Pettersson, linux, lethal, magnus.damm, kgene.kim,
linux-arm-kernel, linux-assembly@vger.kernel.org, linux-hotplug,
linux-kernel@vger.kernel.org, Yangfei (Felix)
In-Reply-To: <CAKw8HL154a=K9O7CzPFZ-EqtT+BxYU-uRHodtutdRfYmNpWVww@mail.gmail.com>
On Mon, Oct 15, 2012 at 11:33:08PM +0800, Fei Yang wrote:
> 2012/10/15 Mikael Pettersson <mikpe@it.uu.se>:
> > Yangfei (Felix) writes:
> > > Hi all,
> > >
> > > I found that hardcoded instruction in inline asm can cause certains certain features fail to work on ARM platform due to endianness.
> > > As an example, consider the following code snippet of platform_do_lowpower function from arch/arm/mach-realview/hotplug.c:
> > > / *
> > > * here's the WFI
> > > */
> > > asm(".word 0xe320f003\n"
> > > :
> > > :
> > > : "memory", "cc");
> > >
> > > The instruction generated from this inline asm will not work on big-endian ARM platform, such as ARM BE-8 format. Instead, an exception will be generated.
> > >
> > > Here the code should be:
> > > / *
> > > * here's the WFI
> > > */
> > > asm("WFI\n"
> > > :
> > > :
> > > : "memory", "cc");
> > >
> > > Seems the kernel doesn't support ARM BE-8 well. I don't know why this problem happens.
> > > Can anyone tell me who owns this part? I can prepare a patch then.
> > > Thanks.
> >
> > Questions regarding the ARM kernel should go to the linux-arm-kernel mailing list
> > (see the MAINTAINERS file), with an optional cc: to the regular LKML.
> >
> > BE-8 is, if I recall correctly, ARMv7's broken format where code and data have
> > different endianess. GAS supports an ".inst" directive which is like ".word"
> > except the data is assumed to be code. This matters for disassembly, and may
> > also be required for BE-8.
> >
> > That is, just s/.word/.inst/g above and report back if that works or not.
> > --
> > 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/
> >
> >
>
> Hi Mikael,
>
> Thanks for the reply. I modified the code as suggested and rebuilt the
> kernel, cpu-hotplug feature now works on big-endian(BE-8) ARM
> platform.
> Since the ARM core can be configured by system software to work in
> big-endian mode, it's necessary to fix this problem. And here is a
> small patch :
>
> diff -urN linux-3.6.2/arch/arm/mach-exynos/hotplug.c
> linux/arch/arm/mach-exynos/hotplug.c
> --- linux-3.6.2/arch/arm/mach-exynos/hotplug.c 2012-10-13
> 04:50:59.000000000 +0800
> +++ linux/arch/arm/mach-exynos/hotplug.c 2012-10-15 23:05:44.000000000 +0800
> @@ -72,7 +72,7 @@
> /*
> * here's the WFI
> */
> - asm(".word 0xe320f003\n"
> + asm(".inst 0xe320f003\n"
The cleanest fix would simply be to build these files with appropriate
modified CFLAGS (-march=armv6k or -march=armv7-a), and use the proper
"wfi" mnemonic.
Failing that, you could use the facilities in <asm/opcodes.h> to
declare a wrapper macro for injecting this opcode (see
<asm/opcodes-virt.h> for an example). However, putting custom
opcodes into the assembler should only be done if it's really
necessary. Nowadays, I think we can consider tools which don't
understand the WFI mnemonic to be obsolete, at least for platforms
which only build for v7 and above.
The relevant board maintainers would need to sign off on such a
change, so we don't end up breaking their builds.
If any of these boards needs to build for v6K, the custom opcode might
be worth it -- some people might just possibly be relying on older tools
for such platforms.
Cheers
---Dave
> :
> :
> : "memory", "cc");
> diff -urN linux-3.6.2/arch/arm/mach-realview/hotplug.c
> linux/arch/arm/mach-realview/hotplug.c
> --- linux-3.6.2/arch/arm/mach-realview/hotplug.c 2012-10-13
> 04:50:59.000000000 +0800
> +++ linux/arch/arm/mach-realview/hotplug.c 2012-10-15 23:05:00.000000000 +0800
> @@ -66,7 +66,7 @@
> /*
> * here's the WFI
> */
> - asm(".word 0xe320f003\n"
> + asm(".inst 0xe320f003\n"
> :
> :
> : "memory", "cc");
> diff -urN linux-3.6.2/arch/arm/mach-shmobile/hotplug.c
> linux/arch/arm/mach-shmobile/hotplug.c
> --- linux-3.6.2/arch/arm/mach-shmobile/hotplug.c 2012-10-13
> 04:50:59.000000000 +0800
> +++ linux/arch/arm/mach-shmobile/hotplug.c 2012-10-15 23:05:25.000000000 +0800
> @@ -53,7 +53,7 @@
> /*
> * here's the WFI
> */
> - asm(".word 0xe320f003\n"
> + asm(".inst 0xe320f003\n"
> :
> :
> : "memory", "cc");
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] Re: Hardcoded instruction causes certain features to fail on ARM platfrom due to endiann
From: Fei Yang @ 2012-10-16 16:33 UTC (permalink / raw)
To: Dave Martin
Cc: Mikael Pettersson, linux, lethal, magnus.damm, kgene.kim,
linux-arm-kernel, linux-assembly@vger.kernel.org, linux-hotplug,
linux-kernel@vger.kernel.org, Yangfei (Felix)
In-Reply-To: <20121016124956.GC26075@linaro.org>
2012/10/16 Dave Martin <dave.martin@linaro.org>:
> On Mon, Oct 15, 2012 at 11:33:08PM +0800, Fei Yang wrote:
>> 2012/10/15 Mikael Pettersson <mikpe@it.uu.se>:
>> > Yangfei (Felix) writes:
>> > > Hi all,
>> > >
>> > > I found that hardcoded instruction in inline asm can cause certains certain features fail to work on ARM platform due to endianness.
>> > > As an example, consider the following code snippet of platform_do_lowpower function from arch/arm/mach-realview/hotplug.c:
>> > > / *
>> > > * here's the WFI
>> > > */
>> > > asm(".word 0xe320f003\n"
>> > > :
>> > > :
>> > > : "memory", "cc");
>> > >
>> > > The instruction generated from this inline asm will not work on big-endian ARM platform, such as ARM BE-8 format. Instead, an exception will be generated.
>> > >
>> > > Here the code should be:
>> > > / *
>> > > * here's the WFI
>> > > */
>> > > asm("WFI\n"
>> > > :
>> > > :
>> > > : "memory", "cc");
>> > >
>> > > Seems the kernel doesn't support ARM BE-8 well. I don't know why this problem happens.
>> > > Can anyone tell me who owns this part? I can prepare a patch then.
>> > > Thanks.
>> >
>> > Questions regarding the ARM kernel should go to the linux-arm-kernel mailing list
>> > (see the MAINTAINERS file), with an optional cc: to the regular LKML.
>> >
>> > BE-8 is, if I recall correctly, ARMv7's broken format where code and data have
>> > different endianess. GAS supports an ".inst" directive which is like ".word"
>> > except the data is assumed to be code. This matters for disassembly, and may
>> > also be required for BE-8.
>> >
>> > That is, just s/.word/.inst/g above and report back if that works or not.
>> > --
>> > 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/
>> >
>> >
>>
>> Hi Mikael,
>>
>> Thanks for the reply. I modified the code as suggested and rebuilt the
>> kernel, cpu-hotplug feature now works on big-endian(BE-8) ARM
>> platform.
>> Since the ARM core can be configured by system software to work in
>> big-endian mode, it's necessary to fix this problem. And here is a
>> small patch :
>>
>> diff -urN linux-3.6.2/arch/arm/mach-exynos/hotplug.c
>> linux/arch/arm/mach-exynos/hotplug.c
>> --- linux-3.6.2/arch/arm/mach-exynos/hotplug.c 2012-10-13
>> 04:50:59.000000000 +0800
>> +++ linux/arch/arm/mach-exynos/hotplug.c 2012-10-15 23:05:44.000000000 +0800
>> @@ -72,7 +72,7 @@
>> /*
>> * here's the WFI
>> */
>> - asm(".word 0xe320f003\n"
>> + asm(".inst 0xe320f003\n"
>
> The cleanest fix would simply be to build these files with appropriate
> modified CFLAGS (-march=armv6k or -march=armv7-a), and use the proper
> "wfi" mnemonic.
>
> Failing that, you could use the facilities in <asm/opcodes.h> to
> declare a wrapper macro for injecting this opcode (see
> <asm/opcodes-virt.h> for an example). However, putting custom
> opcodes into the assembler should only be done if it's really
> necessary. Nowadays, I think we can consider tools which don't
> understand the WFI mnemonic to be obsolete, at least for platforms
> which only build for v7 and above.
>
> The relevant board maintainers would need to sign off on such a
> change, so we don't end up breaking their builds.
>
> If any of these boards needs to build for v6K, the custom opcode might
> be worth it -- some people might just possibly be relying on older tools
> for such platforms.
>
> Cheers
> ---Dave
>
>> :
>> :
>> : "memory", "cc");
>> diff -urN linux-3.6.2/arch/arm/mach-realview/hotplug.c
>> linux/arch/arm/mach-realview/hotplug.c
>> --- linux-3.6.2/arch/arm/mach-realview/hotplug.c 2012-10-13
>> 04:50:59.000000000 +0800
>> +++ linux/arch/arm/mach-realview/hotplug.c 2012-10-15 23:05:00.000000000 +0800
>> @@ -66,7 +66,7 @@
>> /*
>> * here's the WFI
>> */
>> - asm(".word 0xe320f003\n"
>> + asm(".inst 0xe320f003\n"
>> :
>> :
>> : "memory", "cc");
>> diff -urN linux-3.6.2/arch/arm/mach-shmobile/hotplug.c
>> linux/arch/arm/mach-shmobile/hotplug.c
>> --- linux-3.6.2/arch/arm/mach-shmobile/hotplug.c 2012-10-13
>> 04:50:59.000000000 +0800
>> +++ linux/arch/arm/mach-shmobile/hotplug.c 2012-10-15 23:05:25.000000000 +0800
>> @@ -53,7 +53,7 @@
>> /*
>> * here's the WFI
>> */
>> - asm(".word 0xe320f003\n"
>> + asm(".inst 0xe320f003\n"
>> :
>> :
>> : "memory", "cc");
>>
>> _______________________________________________
>> linux-arm-kernel mailing list
>> linux-arm-kernel@lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Thanks for the suggestions. The ".inst" directive here may also bring
us trouble if some older tools is used.
In that situation, "wfi" mnemonic will not be recognized either. If we
cannot suppose that newer tools is used, then how can we determine the
endianness during the preprocessor/compile phase? Any ideas?
BTW: I found this bug on my ARM V7-A Cortex-A9 board and the processor
is configured to work in big-endian mode at boot stage (word and
halfword data is interpreted as big-endian, but instruction is still
little-endian) . The kernel is ported from arch/arm/mach-realview. And
I think these boards(mach-realview/mach-shmobile/mach-exynos) should
have the similar problems. ARM arch is Bi-endian since versions 3 and
above.
^ permalink raw reply
* Re: [PATCH] Re: Hardcoded instruction causes certain features to fail on ARM platfrom due to endiann
From: Dave Martin @ 2012-10-16 17:25 UTC (permalink / raw)
To: Fei Yang
Cc: Mikael Pettersson, linux, lethal, magnus.damm, kgene.kim,
linux-arm-kernel, linux-assembly@vger.kernel.org, linux-hotplug,
linux-kernel@vger.kernel.org, Yangfei (Felix)
In-Reply-To: <CAKw8HL3shtbi0Kk-7ZWO9KhtBVU+Vj_Zunh52GDOGJTZSvt6Gg@mail.gmail.com>
On Wed, Oct 17, 2012 at 12:33:54AM +0800, Fei Yang wrote:
> 2012/10/16 Dave Martin <dave.martin@linaro.org>:
> > On Mon, Oct 15, 2012 at 11:33:08PM +0800, Fei Yang wrote:
> >> 2012/10/15 Mikael Pettersson <mikpe@it.uu.se>:
> >> > Yangfei (Felix) writes:
> >> > > Hi all,
> >> > >
> >> > > I found that hardcoded instruction in inline asm can cause certains certain features fail to work on ARM platform due to endianness.
> >> > > As an example, consider the following code snippet of platform_do_lowpower function from arch/arm/mach-realview/hotplug.c:
> >> > > / *
> >> > > * here's the WFI
> >> > > */
> >> > > asm(".word 0xe320f003\n"
> >> > > :
> >> > > :
> >> > > : "memory", "cc");
> >> > >
> >> > > The instruction generated from this inline asm will not work on big-endian ARM platform, such as ARM BE-8 format. Instead, an exception will be generated.
> >> > >
> >> > > Here the code should be:
> >> > > / *
> >> > > * here's the WFI
> >> > > */
> >> > > asm("WFI\n"
> >> > > :
> >> > > :
> >> > > : "memory", "cc");
> >> > >
> >> > > Seems the kernel doesn't support ARM BE-8 well. I don't know why this problem happens.
> >> > > Can anyone tell me who owns this part? I can prepare a patch then.
> >> > > Thanks.
> >> >
> >> > Questions regarding the ARM kernel should go to the linux-arm-kernel mailing list
> >> > (see the MAINTAINERS file), with an optional cc: to the regular LKML.
> >> >
> >> > BE-8 is, if I recall correctly, ARMv7's broken format where code and data have
> >> > different endianess. GAS supports an ".inst" directive which is like ".word"
> >> > except the data is assumed to be code. This matters for disassembly, and may
> >> > also be required for BE-8.
> >> >
> >> > That is, just s/.word/.inst/g above and report back if that works or not.
> >> > --
> >> > 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/
> >> >
> >> >
> >>
> >> Hi Mikael,
> >>
> >> Thanks for the reply. I modified the code as suggested and rebuilt the
> >> kernel, cpu-hotplug feature now works on big-endian(BE-8) ARM
> >> platform.
> >> Since the ARM core can be configured by system software to work in
> >> big-endian mode, it's necessary to fix this problem. And here is a
> >> small patch :
> >>
> >> diff -urN linux-3.6.2/arch/arm/mach-exynos/hotplug.c
> >> linux/arch/arm/mach-exynos/hotplug.c
> >> --- linux-3.6.2/arch/arm/mach-exynos/hotplug.c 2012-10-13
> >> 04:50:59.000000000 +0800
> >> +++ linux/arch/arm/mach-exynos/hotplug.c 2012-10-15 23:05:44.000000000 +0800
> >> @@ -72,7 +72,7 @@
> >> /*
> >> * here's the WFI
> >> */
> >> - asm(".word 0xe320f003\n"
> >> + asm(".inst 0xe320f003\n"
> >
> > The cleanest fix would simply be to build these files with appropriate
> > modified CFLAGS (-march=armv6k or -march=armv7-a), and use the proper
> > "wfi" mnemonic.
> >
> > Failing that, you could use the facilities in <asm/opcodes.h> to
> > declare a wrapper macro for injecting this opcode (see
> > <asm/opcodes-virt.h> for an example). However, putting custom
> > opcodes into the assembler should only be done if it's really
> > necessary. Nowadays, I think we can consider tools which don't
> > understand the WFI mnemonic to be obsolete, at least for platforms
> > which only build for v7 and above.
> >
> > The relevant board maintainers would need to sign off on such a
> > change, so we don't end up breaking their builds.
> >
> > If any of these boards needs to build for v6K, the custom opcode might
> > be worth it -- some people might just possibly be relying on older tools
> > for such platforms.
> >
> > Cheers
> > ---Dave
> >
> >> :
> >> :
> >> : "memory", "cc");
> >> diff -urN linux-3.6.2/arch/arm/mach-realview/hotplug.c
> >> linux/arch/arm/mach-realview/hotplug.c
> >> --- linux-3.6.2/arch/arm/mach-realview/hotplug.c 2012-10-13
> >> 04:50:59.000000000 +0800
> >> +++ linux/arch/arm/mach-realview/hotplug.c 2012-10-15 23:05:00.000000000 +0800
> >> @@ -66,7 +66,7 @@
> >> /*
> >> * here's the WFI
> >> */
> >> - asm(".word 0xe320f003\n"
> >> + asm(".inst 0xe320f003\n"
> >> :
> >> :
> >> : "memory", "cc");
> >> diff -urN linux-3.6.2/arch/arm/mach-shmobile/hotplug.c
> >> linux/arch/arm/mach-shmobile/hotplug.c
> >> --- linux-3.6.2/arch/arm/mach-shmobile/hotplug.c 2012-10-13
> >> 04:50:59.000000000 +0800
> >> +++ linux/arch/arm/mach-shmobile/hotplug.c 2012-10-15 23:05:25.000000000 +0800
> >> @@ -53,7 +53,7 @@
> >> /*
> >> * here's the WFI
> >> */
> >> - asm(".word 0xe320f003\n"
> >> + asm(".inst 0xe320f003\n"
> >> :
> >> :
> >> : "memory", "cc");
> >>
> >> _______________________________________________
> >> linux-arm-kernel mailing list
> >> linux-arm-kernel@lists.infradead.org
> >> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
> Thanks for the suggestions. The ".inst" directive here may also bring
> us trouble if some older tools is used.
> In that situation, "wfi" mnemonic will not be recognized either. If we
> cannot suppose that newer tools is used, then how can we determine the
> endianness during the preprocessor/compile phase? Any ideas?
The endianness is controlled by the build-time configuration of the
kernel. A single kernel image cannot be bi-endian.
The __inst_*() macros in <asm/opcodes.h> take care of this based on which
CONFIG_CPU_ENDIAN_* option is selected by the board in the kernel config.
For compatibility with old tools, this is done instead of using the
".inst" directive.
> BTW: I found this bug on my ARM V7-A Cortex-A9 board and the processor
> is configured to work in big-endian mode at boot stage (word and
> halfword data is interpreted as big-endian, but instruction is still
> little-endian) . The kernel is ported from arch/arm/mach-realview. And
> I think these boards(mach-realview/mach-shmobile/mach-exynos) should
> have the similar problems. ARM arch is Bi-endian since versions 3 and
> above.
I believe that shmobile and exynos are v7-only, so it may be better to
just use "wfi" and override the CFLAGS for those files. As you can
see, those were just created by copy-pasting the code from mach-realview.
realview itself can be used with ARMv6 based core-tiles, so there may be
an argument for a custom opcode in this case:
#include <asm/opcodes.h>
#define __WFI __inst_arm_thumb16(0xE320F003, 0xBF30)
Not handling the Thumb case is a definite bug for any file which may
run on v7, since the kernel could be built in Thumb for that case.
For example, the existing code is mach-realview/hotplug.c is broken
when building an SMP Thumb-2 kernel for the Realview PBX-A9.
Cheers
---Dave
^ permalink raw reply
* Re: [RFC PATCH v2] Hardcoded instruction causes cpu-hotplug fail on be8 big-endian ARM platfrom
From: Fei Yang @ 2012-10-17 12:00 UTC (permalink / raw)
To: Dave Martin, linux, lethal, magnus.damm, kgene.kim,
linux-arm-kernel
Cc: Mikael Pettersson, linux-assembly@vger.kernel.org, linux-hotplug,
linux-kernel@vger.kernel.org, Yangfei (Felix)
<cut>
> Not handling the Thumb case is a definite bug for any file which may
> run on v7, since the kernel could be built in Thumb for that case.
> For example, the existing code is mach-realview/hotplug.c is broken
> when building an SMP Thumb-2 kernel for the Realview PBX-A9.
>
> Cheers
> ---Dave
Thanks for pointing this out. I think we just cannot make any
assumption about the versions of the tools used. Based on this, I have
made a v2 of the patch against linux-3.7-rc1. I am not touching the
CFLAGS in the patch as I am not familiar with the three ARM boards
here.
Can the respective board maintainers
(mach-exynos/mach-realveiw/mach-shmobile) give any comments about v2
of the patch?
Thanks.
---Fei
v2: Define opcode of the ARM "WFI" instruction in the right way.
Signed-off-by: Fei Yang<yangfei.kernel@gmail.com>
diff -urN linux-3.7-rc1/arch/arm/mach-exynos/hotplug.c
linux/arch/arm/mach-exynos/hotplug.c
--- linux-3.7-rc1/arch/arm/mach-exynos/hotplug.c 2012-10-15
05:41:04.000000000 +0800
+++ linux/arch/arm/mach-exynos/hotplug.c 2012-10-17 19:25:49.000000000 +0800
@@ -18,11 +18,17 @@
#include <asm/cacheflush.h>
#include <asm/cp15.h>
#include <asm/smp_plat.h>
+#include <asm/opcodes.h>
#include <mach/regs-pmu.h>
#include "common.h"
+/*
+ * Define opcode of the WFI instruction.
+ */
+#define __WFI __inst_arm_thumb16(0xe320f003, 0xbf30)
+
static inline void cpu_enter_lowpower(void)
{
unsigned int v;
@@ -72,7 +78,7 @@
/*
* here's the WFI
*/
- asm(".word 0xe320f003\n"
+ asm(__WFI
:
:
: "memory", "cc");
diff -urN linux-3.7-rc1/arch/arm/mach-realview/hotplug.c
linux/arch/arm/mach-realview/hotplug.c
--- linux-3.7-rc1/arch/arm/mach-realview/hotplug.c 2012-10-15
05:41:04.000000000 +0800
+++ linux/arch/arm/mach-realview/hotplug.c 2012-10-17 19:25:20.000000000 +0800
@@ -15,6 +15,12 @@
#include <asm/cacheflush.h>
#include <asm/cp15.h>
#include <asm/smp_plat.h>
+#include <asm/opcodes.h>
+
+/*
+ * Define opcode of the WFI instruction.
+ */
+#define __WFI __inst_arm_thumb16(0xe320f003, 0xbf30)
static inline void cpu_enter_lowpower(void)
{
@@ -64,7 +70,7 @@
/*
* here's the WFI
*/
- asm(".word 0xe320f003\n"
+ asm(__WFI
:
:
: "memory", "cc");
diff -urN linux-3.7-rc1/arch/arm/mach-shmobile/hotplug.c
linux/arch/arm/mach-shmobile/hotplug.c
--- linux-3.7-rc1/arch/arm/mach-shmobile/hotplug.c 2012-10-15
05:41:04.000000000 +0800
+++ linux/arch/arm/mach-shmobile/hotplug.c 2012-10-17 19:25:34.000000000 +0800
@@ -20,6 +20,12 @@
#include <mach/emev2.h>
#include <asm/cacheflush.h>
#include <asm/mach-types.h>
+#include <asm/opcodes.h>
+
+/*
+ * Define opcode of the WFI instruction.
+ */
+#define __WFI __inst_arm_thumb16(0xe320f003, 0xbf30)
static cpumask_t dead_cpus;
@@ -39,7 +45,7 @@
/*
* here's the WFI
*/
- asm(".word 0xe320f003\n"
+ asm(__WFI
:
:
: "memory", "cc");
^ permalink raw reply
* Re: [RFC PATCH v2] ARM hardcoded instruction causes cpu-hotplug fail to work on big-endian platfrom
From: Fei Yang @ 2012-10-22 11:01 UTC (permalink / raw)
To: Dave Martin, linux, lethal, magnus.damm, kgene.kim,
linux-arm-kernel
Cc: Mikael Pettersson, linux-assembly@vger.kernel.org, linux-hotplug,
linux-kernel@vger.kernel.org, yangfei.kernel, Yangfei (Felix)
2012/10/17 Fei Yang <yangfei.kernel@gmail.com>:
> <cut>
>
>> Not handling the Thumb case is a definite bug for any file which may
>> run on v7, since the kernel could be built in Thumb for that case.
>> For example, the existing code is mach-realview/hotplug.c is broken
>> when building an SMP Thumb-2 kernel for the Realview PBX-A9.
>>
>> Cheers
>> ---Dave
>
> Thanks for pointing this out. I think we just cannot make any
> assumption about the versions of the tools used. Based on this, I have
> made a v2 of the patch against linux-3.7-rc1. I am not touching the
> CFLAGS in the patch as I am not familiar with the three ARM boards
> here.
> Can the respective board maintainers
> (mach-exynos/mach-realveiw/mach-shmobile) give any comments about v2
> of the patch?
>
> Thanks.
> ---Fei
>
> v2: Define opcode of the ARM "WFI" instruction in the right way.
>
> Signed-off-by: Fei Yang<yangfei.kernel@gmail.com>
>
> diff -urN linux-3.7-rc1/arch/arm/mach-exynos/hotplug.c
> linux/arch/arm/mach-exynos/hotplug.c
> --- linux-3.7-rc1/arch/arm/mach-exynos/hotplug.c 2012-10-15
> 05:41:04.000000000 +0800
> +++ linux/arch/arm/mach-exynos/hotplug.c 2012-10-17 19:25:49.000000000 +0800
> @@ -18,11 +18,17 @@
> #include <asm/cacheflush.h>
> #include <asm/cp15.h>
> #include <asm/smp_plat.h>
> +#include <asm/opcodes.h>
>
> #include <mach/regs-pmu.h>
>
> #include "common.h"
>
> +/*
> + * Define opcode of the WFI instruction.
> + */
> +#define __WFI __inst_arm_thumb16(0xe320f003, 0xbf30)
> +
> static inline void cpu_enter_lowpower(void)
> {
> unsigned int v;
> @@ -72,7 +78,7 @@
> /*
> * here's the WFI
> */
> - asm(".word 0xe320f003\n"
> + asm(__WFI
> :
> :
> : "memory", "cc");
> diff -urN linux-3.7-rc1/arch/arm/mach-realview/hotplug.c
> linux/arch/arm/mach-realview/hotplug.c
> --- linux-3.7-rc1/arch/arm/mach-realview/hotplug.c 2012-10-15
> 05:41:04.000000000 +0800
> +++ linux/arch/arm/mach-realview/hotplug.c 2012-10-17 19:25:20.000000000 +0800
> @@ -15,6 +15,12 @@
> #include <asm/cacheflush.h>
> #include <asm/cp15.h>
> #include <asm/smp_plat.h>
> +#include <asm/opcodes.h>
> +
> +/*
> + * Define opcode of the WFI instruction.
> + */
> +#define __WFI __inst_arm_thumb16(0xe320f003, 0xbf30)
>
> static inline void cpu_enter_lowpower(void)
> {
> @@ -64,7 +70,7 @@
> /*
> * here's the WFI
> */
> - asm(".word 0xe320f003\n"
> + asm(__WFI
> :
> :
> : "memory", "cc");
> diff -urN linux-3.7-rc1/arch/arm/mach-shmobile/hotplug.c
> linux/arch/arm/mach-shmobile/hotplug.c
> --- linux-3.7-rc1/arch/arm/mach-shmobile/hotplug.c 2012-10-15
> 05:41:04.000000000 +0800
> +++ linux/arch/arm/mach-shmobile/hotplug.c 2012-10-17 19:25:34.000000000 +0800
> @@ -20,6 +20,12 @@
> #include <mach/emev2.h>
> #include <asm/cacheflush.h>
> #include <asm/mach-types.h>
> +#include <asm/opcodes.h>
> +
> +/*
> + * Define opcode of the WFI instruction.
> + */
> +#define __WFI __inst_arm_thumb16(0xe320f003, 0xbf30)
>
> static cpumask_t dead_cpus;
>
> @@ -39,7 +45,7 @@
> /*
> * here's the WFI
> */
> - asm(".word 0xe320f003\n"
> + asm(__WFI
> :
> :
> : "memory", "cc");
> --
> 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/
>
>
Hi,
Any comments on this patch? It is posted last week. Please let me
know if I missed anything.
Thanks.
---Fei
^ permalink raw reply
* [ANNOUNCE] kmod 11
From: Lucas De Marchi @ 2012-11-08 5:02 UTC (permalink / raw)
To: linux-modules; +Cc: LKML, linux-hotplug, Rusty Russell
kmod 11 is out:
ftp://ftp.kernel.org/pub/linux/utils/kernel/kmod/kmod-11.tar.xz
ftp://ftp.kernel.org/pub/linux/utils/kernel/kmod/kmod-11.tar.sign
This is the greatest release ever for those using compressed modules
(I'd like to rather remove it, but some distros are using it so it's
unlikely to happen soon). When using compressed modules there was a
bug regarding modules.order since forever. Now distros don't have to
tweak this file anymore and user can freely mix compressed and
non-compressed modules.
The time needed for running depmod has been greatly reduced with this
release. And this is not exclusive to those using compressed modules.
For non-compressed modules there were reports of a speedup of 3x in
depmod. Check http://git.kernel.org/?p=utils/kernel/kmod/kmod.git;a=commit;h\x1eff942e37adda55bd8c506d4e2a7970fdbf7a74
for details... the timings got improved even more after that commit.
Testsuite also got bug fixes and is now capable of comparing output
files to decide if a test succeeded. Other projects using our
testsuite should upgrade to this new version.
Due to the major refactor in depmod needed to accomplish the speedup
mentioned above, I thought about releasing a -rc1 but then decided to
go straight with a release since it would probably not help a lot.
Please give it more time than usual in your distro testing repository.
If a major bug is found I'll just release another version sooner than
usual.
Last but not least, "--wait" option to rmmod is gone. Or at least it's
now hidden and causing a sleep of 10s if user decides to use it. The
reason is that this feature is being deprecated on kernel side since
it doesn't have any good reason to exist and causes some pain to
maintain.
Take a look in NEWS file for more details on changes. Shortlog is below.
Cheers!
Lucas De Marchi
---
Dave Reisner (5):
Revert "build-sys: disable jobserver for rootfs target"
Define rootfs as dependency of check-am
Makefile: remove redundant flags to $(RM)
modinfo: clarify verbiage for field shortcuts
build-sys: Remove --with-rootprefix option
Jan Engelhardt (1):
NEWS: language corrections
Leandro Pereira (1):
libkmod-hash: Plug possible memory leak when free_value is defined
Lucas De Marchi (38):
testsuite: Fix double definition of 64-bits variant
build-sys: Append -Werror when testing flags
depmod: fix parsing of modules.order with compressed modules
testsuite: allow to check generated files
testsuite: add depmod test for modules.alias
libkmod: Add support for '.' in module parameter on kcmdline
rmmod: Deprecate --wait option
libkmod: cache open file for later access
build-sys: use AS_IF autoconf macro
depmod: do not create a hole in struct depmod
depmod: cache info_list in struct mod
depmod: cache dependency_symbol list in struct mod
depmod: use our copy of modname instead of calling libkmod
depmod: unref kmod_module once we don't need it anymore
modprobe: exit in one place
modprobe: use prio_to_str() helper
modprobe: prefix libkmod messages to stderr with modprobe:
modprobe: move log function
modprobe: prefix log messages to stderr with modprobe
modprobe: use ERR() instead of fprintf(stderr, ...)
depmod: prefer ERR and WRN over plain fprintf
TODO: update file with tasks
depmod: remove inline from _log
depmod: add depmod prefix to log messages
insmod: prefer ERR over plain fprintf
modinfo: prefer ERR over plain fprintf
rmmod: prefer ERR over plain fprintf
rmmod: route all messages to syslog if told to
tools: share getting program name from argv for all tools
tools: share function to convert prio to string
tools: make usage() messages go to stdout rather than stderr
tools: use a single function for logging libkmod output
tools: share setting up libkmod log
tools: share function for logging
tools: staticize functions that are now only used in log.c
tools: use program_invocation_short_name provided by libc
TODO: remove completed action
kmod 11
Sami Kerola (1):
build-sys: require xsltproc when manpages are enabled
^ permalink raw reply
* [PATCH] allow udev to correctly handle 'change' after device has disappeared
From: Robert Milasan @ 2012-11-08 9:42 UTC (permalink / raw)
To: linux-hotplug
From: Neil Brown <nfbrown@suse.com>
Date: Thu, 8 Nov 2012 10:39:06 +0100
Subject: [PATCH] If a 'change' event does not get handled by udev until
after the device has subsequently disappeared, udev mis-handles
it. This can happen with 'md' devices which emit a change
event and then a remove event when they are stopped. It is
normally only noticed if udev is very busy (lots of arrays
being stopped at once) or the machine is otherwise loaded
and reponding slowly.
There are two problems.
1/ udev_device_new_from_syspath() will refuse to create the device
structure if the device does not exist in /sys, and particularly if
the uevent file does not exist.
If a 'db' file does exist, that is sufficient evidence that the device
is genuine and should be created. Equally if we have just received an
event from the kernel about the device, it must be real.
This patch just disabled the test for the 'uevent' file, it doesn't
try imposing any other tests - it isn't clear that they are really
needed.
2/ udev_event_execute_rules() calls udev_device_read_db() on a 'device'
structure that is largely uninitialised and in particular does not
have the 'subsystem' set. udev_device_read_db() needs the subsystem
so it tries to read the 'subsystem' symlink out of sysfs. If the
device is already deleted, this naturally fails.
udev_event_execute_rules() knows the subsystem (as it was in the
event message) so this patch simply sets the subsystem for the device
structure to be loaded to match the subsystem of the device structure
that is handling the event.
With these two changes, deleted handling of change events will still
correctly remove any symlinks that are not needed any more.
---
src/libudev/libudev-device.c | 2 --
src/udev/udev-event.c | 2 ++
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/libudev/libudev-device.c b/src/libudev/libudev-device.c
index 08476e6..0ea5afe 100644
--- a/src/libudev/libudev-device.c
+++ b/src/libudev/libudev-device.c
@@ -662,8 +662,6 @@ _public_ struct udev_device
*udev_device_new_from_syspath(struct udev *udev, con
/* all "devices" require a "uevent" file */
util_strscpyl(file, sizeof(file), path, "/uevent",
NULL);
- if (stat(file, &statbuf) != 0)
- return NULL;
} else {
/* everything else just needs to be a directory */
if (stat(path, &statbuf) != 0
|| !S_ISDIR(statbuf.st_mode)) diff --git a/src/udev/udev-event.c
b/src/udev/udev-event.c index 2b9fdf6..bc936f4 100644
--- a/src/udev/udev-event.c
+++ b/src/udev/udev-event.c
@@ -799,6 +799,8 @@ int udev_event_execute_rules(struct udev_event
*event, struct udev_rules *rules, } else {
event->dev_db udev_device_new_from_syspath(event->udev,
udev_device_get_syspath(dev)); if (event->dev_db != NULL) {
+ udev_device_set_subsystem(event->dev_db,
+
udev_device_get_subsystem(dev)); udev_device_read_db(event->dev_db,
NULL); udev_device_set_info_loaded(event->dev_db);
--
1.7.7
--
Robert Milasan
L3 Support Engineer
SUSE Linux (http://www.suse.com)
email: rmilasan@suse.com
GPG fingerprint: B6FE F4A8 0FA3 3040 3402 6FE7 2F64 167C 1909 6D1A
^ permalink raw reply related
* DQ77KB 100% kworker or high pitch noise
From: Timo @ 2012-11-16 12:31 UTC (permalink / raw)
To: linux-hotplug
Hi,
I have an Intel motherboard DQ77KB which has a 2-pin header which says
panel_off and a fresh Ubuntu 12.10 (3.5.0-18-generic
) install and a display connected via Displayport (DP1, not eDP1). If I
connect the header in the running system a kworker process pops up with
100% cpu usage. If I leave the header unconnected no kworker process
runs, which is good, but a pitch noise comes from the motherboard,
probably from some voltage regulators.
I am no programmer, and I don't understand much about the kernel. But I
would like to get the problem solved. If I can be any help, please let
me know.
Kind regards
Timo
^ permalink raw reply
* Re: DQ77KB 100% kworker or high pitch noise
From: Greg KH @ 2012-11-16 12:40 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <50A63221.4010806@gmail.com>
On Fri, Nov 16, 2012 at 01:31:29PM +0100, Timo wrote:
> Hi,
>
> I have an Intel motherboard DQ77KB which has a 2-pin header which
> says panel_off and a fresh Ubuntu 12.10 (3.5.0-18-generic
> ) install and a display connected via Displayport (DP1, not eDP1).
> If I connect the header in the running system a kworker process pops
> up with 100% cpu usage. If I leave the header unconnected no kworker
> process runs, which is good, but a pitch noise comes from the
> motherboard, probably from some voltage regulators.
>
> I am no programmer, and I don't understand much about the kernel.
> But I would like to get the problem solved. If I can be any help,
> please let me know.
Given that you are running the Ubuntu disto, I suggest you file a bug in
their bug tracking system, as they are the best ones that can help track
down this issue for you.
Best of luck,
greg k-h
^ permalink raw reply
* udevadm monitor and atapi dvdrw
From: Franco Martelli @ 2012-11-21 15:55 UTC (permalink / raw)
To: linux-hotplug
Hi everybody,
I'm using Debian Sqeeze 6.0, kernel 2.6.32, udev version 164.
With kernel provided from debian my dvdrw is under scsi subsystem and
udevadm monitor recognize optical disk change with a lot of info output
suitable to write rules.
I've recompilated the kernel and things has changed, now my dvdrw is
under ide/atapi subsystem and the device name is hdc now.
I'd like to write a rule that remove udf and crc_itu_t modules as soon
as optical disk is left off from dvdrw drive. Example:
SUBSYSTEM="block", KERNEL="hdc", ACTION="change", RUN+="/sbin/rmmod
udf crc_itu_t"
I look at http://reactivated.net/writing_udev_rules.html but doesn't
help for ide devices ACTION="change".
Could anybody help me to write such a rule?
bye,
--
Franco Martelli.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox