On Fri, May 13, 2016 at 5:03 AM, Roger Quadros wrote:
> From: Yoshihiro Shimoda
>
> Since some host controller (e.g. EHCI) needs a companion host controller
> (e.g. OHCI), this patch adds such a configuration to use it in the OTG
> core.
>
> Signed-off-by: Yoshihiro Shimoda
> Signed-off-by: Roge
Ping? Any additional feedback?
We've been holding off putting this code into ChromeOS since I'm happy
to integrate (just about) any addtional feedback on the code or DT
entries.
thanks!
grant
On Tue, May 10, 2016 at 7:07 PM, Grant Grundler wrote:
> From: Daniel Hung-yu Wu
>
> Add I2C driver f
From: Ben Greear
Date: Fri, 13 May 2016 09:57:19 -0700
> How do you feel about a new socket-option to allow a socket to
> request the old veth behaviour?
I depend upon the opinions of the experts who work upstream on and
maintain these components, since it is an area I am not so familiar
with.
On 05/13/2016 11:21 AM, David Miller wrote:
From: Ben Greear
Date: Fri, 13 May 2016 09:57:19 -0700
How do you feel about a new socket-option to allow a socket to
request the old veth behaviour?
I depend upon the opinions of the experts who work upstream on and
maintain these components, sinc
On 05/11/2016 10:36 AM, Jan Kara wrote:
On Tue 03-05-16 14:17:19, Jan Kara wrote:
The question remains how common a pattern where throttling of background
writeback delays also something else is. I'll schedule a couple of
benchmarks to measure impact of your patches for a wider range of workload
On Tue, May 10, 2016 at 7:07 PM, Grant Grundler wrote:
> From: Daniel Hung-yu Wu
>
> Add binding for Atmel Capacitive Touch Button device.
>
> Signed-off-by: Daniel Hung-yu Wu
> Signed-off-by: Grant Grundler
> ---
> .../devicetree/bindings/input/atmel,captouch.txt | 34
> +++
We never want to kill the GIC.
Noticed when making other clock fixups, and seeing the newly-constructed
clock tree try to disable cpll, where we had this parent structure:
aclk_gic <--\
|--- aclk_gic_pre <-- cpll <-- pll_cpll
aclk_gic_noc <--/
Signed-off-by: Brian Norri
From: Xing Zheng
There was a typo, swapping 'c' <--> 'g'.
Signed-off-by: Xing Zheng
Signed-off-by: Brian Norris
---
drivers/clk/rockchip/clk-rk3399.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/clk/rockchip/clk-rk3399.c
b/drivers/clk/rockchip/clk-rk3399.c
As far as I can tell DRDY for ST sensors behaves as a level rather than
edge interrupt. Registering for IRQF_TRIGGER_RISING instead of
IRQF_TRIGGER_HIGH mostly works except when the sampling frequency is
high enough that new samples come before the new ones are read
completely. In that case the int
This fixes odd behavior after reboot.
The fact that we set the device to powerdown mode is not sufficient to
prevent DRDY being active because we might still have an unread sample.
Even if powerdown was sufficient keeping DRDY disabled while trigger is
not active is a good idea.
Cc: Linus Wallei
This fixes a possible race where an interrupt arrives before complete
initialization and crashes because iio_trigger_get_drvdata returns NULL.
Cc: Linus Walleij
Cc: Giuseppe Barba
Cc: Denis Ciocca
Signed-off-by: Crestez Dan Leonard
---
I ran into this while breaking the driver. But since the i
Shawn,
On Thu, May 12, 2016 at 6:02 PM, Shawn Lin wrote:
> Hi Brian,
>
>
> On 2016/5/13 6:43, Brian Norris wrote:
>>
>> From: Shawn Lin
>>
>> Signal integrity analysis has suggested we set these values. Do this in
>> power_on(), so that they get reconfigured after suspend/resume.
>>
>> Signed-of
Linus,
Please pull the latest perf-urgent-for-linus git tree from:
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
perf-urgent-for-linus
# HEAD: 636fa4a7b0d2987b7395cd2e259962cdca16e887 Merge tag
'perf-urgent-for-mingo-20160512' of
git://git.kernel.org/pub/scm/linux/kernel/git
Linus,
Please pull the latest sched-urgent-for-linus git tree from:
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
sched-urgent-for-linus
# HEAD: 53d3bc773eaa7ab1cf63585e76af7ee869d5e709 Revert "sched/fair: Fix
fairness issue on migration"
This is a revert to fix an interacti
> -Original Message-
> From: Muhammad Falak R Wani [mailto:falakre...@gmail.com]
> Sent: Friday, May 13, 2016 1:17 PM
> To: Jani Nikula
> Cc: Koenig, Christian; Nils Wallménius; Zhou, Jammy; linux-
> ker...@vger.kernel.org; dri-de...@lists.freedesktop.org; Deucher,
> Alexander; Zhu, Rex; Da
Changes from v1: https://lkml.org/lkml/2016/5/9/12
- dropped READ_ONCE(sem->counter) patch -- we already have barriers
(ie set_task_struct) in the loop, and therefore do not see stale
variables.
- Reworked and merged the other patches to get rid of the explicit
waiter (reader) refcount.
Readers that are awoken will expect a nil ->task indicating
that a wakeup has occurred. Because of the way readers are
implemented, there's a small chance that the waiter will never
block in the slowpath (rwsem_down_read_failed), and therefore
requires some form of reference counting to avoid the f
As wake_qs gain users, we can teach rwsems about them such that
waiters can be awoken without the wait_lock. This is for both
readers and writer, the former being the most ideal candidate
as we can batch the wakeups shortening the critical region that
much more -- ie writer task blocking a bunch of
On 04/28/2016 12:08 PM, Marc Zyngier wrote:
On 27/04/16 19:52, David Long wrote:
From: "David A. Long"
Add HAVE_REGS_AND_STACK_ACCESS_API feature for arm64.
And clearly a lot more.
Signed-off-by: David A. Long
---
arch/arm64/Kconfig | 1 +
arch/arm64/include/asm/ptrace.
On Tue, May 10, 2016 at 05:16:30PM -0700, Shaohua Li wrote:
> Hi,
>
> This patch set adds low/high limit for blk-throttle cgroup. The interface is
> io.low and io.high.
>
> low limit implements best effort bandwidth/iops protection. If one cgroup
> doesn't reach its low limit, no other cgroups ca
Greetings,
I am analyzing output in /proc/diskstats for block devices that have a
4096B physical and logical sector size. 4KN or 4K-native disk drives.
8 33 sdc1 1289 0 10312 5893 3258606 53 1668254992 16804002 31
583987 16807101
Fields 3 and 7 are sectors read and written respectively
Hello.
On 05/13/2016 12:35 AM, Sergei Shtylyov wrote:
[we already talked about this patch in #armlinux, I'm now just
forwarding my comments on the list. Background was that I sent an easier
and less complete patch with the same idea. See
http://patchwork.ozlabs.org/patch/621418/]
[added Linus
On 04/25/2016 03:26 PM, Colin King wrote:
> From: Colin Ian King
>
> fix spelling mistake, argumant -> argument
>
> Signed-off-by: Colin Ian King
> ---
> drivers/infiniband/hw/mlx4/main.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/infiniband/hw/mlx4/main.
Hello.
On 05/13/2016 12:07 PM, Roger Quadros wrote:
[...]
+}
+EXPORT_SYMBOL(mdio_device_reset);
+
/**
* mdio_probe - probe an MDIO device
* @dev: device to probe
@@ -117,9 +126,16 @@ static int mdio_probe(struct device *dev
struct mdio_driver *mdiodrv = to_mdio_driver(drv);
On 05/01/2016 08:35 AM, Muhammad Falak R Wani wrote:
> It is safe to use RCU_INIT_POINTER() to NULL a pointer, instead of
> rcu_assign_pointer().
> This results in slightly smaller/faster code.
>
> Signed-off-by: Muhammad Falak R Wani
> ---
> drivers/staging/rdma/hfi1/init.c | 2 +-
> 1 file cha
On Fri, 2016-05-13 at 12:50 -0400, Doug Ledford wrote:
> On 05/01/2016 08:07 AM, Julia Lawall wrote:
> > The i40e_client_ops structure is never modified, so declare it as
> const.
> >
> > Done with the help of Coccinelle.
> >
> > Signed-off-by: Julia Lawall
>
> Thanks, applied.
I already have
Here are a few late bugfixes for vc4. I figure it's best to bring
them in through -next since 4.6 is about done. I've based them late
in your -next branch to avoid needing conflict resolution.
The following changes since commit bafb86f5bc3173479002555dea7f31d943b12332:
Merge tag 'v4.6-rc7' in
> Use setup_timer() for initializing the timer, instead of structure
> assignments.
> This is the preferred/standard way.
>
> Signed-off-by: Muhammad Falak R Wani
Acked-by: James Simmons
> ---
> drivers/staging/lustre/lnet/lnet/net_fault.c | 4 +---
> 1 file changed, 1 insertion(+), 3 deleti
Brian,
On Fri, May 13, 2016 at 11:42 AM, Brian Norris wrote:
> We never want to kill the GIC.
>
> Noticed when making other clock fixups, and seeing the newly-constructed
> clock tree try to disable cpll, where we had this parent structure:
>
> aclk_gic <--\
> |--- aclk_gi
On Fri, 13 May 2016, Jeff Kirsher wrote:
> On Fri, 2016-05-13 at 12:50 -0400, Doug Ledford wrote:
> > On 05/01/2016 08:07 AM, Julia Lawall wrote:
> > > The i40e_client_ops structure is never modified, so declare it as
> > const.
> > >
> > > Done with the help of Coccinelle.
> > >
> > > Signed-
On 03/28/2016 07:57 PM, Chien Tin Tung wrote:
> On Mon, Mar 28, 2016 at 12:14:46PM +0100, Colin King wrote:
>> From: Colin Ian King
>>
>> passing hw_stats by value requires a 280 byte copy so instead
>> pass it by reference is much more efficient.
>>
>> Signed-off-by: Colin Ian King
>
> Thank yo
commit 27dd9af6bc000ab21fd ("ARM: dts: sunxi: Add a olinuxino-lime2-emmc")
added the new emmc equipped lime2 but forgot its Makefile.
This patch adds an entry to the Makefile.
Signed-off-by: Olliver Schinagl
---
Changes since v1:
Added proper commit reference (again).
Changes since v0:
Added
On 05/11/2016 10:26 PM, Li Bin wrote:
on 2016/5/11 23:33, James Morse wrote:
Hi David,
On 27/04/16 19:52, David Long wrote:
From: "David A. Long"
This patchset is heavily based on Sandeepa Prabhu's ARM v8 kprobes patches,
first seen in October 2013. This version attempts to address concern
Hi,
On Fri, May 13, 2016 at 11:42 AM, Brian Norris wrote:
> From: Xing Zheng
>
> There was a typo, swapping 'c' <--> 'g'.
>
> Signed-off-by: Xing Zheng
> Signed-off-by: Brian Norris
> ---
> drivers/clk/rockchip/clk-rk3399.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff
On Fri, May 13, 2016 at 10:47:05PM +0530, Muhammad Falak R Wani wrote:
> Sorry for my childish mistake, i got a little too carried away.
No need to appologize, it's just a disagreement about style issues.
regards,
dan carpenter
Hi Ashwin,
On Fri, May 13, 2016 at 10:23 AM, Ashwin Chaugule
wrote:
> On 11 May 2016 at 14:15, Hoan Tran wrote:
>> On Wed, May 11, 2016 at 4:57 AM, Ashwin Chaugule
>> wrote:
>>> On 11 May 2016 at 00:21, Hoan Tran wrote:
On Tue, May 10, 2016 at 5:00 AM, Ashwin Chaugule
> On 6 May 2016
Currently we free the resources backing the enclosure device before we
call device_unregister(). This is racy: during rmmod of low-level SCSI
drivers that hook into enclosure, we end up with a small window of time
during which writing to /sys can OOPS. Example trace with mpt3sas:
general protect
On the hardware I'm testing on, simply removing the mpt3sas module
triggers a litany of WARNs culminating in an OOPS:
[ cut here ]
WARNING: CPU: 5 PID: 13348 at lib/kobject.c:244
kobject_add_internal+0x359/0x8a0
kobject_add_internal failed for ArrayDevice09 (error: -
The following changes since commit c10fcb14c7afd6688c7b197a814358fecf244222:
x86/sysfb_efi: Fix valid BAR address range check (2016-05-05 16:01:00 +0200)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/mfleming/efi.git tags/efi-urgent
for you to fetch c
From: Alex Thorlton
The efi_call assembly code has a slight error that prevents us from
using arguments 7 and higher, which will be passed in on the stack.
mov (%rsp), %rax
mov 8(%rax), %rax
...
mov %rax, 40(%rsp)
This code goes and grabs the return address for t
Paolo Valente writes:
> When a bio is cloned, the newly created bio must be associated with
> the same blkcg as the original bio (if BLK_CGROUP is enabled). If
> this operation is not performed, then the new bio is not associated
> with any group, and the group of the current task is returned whe
On 05/13/2016 03:40 PM, Jeff Kirsher wrote:
> On Fri, 2016-05-13 at 12:50 -0400, Doug Ledford wrote:
>> On 05/01/2016 08:07 AM, Julia Lawall wrote:
>>> The i40e_client_ops structure is never modified, so declare it as
>> const.
>>>
>>> Done with the help of Coccinelle.
>>>
>>> Signed-off-by: Ju
> >Another issue is that on some boards we have one reset line tied to
> >multiple PHYs.How do we prevent multiple resets being taking place when each
> >of
> >the PHYs are registered?
>
>My patch just doesn't address this case -- it's about the
> individual resets only.
This actually needs
On 05/12/16 15:54, Kees Cook wrote:
>>
>> It would be far better to warn on the *type* of relocations rather than in
>> which section they feel.
>
> I'm open to specific changes. What's the best way to detect what you want
> here?
>
Use readelf -r and look for inappropriate relocation types (w
From: Xing Zheng
These clocks are all core clocks used by many blocks/peripherals, many
of whose drivers don't set their clock rates at all. Let's assign
reasonable default clock rates for these core clocks, so that these
peripherals get something reasonable by default, and also so that if
child
On Thu, May 12, 2016 at 01:40:06PM -0600, Jason Gunthorpe wrote:
> On Thu, May 12, 2016 at 03:27:27PM -0400, Dennis Dalessandro wrote:
>
> > >>+static inline int check_ioctl_access(unsigned int cmd, unsigned long arg)
> > >>+{
> > >>+ int read_cmd, write_cmd, read_ok, write_ok;
> > >>+
> > >>+ rea
On 05/13/2016 11:44 PM, Andrew Lunn wrote:
Another issue is that on some boards we have one reset line tied to
multiple PHYs.How do we prevent multiple resets being taking place when each of
the PHYs are registered?
My patch just doesn't address this case -- it's about the
individual resets
Okay, I think it's finally time to release version 1.0 of rt-tests.
There aren't too many interesting changes this round, just a bunch of house
keeping things, like adding missing man-pages, and updating old ones.
Two interesting changes though are:
- We now compile with HAVE_PARSE_CPUSTRING_A
We use netconsole to collect kernel logs from all the servers at
Facebook. We use this patch internally so each logline has a record of
which kernel version emitted it.
At first glance, this might seem lazy: as you would expect, we have a
database which records which kernel version a host is curre
Use setup_timer() and instead of init_timer(), being the preferred way
of setting up a timer.
Also, quoting the mod_timer() function comment:
-> mod_timer() is a more efficient way to update the expire field of an
active timer (if the timer is inactive it will be activated).
Use setup_timer()
Use setup_timer() and instead of init_timer(), being the preferred way
of setting up a timer.
Also, quoting the mod_timer() function comment:
-> mod_timer() is a more efficient way to update the expire field of an
active timer (if the timer is inactive it will be activated).
Use setup_timer()
Use setup_timer() and instead of init_timer(), being the preferred way
of setting up a timer.
Also, quoting the mod_timer() function comment:
-> mod_timer() is a more efficient way to update the expire field of an
active timer (if the timer is inactive it will be activated).
Use setup_timer()
Hi Marcel,
> so I am not big fan of the conditional locking in case of parent is set or
> not. Do you have a test case that reproduces the mentioned race. It would
> love to have that in tools/l2cap-tester or similar.
So far I could only reproduce the bug by repeatedly performing RFCOMM
connec
On Tuesday 10 May 2016 11:39:34 Bjorn Andersson wrote:
> On Mon 09 May 18:29 PDT 2016, Stephen Rothwell wrote:
>
> > Hi all,
> >
> > After merging the net-next tree, today's linux-next build (x86_64
> > allmodconfig) failed like this:
> >
> > net/qrtr/smd.c:106:14: error: initialization from inc
On Fri, May 13, 2016 at 11:46:33AM -0700, Doug Anderson wrote:
> On Thu, May 12, 2016 at 6:02 PM, Shawn Lin wrote:
> > On 2016/5/13 6:43, Brian Norris wrote:
> >> @@ -154,6 +167,20 @@ static int rockchip_emmc_phy_power_on(struct phy
> >> *phy)
> >> struct rockchip_emmc_phy *rk_phy = phy_ge
This patch series adds device tree support for generic memory-mapped GPIOs.
The GPIO library already allows drivers and architecture support code to
reuse generic code for managing a GPIO chip. Currently, a developer has
to create a platform device "basic-mmio-gpio" and attach a bgpio_pdata
platfor
This patch adds support for the Western Digital's
MyBook Live memory-mapped GPIO controllers.
The GPIOs will be supported by the generic driver
for memory-mapped GPIO controllers.
Signed-off-by: Christian Lamparter
---
drivers/gpio/gpio-mmio.c | 4
1 file changed, 4 insertions(+)
diff --g
From: Álvaro Fernández Rojas
This patch adds support for defining memory-mapped GPIOs which
are compatible with the existing gpio-mmio interface. The generic
library provides support for many memory-mapped GPIO controllers
that are found in various on-board FPGA and ASIC solutions that
are used t
On 05/09/2016 11:04 PM, Lijun Ou wrote:
> The HiSilicon Network Substem is a long term evolution IP which is
> supposed to be used in HiSilicon ICT SoCs. HNS (HiSilicon Network
> Sybsystem) also has a hardware support of performing RDMA with
> RoCEE.
> The driver for HiSilicon RoCEE(RoCE Engine) is
From: Shawn Lin
Signal integrity analysis has suggested we set these values. Do this in
power_on(), so that they get reconfigured after suspend/resume.
Signed-off-by: Shawn Lin
Signed-off-by: Brian Norris
---
v2:
* Sent only patch 2/4 with version 2, to avoid spamming; will move on to v3
f
Hello.
On 05/13/2016 07:06 AM, Andrew Lunn wrote:
+ gpiod = fwnode_get_named_gpiod(&child->fwnode, "reset-gpios");
+ /* Deassert the reset signal */
+ if (!IS_ERR(gpiod))
+ gpiod_direction_output(gpiod, 0);
This is wrong I think. You must only ignore -ENODEV, a
> -Original Message-
> From: linux-kernel-ow...@vger.kernel.org [mailto:linux-kernel-
> ow...@vger.kernel.org] On Behalf Of Calvin Owens
> Sent: Friday, May 13, 2016 3:28 PM
...
> Subject: [PATCH] mpt3sas: Do scsi_remove_host() before deleting SAS PHY
> objects
>
...
> The issue is that
Hello, Linus.
CPU hotplug callbacks can invoke DOWN_FAILED w/o preceding
DOWN_PREPARE which can trigger a WARN_ON() in workqueue. The bug has
been there for a very long time. It only triggers if CPU down fails
at a specific point and I don't think it has adverse effects other
than the warning me
Hi,
On Fri, May 13, 2016 at 1:50 PM, Brian Norris wrote:
> From: Xing Zheng
>
> These clocks are all core clocks used by many blocks/peripherals, many
> of whose drivers don't set their clock rates at all. Let's assign
> reasonable default clock rates for these core clocks, so that these
> perip
On 05/09/2016 11:04 PM, Lijun Ou wrote:
> --- a/drivers/infiniband/hw/hns/hns_roce_device.h
> +++ b/drivers/infiniband/hw/hns/hns_roce_device.h
> @@ -29,10 +31,93 @@
> #define HNS_ROCE_AEQE_VEC_NUM1
> #define HNS_ROCE_AEQE_OF_VEC_NUM 1
>
> +#define ADDR_SHI
Hello, Linus.
During v4.6-rc1 cgroup namespace support was merged. There is an
issue where it's impossible to tell whether a given cgroup mount point
is bind mounted or namespaced. Serge has been working on the issue
but it took longer than expected to resolve, so the late pull request.
Given t
Hi,
On Thu, May 12, 2016 at 3:35 PM, Brian Norris wrote:
> Add description for the SDHCI v5.1 eMMC controller on rk3399. Fix it to
> 200 MHz, to support all supported timing modes.
>
> Note that 'rockchip,rk3399-sdhci-5.1' is not documented; we presumably
> have a compliant Arasan controller, but
Rockchip's rk3399 evaluation board has eMMC. Let's enable the
newly-added node.
Signed-off-by: Brian Norris
---
v3:
* no change
v2:
* better commit description
arch/arm64/boot/dts/rockchip/rk3399-evb.dts | 12
1 file changed, 12 insertions(+)
diff --git a/arch/arm64/boot/dts/
Add description for the SDHCI v5.1 eMMC controller on rk3399. Fix it to
200 MHz, to support all supported timing modes.
Note that 'rockchip,rk3399-sdhci-5.1' is not documented; we presumably
have a compliant Arasan controller, but let's have a rockchip property
as the canonical backup/precautionar
On Fri, May 13, 2016 at 02:42:06PM -0700, Doug Anderson wrote:
> On Thu, May 12, 2016 at 3:35 PM, Brian Norris
> wrote:
> > + emmc_phy: phy@f780 {
> > + compatible = "rockchip,rk3399-emmc-phy";
> > + reg = <0xf780 0x20>;
>
> This is sligh
Am Donnerstag, 12. Mai 2016, 15:35:51 schrieb Brian Norris:
> Add description for the SDHCI v5.1 eMMC controller on rk3399. Fix it to
> 200 MHz, to support all supported timing modes.
>
> Note that 'rockchip,rk3399-sdhci-5.1' is not documented; we presumably
> have a compliant Arasan controller, b
Hello.
On 05/13/2016 10:06 AM, Uwe Kleine-König wrote:
[...]
Index: net-next/drivers/of/of_mdio.c
===
--- net-next.orig/drivers/of/of_mdio.c
+++ net-next/drivers/of/of_mdio.c
@@ -44,6 +44,7 @@ static int of_get_phy_id(struct device
Am Donnerstag, 12. Mai 2016, 15:35:52 schrieb Brian Norris:
> Rockchip's rk3399 evaluation board has eMMC. Let's enable the
> newly-added node.
>
> Signed-off-by: Brian Norris
> ---
> v2:
>
> * better commit description
>
> arch/arm64/boot/dts/rockchip/rk3399-evb.dts | 12
> 1 fi
On 05/09/2016 11:04 PM, Lijun Ou wrote:
> +int __hns_roce_cmd(struct hns_roce_dev *hr_dev, u64 in_param, u64 *out_param,
> +unsigned long in_modifier, u8 op_modifier, u16 op,
> +unsigned long timeout);
> +
> +/* Invoke a command with no output parameter */
> +static
On Fri, May 13, 2016 at 11:47:57PM +0200, Heiko Stuebner wrote:
> Am Donnerstag, 12. Mai 2016, 15:35:51 schrieb Brian Norris:
> > Add description for the SDHCI v5.1 eMMC controller on rk3399. Fix it to
> > 200 MHz, to support all supported timing modes.
> >
> > Note that 'rockchip,rk3399-sdhci-5.1
On Thu, May 12, 2016 at 11:00 PM, Arnd Bergmann wrote:
> A recent patch added a stub function for acpi_video_get_levels when
> CONFIG_ACPI_VIDEO is disabled. However, this is marked as 'static'
> and causes a warning about an unused function whereever the header
> gets included:
>
> In file includ
Hi,
On Thu, May 12, 2016 at 3:43 PM, Brian Norris wrote:
> From: Shawn Lin
>
> According to the databook, 10.2us is the max time for dll to be ready to
> work. However in testing, some chips need 20us for dll to be ready. This
> patch adds some extra margin for dllrdy to be ready, fixing our
> -
Hi,
On Fri, May 13, 2016 at 2:09 PM, Brian Norris wrote:
> From: Shawn Lin
>
> Signal integrity analysis has suggested we set these values. Do this in
> power_on(), so that they get reconfigured after suspend/resume.
>
> Signed-off-by: Shawn Lin
> Signed-off-by: Brian Norris
> ---
> v2:
> * S
On 05/09/2016 11:04 PM, Lijun Ou wrote:
> +static void hns_roce_v1_cq_clean(struct hns_roce_cq *hr_cq, u32 qpn,
> + struct hns_roce_srq *srq)
> +{
> + spin_lock_irq(&hr_cq->lock);
> + hns_roce_v1_clean_cq(hr_cq, qpn, srq);
> + spin_unlock_irq(&hr_cq->lock);
On Monday, May 09, 2016 09:02:04 PM Viresh Kumar wrote:
> On 03-05-16, 20:49, Akshay Adiga wrote:
> > Fixes are based on patch https://patchwork.ozlabs.org/patch/612058/ which
> > is in Rafael's linux-next.
> >
> > - Patch [1] fixes WARN_ON in powernv_target_index()
> > - Patch [2] Deleting any pe
(Including more folks, quoting entire patch)
On Thu, 12 May, at 08:19:54PM, Shannon Zhao wrote:
> From: Shannon Zhao
>
> The EFI DT parameters for bare metal are located under /chosen node,
> while for Xen Dom0 they are located under /hyperviosr/uefi node. These
> parameters under /chosen and /h
Per the examples in
Documentation/devicetree/bindings/phy/rockchip-emmc-phy.txt, we need the
grf node to be a simple-mfd in order to properly enumerate child devices
like our eMMC PHY.
Signed-off-by: Brian Norris
---
v4:
* New, split out of patch 2, per Heiko's recommendation
arch/arm64/boot/
Rockchip's rk3399 evaluation board has eMMC. Let's enable the
newly-added nodes.
Signed-off-by: Brian Norris
---
v4:
* alphabetize &node references
v3:
* no change
v2:
* better commit description
arch/arm64/boot/dts/rockchip/rk3399-evb.dts | 12
1 file changed, 12 insertion
Add description for the SDHCI v5.1 eMMC controller on rk3399. Fix it to
200 MHz, to support all supported timing modes.
Note that 'rockchip,rk3399-sdhci-5.1' is not documented; we presumably
have a compliant Arasan controller, but let's have a rockchip property
as the canonical backup/precautionar
From: Dave Hansen
When I added support for the Memory Protection Keys processor
feature, I had to reindent the REQUIRED/DISABLED_MASK macros, and
also consult the later cpufeature words.
I'm not quite sure how I bungled it, but I consulted the wrong
word at the end. This only affected required
Am Freitag, 13. Mai 2016, 14:57:24 schrieb Brian Norris:
> On Fri, May 13, 2016 at 11:47:57PM +0200, Heiko Stuebner wrote:
> > Am Donnerstag, 12. Mai 2016, 15:35:51 schrieb Brian Norris:
> > > Add description for the SDHCI v5.1 eMMC controller on rk3399. Fix it
> > > to
> > > 200 MHz, to support al
If a command with a Simple task attribute is failed due to a Unit
Attention, then a subsequent command with an Ordered task attribute will
hang forever. The reason for this is that the Unit Attention status is
checked for in target_setup_cmd_from_cdb, before the call to
target_execute_cmd, which c
On Fri 13 May 14:01 PDT 2016, Arnd Bergmann wrote:
> On Tuesday 10 May 2016 11:39:34 Bjorn Andersson wrote:
[..]
> > I assume we could have the QRTR go through Andy and arm-soc, with
> > David's approval and this fix squashed in. But we're running rather late
> > in this cycle, perhaps we should j
Hi,
On Thu, May 12, 2016 at 3:43 PM, Brian Norris wrote:
> The output tap delay controls helps maintain the hold requirements for
> eMMC. The exact value is dependent on the SoC and other factors, though
> it isn't really an exact science. But the default of 0 is not very good,
> as it doesn't gi
Hi,
On Thu, May 12, 2016 at 3:43 PM, Brian Norris wrote:
> Some of the spacing was wrong (spaces instead of tabs), and due to
> longer entries added later, the columns weren't aligned. Let's get
> everything consistent.
>
> Signed-off-by: Brian Norris
> ---
> drivers/phy/phy-rockchip-emmc.c | 7
On Thu 12 May 17:52 PDT 2016, Andrew Duggan wrote:
> On 05/11/2016 08:05 PM, Bjorn Andersson wrote:
> >On Wed 11 May 16:30 PDT 2016, Andrew Duggan wrote:
> >
> >>Hi Bjorn,
> >>
> >>On 05/10/2016 08:49 AM, Bjorn Andersson wrote:
> >[..]
> >>>So either we duplicate the regulator support in spi/i2c o
On 5/13/2016 7:58 AM, Peter Zijlstra wrote:
On Thu, May 12, 2016 at 11:39:47PM -0700, Vikram Mulukutla wrote:
Hi,
I came across a piece of engineering code that looked like:
preempt_disable();
/* --cut, lots of code-- */
preempt_enable_no_resched();
put_user()
preempt_disable();
(If you wish
On 13 May 2016 at 17:19, Bjorn Andersson wrote:
> On Fri 13 May 14:01 PDT 2016, Arnd Bergmann wrote:
>
>> On Tuesday 10 May 2016 11:39:34 Bjorn Andersson wrote:
> [..]
>> > I assume we could have the QRTR go through Andy and arm-soc, with
>> > David's approval and this fix squashed in. But we're r
Hi,
On Fri, May 13, 2016 at 3:12 PM, Brian Norris wrote:
> Per the examples in
> Documentation/devicetree/bindings/phy/rockchip-emmc-phy.txt, we need the
> grf node to be a simple-mfd in order to properly enumerate child devices
> like our eMMC PHY.
>
> Signed-off-by: Brian Norris
> ---
> v4:
>
Hi,
On Fri, May 13, 2016 at 3:12 PM, Brian Norris wrote:
> Rockchip's rk3399 evaluation board has eMMC. Let's enable the
> newly-added nodes.
>
> Signed-off-by: Brian Norris
> ---
> v4:
>
> * alphabetize &node references
>
> v3:
>
> * no change
>
> v2:
>
> * better commit description
>
> arc
Hi,
This series is on top of the current linux-next witn the following two patches
applied:
https://patchwork.kernel.org/patch/9080801/
https://patchwork.kernel.org/patch/9080791/
It cleans up a few things and then reworks the governor API to get rid of
governor events and use callbacks represen
From: Rafael J. Wysocki
It is not necessary to check the governor's max_transition_latency
attribute every time cpufreq_governor() runs, so check it only if
the event argument is CPUFREQ_GOV_POLICY_INIT.
Signed-off-by: Rafael J. Wysocki
---
drivers/cpufreq/cpufreq.c | 25 +---
On Fri, May 13, 2016 at 03:12:45PM -0400, Vivek Goyal wrote:
> On Tue, May 10, 2016 at 05:16:30PM -0700, Shaohua Li wrote:
> > Hi,
> >
> > This patch set adds low/high limit for blk-throttle cgroup. The interface is
> > io.low and io.high.
> >
> > low limit implements best effort bandwidth/iops p
From: Rafael J. Wysocki
None of the cpufreq governors currently in the tree will ever fail
an invocation of the ->governor() callback with the event argument
equal to CPUFREQ_GOV_LIMITS (unless invoked with incorrect arguments
which doesn't matter anyway) and had it ever failed, the result of
it
From: Rafael J. Wysocki
The performance and powersave cpufreq governors handle the
CPUFREQ_GOV_START event in the same way as CPUFREQ_GOV_LIMITS.
However, the cpufreq core always invokes cpufreq_governor() with the
event argument equal to CPUFREQ_GOV_LIMITS right after invoking it with
event equa
401 - 500 of 541 matches
Mail list logo
