Hi George,
On 05/06/2019 15:12, George Hung wrote:
> Add support for the Nuvoton NPCM7xx SoC EDAC driver
Could you say something about what the NPCM7xx SoC is, and what errors its
memory
controller can detect?
The commit message is for describing what/why this code was added.
Is this Cadence
Hey everyone,
I hope this is not going to start a trash fire.
While working on a new clone version I tried to find out what the
current naming conventions for syscall revisions is. I was told and
seemed to be able to confirm through the syscall list that revisions of
syscalls are for the most
On 6/6/19 11:32 AM, Waiman Long wrote:
> On 6/6/19 11:21 AM, Alex Kogan wrote:
Also, the paravirt code is under arch/x86, while CNA is generic (not
x86-specific). Do you still want to see CNA-related patching residing
under arch/x86?
We still need a config option
On Thu, Jun 06, 2019 at 10:27:43AM -0400, Jerome Glisse wrote:
> On Thu, Jun 06, 2019 at 11:16:44AM -0300, Jason Gunthorpe wrote:
> > On Mon, May 06, 2019 at 04:29:39PM -0700, rcampb...@nvidia.com wrote:
> > > From: Ralph Campbell
> > >
> > > There are no functional changes, just some coding
On Thu, Jun 06, 2019 at 10:20:40AM -0500, Jassi Brar wrote:
> On Thu, Jun 6, 2019 at 7:51 AM Sudeep Holla wrote:
>
> >
> > > BTW, this is not going to be the end of SCMI troubles (I believe
> > > that's what his client is). SCMI will eventually have to be broken up
> > > in layers (protocol and
Hi Linus,
please pull some additional fixes and cleanups for the parisc architecture from:
git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux.git
parisc-5.2-3
Changes include
- Fix crashes when accessing PCI devices on some machines like C240 and J5000.
The crashes were
Add csi node for i.MX6UL SoC.
Reviewed-by: Fabio Estevam
Signed-off-by: Sébastien Szymanski
---
Changes for v2:
- only "mclk" clock is required now.
arch/arm/boot/dts/imx6ul.dtsi | 9 +
1 file changed, 9 insertions(+)
diff --git a/arch/arm/boot/dts/imx6ul.dtsi
Standardize dump presentation for va, dma and da dumps by adding
"0x" prefix for virtual address.
Fixes: 276ec9934231("remoteproc: replace "%p" with "%pK"")
Signed-off-by: Arnaud Pouliquen
---
drivers/remoteproc/remoteproc_debugfs.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff
This adds documentation of device tree bindings for the
DesignWare IP reset controller.
Signed-off-by: Gustavo Pimentel
Signed-off-by: Luis Oliveira
---
Changelog
- Add active low configuration example
- Fix compatible string in the active high example
From: Gustavo Pimentel
The reset-simple driver can be now used on DesignWare IPs by
default by selecting the following compatible strings:
- snps,dw-high-reset for active high resets inputs
- snps,dw-low-reset for active low resets inputs
Signed-off-by: Gustavo Pimentel
Signed-off-by: Luis
On Wed, Jun 05, 2019 at 01:14:04PM -0700, Andy Lutomirski wrote:
>
>
> > On Jun 5, 2019, at 8:17 AM, Jarkko Sakkinen
> > wrote:
> >
> >> On Tue, Jun 04, 2019 at 10:10:22PM +, Xing, Cedric wrote:
> >> A bit off topic here. This mmap()/mprotect() discussion reminds me a
> >> question (guess
This patch series adds a reset-simple compatible string for DesignWare
IPs allowing active high and low resets inputs.
Also adds the corresponding documentation.
Gustavo Pimentel (1):
reset: Add DesignWare IP support to simple reset
Luis Oliveira (1):
dt-bindings: Document the DesignWare IP
On Sun, May 26, 2019 at 10:07:50AM +0530, Vidya Sagar wrote:
> Add support for Synopsys DesignWare core IP based PCIe host controller
> present in Tegra194 SoC.
>
> Signed-off-by: Vidya Sagar
> ---
> Changes since [v7]:
> * Addressed review comments from Thierry
>
> Changes since [v6]:
> *
On Thu, Jun 6, 2019 at 3:42 AM Jan Kara wrote:
>
> On Wed 05-06-19 18:45:33, ira.we...@intel.com wrote:
> > From: Ira Weiny
> >
> > ... V1,000,000 ;-)
> >
> > Pre-requisites:
> > John Hubbard's put_user_pages() patch series.[1]
> > Jan Kara's ext4_break_layouts() fixes[2]
> >
> >
On 6/6/19 9:58 AM, Srinivas Kandagatla wrote:
On 06/06/2019 15:28, Pierre-Louis Bossart wrote:
On 6/6/19 6:22 AM, Srinivas Kandagatla wrote:
multi bank switching code takes lock on condition but releases without
any check resulting in below warning.
This patch fixes this.
Question to make
06.06.2019 16:58, Bitan Biswas пишет:
>
>
> On 6/6/19 5:06 AM, Dmitry Osipenko wrote:
>> 06.06.2019 8:54, Bitan Biswas пишет:
>>> Post suspend I2C registers have power on reset values. Before any
>>> transfer initialize I2C registers to prevent I2C transfer timeout
>>> and implement suspend and
06.06.2019 17:02, Bitan Biswas пишет:
>
>
> On 6/6/19 4:39 AM, Dmitry Osipenko wrote:
>> 06.06.2019 10:35, Bitan Biswas пишет:
>>> Fix checkpatch.pl warning(s)/error(s)/check(s) in i2c-tegra.c
>>>
>>> Remove redundant BUG_ON calls or replace with WARN_ON_ONCE
>>> as needed. Replace BUG() with
On Sun, May 26, 2019 at 10:07:45AM +0530, Vidya Sagar wrote:
> Add support for Tegra194 PCIe controllers. These controllers are based
> on Synopsys DesignWare core IP.
>
> Signed-off-by: Vidya Sagar
> Reviewed-by: Rob Herring
Acked-by: Thierry Reding
signature.asc
Description: PGP signature
On 2019-06-05 11:27 p.m., Lee Jones wrote:
Without having the .of_full_name support, both MFD cells ended up
wrongly matching against the i2c@c device tree node since we just
picked the first one where of_compatible matched.
>>>
>>> What is contained in each of their resources?
On Wed, Jun 05, 2019 at 07:52:19AM -0700, Sean Christopherson wrote:
> At this point I don't see the access control stuff impacting the LKM
> decision.
>
> Irrespetive of the access control thing, there are (at least) two issues
> with using ACPI to probe the driver:
>
> - ACPI probing breaks
On 6/6/19 11:21 AM, Alex Kogan wrote:
>>> Also, the paravirt code is under arch/x86, while CNA is generic (not
>>> x86-specific). Do you still want to see CNA-related patching residing
>>> under arch/x86?
>>>
>>> We still need a config option (something like NUMA_AWARE_SPINLOCKS) to
>>> enable
On Sun, May 26, 2019 at 10:07:41AM +0530, Vidya Sagar wrote:
> Add extended configuration space capability search API using struct dw_pcie *
> pointer
>
> Signed-off-by: Vidya Sagar
> Acked-by: Gustavo Pimentel
> ---
> Changes since [v7]:
> * Changed data types of return and arguments to be
Hi Felipe,
>-Original Message-
>From: Felipe Balbi [mailto:ba...@kernel.org]
>Sent: Wednesday, June 5, 2019 1:34 PM
>To: Anurag Kumar Vulisha ; Greg Kroah-Hartman
>
>Cc: linux-...@vger.kernel.org; linux-kernel@vger.kernel.org;
>v.anuragku...@gmail.com; Anurag Kumar Vulisha
>Subject: Re:
Check SPP capability in MSR_IA32_VMX_PROCBASED_CTLS2, its 23-bit
indicates SPP support. Mark SPP bit in CPU capabilities bitmap if
it's supported.
Signed-off-by: Yang Weijiang
---
arch/x86/include/asm/cpufeatures.h | 1 +
arch/x86/include/asm/vmx.h | 1 +
arch/x86/kernel/cpu/intel.c
SPPT is a 4-level paging structure similar to EPT, when SPP is
kicked for target physical page, bit 61 of the corresponding
EPT enty will be flaged, then SPPT is traversed with the gfn to
build up entries, the leaf entry of SPPT contains the access
bitmap for subpages inside the target 4KB
Signed-off-by: Yang Weijiang
---
Documentation/virtual/kvm/spp_kvm.txt | 216 ++
1 file changed, 216 insertions(+)
create mode 100644 Documentation/virtual/kvm/spp_kvm.txt
diff --git a/Documentation/virtual/kvm/spp_kvm.txt
b/Documentation/virtual/kvm/spp_kvm.txt
new
EPT-Based Sub-Page write Protection(SPP)is a HW capability which
allows Virtual Machine Monitor(VMM) to specify write-permission for
guest physical memory at a sub-page(128 byte) granularity. When this
capability is enabled, the CPU enforces write-access check for
sub-pages within a 4KB page.
The
User application, e.g., QEMU or VMI, must initialize SPP
before gets/sets SPP subpages, the dynamic initialization is to
reduce the extra storage cost if the SPP feature is not not used.
Signed-off-by: Yang Weijiang
---
arch/x86/kvm/x86.c | 90
Host page swapping/migration may change the translation in
EPT leaf entry, if the target page is SPP protected,
re-enable SPP protection in MMU notifier. If SPPT shadow
page is reclaimed, the level1 pages don't have rmap to clear.
Signed-off-by: Yang Weijiang
---
arch/x86/kvm/mmu.c | 22
init_spp() must be called before {get, set}_subpage
functions, it creates subpage access bitmaps for memory pages
and issues a KVM request to setup SPPT root pages.
kvm_mmu_set_subpages() is to enable SPP bit in EPT leaf page
and setup corresponding SPPT entries. The mmu_lock
is held before above
If write to subpage is not allowed, EPT violation is generated,
it's propagated to QEMU or VMI to handle.
If the target page is SPP protected, however SPPT missing is
encoutered while traversing with gfn, vmexit is generated so
that KVM can handle the issue. Any SPPT misconfig will be
propagated
If SPP subpages are set while the physical page are not
available in EPT leaf entry, the mapping is first stored
in SPP access bitmap buffer. SPPT setup is deferred to
access to the protected page, in EPT page fault handler,
the SPPT enries are set up.
Signed-off-by: Yang Weijiang
---
Create access bitmap for SPP subpages, 4KB/128B = 32bits,
for each 4KB physical page, 32bits are required. The bitmap can
be easily accessed with a gfn. The initial access bitmap for each
physical page is 0x, meaning SPP is not enabled for the
subpages.
Signed-off-by: Yang Weijiang
---
On Thu, Jun 06, 2019 at 05:27:46PM +0200, Greg KH wrote:
> On Thu, Jun 06, 2019 at 03:16:03PM +0200, Rolf Eike Beer wrote:
> > I have at least these 2 instances:
> >
> >
> > In file included from
> > /tmp/e2/build/linux-4.9.180/include/drm/drm_vma_manager.h:28,
> > from
On Mon, Jun 03, 2019 at 09:29:44PM +0800, Peter Xu wrote:
> get_target_base() in the timer code is not using the "base" parameter
> at all. My gut feeling is that instead of removing that extra
> parameter, what we really want to do is "return the old base if it
> does not suite for a new one".
On Thu, Jun 06, 2019 at 03:16:03PM +0200, Rolf Eike Beer wrote:
> I have at least these 2 instances:
>
>
> In file included from
> /tmp/e2/build/linux-4.9.180/include/drm/drm_vma_manager.h:28,
> from /tmp/e2/build/linux-4.9.180/include/drm/drmP.h:78,
> from
>
On Thu, 2019-06-06 at 17:09 +0200, Jessica Yu wrote:
> +++ Matthias Schiffer [03/06/19 12:57 +0200]:
> > Some archs like ARM store unwind information for .exit.text in
> > sections
> > with unusual names. As this unwind information refers to
> > .exit.text, it
> > must not be loaded when
On 31-May-2019 05:08:16 PM, Julien Desfossez wrote:
> > My first reaction is: when shell wakes up from sleep, it will
> > fork date. If the script is untagged and those workloads are
> > tagged and all available cores are already running workload
> > threads, the forked date can lose to the
On 06.06.2019 18:18, Dmitry Vyukov wrote:
> On Thu, Jun 6, 2019 at 4:54 PM Kirill Tkhai wrote:
>>
>> On 06.06.2019 17:40, Dmitry Vyukov wrote:
>>> On Thu, Jun 6, 2019 at 3:43 PM Kirill Tkhai wrote:
On 06.06.2019 16:13, J. Bruce Fields wrote:
> On Thu, Jun 06, 2019 at 10:47:43AM
These function do not prepare the entire state of the vmcs02, only the
rarely needed parts. Rename them to make this clearer.
Signed-off-by: Paolo Bonzini
---
arch/x86/kvm/vmx/nested.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/x86/kvm/vmx/nested.c
>> Also, the paravirt code is under arch/x86, while CNA is generic (not
>> x86-specific). Do you still want to see CNA-related patching residing
>> under arch/x86?
>>
>> We still need a config option (something like NUMA_AWARE_SPINLOCKS) to
>> enable CNA patching under this config only, correct?
+++ Matthias Schiffer [06/06/19 10:14 +0200]:
On Mon, 2019-06-03 at 12:57 +0200, Matthias Schiffer wrote:
For some time (050d18d1c651 "ARM: 8650/1: module: handle negative
R_ARM_PREL31 addends correctly", v4.11+), building a kernel without
CONFIG_MODULE_UNLOAD would lead to module loads failing
On Thu, Jun 6, 2019 at 7:51 AM Sudeep Holla wrote:
>
> > BTW, this is not going to be the end of SCMI troubles (I believe
> > that's what his client is). SCMI will eventually have to be broken up
> > in layers (protocol and transport) for many legit platforms to use it.
> > That is
On Thu, Jun 6, 2019 at 4:54 PM Kirill Tkhai wrote:
>
> On 06.06.2019 17:40, Dmitry Vyukov wrote:
> > On Thu, Jun 6, 2019 at 3:43 PM Kirill Tkhai wrote:
> >>
> >> On 06.06.2019 16:13, J. Bruce Fields wrote:
> >>> On Thu, Jun 06, 2019 at 10:47:43AM +0300, Kirill Tkhai wrote:
> This may be
06.06.2019 17:25, Jon Hunter пишет:
>
>
> On 06/06/2019 14:45, Dmitry Osipenko wrote:
>> 06.06.2019 15:37, Jon Hunter пишет:
>>>
>>> On 06/06/2019 12:54, Peter Ujfalusi wrote:
On 06/06/2019 13.49, Jon Hunter wrote:
>
> On 06/06/2019 11:22, Peter Ujfalusi wrote:
>
>
On Thu, 2019-06-06 at 12:14 +0200, Sebastian Gottschall wrote:
> in addition you should take care about this problem which is raised up
> if SAE is used. since AES-CMAC required tid to be non zero
>
> WARNING: CPU: 2 PID: 15324 at
>
On Thu, 6 Jun 2019 17:12:03 +0200
Vitor Soares wrote:
> This helper return the i3c_device_id structure in order the client
> have access to the driver data.
>
> Signed-off-by: Vitor Soares
> ---
> Changes in v2:
> move this function to drivers/i3c/device.c
>
> drivers/i3c/device.c |
Hi Linus,
Here are a couple more bug fixes for 5.2. They've survived a few days
of fstests and merge cleanly with upstream as of a few minutes ago. Let
me know if there are problems.
--D
The following changes since commit 5cd213b0fec640a46adc5e6e4dfc7763aa54b3b2:
xfs: don't reserve per-AG
On Tue, Jun 04, 2019 at 02:29:31PM +0800, Peter Xu wrote:
> On Mon, Apr 15, 2019 at 05:12:15PM -0300, Marcelo Tosatti wrote:
> > Check base->pending_map locklessly and skip raising timer softirq
> > if empty.
> >
> > What allows the lockless (and potentially racy against mod_timer)
> > check is
Update the code to use a flexible array member instead of a pointer in
structure i2c_mux_pinctrl and use the struct_size() helper:
struct tb10x_pinctrl {
...
struct tb10x_of_pinfunc pinfuncs[];
};
Also, make use of the struct_size() helper instead of an open-coded
version in
Add basic support for i3c bus.
This is a simple implementation that only give support
for SDR Read and Write commands.
Signed-off-by: Vitor Soares
---
Changes in v2:
None
drivers/base/regmap/Kconfig | 6 +++-
drivers/base/regmap/Makefile | 1 +
drivers/base/regmap/regmap-i3c.c |
This patch series add i3c support for STM LSM6DSO and LSM6DSR sensors.
It is also introduced i3c support on regmap api. Due the lack of
i3c devices HDR capables on the market the support for now is only for
i3c sdr mode by using i3c_device_do_priv_xfers() method.
Changes in v2:
Change
This helper return the i3c_device_id structure in order the client
have access to the driver data.
Signed-off-by: Vitor Soares
---
Changes in v2:
move this function to drivers/i3c/device.c
drivers/i3c/device.c | 8
include/linux/i3c/device.h | 1 +
2 files changed, 9
For today the st_lsm6dsx driver support LSM6DSO and LSM6DSR sensor only in
spi and i2c mode.
The LSM6DSO and LSM6DSR are also i3c capable so lets give i3c support to
them.
Signed-off-by: Vitor Soares
---
Changes in v2:
Add support for LSM6DSR
Set pm_ops to st_lsm6dsx_pm_ops
I was able to test the patch [1] exclusion mechanism without access to actual
hardware - by giving it a dummy regmap. See patch below.
Test cases (all via sysfs):
1. verify requested pwm cannot be requested as gpio
2. verify requested gpio cannot be requested as pwm
3. verify pwm "all LEDs"
+++ Matthias Schiffer [03/06/19 12:57 +0200]:
Some archs like ARM store unwind information for .exit.text in sections
with unusual names. As this unwind information refers to .exit.text, it
must not be loaded when .exit.text is not loaded (when CONFIG_MODULE_UNLOAD
is unset); otherwise, loading
Andy Lutomirski wrote:
> > So that the LSM can see the credentials of the last process to do an fput()
> > on a file object when the file object is being dismantled, do the following
> > steps:
> >
>
> I still maintain that this is a giant design error.
Yes, I know. This was primarily a post
My name is Ann Hester, please reply me.
From: Enrico Weigelt
The MODULE_DEVICE_TABLE() macro already checks for MODULE defined,
so the extra check here is not necessary.
Changes v2:
* make dptids const to fix warning on unused variable
Signed-off-by: Enrico Weigelt
---
drivers/scsi/BusLogic.c | 2 --
drivers/scsi/dpt_i2o.c |
Hi Sylwester,
On 6/6/19 3:57 PM, Sylwester Nawrocki wrote:
> On 6/5/19 18:53, Lukasz Luba wrote:
>> Lukasz Luba (13):
>>clk: samsung: add needed IDs for DMC clocks in Exynos5420
>>clk: samsung: add new clocks for DMC for Exynos5422 SoC
>>clk: samsung: add BPLL rate table for Exynos
On 06/06/2019 15:28, Pierre-Louis Bossart wrote:
On 6/6/19 6:22 AM, Srinivas Kandagatla wrote:
multi bank switching code takes lock on condition but releases without
any check resulting in below warning.
This patch fixes this.
Question to make sure we are talking about the same thing:
On Thu, 6 Jun 2019 15:13:00 +0200
Pavel Machek wrote:
> (stable removed from cc list)
>
> > Indio->mlock is used for protecting the different iio device modes.
> > It is currently not being used in this way. Replace the lock with
> > an internal lock specifically used for protecting the SPI
On 06.06.2019 17:40, Dmitry Vyukov wrote:
> On Thu, Jun 6, 2019 at 3:43 PM Kirill Tkhai wrote:
>>
>> On 06.06.2019 16:13, J. Bruce Fields wrote:
>>> On Thu, Jun 06, 2019 at 10:47:43AM +0300, Kirill Tkhai wrote:
This may be connected with that shrinker unregistering is forgotten on
syzbot has bisected this bug to:
commit e9db4ef6bf4ca9894bb324c76e01b8f1a16b2650
Author: John Fastabend
Date: Sat Jun 30 13:17:47 2018 +
bpf: sockhash fix omitted bucket lock in sock_close
bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=111ccbbaa0
start commit:
Hi Pali,
On Wed, 5 Jun 2019 00:33:03 +0200, Pali Rohár wrote:
> Dell platform team told us that some (DMI whitelisted) Dell Latitude
> machines have ST microelectronics accelerometer at I2C address 0x29.
>
> Presence of that ST microelectronics accelerometer is verified by existence
> of
On Mon, May 06, 2019 at 04:29:37PM -0700, rcampb...@nvidia.com wrote:
> From: Ralph Campbell
>
> I hit a use after free bug in hmm_free() with KASAN and then couldn't
> stop myself from cleaning up a bunch of documentation and coding style
> changes. So the first two patches are clean ups, the
On Mon, May 06, 2019 at 04:29:41PM -0700, rcampb...@nvidia.com wrote:
> From: Ralph Campbell
>
> The helper function hmm_vma_fault() calls hmm_range_register() but is
> missing a call to hmm_range_unregister() in one of the error paths.
> This leads to a reference count leak and ultimately a
Fix sparse warning:
drivers/net/ethernet/mscc/ocelot_ace.c:96:3:
warning: symbol 'vcap_data_t' was not declared. Should it be static?
'vcap_data_t' never used so can be removed
Reported-by: Hulk Robot
Signed-off-by: YueHaibing
---
drivers/net/ethernet/mscc/ocelot_ace.c | 2 +-
1 file
On 06/06/2019 15:36, Dmitry Osipenko wrote:
> 06.06.2019 17:26, Jon Hunter пишет:
>>
>> On 06/06/2019 14:55, Dmitry Osipenko wrote:
>>> 06.06.2019 16:45, Dmitry Osipenko пишет:
06.06.2019 15:37, Jon Hunter пишет:
>
> On 06/06/2019 12:54, Peter Ujfalusi wrote:
>>
>>
>> On
On Thu, Jun 06, 2019 at 11:26:44AM -0300, Arnaldo Carvalho de Melo wrote:
> Em Thu, May 30, 2019 at 02:29:22PM +0100, ufo19890607 escreveu:
> > From: yuzhoujian
> >
> > One can just record callchains in the kernel or user space with
> > this new options. We can use it together with
Em Thu, Jun 06, 2019 at 10:12:31PM +0800, Leo Yan escreveu:
> Hi Arnaldo,
>
> On Thu, Jun 06, 2019 at 10:38:38AM -0300, Arnaldo Carvalho de Melo wrote:
> > Em Thu, Jun 06, 2019 at 05:48:44PM +0800, Leo Yan escreveu:
> > > This patch adds support for arm64 raw syscall numbers so that we can use
>
From: Enrico Weigelt
fix an uninitialized variable:
CC net/ipv4/fib_semantics.o
net/ipv4/fib_semantics.c: In function 'fib_check_nh_v4_gw':
net/ipv4/fib_semantics.c:1027:12: warning: 'err' may be used uninitialized in
this function [-Wmaybe-uninitialized]
if (!tbl || err) {
On Thu, 2019-06-06 at 16:22 +0200, Nicolas Saenz Julienne wrote:
> Raspberry Pi's firmware offers an interface though which update it's
> clock's frequencies. This is specially useful in order to change the CPU
> clock (pllb_arm) which is 'owned' by the firmware and we're unable to
> scale using
On Thu, Jun 6, 2019 at 3:52 PM syzbot
wrote:
>
> Hello,
>
> syzbot found the following crash on:
>
> HEAD commit:156c0591 Merge tag 'linux-kselftest-5.2-rc4' of git://git...
> git tree: upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=13512d51a0
> kernel config:
On Thu, Jun 6, 2019 at 3:52 PM syzbot
wrote:
>
> Hello,
>
> syzbot found the following crash on:
>
> HEAD commit:156c0591 Merge tag 'linux-kselftest-5.2-rc4' of git://git...
> git tree: upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=15f2095aa0
> kernel config:
On Thu, Jun 6, 2019 at 3:43 PM Kirill Tkhai wrote:
>
> On 06.06.2019 16:13, J. Bruce Fields wrote:
> > On Thu, Jun 06, 2019 at 10:47:43AM +0300, Kirill Tkhai wrote:
> >> This may be connected with that shrinker unregistering is forgotten on
> >> error path.
> >
> > I was wondering about that
On 6/4/19 3:14 AM, Krzysztof Kozlowski wrote:
> Remove the CONFIG_UEVENT_HELPER_PATH because:
> 1. It is disabled since commit 1be01d4a5714 ("driver: base: Disable
>CONFIG_UEVENT_HELPER by default") as its dependency (UEVENT_HELPER) was
>made default to 'n',
> 2. It is not recommended
06.06.2019 17:26, Jon Hunter пишет:
>
> On 06/06/2019 14:55, Dmitry Osipenko wrote:
>> 06.06.2019 16:45, Dmitry Osipenko пишет:
>>> 06.06.2019 15:37, Jon Hunter пишет:
On 06/06/2019 12:54, Peter Ujfalusi wrote:
>
>
> On 06/06/2019 13.49, Jon Hunter wrote:
>>
>> On
On 06/06/2019 15:26, Jon Hunter wrote:
...
>>> If I understood everything correctly, the FIFO buffer is shared among
>>> all of the ADMA clients and hence it should be up to the ADMA driver to
>>> manage the quotas of the clients. So if there is only one client that
>>> uses ADMA at a time,
Cleaned up the code to remove the error "(foo*)" should be "(foo *)"
reported by checkpatch from the file rtl8723bs/os_dep/ioctl_linux.c
Signed-off-by: Shobhit Kukreti
---
Changes in v2:
- Modified commit message to include reported ERROR by checkpatch
On Wed, Jun 05, 2019 at 01:38:38PM -0700, Guenter Roeck wrote:
> On Wed, May 29, 2019 at 07:56:05PM -0700, Eduardo Valentin wrote:
> > When registering a hwmon device with HWMON_C_REGISTER_TZ flag
> > in place, the hwmon subsystem will attempt to register the device
> > also with the thermal
On Thu, Jun 06, 2019 at 11:08:00AM -0300, Arnaldo Carvalho de Melo wrote:
> Em Thu, Jun 06, 2019 at 05:48:45PM +0800, Leo Yan escreveu:
> > To build this program successfully with clang, there have three
> > compiler options need to be specified:
> >
> > - Header file path:
This enables both the new firmware clock driver and cpufreq driver
available for the RPi3 family of boards.
Signed-off-by: Nicolas Saenz Julienne
---
arch/arm64/configs/defconfig | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
As 'clk-raspberrypi' depends on RPi's firmware interface, which might be
configured as a module, the cpu clock might not be available for the
cpufreq driver during it's init process. So we register the
'raspberrypi-cpufreq' platform device after the probe sequence succeeds.
Signed-off-by: Nicolas
This enables on both multi_v7_defconfig and bcm2835_defconfig the new
firmware based clock and cpufreq drivers for the Raspberry Pi platform.
In the case of bcm2835_defconfig, as the cpufreq subsystem was disabled,
the subsystem configuration was copied from multi_v7_defconfig (default
governor,
Raspberry Pi's firmware offers and interface though which update it's
performance requirements. It allows us to request for specific runtime
frequencies, which the firmware might or might not respect, depending on
the firmware configuration and thermals.
As the maximum and minimum frequencies are
On Thu, Jun 6, 2019 at 1:07 AM Benjamin Tissoires
wrote:
>
> On Thu, Jun 6, 2019 at 1:25 AM Jeffrey Hugo wrote:
> >
> > On Tue, May 21, 2019 at 10:42 AM Bjorn Andersson
> > wrote:
> > >
> > > On Tue 23 Apr 09:06 PDT 2019, Jeffrey Hugo wrote:
> > >
> > > > There needs to be coordination between
Em Thu, Jun 06, 2019 at 11:26:44AM -0300, Arnaldo Carvalho de Melo escreveu:
> Em Thu, May 30, 2019 at 02:29:22PM +0100, ufo19890607 escreveu:
> > From: yuzhoujian
> >
> > One can just record callchains in the kernel or user space with
> > this new options. We can use it together with
On 6/6/19 6:22 AM, Srinivas Kandagatla wrote:
multi bank switching code takes lock on condition but releases without
any check resulting in below warning.
This patch fixes this.
Question to make sure we are talking about the same thing: multi-link
bank switching is a capability beyond the
Since clk-raspberrypi is tied to the VC4 firmware instead of particular
hardware it's registration should be performed by the firmware driver.
Signed-off-by: Nicolas Saenz Julienne
Acked-by: Eric Anholt
---
drivers/firmware/raspberrypi.c | 10 ++
1 file changed, 10 insertions(+)
diff
Raspberry Pi's firmware offers an interface though which update it's
clock's frequencies. This is specially useful in order to change the CPU
clock (pllb_arm) which is 'owned' by the firmware and we're unable to
scale using the register interface provided by clk-bcm2835.
Signed-off-by: Nicolas
On Thu, Jun 06, 2019 at 11:16:44AM -0300, Jason Gunthorpe wrote:
> On Mon, May 06, 2019 at 04:29:39PM -0700, rcampb...@nvidia.com wrote:
> > From: Ralph Campbell
> >
> > There are no functional changes, just some coding style clean ups and
> > minor comment changes.
> >
> > Signed-off-by: Ralph
Em Thu, May 30, 2019 at 02:29:22PM +0100, ufo19890607 escreveu:
> From: yuzhoujian
>
> One can just record callchains in the kernel or user space with
> this new options. We can use it together with "--all-kernel" options.
> This two options is used just like print_stack(sys) or
On 06/06/2019 14:55, Dmitry Osipenko wrote:
> 06.06.2019 16:45, Dmitry Osipenko пишет:
>> 06.06.2019 15:37, Jon Hunter пишет:
>>>
>>> On 06/06/2019 12:54, Peter Ujfalusi wrote:
On 06/06/2019 13.49, Jon Hunter wrote:
>
> On 06/06/2019 11:22, Peter Ujfalusi wrote:
>
On 5/29/19 2:15 PM, Atish Patra wrote:
Both RISC-V & ARM64 are using cpu-map device tree to describe
their cpu topology. It's better to move the relevant code to
a common place instead of duplicate code.
To: Will Deacon
To: Catalin Marinas
Signed-off-by: Atish Patra
[Tested on QDF2400]
On Thu, Jun 6, 2019 at 2:13 AM Lee Jones wrote:
>
> On Thu, 06 Jun 2019, Bjorn Andersson wrote:
>
> > On Wed 05 Jun 22:50 PDT 2019, Lee Jones wrote:
> >
> > > On Tue, 23 Apr 2019, Jeffrey Hugo wrote:
> > >
> > > > This adds the initial DT for the Lenovo Miix 630 laptop. Supported
> > > >
On Tue, May 21, 2019 at 07:40:35AM -0500, Eric W. Biederman wrote:
>
> The usb support for asyncio encoded one of it's values in the wrong
> field. It should have used si_value but instead used si_addr which is
> not present in the _rt union member of struct siginfo.
>
> The practical result of
On 06/06/2019 14:45, Dmitry Osipenko wrote:
> 06.06.2019 15:37, Jon Hunter пишет:
>>
>> On 06/06/2019 12:54, Peter Ujfalusi wrote:
>>>
>>>
>>> On 06/06/2019 13.49, Jon Hunter wrote:
On 06/06/2019 11:22, Peter Ujfalusi wrote:
...
It does sounds like that
On 5/29/19 2:15 PM, Atish Patra wrote:
Currently, ARM32 and ARM64 uses different data structures to represent
their cpu topologies. Since, we are moving the ARM64 topology to common
code to be used by other architectures, we can reuse that for ARM32 as
well.
Take this opprtunity to remove the
hey Colin,
On Fri, May 31, 2019 at 11:57:08AM +0100, Colin King wrote:
> From: Colin Ian King
>
> The u32 variable hw_id is unsigned and cannot be less than zero so
> the comparison with less than zero is always false and hence is redundant
> and can be removed.
>
> Addresses-Coverity:
401 - 500 of 941 matches
Mail list logo
