On 11/24/2016 01:07 AM, Jason Gunthorpe wrote:
On Wed, Nov 23, 2016 at 12:27:36PM -0500, Nayna Jain wrote:
sizep = of_get_property(np, "linux,sml-size", NULL);
+ if (of_property_match_string(np, "compatible", "IBM,vtpm") < 0)
+ log_size = be32_to_cpup(sizep);
+
On 11/24/2016 01:07 AM, Jason Gunthorpe wrote:
On Wed, Nov 23, 2016 at 12:27:36PM -0500, Nayna Jain wrote:
sizep = of_get_property(np, "linux,sml-size", NULL);
+ if (of_property_match_string(np, "compatible", "IBM,vtpm") < 0)
+ log_size = be32_to_cpup(sizep);
+
On Thu, 24 Nov 2016 08:36:39 +0100
Greg Kroah-Hartman wrote:
> On Thu, Nov 24, 2016 at 06:20:26PM +1100, Nicholas Piggin wrote:
> > But still, modversions is pretty complicated for what it gives us. It sends
> > preprocessed C into a C parser that makes CRCs using
On Thu 24-11-16 08:41:30, Vlastimil Babka wrote:
> On 11/23/2016 01:35 PM, Michal Hocko wrote:
> > On Wed 23-11-16 13:19:20, Vlastimil Babka wrote:
[...]
> > > > static inline struct page *
> > > > +__alloc_pages_nowmark(gfp_t gfp_mask, unsigned int order,
> > > > +
On Thu, 24 Nov 2016 08:36:39 +0100
Greg Kroah-Hartman wrote:
> On Thu, Nov 24, 2016 at 06:20:26PM +1100, Nicholas Piggin wrote:
> > But still, modversions is pretty complicated for what it gives us. It sends
> > preprocessed C into a C parser that makes CRCs using type definitions of
> >
On Thu 24-11-16 08:41:30, Vlastimil Babka wrote:
> On 11/23/2016 01:35 PM, Michal Hocko wrote:
> > On Wed 23-11-16 13:19:20, Vlastimil Babka wrote:
[...]
> > > > static inline struct page *
> > > > +__alloc_pages_nowmark(gfp_t gfp_mask, unsigned int order,
> > > > +
Hi!
> > "ifconfig hw ether XX" normally sets the address. I guess that's
> > ioctl?
>
> This sets temporary address and it is ioctl. IIRC same as what ethtool
> uses. (ifconfig is already deprecated).
>
> > And I guess we should use similar mechanism for permanent
> > address.
>
> I'm not
Hi!
> > "ifconfig hw ether XX" normally sets the address. I guess that's
> > ioctl?
>
> This sets temporary address and it is ioctl. IIRC same as what ethtool
> uses. (ifconfig is already deprecated).
>
> > And I guess we should use similar mechanism for permanent
> > address.
>
> I'm not
The device that creates OPP table first should be removed from dev_list
of OPP table in last because it can be used by other resources
(supported_hw, prop_name, regulator), but not now. If OPP table is
shared by several CPUs, the CPU device that creates OPP table can be
removed earlier than other
The device that creates OPP table first should be removed from dev_list
of OPP table in last because it can be used by other resources
(supported_hw, prop_name, regulator), but not now. If OPP table is
shared by several CPUs, the CPU device that creates OPP table can be
removed earlier than other
On 三, 11月 23, 2016 at 04:38:33下午 -0800, Stephen Boyd wrote:
> On 11/12, Xiaolong Zhang wrote:
> > On 二, 10月 25, 2016 at 08:40:08下午 +, Stephen Boyd wrote:
> > > On 10/22, Xiaolong Zhang wrote:
> > > > On 四, 10月 20, 2016 at 04:01:03下午 -0700, Stephen Boyd wrote:
> > > > > On 10/11, Orson Zhai
On 三, 11月 23, 2016 at 04:38:33下午 -0800, Stephen Boyd wrote:
> On 11/12, Xiaolong Zhang wrote:
> > On 二, 10月 25, 2016 at 08:40:08下午 +, Stephen Boyd wrote:
> > > On 10/22, Xiaolong Zhang wrote:
> > > > On 四, 10月 20, 2016 at 04:01:03下午 -0700, Stephen Boyd wrote:
> > > > > On 10/11, Orson Zhai
On Thu, Nov 24, 2016 at 08:26:39AM +0100, Vlastimil Babka wrote:
> On 11/23/2016 05:33 PM, Mel Gorman wrote:
> > > > +
> > > > +static inline unsigned int pindex_to_order(unsigned int pindex)
> > > > +{
> > > > + return pindex < MIGRATE_PCPTYPES ? 0 : pindex -
> > > > MIGRATE_PCPTYPES + 1;
On Thu, Nov 24, 2016 at 08:26:39AM +0100, Vlastimil Babka wrote:
> On 11/23/2016 05:33 PM, Mel Gorman wrote:
> > > > +
> > > > +static inline unsigned int pindex_to_order(unsigned int pindex)
> > > > +{
> > > > + return pindex < MIGRATE_PCPTYPES ? 0 : pindex -
> > > > MIGRATE_PCPTYPES + 1;
On 11/23/2016 01:35 PM, Michal Hocko wrote:
On Wed 23-11-16 13:19:20, Vlastimil Babka wrote:
This makes some sense to me, but there might be unpleasant consequences,
e.g. due to allowing costly allocations without reserves.
I am not sure I understand. Did you mean with reserves? Anyway, my
On 11/23/2016 01:35 PM, Michal Hocko wrote:
On Wed 23-11-16 13:19:20, Vlastimil Babka wrote:
This makes some sense to me, but there might be unpleasant consequences,
e.g. due to allowing costly allocations without reserves.
I am not sure I understand. Did you mean with reserves? Anyway, my
On Thu, Nov 24, 2016 at 06:20:26PM +1100, Nicholas Piggin wrote:
> But still, modversions is pretty complicated for what it gives us. It sends
> preprocessed C into a C parser that makes CRCs using type definitions of
> exported symbols, then turns those CRCs into a linker script which which is
>
On Thu, Nov 24, 2016 at 06:20:26PM +1100, Nicholas Piggin wrote:
> But still, modversions is pretty complicated for what it gives us. It sends
> preprocessed C into a C parser that makes CRCs using type definitions of
> exported symbols, then turns those CRCs into a linker script which which is
>
Hi Chanwoo Choi,
I think the dev_pm_opp_get_suspend_opp() have implement most of
the funtion, all we need is just define the node in dts, like following:
_opp_table {
opp06 {
opp-suspend;
};
};
so i think my way semm more simple.
On 2016年11月24日 15:10, Chanwoo Choi wrote:
Hi Chanwoo Choi,
I think the dev_pm_opp_get_suspend_opp() have implement most of
the funtion, all we need is just define the node in dts, like following:
_opp_table {
opp06 {
opp-suspend;
};
};
so i think my way semm more simple.
On 2016年11月24日 15:10, Chanwoo Choi wrote:
Andreas Dilger wrote:
> > + case S_IFCHR: printf(" character special file\n");ft =
> > 'c'; break;
>
> This will overflow 80 columns. Could use just "character special"?
>
> > + case S_IFDIR: printf(" directory\n"); ft =
> >
Andreas Dilger wrote:
> > + case S_IFCHR: printf(" character special file\n");ft =
> > 'c'; break;
>
> This will overflow 80 columns. Could use just "character special"?
>
> > + case S_IFDIR: printf(" directory\n"); ft =
> > 'd'; break;
> > +
On 11/23/2016 05:33 PM, Mel Gorman wrote:
+
+static inline unsigned int pindex_to_order(unsigned int pindex)
+{
+ return pindex < MIGRATE_PCPTYPES ? 0 : pindex - MIGRATE_PCPTYPES + 1;
+}
+
+static inline unsigned int order_to_pindex(int migratetype, unsigned int order)
+{
+ return
On 11/23/2016 05:33 PM, Mel Gorman wrote:
+
+static inline unsigned int pindex_to_order(unsigned int pindex)
+{
+ return pindex < MIGRATE_PCPTYPES ? 0 : pindex - MIGRATE_PCPTYPES + 1;
+}
+
+static inline unsigned int order_to_pindex(int migratetype, unsigned int order)
+{
+ return
On Thu, 24 Nov 2016 07:00:50 +0100
Ingo Molnar wrote:
> * Nicholas Piggin wrote:
>
> > > scripts/Makefile.build | 78
> > > --
> > > 1 file changed, 72 insertions(+), 6
On Thu, 24 Nov 2016 07:00:50 +0100
Ingo Molnar wrote:
> * Nicholas Piggin wrote:
>
> > > scripts/Makefile.build | 78
> > > --
> > > 1 file changed, 72 insertions(+), 6 deletions(-)
> > >
> > > It was applied 4
On Tuesday 22 November 2016 11:25 PM, Thierry Reding wrote:
+static inline struct tegra_gpio *to_tegra_gpio(struct gpio_chip *chip)
+{
+ return container_of(chip, struct tegra_gpio, gpio);
+}
You dont need this as gpiochip_get_data(chip); can provide the required
driver specific data.
On Tuesday 22 November 2016 11:25 PM, Thierry Reding wrote:
+static inline struct tegra_gpio *to_tegra_gpio(struct gpio_chip *chip)
+{
+ return container_of(chip, struct tegra_gpio, gpio);
+}
You dont need this as gpiochip_get_data(chip); can provide the required
driver specific data.
+ Tobias Jakobi,
Hi Lin,
We need to discuss how to support the suspend-opp of devfreq device.
Now, there are two patch thread for suspend-opp of devfreq.
The Lin's approach modify the devfreq_suspend_device() to support suspend-opp.
The Tobias's approach[1] add new devfreq_suspend() and then
+ Tobias Jakobi,
Hi Lin,
We need to discuss how to support the suspend-opp of devfreq device.
Now, there are two patch thread for suspend-opp of devfreq.
The Lin's approach modify the devfreq_suspend_device() to support suspend-opp.
The Tobias's approach[1] add new devfreq_suspend() and then
On Thursday 24 November 2016 01:10 AM, Thierry Reding wrote:
* PGP Signed by an unknown key
On Wed, Nov 23, 2016 at 02:25:51PM +0100, Linus Walleij wrote:
This is already possible and several drivers are doing this.
Everything, all kernel users and all character device users, end up
calling
On Thursday 24 November 2016 01:10 AM, Thierry Reding wrote:
* PGP Signed by an unknown key
On Wed, Nov 23, 2016 at 02:25:51PM +0100, Linus Walleij wrote:
This is already possible and several drivers are doing this.
Everything, all kernel users and all character device users, end up
calling
On 11/22/2016 09:55 PM, Zi Yan wrote:
> From: Zi Yan
>
> From: Zi Yan
There are multiple "from" for this patch, should be fixed to reflect
just one of them.
>
> migrate_page_copy() and copy_huge_page() are affected.
In this patch you are just
On 11/22/2016 09:55 PM, Zi Yan wrote:
> From: Zi Yan
>
> From: Zi Yan
There are multiple "from" for this patch, should be fixed to reflect
just one of them.
>
> migrate_page_copy() and copy_huge_page() are affected.
In this patch you are just expanding the arguments of both of these
Now that we disable the display engine by default, we need to re-enable
it for the Hummingbird A31, which already had its display pipeline
enabled.
Signed-off-by: Chen-Yu Tsai
---
arch/arm/boot/dts/sun6i-a31-hummingbird.dts | 4
1 file changed, 4 insertions(+)
diff --git
Now that we disable the display engine by default, we need to re-enable
it for the Hummingbird A31, which already had its display pipeline
enabled.
Signed-off-by: Chen-Yu Tsai
---
arch/arm/boot/dts/sun6i-a31-hummingbird.dts | 4
1 file changed, 4 insertions(+)
diff --git
While we now support the internal display pipeline found on sun6i, it
is possible that we are unable to enable the display for some boards,
due to a lack of drivers for the panels or bridges found on them. If
the display pipeline is enabled, the driver will try to enable, and
possibly screw up the
Hi,
While we now support the internal display pipeline found on sun6i, it
is possible that we are unable to enable the display for some boards,
due to a lack of drivers for the panels or bridges found on them. If
the display pipeline is enabled, the driver will try to enable, and
possibly screw
While we now support the internal display pipeline found on sun6i, it
is possible that we are unable to enable the display for some boards,
due to a lack of drivers for the panels or bridges found on them. If
the display pipeline is enabled, the driver will try to enable, and
possibly screw up the
Hi,
While we now support the internal display pipeline found on sun6i, it
is possible that we are unable to enable the display for some boards,
due to a lack of drivers for the panels or bridges found on them. If
the display pipeline is enabled, the driver will try to enable, and
possibly screw
On Wed, Nov 23, 2016 at 10:13:02AM -0700, Mathieu Poirier wrote:
> On Wed, Nov 23, 2016 at 11:01:03AM +0100, Sascha Hauer wrote:
> > With this patch the serial core provides LED triggers for RX and TX.
> >
> > As the serial core layer does not know when the hardware actually sends
> > or receives
On Wed, Nov 23, 2016 at 10:13:02AM -0700, Mathieu Poirier wrote:
> On Wed, Nov 23, 2016 at 11:01:03AM +0100, Sascha Hauer wrote:
> > With this patch the serial core provides LED triggers for RX and TX.
> >
> > As the serial core layer does not know when the hardware actually sends
> > or receives
> https://github.com/0day-ci/linux/commits/Zi-Yan/Parallel-hugepage-migration-optimization/20161123-022913
> reproduce:
> # apt-get install sparse
> make ARCH=x86_64 allmodconfig
> make C=1 CF=-D__CHECK_ENDIAN__
>
>
> sparse warnings: (new ones
> https://github.com/0day-ci/linux/commits/Zi-Yan/Parallel-hugepage-migration-optimization/20161123-022913
> reproduce:
> # apt-get install sparse
> make ARCH=x86_64 allmodconfig
> make C=1 CF=-D__CHECK_ENDIAN__
>
>
> sparse warnings: (new ones
On Wed, Nov 23, 2016 at 8:30 AM, Laurent Pinchart
wrote:
> Hi Matt,
>
> Thank you for the patch.
>
> On Tuesday 22 Nov 2016 17:18:40 Matt Ranostay wrote:
>> There are several thermal sensors that only have a low-speed bus
>> interface but output valid video
On Wed, Nov 23, 2016 at 8:30 AM, Laurent Pinchart
wrote:
> Hi Matt,
>
> Thank you for the patch.
>
> On Tuesday 22 Nov 2016 17:18:40 Matt Ranostay wrote:
>> There are several thermal sensors that only have a low-speed bus
>> interface but output valid video data. This patchset enables support
>>
Hi David,
On Wed, Nov 23, 2016 at 10:13:46PM -0500, David Ahern wrote:
> On 11/23/16 8:11 PM, Namhyung Kim wrote:
> > The sched_switch event always captured from the scheduler function. So
> > it'd be great omit them from the callchain. This patch marks the
> > functions to be omitted by later
Hi David,
On Wed, Nov 23, 2016 at 10:13:46PM -0500, David Ahern wrote:
> On 11/23/16 8:11 PM, Namhyung Kim wrote:
> > The sched_switch event always captured from the scheduler function. So
> > it'd be great omit them from the callchain. This patch marks the
> > functions to be omitted by later
Commit-ID: c4597fd756836a5fb7900f2091797ab564390ad0
Gitweb: http://git.kernel.org/tip/c4597fd756836a5fb7900f2091797ab564390ad0
Author: Dan Carpenter
AuthorDate: Thu, 24 Nov 2016 01:19:08 +0300
Committer: Ingo Molnar
CommitDate: Thu, 24 Nov
Commit-ID: c4597fd756836a5fb7900f2091797ab564390ad0
Gitweb: http://git.kernel.org/tip/c4597fd756836a5fb7900f2091797ab564390ad0
Author: Dan Carpenter
AuthorDate: Thu, 24 Nov 2016 01:19:08 +0300
Committer: Ingo Molnar
CommitDate: Thu, 24 Nov 2016 06:01:05 +0100
x86/apic/uv: Silence a
Commit-ID: 83929cce95251cc77e5659bf493bd424ae0e7a67
Gitweb: http://git.kernel.org/tip/83929cce95251cc77e5659bf493bd424ae0e7a67
Author: Mike Galbraith
AuthorDate: Wed, 23 Nov 2016 11:33:37 +0100
Committer: Ingo Molnar
CommitDate: Thu, 24 Nov 2016
Commit-ID: 83929cce95251cc77e5659bf493bd424ae0e7a67
Gitweb: http://git.kernel.org/tip/83929cce95251cc77e5659bf493bd424ae0e7a67
Author: Mike Galbraith
AuthorDate: Wed, 23 Nov 2016 11:33:37 +0100
Committer: Ingo Molnar
CommitDate: Thu, 24 Nov 2016 05:45:02 +0100
sched/autogroup: Fix
* Viresh Kumar wrote:
> > * Viresh Kumar wrote:
> >
> > > Execute the irq-work specific initialization/exit code only when the
> > > fast path isn't available.
> >
> > Is this an optimization? A correctness fix?
>
> Its an optimization but
* Viresh Kumar wrote:
> > * Viresh Kumar wrote:
> >
> > > Execute the irq-work specific initialization/exit code only when the
> > > fast path isn't available.
> >
> > Is this an optimization? A correctness fix?
>
> Its an optimization but yeah I will try to explain a bit more next time.
From: Grygorii Strashko
Now ARM Global timer (rating 300) will not be selected as clocksource,
because it's initialized after OMAP GP Timer (rating 300) and
Timekeeping core will not allow to replace clocksource with new one if
both of them have the same rating.
Reduce
From: Grygorii Strashko
The commit 55ee7017ee31 ("arm: omap2: board-generic: use
omap4_local_timer_init for AM437x") unintentionally changes the
clocksource devices for AM437x from OMAP GP Timer to SyncTimer32K.
Unfortunately, the SyncTimer32K is starving from
From: Grygorii Strashko
Now ARM Global timer (rating 300) will not be selected as clocksource,
because it's initialized after OMAP GP Timer (rating 300) and
Timekeeping core will not allow to replace clocksource with new one if
both of them have the same rating.
Reduce rating of OMAP GP Timer
From: Grygorii Strashko
The commit 55ee7017ee31 ("arm: omap2: board-generic: use
omap4_local_timer_init for AM437x") unintentionally changes the
clocksource devices for AM437x from OMAP GP Timer to SyncTimer32K.
Unfortunately, the SyncTimer32K is starving from frequency deviation
as mentioned
On Thu, Nov 24, 2016 at 11:18 AM, hl wrote:
> Hi MyungJoo Ham,
[]
>>
>> We still need to sync the all status even i call target() in
>> devfreq_suspend/resume_device
>> directly, so still need update_devfreq() other setp except
>> devfreq->governor->get_target_freq(devfreq,
On Thu, Nov 24, 2016 at 11:18 AM, hl wrote:
> Hi MyungJoo Ham,
[]
>>
>> We still need to sync the all status even i call target() in
>> devfreq_suspend/resume_device
>> directly, so still need update_devfreq() other setp except
>> devfreq->governor->get_target_freq(devfreq, );
>
> And i think it
On 24-11-16, 05:53, Ingo Molnar wrote:
>
> Firstly, please start changes to scheduler code with a verb. This title:
>
> Subject: Re: [PATCH V2 4/4] cpufreq: schedutil: irq-work and mutex are only
> used in slow path
>
> is totally inadequate as it's a statement that says nothing about the
>
On 24-11-16, 05:53, Ingo Molnar wrote:
>
> Firstly, please start changes to scheduler code with a verb. This title:
>
> Subject: Re: [PATCH V2 4/4] cpufreq: schedutil: irq-work and mutex are only
> used in slow path
>
> is totally inadequate as it's a statement that says nothing about the
>
Hi,
On top of previous pull/tag.
Best regards,
Krzysztof
The following changes since commit 8ac46fc57df82efbc19194335b6c7a960c31:
arm64: dts: exynos: Add dts file for Exynos5433-based TM2E board (2016-11-03
22:19:57 +0200)
are available in the git repository at:
Hi,
On top of previous pull/tag.
Best regards,
Krzysztof
The following changes since commit 8ac46fc57df82efbc19194335b6c7a960c31:
arm64: dts: exynos: Add dts file for Exynos5433-based TM2E board (2016-11-03
22:19:57 +0200)
are available in the git repository at:
Hi,
This contains previous dts branch because SCU node in dts is needed
prior to removing it from mach code.
Below you will find full pull request and one stripped from dependency.
Best regards,
Krzysztof
The following changes since commit 1001354ca34179f3db924eb66672442a173147dc:
Linux
Hi,
On top of previous pull/tag.
Possible trivial conflict:
--- a/arch/arm/boot/dts/exynos5440.dtsi
+++ b/arch/arm/boot/dts/exynos5440.dtsi
@@@ -197,10 -188,10 +197,10 @@@
};
gmac: ethernet@0023 {
- compatible = "snps,dwmac-3.70a";
+ compatible
Hi,
Second, probably last round of patches for v4.10.
Best regards,
Krzysztof
Hi,
This contains previous dts branch because SCU node in dts is needed
prior to removing it from mach code.
Below you will find full pull request and one stripped from dependency.
Best regards,
Krzysztof
The following changes since commit 1001354ca34179f3db924eb66672442a173147dc:
Linux
Hi,
On top of previous pull/tag.
Possible trivial conflict:
--- a/arch/arm/boot/dts/exynos5440.dtsi
+++ b/arch/arm/boot/dts/exynos5440.dtsi
@@@ -197,10 -188,10 +197,10 @@@
};
gmac: ethernet@0023 {
- compatible = "snps,dwmac-3.70a";
+ compatible
Hi,
Second, probably last round of patches for v4.10.
Best regards,
Krzysztof
Add more data to 64bit SoCs for the cpufreq support.
Signed-off-by: Masahiro Yamada
---
Changes in v2:
- Drop clock data of 32 bit SoCs. Add 64 bit SoC data for now.
drivers/clk/uniphier/clk-uniphier-sys.c | 32
The struct member name of a union is unneeded. This makes the code
a bit shorter.
Signed-off-by: Masahiro Yamada
---
Changes in v2:
- Newly added
drivers/clk/uniphier/clk-uniphier-core.c | 8
drivers/clk/uniphier/clk-uniphier-mio.c | 2 +-
Add more data to 64bit SoCs for the cpufreq support.
Signed-off-by: Masahiro Yamada
---
Changes in v2:
- Drop clock data of 32 bit SoCs. Add 64 bit SoC data for now.
drivers/clk/uniphier/clk-uniphier-sys.c | 32
drivers/clk/uniphier/clk-uniphier.h | 30
The struct member name of a union is unneeded. This makes the code
a bit shorter.
Signed-off-by: Masahiro Yamada
---
Changes in v2:
- Newly added
drivers/clk/uniphier/clk-uniphier-core.c | 8
drivers/clk/uniphier/clk-uniphier-mio.c | 2 +-
drivers/clk/uniphier/clk-uniphier.h
On Wednesday 23 November 2016 07:09 PM, Bartosz Golaszewski wrote:
> Sekhar noticed there's a section mismatch in the da8xx-mstpri and
> da8xx-ddrctl drivers. This is caused by calling
> of_flat_dt_get_machine_name() which has an __init annotation.
>
> This series makes the drivers drop the call
On Wednesday 23 November 2016 07:09 PM, Bartosz Golaszewski wrote:
> Sekhar noticed there's a section mismatch in the da8xx-mstpri and
> da8xx-ddrctl drivers. This is caused by calling
> of_flat_dt_get_machine_name() which has an __init annotation.
>
> This series makes the drivers drop the call
Core support code for CPU frequency changes, which will be used by
the generic cpufreq driver.
The register view is different from the generic clk-mux; it has
a separate status register, and an update bit to load the register
setting.
Signed-off-by: Masahiro Yamada
Core support code for CPU frequency changes, which will be used by
the generic cpufreq driver.
The register view is different from the generic clk-mux; it has
a separate status register, and an update bit to load the register
setting.
Signed-off-by: Masahiro Yamada
---
Changes in v2: None
* Nicholas Piggin wrote:
> > scripts/Makefile.build | 78
> > --
> > 1 file changed, 72 insertions(+), 6 deletions(-)
> >
> > It was applied 4 hours after it was sent in the -rc3 timeframe, and
* Nicholas Piggin wrote:
> > scripts/Makefile.build | 78
> > --
> > 1 file changed, 72 insertions(+), 6 deletions(-)
> >
> > It was applied 4 hours after it was sent in the -rc3 timeframe, and then it
> > went
> >
On Wednesday 23 November 2016 09:54 PM, David Lechner wrote:
> On 11/23/2016 05:12 AM, Sekhar Nori wrote:
>> On Wednesday 23 November 2016 08:59 AM, David Lechner wrote:
>>> This SoC has a separate pin controller for configuring pullup/pulldown
>>> bias on groups of pins.
>>>
>>> Signed-off-by:
On Wednesday 23 November 2016 09:54 PM, David Lechner wrote:
> On 11/23/2016 05:12 AM, Sekhar Nori wrote:
>> On Wednesday 23 November 2016 08:59 AM, David Lechner wrote:
>>> This SoC has a separate pin controller for configuring pullup/pulldown
>>> bias on groups of pins.
>>>
>>> Signed-off-by:
On Wed, Nov 23, 2016 at 9:45 PM, Thomas Petazzoni
wrote:
> Hello,
>
> On Wed, 23 Nov 2016 14:27:48 +0100, Quentin Schulz wrote:
>> The GPIO input status was read from control register
>> (AXP20X_GPIO[210]_CTRL) instead of status register (AXP20X_GPIO20_SS).
>>
On Wed, Nov 23, 2016 at 9:45 PM, Thomas Petazzoni
wrote:
> Hello,
>
> On Wed, 23 Nov 2016 14:27:48 +0100, Quentin Schulz wrote:
>> The GPIO input status was read from control register
>> (AXP20X_GPIO[210]_CTRL) instead of status register (AXP20X_GPIO20_SS).
>>
>> Signed-off-by: Quentin Schulz
>
Hi,
These patches are based on available work in iio git repository
(git://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio.git) "testing"
branch.
Compatible strings don't exist on ACPI based systems. This patchset adds
probe support by reading ACPI unique identifiers from platform bios for
Hi,
These patches are based on available work in iio git repository
(git://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio.git) "testing"
branch.
Compatible strings don't exist on ACPI based systems. This patchset adds
probe support by reading ACPI unique identifiers from platform bios for
Add support to probe st_accel sensors on i2c bus using ACPI. Compatible
strings are not avaialable on ACPI based systems.
Signed-off-by: Shrirang Bagul
---
drivers/iio/accel/st_accel.h | 18 ++
drivers/iio/accel/st_accel_i2c.c | 73
Add support to probe st_accel sensors on i2c bus using ACPI. Compatible
strings are not avaialable on ACPI based systems.
Signed-off-by: Shrirang Bagul
---
drivers/iio/accel/st_accel.h | 18 ++
drivers/iio/accel/st_accel_i2c.c | 73 +++-
2 files
Add support to match st sensors using information passed from ACPI DST
tables.
Signed-off-by: Shrirang Bagul
---
drivers/iio/common/st_sensors/st_sensors_i2c.c | 20
include/linux/iio/common/st_sensors_i2c.h | 9 +
2 files
Compatible strings are not available on ACPI based systems. This patch adds
support to use DSDT information read from platform BIOS instead for probing
st pressure sensors.
Signed-off-by: Shrirang Bagul
---
drivers/iio/pressure/st_pressure.h | 8 ++
Hi all,
Changes since 20161123:
Removed tree: remoteproc (no longer used)
The powerpc tree gained a conflict against the powerpc-fixes tree.
The kvm-ppc-paulus tree gained conflicts against the powerpc-fixes and
powerpc trees.
The staging tree gained a conflict against the net-next tree
Add support to match st sensors using information passed from ACPI DST
tables.
Signed-off-by: Shrirang Bagul
---
drivers/iio/common/st_sensors/st_sensors_i2c.c | 20
include/linux/iio/common/st_sensors_i2c.h | 9 +
2 files changed, 29 insertions(+)
diff --git
Compatible strings are not available on ACPI based systems. This patch adds
support to use DSDT information read from platform BIOS instead for probing
st pressure sensors.
Signed-off-by: Shrirang Bagul
---
drivers/iio/pressure/st_pressure.h | 8 ++
Hi all,
Changes since 20161123:
Removed tree: remoteproc (no longer used)
The powerpc tree gained a conflict against the powerpc-fixes tree.
The kvm-ppc-paulus tree gained conflicts against the powerpc-fixes and
powerpc trees.
The staging tree gained a conflict against the net-next tree
* Rafael J. Wysocki wrote:
> On Wed, Nov 23, 2016 at 9:13 PM, Jacob Pan
> wrote:
> > Changelog:
> > v3: - rearrange idle.c change based on Rafael's suggestion.
> >
> > v2:
> > - moved duration timer from powerclamp driver to
* Rafael J. Wysocki wrote:
> On Wed, Nov 23, 2016 at 9:13 PM, Jacob Pan
> wrote:
> > Changelog:
> > v3: - rearrange idle.c change based on Rafael's suggestion.
> >
> > v2:
> > - moved duration timer from powerclamp driver to play_idle()
> > - unexport
On Tuesday 15 November 2016 07:13 AM, Rob Herring wrote:
On Thu, Nov 10, 2016 at 10:39:16AM +0530, Keerthy wrote:
GPIO7 is configured in POWERHOLD mode which has higher priority
over DEV_ON bit and keeps the PMIC supplies on even after the DEV_ON
bit is turned off. This property enables
On Tuesday 15 November 2016 07:13 AM, Rob Herring wrote:
On Thu, Nov 10, 2016 at 10:39:16AM +0530, Keerthy wrote:
GPIO7 is configured in POWERHOLD mode which has higher priority
over DEV_ON bit and keeps the PMIC supplies on even after the DEV_ON
bit is turned off. This property enables
+-- On Wed, 23 Nov 2016, Paolo Bonzini wrote --+
| On 23/11/2016 21:15, Radim Krčmář wrote:
| > KVM was using arrays of size KVM_MAX_VCPUS with vcpu_id, but ID can be
| > bigger that the maximal number of VCPUs, resulting in out-of-bounds
| > access.
| >
| > Found by syzkaller:
| >
| > BUG:
+-- On Wed, 23 Nov 2016, Paolo Bonzini wrote --+
| On 23/11/2016 21:15, Radim Krčmář wrote:
| > KVM was using arrays of size KVM_MAX_VCPUS with vcpu_id, but ID can be
| > bigger that the maximal number of VCPUs, resulting in out-of-bounds
| > access.
| >
| > Found by syzkaller:
| >
| > BUG:
1 - 100 of 1850 matches
Mail list logo