[PATCHv2] pwm_backlight: pass correct brightness to callback
pwm_backlight_update_status calls the notify() and notify_after()
callbacks before and after applying the new PWM settings. However, if
brightness levels are used, the brightness value will be changed from
the index into the levels array to the PWM duty cycle length before
being passed to notify_after(), which results in inconsistent behavior.
Signed-off-by: Alexandre Courbot
---
drivers/video/backlight/pwm_bl.c | 11 +++
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/drivers/video/backlight/pwm_bl.c b/drivers/video/backlight/pwm_bl.c
index 057389d..6d1d3ea 100644
--- a/drivers/video/backlight/pwm_bl.c
+++ b/drivers/video/backlight/pwm_bl.c
@@ -39,6 +39,7 @@ static int pwm_backlight_update_status(struct
backlight_device *bl)
{
struct pwm_bl_data *pb = dev_get_drvdata(>dev);
int brightness = bl->props.brightness;
+ int pwm_brightness;
int max = bl->props.max_brightness;
if (bl->props.power != FB_BLANK_UNBLANK)
@@ -55,13 +56,15 @@ static int pwm_backlight_update_status(struct
backlight_device *bl)
pwm_disable(pb->pwm);
} else {
if (pb->levels) {
- brightness = pb->levels[brightness];
+ pwm_brightness = pb->levels[brightness];
max = pb->levels[max];
+ } else {
+ pwm_brightness = brightness;
}
- brightness = pb->lth_brightness +
- (brightness * (pb->period - pb->lth_brightness) / max);
- pwm_config(pb->pwm, brightness, pb->period);
+ pwm_brightness = pb->lth_brightness +
+(pwm_brightness * (pb->period - pb->lth_brightness) / max);
+ pwm_config(pb->pwm, pwm_brightness, pb->period);
pwm_enable(pb->pwm);
}
--
1.7.11.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [net-next RFC V5 0/5] Multiqueue virtio-net
On 07/08/2012 04:19 PM, Ronen Hod wrote:
On 07/05/2012 01:29 PM, Jason Wang wrote:
Hello All:
This series is an update version of multiqueue virtio-net driver
based on
Krishna Kumar's work to let virtio-net use multiple rx/tx queues to
do the
packets reception and transmission. Please review and comments.
Test Environment:
- Intel(R) Xeon(R) CPU E5620 @ 2.40GHz, 8 cores 2 numa nodes
- Two directed connected 82599
Test Summary:
- Highlights: huge improvements on TCP_RR test
Hi Jason,
It might be that the good TCP_RR results are due to the large number
of sessions (50-250). Can you test it also with small number of sessions?
Sure, I would test them.
- Lowlights: regression on small packet transmission, higher cpu
utilization
than single queue, need further optimization
Analysis of the performance result:
- I count the number of packets sending/receiving during the test, and
multiqueue show much more ability in terms of packets per second.
- For the tx regression, multiqueue send about 1-2 times of more packets
compared to single queue, and the packets size were much smaller
than single
queue does. I suspect tcp does less batching in multiqueue, so I
hack the
tcp_write_xmit() to forece more batching, multiqueue works as well as
singlequeue for both small transmission and throughput
Could it be that since the CPUs are not busy they are available for
immediate handling of the packets (little batching)? In such scenario
the CPU utilization is not really interesting. What will happen on a
busy machine?
The regression happnes when test guest transmission in stream test, the
cpu utilization is 100% in this situation.
Ronen.
- I didn't pack the accelerate RFS with virtio-net in this sereis as
it still
need further shaping, for the one that interested in this please see:
http://www.mail-archive.com/kvm@vger.kernel.org/msg64111.html
Changes from V4:
- Add ability to negotiate the number of queues through control
virtqueue
- Ethtool -{L|l} support and default the tx/rx queue number to 1
- Expose the API to set irq affinity instead of irq itself
Changes from V3:
- Rebase to the net-next
- Let queue 2 to be the control virtqueue to obey the spec
- Prodives irq affinity
- Choose txq based on processor id
References:
- V4: https://lkml.org/lkml/2012/6/25/120
- V3: http://lwn.net/Articles/467283/
Test result:
1) 1 vm 2 vcpu 1q vs 2q, 1 - 1q, 2 - 2q, no pinning
- Guest to External Host TCP STREAM
sessions size throughput1 throughput2 norm1 norm2
1 64 650.55 655.61 100% 24.88 24.86 99%
2 64 1446.81 1309.44 90% 30.49 27.16 89%
4 64 1430.52 1305.59 91% 30.78 26.80 87%
8 64 1450.89 1270.82 87% 30.83 25.95 84%
1 256 1699.45 1779.58 104% 56.75 59.08 104%
2 256 4902.71 3446.59 70% 98.53 62.78 63%
4 256 4803.76 2980.76 62% 97.44 54.68 56%
8 256 5128.88 3158.74 61% 104.68 58.61 55%
1 512 2837.98 2838.42 100% 89.76 90.41 100%
2 512 6742.59 5495.83 81% 155.03 99.07 63%
4 512 9193.70 5900.17 64% 202.84 106.44 52%
8 512 9287.51 7107.79 76% 202.18 129.08 63%
1 1024 4166.42 4224.98 101% 128.55 129.86 101%
2 1024 6196.94 7823.08 126% 181.80 168.81 92%
4 1024 9113.62 9219.49 101% 235.15 190.93 81%
8 1024 9324.25 9402.66 100% 239.10 179.99 75%
1 2048 7441.63 6534.04 87% 248.01 215.63 86%
2 2048 7024.61 7414.90 105% 225.79 219.62 97%
4 2048 8971.49 9269.00 103% 278.94 220.84 79%
8 2048 9314.20 9359.96 100% 268.36 192.23 71%
1 4096 8282.60 8990.08 108% 277.45 320.05 115%
2 4096 9194.80 9293.78 101% 317.02 248.76 78%
4 4096 9340.73 9313.19 99% 300.34 230.35 76%
8 4096 9148.23 9347.95 102% 279.49 199.43 71%
1 16384 8787.89 8766.31 99% 312.38 316.53 101%
2 16384 9306.35 9156.14 98% 319.53 279.83 87%
4 16384 9177.81 9307.50 101% 312.69 230.07 73%
8 16384 9035.82 9188.00 101% 298.32 199.17 66%
- TCP RR
sessions size throughput1 throughput2 norm1 norm2
50 1 54695.41 84164.98 153% 1957.33 1901.31 97%
100 1 60141.88 88598.94 147% 2157.90 2000.45 92%
250 1 74763.56 135584.22 181% 2541.94 2628.59 103%
50 64 51628.38 82867.50 160% 1872.55 1812.16 96%
100 64 60367.73 84080.60 139% 2215.69 1867.69 84%
250 64 68502.70 124910.59 182% 2321.43 2495.76 107%
50 128 53477.08 77625.07 145% 1905.10 1870.99 98%
100 128 59697.56 74902.37 125% 2230.66 1751.03 78%
250 128 71248.74 133963.55 188% 2453.12 2711.72 110%
50 256 47663.86 67742.63 142% 1880.45 1735.30 92%
100 256 54051.84 68738.57 127% 2123.03 1778.59 83%
250 256 68250.06 124487.90 182% 2321.89 2598.60 111%
- External Host to Guest TCP STRAM
sessions size throughput1 throughput2 norm1 norm2
1 64 847.71 864.83 102% 57.99 57.93 99%
2 64 1690.82 1544.94 91% 80.13 55.09 68%
4 64 3434.98 3455.53 100% 127.17 89.00 69%
8 64 5890.19 6557.35 111% 194.70 146.52 75%
1 256 2094.04 2109.14 100% 130.73 127.14 97%
2 256 5218.13 3731.97 71% 219.15 114.02 52%
4 256 6734.51 9213.47 136% 227.87 208.31 91%
8 256 6452.86 9402.78 145% 224.83 207.77 92%
1 512 3945.07 4203.68 106% 279.72 273.30 97%
2 512 7878.96 8122.55 103% 278.25 231.71
Re: [PATCH 6/7] memcg: add per cgroup writeback pages accounting
On Mon, Jul 09, 2012 at 01:22:54PM +0800, Sha Zhengju wrote:
> On 07/09/2012 12:18 PM, Kamezawa Hiroyuki wrote:
> >(2012/07/09 13:14), Fengguang Wu wrote:
> >>On Mon, Jul 09, 2012 at 11:36:11AM +0800, Sha Zhengju wrote:
> >>>On 07/08/2012 10:53 PM, Fengguang Wu wrote:
> >@@ -2245,7 +2252,10 @@ int test_set_page_writeback(struct page *page)
> > {
> > struct address_space *mapping = page_mapping(page);
> > int ret;
> >+bool locked;
> >+unsigned long flags;
> >
> >+mem_cgroup_begin_update_page_stat(page,,);
> > if (mapping) {
> > struct backing_dev_info *bdi = mapping->backing_dev_info;
> > unsigned long flags;
> >@@ -2272,6 +2282,8 @@ int test_set_page_writeback(struct page *page)
> > }
> > if (!ret)
> > account_page_writeback(page);
> >+
> >+mem_cgroup_end_update_page_stat(page,,);
> > return ret;
> >
> > }
> Where is the MEM_CGROUP_STAT_FILE_WRITEBACK increased?
>
> >>>
> >>>It's in account_page_writeback().
> >>>
> >>> void account_page_writeback(struct page *page)
> >>> {
> >>>+mem_cgroup_inc_page_stat(page, MEM_CGROUP_STAT_FILE_WRITEBACK);
> >>> inc_zone_page_state(page, NR_WRITEBACK);
> >>> }
> >>
> >>I didn't find that chunk, perhaps it's lost due to rebase..
> >>
> >>>There isn't a unified interface to dec/inc writeback accounting, so
> >>>I just follow that.
> >>>Maybe we can rework account_page_writeback() to also account
> >>>dec in?
> >>
> >>The current seperate inc/dec paths are fine. It sounds like
> >>over-engineering if going any further.
> >>
> >>I'm a bit worried about some 3rd party kernel module to call
> >>account_page_writeback() without
> >>mem_cgroup_begin/end_update_page_stat().
> >>Will that lead to serious locking issues, or merely inaccurate
> >>accounting?
> >>
> >
> >Ah, Hm. Maybe it's better to add some debug check in
> > mem_cgroup_update_page_stat(). rcu_read_lock_held() or some.
> >
>
> This also apply to account_page_dirtied()... But as an "range" lock,
> I think it's common
> in current kernel: just as set_page_dirty(), the caller should call
> it under the page lock
> (in most cases) and it's his responsibility to guarantee
> correctness. I can add some
> comments or debug check as reminding but I think i can only do so...
Yeah, it helps to add some brief comment on the locking rule in
account_page_*().
Thanks,
Fengguang
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 6/7] memcg: add per cgroup writeback pages accounting
> >>>Where is the MEM_CGROUP_STAT_FILE_WRITEBACK increased?
> >>>
> >>It's in account_page_writeback().
> >>
> >> void account_page_writeback(struct page *page)
> >> {
> >>+ mem_cgroup_inc_page_stat(page, MEM_CGROUP_STAT_FILE_WRITEBACK);
> >>inc_zone_page_state(page, NR_WRITEBACK);
> >> }
> >I didn't find that chunk, perhaps it's lost due to rebase..
>
> Ah? a bit weird... you can refer to the link
> http://thread.gmane.org/gmane.linux.kernel.cgroups/3134
> which is an integral one. Thanks!
Ah I got it. Sorry I overlooked it..and the new view does help make it
obvious ;)
Thanks,
Fengguang
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] pwm_backlight: pass correct brightness to callback
On 07/09/2012 02:10 PM, Thierry Reding wrote: I had to actually read this patch a number of times and then realized I was completely missing the context. Looking at the whole function makes it more obvious what you mean. However I think it'd be much clearer if we just passed the value of bl->props.brightness into the callbacks, that way we can avoid the additional variable. This won't work I'm afraid, as brightness can be modified prior to being passed to the callback function: if (bl->props.power != FB_BLANK_UNBLANK) brightness = 0; if (bl->props.fb_blank != FB_BLANK_UNBLANK) brightness = 0; if (pb->notify) brightness = pb->notify(pb->dev, brightness); Alex. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 6/7] memcg: add per cgroup writeback pages accounting
On 07/09/2012 12:18 PM, Kamezawa Hiroyuki wrote:
(2012/07/09 13:14), Fengguang Wu wrote:
On Mon, Jul 09, 2012 at 11:36:11AM +0800, Sha Zhengju wrote:
On 07/08/2012 10:53 PM, Fengguang Wu wrote:
@@ -2245,7 +2252,10 @@ int test_set_page_writeback(struct page *page)
{
struct address_space *mapping = page_mapping(page);
int ret;
+bool locked;
+unsigned long flags;
+mem_cgroup_begin_update_page_stat(page,,);
if (mapping) {
struct backing_dev_info *bdi = mapping->backing_dev_info;
unsigned long flags;
@@ -2272,6 +2282,8 @@ int test_set_page_writeback(struct page *page)
}
if (!ret)
account_page_writeback(page);
+
+mem_cgroup_end_update_page_stat(page,,);
return ret;
}
Where is the MEM_CGROUP_STAT_FILE_WRITEBACK increased?
It's in account_page_writeback().
void account_page_writeback(struct page *page)
{
+mem_cgroup_inc_page_stat(page, MEM_CGROUP_STAT_FILE_WRITEBACK);
inc_zone_page_state(page, NR_WRITEBACK);
}
I didn't find that chunk, perhaps it's lost due to rebase..
There isn't a unified interface to dec/inc writeback accounting, so
I just follow that.
Maybe we can rework account_page_writeback() to also account
dec in?
The current seperate inc/dec paths are fine. It sounds like
over-engineering if going any further.
I'm a bit worried about some 3rd party kernel module to call
account_page_writeback() without
mem_cgroup_begin/end_update_page_stat().
Will that lead to serious locking issues, or merely inaccurate
accounting?
Ah, Hm. Maybe it's better to add some debug check in
mem_cgroup_update_page_stat(). rcu_read_lock_held() or some.
This also apply to account_page_dirtied()... But as an "range" lock, I
think it's common
in current kernel: just as set_page_dirty(), the caller should call it
under the page lock
(in most cases) and it's his responsibility to guarantee correctness. I
can add some
comments or debug check as reminding but I think i can only do so...
Thanks,
Sha
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH] pwm-backlight: add regulator and GPIO support
> -Original Message- > From: linux-fbdev-ow...@vger.kernel.org > [mailto:linux-fbdev-ow...@vger.kernel.org] On Behalf Of Stephen > Warren > Sent: Friday, July 06, 2012 1:04 AM > To: Alex Courbot > Cc: Thierry Reding; Sascha Hauer; Mark Brown; linux-te...@vger.kernel.org; > linux-kernel@vger.kernel.org; > linux-fb...@vger.kernel.org > Subject: Re: [PATCH] pwm-backlight: add regulator and GPIO support > > On 07/05/2012 02:12 AM, Alex Courbot wrote: > > On 07/05/2012 04:57 PM, Thierry Reding wrote: > >> I agree. Non-DT platforms have always used the callbacks to execute this > >> kind of code. As you've said before there are situations where it isn't > >> just about setting a GPIO or enabling a regulator but it also requires a > >> specific timing. Representing this in the platform data would become > >> tedious. > > > > That will settle the whole issue then. > > > >> So I think for the DT case you can parse the power-on and power-off > >> sequences directly and execute code based on it, while in non-DT cases > >> the init and exit callbacks should be used instead. I think it even > >> makes sense to reuse the platform data's init and exit functions in the > >> DT case and implement the parser/interpreter within those. > > > > It totally makes sense indeed. > > I don't agree here. It'd be best if non-DT and DT cases worked as > similarly as possible. Relying on callbacks in one case and > data-parsed-from-DT in the other isn't consistent with that. After all, > in the DT case, you parse some data out of the DT and into some data > structure. In the non-DT case, you can have that data structure passed > in directly using platform data. Now, there's certainly a need to > continue to support callbacks for backwards compatibility, at the very > least temporarily before all clients are converted to the new model, but > requiring different models rather than simply allowing it seems like a > bad idea to me. Hi Alex Courbot, I couldn't agree with Stephen Warren more. Could you support DT and non-DT case for backwards compatibility? Best regards, Jingoo Han > > > -- > To unsubscribe from this list: send the line "unsubscribe linux-fbdev" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: boot failure in next-20120705 and 20120706
On Mon, 2012-07-09 at 14:49 +1000, Stephen Rothwell wrote: > Hi all, > > Boot testing next-20120705 and 20120706 one of my PowerPC machines get this > BUG: > > (this one just after the console login prompt appeared.) I'll have a look tomorrow. Make sure you keep the .config & machine at hand :-) Any chance you can check with just powerpc-next ? Cheers, Ben. > kernel BUG at arch/powerpc/kernel/irq.c:188! > Oops: Exception in kernel mode, sig: 5 [#1] > SMP NR_CPUS=32 NUMA pSeries > Modules linked in: binfmt_misc dm_mirror dm_region_hash dm_log ibmveth > NIP: c000f7d4 LR: c000f838 CTR: c07222a0 > REGS: c0d17a30 TRAP: 0700 Not tainted (3.5.0-rc5-autokern1) > MSR: 80021032 CR: 2448 XER: > SOFTE: 0 > TASK = c0c41a10[0] 'swapper/0' THREAD: c0d14000 CPU: 0 > GPR00: 0001 c0d17cb0 c0d12d10 0500 > GPR04: > GPR08: 001752557ab9dd5b c7ffb000 c0bf5200 > GPR12: c7ffb000 02b0 009d7000 > GPR16: 00d454f0 027dc6f0 01b5f994 0060 > GPR20: 80009032 > GPR24: c0d14000 c0d30290 c0d30178 c0d30290 > GPR28: c08a6180 0008 c0c7e130 0001 > NIP [c000f7d4] .__check_irq_replay+0xc4/0xf0 > LR [c000f838] .arch_local_irq_restore+0x38/0x90 > Call Trace: > [c0d17cb0] [c0d17d30] init_thread_union+0x3d30/0x4000 > (unreliable) > [c0d17d40] [c000f838] .arch_local_irq_restore+0x38/0x90 > [c0d17db0] [c0015c60] .cpu_idle+0x230/0x2b0 > [c0d17e70] [c000b3f8] .rest_init+0x88/0xa0 > [c0d17ef0] [c0b86c0c] .start_kernel+0x478/0x498 > [c0d17f90] [c00096f8] .start_here_common+0x20/0x28 > Instruction dump: > 4e800020 7da96b78 7beaf7e3 880901f3 38600500 5400e87e 5400183e 980901f3 > 4082ffcc 880d01f3 7cd0 78000fe0 <0b00> 3860 4bb4 38610070 > > This is: > BUG_ON(local_paca->irq_happened != 0); > in __check_irq_replay(). > > This only happens on my Power5+ machine. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 6/7] memcg: add per cgroup writeback pages accounting
On 07/09/2012 12:14 PM, Fengguang Wu wrote:
On Mon, Jul 09, 2012 at 11:36:11AM +0800, Sha Zhengju wrote:
On 07/08/2012 10:53 PM, Fengguang Wu wrote:
@@ -2245,7 +2252,10 @@ int test_set_page_writeback(struct page *page)
{
struct address_space *mapping = page_mapping(page);
int ret;
+ bool locked;
+ unsigned long flags;
+ mem_cgroup_begin_update_page_stat(page,,);
if (mapping) {
struct backing_dev_info *bdi = mapping->backing_dev_info;
unsigned long flags;
@@ -2272,6 +2282,8 @@ int test_set_page_writeback(struct page *page)
}
if (!ret)
account_page_writeback(page);
+
+ mem_cgroup_end_update_page_stat(page,,);
return ret;
}
Where is the MEM_CGROUP_STAT_FILE_WRITEBACK increased?
It's in account_page_writeback().
void account_page_writeback(struct page *page)
{
+ mem_cgroup_inc_page_stat(page, MEM_CGROUP_STAT_FILE_WRITEBACK);
inc_zone_page_state(page, NR_WRITEBACK);
}
I didn't find that chunk, perhaps it's lost due to rebase..
Ah? a bit weird... you can refer to the link
http://thread.gmane.org/gmane.linux.kernel.cgroups/3134
which is an integral one. Thanks!
There isn't a unified interface to dec/inc writeback accounting, so
I just follow that.
Maybe we can rework account_page_writeback() to also account
dec in?
The current seperate inc/dec paths are fine. It sounds like
over-engineering if going any further.
I'm a bit worried about some 3rd party kernel module to call
account_page_writeback() without mem_cgroup_begin/end_update_page_stat().
Will that lead to serious locking issues, or merely inaccurate
accounting?
Thanks,
Fengguang
--
To unsubscribe from this list: send the line "unsubscribe cgroups" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH] pwm_backlight: pass correct brightness to callback
On Monday, July 09, 2012 1:22 PM, Alexandre Courbot wrote:
> pwm_backlight_update_status calls two callbacks before and after
> applying the new PWM settings. However, the brightness scale is
> completely changed in between if brightness levels are used. This patch
> ensures that both callbacks are passed brightness values of the same
> meaning.
>
> Signed-off-by: Alexandre Courbot
> ---
> drivers/video/backlight/pwm_bl.c | 12 +++-
> 1 file changed, 7 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/video/backlight/pwm_bl.c
> b/drivers/video/backlight/pwm_bl.c
> index 057389d..dd4d24d 100644
> --- a/drivers/video/backlight/pwm_bl.c
> +++ b/drivers/video/backlight/pwm_bl.c
> @@ -39,6 +39,7 @@ static int pwm_backlight_update_status(struct
> backlight_device *bl)
> {
> struct pwm_bl_data *pb = dev_get_drvdata(>dev);
> int brightness = bl->props.brightness;
> + int pwm_brightness;
> int max = bl->props.max_brightness;
>
> if (bl->props.power != FB_BLANK_UNBLANK)
> @@ -55,13 +56,14 @@ static int pwm_backlight_update_status(struct
> backlight_device *bl)
> pwm_disable(pb->pwm);
> } else {
> if (pb->levels) {
> - brightness = pb->levels[brightness];
> + pwm_brightness = pb->levels[brightness];
> max = pb->levels[max];
> - }
> + } else
> + pwm_brightness = brightness;
Hi Alexandre Courbot,
Please, use braces to keep the Coding Style.
Refer to Documentation/CodingStyle as follow:
169 This does not apply if only one branch of a conditional statement is a
single
170 statement; in the latter case use braces in both branches:
171
172 if (condition) {
173 do_this();
174 do_that();
175 } else {
176 otherwise();
177 }
Best regards,
Jingoo Han
>
> - brightness = pb->lth_brightness +
> - (brightness * (pb->period - pb->lth_brightness) / max);
> - pwm_config(pb->pwm, brightness, pb->period);
> + pwm_brightness = pb->lth_brightness +
> + (pwm_brightness * (pb->period - pb->lth_brightness) / max);
> + pwm_config(pb->pwm, pwm_brightness, pb->period);
> pwm_enable(pb->pwm);
> }
>
> --
> 1.7.11.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-fbdev" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] mm/memcg: return -EBUSY when oom-kill-disable modified and memcg use_hierarchy, has children
On Mon, Jul 09, 2012 at 01:43:23PM +0900, Kamezawa Hiroyuki wrote:
>(2012/07/05 19:55), Wanpeng Li wrote:
>> From: Wanpeng Li
>>
>> When oom-kill-disable modified by the user and current memcg use_hierarchy,
>> the change can occur, provided the current memcg has no children. If it
>> has children, return -EBUSY is enough.
>>
>> Signed-off-by: Wanpeng Li
>
>I'm sorry what is the point ? You think -EBUSY should be returned in this case
>rather than -EINVAl ? Then, why ?
just like in function cmem_cgroup_hierarchy_write:
if((!parent_memcg || !parent_memcg->use_hierarchy) &&
(val == 1 || val == 0) {
if (list_empty(>children))
memcg->use_hierarchy = val;
else
return -EBUSY;
} else
return = -EINVAL;
If memcg->use_hierarchy && has children memcg, the user can try again
if children memcg disappear. Or I miss something
Regards,
Wanpeng Li
>
>
>> ---
>> mm/memcontrol.c |7 +--
>> 1 files changed, 5 insertions(+), 2 deletions(-)
>>
>> diff --git a/mm/memcontrol.c b/mm/memcontrol.c
>> index 63e36e7..4b64fe0 100644
>> --- a/mm/memcontrol.c
>> +++ b/mm/memcontrol.c
>> @@ -4521,11 +4521,14 @@ static int mem_cgroup_oom_control_write(struct
>> cgroup *cgrp,
>>
>> cgroup_lock();
>> /* oom-kill-disable is a flag for subhierarchy. */
>> -if ((parent->use_hierarchy) ||
>> -(memcg->use_hierarchy && !list_empty(>children))) {
>> +if (parent->use_hierarchy) {
>> cgroup_unlock();
>> return -EINVAL;
>> +} else if (memcg->use_hierarchy && !list_empty(>children)) {
>> +cgroup_unlock();
>> +return -EBUSY;
>> }
>> +
>> memcg->oom_kill_disable = val;
>> if (!val)
>> memcg_oom_recover(memcg);
>>
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] pwm_backlight: pass correct brightness to callback
On Mon, Jul 09, 2012 at 01:21:40PM +0900, Alexandre Courbot wrote:
> pwm_backlight_update_status calls two callbacks before and after
> applying the new PWM settings. However, the brightness scale is
> completely changed in between if brightness levels are used. This patch
> ensures that both callbacks are passed brightness values of the same
> meaning.
>
> Signed-off-by: Alexandre Courbot
> ---
> drivers/video/backlight/pwm_bl.c | 12 +++-
> 1 file changed, 7 insertions(+), 5 deletions(-)
I had to actually read this patch a number of times and then realized I
was completely missing the context. Looking at the whole function makes
it more obvious what you mean.
However I think it'd be much clearer if we just passed the value of
bl->props.brightness into the callbacks, that way we can avoid the
additional variable.
Thierry
>
> diff --git a/drivers/video/backlight/pwm_bl.c
> b/drivers/video/backlight/pwm_bl.c
> index 057389d..dd4d24d 100644
> --- a/drivers/video/backlight/pwm_bl.c
> +++ b/drivers/video/backlight/pwm_bl.c
> @@ -39,6 +39,7 @@ static int pwm_backlight_update_status(struct
> backlight_device *bl)
> {
> struct pwm_bl_data *pb = dev_get_drvdata(>dev);
> int brightness = bl->props.brightness;
> + int pwm_brightness;
> int max = bl->props.max_brightness;
>
> if (bl->props.power != FB_BLANK_UNBLANK)
> @@ -55,13 +56,14 @@ static int pwm_backlight_update_status(struct
> backlight_device *bl)
> pwm_disable(pb->pwm);
> } else {
> if (pb->levels) {
> - brightness = pb->levels[brightness];
> + pwm_brightness = pb->levels[brightness];
> max = pb->levels[max];
> - }
> + } else
> + pwm_brightness = brightness;
>
> - brightness = pb->lth_brightness +
> - (brightness * (pb->period - pb->lth_brightness) / max);
> - pwm_config(pb->pwm, brightness, pb->period);
> + pwm_brightness = pb->lth_brightness +
> + (pwm_brightness * (pb->period - pb->lth_brightness) / max);
> + pwm_config(pb->pwm, pwm_brightness, pb->period);
> pwm_enable(pb->pwm);
> }
>
> --
> 1.7.11.1
>
>
pgpxYcm07sPdL.pgp
Description: PGP signature
linux-next: boot failure in next-20120705 and 20120706
Hi all, Boot testing next-20120705 and 20120706 one of my PowerPC machines get this BUG: (this one just after the console login prompt appeared.) kernel BUG at arch/powerpc/kernel/irq.c:188! Oops: Exception in kernel mode, sig: 5 [#1] SMP NR_CPUS=32 NUMA pSeries Modules linked in: binfmt_misc dm_mirror dm_region_hash dm_log ibmveth NIP: c000f7d4 LR: c000f838 CTR: c07222a0 REGS: c0d17a30 TRAP: 0700 Not tainted (3.5.0-rc5-autokern1) MSR: 80021032 CR: 2448 XER: SOFTE: 0 TASK = c0c41a10[0] 'swapper/0' THREAD: c0d14000 CPU: 0 GPR00: 0001 c0d17cb0 c0d12d10 0500 GPR04: GPR08: 001752557ab9dd5b c7ffb000 c0bf5200 GPR12: c7ffb000 02b0 009d7000 GPR16: 00d454f0 027dc6f0 01b5f994 0060 GPR20: 80009032 GPR24: c0d14000 c0d30290 c0d30178 c0d30290 GPR28: c08a6180 0008 c0c7e130 0001 NIP [c000f7d4] .__check_irq_replay+0xc4/0xf0 LR [c000f838] .arch_local_irq_restore+0x38/0x90 Call Trace: [c0d17cb0] [c0d17d30] init_thread_union+0x3d30/0x4000 (unreliable) [c0d17d40] [c000f838] .arch_local_irq_restore+0x38/0x90 [c0d17db0] [c0015c60] .cpu_idle+0x230/0x2b0 [c0d17e70] [c000b3f8] .rest_init+0x88/0xa0 [c0d17ef0] [c0b86c0c] .start_kernel+0x478/0x498 [c0d17f90] [c00096f8] .start_here_common+0x20/0x28 Instruction dump: 4e800020 7da96b78 7beaf7e3 880901f3 38600500 5400e87e 5400183e 980901f3 4082ffcc 880d01f3 7cd0 78000fe0 <0b00> 3860 4bb4 38610070 This is: BUG_ON(local_paca->irq_happened != 0); in __check_irq_replay(). This only happens on my Power5+ machine. -- Cheers, Stephen Rothwells...@canb.auug.org.au pgpqkgRdaluYv.pgp Description: PGP signature
Re: [PATCH] mm/memcg: complete documentation for tcp memcg files
(2012/07/06 18:15), Wanpeng Li wrote: > From: Wanpeng Li > > Signed-off-by: Wanpeng Li Acked-by: KAMEZAWA Hiroyuki -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] mm/memcg: mem_cgroup_relize_xxx_limit can guarantee memcg->res.limit <= memcg->memsw.limit
(2012/07/06 12:21), Wanpeng Li wrote: > From: Wanpeng Li > > Signed-off-by: Wanpeng Li Acked-by: KAMEZAWA Hiroyuki Could you merge all 'commentary fixes' into a patch ? > --- > mm/memcontrol.c |4 ++-- > 1 files changed, 2 insertions(+), 2 deletions(-) > > diff --git a/mm/memcontrol.c b/mm/memcontrol.c > index 4b64fe0..a501660 100644 > --- a/mm/memcontrol.c > +++ b/mm/memcontrol.c > @@ -3418,7 +3418,7 @@ static int mem_cgroup_resize_limit(struct mem_cgroup > *memcg, > /* >* Rather than hide all in some function, I do this in >* open coded manner. You see what this really does. > - * We have to guarantee memcg->res.limit < memcg->memsw.limit. > + * We have to guarantee memcg->res.limit <= memcg->memsw.limit. >*/ > mutex_lock(_limit_mutex); > memswlimit = res_counter_read_u64(>memsw, RES_LIMIT); > @@ -3479,7 +3479,7 @@ static int mem_cgroup_resize_memsw_limit(struct > mem_cgroup *memcg, > /* >* Rather than hide all in some function, I do this in >* open coded manner. You see what this really does. > - * We have to guarantee memcg->res.limit < memcg->memsw.limit. > + * We have to guarantee memcg->res.limit <= memcg->memsw.limit. >*/ > mutex_lock(_limit_mutex); > memlimit = res_counter_read_u64(>res, RES_LIMIT); > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] mm/memcg: return -EBUSY when oom-kill-disable modified and memcg use_hierarchy, has children
(2012/07/05 19:55), Wanpeng Li wrote:
> From: Wanpeng Li
>
> When oom-kill-disable modified by the user and current memcg use_hierarchy,
> the change can occur, provided the current memcg has no children. If it
> has children, return -EBUSY is enough.
>
> Signed-off-by: Wanpeng Li
I'm sorry what is the point ? You think -EBUSY should be returned in this case
rather than -EINVAl ? Then, why ?
> ---
> mm/memcontrol.c |7 +--
> 1 files changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/mm/memcontrol.c b/mm/memcontrol.c
> index 63e36e7..4b64fe0 100644
> --- a/mm/memcontrol.c
> +++ b/mm/memcontrol.c
> @@ -4521,11 +4521,14 @@ static int mem_cgroup_oom_control_write(struct cgroup
> *cgrp,
>
> cgroup_lock();
> /* oom-kill-disable is a flag for subhierarchy. */
> - if ((parent->use_hierarchy) ||
> - (memcg->use_hierarchy && !list_empty(>children))) {
> + if (parent->use_hierarchy) {
> cgroup_unlock();
> return -EINVAL;
> + } else if (memcg->use_hierarchy && !list_empty(>children)) {
> + cgroup_unlock();
> + return -EBUSY;
> }
> +
> memcg->oom_kill_disable = val;
> if (!val)
> memcg_oom_recover(memcg);
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4/4][update] hwmon / exynos4_tmu: Use struct dev_pm_ops for power management
On Sun, Jul 08, 2012 at 10:46:12PM +0200, Rafael J. Wysocki wrote:
> On Sunday, July 08, 2012, Guenter Roeck wrote:
> > On Sun, Jul 08, 2012 at 09:48:15PM +0200, Rafael J. Wysocki wrote:
> > > From: Rafael J. Wysocki
> > >
> > Hi Rafael,
> >
> > > Make the Exynos4 TMU driver define its PM callbacks through
> > > a struct dev_pm_ops object rather than by using legacy PM hooks
> > > in struct platform_driver.
> > >
> > > Signed-off-by: Rafael J. Wysocki
> > > ---
> > > drivers/hwmon/exynos4_tmu.c | 18 +++---
> > > 1 file changed, 11 insertions(+), 7 deletions(-)
> > >
> > > Index: linux/drivers/hwmon/exynos4_tmu.c
> > > ===
> > > --- linux.orig/drivers/hwmon/exynos4_tmu.c
> > > +++ linux/drivers/hwmon/exynos4_tmu.c
> > > @@ -476,34 +476,38 @@ static int __devexit exynos4_tmu_remove(
> > > }
> > >
> > > #ifdef CONFIG_PM
> > > -static int exynos4_tmu_suspend(struct platform_device *pdev,
> > > pm_message_t state)
> > > +static int exynos4_tmu_suspend(struct device *dev)
> > > {
> > > - exynos4_tmu_control(pdev, false);
> > > + exynos4_tmu_control(to_platform_device(dev), false);
> > >
> > > return 0;
> > > }
> > >
> > > -static int exynos4_tmu_resume(struct platform_device *pdev)
> > > +static int exynos4_tmu_resume(struct device *dev)
> > > {
> > > + struct platform_device *pdev = to_platform_device(dev);
> > > +
> > > exynos4_tmu_initialize(pdev);
> > > exynos4_tmu_control(pdev, true);
> > >
> > > return 0;
> > > }
> > > +
> > > +static SIMPLE_DEV_PM_OPS(exynos4_tmu_pm,
> > > + exynos4_tmu_suspend, exynos4_tmu_resume);
> > > +#define EXYNOS4_TMU_PM (_tmu_pm)
> > > #else
> > > -#define exynos4_tmu_suspend NULL
> > > -#define exynos4_tmu_resume NULL
> > > +#define EXYNOS4_TMU_PM NULL
> > > #endif
> >
> > Actually, looking into other drivers, the common approach seems to be to
> > declare
> >
> > static SIMPLE_DEV_PM_OPS(exynos4_tmu_pm,
> > exynos4_tmu_suspend, exynos4_tmu_resume);
> >
> > outside the #ifdef code and then just assign
> >
> > .pm = _tmu_pm;
> >
> > unconditionally.
> >
> > That seems to be a much simpler solution. Any special reason for not
> > implementing it this way ? Same question applies to the other patches in the
> > series.
>
> In fact, there are two ways. One of them is what you said, the other is to
> put SIMPLE_DEV_PM_OPS() under the #ifdef like I did. I'm not sure which one
> is prevalent, but what I did has the advatnage that the kernel data will
> be slightly smaller if CONFIG_PM is unset.
>
Ok, make sense. Applied to -next.
Thanks,
Guenter
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] mm/memcg: replace inexistence move_lock_page_cgroup() by move_lock_mem_cgroup() in comment
(2012/07/05 15:28), Wanpeng Li wrote: > From: Wanpeng Li > > Signed-off-by: Wanpeng Li Acked-by: KAMEZAWA Hiroyuki > --- > mm/memcontrol.c |4 ++-- > 1 files changed, 2 insertions(+), 2 deletions(-) > > diff --git a/mm/memcontrol.c b/mm/memcontrol.c > index 3d318f6..63e36e7 100644 > --- a/mm/memcontrol.c > +++ b/mm/memcontrol.c > @@ -1899,7 +1899,7 @@ again: > return; > /* >* If this memory cgroup is not under account moving, we don't > - * need to take move_lock_page_cgroup(). Because we already hold > + * need to take move_lock_mem_cgroup(). Because we already hold >* rcu_read_lock(), any calls to move_account will be delayed until >* rcu_read_unlock() if mem_cgroup_stolen() == true. >*/ > @@ -1921,7 +1921,7 @@ void __mem_cgroup_end_update_page_stat(struct page > *page, unsigned long *flags) > /* >* It's guaranteed that pc->mem_cgroup never changes while >* lock is held because a routine modifies pc->mem_cgroup > - * should take move_lock_page_cgroup(). > + * should take move_lock_mem_cgroup(). >*/ > move_unlock_mem_cgroup(pc->mem_cgroup, flags); > } > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/6] staging: vt6655: Cleanup in usage of macros
On Sun, 2012-07-08 at 23:51 -0300, Marcos Paulo de Souza wrote: > Hi kernel guys! > > This patchset aims to clean all unused and commented macros. > > For this challenge, forgotten-macros tool helped us. Perhaps there may be false positives in your code. Many times, macros like the below are used: #define SUBSYSTEM_PREFIX_FOO1 #define SUBSYSTEM_PREFIX_BAR2 #define SUBSYSTEM_PREFIX_BAZ3 #define USE_TYPE(type) SUBSYSTEM_PREFIX_##type It doesn't seem your code knows that style. Also, the tool might be more flexible if it was written using perl or python. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 6/7] memcg: add per cgroup writeback pages accounting
(2012/07/09 13:14), Fengguang Wu wrote:
On Mon, Jul 09, 2012 at 11:36:11AM +0800, Sha Zhengju wrote:
On 07/08/2012 10:53 PM, Fengguang Wu wrote:
@@ -2245,7 +2252,10 @@ int test_set_page_writeback(struct page *page)
{
struct address_space *mapping = page_mapping(page);
int ret;
+ bool locked;
+ unsigned long flags;
+ mem_cgroup_begin_update_page_stat(page,,);
if (mapping) {
struct backing_dev_info *bdi = mapping->backing_dev_info;
unsigned long flags;
@@ -2272,6 +2282,8 @@ int test_set_page_writeback(struct page *page)
}
if (!ret)
account_page_writeback(page);
+
+ mem_cgroup_end_update_page_stat(page,,);
return ret;
}
Where is the MEM_CGROUP_STAT_FILE_WRITEBACK increased?
It's in account_page_writeback().
void account_page_writeback(struct page *page)
{
+ mem_cgroup_inc_page_stat(page, MEM_CGROUP_STAT_FILE_WRITEBACK);
inc_zone_page_state(page, NR_WRITEBACK);
}
I didn't find that chunk, perhaps it's lost due to rebase..
There isn't a unified interface to dec/inc writeback accounting, so
I just follow that.
Maybe we can rework account_page_writeback() to also account
dec in?
The current seperate inc/dec paths are fine. It sounds like
over-engineering if going any further.
I'm a bit worried about some 3rd party kernel module to call
account_page_writeback() without mem_cgroup_begin/end_update_page_stat().
Will that lead to serious locking issues, or merely inaccurate
accounting?
Ah, Hm. Maybe it's better to add some debug check in
mem_cgroup_update_page_stat(). rcu_read_lock_held() or some.
Thanks,
-Kame
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] pwm_backlight: pass correct brightness to callback
pwm_backlight_update_status calls two callbacks before and after
applying the new PWM settings. However, the brightness scale is
completely changed in between if brightness levels are used. This patch
ensures that both callbacks are passed brightness values of the same
meaning.
Signed-off-by: Alexandre Courbot
---
drivers/video/backlight/pwm_bl.c | 12 +++-
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/drivers/video/backlight/pwm_bl.c b/drivers/video/backlight/pwm_bl.c
index 057389d..dd4d24d 100644
--- a/drivers/video/backlight/pwm_bl.c
+++ b/drivers/video/backlight/pwm_bl.c
@@ -39,6 +39,7 @@ static int pwm_backlight_update_status(struct
backlight_device *bl)
{
struct pwm_bl_data *pb = dev_get_drvdata(>dev);
int brightness = bl->props.brightness;
+ int pwm_brightness;
int max = bl->props.max_brightness;
if (bl->props.power != FB_BLANK_UNBLANK)
@@ -55,13 +56,14 @@ static int pwm_backlight_update_status(struct
backlight_device *bl)
pwm_disable(pb->pwm);
} else {
if (pb->levels) {
- brightness = pb->levels[brightness];
+ pwm_brightness = pb->levels[brightness];
max = pb->levels[max];
- }
+ } else
+ pwm_brightness = brightness;
- brightness = pb->lth_brightness +
- (brightness * (pb->period - pb->lth_brightness) / max);
- pwm_config(pb->pwm, brightness, pb->period);
+ pwm_brightness = pb->lth_brightness +
+(pwm_brightness * (pb->period - pb->lth_brightness) / max);
+ pwm_config(pb->pwm, pwm_brightness, pb->period);
pwm_enable(pb->pwm);
}
--
1.7.11.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 6/7] memcg: add per cgroup writeback pages accounting
On Mon, Jul 09, 2012 at 11:36:11AM +0800, Sha Zhengju wrote:
> On 07/08/2012 10:53 PM, Fengguang Wu wrote:
> >>@@ -2245,7 +2252,10 @@ int test_set_page_writeback(struct page *page)
> >> {
> >>struct address_space *mapping = page_mapping(page);
> >>int ret;
> >>+ bool locked;
> >>+ unsigned long flags;
> >>
> >>+ mem_cgroup_begin_update_page_stat(page,,);
> >>if (mapping) {
> >>struct backing_dev_info *bdi = mapping->backing_dev_info;
> >>unsigned long flags;
> >>@@ -2272,6 +2282,8 @@ int test_set_page_writeback(struct page *page)
> >>}
> >>if (!ret)
> >>account_page_writeback(page);
> >>+
> >>+ mem_cgroup_end_update_page_stat(page,,);
> >>return ret;
> >>
> >> }
> >Where is the MEM_CGROUP_STAT_FILE_WRITEBACK increased?
> >
>
> It's in account_page_writeback().
>
> void account_page_writeback(struct page *page)
> {
> + mem_cgroup_inc_page_stat(page, MEM_CGROUP_STAT_FILE_WRITEBACK);
> inc_zone_page_state(page, NR_WRITEBACK);
> }
I didn't find that chunk, perhaps it's lost due to rebase..
> There isn't a unified interface to dec/inc writeback accounting, so
> I just follow that.
> Maybe we can rework account_page_writeback() to also account
> dec in?
The current seperate inc/dec paths are fine. It sounds like
over-engineering if going any further.
I'm a bit worried about some 3rd party kernel module to call
account_page_writeback() without mem_cgroup_begin/end_update_page_stat().
Will that lead to serious locking issues, or merely inaccurate
accounting?
Thanks,
Fengguang
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: Fwd: Hid over I2C and ACPI interaction
These are already defined in acpica - in the file acrestyp.h ACPI_RESOURCE_FIXED_DMA FixedDma; ACPI_RESOURCE_GPIO Gpio; ACPI_RESOURCE_I2C_SERIALBUS I2cSerialBus; ACPI_RESOURCE_SPI_SERIALBUS SpiSerialBus; ACPI_RESOURCE_UART_SERIALBUSUartSerialBus; ACPI_RESOURCE_COMMON_SERIALBUS CommonSerialBus; >-Original Message- >From: linux-acpi-ow...@vger.kernel.org [mailto:linux-acpi- >ow...@vger.kernel.org] On Behalf Of Lan Tianyu >Sent: Sunday, July 08, 2012 8:25 PM >To: Mika Westerberg >Cc: Zhang, Rui; kh...@linux-fr.org; ben-li...@fluff.org; >w.s...@pengutronix.de; l...@kernel.org; linux-a...@vger.kernel.org; linux- >i...@vger.kernel.org; linux-kernel@vger.kernel.org; jkos...@suse.cz; >cha...@enac.fr; jj_d...@emc.com.tw; bhelg...@google.com; abe...@mit.edu >Subject: Re: Fwd: Hid over I2C and ACPI interaction > >On 2012年07月06日 13:52, Mika Westerberg wrote: >> On Thu, Jul 05, 2012 at 03:01:57PM +0800, Zhang Rui wrote: >>> +Note that although these are ACPI devices, we prefer to use PnP drivers >>> for them, >>> +this is because: >>> +1. all the non-ACPI-predefined Devices are exported as PnP devices as >>> well >>> +2. PnP bus is a well designed bus. Probing via PnP layer saves a lot of >>> work >>> + for the device driver, e.g. getting& parsing ACPI resources. >> >> (Nice BKM, thanks for sharing) >> >> I have few questions about using PnP drivers instead of pure ACPI >drivers. >> >> ACPI 5.0 defined some new resources, for example "Fixed DMA descriptor" >> that has information about the request line + channel for the device to >> use. Hovewer, PnP drivers pass resources as 'struct resource', which >> basically only has start and end - how do you represent all this new >stuff >> using 'struct resource'? >> >I think we can add new interface to get acpi specific resources. e.g >struct acpi_resource pnp_get_acpi_resource(...). When the pnp acpi devices >were initialized, put those acpi specific resources into a new resource >list >pnpdev->acpi_resources. What pnp_get_acpi_resource does is to get specified >type acpi resources and return. We also need to define some acpi resource >types. > >ACPI_RESOURCE_DMA >ACPI_RESOURCE_I2C_SERIALBUS >ACPI_RESOURCE_SPI_SERIALBUS >ACPI_RESOURCE_UART_SERIALBUS >ACPI_RESOURCE_COMMON_SERIALBUS >... > >How about this? welcome to comments. > >> Or should we use acpi_walk_resources() where 'struct resource' is not >> suitable? >> > >-- >Best Regards >Tianyu Lan >linux kernel enabling team >-- >To unsubscribe from this list: send the line "unsubscribe linux-acpi" in >the body of a message to majord...@vger.kernel.org >More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH V3 5/6] Avoid duplicate probe for of platform devices
> > I don't understand, why is this just showing up now? What changed to > > cause this? Couldn't that be the real problem here? > > > > The issue is showing up because we now probe devices twice. > Previously, we just probe devices once. But now we changed the way of pci > init which makes pci controllers should be probed earlier than other > devices. > So we have to probe pci nodes separately. Probe more than once is the > root > cause of this issue. > > The pci patchset I mentioned please refer to: > http://patchwork.ozlabs.org/patch/163742/ Let me try to clarify a little bit. The of platform bus normally traverse the device tree to add all the devices. The change which caused problem is that we need to probe PCIe RC devices at a earlier stage of initialization. So we added these PCIe RC devices earlier than the normal device tree traversal process. These PCIe RC devices will be scanned again during the normal traversal and cause duplicated devices being added. Our proposal is to deal with duplicated devices automatically and make it possible to scan the device tree multiple times for devices to be added. Regards, Leo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
linux-next: build failure after merge of the mfd tree
Hi Samuel, After merging the mfd tree, today's linux-next build (x86_64 allmodconfig) failed like this: ERROR: "arizona_dai_ops" [sound/soc/codecs/snd-soc-wm5102.ko] undefined! ERROR: "wm5102_aod" [drivers/mfd/arizona-irq.ko] undefined! ERROR: "wm5102_irq" [drivers/mfd/arizona-irq.ko] undefined! ERROR: "irq_set_chip_and_handler_name" [drivers/mfd/arizona-irq.ko] undefined! ERROR: "wm5102_patch" [drivers/mfd/arizona-core.ko] undefined! ERROR: "arizona_irq_init" [drivers/mfd/arizona-core.ko] undefined! ERROR: "arizona_irq_exit" [drivers/mfd/arizona-core.ko] undefined! I have used the mfd tree from next-20120706 for today. -- Cheers, Stephen Rothwells...@canb.auug.org.au pgpjgdTSokVv3.pgp Description: PGP signature
RE: USB: option: Add MEDIATEK product ids
Dear Shtylyov,
Sorry, I send this patch use web mail(in my mail line not wrapped), I
will use git client to send mail again.
Thank you very much.
BR,
Gaosen
-Original Message-
From: Sergei Shtylyov [mailto:sshtyl...@mvista.com]
Sent: 2012年7月7日 1:28
To: Gaosen Zhang (张高森)
Cc: sm...@smurf.noris.de; gre...@linuxfoundation.org;
linux-...@vger.kernel.org; linux-kernel@vger.kernel.org
Subject: Re: USB: option: Add MEDIATEK product ids
On 07/06/2012 05:50 PM, gaosen wrote:
> From 86fcd5bb701bd927d588386c480c37784d10040a Mon Sep 17 00:00:00 2001
> From: Gaosen Zhang
> Date: Fri, 6 Jul 2012 21:44:10 +0800
> Subject: [PATCH 1/1] USB: option: Add MEDIATEK product ids
> Signed-off-by: Gaosen Zhang
> ---
> drivers/usb/serial/option.c | 20
> 1 file changed, 20 insertions(+)
> diff --git a/drivers/usb/serial/option.c b/drivers/usb/serial/option.c
> index e668a24..f342a2c 100644
> --- a/drivers/usb/serial/option.c
> +++ b/drivers/usb/serial/option.c
[...]
> { USB_DEVICE_AND_INTERFACE_INFO(MEDIATEK_VENDOR_ID, 0x00a1, 0xff,
> 0x02, 0x01) },
> { USB_DEVICE_AND_INTERFACE_INFO(MEDIATEK_VENDOR_ID, 0x00a2, 0xff,
> 0x00, 0x00) },
> { USB_DEVICE_AND_INTERFACE_INFO(MEDIATEK_VENDOR_ID, 0x00a2, 0xff,
> 0x02, 0x01) },/* MediaTek MT6276M modem & app port */
> + { USB_DEVICE_AND_INTERFACE_INFO(MEDIATEK_VENDOR_ID, MTK_FP_1COM,
> 0x0a, 0x00, 0x00) },
> + { USB_DEVICE_AND_INTERFACE_INFO(MEDIATEK_VENDOR_ID, MTK_FP_2COM,
> 0x0a, 0x00, 0x00) },
> + { USB_DEVICE_AND_INTERFACE_INFO(MEDIATEK_VENDOR_ID, MTK_FPDC_1COM,
> 0x0a, 0x00, 0x00) },
> + { USB_DEVICE_AND_INTERFACE_INFO(MEDIATEK_VENDOR_ID, MTK_FPDC_2COM,
> 0x0a, 0x00, 0x00) },
> + { USB_DEVICE_AND_INTERFACE_INFO(MEDIATEK_VENDOR_ID, MTK_DC_1COM,
> 0x0a, 0x00, 0x00) },
> + { USB_DEVICE_AND_INTERFACE_INFO(MEDIATEK_VENDOR_ID, MTK_DC_5COM,
> 0xff, 0x02, 0x01) },
> + { USB_DEVICE_AND_INTERFACE_INFO(MEDIATEK_VENDOR_ID, MTK_DC_5COM,
> 0xff, 0x00, 0x00) },
> + { USB_DEVICE_AND_INTERFACE_INFO(MEDIATEK_VENDOR_ID, MTK_DC_4COM,
> 0xff, 0x02, 0x01) },
> + { USB_DEVICE_AND_INTERFACE_INFO(MEDIATEK_VENDOR_ID, MTK_DC_4COM,
> 0xff, 0x00, 0x00) },
> + { USB_DEVICE_AND_INTERFACE_INFO(MEDIATEK_VENDOR_ID, MTK_7208_1COM,
> 0x02, 0x00, 0x00) },
> + { USB_DEVICE_AND_INTERFACE_INFO(MEDIATEK_VENDOR_ID, MTK_7208_2COM,
> 0x02, 0x02, 0x01) },
> { } /* Terminating entry */
> };
> MODULE_DEVICE_TABLE(usb, option_ids);
Still line wrapped.
WBR, Sergei
N�Р骒r��yb�X�肚�v�^�)藓{.n�+�伐�{��赙zXФ�≤�}��财�z�:+v�����赙zZ+��+zf＂�h���~i���z� �wア�?�ㄨ��&�)撷f��^j谦y�m��@A�a囤�
0鹅h���i
Re: [patch 11/11] mm: memcg: only check anon swapin page charges for swap cache
(2012/07/05 9:45), Johannes Weiner wrote: > shmem knows for sure that the page is in swap cache when attempting to > charge a page, because the cache charge entry function has a check for > it. Only anon pages may be removed from swap cache already when > trying to charge their swapin. > > Adjust the comment, though: '4969c11 mm: fix swapin race condition' > added a stable PageSwapCache check under the page lock in the > do_swap_page() before calling the memory controller, so it's > unuse_pte()'s pte_same() that may fail. > > Signed-off-by: Johannes Weiner Acked-by: KAMEZAWA Hiroyuki -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Introduce to batch variants of accept() and epoll_ctl() syscall
于 2012年07月06日 17:38, Li Yu 写道: 于 2012年06月15日 16:51, Eric Dumazet 写道: On Fri, 2012-06-15 at 13:37 +0800, Li Yu wrote: Of course, I think that implementing them should not be a hard work :) Em. I really do not know whether it is necessary to introduce to a new syscall here. An alternative solution to add new socket option to handle such batch requirement, so applications also can detect if kernel has this extended ability with a easy getsockopt() call. Any way, I am going to try to write a prototype first. Before that, could you post the result of "perf top", or "perf record ...;perf report" Sorry for I just have time to write a benchmark to reproduce this problem on my test bed, below are results of "perf record -g -C 0". kernel is 3.4.0: Events: 7K cycles + 54.87% swapper [kernel.kallsyms] [k] poll_idle - 3.10% :22984 [kernel.kallsyms] [k] _raw_spin_lock - _raw_spin_lock - 64.62% sch_direct_xmit dev_queue_xmit ip_finish_output ip_output - ip_local_out + 49.48% ip_queue_xmit + 37.48% ip_build_and_send_pkt + 13.04% ip_send_skb I can not reproduce complete same high CPU usage on my testing environment, but top show that it has similar ratio of sys% and si% on one CPU: Tasks: 125 total, 2 running, 123 sleeping, 0 stopped, 0 zombie Cpu0 : 1.0%us, 30.7%sy, 0.0%ni, 18.8%id, 0.0%wa, 0.0%hi, 49.5%si, 0.0%st Well, it seem that I must acknowledge I was wrong here. however, I recall that I indeed ever encountered this in another benchmarking a small packets performance. I guess, this is since TX softirq and syscall context contend same lock in sch_direct_xmit(), is this right? Em, do we have some means to decrease the lock contention here? thanks Yu The top shows the kernel is most cpu hog, the testing is simple, just a accept() -> epoll_ctl(ADD) loop, the ratio of cpu util sys% to si% is about 2:5. This ratio is not meaningful, if we dont know where time is spent. I doubt epoll_ctl(ADD) is a problem here... If it is, batching the fds wont speed the thing anyway... I believe accept() is the problem here, because it contends with the softirq processing the tcp session handshake. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 6/7] memcg: add per cgroup writeback pages accounting
On 07/08/2012 10:53 PM, Fengguang Wu wrote:
@@ -2245,7 +2252,10 @@ int test_set_page_writeback(struct page *page)
{
struct address_space *mapping = page_mapping(page);
int ret;
+ bool locked;
+ unsigned long flags;
+ mem_cgroup_begin_update_page_stat(page,,);
if (mapping) {
struct backing_dev_info *bdi = mapping->backing_dev_info;
unsigned long flags;
@@ -2272,6 +2282,8 @@ int test_set_page_writeback(struct page *page)
}
if (!ret)
account_page_writeback(page);
+
+ mem_cgroup_end_update_page_stat(page,,);
return ret;
}
Where is the MEM_CGROUP_STAT_FILE_WRITEBACK increased?
It's in account_page_writeback().
void account_page_writeback(struct page *page)
{
+ mem_cgroup_inc_page_stat(page, MEM_CGROUP_STAT_FILE_WRITEBACK);
inc_zone_page_state(page, NR_WRITEBACK);
}
There isn't a unified interface to dec/inc writeback accounting, so
I just follow that.
Maybe we can rework account_page_writeback() to also account
dec in?
Thanks,
Sha
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Fwd: Hid over I2C and ACPI interaction
On 2012年07月06日 13:52, Mika Westerberg wrote: On Thu, Jul 05, 2012 at 03:01:57PM +0800, Zhang Rui wrote: +Note that although these are ACPI devices, we prefer to use PnP drivers for them, +this is because: +1. all the non-ACPI-predefined Devices are exported as PnP devices as well +2. PnP bus is a well designed bus. Probing via PnP layer saves a lot of work + for the device driver, e.g. getting& parsing ACPI resources. (Nice BKM, thanks for sharing) I have few questions about using PnP drivers instead of pure ACPI drivers. ACPI 5.0 defined some new resources, for example "Fixed DMA descriptor" that has information about the request line + channel for the device to use. Hovewer, PnP drivers pass resources as 'struct resource', which basically only has start and end - how do you represent all this new stuff using 'struct resource'? I think we can add new interface to get acpi specific resources. e.g struct acpi_resource pnp_get_acpi_resource(...). When the pnp acpi devices were initialized, put those acpi specific resources into a new resource list pnpdev->acpi_resources. What pnp_get_acpi_resource does is to get specified type acpi resources and return. We also need to define some acpi resource types. ACPI_RESOURCE_DMA ACPI_RESOURCE_I2C_SERIALBUS ACPI_RESOURCE_SPI_SERIALBUS ACPI_RESOURCE_UART_SERIALBUS ACPI_RESOURCE_COMMON_SERIALBUS ... How about this? welcome to comments. Or should we use acpi_walk_resources() where 'struct resource' is not suitable? -- Best Regards Tianyu Lan linux kernel enabling team -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH net-next 04/15] security: Add Linux Security Modules hook for AF_BUS sockets
On Fri, 29 Jun 2012, Vincent Sanders wrote: > From: Javier Martinez Canillas > > AF_BUS implements a security hook bus_connect() to be used by LSM to > enforce connectivity security policies. Nack. Changes to LSM should be cc'd the LSM list and Paul Moore. - James -- James Morris -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 10/11] mm: memcg: only check swap cache pages for repeated charging
(2012/07/05 9:45), Johannes Weiner wrote: > Only anon and shmem pages in the swap cache are attempted to be > charged multiple times, from every swap pte fault or from > shmem_unuse(). No other pages require checking PageCgroupUsed(). > > Charging pages in the swap cache is also serialized by the page lock, > and since both the try_charge and commit_charge are called under the > same page lock section, the PageCgroupUsed() check might as well > happen before the counter charging, let alone reclaim. > > Signed-off-by: Johannes Weiner You're right. This is SwapCache handling is done by commit d13d144309d... I should notice this Thank you very much ! Acked-by: KAMEZAWA Hiroyuki -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RESEND][PATCH RFT 2/2] regulator: twl: Convert twl6030ldo_ops to [get|set]_voltage_sel
Signed-off-by: Axel Lin
---
Sorry, I CCed wrong guys. So here is the resend.
Axel
drivers/regulator/twl-regulator.c | 24 +++-
1 file changed, 7 insertions(+), 17 deletions(-)
diff --git a/drivers/regulator/twl-regulator.c
b/drivers/regulator/twl-regulator.c
index bb51dec..de99b78 100644
--- a/drivers/regulator/twl-regulator.c
+++ b/drivers/regulator/twl-regulator.c
@@ -560,37 +560,27 @@ static struct regulator_ops twl6030coresmps_ops = {
};
static int
-twl6030ldo_set_voltage(struct regulator_dev *rdev, int min_uV, int max_uV,
- unsigned *selector)
+twl6030ldo_set_voltage_sel(struct regulator_dev *rdev, unsigned selector)
{
struct twlreg_info *info = rdev_get_drvdata(rdev);
- int vsel;
- if ((min_uV/1000 < info->min_mV) || (max_uV/1000 > info->max_mV))
- return -EDOM;
-
- vsel = DIV_ROUND_UP(min_uV - rdev->desc->min_uV, rdev->desc->uV_step);
- *selector = vsel;
-
- return twlreg_write(info, TWL_MODULE_PM_RECEIVER, VREG_VOLTAGE, vsel);
+ return twlreg_write(info, TWL_MODULE_PM_RECEIVER, VREG_VOLTAGE,
+ selector);
}
-static int twl6030ldo_get_voltage(struct regulator_dev *rdev)
+static int twl6030ldo_get_voltage_sel(struct regulator_dev *rdev)
{
struct twlreg_info *info = rdev_get_drvdata(rdev);
int vsel = twlreg_read(info, TWL_MODULE_PM_RECEIVER, VREG_VOLTAGE);
- if (vsel < 0)
- return vsel;
-
- return rdev->desc->min_uV + vsel * rdev->desc->uV_step;
+ return vsel;
}
static struct regulator_ops twl6030ldo_ops = {
.list_voltage = regulator_list_voltage_linear,
- .set_voltage= twl6030ldo_set_voltage,
- .get_voltage= twl6030ldo_get_voltage,
+ .set_voltage_sel = twl6030ldo_set_voltage_sel,
+ .get_voltage_sel = twl6030ldo_get_voltage_sel,
.enable = twl6030reg_enable,
.disable= twl6030reg_disable,
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH RFT 2/2] regulator: twl: Convert twl6030ldo_ops to [get|set]_voltage_sel
Signed-off-by: Axel Lin
---
drivers/regulator/twl-regulator.c | 24 +++-
1 file changed, 7 insertions(+), 17 deletions(-)
diff --git a/drivers/regulator/twl-regulator.c
b/drivers/regulator/twl-regulator.c
index bb51dec..de99b78 100644
--- a/drivers/regulator/twl-regulator.c
+++ b/drivers/regulator/twl-regulator.c
@@ -560,37 +560,27 @@ static struct regulator_ops twl6030coresmps_ops = {
};
static int
-twl6030ldo_set_voltage(struct regulator_dev *rdev, int min_uV, int max_uV,
- unsigned *selector)
+twl6030ldo_set_voltage_sel(struct regulator_dev *rdev, unsigned selector)
{
struct twlreg_info *info = rdev_get_drvdata(rdev);
- int vsel;
- if ((min_uV/1000 < info->min_mV) || (max_uV/1000 > info->max_mV))
- return -EDOM;
-
- vsel = DIV_ROUND_UP(min_uV - rdev->desc->min_uV, rdev->desc->uV_step);
- *selector = vsel;
-
- return twlreg_write(info, TWL_MODULE_PM_RECEIVER, VREG_VOLTAGE, vsel);
+ return twlreg_write(info, TWL_MODULE_PM_RECEIVER, VREG_VOLTAGE,
+ selector);
}
-static int twl6030ldo_get_voltage(struct regulator_dev *rdev)
+static int twl6030ldo_get_voltage_sel(struct regulator_dev *rdev)
{
struct twlreg_info *info = rdev_get_drvdata(rdev);
int vsel = twlreg_read(info, TWL_MODULE_PM_RECEIVER, VREG_VOLTAGE);
- if (vsel < 0)
- return vsel;
-
- return rdev->desc->min_uV + vsel * rdev->desc->uV_step;
+ return vsel;
}
static struct regulator_ops twl6030ldo_ops = {
.list_voltage = regulator_list_voltage_linear,
- .set_voltage= twl6030ldo_set_voltage,
- .get_voltage= twl6030ldo_get_voltage,
+ .set_voltage_sel = twl6030ldo_set_voltage_sel,
+ .get_voltage_sel = twl6030ldo_get_voltage_sel,
.enable = twl6030reg_enable,
.disable= twl6030reg_disable,
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH RFT 1/2] regulator: twl: Fix the formula to calculate vsel and voltage for twl6030ldo
In twl6030ldo_set_voltage, current code use below formula to calculate vsel:
vsel = (min_uV/1000 - 1000)/100 + 1;
This is worng because when min_uV is 100 uV, vsel is 1.
It should be 0 in this case.
Fix it by change the equation to: (This equation is common for linear mapping)
vsel = DIV_ROUND_UP(min_uV - rdev->desc->min_uV, rdev->desc->uV_step);
In twl6030ldo_get_voltage, current code use below formula to calculate voltage:
mV = 1000mv + 100mv * (vsel - 1)
This is worng because when vsel is 0, mV is 900mV. Note the min_uV is 1000mV.
Fix it by change the equation to: (This equation is common for linear mapping)
return rdev->desc->min_uV + vsel * rdev->desc->uV_step;
Signed-off-by: Axel Lin
---
drivers/regulator/twl-regulator.c | 17 -
1 file changed, 4 insertions(+), 13 deletions(-)
diff --git a/drivers/regulator/twl-regulator.c
b/drivers/regulator/twl-regulator.c
index 8f0bd56..bb51dec 100644
--- a/drivers/regulator/twl-regulator.c
+++ b/drivers/regulator/twl-regulator.c
@@ -569,30 +569,21 @@ twl6030ldo_set_voltage(struct regulator_dev *rdev, int
min_uV, int max_uV,
if ((min_uV/1000 < info->min_mV) || (max_uV/1000 > info->max_mV))
return -EDOM;
- /*
-* Use the below formula to calculate vsel
-* mV = 1000mv + 100mv * (vsel - 1)
-*/
- vsel = (min_uV/1000 - 1000)/100 + 1;
+ vsel = DIV_ROUND_UP(min_uV - rdev->desc->min_uV, rdev->desc->uV_step);
*selector = vsel;
- return twlreg_write(info, TWL_MODULE_PM_RECEIVER, VREG_VOLTAGE, vsel);
+ return twlreg_write(info, TWL_MODULE_PM_RECEIVER, VREG_VOLTAGE, vsel);
}
static int twl6030ldo_get_voltage(struct regulator_dev *rdev)
{
struct twlreg_info *info = rdev_get_drvdata(rdev);
- int vsel = twlreg_read(info, TWL_MODULE_PM_RECEIVER,
- VREG_VOLTAGE);
+ int vsel = twlreg_read(info, TWL_MODULE_PM_RECEIVER, VREG_VOLTAGE);
if (vsel < 0)
return vsel;
- /*
-* Use the below formula to calculate vsel
-* mV = 1000mv + 100mv * (vsel - 1)
-*/
- return (1000 + (100 * (vsel - 1))) * 1000;
+ return rdev->desc->min_uV + vsel * rdev->desc->uV_step;
}
static struct regulator_ops twl6030ldo_ops = {
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [net-next RFC V5 0/5] Multiqueue virtio-net
On 07/07/2012 12:23 AM, Rick Jones wrote: On 07/06/2012 12:42 AM, Jason Wang wrote: I'm not expert of tcp, but looks like the changes are reasonable: - we can do full-sized TSO check in tcp_tso_should_defer() only for westwood, according to tcp westwood - run tcp_tso_should_defer for tso_segs = 1 when tso is enabled. I'm sure Eric and David will weigh-in on the TCP change. My initial inclination would have been to say "well, if multiqueue is draining faster, that means ACKs come-back faster, which means the "race" between more data being queued by netperf and ACKs will go more to the ACKs which means the segments being sent will be smaller - as TCP_NODELAY is not set, the Nagle algorithm is in force, which means once there is data outstanding on the connection, no more will be sent until either the outstanding data is ACKed, or there is an accumulation of > MSS worth of data to send. Also, how are you combining the concurrent netperf results? Are you taking sums of what netperf reports, or are you gathering statistics outside of netperf? The throughput were just sumed from netperf result like what netperf manual suggests. The cpu utilization were measured by mpstat. Which mechanism to address skew error? The netperf manual describes more than one: This mechanism is missed in my test, I would add them to my test scripts. http://www.netperf.org/svn/netperf2/trunk/doc/netperf.html#Using-Netperf-to-Measure-Aggregate-Performance Personally, my preference these days is to use the "demo mode" method of aggregate results as it can be rather faster than (ab)using the confidence intervals mechanism, which I suspect may not really scale all that well to large numbers of concurrent netperfs. During my test, the confidence interval would even hard to achieved in RR test when I pin vhost/vcpus in the processors, so I didn't use it. I also tend to use the --enable-burst configure option to allow me to minimize the number of concurrent netperfs in the first place. Set TCP_NODELAY (the test-specific -D option) and then have several transactions outstanding at one time (test-specific -b option with a number of additional in-flight transactions). This is expressed in the runemomniaggdemo.sh script: http://www.netperf.org/svn/netperf2/trunk/doc/examples/runemomniaggdemo.sh which uses the find_max_burst.sh script: http://www.netperf.org/svn/netperf2/trunk/doc/examples/find_max_burst.sh to pick the burst size to use in the concurrent netperfs, the results of which can be post-processed with: http://www.netperf.org/svn/netperf2/trunk/doc/examples/post_proc.py The nice feature of using the "demo mode" mechanism is when it is coupled with systems with reasonably synchronized clocks (eg NTP) it can be used for many-to-many testing in addition to one-to-many testing (which cannot be dealt with by the confidence interval method of dealing with skew error) Yes, looks "demo mode" is helpful. I would have a look at these scripts, Thanks. A single instance TCP_RR test would help confirm/refute any non-trivial change in (effective) path length between the two cases. Yes, I would test this thanks. Excellent. happy benchmarking, rick jones -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH firmware 3/4] rtl_nic: add new firmware for RTL8106E
File: rtl_nic/rtl8106e-1.fw
Version: 0.0.1
Signed-off-by: Hayes Wang
---
WHENCE|3 +++
rtl_nic/rtl8106e-1.fw | Bin 0 -> 1856 bytes
2 files changed, 3 insertions(+)
create mode 100644 rtl_nic/rtl8106e-1.fw
diff --git a/WHENCE b/WHENCE
index c7a3e98..8f2b610 100644
--- a/WHENCE
+++ b/WHENCE
@@ -1813,6 +1813,9 @@ Version: 0.0.3
File: rtl_nic/rtl8402-1.fw
Version: 0.0.1
+File: rtl_nic/rtl8106e-1.fw
+Version: 0.0.1
+
Licence:
* Copyright ?? 2011, Realtek Semiconductor Corporation
*
diff --git a/rtl_nic/rtl8106e-1.fw b/rtl_nic/rtl8106e-1.fw
new file mode 100644
index
..85694cb6bf5f0a1807356392497703a779b5148e
GIT binary patch
literal 1856
zcmZ{lYlxIp7{||CawkZ3{NN2d?SMix&;G)KF7QP>}FL6lNbnrS12B-}AD=L<0}cdCz|MPz?
z=ZtgCjcgfys1kJ#Jy5Ad^P~BdQq;Ymx@bYA%9(z30TdPKuYSdkM
zur@fdaqG}XsnXLME$m&`*zx-LHfOQ
zZA$GuhC
z?8G<5gzK@Ux5F2SOKjPfuy>=#bJQ?kjI;O7>A;Wr%g)$SZ|IHRwi@5PD@U3|`@FQ~qzcKU*^d|TYpc`C^l#?vV|Z6cUdI`DlEw;pzX}b{CUNrYiHCZ1$C5aW6mxLW
zFPK$@6>ZjS&9r&5}>9=zKzZr{X0xab>PTV+7OI+1+UR
zvU>?1#Ty7dE%UCLrM-4fOy1@A{*puM-R-1j6M_F~-G|V#4(`?Z@U5QZ_7Eq`(TCLQ
zy7Tr5`d762cMW}QA2x0H@eIP@GH3Z$!+m)QyaQooS!eJWZJD=im%RNBp89o_y7b}S
zLk(sv@pfWyQY-ECh5U6_G>fVJ;dT1^leeY#=XZO1q`};fkKPO6)$x5Byz*lSmcGm6
zrtcK9{T;ea+!R06pAcs;Z`S?bFAMKb1FS53vT*H3_7Eqvm(Ia6?Pmw;Kfs+p-VAoy
zlif_T-k`rpQNR9$1>@|DB(7KK0+C`P6*1i4t9hl^%|1p=HW0C
literal 0
HcmV?d1
--
1.7.10.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH firmware 4/4] rtl_nic: add new firmware for RTL8168G
File: rtl_nic/rtl8168g-1.fw
Version: 0.0.1
Signed-off-by: Hayes Wang
---
WHENCE|3 +++
rtl_nic/rtl8168g-1.fw | Bin 0 -> 4272 bytes
2 files changed, 3 insertions(+)
create mode 100644 rtl_nic/rtl8168g-1.fw
diff --git a/WHENCE b/WHENCE
index 8f2b610..1fb7951 100644
--- a/WHENCE
+++ b/WHENCE
@@ -1816,6 +1816,9 @@ Version: 0.0.1
File: rtl_nic/rtl8106e-1.fw
Version: 0.0.1
+File: rtl_nic/rtl8168g-1.fw
+Version: 0.0.1
+
Licence:
* Copyright ?? 2011, Realtek Semiconductor Corporation
*
diff --git a/rtl_nic/rtl8168g-1.fw b/rtl_nic/rtl8168g-1.fw
new file mode 100644
index
..dace1ea98c66de08107ee0857d8a8680d57d7898
GIT binary patch
literal 4272
zcma)=4Q!QH8OP6kds{wM$}K%Y`HbYuZ+~EWhvW6)o*;>z3c!QeBg%P1LolUbS|4yt?kDnlJF*JodEuCT}Pc
zV`BWv{_m0O*tAECNvo>fn0UPjI`1}St1DCSXug(l^wlSMq#t1)yg*+Kf-uAxewES$oEGwzeX_}
zu`-vr@6nI>{&(mHzTZwi;`?8p;NotrwNkUp%B}dRPGddZ=H_;S>rs4kjg77N{%Xi(
zE#pJXFU0R(l~&}JRvPxe-xK8SaQ+t>t*pjw#0e{lvCBgakniR@t$eq}%3b$csmCuM
z?#;y5hOLeZ{P<+Gl~!+4Og9|XNaNvbgj4Y2L5Nj
z5%qrYVSZ8kny^>9IG92_FEbvS24g<8fPdtmi`iOl<*1L_hhA+0ZxeW%wokB$VxzI2
zYP}xYdiLJ@*2?^=dC?!tpDcWW@uX4HmSDcY>`N01ft8ymi1FlX{&!
z{miTM!C`(!J7(p`YslZzz-2~~-|s_2_u*l5f1sf=?2XPxS-(o>s4V=Fi?fKm{mp0bBS#Q8yRGEZ9Q*uSAu$xokB8}th@U23
zSVudD|+-aS@kv6gv18^U4gIkVX6-8H`pJ#+CMm!q8XHV=$FU@RDhF?)u*U4$56
zz3%=rHOije3r<~sob`uws$&(Y(q@jQMhM=IY}cIIpy=*b8$v(dw~HfG_6#PlM^u
zXvfVDJvYL9!sk_<3*l*6gIi0y
zbCl0~6?k{czri!8dGaeaXt%9#U?FIHws-R
zx-O6Xaisd^;>fM-9j({bPFUNM{QFga{0kgLksppA7V`B1xImt|$U1V~zRry$vXM9H
zz&KF{S!RIZEFRkJXe#Cxd;Gqw@n3H8CwE3bBd
z5#HXaV6M>09n7h3CwNspdfdqm@z?QQ-XWEv-*z(gZzs2WU}XdPsSzh{zro4-iK+Va
z#c(e-1Vpqn{X|=hq$~E>S%AC(t%AGZstHMep
zakAJi5SRTP%=2fLrzo6%*UC=jHBLX6^UkoWxR`(JQ>8)Ic%3RZ}}B^1q(+^@x=x8#!P5uwnmR%dv@KW2k`<;446G
zK0tlnPF!kO<5p_i>8zpI#XUpZwVIE8nA?vHat^Ybx(;4+e99U2YaQ!@^T~6qyof9z
zUOn-FWTa(nM*5pj$Nt$(W
zF9a2Q>*BBT7g?ju{g?!3Jg>HxRCKw_E2?YxjL|^t}0h$e*#YYk_8!F(RO
zMsg+l;H|;}|!2_rW`W^>;3`k`L|&@$G(uF?VWS#L7g*8P=(LJKU#VIgJnFlzd+e
z*Q%T{pIyJ!7yJyKr3<3GnbZv~^Cv0m&`d7LRf*GJ7PWbQQBG)@)gC3y~v#O@_m
zidqY8yRq%%o=Z_Hp)QS1xsG4N?<^SLr<=8A`9S8@OIULy!absAcZ!wwI~<>SPD(f@
z9cj3MJLO8>k8bXuPHHJ1uCn7>IR9Wskh4;;k~5PS;xEnJ)685^N`%$<{t`b2$z^
z<~{-AV#UJQKMNMU8+Cv6Ea_O^6CLY1vvGaSz{l13?3?$#yGxVc?+4G>N{2DSxeNDJ
z@5SSsTjk+n+y!^6b>d%Xf1|xaJB7^%xcsS$IiG$Mn+wmO_wlYBb8nMjf12UO
zJb+|h%`)O*Yu@Axss781RnME!F$&3@pOxfOyROr`=En1FsJ`Gd?N(+Vhttp://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH firmware 2/4] rtl_nic: update firmware for RTL8411
File: rtl_nic/rtl8411-1.fw
Version: 0.0.3
Signed-off-by: Hayes Wang
---
WHENCE |2 +-
rtl_nic/rtl8411-1.fw | Bin 1840 -> 2112 bytes
2 files changed, 1 insertion(+), 1 deletion(-)
diff --git a/WHENCE b/WHENCE
index 676ebb1..c7a3e98 100644
--- a/WHENCE
+++ b/WHENCE
@@ -1808,7 +1808,7 @@ File: rtl_nic/rtl8168f-2.fw
Version: 0.0.4
File: rtl_nic/rtl8411-1.fw
-Version: 0.0.2
+Version: 0.0.3
File: rtl_nic/rtl8402-1.fw
Version: 0.0.1
diff --git a/rtl_nic/rtl8411-1.fw b/rtl_nic/rtl8411-1.fw
index
1bd9e7cdd5605e34e0322c0df185c53e46d6a34b..72772dbc8343c8cef8eac61f704377fc3fb6c7b3
100644
GIT binary patch
delta 430
zcmZ{fze@sP7{~8U`4Wj`Q4Iy9WLe;k_wMStjzDN>X^@6!a}JuKp{*}UOVSiH7DS^R
zg*4kA(2!HBf)TW|m6Sx!NkK~wyga|3@8`W9xQi7uvE98Lcfm9>W>IBT){ZMDXSzAl
z3VMMBL!Y{)O=uhIj-}k9rA$jX%FSAF)Akl^^4yFO$LSP2pZ2E7w6|1x$FL-T-@f
zzGfMly5W~
ztmeT;Tr{c@N5R1vFeR}+B-+E^Z5oXFU`aImXQ}mpk5UUsEp6a{-50PE7Jv_FZVP|_
zHAS#B0*;CgAR4k%p9I%3|HGza?ja{PBC_L(;Fi37FnKPZ!95GKf8fUjz8wRtijefg
X=D>LwO211kzk2%3-~Q$&7btxL90!Z?
delta 157
zcmX>guz@dt0SJmpax6>?4RsCU4fG83j1^^MH+4UIr@AOKRdg^_{5mLbT;%*enZ
z-pIhv$iUdhP{Gj5%EZjd)PSLPi3&(%_y3InXBfqr_OmrGtz|?*uyvWu7=5O3=
o#1zKJRHL)Gihttp://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH firmware 1/4] rtl_nic: update firmware for RTL8168F
File: rtl_nic/rtl8168f-1.fw
Version: 0.0.5
Signed-off-by: Hayes Wang
---
WHENCE|2 +-
rtl_nic/rtl8168f-1.fw | Bin 3136 -> 3424 bytes
2 files changed, 1 insertion(+), 1 deletion(-)
diff --git a/WHENCE b/WHENCE
index 13cbcab..676ebb1 100644
--- a/WHENCE
+++ b/WHENCE
@@ -1802,7 +1802,7 @@ File: rtl_nic/rtl8168e-3.fw
Version: 0.0.4
File: rtl_nic/rtl8168f-1.fw
-Version: 0.0.4
+Version: 0.0.5
File: rtl_nic/rtl8168f-2.fw
Version: 0.0.4
diff --git a/rtl_nic/rtl8168f-1.fw b/rtl_nic/rtl8168f-1.fw
index
41822b54ef44c37400db3ddac26d0e6655e1faa7..bf7883163e3dbed22420dec369ed51a3ee8247d4
100644
GIT binary patch
delta 487
zcmZuuJxc>Y6uex*5QyRjDq^7#zab`j7d#Ie(Z)hSv9hxh0;$A8M9Cne3RVFdK??;z
zG${E2T3MUY$_vCgor;J!CkhrWEbqP9dGls>?|Os26-#S#EAKm=zcJ~oo3u$!C5@MH
z{EXv(k(@@b&?4=ol-zW18y^mXx;P}OQi-9~_L#+i{1LH-Y(0jH99s#z74T5Y9ynlcifV2#<0SrL?Whttp://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 09/11] mm: memcg: split swapin charge function into private and public part
(2012/07/05 9:45), Johannes Weiner wrote: > When shmem is charged upon swapin, it does not need to check twice > whether the memory controller is enabled. > > Also, shmem pages do not have to be checked for everything that > regular anon pages have to be checked for, so let shmem use the > internal version directly and allow future patches to move around > checks that are only required when swapping in anon pages. > > Signed-off-by: Johannes Weiner Acked-by: KAMEZAWA Hiroyuki -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 08/11] mm: memcg: remove needless !mm fixup to init_mm when charging
(2012/07/05 9:45), Johannes Weiner wrote: > It does not matter to __mem_cgroup_try_charge() if the passed mm is > NULL or init_mm, it will charge the root memcg in either case. > > Signed-off-by: Johannes Weiner Acked-by: KAMEZAWA Hiroyuki -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 07/11] mm: memcg: remove unneeded shmem charge type
(2012/07/05 9:44), Johannes Weiner wrote: > shmem page charges have not needed a separate charge type to tell them > from regular file pages since 08e552c 'memcg: synchronized LRU'. > > Signed-off-by: Johannes Weiner Acked-by: KAMEZAWA Hiroyuki -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 6/6] staging: vt6655: hostap.c: Remove all unused macros
All these macros were reported by forgotten-macros tool (https://github.com/marcosps/forgotten_macros). Signed-off-by: Marcos Paulo de Souza --- drivers/staging/vt6655/hostap.c |6 -- 1 file changed, 6 deletions(-) diff --git a/drivers/staging/vt6655/hostap.c b/drivers/staging/vt6655/hostap.c index 7735027..6ac6f45 100644 --- a/drivers/staging/vt6655/hostap.c +++ b/drivers/staging/vt6655/hostap.c @@ -40,14 +40,8 @@ #define VIAWGET_HOSTAPD_MAX_BUF_SIZE 1024 #define HOSTAP_CRYPT_FLAG_SET_TX_KEY BIT0 -#define HOSTAP_CRYPT_FLAG_PERMANENT BIT1 -#define HOSTAP_CRYPT_ERR_UNKNOWN_ALG 2 #define HOSTAP_CRYPT_ERR_UNKNOWN_ADDR 3 -#define HOSTAP_CRYPT_ERR_CRYPT_INIT_FAILED 4 #define HOSTAP_CRYPT_ERR_KEY_SET_FAILED 5 -#define HOSTAP_CRYPT_ERR_TX_KEY_SET_FAILED 6 -#define HOSTAP_CRYPT_ERR_CARD_CONF_FAILED 7 - /*- Static Definitions -*/ -- 1.7.10.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 5/6] staging: vt6655: Remove all commented macros
These macros were reported by forgotten-macros tool (https://github.com/marcosps/forgotten_macros). Signed-off-by: Marcos Paulo de Souza --- drivers/staging/vt6655/80211hdr.h|2 -- drivers/staging/vt6655/baseband.c|2 -- drivers/staging/vt6655/bssdb.c |1 - drivers/staging/vt6655/desc.h| 11 --- drivers/staging/vt6655/device.h | 15 --- drivers/staging/vt6655/device_main.c |4 drivers/staging/vt6655/dpc.c |1 - drivers/staging/vt6655/mib.h |2 -- drivers/staging/vt6655/rf.h |1 - drivers/staging/vt6655/tether.h |3 --- drivers/staging/vt6655/vntwifi.c |2 -- 11 files changed, 44 deletions(-) diff --git a/drivers/staging/vt6655/80211hdr.h b/drivers/staging/vt6655/80211hdr.h index f55283b..c4d2349 100644 --- a/drivers/staging/vt6655/80211hdr.h +++ b/drivers/staging/vt6655/80211hdr.h @@ -80,7 +80,6 @@ #define WLAN_HDR_ADDR4_LEN 30 #define WLAN_IEHDR_LEN 2 #define WLAN_SSID_MAXLEN32 -/*#define WLAN_RATES_MAXLEN 255*/ #define WLAN_RATES_MAXLEN 16 #define WLAN_RATES_MAXLEN_11B 4 #define WLAN_RSN_MAXLEN 32 @@ -106,7 +105,6 @@ #define WLAN_WEP40_KEYLEN 5 #define WLAN_WEP104_KEYLEN 13 #define WLAN_WEP232_KEYLEN 29 -/*#define WLAN_WEPMAX_KEYLEN 29*/ #define WLAN_WEPMAX_KEYLEN 32 #define WLAN_CHALLENGE_IE_MAXLEN255 #define WLAN_CHALLENGE_IE_LEN 130 diff --git a/drivers/staging/vt6655/baseband.c b/drivers/staging/vt6655/baseband.c index 1e1c6e3..e7b93a2 100644 --- a/drivers/staging/vt6655/baseband.c +++ b/drivers/staging/vt6655/baseband.c @@ -60,8 +60,6 @@ //static int msglevel=MSG_LEVEL_DEBUG; static int msglevel=MSG_LEVEL_INFO; -//#define PLICE_DEBUG - /*- Static Classes */ /*- Static Variables --*/ diff --git a/drivers/staging/vt6655/bssdb.c b/drivers/staging/vt6655/bssdb.c index f4f108f..fcffa4f 100644 --- a/drivers/staging/vt6655/bssdb.c +++ b/drivers/staging/vt6655/bssdb.c @@ -58,7 +58,6 @@ #include "wpa2.h" #include "iowpa.h" -//#define PLICE_DEBUG /*- Static Definitions -*/ diff --git a/drivers/staging/vt6655/desc.h b/drivers/staging/vt6655/desc.h index 138897a..084a1a5 100644 --- a/drivers/staging/vt6655/desc.h +++ b/drivers/staging/vt6655/desc.h @@ -152,10 +152,6 @@ #define FRAGCTL_TKIP0x0002 // 0010 #define FRAGCTL_LEGACY 0x0001 // 0001 #define FRAGCTL_NONENCRYPT 0x // -//#define FRAGCTL_AC3 0x0C00 // 1100 -//#define FRAGCTL_AC2 0x0800 // 1000 -//#define FRAGCTL_AC1 0x0400 // 0100 -//#define FRAGCTL_AC0 0x // #define FRAGCTL_ENDFRAG 0x0300 // 0011 #define FRAGCTL_MIDFRAG 0x0200 // 0010 #define FRAGCTL_STAFRAG 0x0100 // 0001 @@ -184,10 +180,6 @@ #define FRAGCTL_TKIP0x0200 // 0010 #define FRAGCTL_LEGACY 0x0100 // 0001 #define FRAGCTL_NONENCRYPT 0x // -//#define FRAGCTL_AC3 0x000C // 1100 -//#define FRAGCTL_AC2 0x0008 // 1000 -//#define FRAGCTL_AC1 0x0004 // 0100 -//#define FRAGCTL_AC0 0x // #define FRAGCTL_ENDFRAG 0x0003 // 0011 #define FRAGCTL_MIDFRAG 0x0002 // 0010 #define FRAGCTL_STAFRAG 0x0001 // 0001 @@ -195,8 +187,6 @@ #endif // #ifdef __BIG_ENDIAN -//#define TYPE_AC0DMA 0 -//#define TYPE_TXDMA0 1 #define TYPE_TXDMA0 0 #define TYPE_AC0DMA 1 #define TYPE_ATIMDMA2 @@ -215,7 +205,6 @@ #define TD_FLAGS_NETIF_SKB 0x01 // check if need release skb #define TD_FLAGS_PRIV_SKB0x02 // check if called from private skb(hostap) #define TD_FLAGS_PS_RETRY0x04 // check if PS STA frame re-transmit -//#define TD_FLAGS_NETIF_SKB0x04 /*- Export Types --*/ diff --git a/drivers/staging/vt6655/device.h b/drivers/staging/vt6655/device.h index 780205c..c5e6b98 100644 --- a/drivers/staging/vt6655/device.h +++ b/drivers/staging/vt6655/device.h @@ -69,10 +69,6 @@ #ifndef WPA_SUPPLICANT_DRIVER_WEXT_SUPPORT #define WPA_SUPPLICANT_DRIVER_WEXT_SUPPORT #endif -//2008-4-14 by chester for led issue -//#define FOR_LED_ON_NOTEBOOK -// - // // device specific @@ -91,12 +87,6 @@ #include "key.h" #include "mac.h" -//PLICE_DEBUG-> -//#define THREAD - -//#define TASK_LET -//PLICE_DEBUG<- -
[PATCH 4/6] staging: vt6655: baseband.h: Remove all unused macros
These macros were reported by forgotten-macros tool (https://github.com/marcosps/forgotten_macros). Signed-off-by: Marcos Paulo de Souza --- drivers/staging/vt6655/baseband.h | 30 -- 1 file changed, 30 deletions(-) diff --git a/drivers/staging/vt6655/baseband.h b/drivers/staging/vt6655/baseband.h index 8294bdb..be2d689 100644 --- a/drivers/staging/vt6655/baseband.h +++ b/drivers/staging/vt6655/baseband.h @@ -46,36 +46,6 @@ // Baseband RF pair definition in eeprom (Bits 6..0) // -/* -#define RATE_1M 0 -#define RATE_2M 1 -#define RATE_5M 2 -#define RATE_11M3 -#define RATE_6M 4 -#define RATE_9M 5 -#define RATE_12M6 -#define RATE_18M7 -#define RATE_24M8 -#define RATE_36M9 -#define RATE_48M 10 -#define RATE_54M 11 -#define RATE_AUTO 12 -#define MAX_RATE 12 - - -//0:11A 1:11B 2:11G -#define BB_TYPE_11A0 -#define BB_TYPE_11B1 -#define BB_TYPE_11G2 - -//0:11a,1:11b,2:11gb(only CCK in BasicRate),3:11ga(OFDM in Basic Rate) -#define PK_TYPE_11A 0 -#define PK_TYPE_11B 1 -#define PK_TYPE_11GB2 -#define PK_TYPE_11GA3 -*/ - - #define PREAMBLE_LONG 0 #define PREAMBLE_SHORT 1 -- 1.7.10.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/6] staging: vt6655: rf.c: Remove all unused macros
These macros were reported by forgotte-macros tool
(https://github.com/marcosps/forgotten_macros).
Signed-off-by: Marcos Paulo de Souza
---
drivers/staging/vt6655/rf.c | 36
1 file changed, 36 deletions(-)
diff --git a/drivers/staging/vt6655/rf.c b/drivers/staging/vt6655/rf.c
index a2db0ff..aa69665 100644
--- a/drivers/staging/vt6655/rf.c
+++ b/drivers/staging/vt6655/rf.c
@@ -41,52 +41,16 @@
//static int msglevel=MSG_LEVEL_INFO;
-#define BY_RF2959_REG_LEN 23 //24bits
-#define CB_RF2959_INIT_SEQ15
-#define SWITCH_CHANNEL_DELAY_RF2959 200 //us
-#define RF2959_PWR_IDX_LEN32
-
-#define BY_MA2825_REG_LEN 23 //24bit
-#define CB_MA2825_INIT_SEQ13
-#define SWITCH_CHANNEL_DELAY_MA2825 200 //us
-#define MA2825_PWR_IDX_LEN31
-
#define BY_AL2230_REG_LEN 23 //24bit
#define CB_AL2230_INIT_SEQ15
#define SWITCH_CHANNEL_DELAY_AL2230 200 //us
#define AL2230_PWR_IDX_LEN64
-#define BY_UW2451_REG_LEN 23
-#define CB_UW2451_INIT_SEQ6
-#define SWITCH_CHANNEL_DELAY_UW2451 200 //us
-#define UW2451_PWR_IDX_LEN25
-
-//{{ RobertYu: 20041118
-#define BY_MA2829_REG_LEN 23 //24bit
-#define CB_MA2829_INIT_SEQ13
-#define SWITCH_CHANNEL_DELAY_MA2829 200 //us
-#define MA2829_PWR_IDX_LEN64
-//}} RobertYu
-
-//{{ RobertYu:20050103
#define BY_AL7230_REG_LEN 23 //24bit
#define CB_AL7230_INIT_SEQ16
#define SWITCH_CHANNEL_DELAY_AL7230 200 //us
#define AL7230_PWR_IDX_LEN64
-//}} RobertYu
-
-//{{ RobertYu: 20041210
-#define BY_UW2452_REG_LEN 23
-#define CB_UW2452_INIT_SEQ5 //RoberYu:20050113, Rev0.2 Programming
Guide(remove R3, so 6-->5)
-#define SWITCH_CHANNEL_DELAY_UW2452 100 //us
-#define UW2452_PWR_IDX_LEN64
-//}} RobertYu
-
-#define BY_VT3226_REG_LEN 23
-#define CB_VT3226_INIT_SEQ12
-#define SWITCH_CHANNEL_DELAY_VT3226 200 //us
-#define VT3226_PWR_IDX_LEN16
/*- Static Classes */
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/6] staging: vt6655: mac.h: Remove all commented macros
These macros were reported by forgotten-macros tool (https://github.com/marcosps/forgotten_macros). Signed-off-by: Marcos Paulo de Souza --- drivers/staging/vt6655/mac.h | 24 1 file changed, 24 deletions(-) diff --git a/drivers/staging/vt6655/mac.h b/drivers/staging/vt6655/mac.h index b96d27e..e3ccfee 100644 --- a/drivers/staging/vt6655/mac.h +++ b/drivers/staging/vt6655/mac.h @@ -292,19 +292,11 @@ // #define EnCFG_BarkerPream 0x0002 #define EnCFG_NXTBTTCFPSTR 0x0001 -//#define EnCFG_TXLMT3UPDATE 0x8000 -//#define EnCFG_TXLMT2UPDATE 0x4000 -//#define EnCFG_TXLMT1UPDATE 0x2000 -//#define EnCFG_TXLMT3EN 0x1000 -//#define EnCFG_TXLMT2EN 0x0800 -//#define EnCFG_TXLMT1EN 0x0400 #define EnCFG_BcnSusClr 0x0200 #define EnCFG_BcnSusInd 0x0100 -//#define EnCFG_CWOFF10x0080 #define EnCFG_CFP_ProtectEn 0x0040 #define EnCFG_ProtectMd 0x0020 #define EnCFG_HwParCFP 0x0010 -//#define EnCFG_QOS 0x0008 #define EnCFG_CFNULRSP 0x0004 #define EnCFG_BBType_MASK 0x0003 #define EnCFG_BBType_g 0x0002 @@ -392,14 +384,6 @@ #define IMR_RADARDETECT 0x1000 // #define IMR_MEASUREEND 0x0800 // #define IMR_SOFTTIMER1 0x0020 // -//#define IMR_SYNCFLUSHOK 0x0010 // -//#define IMR_ATIMEND 0x0008 // 1000 -//#define IMR_CFPEND 0x0004 // 0100 -//#define IMR_AC3DMA 0x0002 // 0010 -//#define IMR_AC2DMA 0x0001 // 0001 -//#define IMR_AC1DMA 0x8000 // 1000 -//#define IMR_SYNCTX 0x4000 // 0100 -//#define IMR_ATIMTX 0x2000 // 0010 #define IMR_RXDMA1 0x1000 // 0001 #define IMR_RXNOBUF 0x0800 // #define IMR_MIBNEARFULL 0x0400 // @@ -424,14 +408,6 @@ #define ISR_RADARDETECT 0x1000 // #define ISR_MEASUREEND 0x0800 // #define ISR_SOFTTIMER1 0x0020 // -//#define ISR_SYNCFLUSHOK 0x0010 //0001 -//#define ISR_ATIMEND 0x0008 // 1000 -//#define ISR_CFPEND 0x0004 // 0100 -//#define ISR_AC3DMA 0x0002 // 0010 -//#define ISR_AC2DMA 0x0001 // 0001 -//#define ISR_AC1DMA 0x8000 // 1000 -//#define ISR_SYNCTX 0x4000 // 0100 -//#define ISR_ATIMTX 0x2000 // 0010 #define ISR_RXDMA1 0x1000 // 0001 #define ISR_RXNOBUF 0x0800 // 1000 #define ISR_MIBNEARFULL 0x0400 // 0100 -- 1.7.10.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/6] staging: vt6655: Remove all "if 0" blocks from driver
This commit removes code that will never be executed by vt6655 driver.
Was the forgotten-macros tool(https://github.com/marcosps/forgotten_macros)
who reported these blocks for us.
Signed-off-by: Marcos Paulo de Souza
---
drivers/staging/vt6655/device_main.c | 33 --
drivers/staging/vt6655/iwctl.c | 36 -
drivers/staging/vt6655/rf.c | 42 --
drivers/staging/vt6655/wcmd.c| 24 ---
4 files changed, 135 deletions(-)
diff --git a/drivers/staging/vt6655/device_main.c
b/drivers/staging/vt6655/device_main.c
index 3e8283c..d0fefb1 100644
--- a/drivers/staging/vt6655/device_main.c
+++ b/drivers/staging/vt6655/device_main.c
@@ -1086,15 +1086,6 @@ vt6655_probe(struct pci_dev *pcid, const struct
pci_device_id *ent)
device_free_info(pDevice);
return -ENODEV;
}
-//2008-07-21-01by MikeLiu
-//register wpadev
-#if 0
- if(wpa_set_wpadev(pDevice, 1)!=0) {
- printk("Fail to Register WPADEV?\n");
-unregister_netdev(pDevice->dev);
-free_netdev(dev);
- }
-#endif
device_print_info(pDevice);
pci_set_drvdata(pcid, pDevice);
return 0;
@@ -1948,15 +1939,6 @@ device_init_rd0_ring(pDevice);
-#if 0
- pDevice->MLMEThr_pid = kernel_thread(MlmeThread, pDevice, CLONE_VM);
- if (pDevice->MLMEThr_pid <0 )
- {
- printk("unable start thread MlmeThread\n");
- return -1;
- }
-#endif
-
//printk("thread id is %d\n",pDevice->MLMEThr_pid);
//printk("Create thread time is %x\n",jiffies);
//wait_for_completion(>notify);
@@ -2493,21 +2475,6 @@ static int device_xmit(struct sk_buff *skb, struct
net_device *dev) {
&(pDevice->byTopCCKBasicRate),
&(pDevice->byTopOFDMBasicRate));
-#if 0
-printk("auto rate:Rate : %d,AckRate:%d,TopCCKRate:%d,TopOFDMRate:%d\n",
-pDevice->wCurrentRate,pDevice->byACKRate,
-pDevice->byTopCCKBasicRate,pDevice->byTopOFDMBasicRate);
-
-#endif
-
-#if 0
-
- pDevice->wCurrentRate = 11;
- pDevice->byACKRate = 8;
- pDevice->byTopCCKBasicRate = 3;
- pDevice->byTopOFDMBasicRate = 8;
-#endif
-
}
}
diff --git a/drivers/staging/vt6655/iwctl.c b/drivers/staging/vt6655/iwctl.c
index 87288db..77aad7f 100644
--- a/drivers/staging/vt6655/iwctl.c
+++ b/drivers/staging/vt6655/iwctl.c
@@ -84,24 +84,6 @@ struct iw_statistics *iwctl_get_wireless_stats(struct
net_device *dev)
pDevice->wstats.status = pDevice->eOPMode;
#ifdef Calcu_LinkQual
-#if 0
- if(pDevice->byBBType == BB_TYPE_11B) {
-if(pDevice->byCurrSQ > 120)
- pDevice->scStatistic.LinkQuality = 100;
-else
-pDevice->scStatistic.LinkQuality = pDevice->byCurrSQ*100/120;
- }
- else if(pDevice->byBBType == BB_TYPE_11G) {
-if(pDevice->byCurrSQ < 20)
- pDevice->scStatistic.LinkQuality = 100;
- else if(pDevice->byCurrSQ >96)
- pDevice->scStatistic.LinkQuality = 0;
- else
- pDevice->scStatistic.LinkQuality =
(96-pDevice->byCurrSQ)*100/76;
- }
- if(pDevice->bLinkPass !=true)
- pDevice->scStatistic.LinkQuality = 0;
- #endif
if(pDevice->scStatistic.LinkQuality > 100)
pDevice->scStatistic.LinkQuality = 100;
pDevice->wstats.qual.qual =(unsigned char)
pDevice->scStatistic.LinkQuality;
@@ -2004,24 +1986,6 @@ param->u.wpa_key.key = (u8 *)key_array;
param->u.wpa_key.seq = (u8 *)seq;
param->u.wpa_key.seq_len = seq_len;
-#if 0
-printk("param->u.wpa_key.alg_name =%d\n",param->u.wpa_key.alg_name);
-printk(KERN_DEBUG "param->addr=%pM\n", param->addr);
-printk("param->u.wpa_key.set_tx =%d\n",param->u.wpa_key.set_tx);
-printk("param->u.wpa_key.key_index =%d\n",param->u.wpa_key.key_index);
-printk("param->u.wpa_key.key_len =%d\n",param->u.wpa_key.key_len);
-printk("param->u.wpa_key.key =");
-for(ii=0;iiu.wpa_key.key_len;ii++)
- printk("%02x:",param->u.wpa_key.key[ii]);
- printk("\n");
-printk("param->u.wpa_key.seq_len =%d\n",param->u.wpa_key.seq_len);
-printk("param->u.wpa_key.seq =");
-for(ii=0;iiu.wpa_key.seq_len;ii++)
- printk("%02x:",param->u.wpa_key.seq[ii]);
- printk("\n");
-
-printk("...\n");
-#endif
//set if current action is Network Manager count??
//this method is so foolish,but there is no other way???
if(param->u.wpa_key.alg_name == WPA_ALG_NONE) {
diff --git a/drivers/staging/vt6655/rf.c b/drivers/staging/vt6655/rf.c
index b8ec783..a2db0ff 100644
--- a/drivers/staging/vt6655/rf.c
+++ b/drivers/staging/vt6655/rf.c
@@ -1067,48 +1067,6 @@ unsigned char byPwrdBm = 0;
break;
}
-#if 0
-
-// 802.11h TPC
-if (pDevice->bLinkPass == true) {
-// do not over
[PATCH 0/6] staging: vt6655: Cleanup in usage of macros
Hi kernel guys! This patchset aims to clean all unused and commented macros. For this challenge, forgotten-macros tool helped us. As I don't have any vt665x hardware, I will be grateful if anyone can test these changes! This patchset was based in staging-next tree. I hope you enjoy :) Marcos Paulo de Souza (6): staging: vt6655: Remove all "if 0" blocks from driver staging: vt6655: mac.h: Remove all commented macros staging: vt6655: rf.c: Remove all unused macros staging: vt6655: baseband.h: Remove all unused macros staging: vt6655: Remove all commented macros staging: vt6655: hostap.c: Remove all unused macros drivers/staging/vt6655/80211hdr.h|2 - drivers/staging/vt6655/baseband.c|2 - drivers/staging/vt6655/baseband.h| 30 - drivers/staging/vt6655/bssdb.c |1 - drivers/staging/vt6655/desc.h| 11 - drivers/staging/vt6655/device.h | 15 --- drivers/staging/vt6655/device_main.c | 37 drivers/staging/vt6655/dpc.c |1 - drivers/staging/vt6655/hostap.c |6 --- drivers/staging/vt6655/iwctl.c | 36 drivers/staging/vt6655/mac.h | 24 --- drivers/staging/vt6655/mib.h |2 - drivers/staging/vt6655/rf.c | 78 -- drivers/staging/vt6655/rf.h |1 - drivers/staging/vt6655/tether.h |3 -- drivers/staging/vt6655/vntwifi.c |2 - drivers/staging/vt6655/wcmd.c| 24 --- 17 files changed, 275 deletions(-) -- 1.7.10.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 06/11] mm: memcg: move swapin charge functions above callsites
(2012/07/05 9:44), Johannes Weiner wrote: > Charging cache pages may require swapin in the shmem case. Save the > forward declaration and just move the swapin functions above the cache > charging functions. > > Signed-off-by: Johannes Weiner Acked-by: KAMEZAWA Hiroyuki -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 05/11] mm: memcg: only check for PageSwapCache when uncharging anon
(2012/07/05 9:44), Johannes Weiner wrote: > Only anon pages that are uncharged at the time of the last page table > mapping vanishing may be in swapcache. > > When shmem pages, file pages, swap-freed anon pages, or just migrated > pages are uncharged, they are known for sure to be not in swapcache. > > Signed-off-by: Johannes Weiner Acked-by: KAMEZAWA Hiroyuki -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 04/11] mm: memcg: push down PageSwapCache check into uncharge entry functions
(2012/07/05 9:44), Johannes Weiner wrote:
> Not all uncharge paths need to check if the page is swapcache, some of
> them can know for sure.
>
> Push down the check into all callsites of uncharge_common() so that
> the patch that removes some of them is more obvious.
>
> Signed-off-by: Johannes Weiner
> ---
some nitpick.
> mm/memcontrol.c | 18 --
> 1 files changed, 12 insertions(+), 6 deletions(-)
>
> diff --git a/mm/memcontrol.c b/mm/memcontrol.c
> index 4ea19c6..a3bf414 100644
> --- a/mm/memcontrol.c
> +++ b/mm/memcontrol.c
> @@ -2920,8 +2920,7 @@ __mem_cgroup_uncharge_common(struct page *page, enum
> charge_type ctype,
> if (mem_cgroup_disabled())
> return NULL;
>
> - if (PageSwapCache(page))
> - return NULL;
> + VM_BUG_ON(PageSwapCache(page));
>
> if (PageTransHuge(page)) {
> nr_pages <<= compound_order(page);
> @@ -3018,6 +3017,8 @@ void mem_cgroup_uncharge_page(struct page *page)
> if (page_mapped(page))
> return;
> VM_BUG_ON(page->mapping && !PageAnon(page));
> + if (PageSwapCache(page))
> + return;
> __mem_cgroup_uncharge_common(page, MEM_CGROUP_CHARGE_TYPE_ANON, false);
> }
>
> @@ -3025,6 +3026,8 @@ void mem_cgroup_uncharge_cache_page(struct page *page)
> {
> VM_BUG_ON(page_mapped(page));
> VM_BUG_ON(page->mapping);
> + if (PageSwapCache(page))
> + return;
> __mem_cgroup_uncharge_common(page, MEM_CGROUP_CHARGE_TYPE_CACHE, false);
> }
>
> @@ -3089,6 +3092,8 @@ mem_cgroup_uncharge_swapcache(struct page *page,
> swp_entry_t ent, bool swapout)
> if (!swapout) /* this was a swap cache but the swap is unused ! */
> ctype = MEM_CGROUP_CHARGE_TYPE_DROP;
>
> + if (PageSwapCache(page))
> + return;
> memcg = __mem_cgroup_uncharge_common(page, ctype, false);
>
> /*
> @@ -3278,10 +3283,11 @@ void mem_cgroup_end_migration(struct mem_cgroup
> *memcg,
> unused = oldpage;
> }
> anon = PageAnon(used);
> - __mem_cgroup_uncharge_common(unused,
> - anon ? MEM_CGROUP_CHARGE_TYPE_ANON
> - : MEM_CGROUP_CHARGE_TYPE_CACHE,
> - true);
> + if (!PageSwapCache(page))
> + __mem_cgroup_uncharge_common(unused,
> + anon ? MEM_CGROUP_CHARGE_TYPE_ANON
> + : MEM_CGROUP_CHARGE_TYPE_CACHE,
> + true);
!PageSwapCache(unused) ?
But I think unused page's PG_swapcache is always dropped. So, the check is
not necessary.
Thanks,
-Kame
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH SLAB 1/2 v3] duplicate the cache name in SLUB's saved_alias list, SLAB, and SLOB
On Fri, 2012-07-06 at 08:56 -0500, Christoph Lameter wrote:
> I thought I posted this a couple of days ago. Would this not fix things
> without having to change all the allocators?
I was pointed by Glauber to the slab common code patches. I need some
more time to read the patches. Now I think the slab/slot changes in this
v3 are not needed, and can be ignored.
But for the SLUB's saved_alias list issue, I don't think the following
patch helps. Details below: (Maybe I am wrong, as I'm reading the patch
based on the 3.5-rc6 code ...)
>
>
> Subject: slub: Dup name earlier in kmem_cache_create
>
> Dup the name earlier in kmem_cache_create so that alias
> processing is done using the copy of the string and not
> the string itself.
>
> Signed-off-by: Christoph Lameter
>
> ---
> mm/slub.c | 29 ++---
> 1 file changed, 14 insertions(+), 15 deletions(-)
>
> Index: linux-2.6/mm/slub.c
> ===
> --- linux-2.6.orig/mm/slub.c 2012-06-11 08:49:56.0 -0500
> +++ linux-2.6/mm/slub.c 2012-07-03 15:17:37.0 -0500
> @@ -3933,8 +3933,12 @@ struct kmem_cache *kmem_cache_create(con
> if (WARN_ON(!name))
> return NULL;
>
> + n = kstrdup(name, GFP_KERNEL);
> + if (!n)
> + goto out;
> +
> down_write(_lock);
> - s = find_mergeable(size, align, flags, name, ctor);
> + s = find_mergeable(size, align, flags, n, ctor);
> if (s) {
> s->refcount++;
> /*
..
up_write(_lock);
return s;
}
Here, the function returns without name string n be kfreed.
But we couldn't kfree n here, because in sysfs_slab_alias(), if
(slab_state < SYS_FS), the name need to be kept valid until
slab_sysfs_init() is finished adding the entry into sysfs.
> @@ -3944,7 +3948,7 @@ struct kmem_cache *kmem_cache_create(con
> s->objsize = max(s->objsize, (int)size);
> s->inuse = max_t(int, s->inuse, ALIGN(size, sizeof(void *)));
>
> - if (sysfs_slab_alias(s, name)) {
> + if (sysfs_slab_alias(s, n)) {
> s->refcount--;
> goto err;
> }
> @@ -3952,31 +3956,26 @@ struct kmem_cache *kmem_cache_create(con
> return s;
> }
>
> - n = kstrdup(name, GFP_KERNEL);
> - if (!n)
> - goto err;
> -
> s = kmalloc(kmem_size, GFP_KERNEL);
> if (s) {
> if (kmem_cache_open(s, n,
> size, align, flags, ctor)) {
> list_add(>list, _caches);
> up_write(_lock);
> - if (sysfs_slab_add(s)) {
> - down_write(_lock);
> - list_del(>list);
> - kfree(n);
> - kfree(s);
> - goto err;
> - }
> - return s;
> + if (!sysfs_slab_add(s))
> + return s;
> +
> + down_write(_lock);
> + list_del(>list);
> }
> kfree(s);
> }
> - kfree(n);
> +
> err:
> + kfree(n);
> up_write(_lock);
>
> +out:
> if (flags & SLAB_PANIC)
> panic("Cannot create slabcache %s\n", name);
> else
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] mm: Warn about costly page allocation
Since lumpy reclaim was introduced at 2.6.23, it helped higher
order allocation.
Recently, we removed it at 3.4 and we didn't enable compaction
forcingly[1]. The reason makes sense that compaction.o + migration.o
isn't trivial for system doesn't use higher order allocation.
But the problem is that we have to enable compaction explicitly
while lumpy reclaim enabled unconditionally.
Normally, admin doesn't know his system have used higher order
allocation and even lumpy reclaim have helped it.
Admin in embdded system have a tendency to minimise code size so that
they can disable compaction. In this case, we can see page allocation
failure we can never see in the past. It's critical on embedded side
because...
Let's think this scenario.
There is QA team in embedded company and they have tested their product.
In test scenario, they can allocate 100 high order allocation.
(they don't matter how many high order allocations in kernel are needed
during test. their concern is just only working well or fail of their
middleware/application) High order allocation will be serviced well
by natural buddy allocation without lumpy's help. So they released
the product and sold out all over the world.
Unfortunately, in real practice, sometime, 105 high order allocation was
needed rarely and fortunately, lumpy reclaim could help it so the product
doesn't have a problem until now.
If they use latest kernel, they will see the new config CONFIG_COMPACTION
which is very poor documentation, and they can't know it's replacement of
lumpy reclaim(even, they don't know lumpy reclaim) so they simply disable
that option for size optimization. Of course, QA team still test it but they
can't find the problem if they don't do test stronger than old.
It ends up release the product and sold out all over the world, again.
But in this time, we don't have both lumpy and compaction so the problem
would happen in real practice. A poor enginner from Korea have to flight
to the USA for the fix a ton of products. Otherwise, should recall products
from all over the world. Maybe he can lose a job. :(
This patch adds warning for notice. If the system try to allocate
PAGE_ALLOC_COSTLY_ORDER above page and system enters reclaim path,
it emits the warning. At least, it gives a chance to look into their
system before the relase.
This patch avoids false positive by alloc_large_system_hash which
allocates with GFP_ATOMIC and a fallback mechanism so it can make
this warning useless.
[1] c53919ad(mm: vmscan: remove lumpy reclaim)
Signed-off-by: Minchan Kim
---
mm/page_alloc.c | 16
1 file changed, 16 insertions(+)
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index a4d3a19..1155e00 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -2276,6 +2276,20 @@ gfp_to_alloc_flags(gfp_t gfp_mask)
return alloc_flags;
}
+#if defined(CONFIG_DEBUG_VM) && !defined(CONFIG_COMPACTION)
+static inline void check_page_alloc_costly_order(unsigned int order)
+{
+ if (unlikely(order > PAGE_ALLOC_COSTLY_ORDER)) {
+ printk_once("WARNING: You are tring to allocate %d-order page."
+ " You might need to turn on CONFIG_COMPACTION\n", order);
+ }
+}
+#else
+static inline void check_page_alloc_costly_order(unsigned int order)
+{
+}
+#endif
+
static inline struct page *
__alloc_pages_slowpath(gfp_t gfp_mask, unsigned int order,
struct zonelist *zonelist, enum zone_type high_zoneidx,
@@ -2353,6 +2367,8 @@ rebalance:
if (!wait)
goto nopage;
+ check_page_alloc_costly_order(order);
+
/* Avoid recursion of direct reclaim */
if (current->flags & PF_MEMALLOC)
goto nopage;
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH V3 5/6] Avoid duplicate probe for of platform devices
> -Original Message- > From: Greg KH [mailto:g...@kroah.com] > Sent: Saturday, July 07, 2012 12:17 AM > To: Jia Hongtao-B38951 > Cc: Rob Herring; devicetree-disc...@lists.ozlabs.org; linux- > ker...@vger.kernel.org; Li Yang-R58472 > Subject: Re: [PATCH V3 5/6] Avoid duplicate probe for of platform devices > > On Fri, Jul 06, 2012 at 06:07:43AM +, Jia Hongtao-B38951 wrote: > > > > > -Original Message- > > > From: Greg KH [mailto:g...@kroah.com] > > > Sent: Friday, July 06, 2012 12:26 PM > > > To: Jia Hongtao-B38951 > > > Cc: Rob Herring; devicetree-disc...@lists.ozlabs.org; linux- > > > ker...@vger.kernel.org; Li Yang-R58472 > > > Subject: Re: [PATCH V3 5/6] Avoid duplicate probe for of platform > devices > > > > > > On Fri, Jul 06, 2012 at 02:05:05AM +, Jia Hongtao-B38951 wrote: > > > > Hi Rob and Greg KH, > > > > > > > > Do you have any better idea to avoid duplication probe warning? > > > > > > I have no idea what the problem is that you are trying to solve. > > > > > > > > On 06/08/2012 04:43 AM, Jia Hongtao wrote: > > > > > > We changed the pcie controller driver to platform driver so > that > > > the > > > > > PCI > > > > > > of platform devices need to be created earlier in the > arch_initcall > > > > > stage > > > > > > according to the original timing of calling fsl_add_bridge(). > So we > > > do > > > > > PCI > > > > > > probing separately from other devices. But probing more than > once > > > could > > > > > > cause duplication warning. We add check if the devices have > already > > > > > probed > > > > > > before probing any devices to avoid duplication warning. > > > > > > Ick, something else is going wrong here, how could you ever have the > > > same device probed more than once? > > > > > > > > > Signed-off-by: Jia Hongtao > > > > > > Signed-off-by: Li Yang > > > > > > --- > > > > > > > > > > Where's v1 and v2 history? > > > > > > > > > > > drivers/of/platform.c | 18 -- > > > > > > 1 files changed, 12 insertions(+), 6 deletions(-) > > > > > > > > > > > > diff --git a/drivers/of/platform.c b/drivers/of/platform.c > > > > > > index a37330e..3aab01f 100644 > > > > > > --- a/drivers/of/platform.c > > > > > > +++ b/drivers/of/platform.c > > > > > > @@ -139,6 +139,18 @@ struct platform_device > *of_device_alloc(struct > > > > > device_node *np, > > > > > > if (!dev) > > > > > > return NULL; > > > > > > > > > > > > + dev->dev.of_node = of_node_get(np); > > > > > > + if (bus_id) > > > > > > + dev_set_name(>dev, "%s", bus_id); > > > > > > + else > > > > > > + of_device_make_bus_id(>dev); > > > > > > + > > > > > > + if (kset_find_obj(dev->dev.kobj.kset, kobject_name( > > > >dev.kobj))) > > > > > > Whatever you are trying to do here, odds are, it's wrong :) > > > > > > What is happening that is causing the problem? What is causing the > > > platform core to be calling probe on a device more than once? > > > > > > greg k-h > > > > This is why in some cases we may probe twice: > > Firstly, we need to probe pci controller separately. But in KVM > different > > topology of device tree is used in which pci nodes are not under root > node > > but under "simple bus". Unfortunately, of_platform_bus_probe() will > probe > > all the first level nodes under "simple bus" so pci nodes will probe > again. > > Sounds like a bug :) > > > Two ways to solve this problem: > > 1. All the nodes that need to be probed should just under root. > > That seems reasonable. > > > 2. Avoid duplication probe at runtime like this patch did. > > No, don't paper over the real problem in the platform core code like > this. Fix the real issue here instead. > > > I do like the first one but it's hard to changing the traditional way > that > > exist for a long time. > > I don't understand, why is this just showing up now? What changed to > cause this? Couldn't that be the real problem here? > The issue is showing up because we now probe devices twice. Previously, we just probe devices once. But now we changed the way of pci init which makes pci controllers should be probed earlier than other devices. So we have to probe pci nodes separately. Probe more than once is the root cause of this issue. The pci patchset I mentioned please refer to: http://patchwork.ozlabs.org/patch/163742/ - Jia Hongtao. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 03/11] mm: shmem: do not try to uncharge known swapcache pages
(2012/07/05 9:44), Johannes Weiner wrote: > Once charged, swapcache pages can only be uncharged after they are > removed from swapcache again. > > Do not try to uncharge pages that are known to be in the swapcache, to > allow future patches to remove checks for that in the uncharge code. > > Signed-off-by: Johannes Weiner > --- Acked-by: KAMEZAWA Hiroyuki -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 02/11] mm: swapfile: clean up unuse_pte race handling
(2012/07/05 9:44), Johannes Weiner wrote: > The conditional mem_cgroup_cancel_charge_swapin() is a leftover from > when the function would continue to reestablish the page even after > mem_cgroup_try_charge_swapin() failed. After 85d9fc8 "memcg: fix > refcnt handling at swapoff", the condition is always true when this > code is reached. > > Signed-off-by: Johannes Weiner Acked-by: KAMEZAWA Hiroyuki -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] acpi : cpu hot-remove returns error number when cpu_down() fails
Hi Srivatsa,
Thank you for your reviewing.
2012/07/06 18:51, Srivatsa S. Bhat wrote:
> On 07/06/2012 08:46 AM, Yasuaki Ishimatsu wrote:
>> Even if cpu_down() fails, acpi_processor_remove() continues to remove the
>> cpu.
>
> Ouch!
>
>> But in this case, it should return error number since some process may run on
>> the cpu. If the cpu has a running process and the cpu is turned the power
>> off,
>> the system cannot work well.
>>
>> Signed-off-by: Yasuaki Ishimatsu
>>
>> ---
>> drivers/acpi/processor_driver.c | 18 --
>> 1 file changed, 12 insertions(+), 6 deletions(-)
>>
>> Index: linux-3.5-rc4/drivers/acpi/processor_driver.c
>> ===
>> --- linux-3.5-rc4.orig/drivers/acpi/processor_driver.c 2012-06-25
>> 04:53:04.0 +0900
>> +++ linux-3.5-rc4/drivers/acpi/processor_driver.c2012-07-05
>> 21:02:58.711285382 +0900
>> @@ -610,7 +610,7 @@ err_free_pr:
>> static int acpi_processor_remove(struct acpi_device *device, int type)
>> {
>> struct acpi_processor *pr = NULL;
>> -
>> +int ret;
>>
>> if (!device || !acpi_driver_data(device))
>> return -EINVAL;
>> @@ -621,8 +621,9 @@ static int acpi_processor_remove(struct
>> goto free;
>>
>> if (type == ACPI_BUS_REMOVAL_EJECT) {
>> -if (acpi_processor_handle_eject(pr))
>> -return -EINVAL;
>> +ret = acpi_processor_handle_eject(pr);
>> +if (ret)
>> +return ret;
>> }
>>
>> acpi_processor_power_exit(pr, device);
>> @@ -841,12 +842,17 @@ static acpi_status acpi_processor_hotadd
>>
>> static int acpi_processor_handle_eject(struct acpi_processor *pr)
>> {
>> -if (cpu_online(pr->id))
>> -cpu_down(pr->id);
>> +int ret;
>> +
>> +if (cpu_online(pr->id)) {
>> +ret = cpu_down(pr->id);
>> +if (ret)
>> +return ret;
>> +}
>>
>
> Strictly speaking, this is not thorough enough. What prevents someone
> from onlining that same cpu again, at this point?
> So, IMHO, you need to wrap the contents of this function inside a
> get_online_cpus()/put_online_cpus() block, to prevent anyone else
> from messing with CPU hotplug at the same time.
If I understand your comment by mistake, please let me know.
If the contents is wrapped a inside get_online_cpus()/put_online_cpus() block
as below, cpu_down() will stop since cpu_down() calls cpu_hotplug_begin() and
cpu_hotplug_begin() waits for cpu_hotplug.refcount to become 0.
+ get_online_cpus()
+ if (cpu_online(pr->id)) {
+ ret = cpu_down(pr->id);
+ if (ret)
+ return ret;
+ }
+ put_online_cpus()
I think following patch can prevent it correctly. How about the patch?
---
drivers/acpi/processor_driver.c | 12
kernel/cpu.c|8 +---
2 files changed, 17 insertions(+), 3 deletions(-)
Index: linux-3.5-rc4/drivers/acpi/processor_driver.c
===
--- linux-3.5-rc4.orig/drivers/acpi/processor_driver.c 2012-07-09
09:59:01.280211202 +0900
+++ linux-3.5-rc4/drivers/acpi/processor_driver.c 2012-07-09
11:05:34.559859236 +0900
@@ -844,14 +844,26 @@ static int acpi_processor_handle_eject(s
{
int ret;
+retry:
if (cpu_online(pr->id)) {
ret = cpu_down(pr->id);
if (ret)
return ret;
}
+ get_online_cpus();
+ /*
+* Someone might online the cpu again at this point. So we check that
+* cpu has been onlined or not. If cpu is online, we try to offline
+* the cpu again.
+*/
+ if (cpu_online(pr->id)) {
+ put_online_cpus();
+ goto retry;
+ }
arch_unregister_cpu(pr->id);
acpi_unmap_lsapic(pr->id);
+ put_online_cpus();
return ret;
}
#else
Index: linux-3.5-rc4/kernel/cpu.c
===
--- linux-3.5-rc4.orig/kernel/cpu.c 2012-07-09 09:59:01.280211202 +0900
+++ linux-3.5-rc4/kernel/cpu.c 2012-07-09 09:59:02.903190965 +0900
@@ -343,11 +343,13 @@ static int __cpuinit _cpu_up(unsigned in
unsigned long mod = tasks_frozen ? CPU_TASKS_FROZEN : 0;
struct task_struct *idle;
- if (cpu_online(cpu) || !cpu_present(cpu))
- return -EINVAL;
-
cpu_hotplug_begin();
+ if (cpu_online(cpu) || !cpu_present(cpu)) {
+ ret = -EINVAL;
+ goto out;
+ }
+
idle = idle_thread_get(cpu);
if (IS_ERR(idle)) {
ret = PTR_ERR(idle);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at
Re: [patch 01/11] mm: memcg: fix compaction/migration failing due to memcg limits
(2012/07/05 9:44), Johannes Weiner wrote: > Compaction (and page migration in general) can currently be hindered > through pages being owned by memory cgroups that are at their limits > and unreclaimable. > > The reason is that the replacement page is being charged against the > limit while the page being replaced is also still charged. But this > seems unnecessary, given that only one of the two pages will still be > in use after migration finishes. > > This patch changes the memcg migration sequence so that the > replacement page is not charged. Whatever page is still in use after > successful or failed migration gets to keep the charge of the page > that was going to be replaced. > > Reported-by: David Rientjes > Signed-off-by: Johannes Weiner Acked-by: KAMEZAWA Hiroyuki -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/2] genirq: export dummy_irq_chip
Export dummy_irq_chip to modules to allow them to do things such as
irq_set_chip_and_handler(virq,
_irq_chip,
handle_level_irq);
This fixes
ERROR: "dummy_irq_chip" [drivers/gpio/gpio-pcf857x.ko] undefined!
when gpio-pcf857x.c is being built as a module.
Signed-off-by: Kuninori Morimoto
---
kernel/irq/dummychip.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/kernel/irq/dummychip.c b/kernel/irq/dummychip.c
index b5fcd96..988dc58 100644
--- a/kernel/irq/dummychip.c
+++ b/kernel/irq/dummychip.c
@@ -6,6 +6,7 @@
*/
#include
#include
+#include
#include "internals.h"
@@ -57,3 +58,4 @@ struct irq_chip dummy_irq_chip = {
.irq_mask = noop,
.irq_unmask = noop,
};
+EXPORT_SYMBOL_GPL(dummy_irq_chip);
--
1.7.5.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/2] genirq: export irq_set_chip_and_handler_name()
Export irq_set_chip_and_handler_name() to modules to allow them to
do things such as
irq_set_chip_and_handler(virq,
_irq_chip,
handle_level_irq);
This fixes
ERROR: "irq_set_chip_and_handler_name" \
[drivers/gpio/gpio-pcf857x.ko] undefined!
when gpio-pcf857x.c is being built as a module.
Signed-off-by: Kuninori Morimoto
---
kernel/irq/chip.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/kernel/irq/chip.c b/kernel/irq/chip.c
index eebd6d5..57d86d0 100644
--- a/kernel/irq/chip.c
+++ b/kernel/irq/chip.c
@@ -671,6 +671,7 @@ irq_set_chip_and_handler_name(unsigned int irq, struct
irq_chip *chip,
irq_set_chip(irq, chip);
__irq_set_handler(irq, handle, 0, name);
}
+EXPORT_SYMBOL_GPL(irq_set_chip_and_handler_name);
void irq_modify_status(unsigned int irq, unsigned long clr, unsigned long set)
{
--
1.7.5.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
linux-next: manual merge of the infiniband tree with Linus' tree
Hi all,
Today's linux-next merge of the infiniband tree got a conflict in
drivers/infiniband/hw/ocrdma/ocrdma_main.c between commit 6ab6827ee999
("RDMA/ocrdma: Fixed GID table for vlan and events") from Linus' tree and
commit 898648347205 ("IB: Use IS_ENABLED(CONFIG_IPV6)") from the
infiniband tree.
I fixed it up (see below) and can carry the fix as necessary.
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc drivers/infiniband/hw/ocrdma/ocrdma_main.c
index b050e62,93c9462..000
--- a/drivers/infiniband/hw/ocrdma/ocrdma_main.c
+++ b/drivers/infiniband/hw/ocrdma/ocrdma_main.c
@@@ -202,8 -197,7 +202,7 @@@ static int ocrdma_build_sgid_tbl(struc
return 0;
}
- #if defined(CONFIG_IPV6) || defined(CONFIG_IPV6_MODULE) || \
- defined(CONFIG_VLAN_8021Q) || defined(CONFIG_VLAN_8021Q_MODULE)
-#if IS_ENABLED(CONFIG_IPV6)
++#if IS_ENABLED(CONFIG_IPV6) || IS_ENABLED(CONFIG_VLAN_8021Q)
static int ocrdma_inet6addr_event(struct notifier_block *notifier,
unsigned long event, void *ptr)
pgpRy2b4if145.pgp
Description: PGP signature
Re: linux-next: build failure after merge of the gpio-lw tree
Hi Linus Walleij, Stephen, and Thomas > >> > After merging the gpio-lw tree, today's linux-next build (x86_64 > >> > allmodconfig) failed like this: > >> > > >> > ERROR: "irq_set_chip_and_handler_name" [drivers/gpio/gpio-pcf857x.ko] > >> > undefined! > >> > ERROR: "dummy_irq_chip" [drivers/gpio/gpio-pcf857x.ko] undefined! > >> > >> Thanks, I've dropped the offending patch, Kuninori can you look into this > >> and > >> provide a new patch? It's the second patch from your patch set. > > > > OK. I will, but it will be next week. > > And could you please show me where is your repository/branch ? > > http://git.kernel.org/?p=linux/kernel/git/linusw/linux-gpio.git;a=summary > branch devel/for-next In my check, these are export symbol issue. I think above 2 function/struct were not exported for module. Is it poosible to solve this issue by these patches ? Kuninori Morimoto (2): genirq: export irq_set_chip_and_handler_name() genirq: export dummy_irq_chip kernel/irq/chip.c |1 + kernel/irq/dummychip.c |2 ++ 2 files changed, 3 insertions(+), 0 deletions(-) Best regards --- Kuninori Morimoto -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 00/36] AArch64 Linux kernel port
On 07/08/2012 06:24 PM, Dennis Gilmore wrote:
> I know that the architecture really is new but thats not really clear
> by adding AArch32 into the mix to represent 32 bit arm as ARM has done
> or by calling it armv8. There is enough way to confuse them already why
> confuse things more by adding yet another variable that is AArch64.
> - From my and most of the other Fedora developers that i've discussed it
> with its more like reluctant acceptance of AArch64 than thinking is a
> good idea.
btw, for clarification of anyone who is confused by the names...the new
architecture is ARMv8. The 64-bit state is AArch64, during which the
processor executes A64 instructions. The 32-bit state is AArch32, during
which the processor executes either A32 ("ARM" version 7+) or T32
("Thumb" - I guess Thumb2+ really due to some of deprecation)
instructions. I've noticed that there appears to be a clarification
effort in which AArch64 is used as an architecture name when ARMv8 would
be confusing, which is most of the time if you don't know whether you're
referring to the new A64 instruction set or the older ones.
Perhaps this is useful if someone is trying to figure out heads or tails
of the different terms.
Jon.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 5/5] staging: vt6656: Remove unsed macros
These macros were reported by forgotten-macros tool
(https://github.com/marcosps/forgotten_macros).
Signed-off-by: Marcos Paulo de Souza
---
drivers/staging/vt6656/card.c|1 -
drivers/staging/vt6656/channel.c |2 --
drivers/staging/vt6656/rxtx.c|2 --
3 files changed, 5 deletions(-)
diff --git a/drivers/staging/vt6656/card.c b/drivers/staging/vt6656/card.c
index 9d09e9f..e3ddc0b 100644
--- a/drivers/staging/vt6656/card.c
+++ b/drivers/staging/vt6656/card.c
@@ -66,7 +66,6 @@ static int msglevel=MSG_LEVEL_INFO;
/*- Static Definitions -*/
-#define CB_TXPOWER_LEVEL6
/*- Static Classes */
diff --git a/drivers/staging/vt6656/channel.c b/drivers/staging/vt6656/channel.c
index 99e054d..6502176 100644
--- a/drivers/staging/vt6656/channel.c
+++ b/drivers/staging/vt6656/channel.c
@@ -368,8 +368,6 @@ static struct
/* 1 2 3 4 5 6 7 8 9
10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29
30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49
50 51 52 53 54 55 56 */
};
-#define NUM_RULES ARRAY_SIZE(ChannelRuleTab)
-
/*- Export function -*/
/
* Country Channel Valid
diff --git a/drivers/staging/vt6656/rxtx.c b/drivers/staging/vt6656/rxtx.c
index 9b64b10..bb46452 100644
--- a/drivers/staging/vt6656/rxtx.c
+++ b/drivers/staging/vt6656/rxtx.c
@@ -73,8 +73,6 @@ static int msglevel= MSG_LEVEL_INFO;
/*- Static Functions --*/
/*- Static Definitions -*/
-#define CRITICAL_PACKET_LEN 256// if packet size < 256 -> in-direct
send
-//packet size >= 256 -> direct send
const WORD wTimeStampOff[2][MAX_RATE] = {
{384, 288, 226, 209, 54, 43, 37, 31, 28, 25, 24, 23}, // Long Preamble
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 4/5] staging: vt6656: Remove all commented macros
These macros were reported by forgotten-macros tool
(https://github.com/marcosps/forgotten_macros).
Signed-off-by: Marcos Paulo de Souza
---
drivers/staging/vt6656/80211hdr.h |2 --
drivers/staging/vt6656/bssdb.h|2 --
drivers/staging/vt6656/card.h |1 -
drivers/staging/vt6656/device.h |4
drivers/staging/vt6656/main_usb.c |5 -
drivers/staging/vt6656/mib.h |1 -
drivers/staging/vt6656/tether.h |2 --
drivers/staging/vt6656/usbpipe.c |3 ---
8 files changed, 20 deletions(-)
diff --git a/drivers/staging/vt6656/80211hdr.h
b/drivers/staging/vt6656/80211hdr.h
index 15c6ef1..b87d543 100644
--- a/drivers/staging/vt6656/80211hdr.h
+++ b/drivers/staging/vt6656/80211hdr.h
@@ -78,7 +78,6 @@
#define WLAN_HDR_ADDR4_LEN 30
#define WLAN_IEHDR_LEN 2
#define WLAN_SSID_MAXLEN32
-/* #define WLAN_RATES_MAXLEN 255 */
#define WLAN_RATES_MAXLEN 16
#define WLAN_RATES_MAXLEN_11B 4
#define WLAN_RSN_MAXLEN 32
@@ -104,7 +103,6 @@
#define WLAN_WEP40_KEYLEN 5
#define WLAN_WEP104_KEYLEN 13
#define WLAN_WEP232_KEYLEN 29
-/* #define WLAN_WEPMAX_KEYLEN 29 */
#define WLAN_WEPMAX_KEYLEN 32
#define WLAN_CHALLENGE_IE_MAXLEN255
#define WLAN_CHALLENGE_IE_LEN 130
diff --git a/drivers/staging/vt6656/bssdb.h b/drivers/staging/vt6656/bssdb.h
index a8f97eb..6b2ec39 100644
--- a/drivers/staging/vt6656/bssdb.h
+++ b/drivers/staging/vt6656/bssdb.h
@@ -64,8 +64,6 @@
// send and receive non-IEEE 802.1X frames
#define WLAN_STA_AUTHORIZED BIT5
-//#define MAX_RATE12
-
#define MAX_WPA_IE_LEN 64
diff --git a/drivers/staging/vt6656/card.h b/drivers/staging/vt6656/card.h
index 9cf71a3..55962b1 100644
--- a/drivers/staging/vt6656/card.h
+++ b/drivers/staging/vt6656/card.h
@@ -52,7 +52,6 @@ typedef enum _CARD_OP_MODE {
} CARD_OP_MODE, *PCARD_OP_MODE;
#define CB_MAX_CHANNEL_24G 14
-/* #define CB_MAX_CHANNEL_5G 24 */
#define CB_MAX_CHANNEL_5G 42 /* add channel9(5045MHz), 41==>42 */
#define CB_MAX_CHANNEL (CB_MAX_CHANNEL_24G+CB_MAX_CHANNEL_5G)
diff --git a/drivers/staging/vt6656/device.h b/drivers/staging/vt6656/device.h
index f1496ec..171dd68 100644
--- a/drivers/staging/vt6656/device.h
+++ b/drivers/staging/vt6656/device.h
@@ -106,10 +106,6 @@
#define MAX_MULTICAST_ADDRESS_NUM 32
#define MULTICAST_ADDRESS_LIST_SIZE (MAX_MULTICAST_ADDRESS_NUM * ETH_ALEN)
-//#define OP_MODE_INFRASTRUCTURE 0
-//#define OP_MODE_ADHOC 1
-//#define OP_MODE_AP 2
-
#define DUPLICATE_RX_CACHE_LENGTH 5
#define NUM_KEY_ENTRY 11
diff --git a/drivers/staging/vt6656/main_usb.c
b/drivers/staging/vt6656/main_usb.c
index 5048341..b06fd5b 100644
--- a/drivers/staging/vt6656/main_usb.c
+++ b/drivers/staging/vt6656/main_usb.c
@@ -205,11 +205,6 @@ static const long frequency_list[] = {
};
-#ifndef IW_ENCODE_NOKEY
-#define IW_ENCODE_NOKEY 0x0800
-#define IW_ENCODE_MODE (IW_ENCODE_DISABLED | IW_ENCODE_RESTRICTED |
IW_ENCODE_OPEN)
-#endif
-
static const struct iw_handler_def iwctl_handler_def;
*/
diff --git a/drivers/staging/vt6656/mib.h b/drivers/staging/vt6656/mib.h
index a89cca0..82d69a9 100644
--- a/drivers/staging/vt6656/mib.h
+++ b/drivers/staging/vt6656/mib.h
@@ -113,7 +113,6 @@ typedef struct tagSMib2Counter {
} SMib2Counter, *PSMib2Counter;
// Value in the ifType entry
-//#define ETHERNETCSMACD 6 //
#define WIRELESSLANIEEE80211b 6 //
// Value in the ifAdminStatus/ifOperStatus entry
diff --git a/drivers/staging/vt6656/tether.h b/drivers/staging/vt6656/tether.h
index 4ec0523..8c1f5d2 100644
--- a/drivers/staging/vt6656/tether.h
+++ b/drivers/staging/vt6656/tether.h
@@ -72,7 +72,6 @@
#define TYPE_CTL_ACK0xd400
-//#define WEP_IV_MASK 0xFF00
#else //if LITTLE_ENDIAN
//
@@ -111,7 +110,6 @@
#define TYPE_CTL_ACK0x00d4
-//#define WEP_IV_MASK 0x00FF
#endif //#ifdef __BIG_ENDIAN
diff --git a/drivers/staging/vt6656/usbpipe.c b/drivers/staging/vt6656/usbpipe.c
index c612ab5..609e8fa 100644
--- a/drivers/staging/vt6656/usbpipe.c
+++ b/drivers/staging/vt6656/usbpipe.c
@@ -52,9 +52,6 @@
//endpoint 2: read bulk
//endpoint 3: write bulk
-//RequestType:
-//#define REQUEST_OUT (USB_DIR_OUT | USB_TYPE_VENDOR | USB_RECIP_DEVICE)
// 0x40
-//#define REQUEST_IN(USB_DIR_IN | USB_TYPE_VENDOR | USB_RECIP_DEVICE )
//0xc0
//static int msglevel=MSG_LEVEL_DEBUG;
static int msglevel=MSG_LEVEL_INFO;
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/5] staging: vt6656: hostap.c: Remove commented code
Signed-off-by: Marcos Paulo de Souza
---
drivers/staging/vt6656/hostap.c | 43 ---
1 file changed, 43 deletions(-)
diff --git a/drivers/staging/vt6656/hostap.c b/drivers/staging/vt6656/hostap.c
index f578095..682002a 100644
--- a/drivers/staging/vt6656/hostap.c
+++ b/drivers/staging/vt6656/hostap.c
@@ -294,37 +294,6 @@ static int hostap_get_info_sta(PSDevice pDevice,
return 0;
}
-/*
- * Description:
- * reset txexec
- *
- * Parameters:
- * In:
- * pDevice -
- * param -
- * Out:
- * TURE, FALSE
- *
- * Return Value:
- *
- */
-/*
-static int hostap_reset_txexc_sta(PSDevice pDevice,
- struct viawget_hostapd_param *param)
-{
-PSMgmtObjectpMgmt = &(pDevice->sMgmtObj);
- unsigned int uNodeIndex;
-
-if (BSSbIsSTAInNodeDB(pDevice, param->sta_addr, )) {
-pMgmt->sNodeDBTable[uNodeIndex].uTxAttempts = 0;
- }
- else {
- return -ENOENT;
- }
-
- return 0;
-}
-*/
/*
* Description:
@@ -459,12 +428,6 @@ static int hostap_set_encryption(PSDevice pDevice,
param->u.crypt.err = 0;
-/*
- if (param_len !=
- (int) ((char *) param->u.crypt.key - (char *) param) +
- param->u.crypt.key_len)
- return -EINVAL;
-*/
if (param->u.crypt.alg > WPA_ALG_CCMP)
return -EINVAL;
@@ -794,12 +757,6 @@ int vt6656_hostap_ioctl(PSDevice pDevice, struct iw_point
*p)
ret = hostap_get_info_sta(pDevice, param);
ap_ioctl = 1;
break;
-/*
- case VIAWGET_HOSTAPD_RESET_TXEXC_STA:
- DBG_PRT(MSG_LEVEL_DEBUG, KERN_INFO "VIAWGET_HOSTAPD_RESET_TXEXC_STA
\n");
-ret = hostap_reset_txexc_sta(pDevice, param);
- break;
-*/
case VIAWGET_HOSTAPD_SET_FLAGS_STA:
DBG_PRT(MSG_LEVEL_DEBUG, KERN_INFO "VIAWGET_HOSTAPD_SET_FLAGS_STA
\n");
ret = hostap_set_flags_sta(pDevice, param);
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/5] staging: vt6656: hostap.c: Remove unused macros and some useless comments
The unused macros were reporteds by forgotten-macros tool(https://github.com/marcosps/forgotten_macros). Signed-off-by: Marcos Paulo de Souza --- drivers/staging/vt6656/hostap.c | 20 1 file changed, 20 deletions(-) diff --git a/drivers/staging/vt6656/hostap.c b/drivers/staging/vt6656/hostap.c index 51b5adf..f578095 100644 --- a/drivers/staging/vt6656/hostap.c +++ b/drivers/staging/vt6656/hostap.c @@ -41,31 +41,11 @@ #define VIAWGET_HOSTAPD_MAX_BUF_SIZE 1024 #define HOSTAP_CRYPT_FLAG_SET_TX_KEY BIT0 -#define HOSTAP_CRYPT_FLAG_PERMANENT BIT1 -#define HOSTAP_CRYPT_ERR_UNKNOWN_ALG 2 #define HOSTAP_CRYPT_ERR_UNKNOWN_ADDR 3 -#define HOSTAP_CRYPT_ERR_CRYPT_INIT_FAILED 4 #define HOSTAP_CRYPT_ERR_KEY_SET_FAILED 5 -#define HOSTAP_CRYPT_ERR_TX_KEY_SET_FAILED 6 -#define HOSTAP_CRYPT_ERR_CARD_CONF_FAILED 7 - -/*- Static Definitions -*/ - -/*- Static Classes */ - -/*- Static Variables --*/ -//static int msglevel=MSG_LEVEL_DEBUG; static int msglevel=MSG_LEVEL_INFO; -/*- Static Functions --*/ - - - - -/*- Export Variables --*/ - - /* * Description: * register net_device (AP) for hostap deamon -- 1.7.10.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/5] staging: vt6656: desc.h: Remove commented macros and useless comments
The commented macros are reported by forgotten-macros
tool(https://github.com/marcosps/forgotten_macros).
Signed-off-by: Marcos Paulo de Souza
---
drivers/staging/vt6656/desc.h | 19 ---
1 file changed, 19 deletions(-)
diff --git a/drivers/staging/vt6656/desc.h b/drivers/staging/vt6656/desc.h
index 767112b..b68b2ec 100644
--- a/drivers/staging/vt6656/desc.h
+++ b/drivers/staging/vt6656/desc.h
@@ -36,8 +36,6 @@
#include "ttype.h"
#include "tether.h"
-/*- Export Definitions -*/
-
// max transmit or receive buffer size
#define CB_MAX_BUF_SIZE 2900U // max buffer size
// NOTE: must be multiple of 4
@@ -120,17 +118,11 @@
#define FRAGCTL_TKIP0x0200 // 0010
#define FRAGCTL_LEGACY 0x0100 // 0001
#define FRAGCTL_NONENCRYPT 0x //
-//#define FRAGCTL_AC3 0x000C // 1100
-//#define FRAGCTL_AC2 0x0008 // 1000
-//#define FRAGCTL_AC1 0x0004 // 0100
-//#define FRAGCTL_AC0 0x //
#define FRAGCTL_ENDFRAG 0x0003 // 0011
#define FRAGCTL_MIDFRAG 0x0002 // 0010
#define FRAGCTL_STAFRAG 0x0001 // 0001
#define FRAGCTL_NONFRAG 0x //
-//#define TYPE_AC0DMA 0
-//#define TYPE_TXDMA0 1
#define TYPE_TXDMA0 0
#define TYPE_AC0DMA 1
#define TYPE_ATIMDMA2
@@ -147,9 +139,6 @@
#define TD_FLAGS_NETIF_SKB 0x01 // check if need release
skb
#define TD_FLAGS_PRIV_SKB0x02 // check if called from
private skb(hostap)
#define TD_FLAGS_PS_RETRY0x04 // check if PS STA frame
re-transmit
-//#define TD_FLAGS_NETIF_SKB0x04
-
-/*- Export Types --*/
//
// RsvTime buffer header
@@ -268,7 +257,6 @@ SRTS_a_FB, *PSRTS_a_FB;
typedef const SRTS_a_FB *PCSRTS_a_FB;
-
//
// CTS buffer header
//
@@ -421,12 +409,5 @@ typedef struct tagSKeyEntry {
DWORD dwKey4[4];
} __attribute__ ((__packed__))
SKeyEntry;
-/*- Export Macros --*/
-
-/*- Export Classes */
-
-/*- Export Variables --*/
-
-/*- Export Functions --*/
#endif /* __DESC_H__ */
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/5] staging: vt6656: Cleanup in usage of macros
Hi kernel guys! This patchset aims to clean all the macros from vt6656 driver. With the forgotten-macros tool(https://github.com/marcosps/forgotten_macros), we can find all unused macros, commented macros and a little more. :) As I don't have the hardware, I will be grateful if anyone could test theses changes. All the changes were based in staging-next tree. Comments are welcome! Marcos Paulo de Souza (5): staging: vt6656: desc.h: Remove commented macros and useless comments staging: vt6656: hostap.c: Remove unused macros and some useless comments staging: vt6656: hostap.c: Remove commented code staging: vt6656: Remove all commented macros staging: vt6656: Remove unsed macros drivers/staging/vt6656/80211hdr.h |2 -- drivers/staging/vt6656/bssdb.h|2 -- drivers/staging/vt6656/card.c |1 - drivers/staging/vt6656/card.h |1 - drivers/staging/vt6656/channel.c |2 -- drivers/staging/vt6656/desc.h | 19 --- drivers/staging/vt6656/device.h |4 --- drivers/staging/vt6656/hostap.c | 63 - drivers/staging/vt6656/main_usb.c |5 --- drivers/staging/vt6656/mib.h |1 - drivers/staging/vt6656/rxtx.c |2 -- drivers/staging/vt6656/tether.h |2 -- drivers/staging/vt6656/usbpipe.c |3 -- 13 files changed, 107 deletions(-) -- 1.7.10.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: perf lock record fails
On 7/6/12 7:06 PM, Namhyung Kim wrote: Hi, David On Fri, 06 Jul 2012 11:27:39 -0600, David Ahern wrote: What config options need to be enabled for 'perf lock record' to work? I tried a number of custom builds and stock Fedora kernels. I always get: $ perf lock record -- sleep 1 invalid or unsupported event: 'lock:lock_acquire' Though trace_lock_acquire exists, CONFIG_LOCKDEP is set, and ftrace is enabled. What am I missing? Weird. AFAICS lock_acquire and lock_release depend on CONFIG_LOCKDEP, and lock_acquired and lock_contented depend on CONFIG_LOCK_STAT (I guess it should be warned/commented somewhere?). Maybe CONFIG_EVENT_TRACING? CONFIG_EVENT_TRACING is set. I started a comparison with other tracepoints to see if I can decipher why they show up but none of the trace functions for the lock system do (e.g., lock_acquire), but haven't had much time to spend on it. I was hoping Steve or Frederic could explain it quicker. ;-) David -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: WARNING: __GFP_FS allocations with IRQs disabled (kmemcheck_alloc_shadow)
On Sun, Jul 08, 2012 at 04:01:44PM -0700, David Rientjes wrote:
> On Mon, 9 Jul 2012, JoonSoo Kim wrote:
>
> > diff --git a/mm/slub.c b/mm/slub.c
> > index 8c691fa..5d41cad 100644
> > --- a/mm/slub.c
> > +++ b/mm/slub.c
> > @@ -1324,8 +1324,14 @@ static struct page *allocate_slab(struct
> > kmem_cache *s, gfp_t flags, int node)
> > && !(s->flags & (SLAB_NOTRACK | DEBUG_DEFAULT_FLAGS))) {
> > int pages = 1 << oo_order(oo);
> >
> > + if (flags & __GFP_WAIT)
> > + local_irq_enable();
> > +
> > kmemcheck_alloc_shadow(page, oo_order(oo), flags, node);
> >
> > + if (flags & __GFP_WAIT)
> > + local_irq_disable();
> > +
> > /*
> > * Objects from caches that have a constructor don't get
> > * cleared when they're allocated, so we need to do it here.
>
> This patch is suboptimal when the branch is taken since you just disabled
> irqs and now are immediately reenabling them and then disabling them
> again. (And your patch is also whitespace damaged, has no changelog, and
> isn't signed off so it can't be applied.)
Agreed.
> The correct fix is what I proposed at
> http://marc.info/?l=linux-kernel=133754837703630 and was awaiting
> testing. If Rus, Steven, or Fengguang could test this then we could add
> it as a stable backport as well.
Acked-by: Fengguang Wu
Tested-by: Fengguang Wu
Thanks,
Fengguang
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
linux-next: build failure after merge of the v4l-dvb tree
Hi Mauro,
After merging the v4l-dvb tree, today's linux-next build (x86_64
allmodconfig) failed like this:
usr/include/linux/v4l2-subdev.h:28: included file 'linux/v4l2-common.h' is not
exported
usr/include/linux/videodev2.h:63: included file 'linux/v4l2-common.h' is not
exported
Introduced by commit 5689b28890f4 ("[media] v4l: Unify selection targets
across V4L2 and V4L2 subdev interfaces").
I have used the v4l-dvb tree from next-20120706 for today.
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
pgp3WLsQlZZMw.pgp
Description: PGP signature
Re: [PATCH powerpc 2/2] kfree the cache name of pgtable cache if SLUB is used
On Fri, 2012-07-06 at 14:13 +0400, Glauber Costa wrote: > On 07/05/2012 01:29 PM, Li Zhong wrote: > > On Thu, 2012-07-05 at 12:23 +0400, Glauber Costa wrote: > >> On 07/05/2012 05:41 AM, Li Zhong wrote: > >>> On Wed, 2012-07-04 at 16:40 +0400, Glauber Costa wrote: > On 07/04/2012 01:00 PM, Li Zhong wrote: > > On Tue, 2012-07-03 at 15:36 -0500, Christoph Lameter wrote: > >>> Looking through the emails it seems that there is an issue with alias > >>> strings. > > To be more precise, there seems no big issue currently. I just wanted to > > make following usage of kmem_cache_create (SLUB) possible: > > > > name = some string kmalloced > > kmem_cache_create(name, ...) > > kfree(name); > > Out of curiosity: Why? > This is not (currently) possible with the other allocators (may change > with christoph's unification patches), so you would be making your code > slub-dependent. > > >>> > >>> For slub itself, I think it's not good that: in some cases, the name > >>> string could be kfreed ( if it was kmalloced ) immediately after calling > >>> the cache create; in some other case, the name string needs to be kept > >>> valid until some init calls finished. > >>> > >>> I agree with you that it would make the code slub-dependent, so I'm now > >>> working on the consistency of the other allocators regarding this name > >>> string duplicating thing. > >> > >> If you really need to kfree the string, or even if it is easier for you > >> this way, it can be done. As a matter of fact, this is the case for me. > >> Just that your patch is not enough. Christoph has a patch that makes > >> this behavior consistent over all allocators. > > > > Sorry, I didn't know that. Seems I don't need to continue the half-done > > work in slab. If possible, would you please give me a link of the patch? > > Thank you. > > > > Sorry for the delay. In case you haven't found it out yourself yet: > > http://www.spinics.net/lists/linux-mm/msg36149.html Thank you. I think it is better to have these things in the slab_common.c. > > Please not this posted patch as is has a bug. > > I do believe that your take on the aliasing code adds value to it. But > as I've already said once, might have to dig a bit deeper in that to get > to end of the rabbit hole. With slab_common, I think my slab/slob modifications are not needed any more. After I understand the common patches, I will check whether the aliasing problem in slub still exists, and if yes, try to send a patch based on that. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 6/7] memcg: add per cgroup writeback pages accounting
On Mon, Jul 09, 2012 at 01:01:00AM +0200, Johannes Weiner wrote: > On Sun, Jul 08, 2012 at 10:44:59PM +0800, Fengguang Wu wrote: > > On Tue, Jul 03, 2012 at 03:31:26PM +0900, KAMEZAWA Hiroyuki wrote: > > > (2012/06/28 20:05), Sha Zhengju wrote: > > > > From: Sha Zhengju > > > > > > > > Similar to dirty page, we add per cgroup writeback pages accounting. > > > > The lock > > > > rule still is: > > > > mem_cgroup_begin_update_page_stat() > > > > modify page WRITEBACK stat > > > > mem_cgroup_update_page_stat() > > > > mem_cgroup_end_update_page_stat() > > > > > > > > There're two writeback interface to modify: > > > > test_clear/set_page_writeback. > > > > > > > > Signed-off-by: Sha Zhengju > > > > > > Seems good to me. BTW, you named macros as MEM_CGROUP_STAT_FILE_XXX > > > but I wonder these counters will be used for accounting swap-out's dirty > > > pages.. > > > > > > STAT_DIRTY, STAT_WRITEBACK ? do you have better name ? > > > > Perhaps we can follow the established "enum zone_stat_item" names: > > > > NR_FILE_DIRTY, > > NR_WRITEBACK, > > > > s/NR_/MEM_CGROUP_STAT_/ > > > > The names indicate that dirty pages for anonymous pages are not > > accounted (by __set_page_dirty_no_writeback()). While the writeback > > pages accounting include both the file/anon pages. > > > > Ah then we'll need to update the document in patch 0 accordingly. This > > may sound a bit tricky to the users.. > > We already report the global one as "nr_dirty", though. Please don't > give the memcg one a different name. > > The enum naming is not too critical, but it would be nice to have it > match the public name. Fair enough. The public name obviously has more weight :) Thanks, Fengguang -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Fix a dead loop in async_synchronize_full()
On Fri, 2012-07-06 at 17:12 +0800, Cong Wang wrote:
> On Mon, Jul 2, 2012 at 2:04 PM, Li Zhong wrote:
> > void async_synchronize_full(void)
> > {
> > - do {
> > - async_synchronize_cookie(next_cookie);
> > - } while (!list_empty(_running) ||
> > !list_empty(_pending));
> > + async_synchronize_cookie_domain(next_cookie, NULL);
> > }
>
> A nitpick:
>
> async_synchronize_cookie_domain(next_cookie, NULL);
>
> equals to
>
> async_synchronize_full_domain(NULL)
>
Why do we need one more level in the function calling stack?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Fix a dead loop in async_synchronize_full()
On Thu, 2012-07-05 at 20:51 -0700, Christian Kujau wrote:
> On Mon, 2 Jul 2012 at 14:04, Li Zhong wrote:
> > This patch tries to fix a dead loop in async_synchronize_full(), which
> > could be seen when preemption is disabled on a single cpu machine.
>
> This helps in my case[0], will this patch be included in -rc6?
>
> Thanks,
> Christian.
>
> [0] https://lists.ozlabs.org/pipermail/linuxppc-dev/2012-July/098922.html
>
Seems it was not included in -rc6 :( I'll try to resend it today
Thanks,
Zhong
>
> > void async_synchronize_full(void)
> > {
> > do {
> > async_synchronize_cookie(next_cookie);
> > } while (!list_empty(_running) || !
> > list_empty(_pending));
> > }
> >
> > async_synchronize_cookie() calls async_synchronize_cookie_domain() with
> > _running as the default domain to synchronize.
> >
> > However, there might be some works in the async_pending list from other
> > domains. On a single cpu system, without preemption, there is no chance
> > for the other works to finish, so async_synchronize_full() enters a dead
> > loop.
> >
> > It seems async_synchronize_full() wants to synchronize all entries in
> > all running lists(domains), so maybe we could just check the entry_count
> > to know whether all works are finished.
> >
> > Currently, async_synchronize_cookie_domain() expects a non-NULL running
> > list ( if NULL, there would be NULL pointer dereference ), so maybe a
> > NULL pointer could be used as an indication for the functions to
> > synchronize all works in all domains.
> >
> > Reported-by: Paul E. McKenney
> > Signed-off-by: Li Zhong
> > Tested-by: Paul E. McKenney
> > ---
> > kernel/async.c | 13 +
> > 1 file changed, 9 insertions(+), 4 deletions(-)
> >
> > diff --git a/kernel/async.c b/kernel/async.c
> > index bd0c168..32d8dc9 100644
> > --- a/kernel/async.c
> > +++ b/kernel/async.c
> > @@ -86,6 +86,13 @@ static async_cookie_t __lowest_in_progress(struct
> > list_head *running)
> > {
> > struct async_entry *entry;
> >
> > + if (!running) { /* just check the entry count */
> > + if (atomic_read(_count))
> > + return 0; /* smaller than any cookie */
> > + else
> > + return next_cookie;
> > + }
> > +
> > if (!list_empty(running)) {
> > entry = list_first_entry(running,
> > struct async_entry, list);
> > @@ -236,9 +243,7 @@ EXPORT_SYMBOL_GPL(async_schedule_domain);
> > */
> > void async_synchronize_full(void)
> > {
> > - do {
> > - async_synchronize_cookie(next_cookie);
> > - } while (!list_empty(_running) || !list_empty(_pending));
> > + async_synchronize_cookie_domain(next_cookie, NULL);
> > }
> > EXPORT_SYMBOL_GPL(async_synchronize_full);
> >
> > @@ -258,7 +263,7 @@ EXPORT_SYMBOL_GPL(async_synchronize_full_domain);
> > /**
> > * async_synchronize_cookie_domain - synchronize asynchronous function
> > calls within a certain domain with cookie checkpointing
> > * @cookie: async_cookie_t to use as checkpoint
> > - * @running: running list to synchronize on
> > + * @running: running list to synchronize on, NULL indicates all lists
> > *
> > * This function waits until all asynchronous function calls for the
> > * synchronization domain specified by the running list @list submitted
> > --
> > 1.7.9.5
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> > the body of a message to majord...@vger.kernel.org
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
> > Please read the FAQ at http://www.tux.org/lkml/
> >
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [Question] sched/rt_mutex: re-enqueue_task on rt_mutex_setprio()
On Sat, 07 Jul 2012 21:29:19 -0400, Steven Rostedt wrote:
> On Sat, 2012-07-07 at 14:44 +0900, Namhyung Kim wrote:
>> Hi,
>>
>> I have a question on the code below:
>>
>> void rt_mutex_setprio(struct task_struct *p, int prio)
>> {
>> ...
>> if (on_rq)
>> enqueue_task(rq, p, oldprio < prio ? ENQUEUE_HEAD : 0);
>>
>> When enqueueing @p with new @prio, it seems put @p at the head of a
>> rq if appropriate. I guess it's the case of boosting @p with higher
>> priority, right?
>
> Actually, no. We put @p at the head of the queue when unboosting. If a
> task is going from a high priority into a lower priority, it is still
> treated as "important" for that priority, and is put to the front of the
> queue (it was just higher than everything else on that queue). But if we
> are boosting a task from a low priority, why put it to the head of other
> tasks of its new priority, when those tasks were just higher than this
> task, and this task is now just an "equal".
Thanks for the explanation. (Isn't it worth getting commented?) :)
Thanks,
Namhyung
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: RFD: virtio balloon API use (was Re: [PATCH 5 of 5] virtio: expose added descriptors immediately)
On Wed, 4 Jul 2012 13:55:33 +0300, "Michael S. Tsirkin" wrote: > On Tue, Jul 03, 2012 at 10:17:46AM +0930, Rusty Russell wrote: > > On Mon, 2 Jul 2012 13:08:19 -0300, Rafael Aquini wrote: > > > As 'locking in balloon', may I assume the approach I took for the > > > compaction case > > > is OK and aligned to address these concerns of yours? If not, do not > > > hesitate in > > > giving me your thoughts, please. I'm respinning a V3 series to address a > > > couple > > > of extra nitpicks from the compaction standpoint, and I'd love to be able > > > to > > > address any extra concern you might have on the balloon side of that work. > > > > It's orthogonal, though looks like they clash textually :( > > > > I'll re-spin MST's patch on top of yours, and include both in my tree, > > otherwise linux-next will have to do the merge. But I'll await your > > push before pushing to Linus next merge window. > > > > Thanks, > > Rusty. > > While theoretical mine is a bugfix so could be 3.5 material, no? It's a little thin, but it's a good idea. I'll try. Cheers, Rusty. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH: 1/1] ACPI: make evaluation of thermal trip points before temperature or vice versa dependant on new "temp_b4_trip" module parameter to support older AMD x86_64s
On Sun, 8 Jul 2012 19:50:54 +0100, Jason Vas Dias wrote: > This patch adds a new acpi.thermal.temp_b4_trip = 1 settting, which > causes the temperature > to be set before evaluation of thermal trip points (the old default) ; > this mode should > be selected automatically by DMI match if the system identifies as "HP > Compaq 6715b" . > > Please consider applying a patch like that attached to fix the issue reported > in lkml thread "Re: PROBLEM: Performance drop" recently, whereby > it was found that HP 6715b laptops ( which have 2.2Ghz dual-core AMD > x86_64 k8 CPUs) > get stuck running the CPU at 800Khz and cannot switch frequency. I have > verified > that this still the case with v3.4.4 tagged "stable" kernel. > > diff --git a/drivers/acpi/thermal.c b/drivers/acpi/thermal.c > index 7dbebea..de2b164 100644 > --- a/drivers/acpi/thermal.c > +++ b/drivers/acpi/thermal.c > @@ -96,6 +96,10 @@ static int psv; > module_param(psv, int, 0644); > MODULE_PARM_DESC(psv, "Disable or override all passive trip points."); > > +static int temp_b4_trip; > +module_param(temp_b4_trip, int, 0); > +MODULE_PARM_DESC(temp_b4_trip, "Get the temperature before > initializing trip points."); > + Hi Jason, Two points: this is a bool, why not make it one? I know, the rest of the code is old-school, but this is a new parameter. Also, why not 0644 so it can be read and set at runtime? Cheers, Rusty. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] virtio-blk: allow toggling host cache between writeback and writethrough
On Thu, 05 Jul 2012 09:02:23 +0200, Sasha Levin wrote: > On Thu, 2012-07-05 at 08:47 +0200, Paolo Bonzini wrote: > > Il 04/07/2012 23:11, Sasha Levin ha scritto: > > > There are two things going on here: > > > 1. Rename VIRTIO_BLK_F_FLUSH to VIRTIO_BLK_F_WCE > > > 2. Add a new VIRTIO_BLK_F_CONFIG_WCE > > > > > > I'm concerned that the first change is going to break compilation for > > > any code that included linux/virtio-blk.h and used VIRTIO_BLK_F_FLUSH. > > > > That would be nlkt, right? :) > > nlkt, lguest, and probably others. > > linux/virtio_blk.h is a public kernel header, which is supposed to be > used from userspace - so I assume many others who implemented virtio-blk > for any reason took advantage of that header. lguest doesn't have an API, so it can be patched. But if someone else breaks, then yes, we need to define the old name too. Cheers, Rusty. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] virtio-blk: add back VIRTIO_BLK_F_FLUSH
On Thu, 5 Jul 2012 12:08:22 +0200, Paolo Bonzini wrote: > The old name is part of the userspace API, add it back for compatibility. > > Reported-by: Sasha Levin > Signed-off-by: Paolo Bonzini > --- > include/linux/virtio_blk.h |3 +++ > 1 files changed, 3 insertions(+), 0 deletions(-) > > diff --git a/include/linux/virtio_blk.h b/include/linux/virtio_blk.h > index 18a1027..83a3116 100644 > --- a/include/linux/virtio_blk.h > +++ b/include/linux/virtio_blk.h > @@ -41,6 +41,9 @@ > #define VIRTIO_BLK_F_TOPOLOGY10 /* Topology information is > available */ > #define VIRTIO_BLK_F_CONFIG_WCE 11 /* Writeback mode available in > config */ > > +/* Backwards-compatibility #defines for renamed features. */ > +#define VIRTIO_BLK_F_FLUSH VIRTIO_BLK_F_WCE Please #ifndef __KERNEL__? Thanks, Rusty. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] MAINTAINERS: add kvm list for virtio components
On Thu, 5 Jul 2012 15:22:25 +0300, "Michael S. Tsirkin" wrote: > On Thu, Jul 05, 2012 at 12:07:07PM +0200, Paolo Bonzini wrote: > > The KVM list is followed by more people than the generic > > virtualizat...@lists.linux-foundation.org mailing list, and is > > already "de facto" the place where virtio patches are posted. > > I have no data on the first statement (do you?) and I disagree with the > last statement, but have no objection to people adding kvm list as well. Well, the kvm list is far more active. It's annoying to have two lists, but it is how things are so best to document it. I'm OK with the original commit message, but MST is smarter than me, so let's do what he suggests :) Cheers, Rusty. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Fwd: Hid over I2C and ACPI interaction
On 四, 2012-07-05 at 10:44 +0200, Benjamin Tissoires wrote:
> Hi,
>
> Many thanks for these information. It seems like I was on the right
> track, but I didn't saw the hidden part of the iceberg.
yep.
> I've already written the i2c slave part (and the acpi handling to get
> the HID register by using the DSM should work), but I need now the
> whole ACPI pnp drivers...
>
you need the ACPI/PNP I2C controller driver.
> But without a real ACPI 5.0 mainboard, I think it will be quite
> difficult to implement and debug this ACPI stuff.
>
yes, that's the problem I have. I can not send out the code based on
some example ASL code. :)
thanks,
rui
> Cheers,
> Benjamin
>
> On Thu, Jul 5, 2012 at 9:20 AM, Zhang Rui wrote:
> > Hah, seems I forgot to reply to Benjamin.
> >
> > On 四, 2012-07-05 at 15:01 +0800, Zhang Rui wrote:
> >> > Original Message
> >> > Subject: Hid over I2C and ACPI interaction
> >> > Date: Wed, 4 Jul 2012 15:46:35 +0200
> >> > From: Benjamin Tissoires
> >> > To: Jean Delvare , Ben Dooks ,
> >> > Wolfram
> >> > Sang , Len Brown ,
> >> > , ,
> >> >
> >> > CC: Jiri Kosina , Stéphane Chatty , JJ
> >> > Ding
> >> >
> >> >
> >> > Hi Guys,
> >> >
> >> > I'm the co-author and the maintainer of the hid-multitouch driver. To
> >> > support even more devices, I started the implementation of the HID
> >> > over I2C protocol specification which is introduced by Win8. I'm quite
> >> > comfortable with the hid and the I2C part, but I'm blocked with the
> >> > interaction with the ACPI for the pnp part.
> >> >
> >> > I wanted to have your advice/help on this problem. I've add in the
> >> > recipients list the maintainers of i2c and ACPI, sorry for the noise
> >> > if you don't feel concerned about this.
> >> >
> >> > So, let's go deeper in the problem ;-)
> >> > Microsoft's spec asks the OEM to fill the ACPI DSDT to provide the
> >> > following scope in the ASL layout:
> >> >
> >> > > begin of ASL
> >> > Scope (\_SB) {
> >> > //
> >> > // General Purpose I/O, ports 0...127
> >> > //
> >> >
> >> > Device(HIDI2C_DEVICE1) {
> >> > Name(_ADR,0)
> >> > Name (_HID, "MSFT1234”)
> >> > Name (_CID, "PNP0C50")
> >> > Name (_UID, 3)
> >> >
> >> > Method(_CRS, 0x0, NotSerialized)
> >> > {
> >> > Name (RBUF, ResourceTemplate ()
> >> > {
> >> > // Address 0x07 on I2C-X (OEM selects this address)
> >> > //IHV SPECIFIC I2C3 = I2C Controller; TGD0 = GPIO Controller;
> >> > I2CSerialBus (0x07, ControllerInitiated,
> >> > 10,AddressingMode7Bit, "\\_SB.I2C3")
> >> > GpioInt(Level, ActiveLow, Exclusive, PullUp, 0, "\\_SB. TGD0",
> >> > 0 , ResourceConsumer, , ) {40}
> >> > })
> >> > Return(RBUF)
> >> > }
> >> >
> >> > Method(_DSM, 0x4, NotSerialized)
> >> > {
> >> > // BreakPoint
> >> > Store ("Method _DSM begin", Debug)
> >> >
> >> > // DSM UUID
> >> > switch(ToBuffer(Arg0))
> >> > {
> >> > // ACPI DSM UUID for HIDI2C
> >> > case(ToUUID("3CDFF6F7-4267-4555-AD05-B30A3D8938DE"))
> >> > {
> >> > // DSM function which returns the HID Descriptor
> >> > Address (skipped)
> >> > }
> >> >
> >> > default
> >> > {
> >> > // No other GUIDs supported
> >> > Return(Buffer(One) { 0x00 })
> >> > }
> >> > }
> >> > }
> >> > }
> >> > < end of ASL
> >> >
> >> yep, this is an ACPI enumerated I2C controller.
> >>
> >> > Summary:
> >> > - a HID over I2C device has to present the Compatibility ID "PNP0C50"
> >> > - in the _CRS block, the address, the adapter and the gpioInt are
> >> > defined (or referenced)
> >> > - it presents a Device Specific Method (_DSM) which returns the HID
> >> > Descriptor register address. This register is our entry point for
> >> > retrieving the information about our hid device (so it's mandatory to
> >> > obtain it).
> >> >
> >> > Where am I:
> >> > - I've written a first layer on top of i2c that retrieves the hid
> >> > register (currently the address 0x0001 is hardcoded), then get the
> >> > report desccriptors and the input events, and forward all this stuff
> >> > to the hid layer.
> >> > - It's working with a custom emulated HID over i2c touchpad, while
> >> > waiting for the one a manufacturer should send to me.
> >> > - The detection and the addition to the adapter is done by adding the
> >> > address in the lists and the name through the i2c "->detect" callback
> >> > (which is not very good, because I don't have the interrupt line
> >> > there).
> >> > - I've written a first acpi implementation that rely on the
> >> > DEVICE_ACPI_HANDLE macro to get the ACPI handle of the device (if
> >> > available).
> >> > - I'm not able to do some tests with the ACPI, as I don't know how to
> >> > implement this DSDT on my
[PATCH] [SCSI] suppress a warning in mpt2sas
Suppress this warning:
drivers/scsi/mpt2sas/mpt2sas_scsih.c: In function
'_scsih_sas_broadcast_primitive_event':
drivers/scsi/mpt2sas/mpt2sas_scsih.c:5811:40: warning: unused variable
'event_data' [-Wunused-variable]
Signed-off-by: Stephen Rothwell
---
drivers/scsi/mpt2sas/mpt2sas_debug.h |6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
After this patch, the same code is generated. This is relative to Linus tree.
diff --git a/drivers/scsi/mpt2sas/mpt2sas_debug.h
b/drivers/scsi/mpt2sas/mpt2sas_debug.h
index 9731f8e..2a6516e 100644
--- a/drivers/scsi/mpt2sas/mpt2sas_debug.h
+++ b/drivers/scsi/mpt2sas/mpt2sas_debug.h
@@ -79,7 +79,11 @@
CMD;\
}
#else
-#define MPT_CHECK_LOGGING(IOC, CMD, BITS)
+#define MPT_CHECK_LOGGING(IOC, CMD, BITS) \
+{ \
+ if (0 & IOC->logging_level & BITS) \
+ CMD;\
+}
#endif /* CONFIG_SCSI_MPT2SAS_LOGGING */
--
1.7.10.280.gaa39
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
pgpoLmXKskZ5f.pgp
Description: PGP signature
Re: [PATCH v2] cgroup: fix panic in netprio_cgroup
于 2012年07月09日 03:50, Eric Dumazet 写道: > On Thu, 2012-07-05 at 17:28 +0800, Gao feng wrote: >> we set max_prioidx to the first zero bit index of prioidx_map in >> function get_prioidx. >> >> So when we delete the low index netprio cgroup and adding a new >> netprio cgroup again,the max_prioidx will be set to the low index. >> >> when we set the high index cgroup's net_prio.ifpriomap,the function >> write_priomap will call update_netdev_tables to alloc memory which >> size is sizeof(struct netprio_map) + sizeof(u32) * (max_prioidx + 1), >> so the size of array that map->priomap point to is max_prioidx +1, >> which is low than what we actually need. >> >> fix this by adding check in get_prioidx,only set max_prioidx when >> max_prioidx low than the new prioidx. >> >> Signed-off-by: Gao feng >> --- >> net/core/netprio_cgroup.c |3 ++- >> 1 files changed, 2 insertions(+), 1 deletions(-) >> >> diff --git a/net/core/netprio_cgroup.c b/net/core/netprio_cgroup.c >> index 5b8aa2f..aa907ed 100644 >> --- a/net/core/netprio_cgroup.c >> +++ b/net/core/netprio_cgroup.c >> @@ -49,8 +49,9 @@ static int get_prioidx(u32 *prio) >> return -ENOSPC; >> } >> set_bit(prioidx, prioidx_map); >> +if (atomic_read(_prioidx) < prioidx) >> +atomic_set(_prioidx, prioidx); >> spin_unlock_irqrestore(_map_lock, flags); >> -atomic_set(_prioidx, prioidx); >> *prio = prioidx; >> return 0; >> } > > This patch seems fine to me. > > Acked-by: Eric Dumazet > > Neil, looking at this file, I believe something is wrong. > > dev->priomap is allocated by extend_netdev_table() called from > update_netdev_tables(). And this is only called if write_priomap() is > called. > > But if write_priomap() is not called, it seems we can have out of bounds > accesses in cgrp_destroy() and read_priomap() Agree,and the function skb_update_prio has the same problem. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
linux-next: comment on pm tree commit
Hi Rafael,
I noticed commit b8eec56cd8e5 ("PM / cpuidle: System resume hang fix with
cpuidle") in the pm tree needs some work (I noticed it because it was
changed in a rebase ...).
diff --git a/include/linux/cpuidle.h b/include/linux/cpuidle.h
index a6b3f2e..b90ccb2 100644
--- a/include/linux/cpuidle.h
+++ b/include/linux/cpuidle.h
@@ -146,6 +146,8 @@ extern void cpuidle_unregister_device(struct cpuidle_device
*dev);
extern void cpuidle_pause_and_lock(void);
extern void cpuidle_resume_and_unlock(void);
+extern void cpuidle_pause(void);
+extern void cpuidle_resume(void);
extern int cpuidle_enable_device(struct cpuidle_device *dev);
extern void cpuidle_disable_device(struct cpuidle_device *dev);
extern int cpuidle_wrap_enter(struct cpuidle_device *dev,
@@ -169,6 +171,8 @@ static inline void cpuidle_unregister_device(struct
cpuidle_device *dev) { }
static inline void cpuidle_pause_and_lock(void) { }
static inline void cpuidle_resume_and_unlock(void) { }
+static inline cpuidle_pause(void) { }
+static inline cpuidle_resume(void) { }
These need to be "static inline void". I wonder what review and build
testing this went through (the above should produce warnings since they
are non void returning functions with no return statements).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
pgp79BNg4Y2lw.pgp
Description: PGP signature
[RFC] SCSI: drivers: Remove unnecessary assignment of scsi_done in driver queuecommand
[ CCing signed-off, acked-by of original patch - let me know if anyone else needs to be added ] Jeff, James, In the following commit: -- commit f281233d3eba15fb225d21ae2e228fd4553d824a Author: Jeff Garzik Date: Tue Nov 16 02:10:29 2010 -0500 SCSI host lock push-down - queuecommand syntax is changed to no longer passing done() routine as parameter. Instead, in scsi_dispatch_command and scsi_send_eh_cmnd, scsi_cmd->scsi_done is set to done() before calling the driver specific queuecommand. But all the drivers queuecommand routines still do the redundant assignment: scsi_cmd->scsi_done = done For example: cciss_scsi_queue_command_lck(): .. cmd->scsi_done = done;// save this for use by completion code .. How about removing all such redundant assignments? Regards, Muthu -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 00/36] AArch64 Linux kernel port
On 07/08/2012 04:31 PM, Jan Engelhardt wrote: > > On Sunday 2012-07-08 09:54, Jon Masters wrote: >> >> FWIW I actually really like the aarch64 name (but you know that already >> :) ). I think it clearly spells out that this is not just a 64-bit >> extension to the existing 32-bit ARM Architecture, it is a new (inspired >> by ARM) architecture. > > IA64 also has a "arch" inside, and look where it took them. > (The contemporary platform winner came to be x86_64 instead > of what Intel had hoped back then.) There is a difference here. Treading carefully to avoid upsetting anyone, but IA64 was a complete departure in many ways from x86, whereas AMD had something that was backward compatible more directly, and the market reacted. In this case, it's different because of many different things - an ARMv8 processor will also be a great ARMv7 processor (albeit a few things nobody ever used are deprecated, but still supported), the makeup of the existing market (ARM doesn't need a 30 year backward compatibility story on the desktop or server and mobile platforms have moved on to higher level stacks), the dynamics of the licensing model, and the fact that compiled code is less relevant. I would say let's not draw too many comparisons with x86/IA64/x86_64. AArch64 is not a complete departure for ARM. It's a 32-bit wide RISC instruction set that is very clean and draws on industry lessons from the past several decades to fix (AFAICS) pretty much anything that was really wrong with A32/T32 (ARM). They already did a lot in ARMv7 in terms of deprecating older features, but it's nice (from an implementation point of view) to have a chance to remove things that no longer make sense - like many conditional instructions, modelling real world software to optimize the encoding formats, etc. - and clean up stuff like explicit knowledge of the pipeline depth of ten years ago. I am very keen on the opportunity here for things like a single zImage and a standardized platform on day one. By the time the first hardware ships, I'm hoping that we've got a nice set of standards that everyone can follow - all things that are needed to do AArch64 in bigger systems. Jon. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: /sys and access(2): Correctly implemented?
On 06/07/12 16:27, Ulrich Windl wrote: > Hi! > > Recently I found a problem with the command (kernel 3.0.34-0.7-default from > SLES 11 SP2, run as root): > test -r "$file" && cat "$file" > emitting "Permission denied" > > Investigating, I found that "test" actually uses "access()" to check for > permissions. Unfortunately there are some files in /sys that have > "write-only" permission bits set (e.g. /sys/devices/system/cpu/probe). > > ~ # ll /sys/devices/system/cpu/probe > --w--- 1 root root 4096 Jun 29 12:43 /sys/devices/system/cpu/probe > ~ # F=/sys/devices/system/cpu/probe > ~ # test "$F" && cat "$F" > cat: /sys/devices/system/cpu/probe: Permission denied Looks like you have a typo here, I think you wanted "test -r $F", not "test $F", the latter will just evaluate "$F" as an expression which will be true, and so you get the permission denied error running cat. Using "test -r $F" on a write-only sysfs file correctly returns false on my machine (Ubuntu 10.04.4 LTS/2.6.32-41-generic). ~Ryan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V3] rtlwifi: rtl8192ce: rtl8192se: rtl8192de: Update to rtl_92ce_92se_92de_linux_mac80211_0004.0816.2011 driver
On Sun, 2012-07-08 at 15:16 -0500, Larry Finger wrote: > Realtek driver rtl_92ce_92se_92de_linux_mac80211_0004.0816.2011 introduced new > versions of the firmware for rtl8192se, and rtl8192de. It also adds new > firmware for new cuts of the RTL8192CE chips. > > Signed-off-by: Larry Finger > --- > > V2 - sent to Ben Hutchings >- fixed the mode for new files >- made clearer the source of the new files > V3 - Removed extraneous material from File line [...] Applied, thanks. Ben. -- Ben Hutchings No political challenge can be met by shopping. - George Monbiot signature.asc Description: This is a digitally signed message part
[PATCH linux-firmware 2/2] WHENCE: Move version strings from Info to Version fields
Signed-off-by: Ben Hutchings --- WHENCE | 77 +++- 1 file changed, 42 insertions(+), 35 deletions(-) diff --git a/WHENCE b/WHENCE index 6a3665a..8e0aff3 100644 --- a/WHENCE +++ b/WHENCE @@ -93,6 +93,7 @@ Licence: Allegedly GPLv2+, but no source visible. Marked: Driver: smctr -- SMC ISA/MCA Token Ring adapter File: tr_smctr.bin +Version: 6.3C1 Info: MCT.BIN v6.3C1 03/01/95 Original licence info: @@ -184,10 +185,12 @@ Compiled from original 8051 source into Intel HEX, used in our binary ihex form. Driver: emi26 -- EMI 2|6 USB Audio interface File: emi26/bitstream.fw -Info: VERSION=1.1.1.131 DATE=2001dec06 +Version: 1.1.1.131 +Info: DATE=2001dec06 File: emi26/firmware.fw -Info: VERSION=1.0.2.916 DATE=12.02.2002 +Version: 1.0.2.916 +Info: DATE=12.02.2002 File: emi26/loader.fw @@ -218,19 +221,23 @@ Original licence information: Driver: emi62 -- EMI 6|2m USB Audio interface File: emi62/bitstream.fw -Info: VERSION=1.0.0.191 DATE= 2002oct28 +Version: 1.0.0.191 +Info: DATE= 2002oct28 File: emi62/loader.fw Source: EMILOAD.HEX -Info: VERSION=1.0.2.002 DATE=10.01.2002 +Version: 1.0.2.002 +Info: DATE=10.01.2002 File: emi62/midi.fw Source: EMI62MFW.HEX -Info: VERSION=1.04.062 DATE=16.10.2002 +Version: 1.04.062 +Info: DATE=16.10.2002 File: emi62/spdif.fw Source: EMI62SFW.HEX -Info: VERSION=1.04.062 DATE=16.10.2002 +Version: 1.04.062 +Info: DATE=16.10.2002 Converted from Intel HEX files, used in our binary representation of ihex. @@ -674,13 +681,13 @@ Linux driver tarballs downloaded from Marvell's "Extranet" with permission. Driver: libertas - Marvell Libertas 802.11b/g cards, OLPC firmware File: libertas/lbtf_sdio.bin -Info: v9.0.7.p4 +Version: 9.0.7.p4 File: lbtf_usb.bin -Info: v5.132.3.p1 +Version: 5.132.3.p1 File: libertas/usb8388_olpc.bin -Info: v5.110.22.p23 +Version: 5.110.22.p23 Licence: Redistributable. See LICENCE.OLPC for details. @@ -717,61 +724,61 @@ Linux driver tarballs downloaded from Marvell's "Extranet" with permission. Driver: iwlwifi - Intel Wireless Wifi File: iwlwifi-3945-2.ucode -Info: v15.32.2.9 +Version: 15.32.2.9 File: iwlwifi-4965-2.ucode -Info: v228.61.2.24 +Version: 228.61.2.24 File: iwlwifi-5000-1.ucode -Info: v5.4.A.11 (aka v5.4.1.16) +Version: 5.4.A.11 (aka 5.4.1.16) File: iwlwifi-5000-2.ucode -Info: v8.24.2.12 +Version: 8.24.2.12 File: iwlwifi-5000-5.ucode -Info: v8.83.5.1 +Version: 8.83.5.1 File: iwlwifi-5150-2.ucode -Info: v8.24.2.2 +Version: 8.24.2.2 File: iwlwifi-1000-3.ucode -Info: v128.50.3.1 +Version: 128.50.3.1 File: iwlwifi-1000-5.ucode -Info: v39.31.5.1 +Version: 39.31.5.1 File: iwlwifi-6000-4.ucode -Info: v9.221.4.1 +Version: 9.221.4.1 File: iwlwifi-6050-4.ucode -Info: v9.201.4.1 +Version: 9.201.4.1 File: iwlwifi-6050-5.ucode -Info: v41.28.5.1 +Version: 41.28.5.1 File: iwlwifi-6000g2a-5.ucode -Info: v17.168.5.3 +Version: 17.168.5.3 File: iwlwifi-6000g2b-5.ucode -Info: v17.168.5.1 +Version: 17.168.5.1 File: iwlwifi-6000g2b-6.ucode -Info: v18.168.6.1 +Version: 18.168.6.1 File: iwlwifi-135-6.ucode -Info: v18.168.6.1 +Version: 18.168.6.1 File: iwlwifi-100-5.ucode -Info: v39.31.5.1 +Version: 39.31.5.1 File: iwlwifi-105-6.ucode -Info: v18.168.6.1 +Version: 18.168.6.1 File: iwlwifi-2030-6.ucode -Info: v18.168.6.1 +Version: 18.168.6.1 File: iwlwifi-2000-6.ucode -Info: v18.168.6.1 +Version: 18.168.6.1 Licence: Redistributable. See LICENCE.iwlwifi_firmware for details @@ -1139,7 +1146,7 @@ Found in hex form in kernel source. Driver: netxen_nic - NetXen Multi port (1/10) Gigabit Ethernet NIC File: phanfw.bin -Info: v4.0.579 +Version: 4.0.579 Licence: Redistributable. See LICENCE.phanfw for details. @@ -1253,7 +1260,7 @@ Provided from the author, Bernd Porr Driver: xc5000 - Xceive 5000 Tuner driver File: dvb-fe-xc5000-1.6.114.fw -Info: v1.6.114 +Version: 1.6.114 Licence: Redistributable. See LICENCE.xc5000 for details @@ -1262,7 +1269,7 @@ Licence: Redistributable. See LICENCE.xc5000 for details Driver: dib0700 - DiBcom dib0700 USB DVB bridge driver File: dvb-usb-dib0700-1.20.fw -Info: v1.20 +Version: 1.20 Licence: Redistributable. See LICENCE.dib0700 for details @@ -1271,7 +1278,7 @@ Licence: Redistributable. See LICENCE.dib0700 for details Driver: ath3k - DFU Driver for Atheros bluetooth chipset AR3011 File: ath3k-1.fw -Info: v1.0 +Version: 1.0 Fix EEPROM radio table issue and change PID to 3005 @@ -1538,7 +1545,7 @@ Driver: ueagle-atm - Driver for USB ADSL Modems based on Eagle IV Chipset File: ueagle-atm/CMV4p.bin.v2 File: ueagle-atm/DSP4p.bin File: ueagle-atm/eagleIV.fw -Info: v1.0 +Version: 1.0 Licence: Redistributable. See LICENCE.ueagle-atm4-firmware for details @@ -1567,7 +1574,7 @@ File: ueagle-atm/CMVei.bin File: ueagle-atm/CMVepFR04.bin File: ueagle-atm/DSP9i.bin File: ueagle-atm/eagleII.fw -Info: v1.1 +Version: 1.1 Licence:
[PATCH linux-firmware 1/2] WHENCE: Move informational text from File to Info fields
Signed-off-by: Ben Hutchings --- WHENCE | 27 ++- 1 file changed, 18 insertions(+), 9 deletions(-) diff --git a/WHENCE b/WHENCE index fb6030c..6a3665a 100644 --- a/WHENCE +++ b/WHENCE @@ -413,12 +413,18 @@ Found in hex form in kernel source. Driver: qla2xxx - QLogic QLA2XXX Fibre Channel -File: ql2100_fw.bin -- 1.19.38 TP -File: ql2200_fw.bin -- 2.02.08 TP -File: ql2300_fw.bin -- 3.03.28 IPX -File: ql2322_fw.bin -- 3.03.28 IPX -File: ql2400_fw.bin -- 5.06.05 MID -File: ql2500_fw.bin -- 5.06.05 MIDQ +File: ql2100_fw.bin +Version: 1.19.38 TP +File: ql2200_fw.bin +Version: 2.02.08 TP +File: ql2300_fw.bin +Version: 3.03.28 IPX +File: ql2322_fw.bin +Version: 3.03.28 IPX +File: ql2400_fw.bin +Version: 5.06.05 MID +File: ql2500_fw.bin +Version: 5.06.05 MIDQ Licence: Redistributable. See LICENCE.qla2xxx for details @@ -428,8 +434,10 @@ Available from ftp://ftp.qlogic.com/outgoing/linux/firmware/ Driver: orinoco - Agere/Prism/Symbol Orinoco support -File: agere_sta_fw.bin -- 9.48 Hermes I -File: agere_ap_fw.bin -- 9.48 Hermes I +File: agere_sta_fw.bin +Version: 9.48 Hermes I +File: agere_ap_fw.bin +Version: 9.48 Hermes I Licence: Redistributable. See LICENCE.agere for details @@ -1731,7 +1739,8 @@ Licence: Driver: r8712u - Realtek 802.11n WLAN driver for RTL8712U -File: rtlwifi/rtl8712u.bin - upgraded to the version found in the Vendor's V2.6.6 +File: rtlwifi/rtl8712u.bin +Info: version found in the Vendor's V2.6.6 Licence: Redistributable. See LICENCE.rtlwifi_firmware.txt for details. -- 1.7.10.4 signature.asc Description: This is a digitally signed message part
Re: [PATCH 1/3] staging: vt6656: iwctl: fix up spacing around operators
On Sun, 8 Jul 2012, Joe Perches wrote:
> On Mon, 2012-07-09 at 00:58 +0200, Jesper Juhl wrote:
> > A few cases were missed in my previous cleanup, this takes care of the
> > last cases of missing space (or too much space (as in a newline))
> > around operators ('=', '==', ',', '<').
>
> Trivia:
>
> > diff --git a/drivers/staging/vt6656/iwctl.c b/drivers/staging/vt6656/iwctl.c
> []
> > @@ -1624,8 +1624,7 @@ int iwctl_siwmlme(struct net_device *dev, struct
> > iw_request_info *info,
> > case IW_MLME_DISASSOC:
> > if (pDevice->bLinkPass == TRUE) {
> > PRINT_K("iwctl_siwmlme--->send DISASSOCIATE\n");
> > - bScheduleCommand((void *)pDevice,
> > - WLAN_CMD_DISASSOCIATE,
> > + bScheduleCommand((void *)pDevice, WLAN_CMD_DISASSOCIATE,
> > NULL);
>
> pDevice doesn't need a cast.
>
> bScheduleCommand uses a lot of casts for pDevice
> that aren't necessary.
>
Right you are.
I have not gone through the file to verify all casts (yet). I was focused
on getting it from the totally chaotic state it was in to something that
was readable and reasonably close to CodingStyle. I'm well aware that it's
not perfect (yet).
I'm a bit out of time right now and for the next couple of days, but I can
probably do a review of the casts and send some follow-up patches later in
the week.
--
Jesper Juhlhttp://www.chaosbits.net/
Don't top-post http://www.catb.org/jargon/html/T/top-post.html
Plain text mails only, please.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH linux-firmware 0/2] Clean up some metadata in WHENCE
I've committed the following changes. Ben. Ben Hutchings (2): WHENCE: Move informational text from File to Info fields WHENCE: Move version strings from Info to Version fields WHENCE | 104 +--- 1 file changed, 60 insertions(+), 44 deletions(-) -- 1.7.10.4 signature.asc Description: This is a digitally signed message part
Re: [PATCH 3/3] staging: vt6656: iwctl: remove a few remaining redundant newlines
On Sun, 8 Jul 2012, Joe Perches wrote: > On Mon, 2012-07-09 at 00:59 +0200, Jesper Juhl wrote: > > I missed a few redundant newlines the first time. > [] > > diff --git a/drivers/staging/vt6656/iwctl.c b/drivers/staging/vt6656/iwctl.c > [] > > @@ -964,7 +964,6 @@ int iwctl_giwrts(struct net_device *dev, struct > > iw_request_info *info, > > wrq->value = pDevice->wRTSThreshold; > > wrq->disabled = (wrq->value >= 2312); > > wrq->fixed = 1; > > - > > return 0; > > } > > I think this is a useful style and these should not be removed. > It's akin to a blank line after automatic variable declarations. > Thank you for your feedback Joe. I see your point, but personally I'd rather leave it out - especially for small functions. I'll leave it up to Greg whether or not to take this one :-) -- Jesper Juhlhttp://www.chaosbits.net/ Don't top-post http://www.catb.org/jargon/html/T/top-post.html Plain text mails only, please. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/3] staging: vt6656: iwctl: remove a few remaining redundant newlines
On Mon, 2012-07-09 at 00:59 +0200, Jesper Juhl wrote: > I missed a few redundant newlines the first time. [] > diff --git a/drivers/staging/vt6656/iwctl.c b/drivers/staging/vt6656/iwctl.c [] > @@ -964,7 +964,6 @@ int iwctl_giwrts(struct net_device *dev, struct > iw_request_info *info, > wrq->value = pDevice->wRTSThreshold; > wrq->disabled = (wrq->value >= 2312); > wrq->fixed = 1; > - > return 0; > } I think this is a useful style and these should not be removed. It's akin to a blank line after automatic variable declarations. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] staging: vt6656: iwctl: fix up spacing around operators
On Mon, 2012-07-09 at 00:58 +0200, Jesper Juhl wrote:
> A few cases were missed in my previous cleanup, this takes care of the
> last cases of missing space (or too much space (as in a newline))
> around operators ('=', '==', ',', '<').
Trivia:
> diff --git a/drivers/staging/vt6656/iwctl.c b/drivers/staging/vt6656/iwctl.c
[]
> @@ -1624,8 +1624,7 @@ int iwctl_siwmlme(struct net_device *dev, struct
> iw_request_info *info,
> case IW_MLME_DISASSOC:
> if (pDevice->bLinkPass == TRUE) {
> PRINT_K("iwctl_siwmlme--->send DISASSOCIATE\n");
> - bScheduleCommand((void *)pDevice,
> - WLAN_CMD_DISASSOCIATE,
> + bScheduleCommand((void *)pDevice, WLAN_CMD_DISASSOCIATE,
> NULL);
pDevice doesn't need a cast.
bScheduleCommand uses a lot of casts for pDevice
that aren't necessary.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: WARNING: __GFP_FS allocations with IRQs disabled (kmemcheck_alloc_shadow)
On Mon, 9 Jul 2012, JoonSoo Kim wrote:
> diff --git a/mm/slub.c b/mm/slub.c
> index 8c691fa..5d41cad 100644
> --- a/mm/slub.c
> +++ b/mm/slub.c
> @@ -1324,8 +1324,14 @@ static struct page *allocate_slab(struct
> kmem_cache *s, gfp_t flags, int node)
> && !(s->flags & (SLAB_NOTRACK | DEBUG_DEFAULT_FLAGS))) {
> int pages = 1 << oo_order(oo);
>
> + if (flags & __GFP_WAIT)
> + local_irq_enable();
> +
> kmemcheck_alloc_shadow(page, oo_order(oo), flags, node);
>
> + if (flags & __GFP_WAIT)
> + local_irq_disable();
> +
> /*
> * Objects from caches that have a constructor don't get
> * cleared when they're allocated, so we need to do it here.
This patch is suboptimal when the branch is taken since you just disabled
irqs and now are immediately reenabling them and then disabling them
again. (And your patch is also whitespace damaged, has no changelog, and
isn't signed off so it can't be applied.)
The correct fix is what I proposed at
http://marc.info/?l=linux-kernel=133754837703630 and was awaiting
testing. If Rus, Steven, or Fengguang could test this then we could add
it as a stable backport as well.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
