On Mon, Aug 29, 2016 at 12:40:32PM -0400, Chris Metcalf wrote:
> On 8/29/2016 12:33 PM, Peter Zijlstra wrote:
> >On Tue, Aug 16, 2016 at 05:19:27PM -0400, Chris Metcalf wrote:
> >>+ /*
> >>+* Request rescheduling unless we are in full dynticks mode.
> >>+* We would eventually get pre-empt
On Mon, Aug 29, 2016 at 12:53:30PM -0400, Chris Metcalf wrote:
> Would it be cleaner to just replace the set_tsk_need_resched() call
> with something like:
>
> set_current_state(TASK_INTERRUPTIBLE);
> schedule();
> __set_current_state(TASK_RUNNING);
>
> or what would you recommend?
On Mon 29-08-16 16:37:04, Michal Hocko wrote:
> [Sorry for a late reply, I was busy with other stuff]
>
> On Mon 22-08-16 15:44:53, Sonny Rao wrote:
> > On Mon, Aug 22, 2016 at 12:54 AM, Michal Hocko wrote:
> [...]
> > But what about the private_clean and private_dirty? Surely
> > those are more
On Wed 24-08-16 12:14:06, Marcin Jabrzyk wrote:
[...]
> Sorry to hijack the thread, but I've found it recently
> and I guess it's the best place to present our point.
> We are working at our custom OS based on Linux and we also suffered much
> by /proc//smaps file. As in Chrome we tried to improve
On Fri, Aug 26, 2016 at 05:38:05PM +0200, Rafał Miłecki wrote:
> On 25 August 2016 at 14:49, Greg KH wrote:
> > On Thu, Aug 25, 2016 at 10:03:52AM +0200, Rafał Miłecki wrote:
> >> +static void usbport_trig_activate(struct led_classdev *led_cdev)
> >> +{
> >> + struct usbport_trig_data *usbport
On 08/25/2016 08:04 AM, Thomas Gleixner wrote:
> On Mon, 22 Aug 2016, Tom Lendacky wrote:
>
>> Provide support for Secure Memory Encryption (SME). This initial support
>> defines the memory encryption mask as a variable for quick access and an
>> accessor for retrieving the number of physical addr
On Aug 30, 2016 6:34 AM, "Tom Lendacky" wrote:
>
> On 08/25/2016 08:04 AM, Thomas Gleixner wrote:
> > On Mon, 22 Aug 2016, Tom Lendacky wrote:
> >
> >> Provide support for Secure Memory Encryption (SME). This initial support
> >> defines the memory encryption mask as a variable for quick access an
On 8/30/2016 3:58 AM, Peter Zijlstra wrote:
On Mon, Aug 29, 2016 at 12:40:32PM -0400, Chris Metcalf wrote:
On 8/29/2016 12:33 PM, Peter Zijlstra wrote:
On Tue, Aug 16, 2016 at 05:19:27PM -0400, Chris Metcalf wrote:
+ /*
+* Request rescheduling unless we are in full dynticks mode.
On Tue, Aug 30, 2016 at 8:32 AM, Chris Metcalf wrote:
> On 8/30/2016 3:58 AM, Peter Zijlstra wrote:
>>
>> On Mon, Aug 29, 2016 at 12:40:32PM -0400, Chris Metcalf wrote:
>>>
>>> On 8/29/2016 12:33 PM, Peter Zijlstra wrote:
On Tue, Aug 16, 2016 at 05:19:27PM -0400, Chris Metcalf wrote:
>>>
> -Original Message-
> From: Greg KH [mailto:gre...@linuxfoundation.org]
> Sent: Sunday, August 21, 2016 2:05 PM
> To: Kershner, David A
>
> On Fri, Jun 10, 2016 at 11:23:56PM -0400, David Kershner wrote:
> > visorbus is currently located at drivers/staging/visorbus,
> > this patch moves
On Tue, Aug 30, 2016 at 11:41:36AM -0400, Chris Metcalf wrote:
> On 8/29/2016 8:55 PM, Frederic Weisbecker wrote:
> >On Mon, Aug 15, 2016 at 10:59:55AM -0400, Chris Metcalf wrote:
> >>On 8/11/2016 2:50 PM, Christoph Lameter wrote:
> >>>On Thu, 11 Aug 2016, Frederic Weisbecker wrote:
> >>>
> Do
On 8/29/2016 8:55 PM, Frederic Weisbecker wrote:
On Mon, Aug 15, 2016 at 10:59:55AM -0400, Chris Metcalf wrote:
On 8/11/2016 2:50 PM, Christoph Lameter wrote:
On Thu, 11 Aug 2016, Frederic Weisbecker wrote:
Do we need to quiesce vmstat everytime before entering userspace?
I thought that vmsta
On 8/30/2016 12:30 PM, Andy Lutomirski wrote:
On Tue, Aug 30, 2016 at 8:32 AM, Chris Metcalf wrote:
On 8/30/2016 3:58 AM, Peter Zijlstra wrote:
On Mon, Aug 29, 2016 at 12:40:32PM -0400, Chris Metcalf wrote:
On 8/29/2016 12:33 PM, Peter Zijlstra wrote:
On Tue, Aug 16, 2016 at 05:19:27PM -0400
On Aug 30, 2016 10:02 AM, "Chris Metcalf" wrote:
>
> On 8/30/2016 12:30 PM, Andy Lutomirski wrote:
>>
>> On Tue, Aug 30, 2016 at 8:32 AM, Chris Metcalf wrote:
>>>
>>> On 8/30/2016 3:58 AM, Peter Zijlstra wrote:
On Mon, Aug 29, 2016 at 12:40:32PM -0400, Chris Metcalf wrote:
>
> O
On 8/30/2016 1:36 PM, Chris Metcalf wrote:
See the other thread with Peter Z for the longer discussion of this.
At this point I'm leaning towards replacing the set_tsk_need_resched() with
set_current_state(TASK_INTERRUPTIBLE);
schedule();
__set_current_state(TASK_RUNNING);
I don'
On Tue, Aug 30, 2016 at 12:37 PM, Chris Metcalf wrote:
> On 8/30/2016 2:43 PM, Andy Lutomirski wrote:
>>
>> On Aug 30, 2016 10:02 AM, "Chris Metcalf" wrote:
>>>
>>> On 8/30/2016 12:30 PM, Andy Lutomirski wrote:
On Tue, Aug 30, 2016 at 8:32 AM, Chris Metcalf
wrote:
>
> The
On 8/30/2016 2:43 PM, Andy Lutomirski wrote:
On Aug 30, 2016 10:02 AM, "Chris Metcalf" wrote:
On 8/30/2016 12:30 PM, Andy Lutomirski wrote:
On Tue, Aug 30, 2016 at 8:32 AM, Chris Metcalf wrote:
The basic idea is just that we don't want to be at risk from the
dyntick getting enabled. Similar
On 30 August 2016 at 14:05, Greg KH wrote:
> On Fri, Aug 26, 2016 at 05:38:05PM +0200, Rafał Miłecki wrote:
>> On 25 August 2016 at 14:49, Greg KH wrote:
>> > On Thu, Aug 25, 2016 at 10:03:52AM +0200, Rafał Miłecki wrote:
>> >> +static void usbport_trig_activate(struct led_classdev *led_cdev)
>>
On Tue, 30 Aug 2016, Rafał Miłecki wrote:
> Please take a look at Documentation to get some idea of LED triggers:
> Documentation/leds/leds-class.txt
>
> Basically a LED (/sys/class/leds/foo/) can be controller with
> "brightness" sysfs file like this:
> echo 0 > brightness
> echo 5 > brightness
On 30 August 2016 at 22:54, Alan Stern wrote:
> On Tue, 30 Aug 2016, Rafał Miłecki wrote:
>
>> Please take a look at Documentation to get some idea of LED triggers:
>> Documentation/leds/leds-class.txt
>>
>> Basically a LED (/sys/class/leds/foo/) can be controller with
>> "brightness" sysfs file l
On 8/30/2016 1:10 PM, Frederic Weisbecker wrote:
On Tue, Aug 30, 2016 at 11:41:36AM -0400, Chris Metcalf wrote:
On 8/29/2016 8:55 PM, Frederic Weisbecker wrote:
On Mon, Aug 15, 2016 at 10:59:55AM -0400, Chris Metcalf wrote:
On 8/11/2016 2:50 PM, Christoph Lameter wrote:
On Thu, 11 Aug 2016, F
Improve the parser to handle typedefs like:
typedef bool v4l2_check_dv_timings_fnc(const struct v4l2_dv_timings *t,
void *handle);
Signed-off-by: Mauro Carvalho Chehab
---
scripts/kernel-doc | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/scripts/kernel-doc b/scr
The kernel-doc parser has two issues when handling typedef functions:
1) its parse is incomplete;
2) it causes warnings when a typedef is used as a function argument.
This series partially addresses (1), adding one extra syntax for the parser.
I'm pretty sure that the parser is still incomplete a
When using a typedef function like this one:
typedef bool v4l2_check_dv_timings_fnc (const struct v4l2_dv_timings *
t, void * handle);
The Sphinx C domain expects it to create a c:type: reference,
as that's the way it creates the type references when parsing
a c:function:: declaration.
S
24 matches
Mail list logo
