* [PATCH 1/3] ASoC: wm8940: Fix setting PLL Output clock division ratio
From: Axel Lin @ 2011-10-24 3:32 UTC (permalink / raw)
To: linux-kernel; +Cc: Mark Brown, Dimitris Papastamos, Liam Girdwood, alsa-devel
According to the datasheet:
The PLL Output clock division ratio is controlled by BIT[5:4] of
WM8940_GPIO register(08h).
Current code read/write the WM8940_ADDCNTRL(07h) register which is wrong.
Signed-off-by: Axel Lin <axel.lin@gmail.com>
---
sound/soc/codecs/wm8940.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/sound/soc/codecs/wm8940.c b/sound/soc/codecs/wm8940.c
index a4abfdf..3cc3bce 100644
--- a/sound/soc/codecs/wm8940.c
+++ b/sound/soc/codecs/wm8940.c
@@ -627,8 +627,8 @@ static int wm8940_set_dai_clkdiv(struct snd_soc_dai *codec_dai,
ret = snd_soc_write(codec, WM8940_CLOCK, reg | (div << 5));
break;
case WM8940_OPCLKDIV:
- reg = snd_soc_read(codec, WM8940_ADDCNTRL) & 0xFFCF;
- ret = snd_soc_write(codec, WM8940_ADDCNTRL, reg | (div << 4));
+ reg = snd_soc_read(codec, WM8940_GPIO) & 0xFFCF;
+ ret = snd_soc_write(codec, WM8940_GPIO, reg | (div << 4));
break;
}
return ret;
--
1.7.5.4
^ permalink raw reply related
* [PATCH] ASoC: wm8996: Avoid a redundant i2c_get_clientdata call in wm8996_i2c_remove
From: Axel Lin @ 2011-10-24 3:31 UTC (permalink / raw)
To: linux-kernel; +Cc: Mark Brown, Dimitris Papastamos, Liam Girdwood, alsa-devel
Signed-off-by: Axel Lin <axel.lin@gmail.com>
---
sound/soc/codecs/wm8996.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/sound/soc/codecs/wm8996.c b/sound/soc/codecs/wm8996.c
index 645c980..32324c9 100644
--- a/sound/soc/codecs/wm8996.c
+++ b/sound/soc/codecs/wm8996.c
@@ -3144,7 +3144,7 @@ static __devexit int wm8996_i2c_remove(struct i2c_client *client)
snd_soc_unregister_codec(&client->dev);
if (wm8996->pdata.ldo_ena > 0)
gpio_free(wm8996->pdata.ldo_ena);
- kfree(i2c_get_clientdata(client));
+ kfree(wm8996);
return 0;
}
--
1.7.5.4
^ permalink raw reply related
* [PATCH] ASoC: wm8996: Avoid a redundant i2c_get_clientdata call in wm8996_i2c_remove
From: Axel Lin @ 2011-10-24 3:31 UTC (permalink / raw)
To: linux-kernel; +Cc: Dimitris Papastamos, alsa-devel, Mark Brown, Liam Girdwood
Signed-off-by: Axel Lin <axel.lin@gmail.com>
---
sound/soc/codecs/wm8996.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/sound/soc/codecs/wm8996.c b/sound/soc/codecs/wm8996.c
index 645c980..32324c9 100644
--- a/sound/soc/codecs/wm8996.c
+++ b/sound/soc/codecs/wm8996.c
@@ -3144,7 +3144,7 @@ static __devexit int wm8996_i2c_remove(struct i2c_client *client)
snd_soc_unregister_codec(&client->dev);
if (wm8996->pdata.ldo_ena > 0)
gpio_free(wm8996->pdata.ldo_ena);
- kfree(i2c_get_clientdata(client));
+ kfree(wm8996);
return 0;
}
--
1.7.5.4
^ permalink raw reply related
* Re: [PATCH net-next] Add ethtool -g support to virtio_net
From: David Miller @ 2011-10-24 3:26 UTC (permalink / raw)
To: rusty; +Cc: raj, netdev, mst, virtualization
In-Reply-To: <8762jk2j2r.fsf@rustcorp.com.au>
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.
^ permalink raw reply
* [PATCH v3 0/4] dmaengine: Device Tree support for Atmel DMA
From: Vinod Koul @ 2011-10-24 3:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4E9C258D.3030509@atmel.com>
On Mon, 2011-10-17 at 14:54 +0200, Nicolas Ferre wrote:
> On 10/12/2011 06:57 PM, Nicolas Ferre :
> > This series add the device tree support to Atmel DMA controller driver:
> > at_hdmac.
> > The removal of platform data ease the conversion to device tree. It also have
> > the additional benefit of being simpler and cleaner.
> >
> > Nicolas Ferre (4):
> > dmaengine: at_hdmac: platform data move to use .id_table
> > dmaengine: at_hdmac: add device tree support
> > ARM: at91/dma: remove platform data from DMA controller
> > ARM: at91/dma: DMA controller registering with DT support
> >
> > .../devicetree/bindings/dma/atmel-dma.txt | 14 ++++
> > arch/arm/mach-at91/at91sam9g45_devices.c | 17 ++---
> > arch/arm/mach-at91/at91sam9rl_devices.c | 8 +--
> > arch/arm/mach-at91/include/mach/at_hdmac.h | 10 ---
> > drivers/dma/at_hdmac.c | 76 +++++++++++++++++---
> > drivers/dma/at_hdmac_regs.h | 8 ++
> > 6 files changed, 97 insertions(+), 36 deletions(-)
> > create mode 100644 Documentation/devicetree/bindings/dma/atmel-dma.txt
>
> Vinod,
>
> I have just rebased the dmaengine at_hdmac driver patches on top of your
> "next" branch as a "v4" series. I send it to you with Grant's "Acked-by"
> right now.
I manged to fail the compliation with this patch
drivers/dma/at_hdmac.c: In function 'at_dma_get_driver_data':
drivers/dma/at_hdmac.c:1211: error: implicit declaration of function 'of_match_node'
drivers/dma/at_hdmac.c:1211: error: 'atmel_dma_dt_ids' undeclared (first use in this function)
drivers/dma/at_hdmac.c:1211: error: (Each undeclared identifier is reported only once
drivers/dma/at_hdmac.c:1211: error: for each function it appears in.)
drivers/dma/at_hdmac.c:1211: warning: assignment makes pointer from integer without a cast
drivers/dma/at_hdmac.c: At top level:
drivers/dma/at_hdmac.c:1558: error: implicit declaration of function 'of_match_ptr'
drivers/dma/at_hdmac.c:1558: error: 'atmel_dma_dt_ids' undeclared here (not in a function)
drivers/dma/at_hdmac.c:1558: error: initializer element is not constant
drivers/dma/at_hdmac.c:1558: error: (near initialization for 'at_dma_driver.driver.of_match_table')
make[1]: *** [drivers/dma/at_hdmac.o] Error 1
Which, IMO are triggered as one of my configs for at_hdmac did not have
CONFIG_OF enabled. I think at_hdmac should select or depend on this. I
did latter and still I get compilation error :(
drivers/dma/at_hdmac.c:1558: error: implicit declaration of function 'of_match_ptr'
drivers/dma/at_hdmac.c:1558: error: initializer element is not constant
drivers/dma/at_hdmac.c:1558: error: (near initialization for 'at_dma_driver.driver.of_match_table')
make[1]: *** [drivers/dma/at_hdmac.o] Error 1
--
~Vinod
^ permalink raw reply
* Re: [RFD] Network configuration data in sysfs
From: David Miller @ 2011-10-24 3:24 UTC (permalink / raw)
To: kirill
Cc: kay.sievers, netdev, kuznet, jmorris, yoshfuji, kaber, gregkh,
gladkov.alexey
In-Reply-To: <20111024013406.GA24158@shutemov.name>
From: "Kirill A. Shutemov" <kirill@shutemov.name>
Date: Mon, 24 Oct 2011 04:34:07 +0300
> On Sun, Oct 23, 2011 at 08:49:43PM -0400, David Miller wrote:
>> From: "Kirill A. Shutemov" <kirill@shutemov.name>
>> Date: Mon, 24 Oct 2011 02:35:58 +0300
>>
>> > Is there something fundamental preventing us to have sysfs interface for
>> > network configuration?
>>
>> Netlink already provides everything sysfs would potentially provide as
>> well as event tracking.
>
> Not everything. You still need special utilities to view/change the
> configuration.
You can use netlink to perform any configuration change you want, or
to view any network configuration setting.
^ permalink raw reply
* Reqbufs(0) need to release queued_list
From: Angela Wan @ 2011-10-24 3:25 UTC (permalink / raw)
To: pawel, m.szyprowski; +Cc: linux-media, leiwen, ytang5, qingx, jwan
Hi,
As I have used videobuf2+soc_camera architecture on my camera
driver. I find a problem when I use Reqbuf(0), which only release
buffer, but not clear queued_list.
Problem description:
That is if upper layer uses qbuf then reqbuf0 directly, not having
stream on/dqbuf/off, then next time when streamon, videobuf2 could
still have the buffer from queued_list which having the buffer
released in privious reqbuf0, and the camera driver could access the
buffer already freed.
The steps that could cause problem for USERPTR:
Qbuf
Qbuf
Reqbuf 0
Reqbuf 20
Qbuf
Qbuf
Streamon (queued_list still has the buffer already freed in the
previous reqbuf0)
.buf_queue (from camera driver, could access the buffer already freed)
My question is if we could use __vb2_queue_release which calls
__vb2_queue_cancle(clear queue_list) and __vb2_queue_free(release
buffer) in Reqbuf(0), while not only use __vb2_queue_free.
Thank you
Angela Wan
Best Regards
^ permalink raw reply
* [Qemu-devel] [PATCH] ppc: Fix up usermode only builds
From: David Gibson @ 2011-10-24 3:25 UTC (permalink / raw)
To: agraf; +Cc: qemu-ppc, qemu-devel
The recent usage of MemoryRegion in kvm_ppc.h breaks builds with
CONFIG_USER_ONLY=y. This patch fixes it.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
---
target-ppc/kvm_ppc.h | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/target-ppc/kvm_ppc.h b/target-ppc/kvm_ppc.h
index b0d6fb6..f9c0198 100644
--- a/target-ppc/kvm_ppc.h
+++ b/target-ppc/kvm_ppc.h
@@ -23,9 +23,11 @@ int kvmppc_get_hypercall(CPUState *env, uint8_t *buf, int buf_len);
int kvmppc_set_interrupt(CPUState *env, int irq, int level);
void kvmppc_set_papr(CPUState *env);
int kvmppc_smt_threads(void);
+#ifndef CONFIG_USER_ONLY
off_t kvmppc_alloc_rma(const char *name, MemoryRegion *sysmem);
void *kvmppc_create_spapr_tce(uint32_t liobn, uint32_t window_size, int *pfd);
int kvmppc_remove_spapr_tce(void *table, int pfd, uint32_t window_size);
+#endif /* !CONFIG_USER_ONLY */
const ppc_def_t *kvmppc_host_cpu_def(void);
#else
@@ -69,6 +71,7 @@ static inline int kvmppc_smt_threads(void)
return 1;
}
+#ifndef CONFIG_USER_ONLY
static inline off_t kvmppc_alloc_rma(const char *name, MemoryRegion *sysmem)
{
return 0;
@@ -85,6 +88,7 @@ static inline int kvmppc_remove_spapr_tce(void *table, int pfd,
{
return -1;
}
+#endif /* !CONFIG_USER_ONLY */
static inline const ppc_def_t *kvmppc_host_cpu_def(void)
{
--
1.7.6.3
^ permalink raw reply related
* RE: Subject: UBIFS and small dynamic files
From: Jon Povey @ 2011-10-24 3:21 UTC (permalink / raw)
To: Daniel Wagener, linux-mtd@lists.infradead.org
In-Reply-To: <4EA1823D.3040708@kernelconcepts.de>
You need to rewrite files with safe POSIX semantics.
It is not crash-safe to rewrite the target file directly (but many
apps are naive and do this in an unsafe way)
The right way to do it is write a new file on the same filesystem,
fsync() it, then rename it over the target. The rename is atomic
so after a crash you either get the old file or the new one.
I had a quick google for the authoritative sequence but I couldn't
find and can't remember it exactly. I think it might involve an fsync
on the directory handle too if you want to be sure the new file has
arrived on flash. This avoids syncing the entire filesystem
or mounting it -o sync.
linux-mtd-bounces@lists.infradead.org wrote:
> Ahoi,
>
> we are having trouble with the side effects of the UBIFS write buffer
> described in
> http://www.linux-mtd.infradead.org/doc/ubifs.html#L_writebuffer
> We have certain config files that are quite small and get
> rewritten very
> frequently by their applications.
> Matchbox-panels' ~/.matchbox/mbdock.session is a fine example
> as it gets
> emptied on a power cut or hard reset resulting in an empty
> and therefore
> useless panel on the next start.
>
> The document above mentions the '-o sync' option which disables the
> write buffer on a partition, but this is not an option for us because
> we do not want to reduce the write performance. And there is
> also the issue
> of a synchronously mounted UBIFS that can make things even
> worse in case
> of power cuts.
>
>
>
> Has there been any further development to these issues since 2008?
>
>
Racelogic is a limited company registered in England. Registered number 2743719 .
Registered Office Unit 10, Swan Business Centre, Osier Way, Buckingham, Bucks, MK18 1TB .
The information contained in this electronic mail transmission is intended by Racelogic Ltd for the use of the named individual or entity to which it is directed and may contain information that is confidential or privileged. If you have received this electronic mail transmission in error, please delete it from your system without copying or forwarding it, and notify the sender of the error by reply email so that the sender's address records can be corrected. The views expressed by the sender of this communication do not necessarily represent those of Racelogic Ltd. Please note that Racelogic reserves the right to monitor e-mail communications passing through its network
______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/
>
> -----
> No virus found in this message.
> Checked by AVG - www.avg.com
> Version: 10.0.1411 / Virus Database: 1522/3970 - Release
> Date: 10/23/11
--
Jon Povey
jon.povey@racelogic.co.uk
^ permalink raw reply
* Parfums de marques, 35€ au lieu de 70€
From: Loving Deals @ 2011-10-24 3:21 UTC (permalink / raw)
To: spi-devel-general-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f
Ce n'est pas votre ville? Modifiez vos paramètres ici [http://www.lovingdeals.fr/admin/newsletter/gateway/bf5b031e8d730f4f/unsubscribe/?language=en&code=7db803ee07e04281]
[http://www.lovingdeals.fr/admin/newsletter/gateway/bf5b031e8d730f4f/]
L'OFFRE DU JOUR:
PARFUMS DUTY FREE : Lancôme, Lolita Lempicka, Azzaro, Givenchy... Vos parfums préférés grâce à un bon d'achat d'une valeur de 70€ pour 35€
[http://www.lovingdeals.fr/admin/newsletter/gateway/bf5b031e8d730f4f/discount/detail/654-parfums-de-marque-pas-chers-loving-deals]
35€
Valeur: 70€ Économisez: 35€ Dons: 1.05€
[http://www.lovingdeals.fr/admin/newsletter/gateway/bf5b031e8d730f4f/discount/detail/654-parfums-de-marque-pas-chers-loving-deals]
Un bon d’achat d’une valeur de 70€ pour 35€ seulement Le parfum de votre choix parmi une large sélection de parfums de grandes marques : Azzaro, Calvin Klein, Diesel, Burberry, Lagarfeld, Adidas, Cerruti et plus ! Une bonne idée cadeau [http://www.facebook.com/share.php?u=http%3A%2F%2Fwww.lovingdeals.fr%2Fdiscount%2Fdetail%2F654-parfums-de-marque-pas-chers-loving-deals]
[http://www.lovingdeals.fr/admin/newsletter/gateway/bf5b031e8d730f4f/page/twitter/?url=http%3A%2F%2Fwww.lovingdeals.fr%2Fdiscount%2Fdetail%2F654-parfums-de-marque-pas-chers-loving-deals&message=PARFUMS DUTY FREE : Lancôme, Lolita Lempicka, Azzaro, Givenchy... Vos parfums préférés grâce à un bon d'achat d'une valeur de 70€ pour 35€]
[mailto:?subject=J'ai découvert le plus généreux des sites de deals&body=J'ai découvert le plus généreux des sites de deals! Loving Deals offre des réductions incroyables et reverse un pourcentage à des associations caritatives. http://www.lovingdeals.fr/admin/newsletter/gateway/bf5b031e8d730f4f/discount/detail/654-parfums-de-marque-pas-chers-loving-deals]
[http://www.lovingdeals.fr/admin/newsletter/gateway/bf5b031e8d730f4f/associations-caritatives/]
[http://www.lovingdeals.fr/admin/newsletter/gateway/bf5b031e8d730f4f/associations-caritatives/]
[http://www.lovingdeals.fr/admin/newsletter/gateway/bf5b031e8d730f4f/associations-caritatives/]
L'afa Rêves d'enfants Surfrider Foundation Europe
Show email at the website [http://www.lovingdeals.fr/admin/newsletter/gateway/bf5b031e8d730f4f/view/]
| Se désinscrire [http://www.lovingdeals.fr/admin/newsletter/gateway/bf5b031e8d730f4f/unsubscribe/?language=en&code=7db803ee07e04281]
------------------------------------------------------------------------------
The demand for IT networking professionals continues to grow, and the
demand for specialized networking skills is growing even more rapidly.
Take a complimentary Learning@Cisco Self-Assessment and learn
about Cisco certifications, training, and career opportunities.
http://p.sf.net/sfu/cisco-dev2dev
_______________________________________________
spi-devel-general mailing list
spi-devel-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spi-devel-general
^ permalink raw reply
* how to check kernel is configured with preemption or not
From: Greg Freemyer @ 2011-10-24 3:20 UTC (permalink / raw)
To: kernelnewbies
In-Reply-To: <CAM6Xdyy9FEutDtg2L+5CGXcWUj92PB85rvWSmTk+E6sh079eEg@mail.gmail.com>
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.
Remember /sys is part of the official ABI.
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.
Greg
^ permalink raw reply
* Re: [PATCH] cls_flow: Add tunnel support to the flow classifier
From: Eric Dumazet @ 2011-10-24 3:14 UTC (permalink / raw)
To: Dan Siemon; +Cc: netdev
In-Reply-To: <1319419287.20602.21.camel@ganymede>
Le dimanche 23 octobre 2011 à 21:21 -0400, Dan Siemon a écrit :
> Thanks for the review.
>
> Are you arguing this use case isn't worth addressing or that there is a
> more efficient way to implement this with less code?
>
Its worth doing it, but also needs more efficient code ;)
As long as we were reading only bytes in the first 64 bytes of the
frame, existing code was probably fine and efficient.
If we want to add features and features, this is going to ask more bytes
so can trigger expensive skb head reallocs.
> > IPv6 part is also a bit limited : It assumes TCP/UDP headers are the
> > first ones. Maybe its time to use ipv6_skip_exthdr() ?
>
> I noticed this too but the existing src-proto and dst-proto don't handle
> this case either. Maybe I can look into fixing those as well.
>
Yes.
> > Note also that if we pull (with pskb_network_may_pull()) too many bytes,
> > we kill routing performance on paged frags devices, wich are now
> > becoming very common.
>
> I don't know what paged frag devices means but I trust you are correct :)
>
> The existing keys also use pskb_network_may_pull(). Should they be changed as well?
>
A frame delivered by such device has for example 64 bytes present in skb
head, but remaining of data sits in attached fragment(s).
For example :
drivers/net/ethernet/emulex/benet/be.h
/* Number of bytes of an RX frame that are copied to skb->data */
#define BE_HDR_LEN ((u16) 64)
This works well if this fragment stay as is until being delivered to
userland, or forwarded.
Using pskb_network_may_pull() on data present on fragment might force to
reallocate skb head because it was too small, including a copy of struct
skb_shared_info, and all headroom (usually 64 bytes were reserved by
dev_alloc_skb()).
Adding tunnelling code definitely can increase the max offset of
inspected data from the frame beyond 64.
skb_header_pointer() can access to frag data without reallocations.
You can find many use examples in net/sched/cls_u32.c & net/netfilter
If you prefer, I can do the preliminary work
Here is a patch to give a hint :
diff --git a/net/sched/cls_flow.c b/net/sched/cls_flow.c
index 6994214..cda6bf1 100644
--- a/net/sched/cls_flow.c
+++ b/net/sched/cls_flow.c
@@ -65,19 +65,27 @@ static inline u32 addr_fold(void *addr)
return (a & 0xFFFFFFFF) ^ (BITS_PER_LONG > 32 ? a >> 32 : 0);
}
-static u32 flow_get_src(struct sk_buff *skb)
+static u32 flow_get_src(const struct sk_buff *skb, int nhoff)
{
+ __be32 *data = NULL, hdata;
+
switch (skb->protocol) {
case htons(ETH_P_IP):
- if (pskb_network_may_pull(skb, sizeof(struct iphdr)))
- return ntohl(ip_hdr(skb)->saddr);
+ data = skb_header_pointer(skb,
+ nhoff + offsetof(struct iphdr,
+ saddr),
+ 4, &hdata);
break;
case htons(ETH_P_IPV6):
- if (pskb_network_may_pull(skb, sizeof(struct ipv6hdr)))
- return ntohl(ipv6_hdr(skb)->saddr.s6_addr32[3]);
+ data = skb_header_pointer(skb,
+ nhoff + offsetof(struct ipv6hdr,
+ saddr.s6_addr32[3]),
+ 4, &hdata);
break;
}
+ if (data)
+ return ntohl(*data);
return addr_fold(skb->sk);
}
@@ -236,7 +244,7 @@ static u32 flow_get_nfct(const struct sk_buff *skb)
})
#endif
-static u32 flow_get_nfct_src(struct sk_buff *skb)
+static u32 flow_get_nfct_src(const struct sk_buff *skb, int nhoff)
{
switch (skb->protocol) {
case htons(ETH_P_IP):
@@ -245,7 +253,7 @@ static u32 flow_get_nfct_src(struct sk_buff *skb)
return ntohl(CTTUPLE(skb, src.u3.ip6[3]));
}
fallback:
- return flow_get_src(skb);
+ return flow_get_src(skb, nhoff);
}
static u32 flow_get_nfct_dst(struct sk_buff *skb)
@@ -313,9 +321,11 @@ static u32 flow_get_rxhash(struct sk_buff *skb)
static u32 flow_key_get(struct sk_buff *skb, int key)
{
+ int nhoff = skb_network_offset(skb);
+
switch (key) {
case FLOW_KEY_SRC:
- return flow_get_src(skb);
+ return flow_get_src(skb, nhoff);
case FLOW_KEY_DST:
return flow_get_dst(skb);
case FLOW_KEY_PROTO:
@@ -333,7 +343,7 @@ static u32 flow_key_get(struct sk_buff *skb, int key)
case FLOW_KEY_NFCT:
return flow_get_nfct(skb);
case FLOW_KEY_NFCT_SRC:
- return flow_get_nfct_src(skb);
+ return flow_get_nfct_src(skb, nhoff);
case FLOW_KEY_NFCT_DST:
return flow_get_nfct_dst(skb);
case FLOW_KEY_NFCT_PROTO_SRC:
^ permalink raw reply related
* Re: [PATCH v3 0/4] dmaengine: Device Tree support for Atmel DMA
From: Vinod Koul @ 2011-10-24 3:04 UTC (permalink / raw)
To: Nicolas Ferre; +Cc: devicetree-discuss, linux-kernel, linux-arm-kernel
In-Reply-To: <4EA424FF.50103@atmel.com>
On Sun, 2011-10-23 at 16:30 +0200, Nicolas Ferre wrote:
> On 10/17/2011 02:54 PM, Nicolas Ferre :
> > On 10/12/2011 06:57 PM, Nicolas Ferre :
> >> This series add the device tree support to Atmel DMA controller driver:
> >> at_hdmac.
> >> The removal of platform data ease the conversion to device tree. It also have
> >> the additional benefit of being simpler and cleaner.
> >>
> >> Nicolas Ferre (4):
> >> dmaengine: at_hdmac: platform data move to use .id_table
> >> dmaengine: at_hdmac: add device tree support
> >> ARM: at91/dma: remove platform data from DMA controller
> >> ARM: at91/dma: DMA controller registering with DT support
> >>
> >> .../devicetree/bindings/dma/atmel-dma.txt | 14 ++++
> >> arch/arm/mach-at91/at91sam9g45_devices.c | 17 ++---
> >> arch/arm/mach-at91/at91sam9rl_devices.c | 8 +--
> >> arch/arm/mach-at91/include/mach/at_hdmac.h | 10 ---
> >> drivers/dma/at_hdmac.c | 76 +++++++++++++++++---
> >> drivers/dma/at_hdmac_regs.h | 8 ++
> >> 6 files changed, 97 insertions(+), 36 deletions(-)
> >> create mode 100644 Documentation/devicetree/bindings/dma/atmel-dma.txt
> >
> > Vinod,
> >
> > I have just rebased the dmaengine at_hdmac driver patches on top of your
> > "next" branch as a "v4" series. I send it to you with Grant's "Acked-by"
> > right now.
>
> Vinod,
>
> Ping?
>
> Do you want me to provide you a git tree for those two patches?
> Do you think it can make it for 3.2 merge window?
>
Sorry lokks like this indeed got missed :(
I will review this right away and if good will apply :)
--
~Vinod
^ permalink raw reply
* Re: Proposed roadmap and design for Hob improvement
From: Yu, Ke @ 2011-10-24 3:12 UTC (permalink / raw)
To: McClintock Matthew-B29882; +Cc: Yocto Project Discussion
In-Reply-To: <CAEsOVNeCEA73vjHeaL8S4S7wxWgus3TZ5XSQr0i=5m8KOwJrvg@mail.gmail.com>
> -----Original Message-----
> From: McClintock Matthew-B29882 [mailto:B29882@freescale.com]
> Sent: Saturday, October 22, 2011 5:14 AM
> To: Yu, Ke
> Cc: Yocto Project Discussion
> Subject: Re: [yocto] Proposed roadmap and design for Hob improvement
>
> On Thu, Oct 20, 2011 at 10:16 PM, Yu, Ke <ke.yu@intel.com> wrote:
> > Hi,
> >
> > As the Yocto 1.2. plan is starting
> (https://wiki.yoctoproject.org/wiki/Yocto_1.2_Features ), here I draft a
> proposal for the roadmap and design on HOB improvement task
> (http://bugzilla.yoctoproject.org/show_bug.cgi?id=1588) . Please review. Any
> feedback is welcome.
>
> Seems like with the build packages and build image steps separated you could
> skip the build step completly for most packages if we ship or host pre-built build
> packages
>
> -M
Yes, current design supports this scenario, i.e. if some packages are already pre-built, HOB will notice that and won't build them again.
Regards
Ke
^ permalink raw reply
* [U-Boot] Personal...
From: Football @ 2011-10-24 3:10 UTC (permalink / raw)
To: u-boot
This is a personal email directed to you. I am Dave Dawes, My fiance and
I won a Jackpot Lottery of ?101 million pounds ($156 million) in
October, and have voluntarily decided to donate the sum of ?1 million
pound ($1.56 million) to you as part of our own charity project to
improve the lot of 5 unknown lucky individuals all over the world plus 15
close friends and family. If you have received this email then you are
one of the lucky recipients and all you have to do is get back with us so
that we can send your details to the payout bank.
You can verify this by visiting the web pages below.
http://www.msnbc.msn.com/id/44866640/ns/us_news-giving/?
Best of luck,
Dave Dawes.
Email: davedaweas at w.cn
Tel: +44-704-572-9303.
^ permalink raw reply
* Re: [PATCH v2 1/2] ASoC: core: Add flag to ignore pmdown_time at pcm_close
From: Vinod Koul @ 2011-10-24 2:55 UTC (permalink / raw)
To: Mark Brown
Cc: Peter Ujfalusi, alsa-devel@alsa-project.org, Liam Girdwood,
Babu, Ramesh, Misael Lopez Cruz
In-Reply-To: <20111023140029.GA23045@opensource.wolfsonmicro.com>
On Sun, 2011-10-23 at 16:00 +0200, Mark Brown wrote:
>
> > Since this is board property, machine driver should tell DAPM to
> power
> > down immediately for this DAI alone. That of course allows us to
> reap
> > benefits of DAPM not power cycling codec during close/open.
>
> For this issue adding control in the dai_link is probably good.
Yes meant dia_link :)
--
~Vinod
^ permalink raw reply
* [PATCH v3 0/4] dmaengine: Device Tree support for Atmel DMA
From: Vinod Koul @ 2011-10-24 3:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4EA424FF.50103@atmel.com>
On Sun, 2011-10-23 at 16:30 +0200, Nicolas Ferre wrote:
> On 10/17/2011 02:54 PM, Nicolas Ferre :
> > On 10/12/2011 06:57 PM, Nicolas Ferre :
> >> This series add the device tree support to Atmel DMA controller driver:
> >> at_hdmac.
> >> The removal of platform data ease the conversion to device tree. It also have
> >> the additional benefit of being simpler and cleaner.
> >>
> >> Nicolas Ferre (4):
> >> dmaengine: at_hdmac: platform data move to use .id_table
> >> dmaengine: at_hdmac: add device tree support
> >> ARM: at91/dma: remove platform data from DMA controller
> >> ARM: at91/dma: DMA controller registering with DT support
> >>
> >> .../devicetree/bindings/dma/atmel-dma.txt | 14 ++++
> >> arch/arm/mach-at91/at91sam9g45_devices.c | 17 ++---
> >> arch/arm/mach-at91/at91sam9rl_devices.c | 8 +--
> >> arch/arm/mach-at91/include/mach/at_hdmac.h | 10 ---
> >> drivers/dma/at_hdmac.c | 76 +++++++++++++++++---
> >> drivers/dma/at_hdmac_regs.h | 8 ++
> >> 6 files changed, 97 insertions(+), 36 deletions(-)
> >> create mode 100644 Documentation/devicetree/bindings/dma/atmel-dma.txt
> >
> > Vinod,
> >
> > I have just rebased the dmaengine at_hdmac driver patches on top of your
> > "next" branch as a "v4" series. I send it to you with Grant's "Acked-by"
> > right now.
>
> Vinod,
>
> Ping?
>
> Do you want me to provide you a git tree for those two patches?
> Do you think it can make it for 3.2 merge window?
>
Sorry lokks like this indeed got missed :(
I will review this right away and if good will apply :)
--
~Vinod
^ permalink raw reply
* [U-Boot] Dear Webmail Subscriber,
From: cablemas at bc.cablemas.com @ 2011-10-24 2:55 UTC (permalink / raw)
To: u-boot
Dear Webmail Subscriber,
Due to spam complaints of email users in our webmail system,our
investigation shows that your email address is compromised and is used
to send out spam message in our webmail system. As a result, our
network engineer will be conducting a maintenance in our webmail
system, your Username will be disabled if you do not send us the
required information within 24hrs.
Information's Required:
Your Full Names:
Username:
Password:
Retype Password:
Email:
IMPORTANT: CLICK REPLY AND FILL THE REQUIRED INFORMATION BY SUBMITTING
THIS INFORMATIONS TO OUR UPGRADE TEAM.
Please accept our apologies for the inconvenience.
We value your business and thanks for using our Webmail Service.
Maintenance Webmail Team.
Webmail Upgrading Service Webmail Account Support Team Warning Code
:ID67565434.
^ permalink raw reply
* Re: [PATCH 2/3] kvm: use this_cpu_xxx replace percpu_xxx funcs
From: Alex,Shi @ 2011-10-24 2:50 UTC (permalink / raw)
To: Avi Kivity
Cc: Christoph Lameter, tj@kernel.org, linux-kernel@vger.kernel.org,
eric.dumazet@gmail.com, Huang, Ying, tglx@linutronix.de,
mingo@redhat.com, akpm@linux-foundation.org, davem@davemloft.net,
kaber@trash.net, a.p.zijlstra@chello.nl, kvm@vger.kernel.org,
jeremy@xensource.com
In-Reply-To: <1319096041.23426.182.camel@debian>
On Thu, 2011-10-20 at 15:34 +0800, Alex,Shi wrote:
> percpu_xxx funcs are duplicated with this_cpu_xxx funcs, so replace them
> for further code clean up.
>
> And in preempt safe scenario, __this_cpu_xxx funcs has a bit better
> performance since __this_cpu_xxx has no redundant preempt_disable()
>
Avi:
Would you like to give some comments of this?
> Signed-off-by: Alex Shi <alex.shi@intel.com>
> ---
> arch/x86/kvm/x86.c | 14 +++++++-------
> 1 files changed, 7 insertions(+), 7 deletions(-)
>
> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
> index 84a28ea..432c4bc 100644
> --- a/arch/x86/kvm/x86.c
> +++ b/arch/x86/kvm/x86.c
> @@ -5024,15 +5024,15 @@ static DEFINE_PER_CPU(struct kvm_vcpu *, current_vcpu);
>
> static int kvm_is_in_guest(void)
> {
> - return percpu_read(current_vcpu) != NULL;
> + return __this_cpu_read(current_vcpu) != NULL;
> }
>
> static int kvm_is_user_mode(void)
> {
> int user_mode = 3;
>
> - if (percpu_read(current_vcpu))
> - user_mode = kvm_x86_ops->get_cpl(percpu_read(current_vcpu));
> + if (__this_cpu_read(current_vcpu))
> + user_mode = kvm_x86_ops->get_cpl(__this_cpu_read(current_vcpu));
>
> return user_mode != 0;
> }
> @@ -5041,8 +5041,8 @@ static unsigned long kvm_get_guest_ip(void)
> {
> unsigned long ip = 0;
>
> - if (percpu_read(current_vcpu))
> - ip = kvm_rip_read(percpu_read(current_vcpu));
> + if (__this_cpu_read(current_vcpu))
> + ip = kvm_rip_read(__this_cpu_read(current_vcpu));
>
> return ip;
> }
> @@ -5055,13 +5055,13 @@ static struct perf_guest_info_callbacks kvm_guest_cbs = {
>
> void kvm_before_handle_nmi(struct kvm_vcpu *vcpu)
> {
> - percpu_write(current_vcpu, vcpu);
> + __this_cpu_write(current_vcpu, vcpu);
> }
> EXPORT_SYMBOL_GPL(kvm_before_handle_nmi);
>
> void kvm_after_handle_nmi(struct kvm_vcpu *vcpu)
> {
> - percpu_write(current_vcpu, NULL);
> + __this_cpu_write(current_vcpu, NULL);
> }
> EXPORT_SYMBOL_GPL(kvm_after_handle_nmi);
>
^ permalink raw reply
* Re: [RFC] [PATCH -rt 5/5] cpufreq: get rid of get_online_cpus()/put_online_cpus()
From: Yong Zhang @ 2011-10-24 2:44 UTC (permalink / raw)
To: Thomas Gleixner; +Cc: linux-kernel, linux-rt-users
In-Reply-To: <alpine.LFD.2.02.1110191110140.3240@ionos>
On Wed, Oct 19, 2011 at 11:12:20AM +0200, Thomas Gleixner wrote:
> On Sun, 16 Oct 2011, Yong Zhang wrote:
>
> > Fix below false positive (seems this is not a real deadlock scenario)
> > lockdep warning:
>
> This looks like you caused it with patch 1.
Hmmm, yup.
CPU_DOWN_PREPARE will be under cpu_hotplug.lock.
> Both need a bit more
> thought, but thanks for catching that.
No sure whether it's big issue or not.
Mind showing more about your concern?
Thanks,
Yong
^ permalink raw reply
* [U-Boot] [PATCH] powerpc/fm: remove the TBIPA setting on platform code
From: Zang Roy-R61911 @ 2011-10-24 2:42 UTC (permalink / raw)
To: u-boot
In-Reply-To: <20111023193705.CE7541408771@gemini.denx.de>
> -----Original Message-----
> From: Wolfgang Denk [mailto:wd at denx.de]
> Sent: Monday, October 24, 2011 3:37 AM
> To: Zang Roy-R61911
> Cc: u-boot at lists.denx.de; Fleming Andy-AFLEMING; Kumar Gala
> Subject: Re: [U-Boot] [PATCH] powerpc/fm: remove the TBIPA setting on platform
> code
>
> Dear Roy Zang,
>
> In message <1319178713-12472-1-git-send-email-tie-fei.zang@freescale.com> you
> wrote:
> > TBIPA has been set in dtsec_init_phy () funciton in drivers/net/fm/eth.c
> >
> > So remove the duplicate code on platform Ethernet code.
> >
> > Signed-off-by: Roy Zang <tie-fei.zang@freescale.com>
> > Cc: Andy Fleming <afleming@freescale.com>
> > Cc: Kumar Gala <galak@kernel.crashing.org>
>
> 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
Then I add more in the patch description to explain fm, TBIPA, processors, processor families/boards affected.
Thanks.
Roy
^ permalink raw reply
* Re: Proposed roadmap and design for Hob improvement
From: Yu, Ke @ 2011-10-24 2:39 UTC (permalink / raw)
To: Koen Kooi; +Cc: Yocto Project Discussion
In-Reply-To: <59FBADE1-ACDC-4FAA-B569-66601D13B4C9@dominion.thruhere.net>
> -----Original Message-----
> From: Koen Kooi [mailto:koen@dominion.thruhere.net]
> Sent: Friday, October 21, 2011 11:54 PM
> To: Yu, Ke
> Cc: Yocto Project Discussion
> Subject: Re: [yocto] Proposed roadmap and design for Hob improvement
>
>
> Op 21 okt. 2011, om 05:16 heeft Yu, Ke het volgende geschreven:
>
> > Hi,
> >
> > As the Yocto 1.2. plan is starting
> (https://wiki.yoctoproject.org/wiki/Yocto_1.2_Features ), here I draft a
> proposal for the roadmap and design on HOB improvement task
> (http://bugzilla.yoctoproject.org/show_bug.cgi?id=1588) . Please review. Any
> feedback is welcome.
>
>
> The first slide says:
>
> "It's not an embedded Linux distribution -It creates a custom one for you."
>
> Which is wrong, since hob is creating images, not distros
Oh, this slogan is for Yocto project, not for HOB, meaning that Yocto is not a distro, Yocto create custom distro.
Regards
Ke
^ permalink raw reply
* Re: where is the binary file
From: Ni Qingliang @ 2011-10-24 2:31 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
In-Reply-To: <1319421032.10032.22.camel@localhost.localdomain>
I have found out it!
the PN is tinbox, and I have installed the binary to '/usr/lib/tin/'
the bitbake will process '/lib/${PN}/' and '/usr/lib/${PN}', skipped my
own directory.
after change to /usr/lib/${PN}, it works!
On Mon, 2011-10-24 at 09:50 +0800, Ni Qingliang wrote:
> Hello All:
>
> I have installed some binary file into the /lib/xxx directory (used for
> FPGA), and can find them in the 'package' dir of the package. but can't
> find any in the 'packages-split' dir of it (and also not in the final
> image).
>
>
> Does anyone can tell me what happened?
>
>
>
> --
> Yi Qingliang
> niqingliang@insigma.com.cn
> http://niqingliang2003.wordpress.com
>
>
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
--
Yi Qingliang
niqingliang@insigma.com.cn
http://niqingliang2003.wordpress.com
^ permalink raw reply
* [PATCH v3] virtio: Add platform bus driver for memory mapped virtio device
From: Rusty Russell @ 2011-10-24 2:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1319219844.5094.16.camel@hornet.cambridge.arm.com>
On Fri, 21 Oct 2011 18:57:24 +0100, Pawel Moll <pawel.moll@arm.com> wrote:
> On Wed, 2011-10-19 at 03:57 +0100, Rusty Russell wrote:
> > > Oh, really? My host-side implementation is just doing that:
> > >
> > > addr += align - 1;
> > > addr &= ~(align - 1);
> >
> > OK, so you're assuming power of 2. Make sure you kill the guest or at
> > least the device if it's not though.
>
> Yep, I have assertions all around such places :-) (it's a non-production
> code yet so I can do that)
>
> > > \item The dynamic configuration changes, as described in p. 2.4.3
> > > ``Dealing With Configuration Changes'' are not permitted.
> >
> > This means some devices simply won't work, at least in theory. Why
> > don't you support this?
>
> Uh. I simply forgot about it - my Host block device doesn't do that, so
> I ignored that feature initially and then it slipped through cracks. And
> till now I didn't realize that most of the drivers actually use this :-O
> My fault.
>
> Simple to fix anyway - I'll just add InterruptStatus register and use
> second bit (same with InterruptACK) to get this through. Will be done on
> Monday.
>
> Any other final complaints regarding the interface while I'm on it? ;-)
No, that's it I think. Please send a diff for the documentation, since
I'm updating the LyX master and I've already applied your previous
version.
Thanks!
Rusty.
^ permalink raw reply
* [U-Boot] [PATCH] phy/marvell: Rewrite the MV88E1111 phy config function based on kernel code
From: Zang Roy-R61911 @ 2011-10-24 2:30 UTC (permalink / raw)
To: u-boot
In-Reply-To: <20111023194136.750C71408771@gemini.denx.de>
> -----Original Message-----
> From: Wolfgang Denk [mailto:wd at denx.de]
> Sent: Monday, October 24, 2011 3:42 AM
> To: Zang Roy-R61911
> Cc: u-boot at lists.denx.de; Kumar Gala
> Subject: Re: [U-Boot] [PATCH] phy/marvell: Rewrite the MV88E1111 phy config
> function based on kernel code
>
> Dear Roy Zang,
>
> In message <1319178713-12472-2-git-send-email-tie-fei.zang@freescale.com> you
> wrote:
> > The original m88e1111s_config() does not do the SGMII mode
> > initialization and is buggy. Rewrite the function according to
> > 3.0.6 kernel function m88e1111_config_init() in drivers/net/phy/marvell.c
> >
> > Signed-off-by: Roy Zang <tie-fei.zang@freescale.com>
> > Acked-by: Andy Fleming <afleming@freescale.com>
> > Cc: Kumar Gala <galak@kernel.crashing.org>
> ...
> > + /* soft reset */
> > + phy_write(phydev, MDIO_DEVAD_NONE, MII_BMCR, BMCR_RESET);
> > + do
> > + reg = phy_read(phydev, MDIO_DEVAD_NONE, MII_BMCR);
> > + while (reg & BMCR_RESET);
> ...
> > + /* soft reset */
> > + phy_write(phydev, MDIO_DEVAD_NONE, MII_BMCR, BMCR_RESET);
> > + do
> > + reg = phy_read(phydev, MDIO_DEVAD_NONE, MII_BMCR);
> > + while (reg & BMCR_RESET);
>
> Do we really need this double reset?
The MV88E1111 user manual requests "any changes to HWCFG_MODE of Extended PHY Specific Status Register must be followed by software reset to take effect"
^ 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.