Re: [PATCH RFC V3.5] leds: trigger: Introduce an USB port trigger

zOn 08/24/2016 07:52 PM, Rafał Miłecki wrote: From: Rafał Miłecki This commit adds a new trigger responsible for turning on LED when USB device gets connected to the specified USB port. This can can useful for various home routers that have USB port(s) and a proper LED

Re: [PATCHv11 0/3] rdmacg: IB/core: rdma controller support

On Wed, Aug 24, 2016 at 05:17:47PM -0400, Tejun Heo wrote: > Looks good to me. I just have a nit in the documentation. Christoph, > what do you think? Looks reasonable from a quick look, but I didn't do a full review yet. -- To unsubscribe from this list: send the line "unsubscribe linux-doc"

[PATCH V4] leds: trigger: Introduce an USB port trigger

From: Rafał Miłecki This commit adds a new trigger responsible for turning on LED when USB device gets connected to the specified USB port. This can can useful for various home routers that have USB port(s) and a proper LED telling user a device is connected. The trigger gets

Re: [PATCH RFC V3.5] leds: trigger: Introduce an USB port trigger

On 25/08/16 10:03, Jacek Anaszewski wrote: zOn 08/24/2016 07:52 PM, Rafał Miłecki wrote: From: Rafał Miłecki This commit adds a new trigger responsible for turning on LED when USB device gets connected to the specified USB port. This can can useful for various home routers

Re: [PATCHv11 3/3] rdmacg: Added documentation for rdmacg

Hi Rami Rosen, On Thu, Aug 25, 2016 at 4:25 AM, Rami Rosen wrote: > Hi, > >> +Whenever RDMA resource charing occurs, owner rdma cgroup is returned to > Should be: charging instead of charing > >> +(b) Query resource limit: >> +cat /sys/fs/cgroup/rdma/2/rdma.max >> +#Output:

Re: [PATCH RFC V3.5] leds: trigger: Introduce an USB port trigger

On 08/25/2016 10:29 AM, Rafał Miłecki wrote: On 25 August 2016 at 10:03, Jacek Anaszewski wrote: On 08/24/2016 07:52 PM, Rafał Miłecki wrote: From: Rafał Miłecki This commit adds a new trigger responsible for turning on LED when USB device gets

Re: [PATCH V3] leds: trigger: Introduce an USB port trigger

On Thu, Aug 25, 2016 at 07:14:52AM +0200, Rafał Miłecki wrote: > On 24 August 2016 at 23:04, Greg KH wrote: > > On Wed, Aug 24, 2016 at 11:29:51AM +0200, Rafał Miłecki wrote: > >> On 24 August 2016 at 11:22, Greg KH wrote: > >> > On Wed,

Re: [PATCH V4] leds: trigger: Introduce an USB port trigger

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_data; > + int err; > + > + usbport_data = kzalloc(sizeof(*usbport_data), GFP_KERNEL); > + if (!usbport_data)

Re: [RFC PATCH v2 04/20] x86: Secure Memory Encryption (SME) support

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 addressing bits lost if > SME is enabled. What is the

imgmath and PDF output

Hi Jon, Mauro, Jani, today I tested imgmath, it worked well, but needs an additional dvipng installation ... What do you think, should we document the prerequisites on different linux distributions to build documentation with sphinx.ext.imgmath and PDF output? What I mean, in the meantime we

Re: imgmath and PDF output

Em Thu, 25 Aug 2016 15:03:16 +0200 Markus Heiser escreveu: > Hi Jon, Mauro, Jani, > > today I tested imgmath, it worked well, but needs an > additional dvipng installation ... > > What do you think, should we document the prerequisites > on different linux

Re: [PATCH RFC V3.5] leds: trigger: Introduce an USB port trigger

On Thu, 25 Aug 2016, Jacek Anaszewski wrote: > I'd see it as follows: > > #cat available_ports > #1-1 1-2 2-1 > > #echo "1-1" > new_port > > #cat observed_ports > #1-1 > > #echo "2-1" > new_port > > #cat observed_ports > #1-1 2-1 > > We've already had few discussions about the sysfs designs

Re: imgmath and PDF output

Em Thu, 25 Aug 2016 10:47:50 -0300 Mauro Carvalho Chehab escreveu: > Em Thu, 25 Aug 2016 15:03:16 +0200 > Markus Heiser escreveu: > > > Hi Jon, Mauro, Jani, > > > > today I tested imgmath, it worked well, but needs an > > additional dvipng

Re: [PATCH 0/5] Networking cgroup controller

On Thu, Aug 25, 2016 at 12:09:20PM -0400, Tejun Heo wrote: > ebpf approach does have its shortcomings for sure but mending them > seems a lot more manageable and future-proof than going with fixed but > constantly expanding set of operations. e.g. We can add per-cgroup > bpf programs which are

Re: [PATCH 0/5] Networking cgroup controller

On Thu, Aug 25, 2016 at 08:54:19AM -0700, Mahesh Bandewar (महेश बंडेवार) wrote: > On Wed, Aug 24, 2016 at 2:03 PM, Tejun Heo wrote: > > Hello, Anoop. > > > > On Wed, Aug 10, 2016 at 05:53:13PM -0700, Anoop Naravaram wrote: > >> This patchset introduces a cgroup controller for the

Re: [PATCH 01/19] compat ABI: use non-compat openat and open_by_handle_at variants

On Monday, August 15, 2016 5:30:28 PM CEST Yury Norov wrote: > On Mon, Jun 27, 2016 at 09:47:38AM +0200, Andreas Schwab wrote: > > Yury Norov writes: > > > > > The only difference is that non-compat version forces O_LARGEFILE, > > > and it should be the default

Re: [PATCH 0/5] Networking cgroup controller

On Wed, Aug 24, 2016 at 2:03 PM, Tejun Heo wrote: > Hello, Anoop. > > On Wed, Aug 10, 2016 at 05:53:13PM -0700, Anoop Naravaram wrote: >> This patchset introduces a cgroup controller for the networking subsystem as >> a >> whole. As of now, this controller will be used for: >>

Re: [PATCH 0/5] Networking cgroup controller

Hello, Mahesh. On Thu, Aug 25, 2016 at 08:54:19AM -0700, Mahesh Bandewar (महेश बंडेवार) wrote: > In short most of the associated problems are handled by the > cgroup-infra / APIs while all that need separate solution in > alternatives. Tejun, feels like I'm advocating cgroup approach to you > ;)

Re: [PATCH 0/5] Networking cgroup controller

On Thu, Aug 25, 2016 at 11:56:27AM -0700, Mahesh Bandewar (महेश बंडेवार) wrote: > On Thu, Aug 25, 2016 at 11:04 AM, Alexei Starovoitov > wrote: > > On Thu, Aug 25, 2016 at 08:54:19AM -0700, Mahesh Bandewar (महेश बंडेवार) > > wrote: > >> On Wed, Aug 24, 2016 at 2:03

Re: [PATCH V3] leds: trigger: Introduce an USB port trigger

Greg KH writes: > On Thu, Aug 25, 2016 at 07:14:52AM +0200, Rafał Miłecki wrote: >> >> Good question. I would like to extend this USB port trigger in the >> future by reacting to USB activity. This involves playing with URBs >> and I believe that at that point it'd be

Re: [PATCH 0/5] Networking cgroup controller

On Thu, Aug 25, 2016 at 9:09 AM, Tejun Heo wrote: > Hello, Mahesh. > > On Thu, Aug 25, 2016 at 08:54:19AM -0700, Mahesh Bandewar (महेश बंडेवार) > wrote: >> In short most of the associated problems are handled by the >> cgroup-infra / APIs while all that need separate solution in

Re: [PATCH v9 1/2] Documentation: kdump: remind user of nr_cpus

On Wed, 24 Aug 2016 13:06:45 +0800 Baoquan He wrote: > Hi Jon, do you think change as below is OK to you? So nr_cpus is the maximum value, and maxcpus is the current number. Figures. No wonder the documentation is confusing... Anyway, this is much more along the lines of what

Re: [PATCH v2 2/5] firmware: annotate thou shalt not request fw on init or probe

Summoning Felix for the embedded aspect on initramfs below. Jörg might be interested in the async facilities you speak of as well. On Thu, Aug 25, 2016 at 01:05:44PM +0200, Daniel Vetter wrote: > On Wed, Aug 24, 2016 at 10:39 PM, Luis R. Rodriguez wrote: > > On Wed, Aug 24,

Re: [PATCH 2/3] docs: split up the driver book

On Tue, 23 Aug 2016 11:30:16 -0300 Mauro Carvalho Chehab wrote: > I noticed several issues on the converted document. Just commenting > a few of them, as they all follow a pattern: kernel-doc markups > needs review during the conversion to RST, because, unfortunately, >

Re: [PATCH RFC V3.5] leds: trigger: Introduce an USB port trigger

On Thu, 25 Aug 2016, Alan Stern wrote: > > Does the lsusb command do the mapping in the user space or maybe > > it takes the names from kernel? > > lsusb does the mapping in userspace, based on an ID database. On my > system (Fedora), the database is /etc/udev/hwdb.bin. There's also

Re: [PATCH v2 2/5] firmware: annotate thou shalt not request fw on init or probe

On Thu, Aug 25, 2016 at 10:10:52PM +0200, Daniel Vetter wrote: > Cutting down since a lot of this is probably better discussed at > ks/lpc. Aside, if you want to check out Chris Wilson's work on our new > depency handling, it's called kfence. > > https://lkml.org/lkml/2016/7/17/37 Thanks more

Re: [PATCH RFC V3.5] leds: trigger: Introduce an USB port trigger

On 08/25/2016 04:30 PM, Alan Stern wrote: On Thu, 25 Aug 2016, Jacek Anaszewski wrote: I'd see it as follows: #cat available_ports #1-1 1-2 2-1 #echo "1-1" > new_port #cat observed_ports #1-1 #echo "2-1" > new_port #cat observed_ports #1-1 2-1 We've already had few discussions about the