From: Yong Zhao
[ Upstream commit 44d8cc6f1a905e4bb1d4221a898abb0d7e9d100a ]
Because CRAT_CU_FLAGS_IOMMU_PRESENT was not set in some BIOS crat, we
need to workaround this.
For future compatibility, we also overwrite the bit in capability according
to the value of needs_iommu_device.
Acked-by:
From: Simon Detheridge
[ Upstream commit 8e2aac333785f91ff74e219a1e78e6bdc1ef2c41 ]
The gpio base for GPP-E was set incorrectly to 258 instead of 256,
preventing the touchpad working on my Tong Fang GK5CN5Z laptop.
Buglink: https://bugzilla.kernel.org/show_bug.cgi?id=200787
Signed-off-by:
From: Hans de Goede
[ Upstream commit 648e921888ad96ea3dc922739e96716ad3225d7f ]
Commit d31fd43c0f9a ("clk: x86: Do not gate clocks enabled by the
firmware"), which added the code to mark clocks as CLK_IS_CRITICAL, causes
all unclaimed PMC clocks on Cherry Trail devices to be on all the time,
The previous fix was incorrect, and now we get a build failure
without CONFIG_DEBUG_FS:
drivers/interconnect/core.c: In function 'icc_init':
drivers/interconnect/core.c:710:32: error: 'icc_summary_fops' undeclared (first
use in this function)
Removing the last #ifdef as well makes it all work
From: Vitaly Kuznetsov
[ Upstream commit d1766202779e81d0f2a94c4650a6ba31497d369d ]
When VMX is used with flexpriority disabled (because of no support or
if disabled with module parameter) MMIO interface to lAPIC is still
available in x2APIC mode while it shouldn't be (kvm-unit-tests):
PASS:
From: Vitaly Kuznetsov
[ Upstream commit d1766202779e81d0f2a94c4650a6ba31497d369d ]
When VMX is used with flexpriority disabled (because of no support or
if disabled with module parameter) MMIO interface to lAPIC is still
available in x2APIC mode while it shouldn't be (kvm-unit-tests):
PASS:
From: Richard Weinberger
[ Upstream commit 37f31b6ca4311b94d985fb398a72e5399ad57925 ]
The requested device name can be NULL or an empty string.
Check for that and refuse to continue. UBIFS has to do this manually
since we cannot use mount_bdev(), which checks for this condition.
Fixes:
From: Richard Weinberger
[ Upstream commit 37f31b6ca4311b94d985fb398a72e5399ad57925 ]
The requested device name can be NULL or an empty string.
Check for that and refuse to continue. UBIFS has to do this manually
since we cannot use mount_bdev(), which checks for this condition.
Fixes:
From: Guenter Roeck
[ Upstream commit f6de298806d9cbc63a4907bca34a06162b9d7dce ]
fan7 on NCT6796D does not have a fan count register; it only has an RPM
register. Switch to using RPM registers to read the fan speed for all
chips supporting it to solve the problem for good.
Reported-by: Robert
From: Guenter Roeck
[ Upstream commit f6de298806d9cbc63a4907bca34a06162b9d7dce ]
fan7 on NCT6796D does not have a fan count register; it only has an RPM
register. Switch to using RPM registers to read the fan speed for all
chips supporting it to solve the problem for good.
Reported-by: Robert
From: Yong Zhao
[ Upstream commit 15426dbb65c5b37680d27e84d58a1ed3b8532518 ]
CWSR fails on Raven if the control stack is MTYPE_UC, which is used
for regular GART mappings. As a workaround we map it using MTYPE_NC.
The MEC firmware expects the control stack at one page offset from the
start of
From: Roman Gushchin
[ Upstream commit 172b06c32b949759fe6313abec514bc4f15014f4 ]
9092c71bb724 ("mm: use sc->priority for slab shrink targets") changed the
way that the target slab pressure is calculated and made it
priority-based:
delta = freeable >> priority;
delta *= 4;
From: Yong Zhao
[ Upstream commit 15426dbb65c5b37680d27e84d58a1ed3b8532518 ]
CWSR fails on Raven if the control stack is MTYPE_UC, which is used
for regular GART mappings. As a workaround we map it using MTYPE_NC.
The MEC firmware expects the control stack at one page offset from the
start of
From: Roman Gushchin
[ Upstream commit 172b06c32b949759fe6313abec514bc4f15014f4 ]
9092c71bb724 ("mm: use sc->priority for slab shrink targets") changed the
way that the target slab pressure is calculated and made it
priority-based:
delta = freeable >> priority;
delta *= 4;
From: Amber Lin
[ Upstream commit caaa4c8a6be2a275bd14f2369ee364978ff74704 ]
A wrong register bit was examinated for checking SDMA status so it reports
false failures. This typo only appears on gfx_v7. gfx_v8 checks the correct
bit.
Acked-by: Alex Deucher
Signed-off-by: Amber Lin
From: Amber Lin
[ Upstream commit caaa4c8a6be2a275bd14f2369ee364978ff74704 ]
A wrong register bit was examinated for checking SDMA status so it reports
false failures. This typo only appears on gfx_v7. gfx_v8 checks the correct
bit.
Acked-by: Alex Deucher
Signed-off-by: Amber Lin
From: Nicolas Ferre
[ Upstream commit eb4ed8e2d7fecb5f40db38e4498b9ee23cddf196 ]
Create a new configuration for the sama5d3-macb new compatibility string.
This configuration disables scatter-gather because we experienced lock down
of the macb interface of this particular SoC under very high
From: Nicolas Ferre
[ Upstream commit eb4ed8e2d7fecb5f40db38e4498b9ee23cddf196 ]
Create a new configuration for the sama5d3-macb new compatibility string.
This configuration disables scatter-gather because we experienced lock down
of the macb interface of this particular SoC under very high
From: Matias Karhumaa
[ Upstream commit 4ba5175f2c10affd412fa41855cecda02b66cd71 ]
In case local OOB data was generated and other device initiated pairing
claiming that it has got OOB data, following crash occurred:
[ 222.847853] general protection fault: [#1] SMP PTI
[ 222.848025] CPU:
From: Pierre-Louis Bossart
[ Upstream commit 960cdd50ca9fdfeb82c2757107bcb7f93c8d7d41 ]
HID made of either Wolfson/CirrusLogic PCI ID + 8804 identifier.
This helps enumerate the HifiBerry Digi+ HAT boards on the Up2 platform.
The scripts at https://github.com/thesofproject/acpi-scripts can be
From: Matias Karhumaa
[ Upstream commit 4ba5175f2c10affd412fa41855cecda02b66cd71 ]
In case local OOB data was generated and other device initiated pairing
claiming that it has got OOB data, following crash occurred:
[ 222.847853] general protection fault: [#1] SMP PTI
[ 222.848025] CPU:
From: Pierre-Louis Bossart
[ Upstream commit 960cdd50ca9fdfeb82c2757107bcb7f93c8d7d41 ]
HID made of either Wolfson/CirrusLogic PCI ID + 8804 identifier.
This helps enumerate the HifiBerry Digi+ HAT boards on the Up2 platform.
The scripts at https://github.com/thesofproject/acpi-scripts can be
From: Ryan Lee
[ Upstream commit 0d22825255f25adb6a609f130b42c752d3fd0f5d ]
Signed-off-by: Ryan Lee
Signed-off-by: Mark Brown
Signed-off-by: Sasha Levin
---
sound/soc/codecs/max98373.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/sound/soc/codecs/max98373.c
From: Johan Hedberg
[ Upstream commit 94f14e4728125f979629b2b020d31cd718191626 ]
A remote device may claim that it has received our OOB data, even
though we never geneated it. Add a new flag to track whether we
actually have OOB data, and ignore the remote peer's flag if haven't
generated OOB
From: Tushar Dave
[ Upstream commit 4c3d795cb012a378855543a775408fba1ccff6f2 ]
Helper bpg_msg_pull_data() can allocate multiple pages while
linearizing multiple scatterlist elements into one shared page.
However, if the shared page has size > PAGE_SIZE, using
copy_page_to_iter() causes below
From: Nicholas Piggin
[ Upstream commit 71d29f43b6332badc5598c656616a62575e83342 ]
THP paths can defer splitting compound pages until after the actual
remap and TLB flushes to split a huge PMD/PUD. This causes radix
partition scope page table mappings to get out of synch with the host
qemu page
From: Ryan Lee
[ Upstream commit 0d22825255f25adb6a609f130b42c752d3fd0f5d ]
Signed-off-by: Ryan Lee
Signed-off-by: Mark Brown
Signed-off-by: Sasha Levin
---
sound/soc/codecs/max98373.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/sound/soc/codecs/max98373.c
From: Johan Hedberg
[ Upstream commit 94f14e4728125f979629b2b020d31cd718191626 ]
A remote device may claim that it has received our OOB data, even
though we never geneated it. Add a new flag to track whether we
actually have OOB data, and ignore the remote peer's flag if haven't
generated OOB
From: Tushar Dave
[ Upstream commit 4c3d795cb012a378855543a775408fba1ccff6f2 ]
Helper bpg_msg_pull_data() can allocate multiple pages while
linearizing multiple scatterlist elements into one shared page.
However, if the shared page has size > PAGE_SIZE, using
copy_page_to_iter() causes below
From: Nicholas Piggin
[ Upstream commit 71d29f43b6332badc5598c656616a62575e83342 ]
THP paths can defer splitting compound pages until after the actual
remap and TLB flushes to split a huge PMD/PUD. This causes radix
partition scope page table mappings to get out of synch with the host
qemu page
From: Guenter Roeck
[ Upstream commit c793279c77035053e67937f5743c6ebfc303e7c5 ]
Not all fans have a fan pulse register. This can result in reading
beyond the end of REG_FAN_PULSES and FAN_PULSE_SHIFT arrays,
and was reported by smatch as possible error.
1672 for (i = 0; i <
From: Guenter Roeck
[ Upstream commit c793279c77035053e67937f5743c6ebfc303e7c5 ]
Not all fans have a fan pulse register. This can result in reading
beyond the end of REG_FAN_PULSES and FAN_PULSE_SHIFT arrays,
and was reported by smatch as possible error.
1672 for (i = 0; i <
The newly added code fails to build when either SECMARK or
NETFILTER are disabled:
security/apparmor/lsm.c: In function 'apparmor_socket_sock_rcv_skb':
security/apparmor/lsm.c:1138:12: error: 'struct sk_buff' has no member named
'secmark'; did you mean 'mark'?
security/apparmor/lsm.c:1671:21:
The newly added code fails to build when either SECMARK or
NETFILTER are disabled:
security/apparmor/lsm.c: In function 'apparmor_socket_sock_rcv_skb':
security/apparmor/lsm.c:1138:12: error: 'struct sk_buff' has no member named
'secmark'; did you mean 'mark'?
security/apparmor/lsm.c:1671:21:
A randconfig build showed that two clk modules have no license tag:
WARNING: modpost: missing MODULE_LICENSE() in drivers/clk/keystone/gate.o
see include/linux/module.h for more information
WARNING: modpost: missing MODULE_LICENSE() in drivers/clk/keystone/pll.o
see include/linux/module.h for
A randconfig build showed that two clk modules have no license tag:
WARNING: modpost: missing MODULE_LICENSE() in drivers/clk/keystone/gate.o
see include/linux/module.h for more information
WARNING: modpost: missing MODULE_LICENSE() in drivers/clk/keystone/pll.o
see include/linux/module.h for
From: Adrian Hunter
With the "branches" export option, not all sample columns are exported.
However the unwanted columns are not at the end of the tuple, as assumed
by the code. Fix by taking the first 15 and last 3 values, instead of
the first 18.
Signed-off-by: Adrian Hunter
Cc: Jiri Olsa
From: Arnaldo Carvalho de Melo
When building in ClearLinux using 'make PYTHON=python3' with gcc 8.2.1
it fails with:
GEN /tmp/build/perf/python/perf.so
In file included from /usr/include/python3.7m/Python.h:126,
from /git/linux/tools/perf/util/python.c:2:
From: Adrian Hunter
Occasional export failures were found to be caused by truncating 64-bit
pointers to 32-bits. Fix by explicitly setting types for all ctype
arguments and results.
Signed-off-by: Adrian Hunter
Cc: Jiri Olsa
Cc: sta...@vger.kernel.org
Link:
From: Adrian Hunter
With the "branches" export option, not all sample columns are exported.
However the unwanted columns are not at the end of the tuple, as assumed
by the code. Fix by taking the first 15 and last 3 values, instead of
the first 18.
Signed-off-by: Adrian Hunter
Cc: Jiri Olsa
From: Arnaldo Carvalho de Melo
When building in ClearLinux using 'make PYTHON=python3' with gcc 8.2.1
it fails with:
GEN /tmp/build/perf/python/perf.so
In file included from /usr/include/python3.7m/Python.h:126,
from /git/linux/tools/perf/util/python.c:2:
From: Adrian Hunter
Occasional export failures were found to be caused by truncating 64-bit
pointers to 32-bits. Fix by explicitly setting types for all ctype
arguments and results.
Signed-off-by: Adrian Hunter
Cc: Jiri Olsa
Cc: sta...@vger.kernel.org
Link:
From: Milian Wolff
Only use the mapped IP to find inline frames, but keep using the
unmapped IP for the callchain cursor. This ensures we properly show the
unmapped IP when displaying a frame we received via the
dso__parse_addr_inlines API for a module which does not contain
sufficient debug
From: Milian Wolff
Only use the mapped IP to find inline frames, but keep using the
unmapped IP for the callchain cursor. This ensures we properly show the
unmapped IP when displaying a frame we received via the
dso__parse_addr_inlines API for a module which does not contain
sufficient debug
into perf/urgent
(2018-09-19 13:25:35 +0200)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux.git
tags/perf-urgent-for-mingo-4.19-20181005
for you to fetch changes up to 7a8a8fcf7b860e4b2d4edc787c844d41cad9dfcf:
perf record: Use unmapped IP
From: Milian Wolff
Fixes a crash when the report encounters an address that could not be
associated with an mmaped region:
#0 0x557bdc4a in callchain_srcline (ip=, sym=0x0, map=0x0) at util/machine.c:2329
#1 unwind_entry (entry=entry@entry=0x7fff9180,
into perf/urgent
(2018-09-19 13:25:35 +0200)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux.git
tags/perf-urgent-for-mingo-4.19-20181005
for you to fetch changes up to 7a8a8fcf7b860e4b2d4edc787c844d41cad9dfcf:
perf record: Use unmapped IP
From: Milian Wolff
Fixes a crash when the report encounters an address that could not be
associated with an mmaped region:
#0 0x557bdc4a in callchain_srcline (ip=, sym=0x0, map=0x0) at util/machine.c:2329
#1 unwind_entry (entry=entry@entry=0x7fff9180,
Em Fri, Oct 05, 2018 at 11:58:43AM -0400, Steven Rostedt escreveu:
> On Fri, 5 Oct 2018 12:47:40 -0300 Arnaldo Carvalho de Melo
> wrote:
> > > Yep, I've been looking at these. I'll need to add yet another version,
> > > so that we can have it for the external libtraceevent. I'll be sending
> > >
Em Fri, Oct 05, 2018 at 11:58:43AM -0400, Steven Rostedt escreveu:
> On Fri, 5 Oct 2018 12:47:40 -0300 Arnaldo Carvalho de Melo
> wrote:
> > > Yep, I've been looking at these. I'll need to add yet another version,
> > > so that we can have it for the external libtraceevent. I'll be sending
> > >
On Sat, 6 Oct 2018 00:03:58 +0800 (CST)
wrote:
> >Hi Peng,
>
> >On Sat, Oct 06, 2018 at 06:22:11AM +0800, Peng Hao wrote:
> >> find_lock_lowest_rq may or not releease rq lock when return
> >> lowest_rq=NULL, but it is fuzzy.
> >> If not releasing rq lock, it is unnecessary to re-call
> >>
On Sat, 6 Oct 2018 00:03:58 +0800 (CST)
wrote:
> >Hi Peng,
>
> >On Sat, Oct 06, 2018 at 06:22:11AM +0800, Peng Hao wrote:
> >> find_lock_lowest_rq may or not releease rq lock when return
> >> lowest_rq=NULL, but it is fuzzy.
> >> If not releasing rq lock, it is unnecessary to re-call
> >>
The previous patch introduced very large kernel stack usage and a Makefile
change to hide the warning about it.
>From what I can tell, a number of things went wrong here:
- The BCH_MAX_T constant was set to the maximum value for 'n',
not the maximum for 't', which is much smaller.
- The stack
On 10/04/2018 06:14 AM, Faiz Abbas wrote:
> Add information to document bindings for the MMC PHY
> on TI's AM654 devices.
>
> Signed-off-by: Faiz Abbas
> Signed-off-by: Sekhar Nori
> ---
> .../devicetree/bindings/phy/am654-mmc-phy.txt | 42 +++
> 1 file changed, 42
The previous patch introduced very large kernel stack usage and a Makefile
change to hide the warning about it.
>From what I can tell, a number of things went wrong here:
- The BCH_MAX_T constant was set to the maximum value for 'n',
not the maximum for 't', which is much smaller.
- The stack
On 10/04/2018 06:14 AM, Faiz Abbas wrote:
> Add information to document bindings for the MMC PHY
> on TI's AM654 devices.
>
> Signed-off-by: Faiz Abbas
> Signed-off-by: Sekhar Nori
> ---
> .../devicetree/bindings/phy/am654-mmc-phy.txt | 42 +++
> 1 file changed, 42
On Fri, 5 Oct 2018 12:47:40 -0300
Arnaldo Carvalho de Melo wrote:
> Em Fri, Oct 05, 2018 at 11:45:16AM -0400, Steven Rostedt escreveu:
> > On Fri, 5 Oct 2018 12:37:31 -0300
> > Arnaldo Carvalho de Melo wrote:
> >
> > > Em Fri, Oct 05, 2018 at 11:30:56AM -0400, Steven Rostedt escreveu:
> >
On Fri, 5 Oct 2018 12:47:40 -0300
Arnaldo Carvalho de Melo wrote:
> Em Fri, Oct 05, 2018 at 11:45:16AM -0400, Steven Rostedt escreveu:
> > On Fri, 5 Oct 2018 12:37:31 -0300
> > Arnaldo Carvalho de Melo wrote:
> >
> > > Em Fri, Oct 05, 2018 at 11:30:56AM -0400, Steven Rostedt escreveu:
> >
On Fri, Oct 5, 2018 at 5:07 PM Aleksa Sarai wrote:
> On 2018-10-04, Jann Horn wrote:
> > On Thu, Oct 4, 2018 at 6:26 PM Aleksa Sarai wrote:
> > > On 2018-09-29, Jann Horn wrote:
> > > > You attempt to open "C/../../etc/passwd" under the root "/A/B".
> > > > Something else concurrently moves
On Fri, Oct 5, 2018 at 5:07 PM Aleksa Sarai wrote:
> On 2018-10-04, Jann Horn wrote:
> > On Thu, Oct 4, 2018 at 6:26 PM Aleksa Sarai wrote:
> > > On 2018-09-29, Jann Horn wrote:
> > > > You attempt to open "C/../../etc/passwd" under the root "/A/B".
> > > > Something else concurrently moves
Hi,
On 05.10.2018 14:50, Alexey Budankov wrote:
>
> According to docs [1] ftruncate() does not advance file pos
> which is essential here.
>
Ideally, the both lseek() syscalls in every loop iteration can be
replaced by the only two syscalls just before and after the loop and
advancing
Hi,
On 05.10.2018 14:50, Alexey Budankov wrote:
>
> According to docs [1] ftruncate() does not advance file pos
> which is essential here.
>
Ideally, the both lseek() syscalls in every loop iteration can be
replaced by the only two syscalls just before and after the loop and
advancing
James Morris wrote:
> > + if (strcmp(encoding, "raw") == 0) {
> > + strcpy(alg_name, pkey->pkey_algo);
> > + return 0;
> > + }
>
> Can encoding here also be NULL to indicate raw? per patch 01:
Ummm... By the letter of the documentation, yes, though in practice it isn't
James Morris wrote:
> > + if (strcmp(encoding, "raw") == 0) {
> > + strcpy(alg_name, pkey->pkey_algo);
> > + return 0;
> > + }
>
> Can encoding here also be NULL to indicate raw? per patch 01:
Ummm... By the letter of the documentation, yes, though in practice it isn't
On 10/03/2018 12:06 PM, Vignesh R wrote:
> K3 devices have the same ECAP IP as OMAP SoC. Enable driver to be built
> for K3 devices.
>
> Signed-off-by: Vignesh R
> Signed-off-by: Sekhar Nori
> ---
> drivers/pwm/Kconfig | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git
On 10/03/2018 12:06 PM, Vignesh R wrote:
> K3 devices have the same ECAP IP as OMAP SoC. Enable driver to be built
> for K3 devices.
>
> Signed-off-by: Vignesh R
> Signed-off-by: Sekhar Nori
> ---
> drivers/pwm/Kconfig | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git
Currently the Switchtec quirk runs on all endpoints in the Switch
which includes all the upstream and downstream ports. Seeing these
other functions do not contain BARs the quirk fails when trying to
map the BAR and prints the error "Cannot iomap Switchtec device".
The user will see a few of these
Currently the Switchtec quirk runs on all endpoints in the Switch
which includes all the upstream and downstream ports. Seeing these
other functions do not contain BARs the quirk fails when trying to
map the BAR and prints the error "Cannot iomap Switchtec device".
The user will see a few of these
On Tue, Oct 02, 2018 at 01:47:33PM -0300, Rodrigo Exterckötter Tjäder wrote:
> > > > > About device tree overlays, I read overlay-notes.txt, but I went
> > > > > looking for an example with "git grep /plugin/ arch" and it came
> > > > > empty. Is this approach not used for other boards?
> > > >
>
On Tue, Oct 02, 2018 at 01:47:33PM -0300, Rodrigo Exterckötter Tjäder wrote:
> > > > > About device tree overlays, I read overlay-notes.txt, but I went
> > > > > looking for an example with "git grep /plugin/ arch" and it came
> > > > > empty. Is this approach not used for other boards?
> > > >
>
Em Fri, Oct 05, 2018 at 11:45:16AM -0400, Steven Rostedt escreveu:
> On Fri, 5 Oct 2018 12:37:31 -0300
> Arnaldo Carvalho de Melo wrote:
>
> > Em Fri, Oct 05, 2018 at 11:30:56AM -0400, Steven Rostedt escreveu:
> > > Bah, I now get warnings that sys_nerr and sys_errlist are deprecated.
> > >
> >
Em Fri, Oct 05, 2018 at 11:45:16AM -0400, Steven Rostedt escreveu:
> On Fri, 5 Oct 2018 12:37:31 -0300
> Arnaldo Carvalho de Melo wrote:
>
> > Em Fri, Oct 05, 2018 at 11:30:56AM -0400, Steven Rostedt escreveu:
> > > Bah, I now get warnings that sys_nerr and sys_errlist are deprecated.
> > >
> >
Hi Peng,
On Sat, Oct 06, 2018 at 06:22:11AM +0800, Peng Hao wrote:
> find_lock_lowest_rq may or not releease rq lock when return
> lowest_rq=NULL, but it is fuzzy.
> If not releasing rq lock, it is unnecessary to re-call
> pick_next_pushable_task.
IIRC, deadline.c uses a similar pattern (c.f.,
Hi Peng,
On Sat, Oct 06, 2018 at 06:22:11AM +0800, Peng Hao wrote:
> find_lock_lowest_rq may or not releease rq lock when return
> lowest_rq=NULL, but it is fuzzy.
> If not releasing rq lock, it is unnecessary to re-call
> pick_next_pushable_task.
IIRC, deadline.c uses a similar pattern (c.f.,
On Fri, 5 Oct 2018 12:37:31 -0300
Arnaldo Carvalho de Melo wrote:
> Em Fri, Oct 05, 2018 at 11:30:56AM -0400, Steven Rostedt escreveu:
> > Bah, I now get warnings that sys_nerr and sys_errlist are deprecated.
> >
> > OK, so going back to just using the racy strerror() should be good
> > enough,
On Fri, 5 Oct 2018 12:37:31 -0300
Arnaldo Carvalho de Melo wrote:
> Em Fri, Oct 05, 2018 at 11:30:56AM -0400, Steven Rostedt escreveu:
> > Bah, I now get warnings that sys_nerr and sys_errlist are deprecated.
> >
> > OK, so going back to just using the racy strerror() should be good
> > enough,
James Morris wrote:
> Perhaps I'm missing something here but why do you need the gotos vs. just
> breaking to this code?
Because at some point we might add support for some other public key
algorithm, such as EC. This makes it clearer that that piece of code is
specific to a certain set of
James Morris wrote:
> Perhaps I'm missing something here but why do you need the gotos vs. just
> breaking to this code?
Because at some point we might add support for some other public key
algorithm, such as EC. This makes it clearer that that piece of code is
specific to a certain set of
HI again!
On Fri, Oct 5, 2018 at 5:23 PM Boris Brezillon
wrote:
>
> On Fri, 5 Oct 2018 14:04:52 +0200
> Ricardo Ribalda Delgado wrote:
>
> > Hi Boris
> > On Fri, Oct 5, 2018 at 12:12 PM Boris Brezillon
> > wrote:
> > >
> > > On Fri, 5 Oct 2018 11:54:18 +0200
> > > Ricardo Ribalda Delgado
HI again!
On Fri, Oct 5, 2018 at 5:23 PM Boris Brezillon
wrote:
>
> On Fri, 5 Oct 2018 14:04:52 +0200
> Ricardo Ribalda Delgado wrote:
>
> > Hi Boris
> > On Fri, Oct 5, 2018 at 12:12 PM Boris Brezillon
> > wrote:
> > >
> > > On Fri, 5 Oct 2018 11:54:18 +0200
> > > Ricardo Ribalda Delgado
Hi Boris
On Fri, Oct 5, 2018 at 4:52 PM Boris Brezillon
wrote:
>
> On Fri, 5 Oct 2018 16:06:57 +0200
> Ricardo Ribalda Delgado wrote:
>
> > Hi again Boris
> >
> >
> > On Fri, Oct 5, 2018 at 2:10 PM Boris Brezillon
> > wrote:
> > >
> > > On Fri, 5 Oct 2018 14:04:52 +0200
> > > Ricardo Ribalda
Hi Boris
On Fri, Oct 5, 2018 at 4:52 PM Boris Brezillon
wrote:
>
> On Fri, 5 Oct 2018 16:06:57 +0200
> Ricardo Ribalda Delgado wrote:
>
> > Hi again Boris
> >
> >
> > On Fri, Oct 5, 2018 at 2:10 PM Boris Brezillon
> > wrote:
> > >
> > > On Fri, 5 Oct 2018 14:04:52 +0200
> > > Ricardo Ribalda
James Morris wrote:
> > + pr_devel("==>%s()\n", __func__);
>
> Are you planning on leaving these pr_devel()s in?
Well, they don't do anything unless you #define DEBUG at the top of the file.
If they really offend you, I can remove them.
David
James Morris wrote:
> > + pr_devel("==>%s()\n", __func__);
>
> Are you planning on leaving these pr_devel()s in?
Well, they don't do anything unless you #define DEBUG at the top of the file.
If they really offend you, I can remove them.
David
From: Maciej Purski
On Odroid XU3/4 and other Exynos5422 based boards there is a case, that
different devices on the board are supplied by different regulators
with non-fixed voltages. If one of these devices temporarily requires
higher voltage, there might occur a situation that the spread
From: Maciej Purski
On Odroid XU3/4 and other Exynos5422 based boards there is a case, that
different devices on the board are supplied by different regulators
with non-fixed voltages. If one of these devices temporarily requires
higher voltage, there might occur a situation that the spread
From: Maciej Purski
On Odroid XU3/4 and other Exynos5422 based boards there is a case, that
different devices on the board are supplied by different regulators
with non-fixed voltages. If one of these devices temporarily requires
higher voltage, there might occur a situation that the spread
From: Maciej Purski
On Odroid XU3/4 and other Exynos5422 based boards there is a case, that
different devices on the board are supplied by different regulators
with non-fixed voltages. If one of these devices temporarily requires
higher voltage, there might occur a situation that the spread
If registered regulator found a couple, then the couple can find the
registered regulator too and hence coupling can be mutually resolved
at the registration time.
Signed-off-by: Dmitry Osipenko
---
drivers/regulator/core.c | 54 +---
1 file changed, 17
If registered regulator found a couple, then the couple can find the
registered regulator too and hence coupling can be mutually resolved
at the registration time.
Signed-off-by: Dmitry Osipenko
---
drivers/regulator/core.c | 54 +---
1 file changed, 17
Don't allow to get regulator until all of its couples resolved because
consumer will get EPERM and coupling shall be transparent for the drivers.
Signed-off-by: Dmitry Osipenko
---
drivers/regulator/core.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drivers/regulator/core.c
Don't allow to get regulator until all of its couples resolved because
consumer will get EPERM and coupling shall be transparent for the drivers.
Signed-off-by: Dmitry Osipenko
---
drivers/regulator/core.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drivers/regulator/core.c
Check whether supply regulator is the couple to avoid infinite recursion
during of locking.
Signed-off-by: Dmitry Osipenko
---
drivers/regulator/core.c | 19 +--
1 file changed, 17 insertions(+), 2 deletions(-)
diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
Certain hardware may require supply voltage to be changed in steps. Define
new property that allow to describe such hardware.
Signed-off-by: Dmitry Osipenko
---
Documentation/devicetree/bindings/regulator/regulator.txt | 2 ++
1 file changed, 2 insertions(+)
diff --git
Regulators shall be uncoupled if one of the couples disappear.
Signed-off-by: Dmitry Osipenko
---
drivers/regulator/core.c | 38 ++
1 file changed, 38 insertions(+)
diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
index
Redefine binding for regulator-coupled-max-spread property in a way that
max-spread values are defined per regulator couple instead of defining
single max-spread for the whole group of coupled regulators.
With that change the following regulators coupling configuration will be
possible:
regA:
Device tree binding was changed in a way that now max-spread values must
be defied per regulator pair. Limit number of pairs in order to adapt to
the new binding without changing regulators code.
Signed-off-by: Dmitry Osipenko
---
include/linux/regulator/driver.h | 2 +-
1 file changed, 1
On NVIDIA Tegra30 there is a requirement for regulator "A" to have voltage
higher than voltage of regulator "B" by N microvolts, the N value changes
depending on the voltage of regulator "B". This is similar to min-spread
between voltages of regulators, the difference is that the spread value
Hello,
Maciej moved on to work on something else and kindly allowed me to
take over the coupled regulators patches [0] which I'll try to finalize.
I recently started to work on adding DVFS support to the CPUFreq driver
of NVIDIA Tegra20/30 which require the coupled regulators functionality.
Both
On NVIDIA Tegra30 there is a requirement for regulator "A" to have voltage
higher than voltage of regulator "B" by N microvolts, the N value changes
depending on the voltage of regulator "B". This is similar to min-spread
between voltages of regulators, the difference is that the spread value
601 - 700 of 1296 matches
Mail list logo
