On Thu, Nov 15, 2018 at 03:23:56PM -0800, Omar Sandoval wrote:
> On Thu, Nov 15, 2018 at 04:52:52PM +0800, Ming Lei wrote:
> > BTRFS and guard_bio_eod() need to get the last singlepage segment
> > from one multipage bvec, so introduce this helper to make them happy.
> >
> > Cc: Dave Chinner
> >
On Thu, Nov 15, 2018 at 03:23:56PM -0800, Omar Sandoval wrote:
> On Thu, Nov 15, 2018 at 04:52:52PM +0800, Ming Lei wrote:
> > BTRFS and guard_bio_eod() need to get the last singlepage segment
> > from one multipage bvec, so introduce this helper to make them happy.
> >
> > Cc: Dave Chinner
> >
On Fri, Nov 16, 2018 at 02:33:14PM +0100, Christoph Hellwig wrote:
> > + if (!*sg)
> > + return sglist;
> > + else {
>
> No need for an else after an early return.
OK, good catch!
Thanks,
Ming
On Fri, Nov 16, 2018 at 02:33:14PM +0100, Christoph Hellwig wrote:
> > + if (!*sg)
> > + return sglist;
> > + else {
>
> No need for an else after an early return.
OK, good catch!
Thanks,
Ming
On Thu, Nov 15, 2018 at 12:20:28PM -0800, Omar Sandoval wrote:
> On Thu, Nov 15, 2018 at 04:52:50PM +0800, Ming Lei wrote:
> > First it is more efficient to use bio_for_each_bvec() in both
> > blk_bio_segment_split() and __blk_recalc_rq_segments() to compute how
> > many multi-page bvecs there are
On Thu, Nov 15, 2018 at 12:20:28PM -0800, Omar Sandoval wrote:
> On Thu, Nov 15, 2018 at 04:52:50PM +0800, Ming Lei wrote:
> > First it is more efficient to use bio_for_each_bvec() in both
> > blk_bio_segment_split() and __blk_recalc_rq_segments() to compute how
> > many multi-page bvecs there are
On 16/11/18 6:58 PM, Anisse Astier wrote:
> Hi Adrian,
>
> On Tue, Oct 23, 2018 at 12:07:29PM +0200, Anisse Astier wrote:
>> If there's no ACPI DSM for voltage switch, it will just cause a lot of
>> debug info down the line, we only need one at startup.
>>
>> Signed-off-by: Anisse Astier
>> ---
On 16/11/18 6:58 PM, Anisse Astier wrote:
> Hi Adrian,
>
> On Tue, Oct 23, 2018 at 12:07:29PM +0200, Anisse Astier wrote:
>> If there's no ACPI DSM for voltage switch, it will just cause a lot of
>> debug info down the line, we only need one at startup.
>>
>> Signed-off-by: Anisse Astier
>> ---
On Wed, Nov 14, 2018 at 10:51 PM Uwe Kleine-König
wrote:
> On Wed, Nov 14, 2018 at 12:34:49PM +0100, Thierry Reding wrote:
> > On Fri, Nov 09, 2018 at 05:55:55PM +0100, Uwe Kleine-König wrote:
> > > On Fri, Nov 09, 2018 at 02:24:42PM +, Vokáč Michal wrote:
> > > > On 8.11.2018 20:18, Uwe
On Wed, Nov 14, 2018 at 10:51 PM Uwe Kleine-König
wrote:
> On Wed, Nov 14, 2018 at 12:34:49PM +0100, Thierry Reding wrote:
> > On Fri, Nov 09, 2018 at 05:55:55PM +0100, Uwe Kleine-König wrote:
> > > On Fri, Nov 09, 2018 at 02:24:42PM +, Vokáč Michal wrote:
> > > > On 8.11.2018 20:18, Uwe
On 17. 11. 18 2:56, Nathan Chancellor wrote:
> On Fri, Nov 16, 2018 at 09:40:45AM +0100, Michal Simek wrote:
>> On 09. 11. 18 16:36, Nathan Chancellor wrote:
>>> On Fri, Nov 09, 2018 at 10:33:00AM +0100, Michal Simek wrote:
On 08. 11. 18 16:01, Nathan Chancellor wrote:
> On Thu, Nov 08,
On 17. 11. 18 2:56, Nathan Chancellor wrote:
> On Fri, Nov 16, 2018 at 09:40:45AM +0100, Michal Simek wrote:
>> On 09. 11. 18 16:36, Nathan Chancellor wrote:
>>> On Fri, Nov 09, 2018 at 10:33:00AM +0100, Michal Simek wrote:
On 08. 11. 18 16:01, Nathan Chancellor wrote:
> On Thu, Nov 08,
add 64 bytes loop to acceleration calculation
Signed-off-by: Rui Sun
---
arch/arm64/lib/crc32.S | 54 ++
1 file changed, 50 insertions(+), 4 deletions(-)
diff --git a/arch/arm64/lib/crc32.S b/arch/arm64/lib/crc32.S
index 5bc1e85..2b37009 100644
add 64 bytes loop to acceleration calculation
Signed-off-by: Rui Sun
---
arch/arm64/lib/crc32.S | 54 ++
1 file changed, 50 insertions(+), 4 deletions(-)
diff --git a/arch/arm64/lib/crc32.S b/arch/arm64/lib/crc32.S
index 5bc1e85..2b37009 100644
On 17/11/2018 18:05, Nishanth Menon wrote:
On 11:31-20181113, Vignesh R wrote:
The dt-bindings header for TI K3 AM6 SoCs define a set of macros for
defining pinmux configs in human readable form, instead of raw-coded
hex values.
Signed-off-by: Vignesh R
---
MAINTAINERS
On 17/11/2018 18:05, Nishanth Menon wrote:
On 11:31-20181113, Vignesh R wrote:
The dt-bindings header for TI K3 AM6 SoCs define a set of macros for
defining pinmux configs in human readable form, instead of raw-coded
hex values.
Signed-off-by: Vignesh R
---
MAINTAINERS
On Sun, Nov 18, 2018 at 10:33:55PM -0800, David Miller wrote:
> From: Namhyung Kim
> Date: Mon, 19 Nov 2018 15:28:37 +0900
>
> > Hello David,
> >
> > On Sun, Nov 18, 2018 at 08:52:43PM -0800, David Miller wrote:
> >> From: Jiri Olsa
> >> Date: Tue, 13 Nov 2018 11:40:54 +0100
> >>
> >> > I
On Sun, Nov 18, 2018 at 10:33:55PM -0800, David Miller wrote:
> From: Namhyung Kim
> Date: Mon, 19 Nov 2018 15:28:37 +0900
>
> > Hello David,
> >
> > On Sun, Nov 18, 2018 at 08:52:43PM -0800, David Miller wrote:
> >> From: Jiri Olsa
> >> Date: Tue, 13 Nov 2018 11:40:54 +0100
> >>
> >> > I
This pushes the handling of inversion semantics and open drain
settings to the GPIO descriptor and gpiolib. All affected board
files are also augmented.
This is especially nice since we don't have to have any
confusing flags passed around to the left and right littering
the fixed and GPIO
Use devm_* managed device resources and create a local
struct device *dev variable to simplify the code inside
probe().
Signed-off-by: Linus Walleij
---
ChangeLog v6->v7:
- Resend with the rest.
ChangeLog v3->v6:
- Rebase on top of the other changes.
- Change numbering to fit the rest of the
Deprecate the open drain binding for fixed regulator and indicate
that we prefer this to be passed in the GPIO phandle flags.
Clarify that the line inversion semantics for fixed and GPIO
regulators completely overrides the active low flags in the
phandle flags.
Unfortunately this can not be
This pushes the handling of inversion semantics and open drain
settings to the GPIO descriptor and gpiolib. All affected board
files are also augmented.
This is especially nice since we don't have to have any
confusing flags passed around to the left and right littering
the fixed and GPIO
Use devm_* managed device resources and create a local
struct device *dev variable to simplify the code inside
probe().
Signed-off-by: Linus Walleij
---
ChangeLog v6->v7:
- Resend with the rest.
ChangeLog v3->v6:
- Rebase on top of the other changes.
- Change numbering to fit the rest of the
Deprecate the open drain binding for fixed regulator and indicate
that we prefer this to be passed in the GPIO phandle flags.
Clarify that the line inversion semantics for fixed and GPIO
regulators completely overrides the active low flags in the
phandle flags.
Unfortunately this can not be
This converts the GPIO regulator driver to use decriptors only.
We have to let go of the array gpio handling: the fetched descriptors
are handled individually anyway, and the array retrieveal function
does not make it possible to retrieve each GPIO descriptor with
unique flags. Instead get them
Now that we changed all providers to pass descriptors into the core
for enable GPIOs instead of a global GPIO number, delete the support
for passing GPIO numbers in, and we get a cleanup and size reduction
in the core, and from a GPIO point of view we use the modern, cleaner
interface.
This converts the GPIO regulator driver to use decriptors only.
We have to let go of the array gpio handling: the fetched descriptors
are handled individually anyway, and the array retrieveal function
does not make it possible to retrieve each GPIO descriptor with
unique flags. Instead get them
Now that we changed all providers to pass descriptors into the core
for enable GPIOs instead of a global GPIO number, delete the support
for passing GPIO numbers in, and we get a cleanup and size reduction
in the core, and from a GPIO point of view we use the modern, cleaner
interface.
On Mon, Nov 19, 2018 at 12:29 PM Shawn Guo wrote:
>
> On Sat, Nov 17, 2018 at 09:13:38AM -0600, Rob Herring wrote:
>
> > > > > +- qcom,init-seq:
> > > > > +Value type:
> > > > > +Definition: Should contain a sequence of
> > > > > tuples to
> > > > > +program 'value'
On Mon, Nov 19, 2018 at 12:29 PM Shawn Guo wrote:
>
> On Sat, Nov 17, 2018 at 09:13:38AM -0600, Rob Herring wrote:
>
> > > > > +- qcom,init-seq:
> > > > > +Value type:
> > > > > +Definition: Should contain a sequence of
> > > > > tuples to
> > > > > +program 'value'
> -Original Message-
> From: David Miller
> Sent: Saturday, November 17, 2018 5:42 AM
> To: Madalin-cristian Bucur
> Subject: Re: [PATCH v2 2/2] dpaa_eth: add ethtool coalesce control
>
> From: Madalin Bucur
> Date: Tue, 13 Nov 2018 18:29:51 +0200
>
> > + for_each_cpu(cpu, cpus) {
>
> -Original Message-
> From: David Miller
> Sent: Saturday, November 17, 2018 5:42 AM
> To: Madalin-cristian Bucur
> Subject: Re: [PATCH v2 2/2] dpaa_eth: add ethtool coalesce control
>
> From: Madalin Bucur
> Date: Tue, 13 Nov 2018 18:29:51 +0200
>
> > + for_each_cpu(cpu, cpus) {
>
Hi Andrey:
Thanks for your patch-set.
I have comment about the L1SS implementation below.
It's better to figure out one method to fix it.
BR
Richard
> -Original Message-
> From: Andrey Smirnov [mailto:andrew.smir...@gmail.com]
> Sent: 2018年11月18日 2:12
> To: linux-kernel@vger.kernel.org
>
Hi Andrey:
Thanks for your patch-set.
I have comment about the L1SS implementation below.
It's better to figure out one method to fix it.
BR
Richard
> -Original Message-
> From: Andrey Smirnov [mailto:andrew.smir...@gmail.com]
> Sent: 2018年11月18日 2:12
> To: linux-kernel@vger.kernel.org
>
On Sat, Nov 17, 2018 at 09:13:38AM -0600, Rob Herring wrote:
> > > > +- qcom,init-seq:
> > > > +Value type:
> > > > +Definition: Should contain a sequence of
> > > > tuples to
> > > > +program 'value' into phy register at 'offset' with
> > > > 'delay'
> > > > +
On Sat, Nov 17, 2018 at 09:13:38AM -0600, Rob Herring wrote:
> > > > +- qcom,init-seq:
> > > > +Value type:
> > > > +Definition: Should contain a sequence of
> > > > tuples to
> > > > +program 'value' into phy register at 'offset' with
> > > > 'delay'
> > > > +
When performing single ended measurements with TSCADC, its recommended
to set negative input (SEL_INM_SWC_3_0) of ADC step to ADC's VREFN in the
corresponding STEP_CONFIGx register.
Also, the positive(SEL_RFP_SWC_2_0) and negative(SEL_RFM_SWC_1_0)
reference voltage for ADC step needs to be set to
When performing single ended measurements with TSCADC, its recommended
to set negative input (SEL_INM_SWC_3_0) of ADC step to ADC's VREFN in the
corresponding STEP_CONFIGx register.
Also, the positive(SEL_RFP_SWC_2_0) and negative(SEL_RFM_SWC_1_0)
reference voltage for ADC step needs to be set to
Provide unique names for child mfd cells, this is required in order to
support registering of multiple instances of same ti_am335x_tscadc IP.
Signed-off-by: Vignesh R
---
drivers/mfd/ti_am335x_tscadc.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git
Provide unique names for child mfd cells, this is required in order to
support registering of multiple instances of same ti_am335x_tscadc IP.
Signed-off-by: Vignesh R
---
drivers/mfd/ti_am335x_tscadc.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git
Couple of fixes for tscadc drivers that I found while adding support for
new SoC. Patches are standalone and can go via individual domain trees.
Vignesh R (2):
mfd: ti_am335x_tscadc: Provide unique name for child mfd cells
iio: adc: ti_am335x_tscadc: Improve accuracy of measurement
Couple of fixes for tscadc drivers that I found while adding support for
new SoC. Patches are standalone and can go via individual domain trees.
Vignesh R (2):
mfd: ti_am335x_tscadc: Provide unique name for child mfd cells
iio: adc: ti_am335x_tscadc: Improve accuracy of measurement
On Mon, Oct 29, 2018 at 03:32:34PM -0600, Alex Williamson wrote:
> On Mon, 29 Oct 2018 13:56:54 -0500
> Wenwen Wang wrote:
>
> > Hello,
> >
> > Could you please apply this patch? Thanks!
>
> I'd like to see testing and/or review from David or Alexey since I also
> don't have an environment for
On Mon, Oct 29, 2018 at 03:32:34PM -0600, Alex Williamson wrote:
> On Mon, 29 Oct 2018 13:56:54 -0500
> Wenwen Wang wrote:
>
> > Hello,
> >
> > Could you please apply this patch? Thanks!
>
> I'd like to see testing and/or review from David or Alexey since I also
> don't have an environment for
From: Namhyung Kim
Date: Mon, 19 Nov 2018 15:28:37 +0900
> Hello David,
>
> On Sun, Nov 18, 2018 at 08:52:43PM -0800, David Miller wrote:
>> From: Jiri Olsa
>> Date: Tue, 13 Nov 2018 11:40:54 +0100
>>
>> > I pushed/rebased what I have to perf/fixes branch again
>> >
>> > please note I had to
From: Namhyung Kim
Date: Mon, 19 Nov 2018 15:28:37 +0900
> Hello David,
>
> On Sun, Nov 18, 2018 at 08:52:43PM -0800, David Miller wrote:
>> From: Jiri Olsa
>> Date: Tue, 13 Nov 2018 11:40:54 +0100
>>
>> > I pushed/rebased what I have to perf/fixes branch again
>> >
>> > please note I had to
Hello David,
On Sun, Nov 18, 2018 at 08:52:43PM -0800, David Miller wrote:
> From: Jiri Olsa
> Date: Tue, 13 Nov 2018 11:40:54 +0100
>
> > I pushed/rebased what I have to perf/fixes branch again
> >
> > please note I had to change our compile changes, because
> > they wouldn't compile on x86,
Hello David,
On Sun, Nov 18, 2018 at 08:52:43PM -0800, David Miller wrote:
> From: Jiri Olsa
> Date: Tue, 13 Nov 2018 11:40:54 +0100
>
> > I pushed/rebased what I have to perf/fixes branch again
> >
> > please note I had to change our compile changes, because
> > they wouldn't compile on x86,
In case of msm drm bind failure, pm runtime put sync
is called from dsi driver which issues an asynchronous
put on mdss device. Subsequently when dpu_mdss_destroy
is triggered the change will make sure to put the mdss
device in suspend and clearing pending work if not
scheduled.
Changes in v2:
In case of msm drm bind failure, pm runtime put sync
is called from dsi driver which issues an asynchronous
put on mdss device. Subsequently when dpu_mdss_destroy
is triggered the change will make sure to put the mdss
device in suspend and clearing pending work if not
scheduled.
Changes in v2:
Hi Jason:
On Mon, Nov 19, 2018 at 07:13:07AM +0100, Jason A. Donenfeld wrote:
>
> Sorry, but there isn't a chance I'll agree to this. The whole idea is
> to have a clean place to focus on synchronous software
> implementations, and not keep it tangled up with the asynchronous API.
There is
Hi Jason:
On Mon, Nov 19, 2018 at 07:13:07AM +0100, Jason A. Donenfeld wrote:
>
> Sorry, but there isn't a chance I'll agree to this. The whole idea is
> to have a clean place to focus on synchronous software
> implementations, and not keep it tangled up with the asynchronous API.
There is
H Boris,
> -Original Message-
> From: Boris Brezillon [mailto:boris.brezil...@bootlin.com]
> Sent: Monday, November 19, 2018 1:13 AM
> To: Naga Sureshkumar Relli
> Cc: miquel.ray...@bootlin.com; rich...@nod.at; dw...@infradead.org;
> computersforpe...@gmail.com; marek.va...@gmail.com;
>
H Boris,
> -Original Message-
> From: Boris Brezillon [mailto:boris.brezil...@bootlin.com]
> Sent: Monday, November 19, 2018 1:13 AM
> To: Naga Sureshkumar Relli
> Cc: miquel.ray...@bootlin.com; rich...@nod.at; dw...@infradead.org;
> computersforpe...@gmail.com; marek.va...@gmail.com;
>
Hi Herbert,
On Mon, Nov 19, 2018 at 6:25 AM Herbert Xu wrote:
> My proposal is to merge the zinc interface as is, but to invert
> how we place the algorithm implementations. IOW the implementations
> should stay where they are now, with in the crypto API. However,
> we will provide direct
Hi Herbert,
On Mon, Nov 19, 2018 at 6:25 AM Herbert Xu wrote:
> My proposal is to merge the zinc interface as is, but to invert
> how we place the algorithm implementations. IOW the implementations
> should stay where they are now, with in the crypto API. However,
> we will provide direct
According to the description of st_sensor_settings and st_sensor_data
structures' comments:
- bootime: samples to discard when sensor passing from power-down to
power-up.
- odr: Output data rate of the sensor [Hz].
The sleep time should be
sdata->sensor_settings->bootime + 1000 / sdata->odr ms.
According to the description of st_sensor_settings and st_sensor_data
structures' comments:
- bootime: samples to discard when sensor passing from power-down to
power-up.
- odr: Output data rate of the sensor [Hz].
The sleep time should be
sdata->sensor_settings->bootime + 1000 / sdata->odr ms.
Hi, Matthias:
On Fri, 2018-11-16 at 13:54 +0100, matthias@kernel.org wrote:
> From: Matthias Brugger
>
> The MMSYS subsystem includes clocks and drm components.
> This patch adds an initailization path through a platform device
> for the clock part, so that both drivers get probed from the
Hi, Matthias:
On Fri, 2018-11-16 at 13:54 +0100, matthias@kernel.org wrote:
> From: Matthias Brugger
>
> The MMSYS subsystem includes clocks and drm components.
> This patch adds an initailization path through a platform device
> for the clock part, so that both drivers get probed from the
Hi all,
Changes since 20181116:
Removed trees: (not updated in more that a year)
aio, drm-panel, edac, idle, keys, kvm-mips, lightnvm,
nand-fixes, realtek, sunxi-drm, uuid, vfs-miklos
The tip tree still had its build failure for which I applied a fix patch.
The akpm tree lost
Hi all,
Changes since 20181116:
Removed trees: (not updated in more that a year)
aio, drm-panel, edac, idle, keys, kvm-mips, lightnvm,
nand-fixes, realtek, sunxi-drm, uuid, vfs-miklos
The tip tree still had its build failure for which I applied a fix patch.
The akpm tree lost
On 11/16/2018 10:25 PM, Dave Hansen wrote:
> On 11/15/18 10:27 PM, Anshuman Khandual wrote:
>> Not able to see the patches from this series either on the list or on the
>> archive (https://lkml.org/lkml/2018/11/15/331). IIRC last time we discussed
>> about this and the concern which I raised
On 11/16/2018 10:25 PM, Dave Hansen wrote:
> On 11/15/18 10:27 PM, Anshuman Khandual wrote:
>> Not able to see the patches from this series either on the list or on the
>> archive (https://lkml.org/lkml/2018/11/15/331). IIRC last time we discussed
>> about this and the concern which I raised
Implement initial version of perf-security.rst documentation file
initially covering security concerns related to PCL/Perf performance
monitoring in multiuser environments.
Suggested-by: Thomas Gleixner
Signed-off-by: Alexey Budankov
---
Documentation/admin-guide/perf-security.rst | 83
Implement initial version of perf-security.rst documentation file
initially covering security concerns related to PCL/Perf performance
monitoring in multiuser environments.
Suggested-by: Thomas Gleixner
Signed-off-by: Alexey Budankov
---
Documentation/admin-guide/perf-security.rst | 83
Extend index.rst index file at admin-guide root directory with
the reference to perf-security.rst file being introduced.
Signed-off-by: Alexey Budankov
---
Documentation/admin-guide/index.rst | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/admin-guide/index.rst
Extend index.rst index file at admin-guide root directory with
the reference to perf-security.rst file being introduced.
Signed-off-by: Alexey Budankov
---
Documentation/admin-guide/index.rst | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/admin-guide/index.rst
Hi, Matthias:
On Fri, 2018-11-16 at 13:54 +0100, matthias@kernel.org wrote:
> From: Matthias Brugger
>
> It can happen that the mmsys clock drivers aren't probed before the
> platform driver gets invoked. The platform driver used to print a warning
> that the driver failed to get the
Hi, Matthias:
On Fri, 2018-11-16 at 13:54 +0100, matthias@kernel.org wrote:
> From: Matthias Brugger
>
> It can happen that the mmsys clock drivers aren't probed before the
> platform driver gets invoked. The platform driver used to print a warning
> that the driver failed to get the
To facilitate informed decision making by system administrators [1]
to permit and manage access to PCL/Perf [2],[3] performance monitoring
for multiple users perf-security.rst document suggested by Thomas Gleixner
is introduced [4] that:
a) states PCL/Perf access security concerns for multi
To facilitate informed decision making by system administrators [1]
to permit and manage access to PCL/Perf [2],[3] performance monitoring
for multiple users perf-security.rst document suggested by Thomas Gleixner
is introduced [4] that:
a) states PCL/Perf access security concerns for multi
Hi Bjorn/Vinod,
On 2018-11-09 15:14, Vinod Koul wrote:
From: Bjorn Andersson
Add the TrustZone based remoteproc nodes and their glink edges for
adsp, cdsp and wcss. Enable them for EVB common DTS.
Signed-off-by: Bjorn Andersson
Signed-off-by: Vinod Koul
---
Hi Bjorn/Vinod,
On 2018-11-09 15:14, Vinod Koul wrote:
From: Bjorn Andersson
Add the TrustZone based remoteproc nodes and their glink edges for
adsp, cdsp and wcss. Enable them for EVB common DTS.
Signed-off-by: Bjorn Andersson
Signed-off-by: Vinod Koul
---
Hi Jirka
Sorry for late!
On Tue, Nov 06, 2018 at 12:54:36PM +0100, Jiri Olsa wrote:
> On Mon, Nov 05, 2018 at 08:53:42PM -0800, David Miller wrote:
> >
> > Jiri,
> >
> > Because you now run queued_events__queue() lockless with that condvar
> > trick, it is possible for top->qe.in to be seen as
Hi Jirka
Sorry for late!
On Tue, Nov 06, 2018 at 12:54:36PM +0100, Jiri Olsa wrote:
> On Mon, Nov 05, 2018 at 08:53:42PM -0800, David Miller wrote:
> >
> > Jiri,
> >
> > Because you now run queued_events__queue() lockless with that condvar
> > trick, it is possible for top->qe.in to be seen as
On 11/13/18 10:32 PM, Firoz Khan wrote:
> The purpose of this patch series is, we can easily
> add/modify/delete system call table support by cha-
> nging entry in syscall.tbl file instead of manually
> changing many files. The other goal is to unify the
> system call table generation support
On Sun, Nov 18, 2018 at 02:46:30PM +0100, Jason A. Donenfeld wrote:
>
> Personally I'd prefer this be merged after Zinc, since there's work to
> be done on adjusting the 20->12 in chacha20. That's not really much of
> a reason though. But maybe we can just sidestep the ordering concern
> all
On 11/13/18 10:32 PM, Firoz Khan wrote:
> The purpose of this patch series is, we can easily
> add/modify/delete system call table support by cha-
> nging entry in syscall.tbl file instead of manually
> changing many files. The other goal is to unify the
> system call table generation support
On Sun, Nov 18, 2018 at 02:46:30PM +0100, Jason A. Donenfeld wrote:
>
> Personally I'd prefer this be merged after Zinc, since there's work to
> be done on adjusting the 20->12 in chacha20. That's not really much of
> a reason though. But maybe we can just sidestep the ordering concern
> all
Hi David,
On Mon, 19 Nov 2018 at 08:29, David Miller wrote:
>
> From: Firoz Khan
> Date: Wed, 14 Nov 2018 10:56:27 +0530
>
> > The purpose of this patch series is, we can easily
> > add/modify/delete system call table support by cha-
> > nging entry in syscall.tbl file instead of manually
> >
Hi David,
On Mon, 19 Nov 2018 at 08:29, David Miller wrote:
>
> From: Firoz Khan
> Date: Wed, 14 Nov 2018 10:56:27 +0530
>
> > The purpose of this patch series is, we can easily
> > add/modify/delete system call table support by cha-
> > nging entry in syscall.tbl file instead of manually
> >
Hi Helge,
On Sat, 17 Nov 2018 at 22:01, Helge Deller wrote:
>
> * Arnd Bergmann :
> > On Fri, Nov 16, 2018 at 1:55 PM Helge Deller wrote:
> > > > On Fri, 16 Nov 2018 at 01:01, Helge Deller wrote:
> > > > >
> > > > > On 14.11.2018 07:34, Firoz Khan wrote:
> > > > > > The purpose of this patch
Hi Helge,
On Sat, 17 Nov 2018 at 22:01, Helge Deller wrote:
>
> * Arnd Bergmann :
> > On Fri, Nov 16, 2018 at 1:55 PM Helge Deller wrote:
> > > > On Fri, 16 Nov 2018 at 01:01, Helge Deller wrote:
> > > > >
> > > > > On 14.11.2018 07:34, Firoz Khan wrote:
> > > > > > The purpose of this patch
On 2018-11-18 18:32, Jarkko Sakkinen wrote:
On Sun, Nov 18, 2018 at 09:15:48AM +0200, Jarkko Sakkinen wrote:
On Thu, Nov 01, 2018 at 10:53:40AM -0700, Andy Lutomirski wrote:
Hi all-
The people working on SGX enablement are grappling with a somewhat
annoying issue: the x86 EENTER instruction
On 2018-11-18 18:32, Jarkko Sakkinen wrote:
On Sun, Nov 18, 2018 at 09:15:48AM +0200, Jarkko Sakkinen wrote:
On Thu, Nov 01, 2018 at 10:53:40AM -0700, Andy Lutomirski wrote:
Hi all-
The people working on SGX enablement are grappling with a somewhat
annoying issue: the x86 EENTER instruction
On Wed, 14 Nov 2018 at 10:02, Firoz Khan wrote:
>
> The purpose of this patch series is, we can easily
> add/modify/delete system call table support by cha-
> nging entry in syscall.tbl file instead of manually
> changing many files. The other goal is to unify the
> system call table generation
On Wed, 14 Nov 2018 at 10:02, Firoz Khan wrote:
>
> The purpose of this patch series is, we can easily
> add/modify/delete system call table support by cha-
> nging entry in syscall.tbl file instead of manually
> changing many files. The other goal is to unify the
> system call table generation
On Sun, 2018-11-18 at 09:27 +0200, Jarkko Sakkinen wrote:
> On Fri, Nov 16, 2018 at 04:55:36PM +0100, Roberto Sassu wrote:
> > On 11/16/2018 4:03 PM, Jarkko Sakkinen wrote:
> > > On Wed, Nov 14, 2018 at 04:31:08PM +0100, Roberto Sassu wrote:
> > > > Currently, tpm_pcr_extend() accepts as an input
On Sun, 2018-11-18 at 09:27 +0200, Jarkko Sakkinen wrote:
> On Fri, Nov 16, 2018 at 04:55:36PM +0100, Roberto Sassu wrote:
> > On 11/16/2018 4:03 PM, Jarkko Sakkinen wrote:
> > > On Wed, Nov 14, 2018 at 04:31:08PM +0100, Roberto Sassu wrote:
> > > > Currently, tpm_pcr_extend() accepts as an input
From: Jiri Olsa
Date: Tue, 13 Nov 2018 11:40:54 +0100
> I pushed/rebased what I have to perf/fixes branch again
>
> please note I had to change our compile changes, because
> they wouldn't compile on x86, but I can't verify on sparc,
> so you might see some compile fails again
I just checked
From: Jiri Olsa
Date: Tue, 13 Nov 2018 11:40:54 +0100
> I pushed/rebased what I have to perf/fixes branch again
>
> please note I had to change our compile changes, because
> they wouldn't compile on x86, but I can't verify on sparc,
> so you might see some compile fails again
I just checked
On Mon, Nov 19, 2018 at 11:32:41AM +0800, YueHaibing wrote:
> Fix a static code checker warning:
> fs/exportfs/expfs.c:171 reconnect_one() warn: passing zero to 'ERR_PTR'
>
> The error path for lookup_one_len_unlocked failure
> should set err to PTR_ERR.
>
> Fixes: bbf7a8a3562f ("exportfs:
On Mon, Nov 19, 2018 at 11:32:41AM +0800, YueHaibing wrote:
> Fix a static code checker warning:
> fs/exportfs/expfs.c:171 reconnect_one() warn: passing zero to 'ERR_PTR'
>
> The error path for lookup_one_len_unlocked failure
> should set err to PTR_ERR.
>
> Fixes: bbf7a8a3562f ("exportfs:
On Fri, Sep 21, 2018 at 05:33:01PM +0100, David Howells wrote:
> Make kernfs support superblock creation/mount/remount with fs_context.
>
> This requires that sysfs, cgroup and intel_rdt, which are built on kernfs,
> be made to support fs_context also.
>
> Notes:
>
> (1) A kernfs_fs_context
On Fri, Sep 21, 2018 at 05:33:01PM +0100, David Howells wrote:
> Make kernfs support superblock creation/mount/remount with fs_context.
>
> This requires that sysfs, cgroup and intel_rdt, which are built on kernfs,
> be made to support fs_context also.
>
> Notes:
>
> (1) A kernfs_fs_context
Add and supporting vddio_ao18 nodes to fix hwmon temperature
readings on the WeTek Hub and Play2 devices. Without these nodes the
temp is reported as 4294967295 degrees C.
Thanks to Martin Blumenstingl for assisting debug and the winning
guess at what was missing.
Signed-off-by: Christian
Add and supporting vddio_ao18 nodes to fix hwmon temperature
readings on the WeTek Hub and Play2 devices. Without these nodes the
temp is reported as 4294967295 degrees C.
Thanks to Martin Blumenstingl for assisting debug and the winning
guess at what was missing.
Signed-off-by: Christian
From: Herbert Xu
Date: Mon, 19 Nov 2018 12:06:34 +0800
> On Mon, Nov 19, 2018 at 11:56:35AM +0800, Herbert Xu wrote:
>>
>> I take that back. Because of your shift which cancels out the
>> shift in NULLS_MARKER, it would appear that this should work just
>> fine with RHT_NULLS_MARRKER(0), no?
From: Herbert Xu
Date: Mon, 19 Nov 2018 12:06:34 +0800
> On Mon, Nov 19, 2018 at 11:56:35AM +0800, Herbert Xu wrote:
>>
>> I take that back. Because of your shift which cancels out the
>> shift in NULLS_MARKER, it would appear that this should work just
>> fine with RHT_NULLS_MARRKER(0), no?
1 - 100 of 554 matches
Mail list logo
