Re: [PATCH v3 0/3] cpufreq: avoid redundant driver calls in schedutil

2016-07-14 Thread Pingbo Wen
On Thursday, July 14, 2016 04:25 AM, Steve Muckle wrote: > Invoking the cpufreq driver to set a frequency can be expensive. On platforms > with a cpufreq driver that does not support fast switching a thread must be > woken to complete the operation. IPIs will also occur if and when support to > p

Re: [RFC PATCH] regulator: introduce boot protection flag

2016-06-23 Thread Pingbo Wen
Hi, Mark On Friday, June 17, 2016 07:42 PM, Mark Brown wrote: > On Fri, Jun 17, 2016 at 11:34:25AM +0800, Pingbo Wen wrote: >> On Wednesday, June 15, 2016 09:32 PM, Mark Brown wrote: > >>> Having the consumer driver know that it's "critical" seems wrong

Re: [RFC PATCH] regulator: introduce boot protection flag

2016-06-16 Thread Pingbo Wen
On Wednesday, June 15, 2016 09:32 PM, Mark Brown wrote: > On Wed, Jun 15, 2016 at 08:05:13PM +0800, Pingbo Wen wrote: >> On Thursday, June 09, 2016 01:16 AM, Mark Brown wrote: > >> If we take modules under consideration, and to make this patch more >> universal, I thin

Re: [RFC PATCH] regulator: introduce boot protection flag

2016-06-15 Thread Pingbo Wen
Hi, Mark On Thursday, June 09, 2016 01:16 AM, Mark Brown wrote: > On Mon, May 09, 2016 at 03:05:08PM +0800, WEN Pingbo wrote: > >> And regulator core will postpone all operations until all consumers >> have taked their place. > > It doesn't, it postpones them until late_initacall(). This is bot

Re: [RFC PATCH 2/2] regulator: add boot protection flag

2016-04-26 Thread Pingbo Wen
Hi, Mark > 在 2016年4月25日,06:51,Mark Brown 写道: > > On Sat, Apr 23, 2016 at 03:11:06PM +0800, WEN Pingbo wrote: > >> This patch try to add a boot_protection flag in regulator constraints. >> So the regulator core will prevent the specified operation during kernel >> booting. > >> The boot_protect

Re: [RFC] shared regulator initialization and protection

2016-04-18 Thread Pingbo Wen
Hi, Mark On Tuesday, April 12, 2016 11:48 AM, Mark Brown wrote: > On Tue, Apr 12, 2016 at 10:44:11AM +0800, Pingbo Wen wrote: > > Please fix your mail client to word wrap within paragraphs at something > substantially less than 80 columns. Doing this makes your messages much >

[RFC] shared regulator initialization and protection

2016-04-11 Thread Pingbo Wen
(Resend, previous one rejected due to html link code) Hi, Those day, I get some fuzz idea in a proxy-consumer regulator driver [1] from Qcom kernel tree. The driver is simple, that let some critical regulator, which specified in DT tree, initializing in a pre-defined state, and hold a regulato

Re: [Eas-dev] [PATCH] cpufreq_sched: set governor_data before waking up kschedfreq

2016-02-22 Thread Pingbo Wen
Hi, Juri On Monday, February 22, 2016 06:53 PM, Juri Lelli wrote: > Hi, > > On 20/02/16 19:32, Pingbo Wen wrote: >> Fix null pointer dereference error liked below. This BUG can be easily >> re-produced by 'monkey --throttle 50' in android 6.0. >> > > I

[PATCH] cpufreq_sched: set governor_data before waking up kschedfreq

2016-02-20 Thread Pingbo Wen
[] kthread+0xd4/0xec Signed-off-by: Pingbo Wen --- kernel/sched/cpufreq_sched.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/kernel/sched/cpufreq_sched.c b/kernel/sched/cpufreq_sched.c index e1d208e..93731ef 100644 --- a/kernel/sched/cpufreq_sched.c +++ b/kernel/sched/cpufr

Re: [PATCH 0/3] introduce new evdev interface type

2015-12-03 Thread Pingbo Wen
> 在 2015年12月1日,18:47,Arnd Bergmann 写道: > > On Tuesday 01 December 2015 16:34:00 Pingbo Wen wrote: >> >> >> What kinds of changes in time_t? Extending it to 64-bits in both kernel >> and userspace? Ok, I get confused here, if there are some sample codes >&g

Re: [PATCH 0/3] introduce new evdev interface type

2015-12-01 Thread Pingbo Wen
Hi, Arnd The patch series add three evdev interface type: - EV_IF_LEGACY send event by input_event. This is the default option, keep kernel backward compatible. >>> >>> The problem I see with this approach is that it still breaks any >>> legacy source code that is

Re: [PATCH 0/3] introduce new evdev interface type

2015-12-01 Thread Pingbo Wen
Hi, Arnd The patch series add three evdev interface type: - EV_IF_LEGACY send event by input_event. This is the default option, keep kernel backward compatible. >>> >>> The problem I see with this approach is that it still breaks any >>> legacy source code that is

Re: [PATCH 2/3] input: evdev: add new ioctl EVIOCSIFTYPE / EVIOCGIFTYPE

2015-11-29 Thread Pingbo Wen
> 在 2015年11月28日,00:59,Arnd Bergmann 写道: > > On Friday 27 November 2015 18:00:31 WEN Pingbo wrote: >> This patch depends on 'introduce new evdev interface'. >> >> Userspace cat set / get evdev interface type via the two ioctl >> commands. And default interface type is EV_IF_LEGACY, so the old bi

Re: [PATCH 0/3] introduce new evdev interface type

2015-11-29 Thread Pingbo Wen
Hi, Arnd > 在 2015年11月28日,00:58,Arnd Bergmann 写道: > > On Friday 27 November 2015 18:00:29 WEN Pingbo wrote: >> To solve the y2038 problem in input_event, I had some attempts before [1], >> and this is the second one. >> >> We can force userspace to use monotonic time in event timestamp, so the >

Re: [Y2038] [PATCH] hil_mlc: convert timeval to timespec64

2015-10-23 Thread Pingbo Wen
> 在 2015年10月23日,17:45,Arnd Bergmann 写道: > > On Friday 23 October 2015 17:12:38 Pingbo Wen wrote: >> On Monday, October 19, 2015 04:58 PM, Arnd Bergmann wrote: >>>> -do_gettimeofday(&tv); >>>> - > Handling the jiffies overflow is

Re: [Y2038] [PATCH V2] hil_mlc: convert timeval to ktime_t

2015-10-23 Thread Pingbo Wen
> 在 2015年10月23日,17:55,Arnd Bergmann 写道: > > On Friday 23 October 2015 17:24:59 WEN Pingbo wrote: >> Using struct timeval will cause time overflow in 2038, replacing it with >> ktime_t. And we don't need to handle sec and nsec separately. >> > > This part looks good now, but as I commented in v

Re: [PATCH V3] hp_sdc: convert struct timeval to ktime_t

2015-10-23 Thread Pingbo Wen
> 在 2015年10月23日,19:45,Arnd Bergmann 写道: > > On Friday 23 October 2015 19:29:39 WEN Pingbo wrote: >> 1. struct timeval is not y2038 safe, convert it to ktime_t, and there is no >> need to handle sec and usec separately >> >> > > The patch looks good now, but the changelog still needs a tiny b

Re: [Y2038] [PATCH V2] hp_sdc: fixed y2038 problem

2015-10-23 Thread Pingbo Wen
On Friday, October 23, 2015 05:25 PM, Arnd Bergmann wrote: > On Friday 23 October 2015 16:53:26 WEN Pingbo wrote: >> 1. Converting timeval to ktime_t, and there is no need to handle sec and >> usec separately >> >> 2. hp_sdc.rtv is only used for time diff, monotonic time is better here >> >> Sign

Re: [Y2038] [PATCH] hil_mlc: convert timeval to timespec64

2015-10-23 Thread Pingbo Wen
On Monday, October 19, 2015 04:58 PM, Arnd Bergmann wrote: > On Sunday 18 October 2015 17:45:19 WEN Pingbo wrote: >> Using struct timeval will cause time overflow in 2038, replacing it with >> a 64bit version. >> >> In addition, the origin driver try to covert usec to jiffies manually in >> hilse

Re: [Y2038] [PATCH] hp_sdc: fixed y2038 problem

2015-10-21 Thread Pingbo Wen
On Monday, October 19, 2015 05:01 PM, Arnd Bergmann wrote: > On Sunday 18 October 2015 17:44:19 WEN Pingbo wrote: >> Two replacements happened in this patch: >> 1. using timespec64 to prevent time overflow in 2038 >> 2. using ktime_get_ts64 to avoid wall time issues(leap second, etc) >> >

Re: [PATCH V2] dummy_hcd: replace timeval with timespec64

2015-09-17 Thread Pingbo Wen
On Thursday, September 17, 2015 05:59 PM, Peter Stuge wrote: > WEN Pingbo wrote: >> +++ b/drivers/usb/gadget/udc/dummy_hcd.c >> @@ -833,10 +833,10 @@ static const struct usb_ep_ops dummy_ep_ops = { >> /* there are both host and device side versions of this call ... */ >> static int dummy_g_get_

Re: [PATCH V2] dummy_hcd: replace timeval with timespec64

2015-09-16 Thread Pingbo Wen
n to cover this. > - using NSEC_PER_MSEC instead of hard code. > > Signed-off-by: Pingbo Wen > Cc: Y2038 > Cc: linux-kernel@vger.kernel.org > Cc: Arnd Bergmann > Cc: Felipe Balbi > Signed-off-by: WEN Pingbo > --- > drivers/usb/gadget/udc/dummy_hcd.c | 6 +++--- >

Re: [Y2038] [PATCH] dummy_hcd: replace timeval with timespec64

2015-09-15 Thread Pingbo Wen
rther risks, we still need to fix it here, >> to avoid similair problems. >> >> Signed-off-by: Pingbo Wen >> Cc: Y2038 >> Cc: linux-kernel@vger.kernel.org >> Cc: Arnd Bergmann >> Cc: Felipe Balbi > > I just replied to the thread of the first mail,