On 2018/8/23 20:19, Alexandre Belloni wrote:
> On 23/08/2018 19:44:38+0800, zhong jiang wrote:
>> Hi, alexandre
>>
>> Can you pick up the patch? Thanks
>>
> We are still in the merge window, this has to wait for v4.19-rc1.
Fine. Thank you for let me know .
>> Best wishes,
>> zhong jiang
>>
>>
On 2018/8/23 20:19, Alexandre Belloni wrote:
> On 23/08/2018 19:44:38+0800, zhong jiang wrote:
>> Hi, alexandre
>>
>> Can you pick up the patch? Thanks
>>
> We are still in the merge window, this has to wait for v4.19-rc1.
Fine. Thank you for let me know .
>> Best wishes,
>> zhong jiang
>>
>>
On Thu, Aug 23, 2018 at 12:38 AM Jassi Brar wrote:
>
> On 23 August 2018 at 10:48, Masahiro Yamada
> wrote:
> > Hi Jassi,
> >
> >
> > 2018-08-21 19:44 GMT+09:00 Jassi Brar :
> >> On 21 August 2018 at 15:17, Masahiro Yamada
> >> wrote:
> >>> (+CC Rob, DT, LKML)
> >>>
> >>> I forgot to CC this to
On Thu, Aug 23, 2018 at 12:38 AM Jassi Brar wrote:
>
> On 23 August 2018 at 10:48, Masahiro Yamada
> wrote:
> > Hi Jassi,
> >
> >
> > 2018-08-21 19:44 GMT+09:00 Jassi Brar :
> >> On 21 August 2018 at 15:17, Masahiro Yamada
> >> wrote:
> >>> (+CC Rob, DT, LKML)
> >>>
> >>> I forgot to CC this to
Add support for the clocks provided by the CGU in the Ingenic JZ4725B
SoC.
Signed-off-by: Paul Cercueil
---
Notes:
No change
drivers/clk/ingenic/Kconfig | 10 ++
drivers/clk/ingenic/Makefile | 1 +
drivers/clk/ingenic/jz4725b-cgu.c | 225
This is better than letting the other developers wondering what are the
supported strings.
Signed-off-by: Paul Cercueil
---
Notes:
New patch
Documentation/devicetree/bindings/clock/ingenic,cgu.txt | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git
Add support for the clocks provided by the CGU in the Ingenic JZ4725B
SoC.
Signed-off-by: Paul Cercueil
---
Notes:
No change
drivers/clk/ingenic/Kconfig | 10 ++
drivers/clk/ingenic/Makefile | 1 +
drivers/clk/ingenic/jz4725b-cgu.c | 225
This is better than letting the other developers wondering what are the
supported strings.
Signed-off-by: Paul Cercueil
---
Notes:
New patch
Documentation/devicetree/bindings/clock/ingenic,cgu.txt | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git
This will be used from the devicetree bindings to specify the clocks
that should be obtained from the jz4725b-cgu driver.
Signed-off-by: Paul Cercueil
---
Notes:
No change
include/dt-bindings/clock/jz4725b-cgu.h | 35 +
1 file changed, 35 insertions(+)
This will be used from the devicetree bindings to specify the clocks
that should be obtained from the jz4725b-cgu driver.
Signed-off-by: Paul Cercueil
---
Notes:
No change
include/dt-bindings/clock/jz4725b-cgu.h | 35 +
1 file changed, 35 insertions(+)
Previously, the CGU code corresponding to the SoC for which we're
compiling the kernel was the only one enabled, which made it impossible
to build one kernel that supports them all.
Now, it is possible to select more than one SoC to support.
Signed-off-by: Paul Cercueil
---
Notes:
v2: Drop
Previously, the CGU code corresponding to the SoC for which we're
compiling the kernel was the only one enabled, which made it impossible
to build one kernel that supports them all.
Now, it is possible to select more than one SoC to support.
Signed-off-by: Paul Cercueil
---
Notes:
v2: Drop
On 8/23/18 12:25 PM, Pierre Morel wrote:
> Before adapting the CRYCB shadowing for a guest supporting
> the AP instructions we want to clean the CRYCB shadowing code.
>
> First patch seem obvious.
>
> Second patch introduce a change in the behavior of
> the virtual machine in that the CRYCB is
On 8/23/18 12:25 PM, Pierre Morel wrote:
> Before adapting the CRYCB shadowing for a guest supporting
> the AP instructions we want to clean the CRYCB shadowing code.
>
> First patch seem obvious.
>
> Second patch introduce a change in the behavior of
> the virtual machine in that the CRYCB is
On 23.08.2018 15:12, Christian Borntraeger wrote:
>
>
> On 08/23/2018 12:25 PM, Pierre Morel wrote:
>> Copy the key mask to the right offset inside the shadow CRYCB
>>
>> Signed-off-by: Pierre Morel
>> Reviewed-by: David Hildenbrand
>> Reviewed-by: Cornelia Huck
>> Reviewed-by: Janosch Frank
On 23.08.2018 15:12, Christian Borntraeger wrote:
>
>
> On 08/23/2018 12:25 PM, Pierre Morel wrote:
>> Copy the key mask to the right offset inside the shadow CRYCB
>>
>> Signed-off-by: Pierre Morel
>> Reviewed-by: David Hildenbrand
>> Reviewed-by: Cornelia Huck
>> Reviewed-by: Janosch Frank
On 08/23/2018 12:25 PM, Pierre Morel wrote:
> Copy the key mask to the right offset inside the shadow CRYCB
>
> Signed-off-by: Pierre Morel
> Reviewed-by: David Hildenbrand
> Reviewed-by: Cornelia Huck
> Reviewed-by: Janosch Frank
> ---
> arch/s390/kvm/vsie.c | 3 ++-
> 1 file changed, 2
On 08/23/2018 12:25 PM, Pierre Morel wrote:
> Copy the key mask to the right offset inside the shadow CRYCB
>
> Signed-off-by: Pierre Morel
> Reviewed-by: David Hildenbrand
> Reviewed-by: Cornelia Huck
> Reviewed-by: Janosch Frank
> ---
> arch/s390/kvm/vsie.c | 3 ++-
> 1 file changed, 2
The metadata is best described as side band data or parameters traveling
alongside the data DMAd by the DMA engine. It is data
which is understood by the peripheral and the peripheral driver only, the
DMA engine see it only as data block and it is not interpreting it in any
way.
The metadata can
The metadata is best described as side band data or parameters traveling
alongside the data DMAd by the DMA engine. It is data
which is understood by the peripheral and the peripheral driver only, the
DMA engine see it only as data block and it is not interpreting it in any
way.
The metadata can
Hi Saravana,
On 08/02/2018 03:57 AM, Saravana Kannan wrote:
> This driver registers itself as a devfreq device that allows devfreq
> governors to make bandwidth votes for an interconnect path. This allows
> applying various policies for different interconnect paths using devfreq
> governors.
>
>
Hi Saravana,
On 08/02/2018 03:57 AM, Saravana Kannan wrote:
> This driver registers itself as a devfreq device that allows devfreq
> governors to make bandwidth votes for an interconnect path. This allows
> applying various policies for different interconnect paths using devfreq
> governors.
>
>
Please pull nfsd changes for 4.19 from:
git://linux-nfs.org/~bfields/linux.git tags/nfsd-4.19
--b.
Chuck Lever fixed a problem with NFSv4.0 callbacks over GSS from
multi-homed servers. The only new feature is a minor bit of
Please pull nfsd changes for 4.19 from:
git://linux-nfs.org/~bfields/linux.git tags/nfsd-4.19
--b.
Chuck Lever fixed a problem with NFSv4.0 callbacks over GSS from
multi-homed servers. The only new feature is a minor bit of
On 16/08/18 10:54, Chunyan Zhang wrote:
> As SD Host Controller Specification v4.10 documents:
> Host Controller Version 4.10 defines this "Auto CMD Auto Select" mode.
> Selection of Auto CMD depends on setting of CMD23 Enable in the Host
> Control 2 register which indicates whether card supports
On 16/08/18 10:54, Chunyan Zhang wrote:
> As SD Host Controller Specification v4.10 documents:
> Host Controller Version 4.10 defines this "Auto CMD Auto Select" mode.
> Selection of Auto CMD depends on setting of CMD23 Enable in the Host
> Control 2 register which indicates whether card supports
On 16/08/18 10:54, Chunyan Zhang wrote:
> For version 4.10 and aboves, SDHCI_ARGUMENT2 is also uses to indicate
> 32-bit number of blocks, it doesn't support stuff bits in argument of
> CMD23, but only block count for the following command (CMD18/25).
>
> Signed-off-by: Chunyan Zhang
> ---
>
On 16/08/18 10:54, Chunyan Zhang wrote:
> For version 4.10 and aboves, SDHCI_ARGUMENT2 is also uses to indicate
> 32-bit number of blocks, it doesn't support stuff bits in argument of
> CMD23, but only block count for the following command (CMD18/25).
>
> Signed-off-by: Chunyan Zhang
> ---
>
Hi David,
Le jeu. 23 août 2018 à 12:41, David Laight
a écrit :
From: Paul Cercueil
Sent: 22 August 2018 18:30
The maximum value found in that array is 15, there's no need to
store
these values as uint32_t, a uint8_t is enough.
Signed-off-by: Paul Cercueil
---
Hi David,
Le jeu. 23 août 2018 à 12:41, David Laight
a écrit :
From: Paul Cercueil
Sent: 22 August 2018 18:30
The maximum value found in that array is 15, there's no need to
store
these values as uint32_t, a uint8_t is enough.
Signed-off-by: Paul Cercueil
---
OK, forget this patch.
I need to drop the include first and
there's a bit of work to do before I can achieve that.
-Paul Cercueil
Le jeu. 23 août 2018 à 4:30, kbuild test robot a
écrit :
Hi Paul,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on
OK, forget this patch.
I need to drop the include first and
there's a bit of work to do before I can achieve that.
-Paul Cercueil
Le jeu. 23 août 2018 à 4:30, kbuild test robot a
écrit :
Hi Paul,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on
On 16/08/18 10:54, Chunyan Zhang wrote:
> Host Controller Version 4.10 re-defines SDMA System Address register
> as 32-bit Block Count for v4 mode, and SDMA uses ADMA System
> Address register (05Fh-058h) instead if v4 mode is enabled. Also
> when using 32-bit block count, 16-bit block count
On 16/08/18 10:54, Chunyan Zhang wrote:
> Host Controller Version 4.10 re-defines SDMA System Address register
> as 32-bit Block Count for v4 mode, and SDMA uses ADMA System
> Address register (05Fh-058h) instead if v4 mode is enabled. Also
> when using 32-bit block count, 16-bit block count
On Tue 21-08-18 18:10:42, Mike Kravetz wrote:
[...]
OK, after burning myself when trying to be clever here it seems like
your proposed solution is indeed simpler.
> +bool huge_pmd_sharing_possible(struct vm_area_struct *vma,
> + unsigned long *start, unsigned long
On 23/08/2018 14:43, Christian Borntraeger wrote:
On 08/23/2018 01:41 PM, Pierre Morel wrote:
On 23/08/2018 13:19, David Hildenbrand wrote:
On 23.08.2018 13:07, Christian Borntraeger wrote:
On 08/23/2018 12:25 PM, Pierre Morel wrote:
Copy the key mask to the right offset inside the
On 23/08/2018 14:43, Christian Borntraeger wrote:
On 08/23/2018 01:41 PM, Pierre Morel wrote:
On 23/08/2018 13:19, David Hildenbrand wrote:
On 23.08.2018 13:07, Christian Borntraeger wrote:
On 08/23/2018 12:25 PM, Pierre Morel wrote:
Copy the key mask to the right offset inside the
On Tue 21-08-18 18:10:42, Mike Kravetz wrote:
[...]
OK, after burning myself when trying to be clever here it seems like
your proposed solution is indeed simpler.
> +bool huge_pmd_sharing_possible(struct vm_area_struct *vma,
> + unsigned long *start, unsigned long
/commits/Dou-Liyang/acpi-processor-Fix-the-return-value-of-acpi_processor_ids_walk/20180823-165002
base: https://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git
linux-next
config: i386-randconfig-h0-08231413 (attached as .config)
compiler: gcc-4.9 (Debian 4.9.4-2) 4.9.4
reproduce
/commits/Dou-Liyang/acpi-processor-Fix-the-return-value-of-acpi_processor_ids_walk/20180823-165002
base: https://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git
linux-next
config: i386-randconfig-h0-08231413 (attached as .config)
compiler: gcc-4.9 (Debian 4.9.4-2) 4.9.4
reproduce
On 23/08/2018 13:12, David Hildenbrand wrote:
On 23.08.2018 13:10, Pierre Morel wrote:
On 23/08/2018 12:28, David Hildenbrand wrote:
On 23.08.2018 12:00, Halil Pasic wrote:
On 08/23/2018 09:44 AM, David Hildenbrand wrote:
On 22.08.2018 22:16, Tony Krowiak wrote:
On 08/22/2018 07:24 AM,
On 23/08/2018 13:12, David Hildenbrand wrote:
On 23.08.2018 13:10, Pierre Morel wrote:
On 23/08/2018 12:28, David Hildenbrand wrote:
On 23.08.2018 12:00, Halil Pasic wrote:
On 08/23/2018 09:44 AM, David Hildenbrand wrote:
On 22.08.2018 22:16, Tony Krowiak wrote:
On 08/22/2018 07:24 AM,
On Thu, Aug 23, 2018 at 06:47:09PM +1000, Nicholas Piggin wrote:
> The generic tlb_end_vma does not call invalidate_range mmu notifier,
> and it resets resets the mmu_gather range, which means the notifier
> won't be called on part of the range in case of an unmap that spans
> multiple vmas.
>
>
On Thu, Aug 23, 2018 at 06:47:09PM +1000, Nicholas Piggin wrote:
> The generic tlb_end_vma does not call invalidate_range mmu notifier,
> and it resets resets the mmu_gather range, which means the notifier
> won't be called on part of the range in case of an unmap that spans
> multiple vmas.
>
>
On 08/23/2018 01:41 PM, Pierre Morel wrote:
> On 23/08/2018 13:19, David Hildenbrand wrote:
>> On 23.08.2018 13:07, Christian Borntraeger wrote:
>>>
>>>
>>> On 08/23/2018 12:25 PM, Pierre Morel wrote:
Copy the key mask to the right offset inside the shadow CRYCB
Signed-off-by:
On 08/23/2018 01:41 PM, Pierre Morel wrote:
> On 23/08/2018 13:19, David Hildenbrand wrote:
>> On 23.08.2018 13:07, Christian Borntraeger wrote:
>>>
>>>
>>> On 08/23/2018 12:25 PM, Pierre Morel wrote:
Copy the key mask to the right offset inside the shadow CRYCB
Signed-off-by:
On 23.8.2018 13:18, Lothar Waßmann wrote:
Michal Vokáč wrote:
On 22.8.2018 16:10, Lothar Waßmann wrote:
My use case is attaching different displays to the same baseboard,
where some displays have the brightness control pin inverted with
respect to the others. It's easy to change the
On 23.8.2018 13:18, Lothar Waßmann wrote:
Michal Vokáč wrote:
On 22.8.2018 16:10, Lothar Waßmann wrote:
My use case is attaching different displays to the same baseboard,
where some displays have the brightness control pin inverted with
respect to the others. It's easy to change the
Hi Michal,
> On 23.8.2018 12:40, Lukasz Majewski wrote:
>
> Hi Lukasz, thanks for the reply!
> > Hi Michal,
> >
> >> Output of the PWM block of i.MX SoCs is always zero volts when the
> >> block is disabled. This can caue issues when inverted PWM polarity
> >> is needed. With inverted
Hi Michal,
> On 23.8.2018 12:40, Lukasz Majewski wrote:
>
> Hi Lukasz, thanks for the reply!
> > Hi Michal,
> >
> >> Output of the PWM block of i.MX SoCs is always zero volts when the
> >> block is disabled. This can caue issues when inverted PWM polarity
> >> is needed. With inverted
The patch changes interpretation of:
callq *0x8(%rbx)
from:
0.26 │ → callq *8
to:
0.26 │ → callq *0x8(%rbx)
in this can an address is followed by a register, thus
one can't parse only address.
Signed-off-by: Martin Liška
---
tools/perf/util/annotate.c | 10 --
1 file
The patch changes interpretation of:
callq *0x8(%rbx)
from:
0.26 │ → callq *8
to:
0.26 │ → callq *0x8(%rbx)
in this can an address is followed by a register, thus
one can't parse only address.
Signed-off-by: Martin Liška
---
tools/perf/util/annotate.c | 10 --
1 file
Reviving an old issue while cleaning my inbox.
On Tue, Mar 27, 2018 at 03:59:37PM +, Ghannam, Yazen wrote:
> > > On Mon, Mar 26, 2018 at 07:58:51PM +, Ghannam, Yazen wrote:
> > > > So at a minimum, we should always save and report as much as we can.
> > >
> > > Only on Zen or all AMD
Reviving an old issue while cleaning my inbox.
On Tue, Mar 27, 2018 at 03:59:37PM +, Ghannam, Yazen wrote:
> > > On Mon, Mar 26, 2018 at 07:58:51PM +, Ghannam, Yazen wrote:
> > > > So at a minimum, we should always save and report as much as we can.
> > >
> > > Only on Zen or all AMD
On 23/08/2018 19:44:38+0800, zhong jiang wrote:
> Hi, alexandre
>
> Can you pick up the patch? Thanks
>
We are still in the merge window, this has to wait for v4.19-rc1.
> Best wishes,
> zhong jiang
>
> On 2018/8/16 18:26, zhong jiang wrote:
> > of_find_device_by_node takes a reference to
On 23/08/2018 19:44:38+0800, zhong jiang wrote:
> Hi, alexandre
>
> Can you pick up the patch? Thanks
>
We are still in the merge window, this has to wait for v4.19-rc1.
> Best wishes,
> zhong jiang
>
> On 2018/8/16 18:26, zhong jiang wrote:
> > of_find_device_by_node takes a reference to
Hi Linus,
Please consider for pull.
-Stafford
The following changes since commit 1e4b044d22517cae7047c99038abb23243ca:
Linux 4.18-rc4 (2018-07-08 16:34:02 -0700)
are available in the Git repository at:
git://github.com/openrisc/linux.git tags/for-linus
for you to fetch changes up to
Hi Linus,
Please consider for pull.
-Stafford
The following changes since commit 1e4b044d22517cae7047c99038abb23243ca:
Linux 4.18-rc4 (2018-07-08 16:34:02 -0700)
are available in the Git repository at:
git://github.com/openrisc/linux.git tags/for-linus
for you to fetch changes up to
On 8/23/18 2:03 PM, David Hildenbrand wrote:
> On 23.08.2018 13:53, Janosch Frank wrote:
>> On 8/23/18 1:47 PM, Pierre Morel wrote:
>>> On 23/08/2018 13:33, Janosch Frank wrote:
On 8/23/18 1:21 PM, David Hildenbrand wrote:
> On 23.08.2018 13:05, Janosch Frank wrote:
>> On 8/23/18
On 8/23/18 2:03 PM, David Hildenbrand wrote:
> On 23.08.2018 13:53, Janosch Frank wrote:
>> On 8/23/18 1:47 PM, Pierre Morel wrote:
>>> On 23/08/2018 13:33, Janosch Frank wrote:
On 8/23/18 1:21 PM, David Hildenbrand wrote:
> On 23.08.2018 13:05, Janosch Frank wrote:
>> On 8/23/18
On 23.08.2018 13:53, Janosch Frank wrote:
> On 8/23/18 1:47 PM, Pierre Morel wrote:
>> On 23/08/2018 13:33, Janosch Frank wrote:
>>> On 8/23/18 1:21 PM, David Hildenbrand wrote:
On 23.08.2018 13:05, Janosch Frank wrote:
> On 8/23/18 12:25 PM, Pierre Morel wrote:
>> The comment
On 23.08.2018 13:53, Janosch Frank wrote:
> On 8/23/18 1:47 PM, Pierre Morel wrote:
>> On 23/08/2018 13:33, Janosch Frank wrote:
>>> On 8/23/18 1:21 PM, David Hildenbrand wrote:
On 23.08.2018 13:05, Janosch Frank wrote:
> On 8/23/18 12:25 PM, Pierre Morel wrote:
>> The comment
DMC is a small memory region with various registers,
including the ones needed for the canvas module.
Reviewed-by: Jerome Brunet
Signed-off-by: Maxime Jourdan
---
arch/arm64/boot/dts/amlogic/meson-gx.dtsi | 13 +
1 file changed, 13 insertions(+)
diff --git
Amlogic SoCs feature a set of 256 canvas that act as pixel buffer
descriptors. Some IPs like the display and video decoders access those
pixels by using canvas IDs rather than direct phy addresses.
As such, allocating/manipulating canvases can be done concurrently and
there is a need for a
DT bindings doc for amlogic,meson-canvas
Reviewed-by: Jerome Brunet
Signed-off-by: Maxime Jourdan
---
.../bindings/soc/amlogic/amlogic,canvas.txt | 29 +++
1 file changed, 29 insertions(+)
create mode 100644
Documentation/devicetree/bindings/soc/amlogic/amlogic,canvas.txt
DMC is a small memory region with various registers,
including the ones needed for the canvas module.
Reviewed-by: Jerome Brunet
Signed-off-by: Maxime Jourdan
---
arch/arm64/boot/dts/amlogic/meson-gx.dtsi | 13 +
1 file changed, 13 insertions(+)
diff --git
Amlogic SoCs feature a set of 256 canvas that act as pixel buffer
descriptors. Some IPs like the display and video decoders access those
pixels by using canvas IDs rather than direct phy addresses.
As such, allocating/manipulating canvases can be done concurrently and
there is a need for a
DT bindings doc for amlogic,meson-canvas
Reviewed-by: Jerome Brunet
Signed-off-by: Maxime Jourdan
---
.../bindings/soc/amlogic/amlogic,canvas.txt | 29 +++
1 file changed, 29 insertions(+)
create mode 100644
Documentation/devicetree/bindings/soc/amlogic/amlogic,canvas.txt
Patches 1-5 are Reviewed-by: Karol Herbst
I think it might be worth to test those patches on a system without
any backlight devices just to verify we don't break things, but the
code looked good already, so maybe we don't really need to test.
On Thu, Aug 23, 2018 at 3:21 AM, Lyude Paul wrote:
Patches 1-5 are Reviewed-by: Karol Herbst
I think it might be worth to test those patches on a system without
any backlight devices just to verify we don't break things, but the
code looked good already, so maybe we don't really need to test.
On Thu, Aug 23, 2018 at 3:21 AM, Lyude Paul wrote:
Amlogic SoCs have a repository of 256 canvas which they use to
describe pixel buffers.
They contain metadata like width, height, block mode, endianness [..]
Many IPs within those SoCs like vdec/vpu rely on those canvas to read/write
pixels.
Reviewed-by: Jerome Brunet
Tested-by: Neil Armstrong
Amlogic SoCs have a repository of 256 canvas which they use to
describe pixel buffers.
They contain metadata like width, height, block mode, endianness [..]
Many IPs within those SoCs like vdec/vpu rely on those canvas to read/write
pixels.
Reviewed-by: Jerome Brunet
Tested-by: Neil Armstrong
/linux/commits/Weikang-Shi/fs-fix-local-var-type/20180823-180758
config: x86_64-randconfig-x009-201833 (attached as .config)
compiler: gcc-7 (Debian 7.3.0-16) 7.3.0
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
All warnings (new ones prefixed
/linux/commits/Weikang-Shi/fs-fix-local-var-type/20180823-180758
config: x86_64-randconfig-x009-201833 (attached as .config)
compiler: gcc-7 (Debian 7.3.0-16) 7.3.0
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
All warnings (new ones prefixed
Hi Linus,
Please pull fbdev changes for v4.19. There are mostly small fixes and
cleanups for fb drivers (the biggest updates are for udlfb and pxafb
drivers). This PR also adds deferred console takeover support to the
console code and efifb driver. Please see the signed tag description
for
Hi Linus,
Please pull fbdev changes for v4.19. There are mostly small fixes and
cleanups for fb drivers (the biggest updates are for udlfb and pxafb
drivers). This PR also adds deferred console takeover support to the
console code and efifb driver. Please see the signed tag description
for
/commits/Dou-Liyang/acpi-processor-Fix-the-return-value-of-acpi_processor_ids_walk/20180823-165002
base: https://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git
linux-next
config: x86_64-randconfig-r0-08231341 (attached as .config)
compiler: gcc-6 (Debian 6.4.0-9) 6.4.0 20171026
reproduce
/commits/Dou-Liyang/acpi-processor-Fix-the-return-value-of-acpi_processor_ids_walk/20180823-165002
base: https://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git
linux-next
config: x86_64-randconfig-r0-08231341 (attached as .config)
compiler: gcc-6 (Debian 6.4.0-9) 6.4.0 20171026
reproduce
On Thu, Aug 23, 2018 at 01:17:28PM +0200, Greg Kroah-Hartman wrote:
> On Thu, Aug 23, 2018 at 01:57:35PM +0300, Sergei Shtylyov wrote:
> > On 08/23/2018 10:55 AM, Greg Kroah-Hartman wrote:
> >
> > > 4.14-stable review patch. If anyone has any objections, please let me
> > > know.
> > >
> > >
On Thu, Aug 23, 2018 at 01:17:28PM +0200, Greg Kroah-Hartman wrote:
> On Thu, Aug 23, 2018 at 01:57:35PM +0300, Sergei Shtylyov wrote:
> > On 08/23/2018 10:55 AM, Greg Kroah-Hartman wrote:
> >
> > > 4.14-stable review patch. If anyone has any objections, please let me
> > > know.
> > >
> > >
On 23/08/18 13:09, Jisheng Zhang wrote:
> When using DMA, if the DMA addr spans 128MB boundary, we have to split
> the DMA transfer into two so that each one doesn't exceed the boundary.
>
> Signed-off-by: Jisheng Zhang
> ---
> drivers/mmc/host/sdhci-of-dwcmshc.c | 39
On 23/08/18 13:09, Jisheng Zhang wrote:
> When using DMA, if the DMA addr spans 128MB boundary, we have to split
> the DMA transfer into two so that each one doesn't exceed the boundary.
>
> Signed-off-by: Jisheng Zhang
> ---
> drivers/mmc/host/sdhci-of-dwcmshc.c | 39
On 8/23/18 1:47 PM, Pierre Morel wrote:
> On 23/08/2018 13:33, Janosch Frank wrote:
>> On 8/23/18 1:21 PM, David Hildenbrand wrote:
>>> On 23.08.2018 13:05, Janosch Frank wrote:
On 8/23/18 12:25 PM, Pierre Morel wrote:
> The comment preceding the shadow_crycb function is
> misleading,
On 8/23/18 1:47 PM, Pierre Morel wrote:
> On 23/08/2018 13:33, Janosch Frank wrote:
>> On 8/23/18 1:21 PM, David Hildenbrand wrote:
>>> On 23.08.2018 13:05, Janosch Frank wrote:
On 8/23/18 12:25 PM, Pierre Morel wrote:
> The comment preceding the shadow_crycb function is
> misleading,
On 23/08/2018 13:33, Janosch Frank wrote:
On 8/23/18 1:21 PM, David Hildenbrand wrote:
On 23.08.2018 13:05, Janosch Frank wrote:
On 8/23/18 12:25 PM, Pierre Morel wrote:
The comment preceding the shadow_crycb function is
misleading, we effectively accept FORMAT2 CRYCB in the
guest.
I beg to
On 23/08/2018 13:33, Janosch Frank wrote:
On 8/23/18 1:21 PM, David Hildenbrand wrote:
On 23.08.2018 13:05, Janosch Frank wrote:
On 8/23/18 12:25 PM, Pierre Morel wrote:
The comment preceding the shadow_crycb function is
misleading, we effectively accept FORMAT2 CRYCB in the
guest.
I beg to
Hi, alexandre
Can you pick up the patch? Thanks
Best wishes,
zhong jiang
On 2018/8/16 18:26, zhong jiang wrote:
> of_find_device_by_node takes a reference to the struct device when it
> finds a match via get_device. but it fails to put_device in
> at91_pm_config_ws,
On 23/08/2018 13:31, Cornelia Huck wrote:
On Thu, 23 Aug 2018 12:43:42 +0200
Pierre Morel wrote:
On 23/08/2018 12:25, Cornelia Huck wrote:
On Wed, 22 Aug 2018 15:16:19 -0400
Tony Krowiak wrote:
One of the things I suggested in a private conversation with Christian
earlier
today was to
Hi, alexandre
Can you pick up the patch? Thanks
Best wishes,
zhong jiang
On 2018/8/16 18:26, zhong jiang wrote:
> of_find_device_by_node takes a reference to the struct device when it
> finds a match via get_device. but it fails to put_device in
> at91_pm_config_ws,
On 23/08/2018 13:31, Cornelia Huck wrote:
On Thu, 23 Aug 2018 12:43:42 +0200
Pierre Morel wrote:
On 23/08/2018 12:25, Cornelia Huck wrote:
On Wed, 22 Aug 2018 15:16:19 -0400
Tony Krowiak wrote:
One of the things I suggested in a private conversation with Christian
earlier
today was to
Harshit Jain wrote:
> Hey! tony thanks for reviewing, pardon me i wasn't able to get your context
> can you please elaborate a little what you are trying to say?
There's a big block comment above the state machine code which tries to
explain what the blazes is going on. The comment includes an
On 23/08/2018 13:19, David Hildenbrand wrote:
On 23.08.2018 13:17, Christian Borntraeger wrote:
On 08/23/2018 12:25 PM, Pierre Morel wrote:
When entering the SIE the CRYCB validation better
be done independently of the instruction's
availability.
Maybe something like
We need to handle the
Harshit Jain wrote:
> Hey! tony thanks for reviewing, pardon me i wasn't able to get your context
> can you please elaborate a little what you are trying to say?
There's a big block comment above the state machine code which tries to
explain what the blazes is going on. The comment includes an
On 23/08/2018 13:19, David Hildenbrand wrote:
On 23.08.2018 13:17, Christian Borntraeger wrote:
On 08/23/2018 12:25 PM, Pierre Morel wrote:
When entering the SIE the CRYCB validation better
be done independently of the instruction's
availability.
Maybe something like
We need to handle the
On 23/08/2018 13:19, David Hildenbrand wrote:
On 23.08.2018 13:07, Christian Borntraeger wrote:
On 08/23/2018 12:25 PM, Pierre Morel wrote:
Copy the key mask to the right offset inside the shadow CRYCB
Signed-off-by: Pierre Morel
Reviewed-by: David Hildenbrand
Reviewed-by: Cornelia Huck
On 23/08/2018 13:19, David Hildenbrand wrote:
On 23.08.2018 13:07, Christian Borntraeger wrote:
On 08/23/2018 12:25 PM, Pierre Morel wrote:
Copy the key mask to the right offset inside the shadow CRYCB
Signed-off-by: Pierre Morel
Reviewed-by: David Hildenbrand
Reviewed-by: Cornelia Huck
On 23/08/2018 13:21, David Hildenbrand wrote:
On 23.08.2018 13:05, Janosch Frank wrote:
On 8/23/18 12:25 PM, Pierre Morel wrote:
The comment preceding the shadow_crycb function is
misleading, we effectively accept FORMAT2 CRYCB in the
guest.
I beg to differ:
if (!(crycbd_o &
On 23/08/2018 13:21, David Hildenbrand wrote:
On 23.08.2018 13:05, Janosch Frank wrote:
On 8/23/18 12:25 PM, Pierre Morel wrote:
The comment preceding the shadow_crycb function is
misleading, we effectively accept FORMAT2 CRYCB in the
guest.
I beg to differ:
if (!(crycbd_o &
On 23/08/2018 13:17, Christian Borntraeger wrote:
On 08/23/2018 12:25 PM, Pierre Morel wrote:
When entering the SIE the CRYCB validation better
be done independently of the instruction's
availability.
Maybe something like
We need to handle the validity checks for the crycb, no matter what
On 23/08/2018 13:17, Christian Borntraeger wrote:
On 08/23/2018 12:25 PM, Pierre Morel wrote:
When entering the SIE the CRYCB validation better
be done independently of the instruction's
availability.
Maybe something like
We need to handle the validity checks for the crycb, no matter what
601 - 700 of 2464 matches
Mail list logo
