* [PATCH 1/9] ib_srpt: Fix potential out-of-bounds array access
From: Nicholas A. Bellinger @ 2011-10-24 5:33 UTC (permalink / raw)
To: target-devel, linux-rdma
Cc: linux-scsi, Roland Dreier, Bart Van Assche, Nicholas A. Bellinger
In-Reply-To: <1319434422-15354-1-git-send-email-nab@linux-iscsi.org>
From: Bart Van Assche <bvanassche@acm.org>
This patch fixes a potential out-of-bounds array access in
srpt_map_sg_to_ib_sge(). This is bugfix port from SCST svn r3262
as recommended by Bart Van Assche for the initial ib_srpt merge.
Cc: Bart Van Assche <bvanassche@acm.org>
Cc: Roland Dreier <roland@purestorage.com>
Signed-off-by: Nicholas A. Bellinger <nab@linux-iscsi.org>
---
drivers/infiniband/ulp/srpt/ib_srpt.c | 7 ++++---
1 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/infiniband/ulp/srpt/ib_srpt.c b/drivers/infiniband/ulp/srpt/ib_srpt.c
index e412a35..383994d 100644
--- a/drivers/infiniband/ulp/srpt/ib_srpt.c
+++ b/drivers/infiniband/ulp/srpt/ib_srpt.c
@@ -1142,7 +1142,8 @@ static int srpt_map_sg_to_ib_sge(struct srpt_rdma_ch *ch,
if (ioctx->rdma_ius && ioctx->n_rdma_ius)
nrdma = ioctx->n_rdma_ius;
else {
- nrdma = count / SRPT_DEF_SG_PER_WQE + ioctx->n_rbuf;
+ nrdma = (count + SRPT_DEF_SG_PER_WQE - 1) / SRPT_DEF_SG_PER_WQE
+ + ioctx->n_rbuf;
ioctx->rdma_ius = kzalloc(nrdma * sizeof *riu, GFP_KERNEL);
if (!ioctx->rdma_ius)
@@ -1258,11 +1259,11 @@ static int srpt_map_sg_to_ib_sge(struct srpt_rdma_ch *ch,
}
++k;
- if (k == riu->sge_cnt && rsize > 0) {
+ if (k == riu->sge_cnt && rsize > 0 && tsize > 0) {
++riu;
sge = riu->sge;
k = 0;
- } else if (rsize > 0)
+ } else if (rsize > 0 && tsize > 0)
++sge;
}
}
--
1.7.2.5
^ permalink raw reply related
* [PATCH 0/9] ib_srpt: Changes from RFC for v3.2-rc1 mainline merge
From: Nicholas A. Bellinger @ 2011-10-24 5:33 UTC (permalink / raw)
To: target-devel, linux-rdma
Cc: linux-scsi, Roland Dreier, Bart Van Assche, Nicholas Bellinger
From: Nicholas Bellinger <nab-IzHhD5pYlfBP7FQvKIMDCQ@public.gmane.org>
Hi Roland, Bart & Co.
The following series are patches from the last round of discussion for
the v3.2-rc1 mainline merge of ib_srpt. This includes the removal and/or
conversion of ib_srpt module parameters into per port configfs attributes,
inclusion of two bugfix patches from the SCST tree, and some other minor
changes as requested by Bart.
This leaves srp_max_req_size, srpt_srq_size, and srpt_service_guid as
module parameters. The first two are currently required because they
are called in sprt_add_one() before the setup of individual srpt_port
endpoints, and the third apparently still needs to be global and would
not function as a per port configfs attribute.
Please have a look, and i'll be sending out a full patch again shortly
on top of target-pending.git with the other target-core patches headed
or v3.2-rc1.
Thanks,
--nab
Bart Van Assche (2):
ib_srpt: Fix potential out-of-bounds array access
ib_srpt: Avoid failed multipart RDMA transfers
Nicholas Bellinger (7):
ib_srpt: Fix srpt_alloc_fabric_acl failure case return value
ib_srpt: Update comments to reference $driver/$port layout
ib_srpt: Fix sport->port_guid formatting code
ib_srpt: Remove legacy use_port_guid_in_session_name module parameter
ib_srpt: Convert srp_max_rdma_size into per port configfs attribute
ib_srpt: Convert srp_max_rsp_size into per port configfs attribute
ib_srpt: Convert srpt_sq_size into per port configfs attribute
drivers/infiniband/ulp/srpt/ib_srpt.c | 351 +++++++++++++++++++++-----------
drivers/infiniband/ulp/srpt/ib_srpt.h | 41 ++++-
2 files changed, 267 insertions(+), 125 deletions(-)
--
1.7.2.5
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH net-next] Add ethtool -g support to virtio_net
From: Michael S. Tsirkin @ 2011-10-24 5:31 UTC (permalink / raw)
To: David Miller; +Cc: rusty, raj, netdev, virtualization
In-Reply-To: <20111023.232604.18246342474494526.davem@davemloft.net>
On Sun, Oct 23, 2011 at 11:26:04PM -0400, David Miller wrote:
> From: Rusty Russell <rusty@rustcorp.com.au>
> Date: Thu, 20 Oct 2011 18:25:24 +1030
>
> > On Wed, 19 Oct 2011 11:10:59 -0700 (PDT), raj@tardy.cup.hp.com (Rick Jones) wrote:
> >> From: Rick Jones <rick.jones2@hp.com>
> >>
> >> Add support for reporting ring sizes via ethtool -g to the virtio_net
> >> driver.
> >>
> >> Signed-off-by: Rick Jones <rick.jones2@hp.com>
> >
> > Acked-by: Rusty Russell <rusty@rustcorp.com.au>
> >
> > MST, want me to take this, or do you?
>
> I can also take it directly, just let me know.
Please do, thanks very much.
Acked-by: Michael S. Tsirkin <mst@redhat.com>
--
MST
^ permalink raw reply
* Re: [Qemu-devel] [Qemu-ppc] [PATCH] pseries: Correct vmx/dfp handling in both KVM and TCG cases
From: David Gibson @ 2011-10-24 5:29 UTC (permalink / raw)
To: Alexander Graf; +Cc: qemu-ppc@nongnu.org, qemu-devel@nongnu.org
In-Reply-To: <4CD82990-0A3D-41E4-B40D-E98607CE276A@suse.de>
On Thu, Oct 20, 2011 at 11:49:40PM -0700, Alexander Graf wrote:
>
> On 20.10.2011, at 22:06, David Gibson wrote:
>
> > On Thu, Oct 20, 2011 at 07:40:00PM -0700, Alexander Graf wrote:
> >> On 20.10.2011, at 17:41, David Gibson <david@gibson.dropbear.id.au> wrote:
> >>> On Thu, Oct 20, 2011 at 10:12:51AM -0700, Alexander Graf wrote:
> >>>> On 17.10.2011, at 21:15, David Gibson wrote:
> > [snip]
> >>> So, I really don't follow what the logic you want is. It sounds more
> >>> like what I have already, so I'm not sure how -cpu host comes into
> >>> this.
> >>
> >> Well, I want something very simple, layered:
> >>
> >> -cpu host only searches for pvr matches and selects a different CPU
> >> -type based on this
> >
> > Hrm, ok, well I can do this if you like, but note that this is quite
> > different from how -cpu host behaves on x86. There it builds the CPU
> > spec from scratch based on querying the host cpuid, rather than
> > selecting from an existing list of cpus. I selected from the existing
> > table based on host PVR because that was the easiest source for some
> > of the info in the cpu_spec, but my intention was that anything we
> > _can_ query directly from the host would override the table.
> >
> > It seems to be your approach is giving up on the possibility of
> > allowing -cpu host to work (and give you full access to the host
> > features) when qemu doesn't recognize the precise PVR of the host cpu.
>
> I disagree :). This is what x86 does:
>
> * -cpu host fetches CPUID info from host, puts it into vcpu
> * vcpu CPUID info gets ANDed with KVM capability CPUIDs
>
> I want basically the same thing. I want to have 2 different layers
> for 2 different semantics. One for what the host CPU would be able
> to do and one for what we can emulate, and two different steps to
> ensure control over them.
>
> The thing I think I'm apparently not bringing over yet is that I'm
> more than happy to get rid of the PVR searching step for -cpu host
> and instead use a full host capability inquiry mechanism. But that
> inquiry should indicate what the host CPU can do. It has nothing to
> do with KVM yet. The masking with KVM capabilities should be the
> next separate step.
>
> My goal is really to separate different layers into actual different
> layers :).
Hrm. I think I see what you're getting at. Although nothing in that
patch is about kvm capabilities - it's all about working out what the
host's cpu can do.
> > This gets further complicated in the case of the w-i-p patch I have to
> > properly advertise page sizes, where it's not just presence or absence
> > of a feature, but the specific SLB and HPTE encodings must be
> > advertised to the guest.
>
> Yup, so we'd read out the host dt to find the host possible
> encodings (probably a bad idea, but that's a different story)
Um, a different story perhaps, but one I kind of need an answer to in
the near future... I can query the host cpu's page sizes easily
enough, but I'm really not sure where this should be stashed before
filtering as suggested below.
> and
> then ask KVM what encodings it supports and expose the ANDed product
> of them to the guest.
>
> >
> >> We have 2 masks of available flags: TCG emulatable flags and KVM
> >> virtualizable flags. The KVM flags need to be generated dynamically,
> >> from the host dt for now. TCG flags are constant.
> >>
> >> Then we always AND the inst feature bits with the mask. This tells
> >> every other layer what features are available. That way even running
> >> -cpu G5 on a p7 works properly by not exposing DFP for example.
> >
> > That case was already fine.
> >
> > Are you suggesting doing the AND in the per-machine code (so, as we
> > build the guest dt in the spapr case) or when we build the env->insn_flags
> > from the spec->insn_flags?
>
> I suggest doing that in translate_init.c where we actually build the
> env->insn_flags from the spec.
Ok, that makes sense.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: [RFC v2 PATCH 5/4 PATCH] virtio-net: send gratuitous packet when needed
From: Michael S. Tsirkin @ 2011-10-24 5:25 UTC (permalink / raw)
To: Rusty Russell
Cc: aliguori, kvm, quintela, jan.kiszka, Jason Wang, qemu-devel,
blauwirbel, netdev, pbonzini
In-Reply-To: <87ty6z10f8.fsf@rustcorp.com.au>
On Mon, Oct 24, 2011 at 02:54:59PM +1030, Rusty Russell wrote:
> On Sat, 22 Oct 2011 13:43:11 +0800, Jason Wang <jasowang@redhat.com> wrote:
> > This make let virtio-net driver can send gratituous packet by a new
> > config bit - VIRTIO_NET_S_ANNOUNCE in each config update
> > interrupt. When this bit is set by backend, the driver would schedule
> > a workqueue to send gratituous packet through NETDEV_NOTIFY_PEERS.
> >
> > This feature is negotiated through bit VIRTIO_NET_F_GUEST_ANNOUNCE.
> >
> > Signed-off-by: Jason Wang <jasowang@redhat.com>
>
> This seems like a huge layering violation. Imagine this in real
> hardware, for example.
commits 06c4648d46d1b757d6b9591a86810be79818b60c
and 99606477a5888b0ead0284fecb13417b1da8e3af
document the need for this:
NETDEV_NOTIFY_PEERS notifier indicates that a device moved to a
different physical link.
and
In real hardware such notifications are only
generated when the device comes up or the address changes.
So hypervisor could get the same behaviour by sending link up/down
events, this is just an optimization so guest won't do
unecessary stuff like try to reconfigure an IP address.
Maybe LOCATION_CHANGE would be a better name?
> There may be a good reason why virtual devices might want this kind of
> reconfiguration cheat, which is unnecessary for normal machines,
I think yes, the difference with real hardware is guest can change
location without link getting dropped.
FWIW, Xen seems to use this capability too.
> but
> it'd have to be spelled out clearly in the spec to justify it...
>
> Cheers,
> Rusty.
Agree, and I'd like to see the spec too. The interface seems
to involve the guest clearing the status bit when it detects
an event?
Also - how does it interact with the link up event?
We probably don't want to schedule this when we detect
a link status change or during initialization, as
this patch seems to do? What if link goes down
while the work is running? Is that OK?
--
MST
^ permalink raw reply
* Re: Use of _hint() functions and older machines
From: Randell Jesup @ 2011-10-24 5:19 UTC (permalink / raw)
To: Clemens Ladisch; +Cc: alsa-devel, Randell Jesup
In-Reply-To: <4EA3EE43.3010904@ladisch.de>
On 10/23/2011 6:36 AM, Clemens Ladisch wrote:
> On 10/21/2011 05:28 AM, Randell Jesup wrote:
>> On older machines, _hint() aren't available, so even if I make them
>> optional to dlsym-loading, I would need some other method to get the
>> information I assume using older, now-deprecated-or-gone interfaces.
>
> On older machines, that information wasn't available at all.
>
> The recommendation was to use "default" or to let the user enter
> a device name.
Ah. Ok. Wow, was it really that painful? I didn't do a lot of Linux
media stuff back then, and generally had only built-in-audio (no USB
headsets, etc) with simple speakers.
> The best way to get a list of devices would have been to enumerate sound
> cards with snd_card_next(), then use device names "default:CARD=x".
> However, this gets only the primary device of each card, there might be
> sound cards without a PCM device, devices not based on an ALSA kernel
> driver aren't listed, and the "default:CARD=x" mechanism doesn't work if
> the user has redefined the "default" device.
Ugh. So, there's no reasonable way to get a user-understandable list
before .14? How useful was
snd_ctl_card_info_get_name()/snd_ctl_card_info()? And I guess I'd need
to enumerate the 'devices' and 'subdevices' on each card as well...
Thanks for the info, BTW
--
Randell Jesup
randell-ietf@jesup.org
^ permalink raw reply
* Re: [Qemu-devel] [RFC v2 PATCH 5/4 PATCH] virtio-net: send gratuitous packet when needed
From: Michael S. Tsirkin @ 2011-10-24 5:25 UTC (permalink / raw)
To: Rusty Russell
Cc: aliguori, kvm, quintela, jan.kiszka, Jason Wang, qemu-devel,
blauwirbel, netdev, pbonzini
In-Reply-To: <87ty6z10f8.fsf@rustcorp.com.au>
On Mon, Oct 24, 2011 at 02:54:59PM +1030, Rusty Russell wrote:
> On Sat, 22 Oct 2011 13:43:11 +0800, Jason Wang <jasowang@redhat.com> wrote:
> > This make let virtio-net driver can send gratituous packet by a new
> > config bit - VIRTIO_NET_S_ANNOUNCE in each config update
> > interrupt. When this bit is set by backend, the driver would schedule
> > a workqueue to send gratituous packet through NETDEV_NOTIFY_PEERS.
> >
> > This feature is negotiated through bit VIRTIO_NET_F_GUEST_ANNOUNCE.
> >
> > Signed-off-by: Jason Wang <jasowang@redhat.com>
>
> This seems like a huge layering violation. Imagine this in real
> hardware, for example.
commits 06c4648d46d1b757d6b9591a86810be79818b60c
and 99606477a5888b0ead0284fecb13417b1da8e3af
document the need for this:
NETDEV_NOTIFY_PEERS notifier indicates that a device moved to a
different physical link.
and
In real hardware such notifications are only
generated when the device comes up or the address changes.
So hypervisor could get the same behaviour by sending link up/down
events, this is just an optimization so guest won't do
unecessary stuff like try to reconfigure an IP address.
Maybe LOCATION_CHANGE would be a better name?
> There may be a good reason why virtual devices might want this kind of
> reconfiguration cheat, which is unnecessary for normal machines,
I think yes, the difference with real hardware is guest can change
location without link getting dropped.
FWIW, Xen seems to use this capability too.
> but
> it'd have to be spelled out clearly in the spec to justify it...
>
> Cheers,
> Rusty.
Agree, and I'd like to see the spec too. The interface seems
to involve the guest clearing the status bit when it detects
an event?
Also - how does it interact with the link up event?
We probably don't want to schedule this when we detect
a link status change or during initialization, as
this patch seems to do? What if link goes down
while the work is running? Is that OK?
--
MST
^ permalink raw reply
* [U-Boot] [PATCH] powerpc/fm: remove the TBIPA setting on platform code
From: Wolfgang Denk @ 2011-10-24 5:23 UTC (permalink / raw)
To: u-boot
In-Reply-To: <2239AC579C7D3646A720227A37E02681200AAA@039-SN1MPN1-004.039d.mgd.msft.net>
Dear Zang Roy-R61911,
In message <2239AC579C7D3646A720227A37E02681200AAA@039-SN1MPN1-004.039d.mgd.msft.net> you wrote:
>
> > Please change the Subject: so everybody understands what you are
> > doing. "powerpc/fm" is not exactly clear to everybody, and neither is
> > TBIPA.
> >
> > Nor is clear which processors / processor families / boards are
> > affected.
> Per my understand, subject is a summary of the patch. poweper/fm and TBIPA should almost be OK for the subject. I can point out that the code is about the network code in subject.
> for example, Subject:
> powerpc/fm: remove the TBIPA setting on platform network related code
No. I have not the lightest idea what FM (Frequency Modulation?) or
TBIPA might be.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
[Doctors and Bartenders], We both get the same two kinds of customers
-- the living and the dying.
-- Dr. Boyce, "The Menagerie" ("The Cage"), stardate unknown
^ permalink raw reply
* [U-Boot] [PATCH v3 03/10] spl: add option for adding post memory test to the SPL framework
From: Heiko Schocher @ 2011-10-24 5:23 UTC (permalink / raw)
To: u-boot
In-Reply-To: <4EA1615D.7010307@mvista.com>
Helllo Sergei,
Sergei Shtylyov wrote:
> Hello.
>
> On 21-10-2011 10:32, Heiko Schocher wrote:
>
>> Signed-off-by: Heiko Schocher<hs@denx.de>
>> Cc: Albert ARIBAUD<albert.u.boot@aribaud.net>
>> Cc: Sandeep Paulraj<s-paulraj@ti.com>
>> ---
>> no changes for v3
>
>> doc/README.SPL | 1 +
>> spl/Makefile | 1 +
>> 2 files changed, 2 insertions(+), 0 deletions(-)
>
>> diff --git a/doc/README.SPL b/doc/README.SPL
>> index d53ef9c..c991aab 100644
>> --- a/doc/README.SPL
>> +++ b/doc/README.SPL
>> @@ -62,3 +62,4 @@ CONFIG_SPL_FAT_SUPPORT (fs/fat/libfat.o)
>> CONFIG_SPL_LIBGENERIC_SUPPORT (lib/libgeneric.o)
>> CONFIG_SPL_POWER_SUPPORT (drivers/power/libpower.o)
>> CONFIG_SPL_NAND_SUPPORT (drivers/mtd/nand/libnand.o)
>> +(CONFIG_SPL_POST_MEM_SUPPORT (post/drivers/memory.o)
>
> Leftmost open paren shouldn't be there?
Yep, good catch, thanks!
bye,
Heiko
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
^ permalink raw reply
* [U-Boot] [PATCH v3] arm926ejs: add NXP LPC32x0 cpu series support
From: Wolfgang Denk @ 2011-10-24 5:19 UTC (permalink / raw)
To: u-boot
In-Reply-To: <4EA49D8E.2050704@mleia.com>
Dear Vladimir Zapolskiy,
In message <4EA49D8E.2050704@mleia.com> you wrote:
>
> you're right, I have a board to make support for. However I presume that >
> U-boot maintainers won't be happy to include a board with >
> CONFIG_ENV_IS_NOWHERE, and unfortunately flash driver isn't yet ready >
Why not? There are other boards with CONFIG_ENV_IS_NOWHERE :
-> grep CONFIG_ENV_IS_NOWHERE include/configs/* | wc -l
68
> I'd like to get an advice, if you think that weakly supported but >
> working U-boot on the board has chances to be included to arm-next I can >
> send the patchset right now for review, otherwise I'll spend some time >
> (one week approximately) to finish NAND driver.
Release early, release often.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Intel's new motto: United we stand. Divided we fall!
^ permalink raw reply
* Re: [PATCH v2 6/6] slub: only preallocate cpus_with_slabs if offstack
From: Andi Kleen @ 2011-10-24 5:19 UTC (permalink / raw)
To: Gilad Ben-Yossef
Cc: lkml, Peter Zijlstra, Frederic Weisbecker, Russell King, linux-mm,
Christoph Lameter, Pekka Enberg, Matt Mackall, Sasha Levin
In-Reply-To: <1319384922-29632-7-git-send-email-gilad@benyossef.com>
Gilad Ben-Yossef <gilad@benyossef.com> writes:
> We need a cpumask to track cpus with per cpu cache pages
> to know which cpu to whack during flush_all. For
> CONFIG_CPUMASK_OFFSTACK=n we allocate the mask on stack.
> For CONFIG_CPUMASK_OFFSTACK=y we don't want to call kmalloc
> on the flush_all path, so we preallocate per kmem_cache
> on cache creation and use it in flush_all.
What's the problem with calling kmalloc in flush_all?
That's a slow path anyways, isn't it?
I believe the IPI functions usually allocate anyways.
So maybe you can do that much simpler.
-Andi
--
ak@linux.intel.com -- Speaking for myself only
--
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/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* [U-Boot] [PATCH] cosmetic, post: Codingstyle cleanup
From: Heiko Schocher @ 2011-10-24 5:18 UTC (permalink / raw)
To: u-boot
In-Reply-To: <20111021223122.A45E211F9E79@gemini.denx.de>
Hello Wolfgang,
Wolfgang Denk schrieb:
> Dear Heiko Schocher,
>
> In message <1316064766-5385-1-git-send-email-hs@denx.de> you wrote:
>> + else
>> /* Use old value */
>> newword = post_word_load () & ~POST_COLDBOOT;
>> - }
> ...
>> if (bootmode == 0)
>> - {
>> /* We are booting after power-on */
>> newword |= POST_COLDBOOT;
>> - }
>
> In U-Boot we rewuire braces around multiline comments (even though
> checkpatch does not complain about this).
>
> Please fix and resubmit.
This is already fixed here:
http://patchwork.ozlabs.org/patch/119184/
and found this patch already applied to u-boot-arm, here:
http://git.denx.de/?p=u-boot/u-boot-arm.git;a=commit;h=095bd94ad54bb407459862129ad8cd23367b2a03
bye,
Heiko
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
^ permalink raw reply
* [U-Boot] [PATCH] dcache:s5p CONFIG_SYS_CACHELINE_SIZE added for s5p GONI target
From: Minkyu Kang @ 2011-10-24 5:12 UTC (permalink / raw)
To: u-boot
In-Reply-To: <CAF6FioXYCnWrTC6c-AOEsu+2JGbSHqY6jeOBd2DH-qgFfZ7Lig@mail.gmail.com>
On 10/18/2011 02:14 AM, Anton Staaf wrote:
> On Mon, Oct 17, 2011 at 4:42 AM, Lukasz Majewski <l.majewski@samsung.com> wrote:
>> Define the D-cache line size for S5PC110 GONI reference target.
>>
>> Signed-off-by: Lukasz Majewski <l.majewski@samsung.com>
>> Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
>
> Acked-by: Anton Staaf <robotboy@chromium.org>
>
>> Cc: Minkyu Kang <mk7.kang@samsung.com>
>> ---
>> include/configs/s5p_goni.h | 2 ++
>> 1 files changed, 2 insertions(+), 0 deletions(-)
>>
applied to u-boot-samsung.
Thanks
Minkyu Kang.
^ permalink raw reply
* [U-Boot] [PATCH] dcache:s5p CONFIG_SYS_CACHELINE_SIZE added for s5p UNIVERSAL C210 target
From: Minkyu Kang @ 2011-10-24 5:12 UTC (permalink / raw)
To: u-boot
In-Reply-To: <CAF6FioXFYVZM2gEe2wu=8q4qDm9c3j0Noc6ZASUKoHa6Emu-kA@mail.gmail.com>
On 10/18/2011 02:14 AM, Anton Staaf wrote:
> On Mon, Oct 17, 2011 at 4:42 AM, Lukasz Majewski <l.majewski@samsung.com> wrote:
>> Define the D-cache line size for S5PC210 UNIVERSAL reference target.
>>
>> Signed-off-by: Lukasz Majewski <l.majewski@samsung.com>
>> Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
>
> Acked-by: Anton Staaf <robotboy@chromium.org>
>
>> Cc: Minkyu Kang <mk7.kang@samsung.com>
>> ---
>> include/configs/s5pc210_universal.h | 2 ++
>> 1 files changed, 2 insertions(+), 0 deletions(-)
>>
applied to u-boot-samsung.
Thanks
Minkyu Kang.
^ permalink raw reply
* Re: [PATCH 00/22] Refactor to accept NUL in commit messages
From: Nguyen Thai Ngoc Duy @ 2011-10-24 5:10 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Jeff King, Ævar Arnfjörð
In-Reply-To: <7vy5wb3sto.fsf@alter.siamese.dyndns.org>
On Mon, Oct 24, 2011 at 3:40 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Junio C Hamano <gitster@pobox.com> writes:
>
>> Jeff King <peff@peff.net> writes:
>>
>>> But as Duy mentions, we have an encoding header. Shouldn't we treat it
>>> like binary goo until we do reencode_log_message, and _then_ we can
>>> break it into lines?
>>
>> That's sensible. If we go that route, I think the "one allocation of
>> separate struct commit_buffer pointed from a pointer field in struct
>> commit to replace the current member 'buffer'" is a reasonable thing
>> to do.
>
> Having given that "sensible" comment, I am not convinced if this is worth
> it. We are talking about what is left in the ephemeral COMMIT_EDITMSG by
> the chosen editor, but are there really editors that can _only_ write in
> UTF-16 and not in UTF-8, and is it worth bending backwards to add support
> such an editor?
This is argument for the sake of argument because I don't use utf-16
and do not care much. UTF-16 can have more code points and some may
prefer utf-16 to utf-8.
I'd be happy with git's refusing to create broken commits because
people accidentally set editor encoding to utf-16. If people do use
utf-16, they'll get caught and should yell up if they want utf-16
supported.
--
Duy
^ permalink raw reply
* Re: -next: NET_VENDOR_8390 dependencies
From: Jeff Kirsher @ 2011-10-24 5:07 UTC (permalink / raw)
To: Geert Uytterhoeven; +Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <CAMuHMdW6hC1JchxVL9-4f58a8Vg7cF+97BbKePxjEDHY3H8wNw@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2060 bytes --]
On Sun, 2011-10-23 at 14:21 -0700, Geert Uytterhoeven wrote:
> drivers/net/ethernet/8390/Kconfig:
>
> config NET_VENDOR_8390
> bool "National Semi-conductor 8390 devices"
> default y
> depends on NET_VENDOR_NATSEMI && (AMIGA_PCMCIA || PCI || SUPERH || \
> ISA || MCA || EISA || MAC || M32R || MACH_TX49XX || \
> MCA_LEGACY || H8300 || ARM || MIPS || ZORRO || PCMCIA || \
> EXPERIMENTAL)
> ---help---
> If you have a network (Ethernet) card belonging to this class, say Y
> and read the Ethernet-HOWTO, available from
> <http://www.tldp.org/docs.html#howto>.
>
> Note that the answer to this question doesn't directly affect the
> kernel: saying N will just cause the configurator to skip all
> the questions about Western Digital cards. If you say Y, you will be
> asked for your specific card in the following questions.
>
> So NET_VENDOR_8390 depends on NET_VENDOR_NATSEMI.
>
> drivers/net/ethernet/natsemi/Kconfig:
>
> config NET_VENDOR_NATSEMI
> bool "National Semi-conductor devices"
> default y
> depends on MCA || MAC || MACH_JAZZ || PCI || XTENSA_PLATFORM_XT2000
> ---help---
> If you have a network (Ethernet) card belonging to this class, say Y
> and read the Ethernet-HOWTO, available from
> <http://www.tldp.org/docs.html#howto>.
>
> Note that the answer to this question doesn't directly affect the
> kernel: saying N will just cause the configurator to skip all
> the questions about National Semi-conductor devices. If you say Y,
> you will be asked for your specific card in the following questions.
>
> But NET_VENDOR_NATSEMI will never be true for several of the other
> dependencies of NET_VENDOR_8390 (e.g. AMIGA_PCMCIA, EISA, H8300, ARM,
> ZORRO, PCMCIA)?
>
You are correct, I will put together a patch to fix that. Thanks!
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH] i2c-designware: Change readl to readw and writel to writew
From: Baruch Siach @ 2011-10-24 5:03 UTC (permalink / raw)
To: Rajeev Kumar, Shinya Kuribayashi
Cc: linux-i2c-u79uwXL29TY76Z2rM5mHXA, shiraz.hashim-qxv4g6HH51o,
viresh.kumar-qxv4g6HH51o, bhupesh.sharma-qxv4g6HH51o,
pratyush.anand-qxv4g6HH51o, vipin.kumar-qxv4g6HH51o,
deepak.sikri-qxv4g6HH51o, amit.virdi-qxv4g6HH51o,
vipulkumar.samar-qxv4g6HH51o, armando.visconti-qxv4g6HH51o
In-Reply-To: <1319430293-2624-1-git-send-email-rajeev-dlh.kumar-qxv4g6HH51o@public.gmane.org>
Hi Rajeev,
On Mon, Oct 24, 2011 at 09:54:53AM +0530, Rajeev Kumar wrote:
> Since I2C designware registers are 16 bit wide and so we should use
> readw/writew.
>
> Signed-off-by: Rajeev Kumar <rajeev-dlh.kumar-qxv4g6HH51o@public.gmane.org>
> ---
For completeness I think you should also change the width of written/read
values, e.g. ic_con, hcnt, lcnt.
I don't have hardware to test these changes though. Shinya, can you test this?
baruch
--
~. .~ Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
- baruch-NswTu9S1W3P6gbPvEgmw2w@public.gmane.org - tel: +972.2.679.5364, http://www.tkos.co.il -
^ permalink raw reply
* RE: ubifs not working with 3.1 kernel and MT29F2G08ABAEAWP NAND Flash.
From: Kumar, Goutam @ 2011-10-24 5:02 UTC (permalink / raw)
To: dedekind1@gmail.com
Cc: Angus CLARK, Ivan Djelic, linux-mtd@lists.infradead.org
In-Reply-To: <1319227591.10043.0.camel@golum>
Hi Ivan,
Are you referring MTD Tests as NAND Write and Read back test?
Regards,
Goutam
-----Original Message-----
From: Artem Bityutskiy [mailto:dedekind1@gmail.com]
Sent: Saturday, October 22, 2011 1:36 AM
To: Kumar, Goutam
Cc: Ivan Djelic; Angus CLARK; linux-mtd@lists.infradead.org
Subject: RE: ubifs not working with 3.1 kernel and MT29F2G08ABAEAWP NAND Flash.
On Thu, 2011-10-20 at 12:17 +0530, Kumar, Goutam wrote:
> Hi Ivan,
>
> Thanks for the input. Can you share the patches, which I can apply and test.
>
Even when you have all the patches, please, do not forget to validate
your flash using the mtd tests.
--
Best Regards,
Artem Bityutskiy
^ permalink raw reply
* Re: [RFD] Network configuration data in sysfs
From: David Miller @ 2011-10-24 4:59 UTC (permalink / raw)
To: kirill
Cc: kay.sievers, netdev, kuznet, jmorris, yoshfuji, kaber, gregkh,
gladkov.alexey
In-Reply-To: <20111024042400.GA31344@shutemov.name>
From: "Kirill A. Shutemov" <kirill@shutemov.name>
Date: Mon, 24 Oct 2011 07:24:00 +0300
> On Sun, Oct 23, 2011 at 11:24:16PM -0400, David Miller wrote:
>> From: "Kirill A. Shutemov" <kirill@shutemov.name>
>> Date: Mon, 24 Oct 2011 04:34:07 +0300
>>
>> You can use netlink to perform any configuration change you want, or
>> to view any network configuration setting.
>
> You need /sbin/ip or similar tool to do this, right?
I'm talking about udev using netlink natively.
^ permalink raw reply
* Re: PCIe can not rescan for new PCIe device ( FPGA board )
From: Kenji Kaneshige @ 2011-10-24 5:00 UTC (permalink / raw)
To: Abdelghani Ouchabane; +Cc: Bjorn Helgaas, linux-kernel, linux-pci
In-Reply-To: <4E98037C.4000403@ezono.com>
Hello,
I'm sorry for the long delay.
(2011/10/14 18:40), Abdelghani Ouchabane wrote:
> On 13/10/11 14:50, Kenji Kaneshige wrote:
>> Thank you for the information. Though I don't have any good news for you,
>> I think as follows based on the info.
>>
>> - There are two hot-plug capable PCIe slots on your machine.
>>
>> - But, it seems you are using fakephp driver, not pciehp (is that
>> correct?). The fakephp cannot handle hot-plug event such as presence
>> change event on the slot. This is why the bus is not scanned automatically.
>>
>> - Unfortunately, the bus would not be scanned automatically even if you
>> use pciehp. As I told you in the previous email, current pciehp don't
>> scan the bus automatically only if the slot is hot-plug surprise
>> capable. According to the lspci output, your hotplug controller is not
>> hot-plug surprise capable.
>>
>> - I don't think pciehp solve invalid register read problem. According to
>> the lspci output, power controller capability isn't present on your
>> hotplug controller. On such environment, pciehp driver does almost the
>> same thing as fakephp does (just scan the bus/remove the pci device data
>> structure) except hot-plug event handling.
>>
>> But it's worth whole trying pciehp.
>> By the way, have you tried acpiphp? It might help you.
>>
>> Regards,
>> Kenji Kaneshige
>>
>
> Hallo Kenji,
>
> many thanks for your great supports. The new BIOS from Congatec solves
> the problem.
>
> I using both fakephp& pciehp drivers, Can I use both drivers at the
> same time?
I think, "no".
> I am using fakephp because I need "/sys/bus/pci/slots/0000\:02\:00.0/power".
>
> Other thing: my Kernel has "CONFIG_ACPI_PROC_EVENT is not set", does
> this explain why the scan is not performed automatically?
Fakephp driver doesn't have any corresponding hotplug controller (hardware).
So I don't think there is no way to detect presence change event on the slot.
>
> [root@localhost ~]# modprobe acpiphp
> FATAL: Error inserting acpiphp
> (/lib/modules/2.6.40.3-0.119.delos.i686/kernel/drivers/pci/hotplug/acpiphp.ko):
> No such device
>
> What is the advantage to use acpiphp ?
Some platform only allows acpiphp, but doesn't allow PCIe native hotplug driver
(like pciehp). The 'pciehp_force' specified your environment is to load pciehp
forcibly on such platform. So I thought acpiphp might solve your problem.
Regards,
Kenji Kaneshige
>
>
> Cheers,
> Ghani
>
>
>
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pci" 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
* broadcom 43224 signal strength
From: Rafał Miłecki @ 2011-10-24 4:54 UTC (permalink / raw)
To: b43-dev
In-Reply-To: <CA+02P4YM3JTecCddRY6j4nCMRFtLmrNfPtfmzScsUoWB__uw-A@mail.gmail.com>
2011/10/24 Mat?j Gr?gr <matej.gregr@gmail.com>:
> Hello,
> ?recently, I noticed, that my wireless card 14e4:4353 should be
> supported by b43 driver. I was able to get it work with 3.1r10 kernel
> and associate with my AP (great work guys!). However, I have a serious
> problem with signal strength. If I move my laptop to another room, the
> signal is lost (I still see the signal with wl driver). When I?am
> scanning for wifi networks, I see 10 wifi networks with wl driver,
> however only 1 network with b43 driver. Is there some workaround, how
> to improve the quality of the signal?
Thanks for reporting. I think Larry experienced some problems with his
BCM43224, but I don't think he finally debugged it.
I'll plug my BCM43224/BCM43225 this week and give it some testing.
--
Rafa?
^ permalink raw reply
* [U-Boot] [PATCH v2] NS16550: buffer reads
From: Simon Glass @ 2011-10-24 4:47 UTC (permalink / raw)
To: u-boot
In-Reply-To: <CALButCKD2ucJ0ZUQJpLCP2ABYcCzO-mACa=FPWczCTVeHeoTKg@mail.gmail.com>
Hi,
On Sun, Oct 23, 2011 at 4:30 PM, Graeme Russ <graeme.russ@gmail.com> wrote:
> Hi Wolfgang,
>
> On Monday, October 24, 2011, Wolfgang Denk <wd@denx.de> wrote:
>> Dear Graeme Russ,
>>
>> In message <
> CALButCJH8BVzfVh14D83WR2JOV89O9jvJO9VzzB7r_ZgKzZqeg at mail.gmail.com> you
> wrote:
>>>
>>> > Problems happen only with multi-line input, so it is perfectly fine
>>> > to handle just that - at the root cause, i. e. when input turns into
>>> > multi-line input.
>>>
>>> Can the U-Boot command line handle multiple commands per line (delimited
> by
>>> ; for example)
>>
>> Yes, it can.
>>
>>> If so, could it not be possible that a Kermit/ymodem command followed by
> a
>>> time consuming command on the same line cause lost input?
>>
>> I don't think so. ?All serial transfers use a protocol - and when the
>> transfer is complete, it does not matter any more, because no more
>> data are flowing.
>
> My point is that the transfer turns off flow control - When the transfer
> completes, flow control will be off when the next command begins to run.
> If the next command is one which takes a long time to execute and it is on
> the same line as the transfer command (i.e. no \r to send XOFF) and the
> user types something then that input can be lost.
>
> I think the solution is fairly trivial though - During the processing of
> commands entered via readline(), cause an XOFF to be sent each time (i.e.
> immediately before) the command string is dispatched a to the command
> processor just in case the previous command called getc() (and thus caused
> an XON to be sent)
I had a go at a patch for this, will send out tomorrow. It will need
fixing up for xmodem etc. So far it works ok with minicom but not
ser2net. It is pretty simple.
I think Albert mentioned that XON/XOFF was invented in 1962. Maybe it
will come back into fashion? Not at all sure it will...
Regards,
Simon
>
> Regards,
>
> Graeme
>
> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
>
>
^ permalink raw reply
* Re: [PATCH] Move mostly read variables to __read_mostly section.
From: Andi Kleen @ 2011-10-24 4:47 UTC (permalink / raw)
To: Eial Czerwacki; +Cc: linux-kernel, Shai Fultheim (Shai@ScaleMP.com)
In-Reply-To: <4EA45BB8.20505@scalemp.com>
Eial Czerwacki <eial@scalemp.com> writes:
> * Once the number of bh's in the machine exceeds this level, we start
> --- a/kernel/time/timekeeping.c 2010-05-12 14:59:32.000000000 -0700
> +++ b/kernel/time/timekeeping.c 2010-05-24 11:56:32.000000000 -0700
> @@ -154,7 +154,7 @@ __cacheline_aligned_in_smp DEFINE_SEQLOC
> * used instead.
> */
> static struct timespec xtime __attribute__ ((aligned (16)));
> -static struct timespec wall_to_monotonic __attribute__ ((aligned (16)));
> +static struct timespec wall_to_monotonic __attribute__ ((aligned
> (16))) __read_mostly;
That means that a common time fetch/update call will usually have to fetch two
cachelines now instead of one, because it needs xtime and
wall_to_monotonic. Usually those end up nearby.
On the other hand it's rare to fetch wall_to_monotonic without xtime.
So if anything all those variables should be grouped together in a
single cacheline, but definitely not split like you do.
The other changes in your patch are fine for me.
-Andi
--
ak@linux.intel.com -- Speaking for myself only
^ permalink raw reply
* Re: [PATCH 00/22] Refactor to accept NUL in commit messages
From: Junio C Hamano @ 2011-10-24 4:40 UTC (permalink / raw)
To: git; +Cc: Jeff King, Nguyen Thai Ngoc Duy, Ævar Arnfjörð
In-Reply-To: <7v39ej5uqb.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Jeff King <peff@peff.net> writes:
>
>> But as Duy mentions, we have an encoding header. Shouldn't we treat it
>> like binary goo until we do reencode_log_message, and _then_ we can
>> break it into lines?
>
> That's sensible. If we go that route, I think the "one allocation of
> separate struct commit_buffer pointed from a pointer field in struct
> commit to replace the current member 'buffer'" is a reasonable thing
> to do.
Having given that "sensible" comment, I am not convinced if this is worth
it. We are talking about what is left in the ephemeral COMMIT_EDITMSG by
the chosen editor, but are there really editors that can _only_ write in
UTF-16 and not in UTF-8, and is it worth bending backwards to add support
such an editor?
^ permalink raw reply
* how to check kernel is configured with preemption or not
From: Greg KH @ 2011-10-24 4:38 UTC (permalink / raw)
To: kernelnewbies
In-Reply-To: <CAGpXXZK_tJVZdxu=B65uAy225Y9cCS1x8yqhJOeK7OEQEfenxA@mail.gmail.com>
On Sun, Oct 23, 2011 at 11:20:03PM -0400, Greg Freemyer wrote:
> On Sun, Oct 23, 2011 at 1:34 PM, sri <bskmohan@gmail.com> wrote:
> > No, uname did not show anything.
> > Is there any way to get the kernel preemption mode, programatically?
> >
> > Thanks,
> > --Sri
> >
> > On Fri, Oct 21, 2011 at 6:41 PM, Daniel Baluta <daniel.baluta@gmail.com>
> > wrote:
> >>
> >> On Fri, Oct 21, 2011 at 2:28 PM, sri <bskmohan@gmail.com> wrote:
> >> > Hi,
> >> >
> >> > Am using kernel 2.6.18-195(centos 5.5).
> >> > My kernel configs have CONFIG_PREEMPT_NONE=7 and
> >> > "CONFIG_PREEMPT_VOLUNTERY
> >> > is not set".
> >> > How to check that preemption is really in place?
> >> > Is there any way to check my kernel is configured with what preemption
> >> > levels?
> >>
> >> Hmm, uname -a?
> I'm sure its in /sys somewhere.
I do not think so.
> Remember /sys is part of the official ABI.
As documented in Documentation/ABI/, so perhaps you can read there.
> Also, you see what your config look like for sure by looking at
> /proc/config.gz (that file is virtual, but shows the contents of how
> your config file was at compile time for the running kernel.
Not all distros enable this :(
I think the question needs to really be stated, why, from userspace,
does it matter if preempt is enabled or not? This should never be
something that userspace cares about at all.
greg k-h
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
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.