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 |
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 v5:
- Get rid of DT property
On Tue, Dec 16, 2014 at 4:53 AM, Laurent Pinchart
wrote:
> Hi Tomasz,
>
> On Monday 15 December 2014 11:39:01 Tomasz Figa wrote:
>> On Sat, Dec 13, 2014 at 5:47 AM, Laurent Pinchart wrote:
>> > On Friday 12 December 2014 13:15:51 Tomasz Figa wrote:
>> >> On Fri, Dec 12, 2014 at 5:48 AM, Rafael J.
On Mon, Dec 15, 2014 at 5:50 PM, Dave Airlie wrote:
>
> Now you might complain that printing anything in this case is bad,
I don't mind it if it's *one* line, and if people realize that the
commentary in the commit in question was pure and utter shit.
Because talking about how it's going to
In filename__read_build_id, phdr points to memory in buf, which gets realloced
before a call to fseek that uses phdr->p_offset. This change stores the value
of p_offset before buf is realloced, so the fseek can use the value safely.
Signed-off-by: Mitchell Krome
---
On 12/05/2014 07:44 PM, Greg Kroah-Hartman wrote:
On Fri, Dec 05, 2014 at 07:30:48PM -0800, Guenter Roeck wrote:
On 12/05/2014 02:42 PM, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 3.17.5 release.
There are 122 patches in this series, all will be posted as a
Hi Mark :
Got it, it will be good to use simple-card. i will try it in next version.
Best Regards.
在 2014年12月16日 00:18, Mark Brown 写道:
On Mon, Dec 15, 2014 at 09:10:26PM +0800, Kuankuan.Yang wrote:
Hi Mark & Russell:
Please don't top post, that way people have some context for what you're
Commit 85c116a6c introduces asprintf() call and matches '%ld' to a u64
argument, which is incorrect on ARM.
CC /home/wn/util/srcline.o
util/srcline.c: In function 'get_srcline':
util/srcline.c:297:6: error: format '%ld' expects argument of type 'long int',
but argument 4 has type
Thanks Martin for the explanation.
I'll send out another patch.
> -Original Message-
> From: Martin K. Petersen [mailto:martin.peter...@oracle.com]
> Sent: Thursday, December 11, 2014 7:04 PM
> To: Long Li
> Cc: Martin K. Petersen; KY Srinivasan; Haiyang Zhang;
>
This patch adds support for EHCI compliant Host controller found
on Fujitsu Socs.
Signed-off-by: Sneeker Yeh
---
.../devicetree/bindings/usb/fujitsu-ehci.txt | 22 ++
drivers/usb/host/Kconfig | 11 +
drivers/usb/host/Makefile |1 +
Synopsis DesignWare USB3 IP Core integrated with a config-free
phy needs special handling during device disconnection to avoid
the host controller dying.
This quirk makes sure PORT_CSC is cleared after the disable slot
command when usb device is disconnected from internal root hub,
otherwise,
This patch adds support for Synopsis DesignWare USB3 IP Core found
on Fujitsu Socs.
Signed-off-by: Sneeker Yeh
---
.../devicetree/bindings/usb/fujitsu-dwc3.txt | 25 +++
drivers/usb/dwc3/Kconfig | 11 ++
drivers/usb/dwc3/Makefile |
These patches add support for EHCI and XHCI compliant Host controller found
on Fujitsu Socs, and are based on
http://www.spinics.net/lists/arm-kernel/msg385573.html
First patch is EHCI platform glue driver. Patch 2 introduces Fujitsu
Specific Glue layer in Synopsis DesignWare USB3 IP driver.
On Wed, Dec 10, 2014 at 8:39 AM, Eric W. Biederman
wrote:
>
> Will people please test these patches with their container project?
>
> These changes break container userspace (hopefully in a minimal way) if
> I could have that confirmed by testing I would really appreciate it. I
> really don't
On Mon, Dec 15, 2014 at 10:22 PM, Dinh Nguyen wrote:
>
>
> On 12/15/14, 12:22 AM, Ley Foon Tan wrote:
>> On Fri, Dec 12, 2014 at 10:38 PM, Dinh Nguyen wrote:
>>
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
On 13/12/14 02:18, Olof Johansson wrote:
> Hi,
>
>
>
> On Thu, Dec 11, 2014 at 12:38 AM, Aaron Lu wrote:
>> INT3406 ACPI device object resembles an ACPI video output device, but its
>> _BCM is said to be deprecated and should not be used. So we will make
>> use of the raw interface to do the
Hi,
The patch set is used to implement reset controller in
http://lists.infradead.org/pipermail/linux-arm-kernel/2014-November/299141.html
Tested-by: Flora Fu
Thanks,
Flora
On Mon, 2014-12-15 at 09:58 +, Lee Jones wrote:
> On Mon, 15 Dec 2014, Philipp Zabel wrote:
> > Am Montag, den
On Mon, Dec 15, 2014 at 5:47 PM, Stephen Rothwell wrote:
> Hi all,
>
> After merging the infiniband tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
>
> drivers/infiniband/hw/mlx5/main.c: In function 'mlx5_ib_query_device':
> drivers/infiniband/hw/mlx5/main.c:248:34:
On 16 December 2014 at 11:03, Linus Torvalds
wrote:
> On Mon, Dec 15, 2014 at 4:48 PM, Dave Airlie wrote:
>>
>> I'd be inclined to just revert this for now, it is annoying we let
>> userspace away with this, but we probably need to find a better
>> way to enforce it, since the cat is out of the
On Mon, Dec 15, 2014 at 7:48 PM, Dave Airlie wrote:
> On 16 December 2014 at 10:35, Linus Torvalds
> wrote:
>> On Sun, Dec 14, 2014 at 11:17 PM, Dave Airlie wrote:
>>>
>>> i915:
>>> Initial Skylake (SKL) support
>>> gen3/4 reset work
>>> start of dri1/ums removal
>>>
clared (first use in this function)
if (dev->caps.gen.flags & MLX5_DEV_CAP_FLAG_ON_DMND_PG)
^
Really? Code added half way though the merge window not even build
tested?
I have used the infiniband tree from next-20141215 for today.
--
Cheers,
Stephen Rothw
On Mon, 2014-12-15 at 11:31 -0600, Eric W. Biederman wrote:
> Huang Ying writes:
>
> > FYI, we noticed the below changes on
> >
> > git://git.kernel.org/pub/scm/linux/kernel/git/ebiederm/user-namespace.git
> > for-testing
> > commit bbea5f5532501fdd67f46442ba7b1122d7ff3123
> > ("userns: Add a
On 2014/12/16 3:54, Thomas Gleixner wrote:
> On Mon, 15 Dec 2014, Jiang Liu wrote:
>> On 2014/12/15 23:13, Joerg Roedel wrote:
>>> Hi,
>>>
>>> here is a patch-set against tip/x86/apic to fix an initialization order
>>> problem with the IRQ remapping code. The problem is in the ordering of
>>>
On Tue, Dec 16, 2014 at 10:09:25AM +0900, Jaewon Kim wrote:
> Hi Dmitry,
>
> 2014년 12월 14일 04:56에 Dmitry Torokhov 이(가) 쓴 글:
> >Hi Jaewon,
> >
> >On Fri, Dec 12, 2014 at 07:32:28PM +0900, Jaewon Kim wrote:
...
> >>+static int __maybe_unused regulator_haptic_suspend(struct device *dev)
> >>+{
> >>+
Hi all,
Today's linux-next merge of the infiniband tree got a conflict in
drivers/infiniband/hw/mlx5/mr.c between commit 479163f46082 ("mlx5:
don't duplicate kvfree()") from Linus' tree and commit 89c925949c1f
("IB/mlx5: Implement on demand paging by adding support for MMU
notifiers") from the
Jeremiah,
No problem. :-)
Thank you very much for your help and so much time on review these patches.
I will fix this issue as soon as possible.
Thanks,
Dudley
> -Original Message-
> From: linux-input-ow...@vger.kernel.org
> [mailto:linux-input-ow...@vger.kernel.org] On Behalf Of
Hi Krzysztof,
On 12/15/2014 11:53 PM, Krzysztof Kozlowski wrote:
> On pią, 2014-12-12 at 17:27 +0900, Chanwoo Choi wrote:
>> This patch add new devfreq_event class for devfreq_event device which provide
>> raw data (e.g., memory bus utilization/GPU utilization). This raw data from
>>
Hi Krzysztof,
On 12/15/2014 11:53 PM, Krzysztof Kozlowski wrote:
> On pią, 2014-12-12 at 17:27 +0900, Chanwoo Choi wrote:
>> This patch adds the list of supported devfreq-event type as following.
>> Each devfreq-event device driver would support the various devfreq-event type
>> for devfreq
Doug,
On Mon, Dec 15, 2014 at 4:22 PM, Doug Anderson wrote:
> We've introduced a new helper in the MMC core:
> mmc_regulator_set_vqmmc(). Let's use this in dw_mmc. Using this new
> helper has some advantages:
>
> 1. We get the mmc_regulator_set_vqmmc() behavior of trying to match
>VQMMC
Hi Dmitry,
2014년 12월 14일 04:56에 Dmitry Torokhov 이(가) 쓴 글:
Hi Jaewon,
On Fri, Dec 12, 2014 at 07:32:28PM +0900, Jaewon Kim wrote:
This patch adds support for haptic driver controlled by
voltage of regulator. And this driver support for
Force Feedback interface from input framework
The mm-of-the-moment snapshot 2014-12-15-17-05 has been uploaded to
http://www.ozlabs.org/~akpm/mmotm/
mmotm-readme.txt says
README for mm-of-the-moment:
http://www.ozlabs.org/~akpm/mmotm/
This is a snapshot of my -mm patch queue. Uploaded at random hopefully
more than once a week.
You
On Mon, Dec 15, 2014 at 4:48 PM, Dave Airlie wrote:
>
> I'd be inclined to just revert this for now, it is annoying we let
> userspace away with this, but we probably need to find a better
> way to enforce it, since the cat is out of the bag.
.. why did that commit ever even get far enough to
dev_pm_opp_get_opp_count() must be called with RCU lock held.
Signed-off-by: Dmitry Torokhov
---
Again, not tested...
drivers/cpufreq/exynos5440-cpufreq.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/cpufreq/exynos5440-cpufreq.c
b/drivers/cpufreq/exynos5440-cpufreq.c
Hello ALSA/Kernel devs,
I have a Dell Precision M6800 with latest BIOS here is output from the HDA
driver
[ 20.783635] snd_hda_intel :00:03.0: enabling device ( -> 0002)
[ 20.783804] snd_hda_intel :00:1b.0: irq 34 for MSI/MSI-X
[ 20.783911] snd_hda_intel :01:00.1: Handle
> > Subject: Re: [E1000-devel] [PATCH] ixgbe, ixgbevf: Add new mbox API to
> > enable MC promiscuous mode
> >
> > On 11/27/2014 02:39 AM, Hiroshi Shimamoto wrote:
> > > From: Hiroshi Shimamoto
> > >
> > > The limitation of the number of multicast address for VF is not enough
> > > for the large
Devices speaking HID++ 2.0 report a different error code (0xff). Detect
these errors too to avoid 5 second delays when the device reports an
error. Caught by... well, a bug in the QEMU emulation of this receiver.
Renamed fap to rap for HID++ 1.0 errors because it is more logical,
it has no
Hi Jiri,
Here are more fixes intended for the 3.19 tree after a review. Two bugfixes.
one which was mentioned in a mail with Benjamin ("avoid unintended
fall-through") and a fix to avoid a possible 5 second delay for HID++ 2.0
errors. I haven't encountered a case where the hidpp module generates
Malicious USB devices can send bogus reports smaller than the expected
buffer size. Ensure that the length is valid to avoid reading out of
bounds.
For the old WTP, I do not have a HID descriptor so just check for the
minimum length in hidpp_raw_event (this can be changed to an inequality
later).
dev_pm_opp_get_opp_count() must be called with RCU lock held.
Signed-off-by: Dmitry Torokhov
---
Not tested at all...
drivers/cpufreq/imx6q-cpufreq.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/cpufreq/imx6q-cpufreq.c b/drivers/cpufreq/imx6q-cpufreq.c
index
On Mon, 2014-12-15 at 14:59 +0300, Dan Carpenter wrote:
> I prefer !foo because it is more common in the kernel and I think it's
> easier to read but I don't feel strongly about this.
Me too. But I do prefer consistency.
fyi: for variants of:
"if (!foo)"
vs
"if (foo == NULL)"
Add a return to avoid a fall-through. Introduced in commit
57ac86cf52e903d9e3e0f12b34c814cce6b65550 ("HID: logitech-hidpp: add
support of the first Logitech Wireless Touchpad").
Signed-off-by: Peter Wu
---
drivers/hid/hid-logitech-hidpp.c | 1 +
1 file changed, 1 insertion(+)
diff --git
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 11/25/2014 02:13 PM, Akers, Jason B wrote:
> Hi Phillip, It turns out that this patch was based on an old
> github repository that doesn't appear to be updated. Doug Gilbert
> reached out after the initial RFC and directed us to his page
>
On 16 December 2014 at 10:35, Linus Torvalds
wrote:
> On Sun, Dec 14, 2014 at 11:17 PM, Dave Airlie wrote:
>>
>> i915:
>> Initial Skylake (SKL) support
>> gen3/4 reset work
>> start of dri1/ums removal
>> infoframe tracking
>> fixes for lots of things.
>
>
On Mon, Dec 15, 2014 at 10:14:15AM -0800, Jacob Pan wrote:
> Enable RAPL driver on Xeon cpu id 0x56.
>
> Signed-off-by: Jacob Pan
> ---
> drivers/powercap/intel_rapl.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/powercap/intel_rapl.c b/drivers/powercap/intel_rapl.c
> index
Fixing the register name in sunxi_mmc_reset_host since the SDXC_HARDWARE_RESET
bit
is actually located within REG_GCTRL and not REG_CMDR as it was pointed out by
Allwinner.
Signed-off-by: David Lanzendörfer
Reported-by: 李想
---
drivers/mmc/host/sunxi-mmc.c |2 +-
1 file changed, 1
When there is only one DES available the DMA performs a FIFO reset and waits
until the reinitialization has been completed.
Disabling the SDXC_IDMAC_DES0_DIC bit prevents the DMA from sending an
interrupt after it has finished this reinitialization.
The flags SDXC_IDMAC_DES0_FD and
1) Adding a comment in order to clarify the choice of the locks within
sunxi_mmc_handle_manual_stop
2) As 李想 has pointed out the wait_dma variable was not accessed within the
spin lock
block in sunxi_mmc_request and so (even if it should never happend) it
would have
Removing a relict from reverse engineering of the Android driver code in
sunxi_mmc_clk_set_rate.
Signed-off-by: David Lanzendörfer
Reported-by: 李想
---
drivers/mmc/host/sunxi-mmc.c | 10 +-
1 file changed, 1 insertion(+), 9 deletions(-)
diff --git a/drivers/mmc/host/sunxi-mmc.c
Hello
This patchset was inspired questions from 李想 of Allwinner and incorporates as
well suggestions from Hans related to spin locks.
For example have not all attributes of the shared host object been protected
by the spin lock, this has been changed.
Also some register names and reset behavior
Hello Ganesh,
On Sat, Dec 13, 2014 at 09:43:23PM +0800, Ganesh Mahendran wrote:
> Currently functions in zsmalloc.c does not arranged in a readable
> and reasonable sequence. With the more and more functions added,
> we may meet below inconvenience. For example:
>
> Current functions:
> void
Certain OPP APIs need to be called under RCU lock; let's add a few
rcu_lockdep_assert() calls to warn about potential misuse.
Signed-off-by: Dmitry Torokhov
---
drivers/base/power/opp.c | 20
1 file changed, 20 insertions(+)
diff --git a/drivers/base/power/opp.c
On Sun, Dec 14, 2014 at 11:17 PM, Dave Airlie wrote:
>
> i915:
> Initial Skylake (SKL) support
> gen3/4 reset work
> start of dri1/ums removal
> infoframe tracking
> fixes for lots of things.
So I'm not sure how happy I am about this. It seems to work, but
Hi George,
On 15 Dec 2014 19:14:53 -0500 "George Spelvin" wrote:
>
> Stephen Rothwell wrote:
> > Please do *not* mix changes up like this. Split this out into a
> > separate patch, please (1 logical change per patch).
>
> Um... I thought I was doing that. More particularly, the task of
>
On 12/15/2014 1:37 PM, Arnd Bergmann wrote:
On Monday 15 December 2014 11:16:31 Ray Jui wrote:
On 12/12/2014 9:21 AM, Arnd Bergmann wrote:
On Friday 12 December 2014 09:08:48 Ray Jui wrote:
One way to solve this would be by turning the driver into a library
the same way as the pcie-dw
We've introduced a new helper in the MMC core:
mmc_regulator_set_vqmmc(). Let's use this in dw_mmc. Using this new
helper has some advantages:
1. We get the mmc_regulator_set_vqmmc() behavior of trying to match
VQMMC and VMMC when the signal voltage is 3.3V. This ensures max
This adds logic to the MMC core to set VQMMC. This is expected to be
called by MMC drivers like dw_mmc as part of (or instead of) their
start_signal_voltage_switch() callback.
A few notes:
* When setting the signal voltage to 3.3V we do our best to make VQMMC
and VMMC match. It's been
Specifying these rails should eventually let us do UHS.
Signed-off-by: Doug Anderson
---
Changes in v3: None
Changes in v2:
- Fix subject line
arch/arm/boot/dts/rk3288-evb.dtsi | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/boot/dts/rk3288-evb.dtsi
Stephen Rothwell wrote:
> Please do *not* mix changes up like this. Split this out into a
> separate patch, please (1 logical change per patch).
Um... I thought I was doing that. More particularly, the task of
untangling header file dependencies eseemed sufficiently cohesive
that it could be
A crash can occur on some platforms where adsp is enumerated but codec is not
matched. Define codec_id as a pointer intead of an array so that it gets
initialized to NULL for the terminating element of sst_acpi_bytcr[] and
sst_acpi_chv[].
Signed-off-by: Kevin Strasser
---
cpufreq-dt driver supports mode when OPP table is provided by platform
code and not device tree. However on certain platforms code that fills
OPP table may run after cpufreq driver tries to initialize, so let's
report -EPROBE_DEFER if we do not find any entires in OPP table for the
CPU.
Andrew,
On Mon, Dec 15, 2014 at 3:44 PM, Andrew Bresticker
wrote:
>> - if (!IS_ERR(mmc->supply.vqmmc)) {
>> - ret = regulator_set_voltage(mmc->supply.vqmmc, min_uv,
>> max_uv);
>> -
>> - if (ret) {
>> - dev_dbg(>class_dev,
>> -
On 12/15/2014 1:57 PM, Arnd Bergmann wrote:
On Monday 15 December 2014 13:35:47 Ray Jui wrote:
Like I said previously, dynamic GPIO allocation works fine in the
kernel, as long as all of our GPIO clients in the kernel use gpiod based
API, which is what we will enforce going forward. The only
On 12/15/2014 05:01 PM, Rickard Strandqvist wrote:
Hi
No the rtw_hw_resume23a() is not used anywhere.
I also do a check of all functions that are not used, but not in the
drivers/staging, I suspected that these might be under development and
used in the future.
What do you want to do, who
On Mon, Dec 15, 2014 at 06:26:09PM -0500, Joe Borg wrote:
> Fixing errors found with checkpatch.pl.
What exact errors? Please be specific here and describe what you are
doing.
thanks,
greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message
On Mon, 2014-12-15 at 23:23 +0100, Rickard Strandqvist wrote:
> Hi Joe
Hello Rickard
> No, it does not look like end can be NULL then.
> Then remove the end != NULL instead?
> ...
> if (end != NULL && *end == '.') {
Up to you.
> However, I am hesitant to the tolower() I think double case
Next pile (and there'll be one or two more). The large piece in this one is
getting rid of /proc/*/ns/* weirdness; among other things, it allows to
(finally) make nameidata completely opaque outside of fs/namei.c, making for
easier further cleanups in there.
I have _not_ included removal of
From: Matt Wagantall
It is sometimes necessary to poll a memory-mapped register until its value
satisfies some condition. Introduce a family of convenience macros that do
this. Tight-looping, sleeping, and timing out can all be accomplished using
these macros.
Cc: Thierry Reding
Cc: Will
On Mon, Dec 15, 2014 at 10:21 AM, Linus Torvalds
wrote:
>
> So let's just fix it. Here's a completely untested patch.
So after looking at this more, I'm actually really convinced that this
was a pretty nasty bug.
I'm *not* convinced that it's necessarily *your* bug, but I still
think it could
On Mon, Dec 15, 2014 at 03:02:17PM +0530, Viresh Kumar wrote:
> On 15 December 2014 at 12:55, Preeti U Murthy
> wrote:
> > Hi Viresh,
> >
> > Let me explain why I think this is happening.
> >
> > 1. tick_nohz_irq_enter/exit() both get called *only if the cpu is idle*
> > and receives an
On Mon, Dec 15 2014 at 03:31:20 PM, Mitchel Humpherys
wrote:
> From: Matt Wagantall
>
> It is sometimes necessary to poll a memory-mapped register until its value
> satisfies some condition. Introduce a family of convenience macros that do
> this. Tight-looping, sleeping, and timing out can all
Hi Doug,
On Mon, Dec 15, 2014 at 3:25 PM, Doug Anderson wrote:
> We've introduced a new helper in the MMC core:
> mmc_regulator_set_vqmmc(). Let's use this in dw_mmc. Using this new
> helper has some advantages:
>
> 1. We get the mmc_regulator_set_vqmmc() behavior of trying to match
>VQMMC
Hi Doug,
On Mon, Dec 15, 2014 at 3:25 PM, Doug Anderson wrote:
> This adds logic to the MMC core to set VQMMC. This is expected to be
> called by MMC drivers like dw_mmc as part of (or instead of) their
> start_signal_voltage_switch() callback.
>
> A few notes:
>
> * When setting the signal
On Mon, 2014-12-15 at 14:32 +1100, Ian Munsie wrote:
> Excerpts from Ian Munsie's message of 2014-12-08 19:18:01 +1100:
> > From: Ian Munsie
> >
> > If we need to force detach a context (e.g. due to EEH or simply force
> > unbinding the driver) we should prevent the userspace contexts from
> >
From: Matt Wagantall
It is sometimes necessary to poll a memory-mapped register until its value
satisfies some condition. Introduce a family of convenience macros that do
this. Tight-looping, sleeping, and timing out can all be accomplished using
these macros.
Cc: Thierry Reding
Cc: Will
We've introduced a new helper in the MMC core:
mmc_regulator_set_vqmmc(). Let's use this in dw_mmc. Using this new
helper has some advantages:
1. We get the mmc_regulator_set_vqmmc() behavior of trying to match
VQMMC and VMMC when the signal voltage is 3.3V. This ensures max
This adds logic to the MMC core to set VQMMC. This is expected to be
called by MMC drivers like dw_mmc as part of (or instead of) their
start_signal_voltage_switch() callback.
A few notes:
* When setting the signal voltage to 3.3V we do our best to make VQMMC
and VMMC match. It's been
Specifying these rails should eventually let us do UHS.
Signed-off-by: Doug Anderson
---
Changes in v2:
- Fix subject line
arch/arm/boot/dts/rk3288-evb.dtsi | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/boot/dts/rk3288-evb.dtsi
b/arch/arm/boot/dts/rk3288-evb.dtsi
index
On Mon, Dec 15, 2014 at 05:06:45PM +, Mark Brown wrote:
> Please fix your mailer to word wrap comfortably under 80 colums so that your
> mails are easily legible.
Understood
> > > This changes the check from verifying if a codec_id is present to
> > > verifying if the first character in the
Hi
My script looks for the same function name, so if they then would be
named exactly the same, they would come up.
But I can not even find drivers/staging/dream/ or is this really new code?
Kind regards
Rickard Strandqvist
2014-12-09 15:46 GMT+01:00 :
>
> Seems ok to me. These files, and
Daniel Baluta schrieb am 03.12.2014 um 14:31:
> We use WUFE (Wake Up from Sleep Engine) and BTSE (Back to Sleep Engine)
> to detect general motion input.
>
A few recommendations, issues and questions inline.
> Signed-off-by: Daniel Baluta
> ---
> drivers/iio/imu/kmx61.c | 433
>
On Mon, 2014-12-15 at 19:14 +0100, Ralf Baechle wrote:
> On Mon, Dec 01, 2014 at 04:09:36AM +, Ben Hutchings wrote:
>
> > > /* Same as tx - compute csum of pseudo header */
> > > csum = hwsum +
> > > -(ih->tot_len - (ih->ihl << 2)) +
> > > -htons((uint16_t)ih->protocol) +
Hi George,
On Mon, 15 Dec 2014 14:26:15 +1030 Rusty Russell wrote:
>
> George Spelvin writes:
> > It's the only user of in kernel.h, so that reduces
> > the compile-time cost of #include
> >
> > Only one user has to change: . The
> > there is needed for one function prototype that passes
Hi Dan
Quite right! Had to try it.
Do nothing then?
But you must agree that it is still ugly and confusing code.
Kind regards
Rickard Strandqvist
2014-12-15 11:25 GMT+01:00 Dan Carpenter :
> On Sun, Dec 14, 2014 at 11:37:18PM +0100, Rickard Strandqvist wrote:
>> There is otherwise a risk of a
Hi
No the rtw_hw_resume23a() is not used anywhere.
I also do a check of all functions that are not used, but not in the
drivers/staging, I suspected that these might be under development and
used in the future.
What do you want to do, who decides?
Kind regards
Rickard Strandqvist
2014-12-15
Vince,
On Mon, Dec 15, 2014 at 11:01 PM, Arnaldo Carvalho de Melo
wrote:
> Em Mon, Dec 15, 2014 at 04:07:46PM -0500, Vince Weaver escreveu:
>> Hello
>>
>> has anyone tested the perf tool cgroup support recently?
>>
>> I was trying to get it working with a command like
>> sudo perf stat -a
No comments besides the ones Randy already mentioned.
Thanks,
-corey
On 12/15/2014 09:52 AM, Jonathan Corbet wrote:
> The SubmittingPatches file still shows a lot of its roots from the era when
> we all sent stuff straight to Linus and hoped for the best. I've gone in
> and thrashed it up to
Dave Gerlach writes:
> From: Nishanth Menon
>
> PM QoS requests are notoriously hard to debug and made even
> more so due to their highly dynamic nature. Having visibility
> into the internal data representation per constraint allows
> us to have much better appreciation of potential issues or
On Monday, December 15, 2014 11:20:17 PM Rafael J. Wysocki wrote:
> On Monday, December 15, 2014 05:15:47 PM Boris Brezillon wrote:
> > Commit cab303be91dc47942bc25de33dc1140123540800 [1] introduced a WARN_ON
> > test which triggers a WARNING backtrace on at91 platforms.
>
> Pretty much as
Kevin Hilman writes:
> Sylwester Nawrocki writes:
>
>> On 09/12/14 13:59, Krzysztof Kozlowski wrote:
>>> On pią, 2014-12-05 at 15:15 +0100, Krzysztof Kozlowski wrote:
> Audio subsystem clocks are located in separate block. On Exynos 5420 if
> clock for this block (from main clock
Hi Joe
No, it does not look like end can be NULL then.
Then remove the end != NULL instead?
...
if (end != NULL && *end == '.') {
However, I am hesitant to the tolower() I think double case is faster...?
Kind regards
Rickard Strandqvist
2014-12-15 2:51 GMT+01:00 Joe Perches :
> On Sun,
Nicolas Ferre writes:
> Arnd, Olof, Kevin,
>
> I'm sending today a "fixes" branch which somehow continues the cleanup with
> only code removal. I was waiting for the arm-soc *and* pinctrl material to
> reach Linus T.'s tree before sending this pull-request. In fact this sequence
> was needed for
Currently there is a lock order problem between the console lock and the
kernfs s_active lock of the console driver's bind sysfs entry. When
writing to the sysfs entry the lock order is first s_active then console
lock, when unregistering the console driver via
do_unregister_con_driver() the order
The default console driver (conswitchp) and busy drivers bound to a
console (as reported by con_is_bound()) shouldn't be unregistered.
System console drivers (without the CON_DRIVER_FLAG_MODULE flag) can be
unregistered, provided they are neither default nor busy. The current
code checks for the
Currently vt_bind and vt_unbind access at least the con_driver object
and registered_con_driver array without holding the console lock. Fix
this by locking around the whole function in each case.
Signed-off-by: Imre Deak
Reviewed-by: Peter Hurley
---
drivers/tty/vt/vt.c | 11 +--
1
Em Mon, Dec 15, 2014 at 04:07:46PM -0500, Vince Weaver escreveu:
> Hello
>
> has anyone tested the perf tool cgroup support recently?
>
> I was trying to get it working with a command like
> sudo perf stat -a -e cycles:u,cycles:u,cycles:u -G systemd -- sleep 1
>
> and it just failed by
On Mon, Dec 15, 2014 at 08:56:15AM -0800, Christoph Hellwig wrote:
> On Mon, Dec 15, 2014 at 05:27:05PM +0100, Jan Kara wrote:
> > On Sun 14-12-14 21:26:56, Omar Sandoval wrote:
> > > The generic write code locks i_mutex for a direct_IO. Swap-over-NFS
> > > doesn't grab the mutex because
Mark,
On Fri, Dec 12, 2014 at 4:59 AM, Mark Brown wrote:
>> > There's also the potential
>> > performance considerations for the DVS type applications now I think
>> > about it.
>
>> Iterating through voltages is really that slow? If so, perhaps we
>> could add some caching to keep track of
Hi,
On Mon, Dec 15, 2014 at 01:31:28PM -0800, David Daney wrote:
> On 12/15/2014 01:09 PM, Aaro Koskinen wrote:
> >Hi,
> >
> >On Mon, Dec 15, 2014 at 09:03:19PM +0300, Aleksey Makarov wrote:
> >>From: David Daney
> >>
> >>Needed by follow-on patches.
> >
> >Looks like only one of the unions was
On Monday, December 15, 2014 05:15:47 PM Boris Brezillon wrote:
> Commit cab303be91dc47942bc25de33dc1140123540800 [1] introduced a WARN_ON
> test which triggers a WARNING backtrace on at91 platforms.
Pretty much as intended.
> While this WARN_ON is absolutely necessary to warn users that they
On Monday 15 December 2014 13:35:47 Ray Jui wrote:
>
> Like I said previously, dynamic GPIO allocation works fine in the
> kernel, as long as all of our GPIO clients in the kernel use gpiod based
> API, which is what we will enforce going forward. The only problem is
> with some of our
101 - 200 of 1908 matches
Mail list logo
