All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH,v2] [media] vivi: Constify structures
From: Kirill Smelkov @ 2012-12-28 13:12 UTC (permalink / raw)
  To: Hans Verkuil; +Cc: Mauro Carvalho Chehab, linux-media, linux-kernel
In-Reply-To: <201212271255.11159.hverkuil@xs4all.nl>

On Thu, Dec 27, 2012 at 12:55:11PM +0100, Hans Verkuil wrote:
> On Wed December 26 2012 16:29:43 Kirill Smelkov wrote:
> > Most of *_ops and other structures in vivi.c were already declared const
> > but some have not. Constify and code/data will take less space:
> > 
> >     $ size drivers/media/platform/vivi.o
> >               text    data     bss     dec     hex filename
> >     before:  12569     248       8   12825    3219 drivers/media/platform/vivi.o
> >     after:   12308      20       8   12336    3030 drivers/media/platform/vivi.o
> > 
> > i.e. vivi.o is now ~500 bytes less.
> > 
> > Signed-off-by: Kirill Smelkov <kirr@navytux.spb.ru>
> > ---
> >  drivers/media/platform/vivi.c | 26 +++++++++++++-------------
> >  1 file changed, 13 insertions(+), 13 deletions(-)
> > 
> > diff --git a/drivers/media/platform/vivi.c b/drivers/media/platform/vivi.c
> > index ec65089..bed04e1 100644
> > --- a/drivers/media/platform/vivi.c
> > +++ b/drivers/media/platform/vivi.c
> > @@ -91,13 +91,13 @@ static const struct v4l2_fract
> >     ------------------------------------------------------------------*/
> >  
> >  struct vivi_fmt {
> > -	char  *name;
> > +	const char  *name;
> 
> Just use one space before '*' since it no longer lines up to anything.

[...]
> > @@ -191,7 +191,7 @@ struct vivi_buffer {
> >  	/* common v4l buffer stuff -- must be first */
> >  	struct vb2_buffer	vb;
> >  	struct list_head	list;
> > -	struct vivi_fmt        *fmt;
> > +	struct vivi_fmt const  *fmt;
> >  };
> >  
> >  struct vivi_dmaqueue {
> > @@ -250,7 +250,7 @@ struct vivi_dev {
> >  	int			   input;
> >  
> >  	/* video capture */
> > -	struct vivi_fmt            *fmt;
> > +	struct vivi_fmt const      *fmt;
> 
> 'const' should be before 'struct' for consistency reasons.

It's just a matter of style, and in this case I though putting const
after would not distract from the fact that fmt is `struct vivi_fmt *`
and also to align types beginning with non-const ones.

But anyway, style is style and this is not a big deal, so here you are
with corrected patch.

Thanks,
Kirill

---- 8< ----
From: Kirill Smelkov <kirr@navytux.spb.ru>
Date: Wed, 26 Dec 2012 19:23:26 +0400
Subject: [PATCH,v2] [media] vivi: Constify structures

Most of *_ops and other structures in vivi.c were already declared const
but some have not. Constify and code/data will take less space:

    $ size drivers/media/platform/vivi.o
              text    data     bss     dec     hex filename
    before:  12569     248       8   12825    3219 drivers/media/platform/vivi.o
    after:   12308      20       8   12336    3030 drivers/media/platform/vivi.o

i.e. vivi.o is now ~500 bytes less.

Signed-off-by: Kirill Smelkov <kirr@navytux.spb.ru>
---
 drivers/media/platform/vivi.c | 26 +++++++++++++-------------
 1 file changed, 13 insertions(+), 13 deletions(-)

 v2:
    
    - put 'const' always before anything, as noted by Hans Verkuil.
    - no changes otherwise.


diff --git a/drivers/media/platform/vivi.c b/drivers/media/platform/vivi.c
index ec65089..8a33a71 100644
--- a/drivers/media/platform/vivi.c
+++ b/drivers/media/platform/vivi.c
@@ -91,13 +91,13 @@ static const struct v4l2_fract
    ------------------------------------------------------------------*/
 
 struct vivi_fmt {
-	char  *name;
+	const char *name;
 	u32   fourcc;          /* v4l2 format id */
 	u8    depth;
 	bool  is_yuv;
 };
 
-static struct vivi_fmt formats[] = {
+static const struct vivi_fmt formats[] = {
 	{
 		.name     = "4:2:2, packed, YUYV",
 		.fourcc   = V4L2_PIX_FMT_YUYV,
@@ -164,9 +164,9 @@ static struct vivi_fmt formats[] = {
 	},
 };
 
-static struct vivi_fmt *__get_format(u32 pixelformat)
+static const struct vivi_fmt *__get_format(u32 pixelformat)
 {
-	struct vivi_fmt *fmt;
+	const struct vivi_fmt *fmt;
 	unsigned int k;
 
 	for (k = 0; k < ARRAY_SIZE(formats); k++) {
@@ -181,7 +181,7 @@ static struct vivi_fmt *__get_format(u32 pixelformat)
 	return &formats[k];
 }
 
-static struct vivi_fmt *get_format(struct v4l2_format *f)
+static const struct vivi_fmt *get_format(struct v4l2_format *f)
 {
 	return __get_format(f->fmt.pix.pixelformat);
 }
@@ -191,7 +191,7 @@ struct vivi_buffer {
 	/* common v4l buffer stuff -- must be first */
 	struct vb2_buffer	vb;
 	struct list_head	list;
-	struct vivi_fmt        *fmt;
+	const struct vivi_fmt  *fmt;
 };
 
 struct vivi_dmaqueue {
@@ -250,7 +250,7 @@ struct vivi_dev {
 	int			   input;
 
 	/* video capture */
-	struct vivi_fmt            *fmt;
+	const struct vivi_fmt      *fmt;
 	struct v4l2_fract          timeperframe;
 	unsigned int               width, height;
 	struct vb2_queue	   vb_vidq;
@@ -297,7 +297,7 @@ struct bar_std {
 
 /* Maximum number of bars are 10 - otherwise, the input print code
    should be modified */
-static struct bar_std bars[] = {
+static const struct bar_std bars[] = {
 	{	/* Standard ITU-R color bar sequence */
 		{ COLOR_WHITE, COLOR_AMBER, COLOR_CYAN, COLOR_GREEN,
 		  COLOR_MAGENTA, COLOR_RED, COLOR_BLUE, COLOR_BLACK, COLOR_BLACK }
@@ -926,7 +926,7 @@ static void vivi_unlock(struct vb2_queue *vq)
 }
 
 
-static struct vb2_ops vivi_video_qops = {
+static const struct vb2_ops vivi_video_qops = {
 	.queue_setup		= queue_setup,
 	.buf_prepare		= buffer_prepare,
 	.buf_queue		= buffer_queue,
@@ -957,7 +957,7 @@ static int vidioc_querycap(struct file *file, void  *priv,
 static int vidioc_enum_fmt_vid_cap(struct file *file, void  *priv,
 					struct v4l2_fmtdesc *f)
 {
-	struct vivi_fmt *fmt;
+	const struct vivi_fmt *fmt;
 
 	if (f->index >= ARRAY_SIZE(formats))
 		return -EINVAL;
@@ -993,7 +993,7 @@ static int vidioc_try_fmt_vid_cap(struct file *file, void *priv,
 			struct v4l2_format *f)
 {
 	struct vivi_dev *dev = video_drvdata(file);
-	struct vivi_fmt *fmt;
+	const struct vivi_fmt *fmt;
 
 	fmt = get_format(f);
 	if (!fmt) {
@@ -1102,7 +1102,7 @@ static int vidioc_s_input(struct file *file, void *priv, unsigned int i)
 static int vidioc_enum_frameintervals(struct file *file, void *priv,
 					     struct v4l2_frmivalenum *fival)
 {
-	struct vivi_fmt *fmt;
+	const struct vivi_fmt *fmt;
 
 	if (fival->index)
 		return -EINVAL;
@@ -1330,7 +1330,7 @@ static const struct v4l2_ioctl_ops vivi_ioctl_ops = {
 	.vidioc_unsubscribe_event = v4l2_event_unsubscribe,
 };
 
-static struct video_device vivi_template = {
+static const struct video_device vivi_template = {
 	.name		= "vivi",
 	.fops           = &vivi_fops,
 	.ioctl_ops 	= &vivi_ioctl_ops,
-- 
1.8.1.rc3.329.g036938a

^ permalink raw reply related

* Re: [patch net-next V3,repost 0/4] net: allow to change carrier from userspace
From: Flavio Leitner @ 2012-12-28 13:18 UTC (permalink / raw)
  To: Jiri Pirko
  Cc: netdev, davem, edumazet, bhutchings, mirqus, shemminger, greearb,
	john.r.fastabend
In-Reply-To: <1356688180-3549-1-git-send-email-jiri@resnulli.us>

On Fri, Dec 28, 2012 at 10:49:36AM +0100, Jiri Pirko wrote:
> This is basically a V3 of a repost of my previous patchset:
> "[patch net-next-2.6 0/2] net: allow to change carrier via sysfs" from Aug 30
> 
> The way net-sysfs stores values changed and this patchset reflects it.
> Also, I exposed carrier via rtnetlink iface.
> 
> So far, only dummy driver uses carrier change ndo. In very near future
> team driver will use that as well.
> 
> V2->V3:
>  - updated ndo_change_carrier comment by Dan Williams
> 
> V1->v2:
>  - added bigger comment to ndo and also note to operstate.txt documentation
>    stating the clear purpose of this iface
> 
> Jiri Pirko (4):
>   net: add change_carrier netdev op
>   net: allow to change carrier via sysfs
>   rtnl: expose carrier value with possibility to set it
>   dummy: implement carrier change
> 
>  Documentation/networking/operstates.txt |  4 ++++
>  drivers/net/dummy.c                     | 10 ++++++++++
>  include/linux/netdevice.h               | 12 ++++++++++++
>  include/uapi/linux/if_link.h            |  1 +
>  net/core/dev.c                          | 19 +++++++++++++++++++
>  net/core/net-sysfs.c                    | 15 ++++++++++++++-
>  net/core/rtnetlink.c                    | 10 ++++++++++
>  7 files changed, 70 insertions(+), 1 deletion(-)

I am using this patch series already with team.

Acked-by: Flavio Leitner <fbl@redhat.com>

^ permalink raw reply

* [Buildroot] Setting up Perf for buildroot
From: Kaiwan Billimoria @ 2012-12-28 13:11 UTC (permalink / raw)
  To: buildroot
In-Reply-To: <CAPDLWs-tb5qydSKCRCAS1Zg6605_ZhmQn=fA6daVxgUm3tT2rw@mail.gmail.com>

Or, perhaps better:

BR2_LINUX_KERNEL_USERMODE_TOOLS_XXX

On Fri, Dec 28, 2012 at 6:39 PM, Kaiwan Billimoria
<kaiwan.billimoria@gmail.com> wrote:
> So I was thinking, keep a config directive in linux/Config.in called
> BR2_LINUX_KERNEL_TOOLS_XXX
> where XXX is the user-mode tool to be built.

^ permalink raw reply

* [Buildroot] Setting up Perf for buildroot
From: Kaiwan Billimoria @ 2012-12-28 13:09 UTC (permalink / raw)
  To: buildroot
In-Reply-To: <20121228115156.2f91b588@skate>

Reproducing the email referenced for context, below.
Pl see my comments inline below:
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

[Buildroot] [PATCH v3] usbip: new package

Thomas Petazzoni thomas.petazzoni at free-electrons.com
Wed Dec 26 17:32:20 UTC 2012

Dear Jeremy Rosen,

On Wed, 26 Dec 2012 17:49:57 +0100 (CET), Jeremy Rosen wrote:

> I would be interested too, more and more tools are distributed with
> the kernel that we might want to build... I'm thinking of the perf
> tools in particular
>
> is there an example somewhere on how to handle these ?

> Unfortunately, there isn't a really good and nice way of handling these
> in Buildroot for now.
>
> I see two options:

 > * Add sub-options to the "Linux kernel" package, to allow the
 >   installation of perf, usbip or other userspace packages whose source
 >   code is bundled with the kernel source code. This is the easiest
 >   solution, since the kernel version, sources and al. is already
>    defined. But it also has major drawbacks: 1/ it makes those tools
  >  available only if you build your kernel with Buildroot and 2/ it
  >  puts the configuration options to install those tools inside the
  >  "Linux kernel" menu, which is not very intuitive.

To my thinking, this (option 1 above) would be the "right" way.

Reasons:
a) As Thomas mentions below, there is an ABI (user<->kernel) that
needs to be honoured, which requires the correct kernel source tree
b) Experienced developers (i.e. buildroot end-users :) ) should be - /
be educated on / - aware of the trade-off's that building a
kernel-tree user-mode tool entails; we should clearly document the
"drawbacks" as well..
c) Drawback 1: Yes it does mean building BR with the kernel; but of
course, a serious end-user can then always choose to use their own
custom kernel afterwards... and regression-test to see whether the
tools work as expected
d) Drawback 2:not a very serious one, IMO... -this can further be
documented in the manual (& word gets around :) )
e) Merely extracting one or 2 folders from the kernel src tree may not
cut it for all tools; in fact, perf has some dependencies on other
portions of the kernel source tree.

So I was thinking, keep a config directive in linux/Config.in called
BR2_LINUX_KERNEL_TOOLS_XXX
where XXX is the user-mode tool to be built.

Thanks,
Kaiwan.

 > * Add separate packages for each of those tools in package/, with
   > those packages depending on the "linux" package. The extract step of
   > those packages could copy the source code of these tools from the
   > Linux kernel source tree into their build directory, or simply build
   > then directly from within the Linux kernel source tree. It solves
   > drawback (2) described above, but not drawback (1).

 > * Add separate packages for each of those tools in package/, and make
   > them independent from the Linux package. They would for example
   > download the latest stable version of the Linux kernel source code,
   > and use that as a source. The extract step could be customized to
   > only extract the part of the kernel sources that are actually
   > relevant for this package. This would solve both drawbacks (1) and
   > (2), but adds different drawbacks: it's another place where we have
   > to bump the kernel version regularly, and people may want to
   > configure the version of the kernel sources used to build those
   > tools: the primary reason why those tools are bundled with the
   > kernel sources is because the userspace-to-kernel ABI specific to
   > those tools gets changed from time to time, and therefore there may
   > be compatibility issues in running those tools from kernel version X
   > under a system running kernel version Y.

> Best regards,

> Thomas
> --
> Thomas Petazzoni, Free Electrons
> Kernel, drivers, real-time and embedded Linux
> development, consulting, training and support.
> http://free-electrons.com

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx



On Fri, Dec 28, 2012 at 4:21 PM, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
>
> Dear Jeremy Rosen,
>
> Please fix your e-mail client to wrap lines at a reasonable width.
>
> On Fri, 28 Dec 2012 11:18:06 +0100 (CET), Jeremy Rosen wrote:
>
> > my guess is that ideally the config entries should be in packages->debug tools, but the makefile should be integrated in the linux kernel makefile
> >
> > I don't think it's possible with KConfig, though...
> >
> >
> > maybe add a perf directory in the packages/ dir with only the Config.in and use the variables set by that Config.in within the kernel makefiles to build the tool
>
> See:
>
> Subject: Re: [Buildroot] [PATCH v3] usbip: new package
> Date: Wed, 26 Dec 2012 18:32:20 +0100
>
> where I did some suggestions on how to do this.
>
> Thomas
> --
> Thomas Petazzoni, Free Electrons
> Kernel, drivers, real-time and embedded Linux
> development, consulting, training and support.
> http://free-electrons.com

^ permalink raw reply

* Re: [PATCH V4 2/2] cfg80211/nl80211: Enable drivers to implement mac address based ACL
From: Johannes Berg @ 2012-12-28 13:09 UTC (permalink / raw)
  To: Vasanthakumar Thiagarajan; +Cc: linville, linux-wireless
In-Reply-To: <1356690070-26612-2-git-send-email-vthiagar@qca.qualcomm.com>

On Fri, 2012-12-28 at 15:51 +0530, Vasanthakumar Thiagarajan wrote:

> + * @acl_type: ACL policy that driver supports,
> + *	see &enum nl80211_acl_policy_attr.

That doesn't make a lot of sense, in particular not the way you use it.
What if a driver supports a blacklist but not a whitelist? It seems that
it should be a bitfield. Also setting a default that isn't "unsupported"
is a bad idea.

> +	NL80211_ATTR_ACL_POLICY,
> +
> +	NL80211_ATTR_MAC_ADDRS,
> +
> +	NL80211_ATTR_MAC_ACL_MAX,
> +
> +	NL80211_ATTR_ACL_TYPE,

> +	if (WARN_ON((wiphy->acl_type <= NL80211_ACL_POLICY_MAX) &&

So basically you could remove the acl_type field completely.


I think maybe if you want to continue supporting the white- & blacklist
you should change it back to nested attributes, but treat the blacklist
there as an optimisation and ignore it for feature advertising.

johannes


^ permalink raw reply

* Re: how to look for source code in kernel
From: Borislav Petkov @ 2012-12-28 13:07 UTC (permalink / raw)
  To: Eric W. Biederman
  Cc: anish singh, amit mehta, Henrique Rodrigues, kishore kumar,
	Jonathan Neuschäfer, linux-kernel, Kernelnewbies
In-Reply-To: <87a9syhbma.fsf@xmission.com>

On Thu, Dec 27, 2012 at 11:36:13PM -0800, Eric W. Biederman wrote:
> git-ls-files | xargs fgrep 'struct f2fs_inode'
> 
> That returns instantly and tells me where to look.  If you can do an
> instant brute force search what is the point of an index?

Not if you're using a lame-ass laptop with a rotating disk:

$ time git ls-files | xargs grep -E 'struct mce\W*{'
arch/x86/include/uapi/asm/mce.h:struct mce {
arch/x86/kernel/cpu/mcheck/mce.c:               if (!final || memcmp(m, final, sizeof(struct mce))) {

real    2m48.415s
user    0m2.388s
sys     0m15.668s

What I've grown accustomed to is cscope with a prior find run on the
kernel source tree to create a custom cscope.files which cscope uses to
index and then using vim bindings in cscope so that if, for example, the
cursor is on a function call, executing a keyboard shortcut opens the
definition of that function in another vim tab. I.e., a thin IDE done
right.

> My experience with gui editors is that they always hide something I
> need to see, or my code is just strange enough (say having asm file,
> or supporting multiple architectures) that the tools get horribly
> confused.

That's true, then I tend to use another xterm with tabbed vim showing
additional files. Btw, git ls-files assumes a source file is tracked by
git and in the seldom case where you're adding new, yet untracked files,
that won't work.

So probably a mixed approach of cscope in one window and grep + editor
in another would cover all bases. For a newbie who wants to only browse
the code, cscope should be enough for starters, I'd say.

Thanks.

-- 
Regards/Gruss,
Boris.

^ permalink raw reply

* Re: Workaround for tcrypt bug?
From: Sandra Schlichting @ 2012-12-28 13:06 UTC (permalink / raw)
  To: Jussi Kivilinna; +Cc: linux-crypto
In-Reply-To: <20121228145509.16824jqi8bl9komo@www.dalek.fi>

> I think you are using wrong module argument, type= instead of mode=. Try
> 'modprobe tcrypt sec=2 mode=402' instead.

Thanks. I would never have thought of that =)

Now it preforms the test, but gives this interesting error:

[root@amd ~]# modprobe tcrypt sec=2 mode=402

Message from syslogd@amd at Dec 28 14:01:05 ...
 kernel:[ 5508.698788] BUG: soft lockup - CPU#0 stuck for 22s! [modprobe:3416]
ERROR: could not insert 'tcrypt': Resource temporarily unavailable

and dmesg gives

[ 5483.730759]
[ 5483.730759] testing speed of async md5
[ 5483.730808] test  0 (   16 byte blocks,   16 bytes per update,   1
updates): 1321110 opers/sec,  21137768 bytes/sec
[ 5485.729538] test  1 (   64 byte blocks,   16 bytes per update,   4
updates): 580970 opers/sec,  37182112 bytes/sec
[ 5487.728254] test  2 (   64 byte blocks,   64 bytes per update,   1
updates): 779323 opers/sec,  49876672 bytes/sec
[ 5489.726972] test  3 (  256 byte blocks,   16 bytes per update,  16
updates): 200928 opers/sec,  51437568 bytes/sec
[ 5491.725692] test  4 (  256 byte blocks,   64 bytes per update,   4
updates): 304514 opers/sec,  77955712 bytes/sec
[ 5493.724408] test  5 (  256 byte blocks,  256 bytes per update,   1
updates): 365982 opers/sec,  93691392 bytes/sec
[ 5495.723126] test  6 ( 1024 byte blocks,   16 bytes per update,  64
updates):  55802 opers/sec,  57141248 bytes/sec
[ 5497.721848] test  7 ( 1024 byte blocks,  256 bytes per update,   4
updates): 110900 opers/sec, 113562112 bytes/sec
[ 5499.720564] test  8 ( 1024 byte blocks, 1024 bytes per update,   1
updates): 118861 opers/sec, 121713664 bytes/sec
[ 5501.719281] test  9 ( 2048 byte blocks,   16 bytes per update, 128
updates):  28424 opers/sec,  58212352 bytes/sec
[ 5503.718022] test 10 ( 2048 byte blocks,  256 bytes per update,   8
updates):  57602 opers/sec, 117968896 bytes/sec
[ 5505.716727] test 11 ( 2048 byte blocks, 1024 bytes per update,   2
updates):  61696 opers/sec, 126353408 bytes/sec
[ 5507.715435] test 12 ( 2048 byte blocks, 2048 bytes per update,   1 updates):
[ 5508.698788] BUG: soft lockup - CPU#0 stuck for 22s! [modprobe:3416]
[ 5508.698793] Modules linked in: tcrypt(+) ansi_cprng vmac xcbc zlib
seed rmd320 rmd256 rmd160 rmd128 cts ccm lzo ghash_generic gcm
salsa20_generic salsa20_x86_64 camellia_generic camellia_x86_64 fcrypt
pcbc tgr192 anubis wp512 khazad tea michael_mic arc4 cast6 cast5
deflate zlib_deflate sha512_generic serpent_sse2_x86_64
serpent_generic twofish_generic twofish_x86_64_3way xts lrw gf128mul
glue_helper twofish_x86_64 twofish_common blowfish_generic
blowfish_x86_64 blowfish_common md4 des_generic fuse ip6table_filter
ip6_tables ebtable_nat ebtables ipt_MASQUERADE iptable_nat nf_nat
xt_CHECKSUM iptable_mangle lockd sunrpc bridge stp llc be2iscsi
iscsi_boot_sysfs bnx2i cnic uio cxgb4i cxgb4 cxgb3i cxgb3 mdio
libcxgbi ib_iser rdma_cm ib_addr iw_cm ib_cm ib_sa ib_mad ib_core
iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi nf_conntrack_ipv4
nf_defrag_ipv4 xt_state nf_conntrack dm_crypt btusb eeepc_wmi asus_wmi
sparse_keymap video ath3k bluetooth rfkill microcode serio_raw r8169
mii k10temp i2c_piix4 snd_hda_codec_realtek snd_hda_codec_hdmi
snd_hda_intel snd_hda_codec snd_hwdep snd_seq snd_seq_device snd_pcm
snd_page_alloc snd_timer snd soundcore binfmt_misc vhost_net tun
macvtap macvlan kvm_amd kvm uinput ata_generic pata_acpi pata_atiixp
wmi radeon i2c_algo_bit drm_kms_helper ttm drm i2c_core
[ 5508.698961] CPU 0
[ 5508.698970] Pid: 3416, comm: modprobe Not tainted
3.6.10-2.fc17.x86_64 #1 System manufacturer System Product
Name/F1A75-I DELUXE
[ 5508.698975] RIP: 0010:[<ffffffff812ddffb>]  [<ffffffff812ddffb>]
md5_transform+0x4db/0x800
[ 5508.698991] RSP: 0018:ffff8801fb401a80  EFLAGS: 00000293
[ 5508.698995] RAX: 000000000c00583a RBX: 000000ff812e5114 RCX: 00000000ffffffff
[ 5508.698999] RDX: 00000000a636da5e RSI: 00000000ffffffff RDI: ffff880210c6c8a0
[ 5508.699002] RBP: ffff8801fb401ad8 R08: 00000000ffffffff R09: 00000000ffffffff
[ 5508.699006] R10: 00000000ffffffff R11: 00000000ffffffff R12: ffffffff81e77e0a
[ 5508.699009] R13: ffffffff00000006 R14: ffff8801fb401a0e R15: ffffffffffffffff
[ 5508.699015] FS:  00007ff4d87f7740(0000) GS:ffff88021ec00000(0000)
knlGS:0000000000000000
[ 5508.699019] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 5508.699022] CR2: 00007ff4d86b3000 CR3: 00000001b4911000 CR4: 00000000000007f0
[ 5508.699027] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 5508.699031] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[ 5508.699036] Process modprobe (pid: 3416, threadinfo
ffff8801fb400000, task ffff880213979710)
[ 5508.699038] Stack:
[ 5508.699041]  3e4ebf9e98282ef4 33626d4a33683409 ffffffffffffffff
ffffffffffffffff
[ 5508.699048]  ffffffffffffffff ffffffffffffffff ffff8801c495f7c0
ffff880210c6c8a0
[ 5508.699055]  ffff880210c6c8b0 0000000000000040 ffff880210c6c8b0
ffff8801fb401b38
[ 5508.699061] Call Trace:
[ 5508.699073]  [<ffffffff812abc39>] md5_update+0xe9/0x140
[ 5508.699081]  [<ffffffff812a6df5>] crypto_shash_update+0x45/0x120
[ 5508.699088]  [<ffffffff812a6ceb>] ? crypto_shash_final+0x3b/0xc0
[ 5508.699095]  [<ffffffff812a6f50>] shash_finup_unaligned+0x20/0x40
[ 5508.699102]  [<ffffffff812a6f8f>] crypto_shash_finup+0x1f/0x40
[ 5508.699108]  [<ffffffff812a6ff8>] shash_digest_unaligned+0x48/0x60
[ 5508.699115]  [<ffffffff812a72b0>] ? shash_ahash_digest+0xf0/0xf0
[ 5508.699121]  [<ffffffff812a702f>] crypto_shash_digest+0x1f/0x40
[ 5508.699128]  [<ffffffff812a727e>] shash_ahash_digest+0xbe/0xf0
[ 5508.699134]  [<ffffffff812a72b0>] ? shash_ahash_digest+0xf0/0xf0
[ 5508.699141]  [<ffffffff812a72d4>] shash_async_digest+0x24/0x30
[ 5508.699147]  [<ffffffff812a6465>] crypto_ahash_op+0x35/0xe0
[ 5508.699153]  [<ffffffff812a6526>] crypto_ahash_digest+0x16/0x20
[ 5508.699164]  [<ffffffffa0701e89>]
test_ahash_speed.constprop.7+0x659/0x7b0 [tcrypt]
[ 5508.699172]  [<ffffffff810b9acc>] ? smp_call_function_many+0x22c/0x260
[ 5508.699185]  [<ffffffffa015b000>] ? 0xffffffffa015afff
[ 5508.699195]  [<ffffffffa0702061>] do_test+0x81/0x2404 [tcrypt]
[ 5508.699205]  [<ffffffffa015b000>] ? 0xffffffffa015afff
[ 5508.699214]  [<ffffffffa015b06e>] tcrypt_mod_init+0x6e/0x1000 [tcrypt]
[ 5508.699224]  [<ffffffffa015b000>] ? 0xffffffffa015afff
[ 5508.699233]  [<ffffffff8100212a>] do_one_initcall+0x12a/0x180
[ 5508.699242]  [<ffffffff810bf16e>] sys_init_module+0xfbe/0x20c0
[ 5508.699248]  [<ffffffff812f9220>] ? ddebug_proc_open+0xd0/0xd0
[ 5508.699257]  [<ffffffff816270e9>] system_call_fastpath+0x16/0x1b
[ 5508.699260] Code: ec 44 8b 6d d4 41 c1 c4 17 41 01 c4 47 8d b4 35
44 ea be a4 41 89 c5 41 31 d5 45 31 e5 45 01 f5 44 8b 75 c8 41 c1 c5
04 45 01 e5 <41> 8d 94 16 a9 cf de 4b 45 8d b4 03 60 4b bb f6 89 55 b4
44 89
[ 5509.714149]  62666 opers/sec, 128339968 bytes/sec
[ 5509.714153] test 13 ( 4096 byte blocks,   16 bytes per update, 256
updates):  14349 opers/sec,  58773504 bytes/sec
[ 5511.712900] test 14 ( 4096 byte blocks,  256 bytes per update,  16
updates):  29364 opers/sec, 120274944 bytes/sec
[ 5513.711616] test 15 ( 4096 byte blocks, 1024 bytes per update,   4
updates):  31516 opers/sec, 129089536 bytes/sec
[ 5515.710331] test 16 ( 4096 byte blocks, 4096 bytes per update,   1
updates):  32178 opers/sec, 131803136 bytes/sec
[ 5517.709019] test 17 ( 8192 byte blocks,   16 bytes per update, 512
updates):   7208 opers/sec,  59047936 bytes/sec
[ 5519.707805] test 18 ( 8192 byte blocks,  256 bytes per update,  32
updates):  14826 opers/sec, 121458688 bytes/sec
[ 5521.706479] test 19 ( 8192 byte blocks, 1024 bytes per update,   8
updates):  15924 opers/sec, 130449408 bytes/sec
[ 5523.705188] test 20 ( 8192 byte blocks, 4096 bytes per update,   2
updates):  16264 opers/sec, 133234688 bytes/sec
[ 5525.703944] test 21 ( 8192 byte blocks, 8192 bytes per update,   1
updates):  16262 opers/sec, 133218304 bytes/sec
[root@amd maj]#

^ permalink raw reply

* [Buildroot] [PATCH 2/2] ulogd: add support for mysql output
From: Gustavo Zacarias @ 2012-12-28 13:05 UTC (permalink / raw)
  To: buildroot
In-Reply-To: <1356699955-27479-1-git-send-email-gustavo@zacarias.com.ar>

Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
---
 package/ulogd/ulogd.mk |    9 ++++++++-
 1 files changed, 8 insertions(+), 1 deletions(-)

diff --git a/package/ulogd/ulogd.mk b/package/ulogd/ulogd.mk
index 4620bbd..34d8665 100644
--- a/package/ulogd/ulogd.mk
+++ b/package/ulogd/ulogd.mk
@@ -7,7 +7,7 @@
 ULOGD_VERSION = 2.0.1
 ULOGD_SOURCE = ulogd-$(ULOGD_VERSION).tar.bz2
 ULOGD_SITE = http://www.netfilter.org/projects/ulogd/files
-ULOGD_CONF_OPT = --with-dbi=no --with-mysql=no --with-pgsql=no
+ULOGD_CONF_OPT = --with-dbi=no --with-pgsql=no
 ULOGD_AUTORECONF = YES
 ULOGD_DEPENDENCIES = host-pkgconf \
 	libmnl libnetfilter_acct libnetfilter_conntrack libnetfilter_log \
@@ -15,4 +15,11 @@ ULOGD_DEPENDENCIES = host-pkgconf \
 ULOGD_LICENSE = GPLv2
 ULOGD_LICENSE_FILES = COPYING
 
+ifeq ($(BR2_PACKAGE_MYSQL_CLIENT),y)
+ULOGD_CONF_OPT += --with-mysql=$(STAGING_DIR)/usr
+ULOGD_DEPENDENCIES += mysql_client
+else
+ULOGD_CONF_OPT += --with-mysql=no
+endif
+
 $(eval $(autotools-package))
-- 
1.7.8.6

^ permalink raw reply related

* [Buildroot] [PATCH 1/2] mysql_client: bump to version 5.1.67
From: Gustavo Zacarias @ 2012-12-28 13:05 UTC (permalink / raw)
  To: buildroot

Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
---
 package/mysql_client/mysql_client.mk |    6 ++++--
 1 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/package/mysql_client/mysql_client.mk b/package/mysql_client/mysql_client.mk
index 9785aee..1477b66 100644
--- a/package/mysql_client/mysql_client.mk
+++ b/package/mysql_client/mysql_client.mk
@@ -4,12 +4,14 @@
 #
 #############################################################
 
-MYSQL_CLIENT_VERSION = 5.1.66
+MYSQL_CLIENT_VERSION = 5.1.67
 MYSQL_CLIENT_SOURCE = mysql-$(MYSQL_CLIENT_VERSION).tar.gz
 MYSQL_CLIENT_SITE = http://downloads.skysql.com/archives/mysql-5.1
 MYSQL_CLIENT_INSTALL_STAGING = YES
 MYSQL_CLIENT_DEPENDENCIES = readline ncurses
-MYSQL_CLIENT_AUTORECONF=YES
+MYSQL_CLIENT_AUTORECONF = YES
+MYSQL_CLIENT_LICENSE = GPLv2
+MYSQL_CLIENT_LICENSE_FILES = README COPYING
 
 MYSQL_CLIENT_CONF_ENV = \
 	ac_cv_sys_restartable_syscalls=yes \
-- 
1.7.8.6

^ permalink raw reply related

* Re: [PATCH net-next] bridge: respect RFC2863 operational state
From: Flavio Leitner @ 2012-12-28 13:03 UTC (permalink / raw)
  To: Stephen Hemminger; +Cc: David Miller, netdev
In-Reply-To: <20121227222854.6ec132dd@nehalam.linuxnetplumber.net>

On Thu, Dec 27, 2012 at 10:28:54PM -0800, Stephen Hemminger wrote:
> The bridge link detection should follow the operational state
> of the lower device, rather than the carrier bit. This allows devices
> like tunnels that are controlled by userspace control plane to work
> with bridge STP link management.
> 
> 
> Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
> 
> 
> --- a/net/bridge/br_if.c	2012-10-25 09:11:15.627272524 -0700
> +++ b/net/bridge/br_if.c	2012-12-14 08:58:14.329847361 -0800
> @@ -66,14 +66,14 @@ void br_port_carrier_check(struct net_br
>  	struct net_device *dev = p->dev;
>  	struct net_bridge *br = p->br;
>  
> -	if (netif_running(dev) && netif_carrier_ok(dev))
> +	if (netif_running(dev) && netif_oper_up(dev))
>  		p->path_cost = port_cost(dev);
>  
>  	if (!netif_running(br->dev))
>  		return;
>  
>  	spin_lock_bh(&br->lock);
> -	if (netif_running(dev) && netif_carrier_ok(dev)) {
> +	if (netif_running(dev) && netif_oper_up(dev))
>  		if (p->state == BR_STATE_DISABLED)
>  			br_stp_enable_port(p);

I found this piece still using netif_carrier_ok():
321 int br_add_if(struct net_bridge *br, struct net_device *dev)
322 {
...
385 
386         if ((dev->flags & IFF_UP) && netif_carrier_ok(dev) &&
387             (br->dev->flags & IFF_UP))
388                 br_stp_enable_port(p);
389         spin_unlock_bh(&br->lock);
390 

Is there any reason for enabling stp on a port using operstate
in br_port_carrier_check() but not in br_add_if() ?

The same thing happens with br_stp_enable_bridge():

 56   list_for_each_entry(p, &br->port_list, list) {
 57          if ((p->dev->flags & IFF_UP) && netif_carrier_ok(p->dev))
 58                  br_stp_enable_port(p);

Also, as operstate UP means that packets are flowing, there is no need to
check if the device is opened, so checking only for operstate should be
enough, right? I.e.

-           if ((p->dev->flags & IFF_UP) && netif_carrier_ok(p->dev))
+           if (netif_oper_up(dev))


>  	} else {
> --- a/net/bridge/br_notify.c	2012-10-25 09:11:15.631272484 -0700
> +++ b/net/bridge/br_notify.c	2012-12-14 08:57:36.954222724 -0800
> @@ -82,7 +82,7 @@ static int br_device_event(struct notifi
>  		break;
>  
>  	case NETDEV_UP:
> -		if (netif_carrier_ok(dev) && (br->dev->flags & IFF_UP)) {
> +		if (netif_running(br->dev) && netif_oper_up(dev)) {
>  			spin_lock_bh(&br->lock);
>  			br_stp_enable_port(p);
>  			spin_unlock_bh(&br->lock);

You are not just changing to use operstate, but also to check another
flag - before it was IFF_UP and now __LINK_STATE_START. Any reason
for that besides being consistent with other checks?

thanks!
-- 
fbl

^ permalink raw reply

* Re: [PATCH v3 02/11] x86/kexec: Add extra pointers to transition page table PGD, PUD, PMD and PTE
From: Borislav Petkov @ 2012-12-28 12:59 UTC (permalink / raw)
  To: Daniel Kiper
  Cc: xen-devel, linux-kernel, konrad.wilk, andrew.cooper3,
	maxim.uvarov, kexec, x86, virtualization, mingo, ebiederm,
	jbeulich, hpa, tglx, vgoyal
In-Reply-To: <71b94237-c365-47ba-8d75-5ee1d8caee73@default>

On Thu, Dec 27, 2012 at 03:19:24PM -0800, Daniel Kiper wrote:
> > Hmm... this code is being redone at the moment... this might conflict.
> 
> Is this available somewhere? May I have a look at it?

http://marc.info/?l=linux-kernel&m=135581534620383

The for-x86-boot-v7 and -v8 branches.

HTH.

-- 
Regards/Gruss,
Boris.

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

^ permalink raw reply

* Re: [PATCH v3 02/11] x86/kexec: Add extra pointers to transition page table PGD, PUD, PMD and PTE
From: Borislav Petkov @ 2012-12-28 12:59 UTC (permalink / raw)
  To: Daniel Kiper
  Cc: hpa, kexec, xen-devel, konrad.wilk, tglx, ebiederm, maxim.uvarov,
	andrew.cooper3, jbeulich, mingo, x86, virtualization, vgoyal,
	linux-kernel
In-Reply-To: <71b94237-c365-47ba-8d75-5ee1d8caee73@default>

On Thu, Dec 27, 2012 at 03:19:24PM -0800, Daniel Kiper wrote:
> > Hmm... this code is being redone at the moment... this might conflict.
> 
> Is this available somewhere? May I have a look at it?

http://marc.info/?l=linux-kernel&m=135581534620383

The for-x86-boot-v7 and -v8 branches.

HTH.

-- 
Regards/Gruss,
Boris.

^ permalink raw reply

* Re: [PATCH v3 02/11] x86/kexec: Add extra pointers to transition page table PGD, PUD, PMD and PTE
From: Borislav Petkov @ 2012-12-28 12:59 UTC (permalink / raw)
  To: Daniel Kiper
  Cc: xen-devel, linux-kernel, konrad.wilk, andrew.cooper3,
	maxim.uvarov, kexec, x86, virtualization, mingo, ebiederm,
	jbeulich, hpa, tglx, vgoyal
In-Reply-To: <71b94237-c365-47ba-8d75-5ee1d8caee73@default>

On Thu, Dec 27, 2012 at 03:19:24PM -0800, Daniel Kiper wrote:
> > Hmm... this code is being redone at the moment... this might conflict.
> 
> Is this available somewhere? May I have a look at it?

http://marc.info/?l=linux-kernel&m=135581534620383

The for-x86-boot-v7 and -v8 branches.

HTH.

-- 
Regards/Gruss,
Boris.

^ permalink raw reply

* Re: BUG: unable to handle kernel NULL pointer dereference at 0000000000000500
From: Zlatko Calusic @ 2012-12-28 12:57 UTC (permalink / raw)
  To: Zhouping Liu
  Cc: linux-mm, linux-kernel, Ingo Molnar, Johannes Weiner, mgorman,
	hughd, Andrea Arcangeli, Hillf Danton, sedat.dilek
In-Reply-To: <1828895463.36547216.1356662710202.JavaMail.root@redhat.com>

On 28.12.2012 03:45, Zhouping Liu wrote:
>>
>> Thank you for the report Zhouping!
>>
>> Would you be so kind to test the following patch and report results?
>> Apply the patch to the latest mainline.
>
> Hello Zlatko,
>
> I have tested the below patch(applied it on mainline directly),
> but IMO, I'd like to say it maybe don't fix the issue completely.
>
> run the reproducer[1] on two machine, one machine has 2 numa nodes(8Gb RAM),
> another one has 4 numa nodes(8Gb RAM), then the system hung all the time, such as the dmesg log:
>
> [  713.066937] Killed process 6085 (oom01) total-vm:18880768kB, anon-rss:7915612kB, file-rss:4kB
> [  959.555269] INFO: task kworker/13:2:147 blocked for more than 120 seconds.
> [  959.562144] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
> [ 1079.382018] INFO: task kworker/13:2:147 blocked for more than 120 seconds.
> [ 1079.388872] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
> [ 1199.209709] INFO: task kworker/13:2:147 blocked for more than 120 seconds.
> [ 1199.216562] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
> [ 1319.036939] INFO: task kworker/13:2:147 blocked for more than 120 seconds.
> [ 1319.043794] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
> [ 1438.864797] INFO: task kworker/13:2:147 blocked for more than 120 seconds.
> [ 1438.871649] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
> [ 1558.691611] INFO: task kworker/13:2:147 blocked for more than 120 seconds.
> [ 1558.698466] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
> ......
>
> I'm not sure whether it's your patch triggering the hung task or not, but reverted cda73a10eb3,
> the reproducer(oom01) can PASS without both 'NULL pointer dereference at 0000000000000500' and hung task issues.
>
> but some time, it's possible that the reproducer(oom01) cause hung task on a box with large RAM(100Gb+), so I can't judge it...
>

Thanks for the test.

Yes, close to OOM things get quite unstable and it's hard to get 
reliable test results. Maybe you could run it a few times, and see if 
you can get any meaningful statistics out of a few runs. I need to check 
oom.c myself and see what it's doing. Thanks for the link.

Regards,
-- 
Zlatko

^ permalink raw reply

* Re: BUG: unable to handle kernel NULL pointer dereference at 0000000000000500
From: Zlatko Calusic @ 2012-12-28 12:57 UTC (permalink / raw)
  To: Zhouping Liu
  Cc: linux-mm, linux-kernel, Ingo Molnar, Johannes Weiner, mgorman,
	hughd, Andrea Arcangeli, Hillf Danton, sedat.dilek
In-Reply-To: <1828895463.36547216.1356662710202.JavaMail.root@redhat.com>

On 28.12.2012 03:45, Zhouping Liu wrote:
>>
>> Thank you for the report Zhouping!
>>
>> Would you be so kind to test the following patch and report results?
>> Apply the patch to the latest mainline.
>
> Hello Zlatko,
>
> I have tested the below patch(applied it on mainline directly),
> but IMO, I'd like to say it maybe don't fix the issue completely.
>
> run the reproducer[1] on two machine, one machine has 2 numa nodes(8Gb RAM),
> another one has 4 numa nodes(8Gb RAM), then the system hung all the time, such as the dmesg log:
>
> [  713.066937] Killed process 6085 (oom01) total-vm:18880768kB, anon-rss:7915612kB, file-rss:4kB
> [  959.555269] INFO: task kworker/13:2:147 blocked for more than 120 seconds.
> [  959.562144] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
> [ 1079.382018] INFO: task kworker/13:2:147 blocked for more than 120 seconds.
> [ 1079.388872] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
> [ 1199.209709] INFO: task kworker/13:2:147 blocked for more than 120 seconds.
> [ 1199.216562] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
> [ 1319.036939] INFO: task kworker/13:2:147 blocked for more than 120 seconds.
> [ 1319.043794] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
> [ 1438.864797] INFO: task kworker/13:2:147 blocked for more than 120 seconds.
> [ 1438.871649] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
> [ 1558.691611] INFO: task kworker/13:2:147 blocked for more than 120 seconds.
> [ 1558.698466] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
> ......
>
> I'm not sure whether it's your patch triggering the hung task or not, but reverted cda73a10eb3,
> the reproducer(oom01) can PASS without both 'NULL pointer dereference at 0000000000000500' and hung task issues.
>
> but some time, it's possible that the reproducer(oom01) cause hung task on a box with large RAM(100Gb+), so I can't judge it...
>

Thanks for the test.

Yes, close to OOM things get quite unstable and it's hard to get 
reliable test results. Maybe you could run it a few times, and see if 
you can get any meaningful statistics out of a few runs. I need to check 
oom.c myself and see what it's doing. Thanks for the link.

Regards,
-- 
Zlatko

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

^ permalink raw reply

* Re: [PATCH V4 2/2] cfg80211/nl80211: Enable drivers to implement mac address based ACL
From: Johannes Berg @ 2012-12-28 12:56 UTC (permalink / raw)
  To: Vasanthakumar Thiagarajan; +Cc: linville, linux-wireless
In-Reply-To: <1356694308.9922.1.camel@jlt4.sipsolutions.net>

On Fri, 2012-12-28 at 12:31 +0100, Johannes Berg wrote:
> On Fri, 2012-12-28 at 15:51 +0530, Vasanthakumar Thiagarajan wrote:
> 
> > V4:
> > 	- Change it accordingly so that at any time the driver can
> > 	  support either white or black list not both.
> 
> I was under the impression you needed both. Unless I get confirmation
> from Kalle and/or Jouni I'll not apply this lest it needs to be changed
> in yet again incompatible ways later ...

Actually I just talked to Jouni again and it seems that the best way to
think of the combined black/whitelist is to treat it as a whitelist +
"notification avoidance optimisation list". The key here being
optimisation, we don't really have to worry about it in terms of feature
advertising etc. since it can be ignored/managed by the driver.

johannes


^ permalink raw reply

* [U-Boot] [PATCH 1/1] OMAP3: igep00x0: add CONFIG_SPL_BOARD_INIT for CONFIG_SPL_NAND_SUPPORT
From: Enric Balletbo Serra @ 2012-12-28 12:55 UTC (permalink / raw)
  To: u-boot
In-Reply-To: <1356699113-30731-1-git-send-email-javier.martinez@collabora.co.uk>

2012/12/28 Javier Martinez Canillas <javier@dowhile0.org>:
> When booting an IGEPv2 board from NAND with SPL, U-Boot hangs
> trying to read the OMAP General Purpose Memory Controller (GPMC).
>
> The reason is that the GPMC initialization function is called
> inside spl_board_init() and this function is only executed when
> CONFIG_SPL_BOARD_INIT is defined.
>
> Signed-off-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
> ---
>  include/configs/igep00x0.h |    1 +
>  1 files changed, 1 insertions(+), 0 deletions(-)
>
> diff --git a/include/configs/igep00x0.h b/include/configs/igep00x0.h
> index 47f637e..2110e64 100644
> --- a/include/configs/igep00x0.h
> +++ b/include/configs/igep00x0.h
> @@ -318,6 +318,7 @@
>  #define CONFIG_SYS_MMC_SD_FAT_BOOT_PARTITION   1
>  #define CONFIG_SPL_FAT_LOAD_PAYLOAD_NAME       "u-boot.img"
>
> +#define CONFIG_SPL_BOARD_INIT
>  #define CONFIG_SPL_LIBCOMMON_SUPPORT
>  #define CONFIG_SPL_LIBDISK_SUPPORT
>  #define CONFIG_SPL_I2C_SUPPORT
> --
> 1.7.7.6
>
> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot

Acked-by: Enric Balletbo i Serra <eballetbo@iseebcn.com>

^ permalink raw reply

* Re: Workaround for tcrypt bug?
From: Jussi Kivilinna @ 2012-12-28 12:55 UTC (permalink / raw)
  To: Sandra Schlichting; +Cc: linux-crypto
In-Reply-To: <CAELiMBMrmagP14SoE1aaDqnuXvwdtVM69zpmK5dn+9Zqby8sQw@mail.gmail.com>

Quoting Sandra Schlichting <littlesandra88@gmail.com>:

>> Why you want to workaround this? It's safe to ignore hmac(crc32) warning.
>
> Because it stops from proceeding. I would have expected that
>
> modprobe tcrypt sec=1 type=1000
>
> would have executed all test cases.
>
> Even if I just want to test one
>
> [root@amd ~]# modprobe tcrypt sec=2 type=402
> ERROR: could not insert 'tcrypt': No such file or directory
>
> I get an error.

I think you are using wrong module argument, type= instead of mode=.  
Try 'modprobe tcrypt sec=2 mode=402' instead.

-Jussi

^ permalink raw reply

* Re: [PATCH v2] sys-tools: Enhance unshare command to support the switching of namespaces
From: Ángel González @ 2012-12-28 12:54 UTC (permalink / raw)
  To: Neil Horman; +Cc: util-linux, kerolasa, grawity, Karel Zak
In-Reply-To: <1356027729-26098-1-git-send-email-nhorman@tuxdriver.com>

On 20/12/12 19:22, Neil Horman wrote:
>  		case 'm':
> -			unshare_flags |= CLONE_NEWNS;
> +			ns = "mount";
> +			if (!optarg)
> +				unshare_flags |= CLONE_NEWNS;
>  			break;

Is this right? I don't have a /proc/<task>/ns/mount locally nor is it
documented in
http://git.kernel.org/?p=docs/man-pages/man-pages.git;a=blob;f=man5/proc.5

However looking at
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=blob;f=fs/proc/namespaces.c
there is a reference to mntns_operations, which is defined in
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=blob;f=fs/proc/namespaces.c

but seems to be called "mnt", not "mount"

There are also pid and user namespaces there, but support for those are
better handled in a different patch IMHO.


> +				sprintf(path, "/proc/%d/ns/%s", (int)pid, ns); 
> +				ns_pids[nscount] = open(path, O_RDONLY);
> +				if (ns_pids[nscount] < 0)
> +					err(EXIT_FAILURE, _("could not open %s"), path);
> +				nscount++;

What about err(EXIT_FAILURE, _("The kernel doesn't seem to support %s
migrations: could not open %s"), ns, path); ?

Mention in the man page the kernel version from which each namespace can
be migrated.

^ permalink raw reply

* [U-Boot] [PATCH 1/1] OMAP3: igep00x0: add CONFIG_SPL_BOARD_INIT for CONFIG_SPL_NAND_SUPPORT
From: Javier Martinez Canillas @ 2012-12-28 12:51 UTC (permalink / raw)
  To: u-boot

When booting an IGEPv2 board from NAND with SPL, U-Boot hangs
trying to read the OMAP General Purpose Memory Controller (GPMC).

The reason is that the GPMC initialization function is called
inside spl_board_init() and this function is only executed when
CONFIG_SPL_BOARD_INIT is defined.

Signed-off-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
---
 include/configs/igep00x0.h |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/include/configs/igep00x0.h b/include/configs/igep00x0.h
index 47f637e..2110e64 100644
--- a/include/configs/igep00x0.h
+++ b/include/configs/igep00x0.h
@@ -318,6 +318,7 @@
 #define CONFIG_SYS_MMC_SD_FAT_BOOT_PARTITION	1
 #define CONFIG_SPL_FAT_LOAD_PAYLOAD_NAME	"u-boot.img"
 
+#define CONFIG_SPL_BOARD_INIT
 #define CONFIG_SPL_LIBCOMMON_SUPPORT
 #define CONFIG_SPL_LIBDISK_SUPPORT
 #define CONFIG_SPL_I2C_SUPPORT
-- 
1.7.7.6

^ permalink raw reply related

* [PATCH BlueZ 11/11] AVRCP: Fix not checking for media_player_controller_create
From: Luiz Augusto von Dentz @ 2012-12-28 12:51 UTC (permalink / raw)
  To: linux-bluetooth
In-Reply-To: <1356699069-5469-1-git-send-email-luiz.dentz@gmail.com>

From: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>

Now that the MediaPlayer1 interface is experimental the interface
registration may fail which return NULL, in that case there is no
point on register to any notifications.
---
 profiles/audio/avrcp.c | 7 +++++--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/profiles/audio/avrcp.c b/profiles/audio/avrcp.c
index 4e3d31d..ce070cd 100644
--- a/profiles/audio/avrcp.c
+++ b/profiles/audio/avrcp.c
@@ -1987,6 +1987,11 @@ static gboolean avrcp_get_capabilities_resp(struct avctp *conn,
 
 	count = pdu->params[1];
 
+	path = device_get_path(session->dev->btd_dev);
+	mp = media_player_controller_create(path);
+	if (mp == NULL)
+		return FALSE;
+
 	for (; count > 0; count--) {
 		uint8_t event = pdu->params[1 + count];
 
@@ -2001,8 +2006,6 @@ static gboolean avrcp_get_capabilities_resp(struct avctp *conn,
 		}
 	}
 
-	path = device_get_path(session->dev->btd_dev);
-	mp = media_player_controller_create(path);
 	media_player_set_callbacks(mp, &ct_cbs, player);
 	player->user_data = mp;
 	player->destroy = (GDestroyNotify) media_player_destroy;
-- 
1.8.0.1


^ permalink raw reply related

* [PATCH BlueZ 10/11] player: Enable MediaPlayer1 interface as experimental
From: Luiz Augusto von Dentz @ 2012-12-28 12:51 UTC (permalink / raw)
  To: linux-bluetooth
In-Reply-To: <1356699069-5469-1-git-send-email-luiz.dentz@gmail.com>

From: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>

This enable MediaPlayer1 when GDBUS_EXPERIMENTAL=1
---
 profiles/audio/player.c | 28 ++++++++++++++++------------
 1 file changed, 16 insertions(+), 12 deletions(-)

diff --git a/profiles/audio/player.c b/profiles/audio/player.c
index 005d0d1..693a590 100644
--- a/profiles/audio/player.c
+++ b/profiles/audio/player.c
@@ -239,25 +239,31 @@ static void set_setting(const GDBusPropertyTable *property,
 }
 
 static const GDBusMethodTable media_player_methods[] = {
-	{ GDBUS_METHOD("GetTrack",
+	{ GDBUS_EXPERIMENTAL_METHOD("GetTrack",
 			NULL, GDBUS_ARGS({ "metadata", "a{sv}" }),
 			media_player_get_track) },
 	{ }
 };
 
 static const GDBusSignalTable media_player_signals[] = {
-	{ GDBUS_SIGNAL("TrackChanged",
+	{ GDBUS_EXPERIMENTAL_SIGNAL("TrackChanged",
 			GDBUS_ARGS({ "metadata", "a{sv}" })) },
 	{ }
 };
 
 static const GDBusPropertyTable media_player_properties[] = {
-	{ "Position", "u", get_position },
-	{ "Status", "s", get_status, NULL, status_exists },
-	{ "Equalizer", "s", get_setting, set_setting, setting_exists },
-	{ "Repeat", "s", get_setting, set_setting, setting_exists },
-	{ "Shuffle", "s", get_setting, set_setting, setting_exists },
-	{ "Scan", "s", get_setting, set_setting, setting_exists },
+	{ "Position", "u", get_position, NULL, NULL,
+					G_DBUS_PROPERTY_FLAG_EXPERIMENTAL },
+	{ "Status", "s", get_status, NULL, status_exists,
+					G_DBUS_PROPERTY_FLAG_EXPERIMENTAL },
+	{ "Equalizer", "s", get_setting, set_setting, setting_exists,
+					G_DBUS_PROPERTY_FLAG_EXPERIMENTAL },
+	{ "Repeat", "s", get_setting, set_setting, setting_exists,
+					G_DBUS_PROPERTY_FLAG_EXPERIMENTAL },
+	{ "Shuffle", "s", get_setting, set_setting, setting_exists,
+					G_DBUS_PROPERTY_FLAG_EXPERIMENTAL },
+	{ "Scan", "s", get_setting, set_setting, setting_exists,
+					G_DBUS_PROPERTY_FLAG_EXPERIMENTAL },
 	{ }
 };
 
@@ -298,7 +304,6 @@ struct media_player *media_player_controller_create(const char *path)
 							g_free, g_free);
 	mp->progress = g_timer_new();
 
-#if 0
 	if (!g_dbus_register_interface(btd_get_dbus_connection(),
 					mp->path, MEDIA_PLAYER_INTERFACE,
 					media_player_methods,
@@ -308,7 +313,7 @@ struct media_player *media_player_controller_create(const char *path)
 		media_player_destroy(mp);
 		return NULL;
 	}
-#endif
+
 	DBG("%s", mp->path);
 
 	return mp;
@@ -410,7 +415,6 @@ void media_player_set_status(struct media_player *mp, const char *status)
 
 static gboolean process_metadata_changed(void *user_data)
 {
-#if 0
 	struct media_player *mp = user_data;
 	DBusMessage *signal;
 	DBusMessageIter iter, dict;
@@ -439,7 +443,7 @@ static gboolean process_metadata_changed(void *user_data)
 	dbus_message_iter_close_container(&iter, &dict);
 
 	g_dbus_send_message(btd_get_dbus_connection(), signal);
-#endif
+
 	return FALSE;
 }
 
-- 
1.8.0.1


^ permalink raw reply related

* [PATCH BlueZ 09/11] media: Enable RegisterPlayer and UnregisterPlayer methods as experimental
From: Luiz Augusto von Dentz @ 2012-12-28 12:51 UTC (permalink / raw)
  To: linux-bluetooth
In-Reply-To: <1356699069-5469-1-git-send-email-luiz.dentz@gmail.com>

From: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>

---
 profiles/audio/media.c | 10 ++--------
 1 file changed, 2 insertions(+), 8 deletions(-)

diff --git a/profiles/audio/media.c b/profiles/audio/media.c
index f728460..e4206e3 100644
--- a/profiles/audio/media.c
+++ b/profiles/audio/media.c
@@ -868,7 +868,6 @@ static DBusMessage *unregister_endpoint(DBusConnection *conn, DBusMessage *msg,
 	return g_dbus_create_reply(msg, DBUS_TYPE_INVALID);
 }
 
-#if 0
 static struct media_player *media_adapter_find_player(
 						struct media_adapter *adapter,
 						const char *sender,
@@ -1533,7 +1532,6 @@ static DBusMessage *unregister_player(DBusConnection *conn, DBusMessage *msg,
 
 	return g_dbus_create_reply(msg, DBUS_TYPE_INVALID);
 }
-#endif
 
 static const GDBusMethodTable media_methods[] = {
 	{ GDBUS_METHOD("RegisterEndpoint",
@@ -1541,14 +1539,12 @@ static const GDBusMethodTable media_methods[] = {
 		NULL, register_endpoint) },
 	{ GDBUS_METHOD("UnregisterEndpoint",
 		GDBUS_ARGS({ "endpoint", "o" }), NULL, unregister_endpoint) },
-#if 0
-	{ GDBUS_METHOD("RegisterPlayer",
+	{ GDBUS_EXPERIMENTAL_METHOD("RegisterPlayer",
 		GDBUS_ARGS({ "player", "o" }, { "properties", "a{sv}" },
 						{ "metadata", "a{sv}" }),
 		NULL, register_player) },
-	{ GDBUS_METHOD("UnregisterPlayer",
+	{ GDBUS_EXPERIMENTAL_METHOD("UnregisterPlayer",
 		GDBUS_ARGS({ "player", "o" }), NULL, unregister_player) },
-#endif
 	{ },
 };
 
@@ -1559,10 +1555,8 @@ static void path_free(void *data)
 	while (adapter->endpoints)
 		release_endpoint(adapter->endpoints->data);
 
-#if 0
 	while (adapter->players)
 		media_player_destroy(adapter->players->data);
-#endif
 
 	adapters = g_slist_remove(adapters, adapter);
 
-- 
1.8.0.1


^ permalink raw reply related

* [PATCH BlueZ 08/11] core: Reuse --compat/-C switch for enabling deprecated interfaces
From: Luiz Augusto von Dentz @ 2012-12-28 12:51 UTC (permalink / raw)
  To: linux-bluetooth
In-Reply-To: <1356699069-5469-1-git-send-email-luiz.dentz@gmail.com>

From: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>

---
 src/main.c | 8 +++++---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/src/main.c b/src/main.c
index 2e8ba34..f6c4ee6 100644
--- a/src/main.c
+++ b/src/main.c
@@ -524,10 +524,12 @@ int main(int argc, char *argv[])
 	if (option_experimental)
 		gdbus_flags = G_DBUS_FLAG_ENABLE_EXPERIMENTAL;
 
-	g_dbus_set_flags(gdbus_flags);
-
-	if (option_compat == TRUE)
+	if (option_compat == TRUE) {
 		sdp_flags |= SDP_SERVER_COMPAT;
+		gdbus_flags |= G_DBUS_FLAG_ENABLE_DEPRECATED;
+	}
+
+	g_dbus_set_flags(gdbus_flags);
 
 	start_sdp_server(sdp_mtu, sdp_flags);
 
-- 
1.8.0.1


^ permalink raw reply related

* [PATCH BlueZ 07/11] core: Add command line switch for enabling experimental interfaces
From: Luiz Augusto von Dentz @ 2012-12-28 12:51 UTC (permalink / raw)
  To: linux-bluetooth
In-Reply-To: <1356699069-5469-1-git-send-email-luiz.dentz@gmail.com>

From: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>

This enable passing --experimental/-E to enable experimental interfaces
---
 src/main.c | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/src/main.c b/src/main.c
index 4a67e0f..2e8ba34 100644
--- a/src/main.c
+++ b/src/main.c
@@ -368,6 +368,7 @@ static gchar *option_noplugin = NULL;
 static gboolean option_compat = FALSE;
 static gboolean option_detach = TRUE;
 static gboolean option_version = FALSE;
+static gboolean option_experimental = FALSE;
 
 static void free_options(void)
 {
@@ -453,6 +454,8 @@ static GOptionEntry options[] = {
 				"Specify plugins not to load", "NAME,..." },
 	{ "compat", 'C', 0, G_OPTION_ARG_NONE, &option_compat,
 				"Provide deprecated command line interfaces" },
+	{ "experimental", 'E', 0, G_OPTION_ARG_NONE, &option_experimental,
+				"Enable experimental interfaces" },
 	{ "nodetach", 'n', G_OPTION_FLAG_REVERSE,
 				G_OPTION_ARG_NONE, &option_detach,
 				"Run with logging in foreground" },
@@ -467,6 +470,7 @@ int main(int argc, char *argv[])
 	GError *err = NULL;
 	uint16_t sdp_mtu = 0;
 	uint32_t sdp_flags = 0;
+	int gdbus_flags = 0;
 	GKeyFile *config;
 	guint signal, watchdog;
 	const char *watchdog_usec;
@@ -517,6 +521,11 @@ int main(int argc, char *argv[])
 		exit(1);
 	}
 
+	if (option_experimental)
+		gdbus_flags = G_DBUS_FLAG_ENABLE_EXPERIMENTAL;
+
+	g_dbus_set_flags(gdbus_flags);
+
 	if (option_compat == TRUE)
 		sdp_flags |= SDP_SERVER_COMPAT;
 
-- 
1.8.0.1


^ permalink raw reply related


This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.