On 12/05/2014 04:30 PM, Rafał Miłecki wrote:
Since my commit
mtd: spi-nor: allow NULL as chip name and try to auto detect it
second argument is optional.
Can you simply pass NULL instead of modalias?
OK, passing NULL. Works fine for me, thanks.
-Graham
--
To unsubscribe from this list: se
On Mon, Dec 08, 2014 at 04:38:57PM +, Arnd Bergmann wrote:
> On Monday 08 December 2014 17:22:44 Arend van Spriel wrote:
> > >> The log: first the ring allocation info is printed. Starting at
> > >> 16.124847, ring 2, 3 and 4 are rings used for device to host. In this
> > >> log the failure is
Hi Vinod,
On Mon, 2014-12-08 at 17:06 +0530, Vinod Koul wrote:
> Can you please rebase this on my next, this fails to apply for me
This is a patch for Laurent's new rcar-dmac driver, which doesn't appear
to be in your next yet. Laurent has already merged my patch into his
dma/next branch and incl
On 04/12/14 15:38, Sifan Naeem wrote:
> Add toggle bit to struct img_ir_scancode_req so that protocols can
> provide it to img_ir_handle_data(), and pass that toggle bit up to
> rc_keydown instead of 0.
>
> This is nedded for the upcoming rc-5 and rc-6 patches.
Typo (nedded).
Otherwise:
Acked-by
On 12/08/14 17:03, Catalin Marinas wrote:
On Mon, Dec 08, 2014 at 03:01:32PM +, Arnd Bergmann wrote:
[0.00] PL310 OF: cache setting yield illegal associativity
[0.00] PL310 OF: -1069781724 calculated, only 8 and 16 legal
[0.00] L2C-310 enabling early BRESP for Cortex-
On 12/06/2014 08:07 AM, Jiri Slaby wrote:
> This is the start of the stable review cycle for the 3.12.35 release.
> There are 66 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be
Provided patch series extend of-thermal.c file API. It is necessary
for ongoing Exynos TMU rework.
First version of this code can be found at:
http://www.spinics.net/lists/linux-samsung-soc/msg37719.html
Second version:
http://www.spinics.net/lists/kernel/msg1872274.html
This code provides meth
Dear All,
I'm Krzysztof Opasiak from SRPOL (Samsung). I'm working on USB support
in Tizen and mainline. In those works we use two Virtual File Systems
- ConfigFS and FunctionFS. Recently I have tried to use them with
SMACK and I ran into a few issues. Most of them looks to be a generic
problem wit
Hi Pali,
On Saturday 06 December 2014 13:49:54 Pavel Machek wrote:
/**
+ * request_firmware_prefer_user: - prefer usermode helper
for loading firmware + * @firmware_p: pointer to firmware
image
+ * @name: name of firmware file
+ * @device: device for which
This patch extends the of-thermal.c to provide information about number of
available trip points.
Signed-off-by: Lukasz Majewski
---
Changes for v3:
- Exporting of_thermal_get_ntrips symbol as a GPL
- Fix build error when CONFIG_THERMAL_OF is disabled
Changes for v2:
- Provide detailed (doxygen
This patch extends the of-thermal.c to provide check if trip point is
valid.
Signed-off-by: Lukasz Majewski
---
Changes for v3:
- Rename of_thermal_is_trip_en() to of_thermal_is_trip_valid()
- Export of_thermal_is_trip_valid symbol as GPL
- Fix the build error when CONFIG_THERMAL_OF is not define
This patch changes name of struct __thermal_trip to thermal_trip and moves
declaration of the latter to ./include/linux/thermal.h for better visibility.
Signed-off-by: Lukasz Majewski
---
Changes for v3:
- New patch - as suggested by Navneet Kumar
---
drivers/thermal/of-thermal.c | 21 +++---
Before this change it was only possible to set get_temp() and get_trend()
methods to be used in the common code handling passing parameters via
device tree to "cpu-thermal" CPU thermal zone device.
Now it is possible to also set emulated value of temperature for debug
purposes.
Signed-off-by: Luk
This patch extends the of-thermal.c to export trip points for a given
thermal zone.
Thermal drivers should use of_thermal_get_trip_points() method to get
pointer to table of thermal trip points.
Signed-off-by: Lukasz Majewski
---
Changes for v3:
- Export of_thermal_get_trip_points symbol as GPL
On Mon, 8 Dec 2014, Vladimir Davydov wrote:
> Sounds reasonable, thanks. The updated patch is below.
Ok. SLAB also needs to have a similar hook scheme than SLUB at some point.
Acked-by: Christoph Lameter
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a
Hi MyungJoo,
Thank for your answer, see my answers inline.
On 12/08/2014 09:44 AM, MyungJoo Ham wrote:
Please let me start with somewhat naive high-level question:
What do you mean by watermark in this context?
Sorry for poor choice of naming. "Load threshold interrupt" might be
more appr
On 12/05/2014 08:27 PM, Bryan Wu wrote:
On Fri, Nov 28, 2014 at 1:17 AM, Jacek Anaszewski
wrote:
Some LED devices support two operation modes - torch and flash.
This patch provides support for flash LED devices in the LED subsystem
by introducing new sysfs attributes and kernel internal interfa
On Monday 08 December 2014 18:05:37 Marcel Holtmann wrote:
> Hi Pali,
>
> On Saturday 06 December 2014 13:49:54 Pavel Machek wrote:
> /**
>
> + * request_firmware_prefer_user: - prefer usermode
> helper for loading firmware + * @firmware_p: pointer to
> firmware imag
On Monday 08 December 2014 08:55:20 Ray Jui wrote:
>
> On 12/8/2014 3:22 AM, Arnd Bergmann wrote:
> > On Sunday 07 December 2014 18:38:32 Ray Jui wrote:
> >> +Required properties:
> >> +
> >> +- compatible:
> >> +Currently supported Cygnus GPIO controllers include:
> >> +"brcm,cygnus-ccm-g
Hi,
On Mon, Dec 8, 2014 at 12:52 AM, Uwe Kleine-König
wrote:
> Hello Addy,
>
> On Mon, Dec 08, 2014 at 10:59:49AM +0800, Addy Ke wrote:
>> high_ns calculated from the low division of CLKDIV register is the sum
>> of actual measured high_ns and rise_ns. The rise time which related to
> I think "ac
On 12/08/2014 05:54 PM, Alex Williamson wrote:
> On Mon, 2014-12-08 at 13:22 +0100, Eric Auger wrote:
>> On 11/25/2014 08:00 PM, Alex Williamson wrote:
>>> On Tue, 2014-11-25 at 19:20 +0100, Eric Auger wrote:
On 11/24/2014 09:56 PM, Alex Williamson wrote:
> On Sun, 2014-11-23 at 19:35 +010
On Mon, Dec 8, 2014 at 6:42 AM, Ankit Jindal wrote:
> On 18 November 2014 at 18:40, Arnd Bergmann wrote:
>> On Tuesday 18 November 2014 14:59:54 Ankit Jindal wrote:
>>> On 17 November 2014 16:47, Arnd Bergmann wrote:
>>> > On Monday 17 November 2014 16:06:11 Ankit Jindal wrote:
>>> >> +
>>> >> +
On 04/12/14 15:38, Sifan Naeem wrote:
> Biphase decoding in the current img-ir has got a quirk, where multiple
> Interrupts are generated when an incomplete IR code is received by the
> decoder.
>
> Patch adds a work around for the quirk and enables biphase decoding.
>
> Signed-off-by: Sifan Naee
On Mon, Dec 08, 2014 at 05:50:26PM +0100, Jürg Billeter wrote:
> Hi Vinod,
>
> On Mon, 2014-12-08 at 17:06 +0530, Vinod Koul wrote:
> > Can you please rebase this on my next, this fails to apply for me
>
> This is a patch for Laurent's new rcar-dmac driver, which doesn't appear
> to be in your ne
On Wed, Nov 12, 2014 at 9:08 AM, Suman Anna wrote:
> Kumar, Mark, Rob,
>
> On 11/12/2014 09:14 AM, Ohad Ben-Cohen wrote:
>> Hi Suman,
>>
>> On Fri, Sep 12, 2014 at 11:24 PM, Suman Anna wrote:
>>> This patch adds the generic common bindings used to represent
>>> a hwlock device and use/request loc
Add dummy implementation of 'of_find_all_nodes',
and remove the unnecessary 'of_can_translate_address',
which is already removed in commit
d9c6866be8a145e32da616d8dcbae806032d75b5 ("of: kill off
of_can_translate_address"), to fix the build errors and warnings
found by sparse.
Signed-off-by: Tsung-
> > There are different capitalisation of i2c in the patch and the commit log. I
> > don't know what Wolfram prefers here, but using the same spelling
> > everywhere would be nice.
>
> Can you please point out? IIRC you should always capitalize I2C in
> prose (descriptions, comments, documentati
On 12/08/2014 09:51 AM, Lee Jones wrote:
On Mon, 08 Dec 2014, Stephen Warren wrote:
...
The primary purpose of the kernel.org linux-rpi.git repo is for
staging patches into arm-soc/linux-next. As such, just like any
other similar repo, users should expect at least the for-xxx (e.g.
for-next) br
Hi Vinod,
On Monday 08 December 2014 22:49:24 Vinod Koul wrote:
> On Mon, Dec 08, 2014 at 05:50:26PM +0100, Jürg Billeter wrote:
> > Hi Vinod,
> >
> > On Mon, 2014-12-08 at 17:06 +0530, Vinod Koul wrote:
> > > Can you please rebase this on my next, this fails to apply for me
> >
> > This is a pa
On Thu, Dec 04, 2014 at 10:12:23AM -0500, Tejun Heo wrote:
> From: NeilBrown
>
> When there is serious memory pressure, all workers in a pool could be
> blocked, and a new thread cannot be created because it requires memory
> allocation.
>
> In this situation a WQ_MEM_RECLAIM workqueue will wake
On 04/12/14 15:38, Sifan Naeem wrote:
> Add img-ir module for decoding Philips rc5 protocol.
>
> Signed-off-by: Sifan Naeem
> ---
> drivers/media/rc/img-ir/Kconfig |7 +++
> drivers/media/rc/img-ir/Makefile |1 +
> drivers/media/rc/img-ir/img-ir-hw.c |3 ++
> drivers/media/
The workqueues list is protected by wq_pool_mutex and a workqueue and
its subordinate data structures are freed directly on destruction. We
want to add the ability dump workqueues from a sysrq callback which
requires walking all workqueues without grabbing wq_pool_mutex. This
patch makes freeing
Add wq_barrier->task and worker_pool->manager to keep track of the
flushing task and pool manager respectively. These are purely
informational and will be used to implement sysrq dump of workqueues.
Signed-off-by: Tejun Heo
---
kernel/workqueue.c |5 +
1 file changed, 5 insertions(+)
-
On 04/12/14 15:38, Sifan Naeem wrote:
> Add img-ir module for decoding Philips rc6 protocol.
>
> Signed-off-by: Sifan Naeem
Aside from the "Philips" thing:
Acked-by: James Hogan
(It's unpleasant having unexplained timings for RC-6, but it's better
than no RC-6 support, and hopefully in the fu
From: ryang
Signed-off-by: ryang
---
drivers/watchdog/watchdog_dev.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/watchdog/watchdog_dev.c b/drivers/watchdog/watchdog_dev.c
index 6aaefba..73793d8 100644
--- a/drivers/watchdog/watchdog_dev.c
+++ b/drivers/watchd
Workqueues are used extensively throughout the kernel but sometimes
it's difficult to debug stalls involving work items because visibility
into its inner workings is fairly limited. Although sysrq-t task dump
annotates each active worker task with the information on the work
item being executed, i
On Sun, Sep 28, 2014 at 01:44:15AM +0100, Miles MH Chen wrote:
> On Sat, Sep 27, 2014 at 11:13 PM, Catalin Marinas
> wrote:
> > On 27 Sep 2014, at 16:09, Miles MH Chen wrote:
> >> Signed-off-by: Min-Hua Chen
> >> ---
> >> arch/arm64/mm/dma-mapping.c |3 ++-
> >> 1 file changed, 2 insertions
On Mon, Dec 08, 2014 at 07:40:15PM +0200, Laurent Pinchart wrote:
> Hi Vinod,
>
> On Monday 08 December 2014 22:49:24 Vinod Koul wrote:
> > On Mon, Dec 08, 2014 at 05:50:26PM +0100, Jürg Billeter wrote:
> > > Hi Vinod,
> > >
> > > On Mon, 2014-12-08 at 17:06 +0530, Vinod Koul wrote:
> > > > Can y
On Sat, 6 Dec 2014 14:55:33 +0100
, Pavel Machek
wrote:
> Hi!
>
> > > I am accustomed to doing 'echo -n' for most of sysfs anyway. Once in a
> > > while I am a bonehead and forget the '-n' and spend a few minutes
> > > wondering why this thing that worked last week suddenly rejects all
> > > co
Is anything wrong with this patch?
It was made against last mainline kernel at the moment.
If a patch against linux-next needed, I can make it.
Without this patch wireless is always blocked.
Regards,
Dmitry.
27.11.2014 19:39, Dmitry Tunin пишет:
Rfkill always shows wireless blocked unless idea
Hi Grant,
> On Dec 8, 2014, at 19:50 , Grant Likely wrote:
>
> On Sat, 6 Dec 2014 14:55:33 +0100
> , Pavel Machek
> wrote:
>> Hi!
>>
I am accustomed to doing 'echo -n' for most of sysfs anyway. Once in a
while I am a bonehead and forget the '-n' and spend a few minutes
wonderin
On Mon, Dec 8, 2014 at 5:50 PM, Grant Likely wrote:
> On Sat, 6 Dec 2014 14:55:33 +0100
> , Pavel Machek
> wrote:
>> Hi!
>>
>> > > I am accustomed to doing 'echo -n' for most of sysfs anyway. Once in a
>> > > while I am a bonehead and forget the '-n' and spend a few minutes
>> > > wondering why
Linus,
The following ktest updates were done:
o Fix handling the make kernelrelease change
o Fix make_min_config that was broken by new bisect_config changes
o Allow tests to undefine default options (not just being able to override
them)
o Print name of test (if defined) to start of tes
On Mon, Dec 08, 2014 at 06:46:50PM +0200, Kirill A. Shutemov wrote:
> I guess this crash is related to the patchset.
Might be. Do you have a reproducer for it?
It looks like the second VIRTUAL_BUG_ON() in __phys_addr(), most likely
from __pa(), from virt_to_page(), from
unsigned
Since both ppc and ppc64 have LE variants which are now reported by uname, add
that flag (__AUDIT_ARCH_LE) to syscall_get_arch() and add AUDIT_ARCH_PPC*LE
variants.
Without this, perf trace and auditctl fail.
Mainline kernel reports ppc64le (per a058801) but there is no matching
AUDIT_ARCH_PPC64
On 12/08/14 17:49, Jens Axboe wrote:
> On 12/08/2014 07:55 AM, Bart Van Assche wrote:
>> diff --git a/block/blk-mq-tag.c b/block/blk-mq-tag.c
>> index 67ab88b..e88af88 100644
>> --- a/block/blk-mq-tag.c
>> +++ b/block/blk-mq-tag.c
>> @@ -256,6 +256,8 @@ static int bt_get(struct blk_mq_alloc_data *d
Since both ppc and ppc64 have LE variants which are now reported by uname, add
that flag (__AUDIT_ARCH_LE) to syscall_get_arch() and add AUDIT_ARCH_PPC*LE
variants.
Without this, perf trace and auditctl fail.
Mainline kernel reports ppc64le (per a058801) but there is no matching
AUDIT_ARCH_PPC64
On Thu, Nov 20, 2014 at 2:42 PM, Benjamin Tissoires
wrote:
> On Fri, Oct 31, 2014 at 12:51 PM, Dmitry Torokhov
> wrote:
>> On Thu, Oct 30, 2014 at 02:33:06PM -0400, Benjamin Tissoires wrote:
>>> The current code tries to consider all states and transitions to properly
>>> detect which finger is a
On Mon, Dec 8, 2014 at 8:28 AM, Thierry Reding wrote:
> On Fri, Dec 05, 2014 at 04:30:00PM -0500, Hai Li wrote:
> [...]
>
>> + if (IS_ERR(edp))
>> + return PTR_ERR(edp);
>> + priv->edp = edp;
>> +
>> + return 0;
>> +}
>> +
>> +static void edp_unbind(struct device *dev, stru
On Mon, 8 Dec 2014 12:47:33 -0500 Tejun Heo wrote:
>
> ...
>
> This patch implements show_workqueue_state() which dumps all busy
> workqueues and pools and is called from the sysrq-t handler. At the
> end of sysrq-t dump, something like the following is printed.
Seems sensible.
sysrq-t already
On Mon, Dec 8, 2014 at 8:46 AM, Kirill A. Shutemov wrote:
>
> I guess this crash is related to the patchset.
Sounds likely.
> [ 102.338270] kernel BUG at
> /home/kas/git/public/linux-next/arch/x86/mm/physaddr.c:26!
So that's
VIRTUAL_BUG_ON((x > y) || !phys_addr_valid(x));
an
On Mon, Dec 08, 2014 at 05:58:05PM +, Al Viro wrote:
> It looks like the second VIRTUAL_BUG_ON() in __phys_addr(), most likely
> from __pa(), from virt_to_page(), from
> unsigned long addr = (unsigned long)v.iov_base, end;
> size_t len = v.iov_len + (*start = add
On Mon, Dec 08, 2014 at 10:55:34AM -0500, Pranith Kumar wrote:
> Isolate the SRCU functions and data structures within CONFIG_SRCU so that
> there
> is a compile time failure if srcu is used when not enabled. This was decided
> to
> be better than waiting until link time for a failure to occur.
Commit b2c4623dcd07 ("rcu: More on deadlock between CPU hotplug and expedited
grace periods") introduced another problem that can easily be reproduced by
starting/stopping cpus in a loop.
E.g.:
for i in `seq 5000`; do
echo 1 > /sys/devices/system/cpu/cpu1/online
echo 0 > /sys/devices
On Mon, Dec 8, 2014 at 10:08 AM, Al Viro wrote:
>
> FWIW, virt_to_page() is probably not OK to call on an address in the
> middle of vmalloc'ed area, is it?
See my email that crossed yours. No it is not.
> Would
> for (end = addr + len; addr < end; addr += PAGE_SIZE) {
>
On Mon, Dec 08, 2014 at 10:07:55AM -0800, Linus Torvalds wrote:
> Which is in the vmalloc address space. So somebody used a vmalloc'ed
> address and tried to convert it to a physical address in order to look
> up the page.
>
> Which is not a valid operation, and the BUG_ON() is definitely proper.
On 12/5/2014 6:50 PM, Rafael J. Wysocki wrote:
From: Rafael J. Wysocki
After commit b2b49ccbdd54 (PM: Kconfig: Set PM_RUNTIME if PM_SLEEP is
selected) PM_RUNTIME is always set if PM is set, so #ifdef blocks
depending on CONFIG_PM_RUNTIME may now be changed to depend on
CONFIG_PM.
Replace CONFI
The title should of course say active_writer ... grml
David
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.o
On Mon, Dec 08, 2014 at 10:14:13AM -0800, Linus Torvalds wrote:
> For a vmalloc() address, you'd have to actually walk the page tables.
> Which is a f*cking horrible idea. Don't do it. We do have a
> "vmalloc_to_page()" that does it, but the basic issue is that you damn
> well shouldn't do IO on v
On Mon, Dec 8, 2014 at 10:14 AM, Al Viro wrote:
>
> iov_iter_get_pages() in ITER_KVEC case, trying to avoid get_user_pages_fast()
> and getting it wrong. FWIW, the reproducer is finit_module(fd, )
> where fd has been opened with O_DIRECT. In that case we get kernel_read()
> on O_DIRECT and t
Hi,
Please consider pulling the following changes,
Steve.
--
The following changes since commit 0df1f2487d2f0d04703f142813d53615d62a1da4:
Linux 3.18-rc3 (2014-11-02 15:01:51 -0800)
are available in the git repos
On Mon, Dec 8, 2014 at 5:56 PM, Pantelis Antoniou
wrote:
> Hi Grant,
>
>> On Dec 8, 2014, at 19:50 , Grant Likely wrote:
>>
>> On Sat, 6 Dec 2014 14:55:33 +0100
>> , Pavel Machek
>> wrote:
>>> Hi!
>>>
> I am accustomed to doing 'echo -n' for most of sysfs anyway. Once in a
> while I am
On Mon, Dec 08, 2014 at 07:13:03PM +0100, David Hildenbrand wrote:
> Commit b2c4623dcd07 ("rcu: More on deadlock between CPU hotplug and expedited
> grace periods") introduced another problem that can easily be reproduced by
> starting/stopping cpus in a loop.
>
> E.g.:
> for i in `seq 5000`; do
On Mon, Dec 08, 2014 at 10:23:26AM -0800, Linus Torvalds wrote:
> Did this actually use to work? Or is it an issue of "the new iov_iter
> is so generic that something that used to just return an error now
> 'works' and triggers the problem"?
Looks like it failed with EINVAL. Which might very wel
From: Dean Ancajas
Fixed a brace coding style issue for functions.
Signed-off-by: Dean Michael Ancajas
---
drivers/staging/lustre/lustre/obdclass/cl_object.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/staging/lustre/lustre/obdclass/cl_object.c
b/drivers/stag
On Mon, Dec 8, 2014 at 10:20 AM, Al Viro wrote:
>
> I certainly had missed that insanity during the analysis - we don't do
> a lot of O_DIRECT IO to/from kernel addresses of any sort... This
> codepath allows it ;-/ Ability to trigger it is equivalent to ability
> to run any code in kernel mode,
On Sun, 7 Dec 2014, Linus Torvalds wrote:
> I'd love to say that we've figured out the problem that plagues 3.17
> for a couple of people, but we haven't. At the same time, there's
> absolutely no point in having everybody else twiddling their thumbs
> when a couple of people are actively trying t
On Mon, Dec 08, 2014 at 09:58:43PM +0530, Vinod Koul wrote:
> > > So bit sceptical for merging now. I will send the patches which I have
> > > applied on top of this
> >
> > Which is why I wanted to merge this at the *beginning* of the
> > development cycle in the first place
> >
> > These pa
Hello, Andrew.
On Mon, Dec 08, 2014 at 10:06:13AM -0800, Andrew Morton wrote:
> sysrq-t already produces thousands of lines of output. Maybe create a
> new keycode for this?
Believe it or not, we already used up all alphanumerics if we count in
the arch-specific ones. Given that the workqueue i
This patchset contains the initial GPIO support for the Broadcom Cygnus SoC.
Cygnus has 3 GPIO controllers: 1) the ASIU GPIO; 2) the chipCommonG GPIO;
and 3) the ALWAYS-ON GPIO. All 3 types of GPIO controllers are supported by
the same Cygnus GPIO driver
Changes from v1:
- Get rid of inline quali
This patchset contains the initial GPIO support for the Broadcom Cygnus SoC.
Cygnus has 3 GPIO controllers: 1) the ASIU GPIO; 2) the chipCommonG GPIO;
and 3) the ALWAYS-ON GPIO. All 3 types of GPIO controllers are supported by
the same Cygnus GPIO driver
Changes from v2:
- Consolidate different c
This enables all 3 GPIO controllers including the ASIU GPIO, the
chipcommonG GPIO, and the ALWAYS-ON GPIO, for Broadcom Cygnus SoC
Signed-off-by: Ray Jui
Reviewed-by: Scott Branden
---
arch/arm/boot/dts/bcm-cygnus.dtsi | 30 ++
1 file changed, 30 insertions(+)
dif
Signed-off-by: Ray Jui
---
MAINTAINERS |7 +++
1 file changed, 7 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index e6bff3a..8473422 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2202,6 +2202,13 @@ N: bcm9583*
N: bcm583*
N: bcm113*
+BROADCOM CYGNUS GPIO DRIVER
This GPIO driver supports all 3 GPIO controllers in the Broadcom Cygnus
SoC. The 3 GPIO controllers are 1) the ASIU GPIO controller, 2) the
chipCommonG GPIO controller, and 3) the ALWAYS-ON GPIO controller
Signed-off-by: Ray Jui
Reviewed-by: Scott Branden
---
drivers/gpio/Kconfig |
On Mon, Dec 08, 2014 at 10:37:51AM -0800, Linus Torvalds wrote:
> How about we make "kernel_read()" just clear O_DIRECT? Does that fix
> it to just use copies?
Umm... clearing O_DIRECT on struct file that might have other references
to it isn't nice, to put it mildly...
Frankly, stopping iov_it
Enable GPIO driver for Broadcom Cygnus SoC by selecting GPIO_BCM_CYGNUS
Signed-off-by: Ray Jui
Reviewed-by: Scott Branden
---
arch/arm/mach-bcm/Kconfig |1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/mach-bcm/Kconfig b/arch/arm/mach-bcm/Kconfig
index aaeec78..5066d5d 100644
---
Document the GPIO device tree binding for Broadcom Cygnus SoC
Signed-off-by: Ray Jui
Reviewed-by: Scott Branden
---
.../devicetree/bindings/gpio/brcm,cygnus-gpio.txt | 82
1 file changed, 82 insertions(+)
create mode 100644 Documentation/devicetree/bindings/gpio/brcm,cy
Sorry. Please ignore this particular cover letter. It accidentally got
sent along with other v3 patches.
On 12/8/2014 10:47 AM, Ray Jui wrote:
This patchset contains the initial GPIO support for the Broadcom Cygnus SoC.
Cygnus has 3 GPIO controllers: 1) the ASIU GPIO; 2) the chipCommonG GPIO;
a
Hi Pali,
>> On Saturday 06 December 2014 13:49:54 Pavel Machek wrote:
>> /**
>>
>> + * request_firmware_prefer_user: - prefer usermode
>> helper for loading firmware + * @firmware_p: pointer to
>> firmware image
>> + * @name: name of firmware file
>> + * @device: d
;
> While at it, fix some minor grammar issues in warning messages.
>
> Suggested-by: Daniel Borkmann
> Signed-off-by: Christoph Jaeger
This doesn't apply on next-20141208. What tree did you base this on?
Thanks,
Paul Bolle
--
To unsubscribe from this list: send the line "
Hi,
On Mon, Dec 8, 2014 at 9:34 AM, Wolfram Sang wrote:
>
>> > There are different capitalisation of i2c in the patch and the commit log.
>> > I
>> > don't know what Wolfram prefers here, but using the same spelling
>> > everywhere would be nice.
>>
>> Can you please point out? IIRC you should
On Mon, Dec 08, 2014 at 05:58:05PM +, Al Viro wrote:
> On Mon, Dec 08, 2014 at 06:46:50PM +0200, Kirill A. Shutemov wrote:
>
> > I guess this crash is related to the patchset.
>
> Might be. Do you have a reproducer for it?
trinity triggers it for me in few minutes. I will try find out more
On Mon, Dec 8, 2014 at 10:46 AM, Al Viro wrote:
> On Mon, Dec 08, 2014 at 10:37:51AM -0800, Linus Torvalds wrote:
>
>> How about we make "kernel_read()" just clear O_DIRECT? Does that fix
>> it to just use copies?
>
> Umm... clearing O_DIRECT on struct file that might have other references
> to i
> On Mon, Dec 08, 2014 at 07:13:03PM +0100, David Hildenbrand wrote:
> > Commit b2c4623dcd07 ("rcu: More on deadlock between CPU hotplug and
> > expedited
> > grace periods") introduced another problem that can easily be reproduced by
> > starting/stopping cpus in a loop.
> >
> > E.g.:
> > for
On Mon, Dec 8, 2014 at 10:56 AM, Kirill A. Shutemov
wrote:
>
> trinity triggers it for me in few minutes. I will try find out more once
> get some time.
You run trinity as *root*?
You're a brave man. Stupid, but brave ;)
I guess you're running it in a VM, but still.. Doing random system
calls a
From: Dave Hansen
We calculate nr_pages with f->flush_end and f->flush_start, both
of which are virtual addresses. However, we only divide
f->flush_start by PAGE_SIZE, and missed f->flush_end. This patch
adds some parenthesis to catch f->flush_end as well.
nr_pages is only used for a trace po
From: Dave Hansen
If flush_end ends up being at or above 1 page before the end of
memory, the following calculation can overflow:
f->flush_end = f->flush_start + PAGE_SIZE;
x86_64 has a 2MB hole at the end of memory, so we don't expect
this to be possible there. On i386, I believe thi
On Mon, 8 Dec 2014 13:40:35 -0500 Tejun Heo wrote:
> Hello, Andrew.
>
> On Mon, Dec 08, 2014 at 10:06:13AM -0800, Andrew Morton wrote:
> > sysrq-t already produces thousands of lines of output. Maybe create a
> > new keycode for this?
>
> Believe it or not, we already used up all alphanumerics
On Mon, Dec 08, 2014 at 07:58:14PM +0100, David Hildenbrand wrote:
> > On Mon, Dec 08, 2014 at 07:13:03PM +0100, David Hildenbrand wrote:
> > > Commit b2c4623dcd07 ("rcu: More on deadlock between CPU hotplug and
> > > expedited
> > > grace periods") introduced another problem that can easily be re
Hi Chao,
On Mon, Dec 08, 2014 at 03:01:16PM +0800, Chao Yu wrote:
> Let's add readahead code for reading contiguous compact/normal summary blocks
> in checkpoint, then we will gain better performance in mount procedure.
>
> Signed-off-by: Chao Yu
> ---
> fs/f2fs/checkpoint.c | 2 +-
> fs/f2fs/
On Mon, 8 Dec 2014, Vince Weaver wrote:
> down. They are borderline heisenbugs that are possibly race conditions,
> so bisecting doesn't work and even things like enablibg ftrace will make
> the issue go away (or crash ftrace itself).
For example, just trying to enable some extra printks in th
On Mon, 2014-12-08 at 19:51 +0100, Paul Bolle wrote:
> This doesn't apply on next-20141208. What tree did you base this on?
I got it to apply on next-20141208 by dropping the hunk for
arch/cris/arch-v32/drivers/Kconfig and by making (trivial) context
changes to the hunks for init/Kconfig
On Monday 08 December 2014 19:50:17 Marcel Holtmann wrote:
> Hi Pali,
>
> >> On Saturday 06 December 2014 13:49:54 Pavel Machek
> >> wrote: /**
> >>
> >> + * request_firmware_prefer_user: - prefer usermode
> >> helper for loading firmware + * @firmware_p: pointer to
> >> f
On Mon, Dec 08, 2014 at 11:01:41AM -0800, Linus Torvalds wrote:
> On Mon, Dec 8, 2014 at 10:56 AM, Kirill A. Shutemov
> wrote:
> >
> > trinity triggers it for me in few minutes. I will try find out more once
> > get some time.
>
> You run trinity as *root*?
>
> You're a brave man. Stupi
On Monday, December 08, 2014 12:59:32 PM Richard Guy Briggs wrote:
> Since both ppc and ppc64 have LE variants which are now reported by uname,
> add that flag (__AUDIT_ARCH_LE) to syscall_get_arch() and add
> AUDIT_ARCH_PPC*LE variants.
>
> Without this, perf trace and auditctl fail.
>
> Mainli
On 12/08/2014 08:13 PM, Paul Bolle wrote:
On Mon, 2014-12-08 at 19:51 +0100, Paul Bolle wrote:
This doesn't apply on next-20141208. What tree did you base this on?
I got it to apply on next-20141208 by dropping the hunk for
arch/cris/arch-v32/drivers/Kconfig and by making (trivial) co
On Sat, Dec 06, 2014 at 09:08:36PM +0900, Alexandre Courbot wrote:
> On Fri, Dec 5, 2014 at 7:24 PM, Maxime Ripard
> wrote:
> > On Thu, Dec 04, 2014 at 11:49:19PM +0900, Alexandre Courbot wrote:
> >> On Thu, Dec 4, 2014 at 11:27 PM, Maxime Ripard
> >> wrote:
> >> > Hi,
> >> >
> >> > On Thu, Dec 0
(cc'ing Greg for tty)
On Mon, Dec 08, 2014 at 11:05:15AM -0800, Andrew Morton wrote:
> > Believe it or not, we already used up all alphanumerics if we count in
> > the arch-specific ones. Given that the workqueue information would
> > primarily be useful in tracking down hangs and we'd want to se
On Mon, Dec 08, 2014 at 11:01:41AM -0800, Linus Torvalds wrote:
> On Mon, Dec 8, 2014 at 10:56 AM, Kirill A. Shutemov
> wrote:
> >
> > trinity triggers it for me in few minutes. I will try find out more once
> > get some time.
>
> You run trinity as *root*?
>
> You're a brave man. Stupid, but br
On Mon, 2014-12-08 at 20:15 +0100, Pali Rohár wrote:
> On Monday 08 December 2014 19:50:17 Marcel Holtmann wrote:
> > Hi Pali,
> >
> > >> On Saturday 06 December 2014 13:49:54 Pavel Machek
> > >> wrote: /**
> > >>
> > >> + * request_firmware_prefer_user: - prefer usermode
> >
1 - 100 of 733 matches
Mail list logo