Re: [PATCH 2/2] perf record: Add --dry-run option to check cmdline options

Em Mon, Jun 20, 2016 at 12:16:55PM -0600, David Ahern escreveu: > On 6/20/16 12:13 PM, Arnaldo Carvalho de Melo wrote: > > 'perf cc' seems sensible, and has the added bonus of being one letter > > shorter :-) > perf is now a general front-end to a compiler? Well, it is for quite a while

Re: [PATCH 2/2] perf record: Add --dry-run option to check cmdline options

Em Mon, Jun 20, 2016 at 12:16:55PM -0600, David Ahern escreveu: > On 6/20/16 12:13 PM, Arnaldo Carvalho de Melo wrote: > > 'perf cc' seems sensible, and has the added bonus of being one letter > > shorter :-) > perf is now a general front-end to a compiler? Well, it is for quite a while

Re: [PATCH v3 05/15] phy: rockchip-emmc: Increase lock time allowance

On Mon, Jun 20, 2016 at 10:56 AM, Douglas Anderson wrote: > Previous PHY code waited a fixed amount of time for the DLL to lock at > power on time. Unfortunately, the time for the DLL to lock is actually > a bit more dynamic and can be longer if the card clock is slower. >

Re: [PATCH v3 05/15] phy: rockchip-emmc: Increase lock time allowance

On Mon, Jun 20, 2016 at 10:56 AM, Douglas Anderson wrote: > Previous PHY code waited a fixed amount of time for the DLL to lock at > power on time. Unfortunately, the time for the DLL to lock is actually > a bit more dynamic and can be longer if the card clock is slower. > > Instead of waiting a

Re: [PATCH v3 01/15] phy: rockchip-emmc: give DLL some extra time to be ready

Hi, On Mon, Jun 20, 2016 at 12:23 PM, Guenter Roeck wrote: > On Mon, Jun 20, 2016 at 10:56 AM, Douglas Anderson > wrote: >> From: Shawn Lin >> >> According to the databook, 10.2us is the max time for dll to be ready to >>

Re: [PATCH v3 01/15] phy: rockchip-emmc: give DLL some extra time to be ready

Hi, On Mon, Jun 20, 2016 at 12:23 PM, Guenter Roeck wrote: > On Mon, Jun 20, 2016 at 10:56 AM, Douglas Anderson > 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

Re: [PATCH v9 01/12] kthread: Rename probe_kthread_data() to kthread_probe_data()

On Thu, Jun 16, 2016 at 01:17:20PM +0200, Petr Mladek wrote: > A good practice is to prefix the names of functions by the name > of the subsystem. > > This patch fixes the name of probe_kthread_data(). The other wrong > functions names are part of the kthread worker API and will be > fixed

Re: [PATCH] torture: use ktime_t consistently

On Monday, June 20, 2016 11:37:57 AM CEST Paul E. McKenney wrote: > On Mon, Jun 20, 2016 at 08:29:48PM +0200, Arnd Bergmann wrote: > > On Monday, June 20, 2016 11:21:05 AM CEST Paul E. McKenney wrote: > > > On Mon, Jun 20, 2016 at 05:56:40PM +0200, Arnd Bergmann wrote: > > > > > > @@ -446,9

Re: [PATCH v9 01/12] kthread: Rename probe_kthread_data() to kthread_probe_data()

On Thu, Jun 16, 2016 at 01:17:20PM +0200, Petr Mladek wrote: > A good practice is to prefix the names of functions by the name > of the subsystem. > > This patch fixes the name of probe_kthread_data(). The other wrong > functions names are part of the kthread worker API and will be > fixed

Re: [PATCH] torture: use ktime_t consistently

On Monday, June 20, 2016 11:37:57 AM CEST Paul E. McKenney wrote: > On Mon, Jun 20, 2016 at 08:29:48PM +0200, Arnd Bergmann wrote: > > On Monday, June 20, 2016 11:21:05 AM CEST Paul E. McKenney wrote: > > > On Mon, Jun 20, 2016 at 05:56:40PM +0200, Arnd Bergmann wrote: > > > > > > @@ -446,9

Re: [PATCH v9 02/12] kthread: Kthread worker API cleanup

Hello, On Thu, Jun 16, 2016 at 01:17:21PM +0200, Petr Mladek wrote: > __init_kthread_worker() -> __kthread_init_worker() > init_kthread_worker() -> kthread_init_worker() > init_kthread_work() -> kthread_init_work() > insert_kthread_work() ->

Re: [PATCH v9 02/12] kthread: Kthread worker API cleanup

Hello, On Thu, Jun 16, 2016 at 01:17:21PM +0200, Petr Mladek wrote: > __init_kthread_worker() -> __kthread_init_worker() > init_kthread_worker() -> kthread_init_worker() > init_kthread_work() -> kthread_init_work() > insert_kthread_work() ->

Re: [PATCH v3 01/15] phy: rockchip-emmc: give DLL some extra time to be ready

On Mon, Jun 20, 2016 at 10:56 AM, Douglas Anderson 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 Nitpick, but

Re: [PATCH v3 01/15] phy: rockchip-emmc: give DLL some extra time to be ready

On Mon, Jun 20, 2016 at 10:56 AM, Douglas Anderson 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 Nitpick, but description (20uS) and code (more than 25 uS) don't

Re: [PATCH] perf: add 'perf bench syscall'

On Mon, Jun 20, 2016 at 11:00 AM, Josh Poimboeuf wrote: > > From: Josh Poimboeuf > Subject: [PATCH] perf: add 'perf bench syscall' > > Add a basic 'perf bench syscall' benchmark which does a getppid() system > call in a tight loop. > My one suggestion

Re: [PATCH] perf: add 'perf bench syscall'

On Mon, Jun 20, 2016 at 11:00 AM, Josh Poimboeuf wrote: > > From: Josh Poimboeuf > Subject: [PATCH] perf: add 'perf bench syscall' > > Add a basic 'perf bench syscall' benchmark which does a getppid() system > call in a tight loop. > My one suggestion would be to use a different syscall than

Re: [PATCH v2 3/3] firmware: scpi: add device power domain support using genpd

On 20/06/16 18:53, Kevin Hilman wrote: Sudeep Holla writes: This patch hooks up the support for device power domain provided by SCPI using the Linux generic power domain infrastructure. Cc: "Rafael J. Wysocki" Cc: Kevin Hilman

Re: [PATCH v2 3/3] firmware: scpi: add device power domain support using genpd

On 20/06/16 18:53, Kevin Hilman wrote: Sudeep Holla writes: This patch hooks up the support for device power domain provided by SCPI using the Linux generic power domain infrastructure. Cc: "Rafael J. Wysocki" Cc: Kevin Hilman Cc: Ulf Hansson Cc: linux...@vger.kernel.org Signed-off-by:

Re: [PATCH v2 4/8] scripts: add glimpse.sh for indexing the kernel

On Sat, Jun 18, 2016 at 07:51:55AM +0200, Julia Lawall wrote: > > > On Sat, 18 Jun 2016, Luis R. Rodriguez wrote: > > > On Fri, Jun 17, 2016 at 05:35:26PM +0200, Julia Lawall wrote: > > > On Fri, 17 Jun 2016, Luis R. Rodriguez wrote: > > > > > > > On Fri, Jun 17, 2016 at 11:44:26AM +0200,

Re: [PATCH v2 4/8] scripts: add glimpse.sh for indexing the kernel

On Sat, Jun 18, 2016 at 07:51:55AM +0200, Julia Lawall wrote: > > > On Sat, 18 Jun 2016, Luis R. Rodriguez wrote: > > > On Fri, Jun 17, 2016 at 05:35:26PM +0200, Julia Lawall wrote: > > > On Fri, 17 Jun 2016, Luis R. Rodriguez wrote: > > > > > > > On Fri, Jun 17, 2016 at 11:44:26AM +0200,

[PATCH v4 0/2] Add support for SYSCON reset

Some SoCs contain reset controls for modules that are memory-mapped to areas shared with other module configuration settings. This requires synchronization across all drivers accessing this memory area. This series adds a generic SYSCON reset driver to allow resets toggled by bits in memory-mapped

[PATCH v4 0/2] Add support for SYSCON reset

Some SoCs contain reset controls for modules that are memory-mapped to areas shared with other module configuration settings. This requires synchronization across all drivers accessing this memory area. This series adds a generic SYSCON reset driver to allow resets toggled by bits in memory-mapped

Re: [RFC PATCH v3 2/2] ARM64/PCI: Start using quirks handling for ACPI based PCI host controller

On Mon, Jun 20, 2016 at 10:17 AM, Christopher Covington wrote: > Hi Duc, > > On 06/20/2016 05:42 AM, Lorenzo Pieralisi wrote: >> On Fri, Jun 17, 2016 at 02:37:02PM -0700, Duc Dang wrote: >>> On Thu, Jun 16, 2016 at 10:48 AM, Lorenzo Pieralisi >>>

Re: [RFC PATCH v3 2/2] ARM64/PCI: Start using quirks handling for ACPI based PCI host controller

On Mon, Jun 20, 2016 at 10:17 AM, Christopher Covington wrote: > Hi Duc, > > On 06/20/2016 05:42 AM, Lorenzo Pieralisi wrote: >> On Fri, Jun 17, 2016 at 02:37:02PM -0700, Duc Dang wrote: >>> On Thu, Jun 16, 2016 at 10:48 AM, Lorenzo Pieralisi >>> wrote: On Wed, Jun 15, 2016 at 11:34:11AM

Re: [PATCH] ppc: Fix BPF JIT for ABIv2

On Sun, Jun 19, 2016 at 11:19:14PM +0530, Naveen N. Rao wrote: > On 2016/06/17 10:00AM, Thadeu Lima de Souza Cascardo wrote: > > On Fri, Jun 17, 2016 at 10:53:21PM +1000, Michael Ellerman wrote: > > > On Tue, 2016-07-06 at 13:32:23 UTC, "Naveen N. Rao" wrote: > > > > diff --git

Re: [PATCH] ppc: Fix BPF JIT for ABIv2

On Sun, Jun 19, 2016 at 11:19:14PM +0530, Naveen N. Rao wrote: > On 2016/06/17 10:00AM, Thadeu Lima de Souza Cascardo wrote: > > On Fri, Jun 17, 2016 at 10:53:21PM +1000, Michael Ellerman wrote: > > > On Tue, 2016-07-06 at 13:32:23 UTC, "Naveen N. Rao" wrote: > > > > diff --git

Re: [PATCH v5 0/7] /dev/random - a new approach

> With that being said, wouldn't it make sense to: > > - Get rid of the entropy heuristic entirely and just assume a fixed value of > entropy for a given event? What does that gain you? You can always impose an upper bound, but *some* evidence that it's not a metronome is nice to have. > -

Re: [PATCH v5 0/7] /dev/random - a new approach

> With that being said, wouldn't it make sense to: > > - Get rid of the entropy heuristic entirely and just assume a fixed value of > entropy for a given event? What does that gain you? You can always impose an upper bound, but *some* evidence that it's not a metronome is nice to have. > -

Re: linux-next: build warnings after merge of the pci tree

On Mon, Jun 20, 2016 at 11:52:13AM +1000, Stephen Rothwell wrote: > Hi Bjorn, > > After merging the pci tree, today's linux-next build (arm > multi_v7_defconfig) produced these warnings: > > drivers/pci/host/pci-host-common.c: In function 'gen_pci_init': >

Re: linux-next: build warnings after merge of the pci tree

On Mon, Jun 20, 2016 at 11:52:13AM +1000, Stephen Rothwell wrote: > Hi Bjorn, > > After merging the pci tree, today's linux-next build (arm > multi_v7_defconfig) produced these warnings: > > drivers/pci/host/pci-host-common.c: In function 'gen_pci_init': >

Re: [PATCH] pci: export devm_request_pci_bus_resources to modules

On Mon, Jun 20, 2016 at 05:45:41PM +0200, Arnd Bergmann wrote: > Host drivers can be loadable modules, so we might run into this > build error with the new interface: > > ERROR: devm_request_pci_bus_resources [drivers/pci/host/pcie-iproc.ko] > undefined! > > This adds an EXPORT_SYMBOL_GPL()

Re: [PATCH v2 4/5] ASoC: tpa6130a2: Add DAPM support

Hi Sebastian, Thank you for reviewing the patches. On 20-06-2016 14:12, Helen Koike wrote: Add DAPM support and updated rx51 accordingly. As a consequence: - the exported function tpa6130a2_stereo_enable is not needed anymore - the mutex is dealt in the DAPM - the power state is tracked by the

Re: [RFC] IB/srp: Remove create_workqueue

Hello, Bart. On Tue, Jun 07, 2016 at 01:00:13PM -0700, Bart Van Assche wrote: > > > > srp_remove_wq is used for SRP target port removal work only. This work > > > > is > > > > neither queued from inside a shrinker nor by the page writeback code so > > > > I > > > > think it is safe to drop

Re: [PATCH] pci: export devm_request_pci_bus_resources to modules

On Mon, Jun 20, 2016 at 05:45:41PM +0200, Arnd Bergmann wrote: > Host drivers can be loadable modules, so we might run into this > build error with the new interface: > > ERROR: devm_request_pci_bus_resources [drivers/pci/host/pcie-iproc.ko] > undefined! > > This adds an EXPORT_SYMBOL_GPL()

Re: [PATCH v2 4/5] ASoC: tpa6130a2: Add DAPM support

Hi Sebastian, Thank you for reviewing the patches. On 20-06-2016 14:12, Helen Koike wrote: Add DAPM support and updated rx51 accordingly. As a consequence: - the exported function tpa6130a2_stereo_enable is not needed anymore - the mutex is dealt in the DAPM - the power state is tracked by the

Re: [RFC] IB/srp: Remove create_workqueue

Hello, Bart. On Tue, Jun 07, 2016 at 01:00:13PM -0700, Bart Van Assche wrote: > > > > srp_remove_wq is used for SRP target port removal work only. This work > > > > is > > > > neither queued from inside a shrinker nor by the page writeback code so > > > > I > > > > think it is safe to drop

Re: [PATCH 0/3] nvme: Don't add namespaces for locked drives

On 20-06-16 08:26, Keith Busch wrote: > On Sun, Jun 19, 2016 at 04:06:31PM -0700, Jethro Beekman wrote: >> If an NVMe drive is locked with ATA Security, most commands sent to the >> drive >> will fail. This includes commands sent by the kernel upon discovery to probe >> for partitions. The

Re: [PATCH 0/3] nvme: Don't add namespaces for locked drives

On 20-06-16 08:26, Keith Busch wrote: > On Sun, Jun 19, 2016 at 04:06:31PM -0700, Jethro Beekman wrote: >> If an NVMe drive is locked with ATA Security, most commands sent to the >> drive >> will fail. This includes commands sent by the kernel upon discovery to probe >> for partitions. The

Re: [RFC] capabilities: add capability cgroup controller

On 06/19/16 20:01, se...@hallyn.com wrote: > apologies for top posting, this phone doesn't support inline) > > Where are you preventing less privileged tasks from limiting the caps of a > more privileged task? It looks like you are relying on the cgroupfs for that? I didn't think that aspect.

Re: [RFC] capabilities: add capability cgroup controller

On 06/19/16 20:01, se...@hallyn.com wrote: > apologies for top posting, this phone doesn't support inline) > > Where are you preventing less privileged tasks from limiting the caps of a > more privileged task? It looks like you are relying on the cgroupfs for that? I didn't think that aspect.

Re: [Jfs-discussion] [PATCH v2 05/24] fs: jfs: Replace CURRENT_TIME_SEC by current_time()

On 06/19/2016 07:27 PM, Deepa Dinamani wrote: > jfs uses nanosecond granularity for filesystem timestamps. > Only this assignemt is not using nanosecond granularity. > Use current_time() to get the right granularity. > > Signed-off-by: Deepa Dinamani > Cc:

Re: [Jfs-discussion] [PATCH v2 05/24] fs: jfs: Replace CURRENT_TIME_SEC by current_time()

On 06/19/2016 07:27 PM, Deepa Dinamani wrote: > jfs uses nanosecond granularity for filesystem timestamps. > Only this assignemt is not using nanosecond granularity. > Use current_time() to get the right granularity. > > Signed-off-by: Deepa Dinamani > Cc: jfs-discuss...@lists.sourceforge.net

Re: [PATCH v2 00/24] Delete CURRENT_TIME and CURRENT_TIME_SEC macros

> This version now looks ok to me. > > I do have a comment (or maybe just a RFD) for future work. > > It does strike me that once we actually change over the inode times to > use timespec64, the calling conventions are going to be fairly > horrendous on most 32-bit architectures. > > Gcc handles

Re: [PATCH v2 00/24] Delete CURRENT_TIME and CURRENT_TIME_SEC macros

> This version now looks ok to me. > > I do have a comment (or maybe just a RFD) for future work. > > It does strike me that once we actually change over the inode times to > use timespec64, the calling conventions are going to be fairly > horrendous on most 32-bit architectures. > > Gcc handles

Re: [patch V2 00/20] timer: Refactor the timer wheel

On Mon, 2016-06-20 at 15:56 +0200, Thomas Gleixner wrote: >  > 2) Cut off at 37hrs for HZ=1000. We could make this configurable as a > 1000HZ >    option so datacenter folks can use this and people who don't care > and want >    better batching for power can use the 4ms thingy. > It might be

Re: [patch V2 00/20] timer: Refactor the timer wheel

On Mon, 2016-06-20 at 15:56 +0200, Thomas Gleixner wrote: >  > 2) Cut off at 37hrs for HZ=1000. We could make this configurable as a > 1000HZ >    option so datacenter folks can use this and people who don't care > and want >    better batching for power can use the 4ms thingy. > It might be

Re: [PATCH v2] arm: tegra124: remove commas from unit addresses

On Mon, Jun 20, 2016 at 10:45:55AM -0600, Stephen Warren wrote: > On 06/20/2016 10:40 AM, Thierry Reding wrote: > > On Mon, Jun 20, 2016 at 09:50:26AM -0600, Stephen Warren wrote: > > > On 06/18/2016 07:04 PM, Marcel Ziswiler wrote: > > > > Remove commas from unit addresses as suggested by Rob

Re: [PATCH v2] arm: tegra124: remove commas from unit addresses

On Mon, Jun 20, 2016 at 10:45:55AM -0600, Stephen Warren wrote: > On 06/20/2016 10:40 AM, Thierry Reding wrote: > > On Mon, Jun 20, 2016 at 09:50:26AM -0600, Stephen Warren wrote: > > > On 06/18/2016 07:04 PM, Marcel Ziswiler wrote: > > > > Remove commas from unit addresses as suggested by Rob

Re: [PATCH v5 0/7] /dev/random - a new approach

Am Montag, 20. Juni 2016, 14:44:03 schrieb George Spelvin: Hi George, > > With that being said, wouldn't it make sense to: > > > > - Get rid of the entropy heuristic entirely and just assume a fixed value > > of entropy for a given event? > > What does that gain you? You can always impose an

Re: [PATCH v5 0/7] /dev/random - a new approach

Am Montag, 20. Juni 2016, 14:44:03 schrieb George Spelvin: Hi George, > > With that being said, wouldn't it make sense to: > > > > - Get rid of the entropy heuristic entirely and just assume a fixed value > > of entropy for a given event? > > What does that gain you? You can always impose an

Re: [PATCH v3 0/2] Add support for SYSCON reset

On 06/15/2016 09:13 PM, Rob Herring wrote: > On Wed, Jun 15, 2016 at 11:45 AM, Philipp Zabel > wrote: >> Hi Andrew, >> >> Am Mittwoch, den 15.06.2016, 10:48 -0500 schrieb Andrew F. Davis: >>> On 06/01/2016 01:41 PM, Andrew F. Davis wrote: Some SoCs contain reset

Re: [PATCH v3 0/2] Add support for SYSCON reset

On 06/15/2016 09:13 PM, Rob Herring wrote: > On Wed, Jun 15, 2016 at 11:45 AM, Philipp Zabel > wrote: >> Hi Andrew, >> >> Am Mittwoch, den 15.06.2016, 10:48 -0500 schrieb Andrew F. Davis: >>> On 06/01/2016 01:41 PM, Andrew F. Davis wrote: Some SoCs contain reset controls for modules that

[PATCH] memcg: mem_cgroup_migrate() may be called with irq disabled

Hello, Christian, I *think* this should fix it. Can you please verify? Thanks! -- 8< -- mem_cgroup_migrate() uses local_irq_disable/enable() but can be called with irq disabled from migrate_page_copy(). This ends up enabling irq while holding a irq context lock triggering the following

[PATCH] memcg: mem_cgroup_migrate() may be called with irq disabled

Hello, Christian, I *think* this should fix it. Can you please verify? Thanks! -- 8< -- mem_cgroup_migrate() uses local_irq_disable/enable() but can be called with irq disabled from migrate_page_copy(). This ends up enabling irq while holding a irq context lock triggering the following

Re: [PATCH v2 2/2] pci: host: new driver for Axis ARTPEC-6 PCIe controller

On Mon, Jun 20, 2016 at 02:56:58AM +0200, Niklas Cassel wrote: > > On 06/13/2016 03:33 PM, Bjorn Helgaas wrote: > > On Mon, Jun 13, 2016 at 03:12:13PM +0200, Niklas Cassel wrote: > >> On 06/10/2016 12:41 AM, Bjorn Helgaas wrote: > >>> On Mon, May 09, 2016 at 01:49:03PM +0200, Niklas Cassel wrote:

Re: [PATCH v2 2/2] pci: host: new driver for Axis ARTPEC-6 PCIe controller

On Mon, Jun 20, 2016 at 02:56:58AM +0200, Niklas Cassel wrote: > > On 06/13/2016 03:33 PM, Bjorn Helgaas wrote: > > On Mon, Jun 13, 2016 at 03:12:13PM +0200, Niklas Cassel wrote: > >> On 06/10/2016 12:41 AM, Bjorn Helgaas wrote: > >>> On Mon, May 09, 2016 at 01:49:03PM +0200, Niklas Cassel wrote:

Re: [PATCH 2/2] dt-bindings: qcom: Add MDM9615 bindings

On Fri, Jun 17, 2016 at 12:35:04PM +0200, Neil Armstrong wrote: > Signed-off-by: Neil Armstrong > --- > Documentation/devicetree/bindings/arm/qcom.txt | 1 + > 1 file changed, 1 insertion(+) Acked-by: Rob Herring

Re: [PATCH 2/2] dt-bindings: qcom: Add MDM9615 bindings

On Fri, Jun 17, 2016 at 12:35:04PM +0200, Neil Armstrong wrote: > Signed-off-by: Neil Armstrong > --- > Documentation/devicetree/bindings/arm/qcom.txt | 1 + > 1 file changed, 1 insertion(+) Acked-by: Rob Herring

Re: ktime_get_ts64() splat during resume

On Mon, Jun 20, 2016 at 7:38 AM, Rafael J. Wysocki wrote: > > Overall, we seem to be heading towards the "really weird" territory here. So the whole commit that Boris bisected down to is weird to me. Why isn't the temporary text mapping just set up unconditionally in the

Re: ktime_get_ts64() splat during resume

On Mon, Jun 20, 2016 at 7:38 AM, Rafael J. Wysocki wrote: > > Overall, we seem to be heading towards the "really weird" territory here. So the whole commit that Boris bisected down to is weird to me. Why isn't the temporary text mapping just set up unconditionally in the temp_level4_pgt? Why

[PATCH v4 2/2] reset: add TI SYSCON based reset driver

Add a reset-controller driver for performing reset management of various devices present on the SoC, with the reset registers shared between devices in a common register memory space. This driver uses the syscon/regmap frameworks to actually implement the various reset functionalities needed by

[PATCH v4 2/2] reset: add TI SYSCON based reset driver

Add a reset-controller driver for performing reset management of various devices present on the SoC, with the reset registers shared between devices in a common register memory space. This driver uses the syscon/regmap frameworks to actually implement the various reset functionalities needed by

[PATCH v4 1/2] Documentation: dt: reset: Add TI syscon reset binding

Add TI syscon reset controller binding. This will hook to the reset framework and use syscon/regmap to set reset bits. This allows reset control of individual SoC subsytems and devices with memory-mapped reset registers in a common register memory space. Signed-off-by: Andrew F. Davis

[PATCH v4 1/2] Documentation: dt: reset: Add TI syscon reset binding

Add TI syscon reset controller binding. This will hook to the reset framework and use syscon/regmap to set reset bits. This allows reset control of individual SoC subsytems and devices with memory-mapped reset registers in a common register memory space. Signed-off-by: Andrew F. Davis

Re: [PATCH 2/4] sched/fair: Introduce idle enter/exit balance callbacks

On Mon, Jun 20, 2016 at 02:15:12PM +0200, Jiri Olsa wrote: > Introducing idle enter/exit balance callbacks to keep > balance.idle_cpus_mask cpumask of current idle cpus > in system. > > It's used only when REBALANCE_AFFINITY feature is > switched on. The code functionality of this feature > is

Re: [PATCH 2/4] sched/fair: Introduce idle enter/exit balance callbacks

On Mon, Jun 20, 2016 at 02:15:12PM +0200, Jiri Olsa wrote: > Introducing idle enter/exit balance callbacks to keep > balance.idle_cpus_mask cpumask of current idle cpus > in system. > > It's used only when REBALANCE_AFFINITY feature is > switched on. The code functionality of this feature > is

Re: [PATCH v4 net-next v4 14/14] net: dsa: mv88e6xxx: abstract switch registers accesses

Hi, [auto build test WARNING on net-next/master] url: https://github.com/0day-ci/linux/commits/Vivien-Didelot/net-dsa-mv88e6xxx-probe-compatible/20160621-020115 config: m68k-allyesconfig (attached as .config) compiler: m68k-linux-gcc (GCC) 4.9.0 reproduce: wget

Re: [PATCH] torture: use ktime_t consistently

On Mon, Jun 20, 2016 at 08:29:48PM +0200, Arnd Bergmann wrote: > On Monday, June 20, 2016 11:21:05 AM CEST Paul E. McKenney wrote: > > On Mon, Jun 20, 2016 at 05:56:40PM +0200, Arnd Bergmann wrote: > > > > @@ -446,9 +447,9 @@ EXPORT_SYMBOL_GPL(torture_shuffle_cleanup); > > * Variables for

Re: [PATCH v4 net-next v4 14/14] net: dsa: mv88e6xxx: abstract switch registers accesses

Hi, [auto build test WARNING on net-next/master] url: https://github.com/0day-ci/linux/commits/Vivien-Didelot/net-dsa-mv88e6xxx-probe-compatible/20160621-020115 config: m68k-allyesconfig (attached as .config) compiler: m68k-linux-gcc (GCC) 4.9.0 reproduce: wget

Re: [PATCH] torture: use ktime_t consistently

On Mon, Jun 20, 2016 at 08:29:48PM +0200, Arnd Bergmann wrote: > On Monday, June 20, 2016 11:21:05 AM CEST Paul E. McKenney wrote: > > On Mon, Jun 20, 2016 at 05:56:40PM +0200, Arnd Bergmann wrote: > > > > @@ -446,9 +447,9 @@ EXPORT_SYMBOL_GPL(torture_shuffle_cleanup); > > * Variables for

[PATCH v4 4/4] Add the extra_latent_entropy kernel parameter

When extra_latent_entropy is passed on the kernel command line, entropy will be extracted from up to the first 4GB of RAM while the runtime memory allocator is being initialized. Based on work created by the PaX Team. Signed-off-by: Emese Revfy ---

[PATCH v4 4/4] Add the extra_latent_entropy kernel parameter

When extra_latent_entropy is passed on the kernel command line, entropy will be extracted from up to the first 4GB of RAM while the runtime memory allocator is being initialized. Based on work created by the PaX Team. Signed-off-by: Emese Revfy --- Documentation/kernel-parameters.txt | 5

[PATCH v4 3/4] Mark functions with the latent_entropy attribute

The latent_entropy gcc attribute can be only on functions and variables. If it is on a function then the plugin will instrument it. If the attribute is on a variable then the plugin will initialize it with a random value. The variable must be an integer, an integer array type or a structure with

Re: [PATCH] ARM: sun8i: Add Parrot Board DTS

On Tue, Jun 21, 2016 at 12:30:25AM +0800, Chen-Yu Tsai wrote: > >> >>> +_aldo1 { > >> >>> + regulator-always-on; > >> >>> + regulator-min-microvolt = <300>; > >> >>> + regulator-max-microvolt = <300>; > >> >>> + regulator-name = "aldo1"; > >> >> > >> >> What is this

[PATCH v4 3/4] Mark functions with the latent_entropy attribute

The latent_entropy gcc attribute can be only on functions and variables. If it is on a function then the plugin will instrument it. If the attribute is on a variable then the plugin will initialize it with a random value. The variable must be an integer, an integer array type or a structure with

Re: [PATCH] ARM: sun8i: Add Parrot Board DTS

On Tue, Jun 21, 2016 at 12:30:25AM +0800, Chen-Yu Tsai wrote: > >> >>> +_aldo1 { > >> >>> + regulator-always-on; > >> >>> + regulator-min-microvolt = <300>; > >> >>> + regulator-max-microvolt = <300>; > >> >>> + regulator-name = "aldo1"; > >> >> > >> >> What is this

[PATCH v4 2/4] Add the latent_entropy gcc plugin

This plugin mitigates the problem of the kernel having too little entropy during and after boot for generating crypto keys. It creates a local variable in every marked function. The value of this variable is modified by randomly chosen operations (add, xor and rol) and random values (gcc

[PATCH v4 2/4] Add the latent_entropy gcc plugin

This plugin mitigates the problem of the kernel having too little entropy during and after boot for generating crypto keys. It creates a local variable in every marked function. The value of this variable is modified by randomly chosen operations (add, xor and rol) and random values (gcc

Re: [PATCH] torture: use ktime_t consistently

On Monday, June 20, 2016 11:21:05 AM CEST Paul E. McKenney wrote: > On Mon, Jun 20, 2016 at 05:56:40PM +0200, Arnd Bergmann wrote: > > @@ -446,9 +447,9 @@ EXPORT_SYMBOL_GPL(torture_shuffle_cleanup); > * Variables for auto-shutdown. This allows "lights out" torture runs > * to be fully

Re: [PATCH] torture: use ktime_t consistently

On Monday, June 20, 2016 11:21:05 AM CEST Paul E. McKenney wrote: > On Mon, Jun 20, 2016 at 05:56:40PM +0200, Arnd Bergmann wrote: > > @@ -446,9 +447,9 @@ EXPORT_SYMBOL_GPL(torture_shuffle_cleanup); > * Variables for auto-shutdown. This allows "lights out" torture runs > * to be fully

Re: [PATCH v4 net-next v4 14/14] net: dsa: mv88e6xxx: abstract switch registers accesses

Hi, [auto build test WARNING on net-next/master] url: https://github.com/0day-ci/linux/commits/Vivien-Didelot/net-dsa-mv88e6xxx-probe-compatible/20160621-020115 config: sparc64-allyesconfig (attached as .config) compiler: sparc64-linux-gnu-gcc (Debian 5.3.1-8) 5.3.1 20160205 reproduce:

Re: [PATCH v4 net-next v4 14/14] net: dsa: mv88e6xxx: abstract switch registers accesses

Hi, [auto build test WARNING on net-next/master] url: https://github.com/0day-ci/linux/commits/Vivien-Didelot/net-dsa-mv88e6xxx-probe-compatible/20160621-020115 config: sparc64-allyesconfig (attached as .config) compiler: sparc64-linux-gnu-gcc (Debian 5.3.1-8) 5.3.1 20160205 reproduce:

[PATCH v4 1/4] Add support for passing gcc plugin arguments

Signed-off-by: Emese Revfy --- scripts/Makefile.gcc-plugins | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/scripts/Makefile.gcc-plugins b/scripts/Makefile.gcc-plugins index 5e22b60..da7f86c 100644 --- a/scripts/Makefile.gcc-plugins +++

[PATCH v4 1/4] Add support for passing gcc plugin arguments

Signed-off-by: Emese Revfy --- scripts/Makefile.gcc-plugins | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/scripts/Makefile.gcc-plugins b/scripts/Makefile.gcc-plugins index 5e22b60..da7f86c 100644 --- a/scripts/Makefile.gcc-plugins +++ b/scripts/Makefile.gcc-plugins @@

[PATCH v3 04/15] phy: rockchip-emmc: reindent the register definitions

From: Brian Norris 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 Signed-off-by: Douglas Anderson

[PATCH v3 04/15] phy: rockchip-emmc: reindent the register definitions

From: Brian Norris 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 Signed-off-by: Douglas Anderson Acked-by: Kishon Vijay Abraham I Reviewed-by: Heiko

[PATCH v4 0/4] Introduce the latent_entropy gcc plugin

I would like to introduce the latent_entropy gcc plugin. This plugin mitigates the problem of the kernel having too little entropy during and after boot for generating crypto keys. This plugin mixes random values into the latent_entropy global variable in functions marked by the __latent_entropy

Re: [PATCH v4 0/5] /dev/random - a new approach

Am Montag, 20. Juni 2016, 13:07:32 schrieb Austin S. Hemmelgarn: Hi Austin, > On 2016-06-18 12:31, Stephan Mueller wrote: > > Am Samstag, 18. Juni 2016, 10:44:08 schrieb Theodore Ts'o: > > > > Hi Theodore, > > > >> At the end of the day, with these devices you really badly need a > >> hardware

[PATCH v4 0/4] Introduce the latent_entropy gcc plugin

I would like to introduce the latent_entropy gcc plugin. This plugin mitigates the problem of the kernel having too little entropy during and after boot for generating crypto keys. This plugin mixes random values into the latent_entropy global variable in functions marked by the __latent_entropy

Re: [PATCH v4 0/5] /dev/random - a new approach

Am Montag, 20. Juni 2016, 13:07:32 schrieb Austin S. Hemmelgarn: Hi Austin, > On 2016-06-18 12:31, Stephan Mueller wrote: > > Am Samstag, 18. Juni 2016, 10:44:08 schrieb Theodore Ts'o: > > > > Hi Theodore, > > > >> At the end of the day, with these devices you really badly need a > >> hardware

[PATCH v3 10/15] Documentation: mmc: sdhci-of-arasan: Add ability to export card clock

Some SD/eMMC PHYs (like the PHY from Arasan that is designed to work with arasan,sdhci-5.1) need to know the card clock frequency in order to function properly. Physically in a SoC this clock is exported from the SDHCI IP block to the PHY IP block and the PHY needs to know the speed. Let's export

[PATCH v3 10/15] Documentation: mmc: sdhci-of-arasan: Add ability to export card clock

Some SD/eMMC PHYs (like the PHY from Arasan that is designed to work with arasan,sdhci-5.1) need to know the card clock frequency in order to function properly. Physically in a SoC this clock is exported from the SDHCI IP block to the PHY IP block and the PHY needs to know the speed. Let's export

[PATCH v3 01/15] phy: rockchip-emmc: give DLL some extra time to be ready

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 -ETIMEDOUT issues. Signed-off-by: Shawn Lin

[PATCH v3 01/15] phy: rockchip-emmc: give DLL some extra time to be ready

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 -ETIMEDOUT issues. Signed-off-by: Shawn Lin Signed-off-by: Brian

[PATCH v3 02/15] phy: rockchip-emmc: configure frequency range and drive impedance

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

[PATCH v3 02/15] phy: rockchip-emmc: configure frequency range and drive impedance

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 Signed-off-by: Douglas Anderson Acked-by: Kishon Vijay Abraham I Tested-by: Heiko

[PATCH v3 13/15] phy: rockchip-emmc: Minor code cleanup in rockchip_emmc_phy_power_on/off()

There's no reason to store the return value of rockchip_emmc_phy_power() in a variable nor to check it. Just return it. Signed-off-by: Douglas Anderson Acked-by: Kishon Vijay Abraham I Reviewed-by: Shawn Lin Tested-by: Heiko

[PATCH v3 13/15] phy: rockchip-emmc: Minor code cleanup in rockchip_emmc_phy_power_on/off()

There's no reason to store the return value of rockchip_emmc_phy_power() in a variable nor to check it. Just return it. Signed-off-by: Douglas Anderson Acked-by: Kishon Vijay Abraham I Reviewed-by: Shawn Lin Tested-by: Heiko Stuebner --- Changes in v3: - Add collected tags Changes in v2: -

Re: [PATCH v4 net-next v4 14/14] net: dsa: mv88e6xxx: abstract switch registers accesses

Hi, [auto build test WARNING on net-next/master] url: https://github.com/0day-ci/linux/commits/Vivien-Didelot/net-dsa-mv88e6xxx-probe-compatible/20160621-020115 config: tile-allyesconfig (attached as .config) compiler: tilegx-linux-gcc (GCC) 4.6.2 reproduce: wget

Re: [PATCH v4 net-next v4 14/14] net: dsa: mv88e6xxx: abstract switch registers accesses

Hi, [auto build test WARNING on net-next/master] url: https://github.com/0day-ci/linux/commits/Vivien-Didelot/net-dsa-mv88e6xxx-probe-compatible/20160621-020115 config: tile-allyesconfig (attached as .config) compiler: tilegx-linux-gcc (GCC) 4.6.2 reproduce: wget

<    4   5   6   7   8   9   10   11   12   13   >