Subject: [PATCH 5/7 v21] LSM: Add security module hook list heads
Add a list header for each security hook. They aren't used until
later in the patch series. They are grouped together in a structure
so that there doesn't need to be an external address for each.
Macro-ize the initialization of
Subject: [PATCH 4/7 v21] LSM: Introduce security hook calling Macros
Introduce two macros around calling the functions in the
security operations vector. The marco versions here do not
change any behavior.
Signed-off-by: Casey Schaufler
---
security/security.c | 435
Subject: [PATCH 3/7 v21] LSM: Remove a comment from security.h
Remove the large comment describing the content of the
security_operations structure from security.h. This
wasn't done in the previous (2/7) patch because it
would have exceeded the mail list size limits.
Signed-off-by: Casey
Subject: [PATCH 2/7 v21] LSM: Add the comment to lsm_hooks.h
Add the large comment describing the content of the
security_operations structure to lsm_hooks.h. This
wasn't done in the previous (1/7) patch because it
would have exceeded the mail list size limits.
Signed-off-by: Casey Schaufler
Subject: [PATCH 1/7 v21] LSM: Split security.h
The security.h header file serves two purposes,
interfaces for users of the security modules and
interfaces for security modules. Users of the
security modules don't need to know about what's
in the security_operations structure, so pull it
out into
Reviewed-by: Changman Lee
On Mon, Mar 09, 2015 at 06:18:19PM +0800, Chao Yu wrote:
> Our f2fs_acl_create is copied and modified from posix_acl_create to avoid
> deadlock bug when inline_dentry feature is enabled.
>
> Now, we got reference leaks in posix_acl_create, and this has been fixed in
>
On Mon, Mar 9, 2015 at 9:03 AM, Steven Rostedt wrote:
>
> This is on top of the last pull request I sent out. But doesn't seem to
> have been pulled.
You make no sense. The commits you list were all on top of plain 4.0-rc2.
So exactly what do you expect me to pull, or haven't I pulled?
Subject: [PATCH 0/7 v21] LSM: Multiple concurrent LSMs
Replace the current ad hoc stacking of the capabilities
and Yama security modules with a generalized stacking scheme.
The old structure had a single set of module hooks contained
in a security_operations structure. This structure was
On Mon, Mar 9, 2015 at 6:09 PM, Kees Cook wrote:
> On Sat, Mar 7, 2015 at 2:07 PM, Yinghai Lu wrote:
>> First, aslr will support to put random VO above 4G, so we must set ident
>> mapping for the range even we come from startup_32 path.
>>
>> Second, when boot from 64bit bootloader, bootloader
On Mon, Mar 9, 2015 at 6:00 PM, Kees Cook wrote:
> On Sat, Mar 7, 2015 at 2:07 PM, Yinghai Lu wrote:
>
> This may be a stupid question, but are boot_params being used outside
> of the compressed loader? If so, it might make sense to split that
> change into a separate patch to go to stable, if
On Sat, Mar 7, 2015 at 2:07 PM, Yinghai Lu wrote:
> First, aslr will support to put random VO above 4G, so we must set ident
> mapping for the range even we come from startup_32 path.
>
> Second, when boot from 64bit bootloader, bootloader set ident mapping,
> and boot via ZO
Hi all,
Today's linux-next merge of the net-next tree got a conflict in
drivers/net/ethernet/cadence/macb.c between commit 0b2eb3e9bc73 ("net:
macb: constify macb configuration data") from the net tree and commits
a848748959d5 ("net: macb: remove #if defined(CONFIG_ARCH_AT91)
sections") and
On Mon, Mar 9, 2015 at 5:54 PM, Kees Cook wrote:
> On Sat, Mar 7, 2015 at 2:07 PM, Yinghai Lu wrote:
>> Boris found data from boot stage can not be used kernel stage.
>
> "... be used during kernel stage."
>
> Also, can you give a specific example of this problem? (Which data, used how?)
>
>>
On Sat, Mar 7, 2015 at 2:07 PM, Yinghai Lu wrote:
> We need to include that in boot::decompress_kernel stage to set new
> ident mapping.
>
> Also add checking for __pa/__va macro definition, as we need to override them
> in boot::decompress_kernel stage.
>
> Signed-off-by: Yinghai Lu
This seems
On Mon, 2015-03-09 at 17:21 -0700, Ray Jui wrote:
> Export symbols of the following PCI functions so they can be referenced
> by a PCI driver compiled as a kernel loadable module:
>
> pci_common_swizzle
> pci_create_root_bus
> pci_stop_root_bus
> pci_remove_root_bus
>
On Sat, Mar 7, 2015 at 2:07 PM, Yinghai Lu wrote:
> Now ZO sit end of the buffer, we can find out where is ZO text
> and data/bss etc.
>
> [input, input+input_size) is copied compressed kernel, not the whole ZO.
> [output, output+init_size) is the buffer for VO.
>
> [input+input_size,
On Sat, Mar 7, 2015 at 2:07 PM, Yinghai Lu wrote:
> Commit
>
> f47233c2d34f ("x86/mm/ASLR: Propagate base load address calculation")
>
> started passing KASLR status to kernel proper, but it uses a physical
> address as the vaule, leading to parsing bogus KASLR status in kernel
> proper.
>
>
On Sat, Mar 7, 2015 at 2:07 PM, Yinghai Lu wrote:
> Boris found data from boot stage can not be used kernel stage.
"... be used during kernel stage."
Also, can you give a specific example of this problem? (Which data, used how?)
> Bootloader allocate buffer according to init_size in hdr, and
On Mon, Mar 9, 2015 at 5:39 PM, Kees Cook wrote:
> On Sat, Mar 7, 2015 at 2:07 PM, Yinghai Lu wrote:
>> First 3 patches make ZO (arch/x86/boot/compressed/vmlinux) data region is not
>> overwritten by VO (vmlinux) after decompress. So could pass data from ZO to
>> VO.
>
> Tiny nit-pick, in case
On Mon, Mar 09 2015, David Rientjes wrote:
> If __get_user_pages() is faulting a significant number of hugetlb pages,
> usually as the result of mmap(MAP_LOCKED), it can potentially allocate a
> very large amount of memory.
>
> If the process has been oom killed, this will cause a lot of memory
From: Corey Minyard
The leds-gpio driver would not clean up properly if it failed in some
places, and it wasn't freeing its private data.
Signed-off-by: Corey Minyard
---
drivers/leds/leds-gpio.c | 13 +
1 file changed, 9 insertions(+), 4 deletions(-)
diff --git
On Sat, Mar 7, 2015 at 2:07 PM, Yinghai Lu wrote:
> commit e6023367d779 ("x86, kaslr: Prevent .bss from overlaping initrd")
> introduced one run_size for kaslr.
> We should use real runtime size (include copy/decompress) aka init_size.
>
> run_size is VO (vmlinux) init size include bss and brk.
>
On Sat, Mar 7, 2015 at 2:07 PM, Yinghai Lu wrote:
> First 3 patches make ZO (arch/x86/boot/compressed/vmlinux) data region is not
> overwritten by VO (vmlinux) after decompress. So could pass data from ZO to
> VO.
Tiny nit-pick, in case there is a v5: the Subject on this (0/7) says
"kasl"
On Mon, Mar 9, 2015 at 12:08 PM, Sebastian Andrzej Siewior
wrote:
> * Brian Silverman | 2015-03-05 00:16:20 [-0500]:
>
>>Beforehand, 000 is spending most of its time in interrupts, but bash
>>is doing something related to memory management on it in between.
>>bash-14721 [000] ..1
We are dealing with CTS, not DSR here (we dealt with DSR a few lines
above), so set appropriate bits.
Reported-by: Kevin Cernekee
Signed-off-by: Dmitry Torokhov
---
drivers/tty/serial/8250/8250_dw.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git
This patch series adds the support for Broadcom iProc PCIe controller
pcie-iproc.c servers as the common core driver, and front-end bus
interface needs to be added to support different bus interfaces
pcie-iproc-pltfm.c contains the support for the platform bus interface
Changes from v4:
-
Export symbols of the following PCI functions so they can be referenced
by a PCI driver compiled as a kernel loadable module:
pci_common_swizzle
pci_create_root_bus
pci_stop_root_bus
pci_remove_root_bus
pci_assign_unassigned_bus_resources
pci_fixup_irqs
Signed-off-by: Ray Jui
---
Add PCIe device nodes in bcm-cygnus.dtsi but keep them disabled there.
Only enable them for bcm958300k where PCIe interfaces are populated
Signed-off-by: Ray Jui
Reviewed-by: Scott Branden
---
arch/arm/boot/dts/bcm-cygnus.dtsi | 42 +
This adds the support for Broadcom iProc PCIe controller
pcie-iproc.c servers as the common core driver, and front-end bus
interface needs to be added to support different bus interfaces
pcie-iproc-pltfm.c contains the support for the platform bus interface
Signed-off-by: Ray Jui
Reviewed-by:
Document the Broadcom iProc PCIe platform interface device tree binding
Signed-off-by: Ray Jui
Reviewed-by: Scott Branden
---
.../devicetree/bindings/pci/brcm,iproc-pcie.txt| 63
1 file changed, 63 insertions(+)
create mode 100644
> It looks like your patch runs into dead locks problems:
>
> I have a cron job reading my sensors. If I read the sensors on another
> thread (e.g. via cat), the 2nd thread can produce a dead lock:
>
> * thread 1 has bus & sl lock
> * thread 1 drops bus lock, keeps sl locks and sleeps
> * thread 2
On Mon, Mar 9, 2015 at 5:28 PM, Michael Ellerman wrote:
> On Sat, 2015-03-07 at 15:02 +1100, Benjamin Herrenschmidt wrote:
>> On Fri, 2015-03-06 at 15:50 -0800, Olof Johansson wrote:
>> > On Fri, Mar 6, 2015 at 2:56 PM, Benjamin Herrenschmidt
>> > wrote:
>> > > On Fri, 2015-03-06 at 10:00 -0500,
On Wed, Mar 4, 2015 at 11:56 PM, Jacek Anaszewski
wrote:
> On 03/04/2015 05:14 PM, Jacek Anaszewski wrote:
>>
>> Add macros for defining boost mode and trigger type properties
>> of flash LED devices.
>>
>> Signed-off-by: Jacek Anaszewski
>> Acked-by: Kyungmin Park
>> Cc: Bryan Wu
>> Cc:
On Sat, 2015-03-07 at 15:02 +1100, Benjamin Herrenschmidt wrote:
> On Fri, 2015-03-06 at 15:50 -0800, Olof Johansson wrote:
> > On Fri, Mar 6, 2015 at 2:56 PM, Benjamin Herrenschmidt
> > wrote:
> > > On Fri, 2015-03-06 at 10:00 -0500, Steven Rostedt wrote:
> > >> On Fri, 06 Mar 2015 15:18:42
This patch adds the 'const' keyword for devfreq_event_ops structure
because the ops of devfreq_event_desc structure shold not be changed
after initialization.
Cc: Myungjoo Ham
Cc: Kyungmin Park
Signed-off-by: Chanwoo Choi
---
drivers/devfreq/event/exynos-ppmu.c | 2 +-
On Wed, Mar 4, 2015 at 8:14 AM, Jacek Anaszewski
wrote:
> The documentation being added contains overall description of the
> LED Flash Class and the related sysfs attributes.
>
Thanks, merged!
-Bryan
> Signed-off-by: Jacek Anaszewski
> Acked-by: Kyungmin Park
> Cc: Bryan Wu
> Cc: Richard
Sorry. I made a mistake. Please IGNORE this patch set. I'll re-send it
again with proper module changes applied.
Ray
On 3/9/2015 5:21 PM, Ray Jui wrote:
> This adds the support for Broadcom iProc PCIe controller
>
> pcie-iproc.c servers as the common core driver, and front-end bus
> interface
This patch renames the extcon core driver from extcon-class.c
to extcon.c because '-class' postfix is not necessary.
Signed-off-by: Chanwoo Choi
---
drivers/extcon/Makefile |2 +-
drivers/extcon/extcon-class.c | 1038 -
drivers/extcon/extcon.c
Export symbols of the following PCI functions so they can be referenced
by a PCI driver compiled as a kernel loadable module:
pci_common_swizzle
pci_create_root_bus
pci_stop_root_bus
pci_remove_root_bus
pci_assign_unassigned_bus_resources
pci_fixup_irqs
Signed-off-by: Ray Jui
---
On Mon, Mar 9, 2015 at 5:11 PM, Kees Cook wrote:
> On Mon, Mar 9, 2015 at 2:11 PM, Kirill A. Shutemov
> wrote:
>> From: "Kirill A. Shutemov"
>>
>> As pointed by recent post[1] on exploiting DRAM physical imperfection,
>> /proc/PID/pagemap exposes sensitive information which can be used to do
This patch series adds the support for Broadcom iProc PCIe controller
pcie-iproc.c servers as the common core driver, and front-end bus
interface needs to be added to support different bus interfaces
pcie-iproc-pltfm.c contains the support for the platform bus interface
Changes from v3:
-
This patch fixes the checkpatch warning about coding style.
Signed-off-by: Chanwoo Choi
---
drivers/extcon/extcon-max14577.c | 5 +
drivers/extcon/extcon-max77693.c | 5 +
drivers/extcon/extcon-max8997.c | 5 +
drivers/extcon/extcon-rt8973a.c | 6 ++
This adds the support for Broadcom iProc PCIe controller
pcie-iproc.c servers as the common core driver, and front-end bus
interface needs to be added to support different bus interfaces
pcie-iproc-pltfm.c contains the support for the platform bus interface
Signed-off-by: Ray Jui
Reviewed-by:
On Fri, 6 Mar 2015 17:42:26 +0100
Christophe Leroy wrote:
> This patch adds talitos1.c and talitos1.h with all specificities needed
> to handle the SEC1 security engine found in MPC885 and MPC8272.
>
> The SEC1 has several differences with its younger brother SEC2:
> * Several bits in registers
Add PCIe device nodes in bcm-cygnus.dtsi but keep them disabled there.
Only enable them for bcm958300k where PCIe interfaces are populated
Signed-off-by: Ray Jui
Reviewed-by: Scott Branden
---
arch/arm/boot/dts/bcm-cygnus.dtsi | 42 +
Document the Broadcom iProc PCIe platform interface device tree binding
Signed-off-by: Ray Jui
Reviewed-by: Scott Branden
---
.../devicetree/bindings/pci/brcm,iproc-pcie.txt| 63
1 file changed, 63 insertions(+)
create mode 100644
This patch renames the extcon core driver from 'extcon-class.c' to 'extcon.c'
because '-class' postfix is not necessary. And fix the checkpatch warning for
extcon provider drivers.
Chanwoo Choi (2):
extcon: Rename extcon core driver
extcon: Fix the checkpatch warning
drivers/extcon/Makefile
On Wed, Mar 4, 2015 at 8:14 AM, Jacek Anaszewski
wrote:
> Add a documentation of LED Flash class specific sysfs attributes.
>
Thanks, merged!
-Bryan
> Signed-off-by: Jacek Anaszewski
> Acked-by: Kyungmin Park
> Cc: Bryan Wu
> Cc: Richard Purdie
> ---
>
On Mon, Mar 9, 2015 at 2:11 PM, Kirill A. Shutemov wrote:
> From: "Kirill A. Shutemov"
>
> As pointed by recent post[1] on exploiting DRAM physical imperfection,
> /proc/PID/pagemap exposes sensitive information which can be used to do
> attacks.
>
> This is RFC patch which disallow anybody
Hi Linus,
Please pull from:
git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git for-linus
or
master.kernel.org:/pub/scm/linux/kernel/git/dtor/input.git for-linus
to receive updates for the input subsystem: miscellaneous driver fixes.
Changelog:
-
Arnd Bergmann
> Oops, sorry, it got lost in the shuffle, here's the first patch again
> (the others were for debugging and increase that time and so wouldn't
> go upstream anyway).
I assumed so.
It looks like your patch runs into dead locks problems:
I have a cron job reading my sensors. If I read the
On Tue, Mar 10, 2015 at 12:08:43AM +0100, Rafael J. Wysocki wrote:
> On Monday, March 09, 2015 11:41:12 PM Rafael J. Wysocki wrote:
> > On Monday, March 09, 2015 11:00:04 AM Dmitry Torokhov wrote:
> > > Hi Rafael,
> > >
> > > On Mon, Mar 09, 2015 at 04:19:50PM +0100, Rafael J. Wysocki wrote:
> >
On Mon, Mar 9, 2015 at 4:43 PM, Eric W. Biederman wrote:
>
> A 1 to 1 blinding function like integer multiplication mudulo 2^32 by an
> appropriate random number ought to keep from revealing page numbers or
> page ajacencies while not requiring any changes in userspace.
>
> That way the revealed
Tony,
On 03/05/2015 10:57 AM, Tony Lindgren wrote:
> * Suman Anna [150305 08:47]:
>> On 03/05/2015 09:40 AM, Tony Lindgren wrote:
>>> * Dave Gerlach [150304 20:14]:
>> Dave,
>>
>> Looks like the commit message disappeared during your patch preparation.
>>
Signed-off-by: Suman Anna
On Mon, Mar 09, 2015 at 04:39:47PM -0700, Paul E. McKenney wrote:
> On Mon, Mar 09, 2015 at 02:40:21PM -0700, Paul E. McKenney wrote:
> > On Mon, Mar 09, 2015 at 09:34:04AM +0100, Alexander Gordeev wrote:
> > > Hi Paul,
> > >
> > > Here is cleanup of RCU tree initialization rebased on linux-rcu
A 1 to 1 blinding function like integer multiplication mudulo 2^32 by an
appropriate random number ought to keep from revealing page numbers or
page ajacencies while not requiring any changes in userspace.
That way the revealed pfn and the physcial pfn would be different but
you could still use
Hi Arnd,
On 3/9/2015 5:35 AM, Arnd Bergmann wrote:
> On Friday 06 March 2015 10:00:34 Ray Jui wrote:
>>>
>>
>> Although I have not tested it, but to my best knowledge there shouldn't
>> be any technical issue by making the PCIe iProc driver a loadable module
>> and installing the module later
On 03/04/2015 03:41 AM, Michael Ellerman wrote:
> There's no need to open-code the build rules, use the implicit ones.
>
> This has the nice side effect of enabling cross compilation.
>
> Signed-off-by: Michael Ellerman
> ---
> tools/testing/selftests/mount/Makefile | 8
> 1 file
On Mon, Mar 9, 2015 at 4:08 PM, Eric W. Biederman wrote:
> Kees Cook writes:
>
>> On Mon, Mar 9, 2015 at 3:13 PM, Eric W. Biederman
>> wrote:
>>> Dave Hansen writes:
>>>
From: Dave Hansen
Physical addresses are sensitive information. There are
existing, known exploits
On Mon, Mar 09, 2015 at 02:40:21PM -0700, Paul E. McKenney wrote:
> On Mon, Mar 09, 2015 at 09:34:04AM +0100, Alexander Gordeev wrote:
> > Hi Paul,
> >
> > Here is cleanup of RCU tree initialization rebased on linux-rcu rcu/next
> > repo, as you requested. Please, note an extra patch #10 that was
On 03/04/2015 03:41 AM, Michael Ellerman wrote:
> There's no need to open-code the build rules, use the implicit ones.
>
> This has the nice side effect of enabling cross compilation.
>
> Signed-off-by: Michael Ellerman
> ---
> tools/testing/selftests/mqueue/Makefile | 15 +--
> 1
On 09/03/15 20:08, Matteo Semenzato wrote:
From: Matteo Semenzato
The comedi_cmd struct has an hole after chanlist_len that could contain
uninitialized
memory, this struct is copied to userspace.
Signed-off-by: Matteo Semenato
---
drivers/staging/comedi/comedi_fops.c | 2 ++
1 file
Hello Stephen,
On Mon, Mar 09, 2015 at 03:40:29PM -0700, Stephen Boyd wrote:
> On 03/09/15 14:58, Uwe Kleine-König wrote:
> > If you see
> >
> > round_rate(110) = 108
> >
> > it would be fortunate to know if you get 108 because the next available
> > greater rate is > 112 or because the
On Fri, Feb 27, 2015 at 06:19:18PM -0600, Joel Schopp wrote:
> From: David Kaplan
> No need to re-decode WBINVD since we know what it is from the intercept.
>
> Signed-off-by: David Kaplan
> [extracted from larger unlrelated patch, forward ported, tested]
> Signed-off-by: Joel Schopp
Can't
On Mon, Mar 9, 2015 at 1:34 PM, Sebastian Andrzej Siewior
wrote:
> From what I can tell not beeing a sched guy is that the patch looks
> reasonable since the timeout gets only set to zero on enqueue_task_rt().
> Is there something special you do to trigger this?
I posted some test code with two
Em Mon, Mar 09, 2015 at 08:11:19PM -0300, Arnaldo Carvalho de Melo escreveu:
> Em Mon, Mar 09, 2015 at 06:51:21PM -0300, Arnaldo Carvalho de Melo escreveu:
> > Doesn't work as well...
> >
> > :-\
> >
> > Will try debugging...
>
> So I tried checkout out before Ingo's changes to libbabeltrace
On 2015/3/5 20:42, Li, Aubrey wrote:
> On 2015/3/5 19:36, Ingo Molnar wrote:
>>
>> * Li, Aubrey wrote:
>>
>>> On 2015/3/5 4:11, Ingo Molnar wrote:
* Arjan van de Ven wrote:
> On 3/4/2015 1:50 AM, Borislav Petkov wrote:
>> On Wed, Mar 04, 2015 at 12:43:08AM -0800, Arjan van
On Wed, Mar 4, 2015 at 8:14 AM, Jacek Anaszewski
wrote:
> Synchronized flash strobe feature has been considered not fitting
> for LED subsystem sysfs interface and thus is being removed.
>
OK, I will merge this.
-Bryan
> Signed-off-by: Jacek Anaszewski
> Acked-by: Kyungmin Park
> Cc: Bryan
Add the recently added hdmi power supplies to evb and firefly boards.
Signed-off-by: Heiko Stuebner
---
arch/arm/boot/dts/rk3288-evb.dtsi | 2 ++
arch/arm/boot/dts/rk3288-firefly.dtsi | 2 ++
2 files changed, 4 insertions(+)
diff --git a/arch/arm/boot/dts/rk3288-evb.dtsi
At least the Rockchip variant of the dw_hdmi can have controllable power
supplies
providing 1.0 and 1.8V. Therefore add the possibility for the generic bridge
driver to enable supplies provided by the hw-specific drivers.
Signed-off-by: Heiko Stuebner
---
When {devm_}regulator_get returns -EPROBE_DEFER the driver in question will
try probing again at a later time. So don't spam the log with failure messages
as this is an expected result of probe ordering.
Signed-off-by: Heiko Stuebner
---
drivers/regulator/core.c | 5 +++--
At least the Rockchip variant of the dw_hdmi should control its supplying
regulators. A cursory glance at the imx manual didn't any equivalent there,
so I'm not sure if there are similar controllable regulators present.
Patch1 is only a small fix to keep {devm_}regulator_bulk_get quiet in
the
In the Designware databook's description of the "Voltage Switch Normal
Scenario" it instructs us to set a timer and fail the voltage change
if we don't see the voltage change interrupt within 2ms. Let's
implement that. Without implementing this I have often been able to
reproduce a hang while
On 03/04/2015 03:41 AM, Michael Ellerman wrote:
> There's no need to open-code the build rules, use the implicit ones.
>
> This has the nice side effect of enabling cross compilation.
>
> Signed-off-by: Michael Ellerman
> ---
> tools/testing/selftests/timers/Makefile | 8
> 1 file
On Tue, Mar 03, 2015 at 10:39:45PM +0100, Frans Klaver wrote:
> add_mtd_device() has a comment suggesting that the caller should have
> set dev.parent. This is required to have the device show up in sysfs,
What do you mean "have the device show up in sysfs"? AFAICT, this only
has bearing on
Kees Cook writes:
> On Mon, Mar 9, 2015 at 3:13 PM, Eric W. Biederman
> wrote:
>> Dave Hansen writes:
>>
>>> From: Dave Hansen
>>>
>>> Physical addresses are sensitive information. There are
>>> existing, known exploits that are made easier if physical
>>> information is available. Here is
Em Mon, Mar 09, 2015 at 06:51:21PM -0300, Arnaldo Carvalho de Melo escreveu:
> Doesn't work as well...
>
> :-\
>
> Will try debugging...
So I tried checkout out before Ingo's changes to libbabeltrace detection, i.e.:
[acme@zoo linux]$ git checkout -b ttmp
On Mon, Mar 09, 2015 at 11:47:24PM +0100, Thorsten Bschorr wrote:
> > Here's a different strategy, add a w1_therm family_data specific mutex
> > so w1_therm_remove_slave won't return while another thread is in
> > w1_slave_show. Thoughts?
> >
> > I included three patches, the first is the
On 03/09/2015 08:28 AM, Shuah Khan wrote:
> On 03/04/2015 03:19 AM, Michael Ellerman wrote:
>> The makefiles under tools/testing/selftests are not real kbuild
>> makefiles, they are regular stand alone makefiles. As such they *do*
>> want all the standard implicit rules and variables defined.
>>
> Here's a different strategy, add a w1_therm family_data specific mutex
> so w1_therm_remove_slave won't return while another thread is in
> w1_slave_show. Thoughts?
>
> I included three patches, the first is the proposed fix, the second
> makes it more reproducible (and since my testing doesn't
On Monday, March 09, 2015 11:41:12 PM Rafael J. Wysocki wrote:
> On Monday, March 09, 2015 11:00:04 AM Dmitry Torokhov wrote:
> > Hi Rafael,
> >
> > On Mon, Mar 09, 2015 at 04:19:50PM +0100, Rafael J. Wysocki wrote:
> > > From: Rafael J. Wysocki
> > >
> > > If they keyboard interrupt is
In sym53c416_read(), the chip can (and does sometimes) return more bytes in
the FIFO than we want to read. This causes buffer overflow, resulting in nasty
memory and data corruption and oopses. I couldn't even read filesystem's root
directory properly (and a simple dd with 1M blocksize crashed the
On 03/09/15 14:58, Uwe Kleine-König wrote:
>
> If you see
>
> round_rate(110) = 108
>
> it would be fortunate to know if you get 108 because the next available
> greater rate is > 112 or because the implementation rounds down always
> (which would mean that 111 is possible, too). For the
Quoting Boris Brezillon (2015-03-02 01:18:16)
> The irq line used by the PMC block is shared with several peripherals
> including the init timer which is registering its handler with
> IRQF_NO_SUSPEND.
> Implement the appropriate suspend/resume callback for the PMC irqchip,
> and inform irq core
On 03/09/2015 08:20 AM, Shuah Khan wrote:
> On 03/05/2015 11:53 AM, Dave Jones wrote:
>> On Tue, Mar 03, 2015 at 03:51:35PM +1100, Michael Ellerman wrote:
>> > This adds make install support to selftests. The basic usage is:
>> >
>> > $ cd tools/testing/selftests
>> > $ make install
>> >
>>
On Mon, Mar 09, 2015 at 02:21:53PM +0100, Sebastian Andrzej Siewior wrote:
> On 03/09/2015 12:29 PM, Mike Galbraith wrote:
> > On Mon, 2015-03-09 at 12:07 +0100, Sebastian Andrzej Siewior wrote:
> >> On 03/09/2015 11:51 AM, Mike Galbraith wrote:
> >>> Why do both mutex and rtmutex then exist one
Hi,
On Mon, Mar 09, 2015 at 11:09:03PM +0100, Mateusz Kulikowski wrote:
> An of_device_id should be const (checkpatch.pl warning).
>
> Signed-off-by: Mateusz Kulikowski
Acked-by: Aaro Koskinen
A.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a
This patch adds the solomon prefix for Solomon Systech Limited.
Signed-off-by: Thomas Niederprüm
---
Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt
This patch adds a module parameter 'bitsperpixel' to adjust the colordepth
of the framebuffer. All values >1 will result in memory map of the requested
color depth. However only the MSB of each pixel will be sent to the device.
The framebuffer identifies itself as a grayscale display with the
The 130X controllers are very similar from the configuration point of view.
The configuration registers for the SSD1305/6/7 are bit identical (except the
the VHCOM register and the the default values for clock setup register). This
patch unifies the init code of the controller and adds hardware
This patch adds sysfs handles to enable userspace control over the display
contrast as well as the dim mode. The handles are available as "contrast"
and "dim" in the framebuffers sysfs domain.
Signed-off-by: Thomas Niederprüm
---
drivers/video/fbdev/ssd1307fb.c | 90
It makes sense to use vmalloc to allocate the video buffer since it has to be
page aligned memory for using it with mmap. Also deffered io seems buggy in
combination with kmalloc'ed memory (crash on unloading the module).
Signed-off-by: Thomas Niederprüm
---
drivers/video/fbdev/ssd1307fb.c | 5
On Mon, Mar 9, 2015 at 3:13 PM, Eric W. Biederman wrote:
> Dave Hansen writes:
>
>> From: Dave Hansen
>>
>> Physical addresses are sensitive information. There are
>> existing, known exploits that are made easier if physical
>> information is available. Here is one example:
>>
>>
This patch adds the module parameter "refreshrate" to set delay for the
deferred io. The refresh rate is given in units of Hertz. The default
refresh rate is 1 Hz.
Signed-off-by: Thomas Niederprüm
---
drivers/video/fbdev/ssd1307fb.c | 23 +--
1 file changed, 17
the smem_start pointer of the framebuffer info struct needs to hold the
physical address rather than the virtual address. This patch fixes a
driver crash on mmaping the framebuffer memory due to an access to the
memory address.
Note however that the memory allocated by kzalloc is not page
This patch series is the result of making the ssd1307fb driver work with
a Newhaven OLED display using the Solomon SSD1305 controller. To achieve
this the intialization code for the SSD1306 and the SSD1307 is merged
and based on DT configuration to reflect the various possible wirings
of the
This patch adds support for the SSD1305 OLED controller.
Signed-off-by: Thomas Niederprüm
---
Documentation/devicetree/bindings/video/ssd1307fb.txt | 2 +-
drivers/video/fbdev/ssd1307fb.c | 13 +
2 files changed, 14 insertions(+), 1 deletion(-)
diff --git
This patch turns off the display when the driver is unloaded.
Signed-off-by: Thomas Niederprüm
Acked-by: Maxime Ripard
---
drivers/video/fbdev/ssd1307fb.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/video/fbdev/ssd1307fb.c b/drivers/video/fbdev/ssd1307fb.c
index
This patch updates the in tree-users of the SSD1306 controller for using
the newly introduced DT properties.
Signed-off-by: Thomas Niederprüm
---
arch/arm/boot/dts/imx28-cfa10036.dts | 4
1 file changed, 4 insertions(+)
diff --git a/arch/arm/boot/dts/imx28-cfa10036.dts
Hello,
On Mon, Mar 09, 2015 at 10:12:32PM +0100, Paul Bolle wrote:
> On Wed, 2015-03-04 at 13:08 +0100, Maxime Coquelin wrote:
> > This is because I added also support for COMPILE_TEST coverage as per
> > Uwe advice,
> > and thought it was necessary to have an entry for this.
> > Maybe I'm just
101 - 200 of 2156 matches
Mail list logo
