Hi Andrew,
Today's linux-next merge of the akpm-current tree got a conflict in:
mm/page_alloc.c
between commit:
3e04040df6d4 ("Revert "mm/page_alloc: fix memmap_init_zone pageblock
alignment"")
from Linus' tree and commit:
45251b0909dc ("mm: remove unused arg from
Hi Andrew,
Today's linux-next merge of the akpm-current tree got a conflict in:
mm/page_alloc.c
between commit:
3e04040df6d4 ("Revert "mm/page_alloc: fix memmap_init_zone pageblock
alignment"")
from Linus' tree and commit:
45251b0909dc ("mm: remove unused arg from
On Thu, Mar 15, 2018 at 4:16 PM Tomer Maimon wrote:
> Modify configuration and MakeFile
> for the Nuvoton NPCM and NPCM7xx BMC.
> Signed-off-by: Tomer Maimon
> ---
> arch/arm/mach-npcm/Kconfig | 40 +++-
>
On Thu, Mar 15, 2018 at 4:16 PM Tomer Maimon wrote:
> Modify configuration and MakeFile
> for the Nuvoton NPCM and NPCM7xx BMC.
> Signed-off-by: Tomer Maimon
> ---
> arch/arm/mach-npcm/Kconfig | 40 +++-
> arch/arm/mach-npcm/Makefile | 4 +++-
> 2
On (03/15/18 18:35), Linus Torvalds wrote:
> On Thu, Mar 15, 2018 at 6:18 PM, Sergey Senozhatsky
> wrote:
> >
> > Hm, may be sizeof(ptr) still won't suffice. It would be great if we
> > could always look at spec.field_width, which can be up to 2 * sizeof(void
>
On (03/15/18 18:35), Linus Torvalds wrote:
> On Thu, Mar 15, 2018 at 6:18 PM, Sergey Senozhatsky
> wrote:
> >
> > Hm, may be sizeof(ptr) still won't suffice. It would be great if we
> > could always look at spec.field_width, which can be up to 2 * sizeof(void
> > *),
> > and then just
On Thu, Mar 15, 2018 at 4:16 PM Tomer Maimon wrote:
> Enable L2 Cache in Nuvoton NPCM7xx BMC.
> Signed-off-by: Tomer Maimon
> ---
> arch/arm/mach-npcm/npcm7xx.c | 2 ++
> 1 file changed, 2 insertions(+)
> diff --git a/arch/arm/mach-npcm/npcm7xx.c
On Thu, Mar 15, 2018 at 4:16 PM Tomer Maimon wrote:
> Enable L2 Cache in Nuvoton NPCM7xx BMC.
> Signed-off-by: Tomer Maimon
> ---
> arch/arm/mach-npcm/npcm7xx.c | 2 ++
> 1 file changed, 2 insertions(+)
> diff --git a/arch/arm/mach-npcm/npcm7xx.c b/arch/arm/mach-npcm/npcm7xx.c
> index
Hi Stephen,
At 03/16/2018 01:37 PM, Stephen Rothwell wrote:
Hi all,
After merging the tip tree, yesterday's linux-next build (x86_64 allnoconfig)
produced this warning:
kernel/cpu.c:129:13: warning: 'cpuhp_is_ap_state' defined but not used
[-Wunused-function]
static bool
Hi Stephen,
At 03/16/2018 01:37 PM, Stephen Rothwell wrote:
Hi all,
After merging the tip tree, yesterday's linux-next build (x86_64 allnoconfig)
produced this warning:
kernel/cpu.c:129:13: warning: 'cpuhp_is_ap_state' defined but not used
[-Wunused-function]
static bool
On 03/16/2018 10:05 AM, Viresh Kumar wrote:
> On 16-03-18, 09:38, Rajendra Nayak wrote:
>> With genpd now expecting powerdomain drivers supporting performance
>> state to support get/set performance state callbacks, add support for it
>> in the rpmpd driver.
>>
>> Signed-off-by: Rajendra Nayak
On 03/16/2018 10:05 AM, Viresh Kumar wrote:
> On 16-03-18, 09:38, Rajendra Nayak wrote:
>> With genpd now expecting powerdomain drivers supporting performance
>> state to support get/set performance state callbacks, add support for it
>> in the rpmpd driver.
>>
>> Signed-off-by: Rajendra Nayak
Hi all,
After merging the tip tree, yesterday's linux-next build (x86_64 allnoconfig)
produced this warning:
kernel/cpu.c:129:13: warning: 'cpuhp_is_ap_state' defined but not used
[-Wunused-function]
static bool cpuhp_is_ap_state(enum cpuhp_state state)
^
Hi all,
After merging the tip tree, yesterday's linux-next build (x86_64 allnoconfig)
produced this warning:
kernel/cpu.c:129:13: warning: 'cpuhp_is_ap_state' defined but not used
[-Wunused-function]
static bool cpuhp_is_ap_state(enum cpuhp_state state)
^
On 23-02-18, 15:53, Viresh Kumar wrote:
> Hi Greg,
>
> The V7 version incorporates the organizational changes suggested by Olof
> earlier. Everything else is same otherwise.
>
> I have tested the Hisilicon patches (again) on hikey 9660 board, IMX stuff was
> earlier tested by Sascha
On 23-02-18, 15:53, Viresh Kumar wrote:
> Hi Greg,
>
> The V7 version incorporates the organizational changes suggested by Olof
> earlier. Everything else is same otherwise.
>
> I have tested the Hisilicon patches (again) on hikey 9660 board, IMX stuff was
> earlier tested by Sascha
On 03/15/2018 09:02 AM, Eddie James wrote:
From: Milton Miller
Allow the device tree to specify a watchdog to fallover to
the alternate boot source.
The aspeeed watchdog can set a latch directing flash chip select 0 to
chip select 1, allowing boot from an alternate media
On 03/15/2018 09:02 AM, Eddie James wrote:
From: Milton Miller
Allow the device tree to specify a watchdog to fallover to
the alternate boot source.
The aspeeed watchdog can set a latch directing flash chip select 0 to
chip select 1, allowing boot from an alternate media if the watchdog
is
We have a great about your E-mail address!!!
You Won $950,500.00 USD on Amnesty International
UK online E-mail Promotion. For more details about
your prize claims, file with the following;
Names:
Country:
Tel:
Regards,
Mr. David Ford
We have a great about your E-mail address!!!
You Won $950,500.00 USD on Amnesty International
UK online E-mail Promotion. For more details about
your prize claims, file with the following;
Names:
Country:
Tel:
Regards,
Mr. David Ford
Hi Christopher,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on linus/master]
[also build test ERROR on v4.16-rc5 next-20180315]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci
Hi Christopher,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on linus/master]
[also build test ERROR on v4.16-rc5 next-20180315]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci
Hi Arnd,
Do you want me to send the fix as a patch or should I re-post the series?
Thanks,
Deepa
On Thu, Mar 15, 2018 at 7:25 PM, Stephen Rothwell wrote:
> Hi Arnd,
>
> After merging the y2038 tree, today's linux-next build (s390 allnoconfig)
> failed like this:
>
> In
Hi Arnd,
Do you want me to send the fix as a patch or should I re-post the series?
Thanks,
Deepa
On Thu, Mar 15, 2018 at 7:25 PM, Stephen Rothwell wrote:
> Hi Arnd,
>
> After merging the y2038 tree, today's linux-next build (s390 allnoconfig)
> failed like this:
>
> In file included from
On Fri, Mar 16, 2018 at 2:32 AM, Eddie James wrote:
> From: Milton Miller
>
> Allow the device tree to specify a watchdog to fallover to
> the alternate boot source.
>
> The aspeeed watchdog can set a latch directing flash chip select 0 to
> chip
On Fri, Mar 16, 2018 at 2:32 AM, Eddie James wrote:
> From: Milton Miller
>
> Allow the device tree to specify a watchdog to fallover to
> the alternate boot source.
>
> The aspeeed watchdog can set a latch directing flash chip select 0 to
> chip select 1, allowing boot from an alternate media
On Thu, 15 Mar 2018 20:15:52 +0100
Michal Suchanek wrote:
> On powerpc syscall entry is done in assembly so patch in an explicit
> barrier_nospec.
Same comment as Linus for this -- the barriers are before the branch here,
so is it possible the branch instruction can be
On Thu, 15 Mar 2018 20:15:52 +0100
Michal Suchanek wrote:
> On powerpc syscall entry is done in assembly so patch in an explicit
> barrier_nospec.
Same comment as Linus for this -- the barriers are before the branch here,
so is it possible the branch instruction can be speculative while the
On 03/15/2018 11:37 AM, jgli...@redhat.com wrote:
> From: Jérôme Glisse
>
> This change hmm_vma_fault() and hmm_vma_get_pfns() API to allow HMM
> to directly write entry that can match any device page table entry
> format. Device driver now provide an array of flags value and
On 03/15/2018 11:37 AM, jgli...@redhat.com wrote:
> From: Jérôme Glisse
>
> This change hmm_vma_fault() and hmm_vma_get_pfns() API to allow HMM
> to directly write entry that can match any device page table entry
> format. Device driver now provide an array of flags value and we use
> enum to
There is no failure checking on the param value which will be allocated
memory by kmalloc. Add a null pointer checking statement. Then goto error:
and return -ENOMEM error code when kmalloc is failed.
Signed-off-by: Ji-Hun Kim
---
There is no failure checking on the param value which will be allocated
memory by kmalloc. Add a null pointer checking statement. Then goto error:
and return -ENOMEM error code when kmalloc is failed.
Signed-off-by: Ji-Hun Kim
---
drivers/staging/media/davinci_vpfe/dm365_ipipe.c | 8
1
Arnd Bergmann writes:
> On Thu, Mar 15, 2018 at 7:30 PM, Marcel Holtmann wrote:
>> Hi Arnd,
>>
>>> The linkage between the bluetooth driver and the wireless
>>> driver is not defined properly, leading to build problems
>>> such as:
>>>
>>> warning:
Arnd Bergmann writes:
> On Thu, Mar 15, 2018 at 7:30 PM, Marcel Holtmann wrote:
>> Hi Arnd,
>>
>>> The linkage between the bluetooth driver and the wireless
>>> driver is not defined properly, leading to build problems
>>> such as:
>>>
>>> warning: (BT_HCIRSI) selects RSI_COEX which has unmet
Hi,
On Thu, Mar 15, 2018 at 10:56:48AM +0100, Arnd Bergmann wrote:
> On Thu, Mar 15, 2018 at 10:42 AM, David Howells wrote:
> > Do we have anything left that still implements NOMMU?
Please don't kill !MMU.
> Yes, plenty.
> I've made an overview of the remaining
Hi,
On Thu, Mar 15, 2018 at 10:56:48AM +0100, Arnd Bergmann wrote:
> On Thu, Mar 15, 2018 at 10:42 AM, David Howells wrote:
> > Do we have anything left that still implements NOMMU?
Please don't kill !MMU.
> Yes, plenty.
> I've made an overview of the remaining architectures for my own
On 16-03-18, 09:38, Rajendra Nayak wrote:
> As we move from no clients/consumers in kernel voting on corners,
> to *some* voting and some not voting, we might end up in a situation
> where the clients which remove votes can adversly impact others
> who still don't have a way to vote.
>
> To avoid
On 16-03-18, 09:38, Rajendra Nayak wrote:
> As we move from no clients/consumers in kernel voting on corners,
> to *some* voting and some not voting, we might end up in a situation
> where the clients which remove votes can adversly impact others
> who still don't have a way to vote.
>
> To avoid
On 16-03-18, 09:38, Rajendra Nayak wrote:
> @@ -1540,6 +1571,9 @@ static int sdhci_msm_probe(struct platform_device *pdev)
> pm_runtime_disable(>dev);
> pm_runtime_set_suspended(>dev);
> pm_runtime_put_noidle(>dev);
> + dev_pm_opp_of_remove_table(>dev);
You can't do this if
On 16-03-18, 09:38, Rajendra Nayak wrote:
> @@ -1540,6 +1571,9 @@ static int sdhci_msm_probe(struct platform_device *pdev)
> pm_runtime_disable(>dev);
> pm_runtime_set_suspended(>dev);
> pm_runtime_put_noidle(>dev);
> + dev_pm_opp_of_remove_table(>dev);
You can't do this if
On Thu, Mar 15, 2018 at 03:31:58PM -0600, Alex Williamson wrote:
> The ioeventfd here is actually irqfd handling of an ioeventfd such as
> supported in KVM. A user is able to pre-program a device write to
> occur when the eventfd triggers. This is yet another instance of
> eventfd-irqfd
On Thu, Mar 15, 2018 at 03:31:58PM -0600, Alex Williamson wrote:
> The ioeventfd here is actually irqfd handling of an ioeventfd such as
> supported in KVM. A user is able to pre-program a device write to
> occur when the eventfd triggers. This is yet another instance of
> eventfd-irqfd
If caching mode is supported, the hardware will cache
none-present or erroneous translation entries. Hence,
software should explicitly invalidate the PASID cache
after a PASID table entry becomes present. We should
issue such invalidation with the PASID value that we
have changed. PASID 0 is not
If caching mode is supported, the hardware will cache
none-present or erroneous translation entries. Hence,
software should explicitly invalidate the PASID cache
after a PASID table entry becomes present. We should
issue such invalidation with the PASID value that we
have changed. PASID 0 is not
On Thu, Mar 15, 2018 at 11:49:56AM -0700, Moritz Fischer wrote:
> Hi Hao,
>
> On Tue, Feb 13, 2018 at 05:24:37PM +0800, Wu Hao wrote:
> > From: Zhang Yi
> >
> > This patch implements the basic framework of the driver for FPGA PCIe
> > device which implements the Device
On Thu, Mar 15, 2018 at 11:49:56AM -0700, Moritz Fischer wrote:
> Hi Hao,
>
> On Tue, Feb 13, 2018 at 05:24:37PM +0800, Wu Hao wrote:
> > From: Zhang Yi
> >
> > This patch implements the basic framework of the driver for FPGA PCIe
> > device which implements the Device Feature List (DFL) in its
On 16-03-18, 09:38, Rajendra Nayak wrote:
> Add rpmpd device node and its OPP table
>
> Signed-off-by: Rajendra Nayak
> Signed-off-by: Viresh Kumar
> ---
> arch/arm64/boot/dts/qcom/msm8996.dtsi | 46
> +++
> 1
On 16-03-18, 09:38, Rajendra Nayak wrote:
> Add rpmpd device node and its OPP table
>
> Signed-off-by: Rajendra Nayak
> Signed-off-by: Viresh Kumar
> ---
> arch/arm64/boot/dts/qcom/msm8996.dtsi | 46
> +++
> 1 file changed, 46 insertions(+)
>
> diff --git
On 16-03-18, 09:38, Rajendra Nayak wrote:
> With genpd now expecting powerdomain drivers supporting performance
> state to support get/set performance state callbacks, add support for it
> in the rpmpd driver.
>
> Signed-off-by: Rajendra Nayak
> Signed-off-by: Viresh Kumar
On 16-03-18, 09:38, Rajendra Nayak wrote:
> With genpd now expecting powerdomain drivers supporting performance
> state to support get/set performance state callbacks, add support for it
> in the rpmpd driver.
>
> Signed-off-by: Rajendra Nayak
> Signed-off-by: Viresh Kumar
> ---
>
On 16-03-18, 09:38, Rajendra Nayak wrote:
> On Qualcomm platforms, an OPP node needs to describe an
> additional level/corner value that is then communicated to
> a remote microprocessor by the CPU, which then takes some
> actions (like adjusting voltage values across various rails)
> based on the
On 16-03-18, 09:38, Rajendra Nayak wrote:
> On Qualcomm platforms, an OPP node needs to describe an
> additional level/corner value that is then communicated to
> a remote microprocessor by the CPU, which then takes some
> actions (like adjusting voltage values across various rails)
> based on the
As part of the effort to remove VLAs from the kernel[1], this moves
the literal values into the stack array calculation instead of using a
variable for the sizing. The resulting size can be found from
sizeof(buf).
[1] https://lkml.org/lkml/2018/3/7/621
Signed-off-by: Kyle Spiers
As part of the effort to remove VLAs from the kernel[1], this moves
the literal values into the stack array calculation instead of using a
variable for the sizing. The resulting size can be found from
sizeof(buf).
[1] https://lkml.org/lkml/2018/3/7/621
Signed-off-by: Kyle Spiers
---
Patch 1 adds const_max_t(), patch 2 uses it in all the places max()
was used for stack arrays. Commit log from patch 1:
---snip---
kernel.h: Introduce const_max_t() for VLA removal
In the effort to remove all VLAs from the kernel[1], it is desirable to
build with -Wvla. However, this warning is
Patch 1 adds const_max_t(), patch 2 uses it in all the places max()
was used for stack arrays. Commit log from patch 1:
---snip---
kernel.h: Introduce const_max_t() for VLA removal
In the effort to remove all VLAs from the kernel[1], it is desirable to
build with -Wvla. However, this warning is
As part of removing VLAs from the kernel[1], we want to build with -Wvla,
but it is overly pessimistic and only accepts constant expressions for
stack array sizes, instead of also constant values. The max() macro
triggers the warning, so this refactors these uses of max() to use the
new
As part of removing VLAs from the kernel[1], we want to build with -Wvla,
but it is overly pessimistic and only accepts constant expressions for
stack array sizes, instead of also constant values. The max() macro
triggers the warning, so this refactors these uses of max() to use the
new
In the effort to remove all VLAs from the kernel[1], it is desirable to
build with -Wvla. However, this warning is overly pessimistic, in that
it is only happy with stack array sizes that are declared as constant
expressions, and not constant values. One case of this is the evaluation
of the max()
In the effort to remove all VLAs from the kernel[1], it is desirable to
build with -Wvla. However, this warning is overly pessimistic, in that
it is only happy with stack array sizes that are declared as constant
expressions, and not constant values. One case of this is the evaluation
of the max()
On Thu, Mar 15, 2018 at 3:00 AM, Kieran Bingham
wrote:
> Simplify array iteration with a helper to iterate each entry in an array.
> Utilise the existing ARRAY_SIZE macro to identify the length of the array
> and pointer arithmetic to process each item as a for
On Thu, Mar 15, 2018 at 3:00 AM, Kieran Bingham
wrote:
> Simplify array iteration with a helper to iterate each entry in an array.
> Utilise the existing ARRAY_SIZE macro to identify the length of the array
> and pointer arithmetic to process each item as a for loop.
>
> Signed-off-by: Kieran
On Thursday 15 March 2018 05:59 PM, Ulf Hansson wrote:
> On 15 March 2018 at 11:26, Andy Shevchenko
> wrote:
>> On Thu, 2018-03-15 at 11:12 +0100, Ulf Hansson wrote:
>>> On 13 March 2018 at 06:10, Harish Jenny K N
On Thursday 15 March 2018 05:59 PM, Ulf Hansson wrote:
> On 15 March 2018 at 11:26, Andy Shevchenko
> wrote:
>> On Thu, 2018-03-15 at 11:12 +0100, Ulf Hansson wrote:
>>> On 13 March 2018 at 06:10, Harish Jenny K N >>> wrote:
>>> Honestly, I don't like this, but maybe other people do, then
With genpd now expecting powerdomain drivers supporting performance
state to support get/set performance state callbacks, add support for it
in the rpmpd driver.
Signed-off-by: Rajendra Nayak
Signed-off-by: Viresh Kumar
---
With genpd now expecting powerdomain drivers supporting performance
state to support get/set performance state callbacks, add support for it
in the rpmpd driver.
Signed-off-by: Rajendra Nayak
Signed-off-by: Viresh Kumar
---
drivers/soc/qcom/rpmpd.c | 42
With performance state support for genpd merged, and with some more
patches to add support for them in the OPP layer [1] under discussion,
this is an effort to model a powerdomain driver to communicate corner/level
values for qualcomm platforms to RPM (Remote Power Manager)
This series adds data
With performance state support for genpd merged, and with some more
patches to add support for them in the OPP layer [1] under discussion,
this is an effort to model a powerdomain driver to communicate corner/level
values for qualcomm platforms to RPM (Remote Power Manager)
This series adds data
On Qualcomm platforms, an OPP node needs to describe an
additional level/corner value that is then communicated to
a remote microprocessor by the CPU, which then takes some
actions (like adjusting voltage values across various rails)
based on the value passed.
Describe these bindings in the
Add rpmpd device node and its OPP table
Signed-off-by: Rajendra Nayak
Signed-off-by: Viresh Kumar
---
arch/arm64/boot/dts/qcom/msm8996.dtsi | 46 +++
1 file changed, 46 insertions(+)
diff --git
On Qualcomm platforms, an OPP node needs to describe an
additional level/corner value that is then communicated to
a remote microprocessor by the CPU, which then takes some
actions (like adjusting voltage values across various rails)
based on the value passed.
Describe these bindings in the
Add rpmpd device node and its OPP table
Signed-off-by: Rajendra Nayak
Signed-off-by: Viresh Kumar
---
arch/arm64/boot/dts/qcom/msm8996.dtsi | 46 +++
1 file changed, 46 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/msm8996.dtsi
SDHCI driver needs to set a performance state along with scaling its
clocks. Modify the driver to use the newly introduced powerdomain
performance state based OPPs to scale clocks as well as set an
appropriate powerdomain performance state.
The patch also adds OPPs for sdhci device on msm8996.
SDHCI driver needs to set a performance state along with scaling its
clocks. Modify the driver to use the newly introduced powerdomain
performance state based OPPs to scale clocks as well as set an
appropriate powerdomain performance state.
The patch also adds OPPs for sdhci device on msm8996.
As we move from no clients/consumers in kernel voting on corners,
to *some* voting and some not voting, we might end up in a situation
where the clients which remove votes can adversly impact others
who still don't have a way to vote.
To avoid this situation, have a max vote on all corners at
The powerdomains for corners just pass the performance state set by the
consumers to the RPM (Remote Power manager) which then takes care
of setting the appropriate voltage on the corresponding rails to
meet the performance needs.
We add all powerdomain data needed on msm8996 here. This driver
As we move from no clients/consumers in kernel voting on corners,
to *some* voting and some not voting, we might end up in a situation
where the clients which remove votes can adversly impact others
who still don't have a way to vote.
To avoid this situation, have a max vote on all corners at
The powerdomains for corners just pass the performance state set by the
consumers to the RPM (Remote Power manager) which then takes care
of setting the appropriate voltage on the corresponding rails to
meet the performance needs.
We add all powerdomain data needed on msm8996 here. This driver
From: Viresh Kumar
This adds a new helper to let the power domain drivers to access
opp->np, so that they can read platform specific properties from the
node.
Signed-off-by: Viresh Kumar
Signed-off-by: Rajendra Nayak
---
From: Viresh Kumar
This adds a new helper to let the power domain drivers to access
opp->np, so that they can read platform specific properties from the
node.
Signed-off-by: Viresh Kumar
Signed-off-by: Rajendra Nayak
---
drivers/opp/of.c | 19 +++
include/linux/pm_opp.h
On 2018年02月23日 19:18, Tiwei Bie wrote:
Signed-off-by: Tiwei Bie
---
drivers/virtio/virtio_ring.c | 699 +--
include/linux/virtio_ring.h | 8 +-
2 files changed, 618 insertions(+), 89 deletions(-)
diff --git
On 2018年02月23日 19:18, Tiwei Bie wrote:
Signed-off-by: Tiwei Bie
---
drivers/virtio/virtio_ring.c | 699 +--
include/linux/virtio_ring.h | 8 +-
2 files changed, 618 insertions(+), 89 deletions(-)
diff --git a/drivers/virtio/virtio_ring.c
On 3/8/2018 5:17 PM, Tom Lendacky wrote:
> When using device passthrough with SME active, the MMIO range that is
> mapped for the device should not be mapped encrypted. Add a check in
> set_spte() to insure that a page is not mapped encrypted if that page
> is a device MMIO page as indicated by
On 3/8/2018 5:17 PM, Tom Lendacky wrote:
> When using device passthrough with SME active, the MMIO range that is
> mapped for the device should not be mapped encrypted. Add a check in
> set_spte() to insure that a page is not mapped encrypted if that page
> is a device MMIO page as indicated by
On 2018-03-15 16:27, Stefan Berger wrote:
> On 03/01/2018 02:41 PM, Richard Guy Briggs wrote:
> > Implement the proc fs write to set the audit container ID of a process,
> > emitting an AUDIT_CONTAINER record to document the event.
> >
> > This is a write from the container orchestrator task to a
On 2018-03-15 16:27, Stefan Berger wrote:
> On 03/01/2018 02:41 PM, Richard Guy Briggs wrote:
> > Implement the proc fs write to set the audit container ID of a process,
> > emitting an AUDIT_CONTAINER record to document the event.
> >
> > This is a write from the container orchestrator task to a
On Thu, Mar 15 2018, Randy Dunlap wrote:
> On 03/14/2018 04:24 PM, a...@linux-foundation.org wrote:
>> The mm-of-the-moment snapshot 2018-03-14-16-24 has been uploaded to
>>
>>http://www.ozlabs.org/~akpm/mmotm/
>
> (not from the mmotm patches, but in its linux-next.patch)
>
>
On Thu, Mar 15 2018, Randy Dunlap wrote:
> On 03/14/2018 04:24 PM, a...@linux-foundation.org wrote:
>> The mm-of-the-moment snapshot 2018-03-14-16-24 has been uploaded to
>>
>>http://www.ozlabs.org/~akpm/mmotm/
>
> (not from the mmotm patches, but in its linux-next.patch)
>
>
This removes the unused legacy clock code from arch/arm/mach-davinci/.
Signed-off-by: David Lechner
Reviewed-by: Sekhar Nori
---
v8 changes:
- none
v7 changes:
- none
v6 changes:
- none
arch/arm/mach-davinci/clock.c | 745
This removes the unused legacy clock code from arch/arm/mach-davinci/.
Signed-off-by: David Lechner
Reviewed-by: Sekhar Nori
---
v8 changes:
- none
v7 changes:
- none
v6 changes:
- none
arch/arm/mach-davinci/clock.c | 745
This removes the unused legacy clock init code from
arch/arm/mach-davinci/dm355.c.
Signed-off-by: David Lechner
Reviewed-by: Sekhar Nori
---
v8 changes:
- none
v7 changes:
- rebased
- add davinci prefix to commit message
v6 changes:
- rebased
This removes the unused legacy clock init code from
arch/arm/mach-davinci/dm355.c.
Signed-off-by: David Lechner
Reviewed-by: Sekhar Nori
---
v8 changes:
- none
v7 changes:
- rebased
- add davinci prefix to commit message
v6 changes:
- rebased
arch/arm/mach-davinci/dm355.c | 357
This adds device tree support to the davinci timer so that when clocks
are moved to device tree, the timer will still work.
Signed-off-by: David Lechner
---
v8 changes:
- none
v7 changes:
- add workaround for platform devices not available in early boot
v6 changes:
-
This adds device tree support to the davinci timer so that when clocks
are moved to device tree, the timer will still work.
Signed-off-by: David Lechner
---
v8 changes:
- none
v7 changes:
- add workaround for platform devices not available in early boot
v6 changes:
- none
This removes the unused legacy clock init code from
arch/arm/mach-davinci/dm646x.c.
Signed-off-by: David Lechner
Reviewed-by: Sekhar Nori
---
v8 changes:
- rebased
v7 changes:
- rebased
- add davinci prefix to commit message
v6 changes:
- rebased
This removes the unused legacy clock init code from
arch/arm/mach-davinci/dm646x.c.
Signed-off-by: David Lechner
Reviewed-by: Sekhar Nori
---
v8 changes:
- rebased
v7 changes:
- rebased
- add davinci prefix to commit message
v6 changes:
- rebased
arch/arm/mach-davinci/dm646x.c | 329
This removes the unused legacy USB and SATA clock init code from
arch/arm/mach-davinci/{devices,usb}-da8xx}.c.
Signed-off-by: David Lechner
Reviewed-by: Sekhar Nori
---
v8 changes:
- none
v7 changes:
- rebased
- add davinci prefix to commit message
-
This removes the unused legacy USB and SATA clock init code from
arch/arm/mach-davinci/{devices,usb}-da8xx}.c.
Signed-off-by: David Lechner
Reviewed-by: Sekhar Nori
---
v8 changes:
- none
v7 changes:
- rebased
- add davinci prefix to commit message
- mention SATA and USB in commit message
v6
This adds clock provider nodes for da850 and wires them up to all of the
devices.
Signed-off-by: David Lechner
---
v8 changes:
- fix typo in clock-names property of psc0
- added power-domains properties to nodes that define that property in their
device tree bindings
v7
This adds clock provider nodes for da850 and wires them up to all of the
devices.
Signed-off-by: David Lechner
---
v8 changes:
- fix typo in clock-names property of psc0
- added power-domains properties to nodes that define that property in their
device tree bindings
v7 changes:
- move
1 - 100 of 2482 matches
Mail list logo