On 9/11/19 8:43 AM, Rasmus Villemoes wrote:
> On 11/09/2019 02.15, Joe Perches wrote:
>> On Tue, 2019-09-10 at 18:26 +0300, Andy Shevchenko wrote:
>>> On Mon, Sep 9, 2019 at 11:39 PM Rasmus Villemoes
>>> wrote:
>
+#define E(err) [err + BUILD_BUG_ON_ZERO(err <= 0 || err > 300)] = #err
+#
On 11/09/2019 11.37, Uwe Kleine-König wrote:
> On 9/11/19 8:43 AM, Rasmus Villemoes wrote:
>> On 11/09/2019 02.15, Joe Perches wrote:
>>> On Tue, 2019-09-10 at 18:26 +0300, Andy Shevchenko wrote:
On Mon, Sep 9, 2019 at 11:39 PM Rasmus Villemoes
wrote:
> +{
> + /* Might as w
Quoting Saravana Kannan (2019-09-04 14:11:22)
> Add device links after the devices are created (but before they are
> probed) by looking at common DT bindings like clocks and
> interconnects.
>
> Automatically adding device links for functional dependencies at the
> framework level provides the fo
Hi Daniel,
On 04/09/2019 21:42, Daniel Jordan wrote:
>> In addition, the tables that are printed by the script were not properly
>> aligned any more, so patch 2 fixes the spacing.
>
> Nit, not for Pages Scanned. With your series I get
>
> Kswapd Kswapd Order Pages Pages
Hi Daniel,
On 04/09/2019 21:44, Daniel Jordan wrote:
> On Tue, Sep 03, 2019 at 11:14:12AM +, Florian Schmidt wrote:
>> mm_vmscan_{direct_reclaim_begin,wakeup_kswapd,lru_isolate,lru_shrink_active}
>> changed their output to the point where the script throws warnings and
>> errors. Update it to
Quoting Saravana Kannan (2019-09-04 14:11:19)
> v10->v11:
> - Dropped 6/7 and 7/7 from previous series that tried to handle cycles in DT
> dependencies. We can solve it later when we actually hit a real world issue
> in DT.
> - Added a new 1/7 that shifts the numbering for the rest of the patch
On Tue, Sep 10, 2019 at 10:26:49AM -0700, Dave Hansen wrote:
From: Dave Hansen
Hardware companies like Intel have lots of information which they
want to disclose to some folks but not others. Non-disclosure
agreements are a tool of choice for helping to ensure that the
flow of information is
This patch series updates trace-vmscan-postprocess.pl to work without
throwing warnings and errors which stem from updates to several trace
points.
3481c37ffa1d ("mm/vmscan: drop may_writepage and classzone_idx from
direct reclaim begin template") removed "may_writepage" from
mm_vmscan_direct_recl
mm_vmscan_{direct_reclaim_begin,wakeup_kswapd,lru_isolate,lru_shrink_active}
changed their output to the point where the script throws warnings and
errors. Update it to be properly in line with those changes.
Fixes: 3481c37ffa1d ("mm/vmscan: drop may_writepage and classzone_idx from
direct reclai
Fix spacing so that both the headers in themselves, as well as the
output of the two tables related to each other, are properly aligned.
Signed-off-by: Florian Schmidt
---
Documentation/trace/postprocess/trace-vmscan-postprocess.pl | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
dif
In the Distribution Kernels track at Linux Plumbers Conference there
was some discussion around the difficulty of making kernel builds
reproducible.
This is a solved problem, but the solutions don't appear to be
documented in one place. This document lists the issues I know about
and the settings
On Tue, Sep 10, 2019 at 10:26:44AM -0700, Dave Hansen wrote:
> Intel will adhere to this process for future hardware embargoed
> issues. This series contains a patch from Tony Luck with him
> volunteering to be Intel's ambassador for this process.
>
> These are some minor improvements here to the
Hi Ben,
Thanks for this.
Please let me add some comments.
On Wed, Sep 11, 2019 at 8:54 PM Ben Hutchings wrote:
>
> In the Distribution Kernels track at Linux Plumbers Conference there
> was some discussion around the difficulty of making kernel builds
> reproducible.
>
> This is a solved probl
On Wed, 2019-09-11 at 21:17 +0900, Masahiro Yamada wrote:
> Hi Ben,
>
>
> Thanks for this.
> Please let me add some comments.
>
>
> On Wed, Sep 11, 2019 at 8:54 PM Ben Hutchings wrote:
[...]
> > +Absolute filenames
> > +--
> > +
> > +When the kernel is built out-of-tree, debug
On Wed, 2019-09-11 at 14:04 +0100, Ben Hutchings wrote:
> On Wed, 2019-09-11 at 21:17 +0900, Masahiro Yamada wrote:
> > Hi Ben,
> >
> >
> > Thanks for this.
> > Please let me add some comments.
> >
> >
> > On Wed, Sep 11, 2019 at 8:54 PM Ben Hutchings wrote:
> [...]
> > > +Absolute filenames
>
Allow several clients to request (hwspin_lock_request_specific()) the
same lock.
In addition to that, protect a given lock from being locked
(hwspin_trylock{_...}()) by more that one client at a time.
Since the RAW and IN_ATOMIC modes do not implement that protection
(unlike the default, IRQ and I
On 9/11/19 3:11 AM, Sasha Levin wrote:
>> +Disclosing parties may have shared information about an issue under a
>> +non-disclosure agreement with third parties. In order to ensure that
>> +these agreements do not interfere with the mitigation development
>> +process, the disclosing party must pro
On Tue, Sep 10, 2019 at 10:26:49AM -0700, Dave Hansen wrote:
>
> From: Dave Hansen
>
> Hardware companies like Intel have lots of information which they
> want to disclose to some folks but not others. Non-disclosure
> agreements are a tool of choice for helping to ensure that the
> flow of inf
On Tue, Sep 10, 2019 at 10:26:51AM -0700, Dave Hansen wrote:
>
> From: Dave Hansen
>
> Both hardware companies and the kernel community prefer coordinated
> disclosure to the alternatives. It is also obvious that sitting on
> ready-to-go mitigations for months is not so nice for kernel
> mainta
On Tue, Sep 10, 2019 at 10:26:52AM -0700, Dave Hansen wrote:
>
> From: Dave Hansen
>
> Transparency is good. It it essential for everyone working under an
> embargo to know who is involved and who else is a "knower". Being
> transparent allows everyone to always make informed decisions about
>
On 9/11/19 8:44 AM, Greg KH wrote:
> Intel had months of review time for this document before this was
> published. Your lawyers had it and never objected to this lack of
> inclusion at all, and explictitly said that the document as written was
> fine with them. So I'm sorry, but it is much too l
Describe how the comedi minor device numbers are split across comedi
devices and comedi subdevices.
Replace the current, long dead URL with an official URL for the Comedi
project.
Signed-off-by: Ian Abbott
---
Documentation/admin-guide/devices.txt | 11 ++-
1 file changed, 10 insertions
Despite of functions being documented they are not in the kernel-doc
specification, and could not be included in kernel documentation. Change
the style of functions comments to be compliant to the kernel-doc style.
Signed-off-by: André Almeida
---
drivers/scsi/scsi_lib.c | 166 +++---
"Busses" is the third person conjugation of verb "to buss" in the
present tense. "Buses" is the plural of bus, as in "serial bus".
Signed-off-by: André Almeida
---
Documentation/driver-api/scsi.rst | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/driver-api/scsi.
Remove all trailing whitespaces from scsi_lib.c
Signed-off-by: André Almeida
---
drivers/scsi/scsi_lib.c | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
index 11e64b50497f..8565bee31922 100644
--- a/drivers/
On Wed, 2019-09-11 at 17:37 -0300, André Almeida wrote:
> "Busses" is the third person conjugation of verb "to buss" in the
> present tense. "Buses" is the plural of bus, as in "serial bus".
busses and buses are both acceptable plurals of bus
https://www.dictionary.com/browse/bus
On 9/11/19 6:10 PM, Joe Perches wrote:
> On Wed, 2019-09-11 at 17:37 -0300, André Almeida wrote:
>> "Busses" is the third person conjugation of verb "to buss" in the
>> present tense. "Buses" is the plural of bus, as in "serial bus".
>
> busses and buses are both acceptable plurals of bus
>
> htt
On Tue, 2019-09-10 at 15:17 +0200, Federico Vaga wrote:
> Generally speaking compactness does not bring any value if then the text is
> unclear or open to interpretation.
It's somewhat difficult to choose between +1 and I agree.
On Wed, Sep 11, 2019 at 10:15 PM Ben Hutchings wrote:
>
> On Wed, 2019-09-11 at 14:04 +0100, Ben Hutchings wrote:
> > On Wed, 2019-09-11 at 21:17 +0900, Masahiro Yamada wrote:
> > > Hi Ben,
> > >
> > >
> > > Thanks for this.
> > > Please let me add some comments.
> > >
> > >
> > > On Wed, Sep 11,
29 matches
Mail list logo
