Re: [PATCH V6 2/5] PCI/ACPI: Check platform specific ECAM quirks

[Tomasz Nowicki]

On 13.09.2016 00:47, Duc Dang wrote:

On Mon, Sep 12, 2016 at 3:24 PM, Duc Dang  wrote:

On Fri, Sep 9, 2016 at 12:24 PM, Tomasz Nowicki  wrote:


Some platforms may not be fully compliant with generic set of PCI config
accessors. For these cases we implement the way to overwrite CFG accessors
set and configuration space range.

In first place pci_mcfg_parse() saves machine's IDs and revision number
(these come from MCFG header) in order to match against known quirk entries.
Then the algorithm traverses available quirk list (static array),
matches against  and
returns custom PCI config ops and/or CFG resource structure.

When adding new quirk there are two possibilities:
1. Override default pci_generic_ecam_ops ops but CFG resource comes from MCFG
{ "OEM_ID", "OEM_TABLE_ID", , , , _ops, MCFG_RES_EMPTY 
},
2. Override default pci_generic_ecam_ops ops and CFG resource. For this case
it is also allowed get CFG resource from quirk entry w/o having it in MCFG.
{ "OEM_ID", "OEM_TABLE_ID", , , , _ops,
  DEFINE_RES_MEM(START, SIZE) },

pci_generic_ecam_ops and MCFG entries will be used for platforms
free from quirks.

Signed-off-by: Tomasz Nowicki 
Signed-off-by: Dongdong Liu 
Signed-off-by: Christopher Covington 
---
 drivers/acpi/pci_mcfg.c | 80 +
 1 file changed, 74 insertions(+), 6 deletions(-)

diff --git a/drivers/acpi/pci_mcfg.c b/drivers/acpi/pci_mcfg.c
index ffcc651..2b8acc7 100644
--- a/drivers/acpi/pci_mcfg.c
+++ b/drivers/acpi/pci_mcfg.c
@@ -32,6 +32,59 @@ struct mcfg_entry {
u8  bus_start;
u8  bus_end;
 };
+struct mcfg_fixup {
+   char oem_id[ACPI_OEM_ID_SIZE + 1];
+   char oem_table_id[ACPI_OEM_TABLE_ID_SIZE + 1];
+   u32 oem_revision;
+   u16 seg;
+   struct resource bus_range;
+   struct pci_ecam_ops *ops;
+   struct resource cfgres;
+};
+
+#define MCFG_DOM_ANY   (-1)
+#define MCFG_BUS_RANGE(start, end) DEFINE_RES_NAMED((start),   \
+   ((end) - (start) + 1),  \
+   NULL, IORESOURCE_BUS)
+#define MCFG_BUS_ANY   MCFG_BUS_RANGE(0x0, 0xff)
+#define MCFG_RES_EMPTY DEFINE_RES_NAMED(0, 0, NULL, 0)
+
+static struct mcfg_fixup mcfg_quirks[] = {
+/* { OEM_ID, OEM_TABLE_ID, REV, DOMAIN, BUS_RANGE, cfgres, ops }, */
+};
+
+static char mcfg_oem_id[ACPI_OEM_ID_SIZE];
+static char mcfg_oem_table_id[ACPI_OEM_TABLE_ID_SIZE];
+static u32 mcfg_oem_revision;
+
+static void pci_mcfg_match_quirks(struct acpi_pci_root *root,
+ struct resource *cfgres,
+ struct pci_ecam_ops **ecam_ops)
+{
+   struct mcfg_fixup *f;
+   int i;
+
+   /*
+* First match against PCI topology  then use OEM ID, OEM
+* table ID, and OEM revision from MCFG table standard header.
+*/
+   for (i = 0, f = mcfg_quirks; i < ARRAY_SIZE(mcfg_quirks); i++, f++) {
+   if (f->seg == root->segment &&


Is dropping the comparison with MCFG_DOM_ANY intended? It is useful if
all the controllers (segs) can use the same quirk (X-Gene case).
If you decide to drop it, then we can remove MCFG_DOM_ANY definition as well.


+   resource_contains(>bus_range, >secondary) &&
+   !memcmp(f->oem_id, mcfg_oem_id, ACPI_OEM_ID_SIZE) &&
+   !memcmp(f->oem_table_id, mcfg_oem_table_id,
+   ACPI_OEM_TABLE_ID_SIZE) &&
+   f->oem_revision == mcfg_oem_revision) {
+   if (f->cfgres.start)
+   *cfgres = f->cfgres;
+   if (f->ops)
+   *ecam_ops =  f->ops;
+   dev_info(>device->dev, "Applying PCI MCFG quirks for 
%s %s rev: %d\n",
+f->oem_id, f->oem_table_id, f->oem_revision);
+   return;
+   }
+   }
+}

 /* List to save MCFG entries */
 static LIST_HEAD(pci_mcfg_list);
@@ -61,14 +114,24 @@ int pci_mcfg_lookup(struct acpi_pci_root *root, struct 
resource *cfgres,

}

-   if (!root->mcfg_addr)
-   return -ENXIO;
-
 skip_lookup:
memset(, 0, sizeof(res));
-   res.start = root->mcfg_addr + (bus_res->start << 20);
-   res.end = res.start + (resource_size(bus_res) << 20) - 1;
-   res.flags = IORESOURCE_MEM;
+   if (root->mcfg_addr) {
+   res.start = root->mcfg_addr + (bus_res->start << 20);
+   res.end = res.start + (resource_size(bus_res) << 20) - 1;
+   res.flags = IORESOURCE_MEM;
+   }
+
+   /*
+* Let to override default ECAM ops and CFG resource range.
+* Also, this might even retrieve CFG 

Re: [PATCH V6 2/5] PCI/ACPI: Check platform specific ECAM quirks

[Tomasz Nowicki]

On 13.09.2016 00:47, Duc Dang wrote:

On Mon, Sep 12, 2016 at 3:24 PM, Duc Dang  wrote:

On Fri, Sep 9, 2016 at 12:24 PM, Tomasz Nowicki  wrote:


Some platforms may not be fully compliant with generic set of PCI config
accessors. For these cases we implement the way to overwrite CFG accessors
set and configuration space range.

In first place pci_mcfg_parse() saves machine's IDs and revision number
(these come from MCFG header) in order to match against known quirk entries.
Then the algorithm traverses available quirk list (static array),
matches against  and
returns custom PCI config ops and/or CFG resource structure.

When adding new quirk there are two possibilities:
1. Override default pci_generic_ecam_ops ops but CFG resource comes from MCFG
{ "OEM_ID", "OEM_TABLE_ID", , , , _ops, MCFG_RES_EMPTY 
},
2. Override default pci_generic_ecam_ops ops and CFG resource. For this case
it is also allowed get CFG resource from quirk entry w/o having it in MCFG.
{ "OEM_ID", "OEM_TABLE_ID", , , , _ops,
  DEFINE_RES_MEM(START, SIZE) },

pci_generic_ecam_ops and MCFG entries will be used for platforms
free from quirks.

Signed-off-by: Tomasz Nowicki 
Signed-off-by: Dongdong Liu 
Signed-off-by: Christopher Covington 
---
 drivers/acpi/pci_mcfg.c | 80 +
 1 file changed, 74 insertions(+), 6 deletions(-)

diff --git a/drivers/acpi/pci_mcfg.c b/drivers/acpi/pci_mcfg.c
index ffcc651..2b8acc7 100644
--- a/drivers/acpi/pci_mcfg.c
+++ b/drivers/acpi/pci_mcfg.c
@@ -32,6 +32,59 @@ struct mcfg_entry {
u8  bus_start;
u8  bus_end;
 };
+struct mcfg_fixup {
+   char oem_id[ACPI_OEM_ID_SIZE + 1];
+   char oem_table_id[ACPI_OEM_TABLE_ID_SIZE + 1];
+   u32 oem_revision;
+   u16 seg;
+   struct resource bus_range;
+   struct pci_ecam_ops *ops;
+   struct resource cfgres;
+};
+
+#define MCFG_DOM_ANY   (-1)
+#define MCFG_BUS_RANGE(start, end) DEFINE_RES_NAMED((start),   \
+   ((end) - (start) + 1),  \
+   NULL, IORESOURCE_BUS)
+#define MCFG_BUS_ANY   MCFG_BUS_RANGE(0x0, 0xff)
+#define MCFG_RES_EMPTY DEFINE_RES_NAMED(0, 0, NULL, 0)
+
+static struct mcfg_fixup mcfg_quirks[] = {
+/* { OEM_ID, OEM_TABLE_ID, REV, DOMAIN, BUS_RANGE, cfgres, ops }, */
+};
+
+static char mcfg_oem_id[ACPI_OEM_ID_SIZE];
+static char mcfg_oem_table_id[ACPI_OEM_TABLE_ID_SIZE];
+static u32 mcfg_oem_revision;
+
+static void pci_mcfg_match_quirks(struct acpi_pci_root *root,
+ struct resource *cfgres,
+ struct pci_ecam_ops **ecam_ops)
+{
+   struct mcfg_fixup *f;
+   int i;
+
+   /*
+* First match against PCI topology  then use OEM ID, OEM
+* table ID, and OEM revision from MCFG table standard header.
+*/
+   for (i = 0, f = mcfg_quirks; i < ARRAY_SIZE(mcfg_quirks); i++, f++) {
+   if (f->seg == root->segment &&


Is dropping the comparison with MCFG_DOM_ANY intended? It is useful if
all the controllers (segs) can use the same quirk (X-Gene case).
If you decide to drop it, then we can remove MCFG_DOM_ANY definition as well.


+   resource_contains(>bus_range, >secondary) &&
+   !memcmp(f->oem_id, mcfg_oem_id, ACPI_OEM_ID_SIZE) &&
+   !memcmp(f->oem_table_id, mcfg_oem_table_id,
+   ACPI_OEM_TABLE_ID_SIZE) &&
+   f->oem_revision == mcfg_oem_revision) {
+   if (f->cfgres.start)
+   *cfgres = f->cfgres;
+   if (f->ops)
+   *ecam_ops =  f->ops;
+   dev_info(>device->dev, "Applying PCI MCFG quirks for 
%s %s rev: %d\n",
+f->oem_id, f->oem_table_id, f->oem_revision);
+   return;
+   }
+   }
+}

 /* List to save MCFG entries */
 static LIST_HEAD(pci_mcfg_list);
@@ -61,14 +114,24 @@ int pci_mcfg_lookup(struct acpi_pci_root *root, struct 
resource *cfgres,

}

-   if (!root->mcfg_addr)
-   return -ENXIO;
-
 skip_lookup:
memset(, 0, sizeof(res));
-   res.start = root->mcfg_addr + (bus_res->start << 20);
-   res.end = res.start + (resource_size(bus_res) << 20) - 1;
-   res.flags = IORESOURCE_MEM;
+   if (root->mcfg_addr) {
+   res.start = root->mcfg_addr + (bus_res->start << 20);
+   res.end = res.start + (resource_size(bus_res) << 20) - 1;
+   res.flags = IORESOURCE_MEM;
+   }
+
+   /*
+* Let to override default ECAM ops and CFG resource range.
+* Also, this might even retrieve CFG resource range in case MCFG
+* does not have it. Invalid CFG start address means MCFG firmware bug
+* or we need another quirk in array.
+ 

[PATCH V2] checkpatch: Add --strict test for precedence challenged macro arguments

[Joe Perches]

Add a test for macro arguents that have a non-comma leading or trailing
operator where the argument isn't parenthesized to avoid possible precedence
issues.

Signed-off-by: Joe Perches 
---

V2: Fix silly comment typo

 scripts/checkpatch.pl | 9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index f135f8e..ea1a7ad 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -4836,7 +4836,7 @@ sub process {
 # check if any macro arguments are reused (ignore '...' and 'type')
foreach my $arg (@def_args) {
next if ($arg =~ /\.\.\./);
-   next if ($arg =~ /^type$/);
+   next if ($arg =~ /^type$/i);
my $tmp = $define_stmt;
$tmp =~ 
s/\b(typeof|__typeof__|__builtin\w+|typecheck\s*\(\s*$Type\s*,|\#+)\s*\(*\s*$arg\s*\)*\b//g;
$tmp =~ s/\#\s*$arg\b//g;
@@ -4845,6 +4845,13 @@ sub process {
if ($use_cnt > 1) {
CHK("MACRO_ARG_REUSE",
"Macro argument reuse '$arg' - 
possible side-effects?\n" . "$herectx");
+   }
+# check if any macro arguments may have other precedence issues
+   if ($define_stmt =~ 
m/($Operators)?\s*\b$arg\b\s*($Operators)?/m &&
+   ((defined($1) && $1 ne ',') ||
+(defined($2) && $2 ne ','))) {
+   CHK("MACRO_ARG_PRECEDENCE",
+   "Macro argument '$arg' may be 
better as '($arg)' to avoid precedence issues\n" . "$herectx");
}
}
 
-- 
2.10.0.rc2.1.g053435c

[PATCH V2] checkpatch: Add --strict test for precedence challenged macro arguments

[Joe Perches]

Add a test for macro arguents that have a non-comma leading or trailing
operator where the argument isn't parenthesized to avoid possible precedence
issues.

Signed-off-by: Joe Perches 
---

V2: Fix silly comment typo

 scripts/checkpatch.pl | 9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index f135f8e..ea1a7ad 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -4836,7 +4836,7 @@ sub process {
 # check if any macro arguments are reused (ignore '...' and 'type')
foreach my $arg (@def_args) {
next if ($arg =~ /\.\.\./);
-   next if ($arg =~ /^type$/);
+   next if ($arg =~ /^type$/i);
my $tmp = $define_stmt;
$tmp =~ 
s/\b(typeof|__typeof__|__builtin\w+|typecheck\s*\(\s*$Type\s*,|\#+)\s*\(*\s*$arg\s*\)*\b//g;
$tmp =~ s/\#\s*$arg\b//g;
@@ -4845,6 +4845,13 @@ sub process {
if ($use_cnt > 1) {
CHK("MACRO_ARG_REUSE",
"Macro argument reuse '$arg' - 
possible side-effects?\n" . "$herectx");
+   }
+# check if any macro arguments may have other precedence issues
+   if ($define_stmt =~ 
m/($Operators)?\s*\b$arg\b\s*($Operators)?/m &&
+   ((defined($1) && $1 ne ',') ||
+(defined($2) && $2 ne ','))) {
+   CHK("MACRO_ARG_PRECEDENCE",
+   "Macro argument '$arg' may be 
better as '($arg)' to avoid precedence issues\n" . "$herectx");
}
}
 
-- 
2.10.0.rc2.1.g053435c

Re: [PATCH] usb: cleanup with list_first_entry_or_null()

[Felipe Balbi]

Hi Masahiro,

Masahiro Yamada  writes:
> The combo of list_empty() check and return list_first_entry()
> can be replaced with list_first_entry_or_null().
>
> Signed-off-by: Masahiro Yamada 
> ---

Care to split this into two patches (one for dwc2 and one for dwc3)?

thanks

-- 
balbi


signature.asc
Description: PGP signature

Re: [PATCH] usb: cleanup with list_first_entry_or_null()

[Felipe Balbi]

Hi Masahiro,

Masahiro Yamada  writes:
> The combo of list_empty() check and return list_first_entry()
> can be replaced with list_first_entry_or_null().
>
> Signed-off-by: Masahiro Yamada 
> ---

Care to split this into two patches (one for dwc2 and one for dwc3)?

thanks

-- 
balbi


signature.asc
Description: PGP signature

Re: [PATCH 2/2] usb: dwc3: Added a property to set GFLADJ register

[Felipe Balbi]

Hi,

Rob Herring  writes:
>> Synopsys HW setup (HAPS DX and phy board) requires a preset to this
>> register to improve interoperablitity. For example, the value for
>> GFLADJ_REFCLK_LPM_SEL should be set to 0 with ref_clk period of 50.
>
> This sounds like it should be handled in the driver. Is it a simple, 
> constant correlation of ref_clk period to this value?

you mean that this could be calculated based off of clk_get_rate() ?

-- 
balbi


signature.asc
Description: PGP signature

Re: [PATCH 2/2] usb: dwc3: Added a property to set GFLADJ register

[Felipe Balbi]

Hi,

Rob Herring  writes:
>> Synopsys HW setup (HAPS DX and phy board) requires a preset to this
>> register to improve interoperablitity. For example, the value for
>> GFLADJ_REFCLK_LPM_SEL should be set to 0 with ref_clk period of 50.
>
> This sounds like it should be handled in the driver. Is it a simple, 
> constant correlation of ref_clk period to this value?

you mean that this could be calculated based off of clk_get_rate() ?

-- 
balbi


signature.asc
Description: PGP signature

[PATCH 0/2] checkpatch: Add --strict macro argument tests

[Joe Perches]

This is rather better than the first submission.
I think this is acceptable and doesn't need to be RFC.

Joe Perches (2):
  checkpatch: Add --strict test for macro argument reuse
  checkpatch: Add --strict test for precedence challenged macro arguments

 scripts/checkpatch.pl | 50 ++
 1 file changed, 42 insertions(+), 8 deletions(-)

-- 
2.10.0.rc2.1.g053435c

[PATCH 1/2] checkpatch: Add --strict test for macro argument reuse

[Joe Perches]

If a macro argument is used multiple times in the macro definition,
the macro argument may have an unexpected side-effect.

Add a test (MACRO_ARG_REUSE) for that condition which is only
emitted with command-line option --strict.

Signed-off-by: Joe Perches 
---
 scripts/checkpatch.pl | 43 +++
 1 file changed, 35 insertions(+), 8 deletions(-)

diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index 3fa2b2e..f135f8e 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -4753,7 +4753,17 @@ sub process {
$has_flow_statement = 1 if ($ctx =~ 
/\b(goto|return)\b/);
$has_arg_concat = 1 if ($ctx =~ /\#\#/ && $ctx !~ 
/\#\#\s*(?:__VA_ARGS__|args)\b/);
 
-   $dstat =~ 
s/^.\s*\#\s*define\s+$Ident(?:\([^\)]*\))?\s*//;
+   $dstat =~ s/^.\s*\#\s*define\s+$Ident(\([^\)]*\))?\s*//;
+   my $define_args = $1;
+   my $define_stmt = $dstat;
+   my @def_args = ();
+
+   if (defined $define_args && $define_args ne "") {
+   $define_args = substr($define_args, 1, 
length($define_args) - 2);
+   $define_args =~ s/\s*//g;
+   @def_args = split(",", $define_args);
+   }
+
$dstat =~ s/$;//g;
$dstat =~ s/\\\n.//g;
$dstat =~ s/^\s*//s;
@@ -4789,6 +4799,15 @@ sub process {
^\[
}x;
#print "REST<$rest> dstat<$dstat> ctx<$ctx>\n";
+
+   $ctx =~ s/\n*$//;
+   my $herectx = $here . "\n";
+   my $stmt_cnt = statement_rawlines($ctx);
+
+   for (my $n = 0; $n < $stmt_cnt; $n++) {
+   $herectx .= raw_line($linenr, $n) . "\n";
+   }
+
if ($dstat ne '' &&
$dstat !~ /^(?:$Ident|-?$Constant),$/ &&
# 10, // foo(),
$dstat !~ /^(?:$Ident|-?$Constant);$/ &&
# foo();
@@ -4804,13 +4823,6 @@ sub process {
$dstat !~ /^\(\{/ &&
# ({...
$ctx !~ 
/^.\s*#\s*define\s+TRACE_(?:SYSTEM|INCLUDE_FILE|INCLUDE_PATH)\b/)
{
-   $ctx =~ s/\n*$//;
-   my $herectx = $here . "\n";
-   my $cnt = statement_rawlines($ctx);
-
-   for (my $n = 0; $n < $cnt; $n++) {
-   $herectx .= raw_line($linenr, $n) . 
"\n";
-   }
 
if ($dstat =~ /;/) {

ERROR("MULTISTATEMENT_MACRO_USE_DO_WHILE",
@@ -4819,6 +4831,21 @@ sub process {
ERROR("COMPLEX_MACRO",
  "Macros with complex values 
should be enclosed in parentheses\n" . "$herectx");
}
+
+   }
+# check if any macro arguments are reused (ignore '...' and 'type')
+   foreach my $arg (@def_args) {
+   next if ($arg =~ /\.\.\./);
+   next if ($arg =~ /^type$/);
+   my $tmp = $define_stmt;
+   $tmp =~ 
s/\b(typeof|__typeof__|__builtin\w+|typecheck\s*\(\s*$Type\s*,|\#+)\s*\(*\s*$arg\s*\)*\b//g;
+   $tmp =~ s/\#\s*$arg\b//g;
+   $tmp =~ s/\b$arg\s*\#\#//g;
+   my $use_cnt = $tmp =~ s/\b$arg\b//g;
+   if ($use_cnt > 1) {
+   CHK("MACRO_ARG_REUSE",
+   "Macro argument reuse '$arg' - 
possible side-effects?\n" . "$herectx");
+   }
}
 
 # check for macros with flow control, but without ## concatenation
-- 
2.10.0.rc2.1.g053435c

[PATCH 2/2] checkpatch: Add --strict test for precedence challenged macro arguments

[Joe Perches]

Add a test for macro arguents that have a non-comma leading or trailing
operator where the argument isn't parenthesized to avoid possible precedence
issues.

Signed-off-by: Joe Perches 
---
 scripts/checkpatch.pl | 9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index f135f8e..6e067e5 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -4836,7 +4836,7 @@ sub process {
 # check if any macro arguments are reused (ignore '...' and 'type')
foreach my $arg (@def_args) {
next if ($arg =~ /\.\.\./);
-   next if ($arg =~ /^type$/);
+   next if ($arg =~ /^type$/i);
my $tmp = $define_stmt;
$tmp =~ 
s/\b(typeof|__typeof__|__builtin\w+|typecheck\s*\(\s*$Type\s*,|\#+)\s*\(*\s*$arg\s*\)*\b//g;
$tmp =~ s/\#\s*$arg\b//g;
@@ -4846,6 +4846,13 @@ sub process {
CHK("MACRO_ARG_REUSE",
"Macro argument reuse '$arg' - 
possible side-effects?\n" . "$herectx");
}
++# check if any macro arguments may have other precedence issues
+   if ($define_stmt =~ 
m/($Operators)?\s*\b$arg\b\s*($Operators)?/m &&
+   ((defined($1) && $1 ne ',') ||
+(defined($2) && $2 ne ','))) {
+   CHK("MACRO_ARG_PRECEDENCE",
+   "Macro argument '$arg' may be 
better as '($arg)' to avoid precedence issues\n" . "$herectx");
+   }
}
 
 # check for macros with flow control, but without ## concatenation
-- 
2.10.0.rc2.1.g053435c

[PATCH 0/2] checkpatch: Add --strict macro argument tests

[Joe Perches]

This is rather better than the first submission.
I think this is acceptable and doesn't need to be RFC.

Joe Perches (2):
  checkpatch: Add --strict test for macro argument reuse
  checkpatch: Add --strict test for precedence challenged macro arguments

 scripts/checkpatch.pl | 50 ++
 1 file changed, 42 insertions(+), 8 deletions(-)

-- 
2.10.0.rc2.1.g053435c

[PATCH 1/2] checkpatch: Add --strict test for macro argument reuse

[Joe Perches]

If a macro argument is used multiple times in the macro definition,
the macro argument may have an unexpected side-effect.

Add a test (MACRO_ARG_REUSE) for that condition which is only
emitted with command-line option --strict.

Signed-off-by: Joe Perches 
---
 scripts/checkpatch.pl | 43 +++
 1 file changed, 35 insertions(+), 8 deletions(-)

diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index 3fa2b2e..f135f8e 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -4753,7 +4753,17 @@ sub process {
$has_flow_statement = 1 if ($ctx =~ 
/\b(goto|return)\b/);
$has_arg_concat = 1 if ($ctx =~ /\#\#/ && $ctx !~ 
/\#\#\s*(?:__VA_ARGS__|args)\b/);
 
-   $dstat =~ 
s/^.\s*\#\s*define\s+$Ident(?:\([^\)]*\))?\s*//;
+   $dstat =~ s/^.\s*\#\s*define\s+$Ident(\([^\)]*\))?\s*//;
+   my $define_args = $1;
+   my $define_stmt = $dstat;
+   my @def_args = ();
+
+   if (defined $define_args && $define_args ne "") {
+   $define_args = substr($define_args, 1, 
length($define_args) - 2);
+   $define_args =~ s/\s*//g;
+   @def_args = split(",", $define_args);
+   }
+
$dstat =~ s/$;//g;
$dstat =~ s/\\\n.//g;
$dstat =~ s/^\s*//s;
@@ -4789,6 +4799,15 @@ sub process {
^\[
}x;
#print "REST<$rest> dstat<$dstat> ctx<$ctx>\n";
+
+   $ctx =~ s/\n*$//;
+   my $herectx = $here . "\n";
+   my $stmt_cnt = statement_rawlines($ctx);
+
+   for (my $n = 0; $n < $stmt_cnt; $n++) {
+   $herectx .= raw_line($linenr, $n) . "\n";
+   }
+
if ($dstat ne '' &&
$dstat !~ /^(?:$Ident|-?$Constant),$/ &&
# 10, // foo(),
$dstat !~ /^(?:$Ident|-?$Constant);$/ &&
# foo();
@@ -4804,13 +4823,6 @@ sub process {
$dstat !~ /^\(\{/ &&
# ({...
$ctx !~ 
/^.\s*#\s*define\s+TRACE_(?:SYSTEM|INCLUDE_FILE|INCLUDE_PATH)\b/)
{
-   $ctx =~ s/\n*$//;
-   my $herectx = $here . "\n";
-   my $cnt = statement_rawlines($ctx);
-
-   for (my $n = 0; $n < $cnt; $n++) {
-   $herectx .= raw_line($linenr, $n) . 
"\n";
-   }
 
if ($dstat =~ /;/) {

ERROR("MULTISTATEMENT_MACRO_USE_DO_WHILE",
@@ -4819,6 +4831,21 @@ sub process {
ERROR("COMPLEX_MACRO",
  "Macros with complex values 
should be enclosed in parentheses\n" . "$herectx");
}
+
+   }
+# check if any macro arguments are reused (ignore '...' and 'type')
+   foreach my $arg (@def_args) {
+   next if ($arg =~ /\.\.\./);
+   next if ($arg =~ /^type$/);
+   my $tmp = $define_stmt;
+   $tmp =~ 
s/\b(typeof|__typeof__|__builtin\w+|typecheck\s*\(\s*$Type\s*,|\#+)\s*\(*\s*$arg\s*\)*\b//g;
+   $tmp =~ s/\#\s*$arg\b//g;
+   $tmp =~ s/\b$arg\s*\#\#//g;
+   my $use_cnt = $tmp =~ s/\b$arg\b//g;
+   if ($use_cnt > 1) {
+   CHK("MACRO_ARG_REUSE",
+   "Macro argument reuse '$arg' - 
possible side-effects?\n" . "$herectx");
+   }
}
 
 # check for macros with flow control, but without ## concatenation
-- 
2.10.0.rc2.1.g053435c

[PATCH 2/2] checkpatch: Add --strict test for precedence challenged macro arguments

[Joe Perches]

Add a test for macro arguents that have a non-comma leading or trailing
operator where the argument isn't parenthesized to avoid possible precedence
issues.

Signed-off-by: Joe Perches 
---
 scripts/checkpatch.pl | 9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index f135f8e..6e067e5 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -4836,7 +4836,7 @@ sub process {
 # check if any macro arguments are reused (ignore '...' and 'type')
foreach my $arg (@def_args) {
next if ($arg =~ /\.\.\./);
-   next if ($arg =~ /^type$/);
+   next if ($arg =~ /^type$/i);
my $tmp = $define_stmt;
$tmp =~ 
s/\b(typeof|__typeof__|__builtin\w+|typecheck\s*\(\s*$Type\s*,|\#+)\s*\(*\s*$arg\s*\)*\b//g;
$tmp =~ s/\#\s*$arg\b//g;
@@ -4846,6 +4846,13 @@ sub process {
CHK("MACRO_ARG_REUSE",
"Macro argument reuse '$arg' - 
possible side-effects?\n" . "$herectx");
}
++# check if any macro arguments may have other precedence issues
+   if ($define_stmt =~ 
m/($Operators)?\s*\b$arg\b\s*($Operators)?/m &&
+   ((defined($1) && $1 ne ',') ||
+(defined($2) && $2 ne ','))) {
+   CHK("MACRO_ARG_PRECEDENCE",
+   "Macro argument '$arg' may be 
better as '($arg)' to avoid precedence issues\n" . "$herectx");
+   }
}
 
 # check for macros with flow control, but without ## concatenation
-- 
2.10.0.rc2.1.g053435c

Re: [RFC PATCH 2/3] tracing/syscalls: add handling for compat tasks

[Marcin Nowakowski]

Hi Andy,

Thanks for your review and the comments, I'll address them in a next 
iteration. Do you have any other comments on the complete patchset?


On 12.09.2016 19:35, Andy Lutomirski wrote:

On Sep 9, 2016 1:04 AM, "Marcin Nowakowski"
 wrote:


Extend the syscall tracing subsystem by adding a handler for compat
tasks. For some architectures, where compat tasks' syscall numbers have
an exclusive set of syscall numbers, this already works since the
removal of syscall_nr.
Architectures where the same syscall may use a different syscall number
for compat tasks need to define ARCH_COMPAT_SYSCALL_NUMBERS_OVERLAP and
define a method arch_trace_is_compat_syscall(struct pt_regs*) that tells
if a current task is a compat one.
For architectures that define ARCH_COMPAT_SYSCALL_NUMBERS_OVERLAP the
number of trace event files is doubled and all syscall trace events are
identified by the syscall number offset by NR_syscalls.

Note that as this patch series is posted as an RFC, this currently only
includes arch updates for MIPS and x86 (and has only been tested on
MIPS and x86_64). I will work on updating other arch trees after this
solution is reviewed.


I bet you didn't test x32 -- see below :)


Indeed ... I've tried with x86_64 and 32-bit x86, but not x32 syscalls. 
I will review that part.




Signed-off-by: Marcin Nowakowski 

---
 arch/mips/kernel/ftrace.c |   4 +-
 arch/x86/include/asm/ftrace.h |  10 +---
 arch/x86/kernel/ftrace.c  |  14 ++
 include/linux/ftrace.h|   2 +-
 kernel/trace/trace.h  |  11 +++-
 kernel/trace/trace_syscalls.c | 113 +-
 6 files changed, 94 insertions(+), 60 deletions(-)

diff --git a/arch/mips/kernel/ftrace.c b/arch/mips/kernel/ftrace.c
index 937c54b..e150cf6 100644
--- a/arch/mips/kernel/ftrace.c
+++ b/arch/mips/kernel/ftrace.c
@@ -412,7 +412,7 @@ out:
 #ifdef CONFIG_FTRACE_SYSCALLS

 #ifdef CONFIG_32BIT
-unsigned long __init arch_syscall_addr(int nr)
+unsigned long __init arch_syscall_addr(int nr, int compat)
 {
return (unsigned long)sys_call_table[nr - __NR_O32_Linux];
 }
@@ -420,7 +420,7 @@ unsigned long __init arch_syscall_addr(int nr)

 #ifdef CONFIG_64BIT

-unsigned long __init arch_syscall_addr(int nr)
+unsigned long __init arch_syscall_addr(int nr, int compat)


bool compat?


Yes, that should make the intention more clear.


 {
 #ifdef CONFIG_MIPS32_N32
if (nr >= __NR_N32_Linux && nr <= __NR_N32_Linux + 
__NR_N32_Linux_syscalls)
diff --git a/arch/x86/include/asm/ftrace.h b/arch/x86/include/asm/ftrace.h
index a4820d4..a24a21c 100644
--- a/arch/x86/include/asm/ftrace.h
+++ b/arch/x86/include/asm/ftrace.h
@@ -47,15 +47,7 @@ int ftrace_int3_handler(struct pt_regs *regs);
 #if defined(CONFIG_FTRACE_SYSCALLS) && defined(CONFIG_IA32_EMULATION)
 #include 

-/*
- * Because ia32 syscalls do not map to x86_64 syscall numbers
- * this screws up the trace output when tracing a ia32 task.
- * Instead of reporting bogus syscalls, just do not trace them.
- *
- * If the user really wants these, then they should use the
- * raw syscall tracepoints with filtering.
- */
-#define ARCH_TRACE_IGNORE_COMPAT_SYSCALLS 1
+#define ARCH_COMPAT_SYSCALL_NUMBERS_OVERLAP 1
 static inline bool arch_trace_is_compat_syscall(struct pt_regs *regs)
 {
if (in_compat_syscall())


This isn't your fault obviously, but shouldn't that be in_ia32_syscall()?


Thanks for pointing this out - I'll need to review this part of code a 
bit more.


Marcin

Re: [RFC PATCH 2/3] tracing/syscalls: add handling for compat tasks

[Marcin Nowakowski]

Hi Andy,

Thanks for your review and the comments, I'll address them in a next 
iteration. Do you have any other comments on the complete patchset?


On 12.09.2016 19:35, Andy Lutomirski wrote:

On Sep 9, 2016 1:04 AM, "Marcin Nowakowski"
 wrote:


Extend the syscall tracing subsystem by adding a handler for compat
tasks. For some architectures, where compat tasks' syscall numbers have
an exclusive set of syscall numbers, this already works since the
removal of syscall_nr.
Architectures where the same syscall may use a different syscall number
for compat tasks need to define ARCH_COMPAT_SYSCALL_NUMBERS_OVERLAP and
define a method arch_trace_is_compat_syscall(struct pt_regs*) that tells
if a current task is a compat one.
For architectures that define ARCH_COMPAT_SYSCALL_NUMBERS_OVERLAP the
number of trace event files is doubled and all syscall trace events are
identified by the syscall number offset by NR_syscalls.

Note that as this patch series is posted as an RFC, this currently only
includes arch updates for MIPS and x86 (and has only been tested on
MIPS and x86_64). I will work on updating other arch trees after this
solution is reviewed.


I bet you didn't test x32 -- see below :)


Indeed ... I've tried with x86_64 and 32-bit x86, but not x32 syscalls. 
I will review that part.




Signed-off-by: Marcin Nowakowski 

---
 arch/mips/kernel/ftrace.c |   4 +-
 arch/x86/include/asm/ftrace.h |  10 +---
 arch/x86/kernel/ftrace.c  |  14 ++
 include/linux/ftrace.h|   2 +-
 kernel/trace/trace.h  |  11 +++-
 kernel/trace/trace_syscalls.c | 113 +-
 6 files changed, 94 insertions(+), 60 deletions(-)

diff --git a/arch/mips/kernel/ftrace.c b/arch/mips/kernel/ftrace.c
index 937c54b..e150cf6 100644
--- a/arch/mips/kernel/ftrace.c
+++ b/arch/mips/kernel/ftrace.c
@@ -412,7 +412,7 @@ out:
 #ifdef CONFIG_FTRACE_SYSCALLS

 #ifdef CONFIG_32BIT
-unsigned long __init arch_syscall_addr(int nr)
+unsigned long __init arch_syscall_addr(int nr, int compat)
 {
return (unsigned long)sys_call_table[nr - __NR_O32_Linux];
 }
@@ -420,7 +420,7 @@ unsigned long __init arch_syscall_addr(int nr)

 #ifdef CONFIG_64BIT

-unsigned long __init arch_syscall_addr(int nr)
+unsigned long __init arch_syscall_addr(int nr, int compat)


bool compat?


Yes, that should make the intention more clear.


 {
 #ifdef CONFIG_MIPS32_N32
if (nr >= __NR_N32_Linux && nr <= __NR_N32_Linux + 
__NR_N32_Linux_syscalls)
diff --git a/arch/x86/include/asm/ftrace.h b/arch/x86/include/asm/ftrace.h
index a4820d4..a24a21c 100644
--- a/arch/x86/include/asm/ftrace.h
+++ b/arch/x86/include/asm/ftrace.h
@@ -47,15 +47,7 @@ int ftrace_int3_handler(struct pt_regs *regs);
 #if defined(CONFIG_FTRACE_SYSCALLS) && defined(CONFIG_IA32_EMULATION)
 #include 

-/*
- * Because ia32 syscalls do not map to x86_64 syscall numbers
- * this screws up the trace output when tracing a ia32 task.
- * Instead of reporting bogus syscalls, just do not trace them.
- *
- * If the user really wants these, then they should use the
- * raw syscall tracepoints with filtering.
- */
-#define ARCH_TRACE_IGNORE_COMPAT_SYSCALLS 1
+#define ARCH_COMPAT_SYSCALL_NUMBERS_OVERLAP 1
 static inline bool arch_trace_is_compat_syscall(struct pt_regs *regs)
 {
if (in_compat_syscall())


This isn't your fault obviously, but shouldn't that be in_ia32_syscall()?


Thanks for pointing this out - I'll need to review this part of code a 
bit more.


Marcin

Re: DAX mapping detection (was: Re: [PATCH] Fix region lost in /proc/self/smaps)

[Nicholas Piggin]

On Mon, 12 Sep 2016 21:06:49 -0700
Dan Williams  wrote:

> On Mon, Sep 12, 2016 at 6:31 PM, Nicholas Piggin  wrote:
> > On Mon, 12 Sep 2016 08:01:48 -0700  
> [..]
> > That said, a noop system call is on the order of 100 cycles nowadays,
> > so rushing to implement these APIs without seeing good numbers and
> > actual users ready to go seems premature. *This* is the real reason
> > not to implement new APIs yet.  
> 
> Yes, and harvesting the current crop of low hanging performance fruit
> in the filesystem-DAX I/O path remains on the todo list.
> 
> In the meantime we're pursuing this mm api, mincore+ or whatever we
> end up with, to allow userspace to distinguish memory address ranges
> that are backed by a filesystem requiring coordination of metadata
> updates + flushes for updates, vs something like device-dax that does
> not.

Yes, that's reasonable.

Do you need page/block granularity? Do you need a way to advise/request
the fs for a particular capability? Is it enough to request and check
success? Would the capability be likely to change, and if so, how would
you notify the app asynchronously?

Re: DAX mapping detection (was: Re: [PATCH] Fix region lost in /proc/self/smaps)

[Nicholas Piggin]

On Mon, 12 Sep 2016 21:06:49 -0700
Dan Williams  wrote:

> On Mon, Sep 12, 2016 at 6:31 PM, Nicholas Piggin  wrote:
> > On Mon, 12 Sep 2016 08:01:48 -0700  
> [..]
> > That said, a noop system call is on the order of 100 cycles nowadays,
> > so rushing to implement these APIs without seeing good numbers and
> > actual users ready to go seems premature. *This* is the real reason
> > not to implement new APIs yet.  
> 
> Yes, and harvesting the current crop of low hanging performance fruit
> in the filesystem-DAX I/O path remains on the todo list.
> 
> In the meantime we're pursuing this mm api, mincore+ or whatever we
> end up with, to allow userspace to distinguish memory address ranges
> that are backed by a filesystem requiring coordination of metadata
> updates + flushes for updates, vs something like device-dax that does
> not.

Yes, that's reasonable.

Do you need page/block granularity? Do you need a way to advise/request
the fs for a particular capability? Is it enough to request and check
success? Would the capability be likely to change, and if so, how would
you notify the app asynchronously?

Re: Question about suspend/resume clock handling in dwc3-of-simple.c

[Felipe Balbi]

Hi,

Guenter Roeck  writes:
>> > Should it be clk_disable_unprepare(), or maybe something like the
>> > following
>> >
>> >if (!pm_runtime_status_suspended(dev))
>> >clk_disable_unprepare();
>> >else
>> >clk_unprepare();
>> 
>> I'm not sure how balanced those calls are, yeah. I don't have HW to test
>> PM with. But note that as it is, there is no actual runtime PM support,
>> so clk_disable_unprepare() will always be necessary.
>> 
>> Perhaps we will find further issues when someone tries to use runtime PM
>> with dwc3-of-simple. ;-)
>> 
>
> We are working on code derived from it, so unless I can convince the author
> that he can not just use clk_unprepare() I suspect we'll hit the problem.
> If so, I'll let you know.

Are you sending that upstream? Depending on your requirements, it might
be easier to patch dwc3-of-simple.c then adding yet another glue layer :-)

-- 
balbi


signature.asc
Description: PGP signature

Re: Question about suspend/resume clock handling in dwc3-of-simple.c

[Felipe Balbi]

Hi,

Guenter Roeck  writes:
>> > Should it be clk_disable_unprepare(), or maybe something like the
>> > following
>> >
>> >if (!pm_runtime_status_suspended(dev))
>> >clk_disable_unprepare();
>> >else
>> >clk_unprepare();
>> 
>> I'm not sure how balanced those calls are, yeah. I don't have HW to test
>> PM with. But note that as it is, there is no actual runtime PM support,
>> so clk_disable_unprepare() will always be necessary.
>> 
>> Perhaps we will find further issues when someone tries to use runtime PM
>> with dwc3-of-simple. ;-)
>> 
>
> We are working on code derived from it, so unless I can convince the author
> that he can not just use clk_unprepare() I suspect we'll hit the problem.
> If so, I'll let you know.

Are you sending that upstream? Depending on your requirements, it might
be easier to patch dwc3-of-simple.c then adding yet another glue layer :-)

-- 
balbi


signature.asc
Description: PGP signature

Re: [PATCH v7 9/9] drm/mediatek: add support for Mediatek SoC MT2701

[CK Hu]

Hi, YT:

On Mon, 2016-09-12 at 18:16 +0800, YT Shen wrote:
> Hi CK,
> 
> On Wed, 2016-09-07 at 13:37 +0800, CK Hu wrote:
> > Hi, YT:
> > 
> > On Fri, 2016-09-02 at 19:24 +0800, YT Shen wrote:
> > > This patch add support for the Mediatek MT2701 DISP subsystem.
> > > There is only one OVL engine in MT2701.
> > > 
> > > Signed-off-by: YT Shen 
> > 
> > [snip...]
> > 
> > > diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c 
> > > b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> > > index 4b4e449..465819b 100644
> > > --- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> > > +++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> > > @@ -112,6 +112,7 @@ struct mtk_ddp_comp_match {
> > >  
> > >  static const struct mtk_ddp_comp_match 
> > > mtk_ddp_matches[DDP_COMPONENT_ID_MAX] = {
> > >   [DDP_COMPONENT_AAL] = { MTK_DISP_AAL,   0, NULL },
> > > + [DDP_COMPONENT_BLS] = { MTK_DISP_PWM,   0, NULL },
> > 
> > I think BLS is different than PWM, so this statement should be
> > 
> > [DDP_COMPONENT_BLS] = { MTK_DISP_BLS, 0, NULL };
> The BLS module actually is a multifunction device, one of them is the
> PWM function.  We only upstream PWM function [1] now, and it is
> accepted.  When there are real use case (gamma function), we will update
> this part.  What do you think?

I think BLS = PWM + GAMMA and the device with register range from
0x1400a000 to 0x1400afff should be called BLS. I think this device is
called PWM in [1] because it just use its PWM function and it's not
suitable. At least in DRM driver, we should use the term BLS rather than
PWM. Maybe we should define as below:

[DDP_COMPONENT_BLS] = { MTK_DISP_BLS, 0, NULL };

and

{ .compatible = "mediatek,mt2701-disp-pwm",   .data = (void
*)MTK_DISP_BLS },


Regards,
CK

[1] https://patchwork.kernel.org/patch/9223001/

> 
> Regards,
> yt.shen
> 
> [1] https://patchwork.kernel.org/patch/9223001/
> 
> > 
> > 
> > >   [DDP_COMPONENT_COLOR0]  = { MTK_DISP_COLOR, 0, _color },
> > >   [DDP_COMPONENT_COLOR1]  = { MTK_DISP_COLOR, 1, _color },
> > >   [DDP_COMPONENT_DPI0]= { MTK_DPI,0, NULL },
> > 
> > Regards,
> > CK
> > 
> > 
> 
> 

Re: [PATCH v7 9/9] drm/mediatek: add support for Mediatek SoC MT2701

[CK Hu]

Hi, YT:

On Mon, 2016-09-12 at 18:16 +0800, YT Shen wrote:
> Hi CK,
> 
> On Wed, 2016-09-07 at 13:37 +0800, CK Hu wrote:
> > Hi, YT:
> > 
> > On Fri, 2016-09-02 at 19:24 +0800, YT Shen wrote:
> > > This patch add support for the Mediatek MT2701 DISP subsystem.
> > > There is only one OVL engine in MT2701.
> > > 
> > > Signed-off-by: YT Shen 
> > 
> > [snip...]
> > 
> > > diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c 
> > > b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> > > index 4b4e449..465819b 100644
> > > --- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> > > +++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> > > @@ -112,6 +112,7 @@ struct mtk_ddp_comp_match {
> > >  
> > >  static const struct mtk_ddp_comp_match 
> > > mtk_ddp_matches[DDP_COMPONENT_ID_MAX] = {
> > >   [DDP_COMPONENT_AAL] = { MTK_DISP_AAL,   0, NULL },
> > > + [DDP_COMPONENT_BLS] = { MTK_DISP_PWM,   0, NULL },
> > 
> > I think BLS is different than PWM, so this statement should be
> > 
> > [DDP_COMPONENT_BLS] = { MTK_DISP_BLS, 0, NULL };
> The BLS module actually is a multifunction device, one of them is the
> PWM function.  We only upstream PWM function [1] now, and it is
> accepted.  When there are real use case (gamma function), we will update
> this part.  What do you think?

I think BLS = PWM + GAMMA and the device with register range from
0x1400a000 to 0x1400afff should be called BLS. I think this device is
called PWM in [1] because it just use its PWM function and it's not
suitable. At least in DRM driver, we should use the term BLS rather than
PWM. Maybe we should define as below:

[DDP_COMPONENT_BLS] = { MTK_DISP_BLS, 0, NULL };

and

{ .compatible = "mediatek,mt2701-disp-pwm",   .data = (void
*)MTK_DISP_BLS },


Regards,
CK

[1] https://patchwork.kernel.org/patch/9223001/

> 
> Regards,
> yt.shen
> 
> [1] https://patchwork.kernel.org/patch/9223001/
> 
> > 
> > 
> > >   [DDP_COMPONENT_COLOR0]  = { MTK_DISP_COLOR, 0, _color },
> > >   [DDP_COMPONENT_COLOR1]  = { MTK_DISP_COLOR, 1, _color },
> > >   [DDP_COMPONENT_DPI0]= { MTK_DPI,0, NULL },
> > 
> > Regards,
> > CK
> > 
> > 
> 
> 

Re: [PATCH v15 1/5] extcon: Introduce EXTCON_PROP_DISP_HPD property

[Chanwoo Choi]

Dear all,

On 2016년 09월 10일 11:15, Chris Zhong wrote:
> EXTCON_PROP_DISP_HPD is need by display port, if the system has no hpd
> interrupt, this property can be used.
> 
> Signed-off-by: Chris Zhong 
> ---
> 
> Changes in v15: None
> Changes in v14: None
> Changes in v13: None
> Changes in v12: None
> Changes in v11: None
> Changes in v10: None
> Changes in v9: None
> Changes in v8: None
> Changes in v7: None
> Changes in v6: None
> Changes in v5: None
> Changes in v4: None
> Changes in v3: None
> Changes in v2: None
> Changes in v1: None
> 
>  include/linux/extcon.h | 14 +-
>  1 file changed, 13 insertions(+), 1 deletion(-)
> 
> diff --git a/include/linux/extcon.h b/include/linux/extcon.h
> index 9147c42..4411893 100644
> --- a/include/linux/extcon.h
> +++ b/include/linux/extcon.h
> @@ -131,9 +131,21 @@
>  #define EXTCON_PROP_JACK_MAX 100
>  #define EXTCON_PROP_JACK_CNT (EXTCON_PROP_JACK_MAX - EXTCON_PROP_JACK_MIN + 
> 1)
>  
> +/*
> + * Properties of EXTCON_TYPE_DISP.
> + *
> + * - EXTCON_PROP_DISP_HPD
> + * @type:   integer (intval)
> + * @value:  0 (no hpd) or 1 (hpd)
> + * @default:0 (no hpd)
> + *
> + */
> +
> +#define EXTCON_PROP_DISP_HPD 150
> +
>  /* Properties of EXTCON_TYPE_DISP. */
>  #define EXTCON_PROP_DISP_MIN 150
> -#define EXTCON_PROP_DISP_MAX 150
> +#define EXTCON_PROP_DISP_MAX 151
>  #define EXTCON_PROP_DISP_CNT (EXTCON_PROP_DISP_MAX - EXTCON_PROP_DISP_MIN + 
> 1)
>  
>  /*
> 

This patch rely on the extcon git repository to support the extcon property.
I created the immutable branch(ib-extcon-phy-4.9). I send this pull request
to prevent the build error.

Best Regards,
Chanwoo Choi

The following changes since commit 29b4817d4018df78086157ea3a55c1d9424a7cfc:

  Linux 4.8-rc1 (2016-08-07 18:18:00 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/chanwoo/extcon.git 
ib-extcon-phy-4.9

for you to fetch changes up to c7914e8dfa4032d24ef7af4c86b9c841ec6b74e6:

  extcon: Introduce EXTCON_PROP_DISP_HPD property (2016-09-13 10:08:47 +0900)


Chanwoo Choi (12):
  extcon: arizona: Remove the usage of extcon_update_state()
  extcon: adc-jack: Remove the usage of extcon_set_state()
  extcon: gpio: Remove the usage of extcon_set_state()
  extcon: Remove the state_store() to prevent the wrong access
  extcon: Block the bit masking operation for cable state except for extcon 
core
  extcon: Add the extcon_type to gather each connector into five category
  extcon: Add the support for extcon property according to extcon type
  extcon: Add the support for the capability of each property
  extcon: Rename the extcon_set/get_state() to maintain the function naming 
pattern
  extcon: Add the synchronization extcon APIs to support the notification
  extcon: Add new EXTCON_DISP_HMD for Head-mounted Display device
  extcon: Add new EXTCON_CHG_WPT for Wireless Power Transfer device

Charles Keepax (1):
  extcon: arizona: Remove unneeded semi-colon

Chris Zhong (2):
  extcon: Add EXTCON_DISP_DP and the property for USB Type-C
  extcon: Introduce EXTCON_PROP_DISP_HPD property

Guenter Roeck (1):
  extcon: Introduce EXTCON_PROP_USB_SS property for SuperSpeed mode

Maninder Singh (1):
  extcon: Fix compile time warning

Stephen Boyd (1):
  extcon: Move extcon_get_edev_by_phandle() errors to dbg level

Venkat Reddy Talla (1):
  extcon: adc-jack: update cable state during boot

 drivers/extcon/extcon-adc-jack.c   |  27 +-
 drivers/extcon/extcon-arizona.c|  13 +-
 drivers/extcon/extcon-gpio.c   |   2 +-
 drivers/extcon/extcon.c| 774 ++---
 include/linux/extcon.h | 192 +++-
 include/linux/extcon/extcon-adc-jack.h |   4 +-
 6 files changed, 820 insertions(+), 192 deletions(-)

Re: [PATCH v15 1/5] extcon: Introduce EXTCON_PROP_DISP_HPD property

[Chanwoo Choi]

Dear all,

On 2016년 09월 10일 11:15, Chris Zhong wrote:
> EXTCON_PROP_DISP_HPD is need by display port, if the system has no hpd
> interrupt, this property can be used.
> 
> Signed-off-by: Chris Zhong 
> ---
> 
> Changes in v15: None
> Changes in v14: None
> Changes in v13: None
> Changes in v12: None
> Changes in v11: None
> Changes in v10: None
> Changes in v9: None
> Changes in v8: None
> Changes in v7: None
> Changes in v6: None
> Changes in v5: None
> Changes in v4: None
> Changes in v3: None
> Changes in v2: None
> Changes in v1: None
> 
>  include/linux/extcon.h | 14 +-
>  1 file changed, 13 insertions(+), 1 deletion(-)
> 
> diff --git a/include/linux/extcon.h b/include/linux/extcon.h
> index 9147c42..4411893 100644
> --- a/include/linux/extcon.h
> +++ b/include/linux/extcon.h
> @@ -131,9 +131,21 @@
>  #define EXTCON_PROP_JACK_MAX 100
>  #define EXTCON_PROP_JACK_CNT (EXTCON_PROP_JACK_MAX - EXTCON_PROP_JACK_MIN + 
> 1)
>  
> +/*
> + * Properties of EXTCON_TYPE_DISP.
> + *
> + * - EXTCON_PROP_DISP_HPD
> + * @type:   integer (intval)
> + * @value:  0 (no hpd) or 1 (hpd)
> + * @default:0 (no hpd)
> + *
> + */
> +
> +#define EXTCON_PROP_DISP_HPD 150
> +
>  /* Properties of EXTCON_TYPE_DISP. */
>  #define EXTCON_PROP_DISP_MIN 150
> -#define EXTCON_PROP_DISP_MAX 150
> +#define EXTCON_PROP_DISP_MAX 151
>  #define EXTCON_PROP_DISP_CNT (EXTCON_PROP_DISP_MAX - EXTCON_PROP_DISP_MIN + 
> 1)
>  
>  /*
> 

This patch rely on the extcon git repository to support the extcon property.
I created the immutable branch(ib-extcon-phy-4.9). I send this pull request
to prevent the build error.

Best Regards,
Chanwoo Choi

The following changes since commit 29b4817d4018df78086157ea3a55c1d9424a7cfc:

  Linux 4.8-rc1 (2016-08-07 18:18:00 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/chanwoo/extcon.git 
ib-extcon-phy-4.9

for you to fetch changes up to c7914e8dfa4032d24ef7af4c86b9c841ec6b74e6:

  extcon: Introduce EXTCON_PROP_DISP_HPD property (2016-09-13 10:08:47 +0900)


Chanwoo Choi (12):
  extcon: arizona: Remove the usage of extcon_update_state()
  extcon: adc-jack: Remove the usage of extcon_set_state()
  extcon: gpio: Remove the usage of extcon_set_state()
  extcon: Remove the state_store() to prevent the wrong access
  extcon: Block the bit masking operation for cable state except for extcon 
core
  extcon: Add the extcon_type to gather each connector into five category
  extcon: Add the support for extcon property according to extcon type
  extcon: Add the support for the capability of each property
  extcon: Rename the extcon_set/get_state() to maintain the function naming 
pattern
  extcon: Add the synchronization extcon APIs to support the notification
  extcon: Add new EXTCON_DISP_HMD for Head-mounted Display device
  extcon: Add new EXTCON_CHG_WPT for Wireless Power Transfer device

Charles Keepax (1):
  extcon: arizona: Remove unneeded semi-colon

Chris Zhong (2):
  extcon: Add EXTCON_DISP_DP and the property for USB Type-C
  extcon: Introduce EXTCON_PROP_DISP_HPD property

Guenter Roeck (1):
  extcon: Introduce EXTCON_PROP_USB_SS property for SuperSpeed mode

Maninder Singh (1):
  extcon: Fix compile time warning

Stephen Boyd (1):
  extcon: Move extcon_get_edev_by_phandle() errors to dbg level

Venkat Reddy Talla (1):
  extcon: adc-jack: update cable state during boot

 drivers/extcon/extcon-adc-jack.c   |  27 +-
 drivers/extcon/extcon-arizona.c|  13 +-
 drivers/extcon/extcon-gpio.c   |   2 +-
 drivers/extcon/extcon.c| 774 ++---
 include/linux/extcon.h | 192 +++-
 include/linux/extcon/extcon-adc-jack.h |   4 +-
 6 files changed, 820 insertions(+), 192 deletions(-)

[PATCH v5 1/3] arm/dts: add pcie aer interrupt-name property in the dts

[Po Liu]

NXP arm aer interrupt was not MSI/MSI-X/INTx but using interrupt
line independently. This patch add a "aer" interrupt-names for
aer interrupt.

With the interrupt-names "aer", code could probe aer interrupt line
for pcie root port, replace the aer interrupt service irq.

This patch is intend to fixup the Layerscape platforms which aer
interrupt was not MSI/MSI-X/INTx, but using interrupt line independently.

Signed-off-by: Po Liu 
---
changes for v5:
- Seperate arm arm64 dts changes

 arch/arm/boot/dts/ls1021a.dtsi | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/ls1021a.dtsi b/arch/arm/boot/dts/ls1021a.dtsi
index 368e219..443e50b 100644
--- a/arch/arm/boot/dts/ls1021a.dtsi
+++ b/arch/arm/boot/dts/ls1021a.dtsi
@@ -634,7 +634,8 @@
reg = <0x00 0x0340 0x0 0x0001   /* controller 
registers */
   0x40 0x 0x0 0x2000>; /* 
configuration space */
reg-names = "regs", "config";
-   interrupts = ; /* 
controller interrupt */
+   interrupts = ; /* aer 
interrupt */
+   interrupt-names = "aer";
fsl,pcie-scfg = < 0>;
#address-cells = <3>;
#size-cells = <2>;
@@ -657,7 +658,8 @@
reg = <0x00 0x0350 0x0 0x0001   /* controller 
registers */
   0x48 0x 0x0 0x2000>; /* 
configuration space */
reg-names = "regs", "config";
-   interrupts = ;
+   interrupts = ; /* aer 
interrupt */
+   interrupt-names = "aer";
fsl,pcie-scfg = < 1>;
#address-cells = <3>;
#size-cells = <2>;
-- 
2.1.0.27.g96db324

[PATCH v5 1/3] arm/dts: add pcie aer interrupt-name property in the dts

[Po Liu]

NXP arm aer interrupt was not MSI/MSI-X/INTx but using interrupt
line independently. This patch add a "aer" interrupt-names for
aer interrupt.

With the interrupt-names "aer", code could probe aer interrupt line
for pcie root port, replace the aer interrupt service irq.

This patch is intend to fixup the Layerscape platforms which aer
interrupt was not MSI/MSI-X/INTx, but using interrupt line independently.

Signed-off-by: Po Liu 
---
changes for v5:
- Seperate arm arm64 dts changes

 arch/arm/boot/dts/ls1021a.dtsi | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/ls1021a.dtsi b/arch/arm/boot/dts/ls1021a.dtsi
index 368e219..443e50b 100644
--- a/arch/arm/boot/dts/ls1021a.dtsi
+++ b/arch/arm/boot/dts/ls1021a.dtsi
@@ -634,7 +634,8 @@
reg = <0x00 0x0340 0x0 0x0001   /* controller 
registers */
   0x40 0x 0x0 0x2000>; /* 
configuration space */
reg-names = "regs", "config";
-   interrupts = ; /* 
controller interrupt */
+   interrupts = ; /* aer 
interrupt */
+   interrupt-names = "aer";
fsl,pcie-scfg = < 0>;
#address-cells = <3>;
#size-cells = <2>;
@@ -657,7 +658,8 @@
reg = <0x00 0x0350 0x0 0x0001   /* controller 
registers */
   0x48 0x 0x0 0x2000>; /* 
configuration space */
reg-names = "regs", "config";
-   interrupts = ;
+   interrupts = ; /* aer 
interrupt */
+   interrupt-names = "aer";
fsl,pcie-scfg = < 1>;
#address-cells = <3>;
#size-cells = <2>;
-- 
2.1.0.27.g96db324

[PATCH v5 3/3] pci:aer: add support aer interrupt with none MSI/MSI-X/INTx mode

[Po Liu]

On some platforms, root port doesn't support MSI/MSI-X/INTx in RC mode.
When chip support the aer interrupt with none MSI/MSI-X/INTx mode,
maybe there is interrupt line for aer pme etc. Search the interrupt
number in the fdt file. Then fixup the dev->irq with it.

Signed-off-by: Po Liu 
---
changes for v5:
- Add clear 'aer' interrup-names description

 .../devicetree/bindings/pci/layerscape-pci.txt | 11 +---
 drivers/pci/pcie/portdrv_core.c| 31 +++---
 2 files changed, 35 insertions(+), 7 deletions(-)

diff --git a/Documentation/devicetree/bindings/pci/layerscape-pci.txt 
b/Documentation/devicetree/bindings/pci/layerscape-pci.txt
index 41e9f55..101d0a7 100644
--- a/Documentation/devicetree/bindings/pci/layerscape-pci.txt
+++ b/Documentation/devicetree/bindings/pci/layerscape-pci.txt
@@ -18,8 +18,10 @@ Required properties:
 - reg: base addresses and lengths of the PCIe controller
 - interrupts: A list of interrupt outputs of the controller. Must contain an
   entry for each entry in the interrupt-names property.
-- interrupt-names: Must include the following entries:
-  "intr": The interrupt that is asserted for controller interrupts
+- interrupt-names: It may be include the following entries:
+  "aer": The interrupt that is asserted for aer interrupt
+  "pme": The interrupt that is asserted for pme interrupt
+  ..
 - fsl,pcie-scfg: Must include two entries.
   The first entry must be a link to the SCFG device node
   The second entry must be '0' or '1' based on physical PCIe controller index.
@@ -35,8 +37,9 @@ Example:
reg = <0x00 0x0340 0x0 0x0001   /* controller registers 
*/
   0x40 0x 0x0 0x2000>; /* configuration space 
*/
reg-names = "regs", "config";
-   interrupts = ; /* controller 
interrupt */
-   interrupt-names = "intr";
+   interrupts = , /* aer 
interrupt */
+   ; /* pme interrupt */
+   interrupt-names = "aer", "pme";
fsl,pcie-scfg = < 0>;
#address-cells = <3>;
#size-cells = <2>;
diff --git a/drivers/pci/pcie/portdrv_core.c b/drivers/pci/pcie/portdrv_core.c
index e9270b4..7c4943d 100644
--- a/drivers/pci/pcie/portdrv_core.c
+++ b/drivers/pci/pcie/portdrv_core.c
@@ -16,6 +16,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "../pci.h"
 #include "portdrv.h"
@@ -200,6 +201,28 @@ static int pcie_port_enable_msix(struct pci_dev *dev, int 
*vectors, int mask)
 static int init_service_irqs(struct pci_dev *dev, int *irqs, int mask)
 {
int i, irq = -1;
+   int ret;
+   struct device_node *np = NULL;
+
+   for (i = 0; i < PCIE_PORT_DEVICE_MAXSERVICES; i++)
+   irqs[i] = 0;
+
+   if (dev->bus->dev.of_node)
+   np = dev->bus->dev.of_node;
+
+   /* If root port doesn't support MSI/MSI-X/INTx in RC mode,
+* request irq for aer
+*/
+   if (IS_ENABLED(CONFIG_OF_IRQ) && np &&
+   (mask & PCIE_PORT_SERVICE_PME)) {
+   ret = of_irq_get_byname(np, "aer");
+   if (ret > 0) {
+   irqs[PCIE_PORT_SERVICE_AER_SHIFT] = ret;
+   if (dev->irq)
+   irq = dev->irq;
+   goto no_msi;
+   }
+   }
 
/*
 * If MSI cannot be used for PCIe PME or hotplug, we have to use
@@ -225,11 +248,13 @@ static int init_service_irqs(struct pci_dev *dev, int 
*irqs, int mask)
irq = dev->irq;
 
  no_msi:
-   for (i = 0; i < PCIE_PORT_DEVICE_MAXSERVICES; i++)
-   irqs[i] = irq;
+   for (i = 0; i < PCIE_PORT_DEVICE_MAXSERVICES; i++) {
+   if (!irqs[i])
+   irqs[i] = irq;
+   }
irqs[PCIE_PORT_SERVICE_VC_SHIFT] = -1;
 
-   if (irq < 0)
+   if (irq < 0 && irqs[PCIE_PORT_SERVICE_AER_SHIFT] < 0)
return -ENODEV;
return 0;
 }
-- 
2.1.0.27.g96db324

[PATCH v5 3/3] pci:aer: add support aer interrupt with none MSI/MSI-X/INTx mode

[Po Liu]

On some platforms, root port doesn't support MSI/MSI-X/INTx in RC mode.
When chip support the aer interrupt with none MSI/MSI-X/INTx mode,
maybe there is interrupt line for aer pme etc. Search the interrupt
number in the fdt file. Then fixup the dev->irq with it.

Signed-off-by: Po Liu 
---
changes for v5:
- Add clear 'aer' interrup-names description

 .../devicetree/bindings/pci/layerscape-pci.txt | 11 +---
 drivers/pci/pcie/portdrv_core.c| 31 +++---
 2 files changed, 35 insertions(+), 7 deletions(-)

diff --git a/Documentation/devicetree/bindings/pci/layerscape-pci.txt 
b/Documentation/devicetree/bindings/pci/layerscape-pci.txt
index 41e9f55..101d0a7 100644
--- a/Documentation/devicetree/bindings/pci/layerscape-pci.txt
+++ b/Documentation/devicetree/bindings/pci/layerscape-pci.txt
@@ -18,8 +18,10 @@ Required properties:
 - reg: base addresses and lengths of the PCIe controller
 - interrupts: A list of interrupt outputs of the controller. Must contain an
   entry for each entry in the interrupt-names property.
-- interrupt-names: Must include the following entries:
-  "intr": The interrupt that is asserted for controller interrupts
+- interrupt-names: It may be include the following entries:
+  "aer": The interrupt that is asserted for aer interrupt
+  "pme": The interrupt that is asserted for pme interrupt
+  ..
 - fsl,pcie-scfg: Must include two entries.
   The first entry must be a link to the SCFG device node
   The second entry must be '0' or '1' based on physical PCIe controller index.
@@ -35,8 +37,9 @@ Example:
reg = <0x00 0x0340 0x0 0x0001   /* controller registers 
*/
   0x40 0x 0x0 0x2000>; /* configuration space 
*/
reg-names = "regs", "config";
-   interrupts = ; /* controller 
interrupt */
-   interrupt-names = "intr";
+   interrupts = , /* aer 
interrupt */
+   ; /* pme interrupt */
+   interrupt-names = "aer", "pme";
fsl,pcie-scfg = < 0>;
#address-cells = <3>;
#size-cells = <2>;
diff --git a/drivers/pci/pcie/portdrv_core.c b/drivers/pci/pcie/portdrv_core.c
index e9270b4..7c4943d 100644
--- a/drivers/pci/pcie/portdrv_core.c
+++ b/drivers/pci/pcie/portdrv_core.c
@@ -16,6 +16,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "../pci.h"
 #include "portdrv.h"
@@ -200,6 +201,28 @@ static int pcie_port_enable_msix(struct pci_dev *dev, int 
*vectors, int mask)
 static int init_service_irqs(struct pci_dev *dev, int *irqs, int mask)
 {
int i, irq = -1;
+   int ret;
+   struct device_node *np = NULL;
+
+   for (i = 0; i < PCIE_PORT_DEVICE_MAXSERVICES; i++)
+   irqs[i] = 0;
+
+   if (dev->bus->dev.of_node)
+   np = dev->bus->dev.of_node;
+
+   /* If root port doesn't support MSI/MSI-X/INTx in RC mode,
+* request irq for aer
+*/
+   if (IS_ENABLED(CONFIG_OF_IRQ) && np &&
+   (mask & PCIE_PORT_SERVICE_PME)) {
+   ret = of_irq_get_byname(np, "aer");
+   if (ret > 0) {
+   irqs[PCIE_PORT_SERVICE_AER_SHIFT] = ret;
+   if (dev->irq)
+   irq = dev->irq;
+   goto no_msi;
+   }
+   }
 
/*
 * If MSI cannot be used for PCIe PME or hotplug, we have to use
@@ -225,11 +248,13 @@ static int init_service_irqs(struct pci_dev *dev, int 
*irqs, int mask)
irq = dev->irq;
 
  no_msi:
-   for (i = 0; i < PCIE_PORT_DEVICE_MAXSERVICES; i++)
-   irqs[i] = irq;
+   for (i = 0; i < PCIE_PORT_DEVICE_MAXSERVICES; i++) {
+   if (!irqs[i])
+   irqs[i] = irq;
+   }
irqs[PCIE_PORT_SERVICE_VC_SHIFT] = -1;
 
-   if (irq < 0)
+   if (irq < 0 && irqs[PCIE_PORT_SERVICE_AER_SHIFT] < 0)
return -ENODEV;
return 0;
 }
-- 
2.1.0.27.g96db324

[PATCH v5 2/3] arm64/dts: add pcie aer interrupt-name property in the dts

[Po Liu]

Some platforms(NXP Layerscape for example) aer interrupt was not
MSI/MSI-X/INTx but using interrupt line independently. This patch
add a "aer" interrupt-names for aer interrupt.

With the interrupt-names "aer", code could probe aer interrupt line
for pcie root port, replace the aer interrupt service irq.

This is intend to fixup the Layerscape platforms which aer interrupt
was not MSI/MSI-X/INTx, but using interrupt line independently.

Signed-off-by: Po Liu 
---
changes for v5:
- Seperate arm and arm64 dts modification into two patches

 arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi | 18 +-
 arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi | 16 
 2 files changed, 17 insertions(+), 17 deletions(-)

diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi 
b/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi
index e669fbd..654071d 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi
@@ -527,9 +527,9 @@
reg = <0x00 0x0340 0x0 0x0010   /* controller 
registers */
   0x40 0x 0x0 0x2000>; /* 
configuration space */
reg-names = "regs", "config";
-   interrupts = <0 118 0x4>, /* controller interrupt */
-<0 117 0x4>; /* PME interrupt */
-   interrupt-names = "intr", "pme";
+   interrupts = <0 117 0x4>, /* PME interrupt */
+<0 118 0x4>; /* aer interrupt */
+   interrupt-names = "pme", "aer";
#address-cells = <3>;
#size-cells = <2>;
device_type = "pci";
@@ -552,9 +552,9 @@
reg = <0x00 0x0350 0x0 0x0010   /* controller 
registers */
   0x48 0x 0x0 0x2000>; /* 
configuration space */
reg-names = "regs", "config";
-   interrupts = <0 128 0x4>,
-<0 127 0x4>;
-   interrupt-names = "intr", "pme";
+   interrupts = <0 127 0x4>,
+<0 128 0x4>;
+   interrupt-names = "pme", "aer";
#address-cells = <3>;
#size-cells = <2>;
device_type = "pci";
@@ -577,9 +577,9 @@
reg = <0x00 0x0360 0x0 0x0010   /* controller 
registers */
   0x50 0x 0x0 0x2000>; /* 
configuration space */
reg-names = "regs", "config";
-   interrupts = <0 162 0x4>,
-<0 161 0x4>;
-   interrupt-names = "intr", "pme";
+   interrupts = <0 161 0x4>,
+<0 162 0x4>;
+   interrupt-names = "pme", "aer";
#address-cells = <3>;
#size-cells = <2>;
device_type = "pci";
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi 
b/arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi
index 21023a3..58844e8 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi
@@ -583,8 +583,8 @@
reg = <0x00 0x0340 0x0 0x0010   /* controller 
registers */
   0x10 0x 0x0 0x2000>; /* 
configuration space */
reg-names = "regs", "config";
-   interrupts = <0 108 0x4>; /* Level high type */
-   interrupt-names = "intr";
+   interrupts = <0 108 0x4>; /* aer interrupt */
+   interrupt-names = "aer";
#address-cells = <3>;
#size-cells = <2>;
device_type = "pci";
@@ -607,8 +607,8 @@
reg = <0x00 0x0350 0x0 0x0010   /* controller 
registers */
   0x12 0x 0x0 0x2000>; /* 
configuration space */
reg-names = "regs", "config";
-   interrupts = <0 113 0x4>; /* Level high type */
-   interrupt-names = "intr";
+   interrupts = <0 113 0x4>; /* aer interrupt */
+   interrupt-names = "aer";
#address-cells = <3>;
#size-cells = <2>;
device_type = "pci";
@@ -631,8 +631,8 @@
reg = <0x00 0x0360 0x0 0x0010   /* controller 
registers */
   0x14 0x 0x0 0x2000>; /* 
configuration space */
reg-names = "regs", "config";
-   

[PATCH v5 2/3] arm64/dts: add pcie aer interrupt-name property in the dts

[Po Liu]

Some platforms(NXP Layerscape for example) aer interrupt was not
MSI/MSI-X/INTx but using interrupt line independently. This patch
add a "aer" interrupt-names for aer interrupt.

With the interrupt-names "aer", code could probe aer interrupt line
for pcie root port, replace the aer interrupt service irq.

This is intend to fixup the Layerscape platforms which aer interrupt
was not MSI/MSI-X/INTx, but using interrupt line independently.

Signed-off-by: Po Liu 
---
changes for v5:
- Seperate arm and arm64 dts modification into two patches

 arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi | 18 +-
 arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi | 16 
 2 files changed, 17 insertions(+), 17 deletions(-)

diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi 
b/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi
index e669fbd..654071d 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi
@@ -527,9 +527,9 @@
reg = <0x00 0x0340 0x0 0x0010   /* controller 
registers */
   0x40 0x 0x0 0x2000>; /* 
configuration space */
reg-names = "regs", "config";
-   interrupts = <0 118 0x4>, /* controller interrupt */
-<0 117 0x4>; /* PME interrupt */
-   interrupt-names = "intr", "pme";
+   interrupts = <0 117 0x4>, /* PME interrupt */
+<0 118 0x4>; /* aer interrupt */
+   interrupt-names = "pme", "aer";
#address-cells = <3>;
#size-cells = <2>;
device_type = "pci";
@@ -552,9 +552,9 @@
reg = <0x00 0x0350 0x0 0x0010   /* controller 
registers */
   0x48 0x 0x0 0x2000>; /* 
configuration space */
reg-names = "regs", "config";
-   interrupts = <0 128 0x4>,
-<0 127 0x4>;
-   interrupt-names = "intr", "pme";
+   interrupts = <0 127 0x4>,
+<0 128 0x4>;
+   interrupt-names = "pme", "aer";
#address-cells = <3>;
#size-cells = <2>;
device_type = "pci";
@@ -577,9 +577,9 @@
reg = <0x00 0x0360 0x0 0x0010   /* controller 
registers */
   0x50 0x 0x0 0x2000>; /* 
configuration space */
reg-names = "regs", "config";
-   interrupts = <0 162 0x4>,
-<0 161 0x4>;
-   interrupt-names = "intr", "pme";
+   interrupts = <0 161 0x4>,
+<0 162 0x4>;
+   interrupt-names = "pme", "aer";
#address-cells = <3>;
#size-cells = <2>;
device_type = "pci";
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi 
b/arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi
index 21023a3..58844e8 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi
@@ -583,8 +583,8 @@
reg = <0x00 0x0340 0x0 0x0010   /* controller 
registers */
   0x10 0x 0x0 0x2000>; /* 
configuration space */
reg-names = "regs", "config";
-   interrupts = <0 108 0x4>; /* Level high type */
-   interrupt-names = "intr";
+   interrupts = <0 108 0x4>; /* aer interrupt */
+   interrupt-names = "aer";
#address-cells = <3>;
#size-cells = <2>;
device_type = "pci";
@@ -607,8 +607,8 @@
reg = <0x00 0x0350 0x0 0x0010   /* controller 
registers */
   0x12 0x 0x0 0x2000>; /* 
configuration space */
reg-names = "regs", "config";
-   interrupts = <0 113 0x4>; /* Level high type */
-   interrupt-names = "intr";
+   interrupts = <0 113 0x4>; /* aer interrupt */
+   interrupt-names = "aer";
#address-cells = <3>;
#size-cells = <2>;
device_type = "pci";
@@ -631,8 +631,8 @@
reg = <0x00 0x0360 0x0 0x0010   /* controller 
registers */
   0x14 0x 0x0 0x2000>; /* 
configuration space */
reg-names = "regs", "config";
-   

Re: [PATCH 2/3] ARM64: dts: amlogic: Add basic support for Amlogic S905X

[Kevin Hilman]

On Mon, Sep 12, 2016 at 2:43 PM, Andreas Färber  wrote:
> Am 12.09.2016 um 22:43 schrieb Kevin Hilman:
>> Carlo Caione  writes:
>>> On Mon, Sep 12, 2016 at 6:28 PM, Andreas Färber  wrote:
>>>
> +Boards with the Amlogic Meson GXL SoC shall have the following 
> properties:
> +  Required root node property:
> +compatible: "amlogic,meson-gxl-s905x", "amlogic,meson-gxl";

 Can we please use "amlogic,s905x", "amlogic,meson-gxl"? No need to
 complicate the name. Also affects .dtsi and .dts below.
>>>
>>> gxl != s905x.
>
> Huh? You're seemingly completely missing my point...
>
> But you are right that _Neil's_ heading needs to be fixed, too:
> Clearly not all GXL SoCs need to have an S905X compatible string!
> So it should be "Boards with the Amlogic S905X SoC shall ..." or so.
>
>>> AFAWK to the GXL family belong several different SoCs, like S905X,
>>> S905D, etc... (see patch 3/3)
>
> Thanks, I already know that, that's why you have two compatible strings
> instead of just one like for GXBB. We can certainly prepend one for
> symmetry there, too, if it makes you happier.
>
>>> This is why we use meson-gxl-s905x, meson-gxl-s905d, etc...
>>
>> Correct.
>>
>>> We could s/meson-gxl-s905x/meson-s905x/ and
>>> s/meson-gxl-s905d/meson-s905d/ but I honestly prefer this way because
>>> we can clearly see which family the SoC belongs to (the Amlogic naming
>>> convention is already messy enough).
>>> I mean, yes it's longer, but it's for the sake of documentation IMO.
>>
>> +1
>
> I still don't follow that conclusion. The board is called "amlogic,p231"
> because P231 is a unique identifier within the Amlogic namespace, so why
> not call the SoC "amlogic,s905x" for the same reason? The documentation
> is already there in having both "amlogic,s905x" _and_
> "amlogic,meson-gxl" - please re-read my post. There is no S905X in GXL
> family and another S905X in some other Amlogic SoC family, so it's
> unique and there is no reason to encode any hierarchies into its name
> other than vendor,name.
>
> I'm not arguing over the file name, where it perfectly makes sense to
> have a meson-gxl- prefix (already discussed), just about the compatible
> string where we don't have "amlogic,meson-gxl-s905x-p231" either because
> it is completely unnecessary and does _not_ add any value.

Sorry, I'm guilty of not fully reading the original post.  I was
thinking only of the filenames, which it seems were already agreed on
to be long.

> Not that we're checking this string anywhere anyway... If you want to
> check for the GXL family you have to use "amlogic,meson-gxl"; if you
> want to check for the specific SoC you use "amlogic,s905x". Simple. We
> never match partial strings, so there is no sense in a hardcoded prefix
> that is duplicating information already available.

For the compatible strings, I think your proposed shorter (but still
unique) forms are fine with me.

Kevin

Re: [PATCH 2/3] ARM64: dts: amlogic: Add basic support for Amlogic S905X

[Kevin Hilman]

On Mon, Sep 12, 2016 at 2:43 PM, Andreas Färber  wrote:
> Am 12.09.2016 um 22:43 schrieb Kevin Hilman:
>> Carlo Caione  writes:
>>> On Mon, Sep 12, 2016 at 6:28 PM, Andreas Färber  wrote:
>>>
> +Boards with the Amlogic Meson GXL SoC shall have the following 
> properties:
> +  Required root node property:
> +compatible: "amlogic,meson-gxl-s905x", "amlogic,meson-gxl";

 Can we please use "amlogic,s905x", "amlogic,meson-gxl"? No need to
 complicate the name. Also affects .dtsi and .dts below.
>>>
>>> gxl != s905x.
>
> Huh? You're seemingly completely missing my point...
>
> But you are right that _Neil's_ heading needs to be fixed, too:
> Clearly not all GXL SoCs need to have an S905X compatible string!
> So it should be "Boards with the Amlogic S905X SoC shall ..." or so.
>
>>> AFAWK to the GXL family belong several different SoCs, like S905X,
>>> S905D, etc... (see patch 3/3)
>
> Thanks, I already know that, that's why you have two compatible strings
> instead of just one like for GXBB. We can certainly prepend one for
> symmetry there, too, if it makes you happier.
>
>>> This is why we use meson-gxl-s905x, meson-gxl-s905d, etc...
>>
>> Correct.
>>
>>> We could s/meson-gxl-s905x/meson-s905x/ and
>>> s/meson-gxl-s905d/meson-s905d/ but I honestly prefer this way because
>>> we can clearly see which family the SoC belongs to (the Amlogic naming
>>> convention is already messy enough).
>>> I mean, yes it's longer, but it's for the sake of documentation IMO.
>>
>> +1
>
> I still don't follow that conclusion. The board is called "amlogic,p231"
> because P231 is a unique identifier within the Amlogic namespace, so why
> not call the SoC "amlogic,s905x" for the same reason? The documentation
> is already there in having both "amlogic,s905x" _and_
> "amlogic,meson-gxl" - please re-read my post. There is no S905X in GXL
> family and another S905X in some other Amlogic SoC family, so it's
> unique and there is no reason to encode any hierarchies into its name
> other than vendor,name.
>
> I'm not arguing over the file name, where it perfectly makes sense to
> have a meson-gxl- prefix (already discussed), just about the compatible
> string where we don't have "amlogic,meson-gxl-s905x-p231" either because
> it is completely unnecessary and does _not_ add any value.

Sorry, I'm guilty of not fully reading the original post.  I was
thinking only of the filenames, which it seems were already agreed on
to be long.

> Not that we're checking this string anywhere anyway... If you want to
> check for the GXL family you have to use "amlogic,meson-gxl"; if you
> want to check for the specific SoC you use "amlogic,s905x". Simple. We
> never match partial strings, so there is no sense in a hardcoded prefix
> that is duplicating information already available.

For the compatible strings, I think your proposed shorter (but still
unique) forms are fine with me.

Kevin

[PATCH] gpio: aspeed: Fix missing licence warning in modpost

[Joel Stanley]

Stephen Rothwell  wrote:

 > After merging the gpio tree, today's linux-next build (x86_64
 > allmodconfig) produced this warning:
 >
 > WARNING: modpost: missing MODULE_LICENSE() in drivers/gpio/gpio-aspeed.o
 >
 > Introduced by commit
 >
 >   361b79119a4b ("gpio: Add Aspeed driver")

Fix it by adding the correct licence.

Fixes: 361b79119a4b ("gpio: Add Aspeed driver")
Reported-by: Stephen Rothwell 
Signed-off-by: Joel Stanley 
---
 drivers/gpio/gpio-aspeed.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpio/gpio-aspeed.c b/drivers/gpio/gpio-aspeed.c
index 64348a6fb60f..9f7266e05f0a 100644
--- a/drivers/gpio/gpio-aspeed.c
+++ b/drivers/gpio/gpio-aspeed.c
@@ -455,3 +455,4 @@ static struct platform_driver aspeed_gpio_driver = {
 module_platform_driver_probe(aspeed_gpio_driver, aspeed_gpio_probe);
 
 MODULE_DESCRIPTION("Aspeed GPIO Driver");
+MODULE_LICENSE("GPL");
-- 
2.9.3

[PATCH] gpio: aspeed: Fix missing licence warning in modpost

[Joel Stanley]

Stephen Rothwell  wrote:

 > After merging the gpio tree, today's linux-next build (x86_64
 > allmodconfig) produced this warning:
 >
 > WARNING: modpost: missing MODULE_LICENSE() in drivers/gpio/gpio-aspeed.o
 >
 > Introduced by commit
 >
 >   361b79119a4b ("gpio: Add Aspeed driver")

Fix it by adding the correct licence.

Fixes: 361b79119a4b ("gpio: Add Aspeed driver")
Reported-by: Stephen Rothwell 
Signed-off-by: Joel Stanley 
---
 drivers/gpio/gpio-aspeed.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpio/gpio-aspeed.c b/drivers/gpio/gpio-aspeed.c
index 64348a6fb60f..9f7266e05f0a 100644
--- a/drivers/gpio/gpio-aspeed.c
+++ b/drivers/gpio/gpio-aspeed.c
@@ -455,3 +455,4 @@ static struct platform_driver aspeed_gpio_driver = {
 module_platform_driver_probe(aspeed_gpio_driver, aspeed_gpio_probe);
 
 MODULE_DESCRIPTION("Aspeed GPIO Driver");
+MODULE_LICENSE("GPL");
-- 
2.9.3

linux-next: Tree for Sep 13

[Stephen Rothwell]

Hi all,

Changes since 20160912:

The v4l-dvb tree lost its build failure.

The netfilter-next tree gained a conflict against the net tree.

The kbuild tree gained a conflict against Linus' tree and still had its
build warnings for PowerPC, for which I reverted a commit.

The gpio tree lost its build failure but gained a conflict against the
pinctrl tree.

Non-merge commits (relative to Linus' tree): 6686
 6623 files changed, 317800 insertions(+), 202629 deletions(-)



I have created today's linux-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
(patches at http://www.kernel.org/pub/linux/kernel/next/ ).  If you
are tracking the linux-next tree using git, you should not use "git pull"
to do so as that will try to merge the new linux-next release with the
old one.  You should use "git fetch" and checkout or reset to the new
master.

You can see which trees have been included by looking in the Next/Trees
file in the source.  There are also quilt-import.log and merge.log
files in the Next directory.  Between each merge, the tree was built
with a ppc64_defconfig for powerpc and an allmodconfig (with
CONFIG_BUILD_DOCSRC=n) for x86_64, a multi_v7_defconfig for arm and a
native build of tools/perf. After the final fixups (if any), I do an
x86_64 modules_install followed by builds for x86_64 allnoconfig,
powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig, allyesconfig
(this fails its final link) and pseries_le_defconfig and i386, sparc
and sparc64 defconfig.

Below is a summary of the state of the merge.

I am currently merging 241 trees (counting Linus' and 34 trees of patches
pending for Linus' tree).

Stats about the size of the tree over time can be seen at
http://neuling.org/linux-next-size.html .

Status of my local build tests will be at
http://kisskb.ellerman.id.au/linux-next .  If maintainers want to give
advice about cross compilers/configs that work, we are always open to add
more builds.

Thanks to Randy Dunlap for doing many randconfig builds.  And to Paul
Gortmaker for triage and bug fixes.

-- 
Cheers,
Stephen Rothwell

$ git checkout master
$ git reset --hard stable
Merging origin/master (da499f8f5385 Merge 
git://git.kernel.org/pub/scm/linux/kernel/git/davem/net)
Merging fixes/master (d3396e1e4ec4 Merge tag 'fixes-for-linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc)
Merging kbuild-current/rc-fixes (d3e2773c4ede builddeb: Skip gcc-plugins when 
not configured)
Merging arc-current/for-curr (3eab887a5542 Linux 4.8-rc4)
Merging arm-current/fixes (1a57c286d8ce ARM: pxa/lubbock: add pcmcia clock)
Merging m68k-current/for-linus (6bd80f372371 m68k/defconfig: Update defconfigs 
for v4.7-rc2)
Merging metag-fixes/fixes (97b1d23f7bcb metag: Drop show_mem() from mem_init())
Merging powerpc-fixes/fixes (f077aaf0754b powerpc/mm: Don't alias user region 
to other regions below PAGE_OFFSET)
Merging sparc/master (4620a06e4b3c shmem: Fix link error if huge pages support 
is disabled)
Merging net/master (da499f8f5385 Merge 
git://git.kernel.org/pub/scm/linux/kernel/git/davem/net)
Merging ipsec/master (1fb81e09d487 vti: use right inner_mode for inbound inter 
address family policy checks)
Merging netfilter/master (ecfcdfec7e0c netfilter: nf_nat: handle NF_DROP from 
nfnetlink_parse_nat_setup())
Merging ipvs/master (ea43f860d984 Merge branch 'ethoc-fixes')
Merging wireless-drivers/master (a0714125d11b Merge ath-current from ath.git)
Merging mac80211/master (5df20f2141ea mac80211: make mpath path fixing more 
robust)
Merging sound-current/for-linus (3f640970a414 ALSA: hda - Fix headset mic 
detection problem for several Dell laptops)
Merging pci-current/for-linus (6af7e4f77259 PCI: Mark Haswell Power Control 
Unit as having non-compliant BARs)
Merging driver-core.current/driver-core-linus (c6935931c189 Linux 4.8-rc5)
Merging tty.current/tty-linus (c6935931c189 Linux 4.8-rc5)
Merging usb.current/usb-linus (9395452b4aab Linux 4.8-rc6)
Merging usb-gadget-fixes/fixes (696118c016dd usb: dwc3: pci: fix build warning 
on !PM_SLEEP)
Merging usb-serial-fixes/usb-linus (f190fd92458d USB: serial: simple: add 
support for another Infineon flashloader)
Merging usb-chipidea-fixes/ci-for-usb-stable (6f3c4fb6d05e usb: chipidea: udc: 
fix NULL ptr dereference in isr_setup_status_phase)
Merging staging.current/staging-linus (9395452b4aab Linux 4.8-rc6)
Merging char-misc.current/char-misc-linus (c6935931c189 Linux 4.8-rc5)
Merging input-current/for-linus (4af2ff91ec3f Input: silead_gsl1680 - use 
"silead/" prefix for firmware loading)
Merging crypto-current/master (0bd2223594a4 crypto: cryptd - initialize child 
shash_desc on import)
Merging ide/master (797cee982eef Merge branch 'stable-4.8' of 
git://git.infradead.org/users/pcmoore/audit)
Merging rr-fixes/fixes (8244062ef1e5 modules: fix longstanding /proc/kallsyms 
vs module insertion race.)
Merging vfio-fixes/for-linus (c

linux-next: Tree for Sep 13

[Stephen Rothwell]

Hi all,

Changes since 20160912:

The v4l-dvb tree lost its build failure.

The netfilter-next tree gained a conflict against the net tree.

The kbuild tree gained a conflict against Linus' tree and still had its
build warnings for PowerPC, for which I reverted a commit.

The gpio tree lost its build failure but gained a conflict against the
pinctrl tree.

Non-merge commits (relative to Linus' tree): 6686
 6623 files changed, 317800 insertions(+), 202629 deletions(-)



I have created today's linux-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
(patches at http://www.kernel.org/pub/linux/kernel/next/ ).  If you
are tracking the linux-next tree using git, you should not use "git pull"
to do so as that will try to merge the new linux-next release with the
old one.  You should use "git fetch" and checkout or reset to the new
master.

You can see which trees have been included by looking in the Next/Trees
file in the source.  There are also quilt-import.log and merge.log
files in the Next directory.  Between each merge, the tree was built
with a ppc64_defconfig for powerpc and an allmodconfig (with
CONFIG_BUILD_DOCSRC=n) for x86_64, a multi_v7_defconfig for arm and a
native build of tools/perf. After the final fixups (if any), I do an
x86_64 modules_install followed by builds for x86_64 allnoconfig,
powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig, allyesconfig
(this fails its final link) and pseries_le_defconfig and i386, sparc
and sparc64 defconfig.

Below is a summary of the state of the merge.

I am currently merging 241 trees (counting Linus' and 34 trees of patches
pending for Linus' tree).

Stats about the size of the tree over time can be seen at
http://neuling.org/linux-next-size.html .

Status of my local build tests will be at
http://kisskb.ellerman.id.au/linux-next .  If maintainers want to give
advice about cross compilers/configs that work, we are always open to add
more builds.

Thanks to Randy Dunlap for doing many randconfig builds.  And to Paul
Gortmaker for triage and bug fixes.

-- 
Cheers,
Stephen Rothwell

$ git checkout master
$ git reset --hard stable
Merging origin/master (da499f8f5385 Merge 
git://git.kernel.org/pub/scm/linux/kernel/git/davem/net)
Merging fixes/master (d3396e1e4ec4 Merge tag 'fixes-for-linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc)
Merging kbuild-current/rc-fixes (d3e2773c4ede builddeb: Skip gcc-plugins when 
not configured)
Merging arc-current/for-curr (3eab887a5542 Linux 4.8-rc4)
Merging arm-current/fixes (1a57c286d8ce ARM: pxa/lubbock: add pcmcia clock)
Merging m68k-current/for-linus (6bd80f372371 m68k/defconfig: Update defconfigs 
for v4.7-rc2)
Merging metag-fixes/fixes (97b1d23f7bcb metag: Drop show_mem() from mem_init())
Merging powerpc-fixes/fixes (f077aaf0754b powerpc/mm: Don't alias user region 
to other regions below PAGE_OFFSET)
Merging sparc/master (4620a06e4b3c shmem: Fix link error if huge pages support 
is disabled)
Merging net/master (da499f8f5385 Merge 
git://git.kernel.org/pub/scm/linux/kernel/git/davem/net)
Merging ipsec/master (1fb81e09d487 vti: use right inner_mode for inbound inter 
address family policy checks)
Merging netfilter/master (ecfcdfec7e0c netfilter: nf_nat: handle NF_DROP from 
nfnetlink_parse_nat_setup())
Merging ipvs/master (ea43f860d984 Merge branch 'ethoc-fixes')
Merging wireless-drivers/master (a0714125d11b Merge ath-current from ath.git)
Merging mac80211/master (5df20f2141ea mac80211: make mpath path fixing more 
robust)
Merging sound-current/for-linus (3f640970a414 ALSA: hda - Fix headset mic 
detection problem for several Dell laptops)
Merging pci-current/for-linus (6af7e4f77259 PCI: Mark Haswell Power Control 
Unit as having non-compliant BARs)
Merging driver-core.current/driver-core-linus (c6935931c189 Linux 4.8-rc5)
Merging tty.current/tty-linus (c6935931c189 Linux 4.8-rc5)
Merging usb.current/usb-linus (9395452b4aab Linux 4.8-rc6)
Merging usb-gadget-fixes/fixes (696118c016dd usb: dwc3: pci: fix build warning 
on !PM_SLEEP)
Merging usb-serial-fixes/usb-linus (f190fd92458d USB: serial: simple: add 
support for another Infineon flashloader)
Merging usb-chipidea-fixes/ci-for-usb-stable (6f3c4fb6d05e usb: chipidea: udc: 
fix NULL ptr dereference in isr_setup_status_phase)
Merging staging.current/staging-linus (9395452b4aab Linux 4.8-rc6)
Merging char-misc.current/char-misc-linus (c6935931c189 Linux 4.8-rc5)
Merging input-current/for-linus (4af2ff91ec3f Input: silead_gsl1680 - use 
"silead/" prefix for firmware loading)
Merging crypto-current/master (0bd2223594a4 crypto: cryptd - initialize child 
shash_desc on import)
Merging ide/master (797cee982eef Merge branch 'stable-4.8' of 
git://git.infradead.org/users/pcmoore/audit)
Merging rr-fixes/fixes (8244062ef1e5 modules: fix longstanding /proc/kallsyms 
vs module insertion race.)
Merging vfio-fixes/for-linus (c

Re: [PATCH 1/5] ipc/sem: do not call wake_sem_queue_do() prematurely

[Manfred Spraul]

Hi Davidlohr,

On 09/12/2016 01:53 PM, Davidlohr Bueso wrote:

... as this call should obviously be paired with its _prepare()
counterpart. At least whenever possible, as there is no harm in
calling it bogusly as we do now in a few places.

I would define the interface differently:
WAKE_Q creates an initialized wake queue. There is no need to track if 
any tasks were added to the wake queue, it is safe to call wake_up_q().
So especially for error paths, there is no need to optimize out calls to 
wake_up_q()

  Immediate error
semop(2) paths that are far from ever having the task block can
be simplified and avoid a few unnecessary loads on their way out
of the call as it is not deeply nested.
Signed-off-by: Davidlohr Bueso 
---
  ipc/sem.c | 19 ---
  1 file changed, 12 insertions(+), 7 deletions(-)

diff --git a/ipc/sem.c b/ipc/sem.c
index 5e318c5f749d..a4e8bb2fae38 100644
--- a/ipc/sem.c
+++ b/ipc/sem.c
@@ -1887,16 +1887,22 @@ SYSCALL_DEFINE4(semtimedop, int, semid, struct sembuf 
__user *, tsops,
}
  
  	error = -EFBIG;

-   if (max >= sma->sem_nsems)
-   goto out_rcu_wakeup;
+   if (max >= sma->sem_nsems) {
+   rcu_read_unlock();
+   goto out_free;
+   }
  
  	error = -EACCES;

-   if (ipcperms(ns, >sem_perm, alter ? S_IWUGO : S_IRUGO))
-   goto out_rcu_wakeup;
+   if (ipcperms(ns, >sem_perm, alter ? S_IWUGO : S_IRUGO)) {
+   rcu_read_unlock();
+   goto out_free;
+   }
  

Is this really better/simpler?
You replace "if (error) goto cleanup" with "if (error) {cleanup_1(); 
goto cleanup_2()}".


From my point of view, this just increases the risks that some cleanup 
steps are forgotten.


--
Manfred

Re: [PATCH 1/5] ipc/sem: do not call wake_sem_queue_do() prematurely

[Manfred Spraul]

Hi Davidlohr,

On 09/12/2016 01:53 PM, Davidlohr Bueso wrote:

... as this call should obviously be paired with its _prepare()
counterpart. At least whenever possible, as there is no harm in
calling it bogusly as we do now in a few places.

I would define the interface differently:
WAKE_Q creates an initialized wake queue. There is no need to track if 
any tasks were added to the wake queue, it is safe to call wake_up_q().
So especially for error paths, there is no need to optimize out calls to 
wake_up_q()

  Immediate error
semop(2) paths that are far from ever having the task block can
be simplified and avoid a few unnecessary loads on their way out
of the call as it is not deeply nested.
Signed-off-by: Davidlohr Bueso 
---
  ipc/sem.c | 19 ---
  1 file changed, 12 insertions(+), 7 deletions(-)

diff --git a/ipc/sem.c b/ipc/sem.c
index 5e318c5f749d..a4e8bb2fae38 100644
--- a/ipc/sem.c
+++ b/ipc/sem.c
@@ -1887,16 +1887,22 @@ SYSCALL_DEFINE4(semtimedop, int, semid, struct sembuf 
__user *, tsops,
}
  
  	error = -EFBIG;

-   if (max >= sma->sem_nsems)
-   goto out_rcu_wakeup;
+   if (max >= sma->sem_nsems) {
+   rcu_read_unlock();
+   goto out_free;
+   }
  
  	error = -EACCES;

-   if (ipcperms(ns, >sem_perm, alter ? S_IWUGO : S_IRUGO))
-   goto out_rcu_wakeup;
+   if (ipcperms(ns, >sem_perm, alter ? S_IWUGO : S_IRUGO)) {
+   rcu_read_unlock();
+   goto out_free;
+   }
  

Is this really better/simpler?
You replace "if (error) goto cleanup" with "if (error) {cleanup_1(); 
goto cleanup_2()}".


From my point of view, this just increases the risks that some cleanup 
steps are forgotten.


--
Manfred

linux-next: build warning after merge of the scsi tree

[Stephen Rothwell]

Hi James,

After merging the scsi tree, today's linux-next build (powerpc
allyesconfig) produced this warning:

drivers/scsi/ibmvscsi_tgt/ibmvscsi_tgt.c: In function 'ibmvscsis_rdma':
drivers/scsi/ibmvscsi_tgt/ibmvscsi_tgt.c:3190:20: warning: unused variable 
'srp' [-Wunused-variable]
struct srp_cmd *srp = (struct srp_cmd *)iue->sbuf->buf;
^

Introduced by commit

  812902159d41 ("scsi: ibmvscsis: Code cleanup of print statements")

-- 
Cheers,
Stephen Rothwell

linux-next: build warning after merge of the scsi tree

[Stephen Rothwell]

Hi James,

After merging the scsi tree, today's linux-next build (powerpc
allyesconfig) produced this warning:

drivers/scsi/ibmvscsi_tgt/ibmvscsi_tgt.c: In function 'ibmvscsis_rdma':
drivers/scsi/ibmvscsi_tgt/ibmvscsi_tgt.c:3190:20: warning: unused variable 
'srp' [-Wunused-variable]
struct srp_cmd *srp = (struct srp_cmd *)iue->sbuf->buf;
^

Introduced by commit

  812902159d41 ("scsi: ibmvscsis: Code cleanup of print statements")

-- 
Cheers,
Stephen Rothwell

Re: linux-next: manual merge of the kbuild tree with Linus' tree

[Nicholas Piggin]

On Tue, 13 Sep 2016 14:02:57 +1000
Stephen Rothwell  wrote:

> Hi Michal,
> 
> [For the new cc's, we are discussing the "thin archives" and "link dead
> code/data elimination" patches in the kbuild tree.]
> 
> On Tue, 13 Sep 2016 09:39:45 +1000 Stephen Rothwell  
> wrote:
> >
> > On Mon, 12 Sep 2016 11:03:08 +0200 Michal Marek  wrote:  
> > >
> > > On 2016-09-12 04:53, Nicholas Piggin wrote:
> > > > Question, what is the best way to merge dependent patches? Considering
> > > > they will need a good amount of architecture testing, I think they will
> > > > have to go via arch trees. But it also does not make sense to merge 
> > > > these
> > > > kbuild changes upstream first, without having tested them.  
> > > 
> > > I think it makes sense to merge the kbuild changes via kbuild.git, even
> > > if they are unused and untested. Any follow-up fixes required to enable
> > > the first architecture can go through the respective architecture tree.
> > > Does that sound OK?
> > 
> > And if you guarantee not to rebase the kbuild tree (or at least the
> > subset containing these patches), then each of the architecture trees
> > can just merge your tree (or a tag?) and then implement any necessary
> > arch dependent changes.  I fixes are necessary, they can also be merged
> > into the architecture trees.  
> 
> Except, of course, the kbuild tree still has the asm EXPORT_SYMBOL
> patches that produce warnings on PowerPC :-( (And I am still reverting
> the PowerPC specific one of those patches).
> 

I'm working on a better patch to fix that (and to whitelist powerpc's
relocation checks to it does not get blamed for such breakage)
Although no guarantees about that yet.

However some of the enablement and subsequent patches I would like to
merge are quite architecture specific, and I would prefer them to go
via arch trees.

So I would like to see a kbuild branch with these 3 in it, if arch
maintainers (or specifically powerpc) would be willing to pull it in
their -next branches.

Thanks,
Nick

Re: linux-next: manual merge of the kbuild tree with Linus' tree

[Nicholas Piggin]

On Tue, 13 Sep 2016 14:02:57 +1000
Stephen Rothwell  wrote:

> Hi Michal,
> 
> [For the new cc's, we are discussing the "thin archives" and "link dead
> code/data elimination" patches in the kbuild tree.]
> 
> On Tue, 13 Sep 2016 09:39:45 +1000 Stephen Rothwell  
> wrote:
> >
> > On Mon, 12 Sep 2016 11:03:08 +0200 Michal Marek  wrote:  
> > >
> > > On 2016-09-12 04:53, Nicholas Piggin wrote:
> > > > Question, what is the best way to merge dependent patches? Considering
> > > > they will need a good amount of architecture testing, I think they will
> > > > have to go via arch trees. But it also does not make sense to merge 
> > > > these
> > > > kbuild changes upstream first, without having tested them.  
> > > 
> > > I think it makes sense to merge the kbuild changes via kbuild.git, even
> > > if they are unused and untested. Any follow-up fixes required to enable
> > > the first architecture can go through the respective architecture tree.
> > > Does that sound OK?
> > 
> > And if you guarantee not to rebase the kbuild tree (or at least the
> > subset containing these patches), then each of the architecture trees
> > can just merge your tree (or a tag?) and then implement any necessary
> > arch dependent changes.  I fixes are necessary, they can also be merged
> > into the architecture trees.  
> 
> Except, of course, the kbuild tree still has the asm EXPORT_SYMBOL
> patches that produce warnings on PowerPC :-( (And I am still reverting
> the PowerPC specific one of those patches).
> 

I'm working on a better patch to fix that (and to whitelist powerpc's
relocation checks to it does not get blamed for such breakage)
Although no guarantees about that yet.

However some of the enablement and subsequent patches I would like to
merge are quite architecture specific, and I would prefer them to go
via arch trees.

So I would like to see a kbuild branch with these 3 in it, if arch
maintainers (or specifically powerpc) would be willing to pull it in
their -next branches.

Thanks,
Nick

Re: DAX mapping detection (was: Re: [PATCH] Fix region lost in /proc/self/smaps)

[Dan Williams]

On Mon, Sep 12, 2016 at 6:31 PM, Nicholas Piggin  wrote:
> On Mon, 12 Sep 2016 08:01:48 -0700
[..]
> That said, a noop system call is on the order of 100 cycles nowadays,
> so rushing to implement these APIs without seeing good numbers and
> actual users ready to go seems premature. *This* is the real reason
> not to implement new APIs yet.

Yes, and harvesting the current crop of low hanging performance fruit
in the filesystem-DAX I/O path remains on the todo list.

In the meantime we're pursuing this mm api, mincore+ or whatever we
end up with, to allow userspace to distinguish memory address ranges
that are backed by a filesystem requiring coordination of metadata
updates + flushes for updates, vs something like device-dax that does
not.

Re: DAX mapping detection (was: Re: [PATCH] Fix region lost in /proc/self/smaps)

[Dan Williams]

On Mon, Sep 12, 2016 at 6:31 PM, Nicholas Piggin  wrote:
> On Mon, 12 Sep 2016 08:01:48 -0700
[..]
> That said, a noop system call is on the order of 100 cycles nowadays,
> so rushing to implement these APIs without seeing good numbers and
> actual users ready to go seems premature. *This* is the real reason
> not to implement new APIs yet.

Yes, and harvesting the current crop of low hanging performance fruit
in the filesystem-DAX I/O path remains on the todo list.

In the meantime we're pursuing this mm api, mincore+ or whatever we
end up with, to allow userspace to distinguish memory address ranges
that are backed by a filesystem requiring coordination of metadata
updates + flushes for updates, vs something like device-dax that does
not.

Re: [PATCH v3] stop_machine: Make migration_cpu_stop() does useful works for CONFIG_PREEMPT_NONE

[Cheng Chao]

Peter, thank you.

on 09/12/2016 07:41 PM, Peter Zijlstra wrote:
> On Mon, Sep 12, 2016 at 01:37:27PM +0200, Peter Zijlstra wrote:
>> So what you're saying is that migration_stop_cpu() doesn't work because
>> wait_for_completion() dequeues the task.
>>
>> True I suppose. Not sure I like your solution, nor your implementation
>> of the solution much though.
>>
>> I would much prefer an unconditional cond_resched() there, but also, I
>> think we should do what __migrate_swap_task() does, and set wake_cpu.
>>
>> So something like so..
>>
>> ---
>>  kernel/sched/core.c | 8 ++--
>>  1 file changed, 6 insertions(+), 2 deletions(-)
>>
>> diff --git a/kernel/sched/core.c b/kernel/sched/core.c
>> index ddd5f48551f1..ade772aa9610 100644
>> --- a/kernel/sched/core.c
>> +++ b/kernel/sched/core.c
>> @@ -1063,8 +1063,12 @@ static int migration_cpu_stop(void *data)
>>   * holding rq->lock, if p->on_rq == 0 it cannot get enqueued because
>>   * we're holding p->pi_lock.
>>   */
>> -if (task_rq(p) == rq && task_on_rq_queued(p))
>> -rq = __migrate_task(rq, p, arg->dest_cpu);
>> +if (task_rq(p) == rq) {
>> +if (task_on_rq_queued(p))
>> +rq = __migrate_task(rq, p, arg->dest_cpu);
>> +else
>> +p->wake_cpu = arg->dest_cpu;
>> +}
>>  raw_spin_unlock(>lock);
>>  raw_spin_unlock(>pi_lock);
>>  
> 
> And this, too narrow a constraint do git diff made it go away.
> 

yes, set wake_cpu is better when try_to_wake_up(). 
Peter, Is it as a new patch?

> ---
>  kernel/stop_machine.c | 5 +
>  1 file changed, 5 insertions(+)
> 
> diff --git a/kernel/stop_machine.c b/kernel/stop_machine.c
> index ae6f41fb9cba..637798d6b554 100644
> --- a/kernel/stop_machine.c
> +++ b/kernel/stop_machine.c
> @@ -121,6 +121,11 @@ int stop_one_cpu(unsigned int cpu, cpu_stop_fn_t fn, 
> void *arg)
>   cpu_stop_init_done(, 1);
>   if (!cpu_stop_queue_work(cpu, ))
>   return -ENOENT;
> + /*
> +  * In case @cpu == smp_proccessor_id() we can avoid a sleep+wakeup
> +  * by doing a preemption.
> +  */
> + cond_resched();
>   wait_for_completion();
>   return done.ret;
>  }
> 

I agree to use cond_resched(). https://lkml.org/lkml/2016/9/12/1228

for CONFIG_PREEMPT=y and CONFIG_PREEMPT_VOLUNTARY=y, this patch seems 
unnecessary.
1. when CONFIG_PREEMPT=y
  stop_one_cpu()
  ->cpu_stop_queue_work()
->spin_unlock_irqrestore() (preempt_enable() calls __preempt_schedule())

2. when CONFIG_PREEMPT_VOLUNTARY=y
  stop_one_cpu()
  ->wait_for_completion()
->...
  ->might_sleep() (calls _cond_resched()


so we really don't need "if defined(CONFIG_PREEMPT_NONE)"?

I also think without the "if defined(CONFIG_PREEMPT_NONE)", 
the code is more clean,and the logic is still ok.



diff --git a/kernel/stop_machine.c b/kernel/stop_machine.c
index 4a1ca5f..87464a2 100644
--- a/kernel/stop_machine.c
+++ b/kernel/stop_machine.c
@@ -126,6 +126,15 @@ int stop_one_cpu(unsigned int cpu, cpu_stop_fn_t fn, void 
*arg)
cpu_stop_init_done(, 1);
if (!cpu_stop_queue_work(cpu, ))
return -ENOENT;
+
+#if defined(CONFIG_PREEMPT_NONE)
+   /*
+* In case @cpu == smp_proccessor_id() we can avoid a sleep+wakeup
+* by doing a preemption.
+*/
+   cond_resched();
+#endif
+
wait_for_completion();
return done.ret;
 }

Re: [PATCH v3] stop_machine: Make migration_cpu_stop() does useful works for CONFIG_PREEMPT_NONE

[Cheng Chao]

Peter, thank you.

on 09/12/2016 07:41 PM, Peter Zijlstra wrote:
> On Mon, Sep 12, 2016 at 01:37:27PM +0200, Peter Zijlstra wrote:
>> So what you're saying is that migration_stop_cpu() doesn't work because
>> wait_for_completion() dequeues the task.
>>
>> True I suppose. Not sure I like your solution, nor your implementation
>> of the solution much though.
>>
>> I would much prefer an unconditional cond_resched() there, but also, I
>> think we should do what __migrate_swap_task() does, and set wake_cpu.
>>
>> So something like so..
>>
>> ---
>>  kernel/sched/core.c | 8 ++--
>>  1 file changed, 6 insertions(+), 2 deletions(-)
>>
>> diff --git a/kernel/sched/core.c b/kernel/sched/core.c
>> index ddd5f48551f1..ade772aa9610 100644
>> --- a/kernel/sched/core.c
>> +++ b/kernel/sched/core.c
>> @@ -1063,8 +1063,12 @@ static int migration_cpu_stop(void *data)
>>   * holding rq->lock, if p->on_rq == 0 it cannot get enqueued because
>>   * we're holding p->pi_lock.
>>   */
>> -if (task_rq(p) == rq && task_on_rq_queued(p))
>> -rq = __migrate_task(rq, p, arg->dest_cpu);
>> +if (task_rq(p) == rq) {
>> +if (task_on_rq_queued(p))
>> +rq = __migrate_task(rq, p, arg->dest_cpu);
>> +else
>> +p->wake_cpu = arg->dest_cpu;
>> +}
>>  raw_spin_unlock(>lock);
>>  raw_spin_unlock(>pi_lock);
>>  
> 
> And this, too narrow a constraint do git diff made it go away.
> 

yes, set wake_cpu is better when try_to_wake_up(). 
Peter, Is it as a new patch?

> ---
>  kernel/stop_machine.c | 5 +
>  1 file changed, 5 insertions(+)
> 
> diff --git a/kernel/stop_machine.c b/kernel/stop_machine.c
> index ae6f41fb9cba..637798d6b554 100644
> --- a/kernel/stop_machine.c
> +++ b/kernel/stop_machine.c
> @@ -121,6 +121,11 @@ int stop_one_cpu(unsigned int cpu, cpu_stop_fn_t fn, 
> void *arg)
>   cpu_stop_init_done(, 1);
>   if (!cpu_stop_queue_work(cpu, ))
>   return -ENOENT;
> + /*
> +  * In case @cpu == smp_proccessor_id() we can avoid a sleep+wakeup
> +  * by doing a preemption.
> +  */
> + cond_resched();
>   wait_for_completion();
>   return done.ret;
>  }
> 

I agree to use cond_resched(). https://lkml.org/lkml/2016/9/12/1228

for CONFIG_PREEMPT=y and CONFIG_PREEMPT_VOLUNTARY=y, this patch seems 
unnecessary.
1. when CONFIG_PREEMPT=y
  stop_one_cpu()
  ->cpu_stop_queue_work()
->spin_unlock_irqrestore() (preempt_enable() calls __preempt_schedule())

2. when CONFIG_PREEMPT_VOLUNTARY=y
  stop_one_cpu()
  ->wait_for_completion()
->...
  ->might_sleep() (calls _cond_resched()


so we really don't need "if defined(CONFIG_PREEMPT_NONE)"?

I also think without the "if defined(CONFIG_PREEMPT_NONE)", 
the code is more clean,and the logic is still ok.



diff --git a/kernel/stop_machine.c b/kernel/stop_machine.c
index 4a1ca5f..87464a2 100644
--- a/kernel/stop_machine.c
+++ b/kernel/stop_machine.c
@@ -126,6 +126,15 @@ int stop_one_cpu(unsigned int cpu, cpu_stop_fn_t fn, void 
*arg)
cpu_stop_init_done(, 1);
if (!cpu_stop_queue_work(cpu, ))
return -ENOENT;
+
+#if defined(CONFIG_PREEMPT_NONE)
+   /*
+* In case @cpu == smp_proccessor_id() we can avoid a sleep+wakeup
+* by doing a preemption.
+*/
+   cond_resched();
+#endif
+
wait_for_completion();
return done.ret;
 }

Re: [PATCH] gpio: pca953x: initialize ret to zero to avoid returning garbage

[Phil Reid]

On 12/09/2016 21:40, Linus Walleij wrote:

On Fri, Sep 9, 2016 at 10:31 AM, Colin King  wrote:


From: Colin Ian King 

ret is not initialized so it contains garbage.  Ensure garbage
is not returned in the case that pdata && pdata->teardown is false
by initializing ret to 0.

Signed-off-by: Colin Ian King 


Patch applied.

G'day Linus,


I believe this does the same as Arnd Bergmanns patch from 26 Aug.
[PATCH 1/5] gpio: pca954x: fix undefined error code from remove

IMO Colin's is the cleaner solution.
Arnd's could be removed.

--
Regards
Phil Reid

Re: [PATCH] gpio: pca953x: initialize ret to zero to avoid returning garbage

[Phil Reid]

On 12/09/2016 21:40, Linus Walleij wrote:

On Fri, Sep 9, 2016 at 10:31 AM, Colin King  wrote:


From: Colin Ian King 

ret is not initialized so it contains garbage.  Ensure garbage
is not returned in the case that pdata && pdata->teardown is false
by initializing ret to 0.

Signed-off-by: Colin Ian King 


Patch applied.

G'day Linus,


I believe this does the same as Arnd Bergmanns patch from 26 Aug.
[PATCH 1/5] gpio: pca954x: fix undefined error code from remove

IMO Colin's is the cleaner solution.
Arnd's could be removed.

--
Regards
Phil Reid

Re: linux-next: manual merge of the kbuild tree with Linus' tree

[Stephen Rothwell]

Hi Michal,

[For the new cc's, we are discussing the "thin archives" and "link dead
code/data elimination" patches in the kbuild tree.]

On Tue, 13 Sep 2016 09:39:45 +1000 Stephen Rothwell  
wrote:
>
> On Mon, 12 Sep 2016 11:03:08 +0200 Michal Marek  wrote:
> >
> > On 2016-09-12 04:53, Nicholas Piggin wrote:  
> > > Question, what is the best way to merge dependent patches? Considering
> > > they will need a good amount of architecture testing, I think they will
> > > have to go via arch trees. But it also does not make sense to merge these
> > > kbuild changes upstream first, without having tested them.
> > 
> > I think it makes sense to merge the kbuild changes via kbuild.git, even
> > if they are unused and untested. Any follow-up fixes required to enable
> > the first architecture can go through the respective architecture tree.
> > Does that sound OK?  
> 
> And if you guarantee not to rebase the kbuild tree (or at least the
> subset containing these patches), then each of the architecture trees
> can just merge your tree (or a tag?) and then implement any necessary
> arch dependent changes.  I fixes are necessary, they can also be merged
> into the architecture trees.

Except, of course, the kbuild tree still has the asm EXPORT_SYMBOL
patches that produce warnings on PowerPC :-( (And I am still reverting
the PowerPC specific one of those patches).

-- 
Cheers,
Stephen Rothwell

Re: linux-next: manual merge of the kbuild tree with Linus' tree

[Stephen Rothwell]

Hi Michal,

[For the new cc's, we are discussing the "thin archives" and "link dead
code/data elimination" patches in the kbuild tree.]

On Tue, 13 Sep 2016 09:39:45 +1000 Stephen Rothwell  
wrote:
>
> On Mon, 12 Sep 2016 11:03:08 +0200 Michal Marek  wrote:
> >
> > On 2016-09-12 04:53, Nicholas Piggin wrote:  
> > > Question, what is the best way to merge dependent patches? Considering
> > > they will need a good amount of architecture testing, I think they will
> > > have to go via arch trees. But it also does not make sense to merge these
> > > kbuild changes upstream first, without having tested them.
> > 
> > I think it makes sense to merge the kbuild changes via kbuild.git, even
> > if they are unused and untested. Any follow-up fixes required to enable
> > the first architecture can go through the respective architecture tree.
> > Does that sound OK?  
> 
> And if you guarantee not to rebase the kbuild tree (or at least the
> subset containing these patches), then each of the architecture trees
> can just merge your tree (or a tag?) and then implement any necessary
> arch dependent changes.  I fixes are necessary, they can also be merged
> into the architecture trees.

Except, of course, the kbuild tree still has the asm EXPORT_SYMBOL
patches that produce warnings on PowerPC :-( (And I am still reverting
the PowerPC specific one of those patches).

-- 
Cheers,
Stephen Rothwell

Re: [PATCH] crypto: qce: Initialize core src clock @100Mhz

[Bjorn Andersson]

On Sat 03 Sep 09:45 PDT 2016, Iaroslav Gridin wrote:

> Without that, QCE performance is about 2x less.
> 
> Signed-off-by: Iaroslav Gridin 
> ---
>  drivers/crypto/qce/core.c | 18 +-
>  drivers/crypto/qce/core.h |  2 +-
>  2 files changed, 18 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/crypto/qce/core.c b/drivers/crypto/qce/core.c
[..]
> @@ -205,10 +209,20 @@ static int qce_crypto_probe(struct platform_device 
> *pdev)
>   if (IS_ERR(qce->bus))
>   return PTR_ERR(qce->bus);
>  
> - ret = clk_prepare_enable(qce->core);
> + ret = clk_prepare_enable(qce->core_src);
>   if (ret)
>   return ret;
>  
> + ret = clk_set_rate(qce->core_src, 1);
> + if (ret) {
> + dev_warn(qce->dev, "Unable to set QCE core src clk @100Mhz, 
> performance might be degraded\n");

This warning is misleading as you return a failure from probe() when it
happens.

> + goto err_clks_core_src;
> + }
> +
[..]
> +err_clks_core_src:
> + clk_disable_unprepare(qce->core_src);
>   return ret;
>  }
>  

Regards,
Bjorn

Re: [PATCH] crypto: qce: Initialize core src clock @100Mhz

[Bjorn Andersson]

On Sat 03 Sep 09:45 PDT 2016, Iaroslav Gridin wrote:

> Without that, QCE performance is about 2x less.
> 
> Signed-off-by: Iaroslav Gridin 
> ---
>  drivers/crypto/qce/core.c | 18 +-
>  drivers/crypto/qce/core.h |  2 +-
>  2 files changed, 18 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/crypto/qce/core.c b/drivers/crypto/qce/core.c
[..]
> @@ -205,10 +209,20 @@ static int qce_crypto_probe(struct platform_device 
> *pdev)
>   if (IS_ERR(qce->bus))
>   return PTR_ERR(qce->bus);
>  
> - ret = clk_prepare_enable(qce->core);
> + ret = clk_prepare_enable(qce->core_src);
>   if (ret)
>   return ret;
>  
> + ret = clk_set_rate(qce->core_src, 1);
> + if (ret) {
> + dev_warn(qce->dev, "Unable to set QCE core src clk @100Mhz, 
> performance might be degraded\n");

This warning is misleading as you return a failure from probe() when it
happens.

> + goto err_clks_core_src;
> + }
> +
[..]
> +err_clks_core_src:
> + clk_disable_unprepare(qce->core_src);
>   return ret;
>  }
>  

Regards,
Bjorn

Re: [PATCH 1/1] staging: slicoss: slicoss.c: fix different address space sparse warnings

[kbuild test robot]

Hi Peng,

[auto build test ERROR on staging/staging-testing]
[also build test ERROR on next-20160912]
[cannot apply to v4.8-rc6]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]
[Suggest to use git(>=2.9.0) format-patch --base= (or --base=auto for 
convenience) to record what (public, well-known) commit your patch series was 
built on]
[Check https://git-scm.com/docs/git-format-patch for more information]

url:
https://github.com/0day-ci/linux/commits/Peng-Sun/staging-slicoss-slicoss-c-fix-different-address-space-sparse-warnings/20160913-112524
config: i386-randconfig-x010-201637 (attached as .config)
compiler: gcc-6 (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
# save the attached .config to linux build tree
make ARCH=i386 

All errors (new ones prefixed by >>):

   In file included from drivers/staging/slicoss/slicoss.c:97:0:
   drivers/staging/slicoss/slicoss.c: In function 'slic_upr_request_complete':
>> drivers/staging/slicoss/slicoss.c:1022:5: error: implicit declaration of 
>> function 'readq' [-Werror=implicit-function-declaration]
readq((char __iomem *)stats +
^
   drivers/staging/slicoss/slic.h:552:19: note: in definition of macro 
'UPDATE_STATS_GB'
 (largestat) += ((newstat) - (oldstat));  \
  ^~~
   cc1: some warnings being treated as errors

vim +/readq +1022 drivers/staging/slicoss/slicoss.c

  1016  dev_err(>netdev->dev,
  1017  "SLIC_UPR_STATS command failed 
isr[%x]\n", isr);
  1018  break;
  1019  }
  1020  
  1021  UPDATE_STATS_GB(stst->tcp.xmit_tcp_segs,
> 1022  readq((char __iomem *)stats +
  1023offsetof(struct slic_stats,
  1024 xmit_tcp_segs)),
  1025  old->xmit_tcp_segs);

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: Binary data

Re: [PATCH 1/1] staging: slicoss: slicoss.c: fix different address space sparse warnings

[kbuild test robot]

Hi Peng,

[auto build test ERROR on staging/staging-testing]
[also build test ERROR on next-20160912]
[cannot apply to v4.8-rc6]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]
[Suggest to use git(>=2.9.0) format-patch --base= (or --base=auto for 
convenience) to record what (public, well-known) commit your patch series was 
built on]
[Check https://git-scm.com/docs/git-format-patch for more information]

url:
https://github.com/0day-ci/linux/commits/Peng-Sun/staging-slicoss-slicoss-c-fix-different-address-space-sparse-warnings/20160913-112524
config: i386-randconfig-x010-201637 (attached as .config)
compiler: gcc-6 (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
# save the attached .config to linux build tree
make ARCH=i386 

All errors (new ones prefixed by >>):

   In file included from drivers/staging/slicoss/slicoss.c:97:0:
   drivers/staging/slicoss/slicoss.c: In function 'slic_upr_request_complete':
>> drivers/staging/slicoss/slicoss.c:1022:5: error: implicit declaration of 
>> function 'readq' [-Werror=implicit-function-declaration]
readq((char __iomem *)stats +
^
   drivers/staging/slicoss/slic.h:552:19: note: in definition of macro 
'UPDATE_STATS_GB'
 (largestat) += ((newstat) - (oldstat));  \
  ^~~
   cc1: some warnings being treated as errors

vim +/readq +1022 drivers/staging/slicoss/slicoss.c

  1016  dev_err(>netdev->dev,
  1017  "SLIC_UPR_STATS command failed 
isr[%x]\n", isr);
  1018  break;
  1019  }
  1020  
  1021  UPDATE_STATS_GB(stst->tcp.xmit_tcp_segs,
> 1022  readq((char __iomem *)stats +
  1023offsetof(struct slic_stats,
  1024 xmit_tcp_segs)),
  1025  old->xmit_tcp_segs);

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: Binary data

Re: Build failure in -next due to 'kbuild: allow archs to select link dead code/data elimination'

[Nicholas Piggin]

On Mon, 12 Sep 2016 20:17:30 -0700
Guenter Roeck  wrote:

> Hi Nicholas,
> 
> On 09/12/2016 07:00 PM, Nicholas Piggin wrote:
> > On Mon, 12 Sep 2016 15:24:43 -0700
> > Guenter Roeck  wrote:
> >  
> >> Hi,
> >>
> >> your commit 'kbuild: allow archs to select link dead code/data elimination'
> >> is causing the following build failure in -next when building 
> >> score:defconfig.
> >>
> >> arch/score/kernel/built-in.o: In function `work_resched':
> >> arch/score/kernel/entry.o:(.text+0xe84):
> >>relocation truncated to fit: R_SCORE_PC19 against `schedule'
> >>
> >> Reverting the commit fixes the problem.
> >>
> >> Please let me know if I can help tracking down the problem.
> >> In case you need a score toochain, you can find the one I use at
> >> http://server.roeck-us.net/toolchains/score.tgz.
> >>
> >> Thanks,
> >> Guenter  
> >
> > It's not supposed to have any real effect unless the
> > option is selected, but there are a few changes to linker
> > script which must be causing it.
> >
> > There are two changes to vmlinux.lds.h. One is to KEEP a
> > few input sections, that *should* be kept anyway. The other
> > is to bring in additional sections into their correct output
> > section.
> >
> > Could you try reverting those lines of vmlinux.lds.h that
> > change the latter, i.e.:
> >
> > -   *(.text.hot .text .text.fixup .text.unlikely)   \
> > +   *(.text.hot .text .text.fixup .text.unlikely .text.*)   \  
> 
> This is the culprit. After removing " .text.*" it builds fine.

Thanks for testing it. Some architectures have .text.x sections
not included here, I should have seen that. We should possibly
just revert that line and require implementing archs to do the
right thing.

[ Convention is to use '.' to avoid C identifiers, so we should
use .text..x for these things. But that's not done completely
throughout the kernel, and a little invasive to do with this
series. I'll revisit this and clean things up subsequently after
this round gets merged. ]

Thanks,
Nick

Re: [PATCH] ARM: dts: msm8974: Add definitions for QCE & cryptobam

[Bjorn Andersson]

On Tue 30 Aug 08:37 PDT 2016, Iaroslav Gridin wrote:

> From: Voker57 
> 
> Add device tree definitions for Qualcomm Cryptography engine and its BAM
> Signed-off-by: Iaroslav Gridin 
> ---
>  arch/arm/boot/dts/qcom-msm8974.dtsi | 42 
> +
>  1 file changed, 42 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/qcom-msm8974.dtsi 
> b/arch/arm/boot/dts/qcom-msm8974.dtsi
> index 561d4d1..c0da739 100644
> --- a/arch/arm/boot/dts/qcom-msm8974.dtsi
> +++ b/arch/arm/boot/dts/qcom-msm8974.dtsi
> @@ -287,6 +287,48 @@
>   reg = <0xf9011000 0x1000>;
>   };
>  
> + cryptobam: dma@fd444000 {
> + compatible = "qcom,bam-v1.4.0";
> + reg = <0xfd444000 0x15000>;
> + interrupts = <0 236 0>;
> + clocks = < GCC_CE2_AHB_CLK>,
> +  < GCC_CE2_AXI_CLK>,
> +  < GCC_CE2_CLK>;
> + clock-names = "bam_clk", "axi_clk", "core_clk";
> + #dma-cells = <1>;
> + qcom,ee = <1>;
> + qcom,controlled-remotely;
> + };

As Stan noted, please shift this '}' one step left (the rest looks well
indented.

> +
> + qcom,qcrypto@fd44 {

Rename this "qcrypto" and make sure the address matches the reg
property.

> + compatible = "qcom,crypto-v5.1";
> + reg = <0xfd45a000 0x6000>;
> + reg-names = "crypto-base";
> + interrupts = <0 236 0>;
> + qcom,bam-pipe-pair = <2>;
> + qcom,ce-hw-instance = <1>;
> + qcom,ce-device = <0>;
> + clocks = < GCC_CE2_CLK>,
> +  < GCC_CE2_AHB_CLK>,
> +  < GCC_CE2_AXI_CLK>,
> +  < CE2_CLK_SRC>;
> +
> + dmas = < 2>, < 3>;
> + dma-names = "rx", "tx";
> + clock-names = "core", "iface", "bus", "core_src";
> + qcom,clk-mgmt-sus-res;
> + qcom,msm-bus,name = "qcrypto-noc";
> +
> + qcom,msm-bus,num-cases = <2>;
> + qcom,msm-bus,num-paths = <1>;
> + qcom,use-sw-aes-cbc-ecb-ctr-algo;
> + qcom,use-sw-aes-xts-algo;
> + qcom,use-sw-ahash-algo;
> + qcom,msm-bus,vectors-KBps = <56 512 0 0>,
> + <56 512 3936000 393600>;
> + };
> +
> +
>   timer@f902 {

It's nice to keep the nodes within a group ordered by address.

Regards,
Bjorn

Re: Build failure in -next due to 'kbuild: allow archs to select link dead code/data elimination'

[Nicholas Piggin]

On Mon, 12 Sep 2016 20:17:30 -0700
Guenter Roeck  wrote:

> Hi Nicholas,
> 
> On 09/12/2016 07:00 PM, Nicholas Piggin wrote:
> > On Mon, 12 Sep 2016 15:24:43 -0700
> > Guenter Roeck  wrote:
> >  
> >> Hi,
> >>
> >> your commit 'kbuild: allow archs to select link dead code/data elimination'
> >> is causing the following build failure in -next when building 
> >> score:defconfig.
> >>
> >> arch/score/kernel/built-in.o: In function `work_resched':
> >> arch/score/kernel/entry.o:(.text+0xe84):
> >>relocation truncated to fit: R_SCORE_PC19 against `schedule'
> >>
> >> Reverting the commit fixes the problem.
> >>
> >> Please let me know if I can help tracking down the problem.
> >> In case you need a score toochain, you can find the one I use at
> >> http://server.roeck-us.net/toolchains/score.tgz.
> >>
> >> Thanks,
> >> Guenter  
> >
> > It's not supposed to have any real effect unless the
> > option is selected, but there are a few changes to linker
> > script which must be causing it.
> >
> > There are two changes to vmlinux.lds.h. One is to KEEP a
> > few input sections, that *should* be kept anyway. The other
> > is to bring in additional sections into their correct output
> > section.
> >
> > Could you try reverting those lines of vmlinux.lds.h that
> > change the latter, i.e.:
> >
> > -   *(.text.hot .text .text.fixup .text.unlikely)   \
> > +   *(.text.hot .text .text.fixup .text.unlikely .text.*)   \  
> 
> This is the culprit. After removing " .text.*" it builds fine.

Thanks for testing it. Some architectures have .text.x sections
not included here, I should have seen that. We should possibly
just revert that line and require implementing archs to do the
right thing.

[ Convention is to use '.' to avoid C identifiers, so we should
use .text..x for these things. But that's not done completely
throughout the kernel, and a little invasive to do with this
series. I'll revisit this and clean things up subsequently after
this round gets merged. ]

Thanks,
Nick

Re: [PATCH] ARM: dts: msm8974: Add definitions for QCE & cryptobam

[Bjorn Andersson]

On Tue 30 Aug 08:37 PDT 2016, Iaroslav Gridin wrote:

> From: Voker57 
> 
> Add device tree definitions for Qualcomm Cryptography engine and its BAM
> Signed-off-by: Iaroslav Gridin 
> ---
>  arch/arm/boot/dts/qcom-msm8974.dtsi | 42 
> +
>  1 file changed, 42 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/qcom-msm8974.dtsi 
> b/arch/arm/boot/dts/qcom-msm8974.dtsi
> index 561d4d1..c0da739 100644
> --- a/arch/arm/boot/dts/qcom-msm8974.dtsi
> +++ b/arch/arm/boot/dts/qcom-msm8974.dtsi
> @@ -287,6 +287,48 @@
>   reg = <0xf9011000 0x1000>;
>   };
>  
> + cryptobam: dma@fd444000 {
> + compatible = "qcom,bam-v1.4.0";
> + reg = <0xfd444000 0x15000>;
> + interrupts = <0 236 0>;
> + clocks = < GCC_CE2_AHB_CLK>,
> +  < GCC_CE2_AXI_CLK>,
> +  < GCC_CE2_CLK>;
> + clock-names = "bam_clk", "axi_clk", "core_clk";
> + #dma-cells = <1>;
> + qcom,ee = <1>;
> + qcom,controlled-remotely;
> + };

As Stan noted, please shift this '}' one step left (the rest looks well
indented.

> +
> + qcom,qcrypto@fd44 {

Rename this "qcrypto" and make sure the address matches the reg
property.

> + compatible = "qcom,crypto-v5.1";
> + reg = <0xfd45a000 0x6000>;
> + reg-names = "crypto-base";
> + interrupts = <0 236 0>;
> + qcom,bam-pipe-pair = <2>;
> + qcom,ce-hw-instance = <1>;
> + qcom,ce-device = <0>;
> + clocks = < GCC_CE2_CLK>,
> +  < GCC_CE2_AHB_CLK>,
> +  < GCC_CE2_AXI_CLK>,
> +  < CE2_CLK_SRC>;
> +
> + dmas = < 2>, < 3>;
> + dma-names = "rx", "tx";
> + clock-names = "core", "iface", "bus", "core_src";
> + qcom,clk-mgmt-sus-res;
> + qcom,msm-bus,name = "qcrypto-noc";
> +
> + qcom,msm-bus,num-cases = <2>;
> + qcom,msm-bus,num-paths = <1>;
> + qcom,use-sw-aes-cbc-ecb-ctr-algo;
> + qcom,use-sw-aes-xts-algo;
> + qcom,use-sw-ahash-algo;
> + qcom,msm-bus,vectors-KBps = <56 512 0 0>,
> + <56 512 3936000 393600>;
> + };
> +
> +
>   timer@f902 {

It's nice to keep the nodes within a group ordered by address.

Regards,
Bjorn

Re: [RFC PATCH 1/2] mm, mincore2(): retrieve dax and tlb-size attributes of an address range

[Dan Williams]

On Mon, Sep 12, 2016 at 7:16 PM, Nicholas Piggin  wrote:
> On Mon, 12 Sep 2016 10:29:17 -0700
[..]
>> Certainly one of the new request flags can indicate that the vector is
>> made up of larger entries.
>
> Hmm. Changing prototype depending on flags. I thought I was having
> a nightmare about ioctls for a minute there :)

Heh :)

> In general, is this what we want for a new API? Should we be thinking
> about an extent API?

This probably fits better with the use cases I know that want to
consume this information, something like fiemap (mextmap, maybe?) for
memory.

Re: [RFC PATCH 1/2] mm, mincore2(): retrieve dax and tlb-size attributes of an address range

[Dan Williams]

On Mon, Sep 12, 2016 at 7:16 PM, Nicholas Piggin  wrote:
> On Mon, 12 Sep 2016 10:29:17 -0700
[..]
>> Certainly one of the new request flags can indicate that the vector is
>> made up of larger entries.
>
> Hmm. Changing prototype depending on flags. I thought I was having
> a nightmare about ioctls for a minute there :)

Heh :)

> In general, is this what we want for a new API? Should we be thinking
> about an extent API?

This probably fits better with the use cases I know that want to
consume this information, something like fiemap (mextmap, maybe?) for
memory.

Re: [PATCH] android: binder: Disable preemption while holding the global binder lock

[Arve Hjønnevåg]

On Sat, Sep 10, 2016 at 10:28 AM, Greg Kroah-Hartman
 wrote:
> On Sat, Sep 10, 2016 at 06:37:29PM +0200, Thomas Gleixner wrote:
>> On Sat, 10 Sep 2016, Peter Zijlstra wrote:
>>
>> > On Sat, Sep 10, 2016 at 09:16:59AM -0700, Christoph Hellwig wrote:
>> > > On Thu, Sep 08, 2016 at 09:12:50AM -0700, Todd Kjos wrote:
>> > > > In Android systems, the display pipeline relies on low
>> > > > latency binder transactions and is therefore sensitive to
>> > > > delays caused by contention for the global binder lock.
>> > > > Jank is siginificantly reduced by disabling preemption
>> > > > while the global binder lock is held.
>> > >
>> > > That's now how preempt_disable is supposed to use.  It is for critical
>> >
>> > not, that's supposed to be _not_. Just to be absolutely clear, this is
>> > NOT how you're supposed to use preempt_disable().
>> >
>> > > sections that use per-cpu or similar resources.
>> > >
>> > > >
>> > > > Originally-from: Riley Andrews 
>> > > > Signed-off-by: Todd Kjos 
>> >
>> > > > @@ -389,7 +390,11 @@ static int task_get_unused_fd_flags(struct
>> > > > binder_proc *proc, int flags)
>> > > >   rlim_cur = task_rlimit(proc->tsk, RLIMIT_NOFILE);
>> > > >   unlock_task_sighand(proc->tsk, );
>> > > >
>> > > > - return __alloc_fd(files, 0, rlim_cur, flags);
>> > > > + preempt_enable_no_resched();
>> > > > + ret = __alloc_fd(files, 0, rlim_cur, flags);
>> > > > + preempt_disable();
>> >
>> > And the fact that people want to use preempt_enable_no_resched() shows
>> > that they're absolutely clueless.
>> >
>> > This is so broken its not funny.
>> >
>> > NAK NAK NAK
>>
>> Indeed. Sprinkling random preempt_enabe/disable() pairs all over the place
>> documents clearly that this is tinkering and not proper software
>> engineering.
>
> I have pointed out in the other thread for this patch (the one that had
> a patch that could be applied) that the single lock in the binder code
> is the main problem here, it should be solved instead of this messing
> around with priorities.
>

While removing the single lock in the binder driver would help reduce
the problem that this patch tries to work around, it would not fix it.
The largest problems occur when a very low priority thread gets
preempted while holding the lock. When a high priority thread then
needs the same lock it can't get it. Changing the driver to use more
fine-grained locking would reduce the set of threads that can trigger
this problem, but there are processes that receive work from both high
and low priority threads and could still end up in the same situation.

A previous attempt to fix this problem, changed the lock to use
rt_mutex instead of mutex, but this apparently did not work as well as
this patch. I believe the added overhead was noticeable, and it did
not work when the preempted thread was in a different cgroup (I don't
know if this is still the case).

It would be useful to generic solution to this problem.

> So don't worry, I'm not taking this change :)
>
> thanks,
>
> greg k-h



-- 
Arve Hjønnevåg

Re: [PATCH] android: binder: Disable preemption while holding the global binder lock

[Arve Hjønnevåg]

On Sat, Sep 10, 2016 at 10:28 AM, Greg Kroah-Hartman
 wrote:
> On Sat, Sep 10, 2016 at 06:37:29PM +0200, Thomas Gleixner wrote:
>> On Sat, 10 Sep 2016, Peter Zijlstra wrote:
>>
>> > On Sat, Sep 10, 2016 at 09:16:59AM -0700, Christoph Hellwig wrote:
>> > > On Thu, Sep 08, 2016 at 09:12:50AM -0700, Todd Kjos wrote:
>> > > > In Android systems, the display pipeline relies on low
>> > > > latency binder transactions and is therefore sensitive to
>> > > > delays caused by contention for the global binder lock.
>> > > > Jank is siginificantly reduced by disabling preemption
>> > > > while the global binder lock is held.
>> > >
>> > > That's now how preempt_disable is supposed to use.  It is for critical
>> >
>> > not, that's supposed to be _not_. Just to be absolutely clear, this is
>> > NOT how you're supposed to use preempt_disable().
>> >
>> > > sections that use per-cpu or similar resources.
>> > >
>> > > >
>> > > > Originally-from: Riley Andrews 
>> > > > Signed-off-by: Todd Kjos 
>> >
>> > > > @@ -389,7 +390,11 @@ static int task_get_unused_fd_flags(struct
>> > > > binder_proc *proc, int flags)
>> > > >   rlim_cur = task_rlimit(proc->tsk, RLIMIT_NOFILE);
>> > > >   unlock_task_sighand(proc->tsk, );
>> > > >
>> > > > - return __alloc_fd(files, 0, rlim_cur, flags);
>> > > > + preempt_enable_no_resched();
>> > > > + ret = __alloc_fd(files, 0, rlim_cur, flags);
>> > > > + preempt_disable();
>> >
>> > And the fact that people want to use preempt_enable_no_resched() shows
>> > that they're absolutely clueless.
>> >
>> > This is so broken its not funny.
>> >
>> > NAK NAK NAK
>>
>> Indeed. Sprinkling random preempt_enabe/disable() pairs all over the place
>> documents clearly that this is tinkering and not proper software
>> engineering.
>
> I have pointed out in the other thread for this patch (the one that had
> a patch that could be applied) that the single lock in the binder code
> is the main problem here, it should be solved instead of this messing
> around with priorities.
>

While removing the single lock in the binder driver would help reduce
the problem that this patch tries to work around, it would not fix it.
The largest problems occur when a very low priority thread gets
preempted while holding the lock. When a high priority thread then
needs the same lock it can't get it. Changing the driver to use more
fine-grained locking would reduce the set of threads that can trigger
this problem, but there are processes that receive work from both high
and low priority threads and could still end up in the same situation.

A previous attempt to fix this problem, changed the lock to use
rt_mutex instead of mutex, but this apparently did not work as well as
this patch. I believe the added overhead was noticeable, and it did
not work when the preempted thread was in a different cgroup (I don't
know if this is still the case).

It would be useful to generic solution to this problem.

> So don't worry, I'm not taking this change :)
>
> thanks,
>
> greg k-h



-- 
Arve Hjønnevåg

Re: [PATCH 00/15] drivers: net: use IS_ENABLED() instead of checking for built-in or module

[David Miller]

From: Javier Martinez Canillas 
Date: Mon, 12 Sep 2016 10:03:31 -0400

> This trivial series is similar to [0] for net/ that you already merged, but
> for drivers/net. The patches replaces the open coding to check for a Kconfig
> symbol being built-in or module, with IS_ENABLED() macro that does the same.

Series applied, thanks.

Re: [PATCH 00/15] drivers: net: use IS_ENABLED() instead of checking for built-in or module

[David Miller]

From: Javier Martinez Canillas 
Date: Mon, 12 Sep 2016 10:03:31 -0400

> This trivial series is similar to [0] for net/ that you already merged, but
> for drivers/net. The patches replaces the open coding to check for a Kconfig
> symbol being built-in or module, with IS_ENABLED() macro that does the same.

Series applied, thanks.

RE: [PATCH for-next 02/10] IB/hns: Register add_gid and del_gid for GID Table management

[Salil Mehta]

> -Original Message-
> From: Leon Romanovsky [mailto:l...@kernel.org]
> Sent: Monday, September 12, 2016 1:40 PM
> To: Salil Mehta
> Cc: dledf...@redhat.com; Huwei (Xavier); oulijun; Zhuangyuzeng (Yisen);
> mehta.salil@gmail.com; linux-r...@vger.kernel.org; linux-
> ker...@vger.kernel.org; Linuxarm
> Subject: Re: [PATCH for-next 02/10] IB/hns: Register add_gid and
> del_gid for GID Table management
> 
> On Fri, Sep 02, 2016 at 05:37:17AM +0800, Salil Mehta wrote:
> > From: Lijun Ou 
> >
> > This patch adds support of add_gid() and del_gid() function in the
> > HNS RoCE driver for manipulation of the GID table associated with
> > port. This shall be used be used by CM when connection is
> > established.
> >
> > Signed-off-by: Lijun Ou 
> > Reviewed-by: Wei Hu 
> > Signed-off-by: Salil Mehta 
> > ---
> >  drivers/infiniband/hw/hns/hns_roce_main.c |   15 +++
> >  1 file changed, 15 insertions(+)
> >
> > diff --git a/drivers/infiniband/hw/hns/hns_roce_main.c
> b/drivers/infiniband/hw/hns/hns_roce_main.c
> > index 39e69c3..4e93120 100644
> > --- a/drivers/infiniband/hw/hns/hns_roce_main.c
> > +++ b/drivers/infiniband/hw/hns/hns_roce_main.c
> > @@ -158,6 +158,19 @@ static void hns_roce_update_gids(struct
> hns_roce_dev *hr_dev, int port)
> > ib_dispatch_event();
> >  }
> >
> > +static int hns_roce_add_gid(struct ib_device *device, u8 port_num,
> > +   unsigned int index, const union ib_gid *gid,
> > +   const struct ib_gid_attr *attr, void **context)
> > +{
> > +   return 0;
> > +}
> > +
> > +static int hns_roce_del_gid(struct ib_device *device, u8 port_num,
> > +   unsigned int index, void **context)
> > +{
> > +   return 0;
> > +}
> 
> This patch makes no sense to me. It is the same as not write this
> functions at all.
I think you are correct. Will remove this patch.  

Thanks
Salil
> 
> > +
> >  static int handle_en_event(struct hns_roce_dev *hr_dev, u8 port,
> >unsigned long event)
> >  {
> > @@ -639,6 +652,8 @@ static int hns_roce_register_device(struct
> hns_roce_dev *hr_dev)
> > ib_dev->get_link_layer  = hns_roce_get_link_layer;
> > ib_dev->get_netdev  = hns_roce_get_netdev;
> > ib_dev->query_gid   = hns_roce_query_gid;
> > +   ib_dev->add_gid = hns_roce_add_gid;
> > +   ib_dev->del_gid = hns_roce_del_gid;
> > ib_dev->query_pkey  = hns_roce_query_pkey;
> > ib_dev->alloc_ucontext  = hns_roce_alloc_ucontext;
> > ib_dev->dealloc_ucontext= hns_roce_dealloc_ucontext;
> > --
> > 1.7.9.5
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-rdma"
> in
> > the body of a message to majord...@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH for-next 02/10] IB/hns: Register add_gid and del_gid for GID Table management

[Salil Mehta]

> -Original Message-
> From: Leon Romanovsky [mailto:l...@kernel.org]
> Sent: Monday, September 12, 2016 1:40 PM
> To: Salil Mehta
> Cc: dledf...@redhat.com; Huwei (Xavier); oulijun; Zhuangyuzeng (Yisen);
> mehta.salil@gmail.com; linux-r...@vger.kernel.org; linux-
> ker...@vger.kernel.org; Linuxarm
> Subject: Re: [PATCH for-next 02/10] IB/hns: Register add_gid and
> del_gid for GID Table management
> 
> On Fri, Sep 02, 2016 at 05:37:17AM +0800, Salil Mehta wrote:
> > From: Lijun Ou 
> >
> > This patch adds support of add_gid() and del_gid() function in the
> > HNS RoCE driver for manipulation of the GID table associated with
> > port. This shall be used be used by CM when connection is
> > established.
> >
> > Signed-off-by: Lijun Ou 
> > Reviewed-by: Wei Hu 
> > Signed-off-by: Salil Mehta 
> > ---
> >  drivers/infiniband/hw/hns/hns_roce_main.c |   15 +++
> >  1 file changed, 15 insertions(+)
> >
> > diff --git a/drivers/infiniband/hw/hns/hns_roce_main.c
> b/drivers/infiniband/hw/hns/hns_roce_main.c
> > index 39e69c3..4e93120 100644
> > --- a/drivers/infiniband/hw/hns/hns_roce_main.c
> > +++ b/drivers/infiniband/hw/hns/hns_roce_main.c
> > @@ -158,6 +158,19 @@ static void hns_roce_update_gids(struct
> hns_roce_dev *hr_dev, int port)
> > ib_dispatch_event();
> >  }
> >
> > +static int hns_roce_add_gid(struct ib_device *device, u8 port_num,
> > +   unsigned int index, const union ib_gid *gid,
> > +   const struct ib_gid_attr *attr, void **context)
> > +{
> > +   return 0;
> > +}
> > +
> > +static int hns_roce_del_gid(struct ib_device *device, u8 port_num,
> > +   unsigned int index, void **context)
> > +{
> > +   return 0;
> > +}
> 
> This patch makes no sense to me. It is the same as not write this
> functions at all.
I think you are correct. Will remove this patch.  

Thanks
Salil
> 
> > +
> >  static int handle_en_event(struct hns_roce_dev *hr_dev, u8 port,
> >unsigned long event)
> >  {
> > @@ -639,6 +652,8 @@ static int hns_roce_register_device(struct
> hns_roce_dev *hr_dev)
> > ib_dev->get_link_layer  = hns_roce_get_link_layer;
> > ib_dev->get_netdev  = hns_roce_get_netdev;
> > ib_dev->query_gid   = hns_roce_query_gid;
> > +   ib_dev->add_gid = hns_roce_add_gid;
> > +   ib_dev->del_gid = hns_roce_del_gid;
> > ib_dev->query_pkey  = hns_roce_query_pkey;
> > ib_dev->alloc_ucontext  = hns_roce_alloc_ucontext;
> > ib_dev->dealloc_ucontext= hns_roce_dealloc_ucontext;
> > --
> > 1.7.9.5
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-rdma"
> in
> > the body of a message to majord...@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 6/6] mfd: twl-core: Make it explicitly non-modular

[Tony Lindgren]

* Paul Gortmaker  [160912 07:41]:
> The Kconfig currently controlling compilation of this code is:
> 
> drivers/mfd/Kconfig:config TWL4030_CORE
> drivers/mfd/Kconfig:bool "TI TWL4030/TWL5030/TWL6030/TPS659x0 Support"
> 
> ...meaning that it currently is not being built as a module by anyone.
> 
> Lets remove what modular code that we can, so that when reading the
> driver there is less doubt that it is builtin-only.  Note that we can't
> remove the twl_remove() itself ; it is still used by the probe unwind
> routine.  So we leave it linked into the .remove as well, even though
> it will most likely never be called via that path from an unbind.
> 
> Since module_i2c_driver() uses the same init level priority as
> builtin_i2c_driver() the init ordering remains unchanged with
> this commit.
> 
> Also note that MODULE_DEVICE_TABLE is a no-op for non-modular code.
> 
> We also delete the MODULE_LICENSE tag etc. since all that information
> is already contained at the top of the file in the comments.
> 
> Cc: Tony Lindgren 
> Cc: Samuel Ortiz 
> Cc: Lee Jones 
> Cc: linux-o...@vger.kernel.org
> Signed-off-by: Paul Gortmaker 

Yeah makes sense to me:

Acked-by: Tony Lindgren 

Re: [PATCH 6/6] mfd: twl-core: Make it explicitly non-modular

[Tony Lindgren]

* Paul Gortmaker  [160912 07:41]:
> The Kconfig currently controlling compilation of this code is:
> 
> drivers/mfd/Kconfig:config TWL4030_CORE
> drivers/mfd/Kconfig:bool "TI TWL4030/TWL5030/TWL6030/TPS659x0 Support"
> 
> ...meaning that it currently is not being built as a module by anyone.
> 
> Lets remove what modular code that we can, so that when reading the
> driver there is less doubt that it is builtin-only.  Note that we can't
> remove the twl_remove() itself ; it is still used by the probe unwind
> routine.  So we leave it linked into the .remove as well, even though
> it will most likely never be called via that path from an unbind.
> 
> Since module_i2c_driver() uses the same init level priority as
> builtin_i2c_driver() the init ordering remains unchanged with
> this commit.
> 
> Also note that MODULE_DEVICE_TABLE is a no-op for non-modular code.
> 
> We also delete the MODULE_LICENSE tag etc. since all that information
> is already contained at the top of the file in the comments.
> 
> Cc: Tony Lindgren 
> Cc: Samuel Ortiz 
> Cc: Lee Jones 
> Cc: linux-o...@vger.kernel.org
> Signed-off-by: Paul Gortmaker 

Yeah makes sense to me:

Acked-by: Tony Lindgren 

[PATCH 0/1] staging: slicoss: slicoss: fix sparse warnings

[Peng Sun]

linux-next next-20160909, commit-id d221eb9f

Peng Sun (1):
  staging: slicoss: slicoss.c: fix different address space sparse
warnings

 drivers/staging/slicoss/slicoss.c | 125 +++---
 1 file changed, 91 insertions(+), 34 deletions(-)

-- 
2.7.4

[PATCH 1/1] staging: slicoss: slicoss.c: fix different address space sparse warnings

[Peng Sun]

Signed-off-by: Peng Sun 
---
 drivers/staging/slicoss/slicoss.c | 125 +++---
 1 file changed, 91 insertions(+), 34 deletions(-)

diff --git a/drivers/staging/slicoss/slicoss.c 
b/drivers/staging/slicoss/slicoss.c
index 21280a3..6996143 100644
--- a/drivers/staging/slicoss/slicoss.c
+++ b/drivers/staging/slicoss/slicoss.c
@@ -924,8 +924,9 @@ err_unlock_irq:
 static void slic_link_upr_complete(struct adapter *adapter, u32 isr)
 {
struct slic_shmemory *sm = >shmem;
-   struct slic_shmem_data *sm_data = sm->shmem_data;
-   u32 lst = sm_data->lnkstatus;
+   struct slic_shmem_data __iomem *sm_data = sm->shmem_data;
+   u32 lst = ioread32((char __iomem *)sm_data +
+  offsetof(struct slic_shmem_data, lnkstatus));
uint linkup;
unsigned char linkspeed;
unsigned char linkduplex;
@@ -1004,8 +1005,10 @@ static void slic_upr_request_complete(struct adapter 
*adapter, u32 isr)
switch (upr->upr_request) {
case SLIC_UPR_STATS: {
struct slic_shmemory *sm = >shmem;
-   struct slic_shmem_data *sm_data = sm->shmem_data;
-   struct slic_stats *stats = _data->stats;
+   struct slic_shmem_data __iomem *sm_data = sm->shmem_data;
+   struct slic_stats __iomem *stats = (struct slic_stats __iomem *)
+   ((char __iomem *)sm_data +
+offsetof(struct slic_shmem_data, stats));
struct slic_stats *old = >inicstats_prev;
struct slicnet_stats *stst = >slic_stats;
 
@@ -1015,49 +1018,91 @@ static void slic_upr_request_complete(struct adapter 
*adapter, u32 isr)
break;
}
 
-   UPDATE_STATS_GB(stst->tcp.xmit_tcp_segs, stats->xmit_tcp_segs,
+   UPDATE_STATS_GB(stst->tcp.xmit_tcp_segs,
+   readq((char __iomem *)stats +
+ offsetof(struct slic_stats,
+  xmit_tcp_segs)),
old->xmit_tcp_segs);
 
-   UPDATE_STATS_GB(stst->tcp.xmit_tcp_bytes, stats->xmit_tcp_bytes,
+   UPDATE_STATS_GB(stst->tcp.xmit_tcp_bytes,
+   readq((char __iomem *)stats +
+ offsetof(struct slic_stats,
+  xmit_tcp_bytes)),
old->xmit_tcp_bytes);
 
-   UPDATE_STATS_GB(stst->tcp.rcv_tcp_segs, stats->rcv_tcp_segs,
+   UPDATE_STATS_GB(stst->tcp.rcv_tcp_segs,
+   readq((char __iomem *)stats +
+ offsetof(struct slic_stats,
+  rcv_tcp_segs)),
old->rcv_tcp_segs);
 
-   UPDATE_STATS_GB(stst->tcp.rcv_tcp_bytes, stats->rcv_tcp_bytes,
+   UPDATE_STATS_GB(stst->tcp.rcv_tcp_bytes,
+   readq((char __iomem *)stats +
+ offsetof(struct slic_stats,
+  rcv_tcp_bytes)),
old->rcv_tcp_bytes);
 
-   UPDATE_STATS_GB(stst->iface.xmt_bytes, stats->xmit_bytes,
+   UPDATE_STATS_GB(stst->iface.xmt_bytes,
+   readq((char __iomem *)stats +
+ offsetof(struct slic_stats,
+  xmit_bytes)),
old->xmit_bytes);
 
-   UPDATE_STATS_GB(stst->iface.xmt_ucast, stats->xmit_unicasts,
+   UPDATE_STATS_GB(stst->iface.xmt_ucast,
+   readq((char __iomem *)stats +
+ offsetof(struct slic_stats,
+  xmit_unicasts)),
old->xmit_unicasts);
 
-   UPDATE_STATS_GB(stst->iface.rcv_bytes, stats->rcv_bytes,
+   UPDATE_STATS_GB(stst->iface.rcv_bytes,
+   readq((char __iomem *)stats +
+ offsetof(struct slic_stats,
+  rcv_bytes)),
old->rcv_bytes);
 
-   UPDATE_STATS_GB(stst->iface.rcv_ucast, stats->rcv_unicasts,
+   UPDATE_STATS_GB(stst->iface.rcv_ucast,
+   readq((char __iomem *)stats +
+ offsetof(struct slic_stats,
+  rcv_unicasts)),
old->rcv_unicasts);
 
-   UPDATE_STATS_GB(stst->iface.xmt_errors, stats->xmit_collisions,
+   UPDATE_STATS_GB(stst->iface.xmt_errors,
+   readq((char __iomem 

[PATCH 0/1] staging: slicoss: slicoss: fix sparse warnings

[Peng Sun]

linux-next next-20160909, commit-id d221eb9f

Peng Sun (1):
  staging: slicoss: slicoss.c: fix different address space sparse
warnings

 drivers/staging/slicoss/slicoss.c | 125 +++---
 1 file changed, 91 insertions(+), 34 deletions(-)

-- 
2.7.4

[PATCH 1/1] staging: slicoss: slicoss.c: fix different address space sparse warnings

[Peng Sun]

Signed-off-by: Peng Sun 
---
 drivers/staging/slicoss/slicoss.c | 125 +++---
 1 file changed, 91 insertions(+), 34 deletions(-)

diff --git a/drivers/staging/slicoss/slicoss.c 
b/drivers/staging/slicoss/slicoss.c
index 21280a3..6996143 100644
--- a/drivers/staging/slicoss/slicoss.c
+++ b/drivers/staging/slicoss/slicoss.c
@@ -924,8 +924,9 @@ err_unlock_irq:
 static void slic_link_upr_complete(struct adapter *adapter, u32 isr)
 {
struct slic_shmemory *sm = >shmem;
-   struct slic_shmem_data *sm_data = sm->shmem_data;
-   u32 lst = sm_data->lnkstatus;
+   struct slic_shmem_data __iomem *sm_data = sm->shmem_data;
+   u32 lst = ioread32((char __iomem *)sm_data +
+  offsetof(struct slic_shmem_data, lnkstatus));
uint linkup;
unsigned char linkspeed;
unsigned char linkduplex;
@@ -1004,8 +1005,10 @@ static void slic_upr_request_complete(struct adapter 
*adapter, u32 isr)
switch (upr->upr_request) {
case SLIC_UPR_STATS: {
struct slic_shmemory *sm = >shmem;
-   struct slic_shmem_data *sm_data = sm->shmem_data;
-   struct slic_stats *stats = _data->stats;
+   struct slic_shmem_data __iomem *sm_data = sm->shmem_data;
+   struct slic_stats __iomem *stats = (struct slic_stats __iomem *)
+   ((char __iomem *)sm_data +
+offsetof(struct slic_shmem_data, stats));
struct slic_stats *old = >inicstats_prev;
struct slicnet_stats *stst = >slic_stats;
 
@@ -1015,49 +1018,91 @@ static void slic_upr_request_complete(struct adapter 
*adapter, u32 isr)
break;
}
 
-   UPDATE_STATS_GB(stst->tcp.xmit_tcp_segs, stats->xmit_tcp_segs,
+   UPDATE_STATS_GB(stst->tcp.xmit_tcp_segs,
+   readq((char __iomem *)stats +
+ offsetof(struct slic_stats,
+  xmit_tcp_segs)),
old->xmit_tcp_segs);
 
-   UPDATE_STATS_GB(stst->tcp.xmit_tcp_bytes, stats->xmit_tcp_bytes,
+   UPDATE_STATS_GB(stst->tcp.xmit_tcp_bytes,
+   readq((char __iomem *)stats +
+ offsetof(struct slic_stats,
+  xmit_tcp_bytes)),
old->xmit_tcp_bytes);
 
-   UPDATE_STATS_GB(stst->tcp.rcv_tcp_segs, stats->rcv_tcp_segs,
+   UPDATE_STATS_GB(stst->tcp.rcv_tcp_segs,
+   readq((char __iomem *)stats +
+ offsetof(struct slic_stats,
+  rcv_tcp_segs)),
old->rcv_tcp_segs);
 
-   UPDATE_STATS_GB(stst->tcp.rcv_tcp_bytes, stats->rcv_tcp_bytes,
+   UPDATE_STATS_GB(stst->tcp.rcv_tcp_bytes,
+   readq((char __iomem *)stats +
+ offsetof(struct slic_stats,
+  rcv_tcp_bytes)),
old->rcv_tcp_bytes);
 
-   UPDATE_STATS_GB(stst->iface.xmt_bytes, stats->xmit_bytes,
+   UPDATE_STATS_GB(stst->iface.xmt_bytes,
+   readq((char __iomem *)stats +
+ offsetof(struct slic_stats,
+  xmit_bytes)),
old->xmit_bytes);
 
-   UPDATE_STATS_GB(stst->iface.xmt_ucast, stats->xmit_unicasts,
+   UPDATE_STATS_GB(stst->iface.xmt_ucast,
+   readq((char __iomem *)stats +
+ offsetof(struct slic_stats,
+  xmit_unicasts)),
old->xmit_unicasts);
 
-   UPDATE_STATS_GB(stst->iface.rcv_bytes, stats->rcv_bytes,
+   UPDATE_STATS_GB(stst->iface.rcv_bytes,
+   readq((char __iomem *)stats +
+ offsetof(struct slic_stats,
+  rcv_bytes)),
old->rcv_bytes);
 
-   UPDATE_STATS_GB(stst->iface.rcv_ucast, stats->rcv_unicasts,
+   UPDATE_STATS_GB(stst->iface.rcv_ucast,
+   readq((char __iomem *)stats +
+ offsetof(struct slic_stats,
+  rcv_unicasts)),
old->rcv_unicasts);
 
-   UPDATE_STATS_GB(stst->iface.xmt_errors, stats->xmit_collisions,
+   UPDATE_STATS_GB(stst->iface.xmt_errors,
+   readq((char __iomem *)stats +
+ 

linux-next: build warning after merge of the gpio tree

[Stephen Rothwell]

Hi Linus,

After merging the gpio tree, today's linux-next build (x86_64
allmodconfig) produced this warning:

WARNING: modpost: missing MODULE_LICENSE() in drivers/gpio/gpio-aspeed.o

Introduced by commit

  361b79119a4b ("gpio: Add Aspeed driver")

-- 
Cheers,
Stephen Rothwell

linux-next: build warning after merge of the gpio tree

[Stephen Rothwell]

Hi Linus,

After merging the gpio tree, today's linux-next build (x86_64
allmodconfig) produced this warning:

WARNING: modpost: missing MODULE_LICENSE() in drivers/gpio/gpio-aspeed.o

Introduced by commit

  361b79119a4b ("gpio: Add Aspeed driver")

-- 
Cheers,
Stephen Rothwell

Re: Build failure in -next due to 'kbuild: allow archs to select link dead code/data elimination'

[Guenter Roeck]

Hi Nicholas,

On 09/12/2016 07:00 PM, Nicholas Piggin wrote:

On Mon, 12 Sep 2016 15:24:43 -0700
Guenter Roeck  wrote:


Hi,

your commit 'kbuild: allow archs to select link dead code/data elimination'
is causing the following build failure in -next when building score:defconfig.

arch/score/kernel/built-in.o: In function `work_resched':
arch/score/kernel/entry.o:(.text+0xe84):
relocation truncated to fit: R_SCORE_PC19 against `schedule'

Reverting the commit fixes the problem.

Please let me know if I can help tracking down the problem.
In case you need a score toochain, you can find the one I use at
http://server.roeck-us.net/toolchains/score.tgz.

Thanks,
Guenter


It's not supposed to have any real effect unless the
option is selected, but there are a few changes to linker
script which must be causing it.

There are two changes to vmlinux.lds.h. One is to KEEP a
few input sections, that *should* be kept anyway. The other
is to bring in additional sections into their correct output
section.

Could you try reverting those lines of vmlinux.lds.h that
change the latter, i.e.:

-   *(.text.hot .text .text.fixup .text.unlikely)   \
+   *(.text.hot .text .text.fixup .text.unlikely .text.*)   \


This is the culprit. After removing " .text.*" it builds fine.

Guenter

Re: Build failure in -next due to 'kbuild: allow archs to select link dead code/data elimination'

[Guenter Roeck]

Hi Nicholas,

On 09/12/2016 07:00 PM, Nicholas Piggin wrote:

On Mon, 12 Sep 2016 15:24:43 -0700
Guenter Roeck  wrote:


Hi,

your commit 'kbuild: allow archs to select link dead code/data elimination'
is causing the following build failure in -next when building score:defconfig.

arch/score/kernel/built-in.o: In function `work_resched':
arch/score/kernel/entry.o:(.text+0xe84):
relocation truncated to fit: R_SCORE_PC19 against `schedule'

Reverting the commit fixes the problem.

Please let me know if I can help tracking down the problem.
In case you need a score toochain, you can find the one I use at
http://server.roeck-us.net/toolchains/score.tgz.

Thanks,
Guenter


It's not supposed to have any real effect unless the
option is selected, but there are a few changes to linker
script which must be causing it.

There are two changes to vmlinux.lds.h. One is to KEEP a
few input sections, that *should* be kept anyway. The other
is to bring in additional sections into their correct output
section.

Could you try reverting those lines of vmlinux.lds.h that
change the latter, i.e.:

-   *(.text.hot .text .text.fixup .text.unlikely)   \
+   *(.text.hot .text .text.fixup .text.unlikely .text.*)   \


This is the culprit. After removing " .text.*" it builds fine.

Guenter

linux-next: manual merge of the gpio tree with the pinctrl tree

[Stephen Rothwell]

Hi Linus,

Today's linux-next merge of the gpio tree got a conflict in:

  drivers/gpio/gpio-mxc.c

between commit:

  e188cbf7564f ("gpio: mxc: shift gpio_mxc_init() to subsys_initcall level")

from the pinctrl tree and commit:

  2c8d6c869feb ("gpio: mxc: drop unused MODULE_ tags from non-modular code")

from the gpio tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc drivers/gpio/gpio-mxc.c
index e38989a4fa0c,e35af5249478..
--- a/drivers/gpio/gpio-mxc.c
+++ b/drivers/gpio/gpio-mxc.c
@@@ -515,10 -510,4 +515,4 @@@ static int __init gpio_mxc_init(void
  {
return platform_driver_register(_gpio_driver);
  }
 -postcore_initcall(gpio_mxc_init);
 +subsys_initcall(gpio_mxc_init);
- 
- MODULE_AUTHOR("Freescale Semiconductor, "
- "Daniel Mack , "
- "Juergen Beisert ");
- MODULE_DESCRIPTION("Freescale MXC GPIO");
- MODULE_LICENSE("GPL");

linux-next: manual merge of the gpio tree with the pinctrl tree

[Stephen Rothwell]

Hi Linus,

Today's linux-next merge of the gpio tree got a conflict in:

  drivers/gpio/gpio-mxc.c

between commit:

  e188cbf7564f ("gpio: mxc: shift gpio_mxc_init() to subsys_initcall level")

from the pinctrl tree and commit:

  2c8d6c869feb ("gpio: mxc: drop unused MODULE_ tags from non-modular code")

from the gpio tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc drivers/gpio/gpio-mxc.c
index e38989a4fa0c,e35af5249478..
--- a/drivers/gpio/gpio-mxc.c
+++ b/drivers/gpio/gpio-mxc.c
@@@ -515,10 -510,4 +515,4 @@@ static int __init gpio_mxc_init(void
  {
return platform_driver_register(_gpio_driver);
  }
 -postcore_initcall(gpio_mxc_init);
 +subsys_initcall(gpio_mxc_init);
- 
- MODULE_AUTHOR("Freescale Semiconductor, "
- "Daniel Mack , "
- "Juergen Beisert ");
- MODULE_DESCRIPTION("Freescale MXC GPIO");
- MODULE_LICENSE("GPL");

Re: [PATCH 4.7 00/59] 4.7.4-stable review

[Guenter Roeck]

On 09/12/2016 08:29 AM, Greg Kroah-Hartman wrote:

This is the start of the stable review cycle for the 4.7.4 release.
There are 59 patches in this series, all will be posted as a response
to this one.  If anyone has any issues with these being applied, please
let me know.

Responses should be made by Wed Sep 14 15:21:16 UTC 2016.
Anything received after that time might be too late.



Build results:
total: 149 pass: 149 fail: 0
Qemu test results:
total: 108 pass: 108 fail: 0

Details are available at http://kerneltests.org/builders.

Guenter

Re: [PATCH 4.7 00/59] 4.7.4-stable review

[Guenter Roeck]

On 09/12/2016 08:29 AM, Greg Kroah-Hartman wrote:

This is the start of the stable review cycle for the 4.7.4 release.
There are 59 patches in this series, all will be posted as a response
to this one.  If anyone has any issues with these being applied, please
let me know.

Responses should be made by Wed Sep 14 15:21:16 UTC 2016.
Anything received after that time might be too late.



Build results:
total: 149 pass: 149 fail: 0
Qemu test results:
total: 108 pass: 108 fail: 0

Details are available at http://kerneltests.org/builders.

Guenter

Re: [PATCH v2] mm, proc: Fix region lost in /proc/self/smaps

[Xiao Guangrong]

On 09/13/2016 03:10 AM, Michal Hocko wrote:

On Mon 12-09-16 08:01:06, Dave Hansen wrote:

On 09/12/2016 05:54 AM, Michal Hocko wrote:

In order to fix this bug, we make 'file->version' indicate the end address
of current VMA

Doesn't this open doors to another weird cases. Say B would be partially
unmapped (tail of the VMA would get unmapped and reused for a new VMA.


In the end, this interface isn't about VMAs.  It's about addresses, and
we need to make sure that the _addresses_ coming out of it are sane.  In
the case that a VMA was partially unmapped, it doesn't make sense to
show the "new" VMA because we already had some output covering the
address of the "new" VMA from the old one.


OK, that is a fair point and it speaks for caching the vm_end rather
than vm_start+skip.


I am not sure we provide any guarantee when there are more read
syscalls. Hmm, even with a single read() we can get inconsistent results
from different threads without any user space synchronization.


Yeah, very true.  But, I think we _can_ at least provide the following
guarantees (among others):
1. addresses don't go backwards
2. If there is something at a given vaddr during the entirety of the
   life of the smaps walk, we will produce some output for it.


I guess we also want
  3. no overlaps with previously printed values (assuming two subsequent
 reads without seek).

the patch tries to achieve the last part as well AFAICS but I guess this
is incomplete because at least /proc//smaps will report counters
for the full vma range while the header (aka show_map_vma) will report
shorter (non-overlapping) range. I haven't checked other files which use
m_{start,next}


You are right. Will fix both /proc/PID/smaps and /proc/PID/maps in
the next version.



Considering how this all can be tricky and how partial reads can be
confusing and even misleading I am really wondering whether we
should simply document that only full reads will provide a sensible
results.


Make sense. Will document the guarantee in
Documentation/filesystems/proc.txt

Thank you, Dave and Michal, for figuring out the right direction. :)

Re: [PATCH v2] mm, proc: Fix region lost in /proc/self/smaps

[Xiao Guangrong]

On 09/13/2016 03:10 AM, Michal Hocko wrote:

On Mon 12-09-16 08:01:06, Dave Hansen wrote:

On 09/12/2016 05:54 AM, Michal Hocko wrote:

In order to fix this bug, we make 'file->version' indicate the end address
of current VMA

Doesn't this open doors to another weird cases. Say B would be partially
unmapped (tail of the VMA would get unmapped and reused for a new VMA.


In the end, this interface isn't about VMAs.  It's about addresses, and
we need to make sure that the _addresses_ coming out of it are sane.  In
the case that a VMA was partially unmapped, it doesn't make sense to
show the "new" VMA because we already had some output covering the
address of the "new" VMA from the old one.


OK, that is a fair point and it speaks for caching the vm_end rather
than vm_start+skip.


I am not sure we provide any guarantee when there are more read
syscalls. Hmm, even with a single read() we can get inconsistent results
from different threads without any user space synchronization.


Yeah, very true.  But, I think we _can_ at least provide the following
guarantees (among others):
1. addresses don't go backwards
2. If there is something at a given vaddr during the entirety of the
   life of the smaps walk, we will produce some output for it.


I guess we also want
  3. no overlaps with previously printed values (assuming two subsequent
 reads without seek).

the patch tries to achieve the last part as well AFAICS but I guess this
is incomplete because at least /proc//smaps will report counters
for the full vma range while the header (aka show_map_vma) will report
shorter (non-overlapping) range. I haven't checked other files which use
m_{start,next}


You are right. Will fix both /proc/PID/smaps and /proc/PID/maps in
the next version.



Considering how this all can be tricky and how partial reads can be
confusing and even misleading I am really wondering whether we
should simply document that only full reads will provide a sensible
results.


Make sense. Will document the guarantee in
Documentation/filesystems/proc.txt

Thank you, Dave and Michal, for figuring out the right direction. :)

Re: [PATCH 4.4 000/192] 4.4.21-stable review

[Guenter Roeck]

On 09/12/2016 09:58 AM, Greg Kroah-Hartman wrote:

Many thanks for the majority of these patches to Sasha Levin, who dug
them out of Canonical's 4.4 kernel tree.  I have no idea why they never
sent them in for inclusion on their own :(

This is the start of the stable review cycle for the 4.4.21 release.
There are 192 patches in this series, all will be posted as a response
to this one.  If anyone has any issues with these being applied, please
let me know.

Responses should be made by Wed Sep 14 15:21:31 UTC 2016.
Anything received after that time might be too late.



Build results:
total: 149 pass: 149 fail: 0
Qemu test results:
total: 101 pass: 101 fail: 0

Details are available at http://kerneltests.org/builders.

Guenter

Re: [PATCH 4.4 000/192] 4.4.21-stable review

[Guenter Roeck]

On 09/12/2016 09:58 AM, Greg Kroah-Hartman wrote:

Many thanks for the majority of these patches to Sasha Levin, who dug
them out of Canonical's 4.4 kernel tree.  I have no idea why they never
sent them in for inclusion on their own :(

This is the start of the stable review cycle for the 4.4.21 release.
There are 192 patches in this series, all will be posted as a response
to this one.  If anyone has any issues with these being applied, please
let me know.

Responses should be made by Wed Sep 14 15:21:31 UTC 2016.
Anything received after that time might be too late.



Build results:
total: 149 pass: 149 fail: 0
Qemu test results:
total: 101 pass: 101 fail: 0

Details are available at http://kerneltests.org/builders.

Guenter

Re: [PATCH v2 05/20] docs-rst: CodingStyle.rst: Convert to ReST markup

[Joe Perches]

On Mon, 2016-09-12 at 23:17 -0300, Mauro Carvalho Chehab wrote:
> - Fix all chapter identation;
> - add c blocks where needed;

Assuming this is really useful and people agree with simple
conversions of .txt to .rst (and it does have some use),
there are a couple funky conversions

if (condition)
do_this();
else
do_that();

do_that() is oddly displayed in the code_block

and in the "Spaces" section, the pointer description is wrong

"\* is adjacent"

other than that, looks good to me.
> 

Re: [PATCH v2 05/20] docs-rst: CodingStyle.rst: Convert to ReST markup

[Joe Perches]

On Mon, 2016-09-12 at 23:17 -0300, Mauro Carvalho Chehab wrote:
> - Fix all chapter identation;
> - add c blocks where needed;

Assuming this is really useful and people agree with simple
conversions of .txt to .rst (and it does have some use),
there are a couple funky conversions

if (condition)
do_this();
else
do_that();

do_that() is oddly displayed in the code_block

and in the "Spaces" section, the pointer description is wrong

"\* is adjacent"

other than that, looks good to me.
> 

Re: Panic when insmod nfit_test.ko

[Dan Williams]

On Mon, Sep 12, 2016 at 7:30 PM, ryan chen  wrote:
> Hi all,
> Recently I'm trying to check the testing suite of nfit_test for nvdimm
> on 4.8-rc5, and system got panic once insmod nfit_test.ko ,
> I've checked the RIP, I guess it panics due to NULL
> nvdimm_map pointer, i.e., accessing nvdimm_map->mem,
> so I have a question that, should we check the return value of
> alloc_nvdimm_map if it failed:
>
> --- a/drivers/nvdimm/core.c
> +++ b/drivers/nvdimm/core.c
> @@ -171,6 +171,9 @@ void *devm_nvdimm_memremap(struct device *dev,
> resource_size_t offset,
> kref_get(_map->kref);
> nvdimm_bus_unlock(dev);
>
> +   if (!nvdimm_map)
> +   return NULL;
> +
> if (devm_add_action_or_reset(dev, nvdimm_map_put, nvdimm_map))
> return NULL;
> But why we got NULL nvdimm_map is still unknown,
> please let me know if you need any information. Thanks.

Thanks for the report.  We do need to check if alloc_nvdimm_map fails.
My guess as to why it is failing the call to request_mem_region().
Can you try the attached patch, and send the kernel log as well as the
contents of /proc/iomem?
libnvdimm: fix devm_nvdimm_memremap() error path

From: Dan Williams 

The internal alloc_nvdimm_map() helper might file, particularly if the
memory region is already busy.  Report request_mem_region() failures and
check for the failure.

Reported-by: Ryan Chen 
Signed-off-by: Dan Williams 
---
 drivers/nvdimm/core.c |8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/drivers/nvdimm/core.c b/drivers/nvdimm/core.c
index 715583f69d28..14066add20f0 100644
--- a/drivers/nvdimm/core.c
+++ b/drivers/nvdimm/core.c
@@ -99,8 +99,11 @@ static struct nvdimm_map *alloc_nvdimm_map(struct device *dev,
 	nvdimm_map->size = size;
 	kref_init(_map->kref);
 
-	if (!request_mem_region(offset, size, dev_name(_bus->dev)))
+	if (!request_mem_region(offset, size, dev_name(_bus->dev))) {
+		dev_err(_bus->dev, "failed to request %pa + %ld for %s\n",
+, size, dev_name(dev));
 		goto err_request_region;
+	}
 
 	if (flags)
 		nvdimm_map->mem = memremap(offset, size, flags);
@@ -171,6 +174,9 @@ void *devm_nvdimm_memremap(struct device *dev, resource_size_t offset,
 		kref_get(_map->kref);
 	nvdimm_bus_unlock(dev);
 
+	if (!nvdimm_map)
+		return NULL;
+
 	if (devm_add_action_or_reset(dev, nvdimm_map_put, nvdimm_map))
 		return NULL;
 

Re: Panic when insmod nfit_test.ko

[Dan Williams]

On Mon, Sep 12, 2016 at 7:30 PM, ryan chen  wrote:
> Hi all,
> Recently I'm trying to check the testing suite of nfit_test for nvdimm
> on 4.8-rc5, and system got panic once insmod nfit_test.ko ,
> I've checked the RIP, I guess it panics due to NULL
> nvdimm_map pointer, i.e., accessing nvdimm_map->mem,
> so I have a question that, should we check the return value of
> alloc_nvdimm_map if it failed:
>
> --- a/drivers/nvdimm/core.c
> +++ b/drivers/nvdimm/core.c
> @@ -171,6 +171,9 @@ void *devm_nvdimm_memremap(struct device *dev,
> resource_size_t offset,
> kref_get(_map->kref);
> nvdimm_bus_unlock(dev);
>
> +   if (!nvdimm_map)
> +   return NULL;
> +
> if (devm_add_action_or_reset(dev, nvdimm_map_put, nvdimm_map))
> return NULL;
> But why we got NULL nvdimm_map is still unknown,
> please let me know if you need any information. Thanks.

Thanks for the report.  We do need to check if alloc_nvdimm_map fails.
My guess as to why it is failing the call to request_mem_region().
Can you try the attached patch, and send the kernel log as well as the
contents of /proc/iomem?
libnvdimm: fix devm_nvdimm_memremap() error path

From: Dan Williams 

The internal alloc_nvdimm_map() helper might file, particularly if the
memory region is already busy.  Report request_mem_region() failures and
check for the failure.

Reported-by: Ryan Chen 
Signed-off-by: Dan Williams 
---
 drivers/nvdimm/core.c |8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/drivers/nvdimm/core.c b/drivers/nvdimm/core.c
index 715583f69d28..14066add20f0 100644
--- a/drivers/nvdimm/core.c
+++ b/drivers/nvdimm/core.c
@@ -99,8 +99,11 @@ static struct nvdimm_map *alloc_nvdimm_map(struct device *dev,
 	nvdimm_map->size = size;
 	kref_init(_map->kref);
 
-	if (!request_mem_region(offset, size, dev_name(_bus->dev)))
+	if (!request_mem_region(offset, size, dev_name(_bus->dev))) {
+		dev_err(_bus->dev, "failed to request %pa + %ld for %s\n",
+, size, dev_name(dev));
 		goto err_request_region;
+	}
 
 	if (flags)
 		nvdimm_map->mem = memremap(offset, size, flags);
@@ -171,6 +174,9 @@ void *devm_nvdimm_memremap(struct device *dev, resource_size_t offset,
 		kref_get(_map->kref);
 	nvdimm_bus_unlock(dev);
 
+	if (!nvdimm_map)
+		return NULL;
+
 	if (devm_add_action_or_reset(dev, nvdimm_map_put, nvdimm_map))
 		return NULL;
 

Re: [PATCH] clk: hisilicon: add CRG driver for Hi3798CV200 SoC

[Jiancheng Xue]

Hi all,

Sorry. I'll fixed this compiling error in the next version.

Regards,
Jiancheng

On 2016/9/12 21:55, kbuild test robot wrote:
> Hi Jiancheng,
> 
> [auto build test ERROR on clk/clk-next]
> [also build test ERROR on v4.8-rc6 next-20160912]
> [if your patch is applied to the wrong git tree, please drop us a note to 
> help improve the system]
> [Suggest to use git(>=2.9.0) format-patch --base= (or --base=auto for 
> convenience) to record what (public, well-known) commit your patch series was 
> built on]
> [Check https://git-scm.com/docs/git-format-patch for more information]
> 
> url:
> https://github.com/0day-ci/linux/commits/Jiancheng-Xue/clk-hisilicon-add-CRG-driver-for-Hi3798CV200-SoC/20160912-175733
> base:   https://git.kernel.org/pub/scm/linux/kernel/git/clk/linux.git clk-next
> config: arm-allmodconfig (attached as .config)
> compiler: arm-linux-gnueabi-gcc (Debian 5.4.0-6) 5.4.0 20160609
> reproduce:
> wget 
> https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
>  -O ~/bin/make.cross
> chmod +x ~/bin/make.cross
> # save the attached .config to linux build tree
> make.cross ARCH=arm 
> 
> All error/warnings (new ones prefixed by >>):
> 
>In file included from drivers/clk/hisilicon/crg-hi3798cv200.c:22:0:
>>> drivers/clk/hisilicon/crg-hi3798cv200.c:245:25: error: 
>>> 'hi3798cv200_clk_match_table' undeclared here (not in a function)
> MODULE_DEVICE_TABLE(of, hi3798cv200_clk_match_table);
> ^
>include/linux/module.h:213:21: note: in definition of macro 
> 'MODULE_DEVICE_TABLE'
> extern const typeof(name) __mod_##type##__##name##_device_table  \
> ^
>>> include/linux/module.h:213:27: error: 
>>> '__mod_of__hi3798cv200_clk_match_table_device_table' aliased to undefined 
>>> symbol 'hi3798cv200_clk_match_table'
> extern const typeof(name) __mod_##type##__##name##_device_table  \
>   ^
>>> drivers/clk/hisilicon/crg-hi3798cv200.c:245:1: note: in expansion of macro 
>>> 'MODULE_DEVICE_TABLE'
> MODULE_DEVICE_TABLE(of, hi3798cv200_clk_match_table);
> ^
> 
> vim +/hi3798cv200_clk_match_table +245 drivers/clk/hisilicon/crg-hi3798cv200.c
> 
>239{ .compatible = "hisilicon,hi3798cv200-crg",
>240.data = _crg_funcs},
>241{ .compatible = "hisilicon,hi3798cv200-sysctrl",
>242.data = _sysctrl_funcs},
>243{ }
>244};
>  > 245MODULE_DEVICE_TABLE(of, hi3798cv200_clk_match_table);
>246
>247static int hi3798cv200_crg_probe(struct platform_device *pdev)
>248{
> 
> ---
> 0-DAY kernel test infrastructureOpen Source Technology Center
> https://lists.01.org/pipermail/kbuild-all   Intel Corporation
> 

Re: [PATCH] clk: hisilicon: add CRG driver for Hi3798CV200 SoC

[Jiancheng Xue]

Hi all,

Sorry. I'll fixed this compiling error in the next version.

Regards,
Jiancheng

On 2016/9/12 21:55, kbuild test robot wrote:
> Hi Jiancheng,
> 
> [auto build test ERROR on clk/clk-next]
> [also build test ERROR on v4.8-rc6 next-20160912]
> [if your patch is applied to the wrong git tree, please drop us a note to 
> help improve the system]
> [Suggest to use git(>=2.9.0) format-patch --base= (or --base=auto for 
> convenience) to record what (public, well-known) commit your patch series was 
> built on]
> [Check https://git-scm.com/docs/git-format-patch for more information]
> 
> url:
> https://github.com/0day-ci/linux/commits/Jiancheng-Xue/clk-hisilicon-add-CRG-driver-for-Hi3798CV200-SoC/20160912-175733
> base:   https://git.kernel.org/pub/scm/linux/kernel/git/clk/linux.git clk-next
> config: arm-allmodconfig (attached as .config)
> compiler: arm-linux-gnueabi-gcc (Debian 5.4.0-6) 5.4.0 20160609
> reproduce:
> wget 
> https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
>  -O ~/bin/make.cross
> chmod +x ~/bin/make.cross
> # save the attached .config to linux build tree
> make.cross ARCH=arm 
> 
> All error/warnings (new ones prefixed by >>):
> 
>In file included from drivers/clk/hisilicon/crg-hi3798cv200.c:22:0:
>>> drivers/clk/hisilicon/crg-hi3798cv200.c:245:25: error: 
>>> 'hi3798cv200_clk_match_table' undeclared here (not in a function)
> MODULE_DEVICE_TABLE(of, hi3798cv200_clk_match_table);
> ^
>include/linux/module.h:213:21: note: in definition of macro 
> 'MODULE_DEVICE_TABLE'
> extern const typeof(name) __mod_##type##__##name##_device_table  \
> ^
>>> include/linux/module.h:213:27: error: 
>>> '__mod_of__hi3798cv200_clk_match_table_device_table' aliased to undefined 
>>> symbol 'hi3798cv200_clk_match_table'
> extern const typeof(name) __mod_##type##__##name##_device_table  \
>   ^
>>> drivers/clk/hisilicon/crg-hi3798cv200.c:245:1: note: in expansion of macro 
>>> 'MODULE_DEVICE_TABLE'
> MODULE_DEVICE_TABLE(of, hi3798cv200_clk_match_table);
> ^
> 
> vim +/hi3798cv200_clk_match_table +245 drivers/clk/hisilicon/crg-hi3798cv200.c
> 
>239{ .compatible = "hisilicon,hi3798cv200-crg",
>240.data = _crg_funcs},
>241{ .compatible = "hisilicon,hi3798cv200-sysctrl",
>242.data = _sysctrl_funcs},
>243{ }
>244};
>  > 245MODULE_DEVICE_TABLE(of, hi3798cv200_clk_match_table);
>246
>247static int hi3798cv200_crg_probe(struct platform_device *pdev)
>248{
> 
> ---
> 0-DAY kernel test infrastructureOpen Source Technology Center
> https://lists.01.org/pipermail/kbuild-all   Intel Corporation
> 

Re: [PATCH v3] stop_machine: Make migration_cpu_stop() does useful works for CONFIG_PREEMPT_NONE

[Cheng Chao]

on 09/12/2016 07:03 PM, Oleg Nesterov wrote:
> On 09/10, Cheng Chao wrote:
>>
>> @@ -126,6 +126,17 @@ int stop_one_cpu(unsigned int cpu, cpu_stop_fn_t fn, 
>> void *arg)
>>  cpu_stop_init_done(, 1);
>>  if (!cpu_stop_queue_work(cpu, ))
>>  return -ENOENT;
>> +
>> +#if defined(CONFIG_PREEMPT_NONE)
>> +/*
>> + * Makes the stopper thread run as soon as possible.
>> + * And if the caller is TASK_RUNNING, keeps the caller TASK_RUNNING.
>> + * It's special useful for some callers which are expected to be
>> + * TASK_ON_RQ_QUEUED.
>> + * sched_exec does benefit from this improvement.
>> + */
>> +schedule();
>> +#endif
>>  wait_for_completion();
>>  return done.ret;
>>  }
> 
> Cheng, I already tried twice to suggest to conditionalize this schedule,
> because it can only help if cpu == smp_processor_id, and you didn't reply.
> I still think _cond_resched() makes more sense.
> 
> I won't really argue if you prefer it this way. But did you see my emails?
>

I read them, thanks. because Peter didn't receive my mails before, it took me 
much time
to fix my mailbox, so I didn't reply on time.

Ok, even if cpu != smp_processor_id(), to call schedule() instead 
_cond_resched() can
give the caller a chance not to sleep. when the caller runs on the cpu again, 
it may 
likely find the completion is already done. 
then the stopper thread cpu_stop_signal_done() and the caller 
wait_for_completion() will
actually run very soon.

I think it is trivial improvement. using cond_resched()/_cond_resched() is 
better for 
readability, I choose the cond_resched().

thanks again.



 
> Oleg.
> 

Re: [PATCH v3] stop_machine: Make migration_cpu_stop() does useful works for CONFIG_PREEMPT_NONE

[Cheng Chao]

on 09/12/2016 07:03 PM, Oleg Nesterov wrote:
> On 09/10, Cheng Chao wrote:
>>
>> @@ -126,6 +126,17 @@ int stop_one_cpu(unsigned int cpu, cpu_stop_fn_t fn, 
>> void *arg)
>>  cpu_stop_init_done(, 1);
>>  if (!cpu_stop_queue_work(cpu, ))
>>  return -ENOENT;
>> +
>> +#if defined(CONFIG_PREEMPT_NONE)
>> +/*
>> + * Makes the stopper thread run as soon as possible.
>> + * And if the caller is TASK_RUNNING, keeps the caller TASK_RUNNING.
>> + * It's special useful for some callers which are expected to be
>> + * TASK_ON_RQ_QUEUED.
>> + * sched_exec does benefit from this improvement.
>> + */
>> +schedule();
>> +#endif
>>  wait_for_completion();
>>  return done.ret;
>>  }
> 
> Cheng, I already tried twice to suggest to conditionalize this schedule,
> because it can only help if cpu == smp_processor_id, and you didn't reply.
> I still think _cond_resched() makes more sense.
> 
> I won't really argue if you prefer it this way. But did you see my emails?
>

I read them, thanks. because Peter didn't receive my mails before, it took me 
much time
to fix my mailbox, so I didn't reply on time.

Ok, even if cpu != smp_processor_id(), to call schedule() instead 
_cond_resched() can
give the caller a chance not to sleep. when the caller runs on the cpu again, 
it may 
likely find the completion is already done. 
then the stopper thread cpu_stop_signal_done() and the caller 
wait_for_completion() will
actually run very soon.

I think it is trivial improvement. using cond_resched()/_cond_resched() is 
better for 
readability, I choose the cond_resched().

thanks again.



 
> Oleg.
> 

Re: [PATCH V6 2/5] PCI/ACPI: Check platform specific ECAM quirks

[Dongdong Liu]

Hi Tomasz

在 2016/9/10 3:24, Tomasz Nowicki 写道:

Some platforms may not be fully compliant with generic set of PCI config
accessors. For these cases we implement the way to overwrite CFG accessors
set and configuration space range.

In first place pci_mcfg_parse() saves machine's IDs and revision number
(these come from MCFG header) in order to match against known quirk entries.
Then the algorithm traverses available quirk list (static array),
matches against  and
returns custom PCI config ops and/or CFG resource structure.

When adding new quirk there are two possibilities:
1. Override default pci_generic_ecam_ops ops but CFG resource comes from MCFG
{ "OEM_ID", "OEM_TABLE_ID", , , , _ops, MCFG_RES_EMPTY 
},
2. Override default pci_generic_ecam_ops ops and CFG resource. For this case
it is also allowed get CFG resource from quirk entry w/o having it in MCFG.
{ "OEM_ID", "OEM_TABLE_ID", , , , _ops,
   DEFINE_RES_MEM(START, SIZE) },

pci_generic_ecam_ops and MCFG entries will be used for platforms
free from quirks.

Signed-off-by: Tomasz Nowicki 
Signed-off-by: Dongdong Liu 
Signed-off-by: Christopher Covington 
---
  drivers/acpi/pci_mcfg.c | 80 +
  1 file changed, 74 insertions(+), 6 deletions(-)

diff --git a/drivers/acpi/pci_mcfg.c b/drivers/acpi/pci_mcfg.c
index ffcc651..2b8acc7 100644
--- a/drivers/acpi/pci_mcfg.c
+++ b/drivers/acpi/pci_mcfg.c
@@ -32,6 +32,59 @@ struct mcfg_entry {
u8  bus_start;
u8  bus_end;
  };
+struct mcfg_fixup {
+   char oem_id[ACPI_OEM_ID_SIZE + 1];
+   char oem_table_id[ACPI_OEM_TABLE_ID_SIZE + 1];
+   u32 oem_revision;
+   u16 seg;
+   struct resource bus_range;
+   struct pci_ecam_ops *ops;
+   struct resource cfgres;
+};
+
+#define MCFG_DOM_ANY   (-1)
+#define MCFG_BUS_RANGE(start, end) DEFINE_RES_NAMED((start),   \
+   ((end) - (start) + 1),  \
+   NULL, IORESOURCE_BUS)
+#define MCFG_BUS_ANY   MCFG_BUS_RANGE(0x0, 0xff)
+#define MCFG_RES_EMPTY DEFINE_RES_NAMED(0, 0, NULL, 0)
+
+static struct mcfg_fixup mcfg_quirks[] = {
+/* { OEM_ID, OEM_TABLE_ID, REV, DOMAIN, BUS_RANGE, cfgres, ops }, */
+};
+
+static char mcfg_oem_id[ACPI_OEM_ID_SIZE];
+static char mcfg_oem_table_id[ACPI_OEM_TABLE_ID_SIZE];
+static u32 mcfg_oem_revision;
+
+static void pci_mcfg_match_quirks(struct acpi_pci_root *root,
+ struct resource *cfgres,
+ struct pci_ecam_ops **ecam_ops)
+{
+   struct mcfg_fixup *f;
+   int i;
+
+   /*
+* First match against PCI topology  then use OEM ID, OEM
+* table ID, and OEM revision from MCFG table standard header.
+*/
+   for (i = 0, f = mcfg_quirks; i < ARRAY_SIZE(mcfg_quirks); i++, f++) {
+   if (f->seg == root->segment &&


why not use MCFG_DOM_RANGE, I think MCFG_DOM_RANGE is better.
if drop MCFG_DOM_RANGE, mcfg_quirks[] will be more complex.

static struct mcfg_fixup mcfg_quirks[] = {
/*  { OEM_ID, OEM_TABLE_ID, REV, DOMAIN, BUS_RANGE, cfgres, ops }, */
#ifdef CONFIG_PCI_HOST_THUNDER_ECAM
/* SoC pass1.x */
{ "CAVIUM", "THUNDERX", 2, 0, MCFG_BUS_ANY, _thunder_ecam_ops,
  MCFG_RES_EMPTY},
{ "CAVIUM", "THUNDERX", 2, 1, MCFG_BUS_ANY, _thunder_ecam_ops,
  MCFG_RES_EMPTY},
{ "CAVIUM", "THUNDERX", 2, 2, MCFG_BUS_ANY, _thunder_ecam_ops,
  MCFG_RES_EMPTY},
{ "CAVIUM", "THUNDERX", 2, 3, MCFG_BUS_ANY, _thunder_ecam_ops,
  MCFG_RES_EMPTY},
{ "CAVIUM", "THUNDERX", 2, 10, MCFG_BUS_ANY, _thunder_ecam_ops,
  MCFG_RES_EMPTY},
{ "CAVIUM", "THUNDERX", 2, 11, MCFG_BUS_ANY, _thunder_ecam_ops,
  MCFG_RES_EMPTY},
{ "CAVIUM", "THUNDERX", 2, 12, MCFG_BUS_ANY, _thunder_ecam_ops,
  MCFG_RES_EMPTY},
{ "CAVIUM", "THUNDERX", 2, 13, MCFG_BUS_ANY, _thunder_ecam_ops,
  MCFG_RES_EMPTY},
#endif
.
};

As PATCH v5 we only need define mcfg_quirks as below, It looks better.
static struct pci_cfg_fixup mcfg_quirks[] __initconst = {
/*  { OEM_ID, OEM_TABLE_ID, REV, DOMAIN, BUS_RANGE, pci_ops, init_hook }, */
#ifdef CONFIG_PCI_HOST_THUNDER_PEM
/* Pass2.0 */
{ "CAVIUM", "THUNDERX", 1, MCFG_DOM_RANGE(4, 9), MCFG_BUS_ANY, NULL,
  thunder_pem_cfg_init },
{ "CAVIUM", "THUNDERX", 1, MCFG_DOM_RANGE(14, 19), MCFG_BUS_ANY, NULL,
  thunder_pem_cfg_init },
#endif
#ifdef CONFIG_PCI_HISI_ACPI
{ "HISI  ", "HIP05   ", 0, MCFG_DOM_RANGE(0, 3), MCFG_BUS_ANY,
  NULL, hisi_pcie_acpi_hip05_init},
{ "HISI  ", "HIP06   ", 0, MCFG_DOM_RANGE(0, 3), MCFG_BUS_ANY,
  NULL, hisi_pcie_acpi_hip06_init},
{ "HISI  ", "HIP07   ", 

Re: [PATCH V6 2/5] PCI/ACPI: Check platform specific ECAM quirks

[Dongdong Liu]

Hi Tomasz

在 2016/9/10 3:24, Tomasz Nowicki 写道:

Some platforms may not be fully compliant with generic set of PCI config
accessors. For these cases we implement the way to overwrite CFG accessors
set and configuration space range.

In first place pci_mcfg_parse() saves machine's IDs and revision number
(these come from MCFG header) in order to match against known quirk entries.
Then the algorithm traverses available quirk list (static array),
matches against  and
returns custom PCI config ops and/or CFG resource structure.

When adding new quirk there are two possibilities:
1. Override default pci_generic_ecam_ops ops but CFG resource comes from MCFG
{ "OEM_ID", "OEM_TABLE_ID", , , , _ops, MCFG_RES_EMPTY 
},
2. Override default pci_generic_ecam_ops ops and CFG resource. For this case
it is also allowed get CFG resource from quirk entry w/o having it in MCFG.
{ "OEM_ID", "OEM_TABLE_ID", , , , _ops,
   DEFINE_RES_MEM(START, SIZE) },

pci_generic_ecam_ops and MCFG entries will be used for platforms
free from quirks.

Signed-off-by: Tomasz Nowicki 
Signed-off-by: Dongdong Liu 
Signed-off-by: Christopher Covington 
---
  drivers/acpi/pci_mcfg.c | 80 +
  1 file changed, 74 insertions(+), 6 deletions(-)

diff --git a/drivers/acpi/pci_mcfg.c b/drivers/acpi/pci_mcfg.c
index ffcc651..2b8acc7 100644
--- a/drivers/acpi/pci_mcfg.c
+++ b/drivers/acpi/pci_mcfg.c
@@ -32,6 +32,59 @@ struct mcfg_entry {
u8  bus_start;
u8  bus_end;
  };
+struct mcfg_fixup {
+   char oem_id[ACPI_OEM_ID_SIZE + 1];
+   char oem_table_id[ACPI_OEM_TABLE_ID_SIZE + 1];
+   u32 oem_revision;
+   u16 seg;
+   struct resource bus_range;
+   struct pci_ecam_ops *ops;
+   struct resource cfgres;
+};
+
+#define MCFG_DOM_ANY   (-1)
+#define MCFG_BUS_RANGE(start, end) DEFINE_RES_NAMED((start),   \
+   ((end) - (start) + 1),  \
+   NULL, IORESOURCE_BUS)
+#define MCFG_BUS_ANY   MCFG_BUS_RANGE(0x0, 0xff)
+#define MCFG_RES_EMPTY DEFINE_RES_NAMED(0, 0, NULL, 0)
+
+static struct mcfg_fixup mcfg_quirks[] = {
+/* { OEM_ID, OEM_TABLE_ID, REV, DOMAIN, BUS_RANGE, cfgres, ops }, */
+};
+
+static char mcfg_oem_id[ACPI_OEM_ID_SIZE];
+static char mcfg_oem_table_id[ACPI_OEM_TABLE_ID_SIZE];
+static u32 mcfg_oem_revision;
+
+static void pci_mcfg_match_quirks(struct acpi_pci_root *root,
+ struct resource *cfgres,
+ struct pci_ecam_ops **ecam_ops)
+{
+   struct mcfg_fixup *f;
+   int i;
+
+   /*
+* First match against PCI topology  then use OEM ID, OEM
+* table ID, and OEM revision from MCFG table standard header.
+*/
+   for (i = 0, f = mcfg_quirks; i < ARRAY_SIZE(mcfg_quirks); i++, f++) {
+   if (f->seg == root->segment &&


why not use MCFG_DOM_RANGE, I think MCFG_DOM_RANGE is better.
if drop MCFG_DOM_RANGE, mcfg_quirks[] will be more complex.

static struct mcfg_fixup mcfg_quirks[] = {
/*  { OEM_ID, OEM_TABLE_ID, REV, DOMAIN, BUS_RANGE, cfgres, ops }, */
#ifdef CONFIG_PCI_HOST_THUNDER_ECAM
/* SoC pass1.x */
{ "CAVIUM", "THUNDERX", 2, 0, MCFG_BUS_ANY, _thunder_ecam_ops,
  MCFG_RES_EMPTY},
{ "CAVIUM", "THUNDERX", 2, 1, MCFG_BUS_ANY, _thunder_ecam_ops,
  MCFG_RES_EMPTY},
{ "CAVIUM", "THUNDERX", 2, 2, MCFG_BUS_ANY, _thunder_ecam_ops,
  MCFG_RES_EMPTY},
{ "CAVIUM", "THUNDERX", 2, 3, MCFG_BUS_ANY, _thunder_ecam_ops,
  MCFG_RES_EMPTY},
{ "CAVIUM", "THUNDERX", 2, 10, MCFG_BUS_ANY, _thunder_ecam_ops,
  MCFG_RES_EMPTY},
{ "CAVIUM", "THUNDERX", 2, 11, MCFG_BUS_ANY, _thunder_ecam_ops,
  MCFG_RES_EMPTY},
{ "CAVIUM", "THUNDERX", 2, 12, MCFG_BUS_ANY, _thunder_ecam_ops,
  MCFG_RES_EMPTY},
{ "CAVIUM", "THUNDERX", 2, 13, MCFG_BUS_ANY, _thunder_ecam_ops,
  MCFG_RES_EMPTY},
#endif
.
};

As PATCH v5 we only need define mcfg_quirks as below, It looks better.
static struct pci_cfg_fixup mcfg_quirks[] __initconst = {
/*  { OEM_ID, OEM_TABLE_ID, REV, DOMAIN, BUS_RANGE, pci_ops, init_hook }, */
#ifdef CONFIG_PCI_HOST_THUNDER_PEM
/* Pass2.0 */
{ "CAVIUM", "THUNDERX", 1, MCFG_DOM_RANGE(4, 9), MCFG_BUS_ANY, NULL,
  thunder_pem_cfg_init },
{ "CAVIUM", "THUNDERX", 1, MCFG_DOM_RANGE(14, 19), MCFG_BUS_ANY, NULL,
  thunder_pem_cfg_init },
#endif
#ifdef CONFIG_PCI_HISI_ACPI
{ "HISI  ", "HIP05   ", 0, MCFG_DOM_RANGE(0, 3), MCFG_BUS_ANY,
  NULL, hisi_pcie_acpi_hip05_init},
{ "HISI  ", "HIP06   ", 0, MCFG_DOM_RANGE(0, 3), MCFG_BUS_ANY,
  NULL, hisi_pcie_acpi_hip06_init},
{ "HISI  ", "HIP07   ", 0, MCFG_DOM_RANGE(0, 15), MCFG_BUS_ANY,
  NULL, hisi_pcie_acpi_hip07_init},
#endif
};


+   

[RFC][PATCH v1 2/2] libsas: Fix hotplug issue in libsas

[Yijing Wang]

Now the libsas hotplug has some issues, Dan Williams report
a similar bug here:
https://www.mail-archive.com/linux-scsi@vger.kernel.org/msg39187.html

The root cause of the issues is we use one workqueue(shost->work_q) to
process libsas event, and we divide a hot-on or hot-remove flow to several
events to process. E.g. we start a new work and queue it into the same
workqueue in sas_deform_port() to remove the children devices after
the sas port. So if there is one hot-on event between remove sas port
and destruct the children devices, some unexpected errors would
be caused.

This patch modify hotplug event process mechanism to solve the
hotplug problems in libsas. We move device add/del operation to
a new workqueue(named sas_dev_wq).

And we use sas_port_alloc_num to replace sas_port_alloc function
because when discovery is concurrently executing with the device
adding or destroying, the old sas port resource may have not
completely deleted, the new sas port resource of the same name
will be created, and this will cause calltrace about sysfs
device node.

Signed-off-by: Yijing Wang 
Signed-off-by: Yousong He 
Signed-off-by: Qilin Chen 
---
 drivers/scsi/libsas/sas_ata.c   |   34 ++---
 drivers/scsi/libsas/sas_discover.c  |  245 +-
 drivers/scsi/libsas/sas_expander.c  |   54 ++--
 drivers/scsi/libsas/sas_init.c  |   26 -
 drivers/scsi/libsas/sas_internal.h  |   46 ++-
 drivers/scsi/libsas/sas_port.c  |   12 ++-
 drivers/scsi/libsas/sas_scsi_host.c |   23 
 include/scsi/libsas.h   |5 +-
 include/scsi/sas_ata.h  |4 +-
 9 files changed, 340 insertions(+), 109 deletions(-)

diff --git a/drivers/scsi/libsas/sas_ata.c b/drivers/scsi/libsas/sas_ata.c
index 763f012..877efa8 100644
--- a/drivers/scsi/libsas/sas_ata.c
+++ b/drivers/scsi/libsas/sas_ata.c
@@ -619,32 +619,22 @@ static int sas_get_ata_command_set(struct domain_device 
*dev)
return ata_dev_classify();
 }
 
-void sas_probe_sata(struct asd_sas_port *port)
+void sas_probe_sata_device(struct domain_device *dev)
 {
-   struct domain_device *dev, *n;
-
-   mutex_lock(>ha->disco_mutex);
-   list_for_each_entry(dev, >disco_list, disco_list_node) {
-   if (!dev_is_sata(dev))
-   continue;
-
-   ata_sas_async_probe(dev->sata_dev.ap);
-   }
-   mutex_unlock(>ha->disco_mutex);
+   struct asd_sas_port *port = dev->port;
 
-   list_for_each_entry_safe(dev, n, >disco_list, disco_list_node) {
-   if (!dev_is_sata(dev))
-   continue;
+   if (!port || !port->ha || !dev_is_sata(dev))
+   return;
 
-   sas_ata_wait_eh(dev);
+   ata_sas_async_probe(dev->sata_dev.ap);
 
-   /* if libata could not bring the link up, don't surface
-* the device
-*/
-   if (ata_dev_disabled(sas_to_ata_dev(dev)))
-   sas_fail_probe(dev, __func__, -ENODEV);
-   }
+   sas_ata_wait_eh(dev);
 
+   /* if libata could not bring the link up, don't surface
+* the device
+*/
+   if (ata_dev_disabled(sas_to_ata_dev(dev)))
+   sas_fail_probe(dev, __func__, -ENODEV);
 }
 
 static void sas_ata_flush_pm_eh(struct asd_sas_port *port, const char *func)
@@ -729,7 +719,7 @@ int sas_discover_sata(struct domain_device *dev)
if (res)
return res;
 
-   sas_discover_event(dev->port, DISCE_PROBE);
+   sas_notify_device_event(dev, SAS_DEVICE_ADD);
return 0;
 }
 
diff --git a/drivers/scsi/libsas/sas_discover.c 
b/drivers/scsi/libsas/sas_discover.c
index 60de662..ea57c66 100644
--- a/drivers/scsi/libsas/sas_discover.c
+++ b/drivers/scsi/libsas/sas_discover.c
@@ -34,6 +34,12 @@
 #include 
 #include "../scsi_sas_internal.h"
 
+
+static void sas_unregister_common_dev(struct asd_sas_port *port,
+   struct domain_device *dev);
+static void sas_unregister_fail_dev(struct asd_sas_port *port,
+   struct domain_device *dev);
+
 /* -- Basic task processing for discovery purposes -- */
 
 void sas_init_dev(struct domain_device *dev)
@@ -158,11 +164,8 @@ static int sas_get_port_device(struct asd_sas_port *port)
 
if (dev_is_sata(dev) || dev->dev_type == SAS_END_DEVICE)
list_add_tail(>disco_list_node, >disco_list);
-   else {
-   spin_lock_irq(>dev_list_lock);
-   list_add_tail(>dev_list_node, >dev_list);
-   spin_unlock_irq(>dev_list_lock);
-   }
+   else
+   list_add_tail(>dev_list_node, >expander_list);
 
spin_lock_irq(>phy_list_lock);
list_for_each_entry(phy, >phy_list, port_phy_el)
@@ -212,34 +215,83 @@ void sas_notify_lldd_dev_gone(struct domain_device *dev)
}
 }
 
-static void 

[RFC][PATCH v1 2/2] libsas: Fix hotplug issue in libsas

[Yijing Wang]

Now the libsas hotplug has some issues, Dan Williams report
a similar bug here:
https://www.mail-archive.com/linux-scsi@vger.kernel.org/msg39187.html

The root cause of the issues is we use one workqueue(shost->work_q) to
process libsas event, and we divide a hot-on or hot-remove flow to several
events to process. E.g. we start a new work and queue it into the same
workqueue in sas_deform_port() to remove the children devices after
the sas port. So if there is one hot-on event between remove sas port
and destruct the children devices, some unexpected errors would
be caused.

This patch modify hotplug event process mechanism to solve the
hotplug problems in libsas. We move device add/del operation to
a new workqueue(named sas_dev_wq).

And we use sas_port_alloc_num to replace sas_port_alloc function
because when discovery is concurrently executing with the device
adding or destroying, the old sas port resource may have not
completely deleted, the new sas port resource of the same name
will be created, and this will cause calltrace about sysfs
device node.

Signed-off-by: Yijing Wang 
Signed-off-by: Yousong He 
Signed-off-by: Qilin Chen 
---
 drivers/scsi/libsas/sas_ata.c   |   34 ++---
 drivers/scsi/libsas/sas_discover.c  |  245 +-
 drivers/scsi/libsas/sas_expander.c  |   54 ++--
 drivers/scsi/libsas/sas_init.c  |   26 -
 drivers/scsi/libsas/sas_internal.h  |   46 ++-
 drivers/scsi/libsas/sas_port.c  |   12 ++-
 drivers/scsi/libsas/sas_scsi_host.c |   23 
 include/scsi/libsas.h   |5 +-
 include/scsi/sas_ata.h  |4 +-
 9 files changed, 340 insertions(+), 109 deletions(-)

diff --git a/drivers/scsi/libsas/sas_ata.c b/drivers/scsi/libsas/sas_ata.c
index 763f012..877efa8 100644
--- a/drivers/scsi/libsas/sas_ata.c
+++ b/drivers/scsi/libsas/sas_ata.c
@@ -619,32 +619,22 @@ static int sas_get_ata_command_set(struct domain_device 
*dev)
return ata_dev_classify();
 }
 
-void sas_probe_sata(struct asd_sas_port *port)
+void sas_probe_sata_device(struct domain_device *dev)
 {
-   struct domain_device *dev, *n;
-
-   mutex_lock(>ha->disco_mutex);
-   list_for_each_entry(dev, >disco_list, disco_list_node) {
-   if (!dev_is_sata(dev))
-   continue;
-
-   ata_sas_async_probe(dev->sata_dev.ap);
-   }
-   mutex_unlock(>ha->disco_mutex);
+   struct asd_sas_port *port = dev->port;
 
-   list_for_each_entry_safe(dev, n, >disco_list, disco_list_node) {
-   if (!dev_is_sata(dev))
-   continue;
+   if (!port || !port->ha || !dev_is_sata(dev))
+   return;
 
-   sas_ata_wait_eh(dev);
+   ata_sas_async_probe(dev->sata_dev.ap);
 
-   /* if libata could not bring the link up, don't surface
-* the device
-*/
-   if (ata_dev_disabled(sas_to_ata_dev(dev)))
-   sas_fail_probe(dev, __func__, -ENODEV);
-   }
+   sas_ata_wait_eh(dev);
 
+   /* if libata could not bring the link up, don't surface
+* the device
+*/
+   if (ata_dev_disabled(sas_to_ata_dev(dev)))
+   sas_fail_probe(dev, __func__, -ENODEV);
 }
 
 static void sas_ata_flush_pm_eh(struct asd_sas_port *port, const char *func)
@@ -729,7 +719,7 @@ int sas_discover_sata(struct domain_device *dev)
if (res)
return res;
 
-   sas_discover_event(dev->port, DISCE_PROBE);
+   sas_notify_device_event(dev, SAS_DEVICE_ADD);
return 0;
 }
 
diff --git a/drivers/scsi/libsas/sas_discover.c 
b/drivers/scsi/libsas/sas_discover.c
index 60de662..ea57c66 100644
--- a/drivers/scsi/libsas/sas_discover.c
+++ b/drivers/scsi/libsas/sas_discover.c
@@ -34,6 +34,12 @@
 #include 
 #include "../scsi_sas_internal.h"
 
+
+static void sas_unregister_common_dev(struct asd_sas_port *port,
+   struct domain_device *dev);
+static void sas_unregister_fail_dev(struct asd_sas_port *port,
+   struct domain_device *dev);
+
 /* -- Basic task processing for discovery purposes -- */
 
 void sas_init_dev(struct domain_device *dev)
@@ -158,11 +164,8 @@ static int sas_get_port_device(struct asd_sas_port *port)
 
if (dev_is_sata(dev) || dev->dev_type == SAS_END_DEVICE)
list_add_tail(>disco_list_node, >disco_list);
-   else {
-   spin_lock_irq(>dev_list_lock);
-   list_add_tail(>dev_list_node, >dev_list);
-   spin_unlock_irq(>dev_list_lock);
-   }
+   else
+   list_add_tail(>dev_list_node, >expander_list);
 
spin_lock_irq(>phy_list_lock);
list_for_each_entry(phy, >phy_list, port_phy_el)
@@ -212,34 +215,83 @@ void sas_notify_lldd_dev_gone(struct domain_device *dev)
}
 }
 
-static void sas_probe_devices(struct work_struct *work)
+static void sas_add_device(struct 

[RFC][PATCH v1 1/2] libsas: Alloc dynamic work to avoid missing sas events

[Yijing Wang]

Now libsas hotplug work is static, LLDD driver queue
the hotplug work into shost->work_q. If LLDD driver
burst post lots hotplug event to libsas, the hotplug
events may pending in the workqueue like

shost->workq
tail | PHYE_LOSS_OF_SIGNAL  | PORTE_BYTES_DMAED | head

In this case, if a new PORTE_BYTES_DMAED event coming,
it would be lost, because we can not queue a work which
is already pending in the workqueue, also libsas has a
pending bit to avoid queue the same event.

The lost hotplug event make something confusing, e.g.
we have sas disks connected hardware, but we can not
found them in kernel.

This patch remove the static defined hotplug work,
and use dynamic work to avoid missing hotplug events.

Signed-off-by: Yijing Wang 
Signed-off-by: Yousong He 
Signed-off-by: Qilin Chen 
---
 drivers/scsi/libsas/sas_event.c|   61 ---
 drivers/scsi/libsas/sas_init.c |5 +--
 drivers/scsi/libsas/sas_internal.h |3 ++
 drivers/scsi/libsas/sas_phy.c  |   50 -
 drivers/scsi/libsas/sas_port.c |   23 --
 include/scsi/libsas.h  |8 -
 6 files changed, 66 insertions(+), 84 deletions(-)

diff --git a/drivers/scsi/libsas/sas_event.c b/drivers/scsi/libsas/sas_event.c
index aadbd53..993156c 100644
--- a/drivers/scsi/libsas/sas_event.c
+++ b/drivers/scsi/libsas/sas_event.c
@@ -27,6 +27,10 @@
 #include "sas_internal.h"
 #include "sas_dump.h"
 
+static const work_func_t sas_ha_event_fns[HA_NUM_EVENTS] = {
+   [HAE_RESET] = sas_hae_reset,
+};
+
 void sas_queue_work(struct sas_ha_struct *ha, struct sas_work *sw)
 {
if (!test_bit(SAS_HA_REGISTERED, >state))
@@ -40,17 +44,14 @@ void sas_queue_work(struct sas_ha_struct *ha, struct 
sas_work *sw)
scsi_queue_work(ha->core.shost, >work);
 }
 
-static void sas_queue_event(int event, unsigned long *pending,
-   struct sas_work *work,
+static void sas_queue_event(int event, struct sas_work *work,
struct sas_ha_struct *ha)
 {
-   if (!test_and_set_bit(event, pending)) {
-   unsigned long flags;
+   unsigned long flags;
 
-   spin_lock_irqsave(>lock, flags);
-   sas_queue_work(ha, work);
-   spin_unlock_irqrestore(>lock, flags);
-   }
+   spin_lock_irqsave(>lock, flags);
+   sas_queue_work(ha, work);
+   spin_unlock_irqrestore(>lock, flags);
 }
 
 
@@ -111,52 +112,60 @@ void sas_enable_revalidation(struct sas_ha_struct *ha)
if (!test_and_clear_bit(ev, >pending))
continue;
 
-   sas_queue_event(ev, >pending, >disc_work[ev].work, ha);
+   sas_queue_event(ev, >disc_work[ev].work, ha);
}
mutex_unlock(>disco_mutex);
 }
 
 static void notify_ha_event(struct sas_ha_struct *sas_ha, enum ha_event event)
 {
+   struct sas_ha_event *ev;
+
BUG_ON(event >= HA_NUM_EVENTS);
 
-   sas_queue_event(event, _ha->pending,
-   _ha->ha_events[event].work, sas_ha);
+   ev = kzalloc(sizeof(*ev), GFP_KERNEL);
+   if (!ev)
+   return;
+
+   INIT_SAS_WORK(>work, sas_ha_event_fns[event]);
+   ev->ha = sas_ha;
+   sas_queue_event(event, >work, sas_ha);
 }
 
 static void notify_port_event(struct asd_sas_phy *phy, enum port_event event)
 {
+   struct asd_sas_event *ev;
struct sas_ha_struct *ha = phy->ha;
 
BUG_ON(event >= PORT_NUM_EVENTS);
 
-   sas_queue_event(event, >port_events_pending,
-   >port_events[event].work, ha);
+   ev = kzalloc(sizeof(*ev), GFP_KERNEL);
+   if (!ev)
+   return;
+
+   INIT_SAS_WORK(>work, sas_port_event_fns[event]);
+   ev->phy = phy;
+   sas_queue_event(event, >work, ha);
 }
 
 void sas_notify_phy_event(struct asd_sas_phy *phy, enum phy_event event)
 {
+   struct asd_sas_event *ev;
struct sas_ha_struct *ha = phy->ha;
 
BUG_ON(event >= PHY_NUM_EVENTS);
 
-   sas_queue_event(event, >phy_events_pending,
-   >phy_events[event].work, ha);
+   ev = kzalloc(sizeof(*ev), GFP_KERNEL);
+   if (!ev)
+   return;
+
+   INIT_SAS_WORK(>work, sas_phy_event_fns[event]);
+   ev->phy = phy;
+   sas_queue_event(event, >work, ha);
 }
 
 int sas_init_events(struct sas_ha_struct *sas_ha)
 {
-   static const work_func_t sas_ha_event_fns[HA_NUM_EVENTS] = {
-   [HAE_RESET] = sas_hae_reset,
-   };
-
-   int i;
-
-   for (i = 0; i < HA_NUM_EVENTS; i++) {
-   INIT_SAS_WORK(_ha->ha_events[i].work, sas_ha_event_fns[i]);
-   sas_ha->ha_events[i].ha = sas_ha;
-   }
-
sas_ha->notify_ha_event = notify_ha_event;
sas_ha->notify_port_event = notify_port_event;
sas_ha->notify_phy_event = sas_notify_phy_event;
diff --git 

[RFC][PATCH v1 1/2] libsas: Alloc dynamic work to avoid missing sas events

[Yijing Wang]

Now libsas hotplug work is static, LLDD driver queue
the hotplug work into shost->work_q. If LLDD driver
burst post lots hotplug event to libsas, the hotplug
events may pending in the workqueue like

shost->workq
tail | PHYE_LOSS_OF_SIGNAL  | PORTE_BYTES_DMAED | head

In this case, if a new PORTE_BYTES_DMAED event coming,
it would be lost, because we can not queue a work which
is already pending in the workqueue, also libsas has a
pending bit to avoid queue the same event.

The lost hotplug event make something confusing, e.g.
we have sas disks connected hardware, but we can not
found them in kernel.

This patch remove the static defined hotplug work,
and use dynamic work to avoid missing hotplug events.

Signed-off-by: Yijing Wang 
Signed-off-by: Yousong He 
Signed-off-by: Qilin Chen 
---
 drivers/scsi/libsas/sas_event.c|   61 ---
 drivers/scsi/libsas/sas_init.c |5 +--
 drivers/scsi/libsas/sas_internal.h |3 ++
 drivers/scsi/libsas/sas_phy.c  |   50 -
 drivers/scsi/libsas/sas_port.c |   23 --
 include/scsi/libsas.h  |8 -
 6 files changed, 66 insertions(+), 84 deletions(-)

diff --git a/drivers/scsi/libsas/sas_event.c b/drivers/scsi/libsas/sas_event.c
index aadbd53..993156c 100644
--- a/drivers/scsi/libsas/sas_event.c
+++ b/drivers/scsi/libsas/sas_event.c
@@ -27,6 +27,10 @@
 #include "sas_internal.h"
 #include "sas_dump.h"
 
+static const work_func_t sas_ha_event_fns[HA_NUM_EVENTS] = {
+   [HAE_RESET] = sas_hae_reset,
+};
+
 void sas_queue_work(struct sas_ha_struct *ha, struct sas_work *sw)
 {
if (!test_bit(SAS_HA_REGISTERED, >state))
@@ -40,17 +44,14 @@ void sas_queue_work(struct sas_ha_struct *ha, struct 
sas_work *sw)
scsi_queue_work(ha->core.shost, >work);
 }
 
-static void sas_queue_event(int event, unsigned long *pending,
-   struct sas_work *work,
+static void sas_queue_event(int event, struct sas_work *work,
struct sas_ha_struct *ha)
 {
-   if (!test_and_set_bit(event, pending)) {
-   unsigned long flags;
+   unsigned long flags;
 
-   spin_lock_irqsave(>lock, flags);
-   sas_queue_work(ha, work);
-   spin_unlock_irqrestore(>lock, flags);
-   }
+   spin_lock_irqsave(>lock, flags);
+   sas_queue_work(ha, work);
+   spin_unlock_irqrestore(>lock, flags);
 }
 
 
@@ -111,52 +112,60 @@ void sas_enable_revalidation(struct sas_ha_struct *ha)
if (!test_and_clear_bit(ev, >pending))
continue;
 
-   sas_queue_event(ev, >pending, >disc_work[ev].work, ha);
+   sas_queue_event(ev, >disc_work[ev].work, ha);
}
mutex_unlock(>disco_mutex);
 }
 
 static void notify_ha_event(struct sas_ha_struct *sas_ha, enum ha_event event)
 {
+   struct sas_ha_event *ev;
+
BUG_ON(event >= HA_NUM_EVENTS);
 
-   sas_queue_event(event, _ha->pending,
-   _ha->ha_events[event].work, sas_ha);
+   ev = kzalloc(sizeof(*ev), GFP_KERNEL);
+   if (!ev)
+   return;
+
+   INIT_SAS_WORK(>work, sas_ha_event_fns[event]);
+   ev->ha = sas_ha;
+   sas_queue_event(event, >work, sas_ha);
 }
 
 static void notify_port_event(struct asd_sas_phy *phy, enum port_event event)
 {
+   struct asd_sas_event *ev;
struct sas_ha_struct *ha = phy->ha;
 
BUG_ON(event >= PORT_NUM_EVENTS);
 
-   sas_queue_event(event, >port_events_pending,
-   >port_events[event].work, ha);
+   ev = kzalloc(sizeof(*ev), GFP_KERNEL);
+   if (!ev)
+   return;
+
+   INIT_SAS_WORK(>work, sas_port_event_fns[event]);
+   ev->phy = phy;
+   sas_queue_event(event, >work, ha);
 }
 
 void sas_notify_phy_event(struct asd_sas_phy *phy, enum phy_event event)
 {
+   struct asd_sas_event *ev;
struct sas_ha_struct *ha = phy->ha;
 
BUG_ON(event >= PHY_NUM_EVENTS);
 
-   sas_queue_event(event, >phy_events_pending,
-   >phy_events[event].work, ha);
+   ev = kzalloc(sizeof(*ev), GFP_KERNEL);
+   if (!ev)
+   return;
+
+   INIT_SAS_WORK(>work, sas_phy_event_fns[event]);
+   ev->phy = phy;
+   sas_queue_event(event, >work, ha);
 }
 
 int sas_init_events(struct sas_ha_struct *sas_ha)
 {
-   static const work_func_t sas_ha_event_fns[HA_NUM_EVENTS] = {
-   [HAE_RESET] = sas_hae_reset,
-   };
-
-   int i;
-
-   for (i = 0; i < HA_NUM_EVENTS; i++) {
-   INIT_SAS_WORK(_ha->ha_events[i].work, sas_ha_event_fns[i]);
-   sas_ha->ha_events[i].ha = sas_ha;
-   }
-
sas_ha->notify_ha_event = notify_ha_event;
sas_ha->notify_port_event = notify_port_event;
sas_ha->notify_phy_event = sas_notify_phy_event;
diff --git a/drivers/scsi/libsas/sas_init.c b/drivers/scsi/libsas/sas_init.c
index 

[PATCH v2 10/20] ManagementStyle.rst: convert it to ReST markup

[Mauro Carvalho Chehab]

- Convert document name to ReST;
- Convert footnotes;
- Convert sections to ReST format;
- Don't use _foo_, as Sphinx doesn't support underline. Instead,
  use bold;
- While here, remove whitespaces at the end of lines.

Signed-off-by: Mauro Carvalho Chehab 
---
 .../development-process/ManagementStyle.rst| 152 +++--
 1 file changed, 80 insertions(+), 72 deletions(-)

diff --git a/Documentation/development-process/ManagementStyle.rst 
b/Documentation/development-process/ManagementStyle.rst
index a211ee8d8b44..86c5a19e08f3 100644
--- a/Documentation/development-process/ManagementStyle.rst
+++ b/Documentation/development-process/ManagementStyle.rst
@@ -1,10 +1,10 @@
-
-Linux kernel management style
+Linux kernel management style
+=
 
 This is a short document describing the preferred (or made up, depending
 on who you ask) management style for the linux kernel.  It's meant to
 mirror the CodingStyle document to some degree, and mainly written to
-avoid answering (*) the same (or similar) questions over and over again. 
+avoid answering [#f1]_  the same (or similar) questions over and over again.
 
 Management style is very personal and much harder to quantify than
 simple coding style rules, so this document may or may not have anything
@@ -14,50 +14,52 @@ might not actually be true. You'll have to decide for 
yourself.
 Btw, when talking about "kernel manager", it's all about the technical
 lead persons, not the people who do traditional management inside
 companies.  If you sign purchase orders or you have any clue about the
-budget of your group, you're almost certainly not a kernel manager. 
-These suggestions may or may not apply to you. 
+budget of your group, you're almost certainly not a kernel manager.
+These suggestions may or may not apply to you.
 
 First off, I'd suggest buying "Seven Habits of Highly Effective
-People", and NOT read it.  Burn it, it's a great symbolic gesture. 
+People", and NOT read it.  Burn it, it's a great symbolic gesture.
 
-(*) This document does so not so much by answering the question, but by
-making it painfully obvious to the questioner that we don't have a clue
-to what the answer is. 
+.. [#f1] This document does so not so much by answering the question, but by
+  making it painfully obvious to the questioner that we don't have a clue
+  to what the answer is.
 
 Anyway, here goes:
 
+.. _decisions:
 
-   Chapter 1: Decisions
+Decisions
+-
 
 Everybody thinks managers make decisions, and that decision-making is
 important.  The bigger and more painful the decision, the bigger the
 manager must be to make it.  That's very deep and obvious, but it's not
-actually true. 
+actually true.
 
-The name of the game is to _avoid_ having to make a decision.  In
+The name of the game is to **avoid** having to make a decision.  In
 particular, if somebody tells you "choose (a) or (b), we really need you
 to decide on this", you're in trouble as a manager.  The people you
 manage had better know the details better than you, so if they come to
 you for a technical decision, you're screwed.  You're clearly not
-competent to make that decision for them. 
+competent to make that decision for them.
 
 (Corollary:if the people you manage don't know the details better than
-you, you're also screwed, although for a totally different reason. 
-Namely that you are in the wrong job, and that _they_ should be managing
-your brilliance instead). 
+you, you're also screwed, although for a totally different reason.
+Namely that you are in the wrong job, and that **they** should be managing
+your brilliance instead).
 
-So the name of the game is to _avoid_ decisions, at least the big and
+So the name of the game is to **avoid** decisions, at least the big and
 painful ones.  Making small and non-consequential decisions is fine, and
 makes you look like you know what you're doing, so what a kernel manager
 needs to do is to turn the big and painful ones into small things where
-nobody really cares. 
+nobody really cares.
 
 It helps to realize that the key difference between a big decision and a
 small one is whether you can fix your decision afterwards.  Any decision
 can be made small by just always making sure that if you were wrong (and
-you _will_ be wrong), you can always undo the damage later by
+you **will** be wrong), you can always undo the damage later by
 backtracking.  Suddenly, you get to be doubly managerial for making
-_two_ inconsequential decisions - the wrong one _and_ the right one. 
+**two** inconsequential decisions - the wrong one **and** the right one.
 
 And people will even see that as true leadership (*cough* bullshit
 *cough*).
@@ -65,10 +67,10 @@ And people will even see that as true leadership (*cough* 
bullshit
 Thus the key to avoiding big decisions becomes to just avoiding to do
 things that can't be undone.  Don't get ushered into a corner from 

[PATCH v2 10/20] ManagementStyle.rst: convert it to ReST markup

[Mauro Carvalho Chehab]

- Convert document name to ReST;
- Convert footnotes;
- Convert sections to ReST format;
- Don't use _foo_, as Sphinx doesn't support underline. Instead,
  use bold;
- While here, remove whitespaces at the end of lines.

Signed-off-by: Mauro Carvalho Chehab 
---
 .../development-process/ManagementStyle.rst| 152 +++--
 1 file changed, 80 insertions(+), 72 deletions(-)

diff --git a/Documentation/development-process/ManagementStyle.rst 
b/Documentation/development-process/ManagementStyle.rst
index a211ee8d8b44..86c5a19e08f3 100644
--- a/Documentation/development-process/ManagementStyle.rst
+++ b/Documentation/development-process/ManagementStyle.rst
@@ -1,10 +1,10 @@
-
-Linux kernel management style
+Linux kernel management style
+=
 
 This is a short document describing the preferred (or made up, depending
 on who you ask) management style for the linux kernel.  It's meant to
 mirror the CodingStyle document to some degree, and mainly written to
-avoid answering (*) the same (or similar) questions over and over again. 
+avoid answering [#f1]_  the same (or similar) questions over and over again.
 
 Management style is very personal and much harder to quantify than
 simple coding style rules, so this document may or may not have anything
@@ -14,50 +14,52 @@ might not actually be true. You'll have to decide for 
yourself.
 Btw, when talking about "kernel manager", it's all about the technical
 lead persons, not the people who do traditional management inside
 companies.  If you sign purchase orders or you have any clue about the
-budget of your group, you're almost certainly not a kernel manager. 
-These suggestions may or may not apply to you. 
+budget of your group, you're almost certainly not a kernel manager.
+These suggestions may or may not apply to you.
 
 First off, I'd suggest buying "Seven Habits of Highly Effective
-People", and NOT read it.  Burn it, it's a great symbolic gesture. 
+People", and NOT read it.  Burn it, it's a great symbolic gesture.
 
-(*) This document does so not so much by answering the question, but by
-making it painfully obvious to the questioner that we don't have a clue
-to what the answer is. 
+.. [#f1] This document does so not so much by answering the question, but by
+  making it painfully obvious to the questioner that we don't have a clue
+  to what the answer is.
 
 Anyway, here goes:
 
+.. _decisions:
 
-   Chapter 1: Decisions
+Decisions
+-
 
 Everybody thinks managers make decisions, and that decision-making is
 important.  The bigger and more painful the decision, the bigger the
 manager must be to make it.  That's very deep and obvious, but it's not
-actually true. 
+actually true.
 
-The name of the game is to _avoid_ having to make a decision.  In
+The name of the game is to **avoid** having to make a decision.  In
 particular, if somebody tells you "choose (a) or (b), we really need you
 to decide on this", you're in trouble as a manager.  The people you
 manage had better know the details better than you, so if they come to
 you for a technical decision, you're screwed.  You're clearly not
-competent to make that decision for them. 
+competent to make that decision for them.
 
 (Corollary:if the people you manage don't know the details better than
-you, you're also screwed, although for a totally different reason. 
-Namely that you are in the wrong job, and that _they_ should be managing
-your brilliance instead). 
+you, you're also screwed, although for a totally different reason.
+Namely that you are in the wrong job, and that **they** should be managing
+your brilliance instead).
 
-So the name of the game is to _avoid_ decisions, at least the big and
+So the name of the game is to **avoid** decisions, at least the big and
 painful ones.  Making small and non-consequential decisions is fine, and
 makes you look like you know what you're doing, so what a kernel manager
 needs to do is to turn the big and painful ones into small things where
-nobody really cares. 
+nobody really cares.
 
 It helps to realize that the key difference between a big decision and a
 small one is whether you can fix your decision afterwards.  Any decision
 can be made small by just always making sure that if you were wrong (and
-you _will_ be wrong), you can always undo the damage later by
+you **will** be wrong), you can always undo the damage later by
 backtracking.  Suddenly, you get to be doubly managerial for making
-_two_ inconsequential decisions - the wrong one _and_ the right one. 
+**two** inconsequential decisions - the wrong one **and** the right one.
 
 And people will even see that as true leadership (*cough* bullshit
 *cough*).
@@ -65,10 +67,10 @@ And people will even see that as true leadership (*cough* 
bullshit
 Thus the key to avoiding big decisions becomes to just avoiding to do
 things that can't be undone.  Don't get ushered into a corner from which
 you cannot escape.  A