Re: [PATCH v6] leds: documentation: 'ide-disk' to 'disk-activity'
Hi Stephan,
On 06/24/2016 07:16 PM, Stephan Linz wrote:
Cc: Joseph Jezak
Cc: Jörg Sommer
Cc: Mark Rutland
Signed-off-by: Stephan Linz
Acked-by: Rob Herring
Signed-off-by: Jacek Anaszewski
---
Changes in v6:
- Reorganize v5.
Changes in v5:
- Keep documentation for the old 'ide-disk' device tree
binding, but mark as deprecated and refer to the new
trigger 'disk-activity'.
Changes in v4:
- Keep the 'ide-disk' trigger and add a second one
for 'disk-activity'.
Changes in v3:
- Port to kernel 4.x
- Split into platform independent and dependent parts.
v2: https://patchwork.ozlabs.org/patch/117485/
v1: http://dev.gentoo.org/~josejx/ata.patch
---
Documentation/devicetree/bindings/leds/common.txt| 4 +++-
Documentation/devicetree/bindings/leds/leds-gpio.txt | 4 ++--
Documentation/laptops/asus-laptop.txt| 2 +-
Documentation/leds/leds-class.txt| 2 +-
4 files changed, 7 insertions(+), 5 deletions(-)
diff --git a/Documentation/devicetree/bindings/leds/common.txt
b/Documentation/devicetree/bindings/leds/common.txt
index af10678..93ef6e6 100644
--- a/Documentation/devicetree/bindings/leds/common.txt
+++ b/Documentation/devicetree/bindings/leds/common.txt
@@ -26,7 +26,9 @@ Optional properties for child nodes:
"default-on" - LED will turn on (but for leds-gpio see "default-state"
property in Documentation/devicetree/bindings/gpio/led.txt)
"heartbeat" - LED "double" flashes at a load average based rate
- "ide-disk" - LED indicates disk activity
+ "disk-activity" - LED indicates disk activity
+ "ide-disk" - LED indicates IDE disk activity (deprecated),
+ in new implementations use "disk-activity"
"timer" - LED flashes at a fixed, configurable rate
- led-max-microamp : Maximum LED supply current in microamperes. This property
diff --git a/Documentation/devicetree/bindings/leds/leds-gpio.txt
b/Documentation/devicetree/bindings/leds/leds-gpio.txt
index cbbeb18..5b1b43a 100644
--- a/Documentation/devicetree/bindings/leds/leds-gpio.txt
+++ b/Documentation/devicetree/bindings/leds/leds-gpio.txt
@@ -33,9 +33,9 @@ Examples:
leds {
compatible = "gpio-leds";
hdd {
- label = "IDE Activity";
+ label = "Disk Activity";
gpios = <&mcu_pio 0 GPIO_ACTIVE_LOW>;
- linux,default-trigger = "ide-disk";
+ linux,default-trigger = "disk-activity";
};
fault {
diff --git a/Documentation/laptops/asus-laptop.txt
b/Documentation/laptops/asus-laptop.txt
index 79a1bc6..5f28587 100644
--- a/Documentation/laptops/asus-laptop.txt
+++ b/Documentation/laptops/asus-laptop.txt
@@ -72,7 +72,7 @@ LEDs
echo 1 > /sys/class/leds/asus::mail/brightness
will switch the mail LED on.
You can also know if they are on/off by reading their content and use
- kernel triggers like ide-disk or heartbeat.
+ kernel triggers like disk-activity or heartbeat.
Backlight
-
diff --git a/Documentation/leds/leds-class.txt
b/Documentation/leds/leds-class.txt
index 44f5e6b..f1f7ec9 100644
--- a/Documentation/leds/leds-class.txt
+++ b/Documentation/leds/leds-class.txt
@@ -11,7 +11,7 @@ brightness support so will just be turned on for non-zero
brightness settings.
The class also introduces the optional concept of an LED trigger. A trigger
is a kernel based source of led events. Triggers can either be simple or
complex. A simple trigger isn't configurable and is designed to slot into
-existing subsystems with minimal additional code. Examples are the ide-disk,
+existing subsystems with minimal additional code. Examples are the
disk-activity,
nand-disk and sharpsl-charge triggers. With led triggers disabled, the code
optimises away.
Applied, thanks.
--
Best regards,
Jacek Anaszewski
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 01/19] compat ABI: use non-compat openat and open_by_handle_at variants
Yury Norov writes: > The only difference is that non-compat version forces O_LARGEFILE, > and it should be the default behaviour for all architectures, as > we don't support 32-bit off_t. The only exception is tile32, that > continues with compat version of syscalls. > > Signed-off-by: Yury Norov > Acked-by: Arnd Bergmann > Acked-by: Chris Metcalf [for tile] > --- > arch/tile/kernel/compat.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/arch/tile/kernel/compat.c b/arch/tile/kernel/compat.c > index 4912084..489ae19 100644 > --- a/arch/tile/kernel/compat.c > +++ b/arch/tile/kernel/compat.c > @@ -94,6 +94,9 @@ COMPAT_SYSCALL_DEFINE5(llseek, unsigned int, fd, unsigned > int, offset_high, > #define compat_sys_readahead sys32_readahead > #define sys_llseek compat_sys_llseek > > +#define sys_openat compat_sys_openat > +#define sys_open_by_handle_atcompat_sys_open_by_handle_at > + > /* Call the assembly trampolines where necessary. */ > #define compat_sys_rt_sigreturn _compat_sys_rt_sigreturn > #define sys_clone _sys_clone This is a no-op. Did you mean to add this? Without that the testsuite of tar fails on ILP32. diff --git a/include/uapi/asm-generic/unistd.h b/include/uapi/asm-generic/unistd.h index a26415b..4dcc38d 100644 --- a/include/uapi/asm-generic/unistd.h +++ b/include/uapi/asm-generic/unistd.h @@ -178,7 +178,7 @@ __SYSCALL(__NR_fchownat, sys_fchownat) #define __NR_fchown 55 __SYSCALL(__NR_fchown, sys_fchown) #define __NR_openat 56 -__SC_COMP(__NR_openat, sys_openat, compat_sys_openat) +__SYSCALL(__NR_openat, sys_openat) #define __NR_close 57 __SYSCALL(__NR_close, sys_close) #define __NR_vhangup 58 @@ -676,8 +676,7 @@ __SYSCALL(__NR_fanotify_mark, sys_fanotify_mark) #define __NR_name_to_handle_at 264 __SYSCALL(__NR_name_to_handle_at, sys_name_to_handle_at) #define __NR_open_by_handle_at 265 -__SC_COMP(__NR_open_by_handle_at, sys_open_by_handle_at, \ - compat_sys_open_by_handle_at) +__SYSCALL(__NR_open_by_handle_at, sys_open_by_handle_at) #define __NR_clock_adjtime 266 __SC_COMP(__NR_clock_adjtime, sys_clock_adjtime, compat_sys_clock_adjtime) #define __NR_syncfs 267 -- 2.9.0 Andreas. -- Andreas Schwab, SUSE Labs, sch...@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different." -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ilp32: fix {GET,SET}SIGMASK request for ptrace
On 2016/6/27 13:39, Yury Norov wrote:
Hi Zhou,
Thank you for the patch. The idea is ok, but patch format got broken
for some reason. Could you re-send it?
Yury.
Sorry for the broken patch, maybe my mail guest has some problems. So
I send the patch as an attachment.
Thanks!
On Mon, Jun 27, 2016 at 12:49:05PM +0800, zhouchengming wrote:
atus: RO
Content-Length: 4732
Lines: 181
The function compat_ptrace_request(used by ilp32) don't handle
{GET,SET}SIGMASK request, so it will be handled by ptrace_request.
But it's wrong because the compat_sigset_t of ilp32 differs from
the sigset_t of aarch64. The patch fixes it.
Signed-off-by: Zhou Chengming
---
arch/arm64/include/asm/signal_ilp32.h | 22
arch/arm64/kernel/ptrace.c| 62
+
Here - unneeded line break
arch/arm64/kernel/signal_ilp32.c | 23 +
3 files changed, 85 insertions(+), 22 deletions(-)
diff --git a/arch/arm64/include/asm/signal_ilp32.h
b/arch/arm64/include/asm/signal_ilp32.h
and here
index 30eff23..ed52607 100644
--- a/arch/arm64/include/asm/signal_ilp32.h
+++ b/arch/arm64/include/asm/signal_ilp32.h
@@ -21,6 +21,28 @@
int ilp32_setup_rt_frame(int usig, struct ksignal *ksig, sigset_t *set,
struct pt_regs *regs);
+static inline int put_sigset_t(compat_sigset_t __user *uset, sigset_t *set)
+{
+ compat_sigset_t cset;
+
+ cset.sig[0] = set->sig[0]& 0xull;
+ cset.sig[1] = set->sig[0]>> 32;
+
+ return copy_to_user(uset,&cset, sizeof(*uset));
+}
+
+static inline int get_sigset_t(sigset_t *set,
+ const compat_sigset_t __user *uset)
+{
+ compat_sigset_t s32;
+
+ if (copy_from_user(&s32, uset, sizeof(*uset)))
+ return -EFAULT;
+
+ set->sig[0] = s32.sig[0] | (((long)s32.sig[1])<< 32);
+ return 0;
+}
+
#else
static inline int ilp32_setup_rt_frame(int usig, struct ksignal *ksig,
sigset_t *set,
and here
diff --git a/arch/arm64/kernel/ptrace.c b/arch/arm64/kernel/ptrace.c
index a861105..8d4cad1 100644
--- a/arch/arm64/kernel/ptrace.c
+++ b/arch/arm64/kernel/ptrace.c
@@ -44,6 +44,7 @@
#include
#include
#include
+#include
#define CREATE_TRACE_POINTS
#include
@@ -1231,12 +1232,73 @@ COMPAT_SYSCALL_DEFINE4(aarch32_ptrace,
compat_long_t, request, compat_long_t, pi
and later on the patch
#endif /* CONFIG_AARCH32_EL0 */
+#ifdef CONFIG_ARM64_ILP32
+
+static int compat_ilp32_ptrace(struct task_struct *child, compat_long_t
request,
+ compat_ulong_t addr, compat_ulong_t data)
+{
+ compat_ulong_t __user *datap = compat_ptr(data);
+ int ret;
+
+ switch (request) {
+ case PTRACE_GETSIGMASK:
+ if (addr != sizeof(compat_sigset_t)) {
+ ret = -EINVAL;
+ break;
+ }
+
+ if (put_sigset_t((compat_sigset_t __user
*)datap,&child->blocked))
+ ret = -EFAULT;
+ else
+ ret = 0;
+ break;
+
+ case PTRACE_SETSIGMASK: {
+ sigset_t new_set;
+ if (addr != sizeof(compat_sigset_t)) {
+ ret = -EINVAL;
+ break;
+ }
+
+ if (get_sigset_t(&new_set, (compat_sigset_t __user *)datap)) {
+ ret = -EFAULT;
+ break;
+ }
+
+ sigdelsetmask(&new_set, sigmask(SIGKILL)|sigmask(SIGSTOP));
+
+ /*
+* Every thread does recalc_sigpending() after resume, so
+* retarget_shared_pending() and recalc_sigpending() are not
+* called here.
+*/
+ spin_lock_irq(&child->sighand->siglock);
+ child->blocked = new_set;
+ spin_unlock_irq(&child->sighand->siglock);
+
+ ret = 0;
+ break;
+ }
+
+ default:
+ ret = compat_ptrace_request(child, request, addr, data);
+ }
+
+ return ret;
+}
+
+#endif /* CONFIG_ARM64_ILP32 */
+
#ifdef CONFIG_COMPAT
long compat_arch_ptrace(struct task_struct *child, compat_long_t request,
compat_ulong_t caddr, compat_ulong_t cdata)
{
+#ifdef CONFIG_ARM64_ILP32
+ return compat_ilp32_ptrace(child, request, caddr, cdata);
+#else
return compat_ptrace_request(child, request, caddr, cdata);
+#endif
}
#endif /* CONFIG_COMPAT */
diff --git a/arch/arm64/kernel/signal_ilp32.c
b/arch/arm64/kernel/signal_ilp32.c
index 8ca64b9..3ef2749 100644
--- a/arch/arm64/kernel/signal_ilp32.c
+++ b/arch/arm64/kernel/signal_ilp32.c
@@ -28,6 +28,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -58,28 +59,6 @@ struct ilp32_rt_sigframe {
struct ilp32_sigframe sig;
};
-static inline int put_sigset_t(compat_sigset_t __user *uset, sigse
Re: [PATCH] capabilities: add capability cgroup controller
Quoting Tejun Heo (t...@kernel.org): > Hello, Topi. > > On Sun, Jun 26, 2016 at 3:14 PM, Topi Miettinen wrote: > > The parent might be able do it if proc/pid/xyz files are still > > accessible after child exit but before its exit status is collected. But > > if the parent doesn't do it (and you are not able to change it to do it) > > and it collects the exit status without collecting other info, can you > > suggest a different way how another process could collect it 100% reliably? > > I'm not saying that there's such mechanism now. I'm suggesting that > that'd be a more fitting way of implementing a new mechanism to track > capability usages. Hi Topi, I think Eric was right a few emails earlier that the audit subsystem is really the most appropriate answer to this. (Perhaps sysctl-controllered?) Combined with taskstats it would give you what you need. Or you could even use an empty new named cgroup controller, say 'none,name=caps', and then look only at audit results for cgroup '/myapp' in the caps hierarchy. -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v8 4/4] Input: synaptics-rmi4 - add SMBus support
On Jun 24 2016 or thereabouts, Dmitry Torokhov wrote:
> On Fri, Jun 24, 2016 at 09:19:32AM +0200, Benjamin Tissoires wrote:
> > On Jun 23 2016 or thereabouts, Dmitry Torokhov wrote:
> > > On Thu, Jun 09, 2016 at 04:53:50PM +0200, Benjamin Tissoires wrote:
> > > > +
> > > > +static struct i2c_driver rmi_smb_driver = {
> > > > + .driver = {
> > > > + .owner = THIS_MODULE,
> > > > + .name = "rmi4_smbus",
> > > > + .pm = &rmi_smb_pm,
> > > > + .resume = rmi_smb_resume,
> > >
> > > Why rmi_smb_resume is not part of rmi_smb_pm?
> > >
> >
> > This is because rmi_smbus device both have a PS/2 interface and a SMBus
> > one. I'll have to check again now that I have a slightly different way
> > of binding smbus devices in my tree, but the issue was:
> > - having resume part of pm means it will get caught by PM directly
> > - the PS/2 node gets also resumed by PM
> > - calling PS/2 commands during resume switches the devices back into
> > PS/2 and stops the SMBus communication.
> >
> > So it's easier to wait only for the PS/2 PM resume call which will call
> > the SMBus resume function when the device is in a proper state.
> >
> > I'll send out the updated patch with your comments next week hopefully.
>
> Hmm, I think you will have to walk me through resume process. How do we
> tie in PS/2 and I2C on these devices abd have PS/2 code call into this
> driver?
>
Sure.
For starters, here is my latest WIP (I need to rework on the series for
commit messages and probably squash some patches):
https://github.com/bentiss/linux/commits/synaptics-rmi4-smbus-v4.7-rc4%2B
Then, let me explain the problems we have with those touchpads and the
resume process.
The touchpads are both connected to PS/2 and SMBus as you know. However,
there is no SMBus enumeration entry anywhere in the system. Luckily,
the PS/2 chip is aware of the other bus, and can be polled to
request whether or not we are confronted to a RMI4 over SMBus device
(see
https://github.com/bentiss/linux/commit/a3e67de764656201522962028bc783fc4b921de3
)
Of course, to make those touchpads robust with reboots and allow legacy
drivers (PS/2) to use them, the firmware tend to switch back to PS/2 as
soon as you issue a PS/2 reset command or if you send some other PS/2
commands. The problem we have is that if you send some various PS/2
commands to the touchpad, it disconnects from the SMBus entirely (it
took me one year to understand why the device was not showing up on
I2C).
The last interesting fact for those touchpad is that you need to enable
SMBus communication by issuing a SMB_PROTOCOL_VERSION_ADDRESS command.
If you do not issue this after a PS/2 reset, the device is muted over
SMBus.
So, to be sure we can query the touchpad from PS/2 and to control the
PS/2 commands and the resume, I have in the series above a separate PS/2
driver for this touchpad. The regular psmouse driver probes the PS/2
chip, but aborts seeing the SMBus capability. Then rmi_ps2 takes over
and binds to the PS/2 chip to fill in the platform data required by
rmi_smbus
(https://github.com/bentiss/linux/commit/3ceb7c80ecee17a86b8ae8476211c7498cc823d2)
If we simply unbind the PS/2 node and let it dangling, the serio driver
issues a reconnect after resume on both the PS/2 chip of the touchpad,
and the PS/2 pass-through node of the trackstick.
But if the PS/2 chip of the touchpad is left dangling, the resume
process will first call a reconnect on the pass-through, then on
the touchpad through the enumeration of the serio bus, which will reset
the touchpad and messed up the pass-through node and the rmi-smbus
driver.
So keeping around a reference to the PS/2 node allows to set this node
as a parent of the pass-through trackstick node and guarantees that the
touchpad will be resumed before the trackstick.
One final thing. I tried not having rmi_ps2 calling the .resume callback
of rmi_smbus and keeping rmi_smbus as a PM. But the issue is that the
serio driver sends the reset command in a workqueue as it can takes some
time:
- serio gets resume called -> prepare the worker for the
resume/reconnect process
- rmi_smbus gets resumed -> OK
- the worker kicks in, reset the PS/2 lines, and shuts down the
rmi_smbus device
I also tried one thing where I did not bind the PS/2 touchpad at all
(and having some kind of platform driver to bind rmi_smbus). And of
course, grub initializes the touchpad, so it disconnects on I2C and you
can't bind it on SMBus, ever :)
I think that's all I know on these touchpads and this is all the mess I can
present. If you have a better option, I'm all ears as this is not clean,
but I can't figure out a better way.
Cheers,
Benjamin
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv5 8/8] ARM: dts: Add Arria10 Ethernet EDAC devicetree entry
Hi Boris, On 06/22/2016 08:58 AM, ttha...@opensource.altera.com wrote: > From: Thor Thayer > > Add the device tree entries needed to support the Altera Ethernet > FIFO buffer EDAC on the Arria10 chip. > > Signed-off-by: Thor Thayer > --- > v2 No change > v3 Add interrupts for SBERR and DBERR. > v4 No change > v5 Change "parent" phandle to "altr,ecc-parent" > --- > arch/arm/boot/dts/socfpga_arria10.dtsi | 16 > 1 file changed, 16 insertions(+) > I've applied this patch and will take through the arm-soc tree. Thanks, Dinh -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv5 8/8] ARM: dts: Add Arria10 Ethernet EDAC devicetree entry
On Mon, Jun 27, 2016 at 10:31:29AM -0500, Dinh Nguyen wrote: > I've applied this patch and will take through the arm-soc tree. I already took the whole branch two days ago: http://git.kernel.org/cgit/linux/kernel/git/bp/bp.git/log/?h=for-next So we need to sort this out as it has come up in the past. Either you pick up all patches and I ack them or I do and you ack the one. But splitting the patchset between trees is always calling for trouble. So what are doing, wanna give me your Ack for that patch instead and I can carry the whole set upstream? -- Regards/Gruss, Boris. ECO tip #101: Trim your mails when you reply. -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv5 8/8] ARM: dts: Add Arria10 Ethernet EDAC devicetree entry
On 06/27/2016 11:18 AM, Borislav Petkov wrote: > On Mon, Jun 27, 2016 at 10:31:29AM -0500, Dinh Nguyen wrote: >> I've applied this patch and will take through the arm-soc tree. > > I already took the whole branch two days ago: > > http://git.kernel.org/cgit/linux/kernel/git/bp/bp.git/log/?h=for-next > > So we need to sort this out as it has come up in the past. Either you > pick up all patches and I ack them or I do and you ack the one. But > splitting the patchset between trees is always calling for trouble. > > So what are doing, wanna give me your Ack for that patch instead and I > can carry the whole set upstream? > Ok, sorry about that. Please carry the whole set: Acked-by: Dinh Nguyen Dinh -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/10] Documentation/Sphinx
Em Mon, 27 Jun 2016 08:15:28 +0200 Markus Heiser escreveu: > Am 24.06.2016 um 12:40 schrieb Mauro Carvalho Chehab > : > > > Em Tue, 31 May 2016 12:16:25 +0200 > > Markus Heiser escreveu: > > > >> Am 30.05.2016 um 23:23 schrieb Mauro Carvalho Chehab > >> : > >> > >>> Em Mon, 30 May 2016 23:05:34 +0300 > >>> Jani Nikula escreveu: > >>> > > I worry a little bit in that reST will be only one more toolchain > > beside DocBook .. in the long term, kernel's documentation > > should get rid of all the DocBook artifacts and for this a more > > comprehensive solution is needed. > > We agree on the end goal, eradicate DocBook. I must say that in my > experiments, apart from the media docs, almost everything converts > surprisingly nicely or IMO "good enough" with just the tmplcvt script in > this series. > >>> > >>> With regards to media, my plan is to merge create a topic branch based > >>> on Kernel 4.7-rc1 at: > >>> https://git.linuxtv.org/media_tree.git/ > >>> > >>> As none of the Jani's patches seem to affect the media API docs, it > >>> seems I don't need to merge back from Jon's -next branch. > >>> > >>> There, I intend to add Markus patches with the conversion from the > >>> DocBook to rst, plus the flat-table extension logic. > >>> > >>> Then, I'll work to manually fix what's needed and I'll add the > >>> automation scripting logic that we have at the DocBook Makefile > >>> to work with the new media rst files. > >>> > >>> Lastly, once the job's done, I'll drop Documentation/DocBook/media. > >>> > >>> Markus, > >>> > >>> With that regards, could you please send the patches to me? > >> > >> Yes. What is your timeline ... is it OK if I send you a patch in the > >> next two weeks? ... first I wan't to finish my other work / I'am just > >> back from holiday .. a lot of work to do :-o > > > > Hi Markus, > > > > I'm wanting to start working on it next week, if possible. > > > > I created an experimental branch on my tree for such work, where > > I'm merging from both Jon's doc-next tree and from media tree at: > > https://git.linuxtv.org//mchehab/experimental.git/log/?h=docs-next > > > > Could you please rebase your work with the media DocBook and with > > the flat-table support to be on the top of it? > > > > Thanks! > > Mauro > > Hi Mauro, > > sorry for my late reply, I finished the man-page builder last weekend. > > > I'm merging from both Jon's doc-next tree and from media tree > > Currently I'am working on a rebase on top of the Jon's docs-next branch > (with "s" in "docs-" / think it was only a typo). > > Hopefully I get this done in the next 2 days. > > I will send a pull request when I'am finished / thanks for your > patience until then. Ok! Thanks for your work! Regards, Mauro -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv5 8/8] ARM: dts: Add Arria10 Ethernet EDAC devicetree entry
On Mon, Jun 27, 2016 at 11:13:05AM -0500, Dinh Nguyen wrote: > Ok, sorry about that. Please carry the whole set: > > Acked-by: Dinh Nguyen Thanks! -- Regards/Gruss, Boris. ECO tip #101: Trim your mails when you reply. -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] capabilities: add capability cgroup controller
On 06/27/16 14:54, Serge E. Hallyn wrote: > Quoting Tejun Heo (t...@kernel.org): >> Hello, Topi. >> >> On Sun, Jun 26, 2016 at 3:14 PM, Topi Miettinen wrote: >>> The parent might be able do it if proc/pid/xyz files are still >>> accessible after child exit but before its exit status is collected. But >>> if the parent doesn't do it (and you are not able to change it to do it) >>> and it collects the exit status without collecting other info, can you >>> suggest a different way how another process could collect it 100% reliably? >> >> I'm not saying that there's such mechanism now. I'm suggesting that >> that'd be a more fitting way of implementing a new mechanism to track >> capability usages. > > Hi Topi, > > I think Eric was right a few emails earlier that the audit subsystem is > really the most appropriate answer to this. (Perhaps sysctl-controllered?) > Combined with taskstats it would give you what you need. Or you could even > use an empty new named cgroup controller, say 'none,name=caps', and then > look only at audit results for cgroup '/myapp' in the caps hierarchy. > I'll have to study these more. But from what I saw so far, it looks to me that a separate tool would be needed to read taskstats and if that tool is not taken by distros, the users would not be any wiser, right? With cgroup (or /proc), no new tools would be needed. -Topi -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] capabilities: add capability cgroup controller
Hello, On Mon, Jun 27, 2016 at 3:10 PM, Topi Miettinen wrote: > I'll have to study these more. But from what I saw so far, it looks to > me that a separate tool would be needed to read taskstats and if that > tool is not taken by distros, the users would not be any wiser, right? > With cgroup (or /proc), no new tools would be needed. That is a factor but shouldn't be a deciding factor in designing our user-facing interfaces. Please also note that kernel source tree already has tools/ subdirectory which contains userland tools which are distributed along with the kernel. Thanks. -- tejun -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] capabilities: add capability cgroup controller
Quoting Tejun Heo (t...@kernel.org): > Hello, > > On Mon, Jun 27, 2016 at 3:10 PM, Topi Miettinen wrote: > > I'll have to study these more. But from what I saw so far, it looks to > > me that a separate tool would be needed to read taskstats and if that > > tool is not taken by distros, the users would not be any wiser, right? > > With cgroup (or /proc), no new tools would be needed. > > That is a factor but shouldn't be a deciding factor in designing our > user-facing interfaces. Please also note that kernel source tree > already has tools/ subdirectory which contains userland tools which > are distributed along with the kernel. And, if you take audit+cgroup approach then no tools are needed. So long as you can have audit print out the cgroups for a task as part of the capability audit record. -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] hwmon: (jc42) Add support for Microchip MCP9808 temperature sensor
MCP9808 is not officially compliant to JC-42, similar to MCP9804,
but its registers are compatible to JC-42.
Signed-off-by: Alison Schofield
Cc: Daniel Baluta
---
Documentation/hwmon/jc42 | 3 ++-
drivers/hwmon/Kconfig| 4 ++--
drivers/hwmon/jc42.c | 4
3 files changed, 8 insertions(+), 3 deletions(-)
diff --git a/Documentation/hwmon/jc42 b/Documentation/hwmon/jc42
index f7f1830a..b4b671f 100644
--- a/Documentation/hwmon/jc42
+++ b/Documentation/hwmon/jc42
@@ -18,10 +18,11 @@ Supported chips:
* Maxim MAX6604
Datasheets:
http://datasheets.maxim-ic.com/en/ds/MAX6604.pdf
- * Microchip MCP9804, MCP9805, MCP98242, MCP98243, MCP98244, MCP9843
+ * Microchip MCP9804, MCP9805, MCP9808, MCP98242, MCP98243, MCP98244, MCP9843
Datasheets:
http://ww1.microchip.com/downloads/en/DeviceDoc/22203C.pdf
http://ww1.microchip.com/downloads/en/DeviceDoc/21977b.pdf
+ http://ww1.microchip.com/downloads/en/DeviceDoc/25095A.pdf
http://ww1.microchip.com/downloads/en/DeviceDoc/21996a.pdf
http://ww1.microchip.com/downloads/en/DeviceDoc/22153c.pdf
http://ww1.microchip.com/downloads/en/DeviceDoc/22327A.pdf
diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
index 5c2d13a..7dfc763 100644
--- a/drivers/hwmon/Kconfig
+++ b/drivers/hwmon/Kconfig
@@ -644,8 +644,8 @@ config SENSORS_JC42
temperature sensors, which are used on many DDR3 memory modules for
mobile devices and servers. Support will include, but not be limited
to, ADT7408, AT30TS00, CAT34TS02, CAT6095, MAX6604, MCP9804, MCP9805,
- MCP98242, MCP98243, MCP98244, MCP9843, SE97, SE98, STTS424(E),
- STTS2002, STTS3000, TSE2002, TSE2004, TS3000, and TS3001.
+ MCP9808, MCP98242, MCP98243, MCP98244, MCP9843, SE97, SE98,
+ STTS424(E), STTS2002, STTS3000, TSE2002, TSE2004, TS3000, and TS3001.
This driver can also be built as a module. If so, the module
will be called jc42.
diff --git a/drivers/hwmon/jc42.c b/drivers/hwmon/jc42.c
index 9887d32..f67c1bb 100644
--- a/drivers/hwmon/jc42.c
+++ b/drivers/hwmon/jc42.c
@@ -104,6 +104,9 @@ static const unsigned short normal_i2c[] = {
#define MCP9804_DEVID 0x0200
#define MCP9804_DEVID_MASK 0xfffc
+#define MCP9808_DEVID 0x0400
+#define MCP9808_DEVID_MASK 0xfffc
+
#define MCP98242_DEVID 0x2000
#define MCP98242_DEVID_MASK0xfffc
@@ -160,6 +163,7 @@ static struct jc42_chips jc42_chips[] = {
{ IDT_MANID, TS3001_DEVID, TS3001_DEVID_MASK },
{ MAX_MANID, MAX6604_DEVID, MAX6604_DEVID_MASK },
{ MCP_MANID, MCP9804_DEVID, MCP9804_DEVID_MASK },
+ { MCP_MANID, MCP9808_DEVID, MCP9808_DEVID_MASK },
{ MCP_MANID, MCP98242_DEVID, MCP98242_DEVID_MASK },
{ MCP_MANID, MCP98243_DEVID, MCP98243_DEVID_MASK },
{ MCP_MANID, MCP98244_DEVID, MCP98244_DEVID_MASK },
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] hwmon: (jc42) Add support for Microchip MCP9808 temperature sensor
On 06/27/2016 05:23 PM, Alison Schofield wrote: MCP9808 is not officially compliant to JC-42, similar to MCP9804, but its registers are compatible to JC-42. Signed-off-by: Alison Schofield Cc: Daniel Baluta Applied to -next. Thanks, Guenter -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] capabilities: add capability cgroup controller
Topi Miettinen writes: > On 06/24/16 17:21, Eric W. Biederman wrote: >> "Serge E. Hallyn" writes: >> >>> Quoting Tejun Heo (t...@kernel.org): Hello, On Fri, Jun 24, 2016 at 10:59:16AM -0500, Serge E. Hallyn wrote: > Quoting Tejun Heo (t...@kernel.org): >> But isn't being recursive orthogonal to using cgroup? Why not account >> usages recursively along the process hierarchy? Capabilities don't >> have much to do with cgroup but everything with process hierarchy. >> That's how they're distributed and modified. If monitoring their >> usages is necessary, it makes sense to do it in the same structure. > > That was my argument against using cgroups to enforce a new bounding > set. For tracking though, the cgroup process tracking seems as applicable > to this as it does to systemd tracking of services. It tracks a task and > the children it forks. Just monitoring is less jarring than implementing security enforcement via cgroup, but it is still jarring. What's wrong with recursive process hierarchy monitoring which is in line with the whole facility is implemented anyway? >>> >>> As I think Topi pointed out, one shortcoming is that if there is a >>> short-lived >>> child task, using its /proc/self/status is racy. You might just miss that >>> it >>> ever even existed, let alone that the "application" needed it. >>> >>> Another alternative we've both mentioned is to use systemtap. That's not >>> as nice a solution as a cgroup, but then again this isn't really a common >>> case, so maybe it is precisely what a tracing infrastructure is meant for. >> >> Hmm. >> >> We have capability use wired up into auditing. So we might be able to >> get away with just adding an appropriate audit message in >> commoncap.c:cap_capable that honors the audit flag and logs an audit >> message. The hook in selinux already appears to do that. >> >> Certainly audit sounds like the subsystem for this kind of work, as it's >> whole point in life is logging things, then something in userspace can >> just run over the audit longs and build a nice summary. > > Even simpler would be to avoid the complexity of audit subsystem and > just printk() when a task starts using a capability first time (not on > further uses by same task). There are not that many capability bits nor > privileged processes, meaning not too many log entries. I know as this > was actually my first approach. But it's also far less user friendly > than just reading a summarized value which could be directly fed back to > configuration. Your loss. > Logging/auditing approach also doesn't work well for other things I'd > like to present meaningful values for the user. For example, consider > RLIMIT_AS, where my goal is also to enable the users to be able to > configure this limit for a service. Should there be an audit message > whenever the address space limit grows (i.e. each mmap())? What about > when it shrinks? For RLIMIT_NOFILE we'd have to report each > open()/close()/dup()/socket()/etc. and track how many are opened at the > same time. I think it's better to store the fully cooked (meaningful to > user) value in kernel and present it only when asked. That doesn't have anything to do with anything. My suggestion was very much to do with capabilities which are already logged with the audit subsystem with selinux. The idea was to move those audit calls into commoncap where they arguably belong allow anyone to use them for anything. That is a non-controversial code cleanup that happens to cover your special case. That is enough to build a tool in userspace that will tell you which capabilities you need without penalizing the kernel, or the vast majority of everyone who does not use your feature. >From what I have seen of this conversation there is not and will not be one interface to rule them all. Eric -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
